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