rfc882.txt

中、英文RFC文档大全打包下载完全版 .

       +----------+--------+--------+----------------------------+

      These records mean that mail for F.ISI.ARPA can either be
      delivered to the host F.ISI.ARPA or forwarded to B.ISI.ARPA, which
      will accept responsibility for its eventual delivery.  In
      principle, an additional name lookup is required to map the domain
      name of the host to the appropriate address, in practice this
      information is usually returned in the response to the mail query.

      The SOA and NS types of resource records are used to define limits


Mockapetris                                                    [Page 10]


RFC 882                                                    November 1983
                                  Domain Names - Concepts and Facilities


      of authority.  The domain name given by the owner field of a SOA
      record is the start of a zone; the domain name given by the owner
      field of a NS record identifies a point in the name space where
      authority has been delegated, and hence marks the zone boundary.
      Except in the case where a name server delegates authority to
      itself, the SOA identifies the top limit of authority, and NS
      records define the first name outside of a zone.  These resource
      records have a standard format for all of the name space:

      +----------+--------+--------+-----------------------------+
      | <owner>  |   SOA  | <class>|       <domain name, etc>    |
      +----------+--------+--------+-----------------------------+
                                    
      +----------+--------+--------+-----------------------------+
      | <owner>  |   NS   | <class>|       <domain name>         |
      +----------+--------+--------+-----------------------------+

      The SOA record marks the start of a zone when it is present in a
      database; the NS record both marks the end of a zone started by an
      SOA (if a higher SOA is present) and also points to a name server
      that has a copy of the zone specified by the <owner. field of the
      NS record.

      The <domain name, etc> in the SOA record specifies the original
      source of the information in the zone and other information used
      by name servers to organize their activities.  SOA records are
      never cached (otherwise they would create false zones); they can
      only be created in special name server maintenance operations.

      The NS record says that a name server which is authoritative for
      records of the given CLASS can be found at <domain name>.

   Queries

      Queries to a name server must include a domain name which
      identifies the target resource set (QNAME), and the type and class
      of desired resource records.  The type and class fields in a query
      can include any of the corresponding type and class fields that
      are defined for resource records; in addition, the query type
      (QTYPE) and query class (QCLASS) fields may contain special values
      that match more than one of the corresponding fields in RRs.

      For example, the QTYPE field may contain:

         MAILA - matches all mail agent RRs (e.g. MD and MF).

         *     - matches any RR type.




Mockapetris                                                    [Page 11]


RFC 882                                                    November 1983
                                  Domain Names - Concepts and Facilities


      The QCLASS field may contain:

         *    - matches any RR class.

      Using the query domain name, QTYPE, and QCLASS, the name server
      looks for matching RRs.  In addition to relevant records, the name
      server may return RRs that point toward a name server that has the
      desired information or RRs that are expected to be useful in
      interpreting the relevant RRs.  For example a name server that
      doesn't have the requested information may know a name server that
      does; a name server that returns a domain name in a relevant RR
      may also return the RR that binds that domain name to an address.

      Note that the QCLASS=* construct requires special interpretation
      regarding authority.  Since a name server may not know all of the
      classes available in the domain system, it can never know if it is
      authoritative for all classes.  Hence responses to QCLASS=*
      queries can never be authoritative.

   Example space

      For purposes of exposition, the following name space is used for
      the remainder of this memo:

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











Mockapetris                                                    [Page 12]


RFC 882                                                    November 1983
                                  Domain Names - Concepts and Facilities


