rfc2181.txt

RFC 的详细文档！


RFC 2181        Clarifications to the DNS Specification        July 1997


   most significant, or sign, bit set to zero.

   Implementations should treat TTL values received with the most
   significant bit set as if the entire value received was zero.

   Implementations are always free to place an upper bound on any TTL
   received, and treat any larger values as if they were that upper
   bound.  The TTL specifies a maximum time to live, not a mandatory
   time to live.

9. The TC (truncated) header bit

   The TC bit should be set in responses only when an RRSet is required
   as a part of the response, but could not be included in its entirety.
   The TC bit should not be set merely because some extra information
   could have been included, but there was insufficient room.  This
   includes the results of additional section processing.  In such cases
   the entire RRSet that will not fit in the response should be omitted,
   and the reply sent as is, with the TC bit clear.  If the recipient of
   the reply needs the omitted data, it can construct a query for that
   data and send that separately.

   Where TC is set, the partial RRSet that would not completely fit may
   be left in the response.  When a DNS client receives a reply with TC
   set, it should ignore that response, and query again, using a
   mechanism, such as a TCP connection, that will permit larger replies.

10. Naming issues

   It has sometimes been inferred from some sections of the DNS
   specification [RFC1034, RFC1035] that a host, or perhaps an interface
   of a host, is permitted exactly one authoritative, or official, name,
   called the canonical name.  There is no such requirement in the DNS.

10.1. CNAME resource records

   The DNS CNAME ("canonical name") record exists to provide the
   canonical name associated with an alias name.  There may be only one
   such canonical name for any one alias.  That name should generally be
   a name that exists elsewhere in the DNS, though there are some rare
   applications for aliases with the accompanying canonical name
   undefined in the DNS.  An alias name (label of a CNAME record) may,
   if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no
   other data.  That is, for any label in the DNS (any domain name)
   exactly one of the following is true:






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


     + one CNAME record exists, optionally accompanied by SIG, NXT, and
       KEY RRs,
     + one or more records exist, none being CNAME records,
     + the name exists, but has no associated RRs of any type,
     + the name does not exist at all.

10.1.1. CNAME terminology

   It has been traditional to refer to the label of a CNAME record as "a
   CNAME".  This is unfortunate, as "CNAME" is an abbreviation of
   "canonical name", and the label of a CNAME record is most certainly
   not a canonical name.  It is, however, an entrenched usage.  Care
   must therefore be taken to be very clear whether the label, or the
   value (the canonical name) of a CNAME resource record is intended.
   In this document, the label of a CNAME resource record will always be
   referred to as an alias.

10.2. PTR records

   Confusion about canonical names has lead to a belief that a PTR
   record should have exactly one RR in its RRSet.  This is incorrect,
   the relevant section of RFC1034 (section 3.6.2) indicates that the
   value of a PTR record should be a canonical name.  That is, it should
   not be an alias.  There is no implication in that section that only
   one PTR record is permitted for a name.  No such restriction should
   be inferred.

   Note that while the value of a PTR record must not be an alias, there
   is no requirement that the process of resolving a PTR record not
   encounter any aliases.  The label that is being looked up for a PTR
   value might have a CNAME record.  That is, it might be an alias.  The
   value of that CNAME RR, if not another alias, which it should not be,
   will give the location where the PTR record is found.  That record
   gives the result of the PTR type lookup.  This final result, the
   value of the PTR RR, is the label which must not be an alias.

10.3. MX and NS records

   The domain name used as the value of a NS resource record, or part of
   the value of a MX resource record must not be an alias.  Not only is
   the specification clear on this point, but using an alias in either
   of these positions neither works as well as might be hoped, nor well
   fulfills the ambition that may have led to this approach.  This
   domain name must have as its value one or more address records.
   Currently those will be A records, however in the future other record
   types giving addressing information may be acceptable.  It can also
   have other RRs, but never a CNAME RR.




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


   Searching for either NS or MX records causes "additional section
   processing" in which address records associated with the value of the
   record sought are appended to the answer.  This helps avoid needless
   extra queries that are easily anticipated when the first was made.

   Additional section processing does not include CNAME records, let
   alone the address records that may be associated with the canonical
   name derived from the alias.  Thus, if an alias is used as the value
   of an NS or MX record, no address will be returned with the NS or MX
   value.  This can cause extra queries, and extra network burden, on
   every query.  It is trivial for the DNS administrator to avoid this
   by resolving the alias and placing the canonical name directly in the
   affected record just once when it is updated or installed.  In some
   particular hard cases the lack of the additional section address
   records in the results of a NS lookup can cause the request to fail.

11. Name syntax

   Occasionally it is assumed that the Domain Name System serves only
   the purpose of mapping Internet host names to data, and mapping
   Internet addresses to host names.  This is not correct, the DNS is a
   general (if somewhat limited) hierarchical database, and can store
   almost any kind of data, for almost any purpose.

   The DNS itself places only one restriction on the particular labels
   that can be used to identify resource records.  That one restriction
   relates to the length of the label and the full name.  The length of
   any one label is limited to between 1 and 63 octets.  A full domain
   name is limited to 255 octets (including the separators).  The zero
   length full name is defined as representing the root of the DNS tree,
   and is typically written and displayed as ".".  Those restrictions
   aside, any binary string whatever can be used as the label of any
   resource record.  Similarly, any binary string can serve as the value
   of any record that includes a domain name as some or all of its value
   (SOA, NS, MX, PTR, CNAME, and any others that may be added).
   Implementations of the DNS protocols must not place any restrictions
   on the labels that can be used.  In particular, DNS servers must not
   refuse to serve a zone because it contains labels that might not be
   acceptable to some DNS client programs.  A DNS server may be
   configurable to issue warnings when loading, or even to refuse to
   load, a primary zone containing labels that might be considered
   questionable, however this should not happen by default.

   Note however, that the various applications that make use of DNS data
   can have restrictions imposed on what particular values are
   acceptable in their environment.  For example, that any binary label
   can have an MX record does not imply that any binary name can be used
   as the host part of an e-mail address.  Clients of the DNS can impose



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


   whatever restrictions are appropriate to their circumstances on the
   values they use as keys for DNS lookup requests, and on the values
   returned by the DNS.  If the client has such restrictions, it is
   solely responsible for validating the data from the DNS to ensure
   that it conforms before it makes any use of that data.

   See also [RFC1123] section 6.1.3.5.

12. Security Considerations

   This document does not consider security.

   In particular, nothing in section 4 is any way related to, or useful
   for, any security related purposes.

   Section 5.4.1 is also not related to security.  Security of DNS data
   will be obtained by the Secure DNS [RFC2065], which is mostly
   orthogonal to this memo.

   It is not believed that anything in this document adds to any
   security issues that may exist with the DNS, nor does it do anything
   to that will necessarily lessen them.  Correct implementation of the
   clarifications in this document might play some small part in
   limiting the spread of non-malicious bad data in the DNS, but only
   DNSSEC can help with deliberate attempts to subvert DNS data.

13. 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.

   [RFC1123]   Braden, R., "Requirements for Internet Hosts - application
               and support", STD 3, RFC 1123, January 1989.

   [RFC1700]   Reynolds, J., Postel, J., "Assigned Numbers",
               STD 2, RFC 1700, October 1994.

   [RFC2065]   Eastlake, D., Kaufman, C., "Domain Name System Security
               Extensions", RFC 2065, January 1997.









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


14. Acknowledgements

   This memo arose from discussions in the DNSIND working group of the
   IETF in 1995 and 1996, the members of that working group are largely
   responsible for the ideas captured herein.  Particular thanks to
   Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the
   DNSSEC issues in this document, and to John Gilmore for pointing out
   where the clarifications were not necessarily clarifying.  Bob Halley
   suggested clarifying the placement of SOA records in authoritative
   answers, and provided the references.  Michael Patton, as usual, and
   Mark Andrews, Alan Barrett and Stan Barber provided much assistance
   with many details.  Josh Littlefield helped make sure that the
   clarifications didn't cause problems in some irritating corner cases.

15. Authors' Addresses

   Robert Elz
   Computer Science
   University of Melbourne
   Parkville, Victoria, 3052
   Australia.

   EMail: [e-mail]


   Randy Bush
   RGnet, Inc.
   5147 Crystal Springs Drive NE
   Bainbridge Island, Washington,  98110
   United States.

   EMail: [e-mail]



















Elz & Bush                  Standards Track                    [Page 15]