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



 

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




 

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