rfc881.txt

RFC 相关的技术文档

Network Working Group                                          J. Postel
Request for Comments: 881                                            ISI
                                                           November 1983



                   The Domain Names Plan and Schedule

This RFC outlines a plan and schedule for the implementation of domain
style names throughout the DDN/ARPA Internet community.  The
introduction of domain style names will impact all hosts on the DDN/ARPA
Internet.

The Plan

   Introduction

      Domain style names are being introduced in the Internet to allow a
      controlled delegation of the authority and responsibility for
      adding hosts to the system.  This also allows a subdivision of the
      task of maintaining information about hosts.

      The subdivision will be based on administrative authority or
      organization boundaries (not necessarily network boundaries).
      Certain requirements will be placed on organizations wishing to be
      "top level" domains.  Initially, all the hosts in the Internet
      will be in the domain "ARPA".  As soon as is practical a second
      domain, "DDN", will be introduced.  Other domains may be added
      after that, provided the requirements listed below are met.

      Domain names will be supported in the long run by a system of
      special servers called "domain servers" which will be used to
      translate names to addresses.  While this system of domain servers
      is being created and programs are being converted to use them, the
      existing host tables will evolve to include domain style names.

      The domain server design also provides for mapping mailbox
      addresses to the host name of the mail server for that mailbox.
      This feature allows mailboxes to be related to an organization
      rather than to a specific host.

      This plan will be implemented in the ARPA community.  After the
      domain system is demonstrated in the ARPA community, the DDN
      Program Management Office (DDN-PMO) will determine the schedule
      for implementation of the domain system in the DDN community.
      This approach will cause some extra steps in the ARPA community
      implementation, and may limit communication between the ARPA and
      DDN communities in some ways.  The details and implications of
      this two phase approach are discussed more fully below.





Postel                                                          [Page 1]



RFC 881                                                    November 1983
The Domain Names Plan and Schedule                                      


   A Catch 22

      There is a problem in introducing domain style names: a great deal
      of software has to be changed.  Some groups would like to start
      using domain style names right away, and other groups don't want
      to see them or use them for a very long time.  Communication
      patterns are very complex and as soon as domain style names are
      allowed and used by a few groups they will start showing up almost
      everywhere.  This argues that everyone should be prepared for them
      before they are used at all.  However, we know that with people
      being people and with so many of people involved, the probability
      of everyone being ready in any reasonable time period is nearly
      zero.  The way out of this situation is to set up a reasonable
      schedule for experimenting with domain style names and authorizing
      their use.  People that get ready on schedule should have no
      problems with these names.

   Evolution of the Table

      Nearly all the hosts in the Internet now use some form of host
      table based on the master file "HOSTS.TXT" maintained by the
      Network Information Center (NIC).

      One way to introduce domain style names is to add to the entries
      in this table names in the domain style.  In particular, make the
      first name in each entry the official host name in the ARPA
      domain.

         For example, the current entry for USC-ISIF is:

            HOST : 10.2.0.52 : USC-ISIF,ISIF : DEC-1090T : TOPS20 :
            TCP/TELNET,TCP/SMTP,TCP/FTP,TCP/FINGER,UDP/TFTP :

         This could become:

            HOST : 10.2.0.52 : USC-ISIF.ARPA,USC-ISIF,ISIF : DEC-1090T :
            TOPS20 : TCP/TELNET,TCP/SMTP,TCP/FTP,TCP/FINGER,UDP/TFTP :

      For some hosts and programs this could be done today with no
      disruptions, but for others substantial problems could occur.  For
      example, with over five hundred entries in the table the addition
      of 500 names could exceed the space allocated to store the table
      in some programs.  (One could argue that these programs are going
      to blow up soon anyway as new host entries are added to the
      table.)  Another problem is that period (or dot, ".") is not now a
      legal character in host names and some programs may not be able to
      parse these new names.



Postel                                                          [Page 2]



