GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2308

Network Working Group M. Andrews Request for Comments: 2308 CSIRO Updates: 1034, 1035 March 1998 Category: Standards Track

            Negative Caching of DNS Queries (DNS NCACHE)

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

 [RFC1034] provided a description of how to cache negative responses.
 It however had a fundamental flaw in that it did not allow a name
 server to hand out those cached responses to other resolvers, thereby
 greatly reducing the effect of the caching.  This document addresses
 issues raise in the light of experience and replaces [RFC1034 Section
 4.3.4].
 Negative caching was an optional part of the DNS specification and
 deals with the caching of the non-existence of an RRset [RFC2181] or
 domain name.
 Negative caching is useful as it reduces the response time for
 negative answers.  It also reduces the number of messages that have
 to be sent between resolvers and name servers hence overall network
 traffic.  A large proportion of DNS traffic on the Internet could be
 eliminated if all resolvers implemented negative caching.  With this
 in mind negative caching should no longer be seen as an optional part
 of a DNS resolver.

Andrews Standards Track [Page 1] RFC 2308 DNS NCACHE March 1998

1 - Terminology

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [RFC2119].
 "Negative caching" - the storage of knowledge that something does not
 exist.  We can store the knowledge that a record has a particular
 value.  We can also do the reverse, that is, to store the knowledge
 that a record does not exist.  It is the storage of knowledge that
 something does not exist, cannot or does not give an answer that we
 call negative caching.
 "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.  The last CNAME in this sense is that which contains a value
 which does not resolve to another CNAME.  Implementations should note
 that including CNAME records in responses in order, so that the first
 has the label from the query section, and then each in sequence has
 the label from the data section of the previous (where more than one
 CNAME is needed) allows the sequence to be processed in one pass, and
 considerably eases the task of the receiver.  Other relevant records
 (such as SIG RRs [RFC2065]) can be interspersed amongst the CNAMEs.
 "NXDOMAIN" - an alternate expression for the "Name Error" RCODE as
 described in [RFC1035 Section 4.1.1] and the two terms are used
 interchangeably in this document.
 "NODATA" - a pseudo RCODE which indicates that the name is valid, for
 the given class, but are no records of the given type.  A NODATA
 response has to be inferred from the answer.
 "FORWARDER" - a nameserver used to resolve queries instead of
 directly using the authoritative nameserver chain.  The forwarder
 typically either has better access to the internet, or maintains a
 bigger cache which may be shared amongst many resolvers.  How a
 server is identified as a FORWARDER, or knows it is a FORWARDER is
 outside the scope of this document.  However if you are being used as
 a forwarder the query will have the recursion desired flag set.
 An understanding of [RFC1034], [RFC1035] and [RFC2065] is expected
 when reading this document.

Andrews Standards Track [Page 2] RFC 2308 DNS NCACHE March 1998

2 - Negative Responses

 The most common negative responses indicate that a particular RRset
 does not exist in the DNS.  The first sections of this document deal
 with this case.  Other negative responses can indicate failures of a
 nameserver, those are dealt with in section 7 (Other Negative
 Responses).
 A negative response is indicated by one of the following conditions:

2.1 - Name Error

 Name errors (NXDOMAIN) are indicated by the presence of "Name Error"
 in the RCODE field.  In this case the domain referred to by the QNAME
 does not exist.  Note: the answer section may have SIG and CNAME RRs
 and the authority section may have SOA, NXT [RFC2065] and SIG RRsets.
 It is possible to distinguish between a referral and a NXDOMAIN
 response by the presense of NXDOMAIN in the RCODE regardless of the
 presence of NS or SOA records in the authority section.
 NXDOMAIN responses can be categorised into four types by the contents
 of the authority section.  These are shown below along with a
 referral for comparison.  Fields not mentioned are not important in
 terms of the examples.
         NXDOMAIN RESPONSE: TYPE 1.
         Header:
             RDCODE=NXDOMAIN
         Query:
             AN.EXAMPLE. A
         Answer:
             AN.EXAMPLE. CNAME TRIPPLE.XX.
         Authority:
             XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
             XX. NS NS1.XX.
             XX. NS NS2.XX.
         Additional:
             NS1.XX. A 127.0.0.2
             NS2.XX. A 127.0.0.3
         NXDOMAIN RESPONSE: TYPE 2.
         Header:
             RDCODE=NXDOMAIN
         Query:
             AN.EXAMPLE. A

