rfc882.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

      findset(DOMAIN-NAME) returns a pointer to the set of stored RRs
                           for DOMAIN-NAME, or NULL if there is no such
                           information.

      set(POINTER)         refers to a set located previously by
                           findset, where POINTER is the value returned
                           by findset.

      relevant(QTYPE,TYPE) returns true if a RR of the specified TYPE is
                           relevant to the specified QTYPE.  For
                           example, relevant(MAILA,MF) is true and
                           relevant(MAILA,NS) is false.

      right(NAME,NUMBER)   returns a domain name that is the rightmost
                           NUMBER labels in the string NAME.



Mockapetris                                                    [Page 15]


RFC 882                                                    November 1983
                                  Domain Names - Concepts and Facilities


      copy(RR)             copies the resource record specified by RR
                           into the response.

      The name server code could be represented as the following
      sequence of steps:

     {    find out whether the database makes this server          
          authoritative for the domain name specified by QNAME   } 

     for i:=0 to ord(QNAME) { sequence through all nodes in QNAME }
     do   begin                                                    
          ptr:=findset(right(QNAME,i));                            
          if ptr<>NULL                                             
          then { there is domain data for this domain name }       
               begin                                               
               for all RRs in set(ptr)                             
               do   if type(RR)=NS and class(RR)=QCLASS            
                    then begin                                     
                         auth=false;                               
                         NSptr:=ptr                                
                         end;                                      
               for all RRs in set(ptr)                             
               do   if type(RR)=SOA and class(RR)=QCLASS           
                    then auth:=true                                
                    end                                            
               end;                                                
           end;                                                    

      {    copy out authority search results }                     

      if auth                                                      
      then { if authority check for domain found }                 
           if ptr=null                                             
           then return(Name error)                                 
           else                                                    
      else { if not authority, copy NS RRs }                       
           for all RRs in set(nsptr)                               
           do   if (type(RR)=NS and class(RR)=QCLASS)              
                                 or                                
                              (QCLASS=*)                           
                then copy(RR);                                     

      {    Copy all RRs that answer the question }                 

      for all RRs in set(ptr)                                      
      do   if class(RR)=QCLASS and relevant(QTYPE,type(RR))        
           then copy(RR);                                          

      The first section of the code (delimited by the for loop over all


Mockapetris                                                    [Page 16]


RFC 882                                                    November 1983
                                  Domain Names - Concepts and Facilities


      of the subnodes of QNAME) discovers whether the name server is
      authoritative for the domain specified by QNAME.  It sequences
      through all containing domains of QNAME, starting at the root.  If
      it encounters a SOA it knows that the name server is authoritative
      unless it finds a lower NS RR which delegates authority.  If the
      name server is authoritative, it sets auth=true; if the name
      server is not authoritative, it sets NSptr to point to the set
      which contains the NS RR closest to the domain specified by QNAME.

      The second section of the code reflects the result of the
      authority search into the response.  If the name server is
      authoritative, the code checks to see that the domain specified by
      QNAME exists; if not, a name error is returned.  If the name
      server is not authoritative, the code copies the RRs for a closer
      name server into the response.

      The last section of the code copies all relevant RRs into the
      response.

      Note that this code is not meant as an actual implementation and
      is incomplete in several aspects.  For example, it doesn't deal
      with providing additional information, wildcards, QCLASS=*, or
      with overlapping zones.  The first two of these issues are dealt
      with in the following discussions, the remaining issues are
      discussed in [14].

   Additional information

      When a resolver returns information to a user program, the
      returned information will often lead to a second query.  For
      example, if a mailer asks a resolver for the appropriate mail
      agent for a particular domain name, the name server queried by the
      resolver returns a domain name that identifies the agent.  In
      general, we would expect that the mailer would then request the
      domain name to address binding for the mail agent, and a new name
      server query would result.

      To avoid this duplication of effort, name servers return
      additional information with a response which satisfies the
      anticipated query.  This information is kept in a separate section
      of the response.  Name servers are required to complete the
      appropriate additional information if such information is
      available, but the requestor should not depend on the presence of
      the information since the name server may not have it.  If the
      resolver caches the additional information, it can respond to the
      second query without an additional network transaction.

      The appropriate information is defined in [14], but generally



Mockapetris                                                    [Page 17]


