RFC 897: Domain name system implementation schedule

This RFC was updated

Network Working Group Jon Postel
Request for Comments: 897 ISI
 February 1984
Updates: RFC 881

 Domain Name System Implementation Schedule


Status of this Memo

 This memo is a policy statement on the implementation of the Domain
 Style Naming System in the Internet. This memo is a partial update
 of RFC 881. This is an official policy statement of the ICCB and the
 DARPA.

 The intent of this memo is to detail the schedule for the
 implementation for the Domain Style Naming System. The explanation
 of how this system works is to be found in the references.

The Current Situation

 Simple Names

 Hosts in the ARPA research and DDN operational communities are
 currently assigned names in a flat or global name space of
 character strings. There are some limits on these names. They
 must start with a letter, end with a letter or digit and have only
 letters or digits or hyphen as interior characters. Case is not
 significant.

 For example: USC-ISIF

 Tables

 Every host in the Internet is expected to have a way of
 translating the name of any other host into its Internet address.

 By and large, the name to address translation is done by looking
 up the information in a table of all hosts.

 The maintenance of this table is centralized at the Network
 Information Center (NIC). Each host is expected to obtain a
 current copy of the table on a timely basis.

 Interface to the World

 A great deal of mail moves between the Internet and other
 "systems" that somehow transport mail among computers. This is
 currently done by hiding some sort of "other-system" addressing
 information in the local-part of the mail address and using a
 mail-relay host in the host-part of the mailbox.


Postel [Page 1]

RFC 897 February 1984
Domain Implementation Schedule


 For example,

 OBERST%EDUCOM.MAILNET@MIT-MULTICS
 EDMISTON.CIC@CSNET-RELAY

The Future Situation

 Hierarchical Names

 Because of the growth of the Internet, structured names (or domain
 style names) will be used. Each element of the structured name
 will be a character string (with the same constraints that
 previously applied to the simple names).

 For example: F.ISI.USC.ARPA

 Servers

 Every host in the Internet will be expected to have a way of
 translating the name of any other host into its Internet address.

 By and large, the name to address translation will be done by
 interacting with a service. There will be a number of servers
 that each hold a portion of the name to address information.

 The maintenance of the translation data will be subdivided and
 distributed.

 There are several stages of implementation for the servers and
 several levels of development for use of the domain style names.

 First, there is the simple substitution of the domain style names
 for the current host names, and the subdivision of these into
 several domains. At this stage all domain style names directly
 translate to host addresses and all domain style names have two
 components.

 For example: USC-ISIF.ARPA or USC-ISIA.DDN

 and: Postel@USC-ISIF.ARPA or Kahn@USC-ISIA.DDN

 Here we expect that "USC-ISIF.ARPA" is the name of an Internet
 host and that we can send mail for "Postel" to the SMTP port on
 that host. It may be that some backward host can still fake it
 by ignoring the ".ARPA" and looking up an address for
 "USC-ISIF".



Postel [Page 2]

RFC 897 February 1984
Domain Implementation Schedule


 Using the domain name servers (but not the tables) mail
 forwarding may be supported. A domain name server query can
 say "I want to send mail to ABCDEF.ARPA". The response might
 be "to send mail to ABCDEF.ARPA send it to the mail relay
 GHIJKL.ARPA at address 123.123.123.123".

 Second, there is an extension to more name components.

 For example: F.ISI.USC.ARPA or A.USC-ISI.DDN

 and: Postel@F.ISI.USC.ARPA or Kahn@A.USC-ISI.DDN

 Here we expect that "F.ISI.USC.ARPA" is the name of an Internet
 host and that we can send mail for "Postel" to the SMTP port on
 that host. It is unlikely that a backward host can hack this
 at all.

 Third, there is an extension to domain style names that may
 represent only organizations or administrative entities. Finding
 a host that represents such entities may require a level of
 indirection in the search.

 For example: USC-ISI.ARPA or ARPA.DDN

 and: Postel@USC-ISI.ARPA or Kahn@ARPA.DDN

 Here we don't count on "USC-ISI.ARPA" being the name of an
 Internet host. When we want to send mail to "Postel" we ask
 the domain name server about sending mail to "USC-ISI.ARPA".
 The server will tell us the name (and address) of a real
 Internet host that handles mail on this organizations behalf,
 for example, "F.USC-ISI.ARPA = 10.2.0.52". We then send mail
 for "Postel" to the SMTP port on F.USC-ISI.ARPA.

 Interface to the World

 Mail will continue to move between the Internet and other
 "systems". This may be done by designating some sort of
 "other-system" representative organization in the domain server
 data bases that can indirect mail to a mail-relay host.

 For example,

 OBERST@EDUCOM.MAILNET
 EDMISTON@CIC.CSNET




