summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1031.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1031.txt')
-rw-r--r--doc/rfc/rfc1031.txt557
1 files changed, 557 insertions, 0 deletions
diff --git a/doc/rfc/rfc1031.txt b/doc/rfc/rfc1031.txt
new file mode 100644
index 0000000..0d20111
--- /dev/null
+++ b/doc/rfc/rfc1031.txt
@@ -0,0 +1,557 @@
+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
+
+
+
+Lazear [Page 1]
+
+RFC 1031 MILNET DOMAIN TRANSITION November 1987
+
+
+ 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
+
+
+
+Lazear [Page 2]
+
+RFC 1031 MILNET DOMAIN TRANSITION November 1987
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+Lazear [Page 3]
+
+RFC 1031 MILNET DOMAIN TRANSITION November 1987
+
+
+ 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.
+
+
+
+Lazear [Page 4]
+
+RFC 1031 MILNET DOMAIN TRANSITION November 1987
+
+
+ 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.
+
+
+
+
+Lazear [Page 5]
+
+RFC 1031 MILNET DOMAIN TRANSITION November 1987
+
+
+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
+
+
+
+Lazear [Page 6]
+
+RFC 1031 MILNET DOMAIN TRANSITION November 1987
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lazear [Page 7]
+
+RFC 1031 MILNET DOMAIN TRANSITION November 1987
+
+
+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
+
+
+
+Lazear [Page 8]
+
+RFC 1031 MILNET DOMAIN TRANSITION November 1987
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+Lazear [Page 9]
+
+RFC 1031 MILNET DOMAIN TRANSITION November 1987
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lazear [Page 10]
+