7Internet Engineering Task Force (IETF) S. Bortzmeyer
8Request for Comments: 8020 AFNIC
9Updates: 1034, 2308 S. Huque
10Category: Standards Track Verisign Labs
11ISSN: 2070-1721 November 2016
14 NXDOMAIN: There Really Is Nothing Underneath
18 This document states clearly that when a DNS resolver receives a
19 response with a response code of NXDOMAIN, it means that the domain
20 name which is thus denied AND ALL THE NAMES UNDER IT do not exist.
22 This document clarifies RFC 1034 and modifies a portion of RFC 2308:
23 it updates both of them.
27 This is an Internet Standards Track document.
29 This document is a product of the Internet Engineering Task Force
30 (IETF). It represents the consensus of the IETF community. It has
31 received public review and has been approved for publication by the
32 Internet Engineering Steering Group (IESG). Further information on
33 Internet Standards is available in Section 2 of RFC 7841.
35 Information about the current status of this document, any errata,
36 and how to provide feedback on it may be obtained at
37 http://www.rfc-editor.org/info/rfc8020.
41 Copyright (c) 2016 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
58Bortzmeyer & Huque Standards Track [Page 1]
60RFC 8020 NXDOMAIN Cut November 2016
65 1. Introduction and Background .....................................2
66 1.1. Terminology ................................................3
67 2. Rules ...........................................................3
68 3. Updates to RFCs .................................................5
69 3.1. Updates to RFC 1034 ........................................5
70 3.2. Updates to RFC 2308 ........................................5
71 4. Benefits ........................................................5
72 5. Possible Issues .................................................6
73 6. Implementation Considerations ...................................6
74 7. Security Considerations .........................................7
75 8. References ......................................................7
76 8.1. Normative References .......................................7
77 8.2. Informative References .....................................8
78 Appendix A. Why can't we just use the owner name of the returned
79 SOA? ...................................................9
80 Appendix B. Related Approaches .....................................9
81 Acknowledgments ....................................................9
82 Authors' Addresses ................................................10
841. Introduction and Background
86 The DNS protocol [RFC1035] defines response code 3 as "Name Error",
87 or "NXDOMAIN" [RFC2308], which means that the queried domain name
88 does not exist in the DNS. Since domain names are represented as a
89 tree of labels ([RFC1034], Section 3.1), nonexistence of a node
90 implies nonexistence of the entire subtree rooted at this node.
92 The DNS iterative resolution algorithm precisely interprets the
93 NXDOMAIN signal in this manner. If it encounters an NXDOMAIN
94 response code from an authoritative server, it immediately stops
95 iteration and returns the NXDOMAIN response to the querier.
97 However, in most known existing resolvers today, a cached
98 nonexistence for a domain is not considered "proof" that there can be
99 no child domains underneath. This is due to an ambiguity in
100 [RFC1034] that failed to distinguish Empty Non-Terminal (ENT) names
101 ([RFC7719]) from nonexistent names (Section 3.1). The distinction
102 became especially important for the development of DNSSEC, which
103 provides proof of nonexistence. [RFC4035], Section 3.1.3.2,
104 describes how security-aware authoritative name servers make the
105 distinction, but no existing RFCs describe the behavior for recursive
114Bortzmeyer & Huque Standards Track [Page 2]
116RFC 8020 NXDOMAIN Cut November 2016
119 This document specifies that an NXDOMAIN response for a domain name
120 means that no child domains underneath the queried name exist either;
121 furthermore, it means that DNS resolvers should interpret cached
122 nonexistence in this manner. Since the domain names are organized in
123 a tree, it is a simple consequence of the tree structure:
124 nonexistence of a node implies nonexistence of the entire subtree
129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
131 document are to be interpreted as described in [RFC2119].
133 "QNAME": defined in [RFC1034] and in [RFC1035], Section 4.1.2, but,
134 because [RFC2308] provides a different definition, we repeat the
135 original one here: the QNAME is the domain name in the question
138 "Denied name": the domain name whose existence has been denied by a
139 response RCODE of NXDOMAIN. In most cases, it is the QNAME but,
140 because of [RFC6604], it is not always the case.
142 Other terms are defined in [RFC1034], [RFC1035], and (like NXDOMAIN
143 itself) in the more recent [RFC7719].
145 The domain name space is conceptually defined in terms of a tree
146 structure. The implementation of a DNS resolver/cache MAY use a tree
147 or other data structures. The cache being a subset of the data in
148 the domain name space, it is much easier to reason about it in terms
149 of that tree structure and to describe things in those terms (names
150 under/above, descendant names, subtrees, etc.). In fact, the DNS
151 algorithm description in [RFC1034] even states an assumption that the
152 cache is a tree structure, so the precedent is already well
153 established: see its Section 4.3.2, which says "The following
154 algorithm assumes that the RRs are organized in several tree
155 structures, one for each zone, and another for the cache..." So, in
156 this document, each time we talk about a tree or tree operations,
157 we're referring to the model, not to the actual implementation.
161 When an iterative caching DNS resolver receives an NXDOMAIN response,
162 it SHOULD store it in its cache and then all names and resource
163 record sets (RRsets) at or below that node SHOULD be considered
164 unreachable. Subsequent queries for such names SHOULD elicit an
170Bortzmeyer & Huque Standards Track [Page 3]
172RFC 8020 NXDOMAIN Cut November 2016
175 But, if a resolver has cached data under the NXDOMAIN cut, it MAY
176 continue to send it as a reply (until the TTL of this cached data
177 expires), since this may avoid additional processing when a query is
178 received. Section 6 provides more information about this.
180 Another exception is that a validating resolver MAY decide to
181 implement the "NXDOMAIN cut" behavior (described in the first
182 paragraph of this section) only when the NXDOMAIN response has been
183 validated with DNSSEC. See Section 7 for the rationale.
185 The fact that a subtree does not exist is not forever: [RFC2308],
186 Section 3, already describes the amount of time that an NXDOMAIN
187 response may be cached (the "negative TTL").
189 If the NXDOMAIN response due to a cached nonexistence is from a
190 DNSSEC-signed zone, then it will have accompanying NSEC or NSEC3
191 records that authenticate the nonexistence of the name. For a
192 descendant name of the original NXDOMAIN name, the same set of NSEC
193 or NSEC3 records proves the nonexistence of the descendant name. The
194 iterative, caching resolver MUST return these NSEC or NSEC3 records
195 in the response to the triggering query if the query had the DNSSEC
198 Warning: if there is a chain of CNAME (or DNAME), the name that does
199 not exist is the last of the chain ([RFC6604]) and not the QNAME.
200 The NXDOMAIN stored in the cache is for the denied name, not always
203 As an example of the consequence of these rules, consider two
204 successive queries to a resolver with a nonexisting domain
205 'foo.example': the first is for 'foo.example' (which results in an
206 NXDOMAIN) and the second for 'bar.foo.example' (which also results in
207 an NXDOMAIN). Many resolvers today will forward both queries.
208 However, following the rules in this document ("NXDOMAIN cut"), a
209 resolver would cache the first NXDOMAIN response, as a sign of
210 nonexistence, and then immediately return an NXDOMAIN response for
211 the second query, without transmitting it to an authoritative server.
213 If the first request is for 'bar.foo.example' and the second for
214 'baz.foo.example', then the first NXDOMAIN response won't tell
215 anything about 'baz.foo.example'; therefore, the second query will be
216 transmitted as it was before the use of "NXDOMAIN cut" optimization
226Bortzmeyer & Huque Standards Track [Page 4]
228RFC 8020 NXDOMAIN Cut November 2016
2333.1. Updates to RFC 1034
235 This document clarifies possible ambiguities in [RFC1034] that did
236 not clearly distinguish Empty Non-Terminal (ENT) names ([RFC7719])
237 from nonexistent names, and it refers to subsequent documents that
238 do. ENTs are nodes in the DNS that do not have resource record sets
239 associated with them but have descendant nodes that do. The correct
240 response to ENTs is NODATA (i.e., a response code of NOERROR and an
241 empty answer section). Additional clarifying language on these
242 points is provided in Section 7.16 of [RFC2136] and in Sections 2.2.2
243 and 2.2.3 of [RFC4592].
2453.2. Updates to RFC 2308
247 The second paragraph of Section 5 in [RFC2308] states the following:
249 A negative answer that resulted from a name error (NXDOMAIN)
250 should be cached such that it can be retrieved and returned in
251 response to another query for the same <QNAME, QCLASS> that
252 resulted in the cached negative response.
254 This document revises that paragraph to the following:
256 A negative answer that resulted from a name error (NXDOMAIN)
257 should be cached such that it can be retrieved and returned in
258 response to another query for the same <QNAME, QCLASS> that
259 resulted in the cached negative response, or where the QNAME is a
260 descendant of the original QNAME and the QCLASS is the same.
262 Section 2 above elaborates on the revised rule and specifies when it
263 may be reasonable to relax or ignore it.
267 The main benefit is a better efficiency of the caches. In the
268 example above, the resolver sends only one query instead of two, the
269 second one being answered from the cache. This will benefit the
270 entire DNS ecosystem, since the authoritative name servers will have
271 less unnecessary traffic to process.
273 The correct behavior (in [RFC1034] and made clearer in this document)
274 is especially useful when combined with QNAME minimization [RFC7816]
275 since it will allow a resolver to stop searching as soon as an
276 NXDOMAIN is encountered.
282Bortzmeyer & Huque Standards Track [Page 5]
284RFC 8020 NXDOMAIN Cut November 2016
287 "NXDOMAIN cut" may also help mitigate certain types of random QNAME
288 attacks [joost-dnsterror] and [balakrichenan-dafa888], where there is
289 a fixed suffix that does not exist. In these attacks against the
290 authoritative name server, queries are sent to resolvers for a QNAME
291 composed of a fixed suffix ("dafa888.wf" in one of the articles
292 above), which is typically nonexistent, and a random prefix,
293 different for each request. A resolver receiving these requests has
294 to forward them to the authoritative servers. With "NXDOMAIN cut", a
295 system administrator would just have to send to the resolver a query
296 for the fixed suffix, the resolver would get a NXDOMAIN and then
297 would stop forwarding the queries. (It would be better if the SOA
298 record in the NXDOMAIN response were sufficient to find the
299 nonexisting domain, but this is not the case, see Appendix A.)
303 Let's assume that the Top-Level Domain (TLD) example exists, but
304 foobar.example is not delegated (so the example's name servers will
305 reply NXDOMAIN for a query about anything.foobar.example). A system
306 administrator decides to name the internal machines of his
307 organization under office.foobar.example and uses a trick of his
308 resolver to forward requests about this zone to his local
309 authoritative name servers. "NXDOMAIN cut" would create problems
310 here; depending on the order of requests to the resolver, it may have
311 cached the nonexistence from example and therefore "deleted"
312 everything under it. This document assumes that such a setup is rare
313 and does not need to be supported.
315 Today, another possible issue exists; we see authoritative name
316 servers that reply to ENT ([RFC7719], Section 6) with NXDOMAIN
317 instead of the normal NODATA ([RFC7719], Section 3).
319 Such name servers are definitely wrong and have always been. Their
320 behaviour is incompatible with DNSSEC. Given the advantages of
321 "NXDOMAIN cut", there is little reason to support this behavior.
3236. Implementation Considerations
325 This section is non-normative and is composed only of various things
326 that may be useful for implementors. A recursive resolver may
327 implement its cache in many ways. The most obvious one is a tree
328 data structure, because it fits the data model of domain names. But,
329 in practice, other implementations are possible, as well as various
330 optimizations (such as a tree, augmented by an index of some common
338Bortzmeyer & Huque Standards Track [Page 6]
340RFC 8020 NXDOMAIN Cut November 2016
343 If a resolver implements its cache as a tree (without any
344 optimization), one way to follow the rules in Section 2 is as
345 follows: when receiving the NXDOMAIN, prune the subtree of positive
346 cache entries at that node or delete all individual cache entries for
347 names below that node. Then, when searching downward in its cache,
348 this iterative caching DNS resolver will stop searching if it
349 encounters a cached nonexistence.
351 Some resolvers may have a cache that is NOT organized as a tree (but,
352 for instance, as a dictionary); therefore, they have a reason to
353 ignore the rules of Section 2. So these rules use SHOULD and not
3567. Security Considerations
358 The technique described in this document may help against a denial-
359 of-service attack named "random qnames" described in Section 4.
361 If a resolver does not validate the answers with DNSSEC, or if the
362 zone is not signed, the resolver can of course be poisoned with a
363 false NXDOMAIN, thus, "deleting" a part of the domain name tree.
364 This denial-of-service attack is already possible without the rules
365 of this document (but "NXDOMAIN cut" may increase its effects). The
366 only solution is to use DNSSEC.
3708.1. Normative References
372 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
373 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
374 <http://www.rfc-editor.org/info/rfc1034>.
376 [RFC1035] Mockapetris, P., "Domain names - implementation and
377 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
378 November 1987, <http://www.rfc-editor.org/info/rfc1035>.
380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
381 Requirement Levels", BCP 14, RFC 2119,
382 DOI 10.17487/RFC2119, March 1997,
383 <http://www.rfc-editor.org/info/rfc2119>.
385 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
386 "Dynamic Updates in the Domain Name System (DNS UPDATE)",
387 RFC 2136, DOI 10.17487/RFC2136, April 1997,
388 <http://www.rfc-editor.org/info/rfc2136>.
394Bortzmeyer & Huque Standards Track [Page 7]
396RFC 8020 NXDOMAIN Cut November 2016
399 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
400 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
401 <http://www.rfc-editor.org/info/rfc2308>.
403 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
404 System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
405 <http://www.rfc-editor.org/info/rfc4592>.
407 [RFC6604] Eastlake 3rd, D., "xNAME RCODE and Status Bits
408 Clarification", RFC 6604, DOI 10.17487/RFC6604, April
409 2012, <http://www.rfc-editor.org/info/rfc6604>.
4118.2. Informative References
413 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
414 Rose, "Protocol Modifications for the DNS Security
415 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
416 <http://www.rfc-editor.org/info/rfc4035>.
418 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
419 Terminology", RFC 7719, DOI 10.17487/RFC7719, December
420 2015, <http://www.rfc-editor.org/info/rfc7719>.
422 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve
423 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
424 <http://www.rfc-editor.org/info/rfc7816>.
426 [DNSRRR] Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS
427 Resolvers for Resiliency, Robustness, and Responsiveness",
428 Work in Progress, draft-vixie-dnsext-resimprove-00, June
431 [NSEC] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive use of
432 NSEC/NSEC3", Work in Progress, draft-ietf-dnsop-nsec-
433 aggressiveuse-04, September 2016.
436 Joost, M., "About DNS Attacks and ICMP Destination
437 Unreachable Reports", December 2014,
438 <http://www.michael-joost.de/dnsterror.html>.
440 [balakrichenan-dafa888]
441 Balakrichenan, S., "Disturbance in the DNS - "Random
442 qnames", the dafa888 DoS attack"", October 2014,
443 <https://indico.dns-oarc.net/event/20/session/3/
450Bortzmeyer & Huque Standards Track [Page 8]
452RFC 8020 NXDOMAIN Cut November 2016
455Appendix A. Why can't we just use the owner name of the returned SOA?
457 In this document, we deduce the nonexistence of a domain only for
458 NXDOMAIN answers where the denied name was the exact domain. If a
459 resolver sends a query to the name servers of the TLD example, asking
460 for the mail exchange (MX) record for www.foobar.example, and
461 subsequently receives a NXDOMAIN, it can only register the fact that
462 www.foobar.example (and everything underneath) does not exist. This
463 is true regardless of whether or not the accompanying SOA record is
464 for the domain example only. One cannot infer that foobar.example is
465 nonexistent. The accompanying SOA record indicates the apex of the
466 zone, not the closest existing domain name. So, using the owner name
467 of the SOA record in the authority section to deduce "NXDOMAIN cuts"
468 is currently definitely not OK.
470 Deducing the nonexistence of a node from the SOA in the NXDOMAIN
471 reply may certainly help with random qnames attacks, but this is out-
472 of-scope for this document. It would require addressing the problems
473 mentioned in the first paragraph of this section. A possible
474 solution is, when receiving a NXDOMAIN with a SOA that is more than
475 one label up in the tree, to send requests for the domains that are
476 between the QNAME and the owner name of the SOA. (A resolver that
477 does DNSSEC validation or QNAME minimization will need to do it
480Appendix B. Related Approaches
482 The document [NSEC] describes another way to address some of the same
483 concerns (decreasing the traffic for nonexisting domain names).
484 Unlike "NXDOMAIN cut", it requires DNSSEC, but it is more powerful
485 since it can synthesize NXDOMAINs for domains that were not queried.
489 The main idea in this document is taken from [DNSRRR], Section 3,
490 "Stopping Downward Cache Search on NXDOMAIN". Thanks to its authors,
491 Paul Vixie, Rodney Joffe, and Frederico Neves. Additionally, Tony
492 Finch, Ted Lemon, John Levine, Jinmei Tatuya, Bob Harold, and Duane
493 Wessels provided valuable feedback and suggestions.
506Bortzmeyer & Huque Standards Track [Page 9]
508RFC 8020 NXDOMAIN Cut November 2016
516 Montigny-le-Bretonneux 78180
519 Phone: +33 1 39 30 83 46
520 Email: bortzmeyer+ietf@nic.fr
521 URI: https://www.afnic.fr/
528 United States of America
530 Email: shuque@verisign.com
531 URI: http://www.verisignlabs.com/
562Bortzmeyer & Huque Standards Track [Page 10]