Postel [Page 3]

RFC 897 February 1984
Domain Implementation Schedule


The Transition Situation

 Actually, the situation is a bit more complicated, of course. A
 number of hosts are already using domain style names under the
 constraint that their domain style name is exactly their old style
 name with the string ".ARPA" appended. The first transition step is
 to have all hosts do this, and then to eliminate the user of old
 style names altogether.

 Please note carefully that two types of changes are being made:

 One is a change in the support mechanism for translating a host
 name to an internet address,

 that is from using local copies of a full centrally maintained
 table to dynamically accessing a distributed set of servers
 each posesing a portion of a data base maintained in a
 distributed fashion.

 The other is a change in the host names themselves,

 from a flat global space of unstructured strings to a
 hierarchical structure of names.

 There are four steps to the transition plan.

 First, change from old names to domain style names.

 host-name --> host-name.ARPA

 Second, one domain to a few domains.

 host-name.ARPA --> host-name.ARPA and host-name.DDN

 Third, change from using central tables to using name servers.

 Fourth, allow many domains.

 There are two communities that are taking slightly different courses
 in this transition. The ARPA research community is making the full
 transition. The DDN operational community is making the change in
 naming on the same schedule, but is not requiring hosts in the DDN
 operational community make the change to using servers at the same
 time (they can if they want to). The DDN PMO will establish a
 schedule for that change at a later time. The NIC will maintain a
 central table of all DDN operational hosts.



Postel [Page 4]

RFC 897 February 1984
Domain Implementation Schedule


 Interface to the World

 The interchange of mail with "other-systems" will have to continue
 pretty much as it does now (except that RELAY-HOST will become
 RELAY-HOST.ARPA) until organization names can be used. Then
 representative organizations can be designated for each
 "other-system" in the domain server data bases that will then
 indirectly specify a mail-relay host.

Policy Statement

 The names of hosts will be changed to domain style names. Hosts will
 begin to use domain style names on 14-Mar-84 and the use of old style
 names will be completely phased out before 2-May-84.

 This applies to both the ARPA research hosts and the DDN operational
 hosts.

Implication

 All Hosts Change Names

 The impact of introducing the domain style names is that all hosts
 change their names at least once. Hosts that move to new domains
 or subdomains may change their names several times.

 Hosts have an official (or primary) name and possibly several
 nicknames. When mail is sent from a host, the official name is
 used in the mail header address fields.

 Suppose, that in the old days before domains were thought of, a
 host changed its name. What is the impact on users of changing
 the name of a host? Suppose one host changed its name from FOO to
 BAR.

 Mail

 Mail that was sent before the name was changed can not be
 answered using mail program commands that automatically fill
 in the return address. While it may be possible to use
 special tricks to fix up the "From" or the "To" users
 addresses, the "Cc" addresses are very difficult to correct.

 Mail that was sent to JOE@ABC from FRED@FOO can not be
 answered unless the change of name is known to the user or
 the mail program an ABC and the host name BAR substituted
 for FOO.


Postel [Page 5]

