NXDOMAIN really means there is nothing underneath

The DNS protocol defines response code 3 as "Name Error", or "NXDOMAIN", i.e. the queried domain name does not exist in the DNS. Since domain names are represented as a tree of labels (, Section 3.1), non-existence of a node implies non-existence of the entire sub-tree rooted at this node. The DNS iterative resolution algorithm precisely interprets the NXDOMAIN signal in this manner. If it encounters an NXDOMAIN response code from an authoritative server, it immediately stops iteration and returns the NXDOMAIN response to the querier. However, in virtually all existing resolvers, a cached NXDOMAIN is not considered "proof" that there can be no child domains underneath. This is due to an ambiguity in that failed to distinguish ENT (empty nonterminal domain names, ) from nonexistent names. For DNSSEC, the IETF had to distinguish this case (, section 3.1.3.2), but the implication on non-DNSSEC resolvers wasn't fully realized. This document specifies that an NXDOMAIN response for a domain name means that no child domains underneath the queried name exist either. And furthermore, that DNS resolvers should interpret cached NXDOMAIN responses in this manner. Since the domain names are organized in a tree, it is a simple consequence of the tree structure: non-existence of a node implies non-existence of the entire sub-tree rooted at this node.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

When searching downward in its cache, an iterative caching DNS resolver SHOULD stop searching if it encounters a cached NXDOMAIN. The response to the triggering query should be NXDOMAIN. TODO The next paragraph is challenged because too implementation-oriented. Should we just keep the first paragraph? My concern is that some resolvers may have an implementation of the cache made of a tree plus a hashed index and therefore won't "search downward" if they have a cached answer. When an iterative caching DNS resolver stores an NXDOMAIN in its cache, all names and RRsets at or below that node SHOULD be deleted since they will have become unreachable. "Deleted" means that subsequent requests for these names will yield NXDOMAIN. [TODO: currently under discussion, some people find it dangerous. MAY instead of SHOULD? Only if the NXDOMAIN is DNSSEC-validated? Perhaps the resolver could be configured to not "bulk delete" TLDs (or root). See .] [TODO: currently under discussion, some people find it costly for the resolver. A large purge also causes the resolver to do a lot of (possibly CPU intensive) work, and could also affect the traffic levels between a recursive and authoritatives. Perhaps a cache may want to limit the number of nodes/records that it deletes per NXDOMAIN response.] By implication, a stream of queries foo.example, then bar.foo.example, where foo.example does not exist would normally cause both queries to be forwarded to example's nameservers. Following this recommended practice of "NXDOMAIN cut", the second query and indeed any other query for names at or below foo.example would not be forwarded. These rules replace the second paragraph of section 5 of . Otherwise, applies unchanged, and the fact that a subtree does not exist is not forever: the NXDOMAIN is cached only for the duration of the "negative TTL" (section 3 of xref target="RFC2308"/>). Validating resolvers need to select the necessary NSEC or NSEC3 records and include them in the AUTHORITY section of the response to provide authenticated denial of existence for names underneath the NXDOMAIN boundary. Warning: because of , the name whose existence is denied by the NXDOMAIN is not always the QNAME. If there is a chain of CNAME (or DNAME), the name which does not exist is the last of the chain. TODO: find a dedicated terminology such as "NXDOMAINed name" or "denied domain" instead of "QNAME".

The main benefit is a better efficiency of the caches. In the example above, we send only one query instead of two, the second one being answered from the cache. The correct behavior (in and made clearer in this document) is specially useful when combined with QNAME minimisation since it will allow to stop searching as soon as a NXDOMAIN is encountered. NXDOMAIN cut may also help mitigate certain types of random QNAME attacks , where there is a fixed suffix which does not exist. In these attacks against the authoritative name server, queries are sent to resolvers for a QNAME composed of a fixed suffix ("dafa888.wf" in one of the articles above), which is typically nonexistent, and a random prefix, different for each request. A resolver receiving these requests have to forward them to the authoritative servers. With NXDOMAIN cut, we would just have to send to the resolver a query for the fixed suffix, the resolver would get a NXDOMAIN and then would stop forwarding the queries. (It would be better if the SOA record in the NXDOMAIN response were sufficient to find the non-existing domain but this is more delicate, see .) Since the principles set in this document are so great, why are the rules of SHOULD and not MUST? This is because some resolver may have a cache which is NOT organized as a tree (but, for instance, as a dictionary) and therefore have a good reason to ignore this.

