rfc973.txt

RFC 相关的技术文档

Network Working Group                                   Paul Mockapetris
Request for Comments: 973                                            ISI
                                                            January 1986

                 Domain System Changes and Observations


STATUS OF THIS MEMO

   This RFC documents updates to Domain Name System specifications
   RFC-882 [1] and RFC-883 [2], suggests some operational guidelines,
   and discusses some experiences and problem areas in the present
   system.  Distribution of this memo is unlimited.

   This document includes all changes to the Domain System through
   January, 1986.  Change notices and additional discussion are
   available online in file [USC-ISIB.ARPA]<DOMAIN>DOMAIN.CHANGES.

OVERVIEW

   This memo is divided into four major sections:

      "UPDATES" which discusses changes to the domain specification
      which are in widespread use and should be regarded as being part
      of the specification.

      "OPERATION GUIDELINES" which suggests rules-of-thumb for using the
      domain system and configuring your database which are appropriate
      in most cases, but which may have rare exceptions.

      "EXPERIENCES" which discusses some unusual situations and common
      bugs which are encountered in the present system, and should be
      helpful in problem determination and tuning.

      "PROBLEM AREAS" which discusses some shortcomings in the present
      system which may be addressed in future versions.

UPDATES

   This section discusses changes to the specification which are final,
   and should be incorporated in all domain system software.

   TTL timeouts too small

      The 16 bit TTL field in RRs could not represent a large enough
      time interval.  The 16 bit field, using seconds for units, has a
      maximum period of approximately 18 hours.

      All time values, including all TTLs and the MINIMUM field of the
      SOA RR, are expanded to 32 bits.



Mockapetris                                                     [Page 1]



RFC 973                                                     January 1986
Domain System Changes and Observations


   CLASS changes

      Class 2, originally reserved for CSNET, is obsolete.  Class 3 has
      been assigned for use by CHAOS.

   CNAME usage

      The specification allows CNAME RRs to exist with other RRs at the
      same node.  This creates difficulties since the other RRs stored
      with the CNAME at the alias might not agree with the RRs stored at
      the primary name.

      If a node has a CNAME RR, it should have no other RRs.

   * semantics

      The use of * to represent a single label wildcard, along with the
      possibility of multiple * labels, led to difficult server
      implementations and complicated search algorithms.  There were
      also questions regarding whether a * based specification could
      refer to names that were not contained in the zone which had the *
      specification.

      While we might want the "inheritability" for some cases, it leads
      to implementation difficulties.  The first of these is that
      whenever we can't find a RR in a particular zone, we have to
      search all parent zones to look for a suitable * result.
      (Alternatively we could develop some automatic method for insuring
      consistency or insist on careful duplication of inherited data.)
      We also must deal with conflicts, i.e. what if a subdomain doesn't
      want to inherit defaults.

      Given these difficulties, the solution is to insist that
      delegation of authority cancels the * defaults.  This is quite
      simple to implement; all you need to do is to check for delegation
      before looking for * RRs.

      A second difficulty is the restriction that * match a single
      label.  Thus if a name server is looking for RRs for the name
      A.B.C.D.E.F, it must check for *.B.C.D.E.F, *.*.C.D.E.F,
      *.*.*.D.E.F, etc.  This check must also be careful of zone
      boundaries and multiplies the effort to handle a query.

      The solution adopted is to allow a single * label in the leftmost
      part of a name stored in a zone, and to allow this label to match




Mockapetris                                                     [Page 2]



