rfc883.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,582 行 · 第 1/5 页

      +---------+ |             +----------+         |  +--------+
      |         | |             |          |responses|  |        |
      |         | |             |   Name   |---------|->|Foreign |
      |  Master |-------------->|  Server  |         |  |Resolver|
      |  files  | |             |          |<--------|--|        |
      |         |/              |          | queries |  +--------+
      +---------+               +----------+         |            
                                  A     |maintenance |  +--------+
                                  |     \------------|->|        |
                                  |      queries     |  |Foreign |
                                  |                  |  |  Name  |
                                  \------------------|--| Server |
                               maintenance responses |  +--------+

      The shared database holds domain space data for the local name
      server and resolver.  The contents of the shared database will
      typically be a mixture of authoritative data maintained by the
      periodic refresh operations of the name server and cached data
      from previous resolver requests.  The structure of the domain data
      and the necessity for synchronization between name servers and
      resolvers imply the general characteristics of this database, but
      the actual format is up to the local implementer.  This memo
      suggests a multiple tree format.






Mockapetris                                                     [Page 4]


RFC 883                                                    November 1983
                         Domain Names - Implementation and Specification


      This memo divides the implementation discussion into sections:

         NAME SERVER TRANSACTIONS, which discusses the formats for name
         servers queries and the corresponding responses.

         NAME SERVER MAINTENANCE, which discusses strategies,
         algorithms, and formats for maintaining the data residing in
         name servers.  These services periodically refresh the local
         copies of zones that originate in other hosts.

         RESOLVER ALGORITHMS, which discusses the internal structure of
         resolvers.  This section also discusses data base sharing
         between a name server and a resolver on the same host.

         DOMAIN SUPPORT FOR MAIL, which discusses the use of the domain
         system to support mail transfer.



































Mockapetris                                                     [Page 5]


RFC 883                                                    November 1983
                         Domain Names - Implementation and Specification


   Conventions

      The domain system has several conventions dealing with low-level,
      but fundamental, issues.  While the implementer is free to violate
      these conventions WITHIN HIS OWN SYSTEM, he must observe these
      conventions in ALL behavior observed from other hosts.

             ********** Data Transmission Order **********

      The order of transmission of the header and data described in this
      document is resolved to the octet level.  Whenever a diagram shows
      a group of octets, the order of transmission of those octets is
      the normal order in which they are read in English.  For example,
      in the following diagram the octets are transmitted in the order
      they are numbered.

                                    
                    0                   1           
                    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |       1       |       2       |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |       3       |       4       |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |       5       |       6       |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Transmission Order of Bytes

      Whenever an octet represents a numeric quantity the left most bit
      in the diagram is the high order or most significant bit.  That
      is, the bit labeled 0 is the most significant bit.  For example,
      the following diagram represents the value 170 (decimal).

                                    
                            0 1 2 3 4 5 6 7 
                           +-+-+-+-+-+-+-+-+
                           |1 0 1 0 1 0 1 0|
                           +-+-+-+-+-+-+-+-+

                          Significance of Bits

      Similarly, whenever a multi-octet field represents a numeric
      quantity the left most bit of the whole field is the most
      significant bit.  When a multi-octet quantity is transmitted the
      most significant octet is transmitted first.





Mockapetris                                                     [Page 6]


RFC 883                                                    November 1983
                         Domain Names - Implementation and Specification


                  ********** Character Case **********

      All comparisons between character strings (e.g. labels, domain
      names, etc.) are done in a case-insensitive manner.

      When data enters the domain system, its original case should be
      preserved whenever possible.  In certain circumstances this cannot
      be done.  For example, if two domain names x.y and X.Y are entered
      into the domain database, they are interpreted as the same name,
      and hence may have a single representation.  The basic rule is
      that case can be discarded only when data is used to define
      structure in a database, and two names are identical when compared
      in a case insensitive manner.

      Loss of case sensitive data must be minimized.  Thus while data
      for x.y and X.Y may both be stored under x.y, data for a.x and B.X
      can be stored as a.x and B.x, but not A.x, A.X, b.x, or b.X.  In
      general, this prevents the first component of a domain name from
      loss of case information.

      Systems administrators who enter data into the domain database
      should take care to represent the data they supply to the domain
      system in a case-consistent manner if their system is
      case-sensitive.  The data distribution system in the domain system
      will ensure that consistent representations are preserved.


