Let's assume the TLD example exists but foobar.example is not delegated (so the example's name servers will reply NXDOMAIN for a query about anything.foobar.example). A system administrator decides to name the internal machines of his organization under office.foobar.example and use a trick of his resolver to forward requests about this zone to his local authoritative name servers. NXDOMAIN cut would create problems here, since, depending on the order of requests to the resolver, it may have cached the NXDOMAIN from example and therefore "deleted" everything under. This document assumes that such setup is rare and does not need to be supported. Another issue that may happen: today, we see broken authoritative name servers which reply to ENT (, section 6) with NXDOMAIN instead of the normal NODATA (, section 3). RFC-EDITOR: REMOVE THE PARAGRAPH BEFORE PUBLICATION. An example today is mta2._domainkey.cbs.nl (which exists) where querying _domainkey.cbs.nl yields NXDOMAIN. Another example is www.upenn.edu, redirected to www.upenn.edu-dscg.edgesuite.net while a query for edu-dscg.edgesuite.net returns NXDOMAIN. Such name servers are definitely broken and have always been. They MUST be fixed. Given the advantages of NXDOMAIN cuts, there is little reason to support this behavior.

TODO: drop this section entirely? Or just downgrade it to an appendix "why can't we just use the owner name of the returned SOA"? In this document, we deduce the non-existence of a domain only for NXDOMAIN answers where the QNAME was this exact domain. If a resolver sends a query to the name servers of the TLD example, and asks the MX record for www.foobar.example, and receives a NXDOMAIN, it can only register the fact that www.foobar.example (and everything underneath) does not exist. Even if the accompanying SOA record is for example only, one cannot infer that foobar.example is nonexistent. The accompanying SOA indicates the apex of the zone, not the closest existing domain name. RFC-EDITOR: REMOVE BEFORE PUBLICATION: to use a real example today, ask the authoritative name servers of the TLD fr about anything.which.does.not.exist.gouv.fr. The SOA will indicate fr (the apex) even while gouv.fr does exist (there is no zone cut between gouv.fr and fr). In the future, deducing the non-existence of a node from the SOA in the NXDOMAIN reply may certainly help with random qnames attacks but this is out-of-scope for this document. It would require to address the problems mentioned in the previous paragraph. A possible solution would be, when receiving a NXDOMAIN with a SOA which is more than one label up in the tree, to send requests for the domains which are between the QNAME and the owner name of the SOA. (A resolver which does DNSSEC validation or QNAME minimisation will need to do it, anyway.) TODO a mention of ? Unlike NXDOMAIN cut, it requires DNSSEC but it is more powerful since it can synthetize NXDOMAINs.

This document has no actions for IANA.

The technique described here may help against a denial-of-service attack named "random qnames" and described in . Apart from that, it is believed to have no security consequences. If a resolver does not validate the answers with DNSSEC, it can of course be poisoned with a false NXDOMAIN, thus "deleting" a part of the domain name tree. This denial-of-service attack is already possible with the rules of this document (but "NXDOMAIN cut" may increase its effects). The only solution is to use DNSSEC.

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". As of today, all existing DNS resolvers are conservative: they consider a NXDOMAIN as only significant for the name itself, not for the names under. All current recursive servers will upstream a query for out-of-cache sub.example.com even if their cache contains an NXDOMAIN for example.com.

The text of this document was mostly copied from , section 3. Thanks to its authors, Paul Vixie, Rodney Joffe and Frederico Neves. Thanks to Duane Wessels, Tony Finch and Jinmei Tatuya for fact checking and explanations.