[dns-operations] NXDOMAIN status, with answers?
davidb at verisign.com
Mon Feb 8 14:43:18 UTC 2021
> On Feb 8, 2021, at 9:00 AM, Anthony Lieuallen via dns-operations <dns-operations at dns-oarc.net> wrote:
> 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?
> * Either way, how should a recursive handle such an authoritative response?
The best resource for this is RFC 6604. In particular it says in section 3:
When there is an xNAME chain, the RCODE field is set as follows:
When an xNAME chain is followed, all but the last query cycle
necessarily had no error. The RCODE in the ultimate DNS response
MUST BE set based on the final query cycle leading to that
response. If the xNAME chain was terminated by an error, it will
be that error code. If the xNAME chain terminated without error,
it will be zero.
Yes, this type of response is valid.
However, if you are validating DNSSEC, surely you need to validate any NXDOMAIN response, regardless of the presence of a CNAME. I'm not sure how you can do that if you fail to get the DNSKEYs for the zone when you encounter one.
David Blacka <davidb at verisign.com>
Verisign Fellow Verisign Product Engineering
More information about the dns-operations