rfc920.txt

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

Network Working Group                                          J. Postel
Request for Comments: 920                                    J. Reynolds
                                                                     ISI
                                                            October 1984

                          Domain Requirements


Status of this Memo

   This memo is a policy statement on the requirements of establishing a
   new domain in the ARPA-Internet and the DARPA research community.
   This is an official policy statement of the IAB and the DARPA.
   Distribution of this memo is unlimited.

Introduction

   This memo restates and refines the requirements on establishing a
   Domain first described in RFC-881 [1].  It adds considerable detail
   to that discussion, and introduces the limited set of top level
   domains.

The Purpose of Domains

   Domains are administrative entities.  The purpose and expected use of
   domains is to divide the name management required of a central
   administration and assign it to sub-administrations.  There are no
   geographical, topological, or technological constraints on a domain.
   The hosts in a domain need not have common hardware or software, nor
   even common protocols.  Most of the requirements and limitations on
   domains are designed to ensure responsible administration.

   The domain system is a tree-structured global name space that has a
   few top level domains.  The top level domains are subdivided into
   second level domains.  The second level domains may be subdivided
   into third level domains, and so on.

   The administration of a domain requires controlling the assignment of
   names within that domain and providing access to the names and name
   related information (such as addresses) to users both inside and
   outside the domain.












Postel & Reynolds                                               [Page 1]



RFC 920                                                     October 1984
Domain Requirements


General Purpose Domains

   While the initial domain name "ARPA" arises from the history of the
   development of this system and environment, in the future most of the
   top level names will be very general categories like "government",
   "education", or "commercial".  The motivation is to provide an
   organization name that is free of undesirable semantics.

   After a short period of initial experimentation, all current
   ARPA-Internet hosts will select some domain other than ARPA for their
   future use.  The use of ARPA as a top level domain will eventually
   cease.

Initial Set of Top Level Domains

   The initial top level domain names are:

      Temporary

         ARPA  =  The current ARPA-Internet hosts.

      Categories

         GOV  =  Government, any government related domains meeting the
                 second level requirements.

         EDU  =  Education, any education related domains meeting the
                 second level requirements.

         COM  =  Commercial, any commercial related domains meeting the
                 second level requirements.

         MIL  =  Military, any military related domains meeting the
                 second level requirements.

         ORG  =  Organization, any other domains meeting the second
                 level requirements.

      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].






Postel & Reynolds                                               [Page 2]



RFC 920                                                     October 1984
Domain Requirements


      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.

Possible Examples of Domains

   The following examples are fictions of the authors' creation, any
   similarity to the real world is coincidental.

   The UC Domain

      It might be that a large state wide university with, say, nine
      campuses and several laboratories may want to form a domain.  Each
      campus or major off-campus laboratory might then be a subdomain,
      and within each subdomain, each department could be further
      distinguished.  This university might be a second level domain in
      the education category.

      One might see domain style names for hosts in this domain like
      these:

         LOCUS.CS.LA.UC.EDU
         CCN.OAC.LA.UC.EDU
         ERNIE.CS.CAL.UC.EDU
         A.S1.LLNL.UC.EDU
         A.LAND.LANL.UC.EDU
         NMM.LBL.CAL.UC.EDU

   The MIT Domain

      Another large university may have many hosts using a variety of
      machine types, some even using several families of protocols.
      However, the administrators at this university may see no need for
      the outside world to be aware of these internal differences.  This
      university might be a second level domain in the education
      category.

      One might see domain style names for hosts in this domain like
      these:

         APIARY-1.MIT.EDU
         BABY-BLUE.MIT.EDU
         CEZANNE.MIT.EDU
         DASH.MIT.EDU


Postel & Reynolds                                               [Page 3]



RFC 920                                                     October 1984
Domain Requirements


         MULTICS.MIT.EDU
         TAC.MIT.EDU
         XX.MIT.EDU

   The CSNET Domain

      There may be a consortium of universities and industry research
      laboratories called, say, "CSNET".  This CSNET is not a network
      per se, but rather a computer mail exchange using a variety of
      protocols and network systems.  Therefore, CSNET is not a network
      in the sense of the ARPANET, or an Ethernet, or even the
      ARPA-Internet, but rather a community.  Yet it does, in fact, have
      the key property needed to form a domain; it has a responsible
      administration.  This consortium might be large enough and might
      have membership that cuts across the categories in such a way that
      it qualifies under the "multiorganization rule" to be a top level
      domain.

      One might see domain style names for hosts in this domain like
      these:

         CIC.CSNET
         EMORY.CSNET
         GATECH.CSNET
         HP-LABS.CSNET
         SJ.IBM.CSNET
         UDEL.CSNET
         UWISC.CSNET

