perm filename DOMAIN.XXX[RFC,NET] blob
sn#727530 filedate 1983-10-27 generic text, type T, neo UTF8
Network Working Group J. Postel
Request for Comments: XXX ISI
October 1983
The Domain Names Plan and Schedule
DRAFT of 13 Oct 83 9:16PM
This RFC outlines a plan and schedule for the implementation of domain
style names throughout the DDN/ARPA Internet community. The
introduction of domain style names will impact all hosts on the DDN/ARPA
Internet.
The Plan
Introduction
Domain style names are being introduced in the Internet to allow a
controlled delegation of the authority and responsibility for
adding hosts to the system. This also allows a subdivision of the
task of maintaining information about hosts.
The subdivision will be based on administrative authority or
organization boundaries (not necessarily network boundaries).
Certain requirements will be placed on organizations wishing to be
"top level" domains. Initially, all the hosts in the Internet
will be in the domain "ARPA". As soon as is practical a second
domain, "DDN", will be introduced. Other domains may be added
after that, provided the requirements listed below are met.
Domain names will be supported in the long run by a system of
special servers called "domain servers" which will be used to
translate names to addresses. While this system of domain servers
is being created and programs are being converted to use them, the
existing host tables will evolve to include domain style names.
The domain server design also provides for mapping mailbox
addresses to the host name of the mail server for that mailbox.
This feature allows mailboxes to be related to an organization
rather than to a specific host.
This plan will be implemented in the ARPA community. After the
domain system is demonstrated in the ARPA community, the DDN
Program Management Office (DDN-PMO) will determine the schedule
for implementation of the domain system in the DDN community.
This approach will cause some extra steps in the ARPA community
implementation, and may limit communication between the ARPA and
DDN communities in some ways. The details and implications of
this two phase approach are discussed more fully below.
Postel [Page 1]
RFC XXX DRAFT October 1983
The Domain Names Plan and Schedule
A Catch 22
There is a problem in introducing domain style names: a great deal
of software has to be changed. Some groups would like to start
using domain style names right away, and other groups don't want
to see them or use them for a very long time. Communication
patterns are very complex and as soon as domain style names are
allowed and used by a few groups they will start showing up almost
everywhere. This argues that everyone should be prepared for them
before they are used at all. However, we know that with people
being people and with so many of people involved, the probability
of everyone being ready in any reasonable time period is nearly
zero. The way out of this situation is to set up a reasonable
schedule for experimenting with domain style names and authorizing
their use. People that get ready on schedule should have no
problems with these names.
Evolution of the Table
Nearly all the hosts in the Internet now use some form of host
table based on the master file "HOSTS.TXT" maintained by the
Network Information Center (NIC).
One way to introduce domain style names is to add to the entries
in this table names in the domain style. In particular, make the
first name in each entry the official host name in the ARPA
domain.
For example, the current entry for USC-ISIF is:
HOST : 10.2.0.52 : USC-ISIF,ISIF : DEC-1090T : TOPS20 :
TCP/TELNET,TCP/SMTP,TCP/MTP,TCP/FTP,TCP/FINGER,UDP/TFTP :
This could become:
HOST : 10.2.0.52 : USC-ISIF.ARPA,USC-ISIF,ISIF : DEC-1090T :
TOPS20 :
TCP/TELNET,TCP/SMTP,TCP/MTP,TCP/FTP,TCP/FINGER,UDP/TFTP :
For some hosts and programs this could be done today with no
disruptions, but for others substantial problems could occur. For
example, with over five hundred entries in the table the addition
of 500 names could exceed the space alocated to store the table in
some programs. (One could argue that these programs are going to
blow up soon anyway as new host entries are added to the table.)
Another problem is that period (or dot, ".") is not now a legal
character in host names and some programs may not be able to parse
these new names.
Postel [Page 2]
RFC XXX DRAFT October 1983
The Domain Names Plan and Schedule
The plan is to make such a domain style name table available in
parallel with the regular table for a few months, then to replace
the regular table with this domain style table. The dates for
these changes is given in the schedule below.
So far, no new domains have been introduced. Only a table with
all the entries having official names in the ARPA domain has been
provided. This should allow programs to be constructed to deal
with domain style names in a general way without any special hacks
to add or delete the string ".ARPA" to or from host names.
The introduction of new domains is tied to the provision of domain
servers by those domains. As new domains meet the requirements
and are authorized they will also be added to the host table. No
new domains will be added before master table is converted to the
domain style entries.
In the long run the Internet will become too complex and change
too fast to keep a master table of all the hosts. At some point
the master table will be reduced to simply the entries for the
domain servers for the top level domains. By this time all normal
translation of host names into addresses should take place by
consulting domain servers.
Conversion to Servers
As soon as domain servers become available programs should be
converted to use them to translate names into addresses. The
details of these procedures are given in RFCs YYY and ZZZ.
The general idea is that a host no longer keeps a complete host
table but rather makes a request on the domain server each time a
name must be translated to an address. The code module in the
host that implements the protocol to do this is called a
"resolver". The resolver may keep a cache of recently translated
names and addresses for improved performance.
Many hosts have a library function or system call that is used to
access the host table to translate names to addresses. It ought
to be possible to replace this function or call with the resolver
module such that most programs would not know which method was
used to accomplish the name to address translation.
Postel [Page 3]
RFC XXX DRAFT October 1983
The Domain Names Plan and Schedule
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 a coordinator for domain related
questions, there must be a robust name service, and the domain
must be registered with the central domain administrator.
Responsible Person:
An individual must be identified who has authority for the
administration of the names within the domain, and who takes
responsibility for the behavior of the hosts in the domain in
their interactions with hosts outside the domain.
The operation of a name server should not be taken on lightly.
There are some difficult problems in providing an adequate
service, primarily the problems in keeping the data base up to
date, and keeping the service operating.
If some host in a domain somehow misbehaves in interactions
with hosts outside the domain (e.g., consistently violates
protocols), the responsible person for the domain must be able
to take action to eliminate the problem.
Domain Servers:
A robust and reliable domain service must be provided. One way
of meeting this requirement is to provide at least two
independent domain servers for the domain. The data base 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 and yet in the
same domain. They should have no common point of failure.
One of the difficult problems in operating a domain server is
the acquisition and maintenance of the data. In this case the
data is 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 data base is easily
managed.
The concepts and implementation details of the domain server
are given in RFCs YYY and ZZZ.
Postel [Page 4]
RFC XXX DRAFT October 1983
The Domain Names Plan and Schedule
Registration:
The administrator must register the domain with the central
authority. The central authority must be satisfied that the
requirements are met before authorization for the domain is
granted.
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 with in 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.
Mailbox Support
The design of the domain servers provides two levels of support
for mail.
The first, called "agent binding", is that the right hand part of
the typical mail box (Y in X@Y) can be mapped a host that will
either accept the mail as the destination or accept the mail for
forwarding.
The second, called "mailbox binding", is to map the entire mailbox
(X@Y) to a destination (this mechanism can also support some
mailing list functions).
Agent binding can be used to establish mailboxes that are based on
an organization name rather than a host name.
For example, an organization, "BLAT", with hosts "BLAT-20" and
"BLAT-VAX" in the ARPA domain could set up mailboxes of the
form "user@BLAT.ARPA" and use the domain server mechanisms for
mapping these to the host that accepts the mail for the
organization.
Mailbox binding will allow different mappings for individual
mailboxes of an organization or host to the destination host. It
will also provide for aliases and mailing groups.
Mailbox binding requires adding information on individual
mailboxes to the domain server database. This could be a
substantial increase in the database size and management
responsibility.
Postel [Page 5]
RFC XXX DRAFT October 1983
The Domain Names Plan and Schedule
The ARPA Community and the DDN Community
This plan will be put into effect in the ARPA community.
The DDN community will adopt the domain style names, but will
continue with the present scheme of a centrally maintained table
copied periodically by each host. Once the use of domain servers
has been demonstrated by use in the ARPA community, the DDN-PMO
will establish a schedule for implementing the domain system in
the DDN community.
This means that there may be a period of a year or more with the
two communities using different schemes for distributing
information about host names and addresses.
Specifically:
The NIC will maintain a table a "HOSTS.TXT" style table for use
by DDN hosts. This table will contain domain style names for
all DDN hosts (e.g., USC-ISIA.DDN). Since this is the only
information DDN hosts will use to translate host names to
Internet Addresses, this table must also contain names and
addresses of ARPA community hosts of interest to DDN users
(e.g., USC-ISIF.ARPA).
There will be a domain server with data for the DDN domain.
That is, hosts in the ARPA community that use the domain system
of resolvers and servers will be able to access servers that
have the data base covering the DDN community.
It is quite likely that the table for the use of the DDN hosts
will be incomplete with respect to coverage of the ARPA community
and any new domains that are established. One motivation for the
domain system is the subdivision of name management to avoid the
difficulty of keeping a global table of all hosts. As the ARPA
community moves to significant use of the domains system the
maintenance of a global table for use by the DDN community will
become very difficult.
This means that DDN hosts might not be able to look up the names
of some ARPA community hosts in their local tables. In some cases
this might prevent establishing communication from a DDN hosts to
such "unknown" ARPA community hosts.
Postel [Page 6]
RFC XXX DRAFT October 1983
The Domain Names Plan and Schedule
The Schedule
04-Oct-83 The ARPANET/MILNET Logical Split
26-Oct-83 Publish this Plan and Schedule
RFC XXX
26-Oct-83 Publish the Domain Concepts Paper
RFC YYY
26-Oct-83 Publish the Domain Implementation Paper
RFC ZZZ
09-Nov-83 Make Available Domain Style Host Table
Create a copy a modified version of the HOSTS.TXT table named
DHOSTS.TXT with an additional name (as the first name) in each
entry of the form "offfical-host-name.ARPA".
23-Nov-83 Make Limited Domain Servers & Resolvers Available
At this point an example limited domain server and an example
limited resolver running on each of TOPS-20 and VAX-Berkeley-Unix
should be made available for testing and copying. This simple
version would be able to do queries and responses for host name to
internet address translation only, and the servers would still use
the global table. These simple servers would not refer the
resolver to another server. However, this would allow user
programs to begin to use the servers.
01-Feb-84 The ARPANET/MILNET Access Controls
07-Mar-84 Replace Main Host Table with Domain Style Host Table
The DHOSTS.TXT becomes HOSTS.TXT.
14-Mar-84 Make Improved Domain Servers & Resolvers Available
At this point an example domain server and an example resolver
running on each of TOPS-20 and VAX-Berkeley-Unix should be made
available for testing and copying. This version should be able to
do any of the defined query and response operations, and should
support segmented data base by refering resolvers to other servers
if necessary. This version does not support the data base update
portion of the server protocol.
Postel [Page 7]
RFC XXX DRAFT October 1983
The Domain Names Plan and Schedule
04-Apr-84 Domain Servers for ARPA Domain Available
Authorative domain servers for the ARPA domain will be available
for regular use.
02-May-84 Introduce New Domains in the Main Host Table
Add the DDN domain. Most MILNET hosts will change to the DDN
domain. Authorative domain servers for the DDN domain will be
available for regular use.
02-May-84 Establish a New Top Level Domains Only Table
Start a new table, DOMAINS.TXT, that lists only the top level
domains and the entries for their domain servers.
06-Jun-83 Permit the Introduction of New Domains
Organizations meeting the requirments for establishing new domains
will be allowed to register and begin use of new domain names.
New domains must have domain servers and will be added to the
HOSTS.TXT table.
13-Jun-84 Make Full Domain Servers & Resolvers Available
At this point an example domain server and an example resolver
running on each of TOPS-20 and VAX-Berkeley-Unix should be made
available for testing and copying. This version should be able to
do any of the defined query and response operations, and should
support segmented data base by refering resolvers to other servers
if necessary. This version should support the data base update
portion of the server protocol. This is a full imlementation of
the protocol.
05-Sep-84 Discontinue the Full Host Table for the ARPA Community
Stop maintaining the HOSTS.TXT table for the ARPA community. The
HOSTS.TXT table continues to be used in the DDN community with
complete data for the DDN domain, however the data for the ARPA
and other domains may no longer be complete or fully up to date.
03-Oct-84 DDN-PMO Schedules DDN Implementation
The DDN-PMO establishes the schedule for the implementation of the
domain system in the DDN community.
Postel [Page 8]