NXDOMAIN: There Really Is Nothing Underneath
updates
Extracted elements (15)
The NXDOMAIN cut optimization is especially useful when combined with QNAME minimization (RFC 7816), since a resolver can stop searching as soon as an NXDOMAIN is encountered along the minimized query path.
The rules in Section 2 use SHOULD rather than MUST because some resolvers implement their cache as a dictionary rather than a tree structure, giving them a legitimate reason to be unable to follow the NXDOMAIN cut rules.
The SOA record owner name returned in an NXDOMAIN response cannot be used to infer the NXDOMAIN cut boundary, because the SOA indicates the zone apex rather than the closest existing domain name. Using it would be incorrect.
RFC 2308 Section 5's negative caching rule is updated: a cached NXDOMAIN response applies not only to the original <QNAME, QCLASS> but also to any descendant names under that QNAME in the same QCLASS.
Some authoritative name servers incorrectly reply with NXDOMAIN instead of NODATA for Empty Non-Terminal (ENT) names. This behavior is incompatible with DNSSEC and implementations should not support it.
Split-horizon DNS setups where a resolver forwards queries for a locally administered zone that appears nonexistent to public authoritative servers may be broken by NXDOMAIN cut; this document assumes such setups are rare and need not be supported.
The NXDOMAIN stored in the cache is for the denied name (the last name in a CNAME/DNAME chain per RFC 6604), not necessarily the QNAME. Implementations must account for CNAME/DNAME chains when determining which name is subject to the NXDOMAIN cut.
A resolver MAY continue to send cached data under an NXDOMAIN cut as a reply until the TTL of that cached data expires, since this may avoid additional processing when a query is received.
A validating resolver MAY implement the NXDOMAIN cut behavior only when the NXDOMAIN response has been validated with DNSSEC, as a safeguard against cache poisoning with false NXDOMAIN responses.
If the NXDOMAIN response due to a cached nonexistence is from a DNSSEC-signed zone, the iterative caching resolver MUST return the accompanying NSEC or NSEC3 records in the response to the triggering query if the query had the DNSSEC OK (DO) bit set.
When an iterative caching DNS resolver receives an NXDOMAIN response, it SHOULD store it in its cache and then all names and resource record sets (RRsets) at or below that node SHOULD be considered unreachable. Subsequent queries for such names SHOULD elicit an NXDOMAIN response.
Empty Non-Terminal (ENT) names are nodes in the DNS tree that have no resource record sets but have descendant nodes that do. The correct response to an ENT query is NODATA (RCODE NOERROR with empty answer section), not NXDOMAIN.
The 'denied name' is defined as the domain name whose existence has been denied by a response RCODE of NXDOMAIN. In most cases this is the QNAME, but due to RFC 6604, it may be the last name in a CNAME/DNAME chain.
If a resolver does not validate answers with DNSSEC, it can be poisoned with a false NXDOMAIN, effectively deleting a subtree of the domain name space. NXDOMAIN cut may amplify this attack's effects; DNSSEC validation is the only mitigation.
NXDOMAIN cut may help mitigate 'random qnames' denial-of-service attacks where queries with a fixed nonexistent suffix and random prefixes flood resolvers; once the resolver caches the NXDOMAIN for the fixed suffix, it stops forwarding the flood to authoritative servers.