RFC 882                                                    November 1983
                                  Domain Names - Concepts and Facilities


      consists of host to address bindings for domain names in returned
      RRs.

   Aliases and canonical names

      In existing systems, hosts and other resources often have several
      names that identify the same resource.  For example, under current
      ARPA Internet naming support, USC-ISIF and ISIF both identify the
      same host.  Similarly, in the case of mailboxes, many
      organizations provide many names that actually go to the same
      mailbox; for example Mockapetris@ISIF, Mockapetris@ISIB, etc., all
      go to the same mailbox (although the mechanism behind this is
      somewhat complicated).

      Most of these systems have a notion that one of the equivalent set
      of names is the canonical name and all others are aliases.

      The domain system provides a similar feature using the canonical
      name (CNAME) RR.  When a name server fails to find a desired RR in
      a set associated with some domain name, it checks to see if the
      resource set contains a CNAME record with a matching class.  If
      so, the name server includes the CNAME record in the response, and
      continues the query at the domain name specified in the data field
      of the CNAME record.

      Suppose a name server was processing a query with QNAME=ISIF.ARPA,
      QTYPE=A, and QCLASS=IN, and had the following resource records:

            ISIF.ARPA     CNAME   IN     F.ISI.ARPA         
            F.ISI.ARPA    A       IN     10.2.0.52          

      Both of these RRs would be returned in the response.

      In the above example, because ISIF.ARPA has no RRs other than the
      CNAME RR, the resources associated with ISIF.ARPA will appear to
      be exactly those associated with F.ISI.ARPA for the IN CLASS.
      Since the CNAME is effective only when the search fails, a CNAME
      can also be used to construct defaults.  For example, suppose the
      name server had the following set of RRs:

            F.ISI.ARPA    A       IN     10.2.0.52          
            F.ISI.ARPA    MD      IN     F.ISI.ARPA         
            XXXX.ARPA     CNAME   IN     F.ISI.ARPA         
            XXXX.ARPA     MF      IN     A.ISI.ARPA         

      Using this database, type A queries for XXXX.ARPA would return the
      XXXX.ARPA CNAME RR and the F.ISI.ARPA A RR, but MAILA or MF
      queries to XXXX.ARPA would return the XXXX.ARPA MF RR without any
      information from F.ISI.ARPA.  This structure might be used to send


Mockapetris                                                    [Page 18]


RFC 882                                                    November 1983
                                  Domain Names - Concepts and Facilities


      mail addressed to XXXX.ARPA to A.ISI.ARPA and to direct TELNET for
      XXXX.ARPA to F.ISI.ARPA.

   Wildcards

      In certain cases, an administrator may wish to associate default
      resource information for all or part of a domain.  For example,
      the CSNET domain administrator may wish to establish IN class mail
      forwarding for all hosts in the CSNET domain without IN
      capability.  In such a case, the domain system provides a special
      label "*" that matches any other label.  Note that "*" matches
      only a single label, and not zero or more than one label.  Note
      also that the "*" is distinct from the "*" values for QCLASS and
      QTYPE.

      The semantics of "*" depend upon whether it appears in a query
      domain name (QNAME) or in a RR in a database.

         When an "*" is used in a QNAME, it can only match a "*" in a
         resource record.

         When "*" appears in a RR in a database, it can never override
         an existing exact match.  For example, if a name server
         received a query for the domain UDEL.CSNET, and had appropriate
         RRs for both UDEL.CSNET and *.CSNET, the UDEL.CSNET RRs would
         be used and the *.CSNET RRs would be ignored.  If a query to
         the same database specified FOO.CSNET, the *.CSNET RR would be
         used, but the corresponding labels from the QNAME would replace
         the "*".  Thus the FOO.CSNET query would match the *.CSNET RR
         and return a RR for FOO.CSNET rather than *.CSNET.

         RRs containing "*" labels are copied exactly when zones are
         transfered via name server maintenance operations.

      These semantics are easily implemented by having the name server
      first search for an exact match for a query, and then replacing
      the leftmost label with a "*" and trying again, repeating the
      process until all labels became "*" or the search succeeded.

      TYPE=* in RRs is prohibited.  If it were to be allowed, the
      requestor would have no way of interpreting the data in the RR
      because this data is type dependent.

      CLASS=* is also prohibited.  Similar effects can be achieved using
      QCLASS=*, and allowing both QCLASS=* and CLASS=* leads to
      complexities without apparent benefit.





Mockapetris                                                    [Page 19]


RFC 882                                                    November 1983
                                  Domain Names - Concepts and Facilities


   A scenario

      In our sample domain space, suppose we wanted separate
      administrative control for the root, DDN, ARPA, CSNET, MIT and ISI
      domains.  We might allocate name servers as follows:

                                   |(B.ISI.ARPA)                  
                                   |(UDEL.CSNET)                  
                +------------------+------------------+           
                |                  |                  |           
               DDN               ARPA               CSNET         
                |(JCS.DDN)         |(F.ISI.ARPA)      |(UDEL.ARPA)
          +-----+-----+            |(A.ISI.ARPA)+-----+-----+     
          |     |     |            |            |           |     
         JCS  ARMY  NAVY           |           UDEL        UCI    
                                   |                              
          +--------+---------------+---------------+--------+     
          |        |               |               |        |     
         DTI      MIT             ISI             UDEL     NBS    
                   |(AI.MIT.ARPA)  |(F.ISI.ARPA)                  
               +---+---+       +---+---+                          
               |       |       |   |   |                          
              DMS     AI       A   B   F                          

      In this example the authoritative name server is shown in