![]()
|
Network Working Group J. Postel
Request for Comments: 1591 ISI
Category: Informational March 1994
Domain Name System Structure and Delegation
Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Postel [Page 1] RFC 1591 Domain Name System Structure and Delegation March 1994 Each of the generic TLDs was created for a general category of organizations. The country code domains (for example, FR, NL, KR, US) are each organized by an administrator for that country. These administrators may further delegate the management of portions of the naming tree. These administrators are performing a public service on behalf of the Internet community. Descriptions of the generic domains and the US country domain follow. Of these generic domains, five are international in nature, and two are restricted to use by entities in the United States. World Wide Generic Domains: COM - This domain is intended for commercial entities, that is
companies. This domain has grown very large and there is
concern about the administrative load and system performance if
the current growth pattern is continued. Consideration is
being taken to subdivide the COM domain and only allow future
commercial registrations in the subdomains.
EDU - This domain was originally intended for all educational
institutions. Many Universities, colleges, schools,
educational service organizations, and educational consortia
have registered here. More recently a decision has been taken
to limit further registrations to 4 year colleges and
universities. Schools and 2-year colleges will be registered
in the country domains (see US Domain, especially K12 and CC,
below).
NET - This domain is intended to hold only the computers of network
providers, that is the NIC and NOC computers, the
administrative computers, and the network node computers. The
customers of the network provider would have domain names of
their own (not in the NET TLD).
ORG - This domain is intended as the miscellaneous TLD for
organizations that didn't fit anywhere else. Some non-
government organizations may fit here.
INT - This domain is for organizations established by international treaties, or international databases. United States Only Generic Domains: GOV - This domain was originally intended for any kind of government
office or agency. More recently a decision was taken to
register only agencies of the US Federal government in this
domain. State and local agencies are registered in the country
Postel [Page 2]
RFC 1591 Domain Name System Structure and Delegation March 1994
domains (see US Domain, below).
MIL - This domain is used by the US military. Example country code Domain: US - As an example of a country domain, the US domain provides for
the registration of all kinds of entities in the United States
on the basis of political geography, that is, a hierarchy of
<entity-name>.<locality>.<state-code>.US. For example,
"IBM.Armonk.NY.US". In addition, branches of the US domain are
provided within each state for schools (K12), community colleges
(CC), technical schools (TEC), state government agencies
(STATE), councils of governments (COG),libraries (LIB), museums
(MUS), and several other generic types of entities (see RFC 1480
for details [1]).
To find a contact for a TLD use the "whois" program to access the database on the host rs.internic.net. Append "-dom" to the name of TLD you are interested in. For example:
whois -h rs.internic.net us-dom
or
whois -h rs.internic.net edu-dom
3. The Administration of Delegated Domains The Internet Assigned Numbers Authority (IANA) is responsible for the overall coordination and management of the Domain Name System (DNS), and especially the delegation of portions of the name space called top-level domains. Most of these top-level domains are two-letter country codes taken from the ISO standard 3166. A central Internet Registry (IR) has been selected and designated to handled the bulk of the day-to-day administration of the Domain Name System. Applications for new top-level domains (for example, country code domains) are handled by the IR with consultation with the IANA. The central IR is INTERNIC.NET. Second level domains in COM, EDU, ORG, NET, and GOV are registered by the Internet Registry at the InterNIC. The second level domains in the MIL are registered by the DDN registry at NIC.DDN.MIL. Second level names in INT are registered by the PVM at ISI.EDU. While all requests for new top-level domains must be sent to the Internic (at hostmaster@internic.net), the regional registries are often enlisted to assist in the administration of the DNS, especially in solving problems with a country administration. Currently, the RIPE NCC is the regional registry for Europe and the APNIC is the Postel [Page 3] RFC 1591 Domain Name System Structure and Delegation March 1994 regional registry for the Asia-Pacific region, while the INTERNIC administers the North America region, and all the as yet undelegated regions. The contact mailboxes for these regional registries are:
INTERNIC hostmaster@internic.net
APNIC hostmaster@apnic.net
RIPE NCC ncc@ripe.net
The policy concerns involved when a new top-level domain is established are described in the following. Also mentioned are concerns raised when it is necessary to change the delegation of an established domain from one party to another. A new top-level domain is usually created and its management delegated to a "designated manager" all at once. Most of these same concerns are relevant when a sub-domain is delegated and in general the principles described here apply recursively to all delegations of the Internet DNS name space. The major concern in selecting a designated manager for a domain is that it be able to carry out the necessary responsibilities, and have the ability to do a equitable, just, honest, and competent job.
Postel [Page 4] RFC 1591 Domain Name System Structure and Delegation March 1994
Concerns about "rights" and "ownership" of domains are
inappropriate. It is appropriate to be concerned about
"responsibilities" and "service" to the community.
3) The designated manager must be equitable to all groups in the domain that request domain names.
This means that the same rules are applied to all requests, all
requests must be processed in a non-discriminatory fashion, and
academic and commercial (and other) users are treated on an equal
basis. No bias shall be shown regarding requests that may come
from customers of some other business related to the manager --
e.g., no preferential service for customers of a particular data
network provider. There can be no requirement that a particular
mail system (or other application), protocol, or product be used.
There are no requirements on subdomains of top-level domains
beyond the requirements on higher-level domains themselves. That
is, the requirements in this memo are applied recursively. In
particular, all subdomains shall be allowed to operate their own
domain name servers, providing in them whatever information the
subdomain manager sees fit (as long as it is true and correct).
4) Significantly interested parties in the domain should agree that the designated manager is the appropriate party.
The IANA tries to have any contending parties reach agreement
among themselves, and generally takes no action to change things
unless all the contending parties agree; only in cases where the
designated manager has substantially mis-behaved would the IANA
step in.
However, it is also appropriate for interested parties to have
some voice in selecting the designated manager.
There are two cases where the IANA and the central IR may
establish a new top-level domain and delegate only a portion of
it: (1) there are contending parties that cannot agree, or (2) the
applying party may not be able to represent or serve the whole
country. The later case sometimes arises when a party outside a
country is trying to be helpful in getting networking started in a
country -- this is sometimes called a "proxy" DNS service.
The Internet DNS Names Review Board (IDNB), a committee
established by the IANA, will act as a review panel for cases in
which the parties can not reach agreement among themselves. The
IDNB's decisions will be binding.
Postel [Page 5]
RFC 1591 Domain Name System Structure and Delegation March 1994
5) The designated manager must do a satisfactory job of operating the DNS service for the domain.
That is, the actual management of the assigning of domain names,
delegating subdomains and operating nameservers must be done with
technical competence. This includes keeping the central IR (in
the case of top-level domains) or other higher-level domain
manager advised of the status of the domain, responding to
requests in a timely manner, and operating the database with
accuracy, robustness, and resilience.
There must be a primary and a secondary nameserver that have IP
connectivity to the Internet and can be easily checked for
operational status and database accuracy by the IR and the IANA.
In cases when there are persistent problems with the proper
operation of a domain, the delegation may be revoked, and possibly
delegated to another designated manager.
6) For any transfer of the designated manager trusteeship from one
organization to another, the higher-level domain manager (the IANA
in the case of top-level domains) must receive communications from
both the old organization and the new organization that assure the
IANA that the transfer in mutually agreed, and that the new
organization understands its responsibilities.
It is also very helpful for the IANA to receive communications
from other parties that may be concerned or affected by the
transfer.
4. Rights to Names
Postel [Page 6] RFC 1591 Domain Name System Structure and Delegation March 1994
The selection of the ISO 3166 list as a basis for country code
top-level domain names was made with the knowledge that ISO has a
procedure for determining which entities should be and should not
be on that list.
5. Security Considerations Security issues are not discussed in this memo. 6. Acknowledgements Many people have made comments on draft version of these descriptions and procedures. Steve Goldstein and John Klensin have been particularly helpful. 7. Author's Address Jon Postel Phone: 310-822-1511 7. References [1] Cooper, A., and J. Postel, "The US Domain", RFC 1480, USC/Information Sciences Institute, June 1993. [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992. [3] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987. [4] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
[6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, CSNET CIC BBN, January 1986. [7] Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, Internet Engineering
Task Force, October 1989.
Postel [Page 7]
|