[dns-operations] NXDOMAIN status, with answers?

[Roy Arends]

> On 8 Feb 2021, at 14:00, Anthony Lieuallen via dns-operations <dns-operations at dns-oarc.net <mailto:dns-operations at dns-oarc.net>> wrote:
> 
> 
> From: Anthony Lieuallen <alieuall at google.com <mailto:alieuall at google.com>>
> Subject: NXDOMAIN status, with answers?
> Date: 8 February 2021 at 14:00:49 GMT
> To: dns-operations at dns-oarc.net <mailto:dns-operations at dns-oarc.net>
> 
> 
> 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
> dns-operations at lists.dns-oarc.net <mailto:dns-operations at lists.dns-oarc.net>
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20210208/b6882767/attachment.html>