|
|
|
Distinguished Toastmaster
BUSINESS & BRANDING COACH . LIFE & LEADERSHIP STRATEGIST MOTIVATIONAL SPEAKER SERVING ENTREPRENEURS & MAIN STREET |
RFC 920 . DOMAIN REQUIREMENTS
[Docs] [txt|pdf]
Network Working Group J. Postel Request for Comments: 920 J. Reynolds ISI October 1984 Domain Requirements Status of this Memo This memo is a policy statement on the requirements of establishing a new domain in the ARPA-Internet and the DARPA research community. This is an official policy statement of the IAB and the DARPA. Distribution of this memo is unlimited. Introduction This memo restates and refines the requirements on establishing a Domain first described in RFC-881 [1]. It adds considerable detail to that discussion, and introduces the limited set of top level domains. The Purpose of Domains Domains are administrative entities. The purpose and expected use of domains is to divide the name management required of a central administration and assign it to sub-administrations. There are no geographical, topological, or technological constraints on a domain. The hosts in a domain need not have common hardware or software, nor even common protocols. Most of the requirements and limitations on domains are designed to ensure responsible administration. The domain system is a tree-structured global name space that has a few top level domains. The top level domains are subdivided into second level domains. The second level domains may be subdivided into third level domains, and so on. The administration of a domain requires controlling the assignment of names within that domain and providing access to the names and name related information (such as addresses) to users both inside and outside the domain. Postel & Reynolds [Page 1]
RFC 920 October 1984 Domain Requirements General Purpose Domains While the initial domain name "ARPA" arises from the history of the development of this system and environment, in the future most of the top level names will be very general categories like "government", "education", or "commercial". The motivation is to provide an organization name that is free of undesirable semantics. After a short period of initial experimentation, all current ARPA-Internet hosts will select some domain other than ARPA for their future use. The use of ARPA as a top level domain will eventually cease. Initial Set of Top Level Domains The initial top level domain names are: Temporary ARPA = The current ARPA-Internet hosts. Categories GOV = Government, any government related domains meeting the second level requirements. EDU = Education, any education related domains meeting the second level requirements. COM = Commercial, any commercial related domains meeting the second level requirements. MIL = Military, any military related domains meeting the second level requirements. ORG = Organization, any other domains meeting the second level requirements. Countries The English two letter code (alpha-2) identifying a country according the the ISO Standard for "Codes for the Representation of Names of Countries" [5]. Postel & Reynolds [Page 2]
RFC 920 October 1984 Domain Requirements Multiorganizations A multiorganization may be a top level domain if it is large, and is composed of other organizations; particularly if the multiorganization can not be easily classified into one of the categories and is international in scope. Possible Examples of Domains The following examples are fictions of the authors' creation, any similarity to the real world is coincidental. The UC Domain It might be that a large state wide university with, say, nine campuses and several laboratories may want to form a domain. Each campus or major off-campus laboratory might then be a subdomain, and within each subdomain, each department could be further distinguished. This university might be a second level domain in the education category. One might see domain style names for hosts in this domain like these: LOCUS.CS.LA.UC.EDU CCN.OAC.LA.UC.EDU ERNIE.CS.CAL.UC.EDU A.S1.LLNL.UC.EDU A.LAND.LANL.UC.EDU NMM.LBL.CAL.UC.EDU The MIT Domain Another large university may have many hosts using a variety of machine types, some even using several families of protocols. However, the administrators at this university may see no need for the outside world to be aware of these internal differences. This university might be a second level domain in the education category. One might see domain style names for hosts in this domain like these: APIARY-1.MIT.EDU BABY-BLUE.MIT.EDU CEZANNE.MIT.EDU DASH.MIT.EDU Postel & Reynolds [Page 3]
RFC 920 October 1984 Domain Requirements MULTICS.MIT.EDU TAC.MIT.EDU XX.MIT.EDU The CSNET Domain There may be a consortium of universities and industry research laboratories called, say, "CSNET". This CSNET is not a network per se, but rather a computer mail exchange using a variety of protocols and network systems. Therefore, CSNET is not a network in the sense of the ARPANET, or an Ethernet, or even the ARPA-Internet, but rather a community. Yet it does, in fact, have the key property needed to form a domain; it has a responsible administration. This consortium might be large enough and might have membership that cuts across the categories in such a way that it qualifies under the "multiorganization rule" to be a top level domain. One might see domain style names for hosts in this domain like these: CIC.CSNET EMORY.CSNET GATECH.CSNET HP-LABS.CSNET SJ.IBM.CSNET UDEL.CSNET UWISC.CSNET General 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 an authoritative coordinator for domain related questions. There must be a robust domain name lookup service, it must be of at least a minimum size, and the domain must be registered with the central domain administrator (the Network Information Center (NIC) Domain Registrar). Responsible Person: An individual must be identified who has authority for the administration of the names within the domain, and who seriously takes on the responsibility for the behavior of the hosts in the domain, plus their interactions with hosts outside the domain. This person must have some technical expertise and the authority within the domain to see that problems are fixed. Postel & Reynolds [Page 4]
RFC 920 October 1984 Domain Requirements If a host in a given domain somehow misbehaves in its interactions with hosts outside the domain (e.g., consistently violates protocols), the responsible person for the domain must be competent and available to receive reports of problems, take action on the reported problems, and follow through to eliminate the problems. Domain Servers: A robust and reliable domain server must be provided. One way of meeting this requirement is to provide at least two independent domain servers for the domain. The database 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. They should have no common point of failure. Some domains may find that providing a robust domain service can most easily be done by cooperating with another domain where each domain provides an additional server for the other. In other situations, it may be desirable for a domain to arrange for domain service to be provided by a third party, perhaps on hosts located outside the domain. One of the difficult problems in operating a domain server is the acquisition and maintenance of the data. In this case, the data are 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 database is easily managed. In the technical language of the domain server implementation the data is divided into zones. Domains and zones are not necessarily one-to-one. It may be reasonable for two or more domains to combine their data in a single zone. The responsible person or an identified technical assistant must understand in detail the procedures for operating a domain server, including the management of master files and zones. The operation of a domain server should not be taken on lightly. There are some difficult problems in providing an adequate service, primarily the problems in keeping the database up to date, and keeping the service operating. Postel & Reynolds [Page 5]
RFC 920 October 1984 Domain Requirements The concepts and implementation details of the domain server are given in RFC-882 [2] and RFC-883 [3]. Minimum Size: The domain must be of at least a minimum size. There is no requirement to form a domain because some set of hosts is above the minimum size. Top level domains must be specially authorized. In general, they will only be authorized for domains expected to have over 500 hosts. The general guideline for a second level domain is that it have over 50 hosts. This is a very soft "requirement". It makes sense that any major organization, such as a university or corporation, be allowed as a second level domain -- even if it has just a few hosts. Registration: Top level domains must be specially authorized and registered with the NIC domain registrar. The administrator of a level N domain must register with the registrar (or responsible person) of the level N-1 domain. This upper level authority must be satisfied that the requirements are met before authorization for the domain is granted. The registration procedure involves answering specific questions about the prospective domain. A prototype of what the NIC Domain Registrar may ask for the registration of a second level domain is shown below. These questions may change from time to time. It is the responsibility of domain administrators to keep this information current. 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 within 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. Even if sub-domains are established, the responsible person for the top-level domain is ultimately responsible for the whole tree of sub-domains and hosts. This does not mean that a domain administrator has to know the Postel & Reynolds [Page 6]
RFC 920 October 1984 Domain Requirements details of all the sub-domains and hosts to the Nth degree, but simply that if a problem occurs he can get it fixed by calling on the administrator of the sub-domain containing the problem. Top Level Domain Requirements There are very few top level domains, each of these may have many second level domains. An initial set of top level names has been identified. Each of these has an administrator and an agent. The top level domains: ARPA = The ARPA-Internet *** TEMPORARY *** Administrator: DARPA Agent: The Network Information Center Mailbox: [email protected] GOV = Government Administrator: DARPA Agent: The Network Information Center Mailbox: [email protected] EDU = Education Administrator: DARPA Agent: The Network Information Center Mailbox: [email protected] COM = Commercial Administrator: DARPA Agent: The Network Information Center Mailbox: [email protected] MIL = Military Administrator: DDN-PMO Agent: The Network Information Center Mailbox: [email protected] Postel & Reynolds [Page 7]
RFC 920 October 1984 Domain Requirements ORG = Organization Administrator: DARPA Agent: The Network Information Center Mailbox: [email protected] Countries The English two letter code (alpha-2) identifying a country according the the ISO Standard for "Codes for the Representation of Names of Countries" [5]. As yet no country domains have been established. As they are established information about the administrators and agents will be made public, and will be listed in subsequent editions of this memo. Multiorganizations A multiorganization may be a top level domain if it is large, and is composed of other organizations; particularly if the multiorganization can not be easily classified into one of the categories and is international in scope. As yet no multiorganization domains have been established. As they are established information about the administrators and agents will be made public, and will be listed in subsequent editions of this memo. Note: The NIC is listed as the agent and registrar for all the currently allowed top level domains. If there are other entities that would be more appropriate agents and registrars for some or all of these domains then it would be desirable to reassign the responsibility. Second Level Domain Requirements Each top level domain may have many second level domains. Every second level domain must meet the general requirements on a domain specified above, and be registered with a top level domain administrator. Postel & Reynolds [Page 8]
RFC 920 October 1984 Domain Requirements Third through Nth Level Domain Requirements Each second level domain may have many third level domains, etc. Every third level domain (through Nth level domain) must meet the requirements set by the administrator of the immediately higher level domain. Note that these may be more or less strict than the general requirements. One would expect the minimum size requirements to decrease at each level. The ARPA Domain At the time the implementation of the domain concept was begun it was thought that the set of hosts under the administrative authority of DARPA would make up a domain. Thus the initial domain selected was called ARPA. Now it is seen that there is no strong motivation for there to be a top level ARPA domain. The plan is for the current ARPA domain to go out of business as soon as possible. Hosts that are currently members of the ARPA domain should make arrangements to join another domain. It is likely that for experimental purposes there will be a second level domain called ARPA in the ORG domain (i.e., there will probably be an ARPA.ORG domain). The DDN Hosts DDN hosts that do not desire to participate in this domain naming system will continue to use the HOSTS.TXT data file maintained by the NIC for name to address translations. This file will be kept up to date for the DDN hosts. However, all DDN hosts will change their names from "host.ARPA" to (for example) "host.DDN.MIL" some time in the future. The schedule for changes required in DDN hosts will be established by the DDN-PMO. Impact on Hosts What is a host administrator to do about all this? For existing hosts already operating in the ARPA-Internet, the best advice is to sit tight for now. Take a few months to consider the options, then select a domain to join. Plan carefully for the impact that changing your host name will have on both your local users and on their remote correspondents. For a new host, careful thought should be given (as discussed below). Some guidance can be obtained by comparing notes on what other hosts with similar administrative properties have done. The owner of a host may decide which domain to join, and the Postel & Reynolds [Page 9]
RFC 920 October 1984 Domain Requirements administrator of a domain may decide which hosts to accept into his domain. Thus the owner of a host and a domain administrator must come to an understanding about the host being in the domain. This is the foundation of responsible administration. For example, a host "XYZ" at MIT might possible be considered as a candidate for becoming any of XYZ.ARPA.ORG, XYZ.CSNET, or XYZ.MIT.EDU. The owner of host XYZ may choose which domain to join, depending on which domain administrators are willing to have him. The domain is part of the host name. Thus if USC-ISIA.ARPA changes its domain affiliation to DDN.MIL to become USC-ISIA.DDN.MIL, it has changed its name. This means that any previous references to USC-ISIA.ARPA are now out of date. Such old references may include private host name to address tables, and any recorded information about mailboxes such as mailing lists, the headers of old messages, printed directories, and peoples' memories. The experience of the DARPA community suggests that changing the name of a host is somewhat painful. It is recommended that careful thought be given to choosing a new name for a host - which includes selecting its place in the domain hierarchy. The Roles of the Network Information Center The NIC plays two types of roles in the administration of domains. First, the NIC is the registrar of all top level domains. Second the NIC is the administrator of several top level domains (and the registrar for second level domains in these). Top Level Domain Registrar As the registrar for top level domains, the NIC is the contact point for investigating the possibility of establishing a new top level domain. Top Level Domain Administrator For the top level domains designated so far, the NIC is the administrator of each of these domains. This means the NIC is responsible for the management of these domains and the registration of the second level domains or hosts (if at the second level) in these domains. Postel & Reynolds [Page 10]
RFC 920 October 1984 Domain Requirements It may be reasonable for the administration of some of these domains to be taken on by other authorities in the future. It is certainly not desired that the NIC be the administrator of all top level domains forever. Prototypical Questions To establish a domain, the following information must be provided to the NIC Domain Registrar ([email protected]): Note: The key people must have computer mail mailboxes and NIC-Idents. If they do not at present, please remedy the situation at once. A NIC-Ident may be established by contacting [email protected]. 1) The name of the top level domain to join. For example: EDU 2) The name, title, mailing address, phone number, and organization of the administrative head of the organization. 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. The online mailbox and NIC-Ident of this person should also be included. For example: Administrator Organization USC/Information Sciences Institute Name Keith Uncapher Title Executive Director Mail Address USC/ISI 4676 Admiralty Way, Suite 1001 Marina del Rey, CA. 90292-6695 Phone Number 213-822-1511 Net Mailbox [email protected] NIC-Ident KU 3) The name, title, mailing address, phone number, and organization of the domain technical contact. The online mailbox and NIC-Ident of the domain technical contact should also be included. This is the contact point for problems with the domain and for updating information about the domain. Also, the domain technical contact may be responsible for hosts in this domain. Postel & Reynolds [Page 11]
RFC 920 October 1984 Domain Requirements For example: Technical Contact Organization USC/Information Sciences Institute Name Craig Milo Rogers Title Researcher Mail Address USC/ISI 4676 Admiralty Way, Suite 1001 Marina del Rey, CA. 90292-6695 Phone Number 213-822-1511 Net Mailbox [email protected] NIC-Ident CMR 4) The name, title, mailing address, phone number, and organization of the zone technical contact. The online mailbox and NIC-Ident of the zone technical contact should also be included. This is the contact point for problems with the zone and for updating information about the zone. In many cases the zone technical contact and the domain technical contact will be the same person. For example: Technical Contact Organization USC/Information Sciences Institute Name Craig Milo Rogers Title Researcher Mail Address USC/ISI 4676 Admiralty Way, Suite 1001 Marina del Rey, CA. 90292-6695 Phone Number 213-822-1511 Net Mailbox [email protected] NIC-Ident CMR 5) The name of the domain (up to 12 characters). This is the name that will be used in tables and lists associating the domain and the domain server addresses. [While technically domain names can be quite long (programmers beware), shorter names are easier for people to cope with.] For example: ALPHA-BETA 6) A description of the servers that provides the domain service for translating name to address for hosts in this domain, and the date they will be operational. Postel & Reynolds [Page 12]
RFC 920 October 1984 Domain Requirements 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 server operated by the NIC, and will be installed and made operational on 1-November-84. 7) A description of the server machines, including: (a) hardware and software (using keywords from the Assigned Numbers) (b) addresses (what host on what net for each connected net) For example: (a) hardware and software VAX-11/750 and UNIX, or IBM-PC and MS-DOS, or DEC-1090 and TOPS-20 (b) address 10.9.0.193 on ARPANET 8) An estimate of the number of hosts that will be in the domain. (a) initially, (b) within one year, (c) two years, and (d) five years. For example: (a) initially = 50 (b) one year = 100 (c) two years = 200 (d) five years = 500 Postel & Reynolds [Page 13]
RFC 920 October 1984 Domain Requirements Acknowledgment We would like to thank the many people who contributed to this memo, including the participants in the Namedroppers Group, the ICCB, the PCCB, and especially the staff of the Network Information Center, particularly J. Feinler and K. Harrenstien. References [1] Postel, J., "The Domain Names Plan and Schedule", RFC-881, USC Information Sciences Institute, November 1983. [2] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC-882, USC Information Sciences Institute, November 1983. [3] Mockapetris, P., "Domain Names - Implementation and Specification", RFC-883, USC Information Sciences Institute, November 1983. [4] Postel, J., "Domain Name System Implementation Schedule", RFC-897, USC Information Sciences Institute, February 1984. [5] ISO, "Codes for the Representation of Names of Countries", ISO-3166, International Standards Organization, May 1981. [6] Postel, J., "Domain Name System Implementation Schedule - Revised", RFC-921, USC Information Sciences Institute, October 1984. [7] 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 1984. [8] 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. Postel & Reynolds [Page 14]
Network Working Group J. Postel Request for Comments: 920 J. Reynolds ISI October 1984 Domain Requirements Status of this Memo This memo is a policy statement on the requirements of establishing a new domain in the ARPA-Internet and the DARPA research community. This is an official policy statement of the IAB and the DARPA. Distribution of this memo is unlimited. Introduction This memo restates and refines the requirements on establishing a Domain first described in RFC-881 [1]. It adds considerable detail to that discussion, and introduces the limited set of top level domains. The Purpose of Domains Domains are administrative entities. The purpose and expected use of domains is to divide the name management required of a central administration and assign it to sub-administrations. There are no geographical, topological, or technological constraints on a domain. The hosts in a domain need not have common hardware or software, nor even common protocols. Most of the requirements and limitations on domains are designed to ensure responsible administration. The domain system is a tree-structured global name space that has a few top level domains. The top level domains are subdivided into second level domains. The second level domains may be subdivided into third level domains, and so on. The administration of a domain requires controlling the assignment of names within that domain and providing access to the names and name related information (such as addresses) to users both inside and outside the domain. Postel & Reynolds [Page 1]
RFC 920 October 1984 Domain Requirements General Purpose Domains While the initial domain name "ARPA" arises from the history of the development of this system and environment, in the future most of the top level names will be very general categories like "government", "education", or "commercial". The motivation is to provide an organization name that is free of undesirable semantics. After a short period of initial experimentation, all current ARPA-Internet hosts will select some domain other than ARPA for their future use. The use of ARPA as a top level domain will eventually cease. Initial Set of Top Level Domains The initial top level domain names are: Temporary ARPA = The current ARPA-Internet hosts. Categories GOV = Government, any government related domains meeting the second level requirements. EDU = Education, any education related domains meeting the second level requirements. COM = Commercial, any commercial related domains meeting the second level requirements. MIL = Military, any military related domains meeting the second level requirements. ORG = Organization, any other domains meeting the second level requirements. Countries The English two letter code (alpha-2) identifying a country according the the ISO Standard for "Codes for the Representation of Names of Countries" [5]. Postel & Reynolds [Page 2]
RFC 920 October 1984 Domain Requirements Multiorganizations A multiorganization may be a top level domain if it is large, and is composed of other organizations; particularly if the multiorganization can not be easily classified into one of the categories and is international in scope. Possible Examples of Domains The following examples are fictions of the authors' creation, any similarity to the real world is coincidental. The UC Domain It might be that a large state wide university with, say, nine campuses and several laboratories may want to form a domain. Each campus or major off-campus laboratory might then be a subdomain, and within each subdomain, each department could be further distinguished. This university might be a second level domain in the education category. One might see domain style names for hosts in this domain like these: LOCUS.CS.LA.UC.EDU CCN.OAC.LA.UC.EDU ERNIE.CS.CAL.UC.EDU A.S1.LLNL.UC.EDU A.LAND.LANL.UC.EDU NMM.LBL.CAL.UC.EDU The MIT Domain Another large university may have many hosts using a variety of machine types, some even using several families of protocols. However, the administrators at this university may see no need for the outside world to be aware of these internal differences. This university might be a second level domain in the education category. One might see domain style names for hosts in this domain like these: APIARY-1.MIT.EDU BABY-BLUE.MIT.EDU CEZANNE.MIT.EDU DASH.MIT.EDU Postel & Reynolds [Page 3]
RFC 920 October 1984 Domain Requirements MULTICS.MIT.EDU TAC.MIT.EDU XX.MIT.EDU The CSNET Domain There may be a consortium of universities and industry research laboratories called, say, "CSNET". This CSNET is not a network per se, but rather a computer mail exchange using a variety of protocols and network systems. Therefore, CSNET is not a network in the sense of the ARPANET, or an Ethernet, or even the ARPA-Internet, but rather a community. Yet it does, in fact, have the key property needed to form a domain; it has a responsible administration. This consortium might be large enough and might have membership that cuts across the categories in such a way that it qualifies under the "multiorganization rule" to be a top level domain. One might see domain style names for hosts in this domain like these: CIC.CSNET EMORY.CSNET GATECH.CSNET HP-LABS.CSNET SJ.IBM.CSNET UDEL.CSNET UWISC.CSNET General 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 an authoritative coordinator for domain related questions. There must be a robust domain name lookup service, it must be of at least a minimum size, and the domain must be registered with the central domain administrator (the Network Information Center (NIC) Domain Registrar). Responsible Person: An individual must be identified who has authority for the administration of the names within the domain, and who seriously takes on the responsibility for the behavior of the hosts in the domain, plus their interactions with hosts outside the domain. This person must have some technical expertise and the authority within the domain to see that problems are fixed. Postel & Reynolds [Page 4]
RFC 920 October 1984 Domain Requirements If a host in a given domain somehow misbehaves in its interactions with hosts outside the domain (e.g., consistently violates protocols), the responsible person for the domain must be competent and available to receive reports of problems, take action on the reported problems, and follow through to eliminate the problems. Domain Servers: A robust and reliable domain server must be provided. One way of meeting this requirement is to provide at least two independent domain servers for the domain. The database 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. They should have no common point of failure. Some domains may find that providing a robust domain service can most easily be done by cooperating with another domain where each domain provides an additional server for the other. In other situations, it may be desirable for a domain to arrange for domain service to be provided by a third party, perhaps on hosts located outside the domain. One of the difficult problems in operating a domain server is the acquisition and maintenance of the data. In this case, the data are 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 database is easily managed. In the technical language of the domain server implementation the data is divided into zones. Domains and zones are not necessarily one-to-one. It may be reasonable for two or more domains to combine their data in a single zone. The responsible person or an identified technical assistant must understand in detail the procedures for operating a domain server, including the management of master files and zones. The operation of a domain server should not be taken on lightly. There are some difficult problems in providing an adequate service, primarily the problems in keeping the database up to date, and keeping the service operating. Postel & Reynolds [Page 5]
RFC 920 October 1984 Domain Requirements The concepts and implementation details of the domain server are given in RFC-882 [2] and RFC-883 [3]. Minimum Size: The domain must be of at least a minimum size. There is no requirement to form a domain because some set of hosts is above the minimum size. Top level domains must be specially authorized. In general, they will only be authorized for domains expected to have over 500 hosts. The general guideline for a second level domain is that it have over 50 hosts. This is a very soft "requirement". It makes sense that any major organization, such as a university or corporation, be allowed as a second level domain -- even if it has just a few hosts. Registration: Top level domains must be specially authorized and registered with the NIC domain registrar. The administrator of a level N domain must register with the registrar (or responsible person) of the level N-1 domain. This upper level authority must be satisfied that the requirements are met before authorization for the domain is granted. The registration procedure involves answering specific questions about the prospective domain. A prototype of what the NIC Domain Registrar may ask for the registration of a second level domain is shown below. These questions may change from time to time. It is the responsibility of domain administrators to keep this information current. 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 within 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. Even if sub-domains are established, the responsible person for the top-level domain is ultimately responsible for the whole tree of sub-domains and hosts. This does not mean that a domain administrator has to know the Postel & Reynolds [Page 6]
RFC 920 October 1984 Domain Requirements details of all the sub-domains and hosts to the Nth degree, but simply that if a problem occurs he can get it fixed by calling on the administrator of the sub-domain containing the problem. Top Level Domain Requirements There are very few top level domains, each of these may have many second level domains. An initial set of top level names has been identified. Each of these has an administrator and an agent. The top level domains: ARPA = The ARPA-Internet *** TEMPORARY *** Administrator: DARPA Agent: The Network Information Center Mailbox: [email protected] GOV = Government Administrator: DARPA Agent: The Network Information Center Mailbox: [email protected] EDU = Education Administrator: DARPA Agent: The Network Information Center Mailbox: [email protected] COM = Commercial Administrator: DARPA Agent: The Network Information Center Mailbox: [email protected] MIL = Military Administrator: DDN-PMO Agent: The Network Information Center Mailbox: [email protected] Postel & Reynolds [Page 7]
RFC 920 October 1984 Domain Requirements ORG = Organization Administrator: DARPA Agent: The Network Information Center Mailbox: [email protected] Countries The English two letter code (alpha-2) identifying a country according the the ISO Standard for "Codes for the Representation of Names of Countries" [5]. As yet no country domains have been established. As they are established information about the administrators and agents will be made public, and will be listed in subsequent editions of this memo. Multiorganizations A multiorganization may be a top level domain if it is large, and is composed of other organizations; particularly if the multiorganization can not be easily classified into one of the categories and is international in scope. As yet no multiorganization domains have been established. As they are established information about the administrators and agents will be made public, and will be listed in subsequent editions of this memo. Note: The NIC is listed as the agent and registrar for all the currently allowed top level domains. If there are other entities that would be more appropriate agents and registrars for some or all of these domains then it would be desirable to reassign the responsibility. Second Level Domain Requirements Each top level domain may have many second level domains. Every second level domain must meet the general requirements on a domain specified above, and be registered with a top level domain administrator. Postel & Reynolds [Page 8]
RFC 920 October 1984 Domain Requirements Third through Nth Level Domain Requirements Each second level domain may have many third level domains, etc. Every third level domain (through Nth level domain) must meet the requirements set by the administrator of the immediately higher level domain. Note that these may be more or less strict than the general requirements. One would expect the minimum size requirements to decrease at each level. The ARPA Domain At the time the implementation of the domain concept was begun it was thought that the set of hosts under the administrative authority of DARPA would make up a domain. Thus the initial domain selected was called ARPA. Now it is seen that there is no strong motivation for there to be a top level ARPA domain. The plan is for the current ARPA domain to go out of business as soon as possible. Hosts that are currently members of the ARPA domain should make arrangements to join another domain. It is likely that for experimental purposes there will be a second level domain called ARPA in the ORG domain (i.e., there will probably be an ARPA.ORG domain). The DDN Hosts DDN hosts that do not desire to participate in this domain naming system will continue to use the HOSTS.TXT data file maintained by the NIC for name to address translations. This file will be kept up to date for the DDN hosts. However, all DDN hosts will change their names from "host.ARPA" to (for example) "host.DDN.MIL" some time in the future. The schedule for changes required in DDN hosts will be established by the DDN-PMO. Impact on Hosts What is a host administrator to do about all this? For existing hosts already operating in the ARPA-Internet, the best advice is to sit tight for now. Take a few months to consider the options, then select a domain to join. Plan carefully for the impact that changing your host name will have on both your local users and on their remote correspondents. For a new host, careful thought should be given (as discussed below). Some guidance can be obtained by comparing notes on what other hosts with similar administrative properties have done. The owner of a host may decide which domain to join, and the Postel & Reynolds [Page 9]
RFC 920 October 1984 Domain Requirements administrator of a domain may decide which hosts to accept into his domain. Thus the owner of a host and a domain administrator must come to an understanding about the host being in the domain. This is the foundation of responsible administration. For example, a host "XYZ" at MIT might possible be considered as a candidate for becoming any of XYZ.ARPA.ORG, XYZ.CSNET, or XYZ.MIT.EDU. The owner of host XYZ may choose which domain to join, depending on which domain administrators are willing to have him. The domain is part of the host name. Thus if USC-ISIA.ARPA changes its domain affiliation to DDN.MIL to become USC-ISIA.DDN.MIL, it has changed its name. This means that any previous references to USC-ISIA.ARPA are now out of date. Such old references may include private host name to address tables, and any recorded information about mailboxes such as mailing lists, the headers of old messages, printed directories, and peoples' memories. The experience of the DARPA community suggests that changing the name of a host is somewhat painful. It is recommended that careful thought be given to choosing a new name for a host - which includes selecting its place in the domain hierarchy. The Roles of the Network Information Center The NIC plays two types of roles in the administration of domains. First, the NIC is the registrar of all top level domains. Second the NIC is the administrator of several top level domains (and the registrar for second level domains in these). Top Level Domain Registrar As the registrar for top level domains, the NIC is the contact point for investigating the possibility of establishing a new top level domain. Top Level Domain Administrator For the top level domains designated so far, the NIC is the administrator of each of these domains. This means the NIC is responsible for the management of these domains and the registration of the second level domains or hosts (if at the second level) in these domains. Postel & Reynolds [Page 10]
RFC 920 October 1984 Domain Requirements It may be reasonable for the administration of some of these domains to be taken on by other authorities in the future. It is certainly not desired that the NIC be the administrator of all top level domains forever. Prototypical Questions To establish a domain, the following information must be provided to the NIC Domain Registrar ([email protected]): Note: The key people must have computer mail mailboxes and NIC-Idents. If they do not at present, please remedy the situation at once. A NIC-Ident may be established by contacting [email protected]. 1) The name of the top level domain to join. For example: EDU 2) The name, title, mailing address, phone number, and organization of the administrative head of the organization. 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. The online mailbox and NIC-Ident of this person should also be included. For example: Administrator Organization USC/Information Sciences Institute Name Keith Uncapher Title Executive Director Mail Address USC/ISI 4676 Admiralty Way, Suite 1001 Marina del Rey, CA. 90292-6695 Phone Number 213-822-1511 Net Mailbox [email protected] NIC-Ident KU 3) The name, title, mailing address, phone number, and organization of the domain technical contact. The online mailbox and NIC-Ident of the domain technical contact should also be included. This is the contact point for problems with the domain and for updating information about the domain. Also, the domain technical contact may be responsible for hosts in this domain. Postel & Reynolds [Page 11]
RFC 920 October 1984 Domain Requirements For example: Technical Contact Organization USC/Information Sciences Institute Name Craig Milo Rogers Title Researcher Mail Address USC/ISI 4676 Admiralty Way, Suite 1001 Marina del Rey, CA. 90292-6695 Phone Number 213-822-1511 Net Mailbox [email protected] NIC-Ident CMR 4) The name, title, mailing address, phone number, and organization of the zone technical contact. The online mailbox and NIC-Ident of the zone technical contact should also be included. This is the contact point for problems with the zone and for updating information about the zone. In many cases the zone technical contact and the domain technical contact will be the same person. For example: Technical Contact Organization USC/Information Sciences Institute Name Craig Milo Rogers Title Researcher Mail Address USC/ISI 4676 Admiralty Way, Suite 1001 Marina del Rey, CA. 90292-6695 Phone Number 213-822-1511 Net Mailbox [email protected] NIC-Ident CMR 5) The name of the domain (up to 12 characters). This is the name that will be used in tables and lists associating the domain and the domain server addresses. [While technically domain names can be quite long (programmers beware), shorter names are easier for people to cope with.] For example: ALPHA-BETA 6) A description of the servers that provides the domain service for translating name to address for hosts in this domain, and the date they will be operational. Postel & Reynolds [Page 12]
RFC 920 October 1984 Domain Requirements 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 server operated by the NIC, and will be installed and made operational on 1-November-84. 7) A description of the server machines, including: (a) hardware and software (using keywords from the Assigned Numbers) (b) addresses (what host on what net for each connected net) For example: (a) hardware and software VAX-11/750 and UNIX, or IBM-PC and MS-DOS, or DEC-1090 and TOPS-20 (b) address 10.9.0.193 on ARPANET 8) An estimate of the number of hosts that will be in the domain. (a) initially, (b) within one year, (c) two years, and (d) five years. For example: (a) initially = 50 (b) one year = 100 (c) two years = 200 (d) five years = 500 Postel & Reynolds [Page 13]
RFC 920 October 1984 Domain Requirements Acknowledgment We would like to thank the many people who contributed to this memo, including the participants in the Namedroppers Group, the ICCB, the PCCB, and especially the staff of the Network Information Center, particularly J. Feinler and K. Harrenstien. References [1] Postel, J., "The Domain Names Plan and Schedule", RFC-881, USC Information Sciences Institute, November 1983. [2] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC-882, USC Information Sciences Institute, November 1983. [3] Mockapetris, P., "Domain Names - Implementation and Specification", RFC-883, USC Information Sciences Institute, November 1983. [4] Postel, J., "Domain Name System Implementation Schedule", RFC-897, USC Information Sciences Institute, February 1984. [5] ISO, "Codes for the Representation of Names of Countries", ISO-3166, International Standards Organization, May 1981. [6] Postel, J., "Domain Name System Implementation Schedule - Revised", RFC-921, USC Information Sciences Institute, October 1984. [7] 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 1984. [8] 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. Postel & Reynolds [Page 14]
RFC 882 - DOMAIN NAMES
[Docs] [txt|pdf]
Obsoleted by: 1034, 1035
Updated by: 973
Network Working Group P. Mockapetris Request for Comments: 882 ISI November 1983 DOMAIN NAMES - CONCEPTS and FACILITIES +-----------------------------------------------------+ | | | This RFC introduces domain style names, their use | | for ARPA Internet mail and host address support, | | and the protocols and servers used to implement | | domain name facilities. | | | | This memo describes the conceptual framework of the | | domain system and some uses, but it omits many | | uses, fields, and implementation details. A | | complete specification of formats, timeouts, etc. | | is presented in RFC 883, "Domain Names - | | Implementation and Specification". That RFC | | assumes that the reader is familiar with the | | concepts discussed in this memo. | | | +-----------------------------------------------------+ INTRODUCTION The need for domain names As applications grow to span multiple hosts, then networks, and finally internets, these applications must also span multiple administrative boundaries and related methods of operation (protocols, data formats, etc). The number of resources (for example mailboxes), the number of locations for resources, and the diversity of such an environment cause formidable problems when we wish to create consistent methods for referencing particular resources that are similar but scattered throughout the environment. The ARPA Internet illustrates the size-related problems; it is a large system and is likely to grow much larger. The need to have a mapping between host names (e.g., USC-ISIF) and ARPA Internet addresses (e.g., 10.2.0.52) is beginning to stress the existing mechanisms. Currently hosts in the ARPA Internet are registered with the Network Information Center (NIC) and listed in a global table (available as the file <NETINFO>HOSTS.TXT on the SRI-NIC host) [1]. The size of this table, and especially the frequency of updates to the table are near the limit of manageability. What is needed is a distributed database that performs the same function, and hence avoids the problems caused by a centralized database. The problem for computer mail is more severe. While mail system implementers long ago recognized the impossibility of centralizing Mockapetris [Page 1]
RFC 882 November 1983 Domain Names - Concepts and Facilities mailbox names, they have also created an increasingly large and irregular set of methods for identifying the location of a mailbox. Some of these methods involve the use of routes and forwarding hosts as part of the mail destination address, and consequently force the mail user to know multiple address formats, the capabilities of various forwarders, and ad hoc tricks for passing address specifications through intermediaries. These problems have common characteristics that suggest the nature of any solution: The basic need is for 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 contain 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 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. 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. Because we want the name space to be useful in dissimilar networks, it is unlikely that all users of domain names will be able to agree on the set of resources or resource information that names will be used to retrieve. Hence names refer to a set of resources, and queries contain resource identifiers. The only standard types of information that we expect to see throughout the name space is structuring information for the name space itself, and resources that are described using domain names and no nonstandard data. We also want the name server transactions to be independent of the communications system that carries them. Some systems may wish to use datagrams for simple 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. Mockapetris [Page 2]
RFC 882 November 1983 Domain Names - Concepts and Facilities Elements of the solution The proposed solution has three major components: The DOMAIN NAME SPACE, which is a specification for a tree structured name space. 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 ARPA Internet uses some of its domain names to identify hosts; queries for address resources return ARPA Internet host addresses. However, to preserve the generality of the domain mechanism, domain names are not required to have a one-to-one correspondence with host names, host addresses, or any other type of information. 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; these parts are called ZONEs; a name server is an AUTHORITY for these parts of the name space. RESOLVERS are programs that extract information from name servers in response to user 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 simple procedure or OS calls to resolvers. 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 server has one or more pieces of the whole domain tree's data, Mockapetris [Page 3]
RFC 882 November 1983 Domain Names - Concepts and Facilities 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 using the local zones. In the interests of performance, these layers blur a bit. For example, resolvers on the same machine as a name server may share a database and may also introduce foreign information for use in later queries. This cached information is treated differently from the authoritative data in zones. Database model 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 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 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 Mockapetris [Page 4]
RFC 882 November 1983 Domain Names - Concepts and Facilities updates or guarantees of consistency. Hence the update process allows updates to percolate out though 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. Some users will wish to access the database via datagrams; others will prefer virtual circuits. The domain system is designed so that simple queries and responses can use either style, although refreshing operations need the reliability of virtual circuits. The same overall message format is used for all communication. The domain system does not assume any special properties of the communications system, and hence could be used with any datagram or virtual circuit protocol. 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. The optional recursive style is discussed in [14], and omitted from further discussion in this memo. 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 to users of the domain system. A standard format for these files is given in [14]. The standard format allows these files 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. Mockapetris [Page 5]
RFC 882 November 1983 Domain Names - Concepts and Facilities Each host's name servers and resolvers are configured by a local system administrator. 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 DOMAIN NAME SPACE 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). Each node and leaf has an associated label. Labels are NOT guaranteed to be unique, with the exception of the root node, which has a null label. The domain name of a node or leaf is the path from the root of the tree to the node or leaf. By convention, the labels that compose a domain name are read left to right, from the most specific (lowest) to the least specific (highest). Internally, programs that manipulate domain names 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 Mockapetris [Page 6]
RFC 882 November 1983 Domain Names - Concepts and Facilities representations can use a length byte of zero to terminate a domain name. When domain names are printed, labels in a path are separated by dots ("."). The root label and its associated dot are omitted from printed domain names, but the root can be named by a null domain name (" " in this memo). To simplify implementations, the total number of octets that represent label octets and label lengths is limited to 255. Thus a printed domain name can be up to 254 characters. A special label is defined that matches any other label. This label is the asterisk or "*". An asterisk matches a single label. Thus *.ARPA matches FOO.ARPA, but does not match FOO.BAR.ARPA. The asterisk is mainly used to create default resource records at the boundary between protocol families, and requires prudence in its use. 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 has the containing domain's name as the right part of its name. For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ". This tree structure is intended to parallel the administrative organization and delegation of authority. Potentially, each node or leaf on the tree can create new subdomains ad infinitum. In practice, this delegation can be limited by the administrator of the name servers that manage the domain space and resource data. The following figure shows an example of a domain name space. | +------------------+------------------+ | | | COLORS FLAVORS TRUTH | | +-----+-----+ | | | | NATURAL RED BLUE GREEN | | +---------------+---------------+ | | | CHOCOLATE VANILLA STRAWBERRY In this example, the root domain has three immediate subdomains: COLORS, FLAVORS, and TRUTH. The FLAVORS domain has one immediate subdomain named NATURAL.FLAVORS. All of the leaves are also Mockapetris [Page 7]
RFC 882 November 1983 Domain Names - Concepts and Facilities domains. This domain tree has the names " "(the root), COLORS, RED.COLORS, BLUE.COLORS, GREEN.COLORS, FLAVORS, NATURAL.FLAVORS, CHOCOLATE.NATURAL.FLAVORS, VANILLA.NATURAL.FLAVORS, STRAWBERRY.NATURAL.FLAVORS, and TRUTH. If we wished to add a new domain of ARTIFICIAL under FLAVORS, FLAVORS would typically be the administrative entity that would decide; if we wished to create CHIP and MOCHA names under CHOCOLATE, CHOCOLATE.NATURAL.FLAVORS would typically be the appropriate administrative entity. Resource set information A domain name identifies a set of resource information. The set of resource information associated with a particular name is composed of separate resource records (RRs). Each resource record has the following major components: The domain name which identifies resource set that holds this record, and hence the "owner" of the information. For example, a RR that specifies a host address has a domain name the specifies the host having that address. Thus F.ISI.ARPA might be the owner of a RR which specified an address field of 10.2.0.52. Since name servers typically store their resource information in tree structures paralleling the organization of the domain space, this information can usually be stored implicitly in the database; however it is always included in each resource record carried in a message. Other information used to manage the RR, such as length fields, timeouts, etc. This information is omitted in much of this memo, but is discussed in [14]. A resource type field that specifies the type of the resource in this resource record. Types refer to abstract resources such as host addresses or mail delivery agents. The type field is two octets long and uses an encoding that is standard throughout the domain name system. A class field identifies the format of the resource data, such as the ARPA Internet format (IN) or the Computer Science Network format (CSNET), for certain RR types (such as address data). Note that while the class may separate different protocol families, networks, etc. it does not do so in all cases. For example, the IN class uses 32 bit IP addresses exclusively, but the CSNET class uses 32 bit IP addresses, X.25 addresses, and phone numbers. Thus the class field should be used as a guide for interpreting the resource data. The class field is two octets long and uses an encoding that is standard throughout the domain name system. Mockapetris [Page 8]
RFC 882 November 1983 Domain Names - Concepts and Facilities Resource data that describes the resource. The format of this data can be determined given the type and class fields, but always starts with a two octet length field that allows a name server or resolver to determine the boundaries of the resource data in any transaction, even if it cannot "understand" the resource data itself. Thus name servers and resolvers can hold and pass on records which they cannot interpret. The format of the internal data is restricted only by the maximum length of 65535 octets; for example the host address record might specify a fixed 32 bit number for one class, and a variable length list of addresses in another class. While the class field in effect partitions the resource data in the domain name system into separate parallel sections according to class, services can span class boundaries if they use compatible resource data formats. For example, the domain name system uses compatible formats for structure information, and the mail data decouples mail agent identification from details of how to contact the agent (e.g. host addresses). This memo uses the following types in its examples: A - the host address associated with the domain name MF - identifies a mail forwarder for the domain MD - identifies a mail destination for the domain NS - the authoritative name server for the domain SOA - identifies the start of a zone of authority CNAME - identifies the canonical name of an alias This memo uses the following classes in its examples: IN - the ARPA Internet system CS - the CSNET system The first type of resource record holds a host name to host address binding. Its fields are: +--------+--------+--------+--------------//----------------------+ |<owner> | A | <class>| <class specific address>information | +--------+--------+--------+--------------//----------------------+ Mockapetris [Page 9]
RFC 882 November 1983 Domain Names - Concepts and Facilities The content of the class specific information varies according to the value in the CLASS field; for the ARPA Internet, it is the 32 bit ARPA Internet address of the host, for the CSNET it might be the phone number of the host. For example, F.ISI.ARPA might have two A records of the form: +----------+--------+--------+----------------------------+ |F.ISI.ARPA| A | IN | 10.2.0.52 | +----------+--------+--------+----------------------------+ and +----------+--------+--------+----------------------------+ |F.ISI.ARPA| A | CS | 213-822-2112 | +----------+--------+--------+----------------------------+ Note that the data formats for the A type are class dependent, and the Internet address and phone number formats shown above are for purposes of illustration only. The actual data formats are specified in [14]. For example, CS class data for type A records might actually be a list of Internet addresses, phone numbers and TELENET addresses. The mail forwarder (MF) and mail delivery (MD) records have the following format: +--------+--------+--------+----------------------------+ |<owner> | MD/MF | <class>| <domain name> | +--------+--------+--------+----------------------------+ The <domain name> field is a domain name of the host that will handle mail; note that this domain name may be completely different from the domain name which names the resource record. For example, F.ISI.ARPA might have two records of the form: +----------+--------+--------+----------------------------+ |F.ISI.ARPA| MD | IN | F.ISI.ARPA | +----------+--------+--------+----------------------------+ and +----------+--------+--------+----------------------------+ |F.ISI.ARPA| MF | IN | B.ISI.ARPA | +----------+--------+--------+----------------------------+ These records mean that mail for F.ISI.ARPA can either be delivered to the host F.ISI.ARPA or forwarded to B.ISI.ARPA, which will accept responsibility for its eventual delivery. In principle, an additional name lookup is required to map the domain name of the host to the appropriate address, in practice this information is usually returned in the response to the mail query. The SOA and NS types of resource records are used to define limits Mockapetris [Page 10]
RFC 882 November 1983 Domain Names - Concepts and Facilities of authority. The domain name given by the owner field of a SOA record is the start of a zone; the domain name given by the owner field of a NS record identifies a point in the name space where authority has been delegated, and hence marks the zone boundary. Except in the case where a name server delegates authority to itself, the SOA identifies the top limit of authority, and NS records define the first name outside of a zone. These resource records have a standard format for all of the name space: +----------+--------+--------+-----------------------------+ | <owner> | SOA | <class>| <domain name, etc> | +----------+--------+--------+-----------------------------+ +----------+--------+--------+-----------------------------+ | <owner> | NS | <class>| <domain name> | +----------+--------+--------+-----------------------------+ The SOA record marks the start of a zone when it is present in a database; the NS record both marks the end of a zone started by an SOA (if a higher SOA is present) and also points to a name server that has a copy of the zone specified by the <owner. field of the NS record. The <domain name, etc> in the SOA record specifies the original source of the information in the zone and other information used by name servers to organize their activities. SOA records are never cached (otherwise they would create false zones); they can only be created in special name server maintenance operations. The NS record says that a name server which is authoritative for records of the given CLASS can be found at <domain name>. Queries Queries to a name server must include a domain name which identifies the target resource set (QNAME), and the type and class of desired resource records. The type and class fields in a query can include any of the corresponding type and class fields that are defined for resource records; in addition, the query type (QTYPE) and query class (QCLASS) fields may contain special values that match more than one of the corresponding fields in RRs. For example, the QTYPE field may contain: MAILA - matches all mail agent RRs (e.g. MD and MF). * - matches any RR type. Mockapetris [Page 11]
RFC 882 November 1983 Domain Names - Concepts and Facilities The QCLASS field may contain: * - matches any RR class. Using the query domain name, QTYPE, and QCLASS, the name server looks for matching RRs. In addition to relevant records, the name server may return RRs that point toward a name server that has the desired information or RRs that are expected to be useful in interpreting the relevant RRs. For example a name server that doesn't have the requested information may know a name server that does; a name server that returns a domain name in a relevant RR may also return the RR that binds that domain name to an address. Note that the QCLASS=* construct requires special interpretation regarding authority. Since a name server may not know all of the classes available in the domain system, it can never know if it is authoritative for all classes. Hence responses to QCLASS=* queries can never be authoritative. Example space For purposes of exposition, the following name space is used for the remainder of this memo: | +------------------+------------------+ | | | DDN ARPA CSNET | | | +-----+-----+ | +-----+-----+ | | | | | | JCS ARMY NAVY | UDEL UCI | +--------+---------------+---------------+--------+ | | | | | DTI MIT ISI UDEL NBS | | +---+---+ +---+---+ | | | | | DMS AI A B F Mockapetris [Page 12]
RFC 882 November 1983 Domain Names - Concepts and Facilities NAME SERVERS Introduction Name servers store a distributed database consisting of the structure of the domain name space, the resource sets associated with domain names, and other information used to coordinate actions between name servers. In general, a name server will be an authority for all or part of a particular domain. The region covered by this authority is called a zone. Name servers may be responsible for no authoritative data, and hence have no zones, or may have several zones. When a name server has multiple zones, the zones may have no common borders or zones may be contiguous. While administrators should not construct overlapping zones, and name servers must defend against overlapping zones, overlapping is regarded as a non-fatal flaw in the database. Hence the measures taken to protect against it are omitted for the remainder of this memo. A detailed discussion can be found in [14]. When presented with a query for a domain name over which it has authority, a name server returns the desired resource information or an indication that the query refers to a domain name or resource that does not exist. If a name server is presented with a query for a domain name that is not within its authority, it may have the desired information, but it will also return a response that points toward an authoritative name server. If a name server is not an authority for a query, it can never return a negative response. There is no requirement that a name server for a domain reside in a host which has a name in the same domain, although this will usually be the case. There is also no restriction on the number of name servers that can have authority over a particular domain; most domains will have redundant authoritative name servers. The assumption is that different authoritative copies are identical, even though inconsistencies are possible as updates are made. Name server functions are designed to allow for very simple implementations of name servers. The simplest name server has a static set of information and uses datagrams to receive queries and return responses. More sophisticated name server implementations can improve the performance of their clients by caching information from other domains. Although this information can be acquired in a number of ways, the normal method is to store the information acquired by a Mockapetris [Page 13]
RFC 882 November 1983 Domain Names - Concepts and Facilities resolver when the resolver consults other name servers. In a sophisticated host, the resolver and name server will coordinate their actions and use a shared database. This cooperation requires the incorporation of a time-to-live (TTL) field in all cached resource records. Caching is discussed in the resolver section of this memo; this section is devoted to the actions of a name servers that don't cache. In order to free simple name servers of the requirement of managing these timeouts, simple name servers should only contain resource records that are expected to remain constant over very long periods or resource records for which the name server is an authority. In the following discussion, the TTL field is assumed to be stored in the resource record but is omitted in descriptions of databases and responses in the interest of clarity. Authority and administrative control of domains Although we want to have the potential of delegating the privileges of name space management at every node, we don't want such delegation to be required. Hence we introduce the concept of authority. Authority is vested in name servers. A name server has authority over all of its domain until it delegates authority for a subdomain to some other name server. Any administrative entity that wishes to establish its own domain must provide a name server, and have that server accepted by the parent name server (i.e. the name server that has authority over the place in the domain name space that will hold the new domain). While the principles of authority allow acceptance to be at the discretion of parent name servers, the following criteria are used by the root, and are recommended to all name servers because they are responsible for their children's actions: 1. It must register with the parent administrator of domains. 2. It must identify a responsible person. 3. In must provide redundant name servers. The domain name must be registered with the administrator to avoid name conflicts and to make the domain related information available to other domains. The central administrator may have further requirements, and a domain is not registered until the central administrator agrees that all requirements are met. There must be a responsible person associated with each domain to Mockapetris [Page 14]
RFC 882 November 1983 Domain Names - Concepts and Facilities be a contact point for questions about the domain, to verify and update the domain related information, and to resolve any problems (e.g., protocol violations) with hosts in the domain. The domain must provide redundant (i.e., two or more) name servers to provide the name to address resolution service. These name servers must be accessible from outside the domain (as well as inside) and must resolve names for at least all the hosts in the domain. Once the central administrator is satisfied, he will communicate the existence to the appropriate administrators of other domains so that they can incorporate NS records for the new name server into their databases. Name server logic The processing steps that a name server performs in responding to a query are conceptually simple, although implementations may have internal databases that are quite complex. For purposes of explanation, we assume that the query consists of a type QTYPE, a class QCLASS, and a domain name QNAME; we assume that the name server stores its RRs in sets where each set has all of the RRs for a particular domain. Note that this database structure and the following algorithms are meant to illustrate one possible implementation, rather than a specification of how all servers must be implemented. The following notation is used: ord(DOMAIN-NAME) returns the number of labels in DOMAIN-NAME. findset(DOMAIN-NAME) returns a pointer to the set of stored RRs for DOMAIN-NAME, or NULL if there is no such information. set(POINTER) refers to a set located previously by findset, where POINTER is the value returned by findset. relevant(QTYPE,TYPE) returns true if a RR of the specified TYPE is relevant to the specified QTYPE. For example, relevant(MAILA,MF) is true and relevant(MAILA,NS) is false. right(NAME,NUMBER) returns a domain name that is the rightmost NUMBER labels in the string NAME. Mockapetris [Page 15]
RFC 882 November 1983 Domain Names - Concepts and Facilities copy(RR) copies the resource record specified by RR into the response. The name server code could be represented as the following sequence of steps: { find out whether the database makes this server authoritative for the domain name specified by QNAME } for i:=0 to ord(QNAME) { sequence through all nodes in QNAME } do begin ptr:=findset(right(QNAME,i)); if ptr<>NULL then { there is domain data for this domain name } begin for all RRs in set(ptr) do if type(RR)=NS and class(RR)=QCLASS then begin auth=false; NSptr:=ptr end; for all RRs in set(ptr) do if type(RR)=SOA and class(RR)=QCLASS then auth:=true end end; end; { copy out authority search results } if auth then { if authority check for domain found } if ptr=null then return(Name error) else else { if not authority, copy NS RRs } for all RRs in set(nsptr) do if (type(RR)=NS and class(RR)=QCLASS) or (QCLASS=*) then copy(RR); { Copy all RRs that answer the question } for all RRs in set(ptr) do if class(RR)=QCLASS and relevant(QTYPE,type(RR)) then copy(RR); The first section of the code (delimited by the for loop over all Mockapetris [Page 16]
RFC 882 November 1983 Domain Names - Concepts and Facilities of the subnodes of QNAME) discovers whether the name server is authoritative for the domain specified by QNAME. It sequences through all containing domains of QNAME, starting at the root. If it encounters a SOA it knows that the name server is authoritative unless it finds a lower NS RR which delegates authority. If the name server is authoritative, it sets auth=true; if the name server is not authoritative, it sets NSptr to point to the set which contains the NS RR closest to the domain specified by QNAME. The second section of the code reflects the result of the authority search into the response. If the name server is authoritative, the code checks to see that the domain specified by QNAME exists; if not, a name error is returned. If the name server is not authoritative, the code copies the RRs for a closer name server into the response. The last section of the code copies all relevant RRs into the response. Note that this code is not meant as an actual implementation and is incomplete in several aspects. For example, it doesn't deal with providing additional information, wildcards, QCLASS=*, or with overlapping zones. The first two of these issues are dealt with in the following discussions, the remaining issues are discussed in [14]. Additional information When a resolver returns information to a user program, the returned information will often lead to a second query. For example, if a mailer asks a resolver for the appropriate mail agent for a particular domain name, the name server queried by the resolver returns a domain name that identifies the agent. In general, we would expect that the mailer would then request the domain name to address binding for the mail agent, and a new name server query would result. To avoid this duplication of effort, name servers return additional information with a response which satisfies the anticipated query. This information is kept in a separate section of the response. Name servers are required to complete the appropriate additional information if such information is available, but the requestor should not depend on the presence of the information since the name server may not have it. If the resolver caches the additional information, it can respond to the second query without an additional network transaction. The appropriate information is defined in [14], but generally Mockapetris [Page 17]
RFC 882 November 1983 Domain Names - Concepts and Facilities consists of host to address bindings for domain names in returned RRs. Aliases and canonical names In existing systems, hosts and other resources often have several names that identify the same resource. For example, under current ARPA Internet naming support, USC-ISIF and ISIF both identify the same host. Similarly, in the case of mailboxes, many organizations provide many names that actually go to the same mailbox; for example Mockapetris@ISIF, Mockapetris@ISIB, etc., all go to the same mailbox (although the mechanism behind this is somewhat complicated). Most of these systems have a notion that one of the equivalent set of names is the canonical name and all others are aliases. The domain system provides a similar feature using the canonical name (CNAME) RR. When a name server fails to find a desired RR in a set associated with some domain name, it checks to see if the resource set contains a CNAME record with a matching class. If so, the name server includes the CNAME record in the response, and continues the query at the domain name specified in the data field of the CNAME record. Suppose a name server was processing a query with QNAME=ISIF.ARPA, QTYPE=A, and QCLASS=IN, and had the following resource records: ISIF.ARPA CNAME IN F.ISI.ARPA F.ISI.ARPA A IN 10.2.0.52 Both of these RRs would be returned in the response. In the above example, because ISIF.ARPA has no RRs other than the CNAME RR, the resources associated with ISIF.ARPA will appear to be exactly those associated with F.ISI.ARPA for the IN CLASS. Since the CNAME is effective only when the search fails, a CNAME can also be used to construct defaults. For example, suppose the name server had the following set of RRs: F.ISI.ARPA A IN 10.2.0.52 F.ISI.ARPA MD IN F.ISI.ARPA XXXX.ARPA CNAME IN F.ISI.ARPA XXXX.ARPA MF IN A.ISI.ARPA Using this database, type A queries for XXXX.ARPA would return the XXXX.ARPA CNAME RR and the F.ISI.ARPA A RR, but MAILA or MF queries to XXXX.ARPA would return the XXXX.ARPA MF RR without any information from F.ISI.ARPA. This structure might be used to send Mockapetris [Page 18]
RFC 882 November 1983 Domain Names - Concepts and Facilities mail addressed to XXXX.ARPA to A.ISI.ARPA and to direct TELNET for XXXX.ARPA to F.ISI.ARPA. Wildcards In certain cases, an administrator may wish to associate default resource information for all or part of a domain. For example, the CSNET domain administrator may wish to establish IN class mail forwarding for all hosts in the CSNET domain without IN capability. In such a case, the domain system provides a special label "*" that matches any other label. Note that "*" matches only a single label, and not zero or more than one label. Note also that the "*" is distinct from the "*" values for QCLASS and QTYPE. The semantics of "*" depend upon whether it appears in a query domain name (QNAME) or in a RR in a database. When an "*" is used in a QNAME, it can only match a "*" in a resource record. When "*" appears in a RR in a database, it can never override an existing exact match. For example, if a name server received a query for the domain UDEL.CSNET, and had appropriate RRs for both UDEL.CSNET and *.CSNET, the UDEL.CSNET RRs would be used and the *.CSNET RRs would be ignored. If a query to the same database specified FOO.CSNET, the *.CSNET RR would be used, but the corresponding labels from the QNAME would replace the "*". Thus the FOO.CSNET query would match the *.CSNET RR and return a RR for FOO.CSNET rather than *.CSNET. RRs containing "*" labels are copied exactly when zones are transfered via name server maintenance operations. These semantics are easily implemented by having the name server first search for an exact match for a query, and then replacing the leftmost label with a "*" and trying again, repeating the process until all labels became "*" or the search succeeded. TYPE=* in RRs is prohibited. If it were to be allowed, the requestor would have no way of interpreting the data in the RR because this data is type dependent. CLASS=* is also prohibited. Similar effects can be achieved using QCLASS=*, and allowing both QCLASS=* and CLASS=* leads to complexities without apparent benefit. Mockapetris [Page 19]
RFC 882 November 1983 Domain Names - Concepts and Facilities A scenario In our sample domain space, suppose we wanted separate administrative control for the root, DDN, ARPA, CSNET, MIT and ISI domains. We might allocate name servers as follows: |(B.ISI.ARPA) |(UDEL.CSNET) +------------------+------------------+ | | | DDN ARPA CSNET |(JCS.DDN) |(F.ISI.ARPA) |(UDEL.ARPA) +-----+-----+ |(A.ISI.ARPA)+-----+-----+ | | | | | | JCS ARMY NAVY | UDEL UCI | +--------+---------------+---------------+--------+ | | | | | DTI MIT ISI UDEL NBS |(AI.MIT.ARPA) |(F.ISI.ARPA) +---+---+ +---+---+ | | | | | DMS AI A B F In this example the authoritative name server is shown in parentheses at the point in the domain tree at which is assumes control. Thus the root name servers are on B.ISI.ARPA and UDEL.CSNET, the DDN name server is on JCS.DDN, the CSNET domain server is on UDEL.ARPA, etc. In an actual system, all domains should have redundant name servers, but in this example only the ARPA domain has redundant servers A.ISI.ARPA and F.ISI.ARPA. (The B.ISI.ARPA and UDEL.CSNET name servers happen to be not redundant because they handle different classes.) The F.ISI.ARPA name server has authority over the ARPA domain, but delegates authority over the MIT.ARPA domain to the name server on AI.MIT.ARPA. The A.ISI.ARPA name server also has authority over the ARPA domain, but delegates both the ISI.ARPA and MIT.ARPA domains to other name servers. Mockapetris [Page 20]
RFC 882 November 1983 Domain Names - Concepts and Facilities B.ISI.ARPA Name server for " " B.ISI.ARPA has the root name server for the IN class. Its database might contain: Domain Resource Record " " SOA IN A.ISI.ARPA DDN NS IN JCS.DDN ARPA NS IN F.ISI.ARPA CSNET NS IN UDEL.ARPA " " NS IN B.ISI.ARPA " " NS CS UDEL.CSNET JCS.DDN A IN 9.0.0.1 F.ISI.ARPA A IN 10.2.0.52 UDEL.CSNET A CS 302-555-0000 UDEL.ARPA A IN 10.0.0.96 The SOA record for the root is necessary so that the name server knows that it is authoritative for the root domain for class IN. The contents of the SOA resource record point back to A.ISI.ARPA and denote that the master data for the zone of authority is originally from this host. The first three NS records denote delegation of authority. The NS root entry for the B.ISI.ARPA name server is necessary so that this name server knows about itself, and can respond correctly to a query for NS information about the root (for which it is an authority). The root entry for class CS denotes that UDEL.CSNET is the authoritative name server for the CS class root. UDEL.CSNET and UDEL.ARPA may or may not refer to the same name server; from this information it is impossible to tell. If this name server was sent a query specifying QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA, it would begin processing (using the previous algorithm) by determining that it was not an authority for F.ISI.ARPA. The test would note that it had authority at " ", but would also note that the authority was delegated at ARPA and never reestablished via another SOA. Thus the response would return the NS record for the domain ARPA. Any queries presented to this server with QCLASS=CS would result in the UDEL.CSNET NS record being returned in the response. Mockapetris [Page 21]
RFC 882 November 1983 Domain Names - Concepts and Facilities F.ISI.ARPA Name server for ARPA and ISI.ARPA In the same domain space, the F.ISI.ARPA database for the domains ARPA and ISI.ARPA might be: Domain Resource Record " " NS IN B.ISI.ARPA " " NS CS CSNET.UDEL ARPA SOA IN B.ISI.ARPA ARPA NS IN A.ISI.ARPA ARPA NS IN F.ISI.ARPA MIT.ARPA NS IN AI.MIT.ARPA ISI.ARPA SOA IN F.ISI.ARPA ISI.ARPA NS IN F.ISI.ARPA A.ISI.ARPA MD IN A.ISI.ARPA ISI.ARPA MD IN F.ISI.ARPA A.ISI.ARPA MF IN F.ISI.ARPA B.ISI.ARPA MD IN B.ISI.ARPA B.ISI.ARPA MF IN F.ISI.ARPA F.ISI.ARPA MD IN F.ISI.ARPA F.ISI.ARPA MF IN A.ISI.ARPA DTI.ARPA MD IN DTI.ARPA NBS.ARPA MD IN NBS.ARPA UDEL.ARPA MD IN UDEL.ARPA A.ISI.ARPA A IN 10.1.0.32 F.ISI.ARPA A IN 10.2.0.52 B.ISI.ARPA A IN 10.3.0.52 DTI.ARPA A IN 10.0.0.12 AI.MIT.ARPA A IN 10.2.0.6 DMS.MIT.ARPA A IN 10.1.0.6 NBS.ARPA A IN 10.0.0.19 UDEL.ARPA A IN 10.0.0.96 For the IN class, the SOA RR for ARPA denotes that this name server is authoritative for the domain ARPA, and that the master file for this authority is stored on B.ISI.ARPA. This zone extends to ISI.ARPA, where the database delegates authority back to this name server in another zone, and doesn't include the domain MIT.ARPA, which is served by a name server on AI.MIT.ARPA. This name server is not authoritative for any data in the CS class. It has a pointer to the root server for CS data which could be use to resolve CS class queries. Suppose this name server received a query of the form QNAME=A.ISI.ARPA, QTYPE=A, and QCLASS=IN. The authority search Mockapetris [Page 22]
RFC 882 November 1983 Domain Names - Concepts and Facilities would notice the NS record for " ", its SOA at ARPA, a delegation at ISI.ARPA, and the reassumption of authority at ISI.ARPA. Hence it would know that it was an authority for this query. It would then find the A record for A.ISI.ARPA, and return a datagram containing this record. Another query might be QNAME=B.ISI.ARPA, QTYPE=MAILA, QCLASS=*. In this case the name server would know that it cannot be authoritative because of the "*" value of QCLASS, and would look for records for domain B.ISI.ARPA that match. Assuming that the name server performs the additional record inclusion mentioned in the name server algorithm, the returned datagram would include: ISI.ARPA NS IN F.ISI.ARPA " " NS CS UDEL.CSNET B.ISI.ARPA MD IN B.ISI.ARPA B.ISI.ARPA MF IN F.ISI.ARPA B.ISI.ARPA A IN 10.3.0.52 F.ISI.ARPA A IN 10.2.0.52 If the query were QNAME=DMS.MIT.ARPA, QTYPE=MAILA, QCLASS=IN, the name server would discover that AI.MIT.ARPA was the authoritative name server and return the following: MIT.ARPA NS IN AI.MIT.ARPA AI.MIT.ARPA A IN 10.2.0.6 In this case, the requestor is directed to seek information from the MIT.ARPA domain name server residing on AI.MIT.ARPA. Mockapetris [Page 23]
RFC 882 November 1983 Domain Names - Concepts and Facilities UDEL.ARPA and UDEL.CSNET name server In the previous discussion of the sample domain, we stated that UDEL.CSNET and UDEL.ARPA might be the same name server. In this example, we assume that this is the case. As such, the name server is an authority for the root for class CS, and an authority for the CSNET domain for class IN. This name server deals with mail forwarding between the ARPA Internet and CSNET systems. Its RRs illustrate one approach to solving this problem. The name server has the following resource records: " " SOA CS UDEL.CSNET " " NS CS UDEL.CSNET " " NS IN B.ISI.ARPA CSNET SOA IN UDEL.ARPA CSNET NS IN UDEL.ARPA ARPA NS IN A.ISI.ARPA *.CSNET MF IN UDEL.ARPA UDEL.CSNET MD CS UDEL.CSNET UCI.CSNET MD CS UCI.CSNET UDEL.ARPA MD IN UDEL.ARPA B.ISI.ARPA A IN 10.3.0.52 UDEL.ARPA A IN 10.0.0.96 UDEL.CSNET A CS 302-555-0000 UCI.CSNET A CS 714-555-0000 Suppose this name server received a query of the form QNAME=UCI.CSNET, QTYPE=MAILA, and QCLASS=IN. The name server would discover it was authoritative for the CSNET domain under class IN, but would find no explicit mail data for UCI.CSNET. However, using the *.CSNET record, it would construct a reply: UCI.CSNET MF IN UDEL.ARPA UDEL.ARPA A IN 10.0.0.96 If this name server received a query of the form QNAME=UCI.CSNET, QTYPE=MAILA, and QCLASS=CS, the name server would return: UCI.CSNET MD CS UCI.CSNET UCI.CSNET A CS 714-555-0000 Note that although this scheme allows for forwarding of all mail addressed as <anything>.CSNET, it doesn't help with names that have more than two components, e.g. A.B.CSNET. Although this problem could be "fixed" by a series of MF entries for *.*.CSNET, Mockapetris [Page 24]
RFC 882 November 1983 Domain Names - Concepts and Facilities *.*.*.CSNET, etc, a more tasteful solution would be to introduce a cleverer pattern matching algorithm in the CSNET name server. Summary of requirements for name servers The requirements for a name server are as follows: 1. It must be recognized by its parent. 2. It must have complete resource information for all domain names for which it is the authority. 3. It must periodically refresh authoritative information from a master file or name server which holds the master. 4. If it caches information it must also handle TTL management for that information. 5. It must answer simple queries. Inverse queries Name servers may also support inverse queries that map a particular resource to a domain name or domain names that have that resource. For example, while a query might map a domain name to a host address, the corresponding inverse query might map the address back to the domain name. Implementation of this service is optional in a name server, but all name servers must at least be able to understand an inverse query message and return an error response. The domain system cannot guarantee the completeness or uniqueness of inverse queries because the domain system is organized by domain name rather than by host address or any other resource type. In general, a resolver or other program that wishes to guarantee that an inverse query will work must use a name server that is known to have the appropriate data, or ask all name servers in a domain of interest. For example, if a resolver wishes to perform an inverse query for an arbitrary host on the ARPA Internet, it must consult a set of name servers sufficient to know that all IN data was considered. In practice, a single inverse query to a name server that has a fairly comprehensive database should satisfy the vast majority of inverse queries. A detailed discussion of inverse queries is contained in [14]. Mockapetris [Page 25]
RFC 882 November 1983 Domain Names - Concepts and Facilities Completion services Some existing systems provide the ability to complete partial specifications of arguments. The general principle is that the user types the first few characters of the argument and then hits an escape character to prompt the system to complete the rest. Some completion systems require that the user type enough of the argument to be unique; others do not. Other systems allow the user to specify one argument and ask the system to fill in other arguments. For example, many mail systems allow the user to specify a username without a host for local mail delivery. The domain system defines name server completion transactions that perform the analogous service for the domain system. Implementation of this service is optional in a name server, but all name servers must at least be able to understand a completion request and return an error response. When a resolver wishes to request a completion, it sends a name server a message that sets QNAME to the partial string, QTYPE to the type of resource desired, and QCLASS to the desired class. The completion request also includes a RR for the target domain. The target domain RR identifies the preferred location of the resource. In completion requests, QNAME must still have a null label to terminate the name, but its presence is ignored. Note that a completion request is not a query, but shares some of the same field formats. For example, a completion request might contain QTYPE=A, QNAME=B, QCLASS=IN and a RR for ISI.ARPA. This request asks for completion for a resource whose name begins with "B" and is "close" to ISI.ARPA. This might be a typical shorthand used in the ISI community which uses "B" as a way of referring to B.ISI.ARPA. The first step in processing a completion request is to look for a "whole label" match. When the name server receives the request mentioned above, it looks at all records that are of type A, class IN, and whose domain name starts (on the left) with the labels of QNAME, in this case, "B". If multiple records match, the name server selects those whose domain names match (from the right) the most labels of the preferred domain name. If there are still multiple candidates, the name server selects the records that have the shortest (in terms of octets in the name) domain name. If several records remain, then the name server returns them all. If no records are found in the previous algorithm, the name server assumes that the rightmost label in QNAME is not complete, and Mockapetris [Page 26]
RFC 882 November 1983 Domain Names - Concepts and Facilities looks for records that match but require addition of characters to the rightmost label of QNAME. For example, the previous search would not match BB.ARPA to B, but this search would. If multiple hits are found, the same discarding strategy is followed. A detailed discussion of completion can be found in [14]. RESOLVERS Introduction Resolvers are programs that interface user programs to domain name servers. In the simplest case, a resolver receives a request from a user program (e.g. mail programs, TELNET, FTP) in the form of a subroutine call, system call etc., and returns the desired information in a form compatible with the local host's data formats. Because a resolver may need to consult several name servers, the amount of time that a resolver will take to complete can vary. This variance is part of the justification for the split between name servers and resolvers; name servers may use datagrams and have a response time that is essentially equal to network delay plus a short service time, while resolvers may take an essentially indeterminate amount of time. We expect to see two types of resolvers: simple resolvers that can chain through multiple name servers when required, and more complicated resolvers that cache resource records for use in future queries. Simple resolvers A simple resolver needs the following capabilities: 1. It must know how to access a name server, and should know the authoritative name server for the host that it services. 2. It must know the protocol capabilities for its clients so that it can set the class fields of the queries it sends to return information that is useful to its clients. If the resolver serves a client that has multiple protocol capabilities, it should be able to support the preferences of the client. The resolver for a multiple protocol client can either collect information for all classes using the * class value, or iterate on the classes supported by the client. Note that in either case, the resolver must understand the preferences of the host. For example, the host that supports both CSNET and ARPA Mockapetris [Page 27]
RFC 882 November 1983 Domain Names - Concepts and Facilities Internet protocols might prefer mail delivery (MD) to mail forwarding (MF), regardless of protocol, or might prefer one protocol regardless of whether MD or MF is required. Care is required to prevent loops. 3. The resolver must be capable of chaining through multiple name servers to get to an authoritative name server for any query. The resolver should guard against loops in referrals; a simple policy is to discard referrals that don't match more of the query name than the referring name server, and also to avoid querying the same name server twice (This test should be done using addresses of name servers instead of domain names to avoid problems when a name server has multiple domain names or errors are present in aliases). 4. The resolver must be able to try alternate name servers when a name server doesn't respond. 5. The resolver must be able to communicate different failure conditions to its client. These failure conditions include unknown domain name, unknown resource for a know domain name, and inability to access any of the authoritative name servers for a domain. 6. If the resolver uses datagrams for queries, it must recover from lost and duplicate datagrams. Resolvers with cache management Caching provides a tool for improving the performance of name service, but also is a potential source of incorrect results. For example, a database might cache information that is later changed in the authoritative name servers. While this problem can't be eliminated without eliminating caching, it can be reduced to an infrequent problem through the use of timeouts. When name servers return resource records, each record has an associated time-to-live (TTL) field. This field is expressed in seconds, and has 16 bits of significance. When a resolver caches a returned resource record it must also remember the TTL field. The resolver must discard the record when the equivalent amount of time has passed. If the resolver shares a database with a name server, it must decrement the TTL field of imported records periodically rather than simply deleting the record. This strategy is necessary to avoid exporting a resource record whose TTL field doesn't reflect the amount of time that the resource record has been cached. Of course, the resolver should Mockapetris [Page 28]
RFC 882 November 1983 Domain Names - Concepts and Facilities not decrement the TTL fields of records for which the associated name server is an authority. Mockapetris [Page 29]
RFC 882 November 1983 Domain Names - Concepts and Facilities Appendix 1 - Domain Name Syntax Specification The preferred syntax of domain names is given by the following BNF rules. Adherence to this syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET). Note that some applications described in [14] use domain names containing binary information and hence do not follow this syntax. <domain> ::= <subdomain> | " " <subdomain> ::= <label> | <subdomain> "." <label> <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ] <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str> <let-dig-hyp> ::= <let-dig> | "-" <let-dig> ::= <letter> | <digit> <letter> ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case <digit> ::= any one of the ten digits 0 through 9 Note that while upper and lower case letters are allowed in domain names no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical. The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less. For example, the following strings identify hosts in the ARPA Internet: F.ISI.ARPA LINKABIT-DCN5.ARPA UCL-TAC.ARPA Mockapetris [Page 30]
RFC 882 November 1983 Domain Names - Concepts and Facilities REFERENCES and BIBLIOGRAPHY [1] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD Internet Host Table Specification", RFC 810, Network Information Center, SRI International, March 1982. [2] J. Postel, "Computer Mail Meeting Notes", RFC 805, USC/Information Sciences Institute, February 1982. [3] Z. Su, and J. Postel, "The Domain Naming Convention for Internet User Applications", RFC 819, Network Information Center, SRI International, August 1982. [4] Z. Su, "A Distributed System for Internet Name Service", RFC 830, Network Information Center, SRI International, October 1982. [5] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC 812, Network Information Center, SRI International, March 1982. [6] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET Name Server", Computer Networks, vol 6, nr 3, July 1982. [7] K. Harrenstien, "NAME/FINGER", RFC 742, Network Information Center, SRI International, December 1977. [8] J. Postel, "Internet Name Server", IEN 116, USC/Information Sciences Institute, August 1979. [9] K. Harrenstien, V. White, and E. Feinler, "Hostnames Server", RFC 811, Network Information Center, SRI International, March 1982. [10] J. Postel, "Transmission Control Protocol", RFC 793, USC/Information Sciences Institute, September 1981. [11] J. Postel, "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, August 1980. [12] J. Postel, "Simple Mail Transfer Protocol", RFC 821, USC/Information Sciences Institute, August 1980. [13] J. Reynolds, and J. Postel, "Assigned Numbers", RFC 870, USC/Information Sciences Institute, October 1983. [14] P. Mockapetris, "Domain Names - Implementation and Specification", RFC 883, USC/Information Sciences Institute, November 1983. Mockapetris [Page 31]
Html markup produced by rfcmarkup 1.115, available from https://tools.ietf.org/tools/rfcmarkup/
Obsoleted by: 1034, 1035
Updated by: 973
Network Working Group P. Mockapetris Request for Comments: 882 ISI November 1983 DOMAIN NAMES - CONCEPTS and FACILITIES +-----------------------------------------------------+ | | | This RFC introduces domain style names, their use | | for ARPA Internet mail and host address support, | | and the protocols and servers used to implement | | domain name facilities. | | | | This memo describes the conceptual framework of the | | domain system and some uses, but it omits many | | uses, fields, and implementation details. A | | complete specification of formats, timeouts, etc. | | is presented in RFC 883, "Domain Names - | | Implementation and Specification". That RFC | | assumes that the reader is familiar with the | | concepts discussed in this memo. | | | +-----------------------------------------------------+ INTRODUCTION The need for domain names As applications grow to span multiple hosts, then networks, and finally internets, these applications must also span multiple administrative boundaries and related methods of operation (protocols, data formats, etc). The number of resources (for example mailboxes), the number of locations for resources, and the diversity of such an environment cause formidable problems when we wish to create consistent methods for referencing particular resources that are similar but scattered throughout the environment. The ARPA Internet illustrates the size-related problems; it is a large system and is likely to grow much larger. The need to have a mapping between host names (e.g., USC-ISIF) and ARPA Internet addresses (e.g., 10.2.0.52) is beginning to stress the existing mechanisms. Currently hosts in the ARPA Internet are registered with the Network Information Center (NIC) and listed in a global table (available as the file <NETINFO>HOSTS.TXT on the SRI-NIC host) [1]. The size of this table, and especially the frequency of updates to the table are near the limit of manageability. What is needed is a distributed database that performs the same function, and hence avoids the problems caused by a centralized database. The problem for computer mail is more severe. While mail system implementers long ago recognized the impossibility of centralizing Mockapetris [Page 1]
RFC 882 November 1983 Domain Names - Concepts and Facilities mailbox names, they have also created an increasingly large and irregular set of methods for identifying the location of a mailbox. Some of these methods involve the use of routes and forwarding hosts as part of the mail destination address, and consequently force the mail user to know multiple address formats, the capabilities of various forwarders, and ad hoc tricks for passing address specifications through intermediaries. These problems have common characteristics that suggest the nature of any solution: The basic need is for 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 contain 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 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. 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. Because we want the name space to be useful in dissimilar networks, it is unlikely that all users of domain names will be able to agree on the set of resources or resource information that names will be used to retrieve. Hence names refer to a set of resources, and queries contain resource identifiers. The only standard types of information that we expect to see throughout the name space is structuring information for the name space itself, and resources that are described using domain names and no nonstandard data. We also want the name server transactions to be independent of the communications system that carries them. Some systems may wish to use datagrams for simple 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. Mockapetris [Page 2]
RFC 882 November 1983 Domain Names - Concepts and Facilities Elements of the solution The proposed solution has three major components: The DOMAIN NAME SPACE, which is a specification for a tree structured name space. 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 ARPA Internet uses some of its domain names to identify hosts; queries for address resources return ARPA Internet host addresses. However, to preserve the generality of the domain mechanism, domain names are not required to have a one-to-one correspondence with host names, host addresses, or any other type of information. 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; these parts are called ZONEs; a name server is an AUTHORITY for these parts of the name space. RESOLVERS are programs that extract information from name servers in response to user 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 simple procedure or OS calls to resolvers. 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 server has one or more pieces of the whole domain tree's data, Mockapetris [Page 3]
RFC 882 November 1983 Domain Names - Concepts and Facilities 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 using the local zones. In the interests of performance, these layers blur a bit. For example, resolvers on the same machine as a name server may share a database and may also introduce foreign information for use in later queries. This cached information is treated differently from the authoritative data in zones. Database model 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 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 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 Mockapetris [Page 4]
RFC 882 November 1983 Domain Names - Concepts and Facilities updates or guarantees of consistency. Hence the update process allows updates to percolate out though 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. Some users will wish to access the database via datagrams; others will prefer virtual circuits. The domain system is designed so that simple queries and responses can use either style, although refreshing operations need the reliability of virtual circuits. The same overall message format is used for all communication. The domain system does not assume any special properties of the communications system, and hence could be used with any datagram or virtual circuit protocol. 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. The optional recursive style is discussed in [14], and omitted from further discussion in this memo. 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 to users of the domain system. A standard format for these files is given in [14]. The standard format allows these files 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. Mockapetris [Page 5]
RFC 882 November 1983 Domain Names - Concepts and Facilities Each host's name servers and resolvers are configured by a local system administrator. 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 DOMAIN NAME SPACE 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). Each node and leaf has an associated label. Labels are NOT guaranteed to be unique, with the exception of the root node, which has a null label. The domain name of a node or leaf is the path from the root of the tree to the node or leaf. By convention, the labels that compose a domain name are read left to right, from the most specific (lowest) to the least specific (highest). Internally, programs that manipulate domain names 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 Mockapetris [Page 6]
RFC 882 November 1983 Domain Names - Concepts and Facilities representations can use a length byte of zero to terminate a domain name. When domain names are printed, labels in a path are separated by dots ("."). The root label and its associated dot are omitted from printed domain names, but the root can be named by a null domain name (" " in this memo). To simplify implementations, the total number of octets that represent label octets and label lengths is limited to 255. Thus a printed domain name can be up to 254 characters. A special label is defined that matches any other label. This label is the asterisk or "*". An asterisk matches a single label. Thus *.ARPA matches FOO.ARPA, but does not match FOO.BAR.ARPA. The asterisk is mainly used to create default resource records at the boundary between protocol families, and requires prudence in its use. 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 has the containing domain's name as the right part of its name. For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ". This tree structure is intended to parallel the administrative organization and delegation of authority. Potentially, each node or leaf on the tree can create new subdomains ad infinitum. In practice, this delegation can be limited by the administrator of the name servers that manage the domain space and resource data. The following figure shows an example of a domain name space. | +------------------+------------------+ | | | COLORS FLAVORS TRUTH | | +-----+-----+ | | | | NATURAL RED BLUE GREEN | | +---------------+---------------+ | | | CHOCOLATE VANILLA STRAWBERRY In this example, the root domain has three immediate subdomains: COLORS, FLAVORS, and TRUTH. The FLAVORS domain has one immediate subdomain named NATURAL.FLAVORS. All of the leaves are also Mockapetris [Page 7]
RFC 882 November 1983 Domain Names - Concepts and Facilities domains. This domain tree has the names " "(the root), COLORS, RED.COLORS, BLUE.COLORS, GREEN.COLORS, FLAVORS, NATURAL.FLAVORS, CHOCOLATE.NATURAL.FLAVORS, VANILLA.NATURAL.FLAVORS, STRAWBERRY.NATURAL.FLAVORS, and TRUTH. If we wished to add a new domain of ARTIFICIAL under FLAVORS, FLAVORS would typically be the administrative entity that would decide; if we wished to create CHIP and MOCHA names under CHOCOLATE, CHOCOLATE.NATURAL.FLAVORS would typically be the appropriate administrative entity. Resource set information A domain name identifies a set of resource information. The set of resource information associated with a particular name is composed of separate resource records (RRs). Each resource record has the following major components: The domain name which identifies resource set that holds this record, and hence the "owner" of the information. For example, a RR that specifies a host address has a domain name the specifies the host having that address. Thus F.ISI.ARPA might be the owner of a RR which specified an address field of 10.2.0.52. Since name servers typically store their resource information in tree structures paralleling the organization of the domain space, this information can usually be stored implicitly in the database; however it is always included in each resource record carried in a message. Other information used to manage the RR, such as length fields, timeouts, etc. This information is omitted in much of this memo, but is discussed in [14]. A resource type field that specifies the type of the resource in this resource record. Types refer to abstract resources such as host addresses or mail delivery agents. The type field is two octets long and uses an encoding that is standard throughout the domain name system. A class field identifies the format of the resource data, such as the ARPA Internet format (IN) or the Computer Science Network format (CSNET), for certain RR types (such as address data). Note that while the class may separate different protocol families, networks, etc. it does not do so in all cases. For example, the IN class uses 32 bit IP addresses exclusively, but the CSNET class uses 32 bit IP addresses, X.25 addresses, and phone numbers. Thus the class field should be used as a guide for interpreting the resource data. The class field is two octets long and uses an encoding that is standard throughout the domain name system. Mockapetris [Page 8]
RFC 882 November 1983 Domain Names - Concepts and Facilities Resource data that describes the resource. The format of this data can be determined given the type and class fields, but always starts with a two octet length field that allows a name server or resolver to determine the boundaries of the resource data in any transaction, even if it cannot "understand" the resource data itself. Thus name servers and resolvers can hold and pass on records which they cannot interpret. The format of the internal data is restricted only by the maximum length of 65535 octets; for example the host address record might specify a fixed 32 bit number for one class, and a variable length list of addresses in another class. While the class field in effect partitions the resource data in the domain name system into separate parallel sections according to class, services can span class boundaries if they use compatible resource data formats. For example, the domain name system uses compatible formats for structure information, and the mail data decouples mail agent identification from details of how to contact the agent (e.g. host addresses). This memo uses the following types in its examples: A - the host address associated with the domain name MF - identifies a mail forwarder for the domain MD - identifies a mail destination for the domain NS - the authoritative name server for the domain SOA - identifies the start of a zone of authority CNAME - identifies the canonical name of an alias This memo uses the following classes in its examples: IN - the ARPA Internet system CS - the CSNET system The first type of resource record holds a host name to host address binding. Its fields are: +--------+--------+--------+--------------//----------------------+ |<owner> | A | <class>| <class specific address>information | +--------+--------+--------+--------------//----------------------+ Mockapetris [Page 9]
RFC 882 November 1983 Domain Names - Concepts and Facilities The content of the class specific information varies according to the value in the CLASS field; for the ARPA Internet, it is the 32 bit ARPA Internet address of the host, for the CSNET it might be the phone number of the host. For example, F.ISI.ARPA might have two A records of the form: +----------+--------+--------+----------------------------+ |F.ISI.ARPA| A | IN | 10.2.0.52 | +----------+--------+--------+----------------------------+ and +----------+--------+--------+----------------------------+ |F.ISI.ARPA| A | CS | 213-822-2112 | +----------+--------+--------+----------------------------+ Note that the data formats for the A type are class dependent, and the Internet address and phone number formats shown above are for purposes of illustration only. The actual data formats are specified in [14]. For example, CS class data for type A records might actually be a list of Internet addresses, phone numbers and TELENET addresses. The mail forwarder (MF) and mail delivery (MD) records have the following format: +--------+--------+--------+----------------------------+ |<owner> | MD/MF | <class>| <domain name> | +--------+--------+--------+----------------------------+ The <domain name> field is a domain name of the host that will handle mail; note that this domain name may be completely different from the domain name which names the resource record. For example, F.ISI.ARPA might have two records of the form: +----------+--------+--------+----------------------------+ |F.ISI.ARPA| MD | IN | F.ISI.ARPA | +----------+--------+--------+----------------------------+ and +----------+--------+--------+----------------------------+ |F.ISI.ARPA| MF | IN | B.ISI.ARPA | +----------+--------+--------+----------------------------+ These records mean that mail for F.ISI.ARPA can either be delivered to the host F.ISI.ARPA or forwarded to B.ISI.ARPA, which will accept responsibility for its eventual delivery. In principle, an additional name lookup is required to map the domain name of the host to the appropriate address, in practice this information is usually returned in the response to the mail query. The SOA and NS types of resource records are used to define limits Mockapetris [Page 10]
RFC 882 November 1983 Domain Names - Concepts and Facilities of authority. The domain name given by the owner field of a SOA record is the start of a zone; the domain name given by the owner field of a NS record identifies a point in the name space where authority has been delegated, and hence marks the zone boundary. Except in the case where a name server delegates authority to itself, the SOA identifies the top limit of authority, and NS records define the first name outside of a zone. These resource records have a standard format for all of the name space: +----------+--------+--------+-----------------------------+ | <owner> | SOA | <class>| <domain name, etc> | +----------+--------+--------+-----------------------------+ +----------+--------+--------+-----------------------------+ | <owner> | NS | <class>| <domain name> | +----------+--------+--------+-----------------------------+ The SOA record marks the start of a zone when it is present in a database; the NS record both marks the end of a zone started by an SOA (if a higher SOA is present) and also points to a name server that has a copy of the zone specified by the <owner. field of the NS record. The <domain name, etc> in the SOA record specifies the original source of the information in the zone and other information used by name servers to organize their activities. SOA records are never cached (otherwise they would create false zones); they can only be created in special name server maintenance operations. The NS record says that a name server which is authoritative for records of the given CLASS can be found at <domain name>. Queries Queries to a name server must include a domain name which identifies the target resource set (QNAME), and the type and class of desired resource records. The type and class fields in a query can include any of the corresponding type and class fields that are defined for resource records; in addition, the query type (QTYPE) and query class (QCLASS) fields may contain special values that match more than one of the corresponding fields in RRs. For example, the QTYPE field may contain: MAILA - matches all mail agent RRs (e.g. MD and MF). * - matches any RR type. Mockapetris [Page 11]
RFC 882 November 1983 Domain Names - Concepts and Facilities The QCLASS field may contain: * - matches any RR class. Using the query domain name, QTYPE, and QCLASS, the name server looks for matching RRs. In addition to relevant records, the name server may return RRs that point toward a name server that has the desired information or RRs that are expected to be useful in interpreting the relevant RRs. For example a name server that doesn't have the requested information may know a name server that does; a name server that returns a domain name in a relevant RR may also return the RR that binds that domain name to an address. Note that the QCLASS=* construct requires special interpretation regarding authority. Since a name server may not know all of the classes available in the domain system, it can never know if it is authoritative for all classes. Hence responses to QCLASS=* queries can never be authoritative. Example space For purposes of exposition, the following name space is used for the remainder of this memo: | +------------------+------------------+ | | | DDN ARPA CSNET | | | +-----+-----+ | +-----+-----+ | | | | | | JCS ARMY NAVY | UDEL UCI | +--------+---------------+---------------+--------+ | | | | | DTI MIT ISI UDEL NBS | | +---+---+ +---+---+ | | | | | DMS AI A B F Mockapetris [Page 12]
RFC 882 November 1983 Domain Names - Concepts and Facilities NAME SERVERS Introduction Name servers store a distributed database consisting of the structure of the domain name space, the resource sets associated with domain names, and other information used to coordinate actions between name servers. In general, a name server will be an authority for all or part of a particular domain. The region covered by this authority is called a zone. Name servers may be responsible for no authoritative data, and hence have no zones, or may have several zones. When a name server has multiple zones, the zones may have no common borders or zones may be contiguous. While administrators should not construct overlapping zones, and name servers must defend against overlapping zones, overlapping is regarded as a non-fatal flaw in the database. Hence the measures taken to protect against it are omitted for the remainder of this memo. A detailed discussion can be found in [14]. When presented with a query for a domain name over which it has authority, a name server returns the desired resource information or an indication that the query refers to a domain name or resource that does not exist. If a name server is presented with a query for a domain name that is not within its authority, it may have the desired information, but it will also return a response that points toward an authoritative name server. If a name server is not an authority for a query, it can never return a negative response. There is no requirement that a name server for a domain reside in a host which has a name in the same domain, although this will usually be the case. There is also no restriction on the number of name servers that can have authority over a particular domain; most domains will have redundant authoritative name servers. The assumption is that different authoritative copies are identical, even though inconsistencies are possible as updates are made. Name server functions are designed to allow for very simple implementations of name servers. The simplest name server has a static set of information and uses datagrams to receive queries and return responses. More sophisticated name server implementations can improve the performance of their clients by caching information from other domains. Although this information can be acquired in a number of ways, the normal method is to store the information acquired by a Mockapetris [Page 13]
RFC 882 November 1983 Domain Names - Concepts and Facilities resolver when the resolver consults other name servers. In a sophisticated host, the resolver and name server will coordinate their actions and use a shared database. This cooperation requires the incorporation of a time-to-live (TTL) field in all cached resource records. Caching is discussed in the resolver section of this memo; this section is devoted to the actions of a name servers that don't cache. In order to free simple name servers of the requirement of managing these timeouts, simple name servers should only contain resource records that are expected to remain constant over very long periods or resource records for which the name server is an authority. In the following discussion, the TTL field is assumed to be stored in the resource record but is omitted in descriptions of databases and responses in the interest of clarity. Authority and administrative control of domains Although we want to have the potential of delegating the privileges of name space management at every node, we don't want such delegation to be required. Hence we introduce the concept of authority. Authority is vested in name servers. A name server has authority over all of its domain until it delegates authority for a subdomain to some other name server. Any administrative entity that wishes to establish its own domain must provide a name server, and have that server accepted by the parent name server (i.e. the name server that has authority over the place in the domain name space that will hold the new domain). While the principles of authority allow acceptance to be at the discretion of parent name servers, the following criteria are used by the root, and are recommended to all name servers because they are responsible for their children's actions: 1. It must register with the parent administrator of domains. 2. It must identify a responsible person. 3. In must provide redundant name servers. The domain name must be registered with the administrator to avoid name conflicts and to make the domain related information available to other domains. The central administrator may have further requirements, and a domain is not registered until the central administrator agrees that all requirements are met. There must be a responsible person associated with each domain to Mockapetris [Page 14]
RFC 882 November 1983 Domain Names - Concepts and Facilities be a contact point for questions about the domain, to verify and update the domain related information, and to resolve any problems (e.g., protocol violations) with hosts in the domain. The domain must provide redundant (i.e., two or more) name servers to provide the name to address resolution service. These name servers must be accessible from outside the domain (as well as inside) and must resolve names for at least all the hosts in the domain. Once the central administrator is satisfied, he will communicate the existence to the appropriate administrators of other domains so that they can incorporate NS records for the new name server into their databases. Name server logic The processing steps that a name server performs in responding to a query are conceptually simple, although implementations may have internal databases that are quite complex. For purposes of explanation, we assume that the query consists of a type QTYPE, a class QCLASS, and a domain name QNAME; we assume that the name server stores its RRs in sets where each set has all of the RRs for a particular domain. Note that this database structure and the following algorithms are meant to illustrate one possible implementation, rather than a specification of how all servers must be implemented. The following notation is used: ord(DOMAIN-NAME) returns the number of labels in DOMAIN-NAME. findset(DOMAIN-NAME) returns a pointer to the set of stored RRs for DOMAIN-NAME, or NULL if there is no such information. set(POINTER) refers to a set located previously by findset, where POINTER is the value returned by findset. relevant(QTYPE,TYPE) returns true if a RR of the specified TYPE is relevant to the specified QTYPE. For example, relevant(MAILA,MF) is true and relevant(MAILA,NS) is false. right(NAME,NUMBER) returns a domain name that is the rightmost NUMBER labels in the string NAME. Mockapetris [Page 15]
RFC 882 November 1983 Domain Names - Concepts and Facilities copy(RR) copies the resource record specified by RR into the response. The name server code could be represented as the following sequence of steps: { find out whether the database makes this server authoritative for the domain name specified by QNAME } for i:=0 to ord(QNAME) { sequence through all nodes in QNAME } do begin ptr:=findset(right(QNAME,i)); if ptr<>NULL then { there is domain data for this domain name } begin for all RRs in set(ptr) do if type(RR)=NS and class(RR)=QCLASS then begin auth=false; NSptr:=ptr end; for all RRs in set(ptr) do if type(RR)=SOA and class(RR)=QCLASS then auth:=true end end; end; { copy out authority search results } if auth then { if authority check for domain found } if ptr=null then return(Name error) else else { if not authority, copy NS RRs } for all RRs in set(nsptr) do if (type(RR)=NS and class(RR)=QCLASS) or (QCLASS=*) then copy(RR); { Copy all RRs that answer the question } for all RRs in set(ptr) do if class(RR)=QCLASS and relevant(QTYPE,type(RR)) then copy(RR); The first section of the code (delimited by the for loop over all Mockapetris [Page 16]
RFC 882 November 1983 Domain Names - Concepts and Facilities of the subnodes of QNAME) discovers whether the name server is authoritative for the domain specified by QNAME. It sequences through all containing domains of QNAME, starting at the root. If it encounters a SOA it knows that the name server is authoritative unless it finds a lower NS RR which delegates authority. If the name server is authoritative, it sets auth=true; if the name server is not authoritative, it sets NSptr to point to the set which contains the NS RR closest to the domain specified by QNAME. The second section of the code reflects the result of the authority search into the response. If the name server is authoritative, the code checks to see that the domain specified by QNAME exists; if not, a name error is returned. If the name server is not authoritative, the code copies the RRs for a closer name server into the response. The last section of the code copies all relevant RRs into the response. Note that this code is not meant as an actual implementation and is incomplete in several aspects. For example, it doesn't deal with providing additional information, wildcards, QCLASS=*, or with overlapping zones. The first two of these issues are dealt with in the following discussions, the remaining issues are discussed in [14]. Additional information When a resolver returns information to a user program, the returned information will often lead to a second query. For example, if a mailer asks a resolver for the appropriate mail agent for a particular domain name, the name server queried by the resolver returns a domain name that identifies the agent. In general, we would expect that the mailer would then request the domain name to address binding for the mail agent, and a new name server query would result. To avoid this duplication of effort, name servers return additional information with a response which satisfies the anticipated query. This information is kept in a separate section of the response. Name servers are required to complete the appropriate additional information if such information is available, but the requestor should not depend on the presence of the information since the name server may not have it. If the resolver caches the additional information, it can respond to the second query without an additional network transaction. The appropriate information is defined in [14], but generally Mockapetris [Page 17]
RFC 882 November 1983 Domain Names - Concepts and Facilities consists of host to address bindings for domain names in returned RRs. Aliases and canonical names In existing systems, hosts and other resources often have several names that identify the same resource. For example, under current ARPA Internet naming support, USC-ISIF and ISIF both identify the same host. Similarly, in the case of mailboxes, many organizations provide many names that actually go to the same mailbox; for example Mockapetris@ISIF, Mockapetris@ISIB, etc., all go to the same mailbox (although the mechanism behind this is somewhat complicated). Most of these systems have a notion that one of the equivalent set of names is the canonical name and all others are aliases. The domain system provides a similar feature using the canonical name (CNAME) RR. When a name server fails to find a desired RR in a set associated with some domain name, it checks to see if the resource set contains a CNAME record with a matching class. If so, the name server includes the CNAME record in the response, and continues the query at the domain name specified in the data field of the CNAME record. Suppose a name server was processing a query with QNAME=ISIF.ARPA, QTYPE=A, and QCLASS=IN, and had the following resource records: ISIF.ARPA CNAME IN F.ISI.ARPA F.ISI.ARPA A IN 10.2.0.52 Both of these RRs would be returned in the response. In the above example, because ISIF.ARPA has no RRs other than the CNAME RR, the resources associated with ISIF.ARPA will appear to be exactly those associated with F.ISI.ARPA for the IN CLASS. Since the CNAME is effective only when the search fails, a CNAME can also be used to construct defaults. For example, suppose the name server had the following set of RRs: F.ISI.ARPA A IN 10.2.0.52 F.ISI.ARPA MD IN F.ISI.ARPA XXXX.ARPA CNAME IN F.ISI.ARPA XXXX.ARPA MF IN A.ISI.ARPA Using this database, type A queries for XXXX.ARPA would return the XXXX.ARPA CNAME RR and the F.ISI.ARPA A RR, but MAILA or MF queries to XXXX.ARPA would return the XXXX.ARPA MF RR without any information from F.ISI.ARPA. This structure might be used to send Mockapetris [Page 18]
RFC 882 November 1983 Domain Names - Concepts and Facilities mail addressed to XXXX.ARPA to A.ISI.ARPA and to direct TELNET for XXXX.ARPA to F.ISI.ARPA. Wildcards In certain cases, an administrator may wish to associate default resource information for all or part of a domain. For example, the CSNET domain administrator may wish to establish IN class mail forwarding for all hosts in the CSNET domain without IN capability. In such a case, the domain system provides a special label "*" that matches any other label. Note that "*" matches only a single label, and not zero or more than one label. Note also that the "*" is distinct from the "*" values for QCLASS and QTYPE. The semantics of "*" depend upon whether it appears in a query domain name (QNAME) or in a RR in a database. When an "*" is used in a QNAME, it can only match a "*" in a resource record. When "*" appears in a RR in a database, it can never override an existing exact match. For example, if a name server received a query for the domain UDEL.CSNET, and had appropriate RRs for both UDEL.CSNET and *.CSNET, the UDEL.CSNET RRs would be used and the *.CSNET RRs would be ignored. If a query to the same database specified FOO.CSNET, the *.CSNET RR would be used, but the corresponding labels from the QNAME would replace the "*". Thus the FOO.CSNET query would match the *.CSNET RR and return a RR for FOO.CSNET rather than *.CSNET. RRs containing "*" labels are copied exactly when zones are transfered via name server maintenance operations. These semantics are easily implemented by having the name server first search for an exact match for a query, and then replacing the leftmost label with a "*" and trying again, repeating the process until all labels became "*" or the search succeeded. TYPE=* in RRs is prohibited. If it were to be allowed, the requestor would have no way of interpreting the data in the RR because this data is type dependent. CLASS=* is also prohibited. Similar effects can be achieved using QCLASS=*, and allowing both QCLASS=* and CLASS=* leads to complexities without apparent benefit. Mockapetris [Page 19]
RFC 882 November 1983 Domain Names - Concepts and Facilities A scenario In our sample domain space, suppose we wanted separate administrative control for the root, DDN, ARPA, CSNET, MIT and ISI domains. We might allocate name servers as follows: |(B.ISI.ARPA) |(UDEL.CSNET) +------------------+------------------+ | | | DDN ARPA CSNET |(JCS.DDN) |(F.ISI.ARPA) |(UDEL.ARPA) +-----+-----+ |(A.ISI.ARPA)+-----+-----+ | | | | | | JCS ARMY NAVY | UDEL UCI | +--------+---------------+---------------+--------+ | | | | | DTI MIT ISI UDEL NBS |(AI.MIT.ARPA) |(F.ISI.ARPA) +---+---+ +---+---+ | | | | | DMS AI A B F In this example the authoritative name server is shown in parentheses at the point in the domain tree at which is assumes control. Thus the root name servers are on B.ISI.ARPA and UDEL.CSNET, the DDN name server is on JCS.DDN, the CSNET domain server is on UDEL.ARPA, etc. In an actual system, all domains should have redundant name servers, but in this example only the ARPA domain has redundant servers A.ISI.ARPA and F.ISI.ARPA. (The B.ISI.ARPA and UDEL.CSNET name servers happen to be not redundant because they handle different classes.) The F.ISI.ARPA name server has authority over the ARPA domain, but delegates authority over the MIT.ARPA domain to the name server on AI.MIT.ARPA. The A.ISI.ARPA name server also has authority over the ARPA domain, but delegates both the ISI.ARPA and MIT.ARPA domains to other name servers. Mockapetris [Page 20]
RFC 882 November 1983 Domain Names - Concepts and Facilities B.ISI.ARPA Name server for " " B.ISI.ARPA has the root name server for the IN class. Its database might contain: Domain Resource Record " " SOA IN A.ISI.ARPA DDN NS IN JCS.DDN ARPA NS IN F.ISI.ARPA CSNET NS IN UDEL.ARPA " " NS IN B.ISI.ARPA " " NS CS UDEL.CSNET JCS.DDN A IN 9.0.0.1 F.ISI.ARPA A IN 10.2.0.52 UDEL.CSNET A CS 302-555-0000 UDEL.ARPA A IN 10.0.0.96 The SOA record for the root is necessary so that the name server knows that it is authoritative for the root domain for class IN. The contents of the SOA resource record point back to A.ISI.ARPA and denote that the master data for the zone of authority is originally from this host. The first three NS records denote delegation of authority. The NS root entry for the B.ISI.ARPA name server is necessary so that this name server knows about itself, and can respond correctly to a query for NS information about the root (for which it is an authority). The root entry for class CS denotes that UDEL.CSNET is the authoritative name server for the CS class root. UDEL.CSNET and UDEL.ARPA may or may not refer to the same name server; from this information it is impossible to tell. If this name server was sent a query specifying QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA, it would begin processing (using the previous algorithm) by determining that it was not an authority for F.ISI.ARPA. The test would note that it had authority at " ", but would also note that the authority was delegated at ARPA and never reestablished via another SOA. Thus the response would return the NS record for the domain ARPA. Any queries presented to this server with QCLASS=CS would result in the UDEL.CSNET NS record being returned in the response. Mockapetris [Page 21]
RFC 882 November 1983 Domain Names - Concepts and Facilities F.ISI.ARPA Name server for ARPA and ISI.ARPA In the same domain space, the F.ISI.ARPA database for the domains ARPA and ISI.ARPA might be: Domain Resource Record " " NS IN B.ISI.ARPA " " NS CS CSNET.UDEL ARPA SOA IN B.ISI.ARPA ARPA NS IN A.ISI.ARPA ARPA NS IN F.ISI.ARPA MIT.ARPA NS IN AI.MIT.ARPA ISI.ARPA SOA IN F.ISI.ARPA ISI.ARPA NS IN F.ISI.ARPA A.ISI.ARPA MD IN A.ISI.ARPA ISI.ARPA MD IN F.ISI.ARPA A.ISI.ARPA MF IN F.ISI.ARPA B.ISI.ARPA MD IN B.ISI.ARPA B.ISI.ARPA MF IN F.ISI.ARPA F.ISI.ARPA MD IN F.ISI.ARPA F.ISI.ARPA MF IN A.ISI.ARPA DTI.ARPA MD IN DTI.ARPA NBS.ARPA MD IN NBS.ARPA UDEL.ARPA MD IN UDEL.ARPA A.ISI.ARPA A IN 10.1.0.32 F.ISI.ARPA A IN 10.2.0.52 B.ISI.ARPA A IN 10.3.0.52 DTI.ARPA A IN 10.0.0.12 AI.MIT.ARPA A IN 10.2.0.6 DMS.MIT.ARPA A IN 10.1.0.6 NBS.ARPA A IN 10.0.0.19 UDEL.ARPA A IN 10.0.0.96 For the IN class, the SOA RR for ARPA denotes that this name server is authoritative for the domain ARPA, and that the master file for this authority is stored on B.ISI.ARPA. This zone extends to ISI.ARPA, where the database delegates authority back to this name server in another zone, and doesn't include the domain MIT.ARPA, which is served by a name server on AI.MIT.ARPA. This name server is not authoritative for any data in the CS class. It has a pointer to the root server for CS data which could be use to resolve CS class queries. Suppose this name server received a query of the form QNAME=A.ISI.ARPA, QTYPE=A, and QCLASS=IN. The authority search Mockapetris [Page 22]
RFC 882 November 1983 Domain Names - Concepts and Facilities would notice the NS record for " ", its SOA at ARPA, a delegation at ISI.ARPA, and the reassumption of authority at ISI.ARPA. Hence it would know that it was an authority for this query. It would then find the A record for A.ISI.ARPA, and return a datagram containing this record. Another query might be QNAME=B.ISI.ARPA, QTYPE=MAILA, QCLASS=*. In this case the name server would know that it cannot be authoritative because of the "*" value of QCLASS, and would look for records for domain B.ISI.ARPA that match. Assuming that the name server performs the additional record inclusion mentioned in the name server algorithm, the returned datagram would include: ISI.ARPA NS IN F.ISI.ARPA " " NS CS UDEL.CSNET B.ISI.ARPA MD IN B.ISI.ARPA B.ISI.ARPA MF IN F.ISI.ARPA B.ISI.ARPA A IN 10.3.0.52 F.ISI.ARPA A IN 10.2.0.52 If the query were QNAME=DMS.MIT.ARPA, QTYPE=MAILA, QCLASS=IN, the name server would discover that AI.MIT.ARPA was the authoritative name server and return the following: MIT.ARPA NS IN AI.MIT.ARPA AI.MIT.ARPA A IN 10.2.0.6 In this case, the requestor is directed to seek information from the MIT.ARPA domain name server residing on AI.MIT.ARPA. Mockapetris [Page 23]
RFC 882 November 1983 Domain Names - Concepts and Facilities UDEL.ARPA and UDEL.CSNET name server In the previous discussion of the sample domain, we stated that UDEL.CSNET and UDEL.ARPA might be the same name server. In this example, we assume that this is the case. As such, the name server is an authority for the root for class CS, and an authority for the CSNET domain for class IN. This name server deals with mail forwarding between the ARPA Internet and CSNET systems. Its RRs illustrate one approach to solving this problem. The name server has the following resource records: " " SOA CS UDEL.CSNET " " NS CS UDEL.CSNET " " NS IN B.ISI.ARPA CSNET SOA IN UDEL.ARPA CSNET NS IN UDEL.ARPA ARPA NS IN A.ISI.ARPA *.CSNET MF IN UDEL.ARPA UDEL.CSNET MD CS UDEL.CSNET UCI.CSNET MD CS UCI.CSNET UDEL.ARPA MD IN UDEL.ARPA B.ISI.ARPA A IN 10.3.0.52 UDEL.ARPA A IN 10.0.0.96 UDEL.CSNET A CS 302-555-0000 UCI.CSNET A CS 714-555-0000 Suppose this name server received a query of the form QNAME=UCI.CSNET, QTYPE=MAILA, and QCLASS=IN. The name server would discover it was authoritative for the CSNET domain under class IN, but would find no explicit mail data for UCI.CSNET. However, using the *.CSNET record, it would construct a reply: UCI.CSNET MF IN UDEL.ARPA UDEL.ARPA A IN 10.0.0.96 If this name server received a query of the form QNAME=UCI.CSNET, QTYPE=MAILA, and QCLASS=CS, the name server would return: UCI.CSNET MD CS UCI.CSNET UCI.CSNET A CS 714-555-0000 Note that although this scheme allows for forwarding of all mail addressed as <anything>.CSNET, it doesn't help with names that have more than two components, e.g. A.B.CSNET. Although this problem could be "fixed" by a series of MF entries for *.*.CSNET, Mockapetris [Page 24]
RFC 882 November 1983 Domain Names - Concepts and Facilities *.*.*.CSNET, etc, a more tasteful solution would be to introduce a cleverer pattern matching algorithm in the CSNET name server. Summary of requirements for name servers The requirements for a name server are as follows: 1. It must be recognized by its parent. 2. It must have complete resource information for all domain names for which it is the authority. 3. It must periodically refresh authoritative information from a master file or name server which holds the master. 4. If it caches information it must also handle TTL management for that information. 5. It must answer simple queries. Inverse queries Name servers may also support inverse queries that map a particular resource to a domain name or domain names that have that resource. For example, while a query might map a domain name to a host address, the corresponding inverse query might map the address back to the domain name. Implementation of this service is optional in a name server, but all name servers must at least be able to understand an inverse query message and return an error response. The domain system cannot guarantee the completeness or uniqueness of inverse queries because the domain system is organized by domain name rather than by host address or any other resource type. In general, a resolver or other program that wishes to guarantee that an inverse query will work must use a name server that is known to have the appropriate data, or ask all name servers in a domain of interest. For example, if a resolver wishes to perform an inverse query for an arbitrary host on the ARPA Internet, it must consult a set of name servers sufficient to know that all IN data was considered. In practice, a single inverse query to a name server that has a fairly comprehensive database should satisfy the vast majority of inverse queries. A detailed discussion of inverse queries is contained in [14]. Mockapetris [Page 25]
RFC 882 November 1983 Domain Names - Concepts and Facilities Completion services Some existing systems provide the ability to complete partial specifications of arguments. The general principle is that the user types the first few characters of the argument and then hits an escape character to prompt the system to complete the rest. Some completion systems require that the user type enough of the argument to be unique; others do not. Other systems allow the user to specify one argument and ask the system to fill in other arguments. For example, many mail systems allow the user to specify a username without a host for local mail delivery. The domain system defines name server completion transactions that perform the analogous service for the domain system. Implementation of this service is optional in a name server, but all name servers must at least be able to understand a completion request and return an error response. When a resolver wishes to request a completion, it sends a name server a message that sets QNAME to the partial string, QTYPE to the type of resource desired, and QCLASS to the desired class. The completion request also includes a RR for the target domain. The target domain RR identifies the preferred location of the resource. In completion requests, QNAME must still have a null label to terminate the name, but its presence is ignored. Note that a completion request is not a query, but shares some of the same field formats. For example, a completion request might contain QTYPE=A, QNAME=B, QCLASS=IN and a RR for ISI.ARPA. This request asks for completion for a resource whose name begins with "B" and is "close" to ISI.ARPA. This might be a typical shorthand used in the ISI community which uses "B" as a way of referring to B.ISI.ARPA. The first step in processing a completion request is to look for a "whole label" match. When the name server receives the request mentioned above, it looks at all records that are of type A, class IN, and whose domain name starts (on the left) with the labels of QNAME, in this case, "B". If multiple records match, the name server selects those whose domain names match (from the right) the most labels of the preferred domain name. If there are still multiple candidates, the name server selects the records that have the shortest (in terms of octets in the name) domain name. If several records remain, then the name server returns them all. If no records are found in the previous algorithm, the name server assumes that the rightmost label in QNAME is not complete, and Mockapetris [Page 26]
RFC 882 November 1983 Domain Names - Concepts and Facilities looks for records that match but require addition of characters to the rightmost label of QNAME. For example, the previous search would not match BB.ARPA to B, but this search would. If multiple hits are found, the same discarding strategy is followed. A detailed discussion of completion can be found in [14]. RESOLVERS Introduction Resolvers are programs that interface user programs to domain name servers. In the simplest case, a resolver receives a request from a user program (e.g. mail programs, TELNET, FTP) in the form of a subroutine call, system call etc., and returns the desired information in a form compatible with the local host's data formats. Because a resolver may need to consult several name servers, the amount of time that a resolver will take to complete can vary. This variance is part of the justification for the split between name servers and resolvers; name servers may use datagrams and have a response time that is essentially equal to network delay plus a short service time, while resolvers may take an essentially indeterminate amount of time. We expect to see two types of resolvers: simple resolvers that can chain through multiple name servers when required, and more complicated resolvers that cache resource records for use in future queries. Simple resolvers A simple resolver needs the following capabilities: 1. It must know how to access a name server, and should know the authoritative name server for the host that it services. 2. It must know the protocol capabilities for its clients so that it can set the class fields of the queries it sends to return information that is useful to its clients. If the resolver serves a client that has multiple protocol capabilities, it should be able to support the preferences of the client. The resolver for a multiple protocol client can either collect information for all classes using the * class value, or iterate on the classes supported by the client. Note that in either case, the resolver must understand the preferences of the host. For example, the host that supports both CSNET and ARPA Mockapetris [Page 27]
RFC 882 November 1983 Domain Names - Concepts and Facilities Internet protocols might prefer mail delivery (MD) to mail forwarding (MF), regardless of protocol, or might prefer one protocol regardless of whether MD or MF is required. Care is required to prevent loops. 3. The resolver must be capable of chaining through multiple name servers to get to an authoritative name server for any query. The resolver should guard against loops in referrals; a simple policy is to discard referrals that don't match more of the query name than the referring name server, and also to avoid querying the same name server twice (This test should be done using addresses of name servers instead of domain names to avoid problems when a name server has multiple domain names or errors are present in aliases). 4. The resolver must be able to try alternate name servers when a name server doesn't respond. 5. The resolver must be able to communicate different failure conditions to its client. These failure conditions include unknown domain name, unknown resource for a know domain name, and inability to access any of the authoritative name servers for a domain. 6. If the resolver uses datagrams for queries, it must recover from lost and duplicate datagrams. Resolvers with cache management Caching provides a tool for improving the performance of name service, but also is a potential source of incorrect results. For example, a database might cache information that is later changed in the authoritative name servers. While this problem can't be eliminated without eliminating caching, it can be reduced to an infrequent problem through the use of timeouts. When name servers return resource records, each record has an associated time-to-live (TTL) field. This field is expressed in seconds, and has 16 bits of significance. When a resolver caches a returned resource record it must also remember the TTL field. The resolver must discard the record when the equivalent amount of time has passed. If the resolver shares a database with a name server, it must decrement the TTL field of imported records periodically rather than simply deleting the record. This strategy is necessary to avoid exporting a resource record whose TTL field doesn't reflect the amount of time that the resource record has been cached. Of course, the resolver should Mockapetris [Page 28]
RFC 882 November 1983 Domain Names - Concepts and Facilities not decrement the TTL fields of records for which the associated name server is an authority. Mockapetris [Page 29]
RFC 882 November 1983 Domain Names - Concepts and Facilities Appendix 1 - Domain Name Syntax Specification The preferred syntax of domain names is given by the following BNF rules. Adherence to this syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET). Note that some applications described in [14] use domain names containing binary information and hence do not follow this syntax. <domain> ::= <subdomain> | " " <subdomain> ::= <label> | <subdomain> "." <label> <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ] <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str> <let-dig-hyp> ::= <let-dig> | "-" <let-dig> ::= <letter> | <digit> <letter> ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case <digit> ::= any one of the ten digits 0 through 9 Note that while upper and lower case letters are allowed in domain names no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical. The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less. For example, the following strings identify hosts in the ARPA Internet: F.ISI.ARPA LINKABIT-DCN5.ARPA UCL-TAC.ARPA Mockapetris [Page 30]
RFC 882 November 1983 Domain Names - Concepts and Facilities REFERENCES and BIBLIOGRAPHY [1] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD Internet Host Table Specification", RFC 810, Network Information Center, SRI International, March 1982. [2] J. Postel, "Computer Mail Meeting Notes", RFC 805, USC/Information Sciences Institute, February 1982. [3] Z. Su, and J. Postel, "The Domain Naming Convention for Internet User Applications", RFC 819, Network Information Center, SRI International, August 1982. [4] Z. Su, "A Distributed System for Internet Name Service", RFC 830, Network Information Center, SRI International, October 1982. [5] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC 812, Network Information Center, SRI International, March 1982. [6] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET Name Server", Computer Networks, vol 6, nr 3, July 1982. [7] K. Harrenstien, "NAME/FINGER", RFC 742, Network Information Center, SRI International, December 1977. [8] J. Postel, "Internet Name Server", IEN 116, USC/Information Sciences Institute, August 1979. [9] K. Harrenstien, V. White, and E. Feinler, "Hostnames Server", RFC 811, Network Information Center, SRI International, March 1982. [10] J. Postel, "Transmission Control Protocol", RFC 793, USC/Information Sciences Institute, September 1981. [11] J. Postel, "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, August 1980. [12] J. Postel, "Simple Mail Transfer Protocol", RFC 821, USC/Information Sciences Institute, August 1980. [13] J. Reynolds, and J. Postel, "Assigned Numbers", RFC 870, USC/Information Sciences Institute, October 1983. [14] P. Mockapetris, "Domain Names - Implementation and Specification", RFC 883, USC/Information Sciences Institute, November 1983. Mockapetris [Page 31]
Html markup produced by rfcmarkup 1.115, available from https://tools.ietf.org/tools/rfcmarkup/
RFC 883 . DOMAIN NAMES IMPLEMENTATION & DOCUMENTATION
[Docs] [txt|pdf]
Obsoleted by: 1034, 1035
Updated by: 973
Network Working Group P. Mockapetris Request for Comments: 883 ISI November 1983 DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION +-----------------------------------------------------+ | | | This memo discusses the implementation of domain | | name servers and resolvers, specifies the format of | | transactions, and discusses the use of domain names | | in the context of existing mail systems and other | | network software. | | | | This memo assumes that the reader is familiar with | | RFC 882, "Domain Names - Concepts and Facilities" | | which discusses the basic principles of domain | | names and their use. | | | | The algorithms and internal data structures used in | | this memo are offered as suggestions rather than | | requirements; implementers are free to design their | | own structures so long as the same external | | behavior is achieved. | | | +-----------------------------------------------------+ +-----------------------------------------------+ | | | ***** WARNING ***** | | | | This RFC contains format specifications which | | are preliminary and are included for purposes | | of explanation only. Do not attempt to use | | this information for actual implementations. | | | +-----------------------------------------------+ Mockapetris [Page i]
RFC 883 November 1983 Domain Names - Implementation and Specification TABLE OF CONTENTS INTRODUCTION........................................................3 Overview.........................................................3 Implementation components........................................2 Conventions......................................................6 Design philosophy................................................8 NAME SERVER TRANSACTIONS...........................................11 Introduction....................................................11 Query and response transport....................................11 Overall message format..........................................13 The contents of standard queries and responses..................15 Standard query and response example.............................15 The contents of inverse queries and responses...................17 Inverse query and response example..............................18 Completion queries and responses................................19 Completion query and response example...........................22 Recursive Name Service..........................................24 Header section format...........................................26 Question section format.........................................29 Resource record format..........................................30 Domain name representation and compression......................31 Organization of the Shared database.............................33 Query processing................................................36 Inverse query processing........................................37 Completion query processing.....................................38 NAME SERVER MAINTENANCE............................................39 Introduction....................................................39 Conceptual model of maintenance operations......................39 Name server data structures and top level logic.................41 Name server file loading........................................43 Name server file loading example................................45 Name server remote zone transfer................................47 RESOLVER ALGORITHMS................................................50 Operations......................................................50 DOMAIN SUPPORT FOR MAIL............................................52 Introduction....................................................52 Agent binding...................................................53 Mailbox binding.................................................54 Appendix 1 - Domain Name Syntax Specification......................56 Appendix 2 - Field formats and encodings...........................57 TYPE values.....................................................57 QTYPE values....................................................57 CLASS values....................................................58 QCLASS values...................................................58 Standard resource record formats................................59 Appendix 3 - Internet specific field formats and operations........67 REFERENCES and BIBLIOGRAPHY........................................72 INDEX..............................................................73 Mockapetris [Page ii]
RFC 883 November 1983 Domain Names - Implementation and Specification INTRODUCTION Overview The goal of domain names is to provide a mechanism for naming resources in such a way that the names are usable in different hosts, networks, protocol families, internets, and administrative organizations. From the user's point of view, domain names are useful as arguments to a local agent, called a resolver, which retrieves information associated with the domain name. Thus a user might ask for the host address or mail information associated with a particular domain name. To enable the user to request a particular type of information, an appropriate query type is passed to the resolver with the domain name. To the user, the domain tree is a single information space. From the resolver's point of view, the database that makes up the domain space is distributed among various name servers. Different parts of the domain space are stored in different name servers, although a particular data item will usually be stored redundantly in two or more name servers. The resolver starts with knowledge of at least one name server. When the resolver processes a user query it asks a known name server for the information; in return, the resolver either receives the desired information or a referral to another name server. Using these referrals, resolvers learn the identities and contents of other name servers. Resolvers are responsible for dealing with the distribution of the domain space and dealing with the effects of name server failure by consulting redundant databases in other servers. Name servers manage two kinds of data. The first kind of data held in sets called zones; each zone is the complete database for a particular subtree of the domain space. This data is called authoritative. A name server periodically checks to make sure that its zones are up to date, and if not obtains a new copy of updated zones from master files stored locally or in another name server. The second kind of data is cached data which was acquired by a local resolver. This data may be incomplete but improves the performance of the retrieval process when non-local data is repeatedly accessed. Cached data is eventually discarded by a timeout mechanism. This functional structure isolates the problems of user interface, failure recovery, and distribution in the resolvers and isolates the database update and refresh problems in the name servers. Mockapetris [Page 1]
RFC 883 November 1983 Domain Names - Implementation and Specification Implementation components A host can participate in the domain name system in a number of ways, depending on whether the host runs programs that retrieve information from the domain system, name servers that answer queries from other hosts, or various combinations of both functions. The simplest, and perhaps most typical, configuration is shown below: Local Host | Foreign | +---------+ +----------+ | +--------+ | | user queries | |queries | | | | User |-------------->| |---------|->|Foreign | | Program | | Resolver | | | Name | | |<--------------| |<--------|--| Server | | | user responses| |responses| | | +---------+ +----------+ | +--------+ | A | cache additions | | references | V | | +----------+ | | database | | +----------+ | User programs interact with the domain name space through resolvers; the format of user queries and user responses is specific to the host and its operating system. User queries will typically be operating system calls, and the resolver and its database will be part of the host operating system. Less capable hosts may choose to implement the resolver as a subroutine to be linked in with every program that needs its services. Resolvers answer user queries with information they acquire via queries to foreign name servers, and may also cache or reference domain information in the local database. Note that the resolver may have to make several queries to several different foreign name servers to answer a particular user query, and hence the resolution of a user query may involve several network accesses and an arbitrary amount of time. The queries to foreign name servers and the corresponding responses have a standard format described in this memo, and may be datagrams. Mockapetris [Page 2]
RFC 883 November 1983 Domain Names - Implementation and Specification Depending on its capabilities, a name server could be a stand alone program on a dedicated machine or a process or processes on a large timeshared host. A simple configuration might be: Local Host | Foreign | +---------+ | / /| | +---------+ | +----------+ | +--------+ | | | | |responses| | | | | | | Name |---------|->|Foreign | | Master |-------------->| Server | | |Resolver| | files | | | |<--------|--| | | |/ | | queries | +--------+ +---------+ +----------+ | Here the name server acquires information about one or more zones by reading master files from its local file system, and answers queries about those zones that arrive from foreign resolvers. A more sophisticated name server might acquire zones from foreign name servers as well as local master files. This configuration is shown below: Local Host | Foreign | +---------+ | / /| | +---------+ | +----------+ | +--------+ | | | | |responses| | | | | | | Name |---------|->|Foreign | | Master |-------------->| Server | | |Resolver| | files | | | |<--------|--| | | |/ | | queries | +--------+ +---------+ +----------+ | A |maintenance | +--------+ | \------------|->| | | queries | |Foreign | | | | Name | \------------------|--| Server | maintenance responses | +--------+ In this configuration, the name server periodically establishes a virtual circuit to a foreign name server to acquire a copy of a zone or to check that an existing copy has not changed. The messages sent for these maintenance activities follow the same form as queries and responses, but the message sequences are somewhat different. Mockapetris [Page 3]
RFC 883 November 1983 Domain Names - Implementation and Specification The information flow in a host that supports all aspects of the domain name system is shown below: Local Host | Foreign | +---------+ +----------+ | +--------+ | | user queries | |queries | | | | User |-------------->| |---------|->|Foreign | | Program | | Resolver | | | Name | | |<--------------| |<--------|--| Server | | | user responses| |responses| | | +---------+ +----------+ | +--------+ | A | cache additions | | references | V | | +----------+ | | Shared | | | database | | +----------+ | A | | +---------+ refreshes | | references | / /| | V | +---------+ | +----------+ | +--------+ | | | | |responses| | | | | | | Name |---------|->|Foreign | | Master |-------------->| Server | | |Resolver| | files | | | |<--------|--| | | |/ | | queries | +--------+ +---------+ +----------+ | A |maintenance | +--------+ | \------------|->| | | queries | |Foreign | | | | Name | \------------------|--| Server | maintenance responses | +--------+ The shared database holds domain space data for the local name server and resolver. The contents of the shared database will typically be a mixture of authoritative data maintained by the periodic refresh operations of the name server and cached data from previous resolver requests. The structure of the domain data and the necessity for synchronization between name servers and resolvers imply the general characteristics of this database, but the actual format is up to the local implementer. This memo suggests a multiple tree format. Mockapetris [Page 4]
RFC 883 November 1983 Domain Names - Implementation and Specification This memo divides the implementation discussion into sections: NAME SERVER TRANSACTIONS, which discusses the formats for name servers queries and the corresponding responses. NAME SERVER MAINTENANCE, which discusses strategies, algorithms, and formats for maintaining the data residing in name servers. These services periodically refresh the local copies of zones that originate in other hosts. RESOLVER ALGORITHMS, which discusses the internal structure of resolvers. This section also discusses data base sharing between a name server and a resolver on the same host. DOMAIN SUPPORT FOR MAIL, which discusses the use of the domain system to support mail transfer. Mockapetris [Page 5]
RFC 883 November 1983 Domain Names - Implementation and Specification Conventions The domain system has several conventions dealing with low-level, but fundamental, issues. While the implementer is free to violate these conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in ALL behavior observed from other hosts. ********** Data Transmission Order ********** The order of transmission of the header and data described in this document is resolved to the octet level. Whenever a diagram shows a group of octets, the order of transmission of those octets is the normal order in which they are read in English. For example, in the following diagram the octets are transmitted in the order they are numbered. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Transmission Order of Bytes Whenever an octet represents a numeric quantity the left most bit in the diagram is the high order or most significant bit. That is, the bit labeled 0 is the most significant bit. For example, the following diagram represents the value 170 (decimal). 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |1 0 1 0 1 0 1 0| +-+-+-+-+-+-+-+-+ Significance of Bits Similarly, whenever a multi-octet field represents a numeric quantity the left most bit of the whole field is the most significant bit. When a multi-octet quantity is transmitted the most significant octet is transmitted first. Mockapetris [Page 6]
RFC 883 November 1983 Domain Names - Implementation and Specification ********** Character Case ********** All comparisons between character strings (e.g. labels, domain names, etc.) are done in a case-insensitive manner. When data enters the domain system, its original case should be preserved whenever possible. In certain circumstances this cannot be done. For example, if two domain names x.y and X.Y are entered into the domain database, they are interpreted as the same name, and hence may have a single representation. The basic rule is that case can be discarded only when data is used to define structure in a database, and two names are identical when compared in a case insensitive manner. Loss of case sensitive data must be minimized. Thus while data for x.y and X.Y may both be stored under x.y, data for a.x and B.X can be stored as a.x and B.x, but not A.x, A.X, b.x, or b.X. In general, this prevents the first component of a domain name from loss of case information. Systems administrators who enter data into the domain database should take care to represent the data they supply to the domain system in a case-consistent manner if their system is case-sensitive. The data distribution system in the domain system will ensure that consistent representations are preserved. Mockapetris [Page 7]
RFC 883 November 1983 Domain Names - Implementation and Specification Design philosophy The design presented in this memo attempts to provide a base which will be suitable for several existing networks. An equally important goal is to provide these services within a framework that is capable of adjustment to fit the evolution of services in early clients as well as to accommodate new networks. Since it is impossible to predict the course of these developments, the domain system attempts to provide for evolution in the form of an extensible framework. This section describes the areas in which we expect to see immediate evolution. DEFINING THE DATABASE This memo defines methods for partitioning the database and data for host names, host addresses, gateway information, and mail support. Experience with this system will provide guidance for future additions. While the present system allows for many new RR types, classes, etc., we feel that it is more important to get the basic services in operation than to cover an exhaustive set of information. Hence we have limited the data types to those we felt were essential, and would caution designers to avoid implementations which are based on the number of existing types and classes. Extensibility in this area is very important. While the domain system provides techniques for partitioning the database, policies for administrating the orderly connection of separate domains and guidelines for constructing the data that makes up a particular domain will be equally important to the success of the system. Unfortunately, we feel that experience with prototype systems will be necessary before this question can be properly addressed. Thus while this memo has minimal discussion of these issues, it is a critical area for development. TYING TOGETHER INTERNETS Although it is very difficult to characterize the types of networks, protocols, and applications that will be clients of the domain system, it is very obvious that some of these applications will cross the boundaries of network and protocol. At the very least, mail is such a service. Attempts to unify two such systems must deal with two major problems: 1. Differing formats for environment sensitive data. For example, Mockapetris [Page 8]
RFC 883 November 1983 Domain Names - Implementation and Specification network addresses vary in format, and it is unreasonable to expect to enforce consistent conventions. 2. Connectivity may require intermediaries. For example, it is a frequent occurence that mail is sent between hosts that share no common protocol. The domain system acknowledges that these are very difficult problems, and attempts to deal with both problems through its CLASS mechanism: 1. The CLASS field in RRs allows data to be tagged so that all programs in the domain system can identify the format in use. 2. The CLASS field allows the requestor to identify the format of data which can be understood by the requestor. 3. The CLASS field guides the search for the requested data. The last point is central to our approach. When a query crosses protocol boundaries, it must be guided though agents capable of performing whatever translation is required. For example, when a mailer wants to identify the location of a mailbox in a portion of the domain system that doesn't have a compatible protocol, the query must be guided to a name server that can cross the boundary itself or form one link in a chain that can span the differences. If query and response transport were the only problem, then this sort of problem could be dealt with in the name servers themselves. However, the applications that will use domain service have similar problems. For example, mail may need to be directed through mail gateways, and the characteristics of one of the environments may not permit frequent connectivity between name servers in all environments. These problems suggest that connectivity will be achieved through a variety of measures: Translation name servers that act as relays between different protocols. Translation application servers that translate application level transactions. Default database entries that route traffic through application level forwarders in ways that depend on the class of the requestor. While this approach seems best given our current understanding of Mockapetris [Page 9]
RFC 883 November 1983 Domain Names - Implementation and Specification the problem, we realize that the approach of using resource data that transcends class may be appropriate in future designs or applications. By not defining class to be directly related to protocol, network, etc., we feel that such services could be added by defining a new "universal" class, while the present use of class will provide immediate service. This problem requires more thought and experience before solutions can be discovered. The concepts of CLASS, recursive servers and other mechanisms are intended as tools for acquiring experience and not as final solutions. Mockapetris [Page 10]
RFC 883 November 1983 Domain Names - Implementation and Specification NAME SERVER TRANSACTIONS Introduction The primary purpose of name servers is to receive queries from resolvers and return responses. The overall model of this service is that a program (typically a resolver) asks the name server questions (queries) and gets responses that either answer the question or refer the questioner to another name server. Other functions related to name server database maintenance use similar procedures and formats and are discussed in a section later in this memo. There are three kinds of queries presently defined: 1. Standard queries that ask for a specified resource attached to a given domain name. 2. Inverse queries that specify a resource and ask for a domain name that possesses that resource. 3. Completion queries that specify a partial domain name and a target domain and ask that the partial domain name be completed with a domain name close to the target domain. This memo uses an unqualified reference to queries to refer to either all queries or standard queries when the context is clear. Query and response transport Name servers and resolvers use a single message format for all communications. The message format consists of a variable-length octet string which includes binary values. The messages used in the domain system are designed so that they can be carried using either datagrams or virtual circuits. To accommodate the datagram style, all responses carry the query as part of the response. While the specification allows datagrams to be used in any context, some activities are ill suited to datagram use. For example, maintenance transactions and recursive queries typically require the error control of virtual circuits. Thus datagram use should be restricted to simple queries. The domain system assumes that a datagram service provides: 1. A non-reliable (i.e. best effort) method of transporting a message of up to 512 octets. Mockapetris [Page 11]
RFC 883 November 1983 Domain Names - Implementation and Specification Hence datagram messages are limited to 512 octets. If a datagram message would exceed 512 octets, it is truncated and a truncation flag is set in its header. 2. A message size that gives the number of octets in the datagram. The main implications for programs accessing name servers via datagrams are: 1. Datagrams should not be used for maintenance transactions and recursive queries. 2. Since datagrams may be lost, the originator of a query must perform error recovery (such as retransmissions) as appropriate. 3. Since network or host delay may cause retransmission when a datagram has not been lost, the originator of a query must be ready to deal with duplicate responses. The domain system assumes that a virtual circuit service provides: 1. A reliable method of transmitting a message of up to 65535 octets. 2. A message size that gives the number of octets in the message. If the virtual circuit service does not provide for message boundary detection or limits transmission size to less than 65535 octets, then messages are prefaced with an unsigned 16 bit length field and broken up into separate transmissions as required. The length field is only prefaced on the first message. This technique is used for TCP virtual circuits. 3. Multiple messages may be sent over a virtual circuit. 4. A method for closing a virtual circuit. 5. A method for detecting that the other party has requested that the virtual circuit be closed. The main implications for programs accessing name servers via virtual circuits are: 1. Either end of a virtual circuit may initiate a close when there is no activity in progress. The other end should comply. Mockapetris [Page 12]
RFC 883 November 1983 Domain Names - Implementation and Specification The decision to initiate a close is a matter of individual site policy; some name servers may leave a virtual circuit open for an indeterminate period following a query to allow for subsequent queries; other name servers may choose to initiate a close following the completion of the first query on a virtual circuit. Of course, name servers should not close the virtual circuit in the midst of a multiple message stream used for zone transfer. 2. Since network delay may cause one end to erroneously believe that no activity is in progress, a program which receives a virtual circuit close while a query is in progress should close the virtual circuit and resubmit the query on a new virtual circuit. All messages may use a compression scheme to reduce the space consumed by repetitive domain names. The use of the compression scheme is optional for the sender of a message, but all receivers must be capable of decoding compressed domain names. Overall message format All messages sent by the domain system are divided into 5 sections (some of which are empty in certain cases) shown below: +---------------------+ | Header | +---------------------+ | Question | the question for the name server +---------------------+ | Answer | answering resource records (RRs) +---------------------+ | Authority | RRs pointing toward an authority +---------------------+ | Additional | RRs holding pertinent information +---------------------+ The header section is always present. The header includes fields that specify which of the remaining sections are present, and also specify whether the message is a query, inverse query, completion query, or response. The question section contains fields that describe a question to a name server. These fields are a query type (QTYPE), a query class (QCLASS), and a query domain name (QNAME). The last three sections have the same format: a possibly empty list of concatenated resource records (RRs). The answer section contains RRs that answer the question; the authority section Mockapetris [Page 13]
RFC 883 November 1983 Domain Names - Implementation and Specification contains RRs that point toward an authoritative name server; the additional records section contains RRs which relate to the query, but are not strictly answers for the question. The next two sections of this memo illustrate the use of these message sections through examples; a detailed discussion of data formats follows the examples. Mockapetris [Page 14]
RFC 883 November 1983 Domain Names - Implementation and Specification The contents of standard queries and responses When a name server processes a standard query, it first determines whether it is an authority for the domain name specified in the query. If the name server is an authority, it returns either: 1. the specified resource information 2. an indication that the specified name does not exist 3. an indication that the requested resource information does not exist If the name server is not an authority for the specified name, it returns whatever relevant resource information it has along with resource records that the requesting resolver can use to locate an authoritative name server. Standard query and response example The overall structure of a query for retrieving information for Internet mail for domain F.ISI.ARPA is shown below: +-----------------------------------------+ Header | OPCODE=QUERY, ID=2304 | +-----------------------------------------+ Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA | +-----------------------------------------+ Answer | <empty> | +-----------------------------------------+ Authority | <empty> | +-----------------------------------------+ Additional | <empty> | +-----------------------------------------+ The header includes an opcode field that specifies that this datagram is a query, and an ID field that will be used to associate replies with the original query. (Some additional header fields have been omitted for clarity.) The question section specifies that the type of the query is for mail agent information, that only ARPA Internet information is to be considered, and that the domain name of interest is F.ISI.ARPA. The remaining sections are empty, and would not use any octets in a real query. Mockapetris [Page 15]
RFC 883 November 1983 Domain Names - Implementation and Specification One possible response to this query might be: +-----------------------------------------+ Header | OPCODE=RESPONSE, ID=2304 | +-----------------------------------------+ Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA | +-----------------------------------------+ Answer | <empty> | +-----------------------------------------+ Authority | ARPA NS IN A.ISI.ARPA | | ------- | | ARPA NS IN F.ISI.ARPA | +-----------------------------------------+ Additional | F.ISI.ARPA A IN 10.2.0.52 | | ------- | | A.ISI.ARPA A IN 10.1.0.22 | +-----------------------------------------+ This type of response would be returned by a name server that was not an authority for the domain name F.ISI.ARPA. The header field specifies that the datagram is a response to a query with an ID of 2304. The question section is copied from the question section in the query datagram. The answer section is empty because the name server did not have any information that would answer the query. (Name servers may happen to have cached information even if they are not authoritative for the query.) The best that this name server could do was to pass back information for the domain ARPA. The authority section specifies two name servers for the domain ARPA using the Internet family: A.ISI.ARPA and F.ISI.ARPA. Note that it is merely a coincidence that F.ISI.ARPA is a name server for ARPA as well as the subject of the query. In this case, the name server included in the additional records section the Internet addresses for the two hosts specified in the authority section. Such additional data is almost always available. Given this response, the process that originally sent the query might resend the query to the name server on A.ISI.ARPA, with a new ID of 2305. Mockapetris [Page 16]
RFC 883 November 1983 Domain Names - Implementation and Specification The name server on A.ISI.ARPA might return a response: +-----------------------------------------+ Header | OPCODE=RESPONSE, ID=2305 | +-----------------------------------------+ Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA | +-----------------------------------------+ Answer | F.ISI.ARPA MD IN F.ISI.ARPA | | ------- | | F.ISI.ARPA MF IN A.ISI.ARPA | +-----------------------------------------+ Authority | <empty> | +-----------------------------------------+ Additional | F.ISI.ARPA A IN 10.2.0.52 | | ------- | | A.ISI.ARPA A IN 10.1.0.22 | +-----------------------------------------+ This query was directed to an authoritative name server, and hence the response includes an answer but no authority records. In this case, the answer section specifies that mail for F.ISI.ARPA can either be delivered to F.ISI.ARPA or forwarded to A.ISI.ARPA. The additional records section specifies the Internet addresses of these hosts. The contents of inverse queries and responses Inverse queries reverse the mappings performed by standard query operations; while a standard query maps a domain name to a resource, an inverse query maps a resource to a domain name. For example, a standard query might bind a domain name to a host address; the corresponding inverse query binds the host address to a domain name. Inverse query mappings are not guaranteed to be unique or complete because the domain system does not have any internal mechanism for determining authority from resource records that parallels the capability for determining authority as a function of domain name. In general, resolvers will be configured to direct inverse queries to a name server which is known to have the desired information. Name servers are not required to support any form of inverse queries; it is anticipated that most name servers will support address to domain name conversions, but no other inverse mappings. If a name server receives an inverse query that it does not support, it returns an error response with the "Not Implemented" error set in the header. While inverse query support is optional, all name servers must be at least able to return the error response. Mockapetris [Page 17]
RFC 883 November 1983 Domain Names - Implementation and Specification When a name server processes an inverse query, it either returns: 1. zero, one, or multiple domain names for the specified resource 2. an error code indicating that the name server doesn't support inverse mapping of the specified resource type. Inverse query and response example The overall structure of an inverse query for retrieving the domain name that corresponds to Internet address 10.2.0.52 is shown below: +-----------------------------------------+ Header | OPCODE=IQUERY, ID=997 | +-----------------------------------------+ Question | <empty> | +-----------------------------------------+ Answer | <anyname> A IN 10.2.0.52 | +-----------------------------------------+ Authority | <empty> | +-----------------------------------------+ Additional | <empty> | +-----------------------------------------+ This query asks for a question whose answer is the Internet style address 10.2.0.52. Since the owner name is not known, any domain name can be used as a placeholder (and is ignored). The response to this query might be: +-----------------------------------------+ Header | OPCODE=RESPONSE, ID=997 | +-----------------------------------------+ Question | QTYPE=A, QCLASS=IN, QNAME=F.ISI.ARPA | +-----------------------------------------+ Answer | F.ISI.ARPA A IN 10.2.0.52 | +-----------------------------------------+ Authority | <empty> | +-----------------------------------------+ Additional | <empty> | +-----------------------------------------+ Note that the QTYPE in a response to an inverse query is the same as the TYPE field in the answer section of the inverse query. Responses to inverse queries may contain multiple questions when the inverse is not unique. Mockapetris [Page 18]
RFC 883 November 1983 Domain Names - Implementation and Specification Completion queries and responses Completion queries ask a name server to complete a partial domain name and return a set of RRs whose domain names meet a specified set of criteria for "closeness" to the partial input. This type of query can provide a local shorthand for domain names or command completion similar to that in TOPS-20. Implementation of completion query processing is optional in a name server. However, a name server must return a "Not Implemented" (NI) error response if it does not support completion. The arguments in a completion query specify: 1. A type in QTYPE that specifies the type of the desired name. The type is used to restrict the type of RRs which will match the partial input so that completion queries can be used for mailbox names, host names, or any other type of RR in the domain system without concern for matches to the wrong type of resource. 2. A class in QCLASS which specifies the desired class of the RR. 3. A partial domain name that gives the input to be completed. All returned RRs will begin with the partial string. The search process first looks for names which qualify under the assumption that the partial string ends with a full label ("whole label match"); if this search fails, the search continues under the assumption that the last label in the partial sting may be an incomplete label ("partial label match"). For example, if the partial string "Smith" was used in a mailbox completion, it would match [email protected] in preference to [email protected]. The partial name is supplied by the user through the user program that is using domain services. For example, if the user program is a mail handler, the string might be "Mockap" which the user intends as a shorthand for the mailbox [email protected]; if the user program is TELNET, the user might specify "F" for F.ISI.ARPA. In order to make parsing of messages consistent, the partial name is supplied in domain name format (i.e. a sequence of labels terminated with a zero length octet). However, the trailing root label is ignored during matching. 4. A target domain name which specifies the domain which is to be examined for matches. This name is specified in the additional Mockapetris [Page 19]
RFC 883 November 1983 Domain Names - Implementation and Specification section using a NULL RR. All returned names will end with the target name. The user program which constructs the query uses the target name to restrict the search. For example, user programs running at ISI might restrict completion to names that end in ISI.ARPA; user programs running at MIT might restrict completion to the domain MIT.ARPA. The target domain name is also used by the resolver to determine the name server which should be used to process the query. In general, queries should be directed to a name server that is authoritative for the target domain name. User programs which wish to provide completion for a more than one target can issue multiple completion queries, each directed at a different target. Selection of the target name and the number of searches will depend on the goals of the user program. 5. An opcode for the query. The two types of completion queries are "Completion Query - Multiple", or CQUERYM, which asks for all RRs which could complete the specified input, and "Completion Query - Unique", or CQUERYU, which asks for the "best" completion. CQUERYM is used by user programs which want to know if ambiguities exist or wants to do its own determinations as to the best choice of the available candidates. CQUERYU is used by user programs which either do not wish to deal with multiple choices or are willing to use the closeness criteria used by CQUERYU to select the best match. When a name server receives either completion query, it first looks for RRs that begin (on the left) with the same labels as are found in QNAME (with the root deleted), and which match the QTYPE and QCLASS. This search is called "whole label" matching. If one or more hits are found the name server either returns all of the hits (CQUERYM) or uses the closeness criteria described below to eliminate all but one of the matches (CQUERYU). If the whole label match fails to find any candidates, then the name server assumes that the rightmost label of QNAME (after root deletion) is not a complete label, and looks for candidates that would match if characters were added (on the right) to the rightmost label of QNAME. If one or more hits are found the name server either returns all of the hits (CQUERYM) or uses the closeness criteria described below to eliminate all but one of the matches (CQUERYU). Mockapetris [Page 20]
RFC 883 November 1983 Domain Names - Implementation and Specification If a CQUERYU query encounters multiple hits, it uses the following sequence of rules to discard multiple hits: 1. Discard candidates that have more labels than others. Since all candidates start with the partial name and end with the target name, this means that we select those entries that require the fewest number of added labels. For example, a host search with a target of "ISI.ARPA" and a partial name of "A" will select A.ISI.ARPA in preference to A.IBM-PCS.ISI.ARPA. 2. If partial label matching was used, discard those labels which required more characters to be added. For example, a mailbox search for partial "X" and target "ISI.ARPA" would prefer [email protected] to [email protected]. If multiple hits are still present, return all hits. Completion query mappings are not guaranteed to be unique or complete because the domain system does not have any internal mechanism for determining authority from a partial domain name that parallels the capability for determining authority as a function of a complete domain name. In general, resolvers will be configured to direct completion queries to a name server which is known to have the desired information. When a name server processes a completion query, it either returns: 1. An answer giving zero, one, or more possible completions. 2. an error response with Not Implemented (NI) set. Mockapetris [Page 21]
RFC 883 November 1983 Domain Names - Implementation and Specification Completion query and response example Suppose that the completion service was used by a TELNET program to allow a user to specify a partial domain name for the desired host. Thus a user might ask to be connected to "B". Assuming that the query originated from an ISI machine, the query might look like: +-----------------------------------------+ Header | OPCODE=CQUERYU, ID=409 | +-----------------------------------------+ Question | QTYPE=A, QCLASS=IN, QNAME=B | +-----------------------------------------+ Answer | <empty> | +-----------------------------------------+ Authority | <empty> | +-----------------------------------------+ Additional | ISI.ARPA NULL IN | +-----------------------------------------+ The partial name in the query is "B", the mappings of interest are ARPA Internet address records, and the target domain is ISI.ARPA. Note that NULL is a special type of NULL resource record that is used as a placeholder and has no significance; NULL RRs obey the standard format but have no other function. The response to this completion query might be: +-----------------------------------------+ Header | OPCODE=RESPONSE, ID=409 | +-----------------------------------------+ Question | QTYPE=A, QCLASS=IN, QNAME=B | +-----------------------------------------+ Answer | B.ISI.ARPA A IN 10.3.0.52 | +-----------------------------------------+ Authority | <empty> | +-----------------------------------------+ Additional | ISI.ARPA NULL IN | +-----------------------------------------+ This response has completed B to mean B.ISI.ARPA. Mockapetris [Page 22]
RFC 883 November 1983 Domain Names - Implementation and Specification Another query might be: +-----------------------------------------+ Header | OPCODE=CQUERYM, ID=410 | +-----------------------------------------+ Question | QTYPE=A, QCLASS=IN, QNAME=B | +-----------------------------------------+ Answer | <empty> | +-----------------------------------------+ Authority | <empty> | +-----------------------------------------+ Additional | ARPA NULL IN | +-----------------------------------------+ This query is similar to the previous one, but specifies a target of ARPA rather than ISI.ARPA. It also allows multiple matches. In this case the same name server might return: +-----------------------------------------+ Header | OPCODE=RESPONSE, ID=410 | +-----------------------------------------+ Question | QTYPE=A, QCLASS=IN, QNAME=B | +-----------------------------------------+ Answer | B.ISI.ARPA A IN 10.3.0.52 | | - | | B.BBN.ARPA A IN 10.0.0.49 | | - | | B.BBNCC.ARPA A IN 8.1.0.2 | +-----------------------------------------+ Authority | <empty> | +-----------------------------------------+ Additional | ARPA NULL IN | +-----------------------------------------+ This response contains three answers, B.ISI.ARPA, B.BBN.ARPA, and B.BBNCC.ARPA. Mockapetris [Page 23]
RFC 883 November 1983 Domain Names - Implementation and Specification Recursive Name Service Recursive service is an optional feature of name servers. When a name server receives a query regarding a part of the name space which is not in one of the name server's zones, the standard response is a message that refers the requestor to another name server. By iterating on these referrals, the requestor eventually is directed to a name server that has the required information. Name servers may also implement recursive service. In this type of service, a name server either answers immediately based on local zone information, or pursues the query for the requestor and returns the eventual result back to the original requestor. A name server that supports recursive service sets the Recursion Available (RA) bit in all responses it generates. A requestor asks for recursive service by setting the Recursion Desired (RD) bit in queries. In some situations where recursive service is the only path to the desired information (see below), the name server may go recursive even if RD is zero. If a query requests recursion (RD set), but the name server does not support recursion, and the query needs recursive service for an answer, the name server returns a "Not Implemented" (NI) error code. If the query can be answered without recursion since the name server is authoritative for the query, it ignores the RD bit. Because of the difficulty in selecting appropriate timeouts and error handling, recursive service is best suited to virtual circuits, although it is allowed for datagrams. Recursive service is valuable in several special situations: In a system of small personal computers clustered around one or more large hosts supporting name servers, the recursive approach minimizes the amount of code in the resolvers in the personal computers. Such a design moves complexity out of the resolver into the name server, and may be appropriate for such systems. Name servers on the boundaries of different networks may wish to offer recursive service to create connectivity between different networks. Such name servers may wish to provide recursive service regardless of the setting of RD. Name servers that translate between domain name service and some other name service may wish to adopt the recursive style. Implicit recursion may be valuable here as well. Mockapetris [Page 24]
RFC 883 November 1983 Domain Names - Implementation and Specification These concepts are still under development. Mockapetris [Page 25]
RFC 883 November 1983 Domain Names - Implementation and Specification Header section format +-----------------------------------------------+ | | | ***** WARNING ***** | | | | The following format is preliminary and is | | included for purposes of explanation only. In | | particular, the size and position of the | | OPCODE, RCODE fields and the number and | | meaning of the single bit fields are subject | | to change. | | | +-----------------------------------------------+ The header contains the following fields: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA| | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: ID - A 16 bit identifier assigned by the program that generates any kind of query. This identifier is copied into all replies and can be used by the requestor to relate replies to outstanding questions. QR - A one bit field that specifies whether this message is a query (0), or a response (1). OPCODE - A four bit field that specifies kind of query in this message. This value is set by the originator of a query and copied into the response. The values are: 0 a standard query (QUERY) Mockapetris [Page 26]
RFC 883 November 1983 Domain Names - Implementation and Specification 1 an inverse query (IQUERY) 2 an completion query allowing multiple answers (CQUERYM) 2 an completion query requesting a single answer (CQUERYU) 4-15 reserved for future use AA - Authoritative Answer - this bit is valid in responses, and specifies that the responding name server is an authority for the domain name in the corresponding query. TC - TrunCation - specifies that this message was truncated due to length greater than 512 characters. This bit is valid in datagram messages but not in messages sent over virtual circuits. RD - Recursion Desired - this bit may be set in a query and is copied into the response. If RD is set, it directs the name server to pursue the query recursively. Recursive query support is optional. RA - Recursion Available - this be is set or cleared in a response, and denotes whether recursive query support is available in the name server. RCODE - Response code - this 4 bit field is set as part of responses. The values have the following interpretation: 0 No error condition 1 Format error - The name server was unable to interpret the query. 2 Server failure - The name server was unable to process this query due to a problem with the name server. 3 Name Error - Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced in the query does not exist. Mockapetris [Page 27]
RFC 883 November 1983 Domain Names - Implementation and Specification 4 Not Implemented - The name server does not support the requested kind of query. 5 Refused - The name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requestor, or a name server may not wish to perform a particular operation (e.g. zone transfer) for particular data. 6-15 Reserved for future use. QDCOUNT - an unsigned 16 bit integer specifying the number of entries in the question section. ANCOUNT - an unsigned 16 bit integer specifying the number of resource records in the answer section. NSCOUNT - an unsigned 16 bit integer specifying the number of name server resource records in the authority records section. ARCOUNT - an unsigned 16 bit integer specifying the number of resource records in the additional records section. Mockapetris [Page 28]
RFC 883 November 1983 Domain Names - Implementation and Specification Question section format The question section is used in all kinds of queries other than inverse queries. In responses to inverse queries, this section may contain multiple entries; for all other responses it contains a single entry. Each entry has the following format: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / QNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QTYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QCLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: QNAME - a variable number of octets that specify a domain name. This field uses the compressed domain name format described in the next section of this memo. This field can be used to derive a text string for the domain name. Note that this field may be an odd number of octets; no padding is used. QTYPE - a two octet code which specifies the type of the query. The values for this field include all codes valid for a TYPE field, together with some more general codes which can match more than one type of RR. For example, QTYPE might be A and only match type A RRs, or might be MAILA, which matches MF and MD type RRs. The values for this field are listed in Appendix 2. QCLASS - a two octet code that specifies the class of the query. For example, the QCLASS field is IN for the ARPA Internet, CS for the CSNET, etc. The numerical values are defined in Appendix 2. Mockapetris [Page 29]
RFC 883 November 1983 Domain Names - Implementation and Specification Resource record format The answer, authority, and additional sections all share the same format: a variable number of resource records, where the number of records is specified in the corresponding count field in the header. Each resource record has the following format: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: NAME - a compressed domain name to which this resource record pertains. TYPE - two octets containing one of the RR type codes defined in Appendix 2. This field specifies the meaning of the data in the RDATA field. CLASS - two octets which specify the class of the data in the RDATA field. TTL - a 16 bit unsigned integer that specifies the time interval (in seconds) that the resource record may be cached before it should be discarded. Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be cached. For example, SOA records are always distributed with a zero TTL to prohibit caching. Zero values can also be used for extremely volatile data. Mockapetris [Page 30]
RFC 883 November 1983 Domain Names - Implementation and Specification RDLENGTH- an unsigned 16 bit integer that specifies the length in octets of the RDATA field. RDATA - a variable length string of octets that describes the resource. The format of this information varies according to the TYPE and CLASS of the resource record. For example, the if the TYPE is A and the CLASS is IN, the RDATA field is a 4 octet ARPA Internet address. Formats for particular resource records are shown in Appendicies 2 and 3. Domain name representation and compression Domain names messages are expressed in terms of a sequence of labels. Each label is represented as a one octet length field followed by that number of octets. Since every domain name ends with the null label of the root, a compressed domain name is terminated by a length byte of zero. The high order two bits of the length field must be zero, and the remaining six bits of the length field limit the label to 63 octets or less. To simplify implementations, the total length of label octets and label length octets that make up a domain name is restricted to 255 octets or less. Since the trailing root label and its dot are not printed, printed domain names are 254 octets or less. Although labels can contain any 8 bit values in octets that make up a label, it is strongly recommended that labels follow the syntax described in Appendix 1 of this memo, which is compatible with existing host naming conventions. Name servers and resolvers must compare labels in a case-insensitive manner, i.e. A=a, and hence all character strings must be ASCII with zero parity. Non-alphabetic codes must match exactly. Whenever possible, name servers and resolvers must preserve all 8 bits of domain names they process. When a name server is given data for the same name under two different case usages, this preservation is not always possible. For example, if a name server is given data for ISI.ARPA and isi.arpa, it should create a single node, not two, and hence will preserve a single casing of the label. Systems with case sensitivity should take special precautions to insure that the domain data for the system is created with consistent case. In order to reduce the amount of space used by repetitive domain names, the sequence of octets that defines a domain name may be terminated by a pointer to the length octet of a previously specified label string. The label string that the pointer Mockapetris [Page 31]
RFC 883 November 1983 Domain Names - Implementation and Specification specifies is appended to the already specified label string. Exact duplication of a previous label string can be done with a single pointer. Multiple levels are allowed. Pointers can only be used in positions in the message where the format is not class specific. If this were not the case, a name server that was handling a RR for another class could make erroneous copies of RRs. As yet, there are no such cases, but they may occur in future RDATA formats. If a domain name is contained in a part of the message subject to a length field (such as the RDATA section of an RR), and compression is used, the length of the compressed name is used in the length calculation, rather than the length of the expanded name. Pointers are represented as a two octet field in which the high order 2 bits are ones, and the low order 14 bits specify an offset from the start of the message. The 01 and 10 values of the high order bits are reserved for future use and should not be used. Programs are free to avoid using pointers in datagrams they generate, although this will reduce datagram capacity. However all programs are required to understand arriving messages that contain pointers. For example, a datagram might need to use the domain names F.ISI.ARPA, FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the other fields of the message, these domain names might be represented as: Mockapetris [Page 32]
RFC 883 November 1983 Domain Names - Implementation and Specification +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 20 | 1 | F | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 22 | 3 | I | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 24 | S | I | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 26 | 4 | A | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 28 | R | P | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 30 | A | 0 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 40 | 3 | F | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 42 | O | O | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 44 | 1 1| 20 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 64 | 1 1| 26 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 92 | 0 | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ The domain name for F.ISI.ARPA is shown at offset 20. The domain name FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to concatenate a label for FOO to the previously defined F.ISI.ARPA. The domain name ARPA is defined at offset 64 using a pointer to the ARPA component of the name F.ISI.ARPA at 20; note that this reference relies on ARPA being the last label in the string at 20. The root domain name is defined by a single octet of zeros at 92; the root domain name has no labels. Organization of the Shared database While name server implementations are free to use any internal data structures they choose, the suggested structure consists of several separate trees. Each tree has structure corresponding to the domain name space, with RRs attached to nodes and leaves. Each zone of authoritative data has a separate tree, and one tree holds all non-authoritative data. All of the trees corresponding to zones are managed identically, but the non-authoritative or cache tree has different management procedures. Mockapetris [Page 33]
RFC 883 November 1983 Domain Names - Implementation and Specification Data stored in the database can be kept in whatever form is convenient for the name server, so long as it can be transformed back into the format needed for messages. In particular, the database will probably use structure in place of expanded domain names, and will also convert many of the time intervals used in the domain systems to absolute local times. Each tree corresponding to a zone has complete information for a "pruned" subtree of the domain space. The top node of a zone has a SOA record that marks the start of the zone. The bottom edge of the zone is delimited by nodes containing NS records signifying delegation of authority to other zones, or by leaves of the domain tree. When a name server contains abutting zones, one tree will have a bottom node containing a NS record, and the other tree will begin with a tree location containing a SOA record. Note that there is one special case that requires consideration when a name server is implemented. A node that contains a SOA RR denoting a start of zone will also have NS records that identify the name servers that are expected to have a copy of the zone. Thus a name server will usually find itself (and possibly other redundant name servers) referred to in NS records occupying the same position in the tree as SOA records. The solution to this problem is to never interpret a NS record as delimiting a zone started by a SOA at the same point in the tree. (The sample programs in this memo deal with this problem by processing SOA records only after NS records have been processed.) Zones may also overlap a particular part of the name space when they are of different classes. Other than the abutting and separate class cases, trees are always expected to be disjoint. Overlapping zones are regarded as a non-fatal error. The scheme described in this memo avoids the overlap issue by maintaining separate trees; other designs must take the appropriate measures to defend against possible overlap. Non-authoritative data is maintained in a separate tree. This tree is unlike the zone trees in that it may have "holes". Each RR in the cache tree has its own TTL that is separately managed. The data in this tree is never used if authoritative data is available from a zone tree; this avoids potential problems due to cached data that conflicts with authoritative data. The shared database will also contain data structures to support the processing of inverse queries and completion queries if the local system supports these optional features. Although many schemes are possible, this memo describes a scheme that is based on tables of pointers that invert the database according to key. Mockapetris [Page 34]
RFC 883 November 1983 Domain Names - Implementation and Specification Each kind of retrieval has a separate set of tables, with one table per zone. When a zone is updated, these tables must also be updated. The contents of these tables are discussed in the "Inverse query processing" and "Completion query processing" sections of this memo. The database implementation described here includes two locks that are used to control concurrent access and modification of the database by name server query processing, name server maintenance operations, and resolver access: The first lock ("main lock") controls access to all of the trees. Multiple concurrent reads are allowed, but write access can only be acquired by a single process. Read and write access are mutually exclusive. Resolvers and name server processes that answer queries acquire this lock in read mode, and unlock upon completion of the current message. This lock is acquired in write mode by a name server maintenance process when it is about to change data in the shared database. The actual update procedures are described under "NAME SERVER MAINTENANCE" but are designed to be brief. The second lock ("cache queue lock") controls access to the cache queue. This queue is used by a resolver that wishes to add information to the cache tree. The resolver acquires this lock, then places the RRs to be cached into the queue. The name server maintenance procedure periodically acquires this lock and adds the queue information to the cache. The rationale for this procedure is that it allows the resolver to operate with read-only access to the shared database, and allows the update process to batch cache additions and the associated costs for inversion calculations. The name server maintenance procedure must take appropriate precautions to avoid problems with data already in the cache, inversions, etc. This organization solves several difficulties: When searching the domain space for the answer to a query, a name server can restrict its search for authoritative data to that tree that matches the most labels on the right side of the domain name of interest. Since updates to a zone must be atomic with respect to searches, maintenance operations can simply acquire the main lock, insert a new copy of a particular zone without disturbing other zones, and then release the storage used by the old copy. Assuming a central table pointing to valid zone trees, this operation can be a simple pointer swap. Mockapetris [Page 35]
RFC 883 November 1983 Domain Names - Implementation and Specification TTL management of zones can be performed using the SOA record for the zone. This avoids potential difficulties if individual RRs in a zone could be timed out separately. This issue is discussed further in the maintenance section. Query processing The following algorithm outlines processing that takes place at a name server when a query arrives: 1. Search the list of zones to find zones which have the same class as the QCLASS field in the query and have a top domain name that matches the right end of the QNAME field. If there are none, go to step 2. If there are more than one, pick the zone that has the longest match and go to step 3. 2. Since the zone search failed, the only possible RRs are contained in the non-authoritative tree. Search the cache tree for the NS record that has the same class as the QCLASS field and the largest right end match for domain name. Add the NS record or records to the authority section of the response. If the cache tree has RRs that are pertinent to the question (domain names match, classes agree, not timed-out, and the type field is relevant to the QTYPE), copy these RRs into the answer section of the response. The name server may also search the cache queue. Go to step 4. 3. Since this zone is the best match, the zone in which QNAME resides is either this zone or a zone to which this zone will directly or indirectly delegate authority. Search down the tree looking for a NS RR or the node specified by QNAME. If the node exists and has no NS record, copy the relevant RRs to the answer section of the response and go to step 4. If a NS RR is found, either matching a part or all of QNAME, then QNAME is in a delegated zone outside of this zone. If so, copy the NS record or records into the authority section of the response, and search the remainder of the zone for an A type record corresponding to the NS reference. If the A record is found, add it to the additional section. Go to step 2. If the node is not found and a NS is not found, there is no such name; set the Name error bit in the response and exit. 4. When this step is reached, the answer and authority sections are complete. What remains is to complete the additional section. This procedure is only possible if the name server Mockapetris [Page 36]
RFC 883 November 1983 Domain Names - Implementation and Specification knows the data formats implied by the class of records in the answer and authority sections. Hence this procedure is class dependent. Appendix 3 discusses this procedure for Internet class data. While this algorithm deals with typical queries and databases, several additions are required that will depend on the database supported by the name server: QCLASS=* Special procedures are required when the QCLASS of the query is "*". If the database contains several classes of data, the query processing steps above are performed separately for each CLASS, and the results are merged into a single response. The name error condition is not meaningful for a QCLASS=* query. If the requestor wants this information, it must test each class independently. If the database is limited to data of a particular class, this operation can be performed by simply reseting the authoritative bit in the response, and performing the query as if QCLASS was the class used in the database. * labels in database RRs Some zones will contain default RRs that use * to match in cases where the search fails for a particular domain name. If the database contains these records then a failure must be retried using * in place of one or more labels of the search key. The procedure is to replace labels from the left with "*"s looking for a match until either all labels have been replaced, or a match is found. Note that these records can never be the result of caching, so a name server can omit this processing for zones that don't contain RRs with * in labels, or can omit this processing entirely if * never appears in local authoritative data. Inverse query processing Name servers that support inverse queries can support these operations through exhaustive searches of their databases, but this becomes impractical as the size of the database increases. An alternative approach is to invert the database according to the search key. For name servers that support multiple zones and a large amount of data, the recommended approach is separate inversions for each Mockapetris [Page 37]
RFC 883 November 1983 Domain Names - Implementation and Specification zone. When a particular zone is changed during a refresh, only its inversions need to be redone. Support for transfer of this type of inversion may be included in future versions of the domain system, but is not supported in this version. Completion query processing Completion query processing shares many of the same problems in data structure design as are found in inverse queries, but is different due to the expected high rate of use of top level labels (ie., ARPA, CSNET). A name server that wishes to be efficient in its use of memory may well choose to invert only occurrences of ARPA, etc. that are below the top level, and use a search for the rare case that top level labels are used to constrain a completion. Mockapetris [Page 38]
RFC 883 November 1983 Domain Names - Implementation and Specification NAME SERVER MAINTENANCE Introduction Name servers perform maintenance operations on their databases to insure that the data they distribute is accurate and timely. The amount and complexity of the maintenance operations that a name server must perform are related to the size, change rate, and complexity of the database that the name server manages. Maintenance operations are fundamentally different for authoritative and non-authoritative data. A name server actively attempts to insure the accuracy and timeliness of authoritative data by refreshing the data from master copies. Non-authoritative data is merely purged when its time-to-live expires; the name server does not attempt to refresh it. Although the refreshing scheme is fairly simple to implement, it is somewhat less powerful than schemes used in other distributed database systems. In particular, an update to the master does not immediately update copies, and should be viewed as gradually percolating though the distributed database. This is adequate for the vast majority of applications. In situations where timliness is critical, the master name server can prohibit caching of copies or assign short timeouts to copies. Conceptual model of maintenance operations The vast majority of information in the domain system is derived from master files scattered among hosts that implement name servers; some name servers will have no master files, other name servers will have one or more master files. Each master file contains the master data for a single zone of authority rather than data for the whole domain name space. The administrator of a particular zone controls that zone by updating its master file. Master files and zone copies from remote servers may include RRs that are outside of the zone of authority when a NS record delegates authority to a domain name that is a descendant of the domain name at which authority is delegated. These forward references are a problem because there is no reasonable method to guarantee that the A type records for the delegatee are available unless they can somehow be attached to the NS records. For example, suppose the ARPA zone delegates authority at MIT.ARPA, and states that the name server is on AI.MIT.ARPA. If a resolver gets the NS record but not the A type record for AI.MIT.ARPA, it might try to ask the MIT name server for the address of AI.MIT.ARPA. Mockapetris [Page 39]
RFC 883 November 1983 Domain Names - Implementation and Specification The solution is to allow type A records that are outside of the zone of authority to be copied with the zone. While these records won't be found in a search for the A type record itself, they can be protected by the zone refreshing system, and will be passed back whenever the name server passes back a referral to the corresponding NS record. If a query is received for the A record, the name server will pass back a referral to the name server with the A record in the additional section, rather than answer section. The only exception to the use of master files is a small amount of data stored in boot files. Boot file data is used by name servers to provide enough resource records to allow zones to be imported from foreign servers (e.g. the address of the server), and to establish the name and address of root servers. Boot file records establish the initial contents of the cache tree, and hence can be overridden by later loads of authoritative data. The data in a master file first becomes available to users of the domain name system when it is loaded by the corresponding name server. By definition, data from a master file is authoritative. Other name servers which wish to be authoritative for a particular zone do so by transferring a copy of the zone from the name server which holds the master copy using a virtual circuit. These copies include parameters which specify the conditions under which the data in the copy is authoritative. In the most common case, the conditions specify a refresh interval and policies to be followed when the refresh operation cannot be performed. A name server may acquire multiple zones from different name servers and master files, but the name server must maintain each zone separately from others and from non-authoritative data. When the refresh interval for a particular zone copy expires, the name server holding the copy must consult the name server that holds the master copy. If the data in the zone has not changed, the master name server instructs the copy name server to reset the refresh interval. If the data has changed, the master passes a new copy of the zone and its associated conditions to the copy name server. Following either of these transactions, the copy name server begins a new refresh interval. Copy name servers must also deal with error conditions under which they are unable to communicate with the name server that holds the master copy of a particular zone. The policies that a copy name server uses are determined by other parameters in the conditions distributed with every copy. The conditions include a retry interval and a maximum holding time. When a copy name server is Mockapetris [Page 40]
RFC 883 November 1983 Domain Names - Implementation and Specification unable to establish communications with a master or is unable to complete the refresh transaction, it must retry the refresh operation at the rate specified by the retry interval. This retry interval will usually be substantially shorter than the refresh interval. Retries continue until the maximum holding time is reached. At that time the copy name server must assume that its copy of the data for the zone in question is no longer authoritative. Queries must be processed while maintenance operations are in progress because a zone transfer can take a long time. However, to avoid problems caused by access to partial databases, the maintenance operations create new copies of data rather than directly modifying the old copies. When the new copy is complete, the maintenance process locks out queries for a short time using the main lock, and switches pointers to replace the old data with the new. After the pointers are swapped, the maintenance process unlocks the main lock and reclaims the storage used by the old copy. Name server data structures and top level logic The name server must multiplex its attention between multiple activities. For example, a name server should be able to answer queries while it is also performing refresh activities for a particular zone. While it is possible to design a name server that devotes a separate process to each query and refresh activity in progress, the model described in this memo is based on the assumption that there is a single process performing all maintenance operations, and one or more processes devoted to handling queries. The model also assumes the existence of shared memory for several control structures, the domain database, locks, etc. The model name server uses the following files and shared data structures: 1. A configuration file that describes the master and boot files which the name server should load and the zones that the name server should attempt to load from foreign name servers. This file establishes the initial contents of the status table. 2. Domain data files that contain master and boot data to be loaded. 3. A status table that is derived from the configuration file. Each entry in this table describes a source of data. Each entry has a zone number. The zone number is zero for Mockapetris [Page 41]
RFC 883 November 1983 Domain Names - Implementation and Specification non-authoritative sources; authoritative sources are assigned separate non-zero numbers. 4. The shared database that holds the domain data. This database is assumed to be organized in some sort of tree structure paralleling the domain name space, with a list of resource records attached to each node and leaf in the tree. The elements of the resource record list need not contain the exact data present in the corresponding output format, but must contain data sufficient to create the output format; for example, these records need not contain the domain name that is associated with the resource because that name can be derived from the tree structure. Each resource record also internal data that the name server uses to organize its data. 5. Inversion data structures that allow the name server to process inverse queries and completion queries. Although many structures could be used, the implementation described in this memo supposes that there is one array for every inversion that the name server can handle. Each array contains a list of pointers to resource records such that the order of the inverted quantities is sorted. 6. The main and cache queue locks 7. The cache queue The maintenance process begins by loading the status table from the configuration file. It then periodically checks each entry, to see if its refresh interval has elapsed. If not, it goes on to the next entry. If so, it performs different operations depending on the entry: If the entry is for zone 0, or the cache tree, the maintenance process checks to see if additions or deletions are required. Additions are acquired from the cache queue using the cache queue lock. Deletions are detected using TTL checks. If any changes are required, the maintenance process recalculates inversion data structures and then alters the cache tree under the protection of the main lock. Whenever the maintenance process modifies the cache tree, it resets the refresh interval to the minimum of the contained TTLs and the desired time interval for cache additions. If the entry is not zone 0, and the entry refers to a local file, the maintenance process checks to see if the file has been modified since its last load. If so the file is reloaded using the procedures specified under "Name server file Mockapetris [Page 42]
RFC 883 November 1983 Domain Names - Implementation and Specification loading". The refresh interval is reset to that specified in the SOA record if the file is a master file. If the entry is for a remote master file, the maintenance process checks for a new version using the procedure described in "Names server remote zone transfer". Name server file loading Master files are kept in text form for ease of editing by system maintainers. These files are not exchanged by name servers; name servers use the standard message format when transferring zones. Organizations that want to have a domain, but do not want to run a name server, can use these files to supply a domain definition to another organization that will run a name server for them. For example, if organization X wants a domain but not a name server, it can find another organization, Y, that has a name server and is willing to provide service for X. Organization X defines domain X via the master file format and ships a copy of the master file to organization Y via mail, FTP, or some other method. A system administrator at Y configures Y's name server to read in X's file and hence support the X domain. X can maintain the master file using a text editor and send new versions to Y for installation. These files have a simple line-oriented format, with one RR per line. Fields are separated by any combination of blanks and tab characters. Tabs are treated the same as spaces; in the following discussion the term "blank" means either a tab or a blank. A line can be either blank (and ignored), a RR, or a $INCLUDE line. If a RR line starts with a domain name, that domain name is used to specify the location in the domain space for the record, i.e. the owner. If a RR line starts with a blank, it is loaded into the location specified by the most recent location specifier. The location specifiers are assumed to be relative to some origin that is provided by the user of a file unless the location specifier contains the root label. This provides a convenient shorthand notation, and can also be used to prevent errors in master files from propagating into other zones. This feature is particularly useful for master files imported from other sites. An include line begins with $INCLUDE, starting at the first line position, and is followed by a local file name and an optional offset modifier. The filename follows the appropriate local conventions. The offset is one or more labels that are added to the offset in use for the file that contained the $INCLUDE. If the offset is omitted, the included file is loaded using the Mockapetris [Page 43]
RFC 883 November 1983 Domain Names - Implementation and Specification offset of the file that contained the $INCLUDE command. For example, a file being loaded at offset ARPA might contain the following lines: $INCLUDE <subsys>isi.data ISI $INCLUDE <subsys>addresses.data The first line would be interpreted to direct loading of the file <subsys>isi.data at offset ISI.ARPA. The second line would be interpreted as a request to load data at offset ARPA. Note that $INCLUDE commands do not cause data to be loaded into a different zone or tree; they are simply ways to allow data for a given zone to be organized in separate files. For example, mailbox data might be kept separately from host data using this mechanism. Resource records are entered as a sequence of fields corresponding to the owner name, TTL, CLASS, TYPE and RDATA components. (Note that this order is different from the order used in examples and the order used in the actual RRs; the given order allows easier parsing and defaulting.) The owner name is derived from the location specifier. The TTL field is optional, and is expressed as a decimal number. If omitted TTL defaults to zero. The CLASS field is also optional; if omitted the CLASS defaults to the most recent value of the CLASS field in a previous RR. The RDATA fields depend on the CLASS and TYPE of the RR. In general, the fields that make up RDATA are expressed as decimal numbers or as domain names. Some exceptions exist, and are documented in the RDATA definitions in Appendicies 2 and 3 of this memo. Because CLASS and TYPE fields don't contain any common identifiers, and because CLASS and TYPE fields are never decimal numbers, the parse is always unique. Because these files are text files several special encodings are necessary to allow arbitrary data to be loaded. In particular: . A free standing dot is used to refer to the current domain name. @ A free standing @ is used to denote the current origin. Mockapetris [Page 44]
RFC 883 November 1983 Domain Names - Implementation and Specification .. Two free standing dots represent the null domain name of the root. \X where X is any character other than a digit (0-9), is used to quote that character so that its special meaning does not apply. For example, "\." can be used to place a dot character in a label. \DDD where each D is a digit is the octet corresponding to the decimal number described by DDD. The resulting octet is assumed to be text and is not checked for special meaning. ( ) Parentheses are used to group data that crosses a line boundary. In effect, line terminations are not recognized within parentheses. ; Semicolon is used to start a comment; the remainder of the line is ignored. Name server file loading example A name server for F.ISI.ARPA , serving as an authority for the ARPA and ISI.ARPA domains, might use a boot file and two master files. The boot file initializes some non-authoritative data, and would be loaded without an origin: .. 9999999 IN NS B.ISI.ARPA 9999999 CS NS UDEL.CSNET B.ISI.ARPA 9999999 IN A 10.3.0.52 UDEL.CSNET 9999999 CS A 302-555-0000 This file loads non-authoritative data which provides the identities and addresses of root name servers. The first line contains a NS RR which is loaded at the root; the second line starts with a blank, and is loaded at the most recent location specifier, in this case the root; the third and fourth lines load RRs at B.ISI.ARPA and UDEL.CSNET, respectively. The timeouts are set to high values (9999999) to prevent this data from being discarded due to timeout. The first master file loads authoritative data for the ARPA domain. This file is designed to be loaded with an origin of ARPA, which allows the location specifiers to omit the trailing .ARPA labels. Mockapetris [Page 45]
RFC 883 November 1983 Domain Names - Implementation and Specification @ IN SOA F.ISI.ARPA Action.E.ISI.ARPA ( 20 ; SERIAL 3600 ; REFRESH 600 ; RETRY 3600000; EXPIRE 60) ; MINIMUM NS F.ISI.ARPA ; F.ISI.ARPA is a name server for ARPA NS A.ISI.ARPA ; A.ISI.ARPA is a name server for ARPA MIT NS AI.MIT.ARPA; delegation to MIT name server ISI NS F.ISI.ARPA ; delegation to ISI name server UDEL MD UDEL.ARPA A 10.0.0.96 NBS MD NBS.ARPA A 10.0.0.19 DTI MD DTI.ARPA A 10.0.0.12 AI.MIT A 10.2.0.6 F.ISI A 10.2.0.52 The first group of lines contains the SOA record and its parameters, and identifies name servers for this zone and for delegated zones. The Action.E.ISI.ARPA field is a mailbox specification for the responsible person for the zone, and is the domain name encoding of the mail destination [email protected]. The second group specifies data for domain names within this zone. The last group has forward references for name server address resolution for AI.MIT.ARPA and F.ISI.ARPA. This data is not technically within the zone, and will only be used for additional record resolution for NS records used in referrals. However, this data is protected by the zone timeouts in the SOA, so it will persist as long as the NS references persist. The second master file defines the ISI.ARPA environment, and is loaded with an origin of ISI.ARPA: @ IN SOA F.ISI.ARPA Action\.ISI.E.ISI.ARPA ( 20 ; SERIAL 7200 ; REFRESH 600 ; RETRY 3600000; EXPIRE 60) ; MINIMUM NS F.ISI.ARPA ; F.ISI.ARPA is a name server A A 10.1.0.32 MD A.ISI.ARPA MF F.ISI.ARPA B A 10.3.0.52 MD B.ISI.ARPA Mockapetris [Page 46]
RFC 883 November 1983 Domain Names - Implementation and Specification MF F.ISI.ARPA F A 10.2.0.52 MD F.ISI.ARPA MF A.ISI.ARPA $INCLUDE <SUBSYS>ISI-MAILBOXES.TXT Where the file <SUBSYS>ISI-MAILBOXES.TXT is: MOE MB F.ISI.ARPA LARRY MB A.ISI.ARPA CURLEY MB B.ISI.ARPA STOOGES MB B.ISI.ARPA MG MOE.ISI.ARPA MG LARRY.ISI.ARPA MG CURLEY.ISI.ARPA Note the use of the \ character in the SOA RR to specify the responsible person mailbox "[email protected]". Name server remote zone transfer When a name server needs to make an initial copy of a zone or test to see if a existing zone copy should be refreshed, it begins by attempting to open a virtual circuit to the foreign name server. If this open attempt fails, and this was an initial load attempt, it schedules a retry and exits. If this was a refresh operation, the name server tests the status table to see if the maximum holding time derived from the SOA EXPIRE field has elapsed. If not, the name server schedules a retry. If the maximum holding time has expired, the name server invalidates the zone in the status table, and scans all resource records tagged with this zone number. For each record it decrements TTL fields by the length of time since the data was last refreshed. If the new TTL value is negative, the record is deleted. If the TTL value is still positive, it moves the RR to the cache tree and schedules a retry. If the open attempt succeeds, the name server sends a query to the foreign name server in which QTYPE=SOA, QCLASS is set according to the status table information from the configuration file, and QNAME is set to the domain name of the zone of interest. The foreign name server will return either a SOA record indicating that it has the zone or an error. If an error is detected, the virtual circuit is closed, and the failure is treated in the same way as if the open attempt failed. If the SOA record is returned and this was a refresh, rather than an initial load of the zone, the name server compares the SERIAL Mockapetris [Page 47]
RFC 883 November 1983 Domain Names - Implementation and Specification field in the new SOA record with the SERIAL field in the SOA record of the existing zone copy. If these values match, the zone has not been updated since the last copy and hence there is no reason to recopy the zone. In this case the name server resets the times in the existing SOA record and closes the virtual circuit to complete the operation. If this is initial load, or the SERIAL fields were different, the name server requests a copy of the zone by sending the foreign name server an AXFR query which specifies the zone by its QCLASS and QNAME fields. When the foreign name server receives the AXFR request, it sends each node from the zone to the requestor in a separate message. It begins with the node that contains the SOA record, walks the tree in breadth-first order, and completes the transfer by resending the node containing the SOA record. Several error conditions are possible: If the AXFR request cannot be matched to a SOA, the foreign name server will return a single message in response that does not contain the AXFR request. (The normal SOA query preceding the AXFR is designed to avoid this condition, but it is still possible.) The foreign name server can detect an internal error or detect some other condition (e.g. system going down, out of resources, etc.) that forces the transfer to be aborted. If so, it sends a message with the "Server failure" condition set. If the AXFR can be immediately retried with some chance of success, it leaves the virtual open; otherwise it initiates a close. If the foreign name server doesn't wish to perform the operation for policy reasons (i.e. the system administrator wishes to forbid zone copies), the foreign server returns a "Refused" condition. The requestor receives these records and builds a new tree. This tree is not yet in the status table, so its data are not used to process queries. The old copy of the zone, if any, may be used to satisfy request while the transfer is in progress. When the requestor receives the second copy of the SOA node, it compares the SERIAL field in the first copy of the SOA against the SERIAL field in the last copy of the SOA record. If these don't match, the foreign server updated its zone while the transfer was in progress. In this case the requestor repeats the AXFR request to acquire the newer version. Mockapetris [Page 48]
RFC 883 November 1983 Domain Names - Implementation and Specification If the AXFR transfer eventually succeeds, the name server closes the virtual circuit and and creates new versions of inversion data structures for this zone. When this operation is complete, the name server acquires the main lock in write mode and then replaces any old copy of the zone and inversion data structures with new ones. The name server then releases the main lock, and can reclaim the storage used by the old copy. If an error occurs during the AXFR transfer, the name server can copy any partial information into its cache tree if it wishes, although it will not normally do so if the zone transfer was a refresh rather than an initial load. Mockapetris [Page 49]
RFC 883 November 1983 Domain Names - Implementation and Specification RESOLVER ALGORITHMS Operations Resolvers have a great deal of latitude in the semantics they allow in user calls. For example, a resolver might support different user calls that specify whether the returned information must be from and authoritative name server or not. Resolvers are also responsible for enforcement of any local restrictions on access, etc. In any case, the resolver will transform the user query into a number of shared database accesses and queries to remote name servers. When a user requests a resource associated with a particular domain name, the resolver will execute the following steps: 1. The resolver first checks the local shared database, if any, for the desired information. If found, it checks the applicable timeout. If the timeout check succeeds, the information is used to satisfy the user request. If not, the resolver goes to step 2. 2. In this step, the resolver consults the shared database for the name server that most closely matches the domain name in the user query. Multiple redundant name servers may be found. The resolver goes to step 3. 3. In this step the resolver chooses one of the available name servers and sends off a query. If the query fails, it tries another name server. If all fail, an error indication is returned to the user. If a reply is received the resolver adds the returned RRs to its database and goes to step 4. 4. In this step, the resolver interprets the reply. If the reply contains the desired information, the resolver returns the information to the user. The the reply indicates that the domain name in the user query doesn't exist, then the resolver returns an error to the user. If the reply contains a transient name server failure, the resolver can either wait and retry the query or go back to step 3 and try a different name server. If the reply doesn't contain the desired information, but does contain a pointer to a closer name server, the resolver returns to step 2, where the closer name servers will be queried. Several modifications to this algorithm are possible. A resolver may not support a local cache and instead only cache information during the course of a single user request, discarding it upon Mockapetris [Page 50]
RFC 883 November 1983 Domain Names - Implementation and Specification completion. The resolver may also find that a datagram reply was truncated, and open a virtual circuit so that the complete reply can be recovered. Inverse and completion queries must be treated in an environment-sensitive manner, because the domain system doesn't provide a method for guaranteeing that it can locate the correct information. The typical choice will be to configure a resolver to use a particular set of known name servers for inverse queries. Mockapetris [Page 51]
RFC 883 November 1983 Domain Names - Implementation and Specification DOMAIN SUPPORT FOR MAIL Introduction Mail service is a particularly sensitive issue for users of the domain system because of the lack of a consistent system for naming mailboxes and even hosts, and the need to support continued operation of existing services. This section discusses an evolutionary approach for adding consistent domain name support for mail. The crucial issue is deciding on the types of binding to be supported. Most mail systems specify a mail destination with a two part construct such as X@Y. The left hand side, X, is an string, often a user or account, and Y is a string, often a host. This section refers to the part on the left, i.e. X, as the local part, and refers to the part on the right, i.e. Y, as the global part. Most existing mail systems route mail based on the global part; a mailer with mail to deliver to X@Y will decide on the host to be contacted using only Y. We refer to this type of binding as "agent binding". For example, mail addressed to Mockapetris@ISIF is delivered to host USC-ISIF (USC-ISIF is the official name for the host specified by nickname ISIF). More sophisticated mail systems use both the local and global parts, i.e. both X and Y to determine which host should receive the mail. These more sophisticated systems usually separate the binding of the destination to the host from the actual delivery. This allows the global part to be a generic name rather than constraining it to a single host. We refer to this type of binding as "mailbox binding". For example, mail addressed to Mockapetris@ISI might be bound to host F.ISI.ARPA, and subsequently delivered to that host, while mail for Cohen@ISI might be bound to host B.ISI.ARPA. The domain support for mail consists of two levels of support, corresponding to these two binding models. The first level, agent binding, is compatible with existing ARPA Internet mail procedures and uses maps a global part onto one or more hosts that will accept the mail. This type of binding uses the MAILA QTYPE. The second level, mailbox binding, offers extended services Mockapetris [Page 52]
RFC 883 November 1983 Domain Names - Implementation and Specification that map a local part and a global part onto one or more sets of data via the MAILB QTYPE. The sets of data include hosts that will accept the mail, mailing list members (mail groups), and mailboxes for reporting errors or requests to change a mail group. The domain system encodes the global part of a mail destination as a domain name and uses dots in the global part to separate labels in the encoded domain name. The domain system encodes the local part of a mail destination as a single label, and any dots in this part are simply copied into the label. The domain system forms a complete mail destination as the local label concatenated to the domain string for the global part. We call this a mailbox. For example, the mailbox [email protected] has a global domain name of three labels, F.ISI.ARPA. The domain name encoding for the whole mailbox is Mockapetris.F.ISI.ARPA. The mailbox [email protected] has the same domain name for the global part and a 4 label domain name for the mailbox of Mockapetris\.cad.F.ISI.ARPA (the \ is not stored in the label, its merely used to denote the "quoted" dot). It is anticipated that the Internet system will adopt agent binding as part of the initial implementation of the domain system, and that mailbox binding will eventually become the preferred style as organizations convert their mail systems to the new style. To facilitate this approach, the domain information for these two binding styles is organized to allow a requestor to determine which types of support are available, and the information is kept in two disjoint classes. Agent binding In agent binding, a mail system uses the global part of the mail destination as a domain name, with dots denoting structure. The domain name is resolved using a MAILA query which return MF and MD RRs to specify the domain name of the appropriate host to receive the mail. MD (Mail delivery) RRs specify hosts that are expected to have the mailbox in question; MF (Mail forwarding) RRs specify hosts that are expected to be intermediaries willing to accept the mail for eventual forwarding. The hosts are hints, rather than definite answers, since the query is made without the full mail destination specification. For example, mail for [email protected] would result in a query with QTYPE=MAILA and QNAME=F.ISI.ARPA, which might return two RRs: Mockapetris [Page 53]
RFC 883 November 1983 Domain Names - Implementation and Specification F.ISI.ARPA MD IN F.ISI.ARPA F.ISI.ARPA MF IN A.ISI.ARPA The mailer would interpret these to mean that the mail agent on F.ISI.ARPA should be able to deliver the mail directly, but that A.ISI.ARPA is willing to accept the mail for probable forwarding. Using this system, an organization could implement a system that uses organization names for global parts, rather than the usual host names, but all mail for the organization would be routed the same, regardless of its local part. Hence and organization with many hosts would expect to see many forwarding operations. Mailbox binding In mailbox binding, the mailer uses the entire mail destination specification to construct a domain name. The encoded domain name for the mailbox is used as the QNAME field in a QTYPE=MAILB query. Several outcomes are possible for this query: 1. The query can return a name error indicating that the mailbox does not exist as a domain name. In the long term this would indicate that the specified mailbox doesn't exist. However, until the use of mailbox binding is universal, this error condition should be interpreted to mean that the organization identified by the global part does not support mailbox binding. The appropriate procedure is to revert to agent binding at this point. 2. The query can return a Mail Rename (MR) RR. The MR RR carries new mailbox specification in its RDATA field. The mailer should replace the old mailbox with the new one and retry the operation. 3. The query can return a MB RR. The MB RR carries a domain name for a host in its RDATA field. The mailer should deliver the message to that host via whatever protocol is applicable, e.g. SMTP. 4. The query can return one or more Mail Group (MG) RRs. This condition means that the mailbox was actually a mailing list or mail group, rather than a single mailbox. Each MG RR has a RDATA field that identifies a mailbox that is a member of Mockapetris [Page 54]
RFC 883 November 1983 Domain Names - Implementation and Specification the group. The mailer should deliver a copy of the message to each member. 5. The query can return a MB RR as well as one or more MG RRs. This condition means the the mailbox was actually a mailing list. The mailer can either deliver the message to the host specified by the MB RR, which will in turn do the delivery to all members, or the mailer can use the MG RRs to do the expansion itself. In any of these cases, the response may include a Mail Information (MINFO) RR. This RR is usually associated with a mail group, but is legal with a MB. The MINFO RR identifies two mailboxes. One of these identifies a responsible person for the original mailbox name. This mailbox should be used for requests to be added to a mail group, etc. The second mailbox name in the MINFO RR identifies a mailbox that should receive error messages for mail failures. This is particularly appropriate for mailing lists when errors in member names should be reported to a person other than the one who sends a message to the list. New fields may be added to this RR in the future. Mockapetris [Page 55]
RFC 883 November 1983 Domain Names - Implementation and Specification Appendix 1 - Domain Name Syntax Specification The preferred syntax of domain names is given by the following BNF rules. Adherence to this syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET). Note that some applications use domain names containing binary information and hence do not follow this syntax. <domain> ::= <subdomain> | " " <subdomain> ::= <label> | <subdomain> "." <label> <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ] <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str> <let-dig-hyp> ::= <let-dig> | "-" <let-dig> ::= <letter> | <digit> <letter> ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case <digit> ::= any one of the ten digits 0 through 9 Note that while upper and lower case letters are allowed in domain names no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical. The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less. For example, the following strings identify hosts in the ARPA Internet: F.ISI.ARPA LINKABIT-DCN5.ARPA UCL-TAC.ARPA Mockapetris [Page 56]
RFC 883 November 1983 Domain Names - Implementation and Specification Appendix 2 - Field formats and encodings +-----------------------------------------------+ | | | ***** WARNING ***** | | | | The following formats are preliminary and | | are included for purposes of explanation only.| | In particular, new RR types will be added, | | and the size, position, and encoding of | | fields are subject to change. | | | +-----------------------------------------------+ TYPE values TYPE fields are used in resource records. Note that these types are not the same as the QTYPE fields used in queries, although the functions are often similar. TYPE value meaning A 1 a host address NS 2 an authoritative name server MD 3 a mail destination MF 4 a mail forwarder CNAME 5 the canonical name for an alias SOA 6 marks the start of a zone of authority MB 7 a mailbox domain name MG 8 a mail group member MR 9 a mail rename domain name NULL 10 a null RR WKS 11 a well known service description PTR 12 a domain name pointer HINFO 13 host information MINFO 14 mailbox or mail list information Mockapetris [Page 57]
RFC 883 November 1983 Domain Names - Implementation and Specification QTYPE values QTYPE fields appear in the question part of a query. They include the values of TYPE with the following additions: AXFR 252 A request for a transfer of an entire zone of authority MAILB 253 A request for mailbox-related records (MB, MG or MR) MAILA 254 A request for mail agent RRs (MD and MF) * 255 A request for all records CLASS values CLASS fields appear in resource records CLASS value meaning IN 1 the ARPA Internet CS 2 the computer science network (CSNET) QCLASS values QCLASS fields appear in the question section of a query. They include the values of CLASS with the following additions: * 255 any class Mockapetris [Page 58]
RFC 883 November 1983 Domain Names - Implementation and Specification Standard resource record formats All RRs have the same top level format shown below: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: NAME - a compressed domain name to which this resource record pertains. TYPE - two octets containing one of the RR type codes defined in Appendix 2. This field specifies the meaning of the data in the RDATA field. CLASS - two octets which specifies the class of the data in the RDATA field. TTL - a 16 bit signed integer that specifies the time interval that the resource record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be cached. For example, SOA records are always distributed with a zero TTL to prohibit caching. Zero values can also be used for extremely volatile data. RDLENGTH- an unsigned 16 bit integer that specifies the length in octets of the RDATA field. Mockapetris [Page 59]
RFC 883 November 1983 Domain Names - Implementation and Specification RDATA - a variable length string of octets that describes the resource. The format of this information varies according to the TYPE and CLASS of the resource record. The format of the RDATA field is standard for all classes for the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO and NULL. These formats are shown below together with the appropriate additional section RR processing. CNAME RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / CNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: CNAME - A compressed domain name which specifies that the domain name of the RR is an alias for a canonical name specified by CNAME. CNAME records cause no additional section processing. The RDATA section of a CNAME line in a master file is a standard printed domain name. HINFO RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / CPU / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / OS / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: CPU - A character string which specifies the CPU type. The character string is represented as a single octet length followed by that number of characters. The following standard strings are defined:. PDP-11/70 C/30 C/70 VAX-11/780 H-316 H-516 DEC-2060 DEC-1090T ALTO IBM-PC IBM-PC/XT PERQ IBM-360/67 IBM-370/145 OS - A character string which specifies the operating system type. The character string is represented as a single octet Mockapetris [Page 60]
RFC 883 November 1983 Domain Names - Implementation and Specification length followed by that number of characters. The following standard types are defined:. ASP AUGUST BKY CCP DOS/360 ELF EPOS EXEC-8 GCOS GPOS ITS INTERCOM KRONOS MCP MOS MPX-RT MULTICS MVT NOS NOS/BE OS/MVS OS/MVT RIG RSX11 RSX11M RT11 SCOPE SIGNAL SINTRAN TENEX TOPS10 TOPS20 TSS UNIX VM/370 VM/CMS VMS WAITS HINFO records cause no additional section processing. HINFO records are used to acquire general information about a host. The main use is for protocols such as FTP that can use special procedures when talking between machines or operating systems of the same type. MB RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / MADNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: MADNAME - A compressed domain name which specifies a host which has the specified mailbox. MB records cause additional section processing which looks up an A type record corresponding to MADNAME. The RDATA section of a MB line in a master file is a standard printed domain name. MD RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / MADNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: MADNAME - A compressed domain name which specifies a host which Mockapetris [Page 61]
RFC 883 November 1983 Domain Names - Implementation and Specification has a mail agent for the domain which should be able to deliver mail for the domain. MD records cause additional section processing which looks up an A type record corresponding to MADNAME. The RDATA section of a MD line in a master file is a standard printed domain name. MF RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / MADNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: MADNAME - A compressed domain name which specifies a host which has a mail agent for the domain which will accept mail for forwarding to the domain. MF records cause additional section processing which looks up an A type record corresponding to MADNAME. The RDATA section of a MF line in a master file is a standard printed domain name. MG RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / MGMNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: MGMNAME - A compressed domain name which specifies a mailbox which is a member of the mail group specified by the domain name. MF records cause no additional section processing. The RDATA section of a MF line in a master file is a standard printed domain name. Mockapetris [Page 62]
RFC 883 November 1983 Domain Names - Implementation and Specification MINFO RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / RMAILBX / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / EMAILBX / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: RMAILBX - A compressed domain name which specifies a mailbox which is responsible for the mailing list or mailbox. If this domain name names the root, the owner of the MINFO RR is responsible for itself. Note that many existing mailing lists use a mailbox X-request for the RMAILBX field of mailing list X, e.g. Msgroup-request for Msgroup. This field provides a more general mechanism. EMAILBX - A compressed domain name which specifies a mailbox which is to receive error messages related to the mailing list or mailbox specified by the owner of the MINFO RR (similar to the ERRORS-TO: field which has been proposed). If this domain name names the root, errors should be returned to the sender of the message. MINFO records cause no additional section processing. Although these records can be associated with a simple mailbox, they are usually used with a mailing list. The MINFO section of a MF line in a master file is a standard printed domain name. MR RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / NEWNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: NEWNAME - A compressed domain name which specifies a mailbox which is the proper rename of the specified mailbox. MR records cause no additional section processing. The RDATA section of a MR line in a master file is a standard printed domain name. Mockapetris [Page 63]
RFC 883 November 1983 Domain Names - Implementation and Specification NULL RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / <anything> / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Anything at all may be in the RDATA field so long as it is 65535 octets or less. NULL records cause no additional section processing. NULL RRs are not allowed in master files. NS RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / NSDNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: NSDNAME - A compressed domain name which specifies a host which has a name server for the domain. NS records cause both the usual additional section processing to locate a type A record, and a special search of the zone in which they reside. The RDATA section of a NS line in a master file is a standard printed domain name. PTR RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / PTRDNAME / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: PTRDNAME - A compressed domain name which points to some location in the domain name space. PTR records cause no additional section processing. These RRs are used in special domains to point to some other location in the domain space. These records are simple data, and don't imply any special processing similar to that performed by CNAME, which identifies aliases. Appendix 3 discusses the use of these records in the ARPA Internet address domain. Mockapetris [Page 64]
RFC 883 November 1983 Domain Names - Implementation and Specification SOA RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / MNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / RNAME / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | SERIAL | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | REFRESH | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RETRY | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | EXPIRE | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | MINIMUM | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: MNAME - The domain name of the name server that was the original source of data for this zone. RNAME - A domain name which specifies the mailbox of the person responsible for this zone. SERIAL - The unsigned 16 bit version number of the of the original copy of the zone. This value wraps and should be compared using sequence space arithmetic. REFRESH - The unsigned 32 bit time interval before the zone should be refreshed. RETRY - The unsigned 32 bit time interval that should elapse before a failed refresh should be retried. EXPIRE - A 32 bit time value that specifies the upper limit on the time interval that can elapse before the zone is no longer authoritative. MINIMUM - The unsigned 16 bit minimum TTL field that should be exported with any RR from this zone (other than the SOA itself). SOA records cause no additional section processing. The RDATA Mockapetris [Page 65]
RFC 883 November 1983 Domain Names - Implementation and Specification section of a SOA line in a master file is a standard printed domain name for MNAME, a standard X@Y mailbox specification for RNAME, and decimal numbers for the remaining parameters. All times are in units of seconds. Most of these fields are pertinent only for name server maintenance operations. However, MINIMUM is used in all query operations that retrieve RRs from a zone. Whenever a RR is sent in a response to a query, the TTL field is set to the maximum of the TTL field from the RR and the MINIMUM field in the appropriate SOA. Thus MINIMUM is a lower bound on the TTL field for all RRs in a zone. RRs in a zone are never discarded due to timeout unless the whole zone is deleted. This prevents partial copies of zones. Mockapetris [Page 66]
RFC 883 November 1983 Domain Names - Implementation and Specification Appendix 3 - Internet specific field formats and operations Message transport The Internet supports name server access using TCP [10] on server port 53 (decimal) as well as datagram access using UDP [11] on UDP port 53 (decimal). Messages sent over TCP virtual circuits are preceded by an unsigned 16 bit length field which describes the length of the message, excluding the length field itself. +-----------------------------------------------+ | | | ***** WARNING ***** | | | | The following formats are preliminary and | | are included for purposes of explanation only.| | In particular, new RR types will be added, | | and the size, position, and encoding of | | fields are subject to change. | | | +-----------------------------------------------+ A RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ADDRESS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: ADDRESS - A 32 bit ARPA internet address Hosts that have multiple ARPA Internet addresses will have multiple A records. A records cause no additional section processing. The RDATA section of an A line in a master file is an Internet address expressed as four decimal numbers separated by dots without any imbedded spaces (e.g., "10.2.0.52" or "192.0.5.6"). Mockapetris [Page 67]
RFC 883 November 1983 Domain Names - Implementation and Specification WKS RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ADDRESS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PROTOCOL | | +--+--+--+--+--+--+--+--+ | | | / <BIT MAP> / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: ADDRESS - An 32 bit ARPA Internet address PROTOCOL - An 8 bit IP protocol number <BIT MAP> - A variable length bit map. The bit map must be a multiple of 8 bits long. The WKS record is used to describe the well known services supported by a particular protocol on a particular internet address. The PROTOCOL field specifies an IP protocol number, and the bit map has one bit per port of the specified protocol. The first bit corresponds to port 0, the second to port 1, etc. If less than 256 bits are present, the remainder are assumed to be zero. The appropriate values for ports and protocols are specified in [13]. For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port 25 (SMTP). If this bit is set, a SMTP server should be listening on TCP port 25; if zero, SMTP service is not supported on the specified address. The anticipated use of WKS RRs is to provide availability information for servers for TCP and UDP. If a server supports both TCP and UDP, or has multiple Internet addresses, then multiple WKS RRs are used. WKS RRs cause no additional section processing. The RDATA section of a WKS record consists of a decimal protocol number followed by mnemonic identifiers which specify bits to be set to 1. IN-ADDR special domain The ARPA internet uses a special domain to support gateway location and ARPA Internet address to host mapping. The intent of this domain is to allow queries to locate all gateways on a Mockapetris [Page 68]
RFC 883 November 1983 Domain Names - Implementation and Specification particular network in the ARPA Internet, and also to provide a guaranteed method to perform host address to host name mapping. Note that both of these services are similar to functions that could be performed by inverse queries; the difference is that this part of the domain name space is structured according to address, and hence can guarantee that the appropriate data can be located without an exhaustive search of the domain space. It is anticipated that the special tree will be used by ARPA Internet resolvers for all gateway location services, but that address to name resolution will be performed by first trying the inverse query on the local name server database followed by a query in the special space if the inverse query fails. The domain is a top level domain called IN-ADDR whose substructure follows the ARPA Internet addressing structure. Domain names in the IN-ADDR domain are defined to have up to four labels in addition to the IN-ADDR label. Each label is a character string which expresses a decimal value in the range 0-255 (with leading zeros omitted except in the case of a zero octet which is represented by a single zero). These labels correspond to the 4 octets of an ARPA Internet address. Host addresses are represented by domain names that have all four labels specified. Thus data for ARPA Internet address 10.2.0.52 is located at domain name 52.0.2.10.IN-ADDR. The reversal, though awkward to read, allows zones to follow the natural grouping of hosts within networks. For example, 10.IN-ADDR can be a zone containing data for the ARPANET, while 26.IN-ADDR can be a separate zone for MILNET. Address nodes are used to hold pointers to primary host names in the normal domain space. Network addresses correspond to some of the non-terminal nodes in the IN-ADDR tree, since ARPA Internet network numbers are either 1, 2, or 3 octets. Network nodes are used to hold pointers to primary host names (which happen to be gateways) in the normal domain space. Since a gateway is, by definition, on more than one network, it will typically have two or more network nodes that point at the gateway. Gateways will also have host level pointers at their fully qualified addresses. Both the gateway pointers at network nodes and the normal host pointers at full address nodes use the PTR RR to point back to the primary domain names of the corresponding hosts. For example, part of the IN-ADDR domain will contain information about the ISI to MILNET and MIT gateways, and hosts F.ISI.ARPA and MULTICS.MIT.ARPA. Assuming that ISI gateway has addresses Mockapetris [Page 69]
RFC 883 November 1983 Domain Names - Implementation and Specification 10.2.0.22 and 26.0.0.103, and a name MILNET-GW.ISI.ARPA, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4 and a name GW.MIT.ARPA, the domain database would contain: 10.IN-ADDR PTR IN MILNET-GW.ISI.ARPA 10.IN-ADDR PTR IN GW.MIT.ARPA 18.IN-ADDR PTR IN GW.MIT.ARPA 26.IN-ADDR PTR IN MILNET-GW.ISI.ARPA 22.0.2.10.IN-ADDR PTR IN MILNET-GW.ISI.ARPA 103.0.0.26.IN-ADDR PTR IN MILNET-GW.ISI.ARPA 77.0.0.10.IN-ADDR PTR IN GW.MIT.ARPA 4.0.10.18.IN-ADDR PTR IN GW.MIT.ARPA 52.0.2.10.IN-ADDR PTR IN F.ISI.ARPA 6.0.0.10.IN-ADDR PTR IN MULTICS.MIT.ARPA Thus a program which wanted to locate gateways on net 10 would originate a query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR. It would receive two RRs in response: 10.IN-ADDR PTR IN MILNET-GW.ISI.ARPA 10.IN-ADDR PTR IN GW.MIT.ARPA The program could then originate QTYPE=A, QCLASS=IN queries for MILNET-GW.ISI.ARPA and GW.MIT.ARPA to discover the ARPA Internet addresses of these gateways. A resolver which wanted to find the host name corresponding to ARPA Internet host address 10.0.0.6 might first try an inverse query on the local name server, but find that this information wasn't available. It could then try a query of the form QTYPE=PTR, QCLASS=IN, QNAME=6.0.0.10.IN-ADDR, and would receive: 6.0.0.10.IN-ADDR PTR IN MULTICS.MIT.ARPA Several cautions apply to the use of these services: Since the IN-ADDR special domain and the normal domain for a particular host or gateway will be in different zones, the possibility exists that that the data may be inconsistent. Gateways will often have two names in separate domains, only one of which can be primary. Systems that use the domain database to initialize their routing tables must start with enough gateway information to guarantee that they can access the appropriate name server. The gateway data only reflects the existence of a gateway in a Mockapetris [Page 70]
RFC 883 November 1983 Domain Names - Implementation and Specification manner equivalent to the current HOSTS.TXT file. It doesn't replace the dynamic availability information from GGP or EGP. Mockapetris [Page 71]
RFC 883 November 1983 Domain Names - Implementation and Specification REFERENCES and BIBLIOGRAPHY [1] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD Internet Host Table Specification", RFC 810, Network Information Center, SRI International, March 1982. [2] J. Postel, "Computer Mail Meeting Notes", RFC 805, USC/Information Sciences Institute, February 1982. [3] Z. Su, and J. Postel, "The Domain Naming Convention for Internet User Applications", RFC 819, Network Information Center, SRI International, August 1982. [4] Z. Su, "A Distributed System for Internet Name Service", RFC 830, Network Information Center, SRI International, October 1982. [5] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC 812, Network Information Center, SRI International, March 1982. [6] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET Name Server", Computer Networks, vol 6, nr 3, July 1982. [7] K. Harrenstien, "NAME/FINGER", RFC 742, Network Information Center, SRI International, December 1977. [8] J. Postel, "Internet Name Server", IEN 116, USC/Information Sciences Institute, August 1979. [9] K. Harrenstien, V. White, and E. Feinler, "Hostnames Server", RFC 811, Network Information Center, SRI International, March 1982. [10] J. Postel, "Transmission Control Protocol", RFC 793, USC/Information Sciences Institute, September 1981. [11] J. Postel, "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, August 1980. [12] J. Postel, "Simple Mail Transfer Protocol", RFC 821, USC/Information Sciences Institute, August 1980. [13] J. Reynolds, and J. Postel, "Assigned Numbers", RFC 870, USC/Information Sciences Institute, October 1983. [14] P. Mockapetris, "Domain names - Concepts and Facilities," RFC 882, USC/Information Sciences Institute, November 1983. Mockapetris [Page 72]
RFC 883 November 1983 Domain Names - Implementation and Specification INDEX * usage........................................................37, 57 A RDATA format.....................................................67 byte order..........................................................6 cache queue....................................................35, 42 character case..................................................7, 31 CLASS...........................................................9, 58 completion.........................................................19 compression........................................................31 CNAME RR...........................................................60 header format......................................................26 HINFO RR...........................................................60 include files......................................................43 inverse queries....................................................17 mailbox names......................................................53 master files.......................................................43 MB RR..............................................................61 MD RR..............................................................61 message format.....................................................13 MF RR..............................................................62 MG RR..............................................................62 MINFO RR...........................................................63 MR RR..............................................................63 NULL RR............................................................64 NS RR..............................................................64 PTR RR.........................................................64, 69 QCLASS.............................................................58 QTYPE..............................................................57 queries (standard).................................................15 recursive service..................................................24 RR format..........................................................59 SOA RR.............................................................65 Special domains....................................................68 TYPE...............................................................57 WKS type RR........................................................68 Mockapetris [Page 73]
Html markup produced by rfcmarkup 1.115, available from https://tools.ietf.org/tools/rfcmarkup/
Obsoleted by: 1034, 1035
Updated by: 973
Network Working Group P. Mockapetris Request for Comments: 883 ISI November 1983 DOMAIN NAMES - IMPLEMENTATION and SPECIFICATION +-----------------------------------------------------+ | | | This memo discusses the implementation of domain | | name servers and resolvers, specifies the format of | | transactions, and discusses the use of domain names | | in the context of existing mail systems and other | | network software. | | | | This memo assumes that the reader is familiar with | | RFC 882, "Domain Names - Concepts and Facilities" | | which discusses the basic principles of domain | | names and their use. | | | | The algorithms and internal data structures used in | | this memo are offered as suggestions rather than | | requirements; implementers are free to design their | | own structures so long as the same external | | behavior is achieved. | | | +-----------------------------------------------------+ +-----------------------------------------------+ | | | ***** WARNING ***** | | | | This RFC contains format specifications which | | are preliminary and are included for purposes | | of explanation only. Do not attempt to use | | this information for actual implementations. | | | +-----------------------------------------------+ Mockapetris [Page i]
RFC 883 November 1983 Domain Names - Implementation and Specification TABLE OF CONTENTS INTRODUCTION........................................................3 Overview.........................................................3 Implementation components........................................2 Conventions......................................................6 Design philosophy................................................8 NAME SERVER TRANSACTIONS...........................................11 Introduction....................................................11 Query and response transport....................................11 Overall message format..........................................13 The contents of standard queries and responses..................15 Standard query and response example.............................15 The contents of inverse queries and responses...................17 Inverse query and response example..............................18 Completion queries and responses................................19 Completion query and response example...........................22 Recursive Name Service..........................................24 Header section format...........................................26 Question section format.........................................29 Resource record format..........................................30 Domain name representation and compression......................31 Organization of the Shared database.............................33 Query processing................................................36 Inverse query processing........................................37 Completion query processing.....................................38 NAME SERVER MAINTENANCE............................................39 Introduction....................................................39 Conceptual model of maintenance operations......................39 Name server data structures and top level logic.................41 Name server file loading........................................43 Name server file loading example................................45 Name server remote zone transfer................................47 RESOLVER ALGORITHMS................................................50 Operations......................................................50 DOMAIN SUPPORT FOR MAIL............................................52 Introduction....................................................52 Agent binding...................................................53 Mailbox binding.................................................54 Appendix 1 - Domain Name Syntax Specification......................56 Appendix 2 - Field formats and encodings...........................57 TYPE values.....................................................57 QTYPE values....................................................57 CLASS values....................................................58 QCLASS values...................................................58 Standard resource record formats................................59 Appendix 3 - Internet specific field formats and operations........67 REFERENCES and BIBLIOGRAPHY........................................72 INDEX..............................................................73 Mockapetris [Page ii]
RFC 883 November 1983 Domain Names - Implementation and Specification INTRODUCTION Overview The goal of domain names is to provide a mechanism for naming resources in such a way that the names are usable in different hosts, networks, protocol families, internets, and administrative organizations. From the user's point of view, domain names are useful as arguments to a local agent, called a resolver, which retrieves information associated with the domain name. Thus a user might ask for the host address or mail information associated with a particular domain name. To enable the user to request a particular type of information, an appropriate query type is passed to the resolver with the domain name. To the user, the domain tree is a single information space. From the resolver's point of view, the database that makes up the domain space is distributed among various name servers. Different parts of the domain space are stored in different name servers, although a particular data item will usually be stored redundantly in two or more name servers. The resolver starts with knowledge of at least one name server. When the resolver processes a user query it asks a known name server for the information; in return, the resolver either receives the desired information or a referral to another name server. Using these referrals, resolvers learn the identities and contents of other name servers. Resolvers are responsible for dealing with the distribution of the domain space and dealing with the effects of name server failure by consulting redundant databases in other servers. Name servers manage two kinds of data. The first kind of data held in sets called zones; each zone is the complete database for a particular subtree of the domain space. This data is called authoritative. A name server periodically checks to make sure that its zones are up to date, and if not obtains a new copy of updated zones from master files stored locally or in another name server. The second kind of data is cached data which was acquired by a local resolver. This data may be incomplete but improves the performance of the retrieval process when non-local data is repeatedly accessed. Cached data is eventually discarded by a timeout mechanism. This functional structure isolates the problems of user interface, failure recovery, and distribution in the resolvers and isolates the database update and refresh problems in the name servers. Mockapetris [Page 1]
RFC 883 November 1983 Domain Names - Implementation and Specification Implementation components A host can participate in the domain name system in a number of ways, depending on whether the host runs programs that retrieve information from the domain system, name servers that answer queries from other hosts, or various combinations of both functions. The simplest, and perhaps most typical, configuration is shown below: Local Host | Foreign | +---------+ +----------+ | +--------+ | | user queries | |queries | | | | User |-------------->| |---------|->|Foreign | | Program | | Resolver | | | Name | | |<--------------| |<--------|--| Server | | | user responses| |responses| | | +---------+ +----------+ | +--------+ | A | cache additions | | references | V | | +----------+ | | database | | +----------+ | User programs interact with the domain name space through resolvers; the format of user queries and user responses is specific to the host and its operating system. User queries will typically be operating system calls, and the resolver and its database will be part of the host operating system. Less capable hosts may choose to implement the resolver as a subroutine to be linked in with every program that needs its services. Resolvers answer user queries with information they acquire via queries to foreign name servers, and may also cache or reference domain information in the local database. Note that the resolver may have to make several queries to several different foreign name servers to answer a particular user query, and hence the resolution of a user query may involve several network accesses and an arbitrary amount of time. The queries to foreign name servers and the corresponding responses have a standard format described in this memo, and may be datagrams. Mockapetris [Page 2]
RFC 883 November 1983 Domain Names - Implementation and Specification Depending on its capabilities, a name server could be a stand alone program on a dedicated machine or a process or processes on a large timeshared host. A simple configuration might be: Local Host | Foreign | +---------+ | / /| | +---------+ | +----------+ | +--------+ | | | | |responses| | | | | | | Name |---------|->|Foreign | | Master |-------------->| Server | | |Resolver| | files | | | |<--------|--| | | |/ | | queries | +--------+ +---------+ +----------+ | Here the name server acquires information about one or more zones by reading master files from its local file system, and answers queries about those zones that arrive from foreign resolvers. A more sophisticated name server might acquire zones from foreign name servers as well as local master files. This configuration is shown below: Local Host | Foreign | +---------+ | / /| | +---------+ | +----------+ | +--------+ | | | | |responses| | | | | | | Name |---------|->|Foreign | | Master |-------------->| Server | | |Resolver| | files | | | |<--------|--| | | |/ | | queries | +--------+ +---------+ +----------+ | A |maintenance | +--------+ | \------------|->| | | queries | |Foreign | | | | Name | \------------------|--| Server | maintenance responses | +--------+ In this configuration, the name server periodically establishes a virtual circuit to a foreign name server to acquire a copy of a zone or to check that an existing copy has not changed. The messages sent for these maintenance activities follow the same form as queries and responses, but the message sequences are somewhat different. Mockapetris [Page 3]
RFC 883 November 1983 Domain Names - Implementation and Specification The information flow in a host that supports all aspects of the domain name system is shown below: Local Host | Foreign | +---------+ +----------+ | +--------+ | | user queries | |queries | | | | User |-------------->| |---------|->|Foreign | | Program | | Resolver | | | Name | | |<--------------| |<--------|--| Server | | | user responses| |responses| | | +---------+ +----------+ | +--------+ | A | cache additions | | references | V | | +----------+ | | Shared | | | database | | +----------+ | A | | +---------+ refreshes | | references | / /| | V | +---------+ | +----------+ | +--------+ | | | | |responses| | | | | | | Name |---------|->|Foreign | | Master |-------------->| Server | | |Resolver| | files | | | |<--------|--| | | |/ | | queries | +--------+ +---------+ +----------+ | A |maintenance | +--------+ | \------------|->| | | queries | |Foreign | | | | Name | \------------------|--| Server | maintenance responses | +--------+ The shared database holds domain space data for the local name server and resolver. The contents of the shared database will typically be a mixture of authoritative data maintained by the periodic refresh operations of the name server and cached data from previous resolver requests. The structure of the domain data and the necessity for synchronization between name servers and resolvers imply the general characteristics of this database, but the actual format is up to the local implementer. This memo suggests a multiple tree format. Mockapetris [Page 4]
RFC 883 November 1983 Domain Names - Implementation and Specification This memo divides the implementation discussion into sections: NAME SERVER TRANSACTIONS, which discusses the formats for name servers queries and the corresponding responses. NAME SERVER MAINTENANCE, which discusses strategies, algorithms, and formats for maintaining the data residing in name servers. These services periodically refresh the local copies of zones that originate in other hosts. RESOLVER ALGORITHMS, which discusses the internal structure of resolvers. This section also discusses data base sharing between a name server and a resolver on the same host. DOMAIN SUPPORT FOR MAIL, which discusses the use of the domain system to support mail transfer. Mockapetris [Page 5]
RFC 883 November 1983 Domain Names - Implementation and Specification Conventions The domain system has several conventions dealing with low-level, but fundamental, issues. While the implementer is free to violate these conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in ALL behavior observed from other hosts. ********** Data Transmission Order ********** The order of transmission of the header and data described in this document is resolved to the octet level. Whenever a diagram shows a group of octets, the order of transmission of those octets is the normal order in which they are read in English. For example, in the following diagram the octets are transmitted in the order they are numbered. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Transmission Order of Bytes Whenever an octet represents a numeric quantity the left most bit in the diagram is the high order or most significant bit. That is, the bit labeled 0 is the most significant bit. For example, the following diagram represents the value 170 (decimal). 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |1 0 1 0 1 0 1 0| +-+-+-+-+-+-+-+-+ Significance of Bits Similarly, whenever a multi-octet field represents a numeric quantity the left most bit of the whole field is the most significant bit. When a multi-octet quantity is transmitted the most significant octet is transmitted first. Mockapetris [Page 6]
RFC 883 November 1983 Domain Names - Implementation and Specification ********** Character Case ********** All comparisons between character strings (e.g. labels, domain names, etc.) are done in a case-insensitive manner. When data enters the domain system, its original case should be preserved whenever possible. In certain circumstances this cannot be done. For example, if two domain names x.y and X.Y are entered into the domain database, they are interpreted as the same name, and hence may have a single representation. The basic rule is that case can be discarded only when data is used to define structure in a database, and two names are identical when compared in a case insensitive manner. Loss of case sensitive data must be minimized. Thus while data for x.y and X.Y may both be stored under x.y, data for a.x and B.X can be stored as a.x and B.x, but not A.x, A.X, b.x, or b.X. In general, this prevents the first component of a domain name from loss of case information. Systems administrators who enter data into the domain database should take care to represent the data they supply to the domain system in a case-consistent manner if their system is case-sensitive. The data distribution system in the domain system will ensure that consistent representations are preserved. Mockapetris [Page 7]
RFC 883 November 1983 Domain Names - Implementation and Specification Design philosophy The design presented in this memo attempts to provide a base which will be suitable for several existing networks. An equally important goal is to provide these services within a framework that is capable of adjustment to fit the evolution of services in early clients as well as to accommodate new networks. Since it is impossible to predict the course of these developments, the domain system attempts to provide for evolution in the form of an extensible framework. This section describes the areas in which we expect to see immediate evolution. DEFINING THE DATABASE This memo defines methods for partitioning the database and data for host names, host addresses, gateway information, and mail support. Experience with this system will provide guidance for future additions. While the present system allows for many new RR types, classes, etc., we feel that it is more important to get the basic services in operation than to cover an exhaustive set of information. Hence we have limited the data types to those we felt were essential, and would caution designers to avoid implementations which are based on the number of existing types and classes. Extensibility in this area is very important. While the domain system provides techniques for partitioning the database, policies for administrating the orderly connection of separate domains and guidelines for constructing the data that makes up a particular domain will be equally important to the success of the system. Unfortunately, we feel that experience with prototype systems will be necessary before this question can be properly addressed. Thus while this memo has minimal discussion of these issues, it is a critical area for development. TYING TOGETHER INTERNETS Although it is very difficult to characterize the types of networks, protocols, and applications that will be clients of the domain system, it is very obvious that some of these applications will cross the boundaries of network and protocol. At the very least, mail is such a service. Attempts to unify two such systems must deal with two major problems: 1. Differing formats for environment sensitive data. For example, Mockapetris [Page 8]
RFC 883 November 1983 Domain Names - Implementation and Specification network addresses vary in format, and it is unreasonable to expect to enforce consistent conventions. 2. Connectivity may require intermediaries. For example, it is a frequent occurence that mail is sent between hosts that share no common protocol. The domain system acknowledges that these are very difficult problems, and attempts to deal with both problems through its CLASS mechanism: 1. The CLASS field in RRs allows data to be tagged so that all programs in the domain system can identify the format in use. 2. The CLASS field allows the requestor to identify the format of data which can be understood by the requestor. 3. The CLASS field guides the search for the requested data. The last point is central to our approach. When a query crosses protocol boundaries, it must be guided though agents capable of performing whatever translation is required. For example, when a mailer wants to identify the location of a mailbox in a portion of the domain system that doesn't have a compatible protocol, the query must be guided to a name server that can cross the boundary itself or form one link in a chain that can span the differences. If query and response transport were the only problem, then this sort of problem could be dealt with in the name servers themselves. However, the applications that will use domain service have similar problems. For example, mail may need to be directed through mail gateways, and the characteristics of one of the environments may not permit frequent connectivity between name servers in all environments. These problems suggest that connectivity will be achieved through a variety of measures: Translation name servers that act as relays between different protocols. Translation application servers that translate application level transactions. Default database entries that route traffic through application level forwarders in ways that depend on the class of the requestor. While this approach seems best given our current understanding of Mockapetris [Page 9]
RFC 883 November 1983 Domain Names - Implementation and Specification the problem, we realize that the approach of using resource data that transcends class may be appropriate in future designs or applications. By not defining class to be directly related to protocol, network, etc., we feel that such services could be added by defining a new "universal" class, while the present use of class will provide immediate service. This problem requires more thought and experience before solutions can be discovered. The concepts of CLASS, recursive servers and other mechanisms are intended as tools for acquiring experience and not as final solutions. Mockapetris [Page 10]
RFC 883 November 1983 Domain Names - Implementation and Specification NAME SERVER TRANSACTIONS Introduction The primary purpose of name servers is to receive queries from resolvers and return responses. The overall model of this service is that a program (typically a resolver) asks the name server questions (queries) and gets responses that either answer the question or refer the questioner to another name server. Other functions related to name server database maintenance use similar procedures and formats and are discussed in a section later in this memo. There are three kinds of queries presently defined: 1. Standard queries that ask for a specified resource attached to a given domain name. 2. Inverse queries that specify a resource and ask for a domain name that possesses that resource. 3. Completion queries that specify a partial domain name and a target domain and ask that the partial domain name be completed with a domain name close to the target domain. This memo uses an unqualified reference to queries to refer to either all queries or standard queries when the context is clear. Query and response transport Name servers and resolvers use a single message format for all communications. The message format consists of a variable-length octet string which includes binary values. The messages used in the domain system are designed so that they can be carried using either datagrams or virtual circuits. To accommodate the datagram style, all responses carry the query as part of the response. While the specification allows datagrams to be used in any context, some activities are ill suited to datagram use. For example, maintenance transactions and recursive queries typically require the error control of virtual circuits. Thus datagram use should be restricted to simple queries. The domain system assumes that a datagram service provides: 1. A non-reliable (i.e. best effort) method of transporting a message of up to 512 octets. Mockapetris [Page 11]
RFC 883 November 1983 Domain Names - Implementation and Specification Hence datagram messages are limited to 512 octets. If a datagram message would exceed 512 octets, it is truncated and a truncation flag is set in its header. 2. A message size that gives the number of octets in the datagram. The main implications for programs accessing name servers via datagrams are: 1. Datagrams should not be used for maintenance transactions and recursive queries. 2. Since datagrams may be lost, the originator of a query must perform error recovery (such as retransmissions) as appropriate. 3. Since network or host delay may cause retransmission when a datagram has not been lost, the originator of a query must be ready to deal with duplicate responses. The domain system assumes that a virtual circuit service provides: 1. A reliable method of transmitting a message of up to 65535 octets. 2. A message size that gives the number of octets in the message. If the virtual circuit service does not provide for message boundary detection or limits transmission size to less than 65535 octets, then messages are prefaced with an unsigned 16 bit length field and broken up into separate transmissions as required. The length field is only prefaced on the first message. This technique is used for TCP virtual circuits. 3. Multiple messages may be sent over a virtual circuit. 4. A method for closing a virtual circuit. 5. A method for detecting that the other party has requested that the virtual circuit be closed. The main implications for programs accessing name servers via virtual circuits are: 1. Either end of a virtual circuit may initiate a close when there is no activity in progress. The other end should comply. Mockapetris [Page 12]
RFC 883 November 1983 Domain Names - Implementation and Specification The decision to initiate a close is a matter of individual site policy; some name servers may leave a virtual circuit open for an indeterminate period following a query to allow for subsequent queries; other name servers may choose to initiate a close following the completion of the first query on a virtual circuit. Of course, name servers should not close the virtual circuit in the midst of a multiple message stream used for zone transfer. 2. Since network delay may cause one end to erroneously believe that no activity is in progress, a program which receives a virtual circuit close while a query is in progress should close the virtual circuit and resubmit the query on a new virtual circuit. All messages may use a compression scheme to reduce the space consumed by repetitive domain names. The use of the compression scheme is optional for the sender of a message, but all receivers must be capable of decoding compressed domain names. Overall message format All messages sent by the domain system are divided into 5 sections (some of which are empty in certain cases) shown below: +---------------------+ | Header | +---------------------+ | Question | the question for the name server +---------------------+ | Answer | answering resource records (RRs) +---------------------+ | Authority | RRs pointing toward an authority +---------------------+ | Additional | RRs holding pertinent information +---------------------+ The header section is always present. The header includes fields that specify which of the remaining sections are present, and also specify whether the message is a query, inverse query, completion query, or response. The question section contains fields that describe a question to a name server. These fields are a query type (QTYPE), a query class (QCLASS), and a query domain name (QNAME). The last three sections have the same format: a possibly empty list of concatenated resource records (RRs). The answer section contains RRs that answer the question; the authority section Mockapetris [Page 13]
RFC 883 November 1983 Domain Names - Implementation and Specification contains RRs that point toward an authoritative name server; the additional records section contains RRs which relate to the query, but are not strictly answers for the question. The next two sections of this memo illustrate the use of these message sections through examples; a detailed discussion of data formats follows the examples. Mockapetris [Page 14]
RFC 883 November 1983 Domain Names - Implementation and Specification The contents of standard queries and responses When a name server processes a standard query, it first determines whether it is an authority for the domain name specified in the query. If the name server is an authority, it returns either: 1. the specified resource information 2. an indication that the specified name does not exist 3. an indication that the requested resource information does not exist If the name server is not an authority for the specified name, it returns whatever relevant resource information it has along with resource records that the requesting resolver can use to locate an authoritative name server. Standard query and response example The overall structure of a query for retrieving information for Internet mail for domain F.ISI.ARPA is shown below: +-----------------------------------------+ Header | OPCODE=QUERY, ID=2304 | +-----------------------------------------+ Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA | +-----------------------------------------+ Answer | <empty> | +-----------------------------------------+ Authority | <empty> | +-----------------------------------------+ Additional | <empty> | +-----------------------------------------+ The header includes an opcode field that specifies that this datagram is a query, and an ID field that will be used to associate replies with the original query. (Some additional header fields have been omitted for clarity.) The question section specifies that the type of the query is for mail agent information, that only ARPA Internet information is to be considered, and that the domain name of interest is F.ISI.ARPA. The remaining sections are empty, and would not use any octets in a real query. Mockapetris [Page 15]
RFC 883 November 1983 Domain Names - Implementation and Specification One possible response to this query might be: +-----------------------------------------+ Header | OPCODE=RESPONSE, ID=2304 | +-----------------------------------------+ Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA | +-----------------------------------------+ Answer | <empty> | +-----------------------------------------+ Authority | ARPA NS IN A.ISI.ARPA | | ------- | | ARPA NS IN F.ISI.ARPA | +-----------------------------------------+ Additional | F.ISI.ARPA A IN 10.2.0.52 | | ------- | | A.ISI.ARPA A IN 10.1.0.22 | +-----------------------------------------+ This type of response would be returned by a name server that was not an authority for the domain name F.ISI.ARPA. The header field specifies that the datagram is a response to a query with an ID of 2304. The question section is copied from the question section in the query datagram. The answer section is empty because the name server did not have any information that would answer the query. (Name servers may happen to have cached information even if they are not authoritative for the query.) The best that this name server could do was to pass back information for the domain ARPA. The authority section specifies two name servers for the domain ARPA using the Internet family: A.ISI.ARPA and F.ISI.ARPA. Note that it is merely a coincidence that F.ISI.ARPA is a name server for ARPA as well as the subject of the query. In this case, the name server included in the additional records section the Internet addresses for the two hosts specified in the authority section. Such additional data is almost always available. Given this response, the process that originally sent the query might resend the query to the name server on A.ISI.ARPA, with a new ID of 2305. Mockapetris [Page 16]
RFC 883 November 1983 Domain Names - Implementation and Specification The name server on A.ISI.ARPA might return a response: +-----------------------------------------+ Header | OPCODE=RESPONSE, ID=2305 | +-----------------------------------------+ Question |QTYPE=MAILA, QCLASS=IN, QNAME=F.ISI.ARPA | +-----------------------------------------+ Answer | F.ISI.ARPA MD IN F.ISI.ARPA | | ------- | | F.ISI.ARPA MF IN A.ISI.ARPA | +-----------------------------------------+ Authority | <empty> | +-----------------------------------------+ Additional | F.ISI.ARPA A IN 10.2.0.52 | | ------- | | A.ISI.ARPA A IN 10.1.0.22 | +-----------------------------------------+ This query was directed to an authoritative name server, and hence the response includes an answer but no authority records. In this case, the answer section specifies that mail for F.ISI.ARPA can either be delivered to F.ISI.ARPA or forwarded to A.ISI.ARPA. The additional records section specifies the Internet addresses of these hosts. The contents of inverse queries and responses Inverse queries reverse the mappings performed by standard query operations; while a standard query maps a domain name to a resource, an inverse query maps a resource to a domain name. For example, a standard query might bind a domain name to a host address; the corresponding inverse query binds the host address to a domain name. Inverse query mappings are not guaranteed to be unique or complete because the domain system does not have any internal mechanism for determining authority from resource records that parallels the capability for determining authority as a function of domain name. In general, resolvers will be configured to direct inverse queries to a name server which is known to have the desired information. Name servers are not required to support any form of inverse queries; it is anticipated that most name servers will support address to domain name conversions, but no other inverse mappings. If a name server receives an inverse query that it does not support, it returns an error response with the "Not Implemented" error set in the header. While inverse query support is optional, all name servers must be at least able to return the error response. Mockapetris [Page 17]
RFC 883 November 1983 Domain Names - Implementation and Specification When a name server processes an inverse query, it either returns: 1. zero, one, or multiple domain names for the specified resource 2. an error code indicating that the name server doesn't support inverse mapping of the specified resource type. Inverse query and response example The overall structure of an inverse query for retrieving the domain name that corresponds to Internet address 10.2.0.52 is shown below: +-----------------------------------------+ Header | OPCODE=IQUERY, ID=997 | +-----------------------------------------+ Question | <empty> | +-----------------------------------------+ Answer | <anyname> A IN 10.2.0.52 | +-----------------------------------------+ Authority | <empty> | +-----------------------------------------+ Additional | <empty> | +-----------------------------------------+ This query asks for a question whose answer is the Internet style address 10.2.0.52. Since the owner name is not known, any domain name can be used as a placeholder (and is ignored). The response to this query might be: +-----------------------------------------+ Header | OPCODE=RESPONSE, ID=997 | +-----------------------------------------+ Question | QTYPE=A, QCLASS=IN, QNAME=F.ISI.ARPA | +-----------------------------------------+ Answer | F.ISI.ARPA A IN 10.2.0.52 | +-----------------------------------------+ Authority | <empty> | +-----------------------------------------+ Additional | <empty> | +-----------------------------------------+ Note that the QTYPE in a response to an inverse query is the same as the TYPE field in the answer section of the inverse query. Responses to inverse queries may contain multiple questions when the inverse is not unique. Mockapetris [Page 18]
RFC 883 November 1983 Domain Names - Implementation and Specification Completion queries and responses Completion queries ask a name server to complete a partial domain name and return a set of RRs whose domain names meet a specified set of criteria for "closeness" to the partial input. This type of query can provide a local shorthand for domain names or command completion similar to that in TOPS-20. Implementation of completion query processing is optional in a name server. However, a name server must return a "Not Implemented" (NI) error response if it does not support completion. The arguments in a completion query specify: 1. A type in QTYPE that specifies the type of the desired name. The type is used to restrict the type of RRs which will match the partial input so that completion queries can be used for mailbox names, host names, or any other type of RR in the domain system without concern for matches to the wrong type of resource. 2. A class in QCLASS which specifies the desired class of the RR. 3. A partial domain name that gives the input to be completed. All returned RRs will begin with the partial string. The search process first looks for names which qualify under the assumption that the partial string ends with a full label ("whole label match"); if this search fails, the search continues under the assumption that the last label in the partial sting may be an incomplete label ("partial label match"). For example, if the partial string "Smith" was used in a mailbox completion, it would match [email protected] in preference to [email protected]. The partial name is supplied by the user through the user program that is using domain services. For example, if the user program is a mail handler, the string might be "Mockap" which the user intends as a shorthand for the mailbox [email protected]; if the user program is TELNET, the user might specify "F" for F.ISI.ARPA. In order to make parsing of messages consistent, the partial name is supplied in domain name format (i.e. a sequence of labels terminated with a zero length octet). However, the trailing root label is ignored during matching. 4. A target domain name which specifies the domain which is to be examined for matches. This name is specified in the additional Mockapetris [Page 19]
RFC 883 November 1983 Domain Names - Implementation and Specification section using a NULL RR. All returned names will end with the target name. The user program which constructs the query uses the target name to restrict the search. For example, user programs running at ISI might restrict completion to names that end in ISI.ARPA; user programs running at MIT might restrict completion to the domain MIT.ARPA. The target domain name is also used by the resolver to determine the name server which should be used to process the query. In general, queries should be directed to a name server that is authoritative for the target domain name. User programs which wish to provide completion for a more than one target can issue multiple completion queries, each directed at a different target. Selection of the target name and the number of searches will depend on the goals of the user program. 5. An opcode for the query. The two types of completion queries are "Completion Query - Multiple", or CQUERYM, which asks for all RRs which could complete the specified input, and "Completion Query - Unique", or CQUERYU, which asks for the "best" completion. CQUERYM is used by user programs which want to know if ambiguities exist or wants to do its own determinations as to the best choice of the available candidates. CQUERYU is used by user programs which either do not wish to deal with multiple choices or are willing to use the closeness criteria used by CQUERYU to select the best match. When a name server receives either completion query, it first looks for RRs that begin (on the left) with the same labels as are found in QNAME (with the root deleted), and which match the QTYPE and QCLASS. This search is called "whole label" matching. If one or more hits are found the name server either returns all of the hits (CQUERYM) or uses the closeness criteria described below to eliminate all but one of the matches (CQUERYU). If the whole label match fails to find any candidates, then the name server assumes that the rightmost label of QNAME (after root deletion) is not a complete label, and looks for candidates that would match if characters were added (on the right) to the rightmost label of QNAME. If one or more hits are found the name server either returns all of the hits (CQUERYM) or uses the closeness criteria described below to eliminate all but one of the matches (CQUERYU). Mockapetris [Page 20]
RFC 883 November 1983 Domain Names - Implementation and Specification If a CQUERYU query encounters multiple hits, it uses the following sequence of rules to discard multiple hits: 1. Discard candidates that have more labels than others. Since all candidates start with the partial name and end with the target name, this means that we select those entries that require the fewest number of added labels. For example, a host search with a target of "ISI.ARPA" and a partial name of "A" will select A.ISI.ARPA in preference to A.IBM-PCS.ISI.ARPA. 2. If partial label matching was used, discard those labels which required more characters to be added. For example, a mailbox search for partial "X" and target "ISI.ARPA" would prefer [email protected] to [email protected]. If multiple hits are still present, return all hits. Completion query mappings are not guaranteed to be unique or complete because the domain system does not have any internal mechanism for determining authority from a partial domain name that parallels the capability for determining authority as a function of a complete domain name. In general, resolvers will be configured to direct completion queries to a name server which is known to have the desired information. When a name server processes a completion query, it either returns: 1. An answer giving zero, one, or more possible completions. 2. an error response with Not Implemented (NI) set. Mockapetris [Page 21]
RFC 883 November 1983 Domain Names - Implementation and Specification Completion query and response example Suppose that the completion service was used by a TELNET program to allow a user to specify a partial domain name for the desired host. Thus a user might ask to be connected to "B". Assuming that the query originated from an ISI machine, the query might look like: +-----------------------------------------+ Header | OPCODE=CQUERYU, ID=409 | +-----------------------------------------+ Question | QTYPE=A, QCLASS=IN, QNAME=B | +-----------------------------------------+ Answer | <empty> | +-----------------------------------------+ Authority | <empty> | +-----------------------------------------+ Additional | ISI.ARPA NULL IN | +-----------------------------------------+ The partial name in the query is "B", the mappings of interest are ARPA Internet address records, and the target domain is ISI.ARPA. Note that NULL is a special type of NULL resource record that is used as a placeholder and has no significance; NULL RRs obey the standard format but have no other function. The response to this completion query might be: +-----------------------------------------+ Header | OPCODE=RESPONSE, ID=409 | +-----------------------------------------+ Question | QTYPE=A, QCLASS=IN, QNAME=B | +-----------------------------------------+ Answer | B.ISI.ARPA A IN 10.3.0.52 | +-----------------------------------------+ Authority | <empty> | +-----------------------------------------+ Additional | ISI.ARPA NULL IN | +-----------------------------------------+ This response has completed B to mean B.ISI.ARPA. Mockapetris [Page 22]
RFC 883 November 1983 Domain Names - Implementation and Specification Another query might be: +-----------------------------------------+ Header | OPCODE=CQUERYM, ID=410 | +-----------------------------------------+ Question | QTYPE=A, QCLASS=IN, QNAME=B | +-----------------------------------------+ Answer | <empty> | +-----------------------------------------+ Authority | <empty> | +-----------------------------------------+ Additional | ARPA NULL IN | +-----------------------------------------+ This query is similar to the previous one, but specifies a target of ARPA rather than ISI.ARPA. It also allows multiple matches. In this case the same name server might return: +-----------------------------------------+ Header | OPCODE=RESPONSE, ID=410 | +-----------------------------------------+ Question | QTYPE=A, QCLASS=IN, QNAME=B | +-----------------------------------------+ Answer | B.ISI.ARPA A IN 10.3.0.52 | | - | | B.BBN.ARPA A IN 10.0.0.49 | | - | | B.BBNCC.ARPA A IN 8.1.0.2 | +-----------------------------------------+ Authority | <empty> | +-----------------------------------------+ Additional | ARPA NULL IN | +-----------------------------------------+ This response contains three answers, B.ISI.ARPA, B.BBN.ARPA, and B.BBNCC.ARPA. Mockapetris [Page 23]
RFC 883 November 1983 Domain Names - Implementation and Specification Recursive Name Service Recursive service is an optional feature of name servers. When a name server receives a query regarding a part of the name space which is not in one of the name server's zones, the standard response is a message that refers the requestor to another name server. By iterating on these referrals, the requestor eventually is directed to a name server that has the required information. Name servers may also implement recursive service. In this type of service, a name server either answers immediately based on local zone information, or pursues the query for the requestor and returns the eventual result back to the original requestor. A name server that supports recursive service sets the Recursion Available (RA) bit in all responses it generates. A requestor asks for recursive service by setting the Recursion Desired (RD) bit in queries. In some situations where recursive service is the only path to the desired information (see below), the name server may go recursive even if RD is zero. If a query requests recursion (RD set), but the name server does not support recursion, and the query needs recursive service for an answer, the name server returns a "Not Implemented" (NI) error code. If the query can be answered without recursion since the name server is authoritative for the query, it ignores the RD bit. Because of the difficulty in selecting appropriate timeouts and error handling, recursive service is best suited to virtual circuits, although it is allowed for datagrams. Recursive service is valuable in several special situations: In a system of small personal computers clustered around one or more large hosts supporting name servers, the recursive approach minimizes the amount of code in the resolvers in the personal computers. Such a design moves complexity out of the resolver into the name server, and may be appropriate for such systems. Name servers on the boundaries of different networks may wish to offer recursive service to create connectivity between different networks. Such name servers may wish to provide recursive service regardless of the setting of RD. Name servers that translate between domain name service and some other name service may wish to adopt the recursive style. Implicit recursion may be valuable here as well. Mockapetris [Page 24]
RFC 883 November 1983 Domain Names - Implementation and Specification These concepts are still under development. Mockapetris [Page 25]
RFC 883 November 1983 Domain Names - Implementation and Specification Header section format +-----------------------------------------------+ | | | ***** WARNING ***** | | | | The following format is preliminary and is | | included for purposes of explanation only. In | | particular, the size and position of the | | OPCODE, RCODE fields and the number and | | meaning of the single bit fields are subject | | to change. | | | +-----------------------------------------------+ The header contains the following fields: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA| | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: ID - A 16 bit identifier assigned by the program that generates any kind of query. This identifier is copied into all replies and can be used by the requestor to relate replies to outstanding questions. QR - A one bit field that specifies whether this message is a query (0), or a response (1). OPCODE - A four bit field that specifies kind of query in this message. This value is set by the originator of a query and copied into the response. The values are: 0 a standard query (QUERY) Mockapetris [Page 26]
RFC 883 November 1983 Domain Names - Implementation and Specification 1 an inverse query (IQUERY) 2 an completion query allowing multiple answers (CQUERYM) 2 an completion query requesting a single answer (CQUERYU) 4-15 reserved for future use AA - Authoritative Answer - this bit is valid in responses, and specifies that the responding name server is an authority for the domain name in the corresponding query. TC - TrunCation - specifies that this message was truncated due to length greater than 512 characters. This bit is valid in datagram messages but not in messages sent over virtual circuits. RD - Recursion Desired - this bit may be set in a query and is copied into the response. If RD is set, it directs the name server to pursue the query recursively. Recursive query support is optional. RA - Recursion Available - this be is set or cleared in a response, and denotes whether recursive query support is available in the name server. RCODE - Response code - this 4 bit field is set as part of responses. The values have the following interpretation: 0 No error condition 1 Format error - The name server was unable to interpret the query. 2 Server failure - The name server was unable to process this query due to a problem with the name server. 3 Name Error - Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced in the query does not exist. Mockapetris [Page 27]
RFC 883 November 1983 Domain Names - Implementation and Specification 4 Not Implemented - The name server does not support the requested kind of query. 5 Refused - The name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requestor, or a name server may not wish to perform a particular operation (e.g. zone transfer) for particular data. 6-15 Reserved for future use. QDCOUNT - an unsigned 16 bit integer specifying the number of entries in the question section. ANCOUNT - an unsigned 16 bit integer specifying the number of resource records in the answer section. NSCOUNT - an unsigned 16 bit integer specifying the number of name server resource records in the authority records section. ARCOUNT - an unsigned 16 bit integer specifying the number of resource records in the additional records section. Mockapetris [Page 28]
RFC 883 November 1983 Domain Names - Implementation and Specification Question section format The question section is used in all kinds of queries other than inverse queries. In responses to inverse queries, this section may contain multiple entries; for all other responses it contains a single entry. Each entry has the following format: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / QNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QTYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QCLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: QNAME - a variable number of octets that specify a domain name. This field uses the compressed domain name format described in the next section of this memo. This field can be used to derive a text string for the domain name. Note that this field may be an odd number of octets; no padding is used. QTYPE - a two octet code which specifies the type of the query. The values for this field include all codes valid for a TYPE field, together with some more general codes which can match more than one type of RR. For example, QTYPE might be A and only match type A RRs, or might be MAILA, which matches MF and MD type RRs. The values for this field are listed in Appendix 2. QCLASS - a two octet code that specifies the class of the query. For example, the QCLASS field is IN for the ARPA Internet, CS for the CSNET, etc. The numerical values are defined in Appendix 2. Mockapetris [Page 29]
RFC 883 November 1983 Domain Names - Implementation and Specification Resource record format The answer, authority, and additional sections all share the same format: a variable number of resource records, where the number of records is specified in the corresponding count field in the header. Each resource record has the following format: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: NAME - a compressed domain name to which this resource record pertains. TYPE - two octets containing one of the RR type codes defined in Appendix 2. This field specifies the meaning of the data in the RDATA field. CLASS - two octets which specify the class of the data in the RDATA field. TTL - a 16 bit unsigned integer that specifies the time interval (in seconds) that the resource record may be cached before it should be discarded. Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be cached. For example, SOA records are always distributed with a zero TTL to prohibit caching. Zero values can also be used for extremely volatile data. Mockapetris [Page 30]
RFC 883 November 1983 Domain Names - Implementation and Specification RDLENGTH- an unsigned 16 bit integer that specifies the length in octets of the RDATA field. RDATA - a variable length string of octets that describes the resource. The format of this information varies according to the TYPE and CLASS of the resource record. For example, the if the TYPE is A and the CLASS is IN, the RDATA field is a 4 octet ARPA Internet address. Formats for particular resource records are shown in Appendicies 2 and 3. Domain name representation and compression Domain names messages are expressed in terms of a sequence of labels. Each label is represented as a one octet length field followed by that number of octets. Since every domain name ends with the null label of the root, a compressed domain name is terminated by a length byte of zero. The high order two bits of the length field must be zero, and the remaining six bits of the length field limit the label to 63 octets or less. To simplify implementations, the total length of label octets and label length octets that make up a domain name is restricted to 255 octets or less. Since the trailing root label and its dot are not printed, printed domain names are 254 octets or less. Although labels can contain any 8 bit values in octets that make up a label, it is strongly recommended that labels follow the syntax described in Appendix 1 of this memo, which is compatible with existing host naming conventions. Name servers and resolvers must compare labels in a case-insensitive manner, i.e. A=a, and hence all character strings must be ASCII with zero parity. Non-alphabetic codes must match exactly. Whenever possible, name servers and resolvers must preserve all 8 bits of domain names they process. When a name server is given data for the same name under two different case usages, this preservation is not always possible. For example, if a name server is given data for ISI.ARPA and isi.arpa, it should create a single node, not two, and hence will preserve a single casing of the label. Systems with case sensitivity should take special precautions to insure that the domain data for the system is created with consistent case. In order to reduce the amount of space used by repetitive domain names, the sequence of octets that defines a domain name may be terminated by a pointer to the length octet of a previously specified label string. The label string that the pointer Mockapetris [Page 31]
RFC 883 November 1983 Domain Names - Implementation and Specification specifies is appended to the already specified label string. Exact duplication of a previous label string can be done with a single pointer. Multiple levels are allowed. Pointers can only be used in positions in the message where the format is not class specific. If this were not the case, a name server that was handling a RR for another class could make erroneous copies of RRs. As yet, there are no such cases, but they may occur in future RDATA formats. If a domain name is contained in a part of the message subject to a length field (such as the RDATA section of an RR), and compression is used, the length of the compressed name is used in the length calculation, rather than the length of the expanded name. Pointers are represented as a two octet field in which the high order 2 bits are ones, and the low order 14 bits specify an offset from the start of the message. The 01 and 10 values of the high order bits are reserved for future use and should not be used. Programs are free to avoid using pointers in datagrams they generate, although this will reduce datagram capacity. However all programs are required to understand arriving messages that contain pointers. For example, a datagram might need to use the domain names F.ISI.ARPA, FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the other fields of the message, these domain names might be represented as: Mockapetris [Page 32]
RFC 883 November 1983 Domain Names - Implementation and Specification +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 20 | 1 | F | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 22 | 3 | I | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 24 | S | I | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 26 | 4 | A | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 28 | R | P | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 30 | A | 0 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 40 | 3 | F | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 42 | O | O | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 44 | 1 1| 20 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 64 | 1 1| 26 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 92 | 0 | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ The domain name for F.ISI.ARPA is shown at offset 20. The domain name FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to concatenate a label for FOO to the previously defined F.ISI.ARPA. The domain name ARPA is defined at offset 64 using a pointer to the ARPA component of the name F.ISI.ARPA at 20; note that this reference relies on ARPA being the last label in the string at 20. The root domain name is defined by a single octet of zeros at 92; the root domain name has no labels. Organization of the Shared database While name server implementations are free to use any internal data structures they choose, the suggested structure consists of several separate trees. Each tree has structure corresponding to the domain name space, with RRs attached to nodes and leaves. Each zone of authoritative data has a separate tree, and one tree holds all non-authoritative data. All of the trees corresponding to zones are managed identically, but the non-authoritative or cache tree has different management procedures. Mockapetris [Page 33]
RFC 883 November 1983 Domain Names - Implementation and Specification Data stored in the database can be kept in whatever form is convenient for the name server, so long as it can be transformed back into the format needed for messages. In particular, the database will probably use structure in place of expanded domain names, and will also convert many of the time intervals used in the domain systems to absolute local times. Each tree corresponding to a zone has complete information for a "pruned" subtree of the domain space. The top node of a zone has a SOA record that marks the start of the zone. The bottom edge of the zone is delimited by nodes containing NS records signifying delegation of authority to other zones, or by leaves of the domain tree. When a name server contains abutting zones, one tree will have a bottom node containing a NS record, and the other tree will begin with a tree location containing a SOA record. Note that there is one special case that requires consideration when a name server is implemented. A node that contains a SOA RR denoting a start of zone will also have NS records that identify the name servers that are expected to have a copy of the zone. Thus a name server will usually find itself (and possibly other redundant name servers) referred to in NS records occupying the same position in the tree as SOA records. The solution to this problem is to never interpret a NS record as delimiting a zone started by a SOA at the same point in the tree. (The sample programs in this memo deal with this problem by processing SOA records only after NS records have been processed.) Zones may also overlap a particular part of the name space when they are of different classes. Other than the abutting and separate class cases, trees are always expected to be disjoint. Overlapping zones are regarded as a non-fatal error. The scheme described in this memo avoids the overlap issue by maintaining separate trees; other designs must take the appropriate measures to defend against possible overlap. Non-authoritative data is maintained in a separate tree. This tree is unlike the zone trees in that it may have "holes". Each RR in the cache tree has its own TTL that is separately managed. The data in this tree is never used if authoritative data is available from a zone tree; this avoids potential problems due to cached data that conflicts with authoritative data. The shared database will also contain data structures to support the processing of inverse queries and completion queries if the local system supports these optional features. Although many schemes are possible, this memo describes a scheme that is based on tables of pointers that invert the database according to key. Mockapetris [Page 34]
RFC 883 November 1983 Domain Names - Implementation and Specification Each kind of retrieval has a separate set of tables, with one table per zone. When a zone is updated, these tables must also be updated. The contents of these tables are discussed in the "Inverse query processing" and "Completion query processing" sections of this memo. The database implementation described here includes two locks that are used to control concurrent access and modification of the database by name server query processing, name server maintenance operations, and resolver access: The first lock ("main lock") controls access to all of the trees. Multiple concurrent reads are allowed, but write access can only be acquired by a single process. Read and write access are mutually exclusive. Resolvers and name server processes that answer queries acquire this lock in read mode, and unlock upon completion of the current message. This lock is acquired in write mode by a name server maintenance process when it is about to change data in the shared database. The actual update procedures are described under "NAME SERVER MAINTENANCE" but are designed to be brief. The second lock ("cache queue lock") controls access to the cache queue. This queue is used by a resolver that wishes to add information to the cache tree. The resolver acquires this lock, then places the RRs to be cached into the queue. The name server maintenance procedure periodically acquires this lock and adds the queue information to the cache. The rationale for this procedure is that it allows the resolver to operate with read-only access to the shared database, and allows the update process to batch cache additions and the associated costs for inversion calculations. The name server maintenance procedure must take appropriate precautions to avoid problems with data already in the cache, inversions, etc. This organization solves several difficulties: When searching the domain space for the answer to a query, a name server can restrict its search for authoritative data to that tree that matches the most labels on the right side of the domain name of interest. Since updates to a zone must be atomic with respect to searches, maintenance operations can simply acquire the main lock, insert a new copy of a particular zone without disturbing other zones, and then release the storage used by the old copy. Assuming a central table pointing to valid zone trees, this operation can be a simple pointer swap. Mockapetris [Page 35]
RFC 883 November 1983 Domain Names - Implementation and Specification TTL management of zones can be performed using the SOA record for the zone. This avoids potential difficulties if individual RRs in a zone could be timed out separately. This issue is discussed further in the maintenance section. Query processing The following algorithm outlines processing that takes place at a name server when a query arrives: 1. Search the list of zones to find zones which have the same class as the QCLASS field in the query and have a top domain name that matches the right end of the QNAME field. If there are none, go to step 2. If there are more than one, pick the zone that has the longest match and go to step 3. 2. Since the zone search failed, the only possible RRs are contained in the non-authoritative tree. Search the cache tree for the NS record that has the same class as the QCLASS field and the largest right end match for domain name. Add the NS record or records to the authority section of the response. If the cache tree has RRs that are pertinent to the question (domain names match, classes agree, not timed-out, and the type field is relevant to the QTYPE), copy these RRs into the answer section of the response. The name server may also search the cache queue. Go to step 4. 3. Since this zone is the best match, the zone in which QNAME resides is either this zone or a zone to which this zone will directly or indirectly delegate authority. Search down the tree looking for a NS RR or the node specified by QNAME. If the node exists and has no NS record, copy the relevant RRs to the answer section of the response and go to step 4. If a NS RR is found, either matching a part or all of QNAME, then QNAME is in a delegated zone outside of this zone. If so, copy the NS record or records into the authority section of the response, and search the remainder of the zone for an A type record corresponding to the NS reference. If the A record is found, add it to the additional section. Go to step 2. If the node is not found and a NS is not found, there is no such name; set the Name error bit in the response and exit. 4. When this step is reached, the answer and authority sections are complete. What remains is to complete the additional section. This procedure is only possible if the name server Mockapetris [Page 36]
RFC 883 November 1983 Domain Names - Implementation and Specification knows the data formats implied by the class of records in the answer and authority sections. Hence this procedure is class dependent. Appendix 3 discusses this procedure for Internet class data. While this algorithm deals with typical queries and databases, several additions are required that will depend on the database supported by the name server: QCLASS=* Special procedures are required when the QCLASS of the query is "*". If the database contains several classes of data, the query processing steps above are performed separately for each CLASS, and the results are merged into a single response. The name error condition is not meaningful for a QCLASS=* query. If the requestor wants this information, it must test each class independently. If the database is limited to data of a particular class, this operation can be performed by simply reseting the authoritative bit in the response, and performing the query as if QCLASS was the class used in the database. * labels in database RRs Some zones will contain default RRs that use * to match in cases where the search fails for a particular domain name. If the database contains these records then a failure must be retried using * in place of one or more labels of the search key. The procedure is to replace labels from the left with "*"s looking for a match until either all labels have been replaced, or a match is found. Note that these records can never be the result of caching, so a name server can omit this processing for zones that don't contain RRs with * in labels, or can omit this processing entirely if * never appears in local authoritative data. Inverse query processing Name servers that support inverse queries can support these operations through exhaustive searches of their databases, but this becomes impractical as the size of the database increases. An alternative approach is to invert the database according to the search key. For name servers that support multiple zones and a large amount of data, the recommended approach is separate inversions for each Mockapetris [Page 37]
RFC 883 November 1983 Domain Names - Implementation and Specification zone. When a particular zone is changed during a refresh, only its inversions need to be redone. Support for transfer of this type of inversion may be included in future versions of the domain system, but is not supported in this version. Completion query processing Completion query processing shares many of the same problems in data structure design as are found in inverse queries, but is different due to the expected high rate of use of top level labels (ie., ARPA, CSNET). A name server that wishes to be efficient in its use of memory may well choose to invert only occurrences of ARPA, etc. that are below the top level, and use a search for the rare case that top level labels are used to constrain a completion. Mockapetris [Page 38]
RFC 883 November 1983 Domain Names - Implementation and Specification NAME SERVER MAINTENANCE Introduction Name servers perform maintenance operations on their databases to insure that the data they distribute is accurate and timely. The amount and complexity of the maintenance operations that a name server must perform are related to the size, change rate, and complexity of the database that the name server manages. Maintenance operations are fundamentally different for authoritative and non-authoritative data. A name server actively attempts to insure the accuracy and timeliness of authoritative data by refreshing the data from master copies. Non-authoritative data is merely purged when its time-to-live expires; the name server does not attempt to refresh it. Although the refreshing scheme is fairly simple to implement, it is somewhat less powerful than schemes used in other distributed database systems. In particular, an update to the master does not immediately update copies, and should be viewed as gradually percolating though the distributed database. This is adequate for the vast majority of applications. In situations where timliness is critical, the master name server can prohibit caching of copies or assign short timeouts to copies. Conceptual model of maintenance operations The vast majority of information in the domain system is derived from master files scattered among hosts that implement name servers; some name servers will have no master files, other name servers will have one or more master files. Each master file contains the master data for a single zone of authority rather than data for the whole domain name space. The administrator of a particular zone controls that zone by updating its master file. Master files and zone copies from remote servers may include RRs that are outside of the zone of authority when a NS record delegates authority to a domain name that is a descendant of the domain name at which authority is delegated. These forward references are a problem because there is no reasonable method to guarantee that the A type records for the delegatee are available unless they can somehow be attached to the NS records. For example, suppose the ARPA zone delegates authority at MIT.ARPA, and states that the name server is on AI.MIT.ARPA. If a resolver gets the NS record but not the A type record for AI.MIT.ARPA, it might try to ask the MIT name server for the address of AI.MIT.ARPA. Mockapetris [Page 39]
RFC 883 November 1983 Domain Names - Implementation and Specification The solution is to allow type A records that are outside of the zone of authority to be copied with the zone. While these records won't be found in a search for the A type record itself, they can be protected by the zone refreshing system, and will be passed back whenever the name server passes back a referral to the corresponding NS record. If a query is received for the A record, the name server will pass back a referral to the name server with the A record in the additional section, rather than answer section. The only exception to the use of master files is a small amount of data stored in boot files. Boot file data is used by name servers to provide enough resource records to allow zones to be imported from foreign servers (e.g. the address of the server), and to establish the name and address of root servers. Boot file records establish the initial contents of the cache tree, and hence can be overridden by later loads of authoritative data. The data in a master file first becomes available to users of the domain name system when it is loaded by the corresponding name server. By definition, data from a master file is authoritative. Other name servers which wish to be authoritative for a particular zone do so by transferring a copy of the zone from the name server which holds the master copy using a virtual circuit. These copies include parameters which specify the conditions under which the data in the copy is authoritative. In the most common case, the conditions specify a refresh interval and policies to be followed when the refresh operation cannot be performed. A name server may acquire multiple zones from different name servers and master files, but the name server must maintain each zone separately from others and from non-authoritative data. When the refresh interval for a particular zone copy expires, the name server holding the copy must consult the name server that holds the master copy. If the data in the zone has not changed, the master name server instructs the copy name server to reset the refresh interval. If the data has changed, the master passes a new copy of the zone and its associated conditions to the copy name server. Following either of these transactions, the copy name server begins a new refresh interval. Copy name servers must also deal with error conditions under which they are unable to communicate with the name server that holds the master copy of a particular zone. The policies that a copy name server uses are determined by other parameters in the conditions distributed with every copy. The conditions include a retry interval and a maximum holding time. When a copy name server is Mockapetris [Page 40]
RFC 883 November 1983 Domain Names - Implementation and Specification unable to establish communications with a master or is unable to complete the refresh transaction, it must retry the refresh operation at the rate specified by the retry interval. This retry interval will usually be substantially shorter than the refresh interval. Retries continue until the maximum holding time is reached. At that time the copy name server must assume that its copy of the data for the zone in question is no longer authoritative. Queries must be processed while maintenance operations are in progress because a zone transfer can take a long time. However, to avoid problems caused by access to partial databases, the maintenance operations create new copies of data rather than directly modifying the old copies. When the new copy is complete, the maintenance process locks out queries for a short time using the main lock, and switches pointers to replace the old data with the new. After the pointers are swapped, the maintenance process unlocks the main lock and reclaims the storage used by the old copy. Name server data structures and top level logic The name server must multiplex its attention between multiple activities. For example, a name server should be able to answer queries while it is also performing refresh activities for a particular zone. While it is possible to design a name server that devotes a separate process to each query and refresh activity in progress, the model described in this memo is based on the assumption that there is a single process performing all maintenance operations, and one or more processes devoted to handling queries. The model also assumes the existence of shared memory for several control structures, the domain database, locks, etc. The model name server uses the following files and shared data structures: 1. A configuration file that describes the master and boot files which the name server should load and the zones that the name server should attempt to load from foreign name servers. This file establishes the initial contents of the status table. 2. Domain data files that contain master and boot data to be loaded. 3. A status table that is derived from the configuration file. Each entry in this table describes a source of data. Each entry has a zone number. The zone number is zero for Mockapetris [Page 41]
RFC 883 November 1983 Domain Names - Implementation and Specification non-authoritative sources; authoritative sources are assigned separate non-zero numbers. 4. The shared database that holds the domain data. This database is assumed to be organized in some sort of tree structure paralleling the domain name space, with a list of resource records attached to each node and leaf in the tree. The elements of the resource record list need not contain the exact data present in the corresponding output format, but must contain data sufficient to create the output format; for example, these records need not contain the domain name that is associated with the resource because that name can be derived from the tree structure. Each resource record also internal data that the name server uses to organize its data. 5. Inversion data structures that allow the name server to process inverse queries and completion queries. Although many structures could be used, the implementation described in this memo supposes that there is one array for every inversion that the name server can handle. Each array contains a list of pointers to resource records such that the order of the inverted quantities is sorted. 6. The main and cache queue locks 7. The cache queue The maintenance process begins by loading the status table from the configuration file. It then periodically checks each entry, to see if its refresh interval has elapsed. If not, it goes on to the next entry. If so, it performs different operations depending on the entry: If the entry is for zone 0, or the cache tree, the maintenance process checks to see if additions or deletions are required. Additions are acquired from the cache queue using the cache queue lock. Deletions are detected using TTL checks. If any changes are required, the maintenance process recalculates inversion data structures and then alters the cache tree under the protection of the main lock. Whenever the maintenance process modifies the cache tree, it resets the refresh interval to the minimum of the contained TTLs and the desired time interval for cache additions. If the entry is not zone 0, and the entry refers to a local file, the maintenance process checks to see if the file has been modified since its last load. If so the file is reloaded using the procedures specified under "Name server file Mockapetris [Page 42]
RFC 883 November 1983 Domain Names - Implementation and Specification loading". The refresh interval is reset to that specified in the SOA record if the file is a master file. If the entry is for a remote master file, the maintenance process checks for a new version using the procedure described in "Names server remote zone transfer". Name server file loading Master files are kept in text form for ease of editing by system maintainers. These files are not exchanged by name servers; name servers use the standard message format when transferring zones. Organizations that want to have a domain, but do not want to run a name server, can use these files to supply a domain definition to another organization that will run a name server for them. For example, if organization X wants a domain but not a name server, it can find another organization, Y, that has a name server and is willing to provide service for X. Organization X defines domain X via the master file format and ships a copy of the master file to organization Y via mail, FTP, or some other method. A system administrator at Y configures Y's name server to read in X's file and hence support the X domain. X can maintain the master file using a text editor and send new versions to Y for installation. These files have a simple line-oriented format, with one RR per line. Fields are separated by any combination of blanks and tab characters. Tabs are treated the same as spaces; in the following discussion the term "blank" means either a tab or a blank. A line can be either blank (and ignored), a RR, or a $INCLUDE line. If a RR line starts with a domain name, that domain name is used to specify the location in the domain space for the record, i.e. the owner. If a RR line starts with a blank, it is loaded into the location specified by the most recent location specifier. The location specifiers are assumed to be relative to some origin that is provided by the user of a file unless the location specifier contains the root label. This provides a convenient shorthand notation, and can also be used to prevent errors in master files from propagating into other zones. This feature is particularly useful for master files imported from other sites. An include line begins with $INCLUDE, starting at the first line position, and is followed by a local file name and an optional offset modifier. The filename follows the appropriate local conventions. The offset is one or more labels that are added to the offset in use for the file that contained the $INCLUDE. If the offset is omitted, the included file is loaded using the Mockapetris [Page 43]
RFC 883 November 1983 Domain Names - Implementation and Specification offset of the file that contained the $INCLUDE command. For example, a file being loaded at offset ARPA might contain the following lines: $INCLUDE <subsys>isi.data ISI $INCLUDE <subsys>addresses.data The first line would be interpreted to direct loading of the file <subsys>isi.data at offset ISI.ARPA. The second line would be interpreted as a request to load data at offset ARPA. Note that $INCLUDE commands do not cause data to be loaded into a different zone or tree; they are simply ways to allow data for a given zone to be organized in separate files. For example, mailbox data might be kept separately from host data using this mechanism. Resource records are entered as a sequence of fields corresponding to the owner name, TTL, CLASS, TYPE and RDATA components. (Note that this order is different from the order used in examples and the order used in the actual RRs; the given order allows easier parsing and defaulting.) The owner name is derived from the location specifier. The TTL field is optional, and is expressed as a decimal number. If omitted TTL defaults to zero. The CLASS field is also optional; if omitted the CLASS defaults to the most recent value of the CLASS field in a previous RR. The RDATA fields depend on the CLASS and TYPE of the RR. In general, the fields that make up RDATA are expressed as decimal numbers or as domain names. Some exceptions exist, and are documented in the RDATA definitions in Appendicies 2 and 3 of this memo. Because CLASS and TYPE fields don't contain any common identifiers, and because CLASS and TYPE fields are never decimal numbers, the parse is always unique. Because these files are text files several special encodings are necessary to allow arbitrary data to be loaded. In particular: . A free standing dot is used to refer to the current domain name. @ A free standing @ is used to denote the current origin. Mockapetris [Page 44]
RFC 883 November 1983 Domain Names - Implementation and Specification .. Two free standing dots represent the null domain name of the root. \X where X is any character other than a digit (0-9), is used to quote that character so that its special meaning does not apply. For example, "\." can be used to place a dot character in a label. \DDD where each D is a digit is the octet corresponding to the decimal number described by DDD. The resulting octet is assumed to be text and is not checked for special meaning. ( ) Parentheses are used to group data that crosses a line boundary. In effect, line terminations are not recognized within parentheses. ; Semicolon is used to start a comment; the remainder of the line is ignored. Name server file loading example A name server for F.ISI.ARPA , serving as an authority for the ARPA and ISI.ARPA domains, might use a boot file and two master files. The boot file initializes some non-authoritative data, and would be loaded without an origin: .. 9999999 IN NS B.ISI.ARPA 9999999 CS NS UDEL.CSNET B.ISI.ARPA 9999999 IN A 10.3.0.52 UDEL.CSNET 9999999 CS A 302-555-0000 This file loads non-authoritative data which provides the identities and addresses of root name servers. The first line contains a NS RR which is loaded at the root; the second line starts with a blank, and is loaded at the most recent location specifier, in this case the root; the third and fourth lines load RRs at B.ISI.ARPA and UDEL.CSNET, respectively. The timeouts are set to high values (9999999) to prevent this data from being discarded due to timeout. The first master file loads authoritative data for the ARPA domain. This file is designed to be loaded with an origin of ARPA, which allows the location specifiers to omit the trailing .ARPA labels. Mockapetris [Page 45]
RFC 883 November 1983 Domain Names - Implementation and Specification @ IN SOA F.ISI.ARPA Action.E.ISI.ARPA ( 20 ; SERIAL 3600 ; REFRESH 600 ; RETRY 3600000; EXPIRE 60) ; MINIMUM NS F.ISI.ARPA ; F.ISI.ARPA is a name server for ARPA NS A.ISI.ARPA ; A.ISI.ARPA is a name server for ARPA MIT NS AI.MIT.ARPA; delegation to MIT name server ISI NS F.ISI.ARPA ; delegation to ISI name server UDEL MD UDEL.ARPA A 10.0.0.96 NBS MD NBS.ARPA A 10.0.0.19 DTI MD DTI.ARPA A 10.0.0.12 AI.MIT A 10.2.0.6 F.ISI A 10.2.0.52 The first group of lines contains the SOA record and its parameters, and identifies name servers for this zone and for delegated zones. The Action.E.ISI.ARPA field is a mailbox specification for the responsible person for the zone, and is the domain name encoding of the mail destination [email protected]. The second group specifies data for domain names within this zone. The last group has forward references for name server address resolution for AI.MIT.ARPA and F.ISI.ARPA. This data is not technically within the zone, and will only be used for additional record resolution for NS records used in referrals. However, this data is protected by the zone timeouts in the SOA, so it will persist as long as the NS references persist. The second master file defines the ISI.ARPA environment, and is loaded with an origin of ISI.ARPA: @ IN SOA F.ISI.ARPA Action\.ISI.E.ISI.ARPA ( 20 ; SERIAL 7200 ; REFRESH 600 ; RETRY 3600000; EXPIRE 60) ; MINIMUM NS F.ISI.ARPA ; F.ISI.ARPA is a name server A A 10.1.0.32 MD A.ISI.ARPA MF F.ISI.ARPA B A 10.3.0.52 MD B.ISI.ARPA Mockapetris [Page 46]
RFC 883 November 1983 Domain Names - Implementation and Specification MF F.ISI.ARPA F A 10.2.0.52 MD F.ISI.ARPA MF A.ISI.ARPA $INCLUDE <SUBSYS>ISI-MAILBOXES.TXT Where the file <SUBSYS>ISI-MAILBOXES.TXT is: MOE MB F.ISI.ARPA LARRY MB A.ISI.ARPA CURLEY MB B.ISI.ARPA STOOGES MB B.ISI.ARPA MG MOE.ISI.ARPA MG LARRY.ISI.ARPA MG CURLEY.ISI.ARPA Note the use of the \ character in the SOA RR to specify the responsible person mailbox "[email protected]". Name server remote zone transfer When a name server needs to make an initial copy of a zone or test to see if a existing zone copy should be refreshed, it begins by attempting to open a virtual circuit to the foreign name server. If this open attempt fails, and this was an initial load attempt, it schedules a retry and exits. If this was a refresh operation, the name server tests the status table to see if the maximum holding time derived from the SOA EXPIRE field has elapsed. If not, the name server schedules a retry. If the maximum holding time has expired, the name server invalidates the zone in the status table, and scans all resource records tagged with this zone number. For each record it decrements TTL fields by the length of time since the data was last refreshed. If the new TTL value is negative, the record is deleted. If the TTL value is still positive, it moves the RR to the cache tree and schedules a retry. If the open attempt succeeds, the name server sends a query to the foreign name server in which QTYPE=SOA, QCLASS is set according to the status table information from the configuration file, and QNAME is set to the domain name of the zone of interest. The foreign name server will return either a SOA record indicating that it has the zone or an error. If an error is detected, the virtual circuit is closed, and the failure is treated in the same way as if the open attempt failed. If the SOA record is returned and this was a refresh, rather than an initial load of the zone, the name server compares the SERIAL Mockapetris [Page 47]
RFC 883 November 1983 Domain Names - Implementation and Specification field in the new SOA record with the SERIAL field in the SOA record of the existing zone copy. If these values match, the zone has not been updated since the last copy and hence there is no reason to recopy the zone. In this case the name server resets the times in the existing SOA record and closes the virtual circuit to complete the operation. If this is initial load, or the SERIAL fields were different, the name server requests a copy of the zone by sending the foreign name server an AXFR query which specifies the zone by its QCLASS and QNAME fields. When the foreign name server receives the AXFR request, it sends each node from the zone to the requestor in a separate message. It begins with the node that contains the SOA record, walks the tree in breadth-first order, and completes the transfer by resending the node containing the SOA record. Several error conditions are possible: If the AXFR request cannot be matched to a SOA, the foreign name server will return a single message in response that does not contain the AXFR request. (The normal SOA query preceding the AXFR is designed to avoid this condition, but it is still possible.) The foreign name server can detect an internal error or detect some other condition (e.g. system going down, out of resources, etc.) that forces the transfer to be aborted. If so, it sends a message with the "Server failure" condition set. If the AXFR can be immediately retried with some chance of success, it leaves the virtual open; otherwise it initiates a close. If the foreign name server doesn't wish to perform the operation for policy reasons (i.e. the system administrator wishes to forbid zone copies), the foreign server returns a "Refused" condition. The requestor receives these records and builds a new tree. This tree is not yet in the status table, so its data are not used to process queries. The old copy of the zone, if any, may be used to satisfy request while the transfer is in progress. When the requestor receives the second copy of the SOA node, it compares the SERIAL field in the first copy of the SOA against the SERIAL field in the last copy of the SOA record. If these don't match, the foreign server updated its zone while the transfer was in progress. In this case the requestor repeats the AXFR request to acquire the newer version. Mockapetris [Page 48]
RFC 883 November 1983 Domain Names - Implementation and Specification If the AXFR transfer eventually succeeds, the name server closes the virtual circuit and and creates new versions of inversion data structures for this zone. When this operation is complete, the name server acquires the main lock in write mode and then replaces any old copy of the zone and inversion data structures with new ones. The name server then releases the main lock, and can reclaim the storage used by the old copy. If an error occurs during the AXFR transfer, the name server can copy any partial information into its cache tree if it wishes, although it will not normally do so if the zone transfer was a refresh rather than an initial load. Mockapetris [Page 49]
RFC 883 November 1983 Domain Names - Implementation and Specification RESOLVER ALGORITHMS Operations Resolvers have a great deal of latitude in the semantics they allow in user calls. For example, a resolver might support different user calls that specify whether the returned information must be from and authoritative name server or not. Resolvers are also responsible for enforcement of any local restrictions on access, etc. In any case, the resolver will transform the user query into a number of shared database accesses and queries to remote name servers. When a user requests a resource associated with a particular domain name, the resolver will execute the following steps: 1. The resolver first checks the local shared database, if any, for the desired information. If found, it checks the applicable timeout. If the timeout check succeeds, the information is used to satisfy the user request. If not, the resolver goes to step 2. 2. In this step, the resolver consults the shared database for the name server that most closely matches the domain name in the user query. Multiple redundant name servers may be found. The resolver goes to step 3. 3. In this step the resolver chooses one of the available name servers and sends off a query. If the query fails, it tries another name server. If all fail, an error indication is returned to the user. If a reply is received the resolver adds the returned RRs to its database and goes to step 4. 4. In this step, the resolver interprets the reply. If the reply contains the desired information, the resolver returns the information to the user. The the reply indicates that the domain name in the user query doesn't exist, then the resolver returns an error to the user. If the reply contains a transient name server failure, the resolver can either wait and retry the query or go back to step 3 and try a different name server. If the reply doesn't contain the desired information, but does contain a pointer to a closer name server, the resolver returns to step 2, where the closer name servers will be queried. Several modifications to this algorithm are possible. A resolver may not support a local cache and instead only cache information during the course of a single user request, discarding it upon Mockapetris [Page 50]
RFC 883 November 1983 Domain Names - Implementation and Specification completion. The resolver may also find that a datagram reply was truncated, and open a virtual circuit so that the complete reply can be recovered. Inverse and completion queries must be treated in an environment-sensitive manner, because the domain system doesn't provide a method for guaranteeing that it can locate the correct information. The typical choice will be to configure a resolver to use a particular set of known name servers for inverse queries. Mockapetris [Page 51]
RFC 883 November 1983 Domain Names - Implementation and Specification DOMAIN SUPPORT FOR MAIL Introduction Mail service is a particularly sensitive issue for users of the domain system because of the lack of a consistent system for naming mailboxes and even hosts, and the need to support continued operation of existing services. This section discusses an evolutionary approach for adding consistent domain name support for mail. The crucial issue is deciding on the types of binding to be supported. Most mail systems specify a mail destination with a two part construct such as X@Y. The left hand side, X, is an string, often a user or account, and Y is a string, often a host. This section refers to the part on the left, i.e. X, as the local part, and refers to the part on the right, i.e. Y, as the global part. Most existing mail systems route mail based on the global part; a mailer with mail to deliver to X@Y will decide on the host to be contacted using only Y. We refer to this type of binding as "agent binding". For example, mail addressed to Mockapetris@ISIF is delivered to host USC-ISIF (USC-ISIF is the official name for the host specified by nickname ISIF). More sophisticated mail systems use both the local and global parts, i.e. both X and Y to determine which host should receive the mail. These more sophisticated systems usually separate the binding of the destination to the host from the actual delivery. This allows the global part to be a generic name rather than constraining it to a single host. We refer to this type of binding as "mailbox binding". For example, mail addressed to Mockapetris@ISI might be bound to host F.ISI.ARPA, and subsequently delivered to that host, while mail for Cohen@ISI might be bound to host B.ISI.ARPA. The domain support for mail consists of two levels of support, corresponding to these two binding models. The first level, agent binding, is compatible with existing ARPA Internet mail procedures and uses maps a global part onto one or more hosts that will accept the mail. This type of binding uses the MAILA QTYPE. The second level, mailbox binding, offers extended services Mockapetris [Page 52]
RFC 883 November 1983 Domain Names - Implementation and Specification that map a local part and a global part onto one or more sets of data via the MAILB QTYPE. The sets of data include hosts that will accept the mail, mailing list members (mail groups), and mailboxes for reporting errors or requests to change a mail group. The domain system encodes the global part of a mail destination as a domain name and uses dots in the global part to separate labels in the encoded domain name. The domain system encodes the local part of a mail destination as a single label, and any dots in this part are simply copied into the label. The domain system forms a complete mail destination as the local label concatenated to the domain string for the global part. We call this a mailbox. For example, the mailbox [email protected] has a global domain name of three labels, F.ISI.ARPA. The domain name encoding for the whole mailbox is Mockapetris.F.ISI.ARPA. The mailbox [email protected] has the same domain name for the global part and a 4 label domain name for the mailbox of Mockapetris\.cad.F.ISI.ARPA (the \ is not stored in the label, its merely used to denote the "quoted" dot). It is anticipated that the Internet system will adopt agent binding as part of the initial implementation of the domain system, and that mailbox binding will eventually become the preferred style as organizations convert their mail systems to the new style. To facilitate this approach, the domain information for these two binding styles is organized to allow a requestor to determine which types of support are available, and the information is kept in two disjoint classes. Agent binding In agent binding, a mail system uses the global part of the mail destination as a domain name, with dots denoting structure. The domain name is resolved using a MAILA query which return MF and MD RRs to specify the domain name of the appropriate host to receive the mail. MD (Mail delivery) RRs specify hosts that are expected to have the mailbox in question; MF (Mail forwarding) RRs specify hosts that are expected to be intermediaries willing to accept the mail for eventual forwarding. The hosts are hints, rather than definite answers, since the query is made without the full mail destination specification. For example, mail for [email protected] would result in a query with QTYPE=MAILA and QNAME=F.ISI.ARPA, which might return two RRs: Mockapetris [Page 53]
RFC 883 November 1983 Domain Names - Implementation and Specification F.ISI.ARPA MD IN F.ISI.ARPA F.ISI.ARPA MF IN A.ISI.ARPA The mailer would interpret these to mean that the mail agent on F.ISI.ARPA should be able to deliver the mail directly, but that A.ISI.ARPA is willing to accept the mail for probable forwarding. Using this system, an organization could implement a system that uses organization names for global parts, rather than the usual host names, but all mail for the organization would be routed the same, regardless of its local part. Hence and organization with many hosts would expect to see many forwarding operations. Mailbox binding In mailbox binding, the mailer uses the entire mail destination specification to construct a domain name. The encoded domain name for the mailbox is used as the QNAME field in a QTYPE=MAILB query. Several outcomes are possible for this query: 1. The query can return a name error indicating that the mailbox does not exist as a domain name. In the long term this would indicate that the specified mailbox doesn't exist. However, until the use of mailbox binding is universal, this error condition should be interpreted to mean that the organization identified by the global part does not support mailbox binding. The appropriate procedure is to revert to agent binding at this point. 2. The query can return a Mail Rename (MR) RR. The MR RR carries new mailbox specification in its RDATA field. The mailer should replace the old mailbox with the new one and retry the operation. 3. The query can return a MB RR. The MB RR carries a domain name for a host in its RDATA field. The mailer should deliver the message to that host via whatever protocol is applicable, e.g. SMTP. 4. The query can return one or more Mail Group (MG) RRs. This condition means that the mailbox was actually a mailing list or mail group, rather than a single mailbox. Each MG RR has a RDATA field that identifies a mailbox that is a member of Mockapetris [Page 54]
RFC 883 November 1983 Domain Names - Implementation and Specification the group. The mailer should deliver a copy of the message to each member. 5. The query can return a MB RR as well as one or more MG RRs. This condition means the the mailbox was actually a mailing list. The mailer can either deliver the message to the host specified by the MB RR, which will in turn do the delivery to all members, or the mailer can use the MG RRs to do the expansion itself. In any of these cases, the response may include a Mail Information (MINFO) RR. This RR is usually associated with a mail group, but is legal with a MB. The MINFO RR identifies two mailboxes. One of these identifies a responsible person for the original mailbox name. This mailbox should be used for requests to be added to a mail group, etc. The second mailbox name in the MINFO RR identifies a mailbox that should receive error messages for mail failures. This is particularly appropriate for mailing lists when errors in member names should be reported to a person other than the one who sends a message to the list. New fields may be added to this RR in the future. Mockapetris [Page 55]
RFC 883 November 1983 Domain Names - Implementation and Specification Appendix 1 - Domain Name Syntax Specification The preferred syntax of domain names is given by the following BNF rules. Adherence to this syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET). Note that some applications use domain names containing binary information and hence do not follow this syntax. <domain> ::= <subdomain> | " " <subdomain> ::= <label> | <subdomain> "." <label> <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ] <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str> <let-dig-hyp> ::= <let-dig> | "-" <let-dig> ::= <letter> | <digit> <letter> ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case <digit> ::= any one of the ten digits 0 through 9 Note that while upper and lower case letters are allowed in domain names no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical. The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less. For example, the following strings identify hosts in the ARPA Internet: F.ISI.ARPA LINKABIT-DCN5.ARPA UCL-TAC.ARPA Mockapetris [Page 56]
RFC 883 November 1983 Domain Names - Implementation and Specification Appendix 2 - Field formats and encodings +-----------------------------------------------+ | | | ***** WARNING ***** | | | | The following formats are preliminary and | | are included for purposes of explanation only.| | In particular, new RR types will be added, | | and the size, position, and encoding of | | fields are subject to change. | | | +-----------------------------------------------+ TYPE values TYPE fields are used in resource records. Note that these types are not the same as the QTYPE fields used in queries, although the functions are often similar. TYPE value meaning A 1 a host address NS 2 an authoritative name server MD 3 a mail destination MF 4 a mail forwarder CNAME 5 the canonical name for an alias SOA 6 marks the start of a zone of authority MB 7 a mailbox domain name MG 8 a mail group member MR 9 a mail rename domain name NULL 10 a null RR WKS 11 a well known service description PTR 12 a domain name pointer HINFO 13 host information MINFO 14 mailbox or mail list information Mockapetris [Page 57]
RFC 883 November 1983 Domain Names - Implementation and Specification QTYPE values QTYPE fields appear in the question part of a query. They include the values of TYPE with the following additions: AXFR 252 A request for a transfer of an entire zone of authority MAILB 253 A request for mailbox-related records (MB, MG or MR) MAILA 254 A request for mail agent RRs (MD and MF) * 255 A request for all records CLASS values CLASS fields appear in resource records CLASS value meaning IN 1 the ARPA Internet CS 2 the computer science network (CSNET) QCLASS values QCLASS fields appear in the question section of a query. They include the values of CLASS with the following additions: * 255 any class Mockapetris [Page 58]
RFC 883 November 1983 Domain Names - Implementation and Specification Standard resource record formats All RRs have the same top level format shown below: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: NAME - a compressed domain name to which this resource record pertains. TYPE - two octets containing one of the RR type codes defined in Appendix 2. This field specifies the meaning of the data in the RDATA field. CLASS - two octets which specifies the class of the data in the RDATA field. TTL - a 16 bit signed integer that specifies the time interval that the resource record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be cached. For example, SOA records are always distributed with a zero TTL to prohibit caching. Zero values can also be used for extremely volatile data. RDLENGTH- an unsigned 16 bit integer that specifies the length in octets of the RDATA field. Mockapetris [Page 59]
RFC 883 November 1983 Domain Names - Implementation and Specification RDATA - a variable length string of octets that describes the resource. The format of this information varies according to the TYPE and CLASS of the resource record. The format of the RDATA field is standard for all classes for the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO and NULL. These formats are shown below together with the appropriate additional section RR processing. CNAME RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / CNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: CNAME - A compressed domain name which specifies that the domain name of the RR is an alias for a canonical name specified by CNAME. CNAME records cause no additional section processing. The RDATA section of a CNAME line in a master file is a standard printed domain name. HINFO RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / CPU / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / OS / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: CPU - A character string which specifies the CPU type. The character string is represented as a single octet length followed by that number of characters. The following standard strings are defined:. PDP-11/70 C/30 C/70 VAX-11/780 H-316 H-516 DEC-2060 DEC-1090T ALTO IBM-PC IBM-PC/XT PERQ IBM-360/67 IBM-370/145 OS - A character string which specifies the operating system type. The character string is represented as a single octet Mockapetris [Page 60]
RFC 883 November 1983 Domain Names - Implementation and Specification length followed by that number of characters. The following standard types are defined:. ASP AUGUST BKY CCP DOS/360 ELF EPOS EXEC-8 GCOS GPOS ITS INTERCOM KRONOS MCP MOS MPX-RT MULTICS MVT NOS NOS/BE OS/MVS OS/MVT RIG RSX11 RSX11M RT11 SCOPE SIGNAL SINTRAN TENEX TOPS10 TOPS20 TSS UNIX VM/370 VM/CMS VMS WAITS HINFO records cause no additional section processing. HINFO records are used to acquire general information about a host. The main use is for protocols such as FTP that can use special procedures when talking between machines or operating systems of the same type. MB RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / MADNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: MADNAME - A compressed domain name which specifies a host which has the specified mailbox. MB records cause additional section processing which looks up an A type record corresponding to MADNAME. The RDATA section of a MB line in a master file is a standard printed domain name. MD RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / MADNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: MADNAME - A compressed domain name which specifies a host which Mockapetris [Page 61]
RFC 883 November 1983 Domain Names - Implementation and Specification has a mail agent for the domain which should be able to deliver mail for the domain. MD records cause additional section processing which looks up an A type record corresponding to MADNAME. The RDATA section of a MD line in a master file is a standard printed domain name. MF RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / MADNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: MADNAME - A compressed domain name which specifies a host which has a mail agent for the domain which will accept mail for forwarding to the domain. MF records cause additional section processing which looks up an A type record corresponding to MADNAME. The RDATA section of a MF line in a master file is a standard printed domain name. MG RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / MGMNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: MGMNAME - A compressed domain name which specifies a mailbox which is a member of the mail group specified by the domain name. MF records cause no additional section processing. The RDATA section of a MF line in a master file is a standard printed domain name. Mockapetris [Page 62]
RFC 883 November 1983 Domain Names - Implementation and Specification MINFO RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / RMAILBX / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / EMAILBX / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: RMAILBX - A compressed domain name which specifies a mailbox which is responsible for the mailing list or mailbox. If this domain name names the root, the owner of the MINFO RR is responsible for itself. Note that many existing mailing lists use a mailbox X-request for the RMAILBX field of mailing list X, e.g. Msgroup-request for Msgroup. This field provides a more general mechanism. EMAILBX - A compressed domain name which specifies a mailbox which is to receive error messages related to the mailing list or mailbox specified by the owner of the MINFO RR (similar to the ERRORS-TO: field which has been proposed). If this domain name names the root, errors should be returned to the sender of the message. MINFO records cause no additional section processing. Although these records can be associated with a simple mailbox, they are usually used with a mailing list. The MINFO section of a MF line in a master file is a standard printed domain name. MR RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / NEWNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: NEWNAME - A compressed domain name which specifies a mailbox which is the proper rename of the specified mailbox. MR records cause no additional section processing. The RDATA section of a MR line in a master file is a standard printed domain name. Mockapetris [Page 63]
RFC 883 November 1983 Domain Names - Implementation and Specification NULL RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / <anything> / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Anything at all may be in the RDATA field so long as it is 65535 octets or less. NULL records cause no additional section processing. NULL RRs are not allowed in master files. NS RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / NSDNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: NSDNAME - A compressed domain name which specifies a host which has a name server for the domain. NS records cause both the usual additional section processing to locate a type A record, and a special search of the zone in which they reside. The RDATA section of a NS line in a master file is a standard printed domain name. PTR RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / PTRDNAME / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: PTRDNAME - A compressed domain name which points to some location in the domain name space. PTR records cause no additional section processing. These RRs are used in special domains to point to some other location in the domain space. These records are simple data, and don't imply any special processing similar to that performed by CNAME, which identifies aliases. Appendix 3 discusses the use of these records in the ARPA Internet address domain. Mockapetris [Page 64]
RFC 883 November 1983 Domain Names - Implementation and Specification SOA RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / MNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / RNAME / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | SERIAL | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | REFRESH | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RETRY | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | EXPIRE | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | MINIMUM | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: MNAME - The domain name of the name server that was the original source of data for this zone. RNAME - A domain name which specifies the mailbox of the person responsible for this zone. SERIAL - The unsigned 16 bit version number of the of the original copy of the zone. This value wraps and should be compared using sequence space arithmetic. REFRESH - The unsigned 32 bit time interval before the zone should be refreshed. RETRY - The unsigned 32 bit time interval that should elapse before a failed refresh should be retried. EXPIRE - A 32 bit time value that specifies the upper limit on the time interval that can elapse before the zone is no longer authoritative. MINIMUM - The unsigned 16 bit minimum TTL field that should be exported with any RR from this zone (other than the SOA itself). SOA records cause no additional section processing. The RDATA Mockapetris [Page 65]
RFC 883 November 1983 Domain Names - Implementation and Specification section of a SOA line in a master file is a standard printed domain name for MNAME, a standard X@Y mailbox specification for RNAME, and decimal numbers for the remaining parameters. All times are in units of seconds. Most of these fields are pertinent only for name server maintenance operations. However, MINIMUM is used in all query operations that retrieve RRs from a zone. Whenever a RR is sent in a response to a query, the TTL field is set to the maximum of the TTL field from the RR and the MINIMUM field in the appropriate SOA. Thus MINIMUM is a lower bound on the TTL field for all RRs in a zone. RRs in a zone are never discarded due to timeout unless the whole zone is deleted. This prevents partial copies of zones. Mockapetris [Page 66]
RFC 883 November 1983 Domain Names - Implementation and Specification Appendix 3 - Internet specific field formats and operations Message transport The Internet supports name server access using TCP [10] on server port 53 (decimal) as well as datagram access using UDP [11] on UDP port 53 (decimal). Messages sent over TCP virtual circuits are preceded by an unsigned 16 bit length field which describes the length of the message, excluding the length field itself. +-----------------------------------------------+ | | | ***** WARNING ***** | | | | The following formats are preliminary and | | are included for purposes of explanation only.| | In particular, new RR types will be added, | | and the size, position, and encoding of | | fields are subject to change. | | | +-----------------------------------------------+ A RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ADDRESS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: ADDRESS - A 32 bit ARPA internet address Hosts that have multiple ARPA Internet addresses will have multiple A records. A records cause no additional section processing. The RDATA section of an A line in a master file is an Internet address expressed as four decimal numbers separated by dots without any imbedded spaces (e.g., "10.2.0.52" or "192.0.5.6"). Mockapetris [Page 67]
RFC 883 November 1983 Domain Names - Implementation and Specification WKS RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ADDRESS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PROTOCOL | | +--+--+--+--+--+--+--+--+ | | | / <BIT MAP> / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: ADDRESS - An 32 bit ARPA Internet address PROTOCOL - An 8 bit IP protocol number <BIT MAP> - A variable length bit map. The bit map must be a multiple of 8 bits long. The WKS record is used to describe the well known services supported by a particular protocol on a particular internet address. The PROTOCOL field specifies an IP protocol number, and the bit map has one bit per port of the specified protocol. The first bit corresponds to port 0, the second to port 1, etc. If less than 256 bits are present, the remainder are assumed to be zero. The appropriate values for ports and protocols are specified in [13]. For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port 25 (SMTP). If this bit is set, a SMTP server should be listening on TCP port 25; if zero, SMTP service is not supported on the specified address. The anticipated use of WKS RRs is to provide availability information for servers for TCP and UDP. If a server supports both TCP and UDP, or has multiple Internet addresses, then multiple WKS RRs are used. WKS RRs cause no additional section processing. The RDATA section of a WKS record consists of a decimal protocol number followed by mnemonic identifiers which specify bits to be set to 1. IN-ADDR special domain The ARPA internet uses a special domain to support gateway location and ARPA Internet address to host mapping. The intent of this domain is to allow queries to locate all gateways on a Mockapetris [Page 68]
RFC 883 November 1983 Domain Names - Implementation and Specification particular network in the ARPA Internet, and also to provide a guaranteed method to perform host address to host name mapping. Note that both of these services are similar to functions that could be performed by inverse queries; the difference is that this part of the domain name space is structured according to address, and hence can guarantee that the appropriate data can be located without an exhaustive search of the domain space. It is anticipated that the special tree will be used by ARPA Internet resolvers for all gateway location services, but that address to name resolution will be performed by first trying the inverse query on the local name server database followed by a query in the special space if the inverse query fails. The domain is a top level domain called IN-ADDR whose substructure follows the ARPA Internet addressing structure. Domain names in the IN-ADDR domain are defined to have up to four labels in addition to the IN-ADDR label. Each label is a character string which expresses a decimal value in the range 0-255 (with leading zeros omitted except in the case of a zero octet which is represented by a single zero). These labels correspond to the 4 octets of an ARPA Internet address. Host addresses are represented by domain names that have all four labels specified. Thus data for ARPA Internet address 10.2.0.52 is located at domain name 52.0.2.10.IN-ADDR. The reversal, though awkward to read, allows zones to follow the natural grouping of hosts within networks. For example, 10.IN-ADDR can be a zone containing data for the ARPANET, while 26.IN-ADDR can be a separate zone for MILNET. Address nodes are used to hold pointers to primary host names in the normal domain space. Network addresses correspond to some of the non-terminal nodes in the IN-ADDR tree, since ARPA Internet network numbers are either 1, 2, or 3 octets. Network nodes are used to hold pointers to primary host names (which happen to be gateways) in the normal domain space. Since a gateway is, by definition, on more than one network, it will typically have two or more network nodes that point at the gateway. Gateways will also have host level pointers at their fully qualified addresses. Both the gateway pointers at network nodes and the normal host pointers at full address nodes use the PTR RR to point back to the primary domain names of the corresponding hosts. For example, part of the IN-ADDR domain will contain information about the ISI to MILNET and MIT gateways, and hosts F.ISI.ARPA and MULTICS.MIT.ARPA. Assuming that ISI gateway has addresses Mockapetris [Page 69]
RFC 883 November 1983 Domain Names - Implementation and Specification 10.2.0.22 and 26.0.0.103, and a name MILNET-GW.ISI.ARPA, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4 and a name GW.MIT.ARPA, the domain database would contain: 10.IN-ADDR PTR IN MILNET-GW.ISI.ARPA 10.IN-ADDR PTR IN GW.MIT.ARPA 18.IN-ADDR PTR IN GW.MIT.ARPA 26.IN-ADDR PTR IN MILNET-GW.ISI.ARPA 22.0.2.10.IN-ADDR PTR IN MILNET-GW.ISI.ARPA 103.0.0.26.IN-ADDR PTR IN MILNET-GW.ISI.ARPA 77.0.0.10.IN-ADDR PTR IN GW.MIT.ARPA 4.0.10.18.IN-ADDR PTR IN GW.MIT.ARPA 52.0.2.10.IN-ADDR PTR IN F.ISI.ARPA 6.0.0.10.IN-ADDR PTR IN MULTICS.MIT.ARPA Thus a program which wanted to locate gateways on net 10 would originate a query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR. It would receive two RRs in response: 10.IN-ADDR PTR IN MILNET-GW.ISI.ARPA 10.IN-ADDR PTR IN GW.MIT.ARPA The program could then originate QTYPE=A, QCLASS=IN queries for MILNET-GW.ISI.ARPA and GW.MIT.ARPA to discover the ARPA Internet addresses of these gateways. A resolver which wanted to find the host name corresponding to ARPA Internet host address 10.0.0.6 might first try an inverse query on the local name server, but find that this information wasn't available. It could then try a query of the form QTYPE=PTR, QCLASS=IN, QNAME=6.0.0.10.IN-ADDR, and would receive: 6.0.0.10.IN-ADDR PTR IN MULTICS.MIT.ARPA Several cautions apply to the use of these services: Since the IN-ADDR special domain and the normal domain for a particular host or gateway will be in different zones, the possibility exists that that the data may be inconsistent. Gateways will often have two names in separate domains, only one of which can be primary. Systems that use the domain database to initialize their routing tables must start with enough gateway information to guarantee that they can access the appropriate name server. The gateway data only reflects the existence of a gateway in a Mockapetris [Page 70]
RFC 883 November 1983 Domain Names - Implementation and Specification manner equivalent to the current HOSTS.TXT file. It doesn't replace the dynamic availability information from GGP or EGP. Mockapetris [Page 71]
RFC 883 November 1983 Domain Names - Implementation and Specification REFERENCES and BIBLIOGRAPHY [1] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD Internet Host Table Specification", RFC 810, Network Information Center, SRI International, March 1982. [2] J. Postel, "Computer Mail Meeting Notes", RFC 805, USC/Information Sciences Institute, February 1982. [3] Z. Su, and J. Postel, "The Domain Naming Convention for Internet User Applications", RFC 819, Network Information Center, SRI International, August 1982. [4] Z. Su, "A Distributed System for Internet Name Service", RFC 830, Network Information Center, SRI International, October 1982. [5] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC 812, Network Information Center, SRI International, March 1982. [6] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET Name Server", Computer Networks, vol 6, nr 3, July 1982. [7] K. Harrenstien, "NAME/FINGER", RFC 742, Network Information Center, SRI International, December 1977. [8] J. Postel, "Internet Name Server", IEN 116, USC/Information Sciences Institute, August 1979. [9] K. Harrenstien, V. White, and E. Feinler, "Hostnames Server", RFC 811, Network Information Center, SRI International, March 1982. [10] J. Postel, "Transmission Control Protocol", RFC 793, USC/Information Sciences Institute, September 1981. [11] J. Postel, "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, August 1980. [12] J. Postel, "Simple Mail Transfer Protocol", RFC 821, USC/Information Sciences Institute, August 1980. [13] J. Reynolds, and J. Postel, "Assigned Numbers", RFC 870, USC/Information Sciences Institute, October 1983. [14] P. Mockapetris, "Domain names - Concepts and Facilities," RFC 882, USC/Information Sciences Institute, November 1983. Mockapetris [Page 72]
RFC 883 November 1983 Domain Names - Implementation and Specification INDEX * usage........................................................37, 57 A RDATA format.....................................................67 byte order..........................................................6 cache queue....................................................35, 42 character case..................................................7, 31 CLASS...........................................................9, 58 completion.........................................................19 compression........................................................31 CNAME RR...........................................................60 header format......................................................26 HINFO RR...........................................................60 include files......................................................43 inverse queries....................................................17 mailbox names......................................................53 master files.......................................................43 MB RR..............................................................61 MD RR..............................................................61 message format.....................................................13 MF RR..............................................................62 MG RR..............................................................62 MINFO RR...........................................................63 MR RR..............................................................63 NULL RR............................................................64 NS RR..............................................................64 PTR RR.........................................................64, 69 QCLASS.............................................................58 QTYPE..............................................................57 queries (standard).................................................15 recursive service..................................................24 RR format..........................................................59 SOA RR.............................................................65 Special domains....................................................68 TYPE...............................................................57 WKS type RR........................................................68 Mockapetris [Page 73]
Html markup produced by rfcmarkup 1.115, available from https://tools.ietf.org/tools/rfcmarkup/
RFC 1591 . DOMAIN NAME SYSTEM STRUCTURE & DELEGATION
[RFCs/IDs] [Plain Text]
INFORMATIONAL
Network Working Group J. Postel Request for Comments: 1591 ISI Category: Informational March 1994 Domain Name System Structure and Delegation Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.1. Introduction This memo provides some information on the structure of the names in the Domain Name System (DNS), specifically the top-level domain names; and on the administration of domains. The Internet Assigned Numbers Authority (IANA) is the overall authority for the IP Addresses, the Domain Names, and many other parameters, used in the Internet. The day-to-day responsibility for the assignment of IP Addresses, Autonomous System Numbers, and most top and second level Domain Names are handled by the Internet Registry (IR) and regional registries.2. The Top Level Structure of the Domain Names In the Domain Name System (DNS) naming of computers there is a hierarchy of names. The root of system is unnamed. There are a set of what are called "top-level domain names" (TLDs). These are the generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two letter country codes from ISO-3166. It is extremely unlikely that any other TLDs will be created. Under each TLD may be created a hierarchy of names. Generally, under the generic TLDs the structure is very flat. That is, many organizations are registered directly under the TLD, and any further structure is up to the individual organizations. In the country TLDs, there is a wide variation in the structure, in some countries the structure is very flat, in others there is substantial structural organization. In some country domains the second levels are generic categories (such as, AC, CO, GO, and RE), in others they are based on political geography, and in still others, organization names are listed directly under the country code. The organization for the US country domain is described in RFC 1480 [1]. Postel [Page 1]
RFC 1591 Domain Name System Structure and Delegation March 1994 Each of the generic TLDs was created for a general category of organizations. The country code domains (for example, FR, NL, KR, US) are each organized by an administrator for that country. These administrators may further delegate the management of portions of the naming tree. These administrators are performing a public service on behalf of the Internet community. Descriptions of the generic domains and the US country domain follow. Of these generic domains, five are international in nature, and two are restricted to use by entities in the United States. World Wide Generic Domains: COM - This domain is intended for commercial entities, that is companies. This domain has grown very large and there is concern about the administrative load and system performance if the current growth pattern is continued. Consideration is being taken to subdivide the COM domain and only allow future commercial registrations in the subdomains. EDU - This domain was originally intended for all educational institutions. Many Universities, colleges, schools, educational service organizations, and educational consortia have registered here. More recently a decision has been taken to limit further registrations to 4 year colleges and universities. Schools and 2-year colleges will be registered in the country domains (see US Domain, especially K12 and CC, below). NET - This domain is intended to hold only the computers of network providers, that is the NIC and NOC computers, the administrative computers, and the network node computers. The customers of the network provider would have domain names of their own (not in the NET TLD). ORG - This domain is intended as the miscellaneous TLD for organizations that didn't fit anywhere else. Some non- government organizations may fit here. INT - This domain is for organizations established by international treaties, or international databases. United States Only Generic Domains: GOV - This domain was originally intended for any kind of government office or agency. More recently a decision was taken to register only agencies of the US Federal government in this domain. State and local agencies are registered in the country Postel [Page 2]
RFC 1591 Domain Name System Structure and Delegation March 1994 domains (see US Domain, below). MIL - This domain is used by the US military. Example country code Domain: US - As an example of a country domain, the US domain provides for the registration of all kinds of entities in the United States on the basis of political geography, that is, a hierarchy of <entity-name>.<locality>.<state-code>.US. For example, "IBM.Armonk.NY.US". In addition, branches of the US domain are provided within each state for schools (K12), community colleges (CC), technical schools (TEC), state government agencies (STATE), councils of governments (COG),libraries (LIB), museums (MUS), and several other generic types of entities (see RFC 1480 for details [1]). To find a contact for a TLD use the "whois" program to access the database on the host rs.internic.net. Append "-dom" to the name of TLD you are interested in. For example: whois -h rs.internic.net us-dom or whois -h rs.internic.net edu-dom 3. The Administration of Delegated Domains The Internet Assigned Numbers Authority (IANA) is responsible for the overall coordination and management of the Domain Name System (DNS), and especially the delegation of portions of the name space called top-level domains. Most of these top-level domains are two-letter country codes taken from the ISO standard 3166. A central Internet Registry (IR) has been selected and designated to handled the bulk of the day-to-day administration of the Domain Name System. Applications for new top-level domains (for example, country code domains) are handled by the IR with consultation with the IANA. The central IR is INTERNIC.NET. Second level domains in COM, EDU, ORG, NET, and GOV are registered by the Internet Registry at the InterNIC. The second level domains in the MIL are registered by the DDN registry at NIC.DDN.MIL. Second level names in INT are registered by the PVM at ISI.EDU. While all requests for new top-level domains must be sent to the Internic (at [email protected]), the regional registries are often enlisted to assist in the administration of the DNS, especially in solving problems with a country administration. Currently, the RIPE NCC is the regional registry for Europe and the APNIC is the Postel [Page 3]
RFC 1591 Domain Name System Structure and Delegation March 1994 regional registry for the Asia-Pacific region, while the INTERNIC administers the North America region, and all the as yet undelegated regions. The contact mailboxes for these regional registries are: INTERNIC [email protected] APNIC [email protected] RIPE NCC [email protected] The policy concerns involved when a new top-level domain is established are described in the following. Also mentioned are concerns raised when it is necessary to change the delegation of an established domain from one party to another. A new top-level domain is usually created and its management delegated to a "designated manager" all at once. Most of these same concerns are relevant when a sub-domain is delegated and in general the principles described here apply recursively to all delegations of the Internet DNS name space. The major concern in selecting a designated manager for a domain is that it be able to carry out the necessary responsibilities, and have the ability to do a equitable, just, honest, and competent job. 1) The key requirement is that for each domain there be a designated manager for supervising that domain's name space. In the case of top-level domains that are country codes this means that there is a manager that supervises the domain names and operates the domain name system in that country. The manager must, of course, be on the Internet. There must be Internet Protocol (IP) connectivity to the nameservers and email connectivity to the management and staff of the manager. There must be an administrative contact and a technical contact for each domain. For top-level domains that are country codes at least the administrative contact must reside in the country involved. 2) These designated authorities are trustees for the delegated domain, and have a duty to serve the community. The designated manager is the trustee of the top-level domain for both the nation, in the case of a country code, and the global Internet community. Postel [Page 4]
RFC 1591 Domain Name System Structure and Delegation March 1994 Concerns about "rights" and "ownership" of domains are inappropriate. It is appropriate to be concerned about "responsibilities" and "service" to the community. 3) The designated manager must be equitable to all groups in the domain that request domain names. This means that the same rules are applied to all requests, all requests must be processed in a non-discriminatory fashion, and academic and commercial (and other) users are treated on an equal basis. No bias shall be shown regarding requests that may come from customers of some other business related to the manager -- e.g., no preferential service for customers of a particular data network provider. There can be no requirement that a particular mail system (or other application), protocol, or product be used. There are no requirements on subdomains of top-level domains beyond the requirements on higher-level domains themselves. That is, the requirements in this memo are applied recursively. In particular, all subdomains shall be allowed to operate their own domain name servers, providing in them whatever information the subdomain manager sees fit (as long as it is true and correct). 4) Significantly interested parties in the domain should agree that the designated manager is the appropriate party. The IANA tries to have any contending parties reach agreement among themselves, and generally takes no action to change things unless all the contending parties agree; only in cases where the designated manager has substantially mis-behaved would the IANA step in. However, it is also appropriate for interested parties to have some voice in selecting the designated manager. There are two cases where the IANA and the central IR may establish a new top-level domain and delegate only a portion of it: (1) there are contending parties that cannot agree, or (2) the applying party may not be able to represent or serve the whole country. The later case sometimes arises when a party outside a country is trying to be helpful in getting networking started in a country -- this is sometimes called a "proxy" DNS service. The Internet DNS Names Review Board (IDNB), a committee established by the IANA, will act as a review panel for cases in which the parties can not reach agreement among themselves. The IDNB's decisions will be binding. Postel [Page 5]
RFC 1591 Domain Name System Structure and Delegation March 1994 5) The designated manager must do a satisfactory job of operating the DNS service for the domain. That is, the actual management of the assigning of domain names, delegating subdomains and operating nameservers must be done with technical competence. This includes keeping the central IR (in the case of top-level domains) or other higher-level domain manager advised of the status of the domain, responding to requests in a timely manner, and operating the database with accuracy, robustness, and resilience. There must be a primary and a secondary nameserver that have IP connectivity to the Internet and can be easily checked for operational status and database accuracy by the IR and the IANA. In cases when there are persistent problems with the proper operation of a domain, the delegation may be revoked, and possibly delegated to another designated manager. 6) For any transfer of the designated manager trusteeship from one organization to another, the higher-level domain manager (the IANA in the case of top-level domains) must receive communications from both the old organization and the new organization that assure the IANA that the transfer in mutually agreed, and that the new organization understands its responsibilities. It is also very helpful for the IANA to receive communications from other parties that may be concerned or affected by the transfer. 4. Rights to Names 1) Names and Trademarks In case of a dispute between domain name registrants as to the rights to a particular name, the registration authority shall have no role or responsibility other than to provide the contact information to both parties. The registration of a domain name does not have any Trademark status. It is up to the requestor to be sure he is not violating anyone else's Trademark. 2) Country Codes The IANA is not in the business of deciding what is and what is not a country. Postel [Page 6]
RFC 1591 Domain Name System Structure and Delegation March 1994 The selection of the ISO 3166 list as a basis for country code top-level domain names was made with the knowledge that ISO has a procedure for determining which entities should be and should not be on that list. 5. Security Considerations Security issues are not discussed in this memo.6. Acknowledgements Many people have made comments on draft version of these descriptions and procedures. Steve Goldstein and John Klensin have been particularly helpful.7. Author's Address Jon Postel USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Phone: 310-822-1511 Fax: 310-823-6714 EMail: [email protected]7. References [1] Cooper, A., and J. Postel, "The US Domain", RFC 1480, USC/Information Sciences Institute, June 1993. [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992. [3] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987. [4] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987. [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, CSNET CIC BBN, January 1986. [7] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, Internet Engineering Task Force, October 1989. Postel [Page 7]
Html markup produced by rfcmarkup 1.70, available from http://tools.ietf.org/tools/rfcmarkup/
INFORMATIONAL
Network Working Group J. Postel Request for Comments: 1591 ISI Category: Informational March 1994 Domain Name System Structure and Delegation Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.1. Introduction This memo provides some information on the structure of the names in the Domain Name System (DNS), specifically the top-level domain names; and on the administration of domains. The Internet Assigned Numbers Authority (IANA) is the overall authority for the IP Addresses, the Domain Names, and many other parameters, used in the Internet. The day-to-day responsibility for the assignment of IP Addresses, Autonomous System Numbers, and most top and second level Domain Names are handled by the Internet Registry (IR) and regional registries.2. The Top Level Structure of the Domain Names In the Domain Name System (DNS) naming of computers there is a hierarchy of names. The root of system is unnamed. There are a set of what are called "top-level domain names" (TLDs). These are the generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two letter country codes from ISO-3166. It is extremely unlikely that any other TLDs will be created. Under each TLD may be created a hierarchy of names. Generally, under the generic TLDs the structure is very flat. That is, many organizations are registered directly under the TLD, and any further structure is up to the individual organizations. In the country TLDs, there is a wide variation in the structure, in some countries the structure is very flat, in others there is substantial structural organization. In some country domains the second levels are generic categories (such as, AC, CO, GO, and RE), in others they are based on political geography, and in still others, organization names are listed directly under the country code. The organization for the US country domain is described in RFC 1480 [1]. Postel [Page 1]
RFC 1591 Domain Name System Structure and Delegation March 1994 Each of the generic TLDs was created for a general category of organizations. The country code domains (for example, FR, NL, KR, US) are each organized by an administrator for that country. These administrators may further delegate the management of portions of the naming tree. These administrators are performing a public service on behalf of the Internet community. Descriptions of the generic domains and the US country domain follow. Of these generic domains, five are international in nature, and two are restricted to use by entities in the United States. World Wide Generic Domains: COM - This domain is intended for commercial entities, that is companies. This domain has grown very large and there is concern about the administrative load and system performance if the current growth pattern is continued. Consideration is being taken to subdivide the COM domain and only allow future commercial registrations in the subdomains. EDU - This domain was originally intended for all educational institutions. Many Universities, colleges, schools, educational service organizations, and educational consortia have registered here. More recently a decision has been taken to limit further registrations to 4 year colleges and universities. Schools and 2-year colleges will be registered in the country domains (see US Domain, especially K12 and CC, below). NET - This domain is intended to hold only the computers of network providers, that is the NIC and NOC computers, the administrative computers, and the network node computers. The customers of the network provider would have domain names of their own (not in the NET TLD). ORG - This domain is intended as the miscellaneous TLD for organizations that didn't fit anywhere else. Some non- government organizations may fit here. INT - This domain is for organizations established by international treaties, or international databases. United States Only Generic Domains: GOV - This domain was originally intended for any kind of government office or agency. More recently a decision was taken to register only agencies of the US Federal government in this domain. State and local agencies are registered in the country Postel [Page 2]
RFC 1591 Domain Name System Structure and Delegation March 1994 domains (see US Domain, below). MIL - This domain is used by the US military. Example country code Domain: US - As an example of a country domain, the US domain provides for the registration of all kinds of entities in the United States on the basis of political geography, that is, a hierarchy of <entity-name>.<locality>.<state-code>.US. For example, "IBM.Armonk.NY.US". In addition, branches of the US domain are provided within each state for schools (K12), community colleges (CC), technical schools (TEC), state government agencies (STATE), councils of governments (COG),libraries (LIB), museums (MUS), and several other generic types of entities (see RFC 1480 for details [1]). To find a contact for a TLD use the "whois" program to access the database on the host rs.internic.net. Append "-dom" to the name of TLD you are interested in. For example: whois -h rs.internic.net us-dom or whois -h rs.internic.net edu-dom 3. The Administration of Delegated Domains The Internet Assigned Numbers Authority (IANA) is responsible for the overall coordination and management of the Domain Name System (DNS), and especially the delegation of portions of the name space called top-level domains. Most of these top-level domains are two-letter country codes taken from the ISO standard 3166. A central Internet Registry (IR) has been selected and designated to handled the bulk of the day-to-day administration of the Domain Name System. Applications for new top-level domains (for example, country code domains) are handled by the IR with consultation with the IANA. The central IR is INTERNIC.NET. Second level domains in COM, EDU, ORG, NET, and GOV are registered by the Internet Registry at the InterNIC. The second level domains in the MIL are registered by the DDN registry at NIC.DDN.MIL. Second level names in INT are registered by the PVM at ISI.EDU. While all requests for new top-level domains must be sent to the Internic (at [email protected]), the regional registries are often enlisted to assist in the administration of the DNS, especially in solving problems with a country administration. Currently, the RIPE NCC is the regional registry for Europe and the APNIC is the Postel [Page 3]
RFC 1591 Domain Name System Structure and Delegation March 1994 regional registry for the Asia-Pacific region, while the INTERNIC administers the North America region, and all the as yet undelegated regions. The contact mailboxes for these regional registries are: INTERNIC [email protected] APNIC [email protected] RIPE NCC [email protected] The policy concerns involved when a new top-level domain is established are described in the following. Also mentioned are concerns raised when it is necessary to change the delegation of an established domain from one party to another. A new top-level domain is usually created and its management delegated to a "designated manager" all at once. Most of these same concerns are relevant when a sub-domain is delegated and in general the principles described here apply recursively to all delegations of the Internet DNS name space. The major concern in selecting a designated manager for a domain is that it be able to carry out the necessary responsibilities, and have the ability to do a equitable, just, honest, and competent job. 1) The key requirement is that for each domain there be a designated manager for supervising that domain's name space. In the case of top-level domains that are country codes this means that there is a manager that supervises the domain names and operates the domain name system in that country. The manager must, of course, be on the Internet. There must be Internet Protocol (IP) connectivity to the nameservers and email connectivity to the management and staff of the manager. There must be an administrative contact and a technical contact for each domain. For top-level domains that are country codes at least the administrative contact must reside in the country involved. 2) These designated authorities are trustees for the delegated domain, and have a duty to serve the community. The designated manager is the trustee of the top-level domain for both the nation, in the case of a country code, and the global Internet community. Postel [Page 4]
RFC 1591 Domain Name System Structure and Delegation March 1994 Concerns about "rights" and "ownership" of domains are inappropriate. It is appropriate to be concerned about "responsibilities" and "service" to the community. 3) The designated manager must be equitable to all groups in the domain that request domain names. This means that the same rules are applied to all requests, all requests must be processed in a non-discriminatory fashion, and academic and commercial (and other) users are treated on an equal basis. No bias shall be shown regarding requests that may come from customers of some other business related to the manager -- e.g., no preferential service for customers of a particular data network provider. There can be no requirement that a particular mail system (or other application), protocol, or product be used. There are no requirements on subdomains of top-level domains beyond the requirements on higher-level domains themselves. That is, the requirements in this memo are applied recursively. In particular, all subdomains shall be allowed to operate their own domain name servers, providing in them whatever information the subdomain manager sees fit (as long as it is true and correct). 4) Significantly interested parties in the domain should agree that the designated manager is the appropriate party. The IANA tries to have any contending parties reach agreement among themselves, and generally takes no action to change things unless all the contending parties agree; only in cases where the designated manager has substantially mis-behaved would the IANA step in. However, it is also appropriate for interested parties to have some voice in selecting the designated manager. There are two cases where the IANA and the central IR may establish a new top-level domain and delegate only a portion of it: (1) there are contending parties that cannot agree, or (2) the applying party may not be able to represent or serve the whole country. The later case sometimes arises when a party outside a country is trying to be helpful in getting networking started in a country -- this is sometimes called a "proxy" DNS service. The Internet DNS Names Review Board (IDNB), a committee established by the IANA, will act as a review panel for cases in which the parties can not reach agreement among themselves. The IDNB's decisions will be binding. Postel [Page 5]
RFC 1591 Domain Name System Structure and Delegation March 1994 5) The designated manager must do a satisfactory job of operating the DNS service for the domain. That is, the actual management of the assigning of domain names, delegating subdomains and operating nameservers must be done with technical competence. This includes keeping the central IR (in the case of top-level domains) or other higher-level domain manager advised of the status of the domain, responding to requests in a timely manner, and operating the database with accuracy, robustness, and resilience. There must be a primary and a secondary nameserver that have IP connectivity to the Internet and can be easily checked for operational status and database accuracy by the IR and the IANA. In cases when there are persistent problems with the proper operation of a domain, the delegation may be revoked, and possibly delegated to another designated manager. 6) For any transfer of the designated manager trusteeship from one organization to another, the higher-level domain manager (the IANA in the case of top-level domains) must receive communications from both the old organization and the new organization that assure the IANA that the transfer in mutually agreed, and that the new organization understands its responsibilities. It is also very helpful for the IANA to receive communications from other parties that may be concerned or affected by the transfer. 4. Rights to Names 1) Names and Trademarks In case of a dispute between domain name registrants as to the rights to a particular name, the registration authority shall have no role or responsibility other than to provide the contact information to both parties. The registration of a domain name does not have any Trademark status. It is up to the requestor to be sure he is not violating anyone else's Trademark. 2) Country Codes The IANA is not in the business of deciding what is and what is not a country. Postel [Page 6]
RFC 1591 Domain Name System Structure and Delegation March 1994 The selection of the ISO 3166 list as a basis for country code top-level domain names was made with the knowledge that ISO has a procedure for determining which entities should be and should not be on that list. 5. Security Considerations Security issues are not discussed in this memo.6. Acknowledgements Many people have made comments on draft version of these descriptions and procedures. Steve Goldstein and John Klensin have been particularly helpful.7. Author's Address Jon Postel USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 Phone: 310-822-1511 Fax: 310-823-6714 EMail: [email protected]7. References [1] Cooper, A., and J. Postel, "The US Domain", RFC 1480, USC/Information Sciences Institute, June 1993. [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992. [3] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987. [4] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987. [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, CSNET CIC BBN, January 1986. [7] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, Internet Engineering Task Force, October 1989. Postel [Page 7]
Html markup produced by rfcmarkup 1.70, available from http://tools.ietf.org/tools/rfcmarkup/
RFC 881 . DOMAIN NAMES PLAN & SCHEDULE
[Docs] [txt|pdf]
Updated by: 897
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 "[email protected]" 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]
Html markup produced by rfcmarkup 1.115, available from https://tools.ietf.org/tools/rfcmarkup/
Updated by: 897
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 "[email protected]" 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]
Html markup produced by rfcmarkup 1.115, available from https://tools.ietf.org/tools/rfcmarkup/
RFC 1918 . Address Allocation for Private Internets
[Docs] [txt|pdf] [draft-ietf-cidrd-...] [Diff1] [Diff2] [Errata]
Updated by: 6761 BEST CURRENT PRACTICE
Errata Exist
Network Working Group Y. Rekhter Request for Comments: 1918 Cisco Systems Obsoletes: 1627, 1597 B. Moskowitz BCP: 5 Chrysler Corp. Category: Best Current Practice D. Karrenberg RIPE NCC G. J. de Groot RIPE NCC E. Lear Silicon Graphics, Inc. February 1996 Address Allocation for Private Internets Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.1. Introduction For the purposes of this document, an enterprise is an entity autonomously operating a network using TCP/IP and in particular determining the addressing plan and address assignments within that network. This document describes address allocation for private internets. The allocation permits full network layer connectivity among all hosts inside an enterprise as well as among all public hosts of different enterprises. The cost of using private internet address space is the potentially costly effort to renumber hosts and networks between public and private.2. Motivation With the proliferation of TCP/IP technology worldwide, including outside the Internet itself, an increasing number of non-connected enterprises use this technology and its addressing capabilities for sole intra-enterprise communications, without any intention to ever directly connect to other enterprises or the Internet itself. The Internet has grown beyond anyone's expectations. Sustained exponential growth continues to introduce new challenges. One challenge is a concern within the community that globally unique address space will be exhausted. A separate and far more pressing concern is that the amount of routing overhead will grow beyond the Rekhter, et al Best Current Practice [Page 1]
RFC 1918 Address Allocation for Private Internets February 1996 capabilities of Internet Service Providers. Efforts are in progress within the community to find long term solutions to both of these problems. Meanwhile it is necessary to revisit address allocation procedures, and their impact on the Internet routing system. To contain growth of routing overhead, an Internet Provider obtains a block of address space from an address registry, and then assigns to its customers addresses from within that block based on each customer requirement. The result of this process is that routes to many customers will be aggregated together, and will appear to other providers as a single route [RFC1518], [RFC1519]. In order for route aggregation to be effective, Internet providers encourage customers joining their network to use the provider's block, and thus renumber their computers. Such encouragement may become a requirement in the future. With the current size of the Internet and its growth rate it is no longer realistic to assume that by virtue of acquiring globally unique IP addresses out of an Internet registry an organization that acquires such addresses would have Internet-wide IP connectivity once the organization gets connected to the Internet. To the contrary, it is quite likely that when the organization would connect to the Internet to achieve Internet-wide IP connectivity the organization would need to change IP addresses (renumber) all of its public hosts (hosts that require Internet-wide IP connectivity), regardless of whether the addresses used by the organization initially were globally unique or not. It has been typical to assign globally unique addresses to all hosts that use TCP/IP. In order to extend the life of the IPv4 address space, address registries are requiring more justification than ever before, making it harder for organizations to acquire additional address space [RFC1466]. Hosts within enterprises that use IP can be partitioned into three categories: Category 1: hosts that do not require access to hosts in other enterprises or the Internet at large; hosts within this category may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises. Category 2: hosts that need access to a limited set of outside services (e.g., E-mail, FTP, netnews, remote login) which can be handled by mediating gateways (e.g., application layer gateways). For many hosts in this category an unrestricted external access (provided Rekhter, et al Best Current Practice [Page 2]
RFC 1918 Address Allocation for Private Internets February 1996 via IP connectivity) may be unnecessary and even undesirable for privacy/security reasons. Just like hosts within the first category, such hosts may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises. Category 3: hosts that need network layer access outside the enterprise (provided via IP connectivity); hosts in the last category require IP addresses that are globally unambiguous. We will refer to the hosts in the first and second categories as "private". We will refer to the hosts in the third category as "public". Many applications require connectivity only within one enterprise and do not need external (outside the enterprise) connectivity for the majority of internal hosts. In larger enterprises it is often easy to identify a substantial number of hosts using TCP/IP that do not need network layer connectivity outside the enterprise. Some examples, where external connectivity might not be required, are: - A large airport which has its arrival/departure displays individually addressable via TCP/IP. It is very unlikely that these displays need to be directly accessible from other networks. - Large organizations like banks and retail chains are switching to TCP/IP for their internal communication. Large numbers of local workstations like cash registers, money machines, and equipment at clerical positions rarely need to have such connectivity. - For security reasons, many enterprises use application layer gateways to connect their internal network to the Internet. The internal network usually does not have direct access to the Internet, thus only one or more gateways are visible from the Internet. In this case, the internal network can use non-unique IP network numbers. - Interfaces of routers on an internal network usually do not need to be directly accessible from outside the enterprise. Rekhter, et al Best Current Practice [Page 3]
RFC 1918 Address Allocation for Private Internets February 1996 3. Private Address Space The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets: 10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) We will refer to the first block as "24-bit block", the second as "20-bit block", and to the third as "16-bit" block. Note that (in pre-CIDR notation) the first block is nothing but a single class A network number, while the second block is a set of 16 contiguous class B network numbers, and third block is a set of 256 contiguous class C network numbers. An enterprise that decides to use IP addresses out of the address space defined in this document can do so without any coordination with IANA or an Internet registry. The address space can thus be used by many enterprises. Addresses within this private address space will only be unique within the enterprise, or the set of enterprises which choose to cooperate over this space so they may communicate with each other in their own private internet. As before, any enterprise that needs globally unique address space is required to obtain such addresses from an Internet registry. An enterprise that requests IP addresses for its external connectivity will never be assigned addresses from the blocks defined above. In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any host outside of the enterprise. While not having external (outside of the enterprise) IP connectivity private hosts can still have access to external services via mediating gateways (e.g., application layer gateways). All other hosts will be public and will use globally unique address space assigned by an Internet Registry. Public hosts can communicate with other hosts inside the enterprise both public and private and can have IP connectivity to public hosts outside the enterprise. Public hosts do not have connectivity to private hosts of other enterprises. Rekhter, et al Best Current Practice [Page 4]
RFC 1918 Address Allocation for Private Internets February 1996 Moving a host from private to public or vice versa involves a change of IP address, changes to the appropriate DNS entries, and changes to configuration files on other hosts that reference the host by IP address. Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks. If such a router receives such information the rejection shall not be treated as a routing protocol error. Indirect references to such addresses should be contained within the enterprise. Prominent examples of such references are DNS Resource Records and other information referring to internal private addresses. In particular, Internet service providers should take measures to prevent such leakage. 4. Advantages and Disadvantages of Using Private Address Space The obvious advantage of using private address space for the Internet at large is to conserve the globally unique address space by not using it where global uniqueness is not required. Enterprises themselves also enjoy a number of benefits from their usage of private address space: They gain a lot of flexibility in network design by having more address space at their disposal than they could obtain from the globally unique pool. This enables operationally and administratively convenient addressing schemes as well as easier growth paths. For a variety of reasons the Internet has already encountered situations where an enterprise that has not been connected to the Internet had used IP address space for its hosts without getting this space assigned from the IANA. In some cases this address space had been already assigned to other enterprises. If such an enterprise would later connects to the Internet, this could potentially create very serious problems, as IP routing cannot provide correct operations in presence of ambiguous addressing. Although in principle Internet Service Providers should guard against such mistakes through the use of route filters, this does not always happen in practice. Using private address space provides a safe choice for such enterprises, avoiding clashes once outside connectivity is needed. Rekhter, et al Best Current Practice [Page 5]
RFC 1918 Address Allocation for Private Internets February 1996 A major drawback to the use of private address space is that it may actually reduce an enterprise's flexibility to access the Internet. Once one commits to using a private address, one is committing to renumber part or all of an enterprise, should one decide to provide IP connectivity between that part (or all of the enterprise) and the Internet. Usually the cost of renumbering can be measured by counting the number of hosts that have to transition from private to public. As was discussed earlier, however, even if a network uses globally unique addresses, it may still have to renumber in order to acquire Internet-wide IP connectivity. Another drawback to the use of private address space is that it may require renumbering when merging several private internets into a single private internet. If we review the examples we list in Section 2, we note that companies tend to merge. If such companies prior to the merge maintained their uncoordinated internets using private address space, then if after the merge these private internets would be combined into a single private internet, some addresses within the combined private internet may not be unique. As a result, hosts with these addresses would need to be renumbered. The cost of renumbering may well be mitigated by development and deployment of tools that facilitate renumbering (e.g. Dynamic Host Configuration Protocol (DHCP)). When deciding whether to use private addresses, we recommend to inquire computer and software vendors about availability of such tools. A separate IETF effort (PIER Working Group) is pursuing full documentation of the requirements and procedures for renumbering. 5. Operational Considerations One possible strategy is to design the private part of the network first and use private address space for all internal links. Then plan public subnets at the locations needed and design the external connectivity. This design does not need to be fixed permanently. If a group of one or more hosts requires to change their status (from private to public or vice versa) later, this can be accomplished by renumbering only the hosts involved, and changing physical connectivity, if needed. In locations where such changes can be foreseen (machine rooms, etc.), it is advisable to configure separate physical media for public and private subnets to facilitate such changes. In order to avoid major network disruptions, it is advisable to group hosts with similar connectivity needs on their own subnets. Rekhter, et al Best Current Practice [Page 6]
RFC 1918 Address Allocation for Private Internets February 1996 If a suitable subnetting scheme can be designed and is supported by the equipment concerned, it is advisable to use the 24-bit block (class A network) of private address space and make an addressing plan with a good growth path. If subnetting is a problem, the 16-bit block (class C networks), or the 20-bit block (class B networks) of private address space can be used. One might be tempted to have both public and private addresses on the same physical medium. While this is possible, there are pitfalls to such a design (note that the pitfalls have nothing to do with the use of private addresses, but are due to the presence of multiple IP subnets on a common Data Link subnetwork). We advise caution when proceeding in this area. It is strongly recommended that routers which connect enterprises to external networks are set up with appropriate packet and routing filters at both ends of the link in order to prevent packet and routing information leakage. An enterprise should also filter any private networks from inbound routing information in order to protect itself from ambiguous routing situations which can occur if routes to the private address space point outside the enterprise. It is possible for two sites, who both coordinate their private address space, to communicate with each other over a public network. To do so they must use some method of encapsulation at their borders to a public network, thus keeping their private addresses private. If two (or more) organizations follow the address allocation specified in this document and then later wish to establish IP connectivity with each other, then there is a risk that address uniqueness would be violated. To minimize the risk it is strongly recommended that an organization using private IP addresses choose randomly from the reserved pool of private addresses, when allocating sub-blocks for its internal allocation. If an enterprise uses the private address space, or a mix of private and public address spaces, then DNS clients outside of the enterprise should not see addresses in the private address space used by the enterprise, since these addresses would be ambiguous. One way to ensure this is to run two authority servers for each DNS zone containing both publically and privately addressed hosts. One server would be visible from the public address space and would contain only the subset of the enterprise's addresses which were reachable using public addresses. The other server would be reachable only from the private network and would contain the full set of data, including the private addresses and whatever public addresses are reachable the private network. In order to ensure consistency, both servers should be configured from the same data of which the publically visible zone Rekhter, et al Best Current Practice [Page 7]
RFC 1918 Address Allocation for Private Internets February 1996 only contains a filtered version. There is certain degree of additional complexity associated with providing these capabilities. 6. Security Considerations Security issues are not addressed in this memo.7. Conclusion With the described scheme many large enterprises will need only a relatively small block of addresses from the globally unique IP address space. The Internet at large benefits through conservation of globally unique address space which will effectively lengthen the lifetime of the IP address space. The enterprises benefit from the increased flexibility provided by a relatively large private address space. However, use of private addressing requires that an organization renumber part or all of its enterprise network, as its connectivity requirements change over time.8. Acknowledgments We would like to thank Tony Bates (MCI), Jordan Becker (ANS), Hans- Werner Braun (SDSC), Ross Callon (BayNetworks), John Curran (BBN Planet), Vince Fuller (BBN Planet), Tony Li (cisco Systems), Anne Lord (RIPE NCC), Milo Medin (NSI), Marten Terpstra (BayNetworks), Geza Turchanyi (RIPE NCC), Christophe Wolfhugel (Pasteur Institute), Andy Linton (connect.com.au), Brian Carpenter (CERN), Randy Bush (PSG), Erik Fair (Apple Computer), Dave Crocker (Brandenburg Consulting), Tom Kessler (SGI), Dave Piscitello (Core Competence), Matt Crawford (FNAL), Michael Patton (BBN), and Paul Vixie (Internet Software Consortium) for their review and constructive comments.9. References [RFC1466] Gerich, E., "Guidelines for Management of IP Address Space", RFC 1466, Merit Network, Inc., May 1993. [RFC1518] Rekhter, Y., and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993. [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993. Rekhter, et al Best Current Practice [Page 8]
RFC 1918 Address Allocation for Private Internets February 1996 10. Authors' Addresses Yakov Rekhter Cisco systems 170 West Tasman Drive San Jose, CA, USA Phone: +1 914 528 0090 Fax: +1 408 526-4952 EMail: [email protected] Robert G Moskowitz Chrysler Corporation CIMS: 424-73-00 25999 Lawrence Ave Center Line, MI 48015 Phone: +1 810 758 8212 Fax: +1 810 758 8173 EMail: [email protected] Daniel Karrenberg RIPE Network Coordination Centre Kruislaan 409 1098 SJ Amsterdam, the Netherlands Phone: +31 20 592 5065 Fax: +31 20 592 5090 EMail: [email protected] Geert Jan de Groot RIPE Network Coordination Centre Kruislaan 409 1098 SJ Amsterdam, the Netherlands Phone: +31 20 592 5065 Fax: +31 20 592 5090 EMail: [email protected] Eliot Lear Mail Stop 15-730 Silicon Graphics, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94043-1389 Phone: +1 415 960 1980 Fax: +1 415 961 9584 EMail: [email protected] Rekhter, et al Best Current Practice [Page 9]
Html markup produced by rfcmarkup 1.115, available from https://tools.ietf.org/tools/rfcmarkup/
Updated by: 6761 BEST CURRENT PRACTICE
Errata Exist
Network Working Group Y. Rekhter Request for Comments: 1918 Cisco Systems Obsoletes: 1627, 1597 B. Moskowitz BCP: 5 Chrysler Corp. Category: Best Current Practice D. Karrenberg RIPE NCC G. J. de Groot RIPE NCC E. Lear Silicon Graphics, Inc. February 1996 Address Allocation for Private Internets Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.1. Introduction For the purposes of this document, an enterprise is an entity autonomously operating a network using TCP/IP and in particular determining the addressing plan and address assignments within that network. This document describes address allocation for private internets. The allocation permits full network layer connectivity among all hosts inside an enterprise as well as among all public hosts of different enterprises. The cost of using private internet address space is the potentially costly effort to renumber hosts and networks between public and private.2. Motivation With the proliferation of TCP/IP technology worldwide, including outside the Internet itself, an increasing number of non-connected enterprises use this technology and its addressing capabilities for sole intra-enterprise communications, without any intention to ever directly connect to other enterprises or the Internet itself. The Internet has grown beyond anyone's expectations. Sustained exponential growth continues to introduce new challenges. One challenge is a concern within the community that globally unique address space will be exhausted. A separate and far more pressing concern is that the amount of routing overhead will grow beyond the Rekhter, et al Best Current Practice [Page 1]
RFC 1918 Address Allocation for Private Internets February 1996 capabilities of Internet Service Providers. Efforts are in progress within the community to find long term solutions to both of these problems. Meanwhile it is necessary to revisit address allocation procedures, and their impact on the Internet routing system. To contain growth of routing overhead, an Internet Provider obtains a block of address space from an address registry, and then assigns to its customers addresses from within that block based on each customer requirement. The result of this process is that routes to many customers will be aggregated together, and will appear to other providers as a single route [RFC1518], [RFC1519]. In order for route aggregation to be effective, Internet providers encourage customers joining their network to use the provider's block, and thus renumber their computers. Such encouragement may become a requirement in the future. With the current size of the Internet and its growth rate it is no longer realistic to assume that by virtue of acquiring globally unique IP addresses out of an Internet registry an organization that acquires such addresses would have Internet-wide IP connectivity once the organization gets connected to the Internet. To the contrary, it is quite likely that when the organization would connect to the Internet to achieve Internet-wide IP connectivity the organization would need to change IP addresses (renumber) all of its public hosts (hosts that require Internet-wide IP connectivity), regardless of whether the addresses used by the organization initially were globally unique or not. It has been typical to assign globally unique addresses to all hosts that use TCP/IP. In order to extend the life of the IPv4 address space, address registries are requiring more justification than ever before, making it harder for organizations to acquire additional address space [RFC1466]. Hosts within enterprises that use IP can be partitioned into three categories: Category 1: hosts that do not require access to hosts in other enterprises or the Internet at large; hosts within this category may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises. Category 2: hosts that need access to a limited set of outside services (e.g., E-mail, FTP, netnews, remote login) which can be handled by mediating gateways (e.g., application layer gateways). For many hosts in this category an unrestricted external access (provided Rekhter, et al Best Current Practice [Page 2]
RFC 1918 Address Allocation for Private Internets February 1996 via IP connectivity) may be unnecessary and even undesirable for privacy/security reasons. Just like hosts within the first category, such hosts may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises. Category 3: hosts that need network layer access outside the enterprise (provided via IP connectivity); hosts in the last category require IP addresses that are globally unambiguous. We will refer to the hosts in the first and second categories as "private". We will refer to the hosts in the third category as "public". Many applications require connectivity only within one enterprise and do not need external (outside the enterprise) connectivity for the majority of internal hosts. In larger enterprises it is often easy to identify a substantial number of hosts using TCP/IP that do not need network layer connectivity outside the enterprise. Some examples, where external connectivity might not be required, are: - A large airport which has its arrival/departure displays individually addressable via TCP/IP. It is very unlikely that these displays need to be directly accessible from other networks. - Large organizations like banks and retail chains are switching to TCP/IP for their internal communication. Large numbers of local workstations like cash registers, money machines, and equipment at clerical positions rarely need to have such connectivity. - For security reasons, many enterprises use application layer gateways to connect their internal network to the Internet. The internal network usually does not have direct access to the Internet, thus only one or more gateways are visible from the Internet. In this case, the internal network can use non-unique IP network numbers. - Interfaces of routers on an internal network usually do not need to be directly accessible from outside the enterprise. Rekhter, et al Best Current Practice [Page 3]
RFC 1918 Address Allocation for Private Internets February 1996 3. Private Address Space The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets: 10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) We will refer to the first block as "24-bit block", the second as "20-bit block", and to the third as "16-bit" block. Note that (in pre-CIDR notation) the first block is nothing but a single class A network number, while the second block is a set of 16 contiguous class B network numbers, and third block is a set of 256 contiguous class C network numbers. An enterprise that decides to use IP addresses out of the address space defined in this document can do so without any coordination with IANA or an Internet registry. The address space can thus be used by many enterprises. Addresses within this private address space will only be unique within the enterprise, or the set of enterprises which choose to cooperate over this space so they may communicate with each other in their own private internet. As before, any enterprise that needs globally unique address space is required to obtain such addresses from an Internet registry. An enterprise that requests IP addresses for its external connectivity will never be assigned addresses from the blocks defined above. In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future and thus could be classified as private. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any host outside of the enterprise. While not having external (outside of the enterprise) IP connectivity private hosts can still have access to external services via mediating gateways (e.g., application layer gateways). All other hosts will be public and will use globally unique address space assigned by an Internet Registry. Public hosts can communicate with other hosts inside the enterprise both public and private and can have IP connectivity to public hosts outside the enterprise. Public hosts do not have connectivity to private hosts of other enterprises. Rekhter, et al Best Current Practice [Page 4]
RFC 1918 Address Allocation for Private Internets February 1996 Moving a host from private to public or vice versa involves a change of IP address, changes to the appropriate DNS entries, and changes to configuration files on other hosts that reference the host by IP address. Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks. If such a router receives such information the rejection shall not be treated as a routing protocol error. Indirect references to such addresses should be contained within the enterprise. Prominent examples of such references are DNS Resource Records and other information referring to internal private addresses. In particular, Internet service providers should take measures to prevent such leakage. 4. Advantages and Disadvantages of Using Private Address Space The obvious advantage of using private address space for the Internet at large is to conserve the globally unique address space by not using it where global uniqueness is not required. Enterprises themselves also enjoy a number of benefits from their usage of private address space: They gain a lot of flexibility in network design by having more address space at their disposal than they could obtain from the globally unique pool. This enables operationally and administratively convenient addressing schemes as well as easier growth paths. For a variety of reasons the Internet has already encountered situations where an enterprise that has not been connected to the Internet had used IP address space for its hosts without getting this space assigned from the IANA. In some cases this address space had been already assigned to other enterprises. If such an enterprise would later connects to the Internet, this could potentially create very serious problems, as IP routing cannot provide correct operations in presence of ambiguous addressing. Although in principle Internet Service Providers should guard against such mistakes through the use of route filters, this does not always happen in practice. Using private address space provides a safe choice for such enterprises, avoiding clashes once outside connectivity is needed. Rekhter, et al Best Current Practice [Page 5]
RFC 1918 Address Allocation for Private Internets February 1996 A major drawback to the use of private address space is that it may actually reduce an enterprise's flexibility to access the Internet. Once one commits to using a private address, one is committing to renumber part or all of an enterprise, should one decide to provide IP connectivity between that part (or all of the enterprise) and the Internet. Usually the cost of renumbering can be measured by counting the number of hosts that have to transition from private to public. As was discussed earlier, however, even if a network uses globally unique addresses, it may still have to renumber in order to acquire Internet-wide IP connectivity. Another drawback to the use of private address space is that it may require renumbering when merging several private internets into a single private internet. If we review the examples we list in Section 2, we note that companies tend to merge. If such companies prior to the merge maintained their uncoordinated internets using private address space, then if after the merge these private internets would be combined into a single private internet, some addresses within the combined private internet may not be unique. As a result, hosts with these addresses would need to be renumbered. The cost of renumbering may well be mitigated by development and deployment of tools that facilitate renumbering (e.g. Dynamic Host Configuration Protocol (DHCP)). When deciding whether to use private addresses, we recommend to inquire computer and software vendors about availability of such tools. A separate IETF effort (PIER Working Group) is pursuing full documentation of the requirements and procedures for renumbering. 5. Operational Considerations One possible strategy is to design the private part of the network first and use private address space for all internal links. Then plan public subnets at the locations needed and design the external connectivity. This design does not need to be fixed permanently. If a group of one or more hosts requires to change their status (from private to public or vice versa) later, this can be accomplished by renumbering only the hosts involved, and changing physical connectivity, if needed. In locations where such changes can be foreseen (machine rooms, etc.), it is advisable to configure separate physical media for public and private subnets to facilitate such changes. In order to avoid major network disruptions, it is advisable to group hosts with similar connectivity needs on their own subnets. Rekhter, et al Best Current Practice [Page 6]
RFC 1918 Address Allocation for Private Internets February 1996 If a suitable subnetting scheme can be designed and is supported by the equipment concerned, it is advisable to use the 24-bit block (class A network) of private address space and make an addressing plan with a good growth path. If subnetting is a problem, the 16-bit block (class C networks), or the 20-bit block (class B networks) of private address space can be used. One might be tempted to have both public and private addresses on the same physical medium. While this is possible, there are pitfalls to such a design (note that the pitfalls have nothing to do with the use of private addresses, but are due to the presence of multiple IP subnets on a common Data Link subnetwork). We advise caution when proceeding in this area. It is strongly recommended that routers which connect enterprises to external networks are set up with appropriate packet and routing filters at both ends of the link in order to prevent packet and routing information leakage. An enterprise should also filter any private networks from inbound routing information in order to protect itself from ambiguous routing situations which can occur if routes to the private address space point outside the enterprise. It is possible for two sites, who both coordinate their private address space, to communicate with each other over a public network. To do so they must use some method of encapsulation at their borders to a public network, thus keeping their private addresses private. If two (or more) organizations follow the address allocation specified in this document and then later wish to establish IP connectivity with each other, then there is a risk that address uniqueness would be violated. To minimize the risk it is strongly recommended that an organization using private IP addresses choose randomly from the reserved pool of private addresses, when allocating sub-blocks for its internal allocation. If an enterprise uses the private address space, or a mix of private and public address spaces, then DNS clients outside of the enterprise should not see addresses in the private address space used by the enterprise, since these addresses would be ambiguous. One way to ensure this is to run two authority servers for each DNS zone containing both publically and privately addressed hosts. One server would be visible from the public address space and would contain only the subset of the enterprise's addresses which were reachable using public addresses. The other server would be reachable only from the private network and would contain the full set of data, including the private addresses and whatever public addresses are reachable the private network. In order to ensure consistency, both servers should be configured from the same data of which the publically visible zone Rekhter, et al Best Current Practice [Page 7]
RFC 1918 Address Allocation for Private Internets February 1996 only contains a filtered version. There is certain degree of additional complexity associated with providing these capabilities. 6. Security Considerations Security issues are not addressed in this memo.7. Conclusion With the described scheme many large enterprises will need only a relatively small block of addresses from the globally unique IP address space. The Internet at large benefits through conservation of globally unique address space which will effectively lengthen the lifetime of the IP address space. The enterprises benefit from the increased flexibility provided by a relatively large private address space. However, use of private addressing requires that an organization renumber part or all of its enterprise network, as its connectivity requirements change over time.8. Acknowledgments We would like to thank Tony Bates (MCI), Jordan Becker (ANS), Hans- Werner Braun (SDSC), Ross Callon (BayNetworks), John Curran (BBN Planet), Vince Fuller (BBN Planet), Tony Li (cisco Systems), Anne Lord (RIPE NCC), Milo Medin (NSI), Marten Terpstra (BayNetworks), Geza Turchanyi (RIPE NCC), Christophe Wolfhugel (Pasteur Institute), Andy Linton (connect.com.au), Brian Carpenter (CERN), Randy Bush (PSG), Erik Fair (Apple Computer), Dave Crocker (Brandenburg Consulting), Tom Kessler (SGI), Dave Piscitello (Core Competence), Matt Crawford (FNAL), Michael Patton (BBN), and Paul Vixie (Internet Software Consortium) for their review and constructive comments.9. References [RFC1466] Gerich, E., "Guidelines for Management of IP Address Space", RFC 1466, Merit Network, Inc., May 1993. [RFC1518] Rekhter, Y., and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993. [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993. Rekhter, et al Best Current Practice [Page 8]
RFC 1918 Address Allocation for Private Internets February 1996 10. Authors' Addresses Yakov Rekhter Cisco systems 170 West Tasman Drive San Jose, CA, USA Phone: +1 914 528 0090 Fax: +1 408 526-4952 EMail: [email protected] Robert G Moskowitz Chrysler Corporation CIMS: 424-73-00 25999 Lawrence Ave Center Line, MI 48015 Phone: +1 810 758 8212 Fax: +1 810 758 8173 EMail: [email protected] Daniel Karrenberg RIPE Network Coordination Centre Kruislaan 409 1098 SJ Amsterdam, the Netherlands Phone: +31 20 592 5065 Fax: +31 20 592 5090 EMail: [email protected] Geert Jan de Groot RIPE Network Coordination Centre Kruislaan 409 1098 SJ Amsterdam, the Netherlands Phone: +31 20 592 5065 Fax: +31 20 592 5090 EMail: [email protected] Eliot Lear Mail Stop 15-730 Silicon Graphics, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94043-1389 Phone: +1 415 960 1980 Fax: +1 415 961 9584 EMail: [email protected] Rekhter, et al Best Current Practice [Page 9]
Html markup produced by rfcmarkup 1.115, available from https://tools.ietf.org/tools/rfcmarkup/
RFC 2860