DNS schedule (revised): Domain name system implementation schedule - revised
A dated plan for moving the Internet from one flat host table to hierarchical domain names and name servers.
Postel, J., "Domain name system implementation schedule - revised", RFC 921, DOI 10.17487/RFC0921, October 1984, <https://www.rfc-editor.org/info/rfc921>.
@misc{rfc921,
series = {Request for Comments},
number = 921,
howpublished = {RFC 921},
publisher = {RFC Editor},
doi = {10.17487/RFC0921},
url = {https://www.rfc-editor.org/info/rfc921},
author = {J. Postel},
title = {{Domain name system implementation schedule - revised}},
pagetotal = 13,
year = 1984,
month = oct,
} RFC text
Contents
Network Working Group Jon Postel
Request for Comments: 921 ISI
October 1984
Updates: RFC 897, RFC 881
Domain Name System Implementation Schedule - Revised
Status of this Memo
This memo is a policy statement on the implementation of the Domain
Style Naming System in the Internet. This memo is an update of
RFC-881, and RFC-897. This is an official policy statement of the
IAB and the DARPA. Distribution of this memo is unlimited.
The intent of this memo is to detail the schedule for the
implementation for the Domain Style Naming System. The explanation
of how this system works is to be found in the references.
The Current Situation
There are three aspects to the domain style naming system, (1) the
names themselves, (2) the method of translating names to addresses,
and (3) the relationship between the Internet and the rest of the
world.
Names
The names are being changed from simple names, or globally unique
strings, to structured names, where each component name is unique
only with respect to the superior component name.
Simple Names
Until recently, hosts in the DARPA research and DDN operational
communities were assigned names in a flat or global name space
of character strings. There are some limits on these names.
They must start with a letter, end with a letter or digit and
have only letters or digits or hyphen as interior characters.
Case is not significant.
For example: USC-ISIF
Hierarchical Names
Because of the growth of the Internet, structured names (or
domain style names) have been introduced. Each element of the
structured name will be a character string (with the same
constraints that previously applied to the simple names). The
Domain Implementation Schedule - Revised
elements (or components) of the structured names are separated
with periods, and the elements are written from the most
specific on the left to the most general on the right.
For example: USC-ISIF.ARPA
The Initial and Temporary Domain
The introduction of these hierarchical names has been very
limited. Every current name in this new system has the form
"old-simple-name.ARPA". That is, the all the hosts are in a
domain called "ARPA". This is a temporary situation. The
current intention is for the ARPA domain to cease to exist.
This means that all hosts will change their names as the domain
style names come into full use.
Name to Address Lookup
Every host in the Internet is expected to have a way of
translating the name of any other host into its Internet address.
By and large, the name to address translation is done by looking
up the information in a table of all hosts.
The maintenance of this table is centralized at the Network
Information Center (NIC). Each host is expected to obtain a
current copy of the table on a timely basis. This table is called
"HOSTS.TXT" [8] and is normally accessed via the Hostnames
Server [9].
Interface to the World
A great deal of mail moves between the Internet and other
"systems" that somehow transport mail among computers. This is
currently done by hiding some sort of "other-system" addressing
information in the local-part of the mail address and using a
mail-relay host in the host-part of the mailbox.
For example,
OBERST%EDUCOM.MAILNET@MIT-MULTICS.ARPA
EDMISTON.CIC@CSNET-RELAY.ARPA
Domain Implementation Schedule - Revised
The Future Situation
Names
Hierarchical Names
The use of the hierarchical names will be greatly expanded
according to the rules established in the "Domain Requirements"
memo (RFC-920) [5].
For example: F.ISI.USC.EDU
There are several levels of development for use of the domain
style names.
First, there is the current simple substitution of the domain
style names for the old style host names. At this stage all
domain style names directly translate to host addresses (using the
NIC tables) and all domain style names have two components. The
mail system uses addresses of the form "local-part@host", where
host is a domain style host name.
For example: USC-ISIF.ARPA and Postel@USC-ISIF.ARPA
Here we expect that "USC-ISIF.ARPA" is the name of an Internet
host and that we can send mail for "Postel" to the SMTP port on
that host. It may be that some backward host can still fake it
by ignoring the ".ARPA" and looking up an address for
"USC-ISIF" in some old style file.
Second, there is an extension to more name components and more top
level domains. The mail system still uses addresses of the form
"local-part@host", where host is a domain style host name.
For example: F.ISI.USC.EDU and Postel@F.ISI.USC.EDU
Here we expect that "F.ISI.USC.EDU" is the name of an Internet
host and that we can send mail for "Postel" to the SMTP port on
that host. It is likely that the NIC will enter these new
domain style names in the centrally maintained table (i.e.,
HOSTS.TXT) during the transition period. It is unlikely that a
backward host can hack this at all.
Third, there is an extension to domain style names that may
represent only organizations or administrative entities. Finding
a host that acts for such entities may require a level of
Domain Implementation Schedule - Revised
indirection in the search. The mail system may use
"local-part@domain-name", where the "domain-name" identifies a
host (as before) or an organization.
For example: USC-ISI.EDU and Postel@USC-ISI.EDU
Here we don't count on "USC-ISI. EDU" being the name of an
Internet host. When we want to send mail to "Postel" we ask
the domain name server about sending mail to "USC-ISI.EDU".
The server will tell us the name (and address) of a real
Internet host that handles mail on this organizations behalf,
for example, "F.ISI.USC.EDU = 10.2.0.52". We then send mail
for "Postel@USC-ISI.EDU" to the SMTP port on F.ISI.USC.EDU.
Name to Address Lookup
Every host in the Internet will be expected to have a way of
translating the name of any other host into its Internet address.
By and large, the name to address translation will be done by
interacting with a lookup server. There will be a number of
servers that each hold a portion of the name to address
information.
The maintenance of the translation data base will be subdivided
and distributed.
The design and implementation details for this service are given
in RFC-882 [2] and RFC-883 [3].
Interface to the World
Mail will continue to move between the Internet and other
"systems". This may be done by designating some sort of
"other-system" representative organization in the domain server
data bases that can indirect mail to a mail-relay host.
For example,
Oberst@EDUCOM.MAILNET
When we want to send mail to "Oberst" we ask the domain name
server about sending mail to "EDUCOM.MAILNET". The server will
tell us the name (and address) of a real Internet host that
handles mail on this organizations behalf, for example,
"MIT-MULTICS.ARPA = 10.0.0.6". We then send mail for
"Oberst@EDUCOM.MAILNET" to the SMTP port on MIT-MULTICS.ARPA.
Domain Implementation Schedule - Revised
For example,
Edmiston@CIC.CSNET
When we want to send mail to "Edmiston" we ask the domain name
server about sending mail to "CIC.CSNET". The server will tell
us the name (and address) of a real Internet host that handles
mail on this organizations behalf, for example,
"CSNET-RELAY.ARPA = 10.4.0.5". We then send mail for
"Edmiston@CIC.CSNET" to the SMTP port on CSNET-RELAY.ARPA.
The Transition Situation
Actually, the situation is a bit more complicated, of course. Hosts
are already using domain style names under the constraint that their
domain style name is exactly their old style name with the string
".ARPA" appended. The first transition step is to ensure that all
hosts do this, and then to eliminate the use of old style names
altogether.
Please note carefully that two types of changes are being made:
One is a change in the support mechanism for translating a host
name to an internet address,
that is from using local copies of a full centrally maintained
table to dynamically accessing a distributed set of servers
each posesing a portion of a data base maintained in a
distributed fashion.
The other is a change in the host names themselves,
from a flat global space of unstructured strings to a
hierarchical structure of names.
There are two steps to the transition plan.
First, change from old names to domain style names.
Second, change from using central tables to using name servers.
There are two communities that are taking slightly different courses
in this transition. The DARPA research community is making the full
transition. The DDN operational community is making the change in
naming on the same schedule, but is not requiring hosts in the DDN
operational community make the change to using servers at the same
Domain Implementation Schedule - Revised
time (they can if they want to). The DDN PMO will establish a
schedule for that change at a later time. The NIC will maintain a
central table of all DDN operational hosts.
Interface to the World
The interchange of mail with "other-systems" will have to continue
pretty much as it has (except that RELAY-HOST is RELAY-HOST.ARPA)
until organization names can be used. Then representative
organizations can be designated for each "other-system" in the
domain server data bases that will then specify a mail-relay host.
All Hosts Change Names
The impact of introducing the domain style names is that all hosts
change their names at least once. Hosts that move to new domains or
subdomains may change their names several times.
Hosts have an official (or primary) name and possibly several
nicknames. When mail is sent from a host, the official name is used
in the mail header address fields.
Suppose, that in the old days before domains were thought of, a host
changed its name. What is the impact on users of changing the name
of a host?
Mail that was sent before the name was changed can not be answered
using mail program commands that automatically fill in the return
address. While it may be possible to use special tricks to fix up
the "From" or the "To" users addresses, the "Cc" addresses are
very difficult to correct.
Suppose one host changed its name from FOO to BAR. Mail that
was sent from FRED@FOO to JOE@ABC can not be answered unless
the change of name is known to the user or the mail program at
ABC and the host name BAR substituted for FOO. Mail that is
sent to JOE@ABC from SAM@DEF with a cc to FRED@FOO can not be
answered easily.
Any mailing lists that have mailboxes with the host that changed
names will now have incorrect entries.
The point is that while the host that changed names may be able to
use special tricks for a while to fix things up for the users, it is
difficult for other hosts to do this.
Domain Implementation Schedule - Revised
A general trick is to make the old name a nickname for the host for
some period of time.
The introduction of domain style names means that all hosts change
their names essentially at the same time.
To lessen the havoc, there will be a period of time when both the old
and the new names are allowed. That is, the old names will be
nicknames for a while.
Primary Names
Currently, host have an official or primary names and may have
several nicknames. For example,
Primary Name Nicknames
USC-ISIF.ARPA USC-ISIF ISIF
ADA-VAX.ARPA ADA-VAX ISI-VAXB AJPO VAXB
The data base is such than given any of the names for a host one can
find the address, and given the address one can find the primary
name.
In the new domain style name system this property must be maintained.
That is, given the Internet address of a host one must be able to
find the primary name of that host. This calls for careful
management of the distributed database by those in charge of the
domains and zones.
Domain Implementation Schedule - Revised
The Revised Time Table
There are three major phases to the implementation of the domain
names system: (1) putting the machinery in place (servers,
resolvers), (2) getting the data base installed, (3) changing the
user programs (mailers, etc.).
The machinery is now (at last) well along, there is a server for
TOPS-20, and two different servers for Unix. The data base now
contains the ARPA domain and is initialized for the other top
level domains. Little has been done to change user programs to
use the new procedures.
Done
Service Design and Specification: The design and specification
for the protocol and data base were published (RFC-882, RFC-883).
Domain Requirements Specification: The requirements for
establishing a new domain are published as an RFC (RFC-920).
Domain Style Names in Table: Hosts are using their domain style
names as their official and primary names. The standard table of
host names contains domain style names as the official and primary
name.
Servers for ARPA Domain: Several domain name servers are in
operation to supply host name to internet address translations,
one of these servers is at the NIC.
15 Dec 84 Domain Table
A master table of top level domain names and their associated
servers is established at the NIC. Probably this information will
be added to the HOSTS.TXT file as a new entry type.
15 Jan 85 Begin New Domain Registration
New domains may register according to the procedures and
restrictions described in RFC-920 [5].
15 Feb 85 Major Machinery Completed
The principal servers are up and running, there are resolvers
programmed and tested for the most popular systems (Unix 4.2bsd,
TOPS-20).
Domain Implementation Schedule - Revised
15 May 85 Significant Use of Resolvers and Servers
Programs (e.g., Mailers, Telnet, FTP) begin regular use of the new
mechanisms (resolvers and servers). This may be done by changing
the programs to act as resolvers themselves and call on servers
directly, or to provide system calls that include the resolver
function to replace old system calls that accessed the host table.
15 Jul 85 Implementation of the Domain Naming System Completed
The goal is to complete the switch over to the domain style names
and the use of the servers by this date. All programs that
translate host name to Internet addresses should now use
procedures based on the use of the domain style names system of
resolvers and servers and the distributed data base.
15 Sep 85 Decommission Host Table
At this point the master host table maintained by the NIC need no
longer be complete for the DARPA research community. A full table
of the DDN operational hosts will be maintained by the NIC.
15 Oct 85 DDN Plan for Domains Name Service
The DDN PMO may establish a plan for the future support of name to
address translations in the DDN community.
Domain Implementation Schedule - Revised
Appendix : The Old Time Table
Here we present the time table from the previous schedule (RFC-897)
with some comments on what was and was not accomplished.
-- Nov 83 Plan and Schedule
At this point the overall plan for the implementation of domain
style names and name servers, and a schedule of events was
published (RFC-881). Also the design and specification for the
protocol and data base were published (RFC-882, RFC-883).
<This was done, but the schedule did not work.>
-- Nov 83 Initial Domain Style Host Name Table
At this point a version of the host table which includes the
domain style names is made available (DHOSTS.TXT).
<This was done, on schedule.>
-- Feb 84 Domain Requirements Specification
At this point the requirements for establishing a new domain are
published as an RFC.
<This topic was much discussed in the Namedroppers mailing
list, but no RFC was published until Oct84 [5].>
14 Mar 84 Begin using Domain Style Names
At this point all hosts should start using their domain style
names as their official and primary names. The standard table of
host names contains domain style names as the official and primary
name (DHOSTS.TXT becomes HOSTS.TXT).
<This was done, on schedule.>
04 Apr 84 Server for ARPA Domain
At this point several domain name servers are in operation to
supply host name to internet address translations, one of these
servers is at the NIC.
<This was done, not on schedule, but by Sep84.>
Domain Implementation Schedule - Revised
04 Apr 84 Domain Table
At this point a master table of top level domain names and their
associated servers is established at the NIC.
<Not done yet.>
02 May 84 Stop using old style Names
At this point the use of old style names must be completely phased
out.
<I think this is done. Except that some hosts still use the
OHOSTS.TXT file.>
02 May 84 Certain New Domains
At this point a few new domains may be established, in particular
the DDN domain.
<Not done yet. Well, "DDN" won't be a top level domain
according to the new rules (see [5]).>
06 Jun 84 General & Multilevel Domains
At this point additional new domains may be established, if they
meet the requirements. Domain style names may have more than two
segments.
<Not done yet.>
18 Jul 84 Organizational Domains
Domain style names may identify organizations. Finding an address
for a host may involve a level of indirection.
<Not done yet.>
05 Sep 84 Decommission Host Table
At this point the master host table maintained by the NIC need no
longer be complete for the DARPA research community. A full table
of the DDN operational hosts will be maintained by the NIC.
<Not done yet.>
Domain Implementation Schedule - Revised
03 Oct 84 DDN Plan for Domains Name Service
At this point the DDN PMO will establish a plan for the future
support of name to address translations in the DDN community.
<Not done yet.>
Domain Implementation Schedule - Revised
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] Postel, J., and J. Reynolds, "Domain Requirements", RFC-920, USC
Information Sciences Institute, October 1984.
[6] 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.
[7] Mockapetris, P., J. Postel, and P. Kirton, "Name Server Design
for Distributed Systems", Proceedings of the Seventh
International Conference on Computer Communication, Sidney,
Australia, October 1984. Also as ISI/RS-84-132, June 1984.
[8] Feinler, E., K. Harrenstien, Z. Su, and V. White, "DoD Internet
Host Table Specification", RFC-810, Network Information Center,
SRI International, March 1982.
[9] Harrenstien, K., V. White, and E. Feinler, "Hostnames Server",
RFC-811, Network Information Center, SRI International,
March 1982.
AI ELI5
On this page
§1The Current Situation
RFC 921 is a policy statement of the IAB and the DARPA on implementing the Domain Style Naming System. It covers three aspects: the names, the way names are translated to addresses, and the relationship between the Internet and the rest of the world.
Until recently hosts had simple names in one flat space. A name had to start with a letter, end with a letter or digit, use only letters, digits or hyphens inside, and case did not matter, for example USC-ISIF. Hierarchical names have a few components separated by periods, written from most specific on the left to most general on the right, for example USC-ISIF.ARPA. So far every name has the form old-simple-name.ARPA, and the ARPA domain is meant to go away.
Name-to-address translation is done with a table of all hosts, called HOSTS.TXT, maintained centrally at the Network Information Center (NIC). Mail to other systems hides their addresses in the local part and uses a mail-relay host, as in EDMISTON.CIC@CSNET-RELAY.ARPA.
Right now every computer has a one-word nickname, and one big phone book at one office lists them all. People want longer, organized names and many small phone books instead.
§2The Planned Design and the Transition
The memo expects names to grow in three levels. First, domain style names simply replace old names, with two components, and still translate through the NIC table. Second, names gain more components and more top-level domains, such as F.ISI.USC.EDU. Third, names may identify only organizations, for example USC-ISI.EDU. Mail for such a name needs a lookup, because the server returns a real host that handles mail for the organization, in the example F.ISI.USC.EDU = 10.2.0.52.
Name-to-address lookup is to be done by a number of servers that each hold part of the data, with the database maintained in a distributed way. The design is in RFC 882 and RFC 883. Mail to other systems is also to go through representative organizations listed in the domain servers, as in Oberst@EDUCOM.MAILNET.
The memo stresses that two changes are being made at once: from a full central table to distributed servers, and from flat names to hierarchical ones. The transition plan has two steps, change to domain style names, then change from central tables to name servers. The DARPA research community makes the full transition. The DDN operational community changes names on the same schedule but need not use servers yet; the DDN PMO will set its own schedule later.
First everyone gets longer, tidier names. Later, instead of one phone book, you ask a helper who knows which small book to check.
§3What Changing Names Costs
All hosts must change their names at least once, and hosts that move to new domains may change several times. A host has an official or primary name and possibly several nicknames, and the official name goes into mail headers.
The memo explains why renaming hurts. Mail sent before a rename cannot be answered with automatic return addresses, Cc addresses are hard to correct, and mailing lists keep stale entries. Its example is a host renamed from FOO to BAR. The general fix is to keep the old name as a nickname for a period, so both old and new names are allowed for a while.
One property must be kept: given any name for a host you can find its address, and given the address you must be able to find the primary name. That calls for careful management of the distributed database by those in charge of the domains and zones.
If you change your name, old letters addressed to you get lost. So for a while you answer to both your old name and your new name.
§4The Revised Time Table
The memo names three phases: putting machinery in place (servers and resolvers), installing the database, and changing user programs such as mailers. The machinery is well along, with a server for TOPS-20 and two for Unix. The database holds the ARPA domain, and little has been done on user programs. Already done: the protocol and database specification (RFC 882, RFC 883), the domain requirements (RFC 920), domain style names as primary names in the table, and servers for the ARPA domain.
The new milestones are:
- 15 Dec 84: master table of top level domains and servers at the NIC.
- 15 Jan 85: new domains may begin to register under RFC 920.
- 15 Feb 85: principal servers running, and resolvers tested for Unix 4.2bsd and TOPS-20.
- 15 May 85: programs such as mailers, Telnet and FTP begin regular use of resolvers and servers.
- 15 Jul 85: the switch to domain style names and servers is to be complete.
- 15 Sep 85: the NIC host table need no longer be complete for the DARPA research community.
- 15 Oct 85: the DDN PMO may establish a plan for name service in the DDN community.
An appendix repeats the earlier time table from RFC 897 with notes on what was done, for example the domain style host table was done on schedule while the domain table, multilevel domains and organizational domains were not yet done.
The calendar lists each step and the date it should be finished, from getting helpers set up to finally retiring the big phone book.
- 198415 Dec: master table of top level domains at the NIC
- 198515 Jan: new domain registration begins
- 198515 Feb: major machinery completed
- 198515 May: significant use of resolvers and servers
- 198515 Jul: implementation completed
- 198515 Sep: host table decommissioned for DARPA community
- 198515 Oct: DDN plan for name service