rfc2308.txt

bind 9.3结合mysql数据库

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.