Difference between revisions of "RFC1031"

From RFC-Wiki
imported>Admin
(Created page with "Networking Working Group W. Lazear Request for Comments: 1031 MITRE ...")
 
Line 1: Line 1:
Networking Working Group                                      W. Lazear
+
Networking Working Group                                      W. LazearRequest for Comments: 1031                                        MITRE                                                           November 1987                     MILNET NAME DOMAIN TRANSITIONSTATUS 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 hostLazear                                                          [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 hostLazear                                                          [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 1DOCUMENTATION  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 1987IMPLEMENTATIONS  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:  [email protected]             US MAIL:  USC Information Sciences Institute                       4676 Admiralty Way                       Marina del Rey, California 90292-66954BSD 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:  [email protected]             US MAIL:  Computer Systems Research Group                       Computer Science Division                       Department of EE & CS                       University of California                       Berkeley, CA  94720Lazear                                                          [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   [email protected] and requesting to join the BIND   list.  Information relating to testing developmental versions of BIND   can be received by contacting [email protected]   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:  [email protected]             US MAIL:  Sun Microsystems                       2550 Garcia Avenue                       Mountain View, CA 94043MS-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:  [email protected]             US MAIL:  FTP Software Inc                       P.O. Box 150                       Kendall Sq. Branch                       Boston, MA  02142Lazear                                                          [Page 7]RFC 1031                MILNET DOMAIN TRANSITION          November 1987Tops-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:  [email protected].             US MAIL:  MIT LCS NE43-503                       545 Technology Square                       Cambridge MA 02139Symbolics Resolver   Symbolics Inc. has an implementation for the 36xx series Lisp   Machines.  Steven L. Sneddon is the point of contact.  His addresses   are:             ARPANET:  [email protected]             US MAIL:  Manager, Networks and Communications                       Symbolics, Inc.                       11 Cambridge Center                       Cambridge, MA 02142Xerox 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:  [email protected]             US MAIL:  Xerox Palo Alto Research Center                       3333 Coyote Hill Road                       Palo Alto, CA  94304Harris 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/[email protected]             US MAIL:  549 Waisman Center                       University of Wisconsin-Madison                       1500 Highland Avenue                       Madison, Wisconsin  53705-2280Lazear                                                          [Page 8]RFC 1031                MILNET DOMAIN TRANSITION          November 1987Fuzzball 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:  [email protected]             US MAIL:  Electrical Engineering Department                       University of Delaware                       Newark, DE 19716Multics 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%[email protected]             US MAIL:  MS K55                       Honeywell Bull                       PO Box 8000                       Phoenix, AZ, 85066-8000VAX/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:  [email protected]             US MAIL:  Computer Science Department                       Carnegie-Mellon University                       Schenley Park                       Pittsburgh, Pa.  15213Lazear                                                          [Page 9]RFC 1031                MILNET DOMAIN TRANSITION          November 1987Macintosh 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:  [email protected]             US MAIL:  Center for Information and Technology Integration                       University of Michigan                       2901 Hubbard                       Ann Arbor, MI 48105ORDERING 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-3695Lazear                                                        [Page 10]
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:  [email protected]
 
 
 
          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:  [email protected]
 
 
 
          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
 
[email protected] and requesting to join the BIND
 
list.  Information relating to testing developmental versions of BIND
 
can be received by contacting [email protected]
 
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:  [email protected]
 
 
 
          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:  [email protected]
 
 
 
          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:  [email protected].
 
 
 
          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:  [email protected]
 
 
 
          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:  [email protected]
 
 
 
          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/[email protected]
 
 
 
          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:  [email protected]
 
 
 
          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%[email protected]
 
 
 
          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:  [email protected]
 
 
 
          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:  [email protected]
 
 
 
          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
 

Revision as of 22:28, 22 September 2020

Networking Working Group W. LazearRequest for Comments: 1031 MITRE November 1987 MILNET NAME DOMAIN TRANSITIONSTATUS 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 hostLazear [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 hostLazear [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 1DOCUMENTATION 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 1987IMPLEMENTATIONS 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: [email protected] US MAIL: USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, California 90292-66954BSD 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: [email protected] US MAIL: Computer Systems Research Group Computer Science Division Department of EE & CS University of California Berkeley, CA 94720Lazear [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 [email protected] and requesting to join the BIND list. Information relating to testing developmental versions of BIND can be received by contacting [email protected] 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: [email protected] US MAIL: Sun Microsystems 2550 Garcia Avenue Mountain View, CA 94043MS-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: [email protected] US MAIL: FTP Software Inc P.O. Box 150 Kendall Sq. Branch Boston, MA 02142Lazear [Page 7]RFC 1031 MILNET DOMAIN TRANSITION November 1987Tops-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: [email protected]. US MAIL: MIT LCS NE43-503 545 Technology Square Cambridge MA 02139Symbolics Resolver Symbolics Inc. has an implementation for the 36xx series Lisp Machines. Steven L. Sneddon is the point of contact. His addresses are: ARPANET: [email protected] US MAIL: Manager, Networks and Communications Symbolics, Inc. 11 Cambridge Center Cambridge, MA 02142Xerox 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: [email protected] US MAIL: Xerox Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304Harris 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/[email protected] US MAIL: 549 Waisman Center University of Wisconsin-Madison 1500 Highland Avenue Madison, Wisconsin 53705-2280Lazear [Page 8]RFC 1031 MILNET DOMAIN TRANSITION November 1987Fuzzball 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: [email protected] US MAIL: Electrical Engineering Department University of Delaware Newark, DE 19716Multics 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%[email protected] US MAIL: MS K55 Honeywell Bull PO Box 8000 Phoenix, AZ, 85066-8000VAX/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: [email protected] US MAIL: Computer Science Department Carnegie-Mellon University Schenley Park Pittsburgh, Pa. 15213Lazear [Page 9]RFC 1031 MILNET DOMAIN TRANSITION November 1987Macintosh 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: [email protected] US MAIL: Center for Information and Technology Integration University of Michigan 2901 Hubbard Ann Arbor, MI 48105ORDERING 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-3695Lazear [Page 10]