From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc881.txt | 580 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 580 insertions(+) create mode 100644 doc/rfc/rfc881.txt (limited to 'doc/rfc/rfc881.txt') 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] + -- cgit v1.2.3