Andrews Standards Track [Page 3] RFC 2308 DNS NCACHE March 1998

         Answer:
             AN.EXAMPLE. CNAME TRIPPLE.XX.
         Authority:
             XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
         Additional:
             <empty>
         NXDOMAIN RESPONSE: TYPE 3.
         Header:
             RDCODE=NXDOMAIN
         Query:
             AN.EXAMPLE. A
         Answer:
             AN.EXAMPLE. CNAME TRIPPLE.XX.
         Authority:
             <empty>
         Additional:
             <empty>
         NXDOMAIN RESPONSE: TYPE 4
         Header:
             RDCODE=NXDOMAIN
         Query:
             AN.EXAMPLE. A
         Answer:
             AN.EXAMPLE. CNAME TRIPPLE.XX.
         Authority:
             XX. NS NS1.XX.
             XX. NS NS2.XX.
         Additional:
             NS1.XX. A 127.0.0.2
             NS2.XX. A 127.0.0.3
         REFERRAL RESPONSE.
         Header:
             RDCODE=NOERROR
         Query:
             AN.EXAMPLE. A
         Answer:
             AN.EXAMPLE. CNAME TRIPPLE.XX.
         Authority:
             XX. NS NS1.XX.
             XX. NS NS2.XX.
         Additional:
             NS1.XX. A 127.0.0.2

Andrews Standards Track [Page 4] RFC 2308 DNS NCACHE March 1998

             NS2.XX. A 127.0.0.3
 Note, in the four examples of NXDOMAIN responses, it is known that
 the name "AN.EXAMPLE." exists, and has as its value a CNAME record.
 The NXDOMAIN refers to "TRIPPLE.XX", which is then known not to
 exist.  On the other hand, in the referral example, it is shown that
 "AN.EXAMPLE" exists, and has a CNAME RR as its value, but nothing is
 known one way or the other about the existence of "TRIPPLE.XX", other
 than that "NS1.XX" or "NS2.XX" can be consulted as the next step in
 obtaining information about it.
 Where no CNAME records appear, the NXDOMAIN response refers to the
 name in the label of the RR in the question section.

2.1.1 Special Handling of Name Error

 This section deals with errors encountered when implementing negative
 caching of NXDOMAIN responses.
 There are a large number of resolvers currently in existence that
 fail to correctly detect and process all forms of NXDOMAIN response.
 Some resolvers treat a TYPE 1 NXDOMAIN response as a referral.  To
 alleviate this problem it is recommended that servers that are
 authoritative for the NXDOMAIN response only send TYPE 2 NXDOMAIN
 responses, that is the authority section contains a SOA record and no
 NS records.  If a non- authoritative server sends a type 1 NXDOMAIN
 response to one of these old resolvers, the result will be an
 unnecessary query to an authoritative server.  This is undesirable,
 but not fatal except when the server is being used a FORWARDER.  If
 however the resolver is using the server as a FORWARDER to such a
 resolver it will be necessary to disable the sending of TYPE 1
 NXDOMAIN response to it, use TYPE 2 NXDOMAIN instead.
 Some resolvers incorrectly continue processing if the authoritative
 answer flag is not set, looping until the query retry threshold is
 exceeded and then returning SERVFAIL.  This is a problem when your
 nameserver is listed as a FORWARDER for such resolvers.  If the
 nameserver is used as a FORWARDER by such resolver, the authority
 flag will have to be forced on for NXDOMAIN responses to these
 resolvers.  In practice this causes no problems even if turned on
 always, and has been the default behaviour in BIND from 4.9.3
 onwards.

2.2 - No Data

 NODATA is indicated by an answer with the RCODE set to NOERROR and no
 relevant answers in the answer section.  The authority section will
 contain an SOA record, or there will be no NS records there.

