> On 8 Feb 2021, at 14:00, Anthony Lieuallen via dns-operations > <[email protected] <mailto:[email protected]>> wrote: > > > From: Anthony Lieuallen <[email protected] <mailto:[email protected]>> > Subject: NXDOMAIN status, with answers? > Date: 8 February 2021 at 14:00:49 GMT > To: [email protected] <mailto:[email protected]> > > > An interesting corner case has recently been brought to our attention, and > I'm hoping for some additional viewpoints to help me understand how best to > handle it. > > An operator reported problems with our recursive resolver, after recently > enabling DNSSEC. The cause seems to be that the authoritative server is > returning an answer (a CNAME, in case it matters) but with NXDOMAIN status. > When we see NXDOMAIN we abort our recursive resolving behavior. Later we get > to the DNSSEC validation phase, but because we stopped at the NXDOMAIN we > never got the DNSKEYs for the zone, and we thus fail to validate, and return > SERVFAIL. > > Other resolvers seem to be handling this domain successfully, so I'm > wondering: > > * Is this (NXDOMAIN status, but CNAME and RRSIG in the answer) valid, per the > spec?
Yes. The canonical name (the right-hand side of the CNAME, the name in the rdata) does not exist. That is, the alias points to something that doesn’t exist. Is the canonical name in the same zone as the owner name of the CNAME record? > * Either way, how should a recursive handle such an authoritative response? This is a valid, albeit rare, terminating response. You can not trust the RCODE in the response. You have proof of existence of the CNAME (it has an RRSIG), and there may be a set of NSEC(or NSEC3) records proving absence of the canonical name (provided the canonical name should be in the same zone). If the latter (proof of absence) is not there, you should restart the query with the canonical name. Hope this helps Roy > > > _______________________________________________ > dns-operations mailing list > [email protected] <mailto:[email protected]> > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
