rfc2308.txt

bind 9.3结合mysql数据库

           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 <[e-mail]> 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