home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 800s / rfc897.txt < prev    next >
Text File  |  1992-09-22  |  16KB  |  457 lines

  1.  
  2.  
  3. Network Working Group                                         Jon Postel
  4. Request for Comments: 897                                            ISI
  5.                                                            February 1984
  6. Updates:  RFC 881
  7.  
  8.                Domain Name System Implementation Schedule
  9.  
  10.  
  11. Status of this Memo
  12.  
  13.    This memo is a policy statement on the implementation of the Domain
  14.    Style Naming System in the Internet.  This memo is a partial update
  15.    of RFC 881.  This is an official policy statement of the ICCB and the
  16.    DARPA.
  17.  
  18.    The intent of this memo is to detail the schedule for the
  19.    implementation for the Domain Style Naming System.  The explanation
  20.    of how this system works is to be found in the references.
  21.  
  22. The Current Situation
  23.  
  24.    Simple Names
  25.  
  26.       Hosts in the ARPA research and DDN operational communities are
  27.       currently assigned names in a flat or global name space of
  28.       character strings.  There are some limits on these names.  They
  29.       must start with a letter, end with a letter or digit and have only
  30.       letters or digits or hyphen as interior characters.  Case is not
  31.       significant.
  32.  
  33.          For example:  USC-ISIF
  34.  
  35.    Tables
  36.  
  37.       Every host in the Internet is expected to have a way of
  38.       translating the name of any other host into its Internet address.
  39.  
  40.       By and large, the name to address translation is done by looking
  41.       up the information in a table of all hosts.
  42.  
  43.       The maintenance of this table is centralized at the Network
  44.       Information Center (NIC).  Each host is expected to obtain a
  45.       current copy of the table on a timely basis.
  46.  
  47.    Interface to the World
  48.  
  49.       A great deal of mail moves between the Internet and other
  50.       "systems" that somehow transport mail among computers.  This is
  51.       currently done by hiding some sort of "other-system" addressing
  52.       information in the local-part of the mail address and using a
  53.       mail-relay host in the host-part of the mailbox.
  54.  
  55.  
  56. Postel                                                          [Page 1]
  57.  
  58.  
  59.  
  60. RFC 897                                                    February 1984
  61. Domain Implementation Schedule
  62.  
  63.  
  64.       For example,
  65.  
  66.          OBERST%EDUCOM.MAILNET@MIT-MULTICS
  67.          EDMISTON.CIC@CSNET-RELAY
  68.  
  69. The Future Situation
  70.  
  71.    Hierarchical Names
  72.  
  73.       Because of the growth of the Internet, structured names (or domain
  74.       style names) will be used.  Each element of the structured name
  75.       will be a character string (with the same constraints that
  76.       previously applied to the simple names).
  77.  
  78.          For example:  F.ISI.USC.ARPA
  79.  
  80.    Servers
  81.  
  82.       Every host in the Internet will be expected to have a way of
  83.       translating the name of any other host into its Internet address.
  84.  
  85.       By and large, the name to address translation will be done by
  86.       interacting with a service.  There will be a number of servers
  87.       that each hold a portion of the name to address information.
  88.  
  89.       The maintenance of the translation data will be subdivided and
  90.       distributed.
  91.  
  92.    There are several stages of implementation for the servers and
  93.    several levels of development for use of the domain style names.
  94.  
  95.       First, there is the simple substitution of the domain style names
  96.       for the current host names, and the subdivision of these into
  97.       several domains.  At this stage all domain style names directly
  98.       translate to host addresses and all domain style names have two
  99.       components.
  100.  
  101.          For example:  USC-ISIF.ARPA  or  USC-ISIA.DDN
  102.  
  103.          and:  Postel@USC-ISIF.ARPA  or  Kahn@USC-ISIA.DDN
  104.  
  105.          Here we expect that "USC-ISIF.ARPA" is the name of an Internet
  106.          host and that we can send mail for "Postel" to the SMTP port on
  107.          that host.  It may be that some backward host can still fake it
  108.          by ignoring the ".ARPA" and looking up an address for
  109.          "USC-ISIF".
  110.  
  111.  
  112.  
  113. Postel                                                          [Page 2]
  114.  
  115.  
  116.  
  117. RFC 897                                                    February 1984
  118. Domain Implementation Schedule
  119.  
  120.  
  121.          Using the domain name servers (but not the tables) mail
  122.          forwarding may be supported.  A domain name server query can
  123.          say "I want to send mail to ABCDEF.ARPA".  The response might
  124.          be "to send mail to ABCDEF.ARPA send it to the mail relay
  125.          GHIJKL.ARPA at address 123.123.123.123".
  126.  
  127.       Second, there is an extension to more name components.
  128.  
  129.          For example:  F.ISI.USC.ARPA  or  A.USC-ISI.DDN
  130.  
  131.          and:  Postel@F.ISI.USC.ARPA  or  Kahn@A.USC-ISI.DDN
  132.  
  133.          Here we expect that "F.ISI.USC.ARPA" is the name of an Internet
  134.          host and that we can send mail for "Postel" to the SMTP port on
  135.          that host.  It is unlikely that a backward host can hack this
  136.          at all.
  137.  
  138.       Third, there is an extension to domain style names that may
  139.       represent only organizations or administrative entities.  Finding
  140.       a host that represents such entities may require a level of
  141.       indirection in the search.
  142.  
  143.          For example:  USC-ISI.ARPA  or  ARPA.DDN
  144.  
  145.          and:  Postel@USC-ISI.ARPA  or  Kahn@ARPA.DDN
  146.  
  147.          Here we don't count on "USC-ISI.ARPA" being the name of an
  148.          Internet host.  When we want to send mail to "Postel" we ask
  149.          the domain name server about sending mail to "USC-ISI.ARPA".
  150.          The server will tell us the name (and address) of a real
  151.          Internet host that handles mail on this organizations behalf,
  152.          for example, "F.USC-ISI.ARPA = 10.2.0.52". We then send mail
  153.          for "Postel" to the SMTP port on F.USC-ISI.ARPA.
  154.  
  155.    Interface to the World
  156.  
  157.       Mail will continue to move between the Internet and other
  158.       "systems".  This may be done by designating some sort of
  159.       "other-system" representative organization in the domain server
  160.       data bases that can indirect mail to a mail-relay host.
  161.  
  162.       For example,
  163.  
  164.          OBERST@EDUCOM.MAILNET
  165.          EDMISTON@CIC.CSNET
  166.  
  167.  
  168.  
  169.  
  170. Postel                                                          [Page 3]
  171.  
  172.  
  173.  
  174. RFC 897                                                    February 1984
  175. Domain Implementation Schedule
  176.  
  177.  
  178. The Transition Situation
  179.  
  180.    Actually, the situation is a bit more complicated, of course.  A
  181.    number of hosts are already using domain style names under the
  182.    constraint that their domain style name is exactly their old style
  183.    name with the string ".ARPA" appended.  The first transition step is
  184.    to have all hosts do this, and then to eliminate the user of old
  185.    style names altogether.
  186.  
  187.    Please note carefully that two types of changes are being made:
  188.  
  189.       One is a change in the support mechanism for translating a host
  190.       name to an internet address,
  191.  
  192.          that is from using local copies of a full centrally maintained
  193.          table to dynamically accessing a distributed set of servers
  194.          each posesing a portion of a data base maintained in a
  195.          distributed fashion.
  196.  
  197.       The other is a change in the host names themselves,
  198.  
  199.          from a flat global space of unstructured strings to a
  200.          hierarchical structure of names.
  201.  
  202.    There are four steps to the transition plan.
  203.  
  204.       First, change from old names to domain style names.
  205.  
  206.          host-name --> host-name.ARPA
  207.  
  208.       Second, one domain to a few domains.
  209.  
  210.          host-name.ARPA --> host-name.ARPA and host-name.DDN
  211.  
  212.       Third, change from using central tables to using name servers.
  213.  
  214.       Fourth, allow many domains.
  215.  
  216.    There are two communities that are taking slightly different courses
  217.    in this transition.  The ARPA research community is making the full
  218.    transition.  The DDN operational community is making the change in
  219.    naming on the same schedule, but is not requiring hosts in the DDN
  220.    operational community make the change to using servers at the same
  221.    time (they can if they want to).  The DDN PMO will establish a
  222.    schedule for that change at a later time.  The NIC will maintain a
  223.    central table of all DDN operational hosts.
  224.  
  225.  
  226.  
  227. Postel                                                          [Page 4]
  228.  
  229.  
  230.  
  231. RFC 897                                                    February 1984
  232. Domain Implementation Schedule
  233.  
  234.  
  235.    Interface to the World
  236.  
  237.       The interchange of mail with "other-systems" will have to continue
  238.       pretty much as it does now (except that RELAY-HOST will become
  239.       RELAY-HOST.ARPA) until organization names can be used.  Then
  240.       representative organizations can be designated for each
  241.       "other-system" in the domain server data bases that will then
  242.       indirectly specify a mail-relay host.
  243.  
  244. Policy Statement
  245.  
  246.    The names of hosts will be changed to domain style names.  Hosts will
  247.    begin to use domain style names on 14-Mar-84 and the use of old style
  248.    names will be completely phased out before 2-May-84.
  249.  
  250.    This applies to both the ARPA research hosts and the DDN operational
  251.    hosts.
  252.  
  253. Implication
  254.  
  255.    All Hosts Change Names
  256.  
  257.       The impact of introducing the domain style names is that all hosts
  258.       change their names at least once.  Hosts that move to new domains
  259.       or subdomains may change their names several times.
  260.  
  261.       Hosts have an official (or primary) name and possibly several
  262.       nicknames.  When mail is sent from a host, the official name is
  263.       used in the mail header address fields.
  264.  
  265.       Suppose, that in the old days before domains were thought of, a
  266.       host changed its name.  What is the impact on users of changing
  267.       the name of a host?  Suppose one host changed its name from FOO to
  268.       BAR.
  269.  
  270.          Mail
  271.  
  272.             Mail that was sent before the name was changed can not be
  273.             answered using mail program commands that automatically fill
  274.             in the return address.  While it may be possible to use
  275.             special tricks to fix up the "From" or the "To" users
  276.             addresses, the "Cc" addresses are very difficult to correct.
  277.  
  278.             Mail that was sent to JOE@ABC from FRED@FOO can not be
  279.             answered unless the change of name is known to the user or
  280.             the mail program an ABC and the host name BAR substituted
  281.             for FOO.
  282.  
  283.  
  284. Postel                                                          [Page 5]
  285.  
  286.  
  287.  
  288. RFC 897                                                    February 1984
  289. Domain Implementation Schedule
  290.  
  291.  
  292.             Mail that is sent to JOE@ABC from SAM@DEF with a cc to
  293.             FRED@FOO can not be answered easily.
  294.  
  295.          Mailing Lists
  296.  
  297.             Any mailing lists that have mailboxes on the host that
  298.             changed names will now have incorrect entries.
  299.  
  300.       The point is that while the host that changed names may be able to
  301.       use special tricks for a while to fix things up for the users, it
  302.       is difficult for other hosts to do this.
  303.  
  304.       A general trick is to make the old name a nickname for the host
  305.       for some period of time.
  306.  
  307.       The introduction of domain style names means that all hosts change
  308.       their names essentially at the same time.
  309.  
  310.          For example, USC-ISIF changes to USC-ISIF.ARPA
  311.  
  312.       To lessen the resulting havoc, the initial set of new names has a
  313.       fixed relationship to the old names.  The first set of domain
  314.       style names is exactly the old names with the domain name "ARPA"
  315.       appended.  That is, if a hosts old name was "HOST-NAME", then its
  316.       new name is "HOST-NAME.ARPA".
  317.  
  318.       To further lessen the havoc, there will be a period of time when
  319.       both the old and the new names are allowed.  That is, the old
  320.       names will be nicknames for a while.
  321.  
  322.    Primary Names
  323.  
  324.       In to old style names, host have an official or primary names and
  325.       may have several nicknames.  For example,
  326.  
  327.          Primary Name             Nicknames
  328.  
  329.          USC-ISIF                 ISIF
  330.  
  331.          ADA-VAX                  ISI-VAXB  AJPO  VAXB
  332.  
  333.       In any case, the data base in such than given any of the names for
  334.       a host one can find the address, and given the address one can
  335.       find the primary name.
  336.  
  337.       In the new domain style name system this property must be
  338.       maintained.  That is, given the Internet address of a host one
  339.  
  340.  
  341. Postel                                                          [Page 6]
  342.  
  343.  
  344.  
  345. RFC 897                                                    February 1984
  346. Domain Implementation Schedule
  347.  
  348.  
  349.       must be able to find the primary name of that host.  This calls
  350.       for careful management of the distributed database by those in
  351.       charge of the domains and subdomains.
  352.  
  353. The Time Table
  354.  
  355.    -- Nov 83  Plan and Schedule
  356.  
  357.       At this point the overall plan for the implementation of domain
  358.       style names and name servers, and a schedule of events was
  359.       published (RFC-881).  Also the draft design and specification for
  360.       the protocol and data base were published (RFC-882, RFC-883).
  361.  
  362.    -- Nov 83  Initial Domain Style Host Name Table
  363.  
  364.       At this point a version of the host table which includes the
  365.       domain style names is made available (DHOSTS.TXT).
  366.  
  367.    -- Feb 84  Domain Requirements Specification
  368.  
  369.       At this point the requirements for establishing a new domain are
  370.       published as an RFC.
  371.  
  372.    14 Mar 84  Begin using Domain Style Names
  373.  
  374.       At this point all hosts should start using their domain style
  375.       names as their official and primary names.  The standard table of
  376.       host names contains domain style names as the official and primary
  377.       name (DHOSTS.TXT becomes HOSTS.TXT).
  378.  
  379.    04 Apr 84  Server for ARPA Domain
  380.  
  381.       At this point several domain name servers are in operation to
  382.       supply host name to internet address translations, one of these
  383.       servers is at the NIC.
  384.  
  385.    04 Apr 84  Domain Table
  386.  
  387.       At this point a master table of top level domain names and their
  388.       associated servers is established at the NIC.
  389.  
  390.    02 May 84  Stop using old style Names
  391.  
  392.       At this point the use of old style names must be completely phased
  393.       out.
  394.  
  395.  
  396.  
  397.  
  398. Postel                                                          [Page 7]
  399.  
  400.  
  401.  
  402. RFC 897                                                    February 1984
  403. Domain Implementation Schedule
  404.  
  405.  
  406.    02 May 84  Certain New Domains
  407.  
  408.       At this point a few new domains may be established, in particular
  409.       the DDN domain.
  410.  
  411.    06 Jun 84  General & Multilevel Domains
  412.  
  413.       At this point additional new domains may be established, if they
  414.       meet the requirements.  Domain style names may have more than two
  415.       segments.
  416.  
  417.    18 Jul 84  Organizational Domains
  418.  
  419.       Domain style names may identify organizations.  Finding an address
  420.       for a host may involve a level of indirection.
  421.  
  422.    05 Sep 84  Decommission Host Table
  423.  
  424.       At this point the master host table maintained by the NIC need no
  425.       longer be complete for the ARPA research community.  A full table
  426.       of the DDN operational hosts will be maintained by the NIC.
  427.  
  428.    03 Oct 84  DDN Plan for Domains Name Service
  429.  
  430.       At this point the DDN PMO will establish a plan for the future
  431.       support of name to address translations in the DDN community.
  432.  
  433. References
  434.  
  435.    [1]  Postel, J., "The Domain Names Plan and Schedule", RFC-881, USC
  436.         Information Sciences Institute, November 1983.
  437.  
  438.    [2]  Mockapetris, P., "Domain Names - Concepts and Facilities",
  439.         RFC-882, USC Information Sciences Institute, November 1983.
  440.  
  441.    [3]  Mockapetris, P., "Domain Names - Implementation and
  442.         Specification", RFC-883, USC Information Sciences Institute,
  443.         November 1983.
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455. Postel                                                          [Page 8]
  456.  
  457.