|
|
|
|
|||||
|
|
|
|||
|
|
|
|
|
|||||||||||||||||||||||||||||||||||||||||
|
|
|
|||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||
[Text version]
Networking Working Group
Request for Comments: 1031W. Lazear
MITRE
November 1987
- 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.
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.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 hostIn 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- 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 SpecificationThis 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.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.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.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.This RFC specifies the format of the host/address table maintained by the NIC.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.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.This RFC describes the guidelines for a domain administrator to follow to establish a new domain.This RFC provides procedures for domain administrators in operating a domain server and maintaining their portion of the hierarchical database.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.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.txtHis mail addresses are:
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:
- 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.
US MAIL: Computer Systems Research Group Computer Science Division Department of EE & CS University of California Berkeley, CA 94720A commercial version of BIND is distributed with Sun Microsystems' operating system version 3.2. The point of contact is Bill Nowicki. His addresses are:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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