summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc881.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc881.txt')
-rw-r--r--doc/rfc/rfc881.txt580
1 files changed, 580 insertions, 0 deletions
diff --git a/doc/rfc/rfc881.txt b/doc/rfc/rfc881.txt
new file mode 100644
index 0000000..f517855
--- /dev/null
+++ b/doc/rfc/rfc881.txt
@@ -0,0 +1,580 @@
+
+
+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]
+