rfc2181.txt

RFC 的详细文档！

Elz & Bush                  Standards Track                     [Page 5]

RFC 2181        Clarifications to the DNS Specification        July 1997


   It has been occasionally stated that a received request for a SIG
   record should be forwarded to an authoritative server, rather than
   being answered from data in the cache.  This is not necessary - a
   server that has the knowledge of SIG as a special case for processing
   this way would be better to correctly cache SIG records, taking into
   account their characteristics.  Then the server can determine when it
   is safe to reply from the cache, and when the answer is not available
   and the query must be forwarded.

5.3.2. NXT RRs

   Next Resource Records (NXT) are even more peculiar.  There will only
   ever be one NXT record in a zone for a particular label, so
   superficially, the RRSet problem is trivial.  However, at a zone cut,
   both the parent zone, and the child zone (superzone and subzone in
   RFC2065 terminology) will have NXT records for the same name.  Those
   two NXT records do not form an RRSet, even where both zones are
   housed at the same server.  NXT RRSets always contain just a single
   RR.  Where both NXT records are visible, two RRSets exist.  However,
   servers are not required to treat this as a special case when
   receiving NXT records in a response.  They may elect to notice the
   existence of two different NXT RRSets, and treat that as they would
   two different RRSets of any other type.  That is, cache one, and
   ignore the other.  Security aware servers will need to correctly
   process the NXT record in the received response though.

5.4. Receiving RRSets

   Servers must never merge RRs from a response with RRs in their cache
   to form an RRSet.  If a response contains data that would form an
   RRSet with data in a server's cache the server must either ignore the
   RRs in the response, or discard the entire RRSet currently in the
   cache, as appropriate.  Consequently the issue of TTLs varying
   between the cache and a response does not cause concern, one will be
   ignored.  That is, one of the data sets is always incorrect if the
   data from an answer differs from the data in the cache.  The
   challenge for the server is to determine which of the data sets is
   correct, if one is, and retain that, while ignoring the other.  Note
   that if a server receives an answer containing an RRSet that is
   identical to that in its cache, with the possible exception of the
   TTL value, it may, optionally, update the TTL in its cache with the
   TTL of the received answer.  It should do this if the received answer
   would be considered more authoritative (as discussed in the next
   section) than the previously cached answer.







Elz & Bush                  Standards Track                     [Page 6]

RFC 2181        Clarifications to the DNS Specification        July 1997


5.4.1. Ranking data

   When considering whether to accept an RRSet in a reply, or retain an
   RRSet already in its cache instead, a server should consider the
   relative likely trustworthiness of the various data.  An
   authoritative answer from a reply should replace cached data that had
   been obtained from additional information in an earlier reply.
   However additional information from a reply will be ignored if the
   cache contains data from an authoritative answer or a zone file.

   The accuracy of data available is assumed from its source.
   Trustworthiness shall be, in order from most to least:

     + Data from a primary zone file, other than glue data,
     + Data from a zone transfer, other than glue,
     + The authoritative data included in the answer section of an
       authoritative reply.
     + Data from the authority section of an authoritative answer,
     + Glue from a primary zone, or glue from a zone transfer,
     + Data from the answer section of a non-authoritative answer, and
       non-authoritative data from the answer section of authoritative
       answers,
     + Additional information from an authoritative answer,
       Data from the authority section of a non-authoritative answer,
       Additional information from non-authoritative answers.

   Note that the answer section of an authoritative answer normally
   contains only authoritative data.  However when the name sought is an
   alias (see section 10.1.1) only the record describing that alias is
   necessarily authoritative.  Clients should assume that other records
   may have come from the server's cache.  Where authoritative answers
   are required, the client should query again, using the canonical name
   associated with the alias.

   Unauthenticated RRs received and cached from the least trustworthy of
   those groupings, that is data from the additional data section, and
   data from the authority section of a non-authoritative answer, should
   not be cached in such a way that they would ever be returned as
   answers to a received query.  They may be returned as additional
   information where appropriate.  Ignoring this would allow the
   trustworthiness of relatively untrustworthy data to be increased
   without cause or excuse.

   When DNS security [RFC2065] is in use, and an authenticated reply has
   been received and verified, the data thus authenticated shall be
   considered more trustworthy than unauthenticated data of the same
   type.  Note that throughout this document, "authoritative" means a
   reply with the AA bit set.  DNSSEC uses trusted chains of SIG and KEY



Elz & Bush                  Standards Track                     [Page 7]

RFC 2181        Clarifications to the DNS Specification        July 1997


   records to determine the authenticity of data, the AA bit is almost
   irrelevant.  However DNSSEC aware servers must still correctly set
   the AA bit in responses to enable correct operation with servers that
   are not security aware (almost all currently).

   Note that, glue excluded, it is impossible for data from two
   correctly configured primary zone files, two correctly configured
   secondary zones (data from zone transfers) or data from correctly
   configured primary and secondary zones to ever conflict.  Where glue
   for the same name exists in multiple zones, and differs in value, the
   nameserver should select data from a primary zone file in preference
   to secondary, but otherwise may choose any single set of such data.
   Choosing that which appears to come from a source nearer the
   authoritative data source may make sense where that can be
   determined.  Choosing primary data over secondary allows the source
   of incorrect glue data to be discovered more readily, when a problem
   with such data exists.  Where a server can detect from two zone files
   that one or more are incorrectly configured, so as to create
   conflicts, it should refuse to load the zones determined to be
   erroneous, and issue suitable diagnostics.

   "Glue" above includes any record in a zone file that is not properly
   part of that zone, including nameserver records of delegated sub-
   zones (NS records), address records that accompany those NS records
   (A, AAAA, etc), and any other stray data that might appear.