RFC 897 February 1984
Domain Implementation Schedule


 Mail that is sent to JOE@ABC from SAM@DEF with a cc to
 FRED@FOO can not be answered easily.

 Mailing Lists

 Any mailing lists that have mailboxes on the host that
 changed names will now have incorrect entries.

 The point is that while the host that changed names may be able to
 use special tricks for a while to fix things up for the users, it
 is difficult for other hosts to do this.

 A general trick is to make the old name a nickname for the host
 for some period of time.

 The introduction of domain style names means that all hosts change
 their names essentially at the same time.

 For example, USC-ISIF changes to USC-ISIF.ARPA

 To lessen the resulting havoc, the initial set of new names has a
 fixed relationship to the old names. The first set of domain
 style names is exactly the old names with the domain name "ARPA"
 appended. That is, if a hosts old name was "HOST-NAME", then its
 new name is "HOST-NAME.ARPA".

 To further lessen the havoc, there will be a period of time when
 both the old and the new names are allowed. That is, the old
 names will be nicknames for a while.

 Primary Names

 In to old style names, host have an official or primary names and
 may have several nicknames. For example,

 Primary Name Nicknames

 USC-ISIF ISIF

 ADA-VAX ISI-VAXB AJPO VAXB

 In any case, the data base in such than given any of the names for
 a host one can find the address, and given the address one can
 find the primary name.

 In the new domain style name system this property must be
 maintained. That is, given the Internet address of a host one


Postel [Page 6]

RFC 897 February 1984
Domain Implementation Schedule


 must be able to find the primary name of that host. This calls
 for careful management of the distributed database by those in
 charge of the domains and subdomains.

The Time Table

 -- Nov 83 Plan and Schedule

 At this point the overall plan for the implementation of domain
 style names and name servers, and a schedule of events was
 published (RFC-881). Also the draft design and specification for
 the protocol and data base were published (RFC-882, RFC-883).

 -- Nov 83 Initial Domain Style Host Name Table

 At this point a version of the host table which includes the
 domain style names is made available (DHOSTS.TXT).

 -- Feb 84 Domain Requirements Specification

 At this point the requirements for establishing a new domain are
 published as an RFC.

 14 Mar 84 Begin using Domain Style Names

 At this point all hosts should start using their domain style
 names as their official and primary names. The standard table of
 host names contains domain style names as the official and primary
 name (DHOSTS.TXT becomes HOSTS.TXT).

 04 Apr 84 Server for ARPA Domain

 At this point several domain name servers are in operation to
 supply host name to internet address translations, one of these
 servers is at the NIC.

 04 Apr 84 Domain Table

 At this point a master table of top level domain names and their
 associated servers is established at the NIC.

 02 May 84 Stop using old style Names

 At this point the use of old style names must be completely phased
 out.




Postel [Page 7]

RFC 897 February 1984
Domain Implementation Schedule


 02 May 84 Certain New Domains

 At this point a few new domains may be established, in particular
 the DDN domain.

 06 Jun 84 General & Multilevel Domains

 At this point additional new domains may be established, if they
 meet the requirements. Domain style names may have more than two
 segments.

 18 Jul 84 Organizational Domains

 Domain style names may identify organizations. Finding an address
 for a host may involve a level of indirection.

 05 Sep 84 Decommission Host Table

 At this point the master host table maintained by the NIC need no
 longer be complete for the ARPA research community. A full table
 of the DDN operational hosts will be maintained by the NIC.

 03 Oct 84 DDN Plan for Domains Name Service

 At this point the DDN PMO will establish a plan for the future
 support of name to address translations in the DDN community.

References

 [] Postel, J., "The Domain Names Plan and Schedule", RFC-881, USC
 Information Sciences Institute, November 1983.

 [] Mockapetris, P., "Domain Names - Concepts and Facilities",
 RFC-882, USC Information Sciences Institute, November 1983.

 [] Mockapetris, P., "Domain Names - Implementation and
 Specification", RFC-883, USC Information Sciences Institute,
 November 1983.











Postel [Page 8]