NAME SERVERS

   Introduction

      Name servers store a distributed database consisting of the
      structure of the domain name space, the resource sets associated
      with domain names, and other information used to coordinate
      actions between name servers.

      In general, a name server will be an authority for all or part of
      a particular domain.  The region covered by this authority is
      called a zone.  Name servers may be responsible for no
      authoritative data, and hence have no zones, or may have several
      zones.  When a name server has multiple zones, the zones may have
      no common borders or zones may be contiguous.

      While administrators should not construct overlapping zones, and
      name servers must defend against overlapping zones, overlapping is
      regarded as a non-fatal flaw in the database.  Hence the measures
      taken to protect against it are omitted for the remainder of this
      memo.  A detailed discussion can be found in [14].

      When presented with a query for a domain name over which it has
      authority, a name server returns the desired resource information
      or an indication that the query refers to a domain name or
      resource that does not exist.  If a name server is presented with
      a query for a domain name that is not within its authority, it may
      have the desired information, but it will also return a response
      that points toward an authoritative name server.  If a name server
      is not an authority for a query, it can never return a negative
      response.

      There is no requirement that a name server for a domain reside in
      a host which has a name in the same domain, although this will
      usually be the case.  There is also no restriction on the number
      of name servers that can have authority over a particular domain;
      most domains will have redundant authoritative name servers.  The
      assumption is that different authoritative copies are identical,
      even though inconsistencies are possible as updates are made.

      Name server functions are designed to allow for very simple
      implementations of name servers.  The simplest name server has a
      static set of information and uses datagrams to receive queries
      and return responses.

      More sophisticated name server implementations can improve the
      performance of their clients by caching information from other
      domains.  Although this information can be acquired in a number of
      ways, the normal method is to store the information acquired by a


Mockapetris                                                    [Page 13]


RFC 882                                                    November 1983
                                  Domain Names - Concepts and Facilities


      resolver when the resolver consults other name servers.  In a
      sophisticated host, the resolver and name server will coordinate
      their actions and use a shared database.  This cooperation
      requires the incorporation of a time-to-live (TTL) field in all
      cached resource records.  Caching is discussed in the resolver
      section of this memo; this section is devoted to the actions of a
      name servers that don't cache.

      In order to free simple name servers of the requirement of
      managing these timeouts, simple name servers should only contain
      resource records that are expected to remain constant over very
      long periods or resource records for which the name server is an
      authority.  In the following discussion, the TTL field is assumed
      to be stored in the resource record but is omitted in descriptions
      of databases and responses in the interest of clarity.

   Authority and administrative control of domains

      Although we want to have the potential of delegating the
      privileges of name space management at every node, we don't want
      such delegation to be required.

      Hence we introduce the concept of authority.  Authority is vested
      in name servers.  A name server has authority over all of its
      domain until it delegates authority for a subdomain to some other
      name server.

      Any administrative entity that wishes to establish its own domain
      must provide a name server, and have that server accepted by the
      parent name server (i.e. the name server that has authority over
      the place in the domain name space that will hold the new domain).
      While the principles of authority allow acceptance to be at the
      discretion of parent name servers, the following criteria are used
      by the root, and are recommended to all name servers because they
      are responsible for their children's actions:

         1.  It must register with the parent administrator of domains.

         2.  It must identify a responsible person.

         3.  In must provide redundant name servers.

      The domain name must be registered with the administrator to avoid
      name conflicts and to make the domain related information
      available to other domains.  The central administrator may have
      further requirements, and a domain is not registered until the
      central administrator agrees that all requirements are met.

      There must be a responsible person associated with each domain to


Mockapetris                                                    [Page 14]


RFC 882                                                    November 1983
                                  Domain Names - Concepts and Facilities


      be a contact point for questions about the domain, to verify and
      update the domain related information, and to resolve any problems
      (e.g., protocol violations) with hosts in the domain.

      The domain must provide redundant (i.e., two or more) name servers
      to provide the name to address resolution service.  These name
      servers must be accessible from outside the domain (as well as
      inside) and must resolve names for at least all the hosts in the
      domain.

      Once the central administrator is satisfied, he will communicate
      the existence to the appropriate administrators of other domains
      so that they can incorporate NS records for the new name server
      into their databases.

   Name server logic

      The processing steps that a name server performs in responding to
      a query are conceptually simple, although implementations may have
      internal databases that are quite complex.

      For purposes of explanation, we assume that the query consists of
      a type QTYPE, a class QCLASS, and a domain name QNAME; we assume
      that the name server stores its RRs in sets where each set has all
      of the RRs for a particular domain.  Note that this database
      structure and the following algorithms are meant to illustrate one
      possible implementation, rather than a specification of how all
      servers must be implemented.

      The following notation is used:

      ord(DOMAIN-NAME)     returns the number of labels in DOMAIN-NAME.