7Network Working Group M. Andrews
8Request for Comments: 2308 CSIRO
9Updates: 1034, 1035 March 1998
10Category: Standards Track
13 Negative Caching of DNS Queries (DNS NCACHE)
17 This document specifies an Internet standards track protocol for the
18 Internet community, and requests discussion and suggestions for
19 improvements. Please refer to the current edition of the "Internet
20 Official Protocol Standards" (STD 1) for the standardization state
21 and status of this protocol. Distribution of this memo is unlimited.
25 Copyright (C) The Internet Society (1998). All Rights Reserved.
29 [RFC1034] provided a description of how to cache negative responses.
30 It however had a fundamental flaw in that it did not allow a name
31 server to hand out those cached responses to other resolvers, thereby
32 greatly reducing the effect of the caching. This document addresses
33 issues raise in the light of experience and replaces [RFC1034 Section
36 Negative caching was an optional part of the DNS specification and
37 deals with the caching of the non-existence of an RRset [RFC2181] or
40 Negative caching is useful as it reduces the response time for
41 negative answers. It also reduces the number of messages that have
42 to be sent between resolvers and name servers hence overall network
43 traffic. A large proportion of DNS traffic on the Internet could be
44 eliminated if all resolvers implemented negative caching. With this
45 in mind negative caching should no longer be seen as an optional part
58Andrews Standards Track [Page 1]
60RFC 2308 DNS NCACHE March 1998
65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
67 document are to be interpreted as described in [RFC2119].
69 "Negative caching" - the storage of knowledge that something does not
70 exist. We can store the knowledge that a record has a particular
71 value. We can also do the reverse, that is, to store the knowledge
72 that a record does not exist. It is the storage of knowledge that
73 something does not exist, cannot or does not give an answer that we
74 call negative caching.
76 "QNAME" - the name in the query section of an answer, or where this
77 resolves to a CNAME, or CNAME chain, the data field of the last
78 CNAME. The last CNAME in this sense is that which contains a value
79 which does not resolve to another CNAME. Implementations should note
80 that including CNAME records in responses in order, so that the first
81 has the label from the query section, and then each in sequence has
82 the label from the data section of the previous (where more than one
83 CNAME is needed) allows the sequence to be processed in one pass, and
84 considerably eases the task of the receiver. Other relevant records
85 (such as SIG RRs [RFC2065]) can be interspersed amongst the CNAMEs.
87 "NXDOMAIN" - an alternate expression for the "Name Error" RCODE as
88 described in [RFC1035 Section 4.1.1] and the two terms are used
89 interchangeably in this document.
91 "NODATA" - a pseudo RCODE which indicates that the name is valid, for
92 the given class, but are no records of the given type. A NODATA
93 response has to be inferred from the answer.
95 "FORWARDER" - a nameserver used to resolve queries instead of
96 directly using the authoritative nameserver chain. The forwarder
97 typically either has better access to the internet, or maintains a
98 bigger cache which may be shared amongst many resolvers. How a
99 server is identified as a FORWARDER, or knows it is a FORWARDER is
100 outside the scope of this document. However if you are being used as
101 a forwarder the query will have the recursion desired flag set.
103 An understanding of [RFC1034], [RFC1035] and [RFC2065] is expected
104 when reading this document.
114Andrews Standards Track [Page 2]
116RFC 2308 DNS NCACHE March 1998
1192 - Negative Responses
121 The most common negative responses indicate that a particular RRset
122 does not exist in the DNS. The first sections of this document deal
123 with this case. Other negative responses can indicate failures of a
124 nameserver, those are dealt with in section 7 (Other Negative
127 A negative response is indicated by one of the following conditions:
131 Name errors (NXDOMAIN) are indicated by the presence of "Name Error"
132 in the RCODE field. In this case the domain referred to by the QNAME
133 does not exist. Note: the answer section may have SIG and CNAME RRs
134 and the authority section may have SOA, NXT [RFC2065] and SIG RRsets.
136 It is possible to distinguish between a referral and a NXDOMAIN
137 response by the presense of NXDOMAIN in the RCODE regardless of the
138 presence of NS or SOA records in the authority section.
140 NXDOMAIN responses can be categorised into four types by the contents
141 of the authority section. These are shown below along with a
142 referral for comparison. Fields not mentioned are not important in
143 terms of the examples.
145 NXDOMAIN RESPONSE: TYPE 1.
152 AN.EXAMPLE. CNAME TRIPPLE.XX.
154 XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
161 NXDOMAIN RESPONSE: TYPE 2.
170Andrews Standards Track [Page 3]
172RFC 2308 DNS NCACHE March 1998
176 AN.EXAMPLE. CNAME TRIPPLE.XX.
178 XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
182 NXDOMAIN RESPONSE: TYPE 3.
189 AN.EXAMPLE. CNAME TRIPPLE.XX.
195 NXDOMAIN RESPONSE: TYPE 4
202 AN.EXAMPLE. CNAME TRIPPLE.XX.
217 AN.EXAMPLE. CNAME TRIPPLE.XX.
226Andrews Standards Track [Page 4]
228RFC 2308 DNS NCACHE March 1998
233 Note, in the four examples of NXDOMAIN responses, it is known that
234 the name "AN.EXAMPLE." exists, and has as its value a CNAME record.
235 The NXDOMAIN refers to "TRIPPLE.XX", which is then known not to
236 exist. On the other hand, in the referral example, it is shown that
237 "AN.EXAMPLE" exists, and has a CNAME RR as its value, but nothing is
238 known one way or the other about the existence of "TRIPPLE.XX", other
239 than that "NS1.XX" or "NS2.XX" can be consulted as the next step in
240 obtaining information about it.
242 Where no CNAME records appear, the NXDOMAIN response refers to the
243 name in the label of the RR in the question section.
2452.1.1 Special Handling of Name Error
247 This section deals with errors encountered when implementing negative
248 caching of NXDOMAIN responses.
250 There are a large number of resolvers currently in existence that
251 fail to correctly detect and process all forms of NXDOMAIN response.
252 Some resolvers treat a TYPE 1 NXDOMAIN response as a referral. To
253 alleviate this problem it is recommended that servers that are
254 authoritative for the NXDOMAIN response only send TYPE 2 NXDOMAIN
255 responses, that is the authority section contains a SOA record and no
256 NS records. If a non- authoritative server sends a type 1 NXDOMAIN
257 response to one of these old resolvers, the result will be an
258 unnecessary query to an authoritative server. This is undesirable,
259 but not fatal except when the server is being used a FORWARDER. If
260 however the resolver is using the server as a FORWARDER to such a
261 resolver it will be necessary to disable the sending of TYPE 1
262 NXDOMAIN response to it, use TYPE 2 NXDOMAIN instead.
264 Some resolvers incorrectly continue processing if the authoritative
265 answer flag is not set, looping until the query retry threshold is
266 exceeded and then returning SERVFAIL. This is a problem when your
267 nameserver is listed as a FORWARDER for such resolvers. If the
268 nameserver is used as a FORWARDER by such resolver, the authority
269 flag will have to be forced on for NXDOMAIN responses to these
270 resolvers. In practice this causes no problems even if turned on
271 always, and has been the default behaviour in BIND from 4.9.3
276 NODATA is indicated by an answer with the RCODE set to NOERROR and no
277 relevant answers in the answer section. The authority section will
278 contain an SOA record, or there will be no NS records there.
282Andrews Standards Track [Page 5]
284RFC 2308 DNS NCACHE March 1998
287 NODATA responses have to be algorithmically determined from the
288 response's contents as there is no RCODE value to indicate NODATA.
289 In some cases to determine with certainty that NODATA is the correct
290 response it can be necessary to send another query.
292 The authority section may contain NXT and SIG RRsets in addition to
293 NS and SOA records. CNAME and SIG records may exist in the answer
296 It is possible to distinguish between a NODATA and a referral
297 response by the presence of a SOA record in the authority section or
298 the absence of NS records in the authority section.
300 NODATA responses can be categorised into three types by the contents
301 of the authority section. These are shown below along with a
302 referral for comparison. Fields not mentioned are not important in
303 terms of the examples.
305 NODATA RESPONSE: TYPE 1.
314 EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
321 NO DATA RESPONSE: TYPE 2.
330 EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
338Andrews Standards Track [Page 6]
340RFC 2308 DNS NCACHE March 1998
343 NO DATA RESPONSE: TYPE 3.
372 These examples, unlike the NXDOMAIN examples above, have no CNAME
373 records, however they could, in just the same way that the NXDOMAIN
374 examples did, in which case it would be the value of the last CNAME
375 (the QNAME) for which NODATA would be concluded.
3772.2.1 - Special Handling of No Data
379 There are a large number of resolvers currently in existence that
380 fail to correctly detect and process all forms of NODATA response.
381 Some resolvers treat a TYPE 1 NODATA response as a referral. To
382 alleviate this problem it is recommended that servers that are
383 authoritative for the NODATA response only send TYPE 2 NODATA
384 responses, that is the authority section contains a SOA record and no
385 NS records. Sending a TYPE 1 NODATA response from a non-
386 authoritative server to one of these resolvers will only result in an
387 unnecessary query. If a server is listed as a FORWARDER for another
388 resolver it may also be necessary to disable the sending of TYPE 1
389 NODATA response for non-authoritative NODATA responses.
394Andrews Standards Track [Page 7]
396RFC 2308 DNS NCACHE March 1998
399 Some name servers fail to set the RCODE to NXDOMAIN in the presence
400 of CNAMEs in the answer section. If a definitive NXDOMAIN / NODATA
401 answer is required in this case the resolver must query again using
402 the QNAME as the query label.
4043 - Negative Answers from Authoritative Servers
406 Name servers authoritative for a zone MUST include the SOA record of
407 the zone in the authority section of the response when reporting an
408 NXDOMAIN or indicating that no data of the requested type exists.
409 This is required so that the response may be cached. The TTL of this
410 record is set from the minimum of the MINIMUM field of the SOA record
411 and the TTL of the SOA itself, and indicates how long a resolver may
412 cache the negative answer. The TTL SIG record associated with the
413 SOA record should also be trimmed in line with the SOA's TTL.
415 If the containing zone is signed [RFC2065] the SOA and appropriate
416 NXT and SIG records MUST be added.
420 The SOA minimum field has been overloaded in the past to have three
421 different meanings, the minimum TTL value of all RRs in a zone, the
422 default TTL of RRs which did not contain a TTL value and the TTL of
425 Despite being the original defined meaning, the first of these, the
426 minimum TTL value of all RRs in a zone, has never in practice been
427 used and is hereby deprecated.
429 The second, the default TTL of RRs which contain no explicit TTL in
430 the master zone file, is relevant only at the primary server. After
431 a zone transfer all RRs have explicit TTLs and it is impossible to
432 determine whether the TTL for a record was explicitly set or derived
433 from the default after a zone transfer. Where a server does not
434 require RRs to include the TTL value explicitly, it should provide a
435 mechanism, not being the value of the MINIMUM field of the SOA
436 record, from which the missing TTL values are obtained. How this is
437 done is implementation dependent.
439 The Master File format [RFC 1035 Section 5] is extended to include
440 the following directive:
450Andrews Standards Track [Page 8]
452RFC 2308 DNS NCACHE March 1998
455 All resource records appearing after the directive, and which do not
456 explicitly include a TTL value, have their TTL set to the TTL given
457 in the $TTL directive. SIG records without a explicit TTL get their
458 TTL from the "original TTL" of the SIG record [RFC 2065 Section 4.5].
460 The remaining of the current meanings, of being the TTL to be used
461 for negative responses, is the new defined meaning of the SOA minimum
4645 - Caching Negative Answers
466 Like normal answers negative answers have a time to live (TTL). As
467 there is no record in the answer section to which this TTL can be
468 applied, the TTL must be carried by another method. This is done by
469 including the SOA record from the zone in the authority section of
470 the reply. When the authoritative server creates this record its TTL
471 is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
472 This TTL decrements in a similar manner to a normal cached answer and
473 upon reaching zero (0) indicates the cached negative answer MUST NOT
476 A negative answer that resulted from a name error (NXDOMAIN) should
477 be cached such that it can be retrieved and returned in response to
478 another query for the same <QNAME, QCLASS> that resulted in the
479 cached negative response.
481 A negative answer that resulted from a no data error (NODATA) should
482 be cached such that it can be retrieved and returned in response to
483 another query for the same <QNAME, QTYPE, QCLASS> that resulted in
484 the cached negative response.
486 The NXT record, if it exists in the authority section of a negative
487 answer received, MUST be stored such that it can be be located and
488 returned with SOA record in the authority section, as should any SIG
489 records in the authority section. For NXDOMAIN answers there is no
490 "necessary" obvious relationship between the NXT records and the
491 QNAME. The NXT record MUST have the same owner name as the query
492 name for NODATA responses.
494 Negative responses without SOA records SHOULD NOT be cached as there
495 is no way to prevent the negative responses looping forever between a
496 pair of servers even with a short TTL.
498 Despite the DNS forming a tree of servers, with various mis-
499 configurations it is possible to form a loop in the query graph, e.g.
500 two servers listing each other as forwarders, various lame server
501 configurations. Without a TTL count down a cache negative response
506Andrews Standards Track [Page 9]
508RFC 2308 DNS NCACHE March 1998
511 when received by the next server would have its TTL reset. This
512 negative indication could then live forever circulating between the
515 As with caching positive responses it is sensible for a resolver to
516 limit for how long it will cache a negative response as the protocol
517 supports caching for up to 68 years. Such a limit should not be
518 greater than that applied to positive answers and preferably be
519 tunable. Values of one to three hours have been found to work well
520 and would make sensible a default. Values exceeding one day have
521 been found to be problematic.
5236 - Negative answers from the cache
525 When a server, in answering a query, encounters a cached negative
526 response it MUST add the cached SOA record to the authority section
527 of the response with the TTL decremented by the amount of time it was
528 stored in the cache. This allows the NXDOMAIN / NODATA response to
531 If a NXT record was cached along with SOA record it MUST be added to
532 the authority section. If a SIG record was cached along with a NXT
533 record it SHOULD be added to the authority section.
535 As with all answers coming from the cache, negative answers SHOULD
536 have an implicit referral built into the answer. This enables the
537 resolver to locate an authoritative source. An implicit referral is
538 characterised by NS records in the authority section referring the
539 resolver towards a authoritative source. NXDOMAIN types 1 and 4
540 responses contain implicit referrals as does NODATA type 1 response.
5427 - Other Negative Responses
544 Caching of other negative responses is not covered by any existing
545 RFC. There is no way to indicate a desired TTL in these responses.
546 Care needs to be taken to ensure that there are not forwarding loops.
5487.1 Server Failure (OPTIONAL)
550 Server failures fall into two major classes. The first is where a
551 server can determine that it has been misconfigured for a zone. This
552 may be where it has been listed as a server, but not configured to be
553 a server for the zone, or where it has been configured to be a server
554 for the zone, but cannot obtain the zone data for some reason. This
555 can occur either because the zone file does not exist or contains
556 errors, or because another server from which the zone should have
557 been available either did not respond or was unable or unwilling to
562Andrews Standards Track [Page 10]
564RFC 2308 DNS NCACHE March 1998
567 The second class is where the server needs to obtain an answer from
568 elsewhere, but is unable to do so, due to network failures, other
569 servers that don't reply, or return server failure errors, or
572 In either case a resolver MAY cache a server failure response. If it
573 does so it MUST NOT cache it for longer than five (5) minutes, and it
574 MUST be cached against the specific query tuple <query name, type,
575 class, server IP address>.
5777.2 Dead / Unreachable Server (OPTIONAL)
579 Dead / Unreachable servers are servers that fail to respond in any
580 way to a query or where the transport layer has provided an
581 indication that the server does not exist or is unreachable. A
582 server may be deemed to be dead or unreachable if it has not
583 responded to an outstanding query within 120 seconds.
585 Examples of transport layer indications are:
587 ICMP error messages indicating host, net or port unreachable.
589 IP stack error messages providing similar indications to those above.
591 A server MAY cache a dead server indication. If it does so it MUST
592 NOT be deemed dead for longer than five (5) minutes. The indication
593 MUST be stored against query tuple <query name, type, class, server
594 IP address> unless there was a transport layer indication that the
595 server does not exist, in which case it applies to all queries to
596 that specific IP address.
5988 - Changes from RFC 1034
600 Negative caching in resolvers is no-longer optional, if a resolver
601 caches anything it must also cache negative answers.
603 Non-authoritative negative answers MAY be cached.
605 The SOA record from the authority section MUST be cached. Name error
606 indications must be cached against the tuple <query name, QCLASS>.
607 No data indications must be cached against <query name, QTYPE,
610 A cached SOA record must be added to the response. This was
611 explicitly not allowed because previously the distinction between a
612 normal cached SOA record, and the SOA cached as a result of a
613 negative response was not made, and simply extracting a normal cached
614 SOA and adding that to a cached negative response causes problems.
618Andrews Standards Track [Page 11]
620RFC 2308 DNS NCACHE March 1998
623 The $TTL TTL directive was added to the master file format.
6259 - History of Negative Caching
627 This section presents a potted history of negative caching in the DNS
628 and forms no part of the technical specification of negative caching.
630 It is interesting to note that the same concepts were re-invented in
631 both the CHIVES and BIND servers.
633 The history of the early CHIVES work (Section 9.1) was supplied by
634 Rob Austein <sra@epilogue.com> and is reproduced here in the form in
635 which he supplied it [MPA].
637 Sometime around the spring of 1985, I mentioned to Paul Mockapetris
638 that our experience with his JEEVES DNS resolver had pointed out the
639 need for some kind of negative caching scheme. Paul suggested that
640 we simply cache authoritative errors, using the SOA MINIMUM value for
641 the zone that would have contained the target RRs. I'm pretty sure
642 that this conversation took place before RFC-973 was written, but it
643 was never clear to me whether this idea was something that Paul came
644 up with on the spot in response to my question or something he'd
645 already been planning to put into the document that became RFC-973.
646 In any case, neither of us was entirely sure that the SOA MINIMUM
647 value was really the right metric to use, but it was available and
648 was under the control of the administrator of the target zone, both
649 of which seemed to us at the time to be important feature.
651 Late in 1987, I released the initial beta-test version of CHIVES, the
652 DNS resolver I'd written to replace Paul's JEEVES resolver. CHIVES
653 included a search path mechanism that was used pretty heavily at
654 several sites (including my own), so CHIVES also included a negative
655 caching mechanism based on SOA MINIMUM values. The basic strategy
656 was to cache authoritative error codes keyed by the exact query
657 parameters (QNAME, QCLASS, and QTYPE), with a cache TTL equal to the
658 SOA MINIMUM value. CHIVES did not attempt to track down SOA RRs if
659 they weren't supplied in the authoritative response, so it never
660 managed to completely eliminate the gratuitous DNS error message
661 traffic, but it did help considerably. Keep in mind that this was
662 happening at about the same time as the near-collapse of the ARPANET
663 due to congestion caused by exponential growth and the the "old"
664 (pre-VJ) TCP retransmission algorithm, so negative caching resulted
665 in drasticly better DNS response time for our users, mailer daemons,
674Andrews Standards Track [Page 12]
676RFC 2308 DNS NCACHE March 1998
679 As far as I know, CHIVES was the first resolver to implement negative
680 caching. CHIVES was developed during the twilight years of TOPS-20,
681 so it never ran on very many machines, but the few machines that it
682 did run on were the ones that were too critical to shut down quickly
683 no matter how much it cost to keep them running. So what few users
684 we did have tended to drive CHIVES pretty hard. Several interesting
685 bits of DNS technology resulted from that, but the one that's
686 relevant here is the MAXTTL configuration parameter.
688 Experience with JEEVES had already shown that RRs often showed up
689 with ridiculously long TTLs (99999999 was particularly popular for
690 many years, due to bugs in the code and documentation of several
691 early versions of BIND), and that robust software that blindly
692 believed such TTLs could create so many strange failures that it was
693 often necessary to reboot the resolver frequently just to clear this
694 garbage out of the cache. So CHIVES had a configuration parameter
695 "MAXTTL", which specified the maximum "reasonable" TTL in a received
696 RR. RRs with TTLs greater than MAXTTL would either have their TTLs
697 reduced to MAXTTL or would be discarded entirely, depending on the
698 setting of another configuration parameter.
700 When we started getting field experience with CHIVES's negative
701 caching code, it became clear that the SOA MINIMUM value was often
702 large enough to cause the same kinds of problems for negative caching
703 as the huge TTLs in RRs had for normal caching (again, this was in
704 part due to a bug in several early versions of BIND, where a
705 secondary server would authoritatively deny all knowledge of its
706 zones if it couldn't contact the primaries on reboot). So we started
707 running the negative cache TTLs through the MAXTTL check too, and
708 continued to experiment.
710 The configuration that seemed to work best on WSMR-SIMTEL20.ARMY.MIL
711 (last of the major Internet TOPS-20 machines to be shut down, thus
712 the last major user of CHIVES, thus the place where we had the
713 longest experimental baseline) was to set MAXTTL to about three days.
714 Most of the traffic initiated by SIMTEL20 in its last years was
715 mail-related, and the mail queue timeout was set to one week, so this
716 gave a "stuck" message several tries at complete DNS resolution,
717 without bogging down the system with a lot of useless queries. Since
718 (for reasons that now escape me) we only had the single MAXTTL
719 parameter rather than separate ones for positive and negative
720 caching, it's not clear how much effect this setting of MAXTTL had on
721 the negative caching code.
723 CHIVES also included a second, somewhat controversial mechanism which
724 took the place of negative caching in some cases. The CHIVES
725 resolver daemon could be configured to load DNS master files, giving
726 it the ability to act as what today would be called a "stealth
730Andrews Standards Track [Page 13]
732RFC 2308 DNS NCACHE March 1998
735 secondary". That is, when configured in this way, the resolver had
736 direct access to authoritative information for heavily-used zones.
737 The search path mechanisms in CHIVES reflected this: there were
738 actually two separate search paths, one of which only searched local
739 authoritative zone data, and one which could generate normal
740 iterative queries. This cut down on the need for negative caching in
741 cases where usage was predictably heavy (e.g., the resolver on
742 XX.LCS.MIT.EDU always loaded the zone files for both LCS.MIT.EDU and
743 AI.MIT.EDU and put both of these suffixes into the "local" search
744 path, since between them the hosts in these two zones accounted for
745 the bulk of the DNS traffic). Not all sites running CHIVES chose to
746 use this feature; C.CS.CMU.EDU, for example, chose to use the
747 "remote" search path for everything because there were too many
748 different sub-zones at CMU for zone shadowing to be practical for
749 them, so they relied pretty heavily on negative caching even for
752 Overall, I still think the basic design we used for negative caching
753 was pretty reasonable: the zone administrator specified how long to
754 cache negative answers, and the resolver configuration chose the
755 actual cache time from the range between zero and the period
756 specified by the zone administrator. There are a lot of details I'd
757 do differently now (like using a new SOA field instead of overloading
758 the MINIMUM field), but after more than a decade, I'd be more worried
759 if we couldn't think of at least a few improvements.
763 While not the first attempt to get negative caching into BIND, in
764 July 1993, BIND 4.9.2 ALPHA, Anant Kumar of ISI supplied code that
765 implemented, validation and negative caching (NCACHE). This code had
766 a 10 minute TTL for negative caching and only cached the indication
767 that there was a negative response, NXDOMAIN or NOERROR_NODATA. This
768 is the origin of the NODATA pseudo response code mentioned above.
770 Mark Andrews of CSIRO added code (RETURNSOA) that stored the SOA
771 record such that it could be retrieved by a similar query. UUnet
772 complained that they were getting old answers after loading a new
773 zone, and the option was turned off, BIND 4.9.3-alpha5, April 1994.
774 In reality this indicated that the named needed to purge the space
775 the zone would occupy. Functionality to do this was added in BIND
776 4.9.3 BETA11 patch2, December 1994.
778 RETURNSOA was re-enabled by default, BIND 4.9.5-T1A, August 1996.
786Andrews Standards Track [Page 14]
788RFC 2308 DNS NCACHE March 1998
793 The following example is based on a signed zone that is empty apart
794 from the nameservers. We will query for WWW.XX.EXAMPLE showing
795 initial response and again 10 minutes later. Note 1: during the
796 intervening 10 minutes the NS records for XX.EXAMPLE have expired.
797 Note 2: the TTL of the SIG records are not explicitly set in the zone
798 file and are hence the TTL of the RRset they are the signature for.
804 @ IN SOA NS1.XX.EXAMPLE. HOSTMATER.XX.EXAMPLE. (
806 1800 ; refresh (30 mins)
807 900 ; retry (15 mins)
808 604800 ; expire (7 days)
809 1200 ) ; minimum (20 mins)
811 1200 IN NXT NS1.XX.EXAMPLE. A NXT SIG SOA NS KEY
812 IN SIG NXT ... XX.EXAMPLE. ...
813 300 IN NS NS1.XX.EXAMPLE.
814 300 IN NS NS2.XX.EXAMPLE.
815 IN SIG NS ... XX.EXAMPLE. ...
816 IN KEY 0x4100 1 1 ...
817 IN SIG KEY ... XX.EXAMPLE. ...
818 IN SIG KEY ... EXAMPLE. ...
820 IN SIG A ... XX.EXAMPLE. ...
821 1200 IN NXT NS2.XX.EXAMPLE. A NXT SIG
824 IN SIG A ... XX.EXAMPLE. ...
825 1200 IN NXT XX.EXAMPLE. A NXT SIG
826 IN SIG NXT ... XX.EXAMPLE. ...
831 RDCODE=NXDOMAIN, AA=1, QR=1, TC=0
837 XX.EXAMPLE. 1200 IN SOA NS1.XX.EXAMPLE. ...
838 XX.EXAMPLE. 1200 IN SIG SOA ... XX.EXAMPLE. ...
842Andrews Standards Track [Page 15]
844RFC 2308 DNS NCACHE March 1998
847 NS2.XX.EXAMPLE. 1200 IN NXT XX.EXAMPLE. NXT A NXT SIG
848 NS2.XX.EXAMPLE. 1200 IN SIG NXT ... XX.EXAMPLE. ...
849 XX.EXAMPLE. 86400 IN NS NS1.XX.EXAMPLE.
850 XX.EXAMPLE. 86400 IN NS NS2.XX.EXAMPLE.
851 XX.EXAMPLE. 86400 IN SIG NS ... XX.EXAMPLE. ...
853 XX.EXAMPLE. 86400 IN KEY 0x4100 1 1 ...
854 XX.EXAMPLE. 86400 IN SIG KEY ... EXAMPLE. ...
855 NS1.XX.EXAMPLE. 86400 IN A 10.0.0.1
856 NS1.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
857 NS2.XX.EXAMPLE. 86400 IN A 10.0.0.2
858 NS3.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
863 RDCODE=NXDOMAIN, AA=0, QR=1, TC=0
869 XX.EXAMPLE. 600 IN SOA NS1.XX.EXAMPLE. ...
870 XX.EXAMPLE. 600 IN SIG SOA ... XX.EXAMPLE. ...
871 NS2.XX.EXAMPLE. 600 IN NXT XX.EXAMPLE. NXT A NXT SIG
872 NS2.XX.EXAMPLE. 600 IN SIG NXT ... XX.EXAMPLE. ...
873 EXAMPLE. 65799 IN NS NS1.YY.EXAMPLE.
874 EXAMPLE. 65799 IN NS NS2.YY.EXAMPLE.
875 EXAMPLE. 65799 IN SIG NS ... XX.EXAMPLE. ...
877 XX.EXAMPLE. 65800 IN KEY 0x4100 1 1 ...
878 XX.EXAMPLE. 65800 IN SIG KEY ... EXAMPLE. ...
879 NS1.YY.EXAMPLE. 65799 IN A 10.100.0.1
880 NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
881 NS2.YY.EXAMPLE. 65799 IN A 10.100.0.2
882 NS3.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
883 EXAMPLE. 65799 IN KEY 0x4100 1 1 ...
884 EXAMPLE. 65799 IN SIG KEY ... . ...
88711 Security Considerations
889 It is believed that this document does not introduce any significant
890 additional security threats other that those that already exist when
891 using data from the DNS.
898Andrews Standards Track [Page 16]
900RFC 2308 DNS NCACHE March 1998
903 With negative caching it might be possible to propagate a denial of
904 service attack by spreading a NXDOMAIN message with a very high TTL.
905 Without negative caching that would be much harder. A similar effect
906 could be achieved previously by spreading a bad A record, so that the
907 server could not be reached - which is almost the same. It has the
908 same effect as far as what the end user is able to do, but with a
909 different psychological effect. With the bad A, I feel "damn the
910 network is broken again" and try again tomorrow. With the "NXDOMAIN"
911 I feel "Oh, they've turned off the server and it doesn't exist any
912 more" and probably never bother trying this server again.
914 A practical example of this is a SMTP server where this behaviour is
915 encoded. With a NXDOMAIN attack the mail message would bounce
916 immediately, where as with a bad A attack the mail would be queued
917 and could potentially get through after the attack was suspended.
919 For such an attack to be successful, the NXDOMAIN indiction must be
920 injected into a parent server (or a busy caching resolver). One way
921 this might be done by the use of a CNAME which results in the parent
922 server querying an attackers server. Resolvers that wish to prevent
923 such attacks can query again the final QNAME ignoring any NS data in
924 the query responses it has received for this query.
926 Implementing TTL sanity checking will reduce the effectiveness of
927 such an attack, because a successful attack would require re-
928 injection of the bogus data at more frequent intervals.
930 DNS Security [RFC2065] provides a mechanism to verify whether a
931 negative response is valid or not, through the use of NXT and SIG
932 records. This document supports the use of that mechanism by
933 promoting the transmission of the relevant security records even in a
934 non security aware server.
938 I would like to thank Rob Austein for his history of the CHIVES
939 nameserver. The DNSIND working group, in particular Robert Elz for
940 his valuable technical and editorial contributions to this document.
954Andrews Standards Track [Page 17]
956RFC 2308 DNS NCACHE March 1998
962 Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES,"
963 STD 13, RFC 1034, November 1987.
966 Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
967 SPECIFICATION," STD 13, RFC 1035, November 1987.
970 Eastlake, D., and C. Kaufman, "Domain Name System Security
971 Extensions," RFC 2065, January 1997.
974 Bradner, S., "Key words for use in RFCs to Indicate
975 Requirement Levels," BCP 14, RFC 2119, March 1997.
978 Elz, R., and R. Bush, "Clarifications to the DNS
979 Specification," RFC 2181, July 1997.
984 CSIRO - Mathematical and Information Sciences
989 Phone: +61 2 9325 3148
990 EMail: Mark.Andrews@cmis.csiro.au
1010Andrews Standards Track [Page 18]
1012RFC 2308 DNS NCACHE March 1998
1015Full Copyright Statement
1017 Copyright (C) The Internet Society (1998). All Rights Reserved.
1019 This document and translations of it may be copied and furnished to
1020 others, and derivative works that comment on or otherwise explain it
1021 or assist in its implementation may be prepared, copied, published
1022 and distributed, in whole or in part, without restriction of any
1023 kind, provided that the above copyright notice and this paragraph are
1024 included on all such copies and derivative works. However, this
1025 document itself may not be modified in any way, such as by removing
1026 the copyright notice or references to the Internet Society or other
1027 Internet organizations, except as needed for the purpose of
1028 developing Internet standards in which case the procedures for
1029 copyrights defined in the Internet Standards process must be
1030 followed, or as required to translate it into languages other than
1033 The limited permissions granted above are perpetual and will not be
1034 revoked by the Internet Society or its successors or assigns.
1036 This document and the information contained herein is provided on an
1037 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1038 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1039 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1040 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1041 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1066Andrews Standards Track [Page 19]