Andrews Standards Track [Page 5] RFC 2308 DNS NCACHE March 1998

 NODATA responses have to be algorithmically determined from the
 response's contents as there is no RCODE value to indicate NODATA.
 In some cases to determine with certainty that NODATA is the correct
 response it can be necessary to send another query.
 The authority section may contain NXT and SIG RRsets in addition to
 NS and SOA records.  CNAME and SIG records may exist in the answer
 section.
 It is possible to distinguish between a NODATA and a referral
 response by the presence of a SOA record in the authority section or
 the absence of NS records in the authority section.
 NODATA responses can be categorised into three types by the contents
 of the authority section.  These are shown below along with a
 referral for comparison.  Fields not mentioned are not important in
 terms of the examples.
         NODATA RESPONSE: TYPE 1.
         Header:
             RDCODE=NOERROR
         Query:
             ANOTHER.EXAMPLE. A
         Answer:
             <empty>
         Authority:
             EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
             EXAMPLE. NS NS1.XX.
             EXAMPLE. NS NS2.XX.
         Additional:
             NS1.XX. A 127.0.0.2
             NS2.XX. A 127.0.0.3
         NO DATA RESPONSE: TYPE 2.
         Header:
             RDCODE=NOERROR
         Query:
             ANOTHER.EXAMPLE. A
         Answer:
             <empty>
         Authority:
             EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
         Additional:
             <empty>

Andrews Standards Track [Page 6] RFC 2308 DNS NCACHE March 1998

         NO DATA RESPONSE: TYPE 3.
         Header:
             RDCODE=NOERROR
         Query:
             ANOTHER.EXAMPLE. A
         Answer:
             <empty>
         Authority:
             <empty>
         Additional:
             <empty>
         REFERRAL RESPONSE.
         Header:
             RDCODE=NOERROR
         Query:
             ANOTHER.EXAMPLE. A
         Answer:
             <empty>
         Authority:
             EXAMPLE. NS NS1.XX.
             EXAMPLE. NS NS2.XX.
         Additional:
             NS1.XX. A 127.0.0.2
             NS2.XX. A 127.0.0.3
 These examples, unlike the NXDOMAIN examples above, have no CNAME
 records, however they could, in just the same way that the NXDOMAIN
 examples did, in which case it would be the value of the last CNAME
 (the QNAME) for which NODATA would be concluded.

2.2.1 - Special Handling of No Data

 There are a large number of resolvers currently in existence that
 fail to correctly detect and process all forms of NODATA response.
 Some resolvers treat a TYPE 1 NODATA response as a referral.  To
 alleviate this problem it is recommended that servers that are
 authoritative for the NODATA response only send TYPE 2 NODATA
 responses, that is the authority section contains a SOA record and no
 NS records.  Sending a TYPE 1 NODATA response from a non-
 authoritative server to one of these resolvers will only result in an
 unnecessary query.  If a server is listed as a FORWARDER for another
 resolver it may also be necessary to disable the sending of TYPE 1
 NODATA response for non-authoritative NODATA responses.

Andrews Standards Track [Page 7] RFC 2308 DNS NCACHE March 1998

 Some name servers fail to set the RCODE to NXDOMAIN in the presence
 of CNAMEs in the answer section.  If a definitive NXDOMAIN / NODATA
 answer is required in this case the resolver must query again using
 the QNAME as the query label.

3 - Negative Answers from Authoritative Servers

 Name servers authoritative for a zone MUST include the SOA record of
 the zone in the authority section of the response when reporting an
 NXDOMAIN or indicating that no data of the requested type exists.
 This is required so that the response may be cached.  The TTL of this
 record is set from the minimum of the MINIMUM field of the SOA record
 and the TTL of the SOA itself, and indicates how long a resolver may
 cache the negative answer.  The TTL SIG record associated with the
 SOA record should also be trimmed in line with the SOA's TTL.
 If the containing zone is signed [RFC2065] the SOA and appropriate
 NXT and SIG records MUST be added.

