    Network Working Group                                          J. Postel
    Request for Comments: 881                                            ISI
                                                               November 1983

                       The Domain Names Plan and Schedule

    This RFC outlines a plan and schedule for the implementation of domain
    style names throughout the DDN/ARPA Internet community.  The
    introduction of domain style names will impact all hosts on the DDN/ARPA
    Internet.

    The Plan

       Introduction

          Domain style names are being introduced in the Internet to allow a
          controlled delegation of the authority and responsibility for
          adding hosts to the system.  This also allows a subdivision of the
          task of maintaining information about hosts.

          The subdivision will be based on administrative authority or
          organization boundaries (not necessarily network boundaries).
          Certain requirements will be placed on organizations wishing to be
          "top level" domains.  Initially, all the hosts in the Internet
          will be in the domain "ARPA".  As soon as is practical a second
          domain, "DDN", will be introduced.  Other domains may be added
          after that, provided the requirements listed below are met.

          Domain names will be supported in the long run by a system of
          special servers called "domain servers" which will be used to
          translate names to addresses.  While this system of domain servers
          is being created and programs are being converted to use them, the
          existing host tables will evolve to include domain style names.

          The domain server design also provides for mapping mailbox
          addresses to the host name of the mail server for that mailbox.
          This feature allows mailboxes to be related to an organization
          rather than to a specific host.

          This plan will be implemented in the ARPA community.  After the
          domain system is demonstrated in the ARPA community, the DDN
          Program Management Office (DDN-PMO) will determine the schedule
          for implementation of the domain system in the DDN community.
          This approach will cause some extra steps in the ARPA community
          implementation, and may limit communication between the ARPA and
          DDN communities in some ways.  The details and implications of
          this two phase approach are discussed more fully below.

    Postel                                                          [Page 1]

    RFC 881                                                    November 1983
    The Domain Names Plan and Schedule

       A Catch 22

          There is a problem in introducing domain style names: a great deal
          of software has to be changed.  Some groups would like to start
          using domain style names right away, and other groups don't want
          to see them or use them for a very long time.  Communication
          patterns are very complex and as soon as domain style names are
          allowed and used by a few groups they will start showing up almost
          everywhere.  This argues that everyone should be prepared for them
          before they are used at all.  However, we know that with people
          being people and with so many of people involved, the probability
          of everyone being ready in any reasonable time period is nearly
          zero.  The way out of this situation is to set up a reasonable
          schedule for experimenting with domain style names and authorizing
          their use.  People that get ready on schedule should have no
          problems with these names.

       Evolution of the Table

          Nearly all the hosts in the Internet now use some form of host
          table based on the master file "HOSTS.TXT" maintained by the
          Network Information Center (NIC).

          One way to introduce domain style names is to add to the entries
          in this table names in the domain style.  In particular, make the
          first name in each entry the official host name in the ARPA
          domain.

             For example, the current entry for USC-ISIF is:

                HOST : 10.2.0.52 : USC-ISIF,ISIF : DEC-1090T : TOPS20 :
                TCP/TELNET,TCP/SMTP,TCP/FTP,TCP/FINGER,UDP/TFTP :

             This could become:

                HOST : 10.2.0.52 : USC-ISIF.ARPA,USC-ISIF,ISIF : DEC-1090T :
                TOPS20 : TCP/TELNET,TCP/SMTP,TCP/FTP,TCP/FINGER,UDP/TFTP :

          For some hosts and programs this could be done today with no
          disruptions, but for others substantial problems could occur.  For
          example, with over five hundred entries in the table the addition
          of 500 names could exceed the space allocated to store the table
          in some programs.  (One could argue that these programs are going
          to blow up soon anyway as new host entries are added to the
          table.)  Another problem is that period (or dot, ".") is not now a
          legal character in host names and some programs may not be able to
          parse these new names.

    Postel                                                          [Page 2]

    RFC 881                                                    November 1983
    The Domain Names Plan and Schedule

          The plan is to make such a domain style name table available in
          parallel with the regular table for a few months, then to replace
          the regular table with this domain style table.  The dates for
          these changes is given in the schedule below.

          So far, no new domains have been introduced.  Only a table with
          all the entries having official names in the ARPA domain has been
          provided.  This should allow programs to be constructed to deal
          with domain style names in a general way without any special hacks
          to add or delete the string ".ARPA" to or from host names.

          The introduction of new domains is tied to the provision of domain
          servers by those domains.  As new domains meet the requirements
          and are authorized they will also be added to the host table.  No
          new domains will be added before master table is converted to the
          domain style entries.

          In the long run the Internet will become too complex and change
          too fast to keep a master table of all the hosts.  At some point
          the master table will be reduced to simply the entries for the
          domain servers for the top level domains.  By this time all normal
          translation of host names into addresses should take place by
          consulting domain servers.

       Conversion to Servers

          As soon as domain servers become available programs should be
          converted to use them to translate names into addresses.  The
          details of these procedures are given in RFCs 882 and 883.

          The general idea is that a host no longer keeps a complete host
          table but rather makes a request on the domain server each time a
          name must be translated to an address.  The code module in the
          host that implements the protocol to do this is called a
          "resolver".  The resolver may keep a cache of recently translated
          names and addresses for improved performance.

          Many hosts have a library function or system call that is used to
          access the host table to translate names to addresses.  It ought
          to be possible to replace this function or call with the resolver
          module such that most programs would not know which method was
          used to accomplish the name to address translation.

    Postel                                                          [Page 3]

    RFC 881                                                    November 1983
    The Domain Names Plan and Schedule

       Requirements on a Domain

          There are several requirements that must be met to establish a
          domain.  In general it must be responsibly managed.  There must be
          a responsible person to serve as a coordinator for domain related
          questions,  there must be a robust name service, it must be of at
          least a minimum size,  and the domain must be registered with the
          central domain administrator.

          Responsible Person:

             An individual must be identified who has authority for the
             administration of the names within the domain, and who takes
             responsibility for the behavior of the hosts in the domain in
             their interactions with hosts outside the domain.

             The operation of a name server should not be taken on lightly.
             There are some difficult problems in providing an adequate
             service, primarily the problems in keeping the data base up to
             date, and keeping the service operating.

             If some host in a domain somehow misbehaves in interactions
             with hosts outside the domain (e.g., consistently violates
             protocols), the responsible person for the domain must be able
             to take action to eliminate the problem.

          Domain Servers:

             A robust and reliable domain service must be provided.  One way
             of meeting this requirement is to provide at least two
             independent domain servers for the domain.  The data base can,
             of course, be the same.  The database can be prepared and
             copied to each domain server.  But, the servers should be in
             separate machines on independent power supplies, et cetera;
             basically as physically independent as can be and yet in the
             same domain.  They should have no common point of failure.

             One of the difficult problems in operating a domain server is
             the acquisition and maintenance of the data.  In this case the
             data is the host names and addresses.  In some environments
             this information changes fairly rapidly and keeping up-to-date
             data may be difficult.  This is one motivation for sub-domains.
             One may wish to create sub-domains until the rate of change of
             the data in a sub-domain domain server data base is easily
             managed.

             The concepts and implementation details of the domain server
             are given in RFCs 882 and 883.

    Postel                                                          [Page 4]

    RFC 881                                                    November 1983
    The Domain Names Plan and Schedule

          Minimum Size:

             The domain must be of at least a minimum size.  Several
             measures of size may be used in combination in making this
             test.  Measures may include: (a) the number of host computers
             in the domain, (b) the number of people with primary mailboxes
             in the domain, (c) the amount of traffic that crosses the
             boundary of the domain [packets/day or mail items/week].
             Specific threshold values for these measures will be
             established before new domains are authorized.

             There is no requirement to form a domain because some set of
             hosts is above the minimum size.

          Registration:

             The administrator must register the domain with the central
             authority.  The central authority must be satisfied that the
             requirements are met before authorization for the domain is
             granted.

             The administrator of a domain is required to make sure that
             host and sub-domain names within that jurisdiction conform to
             the standard name conventions and are unique with in that
             domain.

             If sub-domains are set up the administrator may wish to pass
             along some of his authority and responsibility to a sub-domain
             administrator.

       Mailbox Support

          The design of the domain servers provides two levels of support
          for mail.

          The first, called "agent binding", is that the right hand part of
          the typical mail box (Y in X@Y) can be mapped a host that will
          either accept the mail as the destination or accept the mail for
          forwarding.

          The second, called "mailbox binding", is to map the entire mailbox
          (X@Y) to a destination (this mechanism can also support some
          mailing list functions).

          Agent binding can be used to establish mailboxes that are based on
          an organization name rather than a host name.

             For example, an organization, "BLAT", with hosts "BLAT-20" and

    Postel                                                          [Page 5]

    RFC 881                                                    November 1983
    The Domain Names Plan and Schedule

             "BLAT-VAX" in the ARPA domain could set up mailboxes of the
             form "user@BLAT.ARPA" and use the domain server mechanisms for
             mapping these to the host that accepts the mail for the
             organization.

          Mailbox binding will allow different mappings for individual
          mailboxes of an organization or host to the destination host.  It
          will also provide for aliases and mailing groups.

             Mailbox binding requires adding information on individual
             mailboxes to the domain server database.  This could be a
             substantial increase in the database size and management
             responsibility.

       The ARPA Community and the DDN Community

          This plan will be put into effect in the ARPA community.

          The DDN community will adopt the domain style names, but will
          continue with the present scheme of a centrally maintained table
          copied periodically by each host.  Once the use of domain servers
          has been demonstrated by use in the ARPA community, the DDN-PMO
          will establish a schedule for implementing the domain system in
          the DDN community.

          This means that there may be a period of a year or more with the
          two communities using different schemes for distributing
          information about host names and addresses.

          Specifically:

             The NIC will maintain a table a "HOSTS.TXT" style table for use
             by DDN hosts.  This table will contain domain style names for
             all DDN hosts (e.g., USC-ISIA.DDN).  Since this is the only
             information DDN hosts will use to translate host names to
             Internet Addresses, this table must also contain names and
             addresses of ARPA community hosts of interest to DDN users
             (e.g., USC-ISIF.ARPA).

             There will be a domain server with data for the DDN domain.
             That is, hosts in the ARPA community that use the domain system
             of resolvers and servers will be able to access servers that
             have the data base covering the DDN community.

          It is quite likely that the table for the use of the DDN hosts
          will be incomplete with respect to coverage of the ARPA community
          and any new domains that are established.  One motivation for the
          domain system is the subdivision of name management to avoid the

    Postel                                                          [Page 6]

    RFC 881                                                    November 1983
    The Domain Names Plan and Schedule

          difficulty of keeping a global table of all hosts.  As the ARPA
          community moves to significant use of the domains system the
          maintenance of a global table for use by the DDN community will
          become very difficult.

          This means that DDN hosts might not be able to look up the names
          of some ARPA community hosts in their local tables.  In some cases
          this might result in an inability establish communication from a
          DDN hosts to such "unknown" ARPA community hosts.

             The most likely case is for a computer mail message sent from
             an ARPA community user on a host know to name servers but not
             in the central table to a user on a DDN community host that
             relies on a local copy of the central table.  When the DDN user
             attempts to answer this message his mail program will attempt
             to look up the host name.  This will fail, and the most likely
             result is that the mail program will tell the user that there
             is no such host!

          Please note that DDN community hosts are permitted (even
          encouraged) to implement the domain system in parallel with the
          ARPA community.  However, there is no requirement that they do so
          until called for in the schedule to be established by the DDN-PMO.

    Postel                                                          [Page 7]

    RFC 881                                                    November 1983
    The Domain Names Plan and Schedule

    The Schedule

       04-Oct-83  The ARPANET/MILNET Logical Split

       02-Nov-83  Publish Domain Name Documents

          This Plan and Schedule (RFC-881), Domain Names - Concepts and
          Facilities (RFC-882), and Domain Names - Implementation
          Specification (RFC-883).

       16-Nov-83  Make Available Domain Style Host Table

          Create a copy a modified version of the HOSTS.TXT table named
          DHOSTS.TXT with an additional name (as the first name) in each
          entry of the form "official-host-name.ARPA".

       15-Dec-83  Final Specification of simple Query & Reply Protocol
       Available

          This specification covers the protocol procedures and message
          formats for the simple queries and replies to support translating
          host names to internet addresses only.

       15-Dec-83  Make Limited Domain Server & Resolvers Available

          An example limited domain server running on TOPS-20 and example
          limited resolvers running on each of TOPS-20 and VAX-Berkeley-Unix
          should be made available for testing and copying.  This simple
          version would be able to do queries and responses for host name to
          internet address translation only, and the servers would still use
          the global table.  This simple server would not refer the resolver
          to another server.  This simple server and these resolvers operate
          in datagram mode only.  However, this would allow user programs to
          begin to use the servers.

       01-Feb-84  Specification of Domain Requirements Available

          Detailed requirements for qualifying a set of hosts as a domain,
          and procedure for registering new domains is published.

       15-Feb-84  The ARPANET/MILNET Access Controls

          MILNET access controls installed in the MILNET/ARPANET gateways
          and TAC user access controls put into effect (see DDN MGT Bulletin
          16). [Date approximate.]

    Postel                                                          [Page 8]

    RFC 881                                                    November 1983
    The Domain Names Plan and Schedule

       07-Mar-84  Replace Main Host Table with Domain Style Host Table

          The DHOSTS.TXT becomes HOSTS.TXT.

       14-Mar-84  Final Specification of Query & Reply Protocol Available

          This specification covers the protocol procedures and message
          formats for the all queries and replies between resolvers and
          servers.

       14-Mar-84  Make Improved Domain Servers & Resolvers Available

          An example improved domain server running on TOPS-20 and example
          improved resolvers running on each of TOPS-20 and
          VAX-Berkeley-Unix should be made available for testing and
          copying.  This version should be able to do any of the defined
          query and response operations, and should support segmented data
          base by refering resolvers to other servers if necessary.  This
          server loads zone data from local master files only, and only at
          program start up.  This server and these resolvers operate with
          either datagram or reliable connection style communication.  This
          version does not support the data base update portion of the
          server protocol.

       04-Apr-84  Domain Servers for ARPA Domain Available

          Authoritative domain servers for the ARPA domain will be available
          for regular use.

       02-May-84  Introduce New Domains in the Main Host Table

          Add the DDN domain.  Most MILNET hosts will change to the DDN
          domain.  Authoritative domain servers for the DDN domain will be
          available for regular use.  HOSTS.TXT is updated.

       02-May-84  Establish a New Top Level Domains Only Table

          Start a new table, DOMAINS.TXT, that lists only the top level
          domains and the entries for their domain servers.

       16-May-84  Final Specification of Maintenance Protocol Available

          This specification covers the protocol procedures and message
          formats for the data base update exchanges between servers.

       16-May-84  Make Improved Domain Servers & Resolvers Available

          An example improved domain server running on TOPS-20 and example

    Postel                                                          [Page 9]

    RFC 881                                                    November 1983
    The Domain Names Plan and Schedule

          improved resolvers running on each of TOPS-20 and
          VAX-Berkeley-Unix should be made available for testing and
          copying.  This version should be able to do any of the defined
          query and response operations, and should support segmented data
          base by refering resolvers to other servers if necessary.  This
          server loads zone data from local master files and remote servers,
          and only at program start up.  This server and these resolvers
          operate with either datagram or reliable connection style
          communication.

       06-Jun-84  Permit the Introduction of New Domains

          Organizations meeting the requirements for establishing new
          domains will be allowed to begin use of new domain names.  New
          domains must be registered, meet the requirements (including
          running domain servers), and will be added to the HOSTS.TXT table.

       18-Jul-84  Final Specification of Complete Protocol Available

          This specification covers the protocol procedures and message
          formats for the complete domain names system.

       18-Jul-84  Make Full Domain Servers & Resolvers Available

          At this point an example domain server and an example resolver
          running on each of TOPS-20 and VAX-Berkeley-Unix should be made
          available for testing and copying.  This version should be able to
          do any of the defined query and response operations, and should
          support segmented data base by refering resolvers to other servers
          if necessary.  This version should support the data base update
          portion of the server protocol, including data aging and dynamic
          zone updating from remote servers.  This is a full implementation
          of the protocol.

       05-Sep-84  Discontinue the Full Host Table for the ARPA Community

          Stop maintaining the HOSTS.TXT table for the ARPA community.  The
          HOSTS.TXT table continues to be used in the DDN community with
          complete data for the DDN domain, however the data for the ARPA
          and other domains may no longer be complete or fully up to date.

       03-Oct-84  DDN-PMO Schedules DDN Implementation

          The DDN-PMO establishes the schedule for the implementation of the
          domain system in the DDN community.

    Postel                                                         [Page 10]