In this context, we are resolving A and AAAA resource records for names that we found in NS records, right? Yet, RFC 2181, § 10.3 disallows pointing to an alias from an NS record. If anything, Zonemaster should report an error in this situation, instead of following CNAMEs.

Yet, RFC 2181, § 10.3 disallows pointing to an alias from an NS record. If anything, Zonemaster should report an error in this situation, instead of following CNAMEs.

It is correct that the hostname in the RDATA of an NS record must not have a CNAME record, and Bind will not follow a CNAME. This is the method collecting as many name servers for the zone as possible to be able report as many issues as possible. The methods do not report any issues at all. That is up to the test cases to do.

Delegation05 checks if the name server names has a CNAME record, and if so outputs NS_IS_CNAME on ERROR level

Okay, then I understand the rationale. I’d just suggest adding a remark on why Zonemaster follows aliases in that specific case, even though NS records aren’t supposed to point to any. Then it should be fine.

A clarification of the resolution of CNAME has been added. @marc-vanderwal @tgreenx, please re-review.

@tgreenx, can I just merge? Is any update in the implementation needed?

@tgreenx, can I just merge? Is any update in the implementation needed?

Yes you can, Zonemaster now follows CNAME in recursive queries (zonemaster/zonemaster-engine#1288).