RFC 973                                                     January 1986
Domain System Changes and Observations


      any number of unknown labels or a single known label in the query
      name.  However, the * match is only taken for parts of the tree
      which are neither delegated or explicitly represented.

      The algorithm for performing the search in a tree structured
      database has the following steps:

      1) Descend in the tree matching labels from right to left.  If a
      delegation is found return that;  if the specified node is found
      go to step 2, if the tree ends go to step 3.

      2) Look for RRs that answer the query.  If any are found, return
      them as the answer.  If none are found, look for answers in a *
      node which has the same name as the query name except for the
      rightmost label.  (e.g. if you can't find an answer at F.ISI.ARPA,
      look for a RR at *.ISI.ARPA)

      3) The search for a desired name has failed; look for a node whose
      name is * plus however much matched.  Look for answers there.
      (e.g. If you are looking for X.Y.ISI.ARPA and the tree ends at
      ISI.ARPA, look at *.ISI.ARPA.  The same thing holds for
      Y.ISI.ARPA, or any name of the form <anything>.Z.ISI.ARPA, where Z
      is a label that doesn't exist under ISI.ARPA)

      Note that this interpretation means that * matches names that are
      not in the tree, no matter how much of the tree is missing, and
      also matches one level's worth of known tree.

   AA semantics

      When a name server is responding to a query for a particular name
      and finds a CNAME, it may optionally restart the search at the
      canonical name.  If the server uses the restart feature, the
      answer section of the returned query contains one (or more)
      CNAMEs, possibly followed by answers for the primary name.  The
      canonical name will usually be in the same zone as the alias, but
      this need not be the case.  If the server is authoritative for one
      of the names but not both, it is not clear whether the AA bit
      should be set.

      The solution adopted is to make the AA refer to the original query
      name.







Mockapetris                                                     [Page 3]



RFC 973                                                     January 1986
Domain System Changes and Observations


   Master file format

      The present specification uses a somewhat awkward method for
      representing domain names in master files.

      The change adopted is that all domain names in this file will be
      represented as either absolute or relative.  An absolute domain
      name ends with a ".".  A free standing "." is assumed to refer to
      the root.  A relative domain name doesn't end with a dot, and is
      assumed to be relative to the current origin.

   SERIAL number size

      If the master file changes rapidly, an infrequently updated copy
      may miss the wrapping of the sequence number in the SERIAL field
      of the SOA, or misinterpret the number of updates that have taken
      place.

      The SERIAL field is increased to 32 bits.

   MD and MF replaced by MX

      The original specification uses MD and MF RRs for mail agent
      binding.  The problem is that a mailer making a MAILA query, which
      asks for both types, can't use the cache since the cache might
      have the results for a MD or MF query.  That is, the presence of
      one of these types of information in the cache doesn't imply
      anything about the other type.  The result was that either mailers
      would have to always consult authoritative servers or try to use
      partial information; neither of these is really acceptable.

      The change is to replace MD and MF with a new type of RR called MX
      which conveys similar information in a single RR type.  MX has
      been assigned a type code of 15 decimal.  The format of the MX RR
      is a 16 bit preference value followed by a domain name.  A node
      may have multiple MX RRs, and multiple MX RRs with the same
      preference value are allowed at a given node.












Mockapetris                                                     [Page 4]



RFC 973                                                     January 1986
Domain System Changes and Observations


      The preference values denote the relative preference that the mail
      destination places on the mail agents, with lower values being
      "better".  A mailer is expected to at least try the mail agent(s)
      with the lowest preference value.  The significance of particular
      preference values, the units of preference, and the linearity of
      preference values are not defined but left open; preference values
      should only be used to establish relative rankings.

      For example, the current RRs:

                       MAIL-ORG   MD    HOST1    
                                  MD    HOST2    
                                  MF    HOST3    

      might be replaced by:

                       MAIL-ORG   MX    10 HOST1 
                                  MX    10 HOST2 
                                  MX    20 HOST3 

      The values 10 and 20 have no significance other than 10<20.  A
      detailed discussion of the use of MX is the subject of [3].

   Zone transfer

      The original specification states that zone transfers take place
      in breadth first order.  The intent was to make the transfer
      easier for the accepting name server to handle.  This now doesn't
      work out to be very helpful, and is a severe pain for implementers
      using various hashing algorithms.  The new rule is that you can
      transmit the records in any order you choose, so long as the SOA
      node of the zone is transmitted first and last, and no other
      duplication occurs.

   IN-ADDR domain renamed

      The name of the IN-ADDR domain is now IN-ADDR.ARPA.  This change
      was made because many felt that the use of a top-level name was
      inappropriate to network-specific information.










Mockapetris                                                     [Page 5]