4 - SOA Minimum Field

 The SOA minimum field has been overloaded in the past to have three
 different meanings, the minimum TTL value of all RRs in a zone, the
 default TTL of RRs which did not contain a TTL value and the TTL of
 negative responses.
 Despite being the original defined meaning, the first of these, the
 minimum TTL value of all RRs in a zone, has never in practice been
 used and is hereby deprecated.
 The second, the default TTL of RRs which contain no explicit TTL in
 the master zone file, is relevant only at the primary server.  After
 a zone transfer all RRs have explicit TTLs and it is impossible to
 determine whether the TTL for a record was explicitly set or derived
 from the default after a zone transfer.  Where a server does not
 require RRs to include the TTL value explicitly, it should provide a
 mechanism, not being the value of the MINIMUM field of the SOA
 record, from which the missing TTL values are obtained.  How this is
 done is implementation dependent.
 The Master File format [RFC 1035 Section 5] is extended to include
 the following directive:
                         $TTL <TTL> [comment]

Andrews Standards Track [Page 8] RFC 2308 DNS NCACHE March 1998

 All resource records appearing after the directive, and which do not
 explicitly include a TTL value, have their TTL set to the TTL given
 in the $TTL directive.  SIG records without a explicit TTL get their
 TTL from the "original TTL" of the SIG record [RFC 2065 Section 4.5].
 The remaining of the current meanings, of being the TTL to be used
 for negative responses, is the new defined meaning of the SOA minimum
 field.

5 - Caching Negative Answers

 Like normal answers negative answers have a time to live (TTL).  As
 there is no record in the answer section to which this TTL can be
 applied, the TTL must be carried by another method.  This is done by
 including the SOA record from the zone in the authority section of
 the reply.  When the authoritative server creates this record its TTL
 is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
 This TTL decrements in a similar manner to a normal cached answer and
 upon reaching zero (0) indicates the cached negative answer MUST NOT
 be used again.
 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.
 A negative answer that resulted from a no data error (NODATA) should
 be cached such that it can be retrieved and returned in response to
 another query for the same <QNAME, QTYPE, QCLASS> that resulted in
 the cached negative response.
 The NXT record, if it exists in the authority section of a negative
 answer received, MUST be stored such that it can be be located and
 returned with SOA record in the authority section, as should any SIG
 records in the authority section.  For NXDOMAIN answers there is no
 "necessary" obvious relationship between the NXT records and the
 QNAME.  The NXT record MUST have the same owner name as the query
 name for NODATA responses.
 Negative responses without SOA records SHOULD NOT be cached as there
 is no way to prevent the negative responses looping forever between a
 pair of servers even with a short TTL.
 Despite the DNS forming a tree of servers, with various mis-
 configurations it is possible to form a loop in the query graph, e.g.
 two servers listing each other as forwarders, various lame server
 configurations.  Without a TTL count down a cache negative response

Andrews Standards Track [Page 9] RFC 2308 DNS NCACHE March 1998

 when received by the next server would have its TTL reset.  This
 negative indication could then live forever circulating between the
 servers involved.
 As with caching positive responses it is sensible for a resolver to
 limit for how long it will cache a negative response as the protocol
 supports caching for up to 68 years.  Such a limit should not be
 greater than that applied to positive answers and preferably be
 tunable.  Values of one to three hours have been found to work well
 and would make sensible a default.  Values exceeding one day have
 been found to be problematic.

6 - Negative answers from the cache

 When a server, in answering a query, encounters a cached negative
 response it MUST add the cached SOA record to the authority section
 of the response with the TTL decremented by the amount of time it was
 stored in the cache.  This allows the NXDOMAIN / NODATA response to
 time out correctly.
 If a NXT record was cached along with SOA record it MUST be added to
 the authority section.  If a SIG record was cached along with a NXT
 record it SHOULD be added to the authority section.
 As with all answers coming from the cache, negative answers SHOULD
 have an implicit referral built into the answer.  This enables the
 resolver to locate an authoritative source.  An implicit referral is
 characterised by NS records in the authority section referring the
 resolver towards a authoritative source.  NXDOMAIN types 1 and 4
 responses contain implicit referrals as does NODATA type 1 response.

