MILNET Domain Transition: MILNET name domain transition
The 1987 plan for moving the MILNET community from host tables to domain names.
Lazear, W.D., "MILNET name domain transition", RFC 1031, DOI 10.17487/RFC1031, November 1987, <https://www.rfc-editor.org/info/rfc1031>.
@misc{rfc1031,
series = {Request for Comments},
number = 1031,
howpublished = {RFC 1031},
publisher = {RFC Editor},
doi = {10.17487/RFC1031},
url = {https://www.rfc-editor.org/info/rfc1031},
author = {W.D. Lazear},
title = {{MILNET name domain transition}},
pagetotal = 10,
year = 1987,
month = nov,
} RFC text
Contents
Networking Working Group W. Lazear
Request for Comments: 1031 MITRE
November 1987
MILNET NAME DOMAIN TRANSITION
STATUS OF THIS MEMO
This RFC consolidates information necessary for the implementation of
domain style names throughout the DDN/MILNET Internet community.
Although no official policy has been published, the introduction of
domain style names will impact all hosts in the DDN/MILNET Internet.
The RFC is designed as an aid to implementors and administrators by
providing 1) an overview of the transition process from host tables
to domains, 2) a potential timetable for the transition, and 3)
references to documentation and software relating to the DDN/ARPANET
domain system. Distribution of this RFC is unlimited.
BACKGROUND
All MILNET hosts are expected to have a way of translating the name
of any other host into its Internet address. Although the current
method of name resolution is to look up the information in a table of
all hosts, this method of operation is cumbersome and relies on a
central point of information. The Network Information Center (NIC)
maintains a table of hosts registered in the MILNET Internet and
their addresses. The size of this table and the frequency of updates
has reached the limits of manageability. The central host table is
FTP'd by a host on a timely basis from the NIC, processed locally (to
pare or reformat the table), and used in name resolution.
The domain system uses a distributed database and software to perform
the same functions as the host table. In this system, host resolvers
query domain servers for name resolution. They may cache answers for
performance improvement. The domain servers each maintain a portion
of the hierarchical database under separate administrative authority
and control. Redundancy is obtained by transferring data between
cooperating servers.
The domain system has been operating successfully on the ARPANET for
over a year. One indication of success is that the NIC's central
host table is no longer a complete list (i.e., ARPANET does not
depend primarily on the host table). The domain system is being
implemented on the MILNET with DoD military standard protocols. The
first step in changing to the domain system has been taken, as
required by DDN Management Bulletin #32 (22 Jan 1987). All host
names were converted from a simple, flat namespace to a structured
name consistent with domains. In the second step, servers acting as
the root of the database hierarchy were put in place. In the next
step, hosts are moving away from host table usage.
MIGRATION PATH
All hosts will not change from host table to domain server usage at
one time. Accordingly, three stages of conversion to the domain
system are envisaged. These stages roughly correspond to 1)
continuing to use the host table for all applications, 2) using the
domain system for only some applications, and 3) using the domain
system for all applications. These stages will exist simultaneously
as various hosts convert their application software according to
available resources. The following paragraphs discuss these stages
in more detail.
Host Table Only
In the first stage, a host depends entirely on the host table for
name resolution. The table is obtained from the NIC's central
copy and the resolution is done by local table scanning. Most
hosts are in this stage.
Certain hosts may find it infeasible ever to convert to the domain
system, owing to older architectures, unchangeable software, or
other considerations. At the end of the conversion period, the
NIC will stop maintaining an internet host table. To continue
operations, hosts that do not convert will need to obtain an
equivalent of the host table from some source. This source may be
another host with which a bilateral agreement has been negotiated
offline, a community-of-interest host acting as central repository
for that community, or a locally-maintained table of host names
and addresses. Transfer of the table from the source is a matter
of local implementation and bilateral agreements.
Domain System and Host Table
In the second stage, a host will use both the host table and the
domain system. A likely scenario is that applications like TELNET
and FTP will use the domain system and that MAIL will continue to
use the host table for name resolution. An alternate scenario is
that batchstyle applications like MAIL would use the domain system
and that the interactive applications would convert later.
This stage is viewed as transitory, as hosts convert over to use
the domain system exclusively. It is highlighted as a separate
stage to emphasize the need during transition for both the host
table and the domain system.
Domain System Only
In the third and final stage, a host will have completed
conversion and will be using the domain system exclusively. This
includes correct processing of the mailbox and mail exchanger
resource records.
MIGRATION TIMETABLE
Table 1 shows the events and dates involved in the MILNET transition
from host table to domain system. The operational testing of the
root server software has been completed. Voluntary conversion can
begin immediately, with mandatory conversion required by October
1989. After this date, hosts not converted need to obtain the host
table equivalent by private arrangement (see "Migration Path" above).
Start End
Milestone Date Date
=========================================== ====== ======
Root server operational testing Dec 86 Jul 87
Policy announced in DDN Management Bulletin Oct 87
Host conversion Oct 87 Oct 89
Host table discontinued Oct 89
MILNET Name Domain Timetable
Table 1
DOCUMENTATION
The Name Domain system is described in several documents that are
maintained and available from the NIC in both online and in hardcopy
form. The documents are in "Request For Comments" format (RFC)
commonly used in the Internet to document and discuss various
networking issues. The documents noted in Table 2 fully describe the
concepts, conventions, enhancements, requirements, and operation of
the Name Domain system. The following paragraphs give a brief
synopsis of each document.
RFC PH DOCUMENT TITLE
=== == =======================================================
799 * Internet Name Domains
819 Domain Naming Convention for Internet User Applications
920 Domain Requirements
921 Domain Name System Implementation Schedule - Revised
952 * Internet Host Table Specification
953 * Hostnames Server
974 Mail Routing and the Domain System
1032 Domain Administrators Guide
1033 Domain Administration Operations Guide
1034 Domain Names - Concepts and Facilities
1035 Domain Names - Implementation Specification
* Included in the DDN Protocol Handbook
Name Domain Documents
Table 2
RFC-799
This RFC is an early description of the concepts of a name domain
system. It is exploratory in nature and offers scenarios for name
resolution and mail forwarding.
RFC-819
This RFC is a think peice about hierarchical naming conventions
for internetworking applications. The conventions proposed are
aligned along administrative rather than topological boundaries
and is designed for interoperation among heterogeneous naming
environments. Further topics of discussion include mail relaying,
name service approaches, and naming authorities.
RFC-920
This RFC contains a policy statement on the requirements of
establishing a new domain in the ARPA Internet and introduces the
limited set of top level domains.
RFC-921
This RFC contains a policy statement on the implementation
schedule of the ARPA Internet domain system (as of October 1984).
The discussion describes schedule and future operational
scenarios, as well as the transition between the two.
RFC-952
This RFC specifies the format of the host/address table maintained
by the NIC.
RFC-953
This RFC contains the official specification of the Hostname
Server Protocol. This TCP-based protocol accesses machine-
readable name/address information in the format described by RFC-
952 and is used by hosts to obtain all or a portion of the
centralized host table.
RFC-974
This RFC presents a description of how mail systems are expected
to route messages based on domain system information. In
particular, it discusses how mailers should interpret mail
exchanger resource records for message routing to both host and
domain names.
RFC-1032
This RFC describes the guidelines for a domain administrator to
follow to establish a new domain.
RFC-1033
This RFC provides procedures for domain administrators in
operating a domain server and maintaining their portion of the
hierarchical database.
RFC-1034
This RFC introduces domain style names, their use for ARPA
Internet mail and host address support, and the protocols and
servers used to implement domains. The concepts and facilities of
the domain system are described. The RFC also discusses the
hierarchical database model, resource record usage, query
formation, query resolution, and domain control.
RFC-1035
This RFC specifies the format of domain system transactions,
discusses the implementation of domain servers, and explores the
use of domain names in the context of mail and other network
software.
IMPLEMENTATIONS
Several implementations of the domain system exist. The first two
paragraphs (JEEVES and BIND) discuss the prominent (and most mature)
two implementations and their authors/maintainers. These
implementations are available online. The last paragraphs list
implementations under development. Points of contact can supply more
information.
The intent of listing these implementations is to give vendors the
opportunity to inspect working code. These implementations embody
experience with the domain system and offer interpretations of the
protocols found acceptable in operational environments.
Tops-20 Server and Resolver (JEEVES)
Some domain root servers on the ARPANET are hosted on TOPS-20 systems
and run the code called JEEVES. The JEEVES resolver is specific to
version 5 of TOPS-20. The code is maintained by Paul Mockapetris
(ISI), is available using anonymous FTP from host a.isi.edu, and
resides in the files
<domain.version5>version5.mss
<domain.version5>version5.doc
<domain.version5>version5.txt
His mail addresses are:
ARPANET: pvm@venera.isi.edu
US MAIL: USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, California 90292-6695
4BSD Unix Resolver and Server (BIND)
Most hosts running lower level domain servers on the ARPANET are
hosted on 4BSD systems and run the code called BIND. This code is
maintained for periodic releases by Mike Karels (UCB). His mail
addresses are:
ARPANET: karels@okeeffe.berkeley.edu
US MAIL: Computer Systems Research Group
Computer Science Division
Department of EE & CS
University of California
Berkeley, CA 94720
There are two distribution mailing lists that publish information
about BIND. General discussions can be received by contacting
bindrequest@ucbarpa.berkeley.edu and requesting to join the BIND
list. Information relating to testing developmental versions of BIND
can be received by contacting bind-test-request@ucbarpa.berkeley.edu
and requesting to join the BIND-TEST list.
A commercial version of BIND is distributed with Sun Microsystems'
operating system version 3.2. The point of contact is Bill Nowicki.
His addresses are:
ARPANET: nowicki@sun.com
US MAIL: Sun Microsystems
2550 Garcia Avenue
Mountain View, CA 94043
MS-DOS Server and Resolver
FTP Software is working on a port of BIND to their PC/TCP environment
under MS/DOS (their PC/TCP package). They already have a resolver
that depends on recursive queries. The point of contact is Philip A.
Prindeville. His mail addresses are:
ARPANET: pap4@ai.ai.mit.edu
US MAIL: FTP Software Inc
P.O. Box 150
Kendall Sq. Branch
Boston, MA 02142
Tops-20 Resolver
A resolver is being written in C for Tops-20 and ITS by Rob Austein.
He encourages contacts from Tops-10, WAITS, and TENEX system
programmers. His mail addresses are:
ARPANET: sra@xx.lcs.mit.edu.
US MAIL: MIT LCS NE43-503
545 Technology Square
Cambridge MA 02139
Symbolics Resolver
Symbolics Inc. has an implementation for the 36xx series Lisp
Machines. Steven L. Sneddon is the point of contact. His addresses
are:
ARPANET: sned@pegasus.scrc.symbolics.com
US MAIL: Manager, Networks and Communications
Symbolics, Inc.
11 Cambridge Center
Cambridge, MA 02142
Xerox Cedar Resolver
Xerox has a resolver running in the Cedar language/environment at
Xerox PARC. John Larson is the point of contact. His addresses are:
ARPANET: jlarson.pa@xerox.com
US MAIL: Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304
Harris Resolver
There is a domain resolver for the Harris H series that handles
canonical name, host address, name server, and mail agent (MX)
records. Bruce Orchard is the point of contact. His addresses are:
ARPANET: orchard/bruc@scarecrow.waisman.wisc.edu
US MAIL: 549 Waisman Center
University of Wisconsin-Madison
1500 Highland Avenue
Madison, Wisconsin 53705-2280
Fuzzball Server and Resolver
Dave Mills has both server and solver for the so-called PDP11/LSI- 11
Fuzzballs. However, these are not complete implementations and do
not support zone transfers and so forth. They have little use
outside the fuzzball community, since the code is in assembler and is
not for Unix. His addresses are:
ARPANET: mills@udel.edu
US MAIL: Electrical Engineering Department
University of Delaware
Newark, DE 19716
Multics Resolver
There is a resolver for Multics that is nearly ready for release.
Art Beattie is the point of contact. His addresses are:
ARPANET: beattie%pco@bco-multics.arpa
US MAIL: MS K55
Honeywell Bull
PO Box 8000
Phoenix, AZ, 85066-8000
VAX/VMS Resolver
There is a partial resolver implementation (only supports address
queries and IN-ADDR PTR lookups) that is part of the CMU/TEK TCP/IP
package for VAX/VMS. It is written in BLISS-32. Vince Fuller is the
point of contact. His addresses are:
ARPANET: vince.fuller@c.cs.cmu.edu
US MAIL: Computer Science Department
Carnegie-Mellon University
Schenley Park
Pittsburgh, Pa. 15213
Macintosh Resolver and Server
Tom Unger has ported BIND to the Macintosh. This was done using the
Macintosh Programmer's Workshop and CITI's MacIP that currently
consists of IP, UDP, and a Berkeley style socket library. His mail
addresses are:
ARPANET: tom@citi.umich.edu
US MAIL: Center for Information and Technology Integration
University of Michigan
2901 Hubbard
Ann Arbor, MI 48105
ORDERING INFORMATION
Documents are available online from the NIC (IP address 10.0.0.51 or
26.0.0.73) by using FTP with the login ANONYMOUS and the password
GUEST. RFCs are in files named RFC:RFCnnn.TXT and are simple ASCII
files ready for printing. Pages within the documents are separated
by a form feed character on a line by itself.
Hardcopy of the documents and software mentioned in the discussions
above may be obtained from the NIC or the author. Prices are
available on request and are documented in DDN Newsletter #50 (12 Dec
1986). The address and phone numbers of the NIC are listed below.
DDN Network Information Center
SRI International, Room EJ291
333 Ravenswood Avenue
Menlo Park, CA 94025
(800) 235-3155
(415) 859-3695
ISO Plain Language
On this page
§1What This Document Is For
The RFC consolidates the information needed to implement domain style names throughout the DDN/MILNET Internet community. Although no official policy has been published, the introduction of domain style names will affect all hosts in the DDN/MILNET Internet, so the document is written as an aid to implementors and administrators.
It provides three things: an overview of the transition process from host tables to domains, a potential timetable for the transition, and references to documentation and software relating to the DDN/ARPANET domain system.
This is a briefing for the people who have to make the change: what is happening, when it has to happen, and where to find the specification and the code.
§2Host Tables and the Domain System
All MILNET hosts are expected to have a way of translating the name of any other host into its Internet address. The current method of name resolution is to look the information up in a table of all hosts, which is cumbersome and relies on a central point of information. The Network Information Center maintains the table of hosts registered in the MILNET Internet and their addresses, and the size of that table and the frequency of updates had reached the limits of manageability. The central host table is fetched by a host on a timely basis from the NIC, processed locally to pare or reformat the table, and used in name resolution.
The domain system uses a distributed database and software to perform the same functions as the host table. In this system, host resolvers query domain servers for name resolution and may cache answers for performance. The domain servers each maintain a portion of the hierarchical database under separate administrative authority and control, and redundancy is obtained by transferring data between cooperating servers.
The domain system had been operating successfully on the ARPANET for over a year. One indication of that success was that the NIC's central host table was no longer a complete list: the ARPANET no longer depended primarily on the host table. The domain system was being implemented on the MILNET with DoD military standard protocols, and the first step of the change had already been taken as required by DDN Management Bulletin number 32 of 22 January 1987: all host names were converted from a simple, flat namespace to a structured name consistent with domains. In the second step, servers acting as the root of the database hierarchy were put in place, and in the next step hosts were to move away from host table usage.
The old way was one big list, kept in one place and copied to everybody. The new way is a hierarchy: each server holds the part of the naming tree it is responsible for, and a machine asks a server rather than reading a file. The ARPANET had been running this way for a year by the time this RFC was written.
§3Three Stages of Conversion
Not all hosts will change from host table to domain server usage at one time, so three stages of conversion are envisaged. They roughly correspond to continuing to use the host table for all applications, using the domain system for only some applications, and using the domain system for all applications. The stages exist simultaneously as various hosts convert their application software according to available resources.
In the first stage, host table only, a host depends entirely on the host table for name resolution. The table is obtained from the NIC's central copy and the resolution is done by local table scanning. Most hosts are in this stage. Certain hosts may find it infeasible ever to convert, owing to older architectures, unchangeable software or other considerations, and at the end of the conversion period the NIC will stop maintaining an internet host table. To continue operations, hosts that do not convert will need to obtain an equivalent of the host table from some source: another host with which a bilateral agreement has been negotiated offline, a community-of-interest host acting as central repository for that community, or a locally-maintained table of host names and addresses. Transfer of the table from the source is a matter of local implementation and bilateral agreements.
In the second stage, domain system and host table, a host uses both. A likely scenario is that applications such as TELNET and FTP use the domain system while MAIL continues to use the host table for name resolution; an alternate scenario is that batch-style applications such as MAIL use the domain system and the interactive applications convert later. This stage is viewed as transitory, as hosts convert over to using the domain system exclusively, and it is highlighted as a separate stage to emphasize the need during the transition for both the host table and the domain system.
In the third and final stage, domain system only, a host has completed conversion and uses the domain system exclusively, including correct processing of the mailbox and mail exchanger resource records.
Hosts move over one application at a time. First everything still uses the old list; then some applications use the new system and others still use the list; eventually everything uses the new system. A machine that is too old to change will have to find its own copy of the list, because the central one is going away.
| Stage | What the host uses | Notes |
|---|---|---|
| Host table only | The central list, copied from the NIC and scanned locally. | Most hosts were in this stage. |
| Domain system and host table | Both, for different applications. | Viewed as transitory. TELNET and FTP might move first, or MAIL might. |
| Domain system only | The domain system alone. | Includes correct processing of mailbox and mail exchanger records. |
§4The Timetable
The table of milestones for the MILNET transition from host table to domain system sets four events with their dates. The operational testing of the root server software ran from December 1986 to July 1987. The policy was announced in a DDN Management Bulletin in October 1987. Host conversion ran from October 1987 to October 1989. The host table was discontinued in October 1989.
The operational testing of the root server software has been completed, voluntary conversion can begin immediately, and mandatory conversion is required by October 1989. After that date, hosts that have not converted need to obtain the host table equivalent by private arrangement, as described in the migration path above.
The servers were tested over the second half of 1986 and the first half of 1987. The policy was announced in the autumn of 1987, and the two years after that were for hosts to convert. When the period ended in October 1989, the central list was withdrawn.
- 1986Root server operational testing begins in December
- 1987Root server operational testing ends in July; the policy is announced in a DDN Management Bulletin in October
- 1989Mandatory conversion and discontinuation of the host table, both in October
§6Where to Get the Documents
The documents are available online from the NIC, at IP address 10.0.0.51 or 26.0.0.73, by using FTP with the login ANONYMOUS and the password GUEST. The RFCs are in files named RFC:RFCnnn.TXT and are simple ASCII files ready for printing, with pages separated by a form feed character on a line by itself.
Hardcopy of the documents and of the software mentioned in the discussions above may be obtained from the NIC or from the author. Prices are available on request and are documented in DDN Newsletter number 50 of 12 December 1986.
Everything was published in the ordinary way: fetch the files by anonymous FTP from the NIC, or order paper copies. The machine-readable copies were plain text with form feeds between pages, ready to print.