1 Network Working Group M. Andrews
2 Request for Comments: 2308 CSIRO
3 Updates: 1034, 1035 March 1998
4 Category: Standards Track
5
6
7 Negative Caching of DNS Queries (DNS NCACHE)
8
9 Status of this Memo
10
11 This document specifies an Internet standards track protocol for the
12 Internet community, and requests discussion and suggestions for
13 improvements. Please refer to the current edition of the "Internet
14 Official Protocol Standards" (STD 1) for the standardization state
15 and status of this protocol. Distribution of this memo is unlimited.
16
17 Copyright Notice
18
19 Copyright (C) The Internet Society (1998). All Rights Reserved.
20
21 Abstract
22
23 [RFC1034] provided a description of how to cache negative responses.
24 It however had a fundamental flaw in that it did not allow a name
25 server to hand out those cached responses to other resolvers, thereby
26 greatly reducing the effect of the caching. This document addresses
27 issues raise in the light of experience and replaces [RFC1034 Section
28 4.3.4].
29
30 Negative caching was an optional part of the DNS specification and
31 deals with the caching of the non-existence of an RRset [RFC2181] or
32 domain name.
33
34 Negative caching is useful as it reduces the response time for
35 negative answers. It also reduces the number of messages that have
36 to be sent between resolvers and name servers hence overall network
37 traffic. A large proportion of DNS traffic on the Internet could be
38 eliminated if all resolvers implemented negative caching. With this
39 in mind negative caching should no longer be seen as an optional part
40 of a DNS resolver.
41
42
43
44
45
46
47
48
49
50
51
52 Andrews Standards Track [Page 1]
53 RFC 2308 DNS NCACHE March 1998
54
55
56 1 - Terminology
57
58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
60 document are to be interpreted as described in [RFC2119].
61
62 "Negative caching" - the storage of knowledge that something does not
63 exist. We can store the knowledge that a record has a particular
64 value. We can also do the reverse, that is, to store the knowledge
65 that a record does not exist. It is the storage of knowledge that
66 something does not exist, cannot or does not give an answer that we
67 call negative caching.
68
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.
This RFC is implemented in BIND 9.18 (all versions).
Section 4.7 of RFC4035, "Caching BAD Data", says:
Conceptually, caching such data is similar to negative caching ([RFC2308]), except that instead of caching a valid negative response, the resolver is caching the fact that a particular answer failed to validate. This document refers to a cache of data with invalid signatures as a "BAD cache".
Note that RFC4033 and RFC4034 say that they update RFC 2308, but don't.
69 "QNAME" - the name in the query section of an answer, or where this
70 resolves to a CNAME, or CNAME chain, the data field of the last
71 CNAME. The last CNAME in this sense is that which contains a value
72 which does not resolve to another CNAME. Implementations should note
73 that including CNAME records in responses in order, so that the first
74 has the label from the query section, and then each in sequence has
75 the label from the data section of the previous (where more than one
76 CNAME is needed) allows the sequence to be processed in one pass, and
77 considerably eases the task of the receiver. Other relevant records
78 (such as SIG RRs [RFC2065]) can be interspersed amongst the CNAMEs.
79
80 "NXDOMAIN" - an alternate expression for the "Name Error" RCODE as
81 described in [RFC1035 Section 4.1.1] and the two terms are used
82 interchangeably in this document.
83
84 "NODATA" - a pseudo RCODE which indicates that the name is valid, for
85 the given class, but are no records of the given type. A NODATA
86 response has to be inferred from the answer.
87
"QNAME" - the name in the query section of an answer, or where this resolves to a CNAME, or CNAME chain, the data field of the last CNAME.
"QNAME" - the name in the query section (RFC 1034, section 3.7.1).
See the definition of "QNAME" in RFC8499 for a long discussion of the defintion of QNAME, including why the definition in RFC 2308 is too limited.
88 "FORWARDER" - a nameserver used to resolve queries instead of
89 directly using the authoritative nameserver chain. The forwarder
90 typically either has better access to the internet, or maintains a
91 bigger cache which may be shared amongst many resolvers. How a
92 server is identified as a FORWARDER, or knows it is a FORWARDER is
93 outside the scope of this document. However if you are being used as
94 a forwarder the query will have the recursion desired flag set.
95
96 An understanding of [RFC1034], [RFC1035] and [RFC2065] is expected
97 when reading this document.
98
99
100
101
102
103
104
105
106
107 Andrews Standards Track [Page 2]
108 RFC 2308 DNS NCACHE March 1998
109
110
111 2 - Negative Responses
112
113 The most common negative responses indicate that a particular RRset
114 does not exist in the DNS. The first sections of this document deal
115 with this case. Other negative responses can indicate failures of a
116 nameserver, those are dealt with in section 7 (Other Negative
117 Responses).
118
119 A negative response is indicated by one of the following conditions:
120
See the definition of "forwarder" in RFC8499 for a
defintion of forwarders. In specific, it says that the definition in RFC 2308:
... appears to suggest that forwarders normally only query authoritative servers. In current use, however, forwarders often stand between stub resolvers and recursive servers. [RFC2308] is silent on whether a forwarder is iterative-only or can be a full-service resolver.
121 2.1 - Name Error
122
123 Name errors (NXDOMAIN) are indicated by the presence of "Name Error"
124 in the RCODE field. In this case the domain referred to by the QNAME
125 does not exist. Note: the answer section may have SIG and CNAME RRs
126 and the authority section may have SOA, NXT [RFC2065] and SIG RRsets.
127
128 It is possible to distinguish between a referral and a NXDOMAIN
129 response by the presense of NXDOMAIN in the RCODE regardless of the
130 presence of NS or SOA records in the authority section.
131
132 NXDOMAIN responses can be categorised into four types by the contents
133 of the authority section. These are shown below along with a
134 referral for comparison. Fields not mentioned are not important in
135 terms of the examples.
136
137 NXDOMAIN RESPONSE: TYPE 1.
138
139 Header:
140 RDCODE=NXDOMAIN
141 Query:
142 AN.EXAMPLE. A
143 Answer:
144 AN.EXAMPLE. CNAME TRIPPLE.XX.
145 Authority:
146 XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
147 XX. NS NS1.XX.
148 XX. NS NS2.XX.
149 Additional:
150 NS1.XX. A 127.0.0.2
151 NS2.XX. A 127.0.0.3
152
153 NXDOMAIN RESPONSE: TYPE 2.
154
155 Header:
156 RDCODE=NXDOMAIN
157 Query:
158 AN.EXAMPLE. A
159
160
161
162 Andrews Standards Track [Page 3]
163 RFC 2308 DNS NCACHE March 1998
164
165
166 Answer:
167 AN.EXAMPLE. CNAME TRIPPLE.XX.
168 Authority:
169 XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
170 Additional:
171 <empty>
172
173 NXDOMAIN RESPONSE: TYPE 3.
174
175 Header:
176 RDCODE=NXDOMAIN
177 Query:
178 AN.EXAMPLE. A
179 Answer:
180 AN.EXAMPLE. CNAME TRIPPLE.XX.
181 Authority:
182 <empty>
183 Additional:
184 <empty>
185
186 NXDOMAIN RESPONSE: TYPE 4
187
188 Header:
189 RDCODE=NXDOMAIN
190 Query:
191 AN.EXAMPLE. A
192 Answer:
193 AN.EXAMPLE. CNAME TRIPPLE.XX.
194 Authority:
195 XX. NS NS1.XX.
196 XX. NS NS2.XX.
197 Additional:
198 NS1.XX. A 127.0.0.2
199 NS2.XX. A 127.0.0.3
200
201 REFERRAL RESPONSE.
202
203 Header:
204 RDCODE=NOERROR
205 Query:
206 AN.EXAMPLE. A
207 Answer:
208 AN.EXAMPLE. CNAME TRIPPLE.XX.
209 Authority:
210 XX. NS NS1.XX.
211 XX. NS NS2.XX.
212 Additional:
213 NS1.XX. A 127.0.0.2
214
215
216
217 Andrews Standards Track [Page 4]
218 RFC 2308 DNS NCACHE March 1998
219
220
221 NS2.XX. A 127.0.0.3
222
223 Note, in the four examples of NXDOMAIN responses, it is known that
224 the name "AN.EXAMPLE." exists, and has as its value a CNAME record.
225 The NXDOMAIN refers to "TRIPPLE.XX", which is then known not to
226 exist. On the other hand, in the referral example, it is shown that
227 "AN.EXAMPLE" exists, and has a CNAME RR as its value, but nothing is
228 known one way or the other about the existence of "TRIPPLE.XX", other
229 than that "NS1.XX" or "NS2.XX" can be consulted as the next step in
230 obtaining information about it.
231
232 Where no CNAME records appear, the NXDOMAIN response refers to the
233 name in the label of the RR in the question section.
234
235 2.1.1 Special Handling of Name Error
236
237 This section deals with errors encountered when implementing negative
238 caching of NXDOMAIN responses.
239
240 There are a large number of resolvers currently in existence that
241 fail to correctly detect and process all forms of NXDOMAIN response.
242 Some resolvers treat a TYPE 1 NXDOMAIN response as a referral. To
243 alleviate this problem it is recommended that servers that are
244 authoritative for the NXDOMAIN response only send TYPE 2 NXDOMAIN
245 responses, that is the authority section contains a SOA record and no
246 NS records. If a non- authoritative server sends a type 1 NXDOMAIN
247 response to one of these old resolvers, the result will be an
248 unnecessary query to an authoritative server. This is undesirable,
249 but not fatal except when the server is being used a FORWARDER. If
250 however the resolver is using the server as a FORWARDER to such a
251 resolver it will be necessary to disable the sending of TYPE 1
252 NXDOMAIN response to it, use TYPE 2 NXDOMAIN instead.
253
254 Some resolvers incorrectly continue processing if the authoritative
255 answer flag is not set, looping until the query retry threshold is
256 exceeded and then returning SERVFAIL. This is a problem when your
257 nameserver is listed as a FORWARDER for such resolvers. If the
258 nameserver is used as a FORWARDER by such resolver, the authority
259 flag will have to be forced on for NXDOMAIN responses to these
260 resolvers. In practice this causes no problems even if turned on
261 always, and has been the default behaviour in BIND from 4.9.3
262 onwards.
263
264 2.2 - No Data
265
266 NODATA is indicated by an answer with the RCODE set to NOERROR and no
267 relevant answers in the answer section. The authority section will
268 contain an SOA record, or there will be no NS records there.
269
270
271
272 Andrews Standards Track [Page 5]
273 RFC 2308 DNS NCACHE March 1998
274
275
276 NODATA responses have to be algorithmically determined from the
277 response's contents as there is no RCODE value to indicate NODATA.
278 In some cases to determine with certainty that NODATA is the correct
279 response it can be necessary to send another query.
280
281 The authority section may contain NXT and SIG RRsets in addition to
282 NS and SOA records. CNAME and SIG records may exist in the answer
283 section.
284
285 It is possible to distinguish between a NODATA and a referral
286 response by the presence of a SOA record in the authority section or
287 the absence of NS records in the authority section.
288
289 NODATA responses can be categorised into three types by the contents
290 of the authority section. These are shown below along with a
291 referral for comparison. Fields not mentioned are not important in
292 terms of the examples.
293
294 NODATA RESPONSE: TYPE 1.
295
296 Header:
297 RDCODE=NOERROR
298 Query:
299 ANOTHER.EXAMPLE. A
300 Answer:
301 <empty>
302 Authority:
303 EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
304 EXAMPLE. NS NS1.XX.
305 EXAMPLE. NS NS2.XX.
306 Additional:
307 NS1.XX. A 127.0.0.2
308 NS2.XX. A 127.0.0.3
309
310 NO DATA RESPONSE: TYPE 2.
311
312 Header:
313 RDCODE=NOERROR
314 Query:
315 ANOTHER.EXAMPLE. A
316 Answer:
317 <empty>
318 Authority:
319 EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
320 Additional:
321 <empty>
322
323
324
325
326
327 Andrews Standards Track [Page 6]
328 RFC 2308 DNS NCACHE March 1998
329
330
331 NO DATA RESPONSE: TYPE 3.
332
333 Header:
334 RDCODE=NOERROR
335 Query:
336 ANOTHER.EXAMPLE. A
337 Answer:
338 <empty>
339 Authority:
340 <empty>
341 Additional:
342 <empty>
343
344 REFERRAL RESPONSE.
345
346 Header:
347 RDCODE=NOERROR
348 Query:
349 ANOTHER.EXAMPLE. A
350 Answer:
351 <empty>
352 Authority:
353 EXAMPLE. NS NS1.XX.
354 EXAMPLE. NS NS2.XX.
355 Additional:
356 NS1.XX. A 127.0.0.2
357 NS2.XX. A 127.0.0.3
358
359
360 These examples, unlike the NXDOMAIN examples above, have no CNAME
361 records, however they could, in just the same way that the NXDOMAIN
362 examples did, in which case it would be the value of the last CNAME
363 (the QNAME) for which NODATA would be concluded.
364
365 2.2.1 - Special Handling of No Data
366
367 There are a large number of resolvers currently in existence that
368 fail to correctly detect and process all forms of NODATA response.
369 Some resolvers treat a TYPE 1 NODATA response as a referral. To
370 alleviate this problem it is recommended that servers that are
371 authoritative for the NODATA response only send TYPE 2 NODATA
372 responses, that is the authority section contains a SOA record and no
373 NS records. Sending a TYPE 1 NODATA response from a non-
374 authoritative server to one of these resolvers will only result in an
375 unnecessary query. If a server is listed as a FORWARDER for another
376 resolver it may also be necessary to disable the sending of TYPE 1
377 NODATA response for non-authoritative NODATA responses.
378
379
380
381
382 Andrews Standards Track [Page 7]
383 RFC 2308 DNS NCACHE March 1998
384
385
386 Some name servers fail to set the RCODE to NXDOMAIN in the presence
387 of CNAMEs in the answer section. If a definitive NXDOMAIN / NODATA
388 answer is required in this case the resolver must query again using
389 the QNAME as the query label.
390
391 3 - Negative Answers from Authoritative Servers
392
393 Name servers authoritative for a zone MUST include the SOA record of
394 the zone in the authority section of the response when reporting an
395 NXDOMAIN or indicating that no data of the requested type exists.
396 This is required so that the response may be cached. The TTL of this
397 record is set from the minimum of the MINIMUM field of the SOA record
398 and the TTL of the SOA itself, and indicates how long a resolver may
399 cache the negative answer. The TTL SIG record associated with the
400 SOA record should also be trimmed in line with the SOA's TTL.
401
402 If the containing zone is signed [RFC2065] the SOA and appropriate
403 NXT and SIG records MUST be added.
404
405 4 - SOA Minimum Field
406
407 The SOA minimum field has been overloaded in the past to have three
408 different meanings, the minimum TTL value of all RRs in a zone, the
409 default TTL of RRs which did not contain a TTL value and the TTL of
410 negative responses.
411
412 Despite being the original defined meaning, the first of these, the
413 minimum TTL value of all RRs in a zone, has never in practice been
414 used and is hereby deprecated.
415
416 The second, the default TTL of RRs which contain no explicit TTL in
417 the master zone file, is relevant only at the primary server. After
418 a zone transfer all RRs have explicit TTLs and it is impossible to
419 determine whether the TTL for a record was explicitly set or derived
420 from the default after a zone transfer. Where a server does not
421 require RRs to include the TTL value explicitly, it should provide a
422 mechanism, not being the value of the MINIMUM field of the SOA
423 record, from which the missing TTL values are obtained. How this is
424 done is implementation dependent.
425
426 The Master File format [RFC 1035 Section 5] is extended to include
427 the following directive:
428
429 $TTL <TTL> [comment]
430
431
432
433
434
435
436
437 Andrews Standards Track [Page 8]
438 RFC 2308 DNS NCACHE March 1998
439
440
441 All resource records appearing after the directive, and which do not
442 explicitly include a TTL value, have their TTL set to the TTL given
443 in the $TTL directive. SIG records without a explicit TTL get their
444 TTL from the "original TTL" of the SIG record [RFC 2065 Section 4.5].
445
446 The remaining of the current meanings, of being the TTL to be used
447 for negative responses, is the new defined meaning of the SOA minimum
448 field.
449
450 5 - Caching Negative Answers
451
452 Like normal answers negative answers have a time to live (TTL). As
453 there is no record in the answer section to which this TTL can be
454 applied, the TTL must be carried by another method. This is done by
455 including the SOA record from the zone in the authority section of
456 the reply. When the authoritative server creates this record its TTL
457 is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
458 This TTL decrements in a similar manner to a normal cached answer and
459 upon reaching zero (0) indicates the cached negative answer MUST NOT
460 be used again.
461
RFC6604 says:
Section 2.1 of [RFC2308] implies that the RCODE should be set based on the last query cycle in the case of an xNAME chain, but Section 2.2.1 of [RFC2308] says that some servers don't do that! 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.
462 A negative answer that resulted from a name error (NXDOMAIN) should
463 be cached such that it can be retrieved and returned in response to
464 another query for the same <QNAME, QCLASS> that resulted in the
465 cached negative response.
466
467 A negative answer that resulted from a no data error (NODATA) should
468 be cached such that it can be retrieved and returned in response to
469 another query for the same <QNAME, QTYPE, QCLASS> that resulted in
470 the cached negative response.
471
472 The NXT record, if it exists in the authority section of a negative
473 answer received, MUST be stored such that it can be be located and
474 returned with SOA record in the authority section, as should any SIG
475 records in the authority section. For NXDOMAIN answers there is no
476 "necessary" obvious relationship between the NXT records and the
477 QNAME. The NXT record MUST have the same owner name as the query
478 name for NODATA responses.
479
480 Negative responses without SOA records SHOULD NOT be cached as there
481 is no way to prevent the negative responses looping forever between a
482 pair of servers even with a short TTL.
483
484 Despite the DNS forming a tree of servers, with various mis-
485 configurations it is possible to form a loop in the query graph, e.g.
486 two servers listing each other as forwarders, various lame server
487 configurations. Without a TTL count down a cache negative response
488
489
490
491
492 Andrews Standards Track [Page 9]
493 RFC 2308 DNS NCACHE March 1998
494
495
496 when received by the next server would have its TTL reset. This
497 negative indication could then live forever circulating between the
498 servers involved.
499
500 As with caching positive responses it is sensible for a resolver to
501 limit for how long it will cache a negative response as the protocol
502 supports caching for up to 68 years. Such a limit should not be
503 greater than that applied to positive answers and preferably be
504 tunable. Values of one to three hours have been found to work well
505 and would make sensible a default. Values exceeding one day have
506 been found to be problematic.
507
508 6 - Negative answers from the cache
509
510 When a server, in answering a query, encounters a cached negative
511 response it MUST add the cached SOA record to the authority section
512 of the response with the TTL decremented by the amount of time it was
513 stored in the cache. This allows the NXDOMAIN / NODATA response to
514 time out correctly.
515
516 If a NXT record was cached along with SOA record it MUST be added to
517 the authority section. If a SIG record was cached along with a NXT
518 record it SHOULD be added to the authority section.
519
520 As with all answers coming from the cache, negative answers SHOULD
521 have an implicit referral built into the answer. This enables the
522 resolver to locate an authoritative source. An implicit referral is
523 characterised by NS records in the authority section referring the
524 resolver towards a authoritative source. NXDOMAIN types 1 and 4
525 responses contain implicit referrals as does NODATA type 1 response.
526
527 7 - Other Negative Responses
528
529 Caching of other negative responses is not covered by any existing
530 RFC. There is no way to indicate a desired TTL in these responses.
531 Care needs to be taken to ensure that there are not forwarding loops.
532
533 7.1 Server Failure (OPTIONAL)
534
535 Server failures fall into two major classes. The first is where a
536 server can determine that it has been misconfigured for a zone. This
537 may be where it has been listed as a server, but not configured to be
538 a server for the zone, or where it has been configured to be a server
539 for the zone, but cannot obtain the zone data for some reason. This
540 can occur either because the zone file does not exist or contains
541 errors, or because another server from which the zone should have
542 been available either did not respond or was unable or unwilling to
543 supply the zone.
544
545
546
547 Andrews Standards Track [Page 10]
548 RFC 2308 DNS NCACHE March 1998
549
550
551 The second class is where the server needs to obtain an answer from
552 elsewhere, but is unable to do so, due to network failures, other
553 servers that don't reply, or return server failure errors, or
554 similar.
555
556 In either case a resolver MAY cache a server failure response. If it
557 does so it MUST NOT cache it for longer than five (5) minutes, and it
558 MUST be cached against the specific query tuple <query name, type,
559 class, server IP address>.
560
Section 2 of RFC8020 updates how NXDOMIN responses are cached. The section details the rationale for the update.
Section 3.2 of RFC8020 replaces this paragraph with:
A negative answer that resulted from a name error (NXDOMAIN) should be cached such that it can be retrieved and returned in response to another query for the same <QNAME, QCLASS> that resulted in the cached negative response, or where the QNAME is a descendant of the original QNAME and the QCLASS is the same.
561 7.2 Dead / Unreachable Server (OPTIONAL)
562
563 Dead / Unreachable servers are servers that fail to respond in any
564 way to a query or where the transport layer has provided an
565 indication that the server does not exist or is unreachable. A
566 server may be deemed to be dead or unreachable if it has not
567 responded to an outstanding query within 120 seconds.
568
569 Examples of transport layer indications are:
570
571 ICMP error messages indicating host, net or port unreachable.
572 TCP resets
573 IP stack error messages providing similar indications to those above.
574
575 A server MAY cache a dead server indication. If it does so it MUST
576 NOT be deemed dead for longer than five (5) minutes. The indication
577 MUST be stored against query tuple <query name, type, class, server
578 IP address> unless there was a transport layer indication that the
579 server does not exist, in which case it applies to all queries to
580 that specific IP address.
581
582 8 - Changes from RFC 1034
583
584 Negative caching in resolvers is no-longer optional, if a resolver
585 caches anything it must also cache negative answers.
586
587 Non-authoritative negative answers MAY be cached.
588
589 The SOA record from the authority section MUST be cached. Name error
590 indications must be cached against the tuple <query name, QCLASS>.
591 No data indications must be cached against <query name, QTYPE,
592 QCLASS> tuple.
593
594 A cached SOA record must be added to the response. This was
595 explicitly not allowed because previously the distinction between a
596 normal cached SOA record, and the SOA cached as a result of a
597 negative response was not made, and simply extracting a normal cached
598 SOA and adding that to a cached negative response causes problems.
599
600
601
602 Andrews Standards Track [Page 11]
603 RFC 2308 DNS NCACHE March 1998
604
605
606 The $TTL TTL directive was added to the master file format.
607
608 9 - History of Negative Caching
609
610 This section presents a potted history of negative caching in the DNS
611 and forms no part of the technical specification of negative caching.
612
613 It is interesting to note that the same concepts were re-invented in
614 both the CHIVES and BIND servers.
615
616 The history of the early CHIVES work (Section 9.1) was supplied by
617 Rob Austein <sra@epilogue.com> and is reproduced here in the form in
618 which he supplied it [MPA].
619
620 Sometime around the spring of 1985, I mentioned to Paul Mockapetris
621 that our experience with his JEEVES DNS resolver had pointed out the
622 need for some kind of negative caching scheme. Paul suggested that
623 we simply cache authoritative errors, using the SOA MINIMUM value for
624 the zone that would have contained the target RRs. I'm pretty sure
625 that this conversation took place before RFC-973 was written, but it
626 was never clear to me whether this idea was something that Paul came
627 up with on the spot in response to my question or something he'd
628 already been planning to put into the document that became RFC-973.
629 In any case, neither of us was entirely sure that the SOA MINIMUM
630 value was really the right metric to use, but it was available and
631 was under the control of the administrator of the target zone, both
632 of which seemed to us at the time to be important feature.
633
634 Late in 1987, I released the initial beta-test version of CHIVES, the
635 DNS resolver I'd written to replace Paul's JEEVES resolver. CHIVES
636 included a search path mechanism that was used pretty heavily at
637 several sites (including my own), so CHIVES also included a negative
638 caching mechanism based on SOA MINIMUM values. The basic strategy
639 was to cache authoritative error codes keyed by the exact query
640 parameters (QNAME, QCLASS, and QTYPE), with a cache TTL equal to the
641 SOA MINIMUM value. CHIVES did not attempt to track down SOA RRs if
642 they weren't supplied in the authoritative response, so it never
643 managed to completely eliminate the gratuitous DNS error message
644 traffic, but it did help considerably. Keep in mind that this was
645 happening at about the same time as the near-collapse of the ARPANET
646 due to congestion caused by exponential growth and the the "old"
647 (pre-VJ) TCP retransmission algorithm, so negative caching resulted
648 in drasticly better DNS response time for our users, mailer daemons,
649 etcetera.
650
651
652
653
654
655
656
657 Andrews Standards Track [Page 12]
658 RFC 2308 DNS NCACHE March 1998
659
660
661 As far as I know, CHIVES was the first resolver to implement negative
662 caching. CHIVES was developed during the twilight years of TOPS-20,
663 so it never ran on very many machines, but the few machines that it
664 did run on were the ones that were too critical to shut down quickly
665 no matter how much it cost to keep them running. So what few users
666 we did have tended to drive CHIVES pretty hard. Several interesting
667 bits of DNS technology resulted from that, but the one that's
668 relevant here is the MAXTTL configuration parameter.
669
670 Experience with JEEVES had already shown that RRs often showed up
671 with ridiculously long TTLs (99999999 was particularly popular for
672 many years, due to bugs in the code and documentation of several
673 early versions of BIND), and that robust software that blindly
674 believed such TTLs could create so many strange failures that it was
675 often necessary to reboot the resolver frequently just to clear this
676 garbage out of the cache. So CHIVES had a configuration parameter
677 "MAXTTL", which specified the maximum "reasonable" TTL in a received
678 RR. RRs with TTLs greater than MAXTTL would either have their TTLs
679 reduced to MAXTTL or would be discarded entirely, depending on the
680 setting of another configuration parameter.
681
682 When we started getting field experience with CHIVES's negative
683 caching code, it became clear that the SOA MINIMUM value was often
684 large enough to cause the same kinds of problems for negative caching
685 as the huge TTLs in RRs had for normal caching (again, this was in
686 part due to a bug in several early versions of BIND, where a
687 secondary server would authoritatively deny all knowledge of its
688 zones if it couldn't contact the primaries on reboot). So we started
689 running the negative cache TTLs through the MAXTTL check too, and
690 continued to experiment.
691
692 The configuration that seemed to work best on WSMR-SIMTEL20.ARMY.MIL
693 (last of the major Internet TOPS-20 machines to be shut down, thus
694 the last major user of CHIVES, thus the place where we had the
695 longest experimental baseline) was to set MAXTTL to about three days.
696 Most of the traffic initiated by SIMTEL20 in its last years was
697 mail-related, and the mail queue timeout was set to one week, so this
698 gave a "stuck" message several tries at complete DNS resolution,
699 without bogging down the system with a lot of useless queries. Since
700 (for reasons that now escape me) we only had the single MAXTTL
701 parameter rather than separate ones for positive and negative
702 caching, it's not clear how much effect this setting of MAXTTL had on
703 the negative caching code.
704
705 CHIVES also included a second, somewhat controversial mechanism which
706 took the place of negative caching in some cases. The CHIVES
707 resolver daemon could be configured to load DNS master files, giving
708 it the ability to act as what today would be called a "stealth
709
710
711
712 Andrews Standards Track [Page 13]
713 RFC 2308 DNS NCACHE March 1998
714
715
716 secondary". That is, when configured in this way, the resolver had
717 direct access to authoritative information for heavily-used zones.
718 The search path mechanisms in CHIVES reflected this: there were
719 actually two separate search paths, one of which only searched local
720 authoritative zone data, and one which could generate normal
721 iterative queries. This cut down on the need for negative caching in
722 cases where usage was predictably heavy (e.g., the resolver on
723 XX.LCS.MIT.EDU always loaded the zone files for both LCS.MIT.EDU and
724 AI.MIT.EDU and put both of these suffixes into the "local" search
725 path, since between them the hosts in these two zones accounted for
726 the bulk of the DNS traffic). Not all sites running CHIVES chose to
727 use this feature; C.CS.CMU.EDU, for example, chose to use the
728 "remote" search path for everything because there were too many
729 different sub-zones at CMU for zone shadowing to be practical for
730 them, so they relied pretty heavily on negative caching even for
731 local traffic.
732
733 Overall, I still think the basic design we used for negative caching
734 was pretty reasonable: the zone administrator specified how long to
735 cache negative answers, and the resolver configuration chose the
736 actual cache time from the range between zero and the period
737 specified by the zone administrator. There are a lot of details I'd
738 do differently now (like using a new SOA field instead of overloading
739 the MINIMUM field), but after more than a decade, I'd be more worried
740 if we couldn't think of at least a few improvements.
741
742 9.2 BIND
743
744 While not the first attempt to get negative caching into BIND, in
745 July 1993, BIND 4.9.2 ALPHA, Anant Kumar of ISI supplied code that
746 implemented, validation and negative caching (NCACHE). This code had
747 a 10 minute TTL for negative caching and only cached the indication
748 that there was a negative response, NXDOMAIN or NOERROR_NODATA. This
749 is the origin of the NODATA pseudo response code mentioned above.
750
751 Mark Andrews of CSIRO added code (RETURNSOA) that stored the SOA
752 record such that it could be retrieved by a similar query. UUnet
753 complained that they were getting old answers after loading a new
754 zone, and the option was turned off, BIND 4.9.3-alpha5, April 1994.
755 In reality this indicated that the named needed to purge the space
756 the zone would occupy. Functionality to do this was added in BIND
757 4.9.3 BETA11 patch2, December 1994.
758
759 RETURNSOA was re-enabled by default, BIND 4.9.5-T1A, August 1996.
760
761
762
763
764
765
766
767 Andrews Standards Track [Page 14]
768 RFC 2308 DNS NCACHE March 1998
769
770
771 10 Example
772
773 The following example is based on a signed zone that is empty apart
774 from the nameservers. We will query for WWW.XX.EXAMPLE showing
775 initial response and again 10 minutes later. Note 1: during the
776 intervening 10 minutes the NS records for XX.EXAMPLE have expired.
777 Note 2: the TTL of the SIG records are not explicitly set in the zone
778 file and are hence the TTL of the RRset they are the signature for.
779
780 Zone File:
781
782 $TTL 86400
783 $ORIGIN XX.EXAMPLE.
784 @ IN SOA NS1.XX.EXAMPLE. HOSTMATER.XX.EXAMPLE. (
785 1997102000 ; serial
786 1800 ; refresh (30 mins)
787 900 ; retry (15 mins)
788 604800 ; expire (7 days)
789 1200 ) ; minimum (20 mins)
790 IN SIG SOA ...
791 1200 IN NXT NS1.XX.EXAMPLE. A NXT SIG SOA NS KEY
792 IN SIG NXT ... XX.EXAMPLE. ...
793 300 IN NS NS1.XX.EXAMPLE.
794 300 IN NS NS2.XX.EXAMPLE.
795 IN SIG NS ... XX.EXAMPLE. ...
796 IN KEY 0x4100 1 1 ...
797 IN SIG KEY ... XX.EXAMPLE. ...
798 IN SIG KEY ... EXAMPLE. ...
799 NS1 IN A 10.0.0.1
800 IN SIG A ... XX.EXAMPLE. ...
801 1200 IN NXT NS2.XX.EXAMPLE. A NXT SIG
802 IN SIG NXT ...
803 NS2 IN A 10.0.0.2
804 IN SIG A ... XX.EXAMPLE. ...
805 1200 IN NXT XX.EXAMPLE. A NXT SIG
806 IN SIG NXT ... XX.EXAMPLE. ...
807
808 Initial Response:
809
810 Header:
811 RDCODE=NXDOMAIN, AA=1, QR=1, TC=0
812 Query:
813 WWW.XX.EXAMPLE. IN A
814 Answer:
815 <empty>
816 Authority:
817 XX.EXAMPLE. 1200 IN SOA NS1.XX.EXAMPLE. ...
818 XX.EXAMPLE. 1200 IN SIG SOA ... XX.EXAMPLE. ...
819
820
821
822 Andrews Standards Track [Page 15]
823 RFC 2308 DNS NCACHE March 1998
824
825
826 NS2.XX.EXAMPLE. 1200 IN NXT XX.EXAMPLE. NXT A NXT SIG
827 NS2.XX.EXAMPLE. 1200 IN SIG NXT ... XX.EXAMPLE. ...
828 XX.EXAMPLE. 86400 IN NS NS1.XX.EXAMPLE.
829 XX.EXAMPLE. 86400 IN NS NS2.XX.EXAMPLE.
830 XX.EXAMPLE. 86400 IN SIG NS ... XX.EXAMPLE. ...
831 Additional
832 XX.EXAMPLE. 86400 IN KEY 0x4100 1 1 ...
833 XX.EXAMPLE. 86400 IN SIG KEY ... EXAMPLE. ...
834 NS1.XX.EXAMPLE. 86400 IN A 10.0.0.1
835 NS1.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
836 NS2.XX.EXAMPLE. 86400 IN A 10.0.0.2
837 NS3.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
838
839 After 10 Minutes:
840
841 Header:
842 RDCODE=NXDOMAIN, AA=0, QR=1, TC=0
843 Query:
844 WWW.XX.EXAMPLE. IN A
845 Answer:
846 <empty>
847 Authority:
848 XX.EXAMPLE. 600 IN SOA NS1.XX.EXAMPLE. ...
849 XX.EXAMPLE. 600 IN SIG SOA ... XX.EXAMPLE. ...
850 NS2.XX.EXAMPLE. 600 IN NXT XX.EXAMPLE. NXT A NXT SIG
851 NS2.XX.EXAMPLE. 600 IN SIG NXT ... XX.EXAMPLE. ...
852 EXAMPLE. 65799 IN NS NS1.YY.EXAMPLE.
853 EXAMPLE. 65799 IN NS NS2.YY.EXAMPLE.
854 EXAMPLE. 65799 IN SIG NS ... XX.EXAMPLE. ...
855 Additional
856 XX.EXAMPLE. 65800 IN KEY 0x4100 1 1 ...
857 XX.EXAMPLE. 65800 IN SIG KEY ... EXAMPLE. ...
858 NS1.YY.EXAMPLE. 65799 IN A 10.100.0.1
859 NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
860 NS2.YY.EXAMPLE. 65799 IN A 10.100.0.2
861 NS3.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
862 EXAMPLE. 65799 IN KEY 0x4100 1 1 ...
863 EXAMPLE. 65799 IN SIG KEY ... . ...
864
865
866 11 Security Considerations
867
868 It is believed that this document does not introduce any significant
869 additional security threats other that those that already exist when
870 using data from the DNS.
871
872
873
874
875
876
877 Andrews Standards Track [Page 16]
878 RFC 2308 DNS NCACHE March 1998
879
880
881 With negative caching it might be possible to propagate a denial of
882 service attack by spreading a NXDOMAIN message with a very high TTL.
883 Without negative caching that would be much harder. A similar effect
884 could be achieved previously by spreading a bad A record, so that the
885 server could not be reached - which is almost the same. It has the
886 same effect as far as what the end user is able to do, but with a
887 different psychological effect. With the bad A, I feel "damn the
888 network is broken again" and try again tomorrow. With the "NXDOMAIN"
889 I feel "Oh, they've turned off the server and it doesn't exist any
890 more" and probably never bother trying this server again.
891
892 A practical example of this is a SMTP server where this behaviour is
893 encoded. With a NXDOMAIN attack the mail message would bounce
894 immediately, where as with a bad A attack the mail would be queued
895 and could potentially get through after the attack was suspended.
896
The history of the early CHIVES work (Section 9.1) was supplied by Rob Austein <sra@epilogue.com> and is reproduced here in the form in which he supplied it [MPA]. Sometime around the spring of 1985, I mentioned to Paul Mockapetris that our experience with his JEEVES DNS resolver had pointed out the need for some kind of negative caching scheme. Paul suggested that we simply cache authoritative errors, using the SOA MINIMUM value for the zone that would have contained the target RRs. I'm pretty sure that this conversation took place before RFC-973 was written, but it was never clear to me whether this idea was something that Paul came up with on the spot in response to my question or something he'd already been planning to put into the document that became RFC-973. In any case, neither of us was entirely sure that the SOA MINIMUM value was really the right metric to use, but it was available and was under the control of the administrator of the target zone, both of which seemed to us at the time to be important feature.
The history of the early CHIVES work (Section 9.1) was supplied by Rob Austein <sra@epilogue.com> and is reproduced here in the form in which he supplied it [MPA]. 9.1 CHIVES Sometime around the spring of 1985, I mentioned to Paul Mockapetris that our experience with his JEEVES DNS resolver had pointed out the need for some kind of negative caching scheme. Paul suggested that we simply cache authoritative errors, using the SOA MINIMUM value for the zone that would have contained the target RRs. I'm pretty sure that this conversation took place before RFC-973 was written, but it was never clear to me whether this idea was something that Paul came up with on the spot in response to my question or something he'd already been planning to put into the document that became RFC-973. In any case, neither of us was entirely sure that the SOA MINIMUM value was really the right metric to use, but it was available and was under the control of the administrator of the target zone, both of which seemed to us at the time to be important feature.
897 For such an attack to be successful, the NXDOMAIN indiction must be
898 injected into a parent server (or a busy caching resolver). One way
899 this might be done by the use of a CNAME which results in the parent
900 server querying an attackers server. Resolvers that wish to prevent
901 such attacks can query again the final QNAME ignoring any NS data in
902 the query responses it has received for this query.
903
904 Implementing TTL sanity checking will reduce the effectiveness of
905 such an attack, because a successful attack would require re-
906 injection of the bogus data at more frequent intervals.
907
908 DNS Security [RFC2065] provides a mechanism to verify whether a
909 negative response is valid or not, through the use of NXT and SIG
910 records. This document supports the use of that mechanism by
911 promoting the transmission of the relevant security records even in a
912 non security aware server.
913
914 Acknowledgments
915
916 I would like to thank Rob Austein for his history of the CHIVES
917 nameserver. The DNSIND working group, in particular Robert Elz for
918 his valuable technical and editorial contributions to this document.
919
920
921
922
923
924
925
926
927
928
929
930
931
932 Andrews Standards Track [Page 17]
933 RFC 2308 DNS NCACHE March 1998
934
935
For such an attack to be successful, the NXDOMAIN indiction must be injected into a parent server (or a busy caching resolver). One way this might be done by the use of a CNAME which results in the parent server querying an attackers server. Resolvers that wish to prevent such attacks can query again the final QNAME ignoring any NS data in the query responses it has received for this query.
For such an attack to be successful, the NXDOMAIN indication must be injected into a parent server (or a busy caching resolver). One way this might be done by the use of a CNAME which results in the parent server querying an attackers server. Resolvers that wish to prevent such attacks can query again the final QNAME ignoring any NS data in the query responses it has received for this query.
936 References
937
938 [RFC1034]
939 Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES,"
940 STD 13, RFC 1034, November 1987.
941
942 [RFC1035]
943 Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
944 SPECIFICATION," STD 13, RFC 1035, November 1987.
945
946 [RFC2065]
947 Eastlake, D., and C. Kaufman, "Domain Name System Security
948 Extensions," RFC 2065, January 1997.
949
950 [RFC2119]
951 Bradner, S., "Key words for use in RFCs to Indicate
952 Requirement Levels," BCP 14, RFC 2119, March 1997.
953
954 [RFC2181]
955 Elz, R., and R. Bush, "Clarifications to the DNS
956 Specification," RFC 2181, July 1997.
957
958 Author's Address
959
960 Mark Andrews
961 CSIRO - Mathematical and Information Sciences
962 Locked Bag 17
963 North Ryde NSW 2113
964 AUSTRALIA
965
966 Phone: +61 2 9325 3148
967 EMail: Mark.Andrews@cmis.csiro.au
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987 Andrews Standards Track [Page 18]
988 RFC 2308 DNS NCACHE March 1998
989
990
991 Full Copyright Statement
992
993 Copyright (C) The Internet Society (1998). All Rights Reserved.
994
995 This document and translations of it may be copied and furnished to
996 others, and derivative works that comment on or otherwise explain it
997 or assist in its implementation may be prepared, copied, published
998 and distributed, in whole or in part, without restriction of any
999 kind, provided that the above copyright notice and this paragraph are
1000 included on all such copies and derivative works. However, this
1001 document itself may not be modified in any way, such as by removing
1002 the copyright notice or references to the Internet Society or other
1003 Internet organizations, except as needed for the purpose of
1004 developing Internet standards in which case the procedures for
1005 copyrights defined in the Internet Standards process must be
1006 followed, or as required to translate it into languages other than
1007 English.
1008
1009 The limited permissions granted above are perpetual and will not be
1010 revoked by the Internet Society or its successors or assigns.
1011
1012 This document and the information contained herein is provided on an
1013 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1014 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1015 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1016 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1017 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042 Andrews Standards Track [Page 19]
1043
ADD:
[RFC2136] P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
-------
OR: define SERVFAIL inside of the terminology section (section 1):
"SERVFAIL" - a name for the "Server failure" (2) RCODE described in
[RFC1035 Section 4.1.1].
[MPA] ???