5.5. Sending RRSets (reprise)

   A Resource Record Set should only be included once in any DNS reply.
   It may occur in any of the Answer, Authority, or Additional
   Information sections, as required.  However it should not be repeated
   in the same, or any other, section, except where explicitly required
   by a specification.  For example, an AXFR response requires the SOA
   record (always an RRSet containing a single RR) be both the first and
   last record of the reply.  Where duplicates are required this way,
   the TTL transmitted in each case must be the same.

6. Zone Cuts

   The DNS tree is divided into "zones", which are collections of
   domains that are treated as a unit for certain management purposes.
   Zones are delimited by "zone cuts".  Each zone cut separates a
   "child" zone (below the cut) from a "parent" zone (above the cut).
   The domain name that appears at the top of a zone (just below the cut
   that separates the zone from its parent) is called the zone's
   "origin".  The name of the zone is the same as the name of the domain
   at the zone's origin.  Each zone comprises that subset of the DNS
   tree that is at or below the zone's origin, and that is above the



Elz & Bush                  Standards Track                     [Page 8]

RFC 2181        Clarifications to the DNS Specification        July 1997


   cuts that separate the zone from its children (if any).  The
   existence of a zone cut is indicated in the parent zone by the
   existence of NS records specifying the origin of the child zone.  A
   child zone does not contain any explicit reference to its parent.

6.1. Zone authority

   The authoritative servers for a zone are enumerated in the NS records
   for the origin of the zone, which, along with a Start of Authority
   (SOA) record are the mandatory records in every zone.  Such a server
   is authoritative for all resource records in a zone that are not in
   another zone.  The NS records that indicate a zone cut are the
   property of the child zone created, as are any other records for the
   origin of that child zone, or any sub-domains of it.  A server for a
   zone should not return authoritative answers for queries related to
   names in another zone, which includes the NS, and perhaps A, records
   at a zone cut, unless it also happens to be a server for the other
   zone.

   Other than the DNSSEC cases mentioned immediately below, servers
   should ignore data other than NS records, and necessary A records to
   locate the servers listed in the NS records, that may happen to be
   configured in a zone at a zone cut.

6.2. DNSSEC issues

   The DNS security mechanisms [RFC2065] complicate this somewhat, as
   some of the new resource record types added are very unusual when
   compared with other DNS RRs.  In particular the NXT ("next") RR type
   contains information about which names exist in a zone, and hence
   which do not, and thus must necessarily relate to the zone in which
   it exists.  The same domain name may have different NXT records in
   the parent zone and the child zone, and both are valid, and are not
   an RRSet.  See also section 5.3.2.

   Since NXT records are intended to be automatically generated, rather
   than configured by DNS operators, servers may, but are not required
   to, retain all differing NXT records they receive regardless of the
   rules in section 5.4.

   For a secure parent zone to securely indicate that a subzone is
   insecure, DNSSEC requires that a KEY RR indicating that the subzone
   is insecure, and the parent zone's authenticating SIG RR(s) be
   present in the parent zone, as they by definition cannot be in the
   subzone.  Where a subzone is secure, the KEY and SIG records will be
   present, and authoritative, in that zone, but should also always be
   present in the parent zone (if secure).




Elz & Bush                  Standards Track                     [Page 9]

RFC 2181        Clarifications to the DNS Specification        July 1997


   Note that in none of these cases should a server for the parent zone,
   not also being a server for the subzone, set the AA bit in any
   response for a label at a zone cut.

7. SOA RRs

   Three minor issues concerning the Start of Zone of Authority (SOA)
   Resource Record need some clarification.

7.1. Placement of SOA RRs in authoritative answers

   RFC1034, in section 3.7, indicates that the authority section of an
   authoritative answer may contain the SOA record for the zone from
   which the answer was obtained.  When discussing negative caching,
   RFC1034 section 4.3.4 refers to this technique but mentions the
   additional section of the response.  The former is correct, as is
   implied by the example shown in section 6.2.5 of RFC1034.  SOA
   records, if added, are to be placed in the authority section.

7.2. TTLs on SOA RRs

   It may be observed that in section 3.2.1 of RFC1035, which defines
   the format of a Resource Record, that the definition of the TTL field
   contains a throw away line which states that the TTL of an SOA record
   should always be sent as zero to prevent caching.  This is mentioned
   nowhere else, and has not generally been implemented.
   Implementations should not assume that SOA records will have a TTL of
   zero, nor are they required to send SOA records with a TTL of zero.

7.3. The SOA.MNAME field

   It is quite clear in the specifications, yet seems to have been
   widely ignored, that the MNAME field of the SOA record should contain
   the name of the primary (master) server for the zone identified by
   the SOA.  It should not contain the name of the zone itself.  That
   information would be useless, as to discover it, one needs to start
   with the domain name of the SOA record - that is the name of the
   zone.

8. Time to Live (TTL)

   The definition of values appropriate to the TTL field in STD 13 is
   not as clear as it could be, with respect to how many significant
   bits exist, and whether the value is signed or unsigned.  It is
   hereby specified that a TTL value is an unsigned number, with a
   minimum value of 0, and a maximum value of 2147483647.  That is, a
   maximum of 2^31 - 1.  When transmitted, this value shall be encoded
   in the less significant 31 bits of the 32 bit TTL field, with the



Elz & Bush                  Standards Track                    [Page 10]