Mockapetris                                                     [Page 7]


RFC 883                                                    November 1983
                         Domain Names - Implementation and Specification


   Design philosophy

      The design presented in this memo attempts to provide a base which
      will be suitable for several existing networks.  An equally
      important goal is to provide these services within a framework
      that is capable of adjustment to fit the evolution of services in
      early clients as well as to accommodate new networks.

      Since it is impossible to predict the course of these
      developments, the domain system attempts to provide for evolution
      in the form of an extensible framework.  This section describes
      the areas in which we expect to see immediate evolution.

      DEFINING THE DATABASE

      This memo defines methods for partitioning the database and data
      for host names, host addresses, gateway information, and mail
      support.  Experience with this system will provide guidance for
      future additions.

      While the present system allows for many new RR types, classes,
      etc., we feel that it is more important to get the basic services
      in operation than to cover an exhaustive set of information.
      Hence we have limited the data types to those we felt were
      essential, and would caution designers to avoid implementations
      which are based on the number of existing types and classes.
      Extensibility in this area is very important.

      While the domain system provides techniques for partitioning the
      database, policies for administrating the orderly connection of
      separate domains and guidelines for constructing the data that
      makes up a particular domain will be equally important to the
      success of the system.   Unfortunately, we feel that experience
      with prototype systems will be necessary before this question can
      be properly addressed.  Thus while this memo has minimal
      discussion of these issues, it is a critical area for development.

      TYING TOGETHER INTERNETS

      Although it is very difficult to characterize the types of
      networks, protocols, and applications that will be clients of the
      domain system, it is very obvious that some of these applications
      will cross the boundaries of network and protocol.  At the very
      least, mail is such a service.

      Attempts to unify two such systems must deal with two major
      problems:

      1. Differing formats for environment sensitive data.  For example,


Mockapetris                                                     [Page 8]


RFC 883                                                    November 1983
                         Domain Names - Implementation and Specification


         network addresses vary in format, and it is unreasonable to
         expect to enforce consistent conventions.

      2. Connectivity may require intermediaries.  For example, it is a
         frequent occurence that mail is sent between hosts that share
         no common protocol.

      The domain system acknowledges that these are very difficult
      problems, and attempts to deal with both problems through its
      CLASS mechanism:

      1. The CLASS field in RRs allows data to be tagged so that all
         programs in the domain system can identify the format in use.

      2. The CLASS field allows the requestor to identify the format of
         data which can be understood by the requestor.

      3. The CLASS field guides the search for the requested data.

      The last point is central to our approach.  When a query crosses
      protocol boundaries, it must be guided though agents capable of
      performing whatever translation is required.  For example, when a
      mailer wants to identify the location of a mailbox in a portion of
      the domain system that doesn't have a compatible protocol, the
      query must be guided to a name server that can cross the boundary
      itself or form one link in a chain that can span the differences.

      If query and response transport were the only problem, then this
      sort of problem could be dealt with in the name servers
      themselves.  However, the applications that will use domain
      service have similar problems.  For example, mail may need to be
      directed through mail gateways, and the characteristics of one of
      the environments may not permit frequent connectivity between name
      servers in all environments.

      These problems suggest that connectivity will be achieved through
      a variety of measures:

         Translation name servers that act as relays between different
         protocols.

         Translation application servers that translate application
         level transactions.

         Default database entries that route traffic through application
         level forwarders in ways that depend on the class of the
         requestor.

      While this approach seems best given our current understanding of