home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 800s / rfc881.txt < prev    next >
Text File  |  1992-09-22  |  23KB  |  581 lines
  1.  
  2.  
  3. Network Working Group                                          J. Postel
  4. Request for Comments: 881                                            ISI
  5.                                                            November 1983
  6.  
  7.  
  8.  
  9.                    The Domain Names Plan and Schedule
  10.  
  11. This RFC outlines a plan and schedule for the implementation of domain
  12. style names throughout the DDN/ARPA Internet community.  The
  13. introduction of domain style names will impact all hosts on the DDN/ARPA
  14. Internet.
  15.  
  16. The Plan
  17.  
  18.    Introduction
  19.  
  20.       Domain style names are being introduced in the Internet to allow a
  21.       controlled delegation of the authority and responsibility for
  22.       adding hosts to the system.  This also allows a subdivision of the
  23.       task of maintaining information about hosts.
  24.  
  25.       The subdivision will be based on administrative authority or
  26.       organization boundaries (not necessarily network boundaries).
  27.       Certain requirements will be placed on organizations wishing to be
  28.       "top level" domains.  Initially, all the hosts in the Internet
  29.       will be in the domain "ARPA".  As soon as is practical a second
  30.       domain, "DDN", will be introduced.  Other domains may be added
  31.       after that, provided the requirements listed below are met.
  32.  
  33.       Domain names will be supported in the long run by a system of
  34.       special servers called "domain servers" which will be used to
  35.       translate names to addresses.  While this system of domain servers
  36.       is being created and programs are being converted to use them, the
  37.       existing host tables will evolve to include domain style names.
  38.  
  39.       The domain server design also provides for mapping mailbox
  40.       addresses to the host name of the mail server for that mailbox.
  41.       This feature allows mailboxes to be related to an organization
  42.       rather than to a specific host.
  43.  
  44.       This plan will be implemented in the ARPA community.  After the
  45.       domain system is demonstrated in the ARPA community, the DDN
  46.       Program Management Office (DDN-PMO) will determine the schedule
  47.       for implementation of the domain system in the DDN community.
  48.       This approach will cause some extra steps in the ARPA community
  49.       implementation, and may limit communication between the ARPA and
  50.       DDN communities in some ways.  The details and implications of
  51.       this two phase approach are discussed more fully below.
  52.  
  53.  
  54.  
  55.  
  56.  
  57. Postel                                                          [Page 1]
  58.  
  59.  
  60.  
  61. RFC 881                                                    November 1983
  62. The Domain Names Plan and Schedule                                      
  63.  
  64.  
  65.    A Catch 22
  66.  
  67.       There is a problem in introducing domain style names: a great deal
  68.       of software has to be changed.  Some groups would like to start
  69.       using domain style names right away, and other groups don't want
  70.       to see them or use them for a very long time.  Communication
  71.       patterns are very complex and as soon as domain style names are
  72.       allowed and used by a few groups they will start showing up almost
  73.       everywhere.  This argues that everyone should be prepared for them
  74.       before they are used at all.  However, we know that with people
  75.       being people and with so many of people involved, the probability
  76.       of everyone being ready in any reasonable time period is nearly
  77.       zero.  The way out of this situation is to set up a reasonable
  78.       schedule for experimenting with domain style names and authorizing
  79.       their use.  People that get ready on schedule should have no
  80.       problems with these names.
  81.  
  82.    Evolution of the Table
  83.  
  84.       Nearly all the hosts in the Internet now use some form of host
  85.       table based on the master file "HOSTS.TXT" maintained by the
  86.       Network Information Center (NIC).
  87.  
  88.       One way to introduce domain style names is to add to the entries
  89.       in this table names in the domain style.  In particular, make the
  90.       first name in each entry the official host name in the ARPA
  91.       domain.
  92.  
  93.          For example, the current entry for USC-ISIF is:
  94.  
  95.             HOST : 10.2.0.52 : USC-ISIF,ISIF : DEC-1090T : TOPS20 :
  96.             TCP/TELNET,TCP/SMTP,TCP/FTP,TCP/FINGER,UDP/TFTP :
  97.  
  98.          This could become:
  99.  
  100.             HOST : 10.2.0.52 : USC-ISIF.ARPA,USC-ISIF,ISIF : DEC-1090T :
  101.             TOPS20 : TCP/TELNET,TCP/SMTP,TCP/FTP,TCP/FINGER,UDP/TFTP :
  102.  
  103.       For some hosts and programs this could be done today with no
  104.       disruptions, but for others substantial problems could occur.  For
  105.       example, with over five hundred entries in the table the addition
  106.       of 500 names could exceed the space allocated to store the table
  107.       in some programs.  (One could argue that these programs are going
  108.       to blow up soon anyway as new host entries are added to the
  109.       table.)  Another problem is that period (or dot, ".") is not now a
  110.       legal character in host names and some programs may not be able to
  111.       parse these new names.
  112.  
  113.  
  114.  
  115. Postel                                                          [Page 2]
  116.  
  117.  
  118.  
  119. RFC 881                                                    November 1983
  120. The Domain Names Plan and Schedule                                      
  121.  
  122.  
  123.       The plan is to make such a domain style name table available in
  124.       parallel with the regular table for a few months, then to replace
  125.       the regular table with this domain style table.  The dates for
  126.       these changes is given in the schedule below.
  127.  
  128.       So far, no new domains have been introduced.  Only a table with
  129.       all the entries having official names in the ARPA domain has been
  130.       provided.  This should allow programs to be constructed to deal
  131.       with domain style names in a general way without any special hacks
  132.       to add or delete the string ".ARPA" to or from host names.
  133.  
  134.       The introduction of new domains is tied to the provision of domain
  135.       servers by those domains.  As new domains meet the requirements
  136.       and are authorized they will also be added to the host table.  No
  137.       new domains will be added before master table is converted to the
  138.       domain style entries.
  139.  
  140.       In the long run the Internet will become too complex and change
  141.       too fast to keep a master table of all the hosts.  At some point
  142.       the master table will be reduced to simply the entries for the
  143.       domain servers for the top level domains.  By this time all normal
  144.       translation of host names into addresses should take place by
  145.       consulting domain servers.
  146.  
  147.    Conversion to Servers
  148.  
  149.       As soon as domain servers become available programs should be
  150.       converted to use them to translate names into addresses.  The
  151.       details of these procedures are given in RFCs 882 and 883.
  152.  
  153.       The general idea is that a host no longer keeps a complete host
  154.       table but rather makes a request on the domain server each time a
  155.       name must be translated to an address.  The code module in the
  156.       host that implements the protocol to do this is called a
  157.       "resolver".  The resolver may keep a cache of recently translated
  158.       names and addresses for improved performance.
  159.  
  160.       Many hosts have a library function or system call that is used to
  161.       access the host table to translate names to addresses.  It ought
  162.       to be possible to replace this function or call with the resolver
  163.       module such that most programs would not know which method was
  164.       used to accomplish the name to address translation.
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173. Postel                                                          [Page 3]
  174.  
  175.  
  176.  
  177. RFC 881                                                    November 1983
  178. The Domain Names Plan and Schedule                                      
  179.  
  180.  
  181.    Requirements on a Domain
  182.  
  183.       There are several requirements that must be met to establish a
  184.       domain.  In general it must be responsibly managed.  There must be
  185.       a responsible person to serve as a coordinator for domain related
  186.       questions,  there must be a robust name service, it must be of at
  187.       least a minimum size,  and the domain must be registered with the
  188.       central domain administrator.
  189.  
  190.       Responsible Person:
  191.  
  192.          An individual must be identified who has authority for the
  193.          administration of the names within the domain, and who takes
  194.          responsibility for the behavior of the hosts in the domain in
  195.          their interactions with hosts outside the domain.
  196.  
  197.          The operation of a name server should not be taken on lightly.
  198.          There are some difficult problems in providing an adequate
  199.          service, primarily the problems in keeping the data base up to
  200.          date, and keeping the service operating.
  201.  
  202.          If some host in a domain somehow misbehaves in interactions
  203.          with hosts outside the domain (e.g., consistently violates
  204.          protocols), the responsible person for the domain must be able
  205.          to take action to eliminate the problem.
  206.  
  207.       Domain Servers:
  208.  
  209.          A robust and reliable domain service must be provided.  One way
  210.          of meeting this requirement is to provide at least two
  211.          independent domain servers for the domain.  The data base can,
  212.          of course, be the same.  The database can be prepared and
  213.          copied to each domain server.  But, the servers should be in
  214.          separate machines on independent power supplies, et cetera;
  215.          basically as physically independent as can be and yet in the
  216.          same domain.  They should have no common point of failure.
  217.  
  218.          One of the difficult problems in operating a domain server is
  219.          the acquisition and maintenance of the data.  In this case the
  220.          data is the host names and addresses.  In some environments
  221.          this information changes fairly rapidly and keeping up-to-date
  222.          data may be difficult.  This is one motivation for sub-domains.
  223.          One may wish to create sub-domains until the rate of change of
  224.          the data in a sub-domain domain server data base is easily
  225.          managed.
  226.  
  227.          The concepts and implementation details of the domain server
  228.          are given in RFCs 882 and 883.
  229.  
  230.  
  231. Postel                                                          [Page 4]
  232.  
  233.  
  234.  
  235. RFC 881                                                    November 1983
  236. The Domain Names Plan and Schedule                                      
  237.  
  238.  
  239.       Minimum Size:
  240.  
  241.          The domain must be of at least a minimum size.  Several
  242.          measures of size may be used in combination in making this
  243.          test.  Measures may include: (a) the number of host computers
  244.          in the domain, (b) the number of people with primary mailboxes
  245.          in the domain, (c) the amount of traffic that crosses the
  246.          boundary of the domain [packets/day or mail items/week].
  247.          Specific threshold values for these measures will be
  248.          established before new domains are authorized.
  249.  
  250.          There is no requirement to form a domain because some set of
  251.          hosts is above the minimum size.
  252.  
  253.       Registration:
  254.  
  255.          The administrator must register the domain with the central
  256.          authority.  The central authority must be satisfied that the
  257.          requirements are met before authorization for the domain is
  258.          granted.
  259.  
  260.          The administrator of a domain is required to make sure that
  261.          host and sub-domain names within that jurisdiction conform to
  262.          the standard name conventions and are unique with in that
  263.          domain.
  264.  
  265.          If sub-domains are set up the administrator may wish to pass
  266.          along some of his authority and responsibility to a sub-domain
  267.          administrator.
  268.  
  269.    Mailbox Support
  270.  
  271.       The design of the domain servers provides two levels of support
  272.       for mail.
  273.  
  274.       The first, called "agent binding", is that the right hand part of
  275.       the typical mail box (Y in X@Y) can be mapped a host that will
  276.       either accept the mail as the destination or accept the mail for
  277.       forwarding.
  278.  
  279.       The second, called "mailbox binding", is to map the entire mailbox
  280.       (X@Y) to a destination (this mechanism can also support some
  281.       mailing list functions).
  282.  
  283.       Agent binding can be used to establish mailboxes that are based on
  284.       an organization name rather than a host name.
  285.  
  286.          For example, an organization, "BLAT", with hosts "BLAT-20" and
  287.  
  288.  
  289. Postel                                                          [Page 5]
  290.  
  291.  
  292.  
  293. RFC 881                                                    November 1983
  294. The Domain Names Plan and Schedule                                      
  295.  
  296.  
  297.          "BLAT-VAX" in the ARPA domain could set up mailboxes of the
  298.          form "user@BLAT.ARPA" and use the domain server mechanisms for
  299.          mapping these to the host that accepts the mail for the
  300.          organization.
  301.  
  302.       Mailbox binding will allow different mappings for individual
  303.       mailboxes of an organization or host to the destination host.  It
  304.       will also provide for aliases and mailing groups.
  305.  
  306.          Mailbox binding requires adding information on individual
  307.          mailboxes to the domain server database.  This could be a
  308.          substantial increase in the database size and management
  309.          responsibility.
  310.  
  311.    The ARPA Community and the DDN Community
  312.  
  313.       This plan will be put into effect in the ARPA community.
  314.  
  315.       The DDN community will adopt the domain style names, but will
  316.       continue with the present scheme of a centrally maintained table
  317.       copied periodically by each host.  Once the use of domain servers
  318.       has been demonstrated by use in the ARPA community, the DDN-PMO
  319.       will establish a schedule for implementing the domain system in
  320.       the DDN community.
  321.  
  322.       This means that there may be a period of a year or more with the
  323.       two communities using different schemes for distributing
  324.       information about host names and addresses.
  325.  
  326.       Specifically:
  327.  
  328.          The NIC will maintain a table a "HOSTS.TXT" style table for use
  329.          by DDN hosts.  This table will contain domain style names for
  330.          all DDN hosts (e.g., USC-ISIA.DDN).  Since this is the only
  331.          information DDN hosts will use to translate host names to
  332.          Internet Addresses, this table must also contain names and
  333.          addresses of ARPA community hosts of interest to DDN users
  334.          (e.g., USC-ISIF.ARPA).
  335.  
  336.          There will be a domain server with data for the DDN domain.
  337.          That is, hosts in the ARPA community that use the domain system
  338.          of resolvers and servers will be able to access servers that
  339.          have the data base covering the DDN community.
  340.  
  341.       It is quite likely that the table for the use of the DDN hosts
  342.       will be incomplete with respect to coverage of the ARPA community
  343.       and any new domains that are established.  One motivation for the
  344.       domain system is the subdivision of name management to avoid the
  345.  
  346.  
  347. Postel                                                          [Page 6]
  348.  
  349.  
  350.  
  351. RFC 881                                                    November 1983
  352. The Domain Names Plan and Schedule                                      
  353.  
  354.  
  355.       difficulty of keeping a global table of all hosts.  As the ARPA
  356.       community moves to significant use of the domains system the
  357.       maintenance of a global table for use by the DDN community will
  358.       become very difficult.
  359.  
  360.       This means that DDN hosts might not be able to look up the names
  361.       of some ARPA community hosts in their local tables.  In some cases
  362.       this might result in an inability establish communication from a
  363.       DDN hosts to such "unknown" ARPA community hosts.
  364.  
  365.          The most likely case is for a computer mail message sent from
  366.          an ARPA community user on a host know to name servers but not
  367.          in the central table to a user on a DDN community host that
  368.          relies on a local copy of the central table.  When the DDN user
  369.          attempts to answer this message his mail program will attempt
  370.          to look up the host name.  This will fail, and the most likely
  371.          result is that the mail program will tell the user that there
  372.          is no such host!
  373.  
  374.       Please note that DDN community hosts are permitted (even
  375.       encouraged) to implement the domain system in parallel with the
  376.       ARPA community.  However, there is no requirement that they do so
  377.       until called for in the schedule to be established by the DDN-PMO.
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405. Postel                                                          [Page 7]
  406.  
  407.  
  408.  
  409. RFC 881                                                    November 1983
  410. The Domain Names Plan and Schedule                                      
  411.  
  412.  
  413. The Schedule
  414.  
  415.    04-Oct-83  The ARPANET/MILNET Logical Split
  416.  
  417.    02-Nov-83  Publish Domain Name Documents
  418.  
  419.       This Plan and Schedule (RFC-881), Domain Names - Concepts and
  420.       Facilities (RFC-882), and Domain Names - Implementation
  421.       Specification (RFC-883).
  422.  
  423.    16-Nov-83  Make Available Domain Style Host Table
  424.  
  425.       Create a copy a modified version of the HOSTS.TXT table named
  426.       DHOSTS.TXT with an additional name (as the first name) in each
  427.       entry of the form "official-host-name.ARPA".
  428.  
  429.    15-Dec-83  Final Specification of simple Query & Reply Protocol
  430.    Available
  431.  
  432.       This specification covers the protocol procedures and message
  433.       formats for the simple queries and replies to support translating
  434.       host names to internet addresses only.
  435.  
  436.    15-Dec-83  Make Limited Domain Server & Resolvers Available
  437.  
  438.       An example limited domain server running on TOPS-20 and example
  439.       limited resolvers running on each of TOPS-20 and VAX-Berkeley-Unix
  440.       should be made available for testing and copying.  This simple
  441.       version would be able to do queries and responses for host name to
  442.       internet address translation only, and the servers would still use
  443.       the global table.  This simple server would not refer the resolver
  444.       to another server.  This simple server and these resolvers operate
  445.       in datagram mode only.  However, this would allow user programs to
  446.       begin to use the servers.
  447.  
  448.    01-Feb-84  Specification of Domain Requirements Available
  449.  
  450.       Detailed requirements for qualifying a set of hosts as a domain,
  451.       and procedure for registering new domains is published.
  452.  
  453.    15-Feb-84  The ARPANET/MILNET Access Controls
  454.  
  455.       MILNET access controls installed in the MILNET/ARPANET gateways
  456.       and TAC user access controls put into effect (see DDN MGT Bulletin
  457.       16). [Date approximate.]
  458.  
  459.  
  460.  
  461.  
  462.  
  463. Postel                                                          [Page 8]
  464.  
  465.  
  466.  
  467. RFC 881                                                    November 1983
  468. The Domain Names Plan and Schedule                                      
  469.  
  470.  
  471.    07-Mar-84  Replace Main Host Table with Domain Style Host Table
  472.  
  473.       The DHOSTS.TXT becomes HOSTS.TXT.
  474.  
  475.    14-Mar-84  Final Specification of Query & Reply Protocol Available
  476.  
  477.       This specification covers the protocol procedures and message
  478.       formats for the all queries and replies between resolvers and
  479.       servers.
  480.  
  481.    14-Mar-84  Make Improved Domain Servers & Resolvers Available
  482.  
  483.       An example improved domain server running on TOPS-20 and example
  484.       improved resolvers running on each of TOPS-20 and
  485.       VAX-Berkeley-Unix should be made available for testing and
  486.       copying.  This version should be able to do any of the defined
  487.       query and response operations, and should support segmented data
  488.       base by refering resolvers to other servers if necessary.  This
  489.       server loads zone data from local master files only, and only at
  490.       program start up.  This server and these resolvers operate with
  491.       either datagram or reliable connection style communication.  This
  492.       version does not support the data base update portion of the
  493.       server protocol.
  494.  
  495.    04-Apr-84  Domain Servers for ARPA Domain Available
  496.  
  497.       Authoritative domain servers for the ARPA domain will be available
  498.       for regular use.
  499.  
  500.    02-May-84  Introduce New Domains in the Main Host Table
  501.  
  502.       Add the DDN domain.  Most MILNET hosts will change to the DDN
  503.       domain.  Authoritative domain servers for the DDN domain will be
  504.       available for regular use.  HOSTS.TXT is updated.
  505.  
  506.    02-May-84  Establish a New Top Level Domains Only Table
  507.  
  508.       Start a new table, DOMAINS.TXT, that lists only the top level
  509.       domains and the entries for their domain servers.
  510.  
  511.    16-May-84  Final Specification of Maintenance Protocol Available
  512.  
  513.       This specification covers the protocol procedures and message
  514.       formats for the data base update exchanges between servers.
  515.  
  516.    16-May-84  Make Improved Domain Servers & Resolvers Available
  517.  
  518.       An example improved domain server running on TOPS-20 and example
  519.  
  520.  
  521. Postel                                                          [Page 9]
  522.  
  523.  
  524.  
  525. RFC 881                                                    November 1983
  526. The Domain Names Plan and Schedule                                      
  527.  
  528.  
  529.       improved resolvers running on each of TOPS-20 and
  530.       VAX-Berkeley-Unix should be made available for testing and
  531.       copying.  This version should be able to do any of the defined
  532.       query and response operations, and should support segmented data
  533.       base by refering resolvers to other servers if necessary.  This
  534.       server loads zone data from local master files and remote servers,
  535.       and only at program start up.  This server and these resolvers
  536.       operate with either datagram or reliable connection style
  537.       communication.
  538.  
  539.    06-Jun-84  Permit the Introduction of New Domains
  540.  
  541.       Organizations meeting the requirements for establishing new
  542.       domains will be allowed to begin use of new domain names.  New
  543.       domains must be registered, meet the requirements (including
  544.       running domain servers), and will be added to the HOSTS.TXT table.
  545.  
  546.    18-Jul-84  Final Specification of Complete Protocol Available
  547.  
  548.       This specification covers the protocol procedures and message
  549.       formats for the complete domain names system.
  550.  
  551.    18-Jul-84  Make Full Domain Servers & Resolvers Available
  552.  
  553.       At this point an example domain server and an example resolver
  554.       running on each of TOPS-20 and VAX-Berkeley-Unix should be made
  555.       available for testing and copying.  This version should be able to
  556.       do any of the defined query and response operations, and should
  557.       support segmented data base by refering resolvers to other servers
  558.       if necessary.  This version should support the data base update
  559.       portion of the server protocol, including data aging and dynamic
  560.       zone updating from remote servers.  This is a full implementation
  561.       of the protocol.
  562.  
  563.    05-Sep-84  Discontinue the Full Host Table for the ARPA Community
  564.  
  565.       Stop maintaining the HOSTS.TXT table for the ARPA community.  The
  566.       HOSTS.TXT table continues to be used in the DDN community with
  567.       complete data for the DDN domain, however the data for the ARPA
  568.       and other domains may no longer be complete or fully up to date.
  569.  
  570.    03-Oct-84  DDN-PMO Schedules DDN Implementation
  571.  
  572.       The DDN-PMO establishes the schedule for the implementation of the
  573.       domain system in the DDN community.
  574.  
  575.  
  576.  
  577.  
  578.  
  579. Postel                                                         [Page 10]
  580.  
  581.