7 - Other Negative Responses

 Caching of other negative responses is not covered by any existing
 RFC.  There is no way to indicate a desired TTL in these responses.
 Care needs to be taken to ensure that there are not forwarding loops.

7.1 Server Failure (OPTIONAL)

 Server failures fall into two major classes.  The first is where a
 server can determine that it has been misconfigured for a zone.  This
 may be where it has been listed as a server, but not configured to be
 a server for the zone, or where it has been configured to be a server
 for the zone, but cannot obtain the zone data for some reason.  This
 can occur either because the zone file does not exist or contains
 errors, or because another server from which the zone should have
 been available either did not respond or was unable or unwilling to
 supply the zone.

Andrews Standards Track [Page 10] RFC 2308 DNS NCACHE March 1998

 The second class is where the server needs to obtain an answer from
 elsewhere, but is unable to do so, due to network failures, other
 servers that don't reply, or return server failure errors, or
 similar.
 In either case a resolver MAY cache a server failure response.  If it
 does so it MUST NOT cache it for longer than five (5) minutes, and it
 MUST be cached against the specific query tuple <query name, type,
 class, server IP address>.

7.2 Dead / Unreachable Server (OPTIONAL)

 Dead / Unreachable servers are servers that fail to respond in any
 way to a query or where the transport layer has provided an
 indication that the server does not exist or is unreachable.  A
 server may be deemed to be dead or unreachable if it has not
 responded to an outstanding query within 120 seconds.
 Examples of transport layer indications are:
    ICMP error messages indicating host, net or port unreachable.
    TCP resets
    IP stack error messages providing similar indications to those above.
 A server MAY cache a dead server indication.  If it does so it MUST
 NOT be deemed dead for longer than five (5) minutes.  The indication
 MUST be stored against query tuple <query name, type, class, server
 IP address> unless there was a transport layer indication that the
 server does not exist, in which case it applies to all queries to
 that specific IP address.

8 - Changes from RFC 1034

 Negative caching in resolvers is no-longer optional, if a resolver
 caches anything it must also cache negative answers.
 Non-authoritative negative answers MAY be cached.
 The SOA record from the authority section MUST be cached.  Name error
 indications must be cached against the tuple <query name, QCLASS>.
 No data indications must be cached against <query name, QTYPE,
 QCLASS> tuple.
 A cached SOA record must be added to the response.  This was
 explicitly not allowed because previously the distinction between a
 normal cached SOA record, and the SOA cached as a result of a
 negative response was not made, and simply extracting a normal cached
 SOA and adding that to a cached negative response causes problems.

Andrews Standards Track [Page 11] RFC 2308 DNS NCACHE March 1998

 The $TTL TTL directive was added to the master file format.

9 - History of Negative Caching

 This section presents a potted history of negative caching in the DNS
 and forms no part of the technical specification of negative caching.
 It is interesting to note that the same concepts were re-invented in
 both the CHIVES and BIND servers.
 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.
 Late in 1987, I released the initial beta-test version of CHIVES, the
 DNS resolver I'd written to replace Paul's JEEVES resolver.  CHIVES
 included a search path mechanism that was used pretty heavily at
 several sites (including my own), so CHIVES also included a negative
 caching mechanism based on SOA MINIMUM values.  The basic strategy
 was to cache authoritative error codes keyed by the exact query
 parameters (QNAME, QCLASS, and QTYPE), with a cache TTL equal to the
 SOA MINIMUM value.  CHIVES did not attempt to track down SOA RRs if
 they weren't supplied in the authoritative response, so it never
 managed to completely eliminate the gratuitous DNS error message
 traffic, but it did help considerably.  Keep in mind that this was
 happening at about the same time as the near-collapse of the ARPANET
 due to congestion caused by exponential growth and the the "old"
 (pre-VJ) TCP retransmission algorithm, so negative caching resulted
 in drasticly better DNS response time for our users, mailer daemons,
 etcetera.