RFC 881                                                    November 1983
The Domain Names Plan and Schedule                                      


      The plan is to make such a domain style name table available in
      parallel with the regular table for a few months, then to replace
      the regular table with this domain style table.  The dates for
      these changes is given in the schedule below.

      So far, no new domains have been introduced.  Only a table with
      all the entries having official names in the ARPA domain has been
      provided.  This should allow programs to be constructed to deal
      with domain style names in a general way without any special hacks
      to add or delete the string ".ARPA" to or from host names.

      The introduction of new domains is tied to the provision of domain
      servers by those domains.  As new domains meet the requirements
      and are authorized they will also be added to the host table.  No
      new domains will be added before master table is converted to the
      domain style entries.

      In the long run the Internet will become too complex and change
      too fast to keep a master table of all the hosts.  At some point
      the master table will be reduced to simply the entries for the
      domain servers for the top level domains.  By this time all normal
      translation of host names into addresses should take place by
      consulting domain servers.

   Conversion to Servers

      As soon as domain servers become available programs should be
      converted to use them to translate names into addresses.  The
      details of these procedures are given in RFCs 882 and 883.

      The general idea is that a host no longer keeps a complete host
      table but rather makes a request on the domain server each time a
      name must be translated to an address.  The code module in the
      host that implements the protocol to do this is called a
      "resolver".  The resolver may keep a cache of recently translated
      names and addresses for improved performance.

      Many hosts have a library function or system call that is used to
      access the host table to translate names to addresses.  It ought
      to be possible to replace this function or call with the resolver
      module such that most programs would not know which method was
      used to accomplish the name to address translation.








Postel                                                          [Page 3]



RFC 881                                                    November 1983
The Domain Names Plan and Schedule                                      


   Requirements on a Domain

      There are several requirements that must be met to establish a
      domain.  In general it must be responsibly managed.  There must be
      a responsible person to serve as a coordinator for domain related
      questions,  there must be a robust name service, it must be of at
      least a minimum size,  and the domain must be registered with the
      central domain administrator.

      Responsible Person:

         An individual must be identified who has authority for the
         administration of the names within the domain, and who takes
         responsibility for the behavior of the hosts in the domain in
         their interactions with hosts outside the domain.

         The operation of a name server should not be taken on lightly.
         There are some difficult problems in providing an adequate
         service, primarily the problems in keeping the data base up to
         date, and keeping the service operating.

         If some host in a domain somehow misbehaves in interactions
         with hosts outside the domain (e.g., consistently violates
         protocols), the responsible person for the domain must be able
         to take action to eliminate the problem.

      Domain Servers:

         A robust and reliable domain service must be provided.  One way
         of meeting this requirement is to provide at least two
         independent domain servers for the domain.  The data base can,
         of course, be the same.  The database can be prepared and
         copied to each domain server.  But, the servers should be in
         separate machines on independent power supplies, et cetera;
         basically as physically independent as can be and yet in the
         same domain.  They should have no common point of failure.

         One of the difficult problems in operating a domain server is
         the acquisition and maintenance of the data.  In this case the
         data is the host names and addresses.  In some environments
         this information changes fairly rapidly and keeping up-to-date
         data may be difficult.  This is one motivation for sub-domains.
         One may wish to create sub-domains until the rate of change of
         the data in a sub-domain domain server data base is easily
         managed.

         The concepts and implementation details of the domain server
         are given in RFCs 882 and 883.


Postel                                                          [Page 4]



RFC 881                                                    November 1983
The Domain Names Plan and Schedule                                      


      Minimum Size:

         The domain must be of at least a minimum size.  Several
         measures of size may be used in combination in making this
         test.  Measures may include: (a) the number of host computers
         in the domain, (b) the number of people with primary mailboxes
         in the domain, (c) the amount of traffic that crosses the
         boundary of the domain [packets/day or mail items/week].
         Specific threshold values for these measures will be
         established before new domains are authorized.

         There is no requirement to form a domain because some set of
         hosts is above the minimum size.

      Registration:

         The administrator must register the domain with the central
         authority.  The central authority must be satisfied that the
         requirements are met before authorization for the domain is
         granted.

         The administrator of a domain is required to make sure that
         host and sub-domain names within that jurisdiction conform to
         the standard name conventions and are unique with in that
         domain.

         If sub-domains are set up the administrator may wish to pass
         along some of his authority and responsibility to a sub-domain
         administrator.

   Mailbox Support

      The design of the domain servers provides two levels of support
      for mail.

      The first, called "agent binding", is that the right hand part of
      the typical mail box (Y in X@Y) can be mapped a host that will
      either accept the mail as the destination or accept the mail for
      forwarding.

      The second, called "mailbox binding", is to map the entire mailbox
      (X@Y) to a destination (this mechanism can also support some
      mailing list functions).

      Agent binding can be used to establish mailboxes that are based on
      an organization name rather than a host name.

         For example, an organization, "BLAT", with hosts "BLAT-20" and


Postel                                                          [Page 5]