Network Working Group W A Simpson, Editor
Internet Draft Daydreamer
expires in six months November 1995
Domain Name System Delegation
draft-simpson-dns-delegation-00.txt
Status of this Memo
This document is an independent submission. Comments should be
submitted to the namedroppers@internic.net mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months, and may be updated, replaced, or obsoleted by other documents
at any time. It is not appropriate to use Internet Drafts as
reference material, or to cite them other than as a ``working draft''
or ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
Directories on:
ftp.is.co.za (Africa)
nic.nordu.net (Europe)
ds.internic.net (US East Coast)
ftp.isi.edu (US West Coast)
munnari.oz.au (Pacific Rim)
Abstract
This document provides information on the organizational structure of
the Domain Name System (DNS), specifically the top-level domain
names.
This document is a rewrite and update of RFC-1591.
Simpson expires in six months [Page i]
DRAFT ICMP Delegation November 1995
1. Introduction
The Internet Activities Board (IAB), also known as the Internet
Architecture Board, is responsible for the coordination of Internet
Activities [RFC-1601]. The IAB is responsible for editorial
management and publication of the Request for Comments (RFC) document
series, and for administration of the various Internet assigned
numbers.
The IAB has designated an Internet Assigned Numbers Authority (IANA)
to coordinate the registration of Internet protocol numbers, the top
level Domain Names, and many other parameters used in the Internet.
IANA discretion in the execution of these duties is explicitly
limited to technical and engineering considerations.
The IAB has designated a separate Internet Secretariate to coordinate
meetings, publish minutes and drafts, and administer funds related to
the coordination of the Internet.
2. The Top Level Structure of the Domain Names
In the Domain Name System (DNS) naming of computers, there is a
hierarchy of names. The root of the system is unnamed, and is
usually represented by a trailing dot ".", as at the end of a
sentence.
The small set of names which are registered at the root are called
"primary-level domain names" (1LDN). Under each 1LDN may be created
a hierarchy of names, sometimes called "secondary-level domain names"
(2LDN), "tertiary-level domain names" (3LDN), and so forth.
2.1. Root
The Internet Assigned Numbers Authority (IANA) has principle
responsibility for maintaining the root of the Domain Name System
(DNS). IANA is responsible for oversight of both operation and
security of the DNS root. IANA has sole authority to create or
remove a 1LDN delegation, or transfer delegation to another party
which meets the established criterion.
To this end, the number of primary-level domain names registered at
the root is deliberately kept within humanly managable limits. Only
a few hundred root entries are anticipated.
Simpson expires in six months [Page 1]
DRAFT ICMP Delegation November 1995
Day-to-day database storage and transaction activity may be
distributed to other organizations. However, it is not anticipated
that the root will be updated by external registration authorities.
2.1.1. Servers
The DNS root is maintained and distributed to servers from IANA.
These servers must be continuously available world-wide, and enjoy
multiply-connected network topological distribution.
Technical considerations restrict the number of root servers. The
DNS UDP datagrams can support about 16 such servers. The servers are
currently in the domain root-servers.net.
Another technical consideration is the load placed on the servers.
To promote cached operation, primary root servers should refuse DNS
requests from systems not named as Name Servers (NS) in their
delegation.
Operation of primary root servers is a voluntary service to the
Internet community. When there are more than enough volunteers, IANA
will select sites that are well distributed topologically.
Consideration will also be given to technical considerations such as
proximity to Internet exchanges, and demonstrated capability to
operate such servers.
2.1.2. Establishment
A new 1LDN is usually created and its management delegated to a
"designated manager" all at once.
Root domain delegations must demonstrate a significant world-wide
constituency, and must serve a broad spectrum of the community. Each
1LDN should have at least 6 servers distributed over multiple
continents.
Delegations must provide a Charter with clear membership guidelines.
Each 1LDN must be open to all qualifying applicants on a non-
discriminatory basis.
Requests for new or changed 1LDN delegation records should be
submitted to root-delegation@iana.net. The proposed charter will be
posted as an internet-draft, and a 28 day Last Call will be issued by
the Internet Secretariate. IANA will make its decision based on the
Simpson expires in six months [Page 2]
DRAFT ICMP Delegation November 1995
results of the Last Call. Successful applications will be published
by the RFC-Editor.
2.1.3. Termination
Requests for termination of 1LDN delegation records should be
submitted to root-delegation@iana.net. A 28 day Last Call will be
issued by the Internet Secretariate. IANA will make its decision
based on the results of the Last Call.
2.2. One Letter 1LDN
Currently, there are no single alphabetic, numeric, or symbolic
letter domains.
Operation of single letter alphabetic domains will be distributed by
lottery. Each year 9 alphabetic domains will be randomly paired with
volunteer registries (the third year only 8 will be distributed). No
registry may operate more than one such domain.
Details are described in a separate charter.
2.2.1. Servers
These domain servers are operated on a voluntary basis. Usually, the
primary server for a one letter domain is co-located with one of the
root-servers.
2.3. Two Letter 1LDN
Most of the first level domains are two-letter country codes taken
from the ISO standard 3166. Additional two letter codes are
maintained on an historical basis.
The country code domains (for example, FR, NL, KR, US) are each
organized by an administrator for that country. At their discretion,
these administrators may further delegate the management of portions
of their naming tree. There is a wide variation in the name
structure. In some countries the structure is very flat. In others
there is substantial structural organization.
Simpson expires in six months [Page 3]
DRAFT ICMP Delegation November 1995
In some country domains the second levels are generic categories
(such as AC, CO, GO, and RE), in others they are based on political
geography, and in still others organization names are listed directly
under the country code.
The organization for the US country domain is described in [RFC-
1480].
2.3.1. Servers
These domain servers are operated on a voluntary basis by the country
administrators, performing a public service on behalf of the Internet
community.
2.4. Three Letter and Longer 1LDNs
Longer 1LDNs are available for domains that cross geopolitical
boundaries, that have not been recognized by its native country, or
that choose for some other reason to be independent.
Each of these 1LDNs was created for a general category of
organizations. Some are network related (Net and Int), some are
historic (ARPA, Gov, Mil), some are commercial (Com, Corp, Inc, Ltd),
and others are organizational (Edu, Org)
Generally, under the generic 1LDNs the structure is very flat. That
is, many organizations are registered directly under the 1LDN, and
any further structure is up to the individual organizations.
Unfortunately, this has engendered significant administrative and
engineering problems. In particular, administrative, competitive,
language and naming difficulties.
There have been serious scaling problems. Certain popular 1LDNs have
required tens of thousands of updates per month at a single registry,
rather than having the updates distributed throughout the DNS across
many registries.
These problems are ameliorated by separating the server and registry
functions. With the advent of DNS Security and Dynamic Update
capability, it is recently possible to allow multiple registries to
update the same 1LDN servers.
Simpson expires in six months [Page 4]
DRAFT ICMP Delegation November 1995
2.4.1. Servers
These domain servers are operated on a voluntary basis. When there
are more than enough volunteers, IANA will select sites that are well
distributed topologically. Consideration will also be given to
technical considerations such as proximity to Internet exchanges, and
demonstrated capability to operate such servers. Usually, these
servers are co-located with some of the root-servers.
Security Considerations
Separating delegation of domain servers from sub-domain registration
requires a robust DNS Security service. This is beyond the scope of
this specification.
Author's Address
Questions about this memo can also be directed to:
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com (prefered)
Simpson expires in six months [Page 5]
DRAFT ICMP Delegation November 1995
Table of Contents
1. Introduction .......................................... 1
2. The Top Level Structure of the Domain Names ........... 1
2.1 Root ............................................ 1
2.1.1 Servers ......................................... 2
2.1.2 Establishment ................................... 2
2.1.3 Termination ..................................... 3
2.2 One Letter 1LDN ................................. 3
2.2.1 Servers ......................................... 3
2.3 Two Letter 1LDN ................................. 3
2.3.1 Servers ......................................... 4
2.4 Three Letter and Longer 1LDNs ................... 4
2.4.1 Servers ......................................... 5
SECURITY CONSIDERATIONS ...................................... 5
AUTHOR'S ADDRESS ............................................. 5