Andrews Standards Track [Page 12] RFC 2308 DNS NCACHE March 1998

 As far as I know, CHIVES was the first resolver to implement negative
 caching.  CHIVES was developed during the twilight years of TOPS-20,
 so it never ran on very many machines, but the few machines that it
 did run on were the ones that were too critical to shut down quickly
 no matter how much it cost to keep them running.  So what few users
 we did have tended to drive CHIVES pretty hard.  Several interesting
 bits of DNS technology resulted from that, but the one that's
 relevant here is the MAXTTL configuration parameter.
 Experience with JEEVES had already shown that RRs often showed up
 with ridiculously long TTLs (99999999 was particularly popular for
 many years, due to bugs in the code and documentation of several
 early versions of BIND), and that robust software that blindly
 believed such TTLs could create so many strange failures that it was
 often necessary to reboot the resolver frequently just to clear this
 garbage out of the cache.  So CHIVES had a configuration parameter
 "MAXTTL", which specified the maximum "reasonable" TTL in a received
 RR.  RRs with TTLs greater than MAXTTL would either have their TTLs
 reduced to MAXTTL or would be discarded entirely, depending on the
 setting of another configuration parameter.
 When we started getting field experience with CHIVES's negative
 caching code, it became clear that the SOA MINIMUM value was often
 large enough to cause the same kinds of problems for negative caching
 as the huge TTLs in RRs had for normal caching (again, this was in
 part due to a bug in several early versions of BIND, where a
 secondary server would authoritatively deny all knowledge of its
 zones if it couldn't contact the primaries on reboot).  So we started
 running the negative cache TTLs through the MAXTTL check too, and
 continued to experiment.
 The configuration that seemed to work best on WSMR-SIMTEL20.ARMY.MIL
 (last of the major Internet TOPS-20 machines to be shut down, thus
 the last major user of CHIVES, thus the place where we had the
 longest experimental baseline) was to set MAXTTL to about three days.
 Most of the traffic initiated by SIMTEL20 in its last years was
 mail-related, and the mail queue timeout was set to one week, so this
 gave a "stuck" message several tries at complete DNS resolution,
 without bogging down the system with a lot of useless queries.  Since
 (for reasons that now escape me) we only had the single MAXTTL
 parameter rather than separate ones for positive and negative
 caching, it's not clear how much effect this setting of MAXTTL had on
 the negative caching code.
 CHIVES also included a second, somewhat controversial mechanism which
 took the place of negative caching in some cases.  The CHIVES
 resolver daemon could be configured to load DNS master files, giving
 it the ability to act as what today would be called a "stealth

Andrews Standards Track [Page 13] RFC 2308 DNS NCACHE March 1998

 secondary".  That is, when configured in this way, the resolver had
 direct access to authoritative information for heavily-used zones.
 The search path mechanisms in CHIVES reflected this: there were
 actually two separate search paths, one of which only searched local
 authoritative zone data, and one which could generate normal
 iterative queries.  This cut down on the need for negative caching in
 cases where usage was predictably heavy (e.g., the resolver on
 XX.LCS.MIT.EDU always loaded the zone files for both LCS.MIT.EDU and
 AI.MIT.EDU and put both of these suffixes into the "local" search
 path, since between them the hosts in these two zones accounted for
 the bulk of the DNS traffic).  Not all sites running CHIVES chose to
 use this feature; C.CS.CMU.EDU, for example, chose to use the
 "remote" search path for everything because there were too many
 different sub-zones at CMU for zone shadowing to be practical for
 them, so they relied pretty heavily on negative caching even for
 local traffic.
 Overall, I still think the basic design we used for negative caching
 was pretty reasonable: the zone administrator specified how long to
 cache negative answers, and the resolver configuration chose the
 actual cache time from the range between zero and the period
 specified by the zone administrator.  There are a lot of details I'd
 do differently now (like using a new SOA field instead of overloading
 the MINIMUM field), but after more than a decade, I'd be more worried
 if we couldn't think of at least a few improvements.

9.2 BIND

 While not the first attempt to get negative caching into BIND, in
 July 1993, BIND 4.9.2 ALPHA, Anant Kumar of ISI supplied code that
 implemented, validation and negative caching (NCACHE).  This code had
 a 10 minute TTL for negative caching and only cached the indication
 that there was a negative response, NXDOMAIN or NOERROR_NODATA. This
 is the origin of the NODATA pseudo response code mentioned above.
 Mark Andrews of CSIRO added code (RETURNSOA) that stored the SOA
 record such that it could be retrieved by a similar query.  UUnet
 complained that they were getting old answers after loading a new
 zone, and the option was turned off, BIND 4.9.3-alpha5, April 1994.
 In reality this indicated that the named needed to purge the space
 the zone would occupy.  Functionality to do this was added in BIND
 4.9.3 BETA11 patch2, December 1994.
 RETURNSOA was re-enabled by default, BIND 4.9.5-T1A, August 1996.

Andrews Standards Track [Page 14] RFC 2308 DNS NCACHE March 1998

10 Example

 The following example is based on a signed zone that is empty apart
 from the nameservers.  We will query for WWW.XX.EXAMPLE showing
 initial response and again 10 minutes later.  Note 1: during the
 intervening 10 minutes the NS records for XX.EXAMPLE have expired.
 Note 2: the TTL of the SIG records are not explicitly set in the zone
 file and are hence the TTL of the RRset they are the signature for.
      Zone File:
      $TTL 86400
      $ORIGIN XX.EXAMPLE.
      @       IN      SOA     NS1.XX.EXAMPLE. HOSTMATER.XX.EXAMPLE. (
                              1997102000      ; serial
                              1800    ; refresh (30 mins)
                              900     ; retry (15 mins)
                              604800  ; expire (7 days)
                              1200 ) ; minimum (20 mins)
              IN      SIG     SOA ...
        1200  IN      NXT     NS1.XX.EXAMPLE. A NXT SIG SOA NS KEY
              IN      SIG     NXT ... XX.EXAMPLE. ...
         300  IN      NS      NS1.XX.EXAMPLE.
         300  IN      NS      NS2.XX.EXAMPLE.
              IN      SIG     NS ... XX.EXAMPLE. ...
              IN      KEY     0x4100 1 1 ...
              IN      SIG     KEY ... XX.EXAMPLE. ...
              IN      SIG     KEY ... EXAMPLE. ...
      NS1     IN      A       10.0.0.1
              IN      SIG     A ... XX.EXAMPLE. ...
        1200  IN      NXT     NS2.XX.EXAMPLE. A NXT SIG
              IN      SIG     NXT ...
      NS2     IN      A       10.0.0.2
              IN      SIG     A ... XX.EXAMPLE. ...
        1200  IN      NXT     XX.EXAMPLE. A NXT SIG
              IN      SIG     NXT ... XX.EXAMPLE. ...
      Initial Response:
      Header:
          RDCODE=NXDOMAIN, AA=1, QR=1, TC=0
      Query:
          WWW.XX.EXAMPLE. IN A
      Answer:
          <empty>
      Authority:
          XX.EXAMPLE.      1200 IN SOA NS1.XX.EXAMPLE. ...
          XX.EXAMPLE.      1200 IN SIG SOA ... XX.EXAMPLE. ...

Andrews Standards Track [Page 15] RFC 2308 DNS NCACHE March 1998

          NS2.XX.EXAMPLE.  1200 IN NXT XX.EXAMPLE. NXT A NXT SIG
          NS2.XX.EXAMPLE.  1200 IN SIG NXT ... XX.EXAMPLE. ...
          XX.EXAMPLE.     86400 IN NS  NS1.XX.EXAMPLE.
          XX.EXAMPLE.     86400 IN NS  NS2.XX.EXAMPLE.
          XX.EXAMPLE.     86400 IN SIG NS ... XX.EXAMPLE. ...
      Additional
          XX.EXAMPLE.     86400 IN KEY 0x4100 1 1 ...
          XX.EXAMPLE.     86400 IN SIG KEY ... EXAMPLE. ...
          NS1.XX.EXAMPLE. 86400 IN A   10.0.0.1
          NS1.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
          NS2.XX.EXAMPLE. 86400 IN A   10.0.0.2
          NS3.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
       After 10 Minutes:
       Header:
           RDCODE=NXDOMAIN, AA=0, QR=1, TC=0
       Query:
           WWW.XX.EXAMPLE. IN A
       Answer:
           <empty>
       Authority:
           XX.EXAMPLE.       600 IN SOA NS1.XX.EXAMPLE. ...
           XX.EXAMPLE.       600 IN SIG SOA ... XX.EXAMPLE. ...
           NS2.XX.EXAMPLE.   600 IN NXT XX.EXAMPLE. NXT A NXT SIG
           NS2.XX.EXAMPLE.   600 IN SIG NXT ... XX.EXAMPLE. ...
           EXAMPLE.        65799 IN NS  NS1.YY.EXAMPLE.
           EXAMPLE.        65799 IN NS  NS2.YY.EXAMPLE.
           EXAMPLE.        65799 IN SIG NS ... XX.EXAMPLE. ...
       Additional
           XX.EXAMPLE.     65800 IN KEY 0x4100 1 1 ...
           XX.EXAMPLE.     65800 IN SIG KEY ... EXAMPLE. ...
           NS1.YY.EXAMPLE. 65799 IN A   10.100.0.1
           NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
           NS2.YY.EXAMPLE. 65799 IN A   10.100.0.2
           NS3.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
           EXAMPLE.        65799 IN KEY 0x4100 1 1 ...
           EXAMPLE.        65799 IN SIG KEY ... . ...

11 Security Considerations

 It is believed that this document does not introduce any significant
 additional security threats other that those that already exist when
 using data from the DNS.

Andrews Standards Track [Page 16] RFC 2308 DNS NCACHE March 1998

 With negative caching it might be possible to propagate a denial of
 service attack by spreading a NXDOMAIN message with a very high TTL.
 Without negative caching that would be much harder.  A similar effect
 could be achieved previously by spreading a bad A record, so that the
 server could not be reached - which is almost the same.  It has the
 same effect as far as what the end user is able to do, but with a
 different psychological effect.  With the bad A, I feel "damn the
 network is broken again" and try again tomorrow.  With the "NXDOMAIN"
 I feel "Oh, they've turned off the server and it doesn't exist any
 more" and probably never bother trying this server again.
 A practical example of this is a SMTP server where this behaviour is
 encoded.  With a NXDOMAIN attack the mail message would bounce
 immediately, where as with a bad A attack the mail would be queued
 and could potentially get through after the attack was suspended.
 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.
 Implementing TTL sanity checking will reduce the effectiveness of
 such an attack, because a successful attack would require re-
 injection of the bogus data at more frequent intervals.
 DNS Security [RFC2065] provides a mechanism to verify whether a
 negative response is valid or not, through the use of NXT and SIG
 records.  This document supports the use of that mechanism by
 promoting the transmission of the relevant security records even in a
 non security aware server.

Acknowledgments

 I would like to thank Rob Austein for his history of the CHIVES
 nameserver. The DNSIND working group, in particular Robert Elz for
 his valuable technical and editorial contributions to this document.

Andrews Standards Track [Page 17] RFC 2308 DNS NCACHE March 1998

References

 [RFC1034]
         Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES,"
         STD 13, RFC 1034, November 1987.
 [RFC1035]
         Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
         SPECIFICATION," STD 13, RFC 1035, November 1987.
 [RFC2065]
         Eastlake, D., and C. Kaufman, "Domain Name System Security
         Extensions," RFC 2065, January 1997.
 [RFC2119]
         Bradner, S., "Key words for use in RFCs to Indicate
         Requirement Levels," BCP 14, RFC 2119, March 1997.
 [RFC2181]
         Elz, R., and R. Bush, "Clarifications to the DNS
         Specification," RFC 2181, July 1997.

Author's Address

 Mark Andrews
 CSIRO - Mathematical and Information Sciences
 Locked Bag 17
 North Ryde NSW 2113
 AUSTRALIA
 Phone: +61 2 9325 3148
 EMail: Mark.Andrews@cmis.csiro.au

Andrews Standards Track [Page 18] RFC 2308 DNS NCACHE March 1998

Full Copyright Statement

 Copyright (C) The Internet Society (1998).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Andrews Standards Track [Page 19]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2308.txt · Last modified: 1998/03/17 23:25 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki