rfc2181.txt

dns 解析源代码

Network Working Group                                             R. Elz
Request for Comments: 2181                       University of Melbourne
Updates: 1034, 1035, 1123                                        R. Bush
Category: Standards Track                                    RGnet, Inc.
                                                               July 1997


                Clarifications to the DNS Specification

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.

1. Abstract

   This document considers some areas that have been identified as
   problems with the specification of the Domain Name System, and
   proposes remedies for the defects identified.  Eight separate issues
   are considered:

     + IP packet header address usage from multi-homed servers,
     + TTLs in sets of records with the same name, class, and type,
     + correct handling of zone cuts,
     + three minor issues concerning SOA records and their use,
     + the precise definition of the Time to Live (TTL)
     + Use of the TC (truncated) header bit
     + the issue of what is an authoritative, or canonical, name,
     + and the issue of what makes a valid DNS label.

   The first six of these are areas where the correct behaviour has been
   somewhat unclear, we seek to rectify that.  The other two are already
   adequately specified, however the specifications seem to be sometimes
   ignored.  We seek to reinforce the existing specifications.














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




Contents

    1  Abstract  ...................................................   1
    2  Introduction  ...............................................   2
    3  Terminology  ................................................   3
    4  Server Reply Source Address Selection  ......................   3
    5  Resource Record Sets  .......................................   4
    6  Zone Cuts  ..................................................   8
    7  SOA RRs  ....................................................  10
    8  Time to Live (TTL)  .........................................  10
    9  The TC (truncated) header bit  ..............................  11
   10  Naming issues  ..............................................  11
   11  Name syntax  ................................................  13
   12  Security Considerations  ....................................  14
   13  References  .................................................  14
   14  Acknowledgements  ...........................................  15
   15  Authors' Addresses  .........................................  15




2. Introduction

   Several problem areas in the Domain Name System specification
   [RFC1034, RFC1035] have been noted through the years [RFC1123].  This
   document addresses several additional problem areas.  The issues here
   are independent.  Those issues are the question of which source
   address a multi-homed DNS server should use when replying to a query,
   the issue of differing TTLs for DNS records with the same label,
   class and type, and the issue of canonical names, what they are, how
   CNAME records relate, what names are legal in what parts of the DNS,
   and what is the valid syntax of a DNS name.

   Clarifications to the DNS specification to avoid these problems are
   made in this memo.  A minor ambiguity in RFC1034 concerned with SOA
   records is also corrected, as is one in the definition of the TTL
   (Time To Live) and some possible confusion in use of the TC bit.












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


3. Terminology

   This memo does not use the oft used expressions MUST, SHOULD, MAY, or
   their negative forms.  In some sections it may seem that a
   specification is worded mildly, and hence some may infer that the
   specification is optional.  That is not correct.  Anywhere that this
   memo suggests that some action should be carried out, or must be
   carried out, or that some behaviour is acceptable, or not, that is to
   be considered as a fundamental aspect of this specification,
   regardless of the specific words used.  If some behaviour or action
   is truly optional, that will be clearly specified by the text.

4. Server Reply Source Address Selection

   Most, if not all, DNS clients, expect the address from which a reply
   is received to be the same address as that to which the query
   eliciting the reply was sent.  This is true for servers acting as
   clients for the purposes of recursive query resolution, as well as
   simple resolver clients.  The address, along with the identifier (ID)
   in the reply is used for disambiguating replies, and filtering
   spurious responses.  This may, or may not, have been intended when
   the DNS was designed, but is now a fact of life.

   Some multi-homed hosts running DNS servers generate a reply using a
   source address that is not the same as the destination address from
   the client's request packet.  Such replies will be discarded by the
   client because the source address of the reply does not match that of
   a host to which the client sent the original request.  That is, it
   appears to be an unsolicited response.

4.1. UDP Source Address Selection

   To avoid these problems, servers when responding to queries using UDP
   must cause the reply to be sent with the source address field in the
   IP header set to the address that was in the destination address
   field of the IP header of the packet containing the query causing the
   response.  If this would cause the response to be sent from an IP
   address that is not permitted for this purpose, then the response may
   be sent from any legal IP address allocated to the server.  That
   address should be chosen to maximise the possibility that the client
   will be able to use it for further queries.  Servers configured in
   such a way that not all their addresses are equally reachable from
   all potential clients need take particular care when responding to
   queries sent to anycast, multicast, or similar, addresses.







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


