rfc920.txt

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

RFC 920                                                     October 1984
Domain Requirements


      ORG  =  Organization

         Administrator:  DARPA
         Agent:          The Network Information Center
         Mailbox:        [e-mail]

      Countries

         The English two letter code (alpha-2) identifying a country
         according the the ISO Standard for "Codes for the
         Representation of Names of Countries" [5].

         As yet no country domains have been established.  As they are
         established information about the administrators and agents
         will be made public, and will be listed in subsequent editions
         of this memo.

      Multiorganizations

         A multiorganization may be a top level domain if it is large,
         and is composed of other organizations; particularly if the
         multiorganization can not be easily classified into one of the
         categories and is international in scope.

         As yet no multiorganization domains have been established.  As
         they are established information about the administrators and
         agents will be made public, and will be listed in subsequent
         editions of this memo.

      Note:  The NIC is listed as the agent and registrar for all the
      currently allowed top level domains.  If there are other entities
      that would be more appropriate agents and registrars for some or
      all of these domains then it would be desirable to reassign the
      responsibility.

Second Level Domain Requirements

   Each top level domain may have many second level domains.  Every
   second level domain must meet the general requirements on a domain
   specified above, and be registered with a top level domain
   administrator.








Postel & Reynolds                                               [Page 8]



RFC 920                                                     October 1984
Domain Requirements


Third through Nth Level Domain Requirements

   Each second level domain may have many third level domains, etc.
   Every third level domain (through Nth level domain) must meet the
   requirements set by the administrator of the immediately higher level
   domain.  Note that these may be more or less strict than the general
   requirements.  One would expect the minimum size requirements to
   decrease at each level.

The ARPA Domain

   At the time the implementation of the domain concept was begun it was
   thought that the set of hosts under the administrative authority of
   DARPA would make up a domain.  Thus the initial domain selected was
   called ARPA.  Now it is seen that there is no strong motivation for
   there to be a top level ARPA domain.  The plan is for the current
   ARPA domain to go out of business as soon as possible.  Hosts that
   are currently members of the ARPA domain should make arrangements to
   join another domain.  It is likely that for experimental purposes
   there will be a second level domain called ARPA in the ORG domain
   (i.e., there will probably be an ARPA.ORG domain).

The DDN Hosts

   DDN hosts that do not desire to participate in this domain naming
   system will continue to use the HOSTS.TXT data file maintained by the
   NIC for name to address translations.  This file will be kept up to
   date for the DDN hosts.  However, all DDN hosts will change their
   names from "host.ARPA" to (for example) "host.DDN.MIL" some time in
   the future.  The schedule for changes required in DDN hosts will be
   established by the DDN-PMO.

Impact on Hosts

   What is a host administrator to do about all this?

      For existing hosts already operating in the ARPA-Internet, the
      best advice is to sit tight for now.  Take a few months to
      consider the options, then select a domain to join.  Plan
      carefully for the impact that changing your host name will have on
      both your local users and on their remote correspondents.

      For a new host, careful thought should be given (as discussed
      below).  Some guidance can be obtained by comparing notes on what
      other hosts with similar administrative properties have done.

   The owner of a host may decide which domain to join, and the


Postel & Reynolds                                               [Page 9]



RFC 920                                                     October 1984
Domain Requirements


   administrator of a domain may decide which hosts to accept into his
   domain.  Thus the owner of a host and a domain administrator must
   come to an understanding about the host being in the domain.  This is
   the foundation of responsible administration.

      For example, a host "XYZ" at MIT might possible be considered as a
      candidate for becoming any of XYZ.ARPA.ORG, XYZ.CSNET, or
      XYZ.MIT.EDU.

         The owner of host XYZ may choose which domain to join,
         depending on which domain administrators are willing to have
         him.

   The domain is part of the host name.  Thus if USC-ISIA.ARPA changes
   its domain affiliation to DDN.MIL to become USC-ISIA.DDN.MIL, it has
   changed its name.  This means that any previous references to
   USC-ISIA.ARPA are now out of date.  Such old references may include
   private host name to address tables, and any recorded information
   about mailboxes such as mailing lists, the headers of old messages,
   printed directories, and peoples' memories.

   The experience of the DARPA community suggests that changing the name
   of a host is somewhat painful.  It is recommended that careful
   thought be given to choosing a new name for a host - which includes
   selecting its place in the domain hierarchy.

The Roles of the Network Information Center

   The NIC plays two types of roles in the administration of domains.
   First,  the NIC is the registrar of all top level domains.  Second
   the NIC is the administrator of several top level domains (and the
   registrar for second level domains in these).

   Top Level Domain Registrar

      As the registrar for top level domains, the NIC is the contact
      point for investigating the possibility of establishing a new top
      level domain.

   Top Level Domain Administrator

      For the top level domains designated so far, the NIC is the
      administrator of each of these domains.  This means the NIC is
      responsible for the management of these domains and the
      registration of the second level domains or hosts (if at the
      second level) in these domains.



Postel & Reynolds                                              [Page 10]



RFC 920                                                     October 1984
Domain Requirements


      It may be reasonable for the administration of some of these
      domains to be taken on by other authorities in the future.  It is
      certainly not desired that the NIC be the administrator of all top
      level domains forever.

