RFC920 - Domain requirements

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.

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

RFC920 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

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

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

RFC920 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

RFC920 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