doc: Add RFC documents

1 files changed, 570 insertions, 0 deletions

diff --git a/doc/rfc/rfc973.txt b/doc/rfc/rfc973.txt
new file mode 100644
index 0000000..17776f3
--- /dev/null
+++ b/doc/rfc/rfc973.txt
@@ -0,0 +1,570 @@
+
+
+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]
+
+
+
+RFC 973                                                     January 1986
+Domain System Changes and Observations
+
+
+OPERATIONAL GUIDELINES
+
+   This section 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.
+
+   Zone delegation
+
+      When a domain wishes to become independent from its parent, the
+      RRs which mark the delegation in the parent and child zones should
+      be carefully synchronized to minimize the possibility that
+      resolvers become confused.
+
+      For example, suppose that we wish to create a new zone called
+      ISI.EDU under an existing EDU zone, and that the servers for the
+      child zone are X.ISI.EDU and Y.GOV.
+
+      We might add the following to the parent zone:
+
+       ISI.EDU.      10000 NS  X.ISI.EDU.              
+                     10000 NS  Y.GOV.                  
+       X.ISI.EDU.    10000 A   <address of X.ISI.EDU.> 
+       Y.GOV.        10000 A   <address of Y.GOV.>     
+
+      and the following to the child zone:
+
+       ISI.EDU.      10000 NS  X.ISI.EDU.              
+                     10000 NS  Y.GOV.                  
+                     50000 SOA <SOA information>       
+       X.ISI.EDU.    10000 A   <address of X.ISI.EDU.> 
+       Y.GOV.        10000 A   <address of Y.GOV.>     
+
+      Note the following:
+
+         In both cases, the A RR for Y.GOV is included, even though
+         Y.GOV isn't in the EDU or ISI.EDU domains.  This RR isn't
+         authoritative, but is included to guarantee that the address of
+         Y.GOV is passed with delegations to it.  Strictly speaking this
+         RR need not be in either zone, but its presence is recommended.
+         The X.ISI.EDU A RR is absolutely essential.  The only time that
+         a server should use the glue RRs is when it is returning the NS
+         RRs and doesn't otherwise have the address of the server.  For
+         example, if the parent server also was authoritative for GOV,
+         the glue RR would typically not be consulted.  However, it is
+         still a good idea for it to be present, so that the zone is
+         self-sufficient.
+
+
+
+Mockapetris                                                     [Page 6]
+
+
+
+RFC 973                                                     January 1986
+Domain System Changes and Observations
+
+
+         The child zone and the parent zone have identical NS RRs for
+         the ISI.EDU domain.  This guarantees that no matter which
+         server is asked about the ISI.EDU domain, the same set of name
+         servers is returned.
+
+         The child zone and the parent zone have A RRs for the name
+         servers in the NS RRs that delegate the ISI.EDU domain.  This
+         guarantees that in addition to knowing the name servers for the
+         ISI.EDU domain, the addresses of the servers are known as well.
+
+         The TTLs for the NS RRs that delegate the ISI.EDU domain and
+         the A RRs that represent the addresses of the name servers are
+         all the same.  This guarantees that all of these RRs will
+         timeout simultaneously.  In this example, the value 10000 has
+         no special significance, but the coincidence of the TTLs is
+         significant.
+
+      These guidelines haven't changed any of the flexibility of the
+      system; the name of a name server and the domains it serves are
+      still independent.
+
+      It might also be the case that the organization called ISI wanted
+      to take over management of the IN-ADDR domain for an internal
+      network, say 128.99.0.0.  In this case, we would have additions to
+      the parent zone, say IN-ADDR.ARPA.
+
+      We might add the following to the parent zone:
+
+       99.128.IN-ADDR.ARPA. 2000 NS  Q.ISI.EDU.               
+                            2000 NS  XX.MIT.EDU.              
+       Q.ISI.EDU.           2000 A   <address of Q.ISI.EDU.>  
+       XX.MIT.EDU.          2000 A   <address of XX.MIT.EDU.> 
+
+      and the following to the child zone:
+
+       99.128.IN-ADDR.ARPA. 2000 NS  Q.ISI.EDU.               
+                            2000 NS  XX.MIT.EDU.              
+                            5000 SOA <SOA information>        
+       Q.ISI.EDU.           2000 A   <address of Q.ISI.EDU.>  
+       XX.MIT.EDU.          2000 A   <address of XX.MIT.EDU.> 
+
+   SOA serials
+
+      The serial field of the SOA RR for a domain is supposed to be a
+      continuously increasing (mod 2**32) value which denotes the
+
+
+
+
+Mockapetris                                                     [Page 7]
+
+
+
+RFC 973                                                     January 1986
+Domain System Changes and Observations
+
+
+      version of the database.  The idea is that you can tell that a
+      zone has changed by comparing serial numbers.  When you change a
+      zone, you should increment the serial field of the SOA.
+
+   All RRs with the same name, class, and type should have the same TTL.
+
+      The logic here is that all of them will timeout simultaneously if
+      cached and hence the cache can be reliably used.
+
+   Case consistency
+
+      The domain system is supposed to preserve case, but be case
+      insensitive.  However, it does nobody any good to put both RRs for
+      domain name xxx and XXX in the data base - It merely makes caching
+      ambiguous and decreases the efficiency of compression.  This
+      consistency should also exist in the duplicate RRs that mark
+      delegation in the delegator and delegatee.  For example, if you
+      ask the NIC to delegate UZOO.EDU to you, your database shouldn't
+      say uzoo.edu.
+
+   Inappropriate use of aliases
+
+      Canonical names are preferred to aliases in all RRs.  One reason
+      is that the canonical names are closer to the information
+      associated with a name.  A second is that canonical names are
+      unique, and aliases are not, and hence comparisons will work.
+
+      In particular, the use of aliases in PTR RRs of the IN-ADDR domain
+      or in NS RRs that mark delegation is discouraged.
+
+EXPERIENCES
+
+   This section discusses some unusual situations and common bugs which
+   are encountered in the present system, and should be helpful in
+   problem determination and tuning.  Put differently, you should try to
+   make your code defend against these attacks, and you should expect to
+   be the object of complaint if you make these attacks.
+
+   UDP addresses
+
+      When you send a query to a host with multiple addresses, you might
+      expect the response to be from the address to which you sent the
+      query.  This isn't the case with almost all UNIX implementations.
+
+
+
+
+
+
+Mockapetris                                                     [Page 8]
+
+
+
+RFC 973                                                     January 1986
+Domain System Changes and Observations
+
+
+   UDP checksums
+
+      Many versions of UNIX generate incorrect UDP checksums, and most
+      ignore the checksum of incoming UDP datagrams.  The typical
+      symptom is that your UNIX domain code works fine with other
+      UNIXes, but won't communicate with TOPS-20 or other systems.
+      (JEEVES, the TOPS-20 server used for 3 of the 4 root servers,
+      ignores datagrams with bad UDP checksums.)
+
+   Making up data
+
+      There are lots of name servers which return RRs for the root
+      servers with 99999999 or similar large values in the TTL.  For
+      example, some return RRs that suggest that ISIF is a root server.
+      (It was months ago, but is no longer.)
+
+      One of the main ideas of the domain system is that everybody can
+      get a chunk of the name space to manage as they choose.  However,
+      you aren't supposed to lie about other parts of the name space.
+      Its OK to remember about other parts of the name space for caching
+      or other purposes, but you are supposed to follow the TTL rules.
+
+      Now it may be that you put such records in your server or whatever
+      to ensure a server of last resort.  That's fine.  But if you
+      export these in answers to queries, you should be shot.  These
+      entries get put in caches and never die.
+
+      Suggested domain meta-rule:
+
+         If you must lie, lie only to yourself.
+
+PROBLEM AREAS
+
+   This section discusses some shortcomings in the present system which
+   may be addressed in future versions.
+
+   Compression and types
+
+      The present specification attempts to allow name servers and
+      resolvers to cache RRs for classes they don't "understand" as well
+      as to allow compression of domain names to minimize the size of
+      UDP datagrams.  These two goals conflict in the present scheme
+      since the only way to expand a compressed name is to know that a
+      name is expected in that position.
+
+      One technique for addressing this problem would be to preface
+      binary data (i.e. anything but a domain name) with a length octet.
+
+
+Mockapetris                                                     [Page 9]
+
+
+
+RFC 973                                                     January 1986
+Domain System Changes and Observations
+
+
+      The high order two bits of the length octet could contain either
+      01 or 10, which are illegal for domain names.  To compensate for
+      the additional bytes of data, we could omit the RDATA length field
+      and terminate each RR with a binary length field of zero.
+
+   Caching non-existent names
+
+      In the present system, a resolver has no standard method for
+      caching the result that a name does not exist, which seems to make
+      up a larger than expected percentage of queries.  Some resolvers
+      create "does not exist" RRs with TTLs to guarantee against
+      repetitive queries for a non-existent name.
+
+      A standard technique might be to return the SOA RR for the zone
+      (note that only authoritative servers can say name does not exist)
+      in the reply, and define the semantics to be that the requester is
+      free to assume that the name does not exist for a period equal to
+      the MINIMUM field of the SOA.
+
+   Cache conflicts
+
+      When a resolver is processing a reply, it may well decide to cache
+      all RRs found in sections of the reply.  The problem is that the
+      resolver's cache may already contain a subset of these RRs,
+      probably with different TTLs.
+
+      If the RRs are from authoritative data in the answer section, then
+      the cache RRs should be replaced.  In other cases, the correct
+      strategy isn't completely clear.  Note that if the authoritative
+      data's TTL has changed, then the resolver doesn't have enough
+      information to make the correct decision in all cases.
+
+      This issue is tricky, and deserves thought.
+
+REFERENCES
+
+   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+        RFC-882, USC Information Sciences Institute, November 1983.
+
+   [2]  Mockapetris, P., "Domain Names - Implementation and
+        Specification", RFC-883, USC Information Sciences Institute,
+        November 1983.
+
+   [3]  Partridge, C., "Mail Routing and the Domain System", RFC-974,
+        CSNET-CIC, BBN Laboratories, January 1986.
+
+
+
+
+Mockapetris                                                    [Page 10]
+