Prototypical Questions

   To establish a domain, the following information must be provided to
   the NIC Domain Registrar ([e-mail]):

      Note:  The key people must have computer mail mailboxes and
      NIC-Idents.  If they do not at present, please remedy the
      situation at once.  A NIC-Ident may be established by contacting
      [e-mail].

   1)  The name of the top level domain to join.

      For example:  EDU

   2)  The name, title, mailing address, phone number, and organization
   of the administrative head of the organization.  This is the contact
   point for administrative and policy questions about the domain.  In
   the case of a research project, this should be the Principal
   Investigator.  The online mailbox and NIC-Ident of this person should
   also be included.

      For example:

         Administrator

            Organization  USC/Information Sciences Institute
            Name          Keith Uncapher
            Title         Executive Director
            Mail Address  USC/ISI
                          4676 Admiralty Way, Suite 1001
                          Marina del Rey, CA. 90292-6695
            Phone Number  213-822-1511
            Net Mailbox   [e-mail]
            NIC-Ident     KU

   3)  The name, title, mailing address, phone number, and organization
   of the domain technical contact.  The online mailbox and NIC-Ident of
   the domain technical contact should also be included.  This is the
   contact point for problems with the domain and for updating
   information about the domain.  Also, the domain technical contact may
   be responsible for hosts in this domain.



Postel & Reynolds                                              [Page 11]



RFC 920                                                     October 1984
Domain Requirements


      For example:

         Technical Contact

            Organization  USC/Information Sciences Institute
            Name          Craig Milo Rogers
            Title         Researcher
            Mail Address  USC/ISI
                          4676 Admiralty Way, Suite 1001
                          Marina del Rey, CA. 90292-6695
            Phone Number  213-822-1511
            Net Mailbox   [e-mail]
            NIC-Ident     CMR

   4)  The name, title, mailing address, phone number, and organization
   of the zone technical contact.  The online mailbox and NIC-Ident of
   the zone technical contact should also be included.  This is the
   contact point for problems with the zone and for updating information
   about the zone.  In many cases the zone technical contact and the
   domain technical contact will be the same person.

      For example:

         Technical Contact

            Organization  USC/Information Sciences Institute
            Name          Craig Milo Rogers
            Title         Researcher
            Mail Address  USC/ISI
                          4676 Admiralty Way, Suite 1001
                          Marina del Rey, CA. 90292-6695
            Phone Number  213-822-1511
            Net Mailbox   [e-mail]
            NIC-Ident     CMR

   5)  The name of the domain (up to 12 characters).  This is the name
   that will be used in tables and lists associating the domain and the
   domain server addresses.  [While technically domain names can be
   quite long (programmers beware), shorter names are easier for people
   to cope with.]

      For example:  ALPHA-BETA

   6)  A description of the servers that provides the domain service for
   translating name to address for hosts in this domain, and the date
   they will be operational.



Postel & Reynolds                                              [Page 12]



RFC 920                                                     October 1984
Domain Requirements


      A good way to answer this question is to say "Our server is
      supplied by person or company X and does whatever their standard
      issue server does".

         For example:  Our server is a copy of the server operated by
         the NIC, and will be installed and made operational on
         1-November-84.

   7)  A description of the server machines, including:

      (a) hardware and software (using keywords from the Assigned
      Numbers)

      (b) addresses (what host on what net for each connected net)

      For example:

         (a) hardware and software

            VAX-11/750  and  UNIX,    or
            IBM-PC      and  MS-DOS,  or
            DEC-1090    and  TOPS-20

         (b) address

            10.9.0.193 on ARPANET

   8)  An estimate of the number of hosts that will be in the domain.

      (a) initially,
      (b) within one year,
      (c) two years, and
      (d) five years.

      For example:

         (a) initially  =   50
         (b) one year   =  100
         (c) two years  =  200
         (d) five years =  500









Postel & Reynolds                                              [Page 13]



RFC 920                                                     October 1984
Domain Requirements


Acknowledgment

   We would like to thank the many people who contributed to this memo,
   including the participants in the Namedroppers Group, the ICCB, the
   PCCB, and especially the staff of the Network Information Center,
   particularly J. Feinler and K. Harrenstien.

References

   [1]  Postel, J., "The Domain Names Plan and Schedule", RFC-881, USC
        Information Sciences Institute, November 1983.

   [2]  Mockapetris, P., "Domain Names - Concepts and Facilities",
        RFC-882, USC Information Sciences Institute, November 1983.

   [3]  Mockapetris, P., "Domain Names - Implementation and
        Specification", RFC-883, USC Information Sciences Institute,
        November 1983.

   [4]  Postel, J., "Domain Name System Implementation Schedule",
        RFC-897, USC Information Sciences Institute, February 1984.

   [5]  ISO, "Codes for the Representation of Names of Countries",
        ISO-3166, International Standards Organization, May 1981.

   [6]  Postel, J., "Domain Name System Implementation Schedule -
        Revised", RFC-921, USC Information Sciences Institute, October
        1984.

   [7]  Mockapetris, P., "The Domain Name System", Proceedings of the
        IFIP 6.5 Working Conference on Computer Message Services,
        Nottingham, England, May 1984.  Also as ISI/RS-84-133,
        June 1984.

   [8]  Mockapetris, P., J. Postel, and P. Kirton, "Name Server Design
        for Distributed Systems", Proceedings of the Seventh
        International Conference on Computer Communication, October 30
        to November 3 1984, Sidney, Australia.  Also as ISI/RS-84-132,
        June 1984.










Postel & Reynolds                                              [Page 14]