From c175c2dcf584bb9314c81c8e3bce06351435c80c Mon Sep 17 00:00:00 2001 From: CSRG Date: Sun, 28 Feb 1988 07:34:29 -0800 Subject: [PATCH] BSD 4_3_Net_2 development Work on file usr/src/usr.sbin/named/doc/rfc1032.lpr Work on file usr/src/usr.sbin/named/doc/rfc1033.lpr Work on file usr/src/usr.sbin/named/doc/rfc1034.lpr Work on file usr/src/usr.sbin/named/doc/rfc1035.lpr Synthesized-from: CSRG/cd2/net.2 --- usr/src/usr.sbin/named/doc/rfc1032.lpr | 781 ++++++ usr/src/usr.sbin/named/doc/rfc1033.lpr | 1229 ++++++++++ usr/src/usr.sbin/named/doc/rfc1034.lpr | 3077 ++++++++++++++++++++++++ usr/src/usr.sbin/named/doc/rfc1035.lpr | 3077 ++++++++++++++++++++++++ 4 files changed, 8164 insertions(+) create mode 100644 usr/src/usr.sbin/named/doc/rfc1032.lpr create mode 100644 usr/src/usr.sbin/named/doc/rfc1033.lpr create mode 100644 usr/src/usr.sbin/named/doc/rfc1034.lpr create mode 100644 usr/src/usr.sbin/named/doc/rfc1035.lpr diff --git a/usr/src/usr.sbin/named/doc/rfc1032.lpr b/usr/src/usr.sbin/named/doc/rfc1032.lpr new file mode 100644 index 0000000000..0e82721cee --- /dev/null +++ b/usr/src/usr.sbin/named/doc/rfc1032.lpr @@ -0,0 +1,781 @@ +Network Working Group M. Stahl +Request for Comments: 1032 SRI International + November 1987 + + + DOMAIN ADMINISTRATORS GUIDE + + +STATUS OF THIS MEMO + + This memo describes procedures for registering a domain with the + Network Information Center (NIC) of Defense Data Network (DDN), and + offers guidelines on the establishment and administration of a domain + in accordance with the requirements specified in RFC-920. It is + intended for use by domain administrators. This memo should be used + in conjunction with RFC-920, which is an official policy statement of + the Internet Activities Board (IAB) and the Defense Advanced Research + Projects Agency (DARPA). Distribution of this memo is unlimited. + +BACKGROUND + + Domains are administrative entities that provide decentralized + management of host naming and addressing. The domain-naming system + is distributed and hierarchical. + + The NIC is designated by the Defense Communications Agency (DCA) to + provide registry services for the domain-naming system on the DDN and + DARPA portions of the Internet. + + As registrar of top-level and second-level domains, as well as + administrator of the root domain name servers on behalf of DARPA and + DDN, the NIC is responsible for maintaining the root server zone + files and their binary equivalents. In addition, the NIC is + responsible for administering the top-level domains of "ARPA," "COM," + "EDU," "ORG," "GOV," and "MIL" on behalf of DCA and DARPA until it + becomes feasible for other appropriate organizations to assume those + responsibilities. + + It is recommended that the guidelines described in this document be + used by domain administrators in the establishment and control of + second-level domains. + +THE DOMAIN ADMINISTRATOR + + The role of the domain administrator (DA) is that of coordinator, + manager, and technician. If his domain is established at the second + level or lower in the tree, the DA must register by interacting with + the management of the domain directly above his, making certain that + + + +Stahl [Page 1] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + his domain satisfies all the requirements of the administration under + which his domain would be situated. To find out who has authority + over the name space he wishes to join, the DA can ask the NIC + Hostmaster. Information on contacts for the top-level and second- + level domains can also be found on line in the file NETINFO:DOMAIN- + CONTACTS.TXT, which is available from the NIC via anonymous FTP. + + The DA should be technically competent; he should understand the + concepts and procedures for operating a domain server, as described + in RFC-1034, and make sure that the service provided is reliable and + uninterrupted. It is his responsibility or that of his delegate to + ensure that the data will be current at all times. As a manager, the + DA must be able to handle complaints about service provided by his + domain name server. He must be aware of the behavior of the hosts in + his domain, and take prompt action on reports of problems, such as + protocol violations or other serious misbehavior. The administrator + of a domain must be a responsible person who has the authority to + either enforce these actions himself or delegate them to someone + else. + + Name assignments within a domain are controlled by the DA, who should + verify that names are unique within his domain and that they conform + to standard naming conventions. He furnishes access to names and + name-related information to users both inside and outside his domain. + He should work closely with the personnel he has designated as the + "technical and zone" contacts for his domain, for many administrative + decisions will be made on the basis of input from these people. + +THE DOMAIN TECHNICAL AND ZONE CONTACT + + A zone consists of those contiguous parts of the domain tree for + which a domain server has complete information and over which it has + authority. A domain server may be authoritative for more than one + zone. The domain technical/zone contact is the person who tends to + the technical aspects of maintaining the domain's name server and + resolver software, and database files. He keeps the name server + running, and interacts with technical people in other domains and + zones to solve problems that affect his zone. + +POLICIES + + Domain or host name choices and the allocation of domain name space + are considered to be local matters. In the event of conflicts, it is + the policy of the NIC not to get involved in local disputes or in the + local decision-making process. The NIC will not act as referee in + disputes over such matters as who has the "right" to register a + particular top-level or second-level domain for an organization. The + NIC considers this a private local matter that must be settled among + + + +Stahl [Page 2] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + the parties involved prior to their commencing the registration + process with the NIC. Therefore, it is assumed that the responsible + person for a domain will have resolved any local conflicts among the + members of his domain before registering that domain with the NIC. + The NIC will give guidance, if requested, by answering specific + technical questions, but will not provide arbitration in disputes at + the local level. This policy is also in keeping with the distributed + hierarchical nature of the domain-naming system in that it helps to + distribute the tasks of solving problems and handling questions. + + Naming conventions for hosts should follow the rules specified in + RFC-952. From a technical standpoint, domain names can be very long. + Each segment of a domain name may contain up to 64 characters, but + the NIC strongly advises DAs to choose names that are 12 characters + or fewer, because behind every domain system there is a human being + who must keep track of the names, addresses, contacts, and other data + in a database. The longer the name, the more likely the data + maintainer is to make a mistake. Users also will appreciate shorter + names. Most people agree that short names are easier to remember and + type; most domain names registered so far are 12 characters or fewer. + + Domain name assignments are made on a first-come-first-served basis. + The NIC has chosen not to register individual hosts directly under + the top-level domains it administers. One advantage of the domain + naming system is that administration and data maintenance can be + delegated down a hierarchical tree. Registration of hosts at the + same level in the tree as a second-level domain would dilute the + usefulness of this feature. In addition, the administrator of a + domain is responsible for the actions of hosts within his domain. We + would not want to find ourselves in the awkward position of policing + the actions of individual hosts. Rather, the subdomains registered + under these top-level domains retain the responsibility for this + function. + + Countries that wish to be registered as top-level domains are + required to name themselves after the two-letter country code listed + in the international standard ISO-3166. In some cases, however, the + two-letter ISO country code is identical to a state code used by the + U.S. Postal Service. Requests made by countries to use the three- + letter form of country code specified in the ISO-3166 standard will + be considered in such cases so as to prevent possible conflicts and + confusion. + + + + + + + + + +Stahl [Page 3] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + +HOW TO REGISTER + + Obtain a domain questionnaire from the NIC hostmaster, or FTP the + file NETINFO:DOMAIN-TEMPLATE.TXT from host SRI-NIC.ARPA. + + Fill out the questionnaire completely. Return it via electronic mail + to HOSTMASTER@SRI-NIC.ARPA. + + The APPENDIX to this memo contains the application form for + registering a top-level or second-level domain with the NIC. It + supersedes the version of the questionnaire found in RFC-920. The + application should be submitted by the person administratively + responsible for the domain, and must be filled out completely before + the NIC will authorize establishment of a top-level or second-level + domain. The DA is responsible for keeping his domain's data current + with the NIC or with the registration agent with which his domain is + registered. For example, the CSNET and UUCP managements act as + domain filters, processing domain applications for their own + organizations. They pass pertinent information along periodically to + the NIC for incorporation into the domain database and root server + files. The online file NETINFO:ALTERNATE-DOMAIN-PROCEDURE.TXT + outlines this procedure. It is highly recommended that the DA review + this information periodically and provide any corrections or + additions. Corrections should be submitted via electronic mail. + +WHICH DOMAIN NAME? + + The designers of the domain-naming system initiated several general + categories of names as top-level domain names, so that each could + accommodate a variety of organizations. The current top-level + domains registered with the DDN Network Information Center are ARPA, + COM, EDU, GOV, MIL, NET, and ORG, plus a number of top-level country + domains. To join one of these, a DA needs to be aware of the purpose + for which it was intended. + + "ARPA" is a temporary domain. It is by default appended to the + names of hosts that have not yet joined a domain. When the system + was begun in 1984, the names of all hosts in the Official DoD + Internet Host Table maintained by the NIC were changed by adding + of the label ".ARPA" in order to accelerate a transition to the + domain-naming system. Another reason for the blanket name changes + was to force hosts to become accustomed to using the new style + names and to modify their network software, if necessary. This + was done on a network-wide basis and was directed by DCA in DDN + Management Bulletin No. 22. Hosts that fall into this domain will + eventually move to other branches of the domain tree. + + + + + +Stahl [Page 4] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + "COM" is meant to incorporate subdomains of companies and + businesses. + + "EDU" was initiated to accommodate subdomains set up by + universities and other educational institutions. + + "GOV" exists to act as parent domain for subdomains set up by + government agencies. + + "MIL" was initiated to act as parent to subdomains that are + developed by military organizations. + + "NET" was introduced as a parent domain for various network-type + organizations. Organizations that belong within this top-level + domain are generic or network-specific, such as network service + centers and consortia. "NET" also encompasses network + management-related organizations, such as information centers and + operations centers. + + "ORG" exists as a parent to subdomains that do not clearly fall + within the other top-level domains. This may include technical- + support groups, professional societies, or similar organizations. + + One of the guidelines in effect in the domain-naming system is that a + host should have only one name regardless of what networks it is + connected to. This implies, that, in general, domain names should + not include routing information or addresses. For example, a host + that has one network connection to the Internet and another to BITNET + should use the same name when talking to either network. For a + description of the syntax of domain names, please refer to Section 3 + of RFC-1034. + +VERIFICATION OF DATA + + The verification process can be accomplished in several ways. One of + these is through the NIC WHOIS server. If he has access to WHOIS, + the DA can type the command "whois domain ". + The reply from WHOIS will supply the following: the name and address + of the organization "owning" the domain; the name of the domain; its + administrative, technical, and zone contacts; the host names and + network addresses of sites providing name service for the domain. + + + + + + + + + + +Stahl [Page 5] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + Example: + + @whois domain rice.edu + + Rice University (RICE-DOM) + Advanced Studies and Research + Houston, TX 77001 + + Domain Name: RICE.EDU + + Administrative Contact: + Kennedy, Ken (KK28) Kennedy@LLL-CRG.ARPA (713) 527-4834 + Technical Contact, Zone Contact: + Riffle, Vicky R. (VRR) rif@RICE.EDU + (713) 527-8101 ext 3844 + + Domain servers: + + RICE.EDU 128.42.5.1 + PENDRAGON.CS.PURDUE.EDU 128.10.2.5 + + + Alternatively, the DA can send an electronic mail message to + SERVICE@SRI-NIC.ARPA. In the subject line of the message header, the + DA should type "whois domain ". The requested + information will be returned via electronic mail. This method is + convenient for sites that do not have access to the NIC WHOIS + service. + + The initial application for domain authorization should be submitted + via electronic mail, if possible, to HOSTMASTER@SRI-NIC.ARPA. The + questionnaire described in the appendix may be used or a separate + application can be FTPed from host SRI-NIC.ARPA. The information + provided by the administrator will be reviewed by hostmaster + personnel for completeness. There will most likely be a few + exchanges of correspondence via electronic mail, the preferred method + of communication, prior to authorization of the domain. + +HOW TO GET MORE INFORMATION + + An informational table of the top-level domains and their root + servers is contained in the file NETINFO:DOMAINS.TXT online at SRI- + NIC.ARPA. This table can be obtained by FTPing the file. + Alternatively, the information can be acquired by opening a TCP or + UDP connection to the NIC Host Name Server, port 101 on SRI-NIC.ARPA, + and invoking the command "ALL-DOM". + + + + + +Stahl [Page 6] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + The following online files, all available by FTP from SRI-NIC.ARPA, + contain pertinent domain information: + + - NETINFO:DOMAINS.TXT, a table of all top-level domains and the + network addresses of the machines providing domain name + service for them. It is updated each time a new top-level + domain is approved. + + - NETINFO:DOMAIN-INFO.TXT contains a concise list of all + top-level and second-level domain names registered with the + NIC and is updated monthly. + + - NETINFO:DOMAIN-CONTACTS.TXT also contains a list of all the + top level and second-level domains, but includes the + administrative, technical and zone contacts for each as well. + + - NETINFO:DOMAIN-TEMPLATE.TXT contains the questionnaire to be + completed before registering a top-level or second-level + domain. + + For either general or specific information on the domain system, do + one or more of the following: + + 1. Send electronic mail to HOSTMASTER@SRI-NIC.ARPA + + 2. Call the toll-free NIC hotline at (800) 235-3155 + + 3. Use FTP to get background RFCs and other files maintained + online at the NIC. Some pertinent RFCs are listed below in + the REFERENCES section of this memo. + + + + + + + + + + + + + + + + + + + + + +Stahl [Page 7] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + +REFERENCES + + The references listed here provide important background information + on the domain-naming system. Path names of the online files + available via anonymous FTP from the SRI-NIC.ARPA host are noted in + brackets. + + 1. Defense Communications Agency DDN Defense Communications + System, DDN Management Bulletin No. 22, Domain Names + Transition, March 1984. + [ DDN-NEWS:DDN-MGT-BULLETIN-22.TXT ] + + 2. Defense Communications Agency DDN Defense Communications + System, DDN Management Bulletin No. 32, Phase I of the Domain + Name Implementation, January 1987. + [ DDN-NEWS:DDN-MGT-BULLETIN-32.TXT ] + + 3. Harrenstien, K., M. Stahl, and E. Feinler, "Hostname + Server", RFC-953, DDN Network Information Center, SRI + International, October 1985. [ RFC:RFC953.TXT ] + + 4. Harrenstien, K., M. Stahl, and E. Feinler, "Official DoD + Internet Host Table Specification", RFC-952, DDN Network + Information Center, SRI International, October 1985. + [ RFC:RFC952.TXT ] + + 5. ISO, "Codes for the Representation of Names of Countries", + ISO-3166, International Standards Organization, May 1981. + [ Not online ] + + 6. Lazear, W.D., "MILNET Name Domain Transition", RFC-1031, + Mitre Corporation, October 1987. [ RFC:RFC1031.TXT ] + + 7. Lottor, M.K., "Domain Administrators Operations Guide", + RFC-1033, DDN Network Information Center, SRI International, + July 1987. [ RFC:RFC1033.TXT ] + + 8. Mockapetris, P., "Domain Names - Concepts and Facilities", + RFC-1034, USC Information Sciences Institute, October 1987. + [ RFC:RFC1034.TXT ] + + 9. Mockapetris, P., "Domain Names - Implementation and + Specification", RFC-1035, USC Information Sciences Institute, + October 1987. [ RFC:RFC1035.TXT ] + + 10. Mockapetris, P., "The Domain Name System", Proceedings of the + IFIP 6.5 Working Conference on Computer Message Services, + Nottingham, England, May 1984. Also as ISI/RS-84-133, June + + + +Stahl [Page 8] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + 1984. [ Not online ] + + 11. Mockapetris, P., J. Postel, and P. Kirton, "Name Server + Design for Distributed Systems", Proceedings of the Seventh + International Conference on Computer Communication, October + 30 to November 3 1984, Sidney, Australia. Also as + ISI/RS-84-132, June 1984. [ Not online ] + + 12. Partridge, C., "Mail Routing and the Domain System", RFC-974, + CSNET-CIC, BBN Laboratories, January 1986. + [ RFC:RFC974.TXT ] + + 13. Postel, J., "The Domain Names Plan and Schedule", RFC-881, + USC Information Sciences Institute, November 1983. + [ RFC:RFC881.TXT ] + + 14. Reynolds, J., and Postel, J., "Assigned Numbers", RFC-1010 + USC Information Sciences Institute, May 1986. + [ RFC:RFC1010.TXT ] + + 15. Romano, S., and Stahl, M., "Internet Numbers", RFC-1020, + SRI, November 1987. + [ RFC:RFC1020.TXT ] + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Stahl [Page 9] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + +APPENDIX + + The following questionnaire may be FTPed from SRI-NIC.ARPA as + NETINFO:DOMAIN-TEMPLATE.TXT. + + --------------------------------------------------------------------- + + To establish a domain, the following information must be sent to the + NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA): + + NOTE: The key people must have electronic mailboxes and NIC + "handles," unique NIC database identifiers. If you have access to + "WHOIS", please check to see if you are registered and if so, make + sure the information is current. Include only your handle and any + changes (if any) that need to be made in your entry. If you do not + have access to "WHOIS", please provide all the information indicated + and a NIC handle will be assigned. + + (1) The name of the top-level domain to join. + + For example: COM + + (2) The NIC handle of the administrative head of the organization. + Alternately, the person's name, title, mailing address, phone number, + organization, and network mailbox. This is the contact point for + administrative and policy questions about the domain. In the case of + a research project, this should be the principal investigator. + + For example: + + Administrator + + Organization The NetWorthy Corporation + Name Penelope Q. Sassafrass + Title President + Mail Address The NetWorthy Corporation + 4676 Andrews Way, Suite 100 + Santa Clara, CA 94302-1212 + Phone Number (415) 123-4567 + Net Mailbox Sassafrass@ECHO.TNC.COM + NIC Handle PQS + + (3) The NIC handle of the technical contact for the domain. + Alternately, the person's name, title, mailing address, phone number, + organization, and network mailbox. This is the contact point for + problems concerning the domain or zone, as well as for updating + information about the domain or zone. + + + + +Stahl [Page 10] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + For example: + + Technical and Zone Contact + + Organization The NetWorthy Corporation + Name Ansel A. Aardvark + Title Executive Director + Mail Address The NetWorthy Corporation + 4676 Andrews Way, Suite 100 + Santa Clara, CA. 94302-1212 + Phone Number (415) 123-6789 + Net Mailbox Aardvark@ECHO.TNC.COM + NIC Handle AAA2 + + (4) The name of the domain (up to 12 characters). This is the name + that will be used in tables and lists associating the domain with the + domain server addresses. [While, from a technical standpoint, domain + names can be quite long (programmers beware), shorter names are + easier for people to cope with.] + + For example: TNC + + (5) A description of the servers that provide the domain service for + translating names to addresses for hosts in this domain, and the date + they will be operational. + + A good way to answer this question is to say "Our server is + supplied by person or company X and does whatever their standard + issue server does." + + For example: Our server is a copy of the one operated by + the NIC; it will be installed and made operational on + 1 November 1987. + + (6) Domains must provide at least two independent servers for the + domain. Establishing the servers in physically separate locations + and on different PSNs is strongly recommended. A description of the + server machine and its backup, including + + + + + + + + + + + + + +Stahl [Page 11] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + (a) Hardware and software (using keywords from the Assigned + Numbers RFC). + + (b) Host domain name and network addresses (which host on which + network for each connected network). + + (c) Any domain-style nicknames (please limit your domain-style + nickname request to one) + + For example: + + - Hardware and software + + VAX-11/750 and UNIX, or + IBM-PC and MS-DOS, or + DEC-1090 and TOPS-20 + + - Host domain names and network addresses + + BAR.FOO.COM 10.9.0.193 on ARPANET + + - Domain-style nickname + + BR.FOO.COM (same as BAR.FOO.COM 10.9.0.13 on ARPANET) + + (7) Planned mapping of names of any other network hosts, other than + the server machines, into the new domain's naming space. + + For example: + + BAR-FOO2.ARPA (10.8.0.193) -> FOO2.BAR.COM + BAR-FOO3.ARPA (10.7.0.193) -> FOO3.BAR.COM + BAR-FOO4.ARPA (10.6.0.193) -> FOO4.BAR.COM + + + (8) An estimate of the number of hosts that will be in the domain. + + (a) Initially + (b) Within one year + (c) Two years + (d) Five years. + + For example: + + (a) Initially = 50 + (b) One year = 100 + (c) Two years = 200 + (d) Five years = 500 + + + +Stahl [Page 12] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + (9) The date you expect the fully qualified domain name to become + the official host name in HOSTS.TXT. + + Please note: If changing to a fully qualified domain name (e.g., + FOO.BAR.COM) causes a change in the official host name of an + ARPANET or MILNET host, DCA approval must be obtained beforehand. + Allow 10 working days for your requested changes to be processed. + + ARPANET sites should contact ARPANETMGR@DDN1.ARPA. MILNET sites + should contact HOSTMASTER@SRI-NIC.ARPA, 800-235-3155, for + further instructions. + + (10) Please describe your organization briefly. + + For example: The NetWorthy Corporation is a consulting + organization of people working with UNIX and the C language in an + electronic networking environment. It sponsors two technical + conferences annually and distributes a bimonthly newsletter. + + --------------------------------------------------------------------- + + This example of a completed application corresponds to the examples + found in the companion document RFC-1033, "Domain Administrators + Operations Guide." + + (1) The name of the top-level domain to join. + + COM + + (2) The NIC handle of the administrative contact person. + + NIC Handle JAKE + + (3) The NIC handle of the domain's technical and zone + contact person. + + NIC Handle DLE6 + + (4) The name of the domain. + + SRI + + (5) A description of the servers. + + Our server is the TOPS20 server JEEVES supplied by ISI; it + will be installed and made operational on 1 July 1987. + + + + + +Stahl [Page 13] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + (6) A description of the server machine and its backup: + + (a) Hardware and software + + DEC-1090T and TOPS20 + DEC-2065 and TOPS20 + + (b) Host domain name and network address + + KL.SRI.COM 10.1.0.2 on ARPANET, 128.18.10.6 on SRINET + STRIPE.SRI.COM 10.4.0.2 on ARPANET, 128.18.10.4 on SRINET + + (c) Domain-style nickname + + None + + (7) Planned mapping of names of any other network hosts, other than + the server machines, into the new domain's naming space. + + SRI-Blackjack.ARPA (128.18.2.1) -> Blackjack.SRI.COM + SRI-CSL.ARPA (192.12.33.2) -> CSL.SRI.COM + + (8) An estimate of the number of hosts that will be directly within + this domain. + + (a) Initially = 50 + (b) One year = 100 + (c) Two years = 200 + (d) Five years = 500 + + (9) A date when you expect the fully qualified domain name to become + the official host name in HOSTS.TXT. + + 31 September 1987 + + (10) Brief description of organization. + + SRI International is an independent, nonprofit, scientific + research organization. It performs basic and applied research + for government and commercial clients, and contributes to + worldwide economic, scientific, industrial, and social progress + through research and related services. + + + + + + + + + +Stahl [Page 14] + diff --git a/usr/src/usr.sbin/named/doc/rfc1033.lpr b/usr/src/usr.sbin/named/doc/rfc1033.lpr new file mode 100644 index 0000000000..7db4bee839 --- /dev/null +++ b/usr/src/usr.sbin/named/doc/rfc1033.lpr @@ -0,0 +1,1229 @@ +Network Working Group M. Lottor +Request For Comments: 1033 SRI International + November 1987 + + + DOMAIN ADMINISTRATORS OPERATIONS GUIDE + + + +STATUS OF THIS MEMO + + This RFC provides guidelines for domain administrators in operating a + domain server and maintaining their portion of the hierarchical + database. Familiarity with the domain system is assumed. + Distribution of this memo is unlimited. + +ACKNOWLEDGMENTS + + This memo is a formatted collection of notes and excerpts from the + references listed at the end of this document. Of particular mention + are Paul Mockapetris and Kevin Dunlap. + +INTRODUCTION + + A domain server requires a few files to get started. It will + normally have some number of boot/startup files (also known as the + "safety belt" files). One section will contain a list of possible + root servers that the server will use to find the up-to-date list of + root servers. Another section will list the zone files to be loaded + into the server for your local domain information. A zone file + typically contains all the data for a particular domain. This guide + describes the data formats that can be used in zone files and + suggested parameters to use for certain fields. If you are + attempting to do anything advanced or tricky, consult the appropriate + domain RFC's for more details. + + Note: Each implementation of domain software may require different + files. Zone files are standardized but some servers may require + other startup files. See the appropriate documentation that comes + with your software. See the appendix for some specific examples. + +ZONES + + A zone defines the contents of a contiguous section of the domain + space, usually bounded by administrative boundaries. There will + typically be a separate data file for each zone. The data contained + in a zone file is composed of entries called Resource Records (RRs). + + + + +Lottor [Page 1] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + You may only put data in your domain server that you are + authoritative for. You must not add entries for domains other than + your own (except for the special case of "glue records"). + + A domain server will probably read a file on start-up that lists the + zones it should load into its database. The format of this file is + not standardized and is different for most domain server + implementations. For each zone it will normally contain the domain + name of the zone and the file name that contains the data to load for + the zone. + +ROOT SERVERS + + A resolver will need to find the root servers when it first starts. + When the resolver boots, it will typically read a list of possible + root servers from a file. + + The resolver will cycle through the list trying to contact each one. + When it finds a root server, it will ask it for the current list of + root servers. It will then discard the list of root servers it read + from the data file and replace it with the current list it received. + + Root servers will not change very often. You can get the names of + current root servers from the NIC. + + FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to + NIC@SRI-NIC.ARPA. + + As of this date (June 1987) they are: + + SRI-NIC.ARPA 10.0.0.51 26.0.0.73 + C.ISI.EDU 10.0.0.52 + BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2 + A.ISI.EDU 26.3.0.103 + +RESOURCE RECORDS + + Records in the zone data files are called resource records (RRs). + They are specified in RFC-883 and RFC-973. An RR has a standard + format as shown: + + [] [] + + The record is divided into fields which are separated by white space. + + + + The name field defines what domain name applies to the given + + + +Lottor [Page 2] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + RR. In some cases the name field can be left blank and it will + default to the name field of the previous RR. + + + + TTL stands for Time To Live. It specifies how long a domain + resolver should cache the RR before it throws it out and asks a + domain server again. See the section on TTL's. If you leave + the TTL field blank it will default to the minimum time + specified in the SOA record (described later). + + + + The class field specifies the protocol group. If left blank it + will default to the last class specified. + + + + The type field specifies what type of data is in the RR. See + the section on types. + + + + The data field is defined differently for each type and class + of data. Popular RR data formats are described later. + + The domain system does not guarantee to preserve the order of + resource records. Listing RRs (such as multiple address records) in + a certain order does not guarantee they will be used in that order. + + Case is preserved in names and data fields when loaded into the name + server. All comparisons and lookups in the name server are case + insensitive. + + Parenthesis ("(",")") are used to group data that crosses a line + boundary. + + A semicolon (";") starts a comment; the remainder of the line is + ignored. + + The asterisk ("*") is used for wildcarding. + + The at-sign ("@") denotes the current default domain name. + + + + + + + + +Lottor [Page 3] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +NAMES + + A domain name is a sequence of labels separated by dots. + + Domain names in the zone files can be one of two types, either + absolute or relative. An absolute name is the fully qualified domain + name and is terminated with a period. A relative name does not + terminate with a period, and the current default domain is appended + to it. The default domain is usually the name of the domain that was + specified in the boot file that loads each zone. + + The domain system allows a label to contain any 8-bit character. + Although the domain system has no restrictions, other protocols such + as SMTP do have name restrictions. Because of other protocol + restrictions, only the following characters are recommended for use + in a host name (besides the dot separator): + + "A-Z", "a-z", "0-9", dash and underscore + +TTL's (Time To Live) + + It is important that TTLs are set to appropriate values. The TTL is + the time (in seconds) that a resolver will use the data it got from + your server before it asks your server again. If you set the value + too low, your server will get loaded down with lots of repeat + requests. If you set it too high, then information you change will + not get distributed in a reasonable amount of time. If you leave the + TTL field blank, it will default to what is specified in the SOA + record for the zone. + + Most host information does not change much over long time periods. A + good way to set up your TTLs would be to set them at a high value, + and then lower the value if you know a change will be coming soon. + You might set most TTLs to anywhere between a day (86400) and a week + (604800). Then, if you know some data will be changing in the near + future, set the TTL for that RR down to a lower value (an hour to a + day) until the change takes place, and then put it back up to its + previous value. + + Also, all RRs with the same name, class, and type should have the + same TTL value. + +CLASSES + + The domain system was designed to be protocol independent. The class + field is used to identify the protocol group that each RR is in. + + The class of interest to people using TCP/IP software is the class + + + +Lottor [Page 4] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + "Internet". Its standard designation is "IN". + + A zone file should only contain RRs of the same class. + +TYPES + + There are many defined RR types. For a complete list, see the domain + specification RFCs. Here is a list of current commonly used types. + The data for each type is described in the data section. + + Designation Description + ========================================== + SOA Start Of Authority + NS Name Server + + A Internet Address + CNAME Canonical Name (nickname pointer) + HINFO Host Information + WKS Well Known Services + + MX Mail Exchanger + + PTR Pointer + +SOA (Start Of Authority) + + [] [] SOA ( + + + + + ) + + The Start Of Authority record designates the start of a zone. The + zone ends at the next SOA record. + + is the name of the zone. + + is the name of the host on which the master zone file + resides. + + is a mailbox for the person responsible for the zone. It is + formatted like a mailing address but the at-sign that normally + separates the user from the host name is replaced with a dot. + + is the version number of the zone file. It should be + incremented anytime a change is made to data in the zone. + + + + +Lottor [Page 5] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + is how long, in seconds, a secondary name server is to + check with the primary name server to see if an update is needed. A + good value here would be one hour (3600). + + is how long, in seconds, a secondary name server is to retry + after a failure to check for a refresh. A good value here would be + 10 minutes (600). + + is the upper limit, in seconds, that a secondary name server + is to use the data before it expires for lack of getting a refresh. + You want this to be rather large, and a nice value is 3600000, about + 42 days. + + is the minimum number of seconds to be used for TTL values + in RRs. A minimum of at least a day is a good value here (86400). + + There should only be one SOA record per zone. A sample SOA record + would look something like: + + @ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. ( + 45 ;serial + 3600 ;refresh + 600 ;retry + 3600000 ;expire + 86400 ) ;minimum + + +NS (Name Server) + + [] [] NS + + The NS record lists the name of a machine that provides domain + service for a particular domain. The name associated with the RR is + the domain name and the data portion is the name of a host that + provides the service. If machines SRI-NIC.ARPA and C.ISI.EDU provide + name lookup service for the domain COM then the following entries + would be used: + + COM. NS SRI-NIC.ARPA. + NS C.ISI.EDU. + + Note that the machines providing name service do not have to live in + the named domain. There should be one NS record for each server for + a domain. Also note that the name "COM" defaults for the second NS + record. + + NS records for a domain exist in both the zone that delegates the + domain, and in the domain itself. + + + +Lottor [Page 6] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +GLUE RECORDS + + If the name server host for a particular domain is itself inside the + domain, then a 'glue' record will be needed. A glue record is an A + (address) RR that specifies the address of the server. Glue records + are only needed in the server delegating the domain, not in the + domain itself. If for example the name server for domain SRI.COM was + KL.SRI.COM, then the NS record would look like this, but you will + also need to have the following A record. + + SRI.COM. NS + KL.SRI.COM. KL.SRI.COM. A 10.1.0.2. + + +A (Address) + + [] [] A
+ + The data for an A record is an internet address in dotted decimal + form. A sample A record might look like: + + SRI-NIC.ARPA. A 10.0.0.51 + + There should be one A record for each address of a host. + +CNAME ( Canonical Name) + + [] [] CNAME + + The CNAME record is used for nicknames. The name associated with the + RR is the nickname. The data portion is the official name. For + example, a machine named SRI-NIC.ARPA may want to have the nickname + NIC.ARPA. In that case, the following RR would be used: + + NIC.ARPA. CNAME SRI-NIC.ARPA. + + There must not be any other RRs associated with a nickname of the + same class. + + Nicknames are also useful when a host changes it's name. In that + case, it is usually a good idea to have a CNAME pointer so that + people still using the old name will get to the right place. + + + + + + + + + +Lottor [Page 7] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +HINFO (Host Info) + + [] [] HINFO + + The HINFO record gives information about a particular host. The data + is two strings separated by whitespace. The first string is a + hardware description and the second is software. The hardware is + usually a manufacturer name followed by a dash and model designation. + The software string is usually the name of the operating system. + + Official HINFO types can be found in the latest Assigned Numbers RFC, + the latest of which is RFC-1010. The Hardware type is called the + Machine name and the Software type is called the System name. + + Some sample HINFO records: + + SRI-NIC.ARPA. HINFO DEC-2060 TOPS20 + UCBARPA.Berkeley.EDU. HINFO VAX-11/780 UNIX + + +WKS (Well Known Services) + + [] [] WKS
+ + The WKS record is used to list Well Known Services a host provides. + WKS's are defined to be services on port numbers below 256. The WKS + record lists what services are available at a certain address using a + certain protocol. The common protocols are TCP or UDP. A sample WKS + record for a host offering the same services on all address would + look like: + + Official protocol names can be found in the latest Assigned Numbers + RFC, the latest of which is RFC-1010. + + SRI-NIC.ARPA. WKS 10.0.0.51 TCP TELNET FTP SMTP + WKS 10.0.0.51 UDP TIME + WKS 26.0.0.73 TCP TELNET FTP SMTP + WKS 26.0.0.73 UDP TIME + +MX (Mail Exchanger) (See RFC-974 for more details.) + + [] [] MX + + MX records specify where mail for a domain name should be delivered. + There may be multiple MX records for a particular name. The + preference value specifies the order a mailer should try multiple MX + records when delivering mail. Zero is the highest preference. + Multiple records for the same name may have the same preference. + + + +Lottor [Page 8] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + A host BAR.FOO.COM may want its mail to be delivered to the host + PO.FOO.COM and would then use the MX record: + + BAR.FOO.COM. MX 10 PO.FOO.COM. + + A host BAZ.FOO.COM may want its mail to be delivered to one of three + different machines, in the following order: + + BAZ.FOO.COM. MX 10 PO1.FOO.COM. + MX 20 PO2.FOO.COM. + MX 30 PO3.FOO.COM. + + An entire domain of hosts not connected to the Internet may want + their mail to go through a mail gateway that knows how to deliver + mail to them. If they would like mail addressed to any host in the + domain FOO.COM to go through the mail gateway they might use: + + FOO.COM. MX 10 RELAY.CS.NET. + *.FOO.COM. MX 20 RELAY.CS.NET. + + Note that you can specify a wildcard in the MX record to match on + anything in FOO.COM, but that it won't match a plain FOO.COM. + +IN-ADDR.ARPA + + The structure of names in the domain system is set up in a + hierarchical way such that the address of a name can be found by + tracing down the domain tree contacting a server for each label of + the name. Because of this 'indexing' based on name, there is no easy + way to translate a host address back into its host name. + + In order to do the reverse translation easily, a domain was created + that uses hosts' addresses as part of a name that then points to the + data for that host. In this way, there is now an 'index' to hosts' + RRs based on their address. This address mapping domain is called + IN-ADDR.ARPA. Within that domain are subdomains for each network, + based on network number. Also, for consistency and natural + groupings, the 4 octets of a host number are reversed. + + For example, the ARPANET is net 10. That means there is a domain + called 10.IN-ADDR.ARPA. Within this domain there is a PTR RR at + 51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA + (who's address is 10.0.0.51). Since the NIC is also on the MILNET + (Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN- + ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA. The format + of these special pointers is defined below along with the examples + for the NIC. + + + + +Lottor [Page 9] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +PTR + + [] [] PTR + + The PTR record is used to let special names point to some other + location in the domain tree. They are mainly used in the IN- + ADDR.ARPA records for translation of addresses to names. PTR's + should use official names and not aliases. + + For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73 + would have the following records in the respective zone files for net + 10 and net 26: + + 51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. + 73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. + +GATEWAY PTR's + + The IN-ADDR tree is also used to locate gateways on a particular + network. Gateways have the same kind of PTR RRs as hosts (as above) + but in addition they have other PTRs used to locate them by network + number alone. These records have only 1, 2, or 3 octets as part of + the name depending on whether they are class A, B, or C networks, + respectively. + + Lets take the SRI-CSL gateway for example. It connects 3 different + networks, one class A, one class B and one class C. It will have the + standard RR's for a host in the CSL.SRI.COM zone: + + GW.CSL.SRI.COM. A 10.2.0.2 + A 128.18.1.1 + A 192.12.33.2 + + Also, in 3 different zones (one for each network), it will have one + of the following number to name translation pointers: + + 2.0.2.10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + 1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + 1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + + In addition, in each of the same 3 zones will be one of the following + gateway location pointers: + + 10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + 18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + 33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + + + + + +Lottor [Page 10] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +INSTRUCTIONS + + Adding a subdomain. + + To add a new subdomain to your domain: + + Setup the other domain server and/or the new zone file. + + Add an NS record for each server of the new domain to the zone + file of the parent domain. + + Add any necessary glue RRs. + + Adding a host. + + To add a new host to your zone files: + + Edit the appropriate zone file for the domain the host is in. + + Add an entry for each address of the host. + + Optionally add CNAME, HINFO, WKS, and MX records. + + Add the reverse IN-ADDR entry for each host address in the + appropriate zone files for each network the host in on. + + Deleting a host. + + To delete a host from the zone files: + + Remove all the hosts' resource records from the zone file of + the domain the host is in. + + Remove all the hosts' PTR records from the IN-ADDR zone files + for each network the host was on. + + Adding gateways. + + Follow instructions for adding a host. + + Add the gateway location PTR records for each network the + gateway is on. + + Deleting gateways. + + Follow instructions for deleting a host. + + Also delete the gateway location PTR records for each network + + + +Lottor [Page 11] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + the gateway was on. + +COMPLAINTS + + These are the suggested steps you should take if you are having + problems that you believe are caused by someone else's name server: + + + 1. Complain privately to the responsible person for the domain. You + can find their mailing address in the SOA record for the domain. + + 2. Complain publicly to the responsible person for the domain. + + 3. Ask the NIC for the administrative person responsible for the + domain. Complain. You can also find domain contacts on the NIC in + the file NETINFO:DOMAIN-CONTACTS.TXT + + 4. Complain to the parent domain authorities. + + 5. Ask the parent authorities to excommunicate the domain. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 12] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +EXAMPLE DOMAIN SERVER DATABASE FILES + + The following examples show how zone files are set up for a typical + organization. SRI will be used as the example organization. SRI has + decided to divided their domain SRI.COM into a few subdomains, one + for each group that wants one. The subdomains are CSL and ISTC. + + Note the following interesting items: + + There are both hosts and domains under SRI.COM. + + CSL.SRI.COM is both a domain name and a host name. + + All the domains are serviced by the same pair of domain servers. + + All hosts at SRI are on net 128.18 except hosts in the CSL domain + which are on net 192.12.33. Note that a domain does not have to + correspond to a physical network. + + The examples do not necessarily correspond to actual data in use + by the SRI domain. + + SRI Domain Organization + + +-------+ + | COM | + +-------+ + | + +-------+ + | SRI | + +-------+ + | + +----------++-----------+ + | | | + +-------+ +------+ +-------+ + | CSL | | ISTC | | Hosts | + +-------+ +------+ +-------+ + | | + +-------+ +-------+ + | Hosts | | Hosts | + +-------+ +-------+ + + + + + + + + + + +Lottor [Page 13] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "CONFIG.CMD". Since bootstrap files are not standardized, this + file is presented using a pseudo configuration file syntax.] + + load root server list from file ROOT.SERVERS + load zone SRI.COM. from file SRI.ZONE + load zone CSL.SRI.COM. from file CSL.ZONE + load zone ISTC.SRI.COM. from file ISTC.ZONE + load zone 18.128.IN-ADDR.ARPA. from file SRINET.ZONE + load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.ZONE + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 14] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "ROOT.SERVERS". Again, the format of this file is not + standardized.] + + ;list of possible root servers + SRI-NIC.ARPA 10.0.0.51 26.0.0.73 + C.ISI.EDU 10.0.0.52 + BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2 + A.ISI.EDU 26.3.0.103 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 15] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "SRI.ZONE"] + + SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. ( + 870407 ;serial + 1800 ;refresh every 30 minutes + 600 ;retry every 10 minutes + 604800 ;expire after a week + 86400 ;default of an hour + ) + + SRI.COM. NS KL.SRI.COM. + NS STRIPE.SRI.COM. + MX 10 KL.SRI.COM. + + ;SRI.COM hosts + + KL A 10.1.0.2 + A 128.18.10.6 + MX 10 KL.SRI.COM. + + STRIPE A 10.4.0.2 + STRIPE A 128.18.10.4 + MX 10 STRIPE.SRI.COM. + + NIC CNAME SRI-NIC.ARPA. + + Blackjack A 128.18.2.1 + HINFO VAX-11/780 UNIX + WKS 128.18.2.1 TCP TELNET FTP + + CSL A 192.12.33.2 + HINFO FOONLY-F4 TOPS20 + WKS 192.12.33.2 TCP TELNET FTP SMTP FINGER + MX 10 CSL.SRI.COM. + + + + + + + + + + + + + + + + + +Lottor [Page 16] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "CSL.ZONE"] + + CSL.SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. ( + 870330 ;serial + 1800 ;refresh every 30 minutes + 600 ;retry every 10 minutes + 604800 ;expire after a week + 86400 ;default of a day + ) + + CSL.SRI.COM. NS KL.SRI.COM. + NS STRIPE.SRI.COM. + A 192.12.33.2 + + ;CSL.SRI.COM hosts + + A CNAME CSL.SRI.COM. + B A 192.12.33.3 + HINFO FOONLY-F4 TOPS20 + WKS 192.12.33.3 TCP TELNET FTP SMTP + GW A 10.2.0.2 + A 192.12.33.1 + A 128.18.1.1 + HINFO PDP-11/23 MOS + SMELLY A 192.12.33.4 + HINFO IMAGEN IMAGEN + SQUIRREL A 192.12.33.5 + HINFO XEROX-1100 INTERLISP + VENUS A 192.12.33.7 + HINFO SYMBOLICS-3600 LISPM + HELIUM A 192.12.33.30 + HINFO SUN-3/160 UNIX + ARGON A 192.12.33.31 + HINFO SUN-3/75 UNIX + RADON A 192.12.33.32 + HINFO SUN-3/75 UNIX + + + + + + + + + + + + + + + +Lottor [Page 17] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "ISTC.ZONE"] + + ISTC.SRI.COM. IN SOA KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. ( + 870406 ;serial + 1800 ;refresh every 30 minutes + 600 ;retry every 10 minutes + 604800 ;expire after a week + 86400 ;default of a day + ) + + ISTC.SRI.COM. NS KL.SRI.COM. + NS STRIPE.SRI.COM. + MX 10 SPAM.ISTC.SRI.COM. + + ; ISTC hosts + + joyce A 128.18.4.2 + HINFO VAX-11/750 UNIX + bozo A 128.18.0.6 + HINFO SUN UNIX + sundae A 128.18.0.11 + HINFO SUN UNIX + tsca A 128.18.0.201 + A 10.3.0.2 + HINFO VAX-11/750 UNIX + MX 10 TSCA.ISTC.SRI.COM. + tsc CNAME tsca + prmh A 128.18.0.203 + A 10.2.0.51 + HINFO PDP-11/44 UNIX + spam A 128.18.4.3 + A 10.2.0.107 + HINFO VAX-11/780 UNIX + MX 10 SPAM.ISTC.SRI.COM. + + + + + + + + + + + + + + + + + +Lottor [Page 18] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "SRINET.ZONE"] + + 18.128.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. ( + 870406 ;serial + 1800 ;refresh every 30 minutes + 600 ;retry every 10 minutes + 604800 ;expire after a week + 86400 ;default of a day + ) + + 18.128.IN-ADDR.ARPA. NS KL.SRI.COM. + NS STRIPE.SRI.COM. + PTR GW.CSL.SRI.COM. + + ; SRINET [128.18.0.0] Address Translations + + ; SRI.COM Hosts + 1.2.18.128.IN-ADDR.ARPA. PTR Blackjack.SRI.COM. + + ; ISTC.SRI.COM Hosts + 2.4.18.128.IN-ADDR.ARPA. PTR joyce.ISTC.SRI.COM. + 6.0.18.128.IN-ADDR.ARPA. PTR bozo.ISTC.SRI.COM. + 11.0.18.128.IN-ADDR.ARPA. PTR sundae.ISTC.SRI.COM. + 201.0.18.128.IN-ADDR.ARPA. PTR tsca.ISTC.SRI.COM. + 203.0.18.128.IN-ADDR.ARPA. PTR prmh.ISTC.SRI.COM. + 3.4.18.128.IN-ADDR.ARPA. PTR spam.ISTC.SRI.COM. + + ; CSL.SRI.COM Hosts + 1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 19] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + [File "SRI-CSL-NET.ZONE"] + + 33.12.192.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. ( + 870404 ;serial + 1800 ;refresh every 30 minutes + 600 ;retry every 10 minutes + 604800 ;expire after a week + 86400 ;default of a day + ) + + 33.12.192.IN-ADDR.ARPA. NS KL.SRI.COM. + NS STRIPE.SRI.COM. + PTR GW.CSL.SRI.COM. + + ; SRI-CSL-NET [192.12.33.0] Address Translations + + ; SRI.COM Hosts + 2.33.12.192.IN-ADDR.ARPA. PTR CSL.SRI.COM. + + ; CSL.SRI.COM Hosts + 1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. + 3.33.12.192.IN-ADDR.ARPA. PTR B.CSL.SRI.COM. + 4.33.12.192.IN-ADDR.ARPA. PTR SMELLY.CSL.SRI.COM. + 5.33.12.192.IN-ADDR.ARPA. PTR SQUIRREL.CSL.SRI.COM. + 7.33.12.192.IN-ADDR.ARPA. PTR VENUS.CSL.SRI.COM. + 30.33.12.192.IN-ADDR.ARPA. PTR HELIUM.CSL.SRI.COM. + 31.33.12.192.IN-ADDR.ARPA. PTR ARGON.CSL.SRI.COM. + 32.33.12.192.IN-ADDR.ARPA. PTR RADON.CSL.SRI.COM. + + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 20] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +APPENDIX + + BIND (Berkeley Internet Name Domain server) distributed with 4.3 BSD + UNIX + + This section describes two BIND implementation specific files; the + boot file and the cache file. BIND has other options, files, and + specifications that are not described here. See the Name Server + Operations Guide for BIND for details. + + The boot file for BIND is usually called "named.boot". This + corresponds to file "CONFIG.CMD" in the example section. + + -------------------------------------------------------- + cache . named.ca + primary SRI.COM SRI.ZONE + primary CSL.SRI.COM CSL.ZONE + primary ISTC.SRI.COM ISTC.ZONE + primary 18.128.IN-ADDR.ARPA SRINET.ZONE + primary 33.12.192.IN-ADDR.ARPA SRI-CSL-NET.ZONE + -------------------------------------------------------- + + The cache file for BIND is usually called "named.ca". This + corresponds to file "ROOT.SERVERS" in the example section. + + ------------------------------------------------- + ;list of possible root servers + . 1 IN NS SRI-NIC.ARPA. + NS C.ISI.EDU. + NS BRL-AOS.ARPA. + NS C.ISI.EDU. + ;and their addresses + SRI-NIC.ARPA. A 10.0.0.51 + A 26.0.0.73 + C.ISI.EDU. A 10.0.0.52 + BRL-AOS.ARPA. A 192.5.25.82 + A 192.5.22.82 + A 128.20.1.2 + A.ISI.EDU. A 26.3.0.103 + ------------------------------------------------- + + + + + + + + + + + +Lottor [Page 21] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + +REFERENCES + + [1] Dunlap, K., "Name Server Operations Guide for BIND", CSRG, + Department of Electrical Engineering and Computer Sciences, + University of California, Berkeley, California. + + [2] Partridge, C., "Mail Routing and the Domain System", RFC-974, + CSNET CIC BBN Laboratories, January 1986. + + [3] Mockapetris, P., "Domains Names - Concepts and Facilities", + RFC-1034, USC/Information Sciences Institute, November 1987. + + [4] Mockapetris, P., "Domain Names - Implementations Specification", + RFC-1035, USC/Information Sciences Institute, November 1987. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lottor [Page 22] + diff --git a/usr/src/usr.sbin/named/doc/rfc1034.lpr b/usr/src/usr.sbin/named/doc/rfc1034.lpr new file mode 100644 index 0000000000..55cdb21fe6 --- /dev/null +++ b/usr/src/usr.sbin/named/doc/rfc1034.lpr @@ -0,0 +1,3077 @@ +Network Working Group P. Mockapetris +Request for Comments: 1034 ISI +Obsoletes: RFCs 882, 883, 973 November 1987 + + + DOMAIN NAMES - CONCEPTS AND FACILITIES + + + +1. STATUS OF THIS MEMO + +This RFC is an introduction to the Domain Name System (DNS), and omits +many details which can be found in a companion RFC, "Domain Names - +Implementation and Specification" [RFC-1035]. That RFC assumes that the +reader is familiar with the concepts discussed in this memo. + +A subset of DNS functions and data types constitute an official +protocol. The official protocol includes standard queries and their +responses and most of the Internet class data formats (e.g., host +addresses). + +However, the domain system is intentionally extensible. Researchers are +continuously proposing, implementing and experimenting with new data +types, query types, classes, functions, etc. Thus while the components +of the official protocol are expected to stay essentially unchanged and +operate as a production service, experimental behavior should always be +expected in extensions beyond the official protocol. Experimental or +obsolete features are clearly marked in these RFCs, and such information +should be used with caution. + +The reader is especially cautioned not to depend on the values which +appear in examples to be current or complete, since their purpose is +primarily pedagogical. Distribution of this memo is unlimited. + +2. INTRODUCTION + +This RFC introduces domain style names, their use for Internet mail and +host address support, and the protocols and servers used to implement +domain name facilities. + +2.1. The history of domain names + +The impetus for the development of the domain system was growth in the +Internet: + + - Host name to address mappings were maintained by the Network + Information Center (NIC) in a single file (HOSTS.TXT) which + was FTPed by all hosts [RFC-952, RFC-953]. The total network + + + +Mockapetris [Page 1] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + bandwidth consumed in distributing a new version by this + scheme is proportional to the square of the number of hosts in + the network, and even when multiple levels of FTP are used, + the outgoing FTP load on the NIC host is considerable. + Explosive growth in the number of hosts didn't bode well for + the future. + + - The network population was also changing in character. The + timeshared hosts that made up the original ARPANET were being + replaced with local networks of workstations. Local + organizations were administering their own names and + addresses, but had to wait for the NIC to change HOSTS.TXT to + make changes visible to the Internet at large. Organizations + also wanted some local structure on the name space. + + - The applications on the Internet were getting more + sophisticated and creating a need for general purpose name + service. + + +The result was several ideas about name spaces and their management +[IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a +common thread was the idea of a hierarchical name space, with the +hierarchy roughly corresponding to organizational structure, and names +using "." as the character to mark the boundary between hierarchy +levels. A design using a distributed database and generalized resources +was described in [RFC-882, RFC-883]. Based on experience with several +implementations, the system evolved into the scheme described in this +memo. + +The terms "domain" or "domain name" are used in many contexts beyond the +DNS described here. Very often, the term domain name is used to refer +to a name with structure indicated by dots, but no relation to the DNS. +This is particularly true in mail addressing [Quarterman 86]. + +2.2. DNS design goals + +The design goals of the DNS influence its structure. They are: + + - The primary goal is a consistent name space which will be used + for referring to resources. In order to avoid the problems + caused by ad hoc encodings, names should not be required to + contain network identifiers, addresses, routes, or similar + information as part of the name. + + - The sheer size of the database and frequency of updates + suggest that it must be maintained in a distributed manner, + with local caching to improve performance. Approaches that + + + +Mockapetris [Page 2] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + attempt to collect a consistent copy of the entire database + will become more and more expensive and difficult, and hence + should be avoided. The same principle holds for the structure + of the name space, and in particular mechanisms for creating + and deleting names; these should also be distributed. + + - Where there tradeoffs between the cost of acquiring data, the + speed of updates, and the accuracy of caches, the source of + the data should control the tradeoff. + + - The costs of implementing such a facility dictate that it be + generally useful, and not restricted to a single application. + We should be able to use names to retrieve host addresses, + mailbox data, and other as yet undetermined information. All + data associated with a name is tagged with a type, and queries + can be limited to a single type. + + - Because we want the name space to be useful in dissimilar + networks and applications, we provide the ability to use the + same name space with different protocol families or + management. For example, host address formats differ between + protocols, though all protocols have the notion of address. + The DNS tags all data with a class as well as the type, so + that we can allow parallel use of different formats for data + of type address. + + - We want name server transactions to be independent of the + communications system that carries them. Some systems may + wish to use datagrams for queries and responses, and only + establish virtual circuits for transactions that need the + reliability (e.g., database updates, long transactions); other + systems will use virtual circuits exclusively. + + - The system should be useful across a wide spectrum of host + capabilities. Both personal computers and large timeshared + hosts should be able to use the system, though perhaps in + different ways. + +2.3. Assumptions about usage + +The organization of the domain system derives from some assumptions +about the needs and usage patterns of its user community and is designed +to avoid many of the the complicated problems found in general purpose +database systems. + +The assumptions are: + + - The size of the total database will initially be proportional + + + +Mockapetris [Page 3] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + to the number of hosts using the system, but will eventually + grow to be proportional to the number of users on those hosts + as mailboxes and other information are added to the domain + system. + + - Most of the data in the system will change very slowly (e.g., + mailbox bindings, host addresses), but that the system should + be able to deal with subsets that change more rapidly (on the + order of seconds or minutes). + + - The administrative boundaries used to distribute + responsibility for the database will usually correspond to + organizations that have one or more hosts. Each organization + that has responsibility for a particular set of domains will + provide redundant name servers, either on the organization's + own hosts or other hosts that the organization arranges to + use. + + - Clients of the domain system should be able to identify + trusted name servers they prefer to use before accepting + referrals to name servers outside of this "trusted" set. + + - Access to information is more critical than instantaneous + updates or guarantees of consistency. Hence the update + process allows updates to percolate out through the users of + the domain system rather than guaranteeing that all copies are + simultaneously updated. When updates are unavailable due to + network or host failure, the usual course is to believe old + information while continuing efforts to update it. The + general model is that copies are distributed with timeouts for + refreshing. The distributor sets the timeout value and the + recipient of the distribution is responsible for performing + the refresh. In special situations, very short intervals can + be specified, or the owner can prohibit copies. + + - In any system that has a distributed database, a particular + name server may be presented with a query that can only be + answered by some other server. The two general approaches to + dealing with this problem are "recursive", in which the first + server pursues the query for the client at another server, and + "iterative", in which the server refers the client to another + server and lets the client pursue the query. Both approaches + have advantages and disadvantages, but the iterative approach + is preferred for the datagram style of access. The domain + system requires implementation of the iterative approach, but + allows the recursive approach as an option. + + + + + +Mockapetris [Page 4] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +The domain system assumes that all data originates in master files +scattered through the hosts that use the domain system. These master +files are updated by local system administrators. Master files are text +files that are read by a local name server, and hence become available +through the name servers to users of the domain system. The user +programs access name servers through standard programs called resolvers. + +The standard format of master files allows them to be exchanged between +hosts (via FTP, mail, or some other mechanism); this facility is useful +when an organization wants a domain, but doesn't want to support a name +server. The organization can maintain the master files locally using a +text editor, transfer them to a foreign host which runs a name server, +and then arrange with the system administrator of the name server to get +the files loaded. + +Each host's name servers and resolvers are configured by a local system +administrator [RFC-1033]. For a name server, this configuration data +includes the identity of local master files and instructions on which +non-local master files are to be loaded from foreign servers. The name +server uses the master files or copies to load its zones. For +resolvers, the configuration data identifies the name servers which +should be the primary sources of information. + +The domain system defines procedures for accessing the data and for +referrals to other name servers. The domain system also defines +procedures for caching retrieved data and for periodic refreshing of +data defined by the system administrator. + +The system administrators provide: + + - The definition of zone boundaries. + + - Master files of data. + + - Updates to master files. + + - Statements of the refresh policies desired. + +The domain system provides: + + - Standard formats for resource data. + + - Standard methods for querying the database. + + - Standard methods for name servers to refresh local data from + foreign name servers. + + + + + +Mockapetris [Page 5] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +2.4. Elements of the DNS + +The DNS has three major components: + + - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are + specifications for a tree structured name space and data + associated with the names. Conceptually, each node and leaf + of the domain name space tree names a set of information, and + query operations are attempts to extract specific types of + information from a particular set. A query names the domain + name of interest and describes the type of resource + information that is desired. For example, the Internet + uses some of its domain names to identify hosts; queries for + address resources return Internet host addresses. + + - NAME SERVERS are server programs which hold information about + the domain tree's structure and set information. A name + server may cache structure or set information about any part + of the domain tree, but in general a particular name server + has complete information about a subset of the domain space, + and pointers to other name servers that can be used to lead to + information from any part of the domain tree. Name servers + know the parts of the domain tree for which they have complete + information; a name server is said to be an AUTHORITY for + these parts of the name space. Authoritative information is + organized into units called ZONEs, and these zones can be + automatically distributed to the name servers which provide + redundant service for the data in a zone. + + - RESOLVERS are programs that extract information from name + servers in response to client requests. Resolvers must be + able to access at least one name server and use that name + server's information to answer a query directly, or pursue the + query using referrals to other name servers. A resolver will + typically be a system routine that is directly accessible to + user programs; hence no protocol is necessary between the + resolver and the user program. + +These three components roughly correspond to the three layers or views +of the domain system: + + - From the user's point of view, the domain system is accessed + through a simple procedure or OS call to a local resolver. + The domain space consists of a single tree and the user can + request information from any section of the tree. + + - From the resolver's point of view, the domain system is + composed of an unknown number of name servers. Each name + + + +Mockapetris [Page 6] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + server has one or more pieces of the whole domain tree's data, + but the resolver views each of these databases as essentially + static. + + - From a name server's point of view, the domain system consists + of separate sets of local information called zones. The name + server has local copies of some of the zones. The name server + must periodically refresh its zones from master copies in + local files or foreign name servers. The name server must + concurrently process queries that arrive from resolvers. + +In the interests of performance, implementations may couple these +functions. For example, a resolver on the same machine as a name server +might share a database consisting of the the zones managed by the name +server and the cache managed by the resolver. + +3. DOMAIN NAME SPACE and RESOURCE RECORDS + +3.1. Name space specifications and terminology + +The domain name space is a tree structure. Each node and leaf on the +tree corresponds to a resource set (which may be empty). The domain +system makes no distinctions between the uses of the interior nodes and +leaves, and this memo uses the term "node" to refer to both. + +Each node has a label, which is zero to 63 octets in length. Brother +nodes may not have the same label, although the same label can be used +for nodes which are not brothers. One label is reserved, and that is +the null (i.e., zero length) label used for the root. + +The domain name of a node is the list of the labels on the path from the +node to the root of the tree. By convention, the labels that compose a +domain name are printed or read left to right, from the most specific +(lowest, farthest from the root) to the least specific (highest, closest +to the root). + +Internally, programs that manipulate domain names should represent them +as sequences of labels, where each label is a length octet followed by +an octet string. Because all domain names end at the root, which has a +null string for a label, these internal representations can use a length +byte of zero to terminate a domain name. + +By convention, domain names can be stored with arbitrary case, but +domain name comparisons for all present domain functions are done in a +case-insensitive manner, assuming an ASCII character set, and a high +order zero bit. This means that you are free to create a node with +label "A" or a node with label "a", but not both as brothers; you could +refer to either using "a" or "A". When you receive a domain name or + + + +Mockapetris [Page 7] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +label, you should preserve its case. The rationale for this choice is +that we may someday need to add full binary domain names for new +services; existing services would not be changed. + +When a user needs to type a domain name, the length of each label is +omitted and the labels are separated by dots ("."). Since a complete +domain name ends with the root label, this leads to a printed form which +ends in a dot. We use this property to distinguish between: + + - a character string which represents a complete domain name + (often called "absolute"). For example, "poneria.ISI.EDU." + + - a character string that represents the starting labels of a + domain name which is incomplete, and should be completed by + local software using knowledge of the local domain (often + called "relative"). For example, "poneria" used in the + ISI.EDU domain. + +Relative names are either taken relative to a well known origin, or to a +list of domains used as a search list. Relative names appear mostly at +the user interface, where their interpretation varies from +implementation to implementation, and in master files, where they are +relative to a single origin domain name. The most common interpretation +uses the root "." as either the single origin or as one of the members +of the search list, so a multi-label relative name is often one where +the trailing dot has been omitted to save typing. + +To simplify implementations, the total number of octets that represent a +domain name (i.e., the sum of all label octets and label lengths) is +limited to 255. + +A domain is identified by a domain name, and consists of that part of +the domain name space that is at or below the domain name which +specifies the domain. A domain is a subdomain of another domain if it +is contained within that domain. This relationship can be tested by +seeing if the subdomain's name ends with the containing domain's name. +For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ". + +3.2. Administrative guidelines on use + +As a matter of policy, the DNS technical specifications do not mandate a +particular tree structure or rules for selecting labels; its goal is to +be as general as possible, so that it can be used to build arbitrary +applications. In particular, the system was designed so that the name +space did not have to be organized along the lines of network +boundaries, name servers, etc. The rationale for this is not that the +name space should have no implied semantics, but rather that the choice +of implied semantics should be left open to be used for the problem at + + + +Mockapetris [Page 8] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +hand, and that different parts of the tree can have different implied +semantics. For example, the IN-ADDR.ARPA domain is organized and +distributed by network and host address because its role is to translate +from network or host numbers to names; NetBIOS domains [RFC-1001, RFC- +1002] are flat because that is appropriate for that application. + +However, there are some guidelines that apply to the "normal" parts of +the name space used for hosts, mailboxes, etc., that will make the name +space more uniform, provide for growth, and minimize problems as +software is converted from the older host table. The political +decisions about the top levels of the tree originated in RFC-920. +Current policy for the top levels is discussed in [RFC-1032]. MILNET +conversion issues are covered in [RFC-1031]. + +Lower domains which will eventually be broken into multiple zones should +provide branching at the top of the domain so that the eventual +decomposition can be done without renaming. Node labels which use +special characters, leading digits, etc., are likely to break older +software which depends on more restrictive choices. + +3.3. Technical guidelines on use + +Before the DNS can be used to hold naming information for some kind of +object, two needs must be met: + + - A convention for mapping between object names and domain + names. This describes how information about an object is + accessed. + + - RR types and data formats for describing the object. + +These rules can be quite simple or fairly complex. Very often, the +designer must take into account existing formats and plan for upward +compatibility for existing usage. Multiple mappings or levels of +mapping may be required. + +For hosts, the mapping depends on the existing syntax for host names +which is a subset of the usual text representation for domain names, +together with RR formats for describing host addresses, etc. Because we +need a reliable inverse mapping from address to host name, a special +mapping for addresses into the IN-ADDR.ARPA domain is also defined. + +For mailboxes, the mapping is slightly more complex. The usual mail +address @ is mapped into a domain name by +converting into a single label (regardles of dots it +contains), converting into a domain name using the usual +text format for domain names (dots denote label breaks), and +concatenating the two to form a single domain name. Thus the mailbox + + + +Mockapetris [Page 9] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by +HOSTMASTER.SRI-NIC.ARPA. An appreciation for the reasons behind this +design also must take into account the scheme for mail exchanges [RFC- +974]. + +The typical user is not concerned with defining these rules, but should +understand that they usually are the result of numerous compromises +between desires for upward compatibility with old usage, interactions +between different object definitions, and the inevitable urge to add new +features when defining the rules. The way the DNS is used to support +some object is often more crucial than the restrictions inherent in the +DNS. + +3.4. Example name space + +The following figure shows a part of the current domain name space, and +is used in many examples in this RFC. Note that the tree is a very +small subset of the actual name space. + + | + | + +---------------------+------------------+ + | | | + MIL EDU ARPA + | | | + | | | + +-----+-----+ | +------+-----+-----+ + | | | | | | | + BRL NOSC DARPA | IN-ADDR SRI-NIC ACC + | + +--------+------------------+---------------+--------+ + | | | | | + UCI MIT | UDEL YALE + | ISI + | | + +---+---+ | + | | | + LCS ACHILLES +--+-----+-----+--------+ + | | | | | | + XX A C VAXA VENERA Mockapetris + +In this example, the root domain has three immediate subdomains: MIL, +EDU, and ARPA. The LCS.MIT.EDU domain has one immediate subdomain named +XX.LCS.MIT.EDU. All of the leaves are also domains. + +3.5. Preferred name syntax + +The DNS specifications attempt to be as general as possible in the rules + + + +Mockapetris [Page 10] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +for constructing domain names. The idea is that the name of any +existing object can be expressed as a domain name with minimal changes. +However, when assigning a domain name for an object, the prudent user +will select a name which satisfies both the rules of the domain system +and any existing rules for the object, whether these rules are published +or implied by existing programs. + +For example, when naming a mail domain, the user should satisfy both the +rules of this memo and those in RFC-822. When creating a new host name, +the old rules for HOSTS.TXT should be followed. This avoids problems +when old software is converted to use domain names. + +The following syntax will result in fewer problems with many +applications that use domain names (e.g., mail, TELNET). + + ::= | " " + + ::=