General 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 an authoritative coordinator for
   domain related questions.  There must be a robust domain name lookup
   service, it must be of at least a minimum size, and the domain must
   be registered with the central domain administrator (the Network
   Information Center (NIC) Domain Registrar).

   Responsible Person:

      An individual must be identified who has authority for the
      administration of the names within the domain, and who seriously
      takes on the responsibility for the behavior of the hosts in the
      domain, plus their interactions with hosts outside the domain.
      This person must have some technical expertise and the authority
      within the domain to see that problems are fixed.


Postel & Reynolds                                               [Page 4]



RFC 920                                                     October 1984
Domain Requirements


      If a host in a given domain somehow misbehaves in its interactions
      with hosts outside the domain (e.g., consistently violates
      protocols), the responsible person for the domain must be
      competent and available to receive reports of problems, take
      action on the reported problems, and follow through to eliminate
      the problems.

   Domain Servers:

      A robust and reliable domain server must be provided.  One way of
      meeting this requirement is to provide at least two independent
      domain servers for the domain.  The database 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.  They should have no common point of
      failure.

      Some domains may find that providing a robust domain service can
      most easily be done by cooperating with another domain where each
      domain provides an additional server for the other.

      In other situations, it may be desirable for a domain to arrange
      for domain service to be provided by a third party, perhaps on
      hosts located outside the domain.

      One of the difficult problems in operating a domain server is the
      acquisition and maintenance of the data.  In this case, the data
      are 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 database is easily managed.

      In the technical language of the domain server implementation the
      data is divided into zones.  Domains and zones are not necessarily
      one-to-one.  It may be reasonable for two or more domains to
      combine their data in a single zone.

      The responsible person or an identified technical assistant must
      understand in detail the procedures for operating a domain server,
      including the management of master files and zones.

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


Postel & Reynolds                                               [Page 5]



RFC 920                                                     October 1984
Domain Requirements


      The concepts and implementation details of the domain server are
      given in RFC-882 [2] and RFC-883 [3].

   Minimum Size:

      The domain must be of at least a minimum size.  There is no
      requirement to form a domain because some set of hosts is above
      the minimum size.

      Top level domains must be specially authorized.  In general, they
      will only be authorized for domains expected to have over 500
      hosts.

      The general guideline for a second level domain is that it have
      over 50 hosts.  This is a very soft "requirement".  It makes sense
      that any major organization, such as a university or corporation,
      be allowed as a second level domain -- even if it has just a few
      hosts.

   Registration:

      Top level domains must be specially authorized and registered with
      the NIC domain registrar.

      The administrator of a level N domain must register with the
      registrar (or responsible person) of the level N-1 domain.  This
      upper level authority must be satisfied that the requirements are
      met before authorization for the domain is granted.

      The registration procedure involves answering specific questions
      about the prospective domain.  A prototype of what the NIC Domain
      Registrar may ask for the registration of a second level domain is
      shown below.  These questions may change from time to time.  It is
      the responsibility of domain administrators to keep this
      information current.

      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 within 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.  Even if sub-domains are established, the
      responsible person for the top-level domain is ultimately
      responsible for the whole tree of sub-domains and hosts.

      This does not mean that a domain administrator has to know the


Postel & Reynolds                                               [Page 6]



RFC 920                                                     October 1984
Domain Requirements


      details of all the sub-domains and hosts to the Nth degree, but
      simply that if a problem occurs he can get it fixed by calling on
      the administrator of the sub-domain containing the problem.

Top Level Domain Requirements

   There are very few top level domains, each of these may have many
   second level domains.

   An initial set of top level names has been identified.  Each of these
   has an administrator and an agent.

   The top level domains:

      ARPA =  The ARPA-Internet   *** TEMPORARY ***

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

      GOV  =  Government

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

      EDU  =  Education

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

      COM  =  Commercial

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

      MIL  =  Military

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






Postel & Reynolds                                               [Page 7]