4.2. Port Number Selection

   Replies to all queries must be directed to the port from which they
   were sent.  When queries are received via TCP this is an inherent
   part of the transport protocol.  For queries received by UDP the
   server must take note of the source port and use that as the
   destination port in the response.  Replies should always be sent from
   the port to which they were directed.  Except in extraordinary
   circumstances, this will be the well known port assigned for DNS
   queries [RFC1700].

5. Resource Record Sets

   Each DNS Resource Record (RR) has a label, class, type, and data.  It
   is meaningless for two records to ever have label, class, type and
   data all equal - servers should suppress such duplicates if
   encountered.  It is however possible for most record types to exist
   with the same label, class and type, but with different data.  Such a
   group of records is hereby defined to be a Resource Record Set
   (RRSet).

5.1. Sending RRs from an RRSet

   A query for a specific (or non-specific) label, class, and type, will
   always return all records in the associated RRSet - whether that be
   one or more RRs.  The response must be marked as "truncated" if the
   entire RRSet will not fit in the response.

5.2. TTLs of RRs in an RRSet

   Resource Records also have a time to live (TTL).  It is possible for
   the RRs in an RRSet to have different TTLs.  No uses for this have
   been found that cannot be better accomplished in other ways.  This
   can, however, cause partial replies (not marked "truncated") from a
   caching server, where the TTLs for some but not all the RRs in the
   RRSet have expired.

   Consequently the use of differing TTLs in an RRSet is hereby
   deprecated, the TTLs of all RRs in an RRSet must be the same.

   Should a client receive a response containing RRs from an RRSet with
   differing TTLs, it should treat this as an error.  If the RRSet
   concerned is from a non-authoritative source for this data, the
   client should simply ignore the RRSet, and if the values were
   required, seek to acquire them from an authoritative source.  Clients
   that are configured to send all queries to one, or more, particular
   servers should treat those servers as authoritative for this purpose.
   Should an authoritative source send such a malformed RRSet, the



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


   client should treat the RRs for all purposes as if all TTLs in the
   RRSet had been set to the value of the lowest TTL in the RRSet.  In
   no case may a server send an RRSet with TTLs not all equal.

5.3. DNSSEC Special Cases

   Two of the record types added by DNS Security (DNSSEC) [RFC2065]
   require special attention when considering the formation of Resource
   Record Sets.  Those are the SIG and NXT records.  It should be noted
   that DNS Security is still very new, and there is, as yet, little
   experience with it.  Readers should be prepared for the information
   related to DNSSEC contained in this document to become outdated as
   the DNS Security specification matures.

5.3.1. SIG records and RRSets

   A SIG record provides signature (validation) data for another RRSet
   in the DNS.  Where a zone has been signed, every RRSet in the zone
   will have had a SIG record associated with it.  The data type of the
   RRSet is included in the data of the SIG RR, to indicate with which
   particular RRSet this SIG record is associated.  Were the rules above
   applied, whenever a SIG record was included with a response to
   validate that response, the SIG records for all other RRSets
   associated with the appropriate node would also need to be included.
   In some cases, this could be a very large number of records, not
   helped by their being rather large RRs.

   Thus, it is specifically permitted for the authority section to
   contain only those SIG RRs with the "type covered" field equal to the
   type field of an answer being returned.  However, where SIG records
   are being returned in the answer section, in response to a query for
   SIG records, or a query for all records associated with a name
   (type=ANY) the entire SIG RRSet must be included, as for any other RR
   type.

   Servers that receive responses containing SIG records in the
   authority section, or (probably incorrectly) as additional data, must
   understand that the entire RRSet has almost certainly not been
   included.  Thus, they must not cache that SIG record in a way that
   would permit it to be returned should a query for SIG records be
   received at that server.  RFC2065 actually requires that SIG queries
   be directed only to authoritative servers to avoid the problems that
   could be caused here, and while servers exist that do not understand
   the special properties of SIG records, this will remain necessary.
   However, careful design of SIG record processing in new
   implementations should permit this restriction to be relaxed in the
   future, so resolvers do not need to treat SIG record queries
   specially.