+
+
+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]
+\f
+
+
+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]
+\f
+
+
+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]
+\f
+
+
+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]
+\f
+
+
+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]
+\f
+
+
+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]
+\f
+
+
+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: HOSTMASTER@SRI-NIC.ARPA
+
+ GOV = Government
+
+ Administrator: DARPA
+ Agent: The Network Information Center
+ Mailbox: HOSTMASTER@SRI-NIC.ARPA
+
+ EDU = Education
+
+ Administrator: DARPA
+ Agent: The Network Information Center
+ Mailbox: HOSTMASTER@SRI-NIC.ARPA
+
+ COM = Commercial
+
+ Administrator: DARPA
+ Agent: The Network Information Center
+ Mailbox: HOSTMASTER@SRI-NIC.ARPA
+
+ MIL = Military
+
+ Administrator: DDN-PMO
+ Agent: The Network Information Center
+ Mailbox: HOSTMASTER@SRI-NIC.ARPA
+
+
+
+
+
+
+Postel & Reynolds [Page 7]
+\f
+
+
+RFC 920 October 1984
+Domain Requirements
+
+
+ ORG = Organization
+
+ Administrator: DARPA
+ Agent: The Network Information Center
+ Mailbox: HOSTMASTER@SRI-NIC.ARPA
+
+ 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]
+\f
+
+
+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]
+\f
+
+
+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]
+\f
+
+
+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 (HOSTMASTER@SRI-NIC.ARPA):
+
+ 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
+ NIC@SRI-NIC.ARPA.
+
+ 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 Uncapher@USC-ISIB.ARPA
+ 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]
+\f
+
+
+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 Rogers@USC-ISIB.ARPA
+ 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 Rogers@USC-ISIB.ARPA
+ 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]
+\f
+
+
+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]
+\f
+
+
+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]
+\f
projects / unix-history / commitdiff