diff options
Diffstat (limited to 'contrib/bind9/doc/rfc')
97 files changed, 0 insertions, 91821 deletions
diff --git a/contrib/bind9/doc/rfc/index b/contrib/bind9/doc/rfc/index deleted file mode 100644 index 5c588db93016..000000000000 --- a/contrib/bind9/doc/rfc/index +++ /dev/null @@ -1,103 +0,0 @@ - 952: DOD INTERNET HOST TABLE SPECIFICATION -1032: DOMAIN ADMINISTRATORS GUIDE -1033: DOMAIN ADMINISTRATORS OPERATIONS GUIDE -1034: DOMAIN NAMES - CONCEPTS AND FACILITIES -1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION -1101: DNS Encoding of Network Names and Other Types -1122: Requirements for Internet Hosts -- Communication Layers -1123: Requirements for Internet Hosts -- Application and Support -1183: New DNS RR Definitions (AFSDB, RP, X25, ISDN and RT) -1348: DNS NSAP RRs -1535: A Security Problem and Proposed Correction - With Widely Deployed DNS Software -1536: Common DNS Implementation Errors and Suggested Fixes -1537: Common DNS Data File Configuration Errors -1591: Domain Name System Structure and Delegation -1611: DNS Server MIB Extensions -1612: DNS Resolver MIB Extensions -1706: DNS NSAP Resource Records -1712: DNS Encoding of Geographical Location -1750: Randomness Recommendations for Security -1876: A Means for Expressing Location Information in the Domain Name System -1886: DNS Extensions to support IP version 6 -1982: Serial Number Arithmetic -1995: Incremental Zone Transfer in DNS -1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) -2052: A DNS RR for specifying the location of services (DNS SRV) -2104: HMAC: Keyed-Hashing for Message Authentication -2119: Key words for use in RFCs to Indicate Requirement Levels -2133: Basic Socket Interface Extensions for IPv6 -2136: Dynamic Updates in the Domain Name System (DNS UPDATE) -2137: Secure Domain Name System Dynamic Update -2163: Using the Internet DNS to Distribute MIXER - Conformant Global Address Mapping (MCGAM) -2168: Resolution of Uniform Resource Identifiers using the Domain Name System -2181: Clarifications to the DNS Specification -2230: Key Exchange Delegation Record for the DNS -2308: Negative Caching of DNS Queries (DNS NCACHE) -2317: Classless IN-ADDR.ARPA delegation -2373: IP Version 6 Addressing Architecture -2374: An IPv6 Aggregatable Global Unicast Address Format -2375: IPv6 Multicast Address Assignments -2418: IETF Working Group Guidelines and Procedures -2535: Domain Name System Security Extensions -2536: DSA KEYs and SIGs in the Domain Name System (DNS) -2537: RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) -2538: Storing Certificates in the Domain Name System (DNS) -2539: Storage of Diffie-Hellman Keys in the Domain Name System (DNS) -2540: Detached Domain Name System (DNS) Information -2541: DNS Security Operational Considerations -2553: Basic Socket Interface Extensions for IPv6 -2671: Extension Mechanisms for DNS (EDNS0) -2672: Non-Terminal DNS Name Redirection -2673: Binary Labels in the Domain Name System -2782: A DNS RR for specifying the location of services (DNS SRV) -2825: A Tangled Web: Issues of I18N, Domain Names, and the - Other Internet protocols -2826: IAB Technical Comment on the Unique DNS Root -2845: Secret Key Transaction Authentication for DNS (TSIG) -2874: DNS Extensions to Support IPv6 Address Aggregation and Renumbering -2915: The Naming Authority Pointer (NAPTR) DNS Resource Record -2929: Domain Name System (DNS) IANA Considerations -2930: Secret Key Establishment for DNS (TKEY RR) -2931: DNS Request and Transaction Signatures ( SIG(0)s ) -3007: Secure Domain Name System (DNS) Dynamic Update -3008: Domain Name System Security (DNSSEC) Signing Authority -3071: Reflections on the DNS, RFC 1591, and Categories of Domains -3090: DNS Security Extension Clarification on Zone Status -3110: RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) -3123: A DNS RR Type for Lists of Address Prefixes (APL RR) -3152: Delegation of IP6.ARPA -3197: Applicability Statement for DNS MIB Extensions -3225: Indicating Resolver Support of DNSSEC -3226: DNSSEC and IPv6 A6 aware server/resolver message size requirements -3258: Distributing Authoritative Name Servers via Shared Unicast Addresses -3363: Representing Internet Protocol version 6 (IPv6) - Addresses in the Domain Name System (DNS) -3364: Tradeoffs in Domain Name System (DNS) Support - for Internet Protocol version 6 (IPv6) -3425: Obsoleting IQUERY -3445: Limiting the Scope of the KEY Resource Record (RR) -3490: Internationalizing Domain Names In Applications (IDNA) -3491: Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN) -3492: Punycode:A Bootstring encoding of Unicode for - Internationalized Domain Names in Applications (IDNA) -3493: Basic Socket Interface Extensions for IPv6 -3513: Internet Protocol Version 6 (IPv6) Addressing Architecture -3596: DNS Extensions to Support IP Version 6 -3597: Handling of Unknown DNS Resource Record (RR) Types -3645: Generic Security Service Algorithm for - Secret Key Transaction Authentication for DNS (GSS-TSIG) -3655: Redefinition of DNS Authenticated Data (AD) bit -3658: Delegation Signer (DS) Resource Record (RR) -3757: Domain Name System KEY (DNSKEY) Resource Record (RR) - Secure Entry Point (SEP) Flag -3833: Threat Analysis of the Domain Name System (DNS) -3845: DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format -3901: DNS IPv6 Transport Operational Guidelines -4025: A Method for Storing IPsec Keying Material in DNS -4033: DNS Security Introduction and Requirements -4034: Resource Records for the DNS Security Extensions -4035: Protocol Modifications for the DNS Security Extensions -4074: Common Misbehavior Against DNS Queries for IPv6 Addresses -4159: Deprecation of "ip6.int" diff --git a/contrib/bind9/doc/rfc/rfc1032.txt b/contrib/bind9/doc/rfc/rfc1032.txt deleted file mode 100644 index 0e82721cee71..000000000000 --- a/contrib/bind9/doc/rfc/rfc1032.txt +++ /dev/null @@ -1,781 +0,0 @@ -Network Working Group M. Stahl -Request for Comments: 1032 SRI International - November 1987 - - - DOMAIN ADMINISTRATORS GUIDE - - -STATUS OF THIS MEMO - - This memo describes procedures for registering a domain with the - Network Information Center (NIC) of Defense Data Network (DDN), and - offers guidelines on the establishment and administration of a domain - in accordance with the requirements specified in RFC-920. It is - intended for use by domain administrators. This memo should be used - in conjunction with RFC-920, which is an official policy statement of - the Internet Activities Board (IAB) and the Defense Advanced Research - Projects Agency (DARPA). Distribution of this memo is unlimited. - -BACKGROUND - - Domains are administrative entities that provide decentralized - management of host naming and addressing. The domain-naming system - is distributed and hierarchical. - - The NIC is designated by the Defense Communications Agency (DCA) to - provide registry services for the domain-naming system on the DDN and - DARPA portions of the Internet. - - As registrar of top-level and second-level domains, as well as - administrator of the root domain name servers on behalf of DARPA and - DDN, the NIC is responsible for maintaining the root server zone - files and their binary equivalents. In addition, the NIC is - responsible for administering the top-level domains of "ARPA," "COM," - "EDU," "ORG," "GOV," and "MIL" on behalf of DCA and DARPA until it - becomes feasible for other appropriate organizations to assume those - responsibilities. - - It is recommended that the guidelines described in this document be - used by domain administrators in the establishment and control of - second-level domains. - -THE DOMAIN ADMINISTRATOR - - The role of the domain administrator (DA) is that of coordinator, - manager, and technician. If his domain is established at the second - level or lower in the tree, the DA must register by interacting with - the management of the domain directly above his, making certain that - - - -Stahl [Page 1] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - - his domain satisfies all the requirements of the administration under - which his domain would be situated. To find out who has authority - over the name space he wishes to join, the DA can ask the NIC - Hostmaster. Information on contacts for the top-level and second- - level domains can also be found on line in the file NETINFO:DOMAIN- - CONTACTS.TXT, which is available from the NIC via anonymous FTP. - - The DA should be technically competent; he should understand the - concepts and procedures for operating a domain server, as described - in RFC-1034, and make sure that the service provided is reliable and - uninterrupted. It is his responsibility or that of his delegate to - ensure that the data will be current at all times. As a manager, the - DA must be able to handle complaints about service provided by his - domain name server. He must be aware of the behavior of the hosts in - his domain, and take prompt action on reports of problems, such as - protocol violations or other serious misbehavior. The administrator - of a domain must be a responsible person who has the authority to - either enforce these actions himself or delegate them to someone - else. - - Name assignments within a domain are controlled by the DA, who should - verify that names are unique within his domain and that they conform - to standard naming conventions. He furnishes access to names and - name-related information to users both inside and outside his domain. - He should work closely with the personnel he has designated as the - "technical and zone" contacts for his domain, for many administrative - decisions will be made on the basis of input from these people. - -THE DOMAIN TECHNICAL AND ZONE CONTACT - - A zone consists of those contiguous parts of the domain tree for - which a domain server has complete information and over which it has - authority. A domain server may be authoritative for more than one - zone. The domain technical/zone contact is the person who tends to - the technical aspects of maintaining the domain's name server and - resolver software, and database files. He keeps the name server - running, and interacts with technical people in other domains and - zones to solve problems that affect his zone. - -POLICIES - - Domain or host name choices and the allocation of domain name space - are considered to be local matters. In the event of conflicts, it is - the policy of the NIC not to get involved in local disputes or in the - local decision-making process. The NIC will not act as referee in - disputes over such matters as who has the "right" to register a - particular top-level or second-level domain for an organization. The - NIC considers this a private local matter that must be settled among - - - -Stahl [Page 2] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - - the parties involved prior to their commencing the registration - process with the NIC. Therefore, it is assumed that the responsible - person for a domain will have resolved any local conflicts among the - members of his domain before registering that domain with the NIC. - The NIC will give guidance, if requested, by answering specific - technical questions, but will not provide arbitration in disputes at - the local level. This policy is also in keeping with the distributed - hierarchical nature of the domain-naming system in that it helps to - distribute the tasks of solving problems and handling questions. - - Naming conventions for hosts should follow the rules specified in - RFC-952. From a technical standpoint, domain names can be very long. - Each segment of a domain name may contain up to 64 characters, but - the NIC strongly advises DAs to choose names that are 12 characters - or fewer, because behind every domain system there is a human being - who must keep track of the names, addresses, contacts, and other data - in a database. The longer the name, the more likely the data - maintainer is to make a mistake. Users also will appreciate shorter - names. Most people agree that short names are easier to remember and - type; most domain names registered so far are 12 characters or fewer. - - Domain name assignments are made on a first-come-first-served basis. - The NIC has chosen not to register individual hosts directly under - the top-level domains it administers. One advantage of the domain - naming system is that administration and data maintenance can be - delegated down a hierarchical tree. Registration of hosts at the - same level in the tree as a second-level domain would dilute the - usefulness of this feature. In addition, the administrator of a - domain is responsible for the actions of hosts within his domain. We - would not want to find ourselves in the awkward position of policing - the actions of individual hosts. Rather, the subdomains registered - under these top-level domains retain the responsibility for this - function. - - Countries that wish to be registered as top-level domains are - required to name themselves after the two-letter country code listed - in the international standard ISO-3166. In some cases, however, the - two-letter ISO country code is identical to a state code used by the - U.S. Postal Service. Requests made by countries to use the three- - letter form of country code specified in the ISO-3166 standard will - be considered in such cases so as to prevent possible conflicts and - confusion. - - - - - - - - - -Stahl [Page 3] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - -HOW TO REGISTER - - Obtain a domain questionnaire from the NIC hostmaster, or FTP the - file NETINFO:DOMAIN-TEMPLATE.TXT from host SRI-NIC.ARPA. - - Fill out the questionnaire completely. Return it via electronic mail - to HOSTMASTER@SRI-NIC.ARPA. - - The APPENDIX to this memo contains the application form for - registering a top-level or second-level domain with the NIC. It - supersedes the version of the questionnaire found in RFC-920. The - application should be submitted by the person administratively - responsible for the domain, and must be filled out completely before - the NIC will authorize establishment of a top-level or second-level - domain. The DA is responsible for keeping his domain's data current - with the NIC or with the registration agent with which his domain is - registered. For example, the CSNET and UUCP managements act as - domain filters, processing domain applications for their own - organizations. They pass pertinent information along periodically to - the NIC for incorporation into the domain database and root server - files. The online file NETINFO:ALTERNATE-DOMAIN-PROCEDURE.TXT - outlines this procedure. It is highly recommended that the DA review - this information periodically and provide any corrections or - additions. Corrections should be submitted via electronic mail. - -WHICH DOMAIN NAME? - - The designers of the domain-naming system initiated several general - categories of names as top-level domain names, so that each could - accommodate a variety of organizations. The current top-level - domains registered with the DDN Network Information Center are ARPA, - COM, EDU, GOV, MIL, NET, and ORG, plus a number of top-level country - domains. To join one of these, a DA needs to be aware of the purpose - for which it was intended. - - "ARPA" is a temporary domain. It is by default appended to the - names of hosts that have not yet joined a domain. When the system - was begun in 1984, the names of all hosts in the Official DoD - Internet Host Table maintained by the NIC were changed by adding - of the label ".ARPA" in order to accelerate a transition to the - domain-naming system. Another reason for the blanket name changes - was to force hosts to become accustomed to using the new style - names and to modify their network software, if necessary. This - was done on a network-wide basis and was directed by DCA in DDN - Management Bulletin No. 22. Hosts that fall into this domain will - eventually move to other branches of the domain tree. - - - - - -Stahl [Page 4] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - - "COM" is meant to incorporate subdomains of companies and - businesses. - - "EDU" was initiated to accommodate subdomains set up by - universities and other educational institutions. - - "GOV" exists to act as parent domain for subdomains set up by - government agencies. - - "MIL" was initiated to act as parent to subdomains that are - developed by military organizations. - - "NET" was introduced as a parent domain for various network-type - organizations. Organizations that belong within this top-level - domain are generic or network-specific, such as network service - centers and consortia. "NET" also encompasses network - management-related organizations, such as information centers and - operations centers. - - "ORG" exists as a parent to subdomains that do not clearly fall - within the other top-level domains. This may include technical- - support groups, professional societies, or similar organizations. - - One of the guidelines in effect in the domain-naming system is that a - host should have only one name regardless of what networks it is - connected to. This implies, that, in general, domain names should - not include routing information or addresses. For example, a host - that has one network connection to the Internet and another to BITNET - should use the same name when talking to either network. For a - description of the syntax of domain names, please refer to Section 3 - of RFC-1034. - -VERIFICATION OF DATA - - The verification process can be accomplished in several ways. One of - these is through the NIC WHOIS server. If he has access to WHOIS, - the DA can type the command "whois domain <domain name><return>". - The reply from WHOIS will supply the following: the name and address - of the organization "owning" the domain; the name of the domain; its - administrative, technical, and zone contacts; the host names and - network addresses of sites providing name service for the domain. - - - - - - - - - - -Stahl [Page 5] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - - Example: - - @whois domain rice.edu<Return> - - Rice University (RICE-DOM) - Advanced Studies and Research - Houston, TX 77001 - - Domain Name: RICE.EDU - - Administrative Contact: - Kennedy, Ken (KK28) Kennedy@LLL-CRG.ARPA (713) 527-4834 - Technical Contact, Zone Contact: - Riffle, Vicky R. (VRR) rif@RICE.EDU - (713) 527-8101 ext 3844 - - Domain servers: - - RICE.EDU 128.42.5.1 - PENDRAGON.CS.PURDUE.EDU 128.10.2.5 - - - Alternatively, the DA can send an electronic mail message to - SERVICE@SRI-NIC.ARPA. In the subject line of the message header, the - DA should type "whois domain <domain name>". The requested - information will be returned via electronic mail. This method is - convenient for sites that do not have access to the NIC WHOIS - service. - - The initial application for domain authorization should be submitted - via electronic mail, if possible, to HOSTMASTER@SRI-NIC.ARPA. The - questionnaire described in the appendix may be used or a separate - application can be FTPed from host SRI-NIC.ARPA. The information - provided by the administrator will be reviewed by hostmaster - personnel for completeness. There will most likely be a few - exchanges of correspondence via electronic mail, the preferred method - of communication, prior to authorization of the domain. - -HOW TO GET MORE INFORMATION - - An informational table of the top-level domains and their root - servers is contained in the file NETINFO:DOMAINS.TXT online at SRI- - NIC.ARPA. This table can be obtained by FTPing the file. - Alternatively, the information can be acquired by opening a TCP or - UDP connection to the NIC Host Name Server, port 101 on SRI-NIC.ARPA, - and invoking the command "ALL-DOM". - - - - - -Stahl [Page 6] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - - The following online files, all available by FTP from SRI-NIC.ARPA, - contain pertinent domain information: - - - NETINFO:DOMAINS.TXT, a table of all top-level domains and the - network addresses of the machines providing domain name - service for them. It is updated each time a new top-level - domain is approved. - - - NETINFO:DOMAIN-INFO.TXT contains a concise list of all - top-level and second-level domain names registered with the - NIC and is updated monthly. - - - NETINFO:DOMAIN-CONTACTS.TXT also contains a list of all the - top level and second-level domains, but includes the - administrative, technical and zone contacts for each as well. - - - NETINFO:DOMAIN-TEMPLATE.TXT contains the questionnaire to be - completed before registering a top-level or second-level - domain. - - For either general or specific information on the domain system, do - one or more of the following: - - 1. Send electronic mail to HOSTMASTER@SRI-NIC.ARPA - - 2. Call the toll-free NIC hotline at (800) 235-3155 - - 3. Use FTP to get background RFCs and other files maintained - online at the NIC. Some pertinent RFCs are listed below in - the REFERENCES section of this memo. - - - - - - - - - - - - - - - - - - - - - -Stahl [Page 7] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - -REFERENCES - - The references listed here provide important background information - on the domain-naming system. Path names of the online files - available via anonymous FTP from the SRI-NIC.ARPA host are noted in - brackets. - - 1. Defense Communications Agency DDN Defense Communications - System, DDN Management Bulletin No. 22, Domain Names - Transition, March 1984. - [ DDN-NEWS:DDN-MGT-BULLETIN-22.TXT ] - - 2. Defense Communications Agency DDN Defense Communications - System, DDN Management Bulletin No. 32, Phase I of the Domain - Name Implementation, January 1987. - [ DDN-NEWS:DDN-MGT-BULLETIN-32.TXT ] - - 3. Harrenstien, K., M. Stahl, and E. Feinler, "Hostname - Server", RFC-953, DDN Network Information Center, SRI - International, October 1985. [ RFC:RFC953.TXT ] - - 4. Harrenstien, K., M. Stahl, and E. Feinler, "Official DoD - Internet Host Table Specification", RFC-952, DDN Network - Information Center, SRI International, October 1985. - [ RFC:RFC952.TXT ] - - 5. ISO, "Codes for the Representation of Names of Countries", - ISO-3166, International Standards Organization, May 1981. - [ Not online ] - - 6. Lazear, W.D., "MILNET Name Domain Transition", RFC-1031, - Mitre Corporation, October 1987. [ RFC:RFC1031.TXT ] - - 7. Lottor, M.K., "Domain Administrators Operations Guide", - RFC-1033, DDN Network Information Center, SRI International, - July 1987. [ RFC:RFC1033.TXT ] - - 8. Mockapetris, P., "Domain Names - Concepts and Facilities", - RFC-1034, USC Information Sciences Institute, October 1987. - [ RFC:RFC1034.TXT ] - - 9. Mockapetris, P., "Domain Names - Implementation and - Specification", RFC-1035, USC Information Sciences Institute, - October 1987. [ RFC:RFC1035.TXT ] - - 10. Mockapetris, P., "The Domain Name System", Proceedings of the - IFIP 6.5 Working Conference on Computer Message Services, - Nottingham, England, May 1984. Also as ISI/RS-84-133, June - - - -Stahl [Page 8] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - - 1984. [ Not online ] - - 11. Mockapetris, P., J. Postel, and P. Kirton, "Name Server - Design for Distributed Systems", Proceedings of the Seventh - International Conference on Computer Communication, October - 30 to November 3 1984, Sidney, Australia. Also as - ISI/RS-84-132, June 1984. [ Not online ] - - 12. Partridge, C., "Mail Routing and the Domain System", RFC-974, - CSNET-CIC, BBN Laboratories, January 1986. - [ RFC:RFC974.TXT ] - - 13. Postel, J., "The Domain Names Plan and Schedule", RFC-881, - USC Information Sciences Institute, November 1983. - [ RFC:RFC881.TXT ] - - 14. Reynolds, J., and Postel, J., "Assigned Numbers", RFC-1010 - USC Information Sciences Institute, May 1986. - [ RFC:RFC1010.TXT ] - - 15. Romano, S., and Stahl, M., "Internet Numbers", RFC-1020, - SRI, November 1987. - [ RFC:RFC1020.TXT ] - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Stahl [Page 9] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - -APPENDIX - - The following questionnaire may be FTPed from SRI-NIC.ARPA as - NETINFO:DOMAIN-TEMPLATE.TXT. - - --------------------------------------------------------------------- - - To establish a domain, the following information must be sent to the - NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA): - - NOTE: The key people must have electronic mailboxes and NIC - "handles," unique NIC database identifiers. If you have access to - "WHOIS", please check to see if you are registered and if so, make - sure the information is current. Include only your handle and any - changes (if any) that need to be made in your entry. If you do not - have access to "WHOIS", please provide all the information indicated - and a NIC handle will be assigned. - - (1) The name of the top-level domain to join. - - For example: COM - - (2) The NIC handle of the administrative head of the organization. - Alternately, the person's name, title, mailing address, phone number, - organization, and network mailbox. This is the contact point for - administrative and policy questions about the domain. In the case of - a research project, this should be the principal investigator. - - For example: - - Administrator - - Organization The NetWorthy Corporation - Name Penelope Q. Sassafrass - Title President - Mail Address The NetWorthy Corporation - 4676 Andrews Way, Suite 100 - Santa Clara, CA 94302-1212 - Phone Number (415) 123-4567 - Net Mailbox Sassafrass@ECHO.TNC.COM - NIC Handle PQS - - (3) The NIC handle of the technical contact for the domain. - Alternately, the person's name, title, mailing address, phone number, - organization, and network mailbox. This is the contact point for - problems concerning the domain or zone, as well as for updating - information about the domain or zone. - - - - -Stahl [Page 10] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - - For example: - - Technical and Zone Contact - - Organization The NetWorthy Corporation - Name Ansel A. Aardvark - Title Executive Director - Mail Address The NetWorthy Corporation - 4676 Andrews Way, Suite 100 - Santa Clara, CA. 94302-1212 - Phone Number (415) 123-6789 - Net Mailbox Aardvark@ECHO.TNC.COM - NIC Handle AAA2 - - (4) The name of the domain (up to 12 characters). This is the name - that will be used in tables and lists associating the domain with the - domain server addresses. [While, from a technical standpoint, domain - names can be quite long (programmers beware), shorter names are - easier for people to cope with.] - - For example: TNC - - (5) A description of the servers that provide the domain service for - translating names to addresses for hosts in this domain, and the date - they will be operational. - - A good way to answer this question is to say "Our server is - supplied by person or company X and does whatever their standard - issue server does." - - For example: Our server is a copy of the one operated by - the NIC; it will be installed and made operational on - 1 November 1987. - - (6) Domains must provide at least two independent servers for the - domain. Establishing the servers in physically separate locations - and on different PSNs is strongly recommended. A description of the - server machine and its backup, including - - - - - - - - - - - - - -Stahl [Page 11] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - - (a) Hardware and software (using keywords from the Assigned - Numbers RFC). - - (b) Host domain name and network addresses (which host on which - network for each connected network). - - (c) Any domain-style nicknames (please limit your domain-style - nickname request to one) - - For example: - - - Hardware and software - - VAX-11/750 and UNIX, or - IBM-PC and MS-DOS, or - DEC-1090 and TOPS-20 - - - Host domain names and network addresses - - BAR.FOO.COM 10.9.0.193 on ARPANET - - - Domain-style nickname - - BR.FOO.COM (same as BAR.FOO.COM 10.9.0.13 on ARPANET) - - (7) Planned mapping of names of any other network hosts, other than - the server machines, into the new domain's naming space. - - For example: - - BAR-FOO2.ARPA (10.8.0.193) -> FOO2.BAR.COM - BAR-FOO3.ARPA (10.7.0.193) -> FOO3.BAR.COM - BAR-FOO4.ARPA (10.6.0.193) -> FOO4.BAR.COM - - - (8) An estimate of the number of hosts that will be in the domain. - - (a) Initially - (b) Within one year - (c) Two years - (d) Five years. - - For example: - - (a) Initially = 50 - (b) One year = 100 - (c) Two years = 200 - (d) Five years = 500 - - - -Stahl [Page 12] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - - (9) The date you expect the fully qualified domain name to become - the official host name in HOSTS.TXT. - - Please note: If changing to a fully qualified domain name (e.g., - FOO.BAR.COM) causes a change in the official host name of an - ARPANET or MILNET host, DCA approval must be obtained beforehand. - Allow 10 working days for your requested changes to be processed. - - ARPANET sites should contact ARPANETMGR@DDN1.ARPA. MILNET sites - should contact HOSTMASTER@SRI-NIC.ARPA, 800-235-3155, for - further instructions. - - (10) Please describe your organization briefly. - - For example: The NetWorthy Corporation is a consulting - organization of people working with UNIX and the C language in an - electronic networking environment. It sponsors two technical - conferences annually and distributes a bimonthly newsletter. - - --------------------------------------------------------------------- - - This example of a completed application corresponds to the examples - found in the companion document RFC-1033, "Domain Administrators - Operations Guide." - - (1) The name of the top-level domain to join. - - COM - - (2) The NIC handle of the administrative contact person. - - NIC Handle JAKE - - (3) The NIC handle of the domain's technical and zone - contact person. - - NIC Handle DLE6 - - (4) The name of the domain. - - SRI - - (5) A description of the servers. - - Our server is the TOPS20 server JEEVES supplied by ISI; it - will be installed and made operational on 1 July 1987. - - - - - -Stahl [Page 13] - -RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 - - - (6) A description of the server machine and its backup: - - (a) Hardware and software - - DEC-1090T and TOPS20 - DEC-2065 and TOPS20 - - (b) Host domain name and network address - - KL.SRI.COM 10.1.0.2 on ARPANET, 128.18.10.6 on SRINET - STRIPE.SRI.COM 10.4.0.2 on ARPANET, 128.18.10.4 on SRINET - - (c) Domain-style nickname - - None - - (7) Planned mapping of names of any other network hosts, other than - the server machines, into the new domain's naming space. - - SRI-Blackjack.ARPA (128.18.2.1) -> Blackjack.SRI.COM - SRI-CSL.ARPA (192.12.33.2) -> CSL.SRI.COM - - (8) An estimate of the number of hosts that will be directly within - this domain. - - (a) Initially = 50 - (b) One year = 100 - (c) Two years = 200 - (d) Five years = 500 - - (9) A date when you expect the fully qualified domain name to become - the official host name in HOSTS.TXT. - - 31 September 1987 - - (10) Brief description of organization. - - SRI International is an independent, nonprofit, scientific - research organization. It performs basic and applied research - for government and commercial clients, and contributes to - worldwide economic, scientific, industrial, and social progress - through research and related services. - - - - - - - - - -Stahl [Page 14] - diff --git a/contrib/bind9/doc/rfc/rfc1033.txt b/contrib/bind9/doc/rfc/rfc1033.txt deleted file mode 100644 index 37029fd9ae01..000000000000 --- a/contrib/bind9/doc/rfc/rfc1033.txt +++ /dev/null @@ -1,1229 +0,0 @@ -Network Working Group M. Lottor -Request For Comments: 1033 SRI International - November 1987 - - - DOMAIN ADMINISTRATORS OPERATIONS GUIDE - - - -STATUS OF THIS MEMO - - This RFC provides guidelines for domain administrators in operating a - domain server and maintaining their portion of the hierarchical - database. Familiarity with the domain system is assumed. - Distribution of this memo is unlimited. - -ACKNOWLEDGMENTS - - This memo is a formatted collection of notes and excerpts from the - references listed at the end of this document. Of particular mention - are Paul Mockapetris and Kevin Dunlap. - -INTRODUCTION - - A domain server requires a few files to get started. It will - normally have some number of boot/startup files (also known as the - "safety belt" files). One section will contain a list of possible - root servers that the server will use to find the up-to-date list of - root servers. Another section will list the zone files to be loaded - into the server for your local domain information. A zone file - typically contains all the data for a particular domain. This guide - describes the data formats that can be used in zone files and - suggested parameters to use for certain fields. If you are - attempting to do anything advanced or tricky, consult the appropriate - domain RFC's for more details. - - Note: Each implementation of domain software may require different - files. Zone files are standardized but some servers may require - other startup files. See the appropriate documentation that comes - with your software. See the appendix for some specific examples. - -ZONES - - A zone defines the contents of a contiguous section of the domain - space, usually bounded by administrative boundaries. There will - typically be a separate data file for each zone. The data contained - in a zone file is composed of entries called Resource Records (RRs). - - - - -Lottor [Page 1] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - You may only put data in your domain server that you are - authoritative for. You must not add entries for domains other than - your own (except for the special case of "glue records"). - - A domain server will probably read a file on start-up that lists the - zones it should load into its database. The format of this file is - not standardized and is different for most domain server - implementations. For each zone it will normally contain the domain - name of the zone and the file name that contains the data to load for - the zone. - -ROOT SERVERS - - A resolver will need to find the root servers when it first starts. - When the resolver boots, it will typically read a list of possible - root servers from a file. - - The resolver will cycle through the list trying to contact each one. - When it finds a root server, it will ask it for the current list of - root servers. It will then discard the list of root servers it read - from the data file and replace it with the current list it received. - - Root servers will not change very often. You can get the names of - current root servers from the NIC. - - FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to - NIC@SRI-NIC.ARPA. - - As of this date (June 1987) they are: - - SRI-NIC.ARPA 10.0.0.51 26.0.0.73 - C.ISI.EDU 10.0.0.52 - BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2 - A.ISI.EDU 26.3.0.103 - -RESOURCE RECORDS - - Records in the zone data files are called resource records (RRs). - They are specified in RFC-883 and RFC-973. An RR has a standard - format as shown: - - <name> [<ttl>] [<class>] <type> <data> - - The record is divided into fields which are separated by white space. - - <name> - - The name field defines what domain name applies to the given - - - -Lottor [Page 2] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - RR. In some cases the name field can be left blank and it will - default to the name field of the previous RR. - - <ttl> - - TTL stands for Time To Live. It specifies how long a domain - resolver should cache the RR before it throws it out and asks a - domain server again. See the section on TTL's. If you leave - the TTL field blank it will default to the minimum time - specified in the SOA record (described later). - - <class> - - The class field specifies the protocol group. If left blank it - will default to the last class specified. - - <type> - - The type field specifies what type of data is in the RR. See - the section on types. - - <data> - - The data field is defined differently for each type and class - of data. Popular RR data formats are described later. - - The domain system does not guarantee to preserve the order of - resource records. Listing RRs (such as multiple address records) in - a certain order does not guarantee they will be used in that order. - - Case is preserved in names and data fields when loaded into the name - server. All comparisons and lookups in the name server are case - insensitive. - - Parenthesis ("(",")") are used to group data that crosses a line - boundary. - - A semicolon (";") starts a comment; the remainder of the line is - ignored. - - The asterisk ("*") is used for wildcarding. - - The at-sign ("@") denotes the current default domain name. - - - - - - - - -Lottor [Page 3] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - -NAMES - - A domain name is a sequence of labels separated by dots. - - Domain names in the zone files can be one of two types, either - absolute or relative. An absolute name is the fully qualified domain - name and is terminated with a period. A relative name does not - terminate with a period, and the current default domain is appended - to it. The default domain is usually the name of the domain that was - specified in the boot file that loads each zone. - - The domain system allows a label to contain any 8-bit character. - Although the domain system has no restrictions, other protocols such - as SMTP do have name restrictions. Because of other protocol - restrictions, only the following characters are recommended for use - in a host name (besides the dot separator): - - "A-Z", "a-z", "0-9", dash and underscore - -TTL's (Time To Live) - - It is important that TTLs are set to appropriate values. The TTL is - the time (in seconds) that a resolver will use the data it got from - your server before it asks your server again. If you set the value - too low, your server will get loaded down with lots of repeat - requests. If you set it too high, then information you change will - not get distributed in a reasonable amount of time. If you leave the - TTL field blank, it will default to what is specified in the SOA - record for the zone. - - Most host information does not change much over long time periods. A - good way to set up your TTLs would be to set them at a high value, - and then lower the value if you know a change will be coming soon. - You might set most TTLs to anywhere between a day (86400) and a week - (604800). Then, if you know some data will be changing in the near - future, set the TTL for that RR down to a lower value (an hour to a - day) until the change takes place, and then put it back up to its - previous value. - - Also, all RRs with the same name, class, and type should have the - same TTL value. - -CLASSES - - The domain system was designed to be protocol independent. The class - field is used to identify the protocol group that each RR is in. - - The class of interest to people using TCP/IP software is the class - - - -Lottor [Page 4] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - "Internet". Its standard designation is "IN". - - A zone file should only contain RRs of the same class. - -TYPES - - There are many defined RR types. For a complete list, see the domain - specification RFCs. Here is a list of current commonly used types. - The data for each type is described in the data section. - - Designation Description - ========================================== - SOA Start Of Authority - NS Name Server - - A Internet Address - CNAME Canonical Name (nickname pointer) - HINFO Host Information - WKS Well Known Services - - MX Mail Exchanger - - PTR Pointer - -SOA (Start Of Authority) - - <name> [<ttl>] [<class>] SOA <origin> <person> ( - <serial> - <refresh> - <retry> - <expire> - <minimum> ) - - The Start Of Authority record designates the start of a zone. The - zone ends at the next SOA record. - - <name> is the name of the zone. - - <origin> is the name of the host on which the master zone file - resides. - - <person> is a mailbox for the person responsible for the zone. It is - formatted like a mailing address but the at-sign that normally - separates the user from the host name is replaced with a dot. - - <serial> is the version number of the zone file. It should be - incremented anytime a change is made to data in the zone. - - - - -Lottor [Page 5] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - <refresh> is how long, in seconds, a secondary name server is to - check with the primary name server to see if an update is needed. A - good value here would be one hour (3600). - - <retry> is how long, in seconds, a secondary name server is to retry - after a failure to check for a refresh. A good value here would be - 10 minutes (600). - - <expire> is the upper limit, in seconds, that a secondary name server - is to use the data before it expires for lack of getting a refresh. - You want this to be rather large, and a nice value is 3600000, about - 42 days. - - <minimum> is the minimum number of seconds to be used for TTL values - in RRs. A minimum of at least a day is a good value here (86400). - - There should only be one SOA record per zone. A sample SOA record - would look something like: - - @ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. ( - 45 ;serial - 3600 ;refresh - 600 ;retry - 3600000 ;expire - 86400 ) ;minimum - - -NS (Name Server) - - <domain> [<ttl>] [<class>] NS <server> - - The NS record lists the name of a machine that provides domain - service for a particular domain. The name associated with the RR is - the domain name and the data portion is the name of a host that - provides the service. If machines SRI-NIC.ARPA and C.ISI.EDU provide - name lookup service for the domain COM then the following entries - would be used: - - COM. NS SRI-NIC.ARPA. - NS C.ISI.EDU. - - Note that the machines providing name service do not have to live in - the named domain. There should be one NS record for each server for - a domain. Also note that the name "COM" defaults for the second NS - record. - - NS records for a domain exist in both the zone that delegates the - domain, and in the domain itself. - - - -Lottor [Page 6] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - -GLUE RECORDS - - If the name server host for a particular domain is itself inside the - domain, then a 'glue' record will be needed. A glue record is an A - (address) RR that specifies the address of the server. Glue records - are only needed in the server delegating the domain, not in the - domain itself. If for example the name server for domain SRI.COM was - KL.SRI.COM, then the NS record would look like this, but you will - also need to have the following A record. - - SRI.COM. NS KL.SRI.COM. - KL.SRI.COM. A 10.1.0.2 - - -A (Address) - - <host> [<ttl>] [<class>] A <address> - - The data for an A record is an internet address in dotted decimal - form. A sample A record might look like: - - SRI-NIC.ARPA. A 10.0.0.51 - - There should be one A record for each address of a host. - -CNAME ( Canonical Name) - - <nickname> [<ttl>] [<class>] CNAME <host> - - The CNAME record is used for nicknames. The name associated with the - RR is the nickname. The data portion is the official name. For - example, a machine named SRI-NIC.ARPA may want to have the nickname - NIC.ARPA. In that case, the following RR would be used: - - NIC.ARPA. CNAME SRI-NIC.ARPA. - - There must not be any other RRs associated with a nickname of the - same class. - - Nicknames are also useful when a host changes it's name. In that - case, it is usually a good idea to have a CNAME pointer so that - people still using the old name will get to the right place. - - - - - - - - - -Lottor [Page 7] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - -HINFO (Host Info) - - <host> [<ttl>] [<class>] HINFO <hardware> <software> - - The HINFO record gives information about a particular host. The data - is two strings separated by whitespace. The first string is a - hardware description and the second is software. The hardware is - usually a manufacturer name followed by a dash and model designation. - The software string is usually the name of the operating system. - - Official HINFO types can be found in the latest Assigned Numbers RFC, - the latest of which is RFC-1010. The Hardware type is called the - Machine name and the Software type is called the System name. - - Some sample HINFO records: - - SRI-NIC.ARPA. HINFO DEC-2060 TOPS20 - UCBARPA.Berkeley.EDU. HINFO VAX-11/780 UNIX - - -WKS (Well Known Services) - - <host> [<ttl>] [<class>] WKS <address> <protocol> <services> - - The WKS record is used to list Well Known Services a host provides. - WKS's are defined to be services on port numbers below 256. The WKS - record lists what services are available at a certain address using a - certain protocol. The common protocols are TCP or UDP. A sample WKS - record for a host offering the same services on all address would - look like: - - Official protocol names can be found in the latest Assigned Numbers - RFC, the latest of which is RFC-1010. - - SRI-NIC.ARPA. WKS 10.0.0.51 TCP TELNET FTP SMTP - WKS 10.0.0.51 UDP TIME - WKS 26.0.0.73 TCP TELNET FTP SMTP - WKS 26.0.0.73 UDP TIME - -MX (Mail Exchanger) (See RFC-974 for more details.) - - <name> [<ttl>] [<class>] MX <preference> <host> - - MX records specify where mail for a domain name should be delivered. - There may be multiple MX records for a particular name. The - preference value specifies the order a mailer should try multiple MX - records when delivering mail. Zero is the highest preference. - Multiple records for the same name may have the same preference. - - - -Lottor [Page 8] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - A host BAR.FOO.COM may want its mail to be delivered to the host - PO.FOO.COM and would then use the MX record: - - BAR.FOO.COM. MX 10 PO.FOO.COM. - - A host BAZ.FOO.COM may want its mail to be delivered to one of three - different machines, in the following order: - - BAZ.FOO.COM. MX 10 PO1.FOO.COM. - MX 20 PO2.FOO.COM. - MX 30 PO3.FOO.COM. - - An entire domain of hosts not connected to the Internet may want - their mail to go through a mail gateway that knows how to deliver - mail to them. If they would like mail addressed to any host in the - domain FOO.COM to go through the mail gateway they might use: - - FOO.COM. MX 10 RELAY.CS.NET. - *.FOO.COM. MX 20 RELAY.CS.NET. - - Note that you can specify a wildcard in the MX record to match on - anything in FOO.COM, but that it won't match a plain FOO.COM. - -IN-ADDR.ARPA - - The structure of names in the domain system is set up in a - hierarchical way such that the address of a name can be found by - tracing down the domain tree contacting a server for each label of - the name. Because of this 'indexing' based on name, there is no easy - way to translate a host address back into its host name. - - In order to do the reverse translation easily, a domain was created - that uses hosts' addresses as part of a name that then points to the - data for that host. In this way, there is now an 'index' to hosts' - RRs based on their address. This address mapping domain is called - IN-ADDR.ARPA. Within that domain are subdomains for each network, - based on network number. Also, for consistency and natural - groupings, the 4 octets of a host number are reversed. - - For example, the ARPANET is net 10. That means there is a domain - called 10.IN-ADDR.ARPA. Within this domain there is a PTR RR at - 51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA - (who's address is 10.0.0.51). Since the NIC is also on the MILNET - (Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN- - ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA. The format - of these special pointers is defined below along with the examples - for the NIC. - - - - -Lottor [Page 9] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - -PTR - - <special-name> [<ttl>] [<class>] PTR <name> - - The PTR record is used to let special names point to some other - location in the domain tree. They are mainly used in the IN- - ADDR.ARPA records for translation of addresses to names. PTR's - should use official names and not aliases. - - For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73 - would have the following records in the respective zone files for net - 10 and net 26: - - 51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. - 73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. - -GATEWAY PTR's - - The IN-ADDR tree is also used to locate gateways on a particular - network. Gateways have the same kind of PTR RRs as hosts (as above) - but in addition they have other PTRs used to locate them by network - number alone. These records have only 1, 2, or 3 octets as part of - the name depending on whether they are class A, B, or C networks, - respectively. - - Lets take the SRI-CSL gateway for example. It connects 3 different - networks, one class A, one class B and one class C. It will have the - standard RR's for a host in the CSL.SRI.COM zone: - - GW.CSL.SRI.COM. A 10.2.0.2 - A 128.18.1.1 - A 192.12.33.2 - - Also, in 3 different zones (one for each network), it will have one - of the following number to name translation pointers: - - 2.0.2.10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. - 1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. - 1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. - - In addition, in each of the same 3 zones will be one of the following - gateway location pointers: - - 10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. - 18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. - 33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. - - - - - -Lottor [Page 10] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - -INSTRUCTIONS - - Adding a subdomain. - - To add a new subdomain to your domain: - - Setup the other domain server and/or the new zone file. - - Add an NS record for each server of the new domain to the zone - file of the parent domain. - - Add any necessary glue RRs. - - Adding a host. - - To add a new host to your zone files: - - Edit the appropriate zone file for the domain the host is in. - - Add an entry for each address of the host. - - Optionally add CNAME, HINFO, WKS, and MX records. - - Add the reverse IN-ADDR entry for each host address in the - appropriate zone files for each network the host in on. - - Deleting a host. - - To delete a host from the zone files: - - Remove all the hosts' resource records from the zone file of - the domain the host is in. - - Remove all the hosts' PTR records from the IN-ADDR zone files - for each network the host was on. - - Adding gateways. - - Follow instructions for adding a host. - - Add the gateway location PTR records for each network the - gateway is on. - - Deleting gateways. - - Follow instructions for deleting a host. - - Also delete the gateway location PTR records for each network - - - -Lottor [Page 11] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - the gateway was on. - -COMPLAINTS - - These are the suggested steps you should take if you are having - problems that you believe are caused by someone else's name server: - - - 1. Complain privately to the responsible person for the domain. You - can find their mailing address in the SOA record for the domain. - - 2. Complain publicly to the responsible person for the domain. - - 3. Ask the NIC for the administrative person responsible for the - domain. Complain. You can also find domain contacts on the NIC in - the file NETINFO:DOMAIN-CONTACTS.TXT - - 4. Complain to the parent domain authorities. - - 5. Ask the parent authorities to excommunicate the domain. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lottor [Page 12] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - -EXAMPLE DOMAIN SERVER DATABASE FILES - - The following examples show how zone files are set up for a typical - organization. SRI will be used as the example organization. SRI has - decided to divided their domain SRI.COM into a few subdomains, one - for each group that wants one. The subdomains are CSL and ISTC. - - Note the following interesting items: - - There are both hosts and domains under SRI.COM. - - CSL.SRI.COM is both a domain name and a host name. - - All the domains are serviced by the same pair of domain servers. - - All hosts at SRI are on net 128.18 except hosts in the CSL domain - which are on net 192.12.33. Note that a domain does not have to - correspond to a physical network. - - The examples do not necessarily correspond to actual data in use - by the SRI domain. - - SRI Domain Organization - - +-------+ - | COM | - +-------+ - | - +-------+ - | SRI | - +-------+ - | - +----------++-----------+ - | | | - +-------+ +------+ +-------+ - | CSL | | ISTC | | Hosts | - +-------+ +------+ +-------+ - | | - +-------+ +-------+ - | Hosts | | Hosts | - +-------+ +-------+ - - - - - - - - - - -Lottor [Page 13] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - [File "CONFIG.CMD". Since bootstrap files are not standardized, this - file is presented using a pseudo configuration file syntax.] - - load root server list from file ROOT.SERVERS - load zone SRI.COM. from file SRI.ZONE - load zone CSL.SRI.COM. from file CSL.ZONE - load zone ISTC.SRI.COM. from file ISTC.ZONE - load zone 18.128.IN-ADDR.ARPA. from file SRINET.ZONE - load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.ZONE - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lottor [Page 14] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - [File "ROOT.SERVERS". Again, the format of this file is not - standardized.] - - ;list of possible root servers - SRI-NIC.ARPA 10.0.0.51 26.0.0.73 - C.ISI.EDU 10.0.0.52 - BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2 - A.ISI.EDU 26.3.0.103 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lottor [Page 15] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - [File "SRI.ZONE"] - - SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. ( - 870407 ;serial - 1800 ;refresh every 30 minutes - 600 ;retry every 10 minutes - 604800 ;expire after a week - 86400 ;default of an hour - ) - - SRI.COM. NS KL.SRI.COM. - NS STRIPE.SRI.COM. - MX 10 KL.SRI.COM. - - ;SRI.COM hosts - - KL A 10.1.0.2 - A 128.18.10.6 - MX 10 KL.SRI.COM. - - STRIPE A 10.4.0.2 - STRIPE A 128.18.10.4 - MX 10 STRIPE.SRI.COM. - - NIC CNAME SRI-NIC.ARPA. - - Blackjack A 128.18.2.1 - HINFO VAX-11/780 UNIX - WKS 128.18.2.1 TCP TELNET FTP - - CSL A 192.12.33.2 - HINFO FOONLY-F4 TOPS20 - WKS 192.12.33.2 TCP TELNET FTP SMTP FINGER - MX 10 CSL.SRI.COM. - - - - - - - - - - - - - - - - - -Lottor [Page 16] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - [File "CSL.ZONE"] - - CSL.SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. ( - 870330 ;serial - 1800 ;refresh every 30 minutes - 600 ;retry every 10 minutes - 604800 ;expire after a week - 86400 ;default of a day - ) - - CSL.SRI.COM. NS KL.SRI.COM. - NS STRIPE.SRI.COM. - A 192.12.33.2 - - ;CSL.SRI.COM hosts - - A CNAME CSL.SRI.COM. - B A 192.12.33.3 - HINFO FOONLY-F4 TOPS20 - WKS 192.12.33.3 TCP TELNET FTP SMTP - GW A 10.2.0.2 - A 192.12.33.1 - A 128.18.1.1 - HINFO PDP-11/23 MOS - SMELLY A 192.12.33.4 - HINFO IMAGEN IMAGEN - SQUIRREL A 192.12.33.5 - HINFO XEROX-1100 INTERLISP - VENUS A 192.12.33.7 - HINFO SYMBOLICS-3600 LISPM - HELIUM A 192.12.33.30 - HINFO SUN-3/160 UNIX - ARGON A 192.12.33.31 - HINFO SUN-3/75 UNIX - RADON A 192.12.33.32 - HINFO SUN-3/75 UNIX - - - - - - - - - - - - - - - -Lottor [Page 17] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - [File "ISTC.ZONE"] - - ISTC.SRI.COM. IN SOA KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. ( - 870406 ;serial - 1800 ;refresh every 30 minutes - 600 ;retry every 10 minutes - 604800 ;expire after a week - 86400 ;default of a day - ) - - ISTC.SRI.COM. NS KL.SRI.COM. - NS STRIPE.SRI.COM. - MX 10 SPAM.ISTC.SRI.COM. - - ; ISTC hosts - - joyce A 128.18.4.2 - HINFO VAX-11/750 UNIX - bozo A 128.18.0.6 - HINFO SUN UNIX - sundae A 128.18.0.11 - HINFO SUN UNIX - tsca A 128.18.0.201 - A 10.3.0.2 - HINFO VAX-11/750 UNIX - MX 10 TSCA.ISTC.SRI.COM. - tsc CNAME tsca - prmh A 128.18.0.203 - A 10.2.0.51 - HINFO PDP-11/44 UNIX - spam A 128.18.4.3 - A 10.2.0.107 - HINFO VAX-11/780 UNIX - MX 10 SPAM.ISTC.SRI.COM. - - - - - - - - - - - - - - - - - -Lottor [Page 18] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - [File "SRINET.ZONE"] - - 18.128.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. ( - 870406 ;serial - 1800 ;refresh every 30 minutes - 600 ;retry every 10 minutes - 604800 ;expire after a week - 86400 ;default of a day - ) - - 18.128.IN-ADDR.ARPA. NS KL.SRI.COM. - NS STRIPE.SRI.COM. - PTR GW.CSL.SRI.COM. - - ; SRINET [128.18.0.0] Address Translations - - ; SRI.COM Hosts - 1.2.18.128.IN-ADDR.ARPA. PTR Blackjack.SRI.COM. - - ; ISTC.SRI.COM Hosts - 2.4.18.128.IN-ADDR.ARPA. PTR joyce.ISTC.SRI.COM. - 6.0.18.128.IN-ADDR.ARPA. PTR bozo.ISTC.SRI.COM. - 11.0.18.128.IN-ADDR.ARPA. PTR sundae.ISTC.SRI.COM. - 201.0.18.128.IN-ADDR.ARPA. PTR tsca.ISTC.SRI.COM. - 203.0.18.128.IN-ADDR.ARPA. PTR prmh.ISTC.SRI.COM. - 3.4.18.128.IN-ADDR.ARPA. PTR spam.ISTC.SRI.COM. - - ; CSL.SRI.COM Hosts - 1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. - - - - - - - - - - - - - - - - - - - - - - -Lottor [Page 19] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - - [File "SRI-CSL-NET.ZONE"] - - 33.12.192.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. ( - 870404 ;serial - 1800 ;refresh every 30 minutes - 600 ;retry every 10 minutes - 604800 ;expire after a week - 86400 ;default of a day - ) - - 33.12.192.IN-ADDR.ARPA. NS KL.SRI.COM. - NS STRIPE.SRI.COM. - PTR GW.CSL.SRI.COM. - - ; SRI-CSL-NET [192.12.33.0] Address Translations - - ; SRI.COM Hosts - 2.33.12.192.IN-ADDR.ARPA. PTR CSL.SRI.COM. - - ; CSL.SRI.COM Hosts - 1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM. - 3.33.12.192.IN-ADDR.ARPA. PTR B.CSL.SRI.COM. - 4.33.12.192.IN-ADDR.ARPA. PTR SMELLY.CSL.SRI.COM. - 5.33.12.192.IN-ADDR.ARPA. PTR SQUIRREL.CSL.SRI.COM. - 7.33.12.192.IN-ADDR.ARPA. PTR VENUS.CSL.SRI.COM. - 30.33.12.192.IN-ADDR.ARPA. PTR HELIUM.CSL.SRI.COM. - 31.33.12.192.IN-ADDR.ARPA. PTR ARGON.CSL.SRI.COM. - 32.33.12.192.IN-ADDR.ARPA. PTR RADON.CSL.SRI.COM. - - - - - - - - - - - - - - - - - - - - - - - -Lottor [Page 20] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - -APPENDIX - - BIND (Berkeley Internet Name Domain server) distributed with 4.3 BSD - UNIX - - This section describes two BIND implementation specific files; the - boot file and the cache file. BIND has other options, files, and - specifications that are not described here. See the Name Server - Operations Guide for BIND for details. - - The boot file for BIND is usually called "named.boot". This - corresponds to file "CONFIG.CMD" in the example section. - - -------------------------------------------------------- - cache . named.ca - primary SRI.COM SRI.ZONE - primary CSL.SRI.COM CSL.ZONE - primary ISTC.SRI.COM ISTC.ZONE - primary 18.128.IN-ADDR.ARPA SRINET.ZONE - primary 33.12.192.IN-ADDR.ARPA SRI-CSL-NET.ZONE - -------------------------------------------------------- - - The cache file for BIND is usually called "named.ca". This - corresponds to file "ROOT.SERVERS" in the example section. - - ------------------------------------------------- - ;list of possible root servers - . 1 IN NS SRI-NIC.ARPA. - NS C.ISI.EDU. - NS BRL-AOS.ARPA. - NS C.ISI.EDU. - ;and their addresses - SRI-NIC.ARPA. A 10.0.0.51 - A 26.0.0.73 - C.ISI.EDU. A 10.0.0.52 - BRL-AOS.ARPA. A 192.5.25.82 - A 192.5.22.82 - A 128.20.1.2 - A.ISI.EDU. A 26.3.0.103 - ------------------------------------------------- - - - - - - - - - - - -Lottor [Page 21] - -RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 - - -REFERENCES - - [1] Dunlap, K., "Name Server Operations Guide for BIND", CSRG, - Department of Electrical Engineering and Computer Sciences, - University of California, Berkeley, California. - - [2] Partridge, C., "Mail Routing and the Domain System", RFC-974, - CSNET CIC BBN Laboratories, January 1986. - - [3] Mockapetris, P., "Domains Names - Concepts and Facilities", - RFC-1034, USC/Information Sciences Institute, November 1987. - - [4] Mockapetris, P., "Domain Names - Implementations Specification", - RFC-1035, USC/Information Sciences Institute, November 1987. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lottor [Page 22] - diff --git a/contrib/bind9/doc/rfc/rfc1034.txt b/contrib/bind9/doc/rfc/rfc1034.txt deleted file mode 100644 index 55cdb21fe652..000000000000 --- a/contrib/bind9/doc/rfc/rfc1034.txt +++ /dev/null @@ -1,3077 +0,0 @@ -Network Working Group P. Mockapetris -Request for Comments: 1034 ISI -Obsoletes: RFCs 882, 883, 973 November 1987 - - - DOMAIN NAMES - CONCEPTS AND FACILITIES - - - -1. STATUS OF THIS MEMO - -This RFC is an introduction to the Domain Name System (DNS), and omits -many details which can be found in a companion RFC, "Domain Names - -Implementation and Specification" [RFC-1035]. That RFC assumes that the -reader is familiar with the concepts discussed in this memo. - -A subset of DNS functions and data types constitute an official -protocol. The official protocol includes standard queries and their -responses and most of the Internet class data formats (e.g., host -addresses). - -However, the domain system is intentionally extensible. Researchers are -continuously proposing, implementing and experimenting with new data -types, query types, classes, functions, etc. Thus while the components -of the official protocol are expected to stay essentially unchanged and -operate as a production service, experimental behavior should always be -expected in extensions beyond the official protocol. Experimental or -obsolete features are clearly marked in these RFCs, and such information -should be used with caution. - -The reader is especially cautioned not to depend on the values which -appear in examples to be current or complete, since their purpose is -primarily pedagogical. Distribution of this memo is unlimited. - -2. INTRODUCTION - -This RFC introduces domain style names, their use for Internet mail and -host address support, and the protocols and servers used to implement -domain name facilities. - -2.1. The history of domain names - -The impetus for the development of the domain system was growth in the -Internet: - - - Host name to address mappings were maintained by the Network - Information Center (NIC) in a single file (HOSTS.TXT) which - was FTPed by all hosts [RFC-952, RFC-953]. The total network - - - -Mockapetris [Page 1] - -RFC 1034 Domain Concepts and Facilities November 1987 - - - bandwidth consumed in distributing a new version by this - scheme is proportional to the square of the number of hosts in - the network, and even when multiple levels of FTP are used, - the outgoing FTP load on the NIC host is considerable. - Explosive growth in the number of hosts didn't bode well for - the future. - - - The network population was also changing in character. The - timeshared hosts that made up the original ARPANET were being - replaced with local networks of workstations. Local - organizations were administering their own names and - addresses, but had to wait for the NIC to change HOSTS.TXT to - make changes visible to the Internet at large. Organizations - also wanted some local structure on the name space. - - - The applications on the Internet were getting more - sophisticated and creating a need for general purpose name - service. - - -The result was several ideas about name spaces and their management -[IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a -common thread was the idea of a hierarchical name space, with the -hierarchy roughly corresponding to organizational structure, and names -using "." as the character to mark the boundary between hierarchy -levels. A design using a distributed database and generalized resources -was described in [RFC-882, RFC-883]. Based on experience with several -implementations, the system evolved into the scheme described in this -memo. - -The terms "domain" or "domain name" are used in many contexts beyond the -DNS described here. Very often, the term domain name is used to refer -to a name with structure indicated by dots, but no relation to the DNS. -This is particularly true in mail addressing [Quarterman 86]. - -2.2. DNS design goals - -The design goals of the DNS influence its structure. They are: - - - The primary goal is a consistent name space which will be used - for referring to resources. In order to avoid the problems - caused by ad hoc encodings, names should not be required to - contain network identifiers, addresses, routes, or similar - information as part of the name. - - - The sheer size of the database and frequency of updates - suggest that it must be maintained in a distributed manner, - with local caching to improve performance. Approaches that - - - -Mockapetris [Page 2] - -RFC 1034 Domain Concepts and Facilities November 1987 - - - attempt to collect a consistent copy of the entire database - will become more and more expensive and difficult, and hence - should be avoided. The same principle holds for the structure - of the name space, and in particular mechanisms for creating - and deleting names; these should also be distributed. - - - Where there tradeoffs between the cost of acquiring data, the - speed of updates, and the accuracy of caches, the source of - the data should control the tradeoff. - - - The costs of implementing such a facility dictate that it be - generally useful, and not restricted to a single application. - We should be able to use names to retrieve host addresses, - mailbox data, and other as yet undetermined information. All - data associated with a name is tagged with a type, and queries - can be limited to a single type. - - - Because we want the name space to be useful in dissimilar - networks and applications, we provide the ability to use the - same name space with different protocol families or - management. For example, host address formats differ between - protocols, though all protocols have the notion of address. - The DNS tags all data with a class as well as the type, so - that we can allow parallel use of different formats for data - of type address. - - - We want name server transactions to be independent of the - communications system that carries them. Some systems may - wish to use datagrams for queries and responses, and only - establish virtual circuits for transactions that need the - reliability (e.g., database updates, long transactions); other - systems will use virtual circuits exclusively. - - - The system should be useful across a wide spectrum of host - capabilities. Both personal computers and large timeshared - hosts should be able to use the system, though perhaps in - different ways. - -2.3. Assumptions about usage - -The organization of the domain system derives from some assumptions -about the needs and usage patterns of its user community and is designed -to avoid many of the the complicated problems found in general purpose -database systems. - -The assumptions are: - - - The size of the total database will initially be proportional - - - -Mockapetris [Page 3] - -RFC 1034 Domain Concepts and Facilities November 1987 - - - to the number of hosts using the system, but will eventually - grow to be proportional to the number of users on those hosts - as mailboxes and other information are added to the domain - system. - - - Most of the data in the system will change very slowly (e.g., - mailbox bindings, host addresses), but that the system should - be able to deal with subsets that change more rapidly (on the - order of seconds or minutes). - - - The administrative boundaries used to distribute - responsibility for the database will usually correspond to - organizations that have one or more hosts. Each organization - that has responsibility for a particular set of domains will - provide redundant name servers, either on the organization's - own hosts or other hosts that the organization arranges to - use. - - - Clients of the domain system should be able to identify - trusted name servers they prefer to use before accepting - referrals to name servers outside of this "trusted" set. - - - Access to information is more critical than instantaneous - updates or guarantees of consistency. Hence the update - process allows updates to percolate out through the users of - the domain system rather than guaranteeing that all copies are - simultaneously updated. When updates are unavailable due to - network or host failure, the usual course is to believe old - information while continuing efforts to update it. The - general model is that copies are distributed with timeouts for - refreshing. The distributor sets the timeout value and the - recipient of the distribution is responsible for performing - the refresh. In special situations, very short intervals can - be specified, or the owner can prohibit copies. - - - In any system that has a distributed database, a particular - name server may be presented with a query that can only be - answered by some other server. The two general approaches to - dealing with this problem are "recursive", in which the first - server pursues the query for the client at another server, and - "iterative", in which the server refers the client to another - server and lets the client pursue the query. Both approaches - have advantages and disadvantages, but the iterative approach - is preferred for the datagram style of access. The domain - system requires implementation of the iterative approach, but - allows the recursive approach as an option. - - - - - -Mockapetris [Page 4] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -The domain system assumes that all data originates in master files -scattered through the hosts that use the domain system. These master -files are updated by local system administrators. Master files are text -files that are read by a local name server, and hence become available -through the name servers to users of the domain system. The user -programs access name servers through standard programs called resolvers. - -The standard format of master files allows them to be exchanged between -hosts (via FTP, mail, or some other mechanism); this facility is useful -when an organization wants a domain, but doesn't want to support a name -server. The organization can maintain the master files locally using a -text editor, transfer them to a foreign host which runs a name server, -and then arrange with the system administrator of the name server to get -the files loaded. - -Each host's name servers and resolvers are configured by a local system -administrator [RFC-1033]. For a name server, this configuration data -includes the identity of local master files and instructions on which -non-local master files are to be loaded from foreign servers. The name -server uses the master files or copies to load its zones. For -resolvers, the configuration data identifies the name servers which -should be the primary sources of information. - -The domain system defines procedures for accessing the data and for -referrals to other name servers. The domain system also defines -procedures for caching retrieved data and for periodic refreshing of -data defined by the system administrator. - -The system administrators provide: - - - The definition of zone boundaries. - - - Master files of data. - - - Updates to master files. - - - Statements of the refresh policies desired. - -The domain system provides: - - - Standard formats for resource data. - - - Standard methods for querying the database. - - - Standard methods for name servers to refresh local data from - foreign name servers. - - - - - -Mockapetris [Page 5] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -2.4. Elements of the DNS - -The DNS has three major components: - - - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are - specifications for a tree structured name space and data - associated with the names. Conceptually, each node and leaf - of the domain name space tree names a set of information, and - query operations are attempts to extract specific types of - information from a particular set. A query names the domain - name of interest and describes the type of resource - information that is desired. For example, the Internet - uses some of its domain names to identify hosts; queries for - address resources return Internet host addresses. - - - NAME SERVERS are server programs which hold information about - the domain tree's structure and set information. A name - server may cache structure or set information about any part - of the domain tree, but in general a particular name server - has complete information about a subset of the domain space, - and pointers to other name servers that can be used to lead to - information from any part of the domain tree. Name servers - know the parts of the domain tree for which they have complete - information; a name server is said to be an AUTHORITY for - these parts of the name space. Authoritative information is - organized into units called ZONEs, and these zones can be - automatically distributed to the name servers which provide - redundant service for the data in a zone. - - - RESOLVERS are programs that extract information from name - servers in response to client requests. Resolvers must be - able to access at least one name server and use that name - server's information to answer a query directly, or pursue the - query using referrals to other name servers. A resolver will - typically be a system routine that is directly accessible to - user programs; hence no protocol is necessary between the - resolver and the user program. - -These three components roughly correspond to the three layers or views -of the domain system: - - - From the user's point of view, the domain system is accessed - through a simple procedure or OS call to a local resolver. - The domain space consists of a single tree and the user can - request information from any section of the tree. - - - From the resolver's point of view, the domain system is - composed of an unknown number of name servers. Each name - - - -Mockapetris [Page 6] - -RFC 1034 Domain Concepts and Facilities November 1987 - - - server has one or more pieces of the whole domain tree's data, - but the resolver views each of these databases as essentially - static. - - - From a name server's point of view, the domain system consists - of separate sets of local information called zones. The name - server has local copies of some of the zones. The name server - must periodically refresh its zones from master copies in - local files or foreign name servers. The name server must - concurrently process queries that arrive from resolvers. - -In the interests of performance, implementations may couple these -functions. For example, a resolver on the same machine as a name server -might share a database consisting of the the zones managed by the name -server and the cache managed by the resolver. - -3. DOMAIN NAME SPACE and RESOURCE RECORDS - -3.1. Name space specifications and terminology - -The domain name space is a tree structure. Each node and leaf on the -tree corresponds to a resource set (which may be empty). The domain -system makes no distinctions between the uses of the interior nodes and -leaves, and this memo uses the term "node" to refer to both. - -Each node has a label, which is zero to 63 octets in length. Brother -nodes may not have the same label, although the same label can be used -for nodes which are not brothers. One label is reserved, and that is -the null (i.e., zero length) label used for the root. - -The domain name of a node is the list of the labels on the path from the -node to the root of the tree. By convention, the labels that compose a -domain name are printed or read left to right, from the most specific -(lowest, farthest from the root) to the least specific (highest, closest -to the root). - -Internally, programs that manipulate domain names should represent them -as sequences of labels, where each label is a length octet followed by -an octet string. Because all domain names end at the root, which has a -null string for a label, these internal representations can use a length -byte of zero to terminate a domain name. - -By convention, domain names can be stored with arbitrary case, but -domain name comparisons for all present domain functions are done in a -case-insensitive manner, assuming an ASCII character set, and a high -order zero bit. This means that you are free to create a node with -label "A" or a node with label "a", but not both as brothers; you could -refer to either using "a" or "A". When you receive a domain name or - - - -Mockapetris [Page 7] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -label, you should preserve its case. The rationale for this choice is -that we may someday need to add full binary domain names for new -services; existing services would not be changed. - -When a user needs to type a domain name, the length of each label is -omitted and the labels are separated by dots ("."). Since a complete -domain name ends with the root label, this leads to a printed form which -ends in a dot. We use this property to distinguish between: - - - a character string which represents a complete domain name - (often called "absolute"). For example, "poneria.ISI.EDU." - - - a character string that represents the starting labels of a - domain name which is incomplete, and should be completed by - local software using knowledge of the local domain (often - called "relative"). For example, "poneria" used in the - ISI.EDU domain. - -Relative names are either taken relative to a well known origin, or to a -list of domains used as a search list. Relative names appear mostly at -the user interface, where their interpretation varies from -implementation to implementation, and in master files, where they are -relative to a single origin domain name. The most common interpretation -uses the root "." as either the single origin or as one of the members -of the search list, so a multi-label relative name is often one where -the trailing dot has been omitted to save typing. - -To simplify implementations, the total number of octets that represent a -domain name (i.e., the sum of all label octets and label lengths) is -limited to 255. - -A domain is identified by a domain name, and consists of that part of -the domain name space that is at or below the domain name which -specifies the domain. A domain is a subdomain of another domain if it -is contained within that domain. This relationship can be tested by -seeing if the subdomain's name ends with the containing domain's name. -For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ". - -3.2. Administrative guidelines on use - -As a matter of policy, the DNS technical specifications do not mandate a -particular tree structure or rules for selecting labels; its goal is to -be as general as possible, so that it can be used to build arbitrary -applications. In particular, the system was designed so that the name -space did not have to be organized along the lines of network -boundaries, name servers, etc. The rationale for this is not that the -name space should have no implied semantics, but rather that the choice -of implied semantics should be left open to be used for the problem at - - - -Mockapetris [Page 8] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -hand, and that different parts of the tree can have different implied -semantics. For example, the IN-ADDR.ARPA domain is organized and -distributed by network and host address because its role is to translate -from network or host numbers to names; NetBIOS domains [RFC-1001, RFC- -1002] are flat because that is appropriate for that application. - -However, there are some guidelines that apply to the "normal" parts of -the name space used for hosts, mailboxes, etc., that will make the name -space more uniform, provide for growth, and minimize problems as -software is converted from the older host table. The political -decisions about the top levels of the tree originated in RFC-920. -Current policy for the top levels is discussed in [RFC-1032]. MILNET -conversion issues are covered in [RFC-1031]. - -Lower domains which will eventually be broken into multiple zones should -provide branching at the top of the domain so that the eventual -decomposition can be done without renaming. Node labels which use -special characters, leading digits, etc., are likely to break older -software which depends on more restrictive choices. - -3.3. Technical guidelines on use - -Before the DNS can be used to hold naming information for some kind of -object, two needs must be met: - - - A convention for mapping between object names and domain - names. This describes how information about an object is - accessed. - - - RR types and data formats for describing the object. - -These rules can be quite simple or fairly complex. Very often, the -designer must take into account existing formats and plan for upward -compatibility for existing usage. Multiple mappings or levels of -mapping may be required. - -For hosts, the mapping depends on the existing syntax for host names -which is a subset of the usual text representation for domain names, -together with RR formats for describing host addresses, etc. Because we -need a reliable inverse mapping from address to host name, a special -mapping for addresses into the IN-ADDR.ARPA domain is also defined. - -For mailboxes, the mapping is slightly more complex. The usual mail -address <local-part>@<mail-domain> is mapped into a domain name by -converting <local-part> into a single label (regardles of dots it -contains), converting <mail-domain> into a domain name using the usual -text format for domain names (dots denote label breaks), and -concatenating the two to form a single domain name. Thus the mailbox - - - -Mockapetris [Page 9] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by -HOSTMASTER.SRI-NIC.ARPA. An appreciation for the reasons behind this -design also must take into account the scheme for mail exchanges [RFC- -974]. - -The typical user is not concerned with defining these rules, but should -understand that they usually are the result of numerous compromises -between desires for upward compatibility with old usage, interactions -between different object definitions, and the inevitable urge to add new -features when defining the rules. The way the DNS is used to support -some object is often more crucial than the restrictions inherent in the -DNS. - -3.4. Example name space - -The following figure shows a part of the current domain name space, and -is used in many examples in this RFC. Note that the tree is a very -small subset of the actual name space. - - | - | - +---------------------+------------------+ - | | | - MIL EDU ARPA - | | | - | | | - +-----+-----+ | +------+-----+-----+ - | | | | | | | - BRL NOSC DARPA | IN-ADDR SRI-NIC ACC - | - +--------+------------------+---------------+--------+ - | | | | | - UCI MIT | UDEL YALE - | ISI - | | - +---+---+ | - | | | - LCS ACHILLES +--+-----+-----+--------+ - | | | | | | - XX A C VAXA VENERA Mockapetris - -In this example, the root domain has three immediate subdomains: MIL, -EDU, and ARPA. The LCS.MIT.EDU domain has one immediate subdomain named -XX.LCS.MIT.EDU. All of the leaves are also domains. - -3.5. Preferred name syntax - -The DNS specifications attempt to be as general as possible in the rules - - - -Mockapetris [Page 10] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -for constructing domain names. The idea is that the name of any -existing object can be expressed as a domain name with minimal changes. -However, when assigning a domain name for an object, the prudent user -will select a name which satisfies both the rules of the domain system -and any existing rules for the object, whether these rules are published -or implied by existing programs. - -For example, when naming a mail domain, the user should satisfy both the -rules of this memo and those in RFC-822. When creating a new host name, -the old rules for HOSTS.TXT should be followed. This avoids problems -when old software is converted to use domain names. - -The following syntax will result in fewer problems with many -applications that use domain names (e.g., mail, TELNET). - -<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 Internet: - -A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA - -3.6. Resource Records - -A domain name identifies a node. Each node has a set of resource - - - -Mockapetris [Page 11] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -information, which may be empty. The set of resource information -associated with a particular name is composed of separate resource -records (RRs). The order of RRs in a set is not significant, and need -not be preserved by name servers, resolvers, or other parts of the DNS. - -When we talk about a specific RR, we assume it has the following: - -owner which is the domain name where the RR is found. - -type which is an encoded 16 bit value that specifies the type - of the resource in this resource record. Types refer to - abstract resources. - - This memo uses the following types: - - A a host address - - CNAME identifies the canonical name of an - alias - - HINFO identifies the CPU and OS used by a host - - MX identifies a mail exchange for the - domain. See [RFC-974 for details. - - NS - the authoritative name server for the domain - - PTR - a pointer to another part of the domain name space - - SOA - identifies the start of a zone of authority] - -class which is an encoded 16 bit value which identifies a - protocol family or instance of a protocol. - - This memo uses the following classes: - - IN the Internet system - - CH the Chaos system - -TTL which is the time to live of the RR. This field is a 32 - bit integer in units of seconds, an is primarily used by - resolvers when they cache RRs. The TTL describes how - long a RR can be cached before it should be discarded. - - - - -Mockapetris [Page 12] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -RDATA which is the type and sometimes class dependent data - which describes the resource: - - A For the IN class, a 32 bit IP address - - For the CH class, a domain name followed - by a 16 bit octal Chaos address. - - CNAME a domain name. - - MX a 16 bit preference value (lower is - better) followed by a host name willing - to act as a mail exchange for the owner - domain. - - NS a host name. - - PTR a domain name. - - SOA several fields. - -The owner name is often implicit, rather than forming an integral part -of the RR. For example, many name servers internally form tree or hash -structures for the name space, and chain RRs off nodes. The remaining -RR parts are the fixed header (type, class, TTL) which is consistent for -all RRs, and a variable part (RDATA) that fits the needs of the resource -being described. - -The meaning of the TTL field is a time limit on how long an RR can be -kept in a cache. This limit does not apply to authoritative data in -zones; it is also timed out, but by the refreshing policies for the -zone. The TTL is assigned by the administrator for the zone where the -data originates. While short TTLs can be used to minimize caching, and -a zero TTL prohibits caching, the realities of Internet performance -suggest that these times should be on the order of days for the typical -host. If a change can be anticipated, the TTL can be reduced prior to -the change to minimize inconsistency during the change, and then -increased back to its former value following the change. - -The data in the RDATA section of RRs is carried as a combination of -binary strings and domain names. The domain names are frequently used -as "pointers" to other data in the DNS. - -3.6.1. Textual expression of RRs - -RRs are represented in binary form in the packets of the DNS protocol, -and are usually represented in highly encoded form when stored in a name -server or resolver. In this memo, we adopt a style similar to that used - - - -Mockapetris [Page 13] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -in master files in order to show the contents of RRs. In this format, -most RRs are shown on a single line, although continuation lines are -possible using parentheses. - -The start of the line gives the owner of the RR. If a line begins with -a blank, then the owner is assumed to be the same as that of the -previous RR. Blank lines are often included for readability. - -Following the owner, we list the TTL, type, and class of the RR. Class -and type use the mnemonics defined above, and TTL is an integer before -the type field. In order to avoid ambiguity in parsing, type and class -mnemonics are disjoint, TTLs are integers, and the type mnemonic is -always last. The IN class and TTL values are often omitted from examples -in the interests of clarity. - -The resource data or RDATA section of the RR are given using knowledge -of the typical representation for the data. - -For example, we might show the RRs carried in a message as: - - ISI.EDU. MX 10 VENERA.ISI.EDU. - MX 10 VAXA.ISI.EDU. - VENERA.ISI.EDU. A 128.9.0.32 - A 10.1.0.52 - VAXA.ISI.EDU. A 10.2.0.27 - A 128.9.0.33 - -The MX RRs have an RDATA section which consists of a 16 bit number -followed by a domain name. The address RRs use a standard IP address -format to contain a 32 bit internet address. - -This example shows six RRs, with two RRs at each of three domain names. - -Similarly we might see: - - XX.LCS.MIT.EDU. IN A 10.0.0.44 - CH A MIT.EDU. 2420 - -This example shows two addresses for XX.LCS.MIT.EDU, each of a different -class. - -3.6.2. Aliases and canonical names - -In existing systems, hosts and other resources often have several names -that identify the same resource. For example, the names C.ISI.EDU and -USC-ISIC.ARPA 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@C.ISI.EDU, Mockapetris@B.ISI.EDU, - - - -Mockapetris [Page 14] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -and PVM@ISI.EDU 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 or primary name and all others are aliases. - -The domain system provides such a feature using the canonical name -(CNAME) RR. A CNAME RR identifies its owner name as an alias, and -specifies the corresponding canonical name in the RDATA section of the -RR. If a CNAME RR is present at a node, no other data should be -present; this ensures that the data for a canonical name and its aliases -cannot be different. This rule also insures that a cached CNAME can be -used without checking with an authoritative server for other RR types. - -CNAME RRs cause special action in DNS software. When a name server -fails to find a desired RR in the resource set associated with the -domain name, it checks to see if the resource set consists of a CNAME -record with a matching class. If so, the name server includes the CNAME -record in the response and restarts the query at the domain name -specified in the data field of the CNAME record. The one exception to -this rule is that queries which match the CNAME type are not restarted. - -For example, suppose a name server was processing a query with for USC- -ISIC.ARPA, asking for type A information, and had the following resource -records: - - USC-ISIC.ARPA IN CNAME C.ISI.EDU - - C.ISI.EDU IN A 10.0.0.52 - -Both of these RRs would be returned in the response to the type A query, -while a type CNAME or * query should return just the CNAME. - -Domain names in RRs which point at another name should always point at -the primary name and not the alias. This avoids extra indirections in -accessing information. For example, the address to name RR for the -above host should be: - - 52.0.0.10.IN-ADDR.ARPA IN PTR C.ISI.EDU - -rather than pointing at USC-ISIC.ARPA. Of course, by the robustness -principle, domain software should not fail when presented with CNAME -chains or loops; CNAME chains should be followed and CNAME loops -signalled as an error. - -3.7. Queries - -Queries are messages which may be sent to a name server to provoke a - - - -Mockapetris [Page 15] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -response. In the Internet, queries are carried in UDP datagrams or over -TCP connections. The response by the name server either answers the -question posed in the query, refers the requester to another set of name -servers, or signals some error condition. - -In general, the user does not generate queries directly, but instead -makes a request to a resolver which in turn sends one or more queries to -name servers and deals with the error conditions and referrals that may -result. Of course, the possible questions which can be asked in a query -does shape the kind of service a resolver can provide. - -DNS queries and responses are carried in a standard message format. The -message format has a header containing a number of fixed fields which -are always present, and four sections which carry query parameters and -RRs. - -The most important field in the header is a four bit field called an -opcode which separates different queries. Of the possible 16 values, -one (standard query) is part of the official protocol, two (inverse -query and status query) are options, one (completion) is obsolete, and -the rest are unassigned. - -The four sections are: - -Question Carries the query name and other query parameters. - -Answer Carries RRs which directly answer the query. - -Authority Carries RRs which describe other authoritative servers. - May optionally carry the SOA RR for the authoritative - data in the answer section. - -Additional Carries RRs which may be helpful in using the RRs in the - other sections. - -Note that the content, but not the format, of these sections varies with -header opcode. - -3.7.1. Standard queries - -A standard query specifies a target domain name (QNAME), query type -(QTYPE), and query class (QCLASS) and asks for RRs which match. This -type of query makes up such a vast majority of DNS queries that we use -the term "query" to mean standard query unless otherwise specified. The -QTYPE and QCLASS fields are each 16 bits long, and are a superset of -defined types and classes. - - - - - -Mockapetris [Page 16] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -The QTYPE field may contain: - -<any type> matches just that type. (e.g., A, PTR). - -AXFR special zone transfer QTYPE. - -MAILB matches all mail box related RRs (e.g. MB and MG). - -* matches all RR types. - -The QCLASS field may contain: - -<any class> matches just that class (e.g., IN, CH). - -* matches aLL RR classes. - -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. - -For example, a mailer tying to send mail to Mockapetris@ISI.EDU might -ask the resolver for mail information about ISI.EDU, resulting in a -query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN. The response's answer -section would be: - - ISI.EDU. MX 10 VENERA.ISI.EDU. - MX 10 VAXA.ISI.EDU. - -while the additional section might be: - - VAXA.ISI.EDU. A 10.2.0.27 - A 128.9.0.33 - VENERA.ISI.EDU. A 10.1.0.52 - A 128.9.0.32 - -Because the server assumes that if the requester wants mail exchange -information, it will probably want the addresses of the mail exchanges -soon afterward. - -Note that the QCLASS=* construct requires special interpretation -regarding authority. Since a particular 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 - - - -Mockapetris [Page 17] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -never be authoritative. - -3.7.2. Inverse queries (Optional) - -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 standard query might map a domain name to a SOA RR, the -corresponding inverse query might map the SOA RR 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 a not-implemented 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. Inverse queries -are primarily useful for debugging and database maintenance activities. - -Inverse queries may not return the proper TTL, and do not indicate cases -where the identified RR is one of a set (for example, one address for a -host having multiple addresses). Therefore, the RRs returned in inverse -queries should never be cached. - -Inverse queries are NOT an acceptable method for mapping host addresses -to host names; use the IN-ADDR.ARPA domain instead. - -A detailed discussion of inverse queries is contained in [RFC-1035]. - -3.8. Status queries (Experimental) - -To be defined. - -3.9. Completion queries (Obsolete) - -The optional completion services described in RFCs 882 and 883 have been -deleted. Redesigned services may become available in the future, or the -opcodes may be reclaimed for other use. - -4. NAME SERVERS - -4.1. Introduction - -Name servers are the repositories of information that make up the domain -database. The database is divided up into sections called zones, which -are distributed among the name servers. While name servers can have -several optional functions and sources of data, the essential task of a -name server is to answer queries using data in its zones. By design, - - - -Mockapetris [Page 18] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -name servers can answer queries in a simple manner; the response can -always be generated using only local data, and either contains the -answer to the question or a referral to other name servers "closer" to -the desired information. - -A given zone will be available from several name servers to insure its -availability in spite of host or communication link failure. By -administrative fiat, we require every zone to be available on at least -two servers, and many zones have more redundancy than that. - -A given name server will typically support one or more zones, but this -gives it authoritative information about only a small section of the -domain tree. It may also have some cached non-authoritative data about -other parts of the tree. The name server marks its responses to queries -so that the requester can tell whether the response comes from -authoritative data or not. - -4.2. How the database is divided into zones - -The domain database is partitioned in two ways: by class, and by "cuts" -made in the name space between nodes. - -The class partition is simple. The database for any class is organized, -delegated, and maintained separately from all other classes. Since, by -convention, the name spaces are the same for all classes, the separate -classes can be thought of as an array of parallel namespace trees. Note -that the data attached to nodes will be different for these different -parallel classes. The most common reasons for creating a new class are -the necessity for a new data format for existing types or a desire for a -separately managed version of the existing name space. - -Within a class, "cuts" in the name space can be made between any two -adjacent nodes. After all cuts are made, each group of connected name -space is a separate zone. The zone is said to be authoritative for all -names in the connected region. Note that the "cuts" in the name space -may be in different places for different classes, the name servers may -be different, etc. - -These rules mean that every zone has at least one node, and hence domain -name, for which it is authoritative, and all of the nodes in a -particular zone are connected. Given, the tree structure, every zone -has a highest node which is closer to the root than any other node in -the zone. The name of this node is often used to identify the zone. - -It would be possible, though not particularly useful, to partition the -name space so that each domain name was in a separate zone or so that -all nodes were in a single zone. Instead, the database is partitioned -at points where a particular organization wants to take over control of - - - -Mockapetris [Page 19] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -a subtree. Once an organization controls its own zone it can -unilaterally change the data in the zone, grow new tree sections -connected to the zone, delete existing nodes, or delegate new subzones -under its zone. - -If the organization has substructure, it may want to make further -internal partitions to achieve nested delegations of name space control. -In some cases, such divisions are made purely to make database -maintenance more convenient. - -4.2.1. Technical considerations - -The data that describes a zone has four major parts: - - - Authoritative data for all nodes within the zone. - - - Data that defines the top node of the zone (can be thought of - as part of the authoritative data). - - - Data that describes delegated subzones, i.e., cuts around the - bottom of the zone. - - - Data that allows access to name servers for subzones - (sometimes called "glue" data). - -All of this data is expressed in the form of RRs, so a zone can be -completely described in terms of a set of RRs. Whole zones can be -transferred between name servers by transferring the RRs, either carried -in a series of messages or by FTPing a master file which is a textual -representation. - -The authoritative data for a zone is simply all of the RRs attached to -all of the nodes from the top node of the zone down to leaf nodes or -nodes above cuts around the bottom edge of the zone. - -Though logically part of the authoritative data, the RRs that describe -the top node of the zone are especially important to the zone's -management. These RRs are of two types: name server RRs that list, one -per RR, all of the servers for the zone, and a single SOA RR that -describes zone management parameters. - -The RRs that describe cuts around the bottom of the zone are NS RRs that -name the servers for the subzones. Since the cuts are between nodes, -these RRs are NOT part of the authoritative data of the zone, and should -be exactly the same as the corresponding RRs in the top node of the -subzone. Since name servers are always associated with zone boundaries, -NS RRs are only found at nodes which are the top node of some zone. In -the data that makes up a zone, NS RRs are found at the top node of the - - - -Mockapetris [Page 20] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -zone (and are authoritative) and at cuts around the bottom of the zone -(where they are not authoritative), but never in between. - -One of the goals of the zone structure is that any zone have all the -data required to set up communications with the name servers for any -subzones. That is, parent zones have all the information needed to -access servers for their children zones. The NS RRs that name the -servers for subzones are often not enough for this task since they name -the servers, but do not give their addresses. In particular, if the -name of the name server is itself in the subzone, we could be faced with -the situation where the NS RRs tell us that in order to learn a name -server's address, we should contact the server using the address we wish -to learn. To fix this problem, a zone contains "glue" RRs which are not -part of the authoritative data, and are address RRs for the servers. -These RRs are only necessary if the name server's name is "below" the -cut, and are only used as part of a referral response. - -4.2.2. Administrative considerations - -When some organization wants to control its own domain, the first step -is to identify the proper parent zone, and get the parent zone's owners -to agree to the delegation of control. While there are no particular -technical constraints dealing with where in the tree this can be done, -there are some administrative groupings discussed in [RFC-1032] which -deal with top level organization, and middle level zones are free to -create their own rules. For example, one university might choose to use -a single zone, while another might choose to organize by subzones -dedicated to individual departments or schools. [RFC-1033] catalogs -available DNS software an discusses administration procedures. - -Once the proper name for the new subzone is selected, the new owners -should be required to demonstrate redundant name server support. Note -that there is no requirement that the servers for a zone reside in a -host which has a name in that domain. In many cases, a zone will be -more accessible to the internet at large if its servers are widely -distributed rather than being within the physical facilities controlled -by the same organization that manages the zone. For example, in the -current DNS, one of the name servers for the United Kingdom, or UK -domain, is found in the US. This allows US hosts to get UK data without -using limited transatlantic bandwidth. - -As the last installation step, the delegation NS RRs and glue RRs -necessary to make the delegation effective should be added to the parent -zone. The administrators of both zones should insure that the NS and -glue RRs which mark both sides of the cut are consistent and remain so. - -4.3. Name server internals - - - - -Mockapetris [Page 21] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -4.3.1. Queries and responses - -The principal activity of name servers is to answer standard queries. -Both the query and its response are carried in a standard message format -which is described in [RFC-1035]. The query contains a QTYPE, QCLASS, -and QNAME, which describe the types and classes of desired information -and the name of interest. - -The way that the name server answers the query depends upon whether it -is operating in recursive mode or not: - - - The simplest mode for the server is non-recursive, since it - can answer queries using only local information: the response - contains an error, the answer, or a referral to some other - server "closer" to the answer. All name servers must - implement non-recursive queries. - - - The simplest mode for the client is recursive, since in this - mode the name server acts in the role of a resolver and - returns either an error or the answer, but never referrals. - This service is optional in a name server, and the name server - may also choose to restrict the clients which can use - recursive mode. - -Recursive service is helpful in several situations: - - - a relatively simple requester that lacks the ability to use - anything other than a direct answer to the question. - - - a request that needs to cross protocol or other boundaries and - can be sent to a server which can act as intermediary. - - - a network where we want to concentrate the cache rather than - having a separate cache for each client. - -Non-recursive service is appropriate if the requester is capable of -pursuing referrals and interested in information which will aid future -requests. - -The use of recursive mode is limited to cases where both the client and -the name server agree to its use. The agreement is negotiated through -the use of two bits in query and response messages: - - - The recursion available, or RA bit, is set or cleared by a - name server in all responses. The bit is true if the name - server is willing to provide recursive service for the client, - regardless of whether the client requested recursive service. - That is, RA signals availability rather than use. - - - -Mockapetris [Page 22] - -RFC 1034 Domain Concepts and Facilities November 1987 - - - - Queries contain a bit called recursion desired or RD. This - bit specifies specifies whether the requester wants recursive - service for this query. Clients may request recursive service - from any name server, though they should depend upon receiving - it only from servers which have previously sent an RA, or - servers which have agreed to provide service through private - agreement or some other means outside of the DNS protocol. - -The recursive mode occurs when a query with RD set arrives at a server -which is willing to provide recursive service; the client can verify -that recursive mode was used by checking that both RA and RD are set in -the reply. Note that the name server should never perform recursive -service unless asked via RD, since this interferes with trouble shooting -of name servers and their databases. - -If recursive service is requested and available, the recursive response -to a query will be one of the following: - - - The answer to the query, possibly preface by one or more CNAME - RRs that specify aliases encountered on the way to an answer. - - - A name error indicating that the name does not exist. This - may include CNAME RRs that indicate that the original query - name was an alias for a name which does not exist. - - - A temporary error indication. - -If recursive service is not requested or is not available, the non- -recursive response will be one of the following: - - - An authoritative name error indicating that the name does not - exist. - - - A temporary error indication. - - - Some combination of: - - RRs that answer the question, together with an indication - whether the data comes from a zone or is cached. - - A referral to name servers which have zones which are closer - ancestors to the name than the server sending the reply. - - - RRs that the name server thinks will prove useful to the - requester. - - - - - - -Mockapetris [Page 23] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -4.3.2. Algorithm - -The actual algorithm used by the name server will depend on the local OS -and data structures used to store RRs. The following algorithm assumes -that the RRs are organized in several tree structures, one for each -zone, and another for the cache: - - 1. Set or clear the value of recursion available in the response - depending on whether the name server is willing to provide - recursive service. If recursive service is available and - requested via the RD bit in the query, go to step 5, - otherwise step 2. - - 2. Search the available zones for the zone which is the nearest - ancestor to QNAME. If such a zone is found, go to step 3, - otherwise step 4. - - 3. Start matching down, label by label, in the zone. The - matching process can terminate several ways: - - a. If the whole of QNAME is matched, we have found the - node. - - If the data at the node is a CNAME, and QTYPE doesn't - match CNAME, copy the CNAME RR into the answer section - of the response, change QNAME to the canonical name in - the CNAME RR, and go back to step 1. - - Otherwise, copy all RRs which match QTYPE into the - answer section and go to step 6. - - b. If a match would take us out of the authoritative data, - we have a referral. This happens when we encounter a - node with NS RRs marking cuts along the bottom of a - zone. - - Copy the NS RRs for the subzone into the authority - section of the reply. Put whatever addresses are - available into the additional section, using glue RRs - if the addresses are not available from authoritative - data or the cache. Go to step 4. - - c. If at some label, a match is impossible (i.e., the - corresponding label does not exist), look to see if a - the "*" label exists. - - If the "*" label does not exist, check whether the name - we are looking for is the original QNAME in the query - - - -Mockapetris [Page 24] - -RFC 1034 Domain Concepts and Facilities November 1987 - - - or a name we have followed due to a CNAME. If the name - is original, set an authoritative name error in the - response and exit. Otherwise just exit. - - If the "*" label does exist, match RRs at that node - against QTYPE. If any match, copy them into the answer - section, but set the owner of the RR to be QNAME, and - not the node with the "*" label. Go to step 6. - - 4. Start matching down in the cache. If QNAME is found in the - cache, copy all RRs attached to it that match QTYPE into the - answer section. If there was no delegation from - authoritative data, look for the best one from the cache, and - put it in the authority section. Go to step 6. - - 5. Using the local resolver or a copy of its algorithm (see - resolver section of this memo) to answer the query. Store - the results, including any intermediate CNAMEs, in the answer - section of the response. - - 6. Using local data only, attempt to add other RRs which may be - useful to the additional section of the query. Exit. - -4.3.3. Wildcards - -In the previous algorithm, special treatment was given to RRs with owner -names starting with the label "*". Such RRs are called wildcards. -Wildcard RRs can be thought of as instructions for synthesizing RRs. -When the appropriate conditions are met, the name server creates RRs -with an owner name equal to the query name and contents taken from the -wildcard RRs. - -This facility is most often used to create a zone which will be used to -forward mail from the Internet to some other mail system. The general -idea is that any name in that zone which is presented to server in a -query will be assumed to exist, with certain properties, unless explicit -evidence exists to the contrary. Note that the use of the term zone -here, instead of domain, is intentional; such defaults do not propagate -across zone boundaries, although a subzone may choose to achieve that -appearance by setting up similar defaults. - -The contents of the wildcard RRs follows the usual rules and formats for -RRs. The wildcards in the zone have an owner name that controls the -query names they will match. The owner name of the wildcard RRs is of -the form "*.<anydomain>", where <anydomain> is any domain name. -<anydomain> should not contain other * labels, and should be in the -authoritative data of the zone. The wildcards potentially apply to -descendants of <anydomain>, but not to <anydomain> itself. Another way - - - -Mockapetris [Page 25] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -to look at this is that the "*" label always matches at least one whole -label and sometimes more, but always whole labels. - -Wildcard RRs do not apply: - - - When the query is in another zone. That is, delegation cancels - the wildcard defaults. - - - When the query name or a name between the wildcard domain and - the query name is know to exist. For example, if a wildcard - RR has an owner name of "*.X", and the zone also contains RRs - attached to B.X, the wildcards would apply to queries for name - Z.X (presuming there is no explicit information for Z.X), but - not to B.X, A.B.X, or X. - -A * label appearing in a query name has no special effect, but can be -used to test for wildcards in an authoritative zone; such a query is the -only way to get a response containing RRs with an owner name with * in -it. The result of such a query should not be cached. - -Note that the contents of the wildcard RRs are not modified when used to -synthesize RRs. - -To illustrate the use of wildcard RRs, suppose a large company with a -large, non-IP/TCP, network wanted to create a mail gateway. If the -company was called X.COM, and IP/TCP capable gateway machine was called -A.X.COM, the following RRs might be entered into the COM zone: - - X.COM MX 10 A.X.COM - - *.X.COM MX 10 A.X.COM - - A.X.COM A 1.2.3.4 - A.X.COM MX 10 A.X.COM - - *.A.X.COM MX 10 A.X.COM - -This would cause any MX query for any domain name ending in X.COM to -return an MX RR pointing at A.X.COM. Two wildcard RRs are required -since the effect of the wildcard at *.X.COM is inhibited in the A.X.COM -subtree by the explicit data for A.X.COM. Note also that the explicit -MX data at X.COM and A.X.COM is required, and that none of the RRs above -would match a query name of XX.COM. - -4.3.4. Negative response caching (Optional) - -The DNS provides an optional service which allows name servers to -distribute, and resolvers to cache, negative results with TTLs. For - - - -Mockapetris [Page 26] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -example, a name server can distribute a TTL along with a name error -indication, and a resolver receiving such information is allowed to -assume that the name does not exist during the TTL period without -consulting authoritative data. Similarly, a resolver can make a query -with a QTYPE which matches multiple types, and cache the fact that some -of the types are not present. - -This feature can be particularly important in a system which implements -naming shorthands that use search lists beacuse a popular shorthand, -which happens to require a suffix toward the end of the search list, -will generate multiple name errors whenever it is used. - -The method is that a name server may add an SOA RR to the additional -section of a response when that response is authoritative. The SOA must -be that of the zone which was the source of the authoritative data in -the answer section, or name error if applicable. The MINIMUM field of -the SOA controls the length of time that the negative result may be -cached. - -Note that in some circumstances, the answer section may contain multiple -owner names. In this case, the SOA mechanism should only be used for -the data which matches QNAME, which is the only authoritative data in -this section. - -Name servers and resolvers should never attempt to add SOAs to the -additional section of a non-authoritative response, or attempt to infer -results which are not directly stated in an authoritative response. -There are several reasons for this, including: cached information isn't -usually enough to match up RRs and their zone names, SOA RRs may be -cached due to direct SOA queries, and name servers are not required to -output the SOAs in the authority section. - -This feature is optional, although a refined version is expected to -become part of the standard protocol in the future. Name servers are -not required to add the SOA RRs in all authoritative responses, nor are -resolvers required to cache negative results. Both are recommended. -All resolvers and recursive name servers are required to at least be -able to ignore the SOA RR when it is present in a response. - -Some experiments have also been proposed which will use this feature. -The idea is that if cached data is known to come from a particular zone, -and if an authoritative copy of the zone's SOA is obtained, and if the -zone's SERIAL has not changed since the data was cached, then the TTL of -the cached data can be reset to the zone MINIMUM value if it is smaller. -This usage is mentioned for planning purposes only, and is not -recommended as yet. - - - - - -Mockapetris [Page 27] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -4.3.5. Zone maintenance and transfers - -Part of the job of a zone administrator is to maintain the zones at all -of the name servers which are authoritative for the zone. When the -inevitable changes are made, they must be distributed to all of the name -servers. While this distribution can be accomplished using FTP or some -other ad hoc procedure, the preferred method is the zone transfer part -of the DNS protocol. - -The general model of automatic zone transfer or refreshing is that one -of the name servers is the master or primary for the zone. Changes are -coordinated at the primary, typically by editing a master file for the -zone. After editing, the administrator signals the master server to -load the new zone. The other non-master or secondary servers for the -zone periodically check for changes (at a selectable interval) and -obtain new zone copies when changes have been made. - -To detect changes, secondaries just check the SERIAL field of the SOA -for the zone. In addition to whatever other changes are made, the -SERIAL field in the SOA of the zone is always advanced whenever any -change is made to the zone. The advancing can be a simple increment, or -could be based on the write date and time of the master file, etc. The -purpose is to make it possible to determine which of two copies of a -zone is more recent by comparing serial numbers. Serial number advances -and comparisons use sequence space arithmetic, so there is a theoretic -limit on how fast a zone can be updated, basically that old copies must -die out before the serial number covers half of its 32 bit range. In -practice, the only concern is that the compare operation deals properly -with comparisons around the boundary between the most positive and most -negative 32 bit numbers. - -The periodic polling of the secondary servers is controlled by -parameters in the SOA RR for the zone, which set the minimum acceptable -polling intervals. The parameters are called REFRESH, RETRY, and -EXPIRE. Whenever a new zone is loaded in a secondary, the secondary -waits REFRESH seconds before checking with the primary for a new serial. -If this check cannot be completed, new checks are started every RETRY -seconds. The check is a simple query to the primary for the SOA RR of -the zone. If the serial field in the secondary's zone copy is equal to -the serial returned by the primary, then no changes have occurred, and -the REFRESH interval wait is restarted. If the secondary finds it -impossible to perform a serial check for the EXPIRE interval, it must -assume that its copy of the zone is obsolete an discard it. - -When the poll shows that the zone has changed, then the secondary server -must request a zone transfer via an AXFR request for the zone. The AXFR -may cause an error, such as refused, but normally is answered by a -sequence of response messages. The first and last messages must contain - - - -Mockapetris [Page 28] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -the data for the top authoritative node of the zone. Intermediate -messages carry all of the other RRs from the zone, including both -authoritative and non-authoritative RRs. The stream of messages allows -the secondary to construct a copy of the zone. Because accuracy is -essential, TCP or some other reliable protocol must be used for AXFR -requests. - -Each secondary server is required to perform the following operations -against the master, but may also optionally perform these operations -against other secondary servers. This strategy can improve the transfer -process when the primary is unavailable due to host downtime or network -problems, or when a secondary server has better network access to an -"intermediate" secondary than to the primary. - -5. RESOLVERS - -5.1. 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. - -The resolver is located on the same machine as the program that requests -the resolver's services, but it may need to consult name servers on -other hosts. Because a resolver may need to consult several name -servers, or may have the requested information in a local cache, the -amount of time that a resolver will take to complete can vary quite a -bit, from milliseconds to several seconds. - -A very important goal of the resolver is to eliminate network delay and -name server load from most requests by answering them from its cache of -prior results. It follows that caches which are shared by multiple -processes, users, machines, etc., are more efficient than non-shared -caches. - -5.2. Client-resolver interface - -5.2.1. Typical functions - -The client interface to the resolver is influenced by the local host's -conventions, but the typical resolver-client interface has three -functions: - - 1. Host name to host address translation. - - This function is often defined to mimic a previous HOSTS.TXT - - - -Mockapetris [Page 29] - -RFC 1034 Domain Concepts and Facilities November 1987 - - - based function. Given a character string, the caller wants - one or more 32 bit IP addresses. Under the DNS, it - translates into a request for type A RRs. Since the DNS does - not preserve the order of RRs, this function may choose to - sort the returned addresses or select the "best" address if - the service returns only one choice to the client. Note that - a multiple address return is recommended, but a single - address may be the only way to emulate prior HOSTS.TXT - services. - - 2. Host address to host name translation - - This function will often follow the form of previous - functions. Given a 32 bit IP address, the caller wants a - character string. The octets of the IP address are reversed, - used as name components, and suffixed with "IN-ADDR.ARPA". A - type PTR query is used to get the RR with the primary name of - the host. For example, a request for the host name - corresponding to IP address 1.2.3.4 looks for PTR RRs for - domain name "4.3.2.1.IN-ADDR.ARPA". - - 3. General lookup function - - This function retrieves arbitrary information from the DNS, - and has no counterpart in previous systems. The caller - supplies a QNAME, QTYPE, and QCLASS, and wants all of the - matching RRs. This function will often use the DNS format - for all RR data instead of the local host's, and returns all - RR content (e.g., TTL) instead of a processed form with local - quoting conventions. - -When the resolver performs the indicated function, it usually has one of -the following results to pass back to the client: - - - One or more RRs giving the requested data. - - In this case the resolver returns the answer in the - appropriate format. - - - A name error (NE). - - This happens when the referenced name does not exist. For - example, a user may have mistyped a host name. - - - A data not found error. - - This happens when the referenced name exists, but data of the - appropriate type does not. For example, a host address - - - -Mockapetris [Page 30] - -RFC 1034 Domain Concepts and Facilities November 1987 - - - function applied to a mailbox name would return this error - since the name exists, but no address RR is present. - -It is important to note that the functions for translating between host -names and addresses may combine the "name error" and "data not found" -error conditions into a single type of error return, but the general -function should not. One reason for this is that applications may ask -first for one type of information about a name followed by a second -request to the same name for some other type of information; if the two -errors are combined, then useless queries may slow the application. - -5.2.2. Aliases - -While attempting to resolve a particular request, the resolver may find -that the name in question is an alias. For example, the resolver might -find that the name given for host name to address translation is an -alias when it finds the CNAME RR. If possible, the alias condition -should be signalled back from the resolver to the client. - -In most cases a resolver simply restarts the query at the new name when -it encounters a CNAME. However, when performing the general function, -the resolver should not pursue aliases when the CNAME RR matches the -query type. This allows queries which ask whether an alias is present. -For example, if the query type is CNAME, the user is interested in the -CNAME RR itself, and not the RRs at the name it points to. - -Several special conditions can occur with aliases. Multiple levels of -aliases should be avoided due to their lack of efficiency, but should -not be signalled as an error. Alias loops and aliases which point to -non-existent names should be caught and an error condition passed back -to the client. - -5.2.3. Temporary failures - -In a less than perfect world, all resolvers will occasionally be unable -to resolve a particular request. This condition can be caused by a -resolver which becomes separated from the rest of the network due to a -link failure or gateway problem, or less often by coincident failure or -unavailability of all servers for a particular domain. - -It is essential that this sort of condition should not be signalled as a -name or data not present error to applications. This sort of behavior -is annoying to humans, and can wreak havoc when mail systems use the -DNS. - -While in some cases it is possible to deal with such a temporary problem -by blocking the request indefinitely, this is usually not a good choice, -particularly when the client is a server process that could move on to - - - -Mockapetris [Page 31] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -other tasks. The recommended solution is to always have temporary -failure as one of the possible results of a resolver function, even -though this may make emulation of existing HOSTS.TXT functions more -difficult. - -5.3. Resolver internals - -Every resolver implementation uses slightly different algorithms, and -typically spends much more logic dealing with errors of various sorts -than typical occurances. This section outlines a recommended basic -strategy for resolver operation, but leaves details to [RFC-1035]. - -5.3.1. Stub resolvers - -One option for implementing a resolver is to move the resolution -function out of the local machine and into a name server which supports -recursive queries. This can provide an easy method of providing domain -service in a PC which lacks the resources to perform the resolver -function, or can centralize the cache for a whole local network or -organization. - -All that the remaining stub needs is a list of name server addresses -that will perform the recursive requests. This type of resolver -presumably needs the information in a configuration file, since it -probably lacks the sophistication to locate it in the domain database. -The user also needs to verify that the listed servers will perform the -recursive service; a name server is free to refuse to perform recursive -services for any or all clients. The user should consult the local -system administrator to find name servers willing to perform the -service. - -This type of service suffers from some drawbacks. Since the recursive -requests may take an arbitrary amount of time to perform, the stub may -have difficulty optimizing retransmission intervals to deal with both -lost UDP packets and dead servers; the name server can be easily -overloaded by too zealous a stub if it interprets retransmissions as new -requests. Use of TCP may be an answer, but TCP may well place burdens -on the host's capabilities which are similar to those of a real -resolver. - -5.3.2. Resources - -In addition to its own resources, the resolver may also have shared -access to zones maintained by a local name server. This gives the -resolver the advantage of more rapid access, but the resolver must be -careful to never let cached information override zone data. In this -discussion the term "local information" is meant to mean the union of -the cache and such shared zones, with the understanding that - - - -Mockapetris [Page 32] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -authoritative data is always used in preference to cached data when both -are present. - -The following resolver algorithm assumes that all functions have been -converted to a general lookup function, and uses the following data -structures to represent the state of a request in progress in the -resolver: - -SNAME the domain name we are searching for. - -STYPE the QTYPE of the search request. - -SCLASS the QCLASS of the search request. - -SLIST a structure which describes the name servers and the - zone which the resolver is currently trying to query. - This structure keeps track of the resolver's current - best guess about which name servers hold the desired - information; it is updated when arriving information - changes the guess. This structure includes the - equivalent of a zone name, the known name servers for - the zone, the known addresses for the name servers, and - history information which can be used to suggest which - server is likely to be the best one to try next. The - zone name equivalent is a match count of the number of - labels from the root down which SNAME has in common with - the zone being queried; this is used as a measure of how - "close" the resolver is to SNAME. - -SBELT a "safety belt" structure of the same form as SLIST, - which is initialized from a configuration file, and - lists servers which should be used when the resolver - doesn't have any local information to guide name server - selection. The match count will be -1 to indicate that - no labels are known to match. - -CACHE A structure which stores the results from previous - responses. Since resolvers are responsible for - discarding old RRs whose TTL has expired, most - implementations convert the interval specified in - arriving RRs to some sort of absolute time when the RR - is stored in the cache. Instead of counting the TTLs - down individually, the resolver just ignores or discards - old RRs when it runs across them in the course of a - search, or discards them during periodic sweeps to - reclaim the memory consumed by old RRs. - - - - - -Mockapetris [Page 33] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -5.3.3. Algorithm - -The top level algorithm has four steps: - - 1. See if the answer is in local information, and if so return - it to the client. - - 2. Find the best servers to ask. - - 3. Send them queries until one returns a response. - - 4. Analyze the response, either: - - a. if the response answers the question or contains a name - error, cache the data as well as returning it back to - the client. - - b. if the response contains a better delegation to other - servers, cache the delegation information, and go to - step 2. - - c. if the response shows a CNAME and that is not the - answer itself, cache the CNAME, change the SNAME to the - canonical name in the CNAME RR and go to step 1. - - d. if the response shows a servers failure or other - bizarre contents, delete the server from the SLIST and - go back to step 3. - -Step 1 searches the cache for the desired data. If the data is in the -cache, it is assumed to be good enough for normal use. Some resolvers -have an option at the user interface which will force the resolver to -ignore the cached data and consult with an authoritative server. This -is not recommended as the default. If the resolver has direct access to -a name server's zones, it should check to see if the desired data is -present in authoritative form, and if so, use the authoritative data in -preference to cached data. - -Step 2 looks for a name server to ask for the required data. The -general strategy is to look for locally-available name server RRs, -starting at SNAME, then the parent domain name of SNAME, the -grandparent, and so on toward the root. Thus if SNAME were -Mockapetris.ISI.EDU, this step would look for NS RRs for -Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root). -These NS RRs list the names of hosts for a zone at or above SNAME. Copy -the names into SLIST. Set up their addresses using local data. It may -be the case that the addresses are not available. The resolver has many -choices here; the best is to start parallel resolver processes looking - - - -Mockapetris [Page 34] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -for the addresses while continuing onward with the addresses which are -available. Obviously, the design choices and options are complicated -and a function of the local host's capabilities. The recommended -priorities for the resolver designer are: - - 1. Bound the amount of work (packets sent, parallel processes - started) so that a request can't get into an infinite loop or - start off a chain reaction of requests or queries with other - implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED - SOME DATA. - - 2. Get back an answer if at all possible. - - 3. Avoid unnecessary transmissions. - - 4. Get the answer as quickly as possible. - -If the search for NS RRs fails, then the resolver initializes SLIST from -the safety belt SBELT. The basic idea is that when the resolver has no -idea what servers to ask, it should use information from a configuration -file that lists several servers which are expected to be helpful. -Although there are special situations, the usual choice is two of the -root servers and two of the servers for the host's domain. The reason -for two of each is for redundancy. The root servers will provide -eventual access to all of the domain space. The two local servers will -allow the resolver to continue to resolve local names if the local -network becomes isolated from the internet due to gateway or link -failure. - -In addition to the names and addresses of the servers, the SLIST data -structure can be sorted to use the best servers first, and to insure -that all addresses of all servers are used in a round-robin manner. The -sorting can be a simple function of preferring addresses on the local -network over others, or may involve statistics from past events, such as -previous response times and batting averages. - -Step 3 sends out queries until a response is received. The strategy is -to cycle around all of the addresses for all of the servers with a -timeout between each transmission. In practice it is important to use -all addresses of a multihomed host, and too aggressive a retransmission -policy actually slows response when used by multiple resolvers -contending for the same name server and even occasionally for a single -resolver. SLIST typically contains data values to control the timeouts -and keep track of previous transmissions. - -Step 4 involves analyzing responses. The resolver should be highly -paranoid in its parsing of responses. It should also check that the -response matches the query it sent using the ID field in the response. - - - -Mockapetris [Page 35] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -The ideal answer is one from a server authoritative for the query which -either gives the required data or a name error. The data is passed back -to the user and entered in the cache for future use if its TTL is -greater than zero. - -If the response shows a delegation, the resolver should check to see -that the delegation is "closer" to the answer than the servers in SLIST -are. This can be done by comparing the match count in SLIST with that -computed from SNAME and the NS RRs in the delegation. If not, the reply -is bogus and should be ignored. If the delegation is valid the NS -delegation RRs and any address RRs for the servers should be cached. -The name servers are entered in the SLIST, and the search is restarted. - -If the response contains a CNAME, the search is restarted at the CNAME -unless the response has the data for the canonical name or if the CNAME -is the answer itself. - -Details and implementation hints can be found in [RFC-1035]. - -6. A SCENARIO - -In our sample domain space, suppose we wanted separate administrative -control for the root, MIL, EDU, MIT.EDU and ISI.EDU zones. We might -allocate name servers as follows: - - - |(C.ISI.EDU,SRI-NIC.ARPA - | A.ISI.EDU) - +---------------------+------------------+ - | | | - MIL EDU ARPA - |(SRI-NIC.ARPA, |(SRI-NIC.ARPA, | - | A.ISI.EDU | C.ISI.EDU) | - +-----+-----+ | +------+-----+-----+ - | | | | | | | - BRL NOSC DARPA | IN-ADDR SRI-NIC ACC - | - +--------+------------------+---------------+--------+ - | | | | | - UCI MIT | UDEL YALE - |(XX.LCS.MIT.EDU, ISI - |ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU, - +---+---+ | A.ISI.EDU) - | | | - LCS ACHILLES +--+-----+-----+--------+ - | | | | | | - XX A C VAXA VENERA Mockapetris - - - - -Mockapetris [Page 36] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -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 C.ISI.EDU, SRI-NIC.ARPA, and -A.ISI.EDU. The MIL domain is served by SRI-NIC.ARPA and A.ISI.EDU. The -EDU domain is served by SRI-NIC.ARPA. and C.ISI.EDU. Note that servers -may have zones which are contiguous or disjoint. In this scenario, -C.ISI.EDU has contiguous zones at the root and EDU domains. A.ISI.EDU -has contiguous zones at the root and MIL domains, but also has a non- -contiguous zone at ISI.EDU. - -6.1. C.ISI.EDU name server - -C.ISI.EDU is a name server for the root, MIL, and EDU domains of the IN -class, and would have zones for these domains. The zone data for the -root domain might be: - - . IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. ( - 870611 ;serial - 1800 ;refresh every 30 min - 300 ;retry every 5 min - 604800 ;expire after a week - 86400) ;minimum of a day - NS A.ISI.EDU. - NS C.ISI.EDU. - NS SRI-NIC.ARPA. - - MIL. 86400 NS SRI-NIC.ARPA. - 86400 NS A.ISI.EDU. - - EDU. 86400 NS SRI-NIC.ARPA. - 86400 NS C.ISI.EDU. - - SRI-NIC.ARPA. A 26.0.0.73 - A 10.0.0.51 - MX 0 SRI-NIC.ARPA. - HINFO DEC-2060 TOPS20 - - ACC.ARPA. A 26.6.0.65 - HINFO PDP-11/70 UNIX - MX 10 ACC.ARPA. - - USC-ISIC.ARPA. CNAME C.ISI.EDU. - - 73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. - 65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA. - 51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. - 52.0.0.10.IN-ADDR.ARPA. PTR C.ISI.EDU. - - - -Mockapetris [Page 37] - -RFC 1034 Domain Concepts and Facilities November 1987 - - - 103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU. - - A.ISI.EDU. 86400 A 26.3.0.103 - C.ISI.EDU. 86400 A 10.0.0.52 - -This data is represented as it would be in a master file. Most RRs are -single line entries; the sole exception here is the SOA RR, which uses -"(" to start a multi-line RR and ")" to show the end of a multi-line RR. -Since the class of all RRs in a zone must be the same, only the first RR -in a zone need specify the class. When a name server loads a zone, it -forces the TTL of all authoritative RRs to be at least the MINIMUM field -of the SOA, here 86400 seconds, or one day. The NS RRs marking -delegation of the MIL and EDU domains, together with the glue RRs for -the servers host addresses, are not part of the authoritative data in -the zone, and hence have explicit TTLs. - -Four RRs are attached to the root node: the SOA which describes the root -zone and the 3 NS RRs which list the name servers for the root. The -data in the SOA RR describes the management of the zone. The zone data -is maintained on host SRI-NIC.ARPA, and the responsible party for the -zone is HOSTMASTER@SRI-NIC.ARPA. A key item in the SOA is the 86400 -second minimum TTL, which means that all authoritative data in the zone -has at least that TTL, although higher values may be explicitly -specified. - -The NS RRs for the MIL and EDU domains mark the boundary between the -root zone and the MIL and EDU zones. Note that in this example, the -lower zones happen to be supported by name servers which also support -the root zone. - -The master file for the EDU zone might be stated relative to the origin -EDU. The zone data for the EDU domain might be: - - EDU. IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. ( - 870729 ;serial - 1800 ;refresh every 30 minutes - 300 ;retry every 5 minutes - 604800 ;expire after a week - 86400 ;minimum of a day - ) - NS SRI-NIC.ARPA. - NS C.ISI.EDU. - - UCI 172800 NS ICS.UCI - 172800 NS ROME.UCI - ICS.UCI 172800 A 192.5.19.1 - ROME.UCI 172800 A 192.5.19.31 - - - - -Mockapetris [Page 38] - -RFC 1034 Domain Concepts and Facilities November 1987 - - - ISI 172800 NS VAXA.ISI - 172800 NS A.ISI - 172800 NS VENERA.ISI.EDU. - VAXA.ISI 172800 A 10.2.0.27 - 172800 A 128.9.0.33 - VENERA.ISI.EDU. 172800 A 10.1.0.52 - 172800 A 128.9.0.32 - A.ISI 172800 A 26.3.0.103 - - UDEL.EDU. 172800 NS LOUIE.UDEL.EDU. - 172800 NS UMN-REI-UC.ARPA. - LOUIE.UDEL.EDU. 172800 A 10.0.0.96 - 172800 A 192.5.39.3 - - YALE.EDU. 172800 NS YALE.ARPA. - YALE.EDU. 172800 NS YALE-BULLDOG.ARPA. - - MIT.EDU. 43200 NS XX.LCS.MIT.EDU. - 43200 NS ACHILLES.MIT.EDU. - XX.LCS.MIT.EDU. 43200 A 10.0.0.44 - ACHILLES.MIT.EDU. 43200 A 18.72.0.8 - -Note the use of relative names here. The owner name for the ISI.EDU. is -stated using a relative name, as are two of the name server RR contents. -Relative and absolute domain names may be freely intermixed in a master - -6.2. Example standard queries - -The following queries and responses illustrate name server behavior. -Unless otherwise noted, the queries do not have recursion desired (RD) -in the header. Note that the answers to non-recursive queries do depend -on the server being asked, but do not depend on the identity of the -requester. - - - - - - - - - - - - - - - - - - -Mockapetris [Page 39] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A - -The query would look like: - - +---------------------------------------------------+ - Header | OPCODE=SQUERY | - +---------------------------------------------------+ - Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A | - +---------------------------------------------------+ - Answer | <empty> | - +---------------------------------------------------+ - Authority | <empty> | - +---------------------------------------------------+ - Additional | <empty> | - +---------------------------------------------------+ - -The response from C.ISI.EDU would be: - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE, AA | - +---------------------------------------------------+ - Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A | - +---------------------------------------------------+ - Answer | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 | - | 86400 IN A 10.0.0.51 | - +---------------------------------------------------+ - Authority | <empty> | - +---------------------------------------------------+ - Additional | <empty> | - +---------------------------------------------------+ - -The header of the response looks like the header of the query, except -that the RESPONSE bit is set, indicating that this message is a -response, not a query, and the Authoritative Answer (AA) bit is set -indicating that the address RRs in the answer section are from -authoritative data. The question section of the response matches the -question section of the query. - - - - - - - - - - - - - - -Mockapetris [Page 40] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -If the same query was sent to some other server which was not -authoritative for SRI-NIC.ARPA, the response might be: - - +---------------------------------------------------+ - Header | OPCODE=SQUERY,RESPONSE | - +---------------------------------------------------+ - Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A | - +---------------------------------------------------+ - Answer | SRI-NIC.ARPA. 1777 IN A 10.0.0.51 | - | 1777 IN A 26.0.0.73 | - +---------------------------------------------------+ - Authority | <empty> | - +---------------------------------------------------+ - Additional | <empty> | - +---------------------------------------------------+ - -This response is different from the previous one in two ways: the header -does not have AA set, and the TTLs are different. The inference is that -the data did not come from a zone, but from a cache. The difference -between the authoritative TTL and the TTL here is due to aging of the -data in a cache. The difference in ordering of the RRs in the answer -section is not significant. - -6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=* - -A query similar to the previous one, but using a QTYPE of *, would -receive the following response from C.ISI.EDU: - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE, AA | - +---------------------------------------------------+ - Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* | - +---------------------------------------------------+ - Answer | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 | - | A 10.0.0.51 | - | MX 0 SRI-NIC.ARPA. | - | HINFO DEC-2060 TOPS20 | - +---------------------------------------------------+ - Authority | <empty> | - +---------------------------------------------------+ - Additional | <empty> | - +---------------------------------------------------+ - - - - - - - - - -Mockapetris [Page 41] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -If a similar query was directed to two name servers which are not -authoritative for SRI-NIC.ARPA, the responses might be: - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE | - +---------------------------------------------------+ - Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* | - +---------------------------------------------------+ - Answer | SRI-NIC.ARPA. 12345 IN A 26.0.0.73 | - | A 10.0.0.51 | - +---------------------------------------------------+ - Authority | <empty> | - +---------------------------------------------------+ - Additional | <empty> | - +---------------------------------------------------+ - -and - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE | - +---------------------------------------------------+ - Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=* | - +---------------------------------------------------+ - Answer | SRI-NIC.ARPA. 1290 IN HINFO DEC-2060 TOPS20 | - +---------------------------------------------------+ - Authority | <empty> | - +---------------------------------------------------+ - Additional | <empty> | - +---------------------------------------------------+ - -Neither of these answers have AA set, so neither response comes from -authoritative data. The different contents and different TTLs suggest -that the two servers cached data at different times, and that the first -server cached the response to a QTYPE=A query and the second cached the -response to a HINFO query. - - - - - - - - - - - - - - - - -Mockapetris [Page 42] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX - -This type of query might be result from a mailer trying to look up -routing information for the mail destination HOSTMASTER@SRI-NIC.ARPA. -The response from C.ISI.EDU would be: - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE, AA | - +---------------------------------------------------+ - Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX | - +---------------------------------------------------+ - Answer | SRI-NIC.ARPA. 86400 IN MX 0 SRI-NIC.ARPA.| - +---------------------------------------------------+ - Authority | <empty> | - +---------------------------------------------------+ - Additional | SRI-NIC.ARPA. 86400 IN A 26.0.0.73 | - | A 10.0.0.51 | - +---------------------------------------------------+ - -This response contains the MX RR in the answer section of the response. -The additional section contains the address RRs because the name server -at C.ISI.EDU guesses that the requester will need the addresses in order -to properly use the information carried by the MX. - -6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS - -C.ISI.EDU would reply to this query with: - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE, AA | - +---------------------------------------------------+ - Question | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS | - +---------------------------------------------------+ - Answer | <empty> | - +---------------------------------------------------+ - Authority | <empty> | - +---------------------------------------------------+ - Additional | <empty> | - +---------------------------------------------------+ - -The only difference between the response and the query is the AA and -RESPONSE bits in the header. The interpretation of this response is -that the server is authoritative for the name, and the name exists, but -no RRs of type NS are present there. - -6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A - -If a user mistyped a host name, we might see this type of query. - - - -Mockapetris [Page 43] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -C.ISI.EDU would answer it with: - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE | - +---------------------------------------------------+ - Question | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A | - +---------------------------------------------------+ - Answer | <empty> | - +---------------------------------------------------+ - Authority | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. | - | 870611 1800 300 604800 86400 | - +---------------------------------------------------+ - Additional | <empty> | - +---------------------------------------------------+ - -This response states that the name does not exist. This condition is -signalled in the response code (RCODE) section of the header. - -The SOA RR in the authority section is the optional negative caching -information which allows the resolver using this response to assume that -the name will not exist for the SOA MINIMUM (86400) seconds. - -6.2.6. QNAME=BRL.MIL, QTYPE=A - -If this query is sent to C.ISI.EDU, the reply would be: - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE | - +---------------------------------------------------+ - Question | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A | - +---------------------------------------------------+ - Answer | <empty> | - +---------------------------------------------------+ - Authority | MIL. 86400 IN NS SRI-NIC.ARPA. | - | 86400 NS A.ISI.EDU. | - +---------------------------------------------------+ - Additional | A.ISI.EDU. A 26.3.0.103 | - | SRI-NIC.ARPA. A 26.0.0.73 | - | A 10.0.0.51 | - +---------------------------------------------------+ - -This response has an empty answer section, but is not authoritative, so -it is a referral. The name server on C.ISI.EDU, realizing that it is -not authoritative for the MIL domain, has referred the requester to -servers on A.ISI.EDU and SRI-NIC.ARPA, which it knows are authoritative -for the MIL domain. - - - - - -Mockapetris [Page 44] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A - -The response to this query from A.ISI.EDU would be: - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE, AA | - +---------------------------------------------------+ - Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A | - +---------------------------------------------------+ - Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. | - | C.ISI.EDU. 86400 IN A 10.0.0.52 | - +---------------------------------------------------+ - Authority | <empty> | - +---------------------------------------------------+ - Additional | <empty> | - +---------------------------------------------------+ - -Note that the AA bit in the header guarantees that the data matching -QNAME is authoritative, but does not say anything about whether the data -for C.ISI.EDU is authoritative. This complete reply is possible because -A.ISI.EDU happens to be authoritative for both the ARPA domain where -USC-ISIC.ARPA is found and the ISI.EDU domain where C.ISI.EDU data is -found. - -If the same query was sent to C.ISI.EDU, its response might be the same -as shown above if it had its own address in its cache, but might also -be: - - - - - - - - - - - - - - - - - - - - - - - - -Mockapetris [Page 45] - -RFC 1034 Domain Concepts and Facilities November 1987 - - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE, AA | - +---------------------------------------------------+ - Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A | - +---------------------------------------------------+ - Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. | - +---------------------------------------------------+ - Authority | ISI.EDU. 172800 IN NS VAXA.ISI.EDU. | - | NS A.ISI.EDU. | - | NS VENERA.ISI.EDU. | - +---------------------------------------------------+ - Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 | - | 172800 A 128.9.0.33 | - | VENERA.ISI.EDU. 172800 A 10.1.0.52 | - | 172800 A 128.9.0.32 | - | A.ISI.EDU. 172800 A 26.3.0.103 | - +---------------------------------------------------+ - -This reply contains an authoritative reply for the alias USC-ISIC.ARPA, -plus a referral to the name servers for ISI.EDU. This sort of reply -isn't very likely given that the query is for the host name of the name -server being asked, but would be common for other aliases. - -6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME - -If this query is sent to either A.ISI.EDU or C.ISI.EDU, the reply would -be: - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE, AA | - +---------------------------------------------------+ - Question | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A | - +---------------------------------------------------+ - Answer | USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU. | - +---------------------------------------------------+ - Authority | <empty> | - +---------------------------------------------------+ - Additional | <empty> | - +---------------------------------------------------+ - -Because QTYPE=CNAME, the CNAME RR itself answers the query, and the name -server doesn't attempt to look up anything for C.ISI.EDU. (Except -possibly for the additional section.) - -6.3. Example resolution - -The following examples illustrate the operations a resolver must perform -for its client. We assume that the resolver is starting without a - - - -Mockapetris [Page 46] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -cache, as might be the case after system boot. We further assume that -the system is not one of the hosts in the data and that the host is -located somewhere on net 26, and that its safety belt (SBELT) data -structure has the following information: - - Match count = -1 - SRI-NIC.ARPA. 26.0.0.73 10.0.0.51 - A.ISI.EDU. 26.3.0.103 - -This information specifies servers to try, their addresses, and a match -count of -1, which says that the servers aren't very close to the -target. Note that the -1 isn't supposed to be an accurate closeness -measure, just a value so that later stages of the algorithm will work. - -The following examples illustrate the use of a cache, so each example -assumes that previous requests have completed. - -6.3.1. Resolve MX for ISI.EDU. - -Suppose the first request to the resolver comes from the local mailer, -which has mail for PVM@ISI.EDU. The mailer might then ask for type MX -RRs for the domain name ISI.EDU. - -The resolver would look in its cache for MX RRs at ISI.EDU, but the -empty cache wouldn't be helpful. The resolver would recognize that it -needed to query foreign servers and try to determine the best servers to -query. This search would look for NS RRs for the domains ISI.EDU, EDU, -and the root. These searches of the cache would also fail. As a last -resort, the resolver would use the information from the SBELT, copying -it into its SLIST structure. - -At this point the resolver would need to pick one of the three available -addresses to try. Given that the resolver is on net 26, it should -choose either 26.0.0.73 or 26.3.0.103 as its first choice. It would -then send off a query of the form: - - - - - - - - - - - - - - - - -Mockapetris [Page 47] - -RFC 1034 Domain Concepts and Facilities November 1987 - - - +---------------------------------------------------+ - Header | OPCODE=SQUERY | - +---------------------------------------------------+ - Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX | - +---------------------------------------------------+ - Answer | <empty> | - +---------------------------------------------------+ - Authority | <empty> | - +---------------------------------------------------+ - Additional | <empty> | - +---------------------------------------------------+ - -The resolver would then wait for a response to its query or a timeout. -If the timeout occurs, it would try different servers, then different -addresses of the same servers, lastly retrying addresses already tried. -It might eventually receive a reply from SRI-NIC.ARPA: - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE | - +---------------------------------------------------+ - Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX | - +---------------------------------------------------+ - Answer | <empty> | - +---------------------------------------------------+ - Authority | ISI.EDU. 172800 IN NS VAXA.ISI.EDU. | - | NS A.ISI.EDU. | - | NS VENERA.ISI.EDU.| - +---------------------------------------------------+ - Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 | - | 172800 A 128.9.0.33 | - | VENERA.ISI.EDU. 172800 A 10.1.0.52 | - | 172800 A 128.9.0.32 | - | A.ISI.EDU. 172800 A 26.3.0.103 | - +---------------------------------------------------+ - -The resolver would notice that the information in the response gave a -closer delegation to ISI.EDU than its existing SLIST (since it matches -three labels). The resolver would then cache the information in this -response and use it to set up a new SLIST: - - Match count = 3 - A.ISI.EDU. 26.3.0.103 - VAXA.ISI.EDU. 10.2.0.27 128.9.0.33 - VENERA.ISI.EDU. 10.1.0.52 128.9.0.32 - -A.ISI.EDU appears on this list as well as the previous one, but that is -purely coincidental. The resolver would again start transmitting and -waiting for responses. Eventually it would get an answer: - - - -Mockapetris [Page 48] - -RFC 1034 Domain Concepts and Facilities November 1987 - - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE, AA | - +---------------------------------------------------+ - Question | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX | - +---------------------------------------------------+ - Answer | ISI.EDU. MX 10 VENERA.ISI.EDU. | - | MX 20 VAXA.ISI.EDU. | - +---------------------------------------------------+ - Authority | <empty> | - +---------------------------------------------------+ - Additional | VAXA.ISI.EDU. 172800 A 10.2.0.27 | - | 172800 A 128.9.0.33 | - | VENERA.ISI.EDU. 172800 A 10.1.0.52 | - | 172800 A 128.9.0.32 | - +---------------------------------------------------+ - -The resolver would add this information to its cache, and return the MX -RRs to its client. - -6.3.2. Get the host name for address 26.6.0.65 - -The resolver would translate this into a request for PTR RRs for -65.0.6.26.IN-ADDR.ARPA. This information is not in the cache, so the -resolver would look for foreign servers to ask. No servers would match, -so it would use SBELT again. (Note that the servers for the ISI.EDU -domain are in the cache, but ISI.EDU is not an ancestor of -65.0.6.26.IN-ADDR.ARPA, so the SBELT is used.) - -Since this request is within the authoritative data of both servers in -SBELT, eventually one would return: - - - - - - - - - - - - - - - - - - - - - -Mockapetris [Page 49] - -RFC 1034 Domain Concepts and Facilities November 1987 - - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE, AA | - +---------------------------------------------------+ - Question | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR | - +---------------------------------------------------+ - Answer | 65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA. | - +---------------------------------------------------+ - Authority | <empty> | - +---------------------------------------------------+ - Additional | <empty> | - +---------------------------------------------------+ - -6.3.3. Get the host address of poneria.ISI.EDU - -This request would translate into a type A request for poneria.ISI.EDU. -The resolver would not find any cached data for this name, but would -find the NS RRs in the cache for ISI.EDU when it looks for foreign -servers to ask. Using this data, it would construct a SLIST of the -form: - - Match count = 3 - - A.ISI.EDU. 26.3.0.103 - VAXA.ISI.EDU. 10.2.0.27 128.9.0.33 - VENERA.ISI.EDU. 10.1.0.52 - -A.ISI.EDU is listed first on the assumption that the resolver orders its -choices by preference, and A.ISI.EDU is on the same network. - -One of these servers would answer the query. - -7. REFERENCES and BIBLIOGRAPHY - -[Dyer 87] Dyer, S., and F. Hsu, "Hesiod", Project Athena - Technical Plan - Name Service, April 1987, version 1.9. - - Describes the fundamentals of the Hesiod name service. - -[IEN-116] J. Postel, "Internet Name Server", IEN-116, - USC/Information Sciences Institute, August 1979. - - A name service obsoleted by the Domain Name System, but - still in use. - - - - - - - - -Mockapetris [Page 50] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -[Quarterman 86] Quarterman, J., and J. Hoskins, "Notable Computer - Networks",Communications of the ACM, October 1986, - volume 29, number 10. - -[RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network - Information Center, SRI International, December 1977. - -[RFC-768] J. Postel, "User Datagram Protocol", RFC-768, - USC/Information Sciences Institute, August 1980. - -[RFC-793] J. Postel, "Transmission Control Protocol", RFC-793, - USC/Information Sciences Institute, September 1981. - -[RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT, - September 1981. - - Suggests introduction of a hierarchy in place of a flat - name space for the Internet. - -[RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805, - USC/Information Sciences Institute, February 1982. - -[RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD - Internet Host Table Specification", RFC-810, Network - Information Center, SRI International, March 1982. - - Obsolete. See RFC-952. - -[RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames - Server", RFC-811, Network Information Center, SRI - International, March 1982. - - Obsolete. See RFC-953. - -[RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812, - Network Information Center, SRI International, March - 1982. - -[RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for - Internet User Applications", RFC-819, Network - Information Center, SRI International, August 1982. - - Early thoughts on the design of the domain system. - Current implementation is completely different. - -[RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821, - USC/Information Sciences Institute, August 1980. - - - - -Mockapetris [Page 51] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -[RFC-830] Z. Su, "A Distributed System for Internet Name Service", - RFC-830, Network Information Center, SRI International, - October 1982. - - Early thoughts on the design of the domain system. - Current implementation is completely different. - -[RFC-882] P. Mockapetris, "Domain names - Concepts and - Facilities," RFC-882, USC/Information Sciences - Institute, November 1983. - - Superceeded by this memo. - -[RFC-883] P. Mockapetris, "Domain names - Implementation and - Specification," RFC-883, USC/Information Sciences - Institute, November 1983. - - Superceeded by this memo. - -[RFC-920] J. Postel and J. Reynolds, "Domain Requirements", - RFC-920, USC/Information Sciences Institute - October 1984. - - Explains the naming scheme for top level domains. - -[RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host - Table Specification", RFC-952, SRI, October 1985. - - Specifies the format of HOSTS.TXT, the host/address - table replaced by the DNS. - -[RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server", - RFC-953, SRI, October 1985. - - This RFC contains the official specification of the - hostname server protocol, which is obsoleted by the DNS. - This TCP based protocol accesses information stored in - the RFC-952 format, and is used to obtain copies of the - host table. - -[RFC-973] P. Mockapetris, "Domain System Changes and - Observations", RFC-973, USC/Information Sciences - Institute, January 1986. - - Describes changes to RFC-882 and RFC-883 and reasons for - them. Now obsolete. - - - - - -Mockapetris [Page 52] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -[RFC-974] C. Partridge, "Mail routing and the domain system", - RFC-974, CSNET CIC BBN Labs, January 1986. - - Describes the transition from HOSTS.TXT based mail - addressing to the more powerful MX system used with the - domain system. - -[RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS - service on a TCP/UDP transport: Concepts and Methods", - RFC-1001, March 1987. - - This RFC and RFC-1002 are a preliminary design for - NETBIOS on top of TCP/IP which proposes to base NetBIOS - name service on top of the DNS. - -[RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS - service on a TCP/UDP transport: Detailed - Specifications", RFC-1002, March 1987. - -[RFC-1010] J. Reynolds and J. Postel, "Assigned Numbers", RFC-1010, - USC/Information Sciences Institute, May 1987 - - Contains socket numbers and mnemonics for host names, - operating systems, etc. - -[RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031, - November 1987. - - Describes a plan for converting the MILNET to the DNS. - -[RFC-1032] M. K. Stahl, "Establishing a Domain - Guidelines for - Administrators", RFC-1032, November 1987. - - Describes the registration policies used by the NIC to - administer the top level domains and delegate subzones. - -[RFC-1033] M. K. Lottor, "Domain Administrators Operations Guide", - RFC-1033, November 1987. - - A cookbook for domain administrators. - -[Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET - Name Server", Computer Networks, vol 6, nr 3, July 1982. - - Describes a name service for CSNET which is independent - from the DNS and DNS use in the CSNET. - - - - - -Mockapetris [Page 53] - -RFC 1034 Domain Concepts and Facilities November 1987 - - -Index - - A 12 - Absolute names 8 - Aliases 14, 31 - Authority 6 - AXFR 17 - - Case of characters 7 - CH 12 - CNAME 12, 13, 31 - Completion queries 18 - - Domain name 6, 7 - - Glue RRs 20 - - HINFO 12 - - IN 12 - Inverse queries 16 - Iterative 4 - - Label 7 - - Mailbox names 9 - MX 12 - - Name error 27, 36 - Name servers 5, 17 - NE 30 - Negative caching 44 - NS 12 - - Opcode 16 - - PTR 12 - - QCLASS 16 - QTYPE 16 - - RDATA 13 - Recursive 4 - Recursive service 22 - Relative names 7 - Resolvers 6 - RR 12 - - - - -Mockapetris [Page 54] - -RFC 1034 Domain Concepts and Facilities November 1987 - - - Safety belt 33 - Sections 16 - SOA 12 - Standard queries 22 - - Status queries 18 - Stub resolvers 32 - - TTL 12, 13 - - Wildcards 25 - - Zone transfers 28 - Zones 19 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Mockapetris [Page 55] - diff --git a/contrib/bind9/doc/rfc/rfc1035.txt b/contrib/bind9/doc/rfc/rfc1035.txt deleted file mode 100644 index b1a9bf5a94b6..000000000000 --- a/contrib/bind9/doc/rfc/rfc1035.txt +++ /dev/null @@ -1,3077 +0,0 @@ -Network Working Group P. Mockapetris -Request for Comments: 1035 ISI - November 1987 -Obsoletes: RFCs 882, 883, 973 - - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION - - -1. STATUS OF THIS MEMO - -This RFC describes the details of the domain system and protocol, and -assumes that the reader is familiar with the concepts discussed in a -companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034]. - -The domain system is a mixture of functions and data types which are an -official protocol and functions and data types which are still -experimental. Since the domain system is intentionally extensible, new -data types and experimental behavior should always be expected in parts -of the system beyond the official protocol. The official protocol parts -include standard queries, responses and the Internet class RR data -formats (e.g., host addresses). Since the previous RFC set, several -definitions have changed, so some previous definitions are obsolete. - -Experimental or obsolete features are clearly marked in these RFCs, and -such information should be used with caution. - -The reader is especially cautioned not to depend on the values which -appear in examples to be current or complete, since their purpose is -primarily pedagogical. Distribution of this memo is unlimited. - - Table of Contents - - 1. STATUS OF THIS MEMO 1 - 2. INTRODUCTION 3 - 2.1. Overview 3 - 2.2. Common configurations 4 - 2.3. Conventions 7 - 2.3.1. Preferred name syntax 7 - 2.3.2. Data Transmission Order 8 - 2.3.3. Character Case 9 - 2.3.4. Size limits 10 - 3. DOMAIN NAME SPACE AND RR DEFINITIONS 10 - 3.1. Name space definitions 10 - 3.2. RR definitions 11 - 3.2.1. Format 11 - 3.2.2. TYPE values 12 - 3.2.3. QTYPE values 12 - 3.2.4. CLASS values 13 - - - -Mockapetris [Page 1] - -RFC 1035 Domain Implementation and Specification November 1987 - - - 3.2.5. QCLASS values 13 - 3.3. Standard RRs 13 - 3.3.1. CNAME RDATA format 14 - 3.3.2. HINFO RDATA format 14 - 3.3.3. MB RDATA format (EXPERIMENTAL) 14 - 3.3.4. MD RDATA format (Obsolete) 15 - 3.3.5. MF RDATA format (Obsolete) 15 - 3.3.6. MG RDATA format (EXPERIMENTAL) 16 - 3.3.7. MINFO RDATA format (EXPERIMENTAL) 16 - 3.3.8. MR RDATA format (EXPERIMENTAL) 17 - 3.3.9. MX RDATA format 17 - 3.3.10. NULL RDATA format (EXPERIMENTAL) 17 - 3.3.11. NS RDATA format 18 - 3.3.12. PTR RDATA format 18 - 3.3.13. SOA RDATA format 19 - 3.3.14. TXT RDATA format 20 - 3.4. ARPA Internet specific RRs 20 - 3.4.1. A RDATA format 20 - 3.4.2. WKS RDATA format 21 - 3.5. IN-ADDR.ARPA domain 22 - 3.6. Defining new types, classes, and special namespaces 24 - 4. MESSAGES 25 - 4.1. Format 25 - 4.1.1. Header section format 26 - 4.1.2. Question section format 28 - 4.1.3. Resource record format 29 - 4.1.4. Message compression 30 - 4.2. Transport 32 - 4.2.1. UDP usage 32 - 4.2.2. TCP usage 32 - 5. MASTER FILES 33 - 5.1. Format 33 - 5.2. Use of master files to define zones 35 - 5.3. Master file example 36 - 6. NAME SERVER IMPLEMENTATION 37 - 6.1. Architecture 37 - 6.1.1. Control 37 - 6.1.2. Database 37 - 6.1.3. Time 39 - 6.2. Standard query processing 39 - 6.3. Zone refresh and reload processing 39 - 6.4. Inverse queries (Optional) 40 - 6.4.1. The contents of inverse queries and responses 40 - 6.4.2. Inverse query and response example 41 - 6.4.3. Inverse query processing 42 - - - - - - -Mockapetris [Page 2] - -RFC 1035 Domain Implementation and Specification November 1987 - - - 6.5. Completion queries and responses 42 - 7. RESOLVER IMPLEMENTATION 43 - 7.1. Transforming a user request into a query 43 - 7.2. Sending the queries 44 - 7.3. Processing responses 46 - 7.4. Using the cache 47 - 8. MAIL SUPPORT 47 - 8.1. Mail exchange binding 48 - 8.2. Mailbox binding (Experimental) 48 - 9. REFERENCES and BIBLIOGRAPHY 50 - Index 54 - -2. INTRODUCTION - -2.1. 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; the resolver is -responsible for hiding the distribution of data among name servers from -the user. - -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 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 -"pruned" 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 - - - -Mockapetris [Page 3] - -RFC 1035 Domain Implementation and Specification November 1987 - - -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. - -2.2. Common configurations - -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 | | - +----------+ | - | cache | | - +----------+ | - -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 cache 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 the local cache. - -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 - - - -Mockapetris [Page 4] - -RFC 1035 Domain Implementation and Specification November 1987 - - -in this memo, and may be datagrams. - -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 a primary 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. - -The DNS requires that all zones be redundantly supported by more than -one name server. Designated secondary servers can acquire zones and -check for updates from the primary server using the zone transfer -protocol of the DNS. 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 - - - -Mockapetris [Page 5] - -RFC 1035 Domain Implementation and Specification November 1987 - - -these maintenance activities follow the same form as queries and -responses, but the message sequences are somewhat different. - -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 implementor. - - - - -Mockapetris [Page 6] - -RFC 1035 Domain Implementation and Specification November 1987 - - -Information flow can also be tailored so that a group of hosts act -together to optimize activities. Sometimes this is done to offload less -capable hosts so that they do not have to implement a full resolver. -This can be appropriate for PCs or hosts which want to minimize the -amount of new network code which is required. This scheme can also -allow a group of hosts can share a small number of caches rather than -maintaining a large number of separate caches, on the premise that the -centralized caches will have a higher hit ratio. In either case, -resolvers are replaced with stub resolvers which act as front ends to -resolvers located in a recursive server in one or more name servers -known to perform that service: - - Local Hosts | Foreign - | - +---------+ | - | | responses | - | Stub |<--------------------+ | - | Resolver| | | - | |----------------+ | | - +---------+ recursive | | | - queries | | | - V | | - +---------+ recursive +----------+ | +--------+ - | | queries | |queries | | | - | Stub |-------------->| Recursive|---------|->|Foreign | - | Resolver| | Server | | | Name | - | |<--------------| |<--------|--| Server | - +---------+ responses | |responses| | | - +----------+ | +--------+ - | Central | | - | cache | | - +----------+ | - -In any case, note that domain components are always replicated for -reliability whenever possible. - -2.3. Conventions - -The domain system has several conventions dealing with low-level, but -fundamental, issues. While the implementor is free to violate these -conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in -ALL behavior observed from other hosts. - -2.3.1. Preferred name syntax - -The DNS specifications attempt to be as general as possible in the rules -for constructing domain names. The idea is that the name of any -existing object can be expressed as a domain name with minimal changes. - - - -Mockapetris [Page 7] - -RFC 1035 Domain Implementation and Specification November 1987 - - -However, when assigning a domain name for an object, the prudent user -will select a name which satisfies both the rules of the domain system -and any existing rules for the object, whether these rules are published -or implied by existing programs. - -For example, when naming a mail domain, the user should satisfy both the -rules of this memo and those in RFC-822. When creating a new host name, -the old rules for HOSTS.TXT should be followed. This avoids problems -when old software is converted to use domain names. - -The following syntax will result in fewer problems with many - -applications that use domain names (e.g., mail, TELNET). - -<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 Internet: - -A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA - -2.3.2. 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 - - - -Mockapetris [Page 8] - -RFC 1035 Domain Implementation and Specification November 1987 - - -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 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -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| - +-+-+-+-+-+-+-+-+ - -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. - -2.3.3. Character Case - -For all parts of the DNS that are part of the official protocol, all -comparisons between character strings (e.g., labels, domain names, etc.) -are done in a case-insensitive manner. At present, this rule is in -force throughout the domain system without exception. However, future -additions beyond current usage may need to use the full binary octet -capabilities in names, so attempts to store domain names in 7-bit ASCII -or use of special bytes to terminate labels, etc., should be avoided. - -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 RRs are stored in a database, one at x.y and -one at X.Y, they are actually stored at the same place in the database, -and hence only one casing would be preserved. 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. - - - - -Mockapetris [Page 9] - -RFC 1035 Domain Implementation and Specification November 1987 - - -Loss of case sensitive data must be minimized. Thus while data for x.y -and X.Y may both be stored under a single location x.y or X.Y, data for -a.x and B.X would never be stored under A.x, A.X, b.x, or b.X. In -general, this preserves the case of the first label of a domain name, -but forces standardization of interior node labels. - -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. - -2.3.4. Size limits - -Various objects and parameters in the DNS have size limits. They are -listed below. Some could be easily changed, others are more -fundamental. - -labels 63 octets or less - -names 255 octets or less - -TTL positive values of a signed 32 bit number. - -UDP messages 512 octets or less - -3. DOMAIN NAME SPACE AND RR DEFINITIONS - -3.1. Name space definitions - -Domain names in 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 domain name is terminated by a length byte of zero. The -high order two bits of every length octet 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 a domain name (i.e., -label octets and label length octets) is restricted to 255 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 preferred -syntax described elsewhere in 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), assuming ASCII -with zero parity. Non-alphabetic codes must match exactly. - - - -Mockapetris [Page 10] - -RFC 1035 Domain Implementation and Specification November 1987 - - -3.2. RR definitions - -3.2.1. Format - -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 an owner name, i.e., the name of the node to which this - resource record pertains. - -TYPE two octets containing one of the RR TYPE codes. - -CLASS two octets containing one of the RR CLASS codes. - -TTL a 32 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 11] - -RFC 1035 Domain Implementation and Specification November 1987 - - -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. - -3.2.2. TYPE values - -TYPE fields are used in resource records. Note that these types are a -subset of QTYPEs. - -TYPE value and meaning - -A 1 a host address - -NS 2 an authoritative name server - -MD 3 a mail destination (Obsolete - use MX) - -MF 4 a mail forwarder (Obsolete - use MX) - -CNAME 5 the canonical name for an alias - -SOA 6 marks the start of a zone of authority - -MB 7 a mailbox domain name (EXPERIMENTAL) - -MG 8 a mail group member (EXPERIMENTAL) - -MR 9 a mail rename domain name (EXPERIMENTAL) - -NULL 10 a null RR (EXPERIMENTAL) - -WKS 11 a well known service description - -PTR 12 a domain name pointer - -HINFO 13 host information - -MINFO 14 mailbox or mail list information - -MX 15 mail exchange - -TXT 16 text strings - -3.2.3. QTYPE values - -QTYPE fields appear in the question part of a query. QTYPES are a -superset of TYPEs, hence all TYPEs are valid QTYPEs. In addition, the -following QTYPEs are defined: - - - -Mockapetris [Page 12] - -RFC 1035 Domain Implementation and Specification November 1987 - - -AXFR 252 A request for a transfer of an entire zone - -MAILB 253 A request for mailbox-related records (MB, MG or MR) - -MAILA 254 A request for mail agent RRs (Obsolete - see MX) - -* 255 A request for all records - -3.2.4. CLASS values - -CLASS fields appear in resource records. The following CLASS mnemonics -and values are defined: - -IN 1 the Internet - -CS 2 the CSNET class (Obsolete - used only for examples in - some obsolete RFCs) - -CH 3 the CHAOS class - -HS 4 Hesiod [Dyer 87] - -3.2.5. QCLASS values - -QCLASS fields appear in the question section of a query. QCLASS values -are a superset of CLASS values; every CLASS is a valid QCLASS. In -addition to CLASS values, the following QCLASSes are defined: - -* 255 any class - -3.3. Standard RRs - -The following RR definitions are expected to occur, at least -potentially, in all classes. In particular, NS, SOA, CNAME, and PTR -will be used in all classes, and have the same format in all classes. -Because their RDATA format is known, all domain names in the RDATA -section of these RRs may be compressed. - -<domain-name> is a domain name represented as a series of labels, and -terminated by a label with zero length. <character-string> is a single -length octet followed by that number of characters. <character-string> -is treated as binary information, and can be up to 256 characters in -length (including the length octet). - - - - - - - - -Mockapetris [Page 13] - -RFC 1035 Domain Implementation and Specification November 1987 - - -3.3.1. CNAME RDATA format - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / CNAME / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -CNAME A <domain-name> which specifies the canonical or primary - name for the owner. The owner name is an alias. - -CNAME RRs cause no additional section processing, but name servers may -choose to restart the query at the canonical name in certain cases. See -the description of name server logic in [RFC-1034] for details. - -3.3.2. HINFO RDATA format - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / CPU / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / OS / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -CPU A <character-string> which specifies the CPU type. - -OS A <character-string> which specifies the operating - system type. - -Standard values for CPU and OS can be found in [RFC-1010]. - -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. - -3.3.3. MB RDATA format (EXPERIMENTAL) - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / MADNAME / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -MADNAME A <domain-name> which specifies a host which has the - specified mailbox. - - - -Mockapetris [Page 14] - -RFC 1035 Domain Implementation and Specification November 1987 - - -MB records cause additional section processing which looks up an A type -RRs corresponding to MADNAME. - -3.3.4. MD RDATA format (Obsolete) - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / MADNAME / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -MADNAME A <domain-name> which specifies a host which 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. - -MD is obsolete. See the definition of MX and [RFC-974] for details of -the new scheme. The recommended policy for dealing with MD RRs found in -a master file is to reject them, or to convert them to MX RRs with a -preference of 0. - -3.3.5. MF RDATA format (Obsolete) - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / MADNAME / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -MADNAME A <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. - -MF is obsolete. See the definition of MX and [RFC-974] for details ofw -the new scheme. The recommended policy for dealing with MD RRs found in -a master file is to reject them, or to convert them to MX RRs with a -preference of 10. - - - - - - - -Mockapetris [Page 15] - -RFC 1035 Domain Implementation and Specification November 1987 - - -3.3.6. MG RDATA format (EXPERIMENTAL) - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / MGMNAME / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -MGMNAME A <domain-name> which specifies a mailbox which is a - member of the mail group specified by the domain name. - -MG records cause no additional section processing. - -3.3.7. MINFO RDATA format (EXPERIMENTAL) - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / RMAILBX / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / EMAILBX / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -RMAILBX A <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 <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. - - - - - - - - -Mockapetris [Page 16] - -RFC 1035 Domain Implementation and Specification November 1987 - - -3.3.8. MR RDATA format (EXPERIMENTAL) - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / NEWNAME / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -NEWNAME A <domain-name> which specifies a mailbox which is the - proper rename of the specified mailbox. - -MR records cause no additional section processing. The main use for MR -is as a forwarding entry for a user who has moved to a different -mailbox. - -3.3.9. MX RDATA format - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | PREFERENCE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / EXCHANGE / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -PREFERENCE A 16 bit integer which specifies the preference given to - this RR among others at the same owner. Lower values - are preferred. - -EXCHANGE A <domain-name> which specifies a host willing to act as - a mail exchange for the owner name. - -MX records cause type A additional section processing for the host -specified by EXCHANGE. The use of MX RRs is explained in detail in -[RFC-974]. - -3.3.10. NULL RDATA format (EXPERIMENTAL) - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / <anything> / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -Anything at all may be in the RDATA field so long as it is 65535 octets -or less. - - - - -Mockapetris [Page 17] - -RFC 1035 Domain Implementation and Specification November 1987 - - -NULL records cause no additional section processing. NULL RRs are not -allowed in master files. NULLs are used as placeholders in some -experimental extensions of the DNS. - -3.3.11. NS RDATA format - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / NSDNAME / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -NSDNAME A <domain-name> which specifies a host which should be - authoritative for the specified class and domain. - -NS records cause both the usual additional section processing to locate -a type A record, and, when used in a referral, a special search of the -zone in which they reside for glue information. - -The NS RR states that the named host should be expected to have a zone -starting at owner name of the specified class. Note that the class may -not indicate the protocol family which should be used to communicate -with the host, although it is typically a strong hint. For example, -hosts which are name servers for either Internet (IN) or Hesiod (HS) -class information are normally queried using IN class protocols. - -3.3.12. PTR RDATA format - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / PTRDNAME / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -PTRDNAME A <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. See the -description of the IN-ADDR.ARPA domain for an example. - - - - - - - - -Mockapetris [Page 18] - -RFC 1035 Domain Implementation and Specification November 1987 - - -3.3.13. SOA RDATA format - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / MNAME / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / RNAME / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | SERIAL | - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | REFRESH | - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | RETRY | - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | EXPIRE | - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | MINIMUM | - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -MNAME The <domain-name> of the name server that was the - original or primary source of data for this zone. - -RNAME A <domain-name> which specifies the mailbox of the - person responsible for this zone. - -SERIAL The unsigned 32 bit version number of the original copy - of the zone. Zone transfers preserve this value. This - value wraps and should be compared using sequence space - arithmetic. - -REFRESH A 32 bit time interval before the zone should be - refreshed. - -RETRY A 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. - - - - - -Mockapetris [Page 19] - -RFC 1035 Domain Implementation and Specification November 1987 - - -MINIMUM The unsigned 32 bit minimum TTL field that should be - exported with any RR from this zone. - -SOA records cause no additional section processing. - -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. Note that this use of -MINIMUM should occur when the RRs are copied into the response and not -when the zone is loaded from a master file or via a zone transfer. The -reason for this provison is to allow future dynamic update facilities to -change the SOA RR with known semantics. - - -3.3.14. TXT RDATA format - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / TXT-DATA / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -TXT-DATA One or more <character-string>s. - -TXT RRs are used to hold descriptive text. The semantics of the text -depends on the domain where it is found. - -3.4. Internet specific RRs - -3.4.1. A RDATA format - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ADDRESS | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -ADDRESS A 32 bit Internet address. - -Hosts that have multiple Internet addresses will have multiple A -records. - - - - - -Mockapetris [Page 20] - -RFC 1035 Domain Implementation and Specification November 1987 - - -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"). - -3.4.2. WKS RDATA format - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ADDRESS | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | PROTOCOL | | - +--+--+--+--+--+--+--+--+ | - | | - / <BIT MAP> / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -where: - -ADDRESS An 32 bit 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 the bit map does not include a bit for a -protocol of interest, that bit is assumed zero. The appropriate values -and mnemonics for ports and protocols are specified in [RFC-1010]. - -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 purpose 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. - -In master files, both ports and protocols are expressed using mnemonics -or decimal numbers. - - - - -Mockapetris [Page 21] - -RFC 1035 Domain Implementation and Specification November 1987 - - -3.5. IN-ADDR.ARPA domain - -The Internet uses a special domain to support gateway location and -Internet address to host mapping. Other classes may employ a similar -strategy in other domains. The intent of this domain is to provide a -guaranteed method to perform host address to host name mapping, and to -facilitate queries to locate all gateways on a particular network in the -Internet. - -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. - -The domain begins at IN-ADDR.ARPA and has a substructure which follows -the Internet addressing structure. - -Domain names in the IN-ADDR.ARPA domain are defined to have up to four -labels in addition to the IN-ADDR.ARPA suffix. Each label represents -one octet of an Internet address, and is expressed as a character string -for 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). - -Host addresses are represented by domain names that have all four labels -specified. Thus data for Internet address 10.2.0.52 is located at -domain name 52.0.2.10.IN-ADDR.ARPA. The reversal, though awkward to -read, allows zones to be delegated which are exactly one network of -address space. For example, 10.IN-ADDR.ARPA can be a zone containing -data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for -MILNET. Address nodes are used to hold pointers to primary host names -in the normal domain space. - -Network numbers correspond to some non-terminal nodes at various depths -in the IN-ADDR.ARPA domain, since Internet network numbers are either 1, -2, or 3 octets. Network nodes are used to hold pointers to the primary -host names of gateways attached to that network. Since a gateway is, by -definition, on more than one network, it will typically have two or more -network nodes which point at it. 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, the IN-ADDR.ARPA domain will contain information about the -ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's - - - -Mockapetris [Page 22] - -RFC 1035 Domain Implementation and Specification November 1987 - - -net 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU. Assuming that ISI -gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET- -GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4 -and a name GW.LCS.MIT.EDU, the domain database would contain: - - 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU. - 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU. - 18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU. - 26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU. - 22.0.2.10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU. - 103.0.0.26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU. - 77.0.0.10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU. - 4.0.10.18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU. - 103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU. - 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU. - -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.ARPA. It -would receive two RRs in response: - - 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU. - 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU. - -The program could then originate QTYPE=A, QCLASS=IN queries for MILNET- -GW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of -these gateways. - -A resolver which wanted to find the host name corresponding to Internet -host address 10.0.0.6 would pursue a query of the form QTYPE=PTR, -QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive: - - 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU. - -Several cautions apply to the use of these services: - - Since the IN-ADDR.ARPA 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 - manner equivalent to the current HOSTS.TXT file. It doesn't - replace the dynamic availability information from GGP or EGP. - - - -Mockapetris [Page 23] - -RFC 1035 Domain Implementation and Specification November 1987 - - -3.6. Defining new types, classes, and special namespaces - -The previously defined types and classes are the ones in use as of the -date of this memo. New definitions should be expected. This section -makes some recommendations to designers considering additions to the -existing facilities. The mailing list NAMEDROPPERS@SRI-NIC.ARPA is the -forum where general discussion of design issues takes place. - -In general, a new type is appropriate when new information is to be -added to the database about an existing object, or we need new data -formats for some totally new object. Designers should attempt to define -types and their RDATA formats that are generally applicable to all -classes, and which avoid duplication of information. New classes are -appropriate when the DNS is to be used for a new protocol, etc which -requires new class-specific data formats, or when a copy of the existing -name space is desired, but a separate management domain is necessary. - -New types and classes need mnemonics for master files; the format of the -master files requires that the mnemonics for type and class be disjoint. - -TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes -respectively. - -The present system uses multiple RRs to represent multiple values of a -type rather than storing multiple values in the RDATA section of a -single RR. This is less efficient for most applications, but does keep -RRs shorter. The multiple RRs assumption is incorporated in some -experimental work on dynamic update methods. - -The present system attempts to minimize the duplication of data in the -database in order to insure consistency. Thus, in order to find the -address of the host for a mail exchange, you map the mail domain name to -a host name, then the host name to addresses, rather than a direct -mapping to host address. This approach is preferred because it avoids -the opportunity for inconsistency. - -In defining a new type of data, multiple RR types should not be used to -create an ordering between entries or express different formats for -equivalent bindings, instead this information should be carried in the -body of the RR and a single type used. This policy avoids problems with -caching multiple types and defining QTYPEs to match multiple types. - -For example, the original form of mail exchange binding used two RR -types one to represent a "closer" exchange (MD) and one to represent a -"less close" exchange (MF). The difficulty is that the presence of one -RR type in a cache doesn't convey any information about the other -because the query which acquired the cached information might have used -a QTYPE of MF, MD, or MAILA (which matched both). The redesigned - - - -Mockapetris [Page 24] - -RFC 1035 Domain Implementation and Specification November 1987 - - -service used a single type (MX) with a "preference" value in the RDATA -section which can order different RRs. However, if any MX RRs are found -in the cache, then all should be there. - -4. MESSAGES - -4.1. Format - -All communications inside of the domain protocol are carried in a single -format called a message. The top level format of message is divided -into 5 sections (some of which are empty in certain cases) shown below: - - +---------------------+ - | Header | - +---------------------+ - | Question | the question for the name server - +---------------------+ - | Answer | RRs answering the question - +---------------------+ - | Authority | RRs pointing toward an authority - +---------------------+ - | Additional | RRs holding additional 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 or a response, a standard query or some -other opcode, etc. - -The names of the sections after the header are derived from their use in -standard queries. 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 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. - - - - - - - - - - - - -Mockapetris [Page 25] - -RFC 1035 Domain Implementation and Specification November 1987 - - -4.1.1. Header section format - -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| Z | 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 - the corresponding reply and can be used by the requester - to match up replies to outstanding queries. - -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) - - 1 an inverse query (IQUERY) - - 2 a server status request (STATUS) - - 3-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 question section. - - Note that the contents of the answer section may have - multiple owner names because of aliases. The AA bit - - - -Mockapetris [Page 26] - -RFC 1035 Domain Implementation and Specification November 1987 - - - corresponds to the name which matches the query name, or - the first owner name in the answer section. - -TC TrunCation - specifies that this message was truncated - due to length greater than that permitted on the - transmission channel. - -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. - -Z Reserved for future use. Must be zero in all queries - and responses. - -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. - - 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 requester, - or a name server may not wish to perform - a particular operation (e.g., zone - - - -Mockapetris [Page 27] - -RFC 1035 Domain Implementation and Specification November 1987 - - - 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. - -4.1.2. Question section format - -The question section is used to carry the "question" in most queries, -i.e., the parameters that define what is being asked. The section -contains QDCOUNT (usually 1) entries, each of 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 domain name represented as a sequence of labels, where - each label consists of a length octet followed by that - number of octets. The domain name terminates with the - zero length octet for the null label of the root. 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. - - - -Mockapetris [Page 28] - -RFC 1035 Domain Implementation and Specification November 1987 - - -QCLASS a two octet code that specifies the class of the query. - For example, the QCLASS field is IN for the Internet. - -4.1.3. 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 domain name to which this resource record pertains. - -TYPE two octets containing one of the RR type codes. 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 32 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. - - - - - -Mockapetris [Page 29] - -RFC 1035 Domain Implementation and Specification November 1987 - - -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. - -4.1.4. Message compression - -In order to reduce the size of messages, the domain system utilizes a -compression scheme which eliminates the repetition of domain names in a -message. In this scheme, an entire domain name or a list of labels at -the end of a domain name is replaced with a pointer to a prior occurance -of the same name. - -The pointer takes the form of a two octet sequence: - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | 1 1| OFFSET | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -The first two bits are ones. This allows a pointer to be distinguished -from a label, since the label must begin with two zero bits because -labels are restricted to 63 octets or less. (The 10 and 01 combinations -are reserved for future use.) The OFFSET field specifies an offset from -the start of the message (i.e., the first octet of the ID field in the -domain header). A zero offset specifies the first byte of the ID field, -etc. - -The compression scheme allows a domain name in a message to be -represented as either: - - - a sequence of labels ending in a zero octet - - - a pointer - - - a sequence of labels ending with a pointer - -Pointers can only be used for occurances of a domain name where the -format is not class specific. If this were not the case, a name server -or resolver would be required to know the format of all RRs it handled. -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 - - - -Mockapetris [Page 30] - -RFC 1035 Domain Implementation and Specification November 1987 - - -used, the length of the compressed name is used in the length -calculation, rather than the length of the expanded name. - -Programs are free to avoid using pointers in messages they generate, -although this will reduce datagram capacity, and may cause truncation. -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: - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 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 pointer relies on -ARPA being the last label in the string at 20. The root domain name is - - - -Mockapetris [Page 31] - -RFC 1035 Domain Implementation and Specification November 1987 - - -defined by a single octet of zeros at 92; the root domain name has no -labels. - -4.2. Transport - -The DNS assumes that messages will be transmitted as datagrams or in a -byte stream carried by a virtual circuit. While virtual circuits can be -used for any DNS activity, datagrams are preferred for queries due to -their lower overhead and better performance. Zone refresh activities -must use virtual circuits because of the need for reliable transfer. - -The Internet supports name server access using TCP [RFC-793] on server -port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP -port 53 (decimal). - -4.2.1. UDP usage - -Messages sent using UDP user server port 53 (decimal). - -Messages carried by UDP are restricted to 512 bytes (not counting the IP -or UDP headers). Longer messages are truncated and the TC bit is set in -the header. - -UDP is not acceptable for zone transfers, but is the recommended method -for standard queries in the Internet. Queries sent using UDP may be -lost, and hence a retransmission strategy is required. Queries or their -responses may be reordered by the network, or by processing in name -servers, so resolvers should not depend on them being returned in order. - -The optimal UDP retransmission policy will vary with performance of the -Internet and the needs of the client, but the following are recommended: - - - The client should try other servers and server addresses - before repeating a query to a specific address of a server. - - - The retransmission interval should be based on prior - statistics if possible. Too aggressive retransmission can - easily slow responses for the community at large. Depending - on how well connected the client is to its expected servers, - the minimum retransmission interval should be 2-5 seconds. - -More suggestions on server selection and retransmission policy can be -found in the resolver section of this memo. - -4.2.2. TCP usage - -Messages sent over TCP connections use server port 53 (decimal). The -message is prefixed with a two byte length field which gives the message - - - -Mockapetris [Page 32] - -RFC 1035 Domain Implementation and Specification November 1987 - - -length, excluding the two byte length field. This length field allows -the low-level processing to assemble a complete message before beginning -to parse it. - -Several connection management policies are recommended: - - - The server should not block other activities waiting for TCP - data. - - - The server should support multiple connections. - - - The server should assume that the client will initiate - connection closing, and should delay closing its end of the - connection until all outstanding client requests have been - satisfied. - - - If the server needs to close a dormant connection to reclaim - resources, it should wait until the connection has been idle - for a period on the order of two minutes. In particular, the - server should allow the SOA and AXFR request sequence (which - begins a refresh operation) to be made on a single connection. - Since the server would be unable to answer queries anyway, a - unilateral close or reset may be used instead of a graceful - close. - -5. MASTER FILES - -Master files are text files that contain RRs in text form. Since the -contents of a zone can be expressed in the form of a list of RRs a -master file is most often used to define a zone, though it can be used -to list a cache's contents. Hence, this section first discusses the -format of RRs in a master file, and then the special considerations when -a master file is used to create a zone in some name server. - -5.1. Format - -The format of these files is a sequence of entries. Entries are -predominantly line-oriented, though parentheses can be used to continue -a list of items across a line boundary, and text literals can contain -CRLF within the text. Any combination of tabs and spaces act as a -delimiter between the separate items that make up an entry. The end of -any line in the master file can end with a comment. The comment starts -with a ";" (semicolon). - -The following entries are defined: - - <blank>[<comment>] - - - - -Mockapetris [Page 33] - -RFC 1035 Domain Implementation and Specification November 1987 - - - $ORIGIN <domain-name> [<comment>] - - $INCLUDE <file-name> [<domain-name>] [<comment>] - - <domain-name><rr> [<comment>] - - <blank><rr> [<comment>] - -Blank lines, with or without comments, are allowed anywhere in the file. - -Two control entries are defined: $ORIGIN and $INCLUDE. $ORIGIN is -followed by a domain name, and resets the current origin for relative -domain names to the stated name. $INCLUDE inserts the named file into -the current file, and may optionally specify a domain name that sets the -relative domain name origin for the included file. $INCLUDE may also -have a comment. Note that a $INCLUDE entry never changes the relative -origin of the parent file, regardless of changes to the relative origin -made within the included file. - -The last two forms represent RRs. If an entry for an RR begins with a -blank, then the RR is assumed to be owned by the last stated owner. If -an RR entry begins with a <domain-name>, then the owner name is reset. - -<rr> contents take one of the following forms: - - [<TTL>] [<class>] <type> <RDATA> - - [<class>] [<TTL>] <type> <RDATA> - -The RR begins with optional TTL and class fields, followed by a type and -RDATA field appropriate to the type and class. Class and type use the -standard mnemonics, TTL is a decimal integer. Omitted class and TTL -values are default to the last explicitly stated values. Since type and -class mnemonics are disjoint, the parse is unique. (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.) - -<domain-name>s make up a large share of the data in the master file. -The labels in the domain name are expressed as character strings and -separated by dots. Quoting conventions allow arbitrary characters to be -stored in domain names. Domain names that end in a dot are called -absolute, and are taken as complete. Domain names which do not end in a -dot are called relative; the actual domain name is the concatenation of -the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as -an argument to the master file loading routine. A relative name is an -error when no origin is available. - - - - - -Mockapetris [Page 34] - -RFC 1035 Domain Implementation and Specification November 1987 - - -<character-string> is expressed in one or two ways: as a contiguous set -of characters without interior spaces, or as a string beginning with a " -and ending with a ". Inside a " delimited string any character can -occur, except for a " itself, which must be quoted using \ (back slash). - -Because these files are text files several special encodings are -necessary to allow arbitrary data to be loaded. In particular: - - of the root. - -@ A free standing @ is used to denote the current origin. - -\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. - -5.2. Use of master files to define zones - -When a master file is used to load a zone, the operation should be -suppressed if any errors are encountered in the master file. The -rationale for this is that a single error can have widespread -consequences. For example, suppose that the RRs defining a delegation -have syntax errors; then the server will return authoritative name -errors for all names in the subzone (except in the case where the -subzone is also present on the server). - -Several other validity checks that should be performed in addition to -insuring that the file is syntactically correct: - - 1. All RRs in the file should have the same class. - - 2. Exactly one SOA RR should be present at the top of the zone. - - 3. If delegations are present and glue information is required, - it should be present. - - - -Mockapetris [Page 35] - -RFC 1035 Domain Implementation and Specification November 1987 - - - 4. Information present outside of the authoritative nodes in the - zone should be glue information, rather than the result of an - origin or similar error. - -5.3. Master file example - -The following is an example file which might be used to define the -ISI.EDU zone.and is loaded with an origin of ISI.EDU: - -@ IN SOA VENERA Action\.domains ( - 20 ; SERIAL - 7200 ; REFRESH - 600 ; RETRY - 3600000; EXPIRE - 60) ; MINIMUM - - NS A.ISI.EDU. - NS VENERA - NS VAXA - MX 10 VENERA - MX 20 VAXA - -A A 26.3.0.103 - -VENERA A 10.1.0.52 - A 128.9.0.32 - -VAXA A 10.2.0.27 - A 128.9.0.33 - - -$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT - -Where the file <SUBSYS>ISI-MAILBOXES.TXT is: - - MOE MB A.ISI.EDU. - LARRY MB A.ISI.EDU. - CURLEY MB A.ISI.EDU. - STOOGES MG MOE - MG LARRY - MG CURLEY - -Note the use of the \ character in the SOA RR to specify the responsible -person mailbox "Action.domains@E.ISI.EDU". - - - - - - - -Mockapetris [Page 36] - -RFC 1035 Domain Implementation and Specification November 1987 - - -6. NAME SERVER IMPLEMENTATION - -6.1. Architecture - -The optimal structure for the name server will depend on the host -operating system and whether the name server is integrated with resolver -operations, either by supporting recursive service, or by sharing its -database with a resolver. This section discusses implementation -considerations for a name server which shares a database with a -resolver, but most of these concerns are present in any name server. - -6.1.1. Control - -A name server must employ multiple concurrent activities, whether they -are implemented as separate tasks in the host's OS or multiplexing -inside a single name server program. It is simply not acceptable for a -name server to block the service of UDP requests while it waits for TCP -data for refreshing or query activities. Similarly, a name server -should not attempt to provide recursive service without processing such -requests in parallel, though it may choose to serialize requests from a -single client, or to regard identical requests from the same client as -duplicates. A name server should not substantially delay requests while -it reloads a zone from master files or while it incorporates a newly -refreshed zone into its database. - -6.1.2. Database - -While name server implementations are free to use any internal data -structures they choose, the suggested structure consists of three major -parts: - - - A "catalog" data structure which lists the zones available to - this server, and a "pointer" to the zone data structure. The - main purpose of this structure is to find the nearest ancestor - zone, if any, for arriving standard queries. - - - Separate data structures for each of the zones held by the - name server. - - - A data structure for cached data. (or perhaps separate caches - for different classes) - -All of these data structures can be implemented an identical tree -structure format, with different data chained off the nodes in different -parts: in the catalog the data is pointers to zones, while in the zone -and cache data structures, the data will be RRs. In designing the tree -framework the designer should recognize that query processing will need -to traverse the tree using case-insensitive label comparisons; and that - - - -Mockapetris [Page 37] - -RFC 1035 Domain Implementation and Specification November 1987 - - -in real data, a few nodes have a very high branching factor (100-1000 or -more), but the vast majority have a very low branching factor (0-1). - -One way to solve the case problem is to store the labels for each node -in two pieces: a standardized-case representation of the label where all -ASCII characters are in a single case, together with a bit mask that -denotes which characters are actually of a different case. The -branching factor diversity can be handled using a simple linked list for -a node until the branching factor exceeds some threshold, and -transitioning to a hash structure after the threshold is exceeded. In -any case, hash structures used to store tree sections must insure that -hash functions and procedures preserve the casing conventions of the -DNS. - -The use of separate structures for the different parts of the database -is motivated by several factors: - - - The catalog structure can be an almost static structure that - need change only when the system administrator changes the - zones supported by the server. This structure can also be - used to store parameters used to control refreshing - activities. - - - The individual data structures for zones allow a zone to be - replaced simply by changing a pointer in the catalog. Zone - refresh operations can build a new structure and, when - complete, splice it into the database via a simple pointer - replacement. It is very important that when a zone is - refreshed, queries should not use old and new data - simultaneously. - - - With the proper search procedures, authoritative data in zones - will always "hide", and hence take precedence over, cached - data. - - - Errors in zone definitions that cause overlapping zones, etc., - may cause erroneous responses to queries, but problem - determination is simplified, and the contents of one "bad" - zone can't corrupt another. - - - Since the cache is most frequently updated, it is most - vulnerable to corruption during system restarts. It can also - become full of expired RR data. In either case, it can easily - be discarded without disturbing zone data. - -A major aspect of database design is selecting a structure which allows -the name server to deal with crashes of the name server's host. State -information which a name server should save across system crashes - - - -Mockapetris [Page 38] - -RFC 1035 Domain Implementation and Specification November 1987 - - -includes the catalog structure (including the state of refreshing for -each zone) and the zone data itself. - -6.1.3. Time - -Both the TTL data for RRs and the timing data for refreshing activities -depends on 32 bit timers in units of seconds. Inside the database, -refresh timers and TTLs for cached data conceptually "count down", while -data in the zone stays with constant TTLs. - -A recommended implementation strategy is to store time in two ways: as -a relative increment and as an absolute time. One way to do this is to -use positive 32 bit numbers for one type and negative numbers for the -other. The RRs in zones use relative times; the refresh timers and -cache data use absolute times. Absolute numbers are taken with respect -to some known origin and converted to relative values when placed in the -response to a query. When an absolute TTL is negative after conversion -to relative, then the data is expired and should be ignored. - -6.2. Standard query processing - -The major algorithm for standard query processing is presented in -[RFC-1034]. - -When processing queries with QCLASS=*, or some other QCLASS which -matches multiple classes, the response should never be authoritative -unless the server can guarantee that the response covers all classes. - -When composing a response, RRs which are to be inserted in the -additional section, but duplicate RRs in the answer or authority -sections, may be omitted from the additional section. - -When a response is so long that truncation is required, the truncation -should start at the end of the response and work forward in the -datagram. Thus if there is any data for the authority section, the -answer section is guaranteed to be unique. - -The MINIMUM value in the SOA should be used to set a floor on the TTL of -data distributed from a zone. This floor function should be done when -the data is copied into a response. This will allow future dynamic -update protocols to change the SOA MINIMUM field without ambiguous -semantics. - -6.3. Zone refresh and reload processing - -In spite of a server's best efforts, it may be unable to load zone data -from a master file due to syntax errors, etc., or be unable to refresh a -zone within the its expiration parameter. In this case, the name server - - - -Mockapetris [Page 39] - -RFC 1035 Domain Implementation and Specification November 1987 - - -should answer queries as if it were not supposed to possess the zone. - -If a master is sending a zone out via AXFR, and a new version is created -during the transfer, the master should continue to send the old version -if possible. In any case, it should never send part of one version and -part of another. If completion is not possible, the master should reset -the connection on which the zone transfer is taking place. - -6.4. Inverse queries (Optional) - -Inverse queries are an optional part of the DNS. Name servers are not -required to support any form of inverse queries. 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. - -6.4.1. 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 queries take the form of a single RR in the answer section of -the message, with an empty question section. The owner name of the -query RR and its TTL are not significant. The response carries -questions in the question section which identify all names possessing -the query RR WHICH THE NAME SERVER KNOWS. Since no name server knows -about all of the domain name space, the response can never be assumed to -be complete. Thus inverse queries are primarily useful for database -management and debugging activities. Inverse queries are NOT an -acceptable method of mapping host addresses to host names; use the IN- -ADDR.ARPA domain instead. - -Where possible, name servers should provide case-insensitive comparisons -for inverse queries. Thus an inverse query asking for an MX RR of -"Venera.isi.edu" should get the same response as a query for -"VENERA.ISI.EDU"; an inverse query for HINFO RR "IBM-PC UNIX" should -produce the same result as an inverse query for "IBM-pc unix". However, -this cannot be guaranteed because name servers may possess RRs that -contain character strings but the name server does not know that the -data is character. - -When a name server processes an inverse query, it either returns: - - 1. zero, one, or multiple domain names for the specified - resource as QNAMEs in the question section - - - -Mockapetris [Page 40] - -RFC 1035 Domain Implementation and Specification November 1987 - - - 2. an error code indicating that the name server doesn't support - inverse mapping of the specified resource type. - -When the response to an inverse query contains one or more QNAMEs, the -owner name and TTL of the RR in the answer section which defines the -inverse query is modified to exactly match an RR found at the first -QNAME. - -RRs returned in the inverse queries cannot be cached using the same -mechanism as is used for the replies to standard queries. One reason -for this is that a name might have multiple RRs of the same type, and -only one would appear. For example, an inverse query for a single -address of a multiply homed host might create the impression that only -one address existed. - -6.4.2. Inverse query and response example The overall structure -of an inverse query for retrieving the domain name that corresponds to -Internet address 10.1.0.52 is shown below: - - +-----------------------------------------+ - Header | OPCODE=IQUERY, ID=997 | - +-----------------------------------------+ - Question | <empty> | - +-----------------------------------------+ - Answer | <anyname> A IN 10.1.0.52 | - +-----------------------------------------+ - Authority | <empty> | - +-----------------------------------------+ - Additional | <empty> | - +-----------------------------------------+ - -This query asks for a question whose answer is the Internet style -address 10.1.0.52. Since the owner name is not known, any domain name -can be used as a placeholder (and is ignored). A single octet of zero, -signifying the root, is usually used because it minimizes the length of -the message. The TTL of the RR is not significant. The response to -this query might be: - - - - - - - - - - - - - - -Mockapetris [Page 41] - -RFC 1035 Domain Implementation and Specification November 1987 - - - +-----------------------------------------+ - Header | OPCODE=RESPONSE, ID=997 | - +-----------------------------------------+ - Question |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU | - +-----------------------------------------+ - Answer | VENERA.ISI.EDU A IN 10.1.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. If the question section in the response is not empty, then the -RR in the answer section is modified to correspond to be an exact copy -of an RR at the first QNAME. - -6.4.3. 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 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. - -6.5. Completion queries and responses - -The optional completion services described in RFC-882 and RFC-883 have -been deleted. Redesigned services may become available in the future. - - - - - - - - - - - - - -Mockapetris [Page 42] - -RFC 1035 Domain Implementation and Specification November 1987 - - -7. RESOLVER IMPLEMENTATION - -The top levels of the recommended resolver algorithm are discussed in -[RFC-1034]. This section discusses implementation details assuming the -database structure suggested in the name server implementation section -of this memo. - -7.1. Transforming a user request into a query - -The first step a resolver takes is to transform the client's request, -stated in a format suitable to the local OS, into a search specification -for RRs at a specific name which match a specific QTYPE and QCLASS. -Where possible, the QTYPE and QCLASS should correspond to a single type -and a single class, because this makes the use of cached data much -simpler. The reason for this is that the presence of data of one type -in a cache doesn't confirm the existence or non-existence of data of -other types, hence the only way to be sure is to consult an -authoritative source. If QCLASS=* is used, then authoritative answers -won't be available. - -Since a resolver must be able to multiplex multiple requests if it is to -perform its function efficiently, each pending request is usually -represented in some block of state information. This state block will -typically contain: - - - A timestamp indicating the time the request began. - The timestamp is used to decide whether RRs in the database - can be used or are out of date. This timestamp uses the - absolute time format previously discussed for RR storage in - zones and caches. Note that when an RRs TTL indicates a - relative time, the RR must be timely, since it is part of a - zone. When the RR has an absolute time, it is part of a - cache, and the TTL of the RR is compared against the timestamp - for the start of the request. - - Note that using the timestamp is superior to using a current - time, since it allows RRs with TTLs of zero to be entered in - the cache in the usual manner, but still used by the current - request, even after intervals of many seconds due to system - load, query retransmission timeouts, etc. - - - Some sort of parameters to limit the amount of work which will - be performed for this request. - - The amount of work which a resolver will do in response to a - client request must be limited to guard against errors in the - database, such as circular CNAME references, and operational - problems, such as network partition which prevents the - - - -Mockapetris [Page 43] - -RFC 1035 Domain Implementation and Specification November 1987 - - - resolver from accessing the name servers it needs. While - local limits on the number of times a resolver will retransmit - a particular query to a particular name server address are - essential, the resolver should have a global per-request - counter to limit work on a single request. The counter should - be set to some initial value and decremented whenever the - resolver performs any action (retransmission timeout, - retransmission, etc.) If the counter passes zero, the request - is terminated with a temporary error. - - Note that if the resolver structure allows one request to - start others in parallel, such as when the need to access a - name server for one request causes a parallel resolve for the - name server's addresses, the spawned request should be started - with a lower counter. This prevents circular references in - the database from starting a chain reaction of resolver - activity. - - - The SLIST data structure discussed in [RFC-1034]. - - This structure keeps track of the state of a request if it - must wait for answers from foreign name servers. - -7.2. Sending the queries - -As described in [RFC-1034], the basic task of the resolver is to -formulate a query which will answer the client's request and direct that -query to name servers which can provide the information. The resolver -will usually only have very strong hints about which servers to ask, in -the form of NS RRs, and may have to revise the query, in response to -CNAMEs, or revise the set of name servers the resolver is asking, in -response to delegation responses which point the resolver to name -servers closer to the desired information. In addition to the -information requested by the client, the resolver may have to call upon -its own services to determine the address of name servers it wishes to -contact. - -In any case, the model used in this memo assumes that the resolver is -multiplexing attention between multiple requests, some from the client, -and some internally generated. Each request is represented by some -state information, and the desired behavior is that the resolver -transmit queries to name servers in a way that maximizes the probability -that the request is answered, minimizes the time that the request takes, -and avoids excessive transmissions. The key algorithm uses the state -information of the request to select the next name server address to -query, and also computes a timeout which will cause the next action -should a response not arrive. The next action will usually be a -transmission to some other server, but may be a temporary error to the - - - -Mockapetris [Page 44] - -RFC 1035 Domain Implementation and Specification November 1987 - - -client. - -The resolver always starts with a list of server names to query (SLIST). -This list will be all NS RRs which correspond to the nearest ancestor -zone that the resolver knows about. To avoid startup problems, the -resolver should have a set of default servers which it will ask should -it have no current NS RRs which are appropriate. The resolver then adds -to SLIST all of the known addresses for the name servers, and may start -parallel requests to acquire the addresses of the servers when the -resolver has the name, but no addresses, for the name servers. - -To complete initialization of SLIST, the resolver attaches whatever -history information it has to the each address in SLIST. This will -usually consist of some sort of weighted averages for the response time -of the address, and the batting average of the address (i.e., how often -the address responded at all to the request). Note that this -information should be kept on a per address basis, rather than on a per -name server basis, because the response time and batting average of a -particular server may vary considerably from address to address. Note -also that this information is actually specific to a resolver address / -server address pair, so a resolver with multiple addresses may wish to -keep separate histories for each of its addresses. Part of this step -must deal with addresses which have no such history; in this case an -expected round trip time of 5-10 seconds should be the worst case, with -lower estimates for the same local network, etc. - -Note that whenever a delegation is followed, the resolver algorithm -reinitializes SLIST. - -The information establishes a partial ranking of the available name -server addresses. Each time an address is chosen and the state should -be altered to prevent its selection again until all other addresses have -been tried. The timeout for each transmission should be 50-100% greater -than the average predicted value to allow for variance in response. - -Some fine points: - - - The resolver may encounter a situation where no addresses are - available for any of the name servers named in SLIST, and - where the servers in the list are precisely those which would - normally be used to look up their own addresses. This - situation typically occurs when the glue address RRs have a - smaller TTL than the NS RRs marking delegation, or when the - resolver caches the result of a NS search. The resolver - should detect this condition and restart the search at the - next ancestor zone, or alternatively at the root. - - - - - -Mockapetris [Page 45] - -RFC 1035 Domain Implementation and Specification November 1987 - - - - If a resolver gets a server error or other bizarre response - from a name server, it should remove it from SLIST, and may - wish to schedule an immediate transmission to the next - candidate server address. - -7.3. Processing responses - -The first step in processing arriving response datagrams is to parse the -response. This procedure should include: - - - Check the header for reasonableness. Discard datagrams which - are queries when responses are expected. - - - Parse the sections of the message, and insure that all RRs are - correctly formatted. - - - As an optional step, check the TTLs of arriving data looking - for RRs with excessively long TTLs. If a RR has an - excessively long TTL, say greater than 1 week, either discard - the whole response, or limit all TTLs in the response to 1 - week. - -The next step is to match the response to a current resolver request. -The recommended strategy is to do a preliminary matching using the ID -field in the domain header, and then to verify that the question section -corresponds to the information currently desired. This requires that -the transmission algorithm devote several bits of the domain ID field to -a request identifier of some sort. This step has several fine points: - - - Some name servers send their responses from different - addresses than the one used to receive the query. That is, a - resolver cannot rely that a response will come from the same - address which it sent the corresponding query to. This name - server bug is typically encountered in UNIX systems. - - - If the resolver retransmits a particular request to a name - server it should be able to use a response from any of the - transmissions. However, if it is using the response to sample - the round trip time to access the name server, it must be able - to determine which transmission matches the response (and keep - transmission times for each outgoing message), or only - calculate round trip times based on initial transmissions. - - - A name server will occasionally not have a current copy of a - zone which it should have according to some NS RRs. The - resolver should simply remove the name server from the current - SLIST, and continue. - - - - -Mockapetris [Page 46] - -RFC 1035 Domain Implementation and Specification November 1987 - - -7.4. Using the cache - -In general, we expect a resolver to cache all data which it receives in -responses since it may be useful in answering future client requests. -However, there are several types of data which should not be cached: - - - When several RRs of the same type are available for a - particular owner name, the resolver should either cache them - all or none at all. When a response is truncated, and a - resolver doesn't know whether it has a complete set, it should - not cache a possibly partial set of RRs. - - - Cached data should never be used in preference to - authoritative data, so if caching would cause this to happen - the data should not be cached. - - - The results of an inverse query should not be cached. - - - The results of standard queries where the QNAME contains "*" - labels if the data might be used to construct wildcards. The - reason is that the cache does not necessarily contain existing - RRs or zone boundary information which is necessary to - restrict the application of the wildcard RRs. - - - RR data in responses of dubious reliability. When a resolver - receives unsolicited responses or RR data other than that - requested, it should discard it without caching it. The basic - implication is that all sanity checks on a packet should be - performed before any of it is cached. - -In a similar vein, when a resolver has a set of RRs for some name in a -response, and wants to cache the RRs, it should check its cache for -already existing RRs. Depending on the circumstances, either the data -in the response or the cache is preferred, but the two should never be -combined. If the data in the response is from authoritative data in the -answer section, it is always preferred. - -8. MAIL SUPPORT - -The domain system defines a standard for mapping mailboxes into domain -names, and two methods for using the mailbox information to derive mail -routing information. The first method is called mail exchange binding -and the other method is mailbox binding. The mailbox encoding standard -and mail exchange binding are part of the DNS official protocol, and are -the recommended method for mail routing in the Internet. Mailbox -binding is an experimental feature which is still under development and -subject to change. - - - - -Mockapetris [Page 47] - -RFC 1035 Domain Implementation and Specification November 1987 - - -The mailbox encoding standard assumes a mailbox name of the form -"<local-part>@<mail-domain>". While the syntax allowed in each of these -sections varies substantially between the various mail internets, the -preferred syntax for the ARPA Internet is given in [RFC-822]. - -The DNS encodes the <local-part> as a single label, and encodes the -<mail-domain> as a domain name. The single label from the <local-part> -is prefaced to the domain name from <mail-domain> to form the domain -name corresponding to the mailbox. Thus the mailbox HOSTMASTER@SRI- -NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA. If the -<local-part> contains dots or other special characters, its -representation in a master file will require the use of backslash -quoting to ensure that the domain name is properly encoded. For -example, the mailbox Action.domains@ISI.EDU would be represented as -Action\.domains.ISI.EDU. - -8.1. Mail exchange binding - -Mail exchange binding uses the <mail-domain> part of a mailbox -specification to determine where mail should be sent. The <local-part> -is not even consulted. [RFC-974] specifies this method in detail, and -should be consulted before attempting to use mail exchange support. - -One of the advantages of this method is that it decouples mail -destination naming from the hosts used to support mail service, at the -cost of another layer of indirection in the lookup function. However, -the addition layer should eliminate the need for complicated "%", "!", -etc encodings in <local-part>. - -The essence of the method is that the <mail-domain> is used as a domain -name to locate type MX RRs which list hosts willing to accept mail for -<mail-domain>, together with preference values which rank the hosts -according to an order specified by the administrators for <mail-domain>. - -In this memo, the <mail-domain> ISI.EDU is used in examples, together -with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for -ISI.EDU. If a mailer had a message for Mockapetris@ISI.EDU, it would -route it by looking up MX RRs for ISI.EDU. The MX RRs at ISI.EDU name -VENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host -addresses. - -8.2. Mailbox binding (Experimental) - -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: - - - -Mockapetris [Page 48] - -RFC 1035 Domain Implementation and Specification November 1987 - - - 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 exchange 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., b,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 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. - - - -Mockapetris [Page 49] - -RFC 1035 Domain Implementation and Specification November 1987 - - -New fields may be added to this RR in the future. - - -9. REFERENCES and BIBLIOGRAPHY - -[Dyer 87] S. Dyer, F. Hsu, "Hesiod", Project Athena - Technical Plan - Name Service, April 1987, version 1.9. - - Describes the fundamentals of the Hesiod name service. - -[IEN-116] J. Postel, "Internet Name Server", IEN-116, - USC/Information Sciences Institute, August 1979. - - A name service obsoleted by the Domain Name System, but - still in use. - -[Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks", - Communications of the ACM, October 1986, volume 29, number - 10. - -[RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network - Information Center, SRI International, December 1977. - -[RFC-768] J. Postel, "User Datagram Protocol", RFC-768, - USC/Information Sciences Institute, August 1980. - -[RFC-793] J. Postel, "Transmission Control Protocol", RFC-793, - USC/Information Sciences Institute, September 1981. - -[RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT, - September 1981. - - Suggests introduction of a hierarchy in place of a flat - name space for the Internet. - -[RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805, - USC/Information Sciences Institute, February 1982. - -[RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD - Internet Host Table Specification", RFC-810, Network - Information Center, SRI International, March 1982. - - Obsolete. See RFC-952. - -[RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames - Server", RFC-811, Network Information Center, SRI - International, March 1982. - - - - -Mockapetris [Page 50] - -RFC 1035 Domain Implementation and Specification November 1987 - - - Obsolete. See RFC-953. - -[RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812, - Network Information Center, SRI International, March - 1982. - -[RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for - Internet User Applications", RFC-819, Network - Information Center, SRI International, August 1982. - - Early thoughts on the design of the domain system. - Current implementation is completely different. - -[RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821, - USC/Information Sciences Institute, August 1980. - -[RFC-830] Z. Su, "A Distributed System for Internet Name Service", - RFC-830, Network Information Center, SRI International, - October 1982. - - Early thoughts on the design of the domain system. - Current implementation is completely different. - -[RFC-882] P. Mockapetris, "Domain names - Concepts and - Facilities," RFC-882, USC/Information Sciences - Institute, November 1983. - - Superceeded by this memo. - -[RFC-883] P. Mockapetris, "Domain names - Implementation and - Specification," RFC-883, USC/Information Sciences - Institute, November 1983. - - Superceeded by this memo. - -[RFC-920] J. Postel and J. Reynolds, "Domain Requirements", - RFC-920, USC/Information Sciences Institute, - October 1984. - - Explains the naming scheme for top level domains. - -[RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host - Table Specification", RFC-952, SRI, October 1985. - - Specifies the format of HOSTS.TXT, the host/address - table replaced by the DNS. - - - - - -Mockapetris [Page 51] - -RFC 1035 Domain Implementation and Specification November 1987 - - -[RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server", - RFC-953, SRI, October 1985. - - This RFC contains the official specification of the - hostname server protocol, which is obsoleted by the DNS. - This TCP based protocol accesses information stored in - the RFC-952 format, and is used to obtain copies of the - host table. - -[RFC-973] P. Mockapetris, "Domain System Changes and - Observations", RFC-973, USC/Information Sciences - Institute, January 1986. - - Describes changes to RFC-882 and RFC-883 and reasons for - them. - -[RFC-974] C. Partridge, "Mail routing and the domain system", - RFC-974, CSNET CIC BBN Labs, January 1986. - - Describes the transition from HOSTS.TXT based mail - addressing to the more powerful MX system used with the - domain system. - -[RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS - service on a TCP/UDP transport: Concepts and Methods", - RFC-1001, March 1987. - - This RFC and RFC-1002 are a preliminary design for - NETBIOS on top of TCP/IP which proposes to base NetBIOS - name service on top of the DNS. - -[RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS - service on a TCP/UDP transport: Detailed - Specifications", RFC-1002, March 1987. - -[RFC-1010] J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010, - USC/Information Sciences Institute, May 1987. - - Contains socket numbers and mnemonics for host names, - operating systems, etc. - -[RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031, - November 1987. - - Describes a plan for converting the MILNET to the DNS. - -[RFC-1032] M. Stahl, "Establishing a Domain - Guidelines for - Administrators", RFC-1032, November 1987. - - - -Mockapetris [Page 52] - -RFC 1035 Domain Implementation and Specification November 1987 - - - Describes the registration policies used by the NIC to - administer the top level domains and delegate subzones. - -[RFC-1033] M. Lottor, "Domain Administrators Operations Guide", - RFC-1033, November 1987. - - A cookbook for domain administrators. - -[Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET - Name Server", Computer Networks, vol 6, nr 3, July 1982. - - Describes a name service for CSNET which is independent - from the DNS and DNS use in the CSNET. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Mockapetris [Page 53] - -RFC 1035 Domain Implementation and Specification November 1987 - - -Index - - * 13 - - ; 33, 35 - - <character-string> 35 - <domain-name> 34 - - @ 35 - - \ 35 - - A 12 - - Byte order 8 - - CH 13 - Character case 9 - CLASS 11 - CNAME 12 - Completion 42 - CS 13 - - Hesiod 13 - HINFO 12 - HS 13 - - IN 13 - IN-ADDR.ARPA domain 22 - Inverse queries 40 - - Mailbox names 47 - MB 12 - MD 12 - MF 12 - MG 12 - MINFO 12 - MINIMUM 20 - MR 12 - MX 12 - - NS 12 - NULL 12 - - Port numbers 32 - Primary server 5 - PTR 12, 18 - - - -Mockapetris [Page 54] - -RFC 1035 Domain Implementation and Specification November 1987 - - - QCLASS 13 - QTYPE 12 - - RDATA 12 - RDLENGTH 11 - - Secondary server 5 - SOA 12 - Stub resolvers 7 - - TCP 32 - TXT 12 - TYPE 11 - - UDP 32 - - WKS 12 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Mockapetris [Page 55] - diff --git a/contrib/bind9/doc/rfc/rfc1101.txt b/contrib/bind9/doc/rfc/rfc1101.txt deleted file mode 100644 index 66c9d8b813b3..000000000000 --- a/contrib/bind9/doc/rfc/rfc1101.txt +++ /dev/null @@ -1,787 +0,0 @@ - - - - - - -Network Working Group P. Mockapetris -Request for Comments: 1101 ISI -Updates: RFCs 1034, 1035 April 1989 - - - DNS Encoding of Network Names and Other Types - - -1. STATUS OF THIS MEMO - - This RFC proposes two extensions to the Domain Name System: - - - A specific method for entering and retrieving RRs which map - between network names and numbers. - - - Ideas for a general method for describing mappings between - arbitrary identifiers and numbers. - - The method for mapping between network names and addresses is a - proposed standard, the ideas for a general method are experimental. - - This RFC assumes that the reader is familiar with the DNS [RFC 1034, - RFC 1035] and its use. The data shown is for pedagogical use and - does not necessarily reflect the real Internet. - - Distribution of this memo is unlimited. - -2. INTRODUCTION - - The DNS is extensible and can be used for a virtually unlimited - number of data types, name spaces, etc. New type definitions are - occasionally necessary as are revisions or deletions of old types - (e.g., MX replacement of MD and MF [RFC 974]), and changes described - in [RFC 973]. This RFC describes changes due to the general need to - map between identifiers and values, and a specific need for network - name support. - - Users wish to be able to use the DNS to map between network names and - numbers. This need is the only capability found in HOSTS.TXT which - is not available from the DNS. In designing a method to do this, - there were two major areas of concern: - - - Several tradeoffs involving control of network names, the - syntax of network names, backward compatibility, etc. - - - A desire to create a method which would be sufficiently - general to set a good precedent for future mappings, - for example, between TCP-port names and numbers, - - - -Mockapetris [Page 1] - -RFC 1101 DNS Encoding of Network Names and Other Types April 1989 - - - autonomous system names and numbers, X.500 Relative - Distinguished Names (RDNs) and their servers, or whatever. - - It was impossible to reconcile these two areas of concern for network - names because of the desire to unify network number support within - existing IP address to host name support. The existing support is - the IN-ADDR.ARPA section of the DNS name space. As a result this RFC - describes one structure for network names which builds on the - existing support for host names, and another family of structures for - future yellow pages (YP) functions such as conversions between TCP- - port numbers and mnemonics. - - Both structures are described in following sections. Each structure - has a discussion of design issues and specific structure - recommendations. - - We wish to avoid defining structures and methods which can work but - do not because of indifference or errors on the part of system - administrators when maintaining the database. The WKS RR is an - example. Thus, while we favor distribution as a general method, we - also recognize that centrally maintained tables (such as HOSTS.TXT) - are usually more consistent though less maintainable and timely. - Hence we recommend both specific methods for mapping network names, - addresses, and subnets, as well as an instance of the general method - for mapping between allocated network numbers and network names. - (Allocation is centrally performed by the SRI Network Information - Center, aka the NIC). - -3. NETWORK NAME ISSUES AND DISCUSSION - - The issues involved in the design were the definition of network name - syntax, the mappings to be provided, and possible support for similar - functions at the subnet level. - -3.1. Network name syntax - - The current syntax for network names, as defined by [RFC 952] is an - alphanumeric string of up to 24 characters, which begins with an - alpha, and may include "." and "-" except as first and last - characters. This is the format which was also used for host names - before the DNS. Upward compatibility with existing names might be a - goal of any new scheme. - - However, the present syntax has been used to define a flat name - space, and hence would prohibit the same distributed name allocation - method used for host names. There is some sentiment for allowing the - NIC to continue to allocate and regulate network names, much as it - allocates numbers, but the majority opinion favors local control of - - - -Mockapetris [Page 2] - -RFC 1101 DNS Encoding of Network Names and Other Types April 1989 - - - network names. Although it would be possible to provide a flat space - or a name space in which, for example, the last label of a domain - name captured the old-style network name, any such approach would add - complexity to the method and create different rules for network names - and host names. - - For these reasons, we assume that the syntax of network names will be - the same as the expanded syntax for host names permitted in [HR]. - The new syntax expands the set of names to allow leading digits, so - long as the resulting representations do not conflict with IP - addresses in decimal octet form. For example, 3Com.COM and 3M.COM - are now legal, although 26.0.0.73.COM is not. See [HR] for details. - - The price is that network names will get as complicated as host - names. An administrator will be able to create network names in any - domain under his control, and also create network number to name - entries in IN-ADDR.ARPA domains under his control. Thus, the name - for the ARPANET might become NET.ARPA, ARPANET.ARPA or Arpa- - network.MIL., depending on the preferences of the owner. - -3.2. Mappings - - The desired mappings, ranked by priority with most important first, - are: - - - Mapping a IP address or network number to a network name. - - This mapping is for use in debugging tools and status displays - of various sorts. The conversion from IP address to network - number is well known for class A, B, and C IP addresses, and - involves a simple mask operation. The needs of other classes - are not yet defined and are ignored for the rest of this RFC. - - - Mapping a network name to a network address. - - This facility is of less obvious application, but a - symmetrical mapping seems desirable. - - - Mapping an organization to its network names and numbers. - - This facility is useful because it may not always be possible - to guess the local choice for network names, but the - organization name is often well known. - - - Similar mappings for subnets, even when nested. - - The primary application is to be able to identify all of the - subnets involved in a particular IP address. A secondary - - - -Mockapetris [Page 3] - -RFC 1101 DNS Encoding of Network Names and Other Types April 1989 - - - requirement is to retrieve address mask information. - -3.3. Network address section of the name space - - The network name syntax discussed above can provide domain names - which will contain mappings from network names to various quantities, - but we also need a section of the name space, organized by network - and subnet number to hold the inverse mappings. - - The choices include: - - - The same network number slots already assigned and delegated - in the IN-ADDR.ARPA section of the name space. - - For example, 10.IN-ADDR.ARPA for class A net 10, - 2.128.IN-ADDR.ARPA for class B net 128.2, etc. - - - Host-zero addresses in the IN-ADDR.ARPA tree. (A host field - of all zero in an IP address is prohibited because of - confusion related to broadcast addresses, et al.) - - For example, 0.0.0.10.IN-ADDR.ARPA for class A net 10, - 0.0.2.128.IN-ADDR.arpa for class B net 128.2, etc. Like the - first scheme, it uses in-place name space delegations to - distribute control. - - The main advantage of this scheme over the first is that it - allows convenient names for subnets as well as networks. A - secondary advantage is that it uses names which are not in use - already, and hence it is possible to test whether an - organization has entered this information in its domain - database. - - - Some new section of the name space. - - While this option provides the most opportunities, it creates - a need to delegate a whole new name space. Since the IP - address space is so closely related to the network number - space, most believe that the overhead of creating such a new - space is overwhelming and would lead to the WKS syndrome. (As - of February, 1989, approximately 400 sections of the - IN-ADDR.ARPA tree are already delegated, usually at network - boundaries.) - - - - - - - - -Mockapetris [Page 4] - -RFC 1101 DNS Encoding of Network Names and Other Types April 1989 - - -4. SPECIFICS FOR NETWORK NAME MAPPINGS - - The proposed solution uses information stored at: - - - Names in the IN-ADDR.ARPA tree that correspond to host-zero IP - addresses. The same method is used for subnets in a nested - fashion. For example, 0.0.0.10.IN-ADDR.ARPA. for net 10. - - Two types of information are stored here: PTR RRs which point - to the network name in their data sections, and A RRs, which - are present if the network (or subnet) is subnetted further. - If a type A RR is present, then it has the address mask as its - data. The general form is: - - <reversed-host-zero-number>.IN-ADDR.ARPA. PTR <network-name> - <reversed-host-zero-number>.IN-ADDR.ARPA. A <subnet-mask> - - For example: - - 0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA. - - or - - 0.0.2.128.IN-ADDR.ARPA. PTR cmu-net.cmu.edu. - A 255.255.255.0 - - In general, this information will be added to an existing - master file for some IN-ADDR.ARPA domain for each network - involved. Similar RRs can be used at host-zero subnet - entries. - - - Names which are network names. - - The data stored here is PTR RRs pointing at the host-zero - entries. The general form is: - - <network-name> ptr <reversed-host-zero-number>.IN-ADDR.ARPA - - For example: - - ARPANET.ARPA. PTR 0.0.0.10.IN-ADDR.ARPA. - - or - - isi-net.isi.edu. PTR 0.0.9.128.IN-ADDR.ARPA. - - In general, this information will be inserted in the master - file for the domain name of the organization; this is a - - - -Mockapetris [Page 5] - -RFC 1101 DNS Encoding of Network Names and Other Types April 1989 - - - different file from that which holds the information below - IN-ADDR.ARPA. Similar PTR RRs can be used at subnet names. - - - Names corresponding to organizations. - - The data here is one or more PTR RRs pointing at the - IN-ADDR.ARPA names corresponding to host-zero entries for - networks. - - For example: - - ISI.EDU. PTR 0.0.9.128.IN-ADDR.ARPA. - - MCC.COM. PTR 0.167.5.192.IN-ADDR.ARPA. - PTR 0.168.5.192.IN-ADDR.ARPA. - PTR 0.169.5.192.IN-ADDR.ARPA. - PTR 0.0.62.128.IN-ADDR.ARPA. - -4.1. A simple example - - The ARPANET is a Class A network without subnets. The RRs which - would be added, assuming the ARPANET.ARPA was selected as a network - name, would be: - - ARPA. PTR 0.0.0.10.IN-ADDR.ARPA. - - ARPANET.ARPA. PTR 0.0.0.10.IN-ADDR.ARPA. - - 0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA. - - The first RR states that the organization named ARPA owns net 10 (It - might also own more network numbers, and these would be represented - with an additional RR per net.) The second states that the network - name ARPANET.ARPA. maps to net 10. The last states that net 10 is - named ARPANET.ARPA. - - Note that all of the usual host and corresponding IN-ADDR.ARPA - entries would still be required. - -4.2. A complicated, subnetted example - - The ISI network is 128.9, a class B number. Suppose the ISI network - was organized into two levels of subnet, with the first level using - an additional 8 bits of address, and the second level using 4 bits, - for address masks of x'FFFFFF00' and X'FFFFFFF0'. - - Then the following RRs would be entered in ISI's master file for the - ISI.EDU zone: - - - -Mockapetris [Page 6] - -RFC 1101 DNS Encoding of Network Names and Other Types April 1989 - - - ; Define network entry - isi-net.isi.edu. PTR 0.0.9.128.IN-ADDR.ARPA. - - ; Define first level subnets - div1-subnet.isi.edu. PTR 0.1.9.128.IN-ADDR.ARPA. - div2-subnet.isi.edu. PTR 0.2.9.128.IN-ADDR.ARPA. - - ; Define second level subnets - inc-subsubnet.isi.edu. PTR 16.2.9.128.IN-ADDR.ARPA. - - in the 9.128.IN-ADDR.ARPA zone: - - ; Define network number and address mask - 0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu. - A 255.255.255.0 ;aka X'FFFFFF00' - - ; Define one of the first level subnet numbers and masks - 0.1.9.128.IN-ADDR.ARPA. PTR div1-subnet.isi.edu. - A 255.255.255.240 ;aka X'FFFFFFF0' - - ; Define another first level subnet number and mask - 0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu. - A 255.255.255.240 ;aka X'FFFFFFF0' - - ; Define second level subnet number - 16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu. - - This assumes that the ISI network is named isi-net.isi.edu., first - level subnets are named div1-subnet.isi.edu. and div2- - subnet.isi.edu., and a second level subnet is called inc- - subsubnet.isi.edu. (In a real system as complicated as this there - would be more first and second level subnets defined, but we have - shown enough to illustrate the ideas.) - -4.3. Procedure for using an IP address to get network name - - Depending on whether the IP address is class A, B, or C, mask off the - high one, two, or three bytes, respectively. Reverse the octets, - suffix IN-ADDR.ARPA, and do a PTR query. - - For example, suppose the IP address is 10.0.0.51. - - 1. Since this is a class A address, use a mask x'FF000000' and - get 10.0.0.0. - - 2. Construct the name 0.0.0.10.IN-ADDR.ARPA. - - 3. Do a PTR query. Get back - - - -Mockapetris [Page 7] - -RFC 1101 DNS Encoding of Network Names and Other Types April 1989 - - - 0.0.0.10.IN-ADDR.ARPA. PTR ARPANET.ARPA. - - 4. Conclude that the network name is "ARPANET.ARPA." - - Suppose that the IP address is 128.9.2.17. - - 1. Since this is a class B address, use a mask of x'FFFF0000' - and get 128.9.0.0. - - 2. Construct the name 0.0.9.128.IN-ADDR.ARPA. - - 3. Do a PTR query. Get back - - 0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu - - 4. Conclude that the network name is "isi-net.isi.edu." - -4.4. Procedure for finding all subnets involved with an IP address - - This is a simple extension of the IP address to network name method. - When the network entry is located, do a lookup for a possible A RR. - If the A RR is found, look up the next level of subnet using the - original IP address and the mask in the A RR. Repeat this procedure - until no A RR is found. - - For example, repeating the use of 128.9.2.17. - - 1. As before construct a query for 0.0.9.128.IN-ADDR.ARPA. - Retrieve: - - 0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu. - A 255.255.255.0 - - 2. Since an A RR was found, repeat using mask from RR - (255.255.255.0), constructing a query for - 0.2.9.128.IN-ADDR.ARPA. Retrieve: - - 0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu. - A 255.255.255.240 - - 3. Since another A RR was found, repeat using mask - 255.255.255.240 (x'FFFFFFF0'). constructing a query for - 16.2.9.128.IN-ADDR.ARPA. Retrieve: - - 16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu. - - 4. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there - are no more subnet levels. - - - -Mockapetris [Page 8] - -RFC 1101 DNS Encoding of Network Names and Other Types April 1989 - - -5. YP ISSUES AND DISCUSSION - - The term "Yellow Pages" is used in almost as many ways as the term - "domain", so it is useful to define what is meant herein by YP. The - general problem to be solved is to create a method for creating - mappings from one kind of identifier to another, often with an - inverse capability. The traditional methods are to search or use a - precomputed index of some kind. - - Searching is impractical when the search is too large, and - precomputed indexes are possible only when it is possible to specify - search criteria in advance, and pay for the resources necessary to - build the index. For example, it is impractical to search the entire - domain tree to find a particular address RR, so we build the IN- - ADDR.ARPA YP. Similarly, we could never build an Internet-wide index - of "hosts with a load average of less than 2" in less time than it - would take for the data to change, so indexes are a useless approach - for that problem. - - Such a precomputed index is what we mean by YP, and we regard the - IN-ADDR.ARPA domain as the first instance of a YP in the DNS. - Although a single, centrally-managed YP for well-known values such as - TCP-port is desirable, we regard organization-specific YPs for, say, - locally defined TCP ports as a natural extension, as are combinations - of YPs using search lists to merge the two. - - In examining Internet Numbers [RFC 997] and Assigned Numbers [RFC - 1010], it is clear that there are several mappings which might be of - value. For example: - - <assigned-network-name> <==> <IP-address> - <autonomous-system-id> <==> <number> - <protocol-id> <==> <number> - <port-id> <==> <number> - <ethernet-type> <==> <number> - <public-data-net> <==> <IP-address> - - Following the IN-ADDR example, the YP takes the form of a domain tree - organized to optimize retrieval by search key and distribution via - normal DNS rules. The name used as a key must include: - - 1. A well known origin. For example, IN-ADDR.ARPA is the - current IP-address to host name YP. - - 2. A "from" data type. This identifies the input type of the - mapping. This is necessary because we may be mapping - something as anonymous as a number to any number of - mnemonics, etc. - - - -Mockapetris [Page 9] - -RFC 1101 DNS Encoding of Network Names and Other Types April 1989 - - - 3. A "to" data type. Since we assume several symmetrical - mnemonic <==> number mappings, this is also necessary. - - This ordering reflects the natural scoping of control, and hence the - order of the components in a domain name. Thus domain names would be - of the form: - - <from-value>.<to-data-type>.<from-data-type>.<YP-origin> - - To make this work, we need to define well-know strings for each of - these metavariables, as well as encoding rules for converting a - <from-value> into a domain name. We might define: - - <YP-origin> :=YP - <from-data-type>:=TCP-port | IN-ADDR | Number | - Assigned-network-number | Name - <to-data-type> :=<from-data-type> - - Note that "YP" is NOT a valid country code under [ISO 3166] (although - we may want to worry about the future), and the existence of a - syntactically valid <to-data-type>.<from-data-type> pair does not - imply that a meaningful mapping exists, or is even possible. - - The encoding rules might be: - - TCP-port Six character alphanumeric - - IN-ADDR Reversed 4-octet decimal string - - Number decimal integer - - Assigned-network-number - Reversed 4-octet decimal string - - Name Domain name - -6. SPECIFICS FOR YP MAPPINGS - -6.1. TCP-PORT - - $origin Number.TCP-port.YP. - - 23 PTR TELNET.TCP-port.Number.YP. - 25 PTR SMTP.TCP-port.Number.YP. - - $origin TCP-port.Number.YP. - - TELNET PTR 23.Number.TCP-port.YP. - - - -Mockapetris [Page 10] - -RFC 1101 DNS Encoding of Network Names and Other Types April 1989 - - - SMTP PTR 25.Number.TCP-port.YP. - - Thus the mapping between 23 and TELNET is represented by a pair of - PTR RRs, one for each direction of the mapping. - -6.2. Assigned networks - - Network numbers are assigned by the NIC and reported in "Internet - Numbers" RFCs. To create a YP, the NIC would set up two domains: - - Name.Assigned-network-number.YP and Assigned-network-number.YP - - The first would contain entries of the form: - - $origin Name.Assigned-network-number.YP. - - 0.0.0.4 PTR SATNET.Assigned-network-number.Name.YP. - 0.0.0.10 PTR ARPANET.Assigned-network-number.Name.YP. - - The second would contain entries of the form: - - $origin Assigned-network-number.Name.YP. - - SATNET. PTR 0.0.0.4.Name.Assigned-network-number.YP. - ARPANET. PTR 0.0.0.10.Name.Assigned-network-number.YP. - - These YPs are not in conflict with the network name support described - in the first half of this RFC since they map between ASSIGNED network - names and numbers, not those allocated by the organizations - themselves. That is, they document the NIC's decisions about - allocating network numbers but do not automatically track any - renaming performed by the new owners. - - As a practical matter, we might want to create both of these domains - to enable users on the Internet to experiment with centrally - maintained support as well as the distributed version, or might want - to implement only the allocated number to name mapping and request - organizations to convert their allocated network names to the network - names described in the distributed model. - -6.3. Operational improvements - - We could imagine that all conversion routines using these YPs might - be instructed to use "YP.<local-domain>" followed by "YP." as a - search list. Thus, if the organization ISI.EDU wished to define - locally meaningful TCP-PORT, it would define the domains: - - <TCP-port.Number.YP.ISI.EDU> and <Number.TCP-port.YP.ISI.EDU>. - - - -Mockapetris [Page 11] - -RFC 1101 DNS Encoding of Network Names and Other Types April 1989 - - - We could add another level of indirection in the YP lookup, defining - the <to-data-type>.<from-data-type>.<YP-origin> nodes to point to the - YP tree, rather than being the YP tree directly. This would enable - entries of the form: - - IN-ADDR.Netname.YP. PTR IN-ADDR.ARPA. - - to splice in YPs from other origins or existing spaces. - - Another possibility would be to shorten the RDATA section of the RRs - which map back and forth by deleting the origin. This could be done - either by allowing the domain name in the RDATA portion to not - identify a real domain name, or by defining a new RR which used a - simple text string rather than a domain name. - - Thus, we might replace - - $origin Assigned-network-number.Name.YP. - - SATNET. PTR 0.0.0.4.Name.Assigned-network-number.YP. - ARPANET. PTR 0.0.0.10.Name.Assigned-network-number.YP. - - with - - $origin Assigned-network-number.Name.YP. - - SATNET. PTR 0.0.0.4. - ARPANET. PTR 0.0.0.10. - - or - - $origin Assigned-network-number.Name.YP. - - SATNET. PTT "0.0.0.4" - ARPANET. PTT "0.0.0.10" - - where PTT is a new type whose RDATA section is a text string. - -7. ACKNOWLEDGMENTS - - Drew Perkins, Mark Lottor, and Rob Austein contributed several of the - ideas in this RFC. Numerous contributions, criticisms, and - compromises were produced in the IETF Domain working group and the - NAMEDROPPERS mailing list. - - - - - - - -Mockapetris [Page 12] - -RFC 1101 DNS Encoding of Network Names and Other Types April 1989 - - -8. REFERENCES - - [HR] Braden, B., editor, "Requirements for Internet Hosts", - RFC in preparation. - - [ISO 3166] ISO, "Codes for the Representation of Names of - Countries", 1981. - - [RFC 882] Mockapetris, P., "Domain names - Concepts and - Facilities", RFC 882, USC/Information Sciences Institute, - November 1983. - - Superseded by RFC 1034. - - [RFC 883] Mockapetris, P.,"Domain names - Implementation and - Specification", RFC 883, USC/Information Sciences - Institute, November 1983. - - Superceeded by RFC 1035. - - [RFC 920] Postel, J. and J. Reynolds, "Domain Requirements", RFC - 920, October 1984. - - Explains the naming scheme for top level domains. - - [RFC 952] Harrenstien, K., M. Stahl, and E. Feinler, "DoD Internet - Host Table Specification", RFC 952, SRI, October 1985. - - Specifies the format of HOSTS.TXT, the host/address table - replaced by the DNS - - [RFC 973] Mockapetris, P., "Domain System Changes and - Observations", RFC 973, USC/Information Sciences - Institute, January 1986. - - Describes changes to RFCs 882 and 883 and reasons for - them. - - [RFC 974] Partridge, C., "Mail routing and the domain system", RFC - 974, CSNET CIC BBN Labs, January 1986. - - Describes the transition from HOSTS.TXT based mail - addressing to the more powerful MX system used with the - domain system. - - - - - - - -Mockapetris [Page 13] - -RFC 1101 DNS Encoding of Network Names and Other Types April 1989 - - - [RFC 997] Reynolds, J., and J. Postel, "Internet Numbers", RFC 997, - USC/Information Sciences Institute, March 1987 - - Contains network numbers, autonomous system numbers, etc. - - [RFC 1010] Reynolds, J., and J. Postel, "Assigned Numbers", RFC - 1010, USC/Information Sciences Institute, May 1987 - - Contains socket numbers and mnemonics for host names, - operating systems, etc. - - - [RFC 1034] Mockapetris, P., "Domain names - Concepts and - Facilities", RFC 1034, USC/Information Sciences - Institute, November 1987. - - Introduction/overview of the DNS. - - [RFC 1035] Mockapetris, P., "Domain names - Implementation and - Specification", RFC 1035, USC/Information Sciences - Institute, November 1987. - - DNS implementation instructions. - -Author's Address: - - Paul Mockapetris - USC/Information Sciences Institute - 4676 Admiralty Way - Marina del Rey, CA 90292 - - Phone: (213) 822-1511 - - Email: PVM@ISI.EDU - - - - - - - - - - - - - - - - - -Mockapetris [Page 14] -
\ No newline at end of file diff --git a/contrib/bind9/doc/rfc/rfc1122.txt b/contrib/bind9/doc/rfc/rfc1122.txt deleted file mode 100644 index c14f2e50a319..000000000000 --- a/contrib/bind9/doc/rfc/rfc1122.txt +++ /dev/null @@ -1,6844 +0,0 @@ - - - - - - -Network Working Group Internet Engineering Task Force -Request for Comments: 1122 R. Braden, Editor - October 1989 - - - Requirements for Internet Hosts -- Communication Layers - - -Status of This Memo - - This RFC is an official specification for the Internet community. It - incorporates by reference, amends, corrects, and supplements the - primary protocol standards documents relating to hosts. Distribution - of this document is unlimited. - -Summary - - This is one RFC of a pair that defines and discusses the requirements - for Internet host software. This RFC covers the communications - protocol layers: link layer, IP layer, and transport layer; its - companion RFC-1123 covers the application and support protocols. - - - - Table of Contents - - - - - 1. INTRODUCTION ............................................... 5 - 1.1 The Internet Architecture .............................. 6 - 1.1.1 Internet Hosts .................................... 6 - 1.1.2 Architectural Assumptions ......................... 7 - 1.1.3 Internet Protocol Suite ........................... 8 - 1.1.4 Embedded Gateway Code ............................. 10 - 1.2 General Considerations ................................. 12 - 1.2.1 Continuing Internet Evolution ..................... 12 - 1.2.2 Robustness Principle .............................. 12 - 1.2.3 Error Logging ..................................... 13 - 1.2.4 Configuration ..................................... 14 - 1.3 Reading this Document .................................. 15 - 1.3.1 Organization ...................................... 15 - 1.3.2 Requirements ...................................... 16 - 1.3.3 Terminology ....................................... 17 - 1.4 Acknowledgments ........................................ 20 - - 2. LINK LAYER .................................................. 21 - 2.1 INTRODUCTION ........................................... 21 - - - -Internet Engineering Task Force [Page 1] - - - - -RFC1122 INTRODUCTION October 1989 - - - 2.2 PROTOCOL WALK-THROUGH .................................. 21 - 2.3 SPECIFIC ISSUES ........................................ 21 - 2.3.1 Trailer Protocol Negotiation ...................... 21 - 2.3.2 Address Resolution Protocol -- ARP ................ 22 - 2.3.2.1 ARP Cache Validation ......................... 22 - 2.3.2.2 ARP Packet Queue ............................. 24 - 2.3.3 Ethernet and IEEE 802 Encapsulation ............... 24 - 2.4 LINK/INTERNET LAYER INTERFACE .......................... 25 - 2.5 LINK LAYER REQUIREMENTS SUMMARY ........................ 26 - - 3. INTERNET LAYER PROTOCOLS .................................... 27 - 3.1 INTRODUCTION ............................................ 27 - 3.2 PROTOCOL WALK-THROUGH .................................. 29 - 3.2.1 Internet Protocol -- IP ............................ 29 - 3.2.1.1 Version Number ............................... 29 - 3.2.1.2 Checksum ..................................... 29 - 3.2.1.3 Addressing ................................... 29 - 3.2.1.4 Fragmentation and Reassembly ................. 32 - 3.2.1.5 Identification ............................... 32 - 3.2.1.6 Type-of-Service .............................. 33 - 3.2.1.7 Time-to-Live ................................. 34 - 3.2.1.8 Options ...................................... 35 - 3.2.2 Internet Control Message Protocol -- ICMP .......... 38 - 3.2.2.1 Destination Unreachable ...................... 39 - 3.2.2.2 Redirect ..................................... 40 - 3.2.2.3 Source Quench ................................ 41 - 3.2.2.4 Time Exceeded ................................ 41 - 3.2.2.5 Parameter Problem ............................ 42 - 3.2.2.6 Echo Request/Reply ........................... 42 - 3.2.2.7 Information Request/Reply .................... 43 - 3.2.2.8 Timestamp and Timestamp Reply ................ 43 - 3.2.2.9 Address Mask Request/Reply ................... 45 - 3.2.3 Internet Group Management Protocol IGMP ........... 47 - 3.3 SPECIFIC ISSUES ........................................ 47 - 3.3.1 Routing Outbound Datagrams ........................ 47 - 3.3.1.1 Local/Remote Decision ........................ 47 - 3.3.1.2 Gateway Selection ............................ 48 - 3.3.1.3 Route Cache .................................. 49 - 3.3.1.4 Dead Gateway Detection ....................... 51 - 3.3.1.5 New Gateway Selection ........................ 55 - 3.3.1.6 Initialization ............................... 56 - 3.3.2 Reassembly ........................................ 56 - 3.3.3 Fragmentation ..................................... 58 - 3.3.4 Local Multihoming ................................. 60 - 3.3.4.1 Introduction ................................. 60 - 3.3.4.2 Multihoming Requirements ..................... 61 - 3.3.4.3 Choosing a Source Address .................... 64 - 3.3.5 Source Route Forwarding ........................... 65 - - - -Internet Engineering Task Force [Page 2] - - - - -RFC1122 INTRODUCTION October 1989 - - - 3.3.6 Broadcasts ........................................ 66 - 3.3.7 IP Multicasting ................................... 67 - 3.3.8 Error Reporting ................................... 69 - 3.4 INTERNET/TRANSPORT LAYER INTERFACE ..................... 69 - 3.5 INTERNET LAYER REQUIREMENTS SUMMARY .................... 72 - - 4. TRANSPORT PROTOCOLS ......................................... 77 - 4.1 USER DATAGRAM PROTOCOL -- UDP .......................... 77 - 4.1.1 INTRODUCTION ...................................... 77 - 4.1.2 PROTOCOL WALK-THROUGH ............................. 77 - 4.1.3 SPECIFIC ISSUES ................................... 77 - 4.1.3.1 Ports ........................................ 77 - 4.1.3.2 IP Options ................................... 77 - 4.1.3.3 ICMP Messages ................................ 78 - 4.1.3.4 UDP Checksums ................................ 78 - 4.1.3.5 UDP Multihoming .............................. 79 - 4.1.3.6 Invalid Addresses ............................ 79 - 4.1.4 UDP/APPLICATION LAYER INTERFACE ................... 79 - 4.1.5 UDP REQUIREMENTS SUMMARY .......................... 80 - 4.2 TRANSMISSION CONTROL PROTOCOL -- TCP ................... 82 - 4.2.1 INTRODUCTION ...................................... 82 - 4.2.2 PROTOCOL WALK-THROUGH ............................. 82 - 4.2.2.1 Well-Known Ports ............................. 82 - 4.2.2.2 Use of Push .................................. 82 - 4.2.2.3 Window Size .................................. 83 - 4.2.2.4 Urgent Pointer ............................... 84 - 4.2.2.5 TCP Options .................................. 85 - 4.2.2.6 Maximum Segment Size Option .................. 85 - 4.2.2.7 TCP Checksum ................................. 86 - 4.2.2.8 TCP Connection State Diagram ................. 86 - 4.2.2.9 Initial Sequence Number Selection ............ 87 - 4.2.2.10 Simultaneous Open Attempts .................. 87 - 4.2.2.11 Recovery from Old Duplicate SYN ............. 87 - 4.2.2.12 RST Segment ................................. 87 - 4.2.2.13 Closing a Connection ........................ 87 - 4.2.2.14 Data Communication .......................... 89 - 4.2.2.15 Retransmission Timeout ...................... 90 - 4.2.2.16 Managing the Window ......................... 91 - 4.2.2.17 Probing Zero Windows ........................ 92 - 4.2.2.18 Passive OPEN Calls .......................... 92 - 4.2.2.19 Time to Live ................................ 93 - 4.2.2.20 Event Processing ............................ 93 - 4.2.2.21 Acknowledging Queued Segments ............... 94 - 4.2.3 SPECIFIC ISSUES ................................... 95 - 4.2.3.1 Retransmission Timeout Calculation ........... 95 - 4.2.3.2 When to Send an ACK Segment .................. 96 - 4.2.3.3 When to Send a Window Update ................. 97 - 4.2.3.4 When to Send Data ............................ 98 - - - -Internet Engineering Task Force [Page 3] - - - - -RFC1122 INTRODUCTION October 1989 - - - 4.2.3.5 TCP Connection Failures ...................... 100 - 4.2.3.6 TCP Keep-Alives .............................. 101 - 4.2.3.7 TCP Multihoming .............................. 103 - 4.2.3.8 IP Options ................................... 103 - 4.2.3.9 ICMP Messages ................................ 103 - 4.2.3.10 Remote Address Validation ................... 104 - 4.2.3.11 TCP Traffic Patterns ........................ 104 - 4.2.3.12 Efficiency .................................. 105 - 4.2.4 TCP/APPLICATION LAYER INTERFACE ................... 106 - 4.2.4.1 Asynchronous Reports ......................... 106 - 4.2.4.2 Type-of-Service .............................. 107 - 4.2.4.3 Flush Call ................................... 107 - 4.2.4.4 Multihoming .................................. 108 - 4.2.5 TCP REQUIREMENT SUMMARY ........................... 108 - - 5. REFERENCES ................................................. 112 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 4] - - - - -RFC1122 INTRODUCTION October 1989 - - -1. INTRODUCTION - - This document is one of a pair that defines and discusses the - requirements for host system implementations of the Internet protocol - suite. This RFC covers the communication protocol layers: link - layer, IP layer, and transport layer. Its companion RFC, - "Requirements for Internet Hosts -- Application and Support" - [INTRO:1], covers the application layer protocols. This document - should also be read in conjunction with "Requirements for Internet - Gateways" [INTRO:2]. - - These documents are intended to provide guidance for vendors, - implementors, and users of Internet communication software. They - represent the consensus of a large body of technical experience and - wisdom, contributed by the members of the Internet research and - vendor communities. - - This RFC enumerates standard protocols that a host connected to the - Internet must use, and it incorporates by reference the RFCs and - other documents describing the current specifications for these - protocols. It corrects errors in the referenced documents and adds - additional discussion and guidance for an implementor. - - For each protocol, this document also contains an explicit set of - requirements, recommendations, and options. The reader must - understand that the list of requirements in this document is - incomplete by itself; the complete set of requirements for an - Internet host is primarily defined in the standard protocol - specification documents, with the corrections, amendments, and - supplements contained in this RFC. - - A good-faith implementation of the protocols that was produced after - careful reading of the RFC's and with some interaction with the - Internet technical community, and that followed good communications - software engineering practices, should differ from the requirements - of this document in only minor ways. Thus, in many cases, the - "requirements" in this RFC are already stated or implied in the - standard protocol documents, so that their inclusion here is, in a - sense, redundant. However, they were included because some past - implementation has made the wrong choice, causing problems of - interoperability, performance, and/or robustness. - - This document includes discussion and explanation of many of the - requirements and recommendations. A simple list of requirements - would be dangerous, because: - - o Some required features are more important than others, and some - features are optional. - - - -Internet Engineering Task Force [Page 5] - - - - -RFC1122 INTRODUCTION October 1989 - - - o There may be valid reasons why particular vendor products that - are designed for restricted contexts might choose to use - different specifications. - - However, the specifications of this document must be followed to meet - the general goal of arbitrary host interoperation across the - diversity and complexity of the Internet system. Although most - current implementations fail to meet these requirements in various - ways, some minor and some major, this specification is the ideal - towards which we need to move. - - These requirements are based on the current level of Internet - architecture. This document will be updated as required to provide - additional clarifications or to include additional information in - those areas in which specifications are still evolving. - - This introductory section begins with a brief overview of the - Internet architecture as it relates to hosts, and then gives some - general advice to host software vendors. Finally, there is some - guidance on reading the rest of the document and some terminology. - - 1.1 The Internet Architecture - - General background and discussion on the Internet architecture and - supporting protocol suite can be found in the DDN Protocol - Handbook [INTRO:3]; for background see for example [INTRO:9], - [INTRO:10], and [INTRO:11]. Reference [INTRO:5] describes the - procedure for obtaining Internet protocol documents, while - [INTRO:6] contains a list of the numbers assigned within Internet - protocols. - - 1.1.1 Internet Hosts - - A host computer, or simply "host," is the ultimate consumer of - communication services. A host generally executes application - programs on behalf of user(s), employing network and/or - Internet communication services in support of this function. - An Internet host corresponds to the concept of an "End-System" - used in the OSI protocol suite [INTRO:13]. - - An Internet communication system consists of interconnected - packet networks supporting communication among host computers - using the Internet protocols. The networks are interconnected - using packet-switching computers called "gateways" or "IP - routers" by the Internet community, and "Intermediate Systems" - by the OSI world [INTRO:13]. The RFC "Requirements for - Internet Gateways" [INTRO:2] contains the official - specifications for Internet gateways. That RFC together with - - - -Internet Engineering Task Force [Page 6] - - - - -RFC1122 INTRODUCTION October 1989 - - - the present document and its companion [INTRO:1] define the - rules for the current realization of the Internet architecture. - - Internet hosts span a wide range of size, speed, and function. - They range in size from small microprocessors through - workstations to mainframes and supercomputers. In function, - they range from single-purpose hosts (such as terminal servers) - to full-service hosts that support a variety of online network - services, typically including remote login, file transfer, and - electronic mail. - - A host is generally said to be multihomed if it has more than - one interface to the same or to different networks. See - Section 1.1.3 on "Terminology". - - 1.1.2 Architectural Assumptions - - The current Internet architecture is based on a set of - assumptions about the communication system. The assumptions - most relevant to hosts are as follows: - - (a) The Internet is a network of networks. - - Each host is directly connected to some particular - network(s); its connection to the Internet is only - conceptual. Two hosts on the same network communicate - with each other using the same set of protocols that they - would use to communicate with hosts on distant networks. - - (b) Gateways don't keep connection state information. - - To improve robustness of the communication system, - gateways are designed to be stateless, forwarding each IP - datagram independently of other datagrams. As a result, - redundant paths can be exploited to provide robust service - in spite of failures of intervening gateways and networks. - - All state information required for end-to-end flow control - and reliability is implemented in the hosts, in the - transport layer or in application programs. All - connection control information is thus co-located with the - end points of the communication, so it will be lost only - if an end point fails. - - (c) Routing complexity should be in the gateways. - - Routing is a complex and difficult problem, and ought to - be performed by the gateways, not the hosts. An important - - - -Internet Engineering Task Force [Page 7] - - - - -RFC1122 INTRODUCTION October 1989 - - - objective is to insulate host software from changes caused - by the inevitable evolution of the Internet routing - architecture. - - (d) The System must tolerate wide network variation. - - A basic objective of the Internet design is to tolerate a - wide range of network characteristics -- e.g., bandwidth, - delay, packet loss, packet reordering, and maximum packet - size. Another objective is robustness against failure of - individual networks, gateways, and hosts, using whatever - bandwidth is still available. Finally, the goal is full - "open system interconnection": an Internet host must be - able to interoperate robustly and effectively with any - other Internet host, across diverse Internet paths. - - Sometimes host implementors have designed for less - ambitious goals. For example, the LAN environment is - typically much more benign than the Internet as a whole; - LANs have low packet loss and delay and do not reorder - packets. Some vendors have fielded host implementations - that are adequate for a simple LAN environment, but work - badly for general interoperation. The vendor justifies - such a product as being economical within the restricted - LAN market. However, isolated LANs seldom stay isolated - for long; they are soon gatewayed to each other, to - organization-wide internets, and eventually to the global - Internet system. In the end, neither the customer nor the - vendor is served by incomplete or substandard Internet - host software. - - The requirements spelled out in this document are designed - for a full-function Internet host, capable of full - interoperation over an arbitrary Internet path. - - - 1.1.3 Internet Protocol Suite - - To communicate using the Internet system, a host must implement - the layered set of protocols comprising the Internet protocol - suite. A host typically must implement at least one protocol - from each layer. - - The protocol layers used in the Internet architecture are as - follows [INTRO:4]: - - - o Application Layer - - - -Internet Engineering Task Force [Page 8] - - - - -RFC1122 INTRODUCTION October 1989 - - - The application layer is the top layer of the Internet - protocol suite. The Internet suite does not further - subdivide the application layer, although some of the - Internet application layer protocols do contain some - internal sub-layering. The application layer of the - Internet suite essentially combines the functions of the - top two layers -- Presentation and Application -- of the - OSI reference model. - - We distinguish two categories of application layer - protocols: user protocols that provide service directly - to users, and support protocols that provide common system - functions. Requirements for user and support protocols - will be found in the companion RFC [INTRO:1]. - - The most common Internet user protocols are: - - o Telnet (remote login) - o FTP (file transfer) - o SMTP (electronic mail delivery) - - There are a number of other standardized user protocols - [INTRO:4] and many private user protocols. - - Support protocols, used for host name mapping, booting, - and management, include SNMP, BOOTP, RARP, and the Domain - Name System (DNS) protocols. - - - o Transport Layer - - The transport layer provides end-to-end communication - services for applications. There are two primary - transport layer protocols at present: - - o Transmission Control Protocol (TCP) - o User Datagram Protocol (UDP) - - TCP is a reliable connection-oriented transport service - that provides end-to-end reliability, resequencing, and - flow control. UDP is a connectionless ("datagram") - transport service. - - Other transport protocols have been developed by the - research community, and the set of official Internet - transport protocols may be expanded in the future. - - Transport layer protocols are discussed in Chapter 4. - - - -Internet Engineering Task Force [Page 9] - - - - -RFC1122 INTRODUCTION October 1989 - - - o Internet Layer - - All Internet transport protocols use the Internet Protocol - (IP) to carry data from source host to destination host. - IP is a connectionless or datagram internetwork service, - providing no end-to-end delivery guarantees. Thus, IP - datagrams may arrive at the destination host damaged, - duplicated, out of order, or not at all. The layers above - IP are responsible for reliable delivery service when it - is required. The IP protocol includes provision for - addressing, type-of-service specification, fragmentation - and reassembly, and security information. - - The datagram or connectionless nature of the IP protocol - is a fundamental and characteristic feature of the - Internet architecture. Internet IP was the model for the - OSI Connectionless Network Protocol [INTRO:12]. - - ICMP is a control protocol that is considered to be an - integral part of IP, although it is architecturally - layered upon IP, i.e., it uses IP to carry its data end- - to-end just as a transport protocol like TCP or UDP does. - ICMP provides error reporting, congestion reporting, and - first-hop gateway redirection. - - IGMP is an Internet layer protocol used for establishing - dynamic host groups for IP multicasting. - - The Internet layer protocols IP, ICMP, and IGMP are - discussed in Chapter 3. - - - o Link Layer - - To communicate on its directly-connected network, a host - must implement the communication protocol used to - interface to that network. We call this a link layer or - media-access layer protocol. - - There is a wide variety of link layer protocols, - corresponding to the many different types of networks. - See Chapter 2. - - - 1.1.4 Embedded Gateway Code - - Some Internet host software includes embedded gateway - functionality, so that these hosts can forward packets as a - - - -Internet Engineering Task Force [Page 10] - - - - -RFC1122 INTRODUCTION October 1989 - - - gateway would, while still performing the application layer - functions of a host. - - Such dual-purpose systems must follow the Gateway Requirements - RFC [INTRO:2] with respect to their gateway functions, and - must follow the present document with respect to their host - functions. In all overlapping cases, the two specifications - should be in agreement. - - There are varying opinions in the Internet community about - embedded gateway functionality. The main arguments are as - follows: - - o Pro: in a local network environment where networking is - informal, or in isolated internets, it may be convenient - and economical to use existing host systems as gateways. - - There is also an architectural argument for embedded - gateway functionality: multihoming is much more common - than originally foreseen, and multihoming forces a host to - make routing decisions as if it were a gateway. If the - multihomed host contains an embedded gateway, it will - have full routing knowledge and as a result will be able - to make more optimal routing decisions. - - o Con: Gateway algorithms and protocols are still changing, - and they will continue to change as the Internet system - grows larger. Attempting to include a general gateway - function within the host IP layer will force host system - maintainers to track these (more frequent) changes. Also, - a larger pool of gateway implementations will make - coordinating the changes more difficult. Finally, the - complexity of a gateway IP layer is somewhat greater than - that of a host, making the implementation and operation - tasks more complex. - - In addition, the style of operation of some hosts is not - appropriate for providing stable and robust gateway - service. - - There is considerable merit in both of these viewpoints. One - conclusion can be drawn: an host administrator must have - conscious control over whether or not a given host acts as a - gateway. See Section 3.1 for the detailed requirements. - - - - - - - -Internet Engineering Task Force [Page 11] - - - - -RFC1122 INTRODUCTION October 1989 - - - 1.2 General Considerations - - There are two important lessons that vendors of Internet host - software have learned and which a new vendor should consider - seriously. - - 1.2.1 Continuing Internet Evolution - - The enormous growth of the Internet has revealed problems of - management and scaling in a large datagram-based packet - communication system. These problems are being addressed, and - as a result there will be continuing evolution of the - specifications described in this document. These changes will - be carefully planned and controlled, since there is extensive - participation in this planning by the vendors and by the - organizations responsible for operations of the networks. - - Development, evolution, and revision are characteristic of - computer network protocols today, and this situation will - persist for some years. A vendor who develops computer - communication software for the Internet protocol suite (or any - other protocol suite!) and then fails to maintain and update - that software for changing specifications is going to leave a - trail of unhappy customers. The Internet is a large - communication network, and the users are in constant contact - through it. Experience has shown that knowledge of - deficiencies in vendor software propagates quickly through the - Internet technical community. - - 1.2.2 Robustness Principle - - At every layer of the protocols, there is a general rule whose - application can lead to enormous benefits in robustness and - interoperability [IP:1]: - - "Be liberal in what you accept, and - conservative in what you send" - - Software should be written to deal with every conceivable - error, no matter how unlikely; sooner or later a packet will - come in with that particular combination of errors and - attributes, and unless the software is prepared, chaos can - ensue. In general, it is best to assume that the network is - filled with malevolent entities that will send in packets - designed to have the worst possible effect. This assumption - will lead to suitable protective design, although the most - serious problems in the Internet have been caused by - unenvisaged mechanisms triggered by low-probability events; - - - -Internet Engineering Task Force [Page 12] - - - - -RFC1122 INTRODUCTION October 1989 - - - mere human malice would never have taken so devious a course! - - Adaptability to change must be designed into all levels of - Internet host software. As a simple example, consider a - protocol specification that contains an enumeration of values - for a particular header field -- e.g., a type field, a port - number, or an error code; this enumeration must be assumed to - be incomplete. Thus, if a protocol specification defines four - possible error codes, the software must not break when a fifth - code shows up. An undefined code might be logged (see below), - but it must not cause a failure. - - The second part of the principle is almost as important: - software on other hosts may contain deficiencies that make it - unwise to exploit legal but obscure protocol features. It is - unwise to stray far from the obvious and simple, lest untoward - effects result elsewhere. A corollary of this is "watch out - for misbehaving hosts"; host software should be prepared, not - just to survive other misbehaving hosts, but also to cooperate - to limit the amount of disruption such hosts can cause to the - shared communication facility. - - 1.2.3 Error Logging - - The Internet includes a great variety of host and gateway - systems, each implementing many protocols and protocol layers, - and some of these contain bugs and mis-features in their - Internet protocol software. As a result of complexity, - diversity, and distribution of function, the diagnosis of - Internet problems is often very difficult. - - Problem diagnosis will be aided if host implementations include - a carefully designed facility for logging erroneous or - "strange" protocol events. It is important to include as much - diagnostic information as possible when an error is logged. In - particular, it is often useful to record the header(s) of a - packet that caused an error. However, care must be taken to - ensure that error logging does not consume prohibitive amounts - of resources or otherwise interfere with the operation of the - host. - - There is a tendency for abnormal but harmless protocol events - to overflow error logging files; this can be avoided by using a - "circular" log, or by enabling logging only while diagnosing a - known failure. It may be useful to filter and count duplicate - successive messages. One strategy that seems to work well is: - (1) always count abnormalities and make such counts accessible - through the management protocol (see [INTRO:1]); and (2) allow - - - -Internet Engineering Task Force [Page 13] - - - - -RFC1122 INTRODUCTION October 1989 - - - the logging of a great variety of events to be selectively - enabled. For example, it might useful to be able to "log - everything" or to "log everything for host X". - - Note that different managements may have differing policies - about the amount of error logging that they want normally - enabled in a host. Some will say, "if it doesn't hurt me, I - don't want to know about it", while others will want to take a - more watchful and aggressive attitude about detecting and - removing protocol abnormalities. - - 1.2.4 Configuration - - It would be ideal if a host implementation of the Internet - protocol suite could be entirely self-configuring. This would - allow the whole suite to be implemented in ROM or cast into - silicon, it would simplify diskless workstations, and it would - be an immense boon to harried LAN administrators as well as - system vendors. We have not reached this ideal; in fact, we - are not even close. - - At many points in this document, you will find a requirement - that a parameter be a configurable option. There are several - different reasons behind such requirements. In a few cases, - there is current uncertainty or disagreement about the best - value, and it may be necessary to update the recommended value - in the future. In other cases, the value really depends on - external factors -- e.g., the size of the host and the - distribution of its communication load, or the speeds and - topology of nearby networks -- and self-tuning algorithms are - unavailable and may be insufficient. In some cases, - configurability is needed because of administrative - requirements. - - Finally, some configuration options are required to communicate - with obsolete or incorrect implementations of the protocols, - distributed without sources, that unfortunately persist in many - parts of the Internet. To make correct systems coexist with - these faulty systems, administrators often have to "mis- - configure" the correct systems. This problem will correct - itself gradually as the faulty systems are retired, but it - cannot be ignored by vendors. - - When we say that a parameter must be configurable, we do not - intend to require that its value be explicitly read from a - configuration file at every boot time. We recommend that - implementors set up a default for each parameter, so a - configuration file is only necessary to override those defaults - - - -Internet Engineering Task Force [Page 14] - - - - -RFC1122 INTRODUCTION October 1989 - - - that are inappropriate in a particular installation. Thus, the - configurability requirement is an assurance that it will be - POSSIBLE to override the default when necessary, even in a - binary-only or ROM-based product. - - This document requires a particular value for such defaults in - some cases. The choice of default is a sensitive issue when - the configuration item controls the accommodation to existing - faulty systems. If the Internet is to converge successfully to - complete interoperability, the default values built into - implementations must implement the official protocol, not - "mis-configurations" to accommodate faulty implementations. - Although marketing considerations have led some vendors to - choose mis-configuration defaults, we urge vendors to choose - defaults that will conform to the standard. - - Finally, we note that a vendor needs to provide adequate - documentation on all configuration parameters, their limits and - effects. - - - 1.3 Reading this Document - - 1.3.1 Organization - - Protocol layering, which is generally used as an organizing - principle in implementing network software, has also been used - to organize this document. In describing the rules, we assume - that an implementation does strictly mirror the layering of the - protocols. Thus, the following three major sections specify - the requirements for the link layer, the internet layer, and - the transport layer, respectively. A companion RFC [INTRO:1] - covers application level software. This layerist organization - was chosen for simplicity and clarity. - - However, strict layering is an imperfect model, both for the - protocol suite and for recommended implementation approaches. - Protocols in different layers interact in complex and sometimes - subtle ways, and particular functions often involve multiple - layers. There are many design choices in an implementation, - many of which involve creative "breaking" of strict layering. - Every implementor is urged to read references [INTRO:7] and - [INTRO:8]. - - This document describes the conceptual service interface - between layers using a functional ("procedure call") notation, - like that used in the TCP specification [TCP:1]. A host - implementation must support the logical information flow - - - -Internet Engineering Task Force [Page 15] - - - - -RFC1122 INTRODUCTION October 1989 - - - implied by these calls, but need not literally implement the - calls themselves. For example, many implementations reflect - the coupling between the transport layer and the IP layer by - giving them shared access to common data structures. These - data structures, rather than explicit procedure calls, are then - the agency for passing much of the information that is - required. - - In general, each major section of this document is organized - into the following subsections: - - (1) Introduction - - (2) Protocol Walk-Through -- considers the protocol - specification documents section-by-section, correcting - errors, stating requirements that may be ambiguous or - ill-defined, and providing further clarification or - explanation. - - (3) Specific Issues -- discusses protocol design and - implementation issues that were not included in the walk- - through. - - (4) Interfaces -- discusses the service interface to the next - higher layer. - - (5) Summary -- contains a summary of the requirements of the - section. - - - Under many of the individual topics in this document, there is - parenthetical material labeled "DISCUSSION" or - "IMPLEMENTATION". This material is intended to give - clarification and explanation of the preceding requirements - text. It also includes some suggestions on possible future - directions or developments. The implementation material - contains suggested approaches that an implementor may want to - consider. - - The summary sections are intended to be guides and indexes to - the text, but are necessarily cryptic and incomplete. The - summaries should never be used or referenced separately from - the complete RFC. - - 1.3.2 Requirements - - In this document, the words that are used to define the - significance of each particular requirement are capitalized. - - - -Internet Engineering Task Force [Page 16] - - - - -RFC1122 INTRODUCTION October 1989 - - - These words are: - - * "MUST" - - This word or the adjective "REQUIRED" means that the item - is an absolute requirement of the specification. - - * "SHOULD" - - This word or the adjective "RECOMMENDED" means that there - may exist valid reasons in particular circumstances to - ignore this item, but the full implications should be - understood and the case carefully weighed before choosing - a different course. - - * "MAY" - - This word or the adjective "OPTIONAL" means that this item - is truly optional. One vendor may choose to include the - item because a particular marketplace requires it or - because it enhances the product, for example; another - vendor may omit the same item. - - - An implementation is not compliant if it fails to satisfy one - or more of the MUST requirements for the protocols it - implements. An implementation that satisfies all the MUST and - all the SHOULD requirements for its protocols is said to be - "unconditionally compliant"; one that satisfies all the MUST - requirements but not all the SHOULD requirements for its - protocols is said to be "conditionally compliant". - - 1.3.3 Terminology - - This document uses the following technical terms: - - Segment - A segment is the unit of end-to-end transmission in the - TCP protocol. A segment consists of a TCP header followed - by application data. A segment is transmitted by - encapsulation inside an IP datagram. - - Message - In this description of the lower-layer protocols, a - message is the unit of transmission in a transport layer - protocol. In particular, a TCP segment is a message. A - message consists of a transport protocol header followed - by application protocol data. To be transmitted end-to- - - - -Internet Engineering Task Force [Page 17] - - - - -RFC1122 INTRODUCTION October 1989 - - - end through the Internet, a message must be encapsulated - inside a datagram. - - IP Datagram - An IP datagram is the unit of end-to-end transmission in - the IP protocol. An IP datagram consists of an IP header - followed by transport layer data, i.e., of an IP header - followed by a message. - - In the description of the internet layer (Section 3), the - unqualified term "datagram" should be understood to refer - to an IP datagram. - - Packet - A packet is the unit of data passed across the interface - between the internet layer and the link layer. It - includes an IP header and data. A packet may be a - complete IP datagram or a fragment of an IP datagram. - - Frame - A frame is the unit of transmission in a link layer - protocol, and consists of a link-layer header followed by - a packet. - - Connected Network - A network to which a host is interfaced is often known as - the "local network" or the "subnetwork" relative to that - host. However, these terms can cause confusion, and - therefore we use the term "connected network" in this - document. - - Multihomed - A host is said to be multihomed if it has multiple IP - addresses. For a discussion of multihoming, see Section - 3.3.4 below. - - Physical network interface - This is a physical interface to a connected network and - has a (possibly unique) link-layer address. Multiple - physical network interfaces on a single host may share the - same link-layer address, but the address must be unique - for different hosts on the same physical network. - - Logical [network] interface - We define a logical [network] interface to be a logical - path, distinguished by a unique IP address, to a connected - network. See Section 3.3.4. - - - - -Internet Engineering Task Force [Page 18] - - - - -RFC1122 INTRODUCTION October 1989 - - - Specific-destination address - This is the effective destination address of a datagram, - even if it is broadcast or multicast; see Section 3.2.1.3. - - Path - At a given moment, all the IP datagrams from a particular - source host to a particular destination host will - typically traverse the same sequence of gateways. We use - the term "path" for this sequence. Note that a path is - uni-directional; it is not unusual to have different paths - in the two directions between a given host pair. - - MTU - The maximum transmission unit, i.e., the size of the - largest packet that can be transmitted. - - - The terms frame, packet, datagram, message, and segment are - illustrated by the following schematic diagrams: - - A. Transmission on connected network: - _______________________________________________ - | LL hdr | IP hdr | (data) | - |________|________|_____________________________| - - <---------- Frame -----------------------------> - <----------Packet --------------------> - - - B. Before IP fragmentation or after IP reassembly: - ______________________________________ - | IP hdr | transport| Application Data | - |________|____hdr___|__________________| - - <-------- Datagram ------------------> - <-------- Message -----------> - or, for TCP: - ______________________________________ - | IP hdr | TCP hdr | Application Data | - |________|__________|__________________| - - <-------- Datagram ------------------> - <-------- Segment -----------> - - - - - - - - -Internet Engineering Task Force [Page 19] - - - - -RFC1122 INTRODUCTION October 1989 - - - 1.4 Acknowledgments - - This document incorporates contributions and comments from a large - group of Internet protocol experts, including representatives of - university and research labs, vendors, and government agencies. - It was assembled primarily by the Host Requirements Working Group - of the Internet Engineering Task Force (IETF). - - The Editor would especially like to acknowledge the tireless - dedication of the following people, who attended many long - meetings and generated 3 million bytes of electronic mail over the - past 18 months in pursuit of this document: Philip Almquist, Dave - Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve - Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), - John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), - Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge - (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software). - - In addition, the following people made major contributions to the - effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia - (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA), - Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), - John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill - Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul - (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue - Technology), and Mike StJohns (DCA). The following also made - significant contributions to particular areas: Eric Allman - (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic - (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn - (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann - (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun - Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen - (Toronto). - - We are grateful to all, including any contributors who may have - been inadvertently omitted from this list. - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 20] - - - - -RFC1122 LINK LAYER October 1989 - - -2. LINK LAYER - - 2.1 INTRODUCTION - - All Internet systems, both hosts and gateways, have the same - requirements for link layer protocols. These requirements are - given in Chapter 3 of "Requirements for Internet Gateways" - [INTRO:2], augmented with the material in this section. - - 2.2 PROTOCOL WALK-THROUGH - - None. - - 2.3 SPECIFIC ISSUES - - 2.3.1 Trailer Protocol Negotiation - - The trailer protocol [LINK:1] for link-layer encapsulation MAY - be used, but only when it has been verified that both systems - (host or gateway) involved in the link-layer communication - implement trailers. If the system does not dynamically - negotiate use of the trailer protocol on a per-destination - basis, the default configuration MUST disable the protocol. - - DISCUSSION: - The trailer protocol is a link-layer encapsulation - technique that rearranges the data contents of packets - sent on the physical network. In some cases, trailers - improve the throughput of higher layer protocols by - reducing the amount of data copying within the operating - system. Higher layer protocols are unaware of trailer - use, but both the sending and receiving host MUST - understand the protocol if it is used. - - Improper use of trailers can result in very confusing - symptoms. Only packets with specific size attributes are - encapsulated using trailers, and typically only a small - fraction of the packets being exchanged have these - attributes. Thus, if a system using trailers exchanges - packets with a system that does not, some packets - disappear into a black hole while others are delivered - successfully. - - IMPLEMENTATION: - On an Ethernet, packets encapsulated with trailers use a - distinct Ethernet type [LINK:1], and trailer negotiation - is performed at the time that ARP is used to discover the - link-layer address of a destination system. - - - -Internet Engineering Task Force [Page 21] - - - - -RFC1122 LINK LAYER October 1989 - - - Specifically, the ARP exchange is completed in the usual - manner using the normal IP protocol type, but a host that - wants to speak trailers will send an additional "trailer - ARP reply" packet, i.e., an ARP reply that specifies the - trailer encapsulation protocol type but otherwise has the - format of a normal ARP reply. If a host configured to use - trailers receives a trailer ARP reply message from a - remote machine, it can add that machine to the list of - machines that understand trailers, e.g., by marking the - corresponding entry in the ARP cache. - - Hosts wishing to receive trailer encapsulations send - trailer ARP replies whenever they complete exchanges of - normal ARP messages for IP. Thus, a host that received an - ARP request for its IP protocol address would send a - trailer ARP reply in addition to the normal IP ARP reply; - a host that sent the IP ARP request would send a trailer - ARP reply when it received the corresponding IP ARP reply. - In this way, either the requesting or responding host in - an IP ARP exchange may request that it receive trailer - encapsulations. - - This scheme, using extra trailer ARP reply packets rather - than sending an ARP request for the trailer protocol type, - was designed to avoid a continuous exchange of ARP packets - with a misbehaving host that, contrary to any - specification or common sense, responded to an ARP reply - for trailers with another ARP reply for IP. This problem - is avoided by sending a trailer ARP reply in response to - an IP ARP reply only when the IP ARP reply answers an - outstanding request; this is true when the hardware - address for the host is still unknown when the IP ARP - reply is received. A trailer ARP reply may always be sent - along with an IP ARP reply responding to an IP ARP - request. - - 2.3.2 Address Resolution Protocol -- ARP - - 2.3.2.1 ARP Cache Validation - - An implementation of the Address Resolution Protocol (ARP) - [LINK:2] MUST provide a mechanism to flush out-of-date cache - entries. If this mechanism involves a timeout, it SHOULD be - possible to configure the timeout value. - - A mechanism to prevent ARP flooding (repeatedly sending an - ARP Request for the same IP address, at a high rate) MUST be - included. The recommended maximum rate is 1 per second per - - - -Internet Engineering Task Force [Page 22] - - - - -RFC1122 LINK LAYER October 1989 - - - destination. - - DISCUSSION: - The ARP specification [LINK:2] suggests but does not - require a timeout mechanism to invalidate cache entries - when hosts change their Ethernet addresses. The - prevalence of proxy ARP (see Section 2.4 of [INTRO:2]) - has significantly increased the likelihood that cache - entries in hosts will become invalid, and therefore - some ARP-cache invalidation mechanism is now required - for hosts. Even in the absence of proxy ARP, a long- - period cache timeout is useful in order to - automatically correct any bad ARP data that might have - been cached. - - IMPLEMENTATION: - Four mechanisms have been used, sometimes in - combination, to flush out-of-date cache entries. - - (1) Timeout -- Periodically time out cache entries, - even if they are in use. Note that this timeout - should be restarted when the cache entry is - "refreshed" (by observing the source fields, - regardless of target address, of an ARP broadcast - from the system in question). For proxy ARP - situations, the timeout needs to be on the order - of a minute. - - (2) Unicast Poll -- Actively poll the remote host by - periodically sending a point-to-point ARP Request - to it, and delete the entry if no ARP Reply is - received from N successive polls. Again, the - timeout should be on the order of a minute, and - typically N is 2. - - (3) Link-Layer Advice -- If the link-layer driver - detects a delivery problem, flush the - corresponding ARP cache entry. - - (4) Higher-layer Advice -- Provide a call from the - Internet layer to the link layer to indicate a - delivery problem. The effect of this call would - be to invalidate the corresponding cache entry. - This call would be analogous to the - "ADVISE_DELIVPROB()" call from the transport layer - to the Internet layer (see Section 3.4), and in - fact the ADVISE_DELIVPROB routine might in turn - call the link-layer advice routine to invalidate - - - -Internet Engineering Task Force [Page 23] - - - - -RFC1122 LINK LAYER October 1989 - - - the ARP cache entry. - - Approaches (1) and (2) involve ARP cache timeouts on - the order of a minute or less. In the absence of proxy - ARP, a timeout this short could create noticeable - overhead traffic on a very large Ethernet. Therefore, - it may be necessary to configure a host to lengthen the - ARP cache timeout. - - 2.3.2.2 ARP Packet Queue - - The link layer SHOULD save (rather than discard) at least - one (the latest) packet of each set of packets destined to - the same unresolved IP address, and transmit the saved - packet when the address has been resolved. - - DISCUSSION: - Failure to follow this recommendation causes the first - packet of every exchange to be lost. Although higher- - layer protocols can generally cope with packet loss by - retransmission, packet loss does impact performance. - For example, loss of a TCP open request causes the - initial round-trip time estimate to be inflated. UDP- - based applications such as the Domain Name System are - more seriously affected. - - 2.3.3 Ethernet and IEEE 802 Encapsulation - - The IP encapsulation for Ethernets is described in RFC-894 - [LINK:3], while RFC-1042 [LINK:4] describes the IP - encapsulation for IEEE 802 networks. RFC-1042 elaborates and - replaces the discussion in Section 3.4 of [INTRO:2]. - - Every Internet host connected to a 10Mbps Ethernet cable: - - o MUST be able to send and receive packets using RFC-894 - encapsulation; - - o SHOULD be able to receive RFC-1042 packets, intermixed - with RFC-894 packets; and - - o MAY be able to send packets using RFC-1042 encapsulation. - - - An Internet host that implements sending both the RFC-894 and - the RFC-1042 encapsulations MUST provide a configuration switch - to select which is sent, and this switch MUST default to RFC- - 894. - - - -Internet Engineering Task Force [Page 24] - - - - -RFC1122 LINK LAYER October 1989 - - - Note that the standard IP encapsulation in RFC-1042 does not - use the protocol id value (K1=6) that IEEE reserved for IP; - instead, it uses a value (K1=170) that implies an extension - (the "SNAP") which can be used to hold the Ether-Type field. - An Internet system MUST NOT send 802 packets using K1=6. - - Address translation from Internet addresses to link-layer - addresses on Ethernet and IEEE 802 networks MUST be managed by - the Address Resolution Protocol (ARP). - - The MTU for an Ethernet is 1500 and for 802.3 is 1492. - - DISCUSSION: - The IEEE 802.3 specification provides for operation over a - 10Mbps Ethernet cable, in which case Ethernet and IEEE - 802.3 frames can be physically intermixed. A receiver can - distinguish Ethernet and 802.3 frames by the value of the - 802.3 Length field; this two-octet field coincides in the - header with the Ether-Type field of an Ethernet frame. In - particular, the 802.3 Length field must be less than or - equal to 1500, while all valid Ether-Type values are - greater than 1500. - - Another compatibility problem arises with link-layer - broadcasts. A broadcast sent with one framing will not be - seen by hosts that can receive only the other framing. - - The provisions of this section were designed to provide - direct interoperation between 894-capable and 1042-capable - systems on the same cable, to the maximum extent possible. - It is intended to support the present situation where - 894-only systems predominate, while providing an easy - transition to a possible future in which 1042-capable - systems become common. - - Note that 894-only systems cannot interoperate directly - with 1042-only systems. If the two system types are set - up as two different logical networks on the same cable, - they can communicate only through an IP gateway. - Furthermore, it is not useful or even possible for a - dual-format host to discover automatically which format to - send, because of the problem of link-layer broadcasts. - - 2.4 LINK/INTERNET LAYER INTERFACE - - The packet receive interface between the IP layer and the link - layer MUST include a flag to indicate whether the incoming packet - was addressed to a link-layer broadcast address. - - - -Internet Engineering Task Force [Page 25] - - - - -RFC1122 LINK LAYER October 1989 - - - DISCUSSION - Although the IP layer does not generally know link layer - addresses (since every different network medium typically has - a different address format), the broadcast address on a - broadcast-capable medium is an important special case. See - Section 3.2.2, especially the DISCUSSION concerning broadcast - storms. - - The packet send interface between the IP and link layers MUST - include the 5-bit TOS field (see Section 3.2.1.6). - - The link layer MUST NOT report a Destination Unreachable error to - IP solely because there is no ARP cache entry for a destination. - - 2.5 LINK LAYER REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION| | | |T|T|e ---------------------------------------------------|-------|-|-|-|-|-|-- - | | | | | | | -Trailer encapsulation |2.3.1 | | |x| | | -Send Trailers by default without negotiation |2.3.1 | | | | |x| -ARP |2.3.2 | | | | | | - Flush out-of-date ARP cache entries |2.3.2.1|x| | | | | - Prevent ARP floods |2.3.2.1|x| | | | | - Cache timeout configurable |2.3.2.1| |x| | | | - Save at least one (latest) unresolved pkt |2.3.2.2| |x| | | | -Ethernet and IEEE 802 Encapsulation |2.3.3 | | | | | | - Host able to: |2.3.3 | | | | | | - Send & receive RFC-894 encapsulation |2.3.3 |x| | | | | - Receive RFC-1042 encapsulation |2.3.3 | |x| | | | - Send RFC-1042 encapsulation |2.3.3 | | |x| | | - Then config. sw. to select, RFC-894 dflt |2.3.3 |x| | | | | - Send K1=6 encapsulation |2.3.3 | | | | |x| - Use ARP on Ethernet and IEEE 802 nets |2.3.3 |x| | | | | -Link layer report b'casts to IP layer |2.4 |x| | | | | -IP layer pass TOS to link layer |2.4 |x| | | | | -No ARP cache entry treated as Dest. Unreach. |2.4 | | | | |x| - - - - - -Internet Engineering Task Force [Page 26] - - - - -RFC1122 INTERNET LAYER October 1989 - - -3. INTERNET LAYER PROTOCOLS - - 3.1 INTRODUCTION - - The Robustness Principle: "Be liberal in what you accept, and - conservative in what you send" is particularly important in the - Internet layer, where one misbehaving host can deny Internet - service to many other hosts. - - The protocol standards used in the Internet layer are: - - o RFC-791 [IP:1] defines the IP protocol and gives an - introduction to the architecture of the Internet. - - o RFC-792 [IP:2] defines ICMP, which provides routing, - diagnostic and error functionality for IP. Although ICMP - messages are encapsulated within IP datagrams, ICMP - processing is considered to be (and is typically implemented - as) part of the IP layer. See Section 3.2.2. - - o RFC-950 [IP:3] defines the mandatory subnet extension to the - addressing architecture. - - o RFC-1112 [IP:4] defines the Internet Group Management - Protocol IGMP, as part of a recommended extension to hosts - and to the host-gateway interface to support Internet-wide - multicasting at the IP level. See Section 3.2.3. - - The target of an IP multicast may be an arbitrary group of - Internet hosts. IP multicasting is designed as a natural - extension of the link-layer multicasting facilities of some - networks, and it provides a standard means for local access - to such link-layer multicasting facilities. - - Other important references are listed in Section 5 of this - document. - - The Internet layer of host software MUST implement both IP and - ICMP. See Section 3.3.7 for the requirements on support of IGMP. - - The host IP layer has two basic functions: (1) choose the "next - hop" gateway or host for outgoing IP datagrams and (2) reassemble - incoming IP datagrams. The IP layer may also (3) implement - intentional fragmentation of outgoing datagrams. Finally, the IP - layer must (4) provide diagnostic and error functionality. We - expect that IP layer functions may increase somewhat in the - future, as further Internet control and management facilities are - developed. - - - -Internet Engineering Task Force [Page 27] - - - - -RFC1122 INTERNET LAYER October 1989 - - - For normal datagrams, the processing is straightforward. For - incoming datagrams, the IP layer: - - (1) verifies that the datagram is correctly formatted; - - (2) verifies that it is destined to the local host; - - (3) processes options; - - (4) reassembles the datagram if necessary; and - - (5) passes the encapsulated message to the appropriate - transport-layer protocol module. - - For outgoing datagrams, the IP layer: - - (1) sets any fields not set by the transport layer; - - (2) selects the correct first hop on the connected network (a - process called "routing"); - - (3) fragments the datagram if necessary and if intentional - fragmentation is implemented (see Section 3.3.3); and - - (4) passes the packet(s) to the appropriate link-layer driver. - - - A host is said to be multihomed if it has multiple IP addresses. - Multihoming introduces considerable confusion and complexity into - the protocol suite, and it is an area in which the Internet - architecture falls seriously short of solving all problems. There - are two distinct problem areas in multihoming: - - (1) Local multihoming -- the host itself is multihomed; or - - (2) Remote multihoming -- the local host needs to communicate - with a remote multihomed host. - - At present, remote multihoming MUST be handled at the application - layer, as discussed in the companion RFC [INTRO:1]. A host MAY - support local multihoming, which is discussed in this document, - and in particular in Section 3.3.4. - - Any host that forwards datagrams generated by another host is - acting as a gateway and MUST also meet the specifications laid out - in the gateway requirements RFC [INTRO:2]. An Internet host that - includes embedded gateway code MUST have a configuration switch to - disable the gateway function, and this switch MUST default to the - - - -Internet Engineering Task Force [Page 28] - - - - -RFC1122 INTERNET LAYER October 1989 - - - non-gateway mode. In this mode, a datagram arriving through one - interface will not be forwarded to another host or gateway (unless - it is source-routed), regardless of whether the host is single- - homed or multihomed. The host software MUST NOT automatically - move into gateway mode if the host has more than one interface, as - the operator of the machine may neither want to provide that - service nor be competent to do so. - - In the following, the action specified in certain cases is to - "silently discard" a received datagram. This means that the - datagram will be discarded without further processing and that the - host will not send any ICMP error message (see Section 3.2.2) as a - result. However, for diagnosis of problems a host SHOULD provide - the capability of logging the error (see Section 1.2.3), including - the contents of the silently-discarded datagram, and SHOULD record - the event in a statistics counter. - - DISCUSSION: - Silent discard of erroneous datagrams is generally intended - to prevent "broadcast storms". - - 3.2 PROTOCOL WALK-THROUGH - - 3.2.1 Internet Protocol -- IP - - 3.2.1.1 Version Number: RFC-791 Section 3.1 - - A datagram whose version number is not 4 MUST be silently - discarded. - - 3.2.1.2 Checksum: RFC-791 Section 3.1 - - A host MUST verify the IP header checksum on every received - datagram and silently discard every datagram that has a bad - checksum. - - 3.2.1.3 Addressing: RFC-791 Section 3.2 - - There are now five classes of IP addresses: Class A through - Class E. Class D addresses are used for IP multicasting - [IP:4], while Class E addresses are reserved for - experimental use. - - A multicast (Class D) address is a 28-bit logical address - that stands for a group of hosts, and may be either - permanent or transient. Permanent multicast addresses are - allocated by the Internet Assigned Number Authority - [INTRO:6], while transient addresses may be allocated - - - -Internet Engineering Task Force [Page 29] - - - - -RFC1122 INTERNET LAYER October 1989 - - - dynamically to transient groups. Group membership is - determined dynamically using IGMP [IP:4]. - - We now summarize the important special cases for Class A, B, - and C IP addresses, using the following notation for an IP - address: - - { <Network-number>, <Host-number> } - - or - { <Network-number>, <Subnet-number>, <Host-number> } - - and the notation "-1" for a field that contains all 1 bits. - This notation is not intended to imply that the 1-bits in an - address mask need be contiguous. - - (a) { 0, 0 } - - This host on this network. MUST NOT be sent, except as - a source address as part of an initialization procedure - by which the host learns its own IP address. - - See also Section 3.3.6 for a non-standard use of {0,0}. - - (b) { 0, <Host-number> } - - Specified host on this network. It MUST NOT be sent, - except as a source address as part of an initialization - procedure by which the host learns its full IP address. - - (c) { -1, -1 } - - Limited broadcast. It MUST NOT be used as a source - address. - - A datagram with this destination address will be - received by every host on the connected physical - network but will not be forwarded outside that network. - - (d) { <Network-number>, -1 } - - Directed broadcast to the specified network. It MUST - NOT be used as a source address. - - (e) { <Network-number>, <Subnet-number>, -1 } - - Directed broadcast to the specified subnet. It MUST - NOT be used as a source address. - - - -Internet Engineering Task Force [Page 30] - - - - -RFC1122 INTERNET LAYER October 1989 - - - (f) { <Network-number>, -1, -1 } - - Directed broadcast to all subnets of the specified - subnetted network. It MUST NOT be used as a source - address. - - (g) { 127, <any> } - - Internal host loopback address. Addresses of this form - MUST NOT appear outside a host. - - The <Network-number> is administratively assigned so that - its value will be unique in the entire world. - - IP addresses are not permitted to have the value 0 or -1 for - any of the <Host-number>, <Network-number>, or <Subnet- - number> fields (except in the special cases listed above). - This implies that each of these fields will be at least two - bits long. - - For further discussion of broadcast addresses, see Section - 3.3.6. - - A host MUST support the subnet extensions to IP [IP:3]. As - a result, there will be an address mask of the form: - {-1, -1, 0} associated with each of the host's local IP - addresses; see Sections 3.2.2.9 and 3.3.1.1. - - When a host sends any datagram, the IP source address MUST - be one of its own IP addresses (but not a broadcast or - multicast address). - - A host MUST silently discard an incoming datagram that is - not destined for the host. An incoming datagram is destined - for the host if the datagram's destination address field is: - - (1) (one of) the host's IP address(es); or - - (2) an IP broadcast address valid for the connected - network; or - - (3) the address for a multicast group of which the host is - a member on the incoming physical interface. - - For most purposes, a datagram addressed to a broadcast or - multicast destination is processed as if it had been - addressed to one of the host's IP addresses; we use the term - "specific-destination address" for the equivalent local IP - - - -Internet Engineering Task Force [Page 31] - - - - -RFC1122 INTERNET LAYER October 1989 - - - address of the host. The specific-destination address is - defined to be the destination address in the IP header - unless the header contains a broadcast or multicast address, - in which case the specific-destination is an IP address - assigned to the physical interface on which the datagram - arrived. - - A host MUST silently discard an incoming datagram containing - an IP source address that is invalid by the rules of this - section. This validation could be done in either the IP - layer or by each protocol in the transport layer. - - DISCUSSION: - A mis-addressed datagram might be caused by a link- - layer broadcast of a unicast datagram or by a gateway - or host that is confused or mis-configured. - - An architectural goal for Internet hosts was to allow - IP addresses to be featureless 32-bit numbers, avoiding - algorithms that required a knowledge of the IP address - format. Otherwise, any future change in the format or - interpretation of IP addresses will require host - software changes. However, validation of broadcast and - multicast addresses violates this goal; a few other - violations are described elsewhere in this document. - - Implementers should be aware that applications - depending upon the all-subnets directed broadcast - address (f) may be unusable on some networks. All- - subnets broadcast is not widely implemented in vendor - gateways at present, and even when it is implemented, a - particular network administration may disable it in the - gateway configuration. - - 3.2.1.4 Fragmentation and Reassembly: RFC-791 Section 3.2 - - The Internet model requires that every host support - reassembly. See Sections 3.3.2 and 3.3.3 for the - requirements on fragmentation and reassembly. - - 3.2.1.5 Identification: RFC-791 Section 3.2 - - When sending an identical copy of an earlier datagram, a - host MAY optionally retain the same Identification field in - the copy. - - - - - - -Internet Engineering Task Force [Page 32] - - - - -RFC1122 INTERNET LAYER October 1989 - - - DISCUSSION: - Some Internet protocol experts have maintained that - when a host sends an identical copy of an earlier - datagram, the new copy should contain the same - Identification value as the original. There are two - suggested advantages: (1) if the datagrams are - fragmented and some of the fragments are lost, the - receiver may be able to reconstruct a complete datagram - from fragments of the original and the copies; (2) a - congested gateway might use the IP Identification field - (and Fragment Offset) to discard duplicate datagrams - from the queue. - - However, the observed patterns of datagram loss in the - Internet do not favor the probability of retransmitted - fragments filling reassembly gaps, while other - mechanisms (e.g., TCP repacketizing upon - retransmission) tend to prevent retransmission of an - identical datagram [IP:9]. Therefore, we believe that - retransmitting the same Identification field is not - useful. Also, a connectionless transport protocol like - UDP would require the cooperation of the application - programs to retain the same Identification value in - identical datagrams. - - 3.2.1.6 Type-of-Service: RFC-791 Section 3.2 - - The "Type-of-Service" byte in the IP header is divided into - two sections: the Precedence field (high-order 3 bits), and - a field that is customarily called "Type-of-Service" or - "TOS" (low-order 5 bits). In this document, all references - to "TOS" or the "TOS field" refer to the low-order 5 bits - only. - - The Precedence field is intended for Department of Defense - applications of the Internet protocols. The use of non-zero - values in this field is outside the scope of this document - and the IP standard specification. Vendors should consult - the Defense Communication Agency (DCA) for guidance on the - IP Precedence field and its implications for other protocol - layers. However, vendors should note that the use of - precedence will most likely require that its value be passed - between protocol layers in just the same way as the TOS - field is passed. - - The IP layer MUST provide a means for the transport layer to - set the TOS field of every datagram that is sent; the - default is all zero bits. The IP layer SHOULD pass received - - - -Internet Engineering Task Force [Page 33] - - - - -RFC1122 INTERNET LAYER October 1989 - - - TOS values up to the transport layer. - - The particular link-layer mappings of TOS contained in RFC- - 795 SHOULD NOT be implemented. - - DISCUSSION: - While the TOS field has been little used in the past, - it is expected to play an increasing role in the near - future. The TOS field is expected to be used to - control two aspects of gateway operations: routing and - queueing algorithms. See Section 2 of [INTRO:1] for - the requirements on application programs to specify TOS - values. - - The TOS field may also be mapped into link-layer - service selectors. This has been applied to provide - effective sharing of serial lines by different classes - of TCP traffic, for example. However, the mappings - suggested in RFC-795 for networks that were included in - the Internet as of 1981 are now obsolete. - - 3.2.1.7 Time-to-Live: RFC-791 Section 3.2 - - A host MUST NOT send a datagram with a Time-to-Live (TTL) - value of zero. - - A host MUST NOT discard a datagram just because it was - received with TTL less than 2. - - The IP layer MUST provide a means for the transport layer to - set the TTL field of every datagram that is sent. When a - fixed TTL value is used, it MUST be configurable. The - current suggested value will be published in the "Assigned - Numbers" RFC. - - DISCUSSION: - The TTL field has two functions: limit the lifetime of - TCP segments (see RFC-793 [TCP:1], p. 28), and - terminate Internet routing loops. Although TTL is a - time in seconds, it also has some attributes of a hop- - count, since each gateway is required to reduce the TTL - field by at least one. - - The intent is that TTL expiration will cause a datagram - to be discarded by a gateway but not by the destination - host; however, hosts that act as gateways by forwarding - datagrams must follow the gateway rules for TTL. - - - - -Internet Engineering Task Force [Page 34] - - - - -RFC1122 INTERNET LAYER October 1989 - - - A higher-layer protocol may want to set the TTL in - order to implement an "expanding scope" search for some - Internet resource. This is used by some diagnostic - tools, and is expected to be useful for locating the - "nearest" server of a given class using IP - multicasting, for example. A particular transport - protocol may also want to specify its own TTL bound on - maximum datagram lifetime. - - A fixed value must be at least big enough for the - Internet "diameter," i.e., the longest possible path. - A reasonable value is about twice the diameter, to - allow for continued Internet growth. - - 3.2.1.8 Options: RFC-791 Section 3.2 - - There MUST be a means for the transport layer to specify IP - options to be included in transmitted IP datagrams (see - Section 3.4). - - All IP options (except NOP or END-OF-LIST) received in - datagrams MUST be passed to the transport layer (or to ICMP - processing when the datagram is an ICMP message). The IP - and transport layer MUST each interpret those IP options - that they understand and silently ignore the others. - - Later sections of this document discuss specific IP option - support required by each of ICMP, TCP, and UDP. - - DISCUSSION: - Passing all received IP options to the transport layer - is a deliberate "violation of strict layering" that is - designed to ease the introduction of new transport- - relevant IP options in the future. Each layer must - pick out any options that are relevant to its own - processing and ignore the rest. For this purpose, - every IP option except NOP and END-OF-LIST will include - a specification of its own length. - - This document does not define the order in which a - receiver must process multiple options in the same IP - header. Hosts sending multiple options must be aware - that this introduces an ambiguity in the meaning of - certain options when combined with a source-route - option. - - IMPLEMENTATION: - The IP layer must not crash as the result of an option - - - -Internet Engineering Task Force [Page 35] - - - - -RFC1122 INTERNET LAYER October 1989 - - - length that is outside the possible range. For - example, erroneous option lengths have been observed to - put some IP implementations into infinite loops. - - Here are the requirements for specific IP options: - - - (a) Security Option - - Some environments require the Security option in every - datagram; such a requirement is outside the scope of - this document and the IP standard specification. Note, - however, that the security options described in RFC-791 - and RFC-1038 are obsolete. For DoD applications, - vendors should consult [IP:8] for guidance. - - - (b) Stream Identifier Option - - This option is obsolete; it SHOULD NOT be sent, and it - MUST be silently ignored if received. - - - (c) Source Route Options - - A host MUST support originating a source route and MUST - be able to act as the final destination of a source - route. - - If host receives a datagram containing a completed - source route (i.e., the pointer points beyond the last - field), the datagram has reached its final destination; - the option as received (the recorded route) MUST be - passed up to the transport layer (or to ICMP message - processing). This recorded route will be reversed and - used to form a return source route for reply datagrams - (see discussion of IP Options in Section 4). When a - return source route is built, it MUST be correctly - formed even if the recorded route included the source - host (see case (B) in the discussion below). - - An IP header containing more than one Source Route - option MUST NOT be sent; the effect on routing of - multiple Source Route options is implementation- - specific. - - Section 3.3.5 presents the rules for a host acting as - an intermediate hop in a source route, i.e., forwarding - - - -Internet Engineering Task Force [Page 36] - - - - -RFC1122 INTERNET LAYER October 1989 - - - a source-routed datagram. - - DISCUSSION: - If a source-routed datagram is fragmented, each - fragment will contain a copy of the source route. - Since the processing of IP options (including a - source route) must precede reassembly, the - original datagram will not be reassembled until - the final destination is reached. - - Suppose a source routed datagram is to be routed - from host S to host D via gateways G1, G2, ... Gn. - There was an ambiguity in the specification over - whether the source route option in a datagram sent - out by S should be (A) or (B): - - (A): {>>G2, G3, ... Gn, D} <--- CORRECT - - (B): {S, >>G2, G3, ... Gn, D} <---- WRONG - - (where >> represents the pointer). If (A) is - sent, the datagram received at D will contain the - option: {G1, G2, ... Gn >>}, with S and D as the - IP source and destination addresses. If (B) were - sent, the datagram received at D would again - contain S and D as the same IP source and - destination addresses, but the option would be: - {S, G1, ...Gn >>}; i.e., the originating host - would be the first hop in the route. - - - (d) Record Route Option - - Implementation of originating and processing the Record - Route option is OPTIONAL. - - - (e) Timestamp Option - - Implementation of originating and processing the - Timestamp option is OPTIONAL. If it is implemented, - the following rules apply: - - o The originating host MUST record a timestamp in a - Timestamp option whose Internet address fields are - not pre-specified or whose first pre-specified - address is the host's interface address. - - - - -Internet Engineering Task Force [Page 37] - - - - -RFC1122 INTERNET LAYER October 1989 - - - o The destination host MUST (if possible) add the - current timestamp to a Timestamp option before - passing the option to the transport layer or to - ICMP for processing. - - o A timestamp value MUST follow the rules given in - Section 3.2.2.8 for the ICMP Timestamp message. - - - 3.2.2 Internet Control Message Protocol -- ICMP - - ICMP messages are grouped into two classes. - - * - ICMP error messages: - - Destination Unreachable (see Section 3.2.2.1) - Redirect (see Section 3.2.2.2) - Source Quench (see Section 3.2.2.3) - Time Exceeded (see Section 3.2.2.4) - Parameter Problem (see Section 3.2.2.5) - - - * - ICMP query messages: - - Echo (see Section 3.2.2.6) - Information (see Section 3.2.2.7) - Timestamp (see Section 3.2.2.8) - Address Mask (see Section 3.2.2.9) - - - If an ICMP message of unknown type is received, it MUST be - silently discarded. - - Every ICMP error message includes the Internet header and at - least the first 8 data octets of the datagram that triggered - the error; more than 8 octets MAY be sent; this header and data - MUST be unchanged from the received datagram. - - In those cases where the Internet layer is required to pass an - ICMP error message to the transport layer, the IP protocol - number MUST be extracted from the original header and used to - select the appropriate transport protocol entity to handle the - error. - - An ICMP error message SHOULD be sent with normal (i.e., zero) - TOS bits. - - - -Internet Engineering Task Force [Page 38] - - - - -RFC1122 INTERNET LAYER October 1989 - - - An ICMP error message MUST NOT be sent as the result of - receiving: - - * an ICMP error message, or - - * a datagram destined to an IP broadcast or IP multicast - address, or - - * a datagram sent as a link-layer broadcast, or - - * a non-initial fragment, or - - * a datagram whose source address does not define a single - host -- e.g., a zero address, a loopback address, a - broadcast address, a multicast address, or a Class E - address. - - NOTE: THESE RESTRICTIONS TAKE PRECEDENCE OVER ANY REQUIREMENT - ELSEWHERE IN THIS DOCUMENT FOR SENDING ICMP ERROR MESSAGES. - - DISCUSSION: - These rules will prevent the "broadcast storms" that have - resulted from hosts returning ICMP error messages in - response to broadcast datagrams. For example, a broadcast - UDP segment to a non-existent port could trigger a flood - of ICMP Destination Unreachable datagrams from all - machines that do not have a client for that destination - port. On a large Ethernet, the resulting collisions can - render the network useless for a second or more. - - Every datagram that is broadcast on the connected network - should have a valid IP broadcast address as its IP - destination (see Section 3.3.6). However, some hosts - violate this rule. To be certain to detect broadcast - datagrams, therefore, hosts are required to check for a - link-layer broadcast as well as an IP-layer broadcast - address. - - IMPLEMENTATION: - This requires that the link layer inform the IP layer when - a link-layer broadcast datagram has been received; see - Section 2.4. - - 3.2.2.1 Destination Unreachable: RFC-792 - - The following additional codes are hereby defined: - - 6 = destination network unknown - - - -Internet Engineering Task Force [Page 39] - - - - -RFC1122 INTERNET LAYER October 1989 - - - 7 = destination host unknown - - 8 = source host isolated - - 9 = communication with destination network - administratively prohibited - - 10 = communication with destination host - administratively prohibited - - 11 = network unreachable for type of service - - 12 = host unreachable for type of service - - A host SHOULD generate Destination Unreachable messages with - code: - - 2 (Protocol Unreachable), when the designated transport - protocol is not supported; or - - 3 (Port Unreachable), when the designated transport - protocol (e.g., UDP) is unable to demultiplex the - datagram but has no protocol mechanism to inform the - sender. - - A Destination Unreachable message that is received MUST be - reported to the transport layer. The transport layer SHOULD - use the information appropriately; for example, see Sections - 4.1.3.3, 4.2.3.9, and 4.2.4 below. A transport protocol - that has its own mechanism for notifying the sender that a - port is unreachable (e.g., TCP, which sends RST segments) - MUST nevertheless accept an ICMP Port Unreachable for the - same purpose. - - A Destination Unreachable message that is received with code - 0 (Net), 1 (Host), or 5 (Bad Source Route) may result from a - routing transient and MUST therefore be interpreted as only - a hint, not proof, that the specified destination is - unreachable [IP:11]. For example, it MUST NOT be used as - proof of a dead gateway (see Section 3.3.1). - - 3.2.2.2 Redirect: RFC-792 - - A host SHOULD NOT send an ICMP Redirect message; Redirects - are to be sent only by gateways. - - A host receiving a Redirect message MUST update its routing - information accordingly. Every host MUST be prepared to - - - -Internet Engineering Task Force [Page 40] - - - - -RFC1122 INTERNET LAYER October 1989 - - - accept both Host and Network Redirects and to process them - as described in Section 3.3.1.2 below. - - A Redirect message SHOULD be silently discarded if the new - gateway address it specifies is not on the same connected - (sub-) net through which the Redirect arrived [INTRO:2, - Appendix A], or if the source of the Redirect is not the - current first-hop gateway for the specified destination (see - Section 3.3.1). - - 3.2.2.3 Source Quench: RFC-792 - - A host MAY send a Source Quench message if it is - approaching, or has reached, the point at which it is forced - to discard incoming datagrams due to a shortage of - reassembly buffers or other resources. See Section 2.2.3 of - [INTRO:2] for suggestions on when to send Source Quench. - - If a Source Quench message is received, the IP layer MUST - report it to the transport layer (or ICMP processing). In - general, the transport or application layer SHOULD implement - a mechanism to respond to Source Quench for any protocol - that can send a sequence of datagrams to the same - destination and which can reasonably be expected to maintain - enough state information to make this feasible. See Section - 4 for the handling of Source Quench by TCP and UDP. - - DISCUSSION: - A Source Quench may be generated by the target host or - by some gateway in the path of a datagram. The host - receiving a Source Quench should throttle itself back - for a period of time, then gradually increase the - transmission rate again. The mechanism to respond to - Source Quench may be in the transport layer (for - connection-oriented protocols like TCP) or in the - application layer (for protocols that are built on top - of UDP). - - A mechanism has been proposed [IP:14] to make the IP - layer respond directly to Source Quench by controlling - the rate at which datagrams are sent, however, this - proposal is currently experimental and not currently - recommended. - - 3.2.2.4 Time Exceeded: RFC-792 - - An incoming Time Exceeded message MUST be passed to the - transport layer. - - - -Internet Engineering Task Force [Page 41] - - - - -RFC1122 INTERNET LAYER October 1989 - - - DISCUSSION: - A gateway will send a Time Exceeded Code 0 (In Transit) - message when it discards a datagram due to an expired - TTL field. This indicates either a gateway routing - loop or too small an initial TTL value. - - A host may receive a Time Exceeded Code 1 (Reassembly - Timeout) message from a destination host that has timed - out and discarded an incomplete datagram; see Section - 3.3.2 below. In the future, receipt of this message - might be part of some "MTU discovery" procedure, to - discover the maximum datagram size that can be sent on - the path without fragmentation. - - 3.2.2.5 Parameter Problem: RFC-792 - - A host SHOULD generate Parameter Problem messages. An - incoming Parameter Problem message MUST be passed to the - transport layer, and it MAY be reported to the user. - - DISCUSSION: - The ICMP Parameter Problem message is sent to the - source host for any problem not specifically covered by - another ICMP message. Receipt of a Parameter Problem - message generally indicates some local or remote - implementation error. - - A new variant on the Parameter Problem message is hereby - defined: - Code 1 = required option is missing. - - DISCUSSION: - This variant is currently in use in the military - community for a missing security option. - - 3.2.2.6 Echo Request/Reply: RFC-792 - - Every host MUST implement an ICMP Echo server function that - receives Echo Requests and sends corresponding Echo Replies. - A host SHOULD also implement an application-layer interface - for sending an Echo Request and receiving an Echo Reply, for - diagnostic purposes. - - An ICMP Echo Request destined to an IP broadcast or IP - multicast address MAY be silently discarded. - - - - - - -Internet Engineering Task Force [Page 42] - - - - -RFC1122 INTERNET LAYER October 1989 - - - DISCUSSION: - This neutral provision results from a passionate debate - between those who feel that ICMP Echo to a broadcast - address provides a valuable diagnostic capability and - those who feel that misuse of this feature can too - easily create packet storms. - - The IP source address in an ICMP Echo Reply MUST be the same - as the specific-destination address (defined in Section - 3.2.1.3) of the corresponding ICMP Echo Request message. - - Data received in an ICMP Echo Request MUST be entirely - included in the resulting Echo Reply. However, if sending - the Echo Reply requires intentional fragmentation that is - not implemented, the datagram MUST be truncated to maximum - transmission size (see Section 3.3.3) and sent. - - Echo Reply messages MUST be passed to the ICMP user - interface, unless the corresponding Echo Request originated - in the IP layer. - - If a Record Route and/or Time Stamp option is received in an - ICMP Echo Request, this option (these options) SHOULD be - updated to include the current host and included in the IP - header of the Echo Reply message, without "truncation". - Thus, the recorded route will be for the entire round trip. - - If a Source Route option is received in an ICMP Echo - Request, the return route MUST be reversed and used as a - Source Route option for the Echo Reply message. - - 3.2.2.7 Information Request/Reply: RFC-792 - - A host SHOULD NOT implement these messages. - - DISCUSSION: - The Information Request/Reply pair was intended to - support self-configuring systems such as diskless - workstations, to allow them to discover their IP - network numbers at boot time. However, the RARP and - BOOTP protocols provide better mechanisms for a host to - discover its own IP address. - - 3.2.2.8 Timestamp and Timestamp Reply: RFC-792 - - A host MAY implement Timestamp and Timestamp Reply. If they - are implemented, the following rules MUST be followed. - - - - -Internet Engineering Task Force [Page 43] - - - - -RFC1122 INTERNET LAYER October 1989 - - - o The ICMP Timestamp server function returns a Timestamp - Reply to every Timestamp message that is received. If - this function is implemented, it SHOULD be designed for - minimum variability in delay (e.g., implemented in the - kernel to avoid delay in scheduling a user process). - - The following cases for Timestamp are to be handled - according to the corresponding rules for ICMP Echo: - - o An ICMP Timestamp Request message to an IP broadcast or - IP multicast address MAY be silently discarded. - - o The IP source address in an ICMP Timestamp Reply MUST - be the same as the specific-destination address of the - corresponding Timestamp Request message. - - o If a Source-route option is received in an ICMP Echo - Request, the return route MUST be reversed and used as - a Source Route option for the Timestamp Reply message. - - o If a Record Route and/or Timestamp option is received - in a Timestamp Request, this (these) option(s) SHOULD - be updated to include the current host and included in - the IP header of the Timestamp Reply message. - - o Incoming Timestamp Reply messages MUST be passed up to - the ICMP user interface. - - The preferred form for a timestamp value (the "standard - value") is in units of milliseconds since midnight Universal - Time. However, it may be difficult to provide this value - with millisecond resolution. For example, many systems use - clocks that update only at line frequency, 50 or 60 times - per second. Therefore, some latitude is allowed in a - "standard value": - - (a) A "standard value" MUST be updated at least 15 times - per second (i.e., at most the six low-order bits of the - value may be undefined). - - (b) The accuracy of a "standard value" MUST approximate - that of operator-set CPU clocks, i.e., correct within a - few minutes. - - - - - - - - -Internet Engineering Task Force [Page 44] - - - - -RFC1122 INTERNET LAYER October 1989 - - - 3.2.2.9 Address Mask Request/Reply: RFC-950 - - A host MUST support the first, and MAY implement all three, - of the following methods for determining the address mask(s) - corresponding to its IP address(es): - - (1) static configuration information; - - (2) obtaining the address mask(s) dynamically as a side- - effect of the system initialization process (see - [INTRO:1]); and - - (3) sending ICMP Address Mask Request(s) and receiving ICMP - Address Mask Reply(s). - - The choice of method to be used in a particular host MUST be - configurable. - - When method (3), the use of Address Mask messages, is - enabled, then: - - (a) When it initializes, the host MUST broadcast an Address - Mask Request message on the connected network - corresponding to the IP address. It MUST retransmit - this message a small number of times if it does not - receive an immediate Address Mask Reply. - - (b) Until it has received an Address Mask Reply, the host - SHOULD assume a mask appropriate for the address class - of the IP address, i.e., assume that the connected - network is not subnetted. - - (c) The first Address Mask Reply message received MUST be - used to set the address mask corresponding to the - particular local IP address. This is true even if the - first Address Mask Reply message is "unsolicited", in - which case it will have been broadcast and may arrive - after the host has ceased to retransmit Address Mask - Requests. Once the mask has been set by an Address - Mask Reply, later Address Mask Reply messages MUST be - (silently) ignored. - - Conversely, if Address Mask messages are disabled, then no - ICMP Address Mask Requests will be sent, and any ICMP - Address Mask Replies received for that local IP address MUST - be (silently) ignored. - - A host SHOULD make some reasonableness check on any address - - - -Internet Engineering Task Force [Page 45] - - - - -RFC1122 INTERNET LAYER October 1989 - - - mask it installs; see IMPLEMENTATION section below. - - A system MUST NOT send an Address Mask Reply unless it is an - authoritative agent for address masks. An authoritative - agent may be a host or a gateway, but it MUST be explicitly - configured as a address mask agent. Receiving an address - mask via an Address Mask Reply does not give the receiver - authority and MUST NOT be used as the basis for issuing - Address Mask Replies. - - With a statically configured address mask, there SHOULD be - an additional configuration flag that determines whether the - host is to act as an authoritative agent for this mask, - i.e., whether it will answer Address Mask Request messages - using this mask. - - If it is configured as an agent, the host MUST broadcast an - Address Mask Reply for the mask on the appropriate interface - when it initializes. - - See "System Initialization" in [INTRO:1] for more - information about the use of Address Mask Request/Reply - messages. - - DISCUSSION - Hosts that casually send Address Mask Replies with - invalid address masks have often been a serious - nuisance. To prevent this, Address Mask Replies ought - to be sent only by authoritative agents that have been - selected by explicit administrative action. - - When an authoritative agent receives an Address Mask - Request message, it will send a unicast Address Mask - Reply to the source IP address. If the network part of - this address is zero (see (a) and (b) in 3.2.1.3), the - Reply will be broadcast. - - Getting no reply to its Address Mask Request messages, - a host will assume there is no agent and use an - unsubnetted mask, but the agent may be only temporarily - unreachable. An agent will broadcast an unsolicited - Address Mask Reply whenever it initializes, in order to - update the masks of all hosts that have initialized in - the meantime. - - IMPLEMENTATION: - The following reasonableness check on an address mask - is suggested: the mask is not all 1 bits, and it is - - - -Internet Engineering Task Force [Page 46] - - - - -RFC1122 INTERNET LAYER October 1989 - - - either zero or else the 8 highest-order bits are on. - - 3.2.3 Internet Group Management Protocol IGMP - - IGMP [IP:4] is a protocol used between hosts and gateways on a - single network to establish hosts' membership in particular - multicast groups. The gateways use this information, in - conjunction with a multicast routing protocol, to support IP - multicasting across the Internet. - - At this time, implementation of IGMP is OPTIONAL; see Section - 3.3.7 for more information. Without IGMP, a host can still - participate in multicasting local to its connected networks. - - 3.3 SPECIFIC ISSUES - - 3.3.1 Routing Outbound Datagrams - - The IP layer chooses the correct next hop for each datagram it - sends. If the destination is on a connected network, the - datagram is sent directly to the destination host; otherwise, - it has to be routed to a gateway on a connected network. - - 3.3.1.1 Local/Remote Decision - - To decide if the destination is on a connected network, the - following algorithm MUST be used [see IP:3]: - - (a) The address mask (particular to a local IP address for - a multihomed host) is a 32-bit mask that selects the - network number and subnet number fields of the - corresponding IP address. - - (b) If the IP destination address bits extracted by the - address mask match the IP source address bits extracted - by the same mask, then the destination is on the - corresponding connected network, and the datagram is to - be transmitted directly to the destination host. - - (c) If not, then the destination is accessible only through - a gateway. Selection of a gateway is described below - (3.3.1.2). - - A special-case destination address is handled as follows: - - * For a limited broadcast or a multicast address, simply - pass the datagram to the link layer for the appropriate - interface. - - - -Internet Engineering Task Force [Page 47] - - - - -RFC1122 INTERNET LAYER October 1989 - - - * For a (network or subnet) directed broadcast, the - datagram can use the standard routing algorithms. - - The host IP layer MUST operate correctly in a minimal - network environment, and in particular, when there are no - gateways. For example, if the IP layer of a host insists on - finding at least one gateway to initialize, the host will be - unable to operate on a single isolated broadcast net. - - 3.3.1.2 Gateway Selection - - To efficiently route a series of datagrams to the same - destination, the source host MUST keep a "route cache" of - mappings to next-hop gateways. A host uses the following - basic algorithm on this cache to route a datagram; this - algorithm is designed to put the primary routing burden on - the gateways [IP:11]. - - (a) If the route cache contains no information for a - particular destination, the host chooses a "default" - gateway and sends the datagram to it. It also builds a - corresponding Route Cache entry. - - (b) If that gateway is not the best next hop to the - destination, the gateway will forward the datagram to - the best next-hop gateway and return an ICMP Redirect - message to the source host. - - (c) When it receives a Redirect, the host updates the - next-hop gateway in the appropriate route cache entry, - so later datagrams to the same destination will go - directly to the best gateway. - - Since the subnet mask appropriate to the destination address - is generally not known, a Network Redirect message SHOULD be - treated identically to a Host Redirect message; i.e., the - cache entry for the destination host (only) would be updated - (or created, if an entry for that host did not exist) for - the new gateway. - - DISCUSSION: - This recommendation is to protect against gateways that - erroneously send Network Redirects for a subnetted - network, in violation of the gateway requirements - [INTRO:2]. - - When there is no route cache entry for the destination host - address (and the destination is not on the connected - - - -Internet Engineering Task Force [Page 48] - - - - -RFC1122 INTERNET LAYER October 1989 - - - network), the IP layer MUST pick a gateway from its list of - "default" gateways. The IP layer MUST support multiple - default gateways. - - As an extra feature, a host IP layer MAY implement a table - of "static routes". Each such static route MAY include a - flag specifying whether it may be overridden by ICMP - Redirects. - - DISCUSSION: - A host generally needs to know at least one default - gateway to get started. This information can be - obtained from a configuration file or else from the - host startup sequence, e.g., the BOOTP protocol (see - [INTRO:1]). - - It has been suggested that a host can augment its list - of default gateways by recording any new gateways it - learns about. For example, it can record every gateway - to which it is ever redirected. Such a feature, while - possibly useful in some circumstances, may cause - problems in other cases (e.g., gateways are not all - equal), and it is not recommended. - - A static route is typically a particular preset mapping - from destination host or network into a particular - next-hop gateway; it might also depend on the Type-of- - Service (see next section). Static routes would be set - up by system administrators to override the normal - automatic routing mechanism, to handle exceptional - situations. However, any static routing information is - a potential source of failure as configurations change - or equipment fails. - - 3.3.1.3 Route Cache - - Each route cache entry needs to include the following - fields: - - (1) Local IP address (for a multihomed host) - - (2) Destination IP address - - (3) Type(s)-of-Service - - (4) Next-hop gateway IP address - - Field (2) MAY be the full IP address of the destination - - - -Internet Engineering Task Force [Page 49] - - - - -RFC1122 INTERNET LAYER October 1989 - - - host, or only the destination network number. Field (3), - the TOS, SHOULD be included. - - See Section 3.3.4.2 for a discussion of the implications of - multihoming for the lookup procedure in this cache. - - DISCUSSION: - Including the Type-of-Service field in the route cache - and considering it in the host route algorithm will - provide the necessary mechanism for the future when - Type-of-Service routing is commonly used in the - Internet. See Section 3.2.1.6. - - Each route cache entry defines the endpoints of an - Internet path. Although the connecting path may change - dynamically in an arbitrary way, the transmission - characteristics of the path tend to remain - approximately constant over a time period longer than a - single typical host-host transport connection. - Therefore, a route cache entry is a natural place to - cache data on the properties of the path. Examples of - such properties might be the maximum unfragmented - datagram size (see Section 3.3.3), or the average - round-trip delay measured by a transport protocol. - This data will generally be both gathered and used by a - higher layer protocol, e.g., by TCP, or by an - application using UDP. Experiments are currently in - progress on caching path properties in this manner. - - There is no consensus on whether the route cache should - be keyed on destination host addresses alone, or allow - both host and network addresses. Those who favor the - use of only host addresses argue that: - - (1) As required in Section 3.3.1.2, Redirect messages - will generally result in entries keyed on - destination host addresses; the simplest and most - general scheme would be to use host addresses - always. - - (2) The IP layer may not always know the address mask - for a network address in a complex subnetted - environment. - - (3) The use of only host addresses allows the - destination address to be used as a pure 32-bit - number, which may allow the Internet architecture - to be more easily extended in the future without - - - -Internet Engineering Task Force [Page 50] - - - - -RFC1122 INTERNET LAYER October 1989 - - - any change to the hosts. - - The opposing view is that allowing a mixture of - destination hosts and networks in the route cache: - - (1) Saves memory space. - - (2) Leads to a simpler data structure, easily - combining the cache with the tables of default and - static routes (see below). - - (3) Provides a more useful place to cache path - properties, as discussed earlier. - - - IMPLEMENTATION: - The cache needs to be large enough to include entries - for the maximum number of destination hosts that may be - in use at one time. - - A route cache entry may also include control - information used to choose an entry for replacement. - This might take the form of a "recently used" bit, a - use count, or a last-used timestamp, for example. It - is recommended that it include the time of last - modification of the entry, for diagnostic purposes. - - An implementation may wish to reduce the overhead of - scanning the route cache for every datagram to be - transmitted. This may be accomplished with a hash - table to speed the lookup, or by giving a connection- - oriented transport protocol a "hint" or temporary - handle on the appropriate cache entry, to be passed to - the IP layer with each subsequent datagram. - - Although we have described the route cache, the lists - of default gateways, and a table of static routes as - conceptually distinct, in practice they may be combined - into a single "routing table" data structure. - - 3.3.1.4 Dead Gateway Detection - - The IP layer MUST be able to detect the failure of a "next- - hop" gateway that is listed in its route cache and to choose - an alternate gateway (see Section 3.3.1.5). - - Dead gateway detection is covered in some detail in RFC-816 - [IP:11]. Experience to date has not produced a complete - - - -Internet Engineering Task Force [Page 51] - - - - -RFC1122 INTERNET LAYER October 1989 - - - algorithm which is totally satisfactory, though it has - identified several forbidden paths and promising techniques. - - * A particular gateway SHOULD NOT be used indefinitely in - the absence of positive indications that it is - functioning. - - * Active probes such as "pinging" (i.e., using an ICMP - Echo Request/Reply exchange) are expensive and scale - poorly. In particular, hosts MUST NOT actively check - the status of a first-hop gateway by simply pinging the - gateway continuously. - - * Even when it is the only effective way to verify a - gateway's status, pinging MUST be used only when - traffic is being sent to the gateway and when there is - no other positive indication to suggest that the - gateway is functioning. - - * To avoid pinging, the layers above and/or below the - Internet layer SHOULD be able to give "advice" on the - status of route cache entries when either positive - (gateway OK) or negative (gateway dead) information is - available. - - - DISCUSSION: - If an implementation does not include an adequate - mechanism for detecting a dead gateway and re-routing, - a gateway failure may cause datagrams to apparently - vanish into a "black hole". This failure can be - extremely confusing for users and difficult for network - personnel to debug. - - The dead-gateway detection mechanism must not cause - unacceptable load on the host, on connected networks, - or on first-hop gateway(s). The exact constraints on - the timeliness of dead gateway detection and on - acceptable load may vary somewhat depending on the - nature of the host's mission, but a host generally - needs to detect a failed first-hop gateway quickly - enough that transport-layer connections will not break - before an alternate gateway can be selected. - - Passing advice from other layers of the protocol stack - complicates the interfaces between the layers, but it - is the preferred approach to dead gateway detection. - Advice can come from almost any part of the IP/TCP - - - -Internet Engineering Task Force [Page 52] - - - - -RFC1122 INTERNET LAYER October 1989 - - - architecture, but it is expected to come primarily from - the transport and link layers. Here are some possible - sources for gateway advice: - - o TCP or any connection-oriented transport protocol - should be able to give negative advice, e.g., - triggered by excessive retransmissions. - - o TCP may give positive advice when (new) data is - acknowledged. Even though the route may be - asymmetric, an ACK for new data proves that the - acknowleged data must have been transmitted - successfully. - - o An ICMP Redirect message from a particular gateway - should be used as positive advice about that - gateway. - - o Link-layer information that reliably detects and - reports host failures (e.g., ARPANET Destination - Dead messages) should be used as negative advice. - - o Failure to ARP or to re-validate ARP mappings may - be used as negative advice for the corresponding - IP address. - - o Packets arriving from a particular link-layer - address are evidence that the system at this - address is alive. However, turning this - information into advice about gateways requires - mapping the link-layer address into an IP address, - and then checking that IP address against the - gateways pointed to by the route cache. This is - probably prohibitively inefficient. - - Note that positive advice that is given for every - datagram received may cause unacceptable overhead in - the implementation. - - While advice might be passed using required arguments - in all interfaces to the IP layer, some transport and - application layer protocols cannot deduce the correct - advice. These interfaces must therefore allow a - neutral value for advice, since either always-positive - or always-negative advice leads to incorrect behavior. - - There is another technique for dead gateway detection - that has been commonly used but is not recommended. - - - -Internet Engineering Task Force [Page 53] - - - - -RFC1122 INTERNET LAYER October 1989 - - - This technique depends upon the host passively - receiving ("wiretapping") the Interior Gateway Protocol - (IGP) datagrams that the gateways are broadcasting to - each other. This approach has the drawback that a host - needs to recognize all the interior gateway protocols - that gateways may use (see [INTRO:2]). In addition, it - only works on a broadcast network. - - At present, pinging (i.e., using ICMP Echo messages) is - the mechanism for gateway probing when absolutely - required. A successful ping guarantees that the - addressed interface and its associated machine are up, - but it does not guarantee that the machine is a gateway - as opposed to a host. The normal inference is that if - a Redirect or other evidence indicates that a machine - was a gateway, successful pings will indicate that the - machine is still up and hence still a gateway. - However, since a host silently discards packets that a - gateway would forward or redirect, this assumption - could sometimes fail. To avoid this problem, a new - ICMP message under development will ask "are you a - gateway?" - - IMPLEMENTATION: - The following specific algorithm has been suggested: - - o Associate a "reroute timer" with each gateway - pointed to by the route cache. Initialize the - timer to a value Tr, which must be small enough to - allow detection of a dead gateway before transport - connections time out. - - o Positive advice would reset the reroute timer to - Tr. Negative advice would reduce or zero the - reroute timer. - - o Whenever the IP layer used a particular gateway to - route a datagram, it would check the corresponding - reroute timer. If the timer had expired (reached - zero), the IP layer would send a ping to the - gateway, followed immediately by the datagram. - - o The ping (ICMP Echo) would be sent again if - necessary, up to N times. If no ping reply was - received in N tries, the gateway would be assumed - to have failed, and a new first-hop gateway would - be chosen for all cache entries pointing to the - failed gateway. - - - -Internet Engineering Task Force [Page 54] - - - - -RFC1122 INTERNET LAYER October 1989 - - - Note that the size of Tr is inversely related to the - amount of advice available. Tr should be large enough - to insure that: - - * Any pinging will be at a low level (e.g., <10%) of - all packets sent to a gateway from the host, AND - - * pinging is infrequent (e.g., every 3 minutes) - - Since the recommended algorithm is concerned with the - gateways pointed to by route cache entries, rather than - the cache entries themselves, a two level data - structure (perhaps coordinated with ARP or similar - caches) may be desirable for implementing a route - cache. - - 3.3.1.5 New Gateway Selection - - If the failed gateway is not the current default, the IP - layer can immediately switch to a default gateway. If it is - the current default that failed, the IP layer MUST select a - different default gateway (assuming more than one default is - known) for the failed route and for establishing new routes. - - DISCUSSION: - When a gateway does fail, the other gateways on the - connected network will learn of the failure through - some inter-gateway routing protocol. However, this - will not happen instantaneously, since gateway routing - protocols typically have a settling time of 30-60 - seconds. If the host switches to an alternative - gateway before the gateways have agreed on the failure, - the new target gateway will probably forward the - datagram to the failed gateway and send a Redirect back - to the host pointing to the failed gateway (!). The - result is likely to be a rapid oscillation in the - contents of the host's route cache during the gateway - settling period. It has been proposed that the dead- - gateway logic should include some hysteresis mechanism - to prevent such oscillations. However, experience has - not shown any harm from such oscillations, since - service cannot be restored to the host until the - gateways' routing information does settle down. - - IMPLEMENTATION: - One implementation technique for choosing a new default - gateway is to simply round-robin among the default - gateways in the host's list. Another is to rank the - - - -Internet Engineering Task Force [Page 55] - - - - -RFC1122 INTERNET LAYER October 1989 - - - gateways in priority order, and when the current - default gateway is not the highest priority one, to - "ping" the higher-priority gateways slowly to detect - when they return to service. This pinging can be at a - very low rate, e.g., 0.005 per second. - - 3.3.1.6 Initialization - - The following information MUST be configurable: - - (1) IP address(es). - - (2) Address mask(s). - - (3) A list of default gateways, with a preference level. - - A manual method of entering this configuration data MUST be - provided. In addition, a variety of methods can be used to - determine this information dynamically; see the section on - "Host Initialization" in [INTRO:1]. - - DISCUSSION: - Some host implementations use "wiretapping" of gateway - protocols on a broadcast network to learn what gateways - exist. A standard method for default gateway discovery - is under development. - - 3.3.2 Reassembly - - The IP layer MUST implement reassembly of IP datagrams. - - We designate the largest datagram size that can be reassembled - by EMTU_R ("Effective MTU to receive"); this is sometimes - called the "reassembly buffer size". EMTU_R MUST be greater - than or equal to 576, SHOULD be either configurable or - indefinite, and SHOULD be greater than or equal to the MTU of - the connected network(s). - - DISCUSSION: - A fixed EMTU_R limit should not be built into the code - because some application layer protocols require EMTU_R - values larger than 576. - - IMPLEMENTATION: - An implementation may use a contiguous reassembly buffer - for each datagram, or it may use a more complex data - structure that places no definite limit on the reassembled - datagram size; in the latter case, EMTU_R is said to be - - - -Internet Engineering Task Force [Page 56] - - - - -RFC1122 INTERNET LAYER October 1989 - - - "indefinite". - - Logically, reassembly is performed by simply copying each - fragment into the packet buffer at the proper offset. - Note that fragments may overlap if successive - retransmissions use different packetizing but the same - reassembly Id. - - The tricky part of reassembly is the bookkeeping to - determine when all bytes of the datagram have been - reassembled. We recommend Clark's algorithm [IP:10] that - requires no additional data space for the bookkeeping. - However, note that, contrary to [IP:10], the first - fragment header needs to be saved for inclusion in a - possible ICMP Time Exceeded (Reassembly Timeout) message. - - There MUST be a mechanism by which the transport layer can - learn MMS_R, the maximum message size that can be received and - reassembled in an IP datagram (see GET_MAXSIZES calls in - Section 3.4). If EMTU_R is not indefinite, then the value of - MMS_R is given by: - - MMS_R = EMTU_R - 20 - - since 20 is the minimum size of an IP header. - - There MUST be a reassembly timeout. The reassembly timeout - value SHOULD be a fixed value, not set from the remaining TTL. - It is recommended that the value lie between 60 seconds and 120 - seconds. If this timeout expires, the partially-reassembled - datagram MUST be discarded and an ICMP Time Exceeded message - sent to the source host (if fragment zero has been received). - - DISCUSSION: - The IP specification says that the reassembly timeout - should be the remaining TTL from the IP header, but this - does not work well because gateways generally treat TTL as - a simple hop count rather than an elapsed time. If the - reassembly timeout is too small, datagrams will be - discarded unnecessarily, and communication may fail. The - timeout needs to be at least as large as the typical - maximum delay across the Internet. A realistic minimum - reassembly timeout would be 60 seconds. - - It has been suggested that a cache might be kept of - round-trip times measured by transport protocols for - various destinations, and that these values might be used - to dynamically determine a reasonable reassembly timeout - - - -Internet Engineering Task Force [Page 57] - - - - -RFC1122 INTERNET LAYER October 1989 - - - value. Further investigation of this approach is - required. - - If the reassembly timeout is set too high, buffer - resources in the receiving host will be tied up too long, - and the MSL (Maximum Segment Lifetime) [TCP:1] will be - larger than necessary. The MSL controls the maximum rate - at which fragmented datagrams can be sent using distinct - values of the 16-bit Ident field; a larger MSL lowers the - maximum rate. The TCP specification [TCP:1] arbitrarily - assumes a value of 2 minutes for MSL. This sets an upper - limit on a reasonable reassembly timeout value. - - 3.3.3 Fragmentation - - Optionally, the IP layer MAY implement a mechanism to fragment - outgoing datagrams intentionally. - - We designate by EMTU_S ("Effective MTU for sending") the - maximum IP datagram size that may be sent, for a particular - combination of IP source and destination addresses and perhaps - TOS. - - A host MUST implement a mechanism to allow the transport layer - to learn MMS_S, the maximum transport-layer message size that - may be sent for a given {source, destination, TOS} triplet (see - GET_MAXSIZES call in Section 3.4). If no local fragmentation - is performed, the value of MMS_S will be: - - MMS_S = EMTU_S - <IP header size> - - and EMTU_S must be less than or equal to the MTU of the network - interface corresponding to the source address of the datagram. - Note that <IP header size> in this equation will be 20, unless - the IP reserves space to insert IP options for its own purposes - in addition to any options inserted by the transport layer. - - A host that does not implement local fragmentation MUST ensure - that the transport layer (for TCP) or the application layer - (for UDP) obtains MMS_S from the IP layer and does not send a - datagram exceeding MMS_S in size. - - It is generally desirable to avoid local fragmentation and to - choose EMTU_S low enough to avoid fragmentation in any gateway - along the path. In the absence of actual knowledge of the - minimum MTU along the path, the IP layer SHOULD use - EMTU_S <= 576 whenever the destination address is not on a - connected network, and otherwise use the connected network's - - - -Internet Engineering Task Force [Page 58] - - - - -RFC1122 INTERNET LAYER October 1989 - - - MTU. - - The MTU of each physical interface MUST be configurable. - - A host IP layer implementation MAY have a configuration flag - "All-Subnets-MTU", indicating that the MTU of the connected - network is to be used for destinations on different subnets - within the same network, but not for other networks. Thus, - this flag causes the network class mask, rather than the subnet - address mask, to be used to choose an EMTU_S. For a multihomed - host, an "All-Subnets-MTU" flag is needed for each network - interface. - - DISCUSSION: - Picking the correct datagram size to use when sending data - is a complex topic [IP:9]. - - (a) In general, no host is required to accept an IP - datagram larger than 576 bytes (including header and - data), so a host must not send a larger datagram - without explicit knowledge or prior arrangement with - the destination host. Thus, MMS_S is only an upper - bound on the datagram size that a transport protocol - may send; even when MMS_S exceeds 556, the transport - layer must limit its messages to 556 bytes in the - absence of other knowledge about the destination - host. - - (b) Some transport protocols (e.g., TCP) provide a way to - explicitly inform the sender about the largest - datagram the other end can receive and reassemble - [IP:7]. There is no corresponding mechanism in the - IP layer. - - A transport protocol that assumes an EMTU_R larger - than 576 (see Section 3.3.2), can send a datagram of - this larger size to another host that implements the - same protocol. - - (c) Hosts should ideally limit their EMTU_S for a given - destination to the minimum MTU of all the networks - along the path, to avoid any fragmentation. IP - fragmentation, while formally correct, can create a - serious transport protocol performance problem, - because loss of a single fragment means all the - fragments in the segment must be retransmitted - [IP:9]. - - - - -Internet Engineering Task Force [Page 59] - - - - -RFC1122 INTERNET LAYER October 1989 - - - Since nearly all networks in the Internet currently - support an MTU of 576 or greater, we strongly recommend - the use of 576 for datagrams sent to non-local networks. - - It has been suggested that a host could determine the MTU - over a given path by sending a zero-offset datagram - fragment and waiting for the receiver to time out the - reassembly (which cannot complete!) and return an ICMP - Time Exceeded message. This message would include the - largest remaining fragment header in its body. More - direct mechanisms are being experimented with, but have - not yet been adopted (see e.g., RFC-1063). - - 3.3.4 Local Multihoming - - 3.3.4.1 Introduction - - A multihomed host has multiple IP addresses, which we may - think of as "logical interfaces". These logical interfaces - may be associated with one or more physical interfaces, and - these physical interfaces may be connected to the same or - different networks. - - Here are some important cases of multihoming: - - (a) Multiple Logical Networks - - The Internet architects envisioned that each physical - network would have a single unique IP network (or - subnet) number. However, LAN administrators have - sometimes found it useful to violate this assumption, - operating a LAN with multiple logical networks per - physical connected network. - - If a host connected to such a physical network is - configured to handle traffic for each of N different - logical networks, then the host will have N logical - interfaces. These could share a single physical - interface, or might use N physical interfaces to the - same network. - - (b) Multiple Logical Hosts - - When a host has multiple IP addresses that all have the - same <Network-number> part (and the same <Subnet- - number> part, if any), the logical interfaces are known - as "logical hosts". These logical interfaces might - share a single physical interface or might use separate - - - -Internet Engineering Task Force [Page 60] - - - - -RFC1122 INTERNET LAYER October 1989 - - - physical interfaces to the same physical network. - - (c) Simple Multihoming - - In this case, each logical interface is mapped into a - separate physical interface and each physical interface - is connected to a different physical network. The term - "multihoming" was originally applied only to this case, - but it is now applied more generally. - - A host with embedded gateway functionality will - typically fall into the simple multihoming case. Note, - however, that a host may be simply multihomed without - containing an embedded gateway, i.e., without - forwarding datagrams from one connected network to - another. - - This case presents the most difficult routing problems. - The choice of interface (i.e., the choice of first-hop - network) may significantly affect performance or even - reachability of remote parts of the Internet. - - - Finally, we note another possibility that is NOT - multihoming: one logical interface may be bound to multiple - physical interfaces, in order to increase the reliability or - throughput between directly connected machines by providing - alternative physical paths between them. For instance, two - systems might be connected by multiple point-to-point links. - We call this "link-layer multiplexing". With link-layer - multiplexing, the protocols above the link layer are unaware - that multiple physical interfaces are present; the link- - layer device driver is responsible for multiplexing and - routing packets across the physical interfaces. - - In the Internet protocol architecture, a transport protocol - instance ("entity") has no address of its own, but instead - uses a single Internet Protocol (IP) address. This has - implications for the IP, transport, and application layers, - and for the interfaces between them. In particular, the - application software may have to be aware of the multiple IP - addresses of a multihomed host; in other cases, the choice - can be made within the network software. - - 3.3.4.2 Multihoming Requirements - - The following general rules apply to the selection of an IP - source address for sending a datagram from a multihomed - - - -Internet Engineering Task Force [Page 61] - - - - -RFC1122 INTERNET LAYER October 1989 - - - host. - - (1) If the datagram is sent in response to a received - datagram, the source address for the response SHOULD be - the specific-destination address of the request. See - Sections 4.1.3.5 and 4.2.3.7 and the "General Issues" - section of [INTRO:1] for more specific requirements on - higher layers. - - Otherwise, a source address must be selected. - - (2) An application MUST be able to explicitly specify the - source address for initiating a connection or a - request. - - (3) In the absence of such a specification, the networking - software MUST choose a source address. Rules for this - choice are described below. - - - There are two key requirement issues related to multihoming: - - (A) A host MAY silently discard an incoming datagram whose - destination address does not correspond to the physical - interface through which it is received. - - (B) A host MAY restrict itself to sending (non-source- - routed) IP datagrams only through the physical - interface that corresponds to the IP source address of - the datagrams. - - - DISCUSSION: - Internet host implementors have used two different - conceptual models for multihoming, briefly summarized - in the following discussion. This document takes no - stand on which model is preferred; each seems to have a - place. This ambivalence is reflected in the issues (A) - and (B) being optional. - - o Strong ES Model - - The Strong ES (End System, i.e., host) model - emphasizes the host/gateway (ES/IS) distinction, - and would therefore substitute MUST for MAY in - issues (A) and (B) above. It tends to model a - multihomed host as a set of logical hosts within - the same physical host. - - - -Internet Engineering Task Force [Page 62] - - - - -RFC1122 INTERNET LAYER October 1989 - - - With respect to (A), proponents of the Strong ES - model note that automatic Internet routing - mechanisms could not route a datagram to a - physical interface that did not correspond to the - destination address. - - Under the Strong ES model, the route computation - for an outgoing datagram is the mapping: - - route(src IP addr, dest IP addr, TOS) - -> gateway - - Here the source address is included as a parameter - in order to select a gateway that is directly - reachable on the corresponding physical interface. - Note that this model logically requires that in - general there be at least one default gateway, and - preferably multiple defaults, for each IP source - address. - - o Weak ES Model - - This view de-emphasizes the ES/IS distinction, and - would therefore substitute MUST NOT for MAY in - issues (A) and (B). This model may be the more - natural one for hosts that wiretap gateway routing - protocols, and is necessary for hosts that have - embedded gateway functionality. - - The Weak ES Model may cause the Redirect mechanism - to fail. If a datagram is sent out a physical - interface that does not correspond to the - destination address, the first-hop gateway will - not realize when it needs to send a Redirect. On - the other hand, if the host has embedded gateway - functionality, then it has routing information - without listening to Redirects. - - In the Weak ES model, the route computation for an - outgoing datagram is the mapping: - - route(dest IP addr, TOS) -> gateway, interface - - - - - - - - - -Internet Engineering Task Force [Page 63] - - - - -RFC1122 INTERNET LAYER October 1989 - - - 3.3.4.3 Choosing a Source Address - - DISCUSSION: - When it sends an initial connection request (e.g., a - TCP "SYN" segment) or a datagram service request (e.g., - a UDP-based query), the transport layer on a multihomed - host needs to know which source address to use. If the - application does not specify it, the transport layer - must ask the IP layer to perform the conceptual - mapping: - - GET_SRCADDR(remote IP addr, TOS) - -> local IP address - - Here TOS is the Type-of-Service value (see Section - 3.2.1.6), and the result is the desired source address. - The following rules are suggested for implementing this - mapping: - - (a) If the remote Internet address lies on one of the - (sub-) nets to which the host is directly - connected, a corresponding source address may be - chosen, unless the corresponding interface is - known to be down. - - (b) The route cache may be consulted, to see if there - is an active route to the specified destination - network through any network interface; if so, a - local IP address corresponding to that interface - may be chosen. - - (c) The table of static routes, if any (see Section - 3.3.1.2) may be similarly consulted. - - (d) The default gateways may be consulted. If these - gateways are assigned to different interfaces, the - interface corresponding to the gateway with the - highest preference may be chosen. - - In the future, there may be a defined way for a - multihomed host to ask the gateways on all connected - networks for advice about the best network to use for a - given destination. - - IMPLEMENTATION: - It will be noted that this process is essentially the - same as datagram routing (see Section 3.3.1), and - therefore hosts may be able to combine the - - - -Internet Engineering Task Force [Page 64] - - - - -RFC1122 INTERNET LAYER October 1989 - - - implementation of the two functions. - - 3.3.5 Source Route Forwarding - - Subject to restrictions given below, a host MAY be able to act - as an intermediate hop in a source route, forwarding a source- - routed datagram to the next specified hop. - - However, in performing this gateway-like function, the host - MUST obey all the relevant rules for a gateway forwarding - source-routed datagrams [INTRO:2]. This includes the following - specific provisions, which override the corresponding host - provisions given earlier in this document: - - (A) TTL (ref. Section 3.2.1.7) - - The TTL field MUST be decremented and the datagram perhaps - discarded as specified for a gateway in [INTRO:2]. - - (B) ICMP Destination Unreachable (ref. Section 3.2.2.1) - - A host MUST be able to generate Destination Unreachable - messages with the following codes: - - 4 (Fragmentation Required but DF Set) when a source- - routed datagram cannot be fragmented to fit into the - target network; - - 5 (Source Route Failed) when a source-routed datagram - cannot be forwarded, e.g., because of a routing - problem or because the next hop of a strict source - route is not on a connected network. - - (C) IP Source Address (ref. Section 3.2.1.3) - - A source-routed datagram being forwarded MAY (and normally - will) have a source address that is not one of the IP - addresses of the forwarding host. - - (D) Record Route Option (ref. Section 3.2.1.8d) - - A host that is forwarding a source-routed datagram - containing a Record Route option MUST update that option, - if it has room. - - (E) Timestamp Option (ref. Section 3.2.1.8e) - - A host that is forwarding a source-routed datagram - - - -Internet Engineering Task Force [Page 65] - - - - -RFC1122 INTERNET LAYER October 1989 - - - containing a Timestamp Option MUST add the current - timestamp to that option, according to the rules for this - option. - - To define the rules restricting host forwarding of source- - routed datagrams, we use the term "local source-routing" if the - next hop will be through the same physical interface through - which the datagram arrived; otherwise, it is "non-local - source-routing". - - o A host is permitted to perform local source-routing - without restriction. - - o A host that supports non-local source-routing MUST have a - configurable switch to disable forwarding, and this switch - MUST default to disabled. - - o The host MUST satisfy all gateway requirements for - configurable policy filters [INTRO:2] restricting non- - local forwarding. - - If a host receives a datagram with an incomplete source route - but does not forward it for some reason, the host SHOULD return - an ICMP Destination Unreachable (code 5, Source Route Failed) - message, unless the datagram was itself an ICMP error message. - - 3.3.6 Broadcasts - - Section 3.2.1.3 defined the four standard IP broadcast address - forms: - - Limited Broadcast: {-1, -1} - - Directed Broadcast: {<Network-number>,-1} - - Subnet Directed Broadcast: - {<Network-number>,<Subnet-number>,-1} - - All-Subnets Directed Broadcast: {<Network-number>,-1,-1} - - A host MUST recognize any of these forms in the destination - address of an incoming datagram. - - There is a class of hosts* that use non-standard broadcast - address forms, substituting 0 for -1. All hosts SHOULD -_________________________ -*4.2BSD Unix and its derivatives, but not 4.3BSD. - - - - -Internet Engineering Task Force [Page 66] - - - - -RFC1122 INTERNET LAYER October 1989 - - - recognize and accept any of these non-standard broadcast - addresses as the destination address of an incoming datagram. - A host MAY optionally have a configuration option to choose the - 0 or the -1 form of broadcast address, for each physical - interface, but this option SHOULD default to the standard (-1) - form. - - When a host sends a datagram to a link-layer broadcast address, - the IP destination address MUST be a legal IP broadcast or IP - multicast address. - - A host SHOULD silently discard a datagram that is received via - a link-layer broadcast (see Section 2.4) but does not specify - an IP multicast or broadcast destination address. - - Hosts SHOULD use the Limited Broadcast address to broadcast to - a connected network. - - - DISCUSSION: - Using the Limited Broadcast address instead of a Directed - Broadcast address may improve system robustness. Problems - are often caused by machines that do not understand the - plethora of broadcast addresses (see Section 3.2.1.3), or - that may have different ideas about which broadcast - addresses are in use. The prime example of the latter is - machines that do not understand subnetting but are - attached to a subnetted net. Sending a Subnet Broadcast - for the connected network will confuse those machines, - which will see it as a message to some other host. - - There has been discussion on whether a datagram addressed - to the Limited Broadcast address ought to be sent from all - the interfaces of a multihomed host. This specification - takes no stand on the issue. - - 3.3.7 IP Multicasting - - A host SHOULD support local IP multicasting on all connected - networks for which a mapping from Class D IP addresses to - link-layer addresses has been specified (see below). Support - for local IP multicasting includes sending multicast datagrams, - joining multicast groups and receiving multicast datagrams, and - leaving multicast groups. This implies support for all of - [IP:4] except the IGMP protocol itself, which is OPTIONAL. - - - - - - -Internet Engineering Task Force [Page 67] - - - - -RFC1122 INTERNET LAYER October 1989 - - - DISCUSSION: - IGMP provides gateways that are capable of multicast - routing with the information required to support IP - multicasting across multiple networks. At this time, - multicast-routing gateways are in the experimental stage - and are not widely available. For hosts that are not - connected to networks with multicast-routing gateways or - that do not need to receive multicast datagrams - originating on other networks, IGMP serves no purpose and - is therefore optional for now. However, the rest of - [IP:4] is currently recommended for the purpose of - providing IP-layer access to local network multicast - addressing, as a preferable alternative to local broadcast - addressing. It is expected that IGMP will become - recommended at some future date, when multicast-routing - gateways have become more widely available. - - If IGMP is not implemented, a host SHOULD still join the "all- - hosts" group (224.0.0.1) when the IP layer is initialized and - remain a member for as long as the IP layer is active. - - DISCUSSION: - Joining the "all-hosts" group will support strictly local - uses of multicasting, e.g., a gateway discovery protocol, - even if IGMP is not implemented. - - The mapping of IP Class D addresses to local addresses is - currently specified for the following types of networks: - - o Ethernet/IEEE 802.3, as defined in [IP:4]. - - o Any network that supports broadcast but not multicast, - addressing: all IP Class D addresses map to the local - broadcast address. - - o Any type of point-to-point link (e.g., SLIP or HDLC - links): no mapping required. All IP multicast datagrams - are sent as-is, inside the local framing. - - Mappings for other types of networks will be specified in the - future. - - A host SHOULD provide a way for higher-layer protocols or - applications to determine which of the host's connected - network(s) support IP multicast addressing. - - - - - - -Internet Engineering Task Force [Page 68] - - - - -RFC1122 INTERNET LAYER October 1989 - - - 3.3.8 Error Reporting - - Wherever practical, hosts MUST return ICMP error datagrams on - detection of an error, except in those cases where returning an - ICMP error message is specifically prohibited. - - DISCUSSION: - A common phenomenon in datagram networks is the "black - hole disease": datagrams are sent out, but nothing comes - back. Without any error datagrams, it is difficult for - the user to figure out what the problem is. - - 3.4 INTERNET/TRANSPORT LAYER INTERFACE - - The interface between the IP layer and the transport layer MUST - provide full access to all the mechanisms of the IP layer, - including options, Type-of-Service, and Time-to-Live. The - transport layer MUST either have mechanisms to set these interface - parameters, or provide a path to pass them through from an - application, or both. - - DISCUSSION: - Applications are urged to make use of these mechanisms where - applicable, even when the mechanisms are not currently - effective in the Internet (e.g., TOS). This will allow these - mechanisms to be immediately useful when they do become - effective, without a large amount of retrofitting of host - software. - - We now describe a conceptual interface between the transport layer - and the IP layer, as a set of procedure calls. This is an - extension of the information in Section 3.3 of RFC-791 [IP:1]. - - - * Send Datagram - - SEND(src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt - => result ) - - where the parameters are defined in RFC-791. Passing an Id - parameter is optional; see Section 3.2.1.5. - - - * Receive Datagram - - RECV(BufPTR, prot - => result, src, dst, SpecDest, TOS, len, opt) - - - - -Internet Engineering Task Force [Page 69] - - - - -RFC1122 INTERNET LAYER October 1989 - - - All the parameters are defined in RFC-791, except for: - - SpecDest = specific-destination address of datagram - (defined in Section 3.2.1.3) - - The result parameter dst contains the datagram's destination - address. Since this may be a broadcast or multicast address, - the SpecDest parameter (not shown in RFC-791) MUST be passed. - The parameter opt contains all the IP options received in the - datagram; these MUST also be passed to the transport layer. - - - * Select Source Address - - GET_SRCADDR(remote, TOS) -> local - - remote = remote IP address - TOS = Type-of-Service - local = local IP address - - See Section 3.3.4.3. - - - * Find Maximum Datagram Sizes - - GET_MAXSIZES(local, remote, TOS) -> MMS_R, MMS_S - - MMS_R = maximum receive transport-message size. - MMS_S = maximum send transport-message size. - (local, remote, TOS defined above) - - See Sections 3.3.2 and 3.3.3. - - - * Advice on Delivery Success - - ADVISE_DELIVPROB(sense, local, remote, TOS) - - Here the parameter sense is a 1-bit flag indicating whether - positive or negative advice is being given; see the - discussion in Section 3.3.1.4. The other parameters were - defined earlier. - - - * Send ICMP Message - - SEND_ICMP(src, dst, TOS, TTL, BufPTR, len, Id, DF, opt) - -> result - - - -Internet Engineering Task Force [Page 70] - - - - -RFC1122 INTERNET LAYER October 1989 - - - (Parameters defined in RFC-791). - - Passing an Id parameter is optional; see Section 3.2.1.5. - The transport layer MUST be able to send certain ICMP - messages: Port Unreachable or any of the query-type - messages. This function could be considered to be a special - case of the SEND() call, of course; we describe it separately - for clarity. - - - * Receive ICMP Message - - RECV_ICMP(BufPTR ) -> result, src, dst, len, opt - - (Parameters defined in RFC-791). - - The IP layer MUST pass certain ICMP messages up to the - appropriate transport-layer routine. This function could be - considered to be a special case of the RECV() call, of - course; we describe it separately for clarity. - - For an ICMP error message, the data that is passed up MUST - include the original Internet header plus all the octets of - the original message that are included in the ICMP message. - This data will be used by the transport layer to locate the - connection state information, if any. - - In particular, the following ICMP messages are to be passed - up: - - o Destination Unreachable - - o Source Quench - - o Echo Reply (to ICMP user interface, unless the Echo - Request originated in the IP layer) - - o Timestamp Reply (to ICMP user interface) - - o Time Exceeded - - - DISCUSSION: - In the future, there may be additions to this interface to - pass path data (see Section 3.3.1.3) between the IP and - transport layers. - - - - - -Internet Engineering Task Force [Page 71] - - - - -RFC1122 INTERNET LAYER October 1989 - - - 3.5 INTERNET LAYER REQUIREMENTS SUMMARY - - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e --------------------------------------------------|--------|-|-|-|-|-|-- - | | | | | | | -Implement IP and ICMP |3.1 |x| | | | | -Handle remote multihoming in application layer |3.1 |x| | | | | -Support local multihoming |3.1 | | |x| | | -Meet gateway specs if forward datagrams |3.1 |x| | | | | -Configuration switch for embedded gateway |3.1 |x| | | | |1 - Config switch default to non-gateway |3.1 |x| | | | |1 - Auto-config based on number of interfaces |3.1 | | | | |x|1 -Able to log discarded datagrams |3.1 | |x| | | | - Record in counter |3.1 | |x| | | | - | | | | | | | -Silently discard Version != 4 |3.2.1.1 |x| | | | | -Verify IP checksum, silently discard bad dgram |3.2.1.2 |x| | | | | -Addressing: | | | | | | | - Subnet addressing (RFC-950) |3.2.1.3 |x| | | | | - Src address must be host's own IP address |3.2.1.3 |x| | | | | - Silently discard datagram with bad dest addr |3.2.1.3 |x| | | | | - Silently discard datagram with bad src addr |3.2.1.3 |x| | | | | -Support reassembly |3.2.1.4 |x| | | | | -Retain same Id field in identical datagram |3.2.1.5 | | |x| | | - | | | | | | | -TOS: | | | | | | | - Allow transport layer to set TOS |3.2.1.6 |x| | | | | - Pass received TOS up to transport layer |3.2.1.6 | |x| | | | - Use RFC-795 link-layer mappings for TOS |3.2.1.6 | | | |x| | -TTL: | | | | | | | - Send packet with TTL of 0 |3.2.1.7 | | | | |x| - Discard received packets with TTL < 2 |3.2.1.7 | | | | |x| - Allow transport layer to set TTL |3.2.1.7 |x| | | | | - Fixed TTL is configurable |3.2.1.7 |x| | | | | - | | | | | | | -IP Options: | | | | | | | - Allow transport layer to send IP options |3.2.1.8 |x| | | | | - Pass all IP options rcvd to higher layer |3.2.1.8 |x| | | | | - - - -Internet Engineering Task Force [Page 72] - - - - -RFC1122 INTERNET LAYER October 1989 - - - IP layer silently ignore unknown options |3.2.1.8 |x| | | | | - Security option |3.2.1.8a| | |x| | | - Send Stream Identifier option |3.2.1.8b| | | |x| | - Silently ignore Stream Identifer option |3.2.1.8b|x| | | | | - Record Route option |3.2.1.8d| | |x| | | - Timestamp option |3.2.1.8e| | |x| | | -Source Route Option: | | | | | | | - Originate & terminate Source Route options |3.2.1.8c|x| | | | | - Datagram with completed SR passed up to TL |3.2.1.8c|x| | | | | - Build correct (non-redundant) return route |3.2.1.8c|x| | | | | - Send multiple SR options in one header |3.2.1.8c| | | | |x| - | | | | | | | -ICMP: | | | | | | | - Silently discard ICMP msg with unknown type |3.2.2 |x| | | | | - Include more than 8 octets of orig datagram |3.2.2 | | |x| | | - Included octets same as received |3.2.2 |x| | | | | - Demux ICMP Error to transport protocol |3.2.2 |x| | | | | - Send ICMP error message with TOS=0 |3.2.2 | |x| | | | - Send ICMP error message for: | | | | | | | - - ICMP error msg |3.2.2 | | | | |x| - - IP b'cast or IP m'cast |3.2.2 | | | | |x| - - Link-layer b'cast |3.2.2 | | | | |x| - - Non-initial fragment |3.2.2 | | | | |x| - - Datagram with non-unique src address |3.2.2 | | | | |x| - Return ICMP error msgs (when not prohibited) |3.3.8 |x| | | | | - | | | | | | | - Dest Unreachable: | | | | | | | - Generate Dest Unreachable (code 2/3) |3.2.2.1 | |x| | | | - Pass ICMP Dest Unreachable to higher layer |3.2.2.1 |x| | | | | - Higher layer act on Dest Unreach |3.2.2.1 | |x| | | | - Interpret Dest Unreach as only hint |3.2.2.1 |x| | | | | - Redirect: | | | | | | | - Host send Redirect |3.2.2.2 | | | |x| | - Update route cache when recv Redirect |3.2.2.2 |x| | | | | - Handle both Host and Net Redirects |3.2.2.2 |x| | | | | - Discard illegal Redirect |3.2.2.2 | |x| | | | - Source Quench: | | | | | | | - Send Source Quench if buffering exceeded |3.2.2.3 | | |x| | | - Pass Source Quench to higher layer |3.2.2.3 |x| | | | | - Higher layer act on Source Quench |3.2.2.3 | |x| | | | - Time Exceeded: pass to higher layer |3.2.2.4 |x| | | | | - Parameter Problem: | | | | | | | - Send Parameter Problem messages |3.2.2.5 | |x| | | | - Pass Parameter Problem to higher layer |3.2.2.5 |x| | | | | - Report Parameter Problem to user |3.2.2.5 | | |x| | | - | | | | | | | - ICMP Echo Request or Reply: | | | | | | | - Echo server and Echo client |3.2.2.6 |x| | | | | - - - -Internet Engineering Task Force [Page 73] - - - - -RFC1122 INTERNET LAYER October 1989 - - - Echo client |3.2.2.6 | |x| | | | - Discard Echo Request to broadcast address |3.2.2.6 | | |x| | | - Discard Echo Request to multicast address |3.2.2.6 | | |x| | | - Use specific-dest addr as Echo Reply src |3.2.2.6 |x| | | | | - Send same data in Echo Reply |3.2.2.6 |x| | | | | - Pass Echo Reply to higher layer |3.2.2.6 |x| | | | | - Reflect Record Route, Time Stamp options |3.2.2.6 | |x| | | | - Reverse and reflect Source Route option |3.2.2.6 |x| | | | | - | | | | | | | - ICMP Information Request or Reply: |3.2.2.7 | | | |x| | - ICMP Timestamp and Timestamp Reply: |3.2.2.8 | | |x| | | - Minimize delay variability |3.2.2.8 | |x| | | |1 - Silently discard b'cast Timestamp |3.2.2.8 | | |x| | |1 - Silently discard m'cast Timestamp |3.2.2.8 | | |x| | |1 - Use specific-dest addr as TS Reply src |3.2.2.8 |x| | | | |1 - Reflect Record Route, Time Stamp options |3.2.2.6 | |x| | | |1 - Reverse and reflect Source Route option |3.2.2.8 |x| | | | |1 - Pass Timestamp Reply to higher layer |3.2.2.8 |x| | | | |1 - Obey rules for "standard value" |3.2.2.8 |x| | | | |1 - | | | | | | | - ICMP Address Mask Request and Reply: | | | | | | | - Addr Mask source configurable |3.2.2.9 |x| | | | | - Support static configuration of addr mask |3.2.2.9 |x| | | | | - Get addr mask dynamically during booting |3.2.2.9 | | |x| | | - Get addr via ICMP Addr Mask Request/Reply |3.2.2.9 | | |x| | | - Retransmit Addr Mask Req if no Reply |3.2.2.9 |x| | | | |3 - Assume default mask if no Reply |3.2.2.9 | |x| | | |3 - Update address mask from first Reply only |3.2.2.9 |x| | | | |3 - Reasonableness check on Addr Mask |3.2.2.9 | |x| | | | - Send unauthorized Addr Mask Reply msgs |3.2.2.9 | | | | |x| - Explicitly configured to be agent |3.2.2.9 |x| | | | | - Static config=> Addr-Mask-Authoritative flag |3.2.2.9 | |x| | | | - Broadcast Addr Mask Reply when init. |3.2.2.9 |x| | | | |3 - | | | | | | | -ROUTING OUTBOUND DATAGRAMS: | | | | | | | - Use address mask in local/remote decision |3.3.1.1 |x| | | | | - Operate with no gateways on conn network |3.3.1.1 |x| | | | | - Maintain "route cache" of next-hop gateways |3.3.1.2 |x| | | | | - Treat Host and Net Redirect the same |3.3.1.2 | |x| | | | - If no cache entry, use default gateway |3.3.1.2 |x| | | | | - Support multiple default gateways |3.3.1.2 |x| | | | | - Provide table of static routes |3.3.1.2 | | |x| | | - Flag: route overridable by Redirects |3.3.1.2 | | |x| | | - Key route cache on host, not net address |3.3.1.3 | | |x| | | - Include TOS in route cache |3.3.1.3 | |x| | | | - | | | | | | | - Able to detect failure of next-hop gateway |3.3.1.4 |x| | | | | - Assume route is good forever |3.3.1.4 | | | |x| | - - - -Internet Engineering Task Force [Page 74] - - - - -RFC1122 INTERNET LAYER October 1989 - - - Ping gateways continuously |3.3.1.4 | | | | |x| - Ping only when traffic being sent |3.3.1.4 |x| | | | | - Ping only when no positive indication |3.3.1.4 |x| | | | | - Higher and lower layers give advice |3.3.1.4 | |x| | | | - Switch from failed default g'way to another |3.3.1.5 |x| | | | | - Manual method of entering config info |3.3.1.6 |x| | | | | - | | | | | | | -REASSEMBLY and FRAGMENTATION: | | | | | | | - Able to reassemble incoming datagrams |3.3.2 |x| | | | | - At least 576 byte datagrams |3.3.2 |x| | | | | - EMTU_R configurable or indefinite |3.3.2 | |x| | | | - Transport layer able to learn MMS_R |3.3.2 |x| | | | | - Send ICMP Time Exceeded on reassembly timeout |3.3.2 |x| | | | | - Fixed reassembly timeout value |3.3.2 | |x| | | | - | | | | | | | - Pass MMS_S to higher layers |3.3.3 |x| | | | | - Local fragmentation of outgoing packets |3.3.3 | | |x| | | - Else don't send bigger than MMS_S |3.3.3 |x| | | | | - Send max 576 to off-net destination |3.3.3 | |x| | | | - All-Subnets-MTU configuration flag |3.3.3 | | |x| | | - | | | | | | | -MULTIHOMING: | | | | | | | - Reply with same addr as spec-dest addr |3.3.4.2 | |x| | | | - Allow application to choose local IP addr |3.3.4.2 |x| | | | | - Silently discard d'gram in "wrong" interface |3.3.4.2 | | |x| | | - Only send d'gram through "right" interface |3.3.4.2 | | |x| | |4 - | | | | | | | -SOURCE-ROUTE FORWARDING: | | | | | | | - Forward datagram with Source Route option |3.3.5 | | |x| | |1 - Obey corresponding gateway rules |3.3.5 |x| | | | |1 - Update TTL by gateway rules |3.3.5 |x| | | | |1 - Able to generate ICMP err code 4, 5 |3.3.5 |x| | | | |1 - IP src addr not local host |3.3.5 | | |x| | |1 - Update Timestamp, Record Route options |3.3.5 |x| | | | |1 - Configurable switch for non-local SRing |3.3.5 |x| | | | |1 - Defaults to OFF |3.3.5 |x| | | | |1 - Satisfy gwy access rules for non-local SRing |3.3.5 |x| | | | |1 - If not forward, send Dest Unreach (cd 5) |3.3.5 | |x| | | |2 - | | | | | | | -BROADCAST: | | | | | | | - Broadcast addr as IP source addr |3.2.1.3 | | | | |x| - Receive 0 or -1 broadcast formats OK |3.3.6 | |x| | | | - Config'ble option to send 0 or -1 b'cast |3.3.6 | | |x| | | - Default to -1 broadcast |3.3.6 | |x| | | | - Recognize all broadcast address formats |3.3.6 |x| | | | | - Use IP b'cast/m'cast addr in link-layer b'cast |3.3.6 |x| | | | | - Silently discard link-layer-only b'cast dg's |3.3.6 | |x| | | | - Use Limited Broadcast addr for connected net |3.3.6 | |x| | | | - - - -Internet Engineering Task Force [Page 75] - - - - -RFC1122 INTERNET LAYER October 1989 - - - | | | | | | | -MULTICAST: | | | | | | | - Support local IP multicasting (RFC-1112) |3.3.7 | |x| | | | - Support IGMP (RFC-1112) |3.3.7 | | |x| | | - Join all-hosts group at startup |3.3.7 | |x| | | | - Higher layers learn i'face m'cast capability |3.3.7 | |x| | | | - | | | | | | | -INTERFACE: | | | | | | | - Allow transport layer to use all IP mechanisms |3.4 |x| | | | | - Pass interface ident up to transport layer |3.4 |x| | | | | - Pass all IP options up to transport layer |3.4 |x| | | | | - Transport layer can send certain ICMP messages |3.4 |x| | | | | - Pass spec'd ICMP messages up to transp. layer |3.4 |x| | | | | - Include IP hdr+8 octets or more from orig. |3.4 |x| | | | | - Able to leap tall buildings at a single bound |3.5 | |x| | | | - -Footnotes: - -(1) Only if feature is implemented. - -(2) This requirement is overruled if datagram is an ICMP error message. - -(3) Only if feature is implemented and is configured "on". - -(4) Unless has embedded gateway functionality or is source routed. - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 76] - - - - -RFC1122 TRANSPORT LAYER -- UDP October 1989 - - -4. TRANSPORT PROTOCOLS - - 4.1 USER DATAGRAM PROTOCOL -- UDP - - 4.1.1 INTRODUCTION - - The User Datagram Protocol UDP [UDP:1] offers only a minimal - transport service -- non-guaranteed datagram delivery -- and - gives applications direct access to the datagram service of the - IP layer. UDP is used by applications that do not require the - level of service of TCP or that wish to use communications - services (e.g., multicast or broadcast delivery) not available - from TCP. - - UDP is almost a null protocol; the only services it provides - over IP are checksumming of data and multiplexing by port - number. Therefore, an application program running over UDP - must deal directly with end-to-end communication problems that - a connection-oriented protocol would have handled -- e.g., - retransmission for reliable delivery, packetization and - reassembly, flow control, congestion avoidance, etc., when - these are required. The fairly complex coupling between IP and - TCP will be mirrored in the coupling between UDP and many - applications using UDP. - - 4.1.2 PROTOCOL WALK-THROUGH - - There are no known errors in the specification of UDP. - - 4.1.3 SPECIFIC ISSUES - - 4.1.3.1 Ports - - UDP well-known ports follow the same rules as TCP well-known - ports; see Section 4.2.2.1 below. - - If a datagram arrives addressed to a UDP port for which - there is no pending LISTEN call, UDP SHOULD send an ICMP - Port Unreachable message. - - 4.1.3.2 IP Options - - UDP MUST pass any IP option that it receives from the IP - layer transparently to the application layer. - - An application MUST be able to specify IP options to be sent - in its UDP datagrams, and UDP MUST pass these options to the - IP layer. - - - -Internet Engineering Task Force [Page 77] - - - - -RFC1122 TRANSPORT LAYER -- UDP October 1989 - - - DISCUSSION: - At present, the only options that need be passed - through UDP are Source Route, Record Route, and Time - Stamp. However, new options may be defined in the - future, and UDP need not and should not make any - assumptions about the format or content of options it - passes to or from the application; an exception to this - might be an IP-layer security option. - - An application based on UDP will need to obtain a - source route from a request datagram and supply a - reversed route for sending the corresponding reply. - - 4.1.3.3 ICMP Messages - - UDP MUST pass to the application layer all ICMP error - messages that it receives from the IP layer. Conceptually - at least, this may be accomplished with an upcall to the - ERROR_REPORT routine (see Section 4.2.4.1). - - DISCUSSION: - Note that ICMP error messages resulting from sending a - UDP datagram are received asynchronously. A UDP-based - application that wants to receive ICMP error messages - is responsible for maintaining the state necessary to - demultiplex these messages when they arrive; for - example, the application may keep a pending receive - operation for this purpose. The application is also - responsible to avoid confusion from a delayed ICMP - error message resulting from an earlier use of the same - port(s). - - 4.1.3.4 UDP Checksums - - A host MUST implement the facility to generate and validate - UDP checksums. An application MAY optionally be able to - control whether a UDP checksum will be generated, but it - MUST default to checksumming on. - - If a UDP datagram is received with a checksum that is non- - zero and invalid, UDP MUST silently discard the datagram. - An application MAY optionally be able to control whether UDP - datagrams without checksums should be discarded or passed to - the application. - - DISCUSSION: - Some applications that normally run only across local - area networks have chosen to turn off UDP checksums for - - - -Internet Engineering Task Force [Page 78] - - - - -RFC1122 TRANSPORT LAYER -- UDP October 1989 - - - efficiency. As a result, numerous cases of undetected - errors have been reported. The advisability of ever - turning off UDP checksumming is very controversial. - - IMPLEMENTATION: - There is a common implementation error in UDP - checksums. Unlike the TCP checksum, the UDP checksum - is optional; the value zero is transmitted in the - checksum field of a UDP header to indicate the absence - of a checksum. If the transmitter really calculates a - UDP checksum of zero, it must transmit the checksum as - all 1's (65535). No special action is required at the - receiver, since zero and 65535 are equivalent in 1's - complement arithmetic. - - 4.1.3.5 UDP Multihoming - - When a UDP datagram is received, its specific-destination - address MUST be passed up to the application layer. - - An application program MUST be able to specify the IP source - address to be used for sending a UDP datagram or to leave it - unspecified (in which case the networking software will - choose an appropriate source address). There SHOULD be a - way to communicate the chosen source address up to the - application layer (e.g, so that the application can later - receive a reply datagram only from the corresponding - interface). - - DISCUSSION: - A request/response application that uses UDP should use - a source address for the response that is the same as - the specific destination address of the request. See - the "General Issues" section of [INTRO:1]. - - 4.1.3.6 Invalid Addresses - - A UDP datagram received with an invalid IP source address - (e.g., a broadcast or multicast address) must be discarded - by UDP or by the IP layer (see Section 3.2.1.3). - - When a host sends a UDP datagram, the source address MUST be - (one of) the IP address(es) of the host. - - 4.1.4 UDP/APPLICATION LAYER INTERFACE - - The application interface to UDP MUST provide the full services - of the IP/transport interface described in Section 3.4 of this - - - -Internet Engineering Task Force [Page 79] - - - - -RFC1122 TRANSPORT LAYER -- UDP October 1989 - - - document. Thus, an application using UDP needs the functions - of the GET_SRCADDR(), GET_MAXSIZES(), ADVISE_DELIVPROB(), and - RECV_ICMP() calls described in Section 3.4. For example, - GET_MAXSIZES() can be used to learn the effective maximum UDP - maximum datagram size for a particular {interface,remote - host,TOS} triplet. - - An application-layer program MUST be able to set the TTL and - TOS values as well as IP options for sending a UDP datagram, - and these values must be passed transparently to the IP layer. - UDP MAY pass the received TOS up to the application layer. - - 4.1.5 UDP REQUIREMENTS SUMMARY - - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e --------------------------------------------------|--------|-|-|-|-|-|-- - | | | | | | | - UDP | | | | | | | --------------------------------------------------|--------|-|-|-|-|-|-- - | | | | | | | -UDP send Port Unreachable |4.1.3.1 | |x| | | | - | | | | | | | -IP Options in UDP | | | | | | | - - Pass rcv'd IP options to applic layer |4.1.3.2 |x| | | | | - - Applic layer can specify IP options in Send |4.1.3.2 |x| | | | | - - UDP passes IP options down to IP layer |4.1.3.2 |x| | | | | - | | | | | | | -Pass ICMP msgs up to applic layer |4.1.3.3 |x| | | | | - | | | | | | | -UDP checksums: | | | | | | | - - Able to generate/check checksum |4.1.3.4 |x| | | | | - - Silently discard bad checksum |4.1.3.4 |x| | | | | - - Sender Option to not generate checksum |4.1.3.4 | | |x| | | - - Default is to checksum |4.1.3.4 |x| | | | | - - Receiver Option to require checksum |4.1.3.4 | | |x| | | - | | | | | | | -UDP Multihoming | | | | | | | - - Pass spec-dest addr to application |4.1.3.5 |x| | | | | - - - -Internet Engineering Task Force [Page 80] - - - - -RFC1122 TRANSPORT LAYER -- UDP October 1989 - - - - Applic layer can specify Local IP addr |4.1.3.5 |x| | | | | - - Applic layer specify wild Local IP addr |4.1.3.5 |x| | | | | - - Applic layer notified of Local IP addr used |4.1.3.5 | |x| | | | - | | | | | | | -Bad IP src addr silently discarded by UDP/IP |4.1.3.6 |x| | | | | -Only send valid IP source address |4.1.3.6 |x| | | | | -UDP Application Interface Services | | | | | | | -Full IP interface of 3.4 for application |4.1.4 |x| | | | | - - Able to spec TTL, TOS, IP opts when send dg |4.1.4 |x| | | | | - - Pass received TOS up to applic layer |4.1.4 | | |x| | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 81] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - 4.2 TRANSMISSION CONTROL PROTOCOL -- TCP - - 4.2.1 INTRODUCTION - - The Transmission Control Protocol TCP [TCP:1] is the primary - virtual-circuit transport protocol for the Internet suite. TCP - provides reliable, in-sequence delivery of a full-duplex stream - of octets (8-bit bytes). TCP is used by those applications - needing reliable, connection-oriented transport service, e.g., - mail (SMTP), file transfer (FTP), and virtual terminal service - (Telnet); requirements for these application-layer protocols - are described in [INTRO:1]. - - 4.2.2 PROTOCOL WALK-THROUGH - - 4.2.2.1 Well-Known Ports: RFC-793 Section 2.7 - - DISCUSSION: - TCP reserves port numbers in the range 0-255 for - "well-known" ports, used to access services that are - standardized across the Internet. The remainder of the - port space can be freely allocated to application - processes. Current well-known port definitions are - listed in the RFC entitled "Assigned Numbers" - [INTRO:6]. A prerequisite for defining a new well- - known port is an RFC documenting the proposed service - in enough detail to allow new implementations. - - Some systems extend this notion by adding a third - subdivision of the TCP port space: reserved ports, - which are generally used for operating-system-specific - services. For example, reserved ports might fall - between 256 and some system-dependent upper limit. - Some systems further choose to protect well-known and - reserved ports by permitting only privileged users to - open TCP connections with those port values. This is - perfectly reasonable as long as the host does not - assume that all hosts protect their low-numbered ports - in this manner. - - 4.2.2.2 Use of Push: RFC-793 Section 2.8 - - When an application issues a series of SEND calls without - setting the PUSH flag, the TCP MAY aggregate the data - internally without sending it. Similarly, when a series of - segments is received without the PSH bit, a TCP MAY queue - the data internally without passing it to the receiving - application. - - - -Internet Engineering Task Force [Page 82] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - The PSH bit is not a record marker and is independent of - segment boundaries. The transmitter SHOULD collapse - successive PSH bits when it packetizes data, to send the - largest possible segment. - - A TCP MAY implement PUSH flags on SEND calls. If PUSH flags - are not implemented, then the sending TCP: (1) must not - buffer data indefinitely, and (2) MUST set the PSH bit in - the last buffered segment (i.e., when there is no more - queued data to be sent). - - The discussion in RFC-793 on pages 48, 50, and 74 - erroneously implies that a received PSH flag must be passed - to the application layer. Passing a received PSH flag to - the application layer is now OPTIONAL. - - An application program is logically required to set the PUSH - flag in a SEND call whenever it needs to force delivery of - the data to avoid a communication deadlock. However, a TCP - SHOULD send a maximum-sized segment whenever possible, to - improve performance (see Section 4.2.3.4). - - DISCUSSION: - When the PUSH flag is not implemented on SEND calls, - i.e., when the application/TCP interface uses a pure - streaming model, responsibility for aggregating any - tiny data fragments to form reasonable sized segments - is partially borne by the application layer. - - Generally, an interactive application protocol must set - the PUSH flag at least in the last SEND call in each - command or response sequence. A bulk transfer protocol - like FTP should set the PUSH flag on the last segment - of a file or when necessary to prevent buffer deadlock. - - At the receiver, the PSH bit forces buffered data to be - delivered to the application (even if less than a full - buffer has been received). Conversely, the lack of a - PSH bit can be used to avoid unnecessary wakeup calls - to the application process; this can be an important - performance optimization for large timesharing hosts. - Passing the PSH bit to the receiving application allows - an analogous optimization within the application. - - 4.2.2.3 Window Size: RFC-793 Section 3.1 - - The window size MUST be treated as an unsigned number, or - else large window sizes will appear like negative windows - - - -Internet Engineering Task Force [Page 83] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - and TCP will not work. It is RECOMMENDED that - implementations reserve 32-bit fields for the send and - receive window sizes in the connection record and do all - window computations with 32 bits. - - DISCUSSION: - It is known that the window field in the TCP header is - too small for high-speed, long-delay paths. - Experimental TCP options have been defined to extend - the window size; see for example [TCP:11]. In - anticipation of the adoption of such an extension, TCP - implementors should treat windows as 32 bits. - - 4.2.2.4 Urgent Pointer: RFC-793 Section 3.1 - - The second sentence is in error: the urgent pointer points - to the sequence number of the LAST octet (not LAST+1) in a - sequence of urgent data. The description on page 56 (last - sentence) is correct. - - A TCP MUST support a sequence of urgent data of any length. - - A TCP MUST inform the application layer asynchronously - whenever it receives an Urgent pointer and there was - previously no pending urgent data, or whenever the Urgent - pointer advances in the data stream. There MUST be a way - for the application to learn how much urgent data remains to - be read from the connection, or at least to determine - whether or not more urgent data remains to be read. - - DISCUSSION: - Although the Urgent mechanism may be used for any - application, it is normally used to send "interrupt"- - type commands to a Telnet program (see "Using Telnet - Synch Sequence" section in [INTRO:1]). - - The asynchronous or "out-of-band" notification will - allow the application to go into "urgent mode", reading - data from the TCP connection. This allows control - commands to be sent to an application whose normal - input buffers are full of unprocessed data. - - IMPLEMENTATION: - The generic ERROR-REPORT() upcall described in Section - 4.2.4.1 is a possible mechanism for informing the - application of the arrival of urgent data. - - - - - -Internet Engineering Task Force [Page 84] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - 4.2.2.5 TCP Options: RFC-793 Section 3.1 - - A TCP MUST be able to receive a TCP option in any segment. - A TCP MUST ignore without error any TCP option it does not - implement, assuming that the option has a length field (all - TCP options defined in the future will have length fields). - TCP MUST be prepared to handle an illegal option length - (e.g., zero) without crashing; a suggested procedure is to - reset the connection and log the reason. - - 4.2.2.6 Maximum Segment Size Option: RFC-793 Section 3.1 - - TCP MUST implement both sending and receiving the Maximum - Segment Size option [TCP:4]. - - TCP SHOULD send an MSS (Maximum Segment Size) option in - every SYN segment when its receive MSS differs from the - default 536, and MAY send it always. - - If an MSS option is not received at connection setup, TCP - MUST assume a default send MSS of 536 (576-40) [TCP:4]. - - The maximum size of a segment that TCP really sends, the - "effective send MSS," MUST be the smaller of the send MSS - (which reflects the available reassembly buffer size at the - remote host) and the largest size permitted by the IP layer: - - Eff.snd.MSS = - - min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize - - where: - - * SendMSS is the MSS value received from the remote host, - or the default 536 if no MSS option is received. - - * MMS_S is the maximum size for a transport-layer message - that TCP may send. - - * TCPhdrsize is the size of the TCP header; this is - normally 20, but may be larger if TCP options are to be - sent. - - * IPoptionsize is the size of any IP options that TCP - will pass to the IP layer with the current message. - - - The MSS value to be sent in an MSS option must be less than - - - -Internet Engineering Task Force [Page 85] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - or equal to: - - MMS_R - 20 - - where MMS_R is the maximum size for a transport-layer - message that can be received (and reassembled). TCP obtains - MMS_R and MMS_S from the IP layer; see the generic call - GET_MAXSIZES in Section 3.4. - - DISCUSSION: - The choice of TCP segment size has a strong effect on - performance. Larger segments increase throughput by - amortizing header size and per-datagram processing - overhead over more data bytes; however, if the packet - is so large that it causes IP fragmentation, efficiency - drops sharply if any fragments are lost [IP:9]. - - Some TCP implementations send an MSS option only if the - destination host is on a non-connected network. - However, in general the TCP layer may not have the - appropriate information to make this decision, so it is - preferable to leave to the IP layer the task of - determining a suitable MTU for the Internet path. We - therefore recommend that TCP always send the option (if - not 536) and that the IP layer determine MMS_R as - specified in 3.3.3 and 3.4. A proposed IP-layer - mechanism to measure the MTU would then modify the IP - layer without changing TCP. - - 4.2.2.7 TCP Checksum: RFC-793 Section 3.1 - - Unlike the UDP checksum (see Section 4.1.3.4), the TCP - checksum is never optional. The sender MUST generate it and - the receiver MUST check it. - - 4.2.2.8 TCP Connection State Diagram: RFC-793 Section 3.2, - page 23 - - There are several problems with this diagram: - - (a) The arrow from SYN-SENT to SYN-RCVD should be labeled - with "snd SYN,ACK", to agree with the text on page 68 - and with Figure 8. - - (b) There could be an arrow from SYN-RCVD state to LISTEN - state, conditioned on receiving a RST after a passive - open (see text page 70). - - - - -Internet Engineering Task Force [Page 86] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - (c) It is possible to go directly from FIN-WAIT-1 to the - TIME-WAIT state (see page 75 of the spec). - - - 4.2.2.9 Initial Sequence Number Selection: RFC-793 Section - 3.3, page 27 - - A TCP MUST use the specified clock-driven selection of - initial sequence numbers. - - 4.2.2.10 Simultaneous Open Attempts: RFC-793 Section 3.4, page - 32 - - There is an error in Figure 8: the packet on line 7 should - be identical to the packet on line 5. - - A TCP MUST support simultaneous open attempts. - - DISCUSSION: - It sometimes surprises implementors that if two - applications attempt to simultaneously connect to each - other, only one connection is generated instead of two. - This was an intentional design decision; don't try to - "fix" it. - - 4.2.2.11 Recovery from Old Duplicate SYN: RFC-793 Section 3.4, - page 33 - - Note that a TCP implementation MUST keep track of whether a - connection has reached SYN_RCVD state as the result of a - passive OPEN or an active OPEN. - - 4.2.2.12 RST Segment: RFC-793 Section 3.4 - - A TCP SHOULD allow a received RST segment to include data. - - DISCUSSION - It has been suggested that a RST segment could contain - ASCII text that encoded and explained the cause of the - RST. No standard has yet been established for such - data. - - 4.2.2.13 Closing a Connection: RFC-793 Section 3.5 - - A TCP connection may terminate in two ways: (1) the normal - TCP close sequence using a FIN handshake, and (2) an "abort" - in which one or more RST segments are sent and the - connection state is immediately discarded. If a TCP - - - -Internet Engineering Task Force [Page 87] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - connection is closed by the remote site, the local - application MUST be informed whether it closed normally or - was aborted. - - The normal TCP close sequence delivers buffered data - reliably in both directions. Since the two directions of a - TCP connection are closed independently, it is possible for - a connection to be "half closed," i.e., closed in only one - direction, and a host is permitted to continue sending data - in the open direction on a half-closed connection. - - A host MAY implement a "half-duplex" TCP close sequence, so - that an application that has called CLOSE cannot continue to - read data from the connection. If such a host issues a - CLOSE call while received data is still pending in TCP, or - if new data is received after CLOSE is called, its TCP - SHOULD send a RST to show that data was lost. - - When a connection is closed actively, it MUST linger in - TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime). - However, it MAY accept a new SYN from the remote TCP to - reopen the connection directly from TIME-WAIT state, if it: - - (1) assigns its initial sequence number for the new - connection to be larger than the largest sequence - number it used on the previous connection incarnation, - and - - (2) returns to TIME-WAIT state if the SYN turns out to be - an old duplicate. - - - DISCUSSION: - TCP's full-duplex data-preserving close is a feature - that is not included in the analogous ISO transport - protocol TP4. - - Some systems have not implemented half-closed - connections, presumably because they do not fit into - the I/O model of their particular operating system. On - these systems, once an application has called CLOSE, it - can no longer read input data from the connection; this - is referred to as a "half-duplex" TCP close sequence. - - The graceful close algorithm of TCP requires that the - connection state remain defined on (at least) one end - of the connection, for a timeout period of 2xMSL, i.e., - 4 minutes. During this period, the (remote socket, - - - -Internet Engineering Task Force [Page 88] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - local socket) pair that defines the connection is busy - and cannot be reused. To shorten the time that a given - port pair is tied up, some TCPs allow a new SYN to be - accepted in TIME-WAIT state. - - 4.2.2.14 Data Communication: RFC-793 Section 3.7, page 40 - - Since RFC-793 was written, there has been extensive work on - TCP algorithms to achieve efficient data communication. - Later sections of the present document describe required and - recommended TCP algorithms to determine when to send data - (Section 4.2.3.4), when to send an acknowledgment (Section - 4.2.3.2), and when to update the window (Section 4.2.3.3). - - DISCUSSION: - One important performance issue is "Silly Window - Syndrome" or "SWS" [TCP:5], a stable pattern of small - incremental window movements resulting in extremely - poor TCP performance. Algorithms to avoid SWS are - described below for both the sending side (Section - 4.2.3.4) and the receiving side (Section 4.2.3.3). - - In brief, SWS is caused by the receiver advancing the - right window edge whenever it has any new buffer space - available to receive data and by the sender using any - incremental window, no matter how small, to send more - data [TCP:5]. The result can be a stable pattern of - sending tiny data segments, even though both sender and - receiver have a large total buffer space for the - connection. SWS can only occur during the transmission - of a large amount of data; if the connection goes - quiescent, the problem will disappear. It is caused by - typical straightforward implementation of window - management, but the sender and receiver algorithms - given below will avoid it. - - Another important TCP performance issue is that some - applications, especially remote login to character-at- - a-time hosts, tend to send streams of one-octet data - segments. To avoid deadlocks, every TCP SEND call from - such applications must be "pushed", either explicitly - by the application or else implicitly by TCP. The - result may be a stream of TCP segments that contain one - data octet each, which makes very inefficient use of - the Internet and contributes to Internet congestion. - The Nagle Algorithm described in Section 4.2.3.4 - provides a simple and effective solution to this - problem. It does have the effect of clumping - - - -Internet Engineering Task Force [Page 89] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - characters over Telnet connections; this may initially - surprise users accustomed to single-character echo, but - user acceptance has not been a problem. - - Note that the Nagle algorithm and the send SWS - avoidance algorithm play complementary roles in - improving performance. The Nagle algorithm discourages - sending tiny segments when the data to be sent - increases in small increments, while the SWS avoidance - algorithm discourages small segments resulting from the - right window edge advancing in small increments. - - A careless implementation can send two or more - acknowledgment segments per data segment received. For - example, suppose the receiver acknowledges every data - segment immediately. When the application program - subsequently consumes the data and increases the - available receive buffer space again, the receiver may - send a second acknowledgment segment to update the - window at the sender. The extreme case occurs with - single-character segments on TCP connections using the - Telnet protocol for remote login service. Some - implementations have been observed in which each - incoming 1-character segment generates three return - segments: (1) the acknowledgment, (2) a one byte - increase in the window, and (3) the echoed character, - respectively. - - 4.2.2.15 Retransmission Timeout: RFC-793 Section 3.7, page 41 - - The algorithm suggested in RFC-793 for calculating the - retransmission timeout is now known to be inadequate; see - Section 4.2.3.1 below. - - Recent work by Jacobson [TCP:7] on Internet congestion and - TCP retransmission stability has produced a transmission - algorithm combining "slow start" with "congestion - avoidance". A TCP MUST implement this algorithm. - - If a retransmitted packet is identical to the original - packet (which implies not only that the data boundaries have - not changed, but also that the window and acknowledgment - fields of the header have not changed), then the same IP - Identification field MAY be used (see Section 3.2.1.5). - - IMPLEMENTATION: - Some TCP implementors have chosen to "packetize" the - data stream, i.e., to pick segment boundaries when - - - -Internet Engineering Task Force [Page 90] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - segments are originally sent and to queue these - segments in a "retransmission queue" until they are - acknowledged. Another design (which may be simpler) is - to defer packetizing until each time data is - transmitted or retransmitted, so there will be no - segment retransmission queue. - - In an implementation with a segment retransmission - queue, TCP performance may be enhanced by repacketizing - the segments awaiting acknowledgment when the first - retransmission timeout occurs. That is, the - outstanding segments that fitted would be combined into - one maximum-sized segment, with a new IP Identification - value. The TCP would then retain this combined segment - in the retransmit queue until it was acknowledged. - However, if the first two segments in the - retransmission queue totalled more than one maximum- - sized segment, the TCP would retransmit only the first - segment using the original IP Identification field. - - 4.2.2.16 Managing the Window: RFC-793 Section 3.7, page 41 - - A TCP receiver SHOULD NOT shrink the window, i.e., move the - right window edge to the left. However, a sending TCP MUST - be robust against window shrinking, which may cause the - "useable window" (see Section 4.2.3.4) to become negative. - - If this happens, the sender SHOULD NOT send new data, but - SHOULD retransmit normally the old unacknowledged data - between SND.UNA and SND.UNA+SND.WND. The sender MAY also - retransmit old data beyond SND.UNA+SND.WND, but SHOULD NOT - time out the connection if data beyond the right window edge - is not acknowledged. If the window shrinks to zero, the TCP - MUST probe it in the standard way (see next Section). - - DISCUSSION: - Many TCP implementations become confused if the window - shrinks from the right after data has been sent into a - larger window. Note that TCP has a heuristic to select - the latest window update despite possible datagram - reordering; as a result, it may ignore a window update - with a smaller window than previously offered if - neither the sequence number nor the acknowledgment - number is increased. - - - - - - - -Internet Engineering Task Force [Page 91] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - 4.2.2.17 Probing Zero Windows: RFC-793 Section 3.7, page 42 - - Probing of zero (offered) windows MUST be supported. - - A TCP MAY keep its offered receive window closed - indefinitely. As long as the receiving TCP continues to - send acknowledgments in response to the probe segments, the - sending TCP MUST allow the connection to stay open. - - DISCUSSION: - It is extremely important to remember that ACK - (acknowledgment) segments that contain no data are not - reliably transmitted by TCP. If zero window probing is - not supported, a connection may hang forever when an - ACK segment that re-opens the window is lost. - - The delay in opening a zero window generally occurs - when the receiving application stops taking data from - its TCP. For example, consider a printer daemon - application, stopped because the printer ran out of - paper. - - The transmitting host SHOULD send the first zero-window - probe when a zero window has existed for the retransmission - timeout period (see Section 4.2.2.15), and SHOULD increase - exponentially the interval between successive probes. - - DISCUSSION: - This procedure minimizes delay if the zero-window - condition is due to a lost ACK segment containing a - window-opening update. Exponential backoff is - recommended, possibly with some maximum interval not - specified here. This procedure is similar to that of - the retransmission algorithm, and it may be possible to - combine the two procedures in the implementation. - - 4.2.2.18 Passive OPEN Calls: RFC-793 Section 3.8 - - Every passive OPEN call either creates a new connection - record in LISTEN state, or it returns an error; it MUST NOT - affect any previously created connection record. - - A TCP that supports multiple concurrent users MUST provide - an OPEN call that will functionally allow an application to - LISTEN on a port while a connection block with the same - local port is in SYN-SENT or SYN-RECEIVED state. - - DISCUSSION: - - - -Internet Engineering Task Force [Page 92] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - Some applications (e.g., SMTP servers) may need to - handle multiple connection attempts at about the same - time. The probability of a connection attempt failing - is reduced by giving the application some means of - listening for a new connection at the same time that an - earlier connection attempt is going through the three- - way handshake. - - IMPLEMENTATION: - Acceptable implementations of concurrent opens may - permit multiple passive OPEN calls, or they may allow - "cloning" of LISTEN-state connections from a single - passive OPEN call. - - 4.2.2.19 Time to Live: RFC-793 Section 3.9, page 52 - - RFC-793 specified that TCP was to request the IP layer to - send TCP segments with TTL = 60. This is obsolete; the TTL - value used to send TCP segments MUST be configurable. See - Section 3.2.1.7 for discussion. - - 4.2.2.20 Event Processing: RFC-793 Section 3.9 - - While it is not strictly required, a TCP SHOULD be capable - of queueing out-of-order TCP segments. Change the "may" in - the last sentence of the first paragraph on page 70 to - "should". - - DISCUSSION: - Some small-host implementations have omitted segment - queueing because of limited buffer space. This - omission may be expected to adversely affect TCP - throughput, since loss of a single segment causes all - later segments to appear to be "out of sequence". - - In general, the processing of received segments MUST be - implemented to aggregate ACK segments whenever possible. - For example, if the TCP is processing a series of queued - segments, it MUST process them all before sending any ACK - segments. - - Here are some detailed error corrections and notes on the - Event Processing section of RFC-793. - - (a) CLOSE Call, CLOSE-WAIT state, p. 61: enter LAST-ACK - state, not CLOSING. - - (b) LISTEN state, check for SYN (pp. 65, 66): With a SYN - - - -Internet Engineering Task Force [Page 93] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - bit, if the security/compartment or the precedence is - wrong for the segment, a reset is sent. The wrong form - of reset is shown in the text; it should be: - - <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK> - - - (c) SYN-SENT state, Check for SYN, p. 68: When the - connection enters ESTABLISHED state, the following - variables must be set: - SND.WND <- SEG.WND - SND.WL1 <- SEG.SEQ - SND.WL2 <- SEG.ACK - - - (d) Check security and precedence, p. 71: The first heading - "ESTABLISHED STATE" should really be a list of all - states other than SYN-RECEIVED: ESTABLISHED, FIN-WAIT- - 1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, and - TIME-WAIT. - - (e) Check SYN bit, p. 71: "In SYN-RECEIVED state and if - the connection was initiated with a passive OPEN, then - return this connection to the LISTEN state and return. - Otherwise...". - - (f) Check ACK field, SYN-RECEIVED state, p. 72: When the - connection enters ESTABLISHED state, the variables - listed in (c) must be set. - - (g) Check ACK field, ESTABLISHED state, p. 72: The ACK is a - duplicate if SEG.ACK =< SND.UNA (the = was omitted). - Similarly, the window should be updated if: SND.UNA =< - SEG.ACK =< SND.NXT. - - (h) USER TIMEOUT, p. 77: - - It would be better to notify the application of the - timeout rather than letting TCP force the connection - closed. However, see also Section 4.2.3.5. - - - 4.2.2.21 Acknowledging Queued Segments: RFC-793 Section 3.9 - - A TCP MAY send an ACK segment acknowledging RCV.NXT when a - valid segment arrives that is in the window but not at the - left window edge. - - - - -Internet Engineering Task Force [Page 94] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - DISCUSSION: - RFC-793 (see page 74) was ambiguous about whether or - not an ACK segment should be sent when an out-of-order - segment was received, i.e., when SEG.SEQ was unequal to - RCV.NXT. - - One reason for ACKing out-of-order segments might be to - support an experimental algorithm known as "fast - retransmit". With this algorithm, the sender uses the - "redundant" ACK's to deduce that a segment has been - lost before the retransmission timer has expired. It - counts the number of times an ACK has been received - with the same value of SEG.ACK and with the same right - window edge. If more than a threshold number of such - ACK's is received, then the segment containing the - octets starting at SEG.ACK is assumed to have been lost - and is retransmitted, without awaiting a timeout. The - threshold is chosen to compensate for the maximum - likely segment reordering in the Internet. There is - not yet enough experience with the fast retransmit - algorithm to determine how useful it is. - - 4.2.3 SPECIFIC ISSUES - - 4.2.3.1 Retransmission Timeout Calculation - - A host TCP MUST implement Karn's algorithm and Jacobson's - algorithm for computing the retransmission timeout ("RTO"). - - o Jacobson's algorithm for computing the smoothed round- - trip ("RTT") time incorporates a simple measure of the - variance [TCP:7]. - - o Karn's algorithm for selecting RTT measurements ensures - that ambiguous round-trip times will not corrupt the - calculation of the smoothed round-trip time [TCP:6]. - - This implementation also MUST include "exponential backoff" - for successive RTO values for the same segment. - Retransmission of SYN segments SHOULD use the same algorithm - as data segments. - - DISCUSSION: - There were two known problems with the RTO calculations - specified in RFC-793. First, the accurate measurement - of RTTs is difficult when there are retransmissions. - Second, the algorithm to compute the smoothed round- - trip time is inadequate [TCP:7], because it incorrectly - - - -Internet Engineering Task Force [Page 95] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - assumed that the variance in RTT values would be small - and constant. These problems were solved by Karn's and - Jacobson's algorithm, respectively. - - The performance increase resulting from the use of - these improvements varies from noticeable to dramatic. - Jacobson's algorithm for incorporating the measured RTT - variance is especially important on a low-speed link, - where the natural variation of packet sizes causes a - large variation in RTT. One vendor found link - utilization on a 9.6kb line went from 10% to 90% as a - result of implementing Jacobson's variance algorithm in - TCP. - - The following values SHOULD be used to initialize the - estimation parameters for a new connection: - - (a) RTT = 0 seconds. - - (b) RTO = 3 seconds. (The smoothed variance is to be - initialized to the value that will result in this RTO). - - The recommended upper and lower bounds on the RTO are known - to be inadequate on large internets. The lower bound SHOULD - be measured in fractions of a second (to accommodate high - speed LANs) and the upper bound should be 2*MSL, i.e., 240 - seconds. - - DISCUSSION: - Experience has shown that these initialization values - are reasonable, and that in any case the Karn and - Jacobson algorithms make TCP behavior reasonably - insensitive to the initial parameter choices. - - 4.2.3.2 When to Send an ACK Segment - - A host that is receiving a stream of TCP data segments can - increase efficiency in both the Internet and the hosts by - sending fewer than one ACK (acknowledgment) segment per data - segment received; this is known as a "delayed ACK" [TCP:5]. - - A TCP SHOULD implement a delayed ACK, but an ACK should not - be excessively delayed; in particular, the delay MUST be - less than 0.5 seconds, and in a stream of full-sized - segments there SHOULD be an ACK for at least every second - segment. - - DISCUSSION: - - - -Internet Engineering Task Force [Page 96] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - A delayed ACK gives the application an opportunity to - update the window and perhaps to send an immediate - response. In particular, in the case of character-mode - remote login, a delayed ACK can reduce the number of - segments sent by the server by a factor of 3 (ACK, - window update, and echo character all combined in one - segment). - - In addition, on some large multi-user hosts, a delayed - ACK can substantially reduce protocol processing - overhead by reducing the total number of packets to be - processed [TCP:5]. However, excessive delays on ACK's - can disturb the round-trip timing and packet "clocking" - algorithms [TCP:7]. - - 4.2.3.3 When to Send a Window Update - - A TCP MUST include a SWS avoidance algorithm in the receiver - [TCP:5]. - - IMPLEMENTATION: - The receiver's SWS avoidance algorithm determines when - the right window edge may be advanced; this is - customarily known as "updating the window". This - algorithm combines with the delayed ACK algorithm (see - Section 4.2.3.2) to determine when an ACK segment - containing the current window will really be sent to - the receiver. We use the notation of RFC-793; see - Figures 4 and 5 in that document. - - The solution to receiver SWS is to avoid advancing the - right window edge RCV.NXT+RCV.WND in small increments, - even if data is received from the network in small - segments. - - Suppose the total receive buffer space is RCV.BUFF. At - any given moment, RCV.USER octets of this total may be - tied up with data that has been received and - acknowledged but which the user process has not yet - consumed. When the connection is quiescent, RCV.WND = - RCV.BUFF and RCV.USER = 0. - - Keeping the right window edge fixed as data arrives and - is acknowledged requires that the receiver offer less - than its full buffer space, i.e., the receiver must - specify a RCV.WND that keeps RCV.NXT+RCV.WND constant - as RCV.NXT increases. Thus, the total buffer space - RCV.BUFF is generally divided into three parts: - - - -Internet Engineering Task Force [Page 97] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - - |<------- RCV.BUFF ---------------->| - 1 2 3 - ----|---------|------------------|------|---- - RCV.NXT ^ - (Fixed) - - 1 - RCV.USER = data received but not yet consumed; - 2 - RCV.WND = space advertised to sender; - 3 - Reduction = space available but not yet - advertised. - - - The suggested SWS avoidance algorithm for the receiver - is to keep RCV.NXT+RCV.WND fixed until the reduction - satisfies: - - RCV.BUFF - RCV.USER - RCV.WND >= - - min( Fr * RCV.BUFF, Eff.snd.MSS ) - - where Fr is a fraction whose recommended value is 1/2, - and Eff.snd.MSS is the effective send MSS for the - connection (see Section 4.2.2.6). When the inequality - is satisfied, RCV.WND is set to RCV.BUFF-RCV.USER. - - Note that the general effect of this algorithm is to - advance RCV.WND in increments of Eff.snd.MSS (for - realistic receive buffers: Eff.snd.MSS < RCV.BUFF/2). - Note also that the receiver must use its own - Eff.snd.MSS, assuming it is the same as the sender's. - - 4.2.3.4 When to Send Data - - A TCP MUST include a SWS avoidance algorithm in the sender. - - A TCP SHOULD implement the Nagle Algorithm [TCP:9] to - coalesce short segments. However, there MUST be a way for - an application to disable the Nagle algorithm on an - individual connection. In all cases, sending data is also - subject to the limitation imposed by the Slow Start - algorithm (Section 4.2.2.15). - - DISCUSSION: - The Nagle algorithm is generally as follows: - - If there is unacknowledged data (i.e., SND.NXT > - SND.UNA), then the sending TCP buffers all user - - - -Internet Engineering Task Force [Page 98] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - data (regardless of the PSH bit), until the - outstanding data has been acknowledged or until - the TCP can send a full-sized segment (Eff.snd.MSS - bytes; see Section 4.2.2.6). - - Some applications (e.g., real-time display window - updates) require that the Nagle algorithm be turned - off, so small data segments can be streamed out at the - maximum rate. - - IMPLEMENTATION: - The sender's SWS avoidance algorithm is more difficult - than the receivers's, because the sender does not know - (directly) the receiver's total buffer space RCV.BUFF. - An approach which has been found to work well is for - the sender to calculate Max(SND.WND), the maximum send - window it has seen so far on the connection, and to use - this value as an estimate of RCV.BUFF. Unfortunately, - this can only be an estimate; the receiver may at any - time reduce the size of RCV.BUFF. To avoid a resulting - deadlock, it is necessary to have a timeout to force - transmission of data, overriding the SWS avoidance - algorithm. In practice, this timeout should seldom - occur. - - The "useable window" [TCP:5] is: - - U = SND.UNA + SND.WND - SND.NXT - - i.e., the offered window less the amount of data sent - but not acknowledged. If D is the amount of data - queued in the sending TCP but not yet sent, then the - following set of rules is recommended. - - Send data: - - (1) if a maximum-sized segment can be sent, i.e, if: - - min(D,U) >= Eff.snd.MSS; - - - (2) or if the data is pushed and all queued data can - be sent now, i.e., if: - - [SND.NXT = SND.UNA and] PUSHED and D <= U - - (the bracketed condition is imposed by the Nagle - algorithm); - - - -Internet Engineering Task Force [Page 99] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - (3) or if at least a fraction Fs of the maximum window - can be sent, i.e., if: - - [SND.NXT = SND.UNA and] - - min(D.U) >= Fs * Max(SND.WND); - - - (4) or if data is PUSHed and the override timeout - occurs. - - Here Fs is a fraction whose recommended value is 1/2. - The override timeout should be in the range 0.1 - 1.0 - seconds. It may be convenient to combine this timer - with the timer used to probe zero windows (Section - 4.2.2.17). - - Finally, note that the SWS avoidance algorithm just - specified is to be used instead of the sender-side - algorithm contained in [TCP:5]. - - 4.2.3.5 TCP Connection Failures - - Excessive retransmission of the same segment by TCP - indicates some failure of the remote host or the Internet - path. This failure may be of short or long duration. The - following procedure MUST be used to handle excessive - retransmissions of data segments [IP:11]: - - (a) There are two thresholds R1 and R2 measuring the amount - of retransmission that has occurred for the same - segment. R1 and R2 might be measured in time units or - as a count of retransmissions. - - (b) When the number of transmissions of the same segment - reaches or exceeds threshold R1, pass negative advice - (see Section 3.3.1.4) to the IP layer, to trigger - dead-gateway diagnosis. - - (c) When the number of transmissions of the same segment - reaches a threshold R2 greater than R1, close the - connection. - - (d) An application MUST be able to set the value for R2 for - a particular connection. For example, an interactive - application might set R2 to "infinity," giving the user - control over when to disconnect. - - - - -Internet Engineering Task Force [Page 100] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - (d) TCP SHOULD inform the application of the delivery - problem (unless such information has been disabled by - the application; see Section 4.2.4.1), when R1 is - reached and before R2. This will allow a remote login - (User Telnet) application program to inform the user, - for example. - - The value of R1 SHOULD correspond to at least 3 - retransmissions, at the current RTO. The value of R2 SHOULD - correspond to at least 100 seconds. - - An attempt to open a TCP connection could fail with - excessive retransmissions of the SYN segment or by receipt - of a RST segment or an ICMP Port Unreachable. SYN - retransmissions MUST be handled in the general way just - described for data retransmissions, including notification - of the application layer. - - However, the values of R1 and R2 may be different for SYN - and data segments. In particular, R2 for a SYN segment MUST - be set large enough to provide retransmission of the segment - for at least 3 minutes. The application can close the - connection (i.e., give up on the open attempt) sooner, of - course. - - DISCUSSION: - Some Internet paths have significant setup times, and - the number of such paths is likely to increase in the - future. - - 4.2.3.6 TCP Keep-Alives - - Implementors MAY include "keep-alives" in their TCP - implementations, although this practice is not universally - accepted. If keep-alives are included, the application MUST - be able to turn them on or off for each TCP connection, and - they MUST default to off. - - Keep-alive packets MUST only be sent when no data or - acknowledgement packets have been received for the - connection within an interval. This interval MUST be - configurable and MUST default to no less than two hours. - - It is extremely important to remember that ACK segments that - contain no data are not reliably transmitted by TCP. - Consequently, if a keep-alive mechanism is implemented it - MUST NOT interpret failure to respond to any specific probe - as a dead connection. - - - -Internet Engineering Task Force [Page 101] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - An implementation SHOULD send a keep-alive segment with no - data; however, it MAY be configurable to send a keep-alive - segment containing one garbage octet, for compatibility with - erroneous TCP implementations. - - DISCUSSION: - A "keep-alive" mechanism periodically probes the other - end of a connection when the connection is otherwise - idle, even when there is no data to be sent. The TCP - specification does not include a keep-alive mechanism - because it could: (1) cause perfectly good connections - to break during transient Internet failures; (2) - consume unnecessary bandwidth ("if no one is using the - connection, who cares if it is still good?"); and (3) - cost money for an Internet path that charges for - packets. - - Some TCP implementations, however, have included a - keep-alive mechanism. To confirm that an idle - connection is still active, these implementations send - a probe segment designed to elicit a response from the - peer TCP. Such a segment generally contains SEG.SEQ = - SND.NXT-1 and may or may not contain one garbage octet - of data. Note that on a quiet connection SND.NXT = - RCV.NXT, so that this SEG.SEQ will be outside the - window. Therefore, the probe causes the receiver to - return an acknowledgment segment, confirming that the - connection is still live. If the peer has dropped the - connection due to a network partition or a crash, it - will respond with a RST instead of an acknowledgment - segment. - - Unfortunately, some misbehaved TCP implementations fail - to respond to a segment with SEG.SEQ = SND.NXT-1 unless - the segment contains data. Alternatively, an - implementation could determine whether a peer responded - correctly to keep-alive packets with no garbage data - octet. - - A TCP keep-alive mechanism should only be invoked in - server applications that might otherwise hang - indefinitely and consume resources unnecessarily if a - client crashes or aborts a connection during a network - failure. - - - - - - - -Internet Engineering Task Force [Page 102] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - 4.2.3.7 TCP Multihoming - - If an application on a multihomed host does not specify the - local IP address when actively opening a TCP connection, - then the TCP MUST ask the IP layer to select a local IP - address before sending the (first) SYN. See the function - GET_SRCADDR() in Section 3.4. - - At all other times, a previous segment has either been sent - or received on this connection, and TCP MUST use the same - local address is used that was used in those previous - segments. - - 4.2.3.8 IP Options - - When received options are passed up to TCP from the IP - layer, TCP MUST ignore options that it does not understand. - - A TCP MAY support the Time Stamp and Record Route options. - - An application MUST be able to specify a source route when - it actively opens a TCP connection, and this MUST take - precedence over a source route received in a datagram. - - When a TCP connection is OPENed passively and a packet - arrives with a completed IP Source Route option (containing - a return route), TCP MUST save the return route and use it - for all segments sent on this connection. If a different - source route arrives in a later segment, the later - definition SHOULD override the earlier one. - - 4.2.3.9 ICMP Messages - - TCP MUST act on an ICMP error message passed up from the IP - layer, directing it to the connection that created the - error. The necessary demultiplexing information can be - found in the IP header contained within the ICMP message. - - o Source Quench - - TCP MUST react to a Source Quench by slowing - transmission on the connection. The RECOMMENDED - procedure is for a Source Quench to trigger a "slow - start," as if a retransmission timeout had occurred. - - o Destination Unreachable -- codes 0, 1, 5 - - Since these Unreachable messages indicate soft error - - - -Internet Engineering Task Force [Page 103] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - conditions, TCP MUST NOT abort the connection, and it - SHOULD make the information available to the - application. - - DISCUSSION: - TCP could report the soft error condition directly - to the application layer with an upcall to the - ERROR_REPORT routine, or it could merely note the - message and report it to the application only when - and if the TCP connection times out. - - o Destination Unreachable -- codes 2-4 - - These are hard error conditions, so TCP SHOULD abort - the connection. - - o Time Exceeded -- codes 0, 1 - - This should be handled the same way as Destination - Unreachable codes 0, 1, 5 (see above). - - o Parameter Problem - - This should be handled the same way as Destination - Unreachable codes 0, 1, 5 (see above). - - - 4.2.3.10 Remote Address Validation - - A TCP implementation MUST reject as an error a local OPEN - call for an invalid remote IP address (e.g., a broadcast or - multicast address). - - An incoming SYN with an invalid source address must be - ignored either by TCP or by the IP layer (see Section - 3.2.1.3). - - A TCP implementation MUST silently discard an incoming SYN - segment that is addressed to a broadcast or multicast - address. - - 4.2.3.11 TCP Traffic Patterns - - IMPLEMENTATION: - The TCP protocol specification [TCP:1] gives the - implementor much freedom in designing the algorithms - that control the message flow over the connection -- - packetizing, managing the window, sending - - - -Internet Engineering Task Force [Page 104] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - acknowledgments, etc. These design decisions are - difficult because a TCP must adapt to a wide range of - traffic patterns. Experience has shown that a TCP - implementor needs to verify the design on two extreme - traffic patterns: - - o Single-character Segments - - Even if the sender is using the Nagle Algorithm, - when a TCP connection carries remote login traffic - across a low-delay LAN the receiver will generally - get a stream of single-character segments. If - remote terminal echo mode is in effect, the - receiver's system will generally echo each - character as it is received. - - o Bulk Transfer - - When TCP is used for bulk transfer, the data - stream should be made up (almost) entirely of - segments of the size of the effective MSS. - Although TCP uses a sequence number space with - byte (octet) granularity, in bulk-transfer mode - its operation should be as if TCP used a sequence - space that counted only segments. - - Experience has furthermore shown that a single TCP can - effectively and efficiently handle these two extremes. - - The most important tool for verifying a new TCP - implementation is a packet trace program. There is a - large volume of experience showing the importance of - tracing a variety of traffic patterns with other TCP - implementations and studying the results carefully. - - - 4.2.3.12 Efficiency - - IMPLEMENTATION: - Extensive experience has led to the following - suggestions for efficient implementation of TCP: - - (a) Don't Copy Data - - In bulk data transfer, the primary CPU-intensive - tasks are copying data from one place to another - and checksumming the data. It is vital to - minimize the number of copies of TCP data. Since - - - -Internet Engineering Task Force [Page 105] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - the ultimate speed limitation may be fetching data - across the memory bus, it may be useful to combine - the copy with checksumming, doing both with a - single memory fetch. - - (b) Hand-Craft the Checksum Routine - - A good TCP checksumming routine is typically two - to five times faster than a simple and direct - implementation of the definition. Great care and - clever coding are often required and advisable to - make the checksumming code "blazing fast". See - [TCP:10]. - - (c) Code for the Common Case - - TCP protocol processing can be complicated, but - for most segments there are only a few simple - decisions to be made. Per-segment processing will - be greatly speeded up by coding the main line to - minimize the number of decisions in the most - common case. - - - 4.2.4 TCP/APPLICATION LAYER INTERFACE - - 4.2.4.1 Asynchronous Reports - - There MUST be a mechanism for reporting soft TCP error - conditions to the application. Generically, we assume this - takes the form of an application-supplied ERROR_REPORT - routine that may be upcalled [INTRO:7] asynchronously from - the transport layer: - - ERROR_REPORT(local connection name, reason, subreason) - - The precise encoding of the reason and subreason parameters - is not specified here. However, the conditions that are - reported asynchronously to the application MUST include: - - * ICMP error message arrived (see 4.2.3.9) - - * Excessive retransmissions (see 4.2.3.5) - - * Urgent pointer advance (see 4.2.2.4). - - However, an application program that does not want to - receive such ERROR_REPORT calls SHOULD be able to - - - -Internet Engineering Task Force [Page 106] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - effectively disable these calls. - - DISCUSSION: - These error reports generally reflect soft errors that - can be ignored without harm by many applications. It - has been suggested that these error report calls should - default to "disabled," but this is not required. - - 4.2.4.2 Type-of-Service - - The application layer MUST be able to specify the Type-of- - Service (TOS) for segments that are sent on a connection. - It not required, but the application SHOULD be able to - change the TOS during the connection lifetime. TCP SHOULD - pass the current TOS value without change to the IP layer, - when it sends segments on the connection. - - The TOS will be specified independently in each direction on - the connection, so that the receiver application will - specify the TOS used for ACK segments. - - TCP MAY pass the most recently received TOS up to the - application. - - DISCUSSION - Some applications (e.g., SMTP) change the nature of - their communication during the lifetime of a - connection, and therefore would like to change the TOS - specification. - - Note also that the OPEN call specified in RFC-793 - includes a parameter ("options") in which the caller - can specify IP options such as source route, record - route, or timestamp. - - 4.2.4.3 Flush Call - - Some TCP implementations have included a FLUSH call, which - will empty the TCP send queue of any data for which the user - has issued SEND calls but which is still to the right of the - current send window. That is, it flushes as much queued - send data as possible without losing sequence number - synchronization. This is useful for implementing the "abort - output" function of Telnet. - - - - - - - -Internet Engineering Task Force [Page 107] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - 4.2.4.4 Multihoming - - The user interface outlined in sections 2.7 and 3.8 of RFC- - 793 needs to be extended for multihoming. The OPEN call - MUST have an optional parameter: - - OPEN( ... [local IP address,] ... ) - - to allow the specification of the local IP address. - - DISCUSSION: - Some TCP-based applications need to specify the local - IP address to be used to open a particular connection; - FTP is an example. - - IMPLEMENTATION: - A passive OPEN call with a specified "local IP address" - parameter will await an incoming connection request to - that address. If the parameter is unspecified, a - passive OPEN will await an incoming connection request - to any local IP address, and then bind the local IP - address of the connection to the particular address - that is used. - - For an active OPEN call, a specified "local IP address" - parameter will be used for opening the connection. If - the parameter is unspecified, the networking software - will choose an appropriate local IP address (see - Section 3.3.4.2) for the connection - - 4.2.5 TCP REQUIREMENT SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e --------------------------------------------------|--------|-|-|-|-|-|-- - | | | | | | | -Push flag | | | | | | | - Aggregate or queue un-pushed data |4.2.2.2 | | |x| | | - Sender collapse successive PSH flags |4.2.2.2 | |x| | | | - SEND call can specify PUSH |4.2.2.2 | | |x| | | - - - -Internet Engineering Task Force [Page 108] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - If cannot: sender buffer indefinitely |4.2.2.2 | | | | |x| - If cannot: PSH last segment |4.2.2.2 |x| | | | | - Notify receiving ALP of PSH |4.2.2.2 | | |x| | |1 - Send max size segment when possible |4.2.2.2 | |x| | | | - | | | | | | | -Window | | | | | | | - Treat as unsigned number |4.2.2.3 |x| | | | | - Handle as 32-bit number |4.2.2.3 | |x| | | | - Shrink window from right |4.2.2.16| | | |x| | - Robust against shrinking window |4.2.2.16|x| | | | | - Receiver's window closed indefinitely |4.2.2.17| | |x| | | - Sender probe zero window |4.2.2.17|x| | | | | - First probe after RTO |4.2.2.17| |x| | | | - Exponential backoff |4.2.2.17| |x| | | | - Allow window stay zero indefinitely |4.2.2.17|x| | | | | - Sender timeout OK conn with zero wind |4.2.2.17| | | | |x| - | | | | | | | -Urgent Data | | | | | | | - Pointer points to last octet |4.2.2.4 |x| | | | | - Arbitrary length urgent data sequence |4.2.2.4 |x| | | | | - Inform ALP asynchronously of urgent data |4.2.2.4 |x| | | | |1 - ALP can learn if/how much urgent data Q'd |4.2.2.4 |x| | | | |1 - | | | | | | | -TCP Options | | | | | | | - Receive TCP option in any segment |4.2.2.5 |x| | | | | - Ignore unsupported options |4.2.2.5 |x| | | | | - Cope with illegal option length |4.2.2.5 |x| | | | | - Implement sending & receiving MSS option |4.2.2.6 |x| | | | | - Send MSS option unless 536 |4.2.2.6 | |x| | | | - Send MSS option always |4.2.2.6 | | |x| | | - Send-MSS default is 536 |4.2.2.6 |x| | | | | - Calculate effective send seg size |4.2.2.6 |x| | | | | - | | | | | | | -TCP Checksums | | | | | | | - Sender compute checksum |4.2.2.7 |x| | | | | - Receiver check checksum |4.2.2.7 |x| | | | | - | | | | | | | -Use clock-driven ISN selection |4.2.2.9 |x| | | | | - | | | | | | | -Opening Connections | | | | | | | - Support simultaneous open attempts |4.2.2.10|x| | | | | - SYN-RCVD remembers last state |4.2.2.11|x| | | | | - Passive Open call interfere with others |4.2.2.18| | | | |x| - Function: simultan. LISTENs for same port |4.2.2.18|x| | | | | - Ask IP for src address for SYN if necc. |4.2.3.7 |x| | | | | - Otherwise, use local addr of conn. |4.2.3.7 |x| | | | | - OPEN to broadcast/multicast IP Address |4.2.3.14| | | | |x| - Silently discard seg to bcast/mcast addr |4.2.3.14|x| | | | | - - - -Internet Engineering Task Force [Page 109] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - | | | | | | | -Closing Connections | | | | | | | - RST can contain data |4.2.2.12| |x| | | | - Inform application of aborted conn |4.2.2.13|x| | | | | - Half-duplex close connections |4.2.2.13| | |x| | | - Send RST to indicate data lost |4.2.2.13| |x| | | | - In TIME-WAIT state for 2xMSL seconds |4.2.2.13|x| | | | | - Accept SYN from TIME-WAIT state |4.2.2.13| | |x| | | - | | | | | | | -Retransmissions | | | | | | | - Jacobson Slow Start algorithm |4.2.2.15|x| | | | | - Jacobson Congestion-Avoidance algorithm |4.2.2.15|x| | | | | - Retransmit with same IP ident |4.2.2.15| | |x| | | - Karn's algorithm |4.2.3.1 |x| | | | | - Jacobson's RTO estimation alg. |4.2.3.1 |x| | | | | - Exponential backoff |4.2.3.1 |x| | | | | - SYN RTO calc same as data |4.2.3.1 | |x| | | | - Recommended initial values and bounds |4.2.3.1 | |x| | | | - | | | | | | | -Generating ACK's: | | | | | | | - Queue out-of-order segments |4.2.2.20| |x| | | | - Process all Q'd before send ACK |4.2.2.20|x| | | | | - Send ACK for out-of-order segment |4.2.2.21| | |x| | | - Delayed ACK's |4.2.3.2 | |x| | | | - Delay < 0.5 seconds |4.2.3.2 |x| | | | | - Every 2nd full-sized segment ACK'd |4.2.3.2 |x| | | | | - Receiver SWS-Avoidance Algorithm |4.2.3.3 |x| | | | | - | | | | | | | -Sending data | | | | | | | - Configurable TTL |4.2.2.19|x| | | | | - Sender SWS-Avoidance Algorithm |4.2.3.4 |x| | | | | - Nagle algorithm |4.2.3.4 | |x| | | | - Application can disable Nagle algorithm |4.2.3.4 |x| | | | | - | | | | | | | -Connection Failures: | | | | | | | - Negative advice to IP on R1 retxs |4.2.3.5 |x| | | | | - Close connection on R2 retxs |4.2.3.5 |x| | | | | - ALP can set R2 |4.2.3.5 |x| | | | |1 - Inform ALP of R1<=retxs<R2 |4.2.3.5 | |x| | | |1 - Recommended values for R1, R2 |4.2.3.5 | |x| | | | - Same mechanism for SYNs |4.2.3.5 |x| | | | | - R2 at least 3 minutes for SYN |4.2.3.5 |x| | | | | - | | | | | | | -Send Keep-alive Packets: |4.2.3.6 | | |x| | | - - Application can request |4.2.3.6 |x| | | | | - - Default is "off" |4.2.3.6 |x| | | | | - - Only send if idle for interval |4.2.3.6 |x| | | | | - - Interval configurable |4.2.3.6 |x| | | | | - - - -Internet Engineering Task Force [Page 110] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - - Default at least 2 hrs. |4.2.3.6 |x| | | | | - - Tolerant of lost ACK's |4.2.3.6 |x| | | | | - | | | | | | | -IP Options | | | | | | | - Ignore options TCP doesn't understand |4.2.3.8 |x| | | | | - Time Stamp support |4.2.3.8 | | |x| | | - Record Route support |4.2.3.8 | | |x| | | - Source Route: | | | | | | | - ALP can specify |4.2.3.8 |x| | | | |1 - Overrides src rt in datagram |4.2.3.8 |x| | | | | - Build return route from src rt |4.2.3.8 |x| | | | | - Later src route overrides |4.2.3.8 | |x| | | | - | | | | | | | -Receiving ICMP Messages from IP |4.2.3.9 |x| | | | | - Dest. Unreach (0,1,5) => inform ALP |4.2.3.9 | |x| | | | - Dest. Unreach (0,1,5) => abort conn |4.2.3.9 | | | | |x| - Dest. Unreach (2-4) => abort conn |4.2.3.9 | |x| | | | - Source Quench => slow start |4.2.3.9 | |x| | | | - Time Exceeded => tell ALP, don't abort |4.2.3.9 | |x| | | | - Param Problem => tell ALP, don't abort |4.2.3.9 | |x| | | | - | | | | | | | -Address Validation | | | | | | | - Reject OPEN call to invalid IP address |4.2.3.10|x| | | | | - Reject SYN from invalid IP address |4.2.3.10|x| | | | | - Silently discard SYN to bcast/mcast addr |4.2.3.10|x| | | | | - | | | | | | | -TCP/ALP Interface Services | | | | | | | - Error Report mechanism |4.2.4.1 |x| | | | | - ALP can disable Error Report Routine |4.2.4.1 | |x| | | | - ALP can specify TOS for sending |4.2.4.2 |x| | | | | - Passed unchanged to IP |4.2.4.2 | |x| | | | - ALP can change TOS during connection |4.2.4.2 | |x| | | | - Pass received TOS up to ALP |4.2.4.2 | | |x| | | - FLUSH call |4.2.4.3 | | |x| | | - Optional local IP addr parm. in OPEN |4.2.4.4 |x| | | | | --------------------------------------------------|--------|-|-|-|-|-|-- --------------------------------------------------|--------|-|-|-|-|-|-- - -FOOTNOTES: - -(1) "ALP" means Application-Layer program. - - - - - - - - - - -Internet Engineering Task Force [Page 111] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - -5. REFERENCES - -INTRODUCTORY REFERENCES - - -[INTRO:1] "Requirements for Internet Hosts -- Application and Support," - IETF Host Requirements Working Group, R. Braden, Ed., RFC-1123, - October 1989. - -[INTRO:2] "Requirements for Internet Gateways," R. Braden and J. - Postel, RFC-1009, June 1987. - -[INTRO:3] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006, - (three volumes), SRI International, December 1985. - -[INTRO:4] "Official Internet Protocols," J. Reynolds and J. Postel, - RFC-1011, May 1987. - - This document is republished periodically with new RFC numbers; the - latest version must be used. - -[INTRO:5] "Protocol Document Order Information," O. Jacobsen and J. - Postel, RFC-980, March 1986. - -[INTRO:6] "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, May - 1987. - - This document is republished periodically with new RFC numbers; the - latest version must be used. - -[INTRO:7] "Modularity and Efficiency in Protocol Implementations," D. - Clark, RFC-817, July 1982. - -[INTRO:8] "The Structuring of Systems Using Upcalls," D. Clark, 10th ACM - SOSP, Orcas Island, Washington, December 1985. - - -Secondary References: - - -[INTRO:9] "A Protocol for Packet Network Intercommunication," V. Cerf - and R. Kahn, IEEE Transactions on Communication, May 1974. - -[INTRO:10] "The ARPA Internet Protocol," J. Postel, C. Sunshine, and D. - Cohen, Computer Networks, Vol. 5, No. 4, July 1981. - -[INTRO:11] "The DARPA Internet Protocol Suite," B. Leiner, J. Postel, - R. Cole and D. Mills, Proceedings INFOCOM 85, IEEE, Washington DC, - - - -Internet Engineering Task Force [Page 112] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - March 1985. Also in: IEEE Communications Magazine, March 1985. - Also available as ISI-RS-85-153. - -[INTRO:12] "Final Text of DIS8473, Protocol for Providing the - Connectionless Mode Network Service," ANSI, published as RFC-994, - March 1986. - -[INTRO:13] "End System to Intermediate System Routing Exchange - Protocol," ANSI X3S3.3, published as RFC-995, April 1986. - - -LINK LAYER REFERENCES - - -[LINK:1] "Trailer Encapsulations," S. Leffler and M. Karels, RFC-893, - April 1984. - -[LINK:2] "An Ethernet Address Resolution Protocol," D. Plummer, RFC-826, - November 1982. - -[LINK:3] "A Standard for the Transmission of IP Datagrams over Ethernet - Networks," C. Hornig, RFC-894, April 1984. - -[LINK:4] "A Standard for the Transmission of IP Datagrams over IEEE 802 - "Networks," J. Postel and J. Reynolds, RFC-1042, February 1988. - - This RFC contains a great deal of information of importance to - Internet implementers planning to use IEEE 802 networks. - - -IP LAYER REFERENCES - - -[IP:1] "Internet Protocol (IP)," J. Postel, RFC-791, September 1981. - -[IP:2] "Internet Control Message Protocol (ICMP)," J. Postel, RFC-792, - September 1981. - -[IP:3] "Internet Standard Subnetting Procedure," J. Mogul and J. Postel, - RFC-950, August 1985. - -[IP:4] "Host Extensions for IP Multicasting," S. Deering, RFC-1112, - August 1989. - -[IP:5] "Military Standard Internet Protocol," MIL-STD-1777, Department - of Defense, August 1983. - - This specification, as amended by RFC-963, is intended to describe - - - -Internet Engineering Task Force [Page 113] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - - the Internet Protocol but has some serious omissions (e.g., the - mandatory subnet extension [IP:3] and the optional multicasting - extension [IP:4]). It is also out of date. If there is a - conflict, RFC-791, RFC-792, and RFC-950 must be taken as - authoritative, while the present document is authoritative over - all. - -[IP:6] "Some Problems with the Specification of the Military Standard - Internet Protocol," D. Sidhu, RFC-963, November 1985. - -[IP:7] "The TCP Maximum Segment Size and Related Topics," J. Postel, - RFC-879, November 1983. - - Discusses and clarifies the relationship between the TCP Maximum - Segment Size option and the IP datagram size. - -[IP:8] "Internet Protocol Security Options," B. Schofield, RFC-1108, - October 1989. - -[IP:9] "Fragmentation Considered Harmful," C. Kent and J. Mogul, ACM - SIGCOMM-87, August 1987. Published as ACM Comp Comm Review, Vol. - 17, no. 5. - - This useful paper discusses the problems created by Internet - fragmentation and presents alternative solutions. - -[IP:10] "IP Datagram Reassembly Algorithms," D. Clark, RFC-815, July - 1982. - - This and the following paper should be read by every implementor. - -[IP:11] "Fault Isolation and Recovery," D. Clark, RFC-816, July 1982. - -SECONDARY IP REFERENCES: - - -[IP:12] "Broadcasting Internet Datagrams in the Presence of Subnets," J. - Mogul, RFC-922, October 1984. - -[IP:13] "Name, Addresses, Ports, and Routes," D. Clark, RFC-814, July - 1982. - -[IP:14] "Something a Host Could Do with Source Quench: The Source Quench - Introduced Delay (SQUID)," W. Prue and J. Postel, RFC-1016, July - 1987. - - This RFC first described directed broadcast addresses. However, - the bulk of the RFC is concerned with gateways, not hosts. - - - -Internet Engineering Task Force [Page 114] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - -UDP REFERENCES: - - -[UDP:1] "User Datagram Protocol," J. Postel, RFC-768, August 1980. - - -TCP REFERENCES: - - -[TCP:1] "Transmission Control Protocol," J. Postel, RFC-793, September - 1981. - - -[TCP:2] "Transmission Control Protocol," MIL-STD-1778, US Department of - Defense, August 1984. - - This specification as amended by RFC-964 is intended to describe - the same protocol as RFC-793 [TCP:1]. If there is a conflict, - RFC-793 takes precedence, and the present document is authoritative - over both. - - -[TCP:3] "Some Problems with the Specification of the Military Standard - Transmission Control Protocol," D. Sidhu and T. Blumer, RFC-964, - November 1985. - - -[TCP:4] "The TCP Maximum Segment Size and Related Topics," J. Postel, - RFC-879, November 1983. - - -[TCP:5] "Window and Acknowledgment Strategy in TCP," D. Clark, RFC-813, - July 1982. - - -[TCP:6] "Round Trip Time Estimation," P. Karn & C. Partridge, ACM - SIGCOMM-87, August 1987. - - -[TCP:7] "Congestion Avoidance and Control," V. Jacobson, ACM SIGCOMM-88, - August 1988. - - -SECONDARY TCP REFERENCES: - - -[TCP:8] "Modularity and Efficiency in Protocol Implementation," D. - Clark, RFC-817, July 1982. - - - -Internet Engineering Task Force [Page 115] - - - - -RFC1122 TRANSPORT LAYER -- TCP October 1989 - - -[TCP:9] "Congestion Control in IP/TCP," J. Nagle, RFC-896, January 1984. - - -[TCP:10] "Computing the Internet Checksum," R. Braden, D. Borman, and C. - Partridge, RFC-1071, September 1988. - - -[TCP:11] "TCP Extensions for Long-Delay Paths," V. Jacobson & R. Braden, - RFC-1072, October 1988. - - -Security Considerations - - There are many security issues in the communication layers of host - software, but a full discussion is beyond the scope of this RFC. - - The Internet architecture generally provides little protection - against spoofing of IP source addresses, so any security mechanism - that is based upon verifying the IP source address of a datagram - should be treated with suspicion. However, in restricted - environments some source-address checking may be possible. For - example, there might be a secure LAN whose gateway to the rest of the - Internet discarded any incoming datagram with a source address that - spoofed the LAN address. In this case, a host on the LAN could use - the source address to test for local vs. remote source. This problem - is complicated by source routing, and some have suggested that - source-routed datagram forwarding by hosts (see Section 3.3.5) should - be outlawed for security reasons. - - Security-related issues are mentioned in sections concerning the IP - Security option (Section 3.2.1.8), the ICMP Parameter Problem message - (Section 3.2.2.5), IP options in UDP datagrams (Section 4.1.3.2), and - reserved TCP ports (Section 4.2.2.1). - -Author's Address - - Robert Braden - USC/Information Sciences Institute - 4676 Admiralty Way - Marina del Rey, CA 90292-6695 - - Phone: (213) 822 1511 - - EMail: Braden@ISI.EDU - - - - - - - -Internet Engineering Task Force [Page 116] - diff --git a/contrib/bind9/doc/rfc/rfc1123.txt b/contrib/bind9/doc/rfc/rfc1123.txt deleted file mode 100644 index 51cdf83c9844..000000000000 --- a/contrib/bind9/doc/rfc/rfc1123.txt +++ /dev/null @@ -1,5782 +0,0 @@ - - - - - - -Network Working Group Internet Engineering Task Force -Request for Comments: 1123 R. Braden, Editor - October 1989 - - - Requirements for Internet Hosts -- Application and Support - -Status of This Memo - - This RFC is an official specification for the Internet community. It - incorporates by reference, amends, corrects, and supplements the - primary protocol standards documents relating to hosts. Distribution - of this document is unlimited. - -Summary - - This RFC is one of a pair that defines and discusses the requirements - for Internet host software. This RFC covers the application and - support protocols; its companion RFC-1122 covers the communication - protocol layers: link layer, IP layer, and transport layer. - - - - Table of Contents - - - - - 1. INTRODUCTION ............................................... 5 - 1.1 The Internet Architecture .............................. 6 - 1.2 General Considerations ................................. 6 - 1.2.1 Continuing Internet Evolution ..................... 6 - 1.2.2 Robustness Principle .............................. 7 - 1.2.3 Error Logging ..................................... 8 - 1.2.4 Configuration ..................................... 8 - 1.3 Reading this Document .................................. 10 - 1.3.1 Organization ...................................... 10 - 1.3.2 Requirements ...................................... 10 - 1.3.3 Terminology ....................................... 11 - 1.4 Acknowledgments ........................................ 12 - - 2. GENERAL ISSUES ............................................. 13 - 2.1 Host Names and Numbers ................................. 13 - 2.2 Using Domain Name Service .............................. 13 - 2.3 Applications on Multihomed hosts ....................... 14 - 2.4 Type-of-Service ........................................ 14 - 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY ............... 15 - - - - -Internet Engineering Task Force [Page 1] - - - - -RFC1123 INTRODUCTION October 1989 - - - 3. REMOTE LOGIN -- TELNET PROTOCOL ............................ 16 - 3.1 INTRODUCTION ........................................... 16 - 3.2 PROTOCOL WALK-THROUGH .................................. 16 - 3.2.1 Option Negotiation ................................ 16 - 3.2.2 Telnet Go-Ahead Function .......................... 16 - 3.2.3 Control Functions ................................. 17 - 3.2.4 Telnet "Synch" Signal ............................. 18 - 3.2.5 NVT Printer and Keyboard .......................... 19 - 3.2.6 Telnet Command Structure .......................... 20 - 3.2.7 Telnet Binary Option .............................. 20 - 3.2.8 Telnet Terminal-Type Option ....................... 20 - 3.3 SPECIFIC ISSUES ........................................ 21 - 3.3.1 Telnet End-of-Line Convention ..................... 21 - 3.3.2 Data Entry Terminals .............................. 23 - 3.3.3 Option Requirements ............................... 24 - 3.3.4 Option Initiation ................................. 24 - 3.3.5 Telnet Linemode Option ............................ 25 - 3.4 TELNET/USER INTERFACE .................................. 25 - 3.4.1 Character Set Transparency ........................ 25 - 3.4.2 Telnet Commands ................................... 26 - 3.4.3 TCP Connection Errors ............................. 26 - 3.4.4 Non-Default Telnet Contact Port ................... 26 - 3.4.5 Flushing Output ................................... 26 - 3.5. TELNET REQUIREMENTS SUMMARY ........................... 27 - - 4. FILE TRANSFER .............................................. 29 - 4.1 FILE TRANSFER PROTOCOL -- FTP .......................... 29 - 4.1.1 INTRODUCTION ...................................... 29 - 4.1.2. PROTOCOL WALK-THROUGH ............................ 29 - 4.1.2.1 LOCAL Type ................................... 29 - 4.1.2.2 Telnet Format Control ........................ 30 - 4.1.2.3 Page Structure ............................... 30 - 4.1.2.4 Data Structure Transformations ............... 30 - 4.1.2.5 Data Connection Management ................... 31 - 4.1.2.6 PASV Command ................................. 31 - 4.1.2.7 LIST and NLST Commands ....................... 31 - 4.1.2.8 SITE Command ................................. 32 - 4.1.2.9 STOU Command ................................. 32 - 4.1.2.10 Telnet End-of-line Code ..................... 32 - 4.1.2.11 FTP Replies ................................. 33 - 4.1.2.12 Connections ................................. 34 - 4.1.2.13 Minimum Implementation; RFC-959 Section ..... 34 - 4.1.3 SPECIFIC ISSUES ................................... 35 - 4.1.3.1 Non-standard Command Verbs ................... 35 - 4.1.3.2 Idle Timeout ................................. 36 - 4.1.3.3 Concurrency of Data and Control .............. 36 - 4.1.3.4 FTP Restart Mechanism ........................ 36 - 4.1.4 FTP/USER INTERFACE ................................ 39 - - - -Internet Engineering Task Force [Page 2] - - - - -RFC1123 INTRODUCTION October 1989 - - - 4.1.4.1 Pathname Specification ....................... 39 - 4.1.4.2 "QUOTE" Command .............................. 40 - 4.1.4.3 Displaying Replies to User ................... 40 - 4.1.4.4 Maintaining Synchronization .................. 40 - 4.1.5 FTP REQUIREMENTS SUMMARY ......................... 41 - 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP ................. 44 - 4.2.1 INTRODUCTION ...................................... 44 - 4.2.2 PROTOCOL WALK-THROUGH ............................. 44 - 4.2.2.1 Transfer Modes ............................... 44 - 4.2.2.2 UDP Header ................................... 44 - 4.2.3 SPECIFIC ISSUES ................................... 44 - 4.2.3.1 Sorcerer's Apprentice Syndrome ............... 44 - 4.2.3.2 Timeout Algorithms ........................... 46 - 4.2.3.3 Extensions ................................... 46 - 4.2.3.4 Access Control ............................... 46 - 4.2.3.5 Broadcast Request ............................ 46 - 4.2.4 TFTP REQUIREMENTS SUMMARY ......................... 47 - - 5. ELECTRONIC MAIL -- SMTP and RFC-822 ........................ 48 - 5.1 INTRODUCTION ........................................... 48 - 5.2 PROTOCOL WALK-THROUGH .................................. 48 - 5.2.1 The SMTP Model .................................... 48 - 5.2.2 Canonicalization .................................. 49 - 5.2.3 VRFY and EXPN Commands ............................ 50 - 5.2.4 SEND, SOML, and SAML Commands ..................... 50 - 5.2.5 HELO Command ...................................... 50 - 5.2.6 Mail Relay ........................................ 51 - 5.2.7 RCPT Command ...................................... 52 - 5.2.8 DATA Command ...................................... 53 - 5.2.9 Command Syntax .................................... 54 - 5.2.10 SMTP Replies ..................................... 54 - 5.2.11 Transparency ..................................... 55 - 5.2.12 WKS Use in MX Processing ......................... 55 - 5.2.13 RFC-822 Message Specification .................... 55 - 5.2.14 RFC-822 Date and Time Specification .............. 55 - 5.2.15 RFC-822 Syntax Change ............................ 56 - 5.2.16 RFC-822 Local-part .............................. 56 - 5.2.17 Domain Literals .................................. 57 - 5.2.18 Common Address Formatting Errors ................. 58 - 5.2.19 Explicit Source Routes ........................... 58 - 5.3 SPECIFIC ISSUES ........................................ 59 - 5.3.1 SMTP Queueing Strategies .......................... 59 - 5.3.1.1 Sending Strategy .............................. 59 - 5.3.1.2 Receiving strategy ........................... 61 - 5.3.2 Timeouts in SMTP .................................. 61 - 5.3.3 Reliable Mail Receipt ............................. 63 - 5.3.4 Reliable Mail Transmission ........................ 63 - 5.3.5 Domain Name Support ............................... 65 - - - -Internet Engineering Task Force [Page 3] - - - - -RFC1123 INTRODUCTION October 1989 - - - 5.3.6 Mailing Lists and Aliases ......................... 65 - 5.3.7 Mail Gatewaying ................................... 66 - 5.3.8 Maximum Message Size .............................. 68 - 5.4 SMTP REQUIREMENTS SUMMARY .............................. 69 - - 6. SUPPORT SERVICES ............................................ 72 - 6.1 DOMAIN NAME TRANSLATION ................................. 72 - 6.1.1 INTRODUCTION ....................................... 72 - 6.1.2 PROTOCOL WALK-THROUGH ............................. 72 - 6.1.2.1 Resource Records with Zero TTL ............... 73 - 6.1.2.2 QCLASS Values ................................ 73 - 6.1.2.3 Unused Fields ................................ 73 - 6.1.2.4 Compression .................................. 73 - 6.1.2.5 Misusing Configuration Info .................. 73 - 6.1.3 SPECIFIC ISSUES ................................... 74 - 6.1.3.1 Resolver Implementation ...................... 74 - 6.1.3.2 Transport Protocols .......................... 75 - 6.1.3.3 Efficient Resource Usage ..................... 77 - 6.1.3.4 Multihomed Hosts ............................. 78 - 6.1.3.5 Extensibility ................................ 79 - 6.1.3.6 Status of RR Types ........................... 79 - 6.1.3.7 Robustness ................................... 80 - 6.1.3.8 Local Host Table ............................. 80 - 6.1.4 DNS USER INTERFACE ................................ 81 - 6.1.4.1 DNS Administration ........................... 81 - 6.1.4.2 DNS User Interface ........................... 81 - 6.1.4.3 Interface Abbreviation Facilities ............. 82 - 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ........... 84 - 6.2 HOST INITIALIZATION .................................... 87 - 6.2.1 INTRODUCTION ...................................... 87 - 6.2.2 REQUIREMENTS ...................................... 87 - 6.2.2.1 Dynamic Configuration ........................ 87 - 6.2.2.2 Loading Phase ................................ 89 - 6.3 REMOTE MANAGEMENT ...................................... 90 - 6.3.1 INTRODUCTION ...................................... 90 - 6.3.2 PROTOCOL WALK-THROUGH ............................. 90 - 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY ................... 92 - - 7. REFERENCES ................................................. 93 - - - - - - - - - - - - -Internet Engineering Task Force [Page 4] - - - - -RFC1123 INTRODUCTION October 1989 - - -1. INTRODUCTION - - This document is one of a pair that defines and discusses the - requirements for host system implementations of the Internet protocol - suite. This RFC covers the applications layer and support protocols. - Its companion RFC, "Requirements for Internet Hosts -- Communications - Layers" [INTRO:1] covers the lower layer protocols: transport layer, - IP layer, and link layer. - - These documents are intended to provide guidance for vendors, - implementors, and users of Internet communication software. They - represent the consensus of a large body of technical experience and - wisdom, contributed by members of the Internet research and vendor - communities. - - This RFC enumerates standard protocols that a host connected to the - Internet must use, and it incorporates by reference the RFCs and - other documents describing the current specifications for these - protocols. It corrects errors in the referenced documents and adds - additional discussion and guidance for an implementor. - - For each protocol, this document also contains an explicit set of - requirements, recommendations, and options. The reader must - understand that the list of requirements in this document is - incomplete by itself; the complete set of requirements for an - Internet host is primarily defined in the standard protocol - specification documents, with the corrections, amendments, and - supplements contained in this RFC. - - A good-faith implementation of the protocols that was produced after - careful reading of the RFC's and with some interaction with the - Internet technical community, and that followed good communications - software engineering practices, should differ from the requirements - of this document in only minor ways. Thus, in many cases, the - "requirements" in this RFC are already stated or implied in the - standard protocol documents, so that their inclusion here is, in a - sense, redundant. However, they were included because some past - implementation has made the wrong choice, causing problems of - interoperability, performance, and/or robustness. - - This document includes discussion and explanation of many of the - requirements and recommendations. A simple list of requirements - would be dangerous, because: - - o Some required features are more important than others, and some - features are optional. - - o There may be valid reasons why particular vendor products that - - - -Internet Engineering Task Force [Page 5] - - - - -RFC1123 INTRODUCTION October 1989 - - - are designed for restricted contexts might choose to use - different specifications. - - However, the specifications of this document must be followed to meet - the general goal of arbitrary host interoperation across the - diversity and complexity of the Internet system. Although most - current implementations fail to meet these requirements in various - ways, some minor and some major, this specification is the ideal - towards which we need to move. - - These requirements are based on the current level of Internet - architecture. This document will be updated as required to provide - additional clarifications or to include additional information in - those areas in which specifications are still evolving. - - This introductory section begins with general advice to host software - vendors, and then gives some guidance on reading the rest of the - document. Section 2 contains general requirements that may be - applicable to all application and support protocols. Sections 3, 4, - and 5 contain the requirements on protocols for the three major - applications: Telnet, file transfer, and electronic mail, - respectively. Section 6 covers the support applications: the domain - name system, system initialization, and management. Finally, all - references will be found in Section 7. - - 1.1 The Internet Architecture - - For a brief introduction to the Internet architecture from a host - viewpoint, see Section 1.1 of [INTRO:1]. That section also - contains recommended references for general background on the - Internet architecture. - - 1.2 General Considerations - - There are two important lessons that vendors of Internet host - software have learned and which a new vendor should consider - seriously. - - 1.2.1 Continuing Internet Evolution - - The enormous growth of the Internet has revealed problems of - management and scaling in a large datagram-based packet - communication system. These problems are being addressed, and - as a result there will be continuing evolution of the - specifications described in this document. These changes will - be carefully planned and controlled, since there is extensive - participation in this planning by the vendors and by the - organizations responsible for operations of the networks. - - - -Internet Engineering Task Force [Page 6] - - - - -RFC1123 INTRODUCTION October 1989 - - - Development, evolution, and revision are characteristic of - computer network protocols today, and this situation will - persist for some years. A vendor who develops computer - communication software for the Internet protocol suite (or any - other protocol suite!) and then fails to maintain and update - that software for changing specifications is going to leave a - trail of unhappy customers. The Internet is a large - communication network, and the users are in constant contact - through it. Experience has shown that knowledge of - deficiencies in vendor software propagates quickly through the - Internet technical community. - - 1.2.2 Robustness Principle - - At every layer of the protocols, there is a general rule whose - application can lead to enormous benefits in robustness and - interoperability: - - "Be liberal in what you accept, and - conservative in what you send" - - Software should be written to deal with every conceivable - error, no matter how unlikely; sooner or later a packet will - come in with that particular combination of errors and - attributes, and unless the software is prepared, chaos can - ensue. In general, it is best to assume that the network is - filled with malevolent entities that will send in packets - designed to have the worst possible effect. This assumption - will lead to suitable protective design, although the most - serious problems in the Internet have been caused by - unenvisaged mechanisms triggered by low-probability events; - mere human malice would never have taken so devious a course! - - Adaptability to change must be designed into all levels of - Internet host software. As a simple example, consider a - protocol specification that contains an enumeration of values - for a particular header field -- e.g., a type field, a port - number, or an error code; this enumeration must be assumed to - be incomplete. Thus, if a protocol specification defines four - possible error codes, the software must not break when a fifth - code shows up. An undefined code might be logged (see below), - but it must not cause a failure. - - The second part of the principle is almost as important: - software on other hosts may contain deficiencies that make it - unwise to exploit legal but obscure protocol features. It is - unwise to stray far from the obvious and simple, lest untoward - effects result elsewhere. A corollary of this is "watch out - - - -Internet Engineering Task Force [Page 7] - - - - -RFC1123 INTRODUCTION October 1989 - - - for misbehaving hosts"; host software should be prepared, not - just to survive other misbehaving hosts, but also to cooperate - to limit the amount of disruption such hosts can cause to the - shared communication facility. - - 1.2.3 Error Logging - - The Internet includes a great variety of host and gateway - systems, each implementing many protocols and protocol layers, - and some of these contain bugs and mis-features in their - Internet protocol software. As a result of complexity, - diversity, and distribution of function, the diagnosis of user - problems is often very difficult. - - Problem diagnosis will be aided if host implementations include - a carefully designed facility for logging erroneous or - "strange" protocol events. It is important to include as much - diagnostic information as possible when an error is logged. In - particular, it is often useful to record the header(s) of a - packet that caused an error. However, care must be taken to - ensure that error logging does not consume prohibitive amounts - of resources or otherwise interfere with the operation of the - host. - - There is a tendency for abnormal but harmless protocol events - to overflow error logging files; this can be avoided by using a - "circular" log, or by enabling logging only while diagnosing a - known failure. It may be useful to filter and count duplicate - successive messages. One strategy that seems to work well is: - (1) always count abnormalities and make such counts accessible - through the management protocol (see Section 6.3); and (2) - allow the logging of a great variety of events to be - selectively enabled. For example, it might useful to be able - to "log everything" or to "log everything for host X". - - Note that different managements may have differing policies - about the amount of error logging that they want normally - enabled in a host. Some will say, "if it doesn't hurt me, I - don't want to know about it", while others will want to take a - more watchful and aggressive attitude about detecting and - removing protocol abnormalities. - - 1.2.4 Configuration - - It would be ideal if a host implementation of the Internet - protocol suite could be entirely self-configuring. This would - allow the whole suite to be implemented in ROM or cast into - silicon, it would simplify diskless workstations, and it would - - - -Internet Engineering Task Force [Page 8] - - - - -RFC1123 INTRODUCTION October 1989 - - - be an immense boon to harried LAN administrators as well as - system vendors. We have not reached this ideal; in fact, we - are not even close. - - At many points in this document, you will find a requirement - that a parameter be a configurable option. There are several - different reasons behind such requirements. In a few cases, - there is current uncertainty or disagreement about the best - value, and it may be necessary to update the recommended value - in the future. In other cases, the value really depends on - external factors -- e.g., the size of the host and the - distribution of its communication load, or the speeds and - topology of nearby networks -- and self-tuning algorithms are - unavailable and may be insufficient. In some cases, - configurability is needed because of administrative - requirements. - - Finally, some configuration options are required to communicate - with obsolete or incorrect implementations of the protocols, - distributed without sources, that unfortunately persist in many - parts of the Internet. To make correct systems coexist with - these faulty systems, administrators often have to "mis- - configure" the correct systems. This problem will correct - itself gradually as the faulty systems are retired, but it - cannot be ignored by vendors. - - When we say that a parameter must be configurable, we do not - intend to require that its value be explicitly read from a - configuration file at every boot time. We recommend that - implementors set up a default for each parameter, so a - configuration file is only necessary to override those defaults - that are inappropriate in a particular installation. Thus, the - configurability requirement is an assurance that it will be - POSSIBLE to override the default when necessary, even in a - binary-only or ROM-based product. - - This document requires a particular value for such defaults in - some cases. The choice of default is a sensitive issue when - the configuration item controls the accommodation to existing - faulty systems. If the Internet is to converge successfully to - complete interoperability, the default values built into - implementations must implement the official protocol, not - "mis-configurations" to accommodate faulty implementations. - Although marketing considerations have led some vendors to - choose mis-configuration defaults, we urge vendors to choose - defaults that will conform to the standard. - - Finally, we note that a vendor needs to provide adequate - - - -Internet Engineering Task Force [Page 9] - - - - -RFC1123 INTRODUCTION October 1989 - - - documentation on all configuration parameters, their limits and - effects. - - - 1.3 Reading this Document - - 1.3.1 Organization - - In general, each major section is organized into the following - subsections: - - (1) Introduction - - (2) Protocol Walk-Through -- considers the protocol - specification documents section-by-section, correcting - errors, stating requirements that may be ambiguous or - ill-defined, and providing further clarification or - explanation. - - (3) Specific Issues -- discusses protocol design and - implementation issues that were not included in the walk- - through. - - (4) Interfaces -- discusses the service interface to the next - higher layer. - - (5) Summary -- contains a summary of the requirements of the - section. - - Under many of the individual topics in this document, there is - parenthetical material labeled "DISCUSSION" or - "IMPLEMENTATION". This material is intended to give - clarification and explanation of the preceding requirements - text. It also includes some suggestions on possible future - directions or developments. The implementation material - contains suggested approaches that an implementor may want to - consider. - - The summary sections are intended to be guides and indexes to - the text, but are necessarily cryptic and incomplete. The - summaries should never be used or referenced separately from - the complete RFC. - - 1.3.2 Requirements - - In this document, the words that are used to define the - significance of each particular requirement are capitalized. - These words are: - - - -Internet Engineering Task Force [Page 10] - - - - -RFC1123 INTRODUCTION October 1989 - - - * "MUST" - - This word or the adjective "REQUIRED" means that the item - is an absolute requirement of the specification. - - * "SHOULD" - - This word or the adjective "RECOMMENDED" means that there - may exist valid reasons in particular circumstances to - ignore this item, but the full implications should be - understood and the case carefully weighed before choosing - a different course. - - * "MAY" - - This word or the adjective "OPTIONAL" means that this item - is truly optional. One vendor may choose to include the - item because a particular marketplace requires it or - because it enhances the product, for example; another - vendor may omit the same item. - - - An implementation is not compliant if it fails to satisfy one - or more of the MUST requirements for the protocols it - implements. An implementation that satisfies all the MUST and - all the SHOULD requirements for its protocols is said to be - "unconditionally compliant"; one that satisfies all the MUST - requirements but not all the SHOULD requirements for its - protocols is said to be "conditionally compliant". - - 1.3.3 Terminology - - This document uses the following technical terms: - - Segment - A segment is the unit of end-to-end transmission in the - TCP protocol. A segment consists of a TCP header followed - by application data. A segment is transmitted by - encapsulation in an IP datagram. - - Message - This term is used by some application layer protocols - (particularly SMTP) for an application data unit. - - Datagram - A [UDP] datagram is the unit of end-to-end transmission in - the UDP protocol. - - - - -Internet Engineering Task Force [Page 11] - - - - -RFC1123 INTRODUCTION October 1989 - - - Multihomed - A host is said to be multihomed if it has multiple IP - addresses to connected networks. - - - - 1.4 Acknowledgments - - This document incorporates contributions and comments from a large - group of Internet protocol experts, including representatives of - university and research labs, vendors, and government agencies. - It was assembled primarily by the Host Requirements Working Group - of the Internet Engineering Task Force (IETF). - - The Editor would especially like to acknowledge the tireless - dedication of the following people, who attended many long - meetings and generated 3 million bytes of electronic mail over the - past 18 months in pursuit of this document: Philip Almquist, Dave - Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve - Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), - John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), - Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge - (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software). - - In addition, the following people made major contributions to the - effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia - (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA), - Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), - John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill - Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul - (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue - Technology), and Mike StJohns (DCA). The following also made - significant contributions to particular areas: Eric Allman - (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic - (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn - (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann - (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun - Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen - (Toronto). - - We are grateful to all, including any contributors who may have - been inadvertently omitted from this list. - - - - - - - - - -Internet Engineering Task Force [Page 12] - - - - -RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 - - -2. GENERAL ISSUES - - This section contains general requirements that may be applicable to - all application-layer protocols. - - 2.1 Host Names and Numbers - - The syntax of a legal Internet host name was specified in RFC-952 - [DNS:4]. One aspect of host name syntax is hereby changed: the - restriction on the first character is relaxed to allow either a - letter or a digit. Host software MUST support this more liberal - syntax. - - Host software MUST handle host names of up to 63 characters and - SHOULD handle host names of up to 255 characters. - - Whenever a user inputs the identity of an Internet host, it SHOULD - be possible to enter either (1) a host domain name or (2) an IP - address in dotted-decimal ("#.#.#.#") form. The host SHOULD check - the string syntactically for a dotted-decimal number before - looking it up in the Domain Name System. - - DISCUSSION: - This last requirement is not intended to specify the complete - syntactic form for entering a dotted-decimal host number; - that is considered to be a user-interface issue. For - example, a dotted-decimal number must be enclosed within - "[ ]" brackets for SMTP mail (see Section 5.2.17). This - notation could be made universal within a host system, - simplifying the syntactic checking for a dotted-decimal - number. - - If a dotted-decimal number can be entered without such - identifying delimiters, then a full syntactic check must be - made, because a segment of a host domain name is now allowed - to begin with a digit and could legally be entirely numeric - (see Section 6.1.2.4). However, a valid host name can never - have the dotted-decimal form #.#.#.#, since at least the - highest-level component label will be alphabetic. - - 2.2 Using Domain Name Service - - Host domain names MUST be translated to IP addresses as described - in Section 6.1. - - Applications using domain name services MUST be able to cope with - soft error conditions. Applications MUST wait a reasonable - interval between successive retries due to a soft error, and MUST - - - -Internet Engineering Task Force [Page 13] - - - - -RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 - - - allow for the possibility that network problems may deny service - for hours or even days. - - An application SHOULD NOT rely on the ability to locate a WKS - record containing an accurate listing of all services at a - particular host address, since the WKS RR type is not often used - by Internet sites. To confirm that a service is present, simply - attempt to use it. - - 2.3 Applications on Multihomed hosts - - When the remote host is multihomed, the name-to-address - translation will return a list of alternative IP addresses. As - specified in Section 6.1.3.4, this list should be in order of - decreasing preference. Application protocol implementations - SHOULD be prepared to try multiple addresses from the list until - success is obtained. More specific requirements for SMTP are - given in Section 5.3.4. - - When the local host is multihomed, a UDP-based request/response - application SHOULD send the response with an IP source address - that is the same as the specific destination address of the UDP - request datagram. The "specific destination address" is defined - in the "IP Addressing" section of the companion RFC [INTRO:1]. - - Similarly, a server application that opens multiple TCP - connections to the same client SHOULD use the same local IP - address for all. - - 2.4 Type-of-Service - - Applications MUST select appropriate TOS values when they invoke - transport layer services, and these values MUST be configurable. - Note that a TOS value contains 5 bits, of which only the most- - significant 3 bits are currently defined; the other two bits MUST - be zero. - - DISCUSSION: - As gateway algorithms are developed to implement Type-of- - Service, the recommended values for various application - protocols may change. In addition, it is likely that - particular combinations of users and Internet paths will want - non-standard TOS values. For these reasons, the TOS values - must be configurable. - - See the latest version of the "Assigned Numbers" RFC - [INTRO:5] for the recommended TOS values for the major - application protocols. - - - -Internet Engineering Task Force [Page 14] - - - - -RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 - - - 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e ------------------------------------------------|----------|-|-|-|-|-|-- - | | | | | | | -User interfaces: | | | | | | | - Allow host name to begin with digit |2.1 |x| | | | | - Host names of up to 635 characters |2.1 |x| | | | | - Host names of up to 255 characters |2.1 | |x| | | | - Support dotted-decimal host numbers |2.1 | |x| | | | - Check syntactically for dotted-dec first |2.1 | |x| | | | - | | | | | | | -Map domain names per Section 6.1 |2.2 |x| | | | | -Cope with soft DNS errors |2.2 |x| | | | | - Reasonable interval between retries |2.2 |x| | | | | - Allow for long outages |2.2 |x| | | | | -Expect WKS records to be available |2.2 | | | |x| | - | | | | | | | -Try multiple addr's for remote multihomed host |2.3 | |x| | | | -UDP reply src addr is specific dest of request |2.3 | |x| | | | -Use same IP addr for related TCP connections |2.3 | |x| | | | -Specify appropriate TOS values |2.4 |x| | | | | - TOS values configurable |2.4 |x| | | | | - Unused TOS bits zero |2.4 |x| | | | | - | | | | | | | - | | | | | | | - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 15] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - -3. REMOTE LOGIN -- TELNET PROTOCOL - - 3.1 INTRODUCTION - - Telnet is the standard Internet application protocol for remote - login. It provides the encoding rules to link a user's - keyboard/display on a client ("user") system with a command - interpreter on a remote server system. A subset of the Telnet - protocol is also incorporated within other application protocols, - e.g., FTP and SMTP. - - Telnet uses a single TCP connection, and its normal data stream - ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with - escape sequences to embed control functions. Telnet also allows - the negotiation of many optional modes and functions. - - The primary Telnet specification is to be found in RFC-854 - [TELNET:1], while the options are defined in many other RFCs; see - Section 7 for references. - - 3.2 PROTOCOL WALK-THROUGH - - 3.2.1 Option Negotiation: RFC-854, pp. 2-3 - - Every Telnet implementation MUST include option negotiation and - subnegotiation machinery [TELNET:2]. - - A host MUST carefully follow the rules of RFC-854 to avoid - option-negotiation loops. A host MUST refuse (i.e, reply - WONT/DONT to a DO/WILL) an unsupported option. Option - negotiation SHOULD continue to function (even if all requests - are refused) throughout the lifetime of a Telnet connection. - - If all option negotiations fail, a Telnet implementation MUST - default to, and support, an NVT. - - DISCUSSION: - Even though more sophisticated "terminals" and supporting - option negotiations are becoming the norm, all - implementations must be prepared to support an NVT for any - user-server communication. - - 3.2.2 Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858 - - On a host that never sends the Telnet command Go Ahead (GA), - the Telnet Server MUST attempt to negotiate the Suppress Go - Ahead option (i.e., send "WILL Suppress Go Ahead"). A User or - Server Telnet MUST always accept negotiation of the Suppress Go - - - -Internet Engineering Task Force [Page 16] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - Ahead option. - - When it is driving a full-duplex terminal for which GA has no - meaning, a User Telnet implementation MAY ignore GA commands. - - DISCUSSION: - Half-duplex ("locked-keyboard") line-at-a-time terminals - for which the Go-Ahead mechanism was designed have largely - disappeared from the scene. It turned out to be difficult - to implement sending the Go-Ahead signal in many operating - systems, even some systems that support native half-duplex - terminals. The difficulty is typically that the Telnet - server code does not have access to information about - whether the user process is blocked awaiting input from - the Telnet connection, i.e., it cannot reliably determine - when to send a GA command. Therefore, most Telnet Server - hosts do not send GA commands. - - The effect of the rules in this section is to allow either - end of a Telnet connection to veto the use of GA commands. - - There is a class of half-duplex terminals that is still - commercially important: "data entry terminals," which - interact in a full-screen manner. However, supporting - data entry terminals using the Telnet protocol does not - require the Go Ahead signal; see Section 3.3.2. - - 3.2.3 Control Functions: RFC-854, pp. 7-8 - - The list of Telnet commands has been extended to include EOR - (End-of-Record), with code 239 [TELNET:9]. - - Both User and Server Telnets MAY support the control functions - EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP, - SB, and SE. - - A host MUST be able to receive and ignore any Telnet control - functions that it does not support. - - DISCUSSION: - Note that a Server Telnet is required to support the - Telnet IP (Interrupt Process) function, even if the server - host has an equivalent in-stream function (e.g., Control-C - in many systems). The Telnet IP function may be stronger - than an in-stream interrupt command, because of the out- - of-band effect of TCP urgent data. - - The EOR control function may be used to delimit the - - - -Internet Engineering Task Force [Page 17] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - stream. An important application is data entry terminal - support (see Section 3.3.2). There was concern that since - EOR had not been defined in RFC-854, a host that was not - prepared to correctly ignore unknown Telnet commands might - crash if it received an EOR. To protect such hosts, the - End-of-Record option [TELNET:9] was introduced; however, a - properly implemented Telnet program will not require this - protection. - - 3.2.4 Telnet "Synch" Signal: RFC-854, pp. 8-10 - - When it receives "urgent" TCP data, a User or Server Telnet - MUST discard all data except Telnet commands until the DM (and - end of urgent) is reached. - - When it sends Telnet IP (Interrupt Process), a User Telnet - SHOULD follow it by the Telnet "Synch" sequence, i.e., send as - TCP urgent data the sequence "IAC IP IAC DM". The TCP urgent - pointer points to the DM octet. - - When it receives a Telnet IP command, a Server Telnet MAY send - a Telnet "Synch" sequence back to the user, to flush the output - stream. The choice ought to be consistent with the way the - server operating system behaves when a local user interrupts a - process. - - When it receives a Telnet AO command, a Server Telnet MUST send - a Telnet "Synch" sequence back to the user, to flush the output - stream. - - A User Telnet SHOULD have the capability of flushing output - when it sends a Telnet IP; see also Section 3.4.5. - - DISCUSSION: - There are three possible ways for a User Telnet to flush - the stream of server output data: - - (1) Send AO after IP. - - This will cause the server host to send a "flush- - buffered-output" signal to its operating system. - However, the AO may not take effect locally, i.e., - stop terminal output at the User Telnet end, until - the Server Telnet has received and processed the AO - and has sent back a "Synch". - - (2) Send DO TIMING-MARK [TELNET:7] after IP, and discard - all output locally until a WILL/WONT TIMING-MARK is - - - -Internet Engineering Task Force [Page 18] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - received from the Server Telnet. - - Since the DO TIMING-MARK will be processed after the - IP at the server, the reply to it should be in the - right place in the output data stream. However, the - TIMING-MARK will not send a "flush buffered output" - signal to the server operating system. Whether or - not this is needed is dependent upon the server - system. - - (3) Do both. - - The best method is not entirely clear, since it must - accommodate a number of existing server hosts that do not - follow the Telnet standards in various ways. The safest - approach is probably to provide a user-controllable option - to select (1), (2), or (3). - - 3.2.5 NVT Printer and Keyboard: RFC-854, p. 11 - - In NVT mode, a Telnet SHOULD NOT send characters with the - high-order bit 1, and MUST NOT send it as a parity bit. - Implementations that pass the high-order bit to applications - SHOULD negotiate binary mode (see Section 3.2.6). - - - DISCUSSION: - Implementors should be aware that a strict reading of - RFC-854 allows a client or server expecting NVT ASCII to - ignore characters with the high-order bit set. In - general, binary mode is expected to be used for - transmission of an extended (beyond 7-bit) character set - with Telnet. - - However, there exist applications that really need an 8- - bit NVT mode, which is currently not defined, and these - existing applications do set the high-order bit during - part or all of the life of a Telnet connection. Note that - binary mode is not the same as 8-bit NVT mode, since - binary mode turns off end-of-line processing. For this - reason, the requirements on the high-order bit are stated - as SHOULD, not MUST. - - RFC-854 defines a minimal set of properties of a "network - virtual terminal" or NVT; this is not meant to preclude - additional features in a real terminal. A Telnet - connection is fully transparent to all 7-bit ASCII - characters, including arbitrary ASCII control characters. - - - -Internet Engineering Task Force [Page 19] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - For example, a terminal might support full-screen commands - coded as ASCII escape sequences; a Telnet implementation - would pass these sequences as uninterpreted data. Thus, - an NVT should not be conceived as a terminal type of a - highly-restricted device. - - 3.2.6 Telnet Command Structure: RFC-854, p. 13 - - Since options may appear at any point in the data stream, a - Telnet escape character (known as IAC, with the value 255) to - be sent as data MUST be doubled. - - 3.2.7 Telnet Binary Option: RFC-856 - - When the Binary option has been successfully negotiated, - arbitrary 8-bit characters are allowed. However, the data - stream MUST still be scanned for IAC characters, any embedded - Telnet commands MUST be obeyed, and data bytes equal to IAC - MUST be doubled. Other character processing (e.g., replacing - CR by CR NUL or by CR LF) MUST NOT be done. In particular, - there is no end-of-line convention (see Section 3.3.1) in - binary mode. - - DISCUSSION: - The Binary option is normally negotiated in both - directions, to change the Telnet connection from NVT mode - to "binary mode". - - The sequence IAC EOR can be used to delimit blocks of data - within a binary-mode Telnet stream. - - 3.2.8 Telnet Terminal-Type Option: RFC-1091 - - The Terminal-Type option MUST use the terminal type names - officially defined in the Assigned Numbers RFC [INTRO:5], when - they are available for the particular terminal. However, the - receiver of a Terminal-Type option MUST accept any name. - - DISCUSSION: - RFC-1091 [TELNET:10] updates an earlier version of the - Terminal-Type option defined in RFC-930. The earlier - version allowed a server host capable of supporting - multiple terminal types to learn the type of a particular - client's terminal, assuming that each physical terminal - had an intrinsic type. However, today a "terminal" is - often really a terminal emulator program running in a PC, - perhaps capable of emulating a range of terminal types. - Therefore, RFC-1091 extends the specification to allow a - - - -Internet Engineering Task Force [Page 20] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - more general terminal-type negotiation between User and - Server Telnets. - - 3.3 SPECIFIC ISSUES - - 3.3.1 Telnet End-of-Line Convention - - The Telnet protocol defines the sequence CR LF to mean "end- - of-line". For terminal input, this corresponds to a command- - completion or "end-of-line" key being pressed on a user - terminal; on an ASCII terminal, this is the CR key, but it may - also be labelled "Return" or "Enter". - - When a Server Telnet receives the Telnet end-of-line sequence - CR LF as input from a remote terminal, the effect MUST be the - same as if the user had pressed the "end-of-line" key on a - local terminal. On server hosts that use ASCII, in particular, - receipt of the Telnet sequence CR LF must cause the same effect - as a local user pressing the CR key on a local terminal. Thus, - CR LF and CR NUL MUST have the same effect on an ASCII server - host when received as input over a Telnet connection. - - A User Telnet MUST be able to send any of the forms: CR LF, CR - NUL, and LF. A User Telnet on an ASCII host SHOULD have a - user-controllable mode to send either CR LF or CR NUL when the - user presses the "end-of-line" key, and CR LF SHOULD be the - default. - - The Telnet end-of-line sequence CR LF MUST be used to send - Telnet data that is not terminal-to-computer (e.g., for Server - Telnet sending output, or the Telnet protocol incorporated - another application protocol). - - DISCUSSION: - To allow interoperability between arbitrary Telnet clients - and servers, the Telnet protocol defined a standard - representation for a line terminator. Since the ASCII - character set includes no explicit end-of-line character, - systems have chosen various representations, e.g., CR, LF, - and the sequence CR LF. The Telnet protocol chose the CR - LF sequence as the standard for network transmission. - - Unfortunately, the Telnet protocol specification in RFC- - 854 [TELNET:1] has turned out to be somewhat ambiguous on - what character(s) should be sent from client to server for - the "end-of-line" key. The result has been a massive and - continuing interoperability headache, made worse by - various faulty implementations of both User and Server - - - -Internet Engineering Task Force [Page 21] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - Telnets. - - Although the Telnet protocol is based on a perfectly - symmetric model, in a remote login session the role of the - user at a terminal differs from the role of the server - host. For example, RFC-854 defines the meaning of CR, LF, - and CR LF as output from the server, but does not specify - what the User Telnet should send when the user presses the - "end-of-line" key on the terminal; this turns out to be - the point at issue. - - When a user presses the "end-of-line" key, some User - Telnet implementations send CR LF, while others send CR - NUL (based on a different interpretation of the same - sentence in RFC-854). These will be equivalent for a - correctly-implemented ASCII server host, as discussed - above. For other servers, a mode in the User Telnet is - needed. - - The existence of User Telnets that send only CR NUL when - CR is pressed creates a dilemma for non-ASCII hosts: they - can either treat CR NUL as equivalent to CR LF in input, - thus precluding the possibility of entering a "bare" CR, - or else lose complete interworking. - - Suppose a user on host A uses Telnet to log into a server - host B, and then execute B's User Telnet program to log - into server host C. It is desirable for the Server/User - Telnet combination on B to be as transparent as possible, - i.e., to appear as if A were connected directly to C. In - particular, correct implementation will make B transparent - to Telnet end-of-line sequences, except that CR LF may be - translated to CR NUL or vice versa. - - IMPLEMENTATION: - To understand Telnet end-of-line issues, one must have at - least a general model of the relationship of Telnet to the - local operating system. The Server Telnet process is - typically coupled into the terminal driver software of the - operating system as a pseudo-terminal. A Telnet end-of- - line sequence received by the Server Telnet must have the - same effect as pressing the end-of-line key on a real - locally-connected terminal. - - Operating systems that support interactive character-at- - a-time applications (e.g., editors) typically have two - internal modes for their terminal I/O: a formatted mode, - in which local conventions for end-of-line and other - - - -Internet Engineering Task Force [Page 22] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - formatting rules have been applied to the data stream, and - a "raw" mode, in which the application has direct access - to every character as it was entered. A Server Telnet - must be implemented in such a way that these modes have - the same effect for remote as for local terminals. For - example, suppose a CR LF or CR NUL is received by the - Server Telnet on an ASCII host. In raw mode, a CR - character is passed to the application; in formatted mode, - the local system's end-of-line convention is used. - - 3.3.2 Data Entry Terminals - - DISCUSSION: - In addition to the line-oriented and character-oriented - ASCII terminals for which Telnet was designed, there are - several families of video display terminals that are - sometimes known as "data entry terminals" or DETs. The - IBM 3270 family is a well-known example. - - Two Internet protocols have been designed to support - generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET - option [TELNET:18, TELNET:19]. The DET option drives a - data entry terminal over a Telnet connection using (sub-) - negotiation. SUPDUP is a completely separate terminal - protocol, which can be entered from Telnet by negotiation. - Although both SUPDUP and the DET option have been used - successfully in particular environments, neither has - gained general acceptance or wide implementation. - - A different approach to DET interaction has been developed - for supporting the IBM 3270 family through Telnet, - although the same approach would be applicable to any DET. - The idea is to enter a "native DET" mode, in which the - native DET input/output stream is sent as binary data. - The Telnet EOR command is used to delimit logical records - (e.g., "screens") within this binary stream. - - IMPLEMENTATION: - The rules for entering and leaving native DET mode are as - follows: - - o The Server uses the Terminal-Type option [TELNET:10] - to learn that the client is a DET. - - o It is conventional, but not required, that both ends - negotiate the EOR option [TELNET:9]. - - o Both ends negotiate the Binary option [TELNET:3] to - - - -Internet Engineering Task Force [Page 23] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - enter native DET mode. - - o When either end negotiates out of binary mode, the - other end does too, and the mode then reverts to - normal NVT. - - - 3.3.3 Option Requirements - - Every Telnet implementation MUST support the Binary option - [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and - SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of- - Record [TELNET:9], and Extended Options List [TELNET:8] - options. - - A User or Server Telnet SHOULD support the Window Size Option - [TELNET:12] if the local operating system provides the - corresponding capability. - - DISCUSSION: - Note that the End-of-Record option only signifies that a - Telnet can receive a Telnet EOR without crashing; - therefore, every Telnet ought to be willing to accept - negotiation of the End-of-Record option. See also the - discussion in Section 3.2.3. - - 3.3.4 Option Initiation - - When the Telnet protocol is used in a client/server situation, - the server SHOULD initiate negotiation of the terminal - interaction mode it expects. - - DISCUSSION: - The Telnet protocol was defined to be perfectly - symmetrical, but its application is generally asymmetric. - Remote login has been known to fail because NEITHER side - initiated negotiation of the required non-default terminal - modes. It is generally the server that determines the - preferred mode, so the server needs to initiate the - negotiation; since the negotiation is symmetric, the user - can also initiate it. - - A client (User Telnet) SHOULD provide a means for users to - enable and disable the initiation of option negotiation. - - DISCUSSION: - A user sometimes needs to connect to an application - service (e.g., FTP or SMTP) that uses Telnet for its - - - -Internet Engineering Task Force [Page 24] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - control stream but does not support Telnet options. User - Telnet may be used for this purpose if initiation of - option negotiation is disabled. - - 3.3.5 Telnet Linemode Option - - DISCUSSION: - An important new Telnet option, LINEMODE [TELNET:12], has - been proposed. The LINEMODE option provides a standard - way for a User Telnet and a Server Telnet to agree that - the client rather than the server will perform terminal - character processing. When the client has prepared a - complete line of text, it will send it to the server in - (usually) one TCP packet. This option will greatly - decrease the packet cost of Telnet sessions and will also - give much better user response over congested or long- - delay networks. - - The LINEMODE option allows dynamic switching between local - and remote character processing. For example, the Telnet - connection will automatically negotiate into single- - character mode while a full screen editor is running, and - then return to linemode when the editor is finished. - - We expect that when this RFC is released, hosts should - implement the client side of this option, and may - implement the server side of this option. To properly - implement the server side, the server needs to be able to - tell the local system not to do any input character - processing, but to remember its current terminal state and - notify the Server Telnet process whenever the state - changes. This will allow password echoing and full screen - editors to be handled properly, for example. - - 3.4 TELNET/USER INTERFACE - - 3.4.1 Character Set Transparency - - User Telnet implementations SHOULD be able to send or receive - any 7-bit ASCII character. Where possible, any special - character interpretations by the user host's operating system - SHOULD be bypassed so that these characters can conveniently be - sent and received on the connection. - - Some character value MUST be reserved as "escape to command - mode"; conventionally, doubling this character allows it to be - entered as data. The specific character used SHOULD be user - selectable. - - - -Internet Engineering Task Force [Page 25] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - On binary-mode connections, a User Telnet program MAY provide - an escape mechanism for entering arbitrary 8-bit values, if the - host operating system doesn't allow them to be entered directly - from the keyboard. - - IMPLEMENTATION: - The transparency issues are less pressing on servers, but - implementors should take care in dealing with issues like: - masking off parity bits (sent by an older, non-conforming - client) before they reach programs that expect only NVT - ASCII, and properly handling programs that request 8-bit - data streams. - - 3.4.2 Telnet Commands - - A User Telnet program MUST provide a user the capability of - entering any of the Telnet control functions IP, AO, or AYT, - and SHOULD provide the capability of entering EC, EL, and - Break. - - 3.4.3 TCP Connection Errors - - A User Telnet program SHOULD report to the user any TCP errors - that are reported by the transport layer (see "TCP/Application - Layer Interface" section in [INTRO:1]). - - 3.4.4 Non-Default Telnet Contact Port - - A User Telnet program SHOULD allow the user to optionally - specify a non-standard contact port number at the Server Telnet - host. - - 3.4.5 Flushing Output - - A User Telnet program SHOULD provide the user the ability to - specify whether or not output should be flushed when an IP is - sent; see Section 3.2.4. - - For any output flushing scheme that causes the User Telnet to - flush output locally until a Telnet signal is received from the - Server, there SHOULD be a way for the user to manually restore - normal output, in case the Server fails to send the expected - signal. - - - - - - - - -Internet Engineering Task Force [Page 26] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - 3.5. TELNET REQUIREMENTS SUMMARY - - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e --------------------------------------------------|--------|-|-|-|-|-|-- - | | | | | | | -Option Negotiation |3.2.1 |x| | | | | - Avoid negotiation loops |3.2.1 |x| | | | | - Refuse unsupported options |3.2.1 |x| | | | | - Negotiation OK anytime on connection |3.2.1 | |x| | | | - Default to NVT |3.2.1 |x| | | | | - Send official name in Term-Type option |3.2.8 |x| | | | | - Accept any name in Term-Type option |3.2.8 |x| | | | | - Implement Binary, Suppress-GA options |3.3.3 |x| | | | | - Echo, Status, EOL, Ext-Opt-List options |3.3.3 | |x| | | | - Implement Window-Size option if appropriate |3.3.3 | |x| | | | - Server initiate mode negotiations |3.3.4 | |x| | | | - User can enable/disable init negotiations |3.3.4 | |x| | | | - | | | | | | | -Go-Aheads | | | | | | | - Non-GA server negotiate SUPPRESS-GA option |3.2.2 |x| | | | | - User or Server accept SUPPRESS-GA option |3.2.2 |x| | | | | - User Telnet ignore GA's |3.2.2 | | |x| | | - | | | | | | | -Control Functions | | | | | | | - Support SE NOP DM IP AO AYT SB |3.2.3 |x| | | | | - Support EOR EC EL Break |3.2.3 | | |x| | | - Ignore unsupported control functions |3.2.3 |x| | | | | - User, Server discard urgent data up to DM |3.2.4 |x| | | | | - User Telnet send "Synch" after IP, AO, AYT |3.2.4 | |x| | | | - Server Telnet reply Synch to IP |3.2.4 | | |x| | | - Server Telnet reply Synch to AO |3.2.4 |x| | | | | - User Telnet can flush output when send IP |3.2.4 | |x| | | | - | | | | | | | -Encoding | | | | | | | - Send high-order bit in NVT mode |3.2.5 | | | |x| | - Send high-order bit as parity bit |3.2.5 | | | | |x| - Negot. BINARY if pass high-ord. bit to applic |3.2.5 | |x| | | | - Always double IAC data byte |3.2.6 |x| | | | | - - - -Internet Engineering Task Force [Page 27] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - Double IAC data byte in binary mode |3.2.7 |x| | | | | - Obey Telnet cmds in binary mode |3.2.7 |x| | | | | - End-of-line, CR NUL in binary mode |3.2.7 | | | | |x| - | | | | | | | -End-of-Line | | | | | | | - EOL at Server same as local end-of-line |3.3.1 |x| | | | | - ASCII Server accept CR LF or CR NUL for EOL |3.3.1 |x| | | | | - User Telnet able to send CR LF, CR NUL, or LF |3.3.1 |x| | | | | - ASCII user able to select CR LF/CR NUL |3.3.1 | |x| | | | - User Telnet default mode is CR LF |3.3.1 | |x| | | | - Non-interactive uses CR LF for EOL |3.3.1 |x| | | | | - | | | | | | | -User Telnet interface | | | | | | | - Input & output all 7-bit characters |3.4.1 | |x| | | | - Bypass local op sys interpretation |3.4.1 | |x| | | | - Escape character |3.4.1 |x| | | | | - User-settable escape character |3.4.1 | |x| | | | - Escape to enter 8-bit values |3.4.1 | | |x| | | - Can input IP, AO, AYT |3.4.2 |x| | | | | - Can input EC, EL, Break |3.4.2 | |x| | | | - Report TCP connection errors to user |3.4.3 | |x| | | | - Optional non-default contact port |3.4.4 | |x| | | | - Can spec: output flushed when IP sent |3.4.5 | |x| | | | - Can manually restore output mode |3.4.5 | |x| | | | - | | | | | | | - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 28] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - -4. FILE TRANSFER - - 4.1 FILE TRANSFER PROTOCOL -- FTP - - 4.1.1 INTRODUCTION - - The File Transfer Protocol FTP is the primary Internet standard - for file transfer. The current specification is contained in - RFC-959 [FTP:1]. - - FTP uses separate simultaneous TCP connections for control and - for data transfer. The FTP protocol includes many features, - some of which are not commonly implemented. However, for every - feature in FTP, there exists at least one implementation. The - minimum implementation defined in RFC-959 was too small, so a - somewhat larger minimum implementation is defined here. - - Internet users have been unnecessarily burdened for years by - deficient FTP implementations. Protocol implementors have - suffered from the erroneous opinion that implementing FTP ought - to be a small and trivial task. This is wrong, because FTP has - a user interface, because it has to deal (correctly) with the - whole variety of communication and operating system errors that - may occur, and because it has to handle the great diversity of - real file systems in the world. - - 4.1.2. PROTOCOL WALK-THROUGH - - 4.1.2.1 LOCAL Type: RFC-959 Section 3.1.1.4 - - An FTP program MUST support TYPE I ("IMAGE" or binary type) - as well as TYPE L 8 ("LOCAL" type with logical byte size 8). - A machine whose memory is organized into m-bit words, where - m is not a multiple of 8, MAY also support TYPE L m. - - DISCUSSION: - The command "TYPE L 8" is often required to transfer - binary data between a machine whose memory is organized - into (e.g.) 36-bit words and a machine with an 8-bit - byte organization. For an 8-bit byte machine, TYPE L 8 - is equivalent to IMAGE. - - "TYPE L m" is sometimes specified to the FTP programs - on two m-bit word machines to ensure the correct - transfer of a native-mode binary file from one machine - to the other. However, this command should have the - same effect on these machines as "TYPE I". - - - - -Internet Engineering Task Force [Page 29] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - 4.1.2.2 Telnet Format Control: RFC-959 Section 3.1.1.5.2 - - A host that makes no distinction between TYPE N and TYPE T - SHOULD implement TYPE T to be identical to TYPE N. - - DISCUSSION: - This provision should ease interoperation with hosts - that do make this distinction. - - Many hosts represent text files internally as strings - of ASCII characters, using the embedded ASCII format - effector characters (LF, BS, FF, ...) to control the - format when a file is printed. For such hosts, there - is no distinction between "print" files and other - files. However, systems that use record structured - files typically need a special format for printable - files (e.g., ASA carriage control). For the latter - hosts, FTP allows a choice of TYPE N or TYPE T. - - 4.1.2.3 Page Structure: RFC-959 Section 3.1.2.3 and Appendix I - - Implementation of page structure is NOT RECOMMENDED in - general. However, if a host system does need to implement - FTP for "random access" or "holey" files, it MUST use the - defined page structure format rather than define a new - private FTP format. - - 4.1.2.4 Data Structure Transformations: RFC-959 Section 3.1.2 - - An FTP transformation between record-structure and file- - structure SHOULD be invertible, to the extent possible while - making the result useful on the target host. - - DISCUSSION: - RFC-959 required strict invertibility between record- - structure and file-structure, but in practice, - efficiency and convenience often preclude it. - Therefore, the requirement is being relaxed. There are - two different objectives for transferring a file: - processing it on the target host, or just storage. For - storage, strict invertibility is important. For - processing, the file created on the target host needs - to be in the format expected by application programs on - that host. - - As an example of the conflict, imagine a record- - oriented operating system that requires some data files - to have exactly 80 bytes in each record. While STORing - - - -Internet Engineering Task Force [Page 30] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - a file on such a host, an FTP Server must be able to - pad each line or record to 80 bytes; a later retrieval - of such a file cannot be strictly invertible. - - 4.1.2.5 Data Connection Management: RFC-959 Section 3.3 - - A User-FTP that uses STREAM mode SHOULD send a PORT command - to assign a non-default data port before each transfer - command is issued. - - DISCUSSION: - This is required because of the long delay after a TCP - connection is closed until its socket pair can be - reused, to allow multiple transfers during a single FTP - session. Sending a port command can avoided if a - transfer mode other than stream is used, by leaving the - data transfer connection open between transfers. - - 4.1.2.6 PASV Command: RFC-959 Section 4.1.2 - - A server-FTP MUST implement the PASV command. - - If multiple third-party transfers are to be executed during - the same session, a new PASV command MUST be issued before - each transfer command, to obtain a unique port pair. - - IMPLEMENTATION: - The format of the 227 reply to a PASV command is not - well standardized. In particular, an FTP client cannot - assume that the parentheses shown on page 40 of RFC-959 - will be present (and in fact, Figure 3 on page 43 omits - them). Therefore, a User-FTP program that interprets - the PASV reply must scan the reply for the first digit - of the host and port numbers. - - Note that the host number h1,h2,h3,h4 is the IP address - of the server host that is sending the reply, and that - p1,p2 is a non-default data transfer port that PASV has - assigned. - - 4.1.2.7 LIST and NLST Commands: RFC-959 Section 4.1.3 - - The data returned by an NLST command MUST contain only a - simple list of legal pathnames, such that the server can use - them directly as the arguments of subsequent data transfer - commands for the individual files. - - The data returned by a LIST or NLST command SHOULD use an - - - -Internet Engineering Task Force [Page 31] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - implied TYPE AN, unless the current type is EBCDIC, in which - case an implied TYPE EN SHOULD be used. - - DISCUSSION: - Many FTP clients support macro-commands that will get - or put files matching a wildcard specification, using - NLST to obtain a list of pathnames. The expansion of - "multiple-put" is local to the client, but "multiple- - get" requires cooperation by the server. - - The implied type for LIST and NLST is designed to - provide compatibility with existing User-FTPs, and in - particular with multiple-get commands. - - 4.1.2.8 SITE Command: RFC-959 Section 4.1.3 - - A Server-FTP SHOULD use the SITE command for non-standard - features, rather than invent new private commands or - unstandardized extensions to existing commands. - - 4.1.2.9 STOU Command: RFC-959 Section 4.1.3 - - The STOU command stores into a uniquely named file. When it - receives an STOU command, a Server-FTP MUST return the - actual file name in the "125 Transfer Starting" or the "150 - Opening Data Connection" message that precedes the transfer - (the 250 reply code mentioned in RFC-959 is incorrect). The - exact format of these messages is hereby defined to be as - follows: - - 125 FILE: pppp - 150 FILE: pppp - - where pppp represents the unique pathname of the file that - will be written. - - 4.1.2.10 Telnet End-of-line Code: RFC-959, Page 34 - - Implementors MUST NOT assume any correspondence between READ - boundaries on the control connection and the Telnet EOL - sequences (CR LF). - - DISCUSSION: - Thus, a server-FTP (or User-FTP) must continue reading - characters from the control connection until a complete - Telnet EOL sequence is encountered, before processing - the command (or response, respectively). Conversely, a - single READ from the control connection may include - - - -Internet Engineering Task Force [Page 32] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - more than one FTP command. - - 4.1.2.11 FTP Replies: RFC-959 Section 4.2, Page 35 - - A Server-FTP MUST send only correctly formatted replies on - the control connection. Note that RFC-959 (unlike earlier - versions of the FTP spec) contains no provision for a - "spontaneous" reply message. - - A Server-FTP SHOULD use the reply codes defined in RFC-959 - whenever they apply. However, a server-FTP MAY use a - different reply code when needed, as long as the general - rules of Section 4.2 are followed. When the implementor has - a choice between a 4xx and 5xx reply code, a Server-FTP - SHOULD send a 4xx (temporary failure) code when there is any - reasonable possibility that a failed FTP will succeed a few - hours later. - - A User-FTP SHOULD generally use only the highest-order digit - of a 3-digit reply code for making a procedural decision, to - prevent difficulties when a Server-FTP uses non-standard - reply codes. - - A User-FTP MUST be able to handle multi-line replies. If - the implementation imposes a limit on the number of lines - and if this limit is exceeded, the User-FTP MUST recover, - e.g., by ignoring the excess lines until the end of the - multi-line reply is reached. - - A User-FTP SHOULD NOT interpret a 421 reply code ("Service - not available, closing control connection") specially, but - SHOULD detect closing of the control connection by the - server. - - DISCUSSION: - Server implementations that fail to strictly follow the - reply rules often cause FTP user programs to hang. - Note that RFC-959 resolved ambiguities in the reply - rules found in earlier FTP specifications and must be - followed. - - It is important to choose FTP reply codes that properly - distinguish between temporary and permanent failures, - to allow the successful use of file transfer client - daemons. These programs depend on the reply codes to - decide whether or not to retry a failed transfer; using - a permanent failure code (5xx) for a temporary error - will cause these programs to give up unnecessarily. - - - -Internet Engineering Task Force [Page 33] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - When the meaning of a reply matches exactly the text - shown in RFC-959, uniformity will be enhanced by using - the RFC-959 text verbatim. However, a Server-FTP - implementor is encouraged to choose reply text that - conveys specific system-dependent information, when - appropriate. - - 4.1.2.12 Connections: RFC-959 Section 5.2 - - The words "and the port used" in the second paragraph of - this section of RFC-959 are erroneous (historical), and they - should be ignored. - - On a multihomed server host, the default data transfer port - (L-1) MUST be associated with the same local IP address as - the corresponding control connection to port L. - - A user-FTP MUST NOT send any Telnet controls other than - SYNCH and IP on an FTP control connection. In particular, it - MUST NOT attempt to negotiate Telnet options on the control - connection. However, a server-FTP MUST be capable of - accepting and refusing Telnet negotiations (i.e., sending - DONT/WONT). - - DISCUSSION: - Although the RFC says: "Server- and User- processes - should follow the conventions for the Telnet - protocol...[on the control connection]", it is not the - intent that Telnet option negotiation is to be - employed. - - 4.1.2.13 Minimum Implementation; RFC-959 Section 5.1 - - The following commands and options MUST be supported by - every server-FTP and user-FTP, except in cases where the - underlying file system or operating system does not allow or - support a particular command. - - Type: ASCII Non-print, IMAGE, LOCAL 8 - Mode: Stream - Structure: File, Record* - Commands: - USER, PASS, ACCT, - PORT, PASV, - TYPE, MODE, STRU, - RETR, STOR, APPE, - RNFR, RNTO, DELE, - CWD, CDUP, RMD, MKD, PWD, - - - -Internet Engineering Task Force [Page 34] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - LIST, NLST, - SYST, STAT, - HELP, NOOP, QUIT. - - *Record structure is REQUIRED only for hosts whose file - systems support record structure. - - DISCUSSION: - Vendors are encouraged to implement a larger subset of - the protocol. For example, there are important - robustness features in the protocol (e.g., Restart, - ABOR, block mode) that would be an aid to some Internet - users but are not widely implemented. - - A host that does not have record structures in its file - system may still accept files with STRU R, recording - the byte stream literally. - - 4.1.3 SPECIFIC ISSUES - - 4.1.3.1 Non-standard Command Verbs - - FTP allows "experimental" commands, whose names begin with - "X". If these commands are subsequently adopted as - standards, there may still be existing implementations using - the "X" form. At present, this is true for the directory - commands: - - RFC-959 "Experimental" - - MKD XMKD - RMD XRMD - PWD XPWD - CDUP XCUP - CWD XCWD - - All FTP implementations SHOULD recognize both forms of these - commands, by simply equating them with extra entries in the - command lookup table. - - IMPLEMENTATION: - A User-FTP can access a server that supports only the - "X" forms by implementing a mode switch, or - automatically using the following procedure: if the - RFC-959 form of one of the above commands is rejected - with a 500 or 502 response code, then try the - experimental form; any other response would be passed - to the user. - - - -Internet Engineering Task Force [Page 35] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - 4.1.3.2 Idle Timeout - - A Server-FTP process SHOULD have an idle timeout, which will - terminate the process and close the control connection if - the server is inactive (i.e., no command or data transfer in - progress) for a long period of time. The idle timeout time - SHOULD be configurable, and the default should be at least 5 - minutes. - - A client FTP process ("User-PI" in RFC-959) will need - timeouts on responses only if it is invoked from a program. - - DISCUSSION: - Without a timeout, a Server-FTP process may be left - pending indefinitely if the corresponding client - crashes without closing the control connection. - - 4.1.3.3 Concurrency of Data and Control - - DISCUSSION: - The intent of the designers of FTP was that a user - should be able to send a STAT command at any time while - data transfer was in progress and that the server-FTP - would reply immediately with status -- e.g., the number - of bytes transferred so far. Similarly, an ABOR - command should be possible at any time during a data - transfer. - - Unfortunately, some small-machine operating systems - make such concurrent programming difficult, and some - other implementers seek minimal solutions, so some FTP - implementations do not allow concurrent use of the data - and control connections. Even such a minimal server - must be prepared to accept and defer a STAT or ABOR - command that arrives during data transfer. - - 4.1.3.4 FTP Restart Mechanism - - The description of the 110 reply on pp. 40-41 of RFC-959 is - incorrect; the correct description is as follows. A restart - reply message, sent over the control connection from the - receiving FTP to the User-FTP, has the format: - - 110 MARK ssss = rrrr - - Here: - - * ssss is a text string that appeared in a Restart Marker - - - -Internet Engineering Task Force [Page 36] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - in the data stream and encodes a position in the - sender's file system; - - * rrrr encodes the corresponding position in the - receiver's file system. - - The encoding, which is specific to a particular file system - and network implementation, is always generated and - interpreted by the same system, either sender or receiver. - - When an FTP that implements restart receives a Restart - Marker in the data stream, it SHOULD force the data to that - point to be written to stable storage before encoding the - corresponding position rrrr. An FTP sending Restart Markers - MUST NOT assume that 110 replies will be returned - synchronously with the data, i.e., it must not await a 110 - reply before sending more data. - - Two new reply codes are hereby defined for errors - encountered in restarting a transfer: - - 554 Requested action not taken: invalid REST parameter. - - A 554 reply may result from a FTP service command that - follows a REST command. The reply indicates that the - existing file at the Server-FTP cannot be repositioned - as specified in the REST. - - 555 Requested action not taken: type or stru mismatch. - - A 555 reply may result from an APPE command or from any - FTP service command following a REST command. The - reply indicates that there is some mismatch between the - current transfer parameters (type and stru) and the - attributes of the existing file. - - DISCUSSION: - Note that the FTP Restart mechanism requires that Block - or Compressed mode be used for data transfer, to allow - the Restart Markers to be included within the data - stream. The frequency of Restart Markers can be low. - - Restart Markers mark a place in the data stream, but - the receiver may be performing some transformation on - the data as it is stored into stable storage. In - general, the receiver's encoding must include any state - information necessary to restart this transformation at - any point of the FTP data stream. For example, in TYPE - - - -Internet Engineering Task Force [Page 37] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - A transfers, some receiver hosts transform CR LF - sequences into a single LF character on disk. If a - Restart Marker happens to fall between CR and LF, the - receiver must encode in rrrr that the transfer must be - restarted in a "CR has been seen and discarded" state. - - Note that the Restart Marker is required to be encoded - as a string of printable ASCII characters, regardless - of the type of the data. - - RFC-959 says that restart information is to be returned - "to the user". This should not be taken literally. In - general, the User-FTP should save the restart - information (ssss,rrrr) in stable storage, e.g., append - it to a restart control file. An empty restart control - file should be created when the transfer first starts - and deleted automatically when the transfer completes - successfully. It is suggested that this file have a - name derived in an easily-identifiable manner from the - name of the file being transferred and the remote host - name; this is analogous to the means used by many text - editors for naming "backup" files. - - There are three cases for FTP restart. - - (1) User-to-Server Transfer - - The User-FTP puts Restart Markers <ssss> at - convenient places in the data stream. When the - Server-FTP receives a Marker, it writes all prior - data to disk, encodes its file system position and - transformation state as rrrr, and returns a "110 - MARK ssss = rrrr" reply over the control - connection. The User-FTP appends the pair - (ssss,rrrr) to its restart control file. - - To restart the transfer, the User-FTP fetches the - last (ssss,rrrr) pair from the restart control - file, repositions its local file system and - transformation state using ssss, and sends the - command "REST rrrr" to the Server-FTP. - - (2) Server-to-User Transfer - - The Server-FTP puts Restart Markers <ssss> at - convenient places in the data stream. When the - User-FTP receives a Marker, it writes all prior - data to disk, encodes its file system position and - - - -Internet Engineering Task Force [Page 38] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - transformation state as rrrr, and appends the pair - (rrrr,ssss) to its restart control file. - - To restart the transfer, the User-FTP fetches the - last (rrrr,ssss) pair from the restart control - file, repositions its local file system and - transformation state using rrrr, and sends the - command "REST ssss" to the Server-FTP. - - (3) Server-to-Server ("Third-Party") Transfer - - The sending Server-FTP puts Restart Markers <ssss> - at convenient places in the data stream. When it - receives a Marker, the receiving Server-FTP writes - all prior data to disk, encodes its file system - position and transformation state as rrrr, and - sends a "110 MARK ssss = rrrr" reply over the - control connection to the User. The User-FTP - appends the pair (ssss,rrrr) to its restart - control file. - - To restart the transfer, the User-FTP fetches the - last (ssss,rrrr) pair from the restart control - file, sends "REST ssss" to the sending Server-FTP, - and sends "REST rrrr" to the receiving Server-FTP. - - - 4.1.4 FTP/USER INTERFACE - - This section discusses the user interface for a User-FTP - program. - - 4.1.4.1 Pathname Specification - - Since FTP is intended for use in a heterogeneous - environment, User-FTP implementations MUST support remote - pathnames as arbitrary character strings, so that their form - and content are not limited by the conventions of the local - operating system. - - DISCUSSION: - In particular, remote pathnames can be of arbitrary - length, and all the printing ASCII characters as well - as space (0x20) must be allowed. RFC-959 allows a - pathname to contain any 7-bit ASCII character except CR - or LF. - - - - - -Internet Engineering Task Force [Page 39] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - 4.1.4.2 "QUOTE" Command - - A User-FTP program MUST implement a "QUOTE" command that - will pass an arbitrary character string to the server and - display all resulting response messages to the user. - - To make the "QUOTE" command useful, a User-FTP SHOULD send - transfer control commands to the server as the user enters - them, rather than saving all the commands and sending them - to the server only when a data transfer is started. - - DISCUSSION: - The "QUOTE" command is essential to allow the user to - access servers that require system-specific commands - (e.g., SITE or ALLO), or to invoke new or optional - features that are not implemented by the User-FTP. For - example, "QUOTE" may be used to specify "TYPE A T" to - send a print file to hosts that require the - distinction, even if the User-FTP does not recognize - that TYPE. - - 4.1.4.3 Displaying Replies to User - - A User-FTP SHOULD display to the user the full text of all - error reply messages it receives. It SHOULD have a - "verbose" mode in which all commands it sends and the full - text and reply codes it receives are displayed, for - diagnosis of problems. - - 4.1.4.4 Maintaining Synchronization - - The state machine in a User-FTP SHOULD be forgiving of - missing and unexpected reply messages, in order to maintain - command synchronization with the server. - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 40] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - 4.1.5 FTP REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e --------------------------------------------|---------------|-|-|-|-|-|-- -Implement TYPE T if same as TYPE N |4.1.2.2 | |x| | | | -File/Record transform invertible if poss. |4.1.2.4 | |x| | | | -User-FTP send PORT cmd for stream mode |4.1.2.5 | |x| | | | -Server-FTP implement PASV |4.1.2.6 |x| | | | | - PASV is per-transfer |4.1.2.6 |x| | | | | -NLST reply usable in RETR cmds |4.1.2.7 |x| | | | | -Implied type for LIST and NLST |4.1.2.7 | |x| | | | -SITE cmd for non-standard features |4.1.2.8 | |x| | | | -STOU cmd return pathname as specified |4.1.2.9 |x| | | | | -Use TCP READ boundaries on control conn. |4.1.2.10 | | | | |x| - | | | | | | | -Server-FTP send only correct reply format |4.1.2.11 |x| | | | | -Server-FTP use defined reply code if poss. |4.1.2.11 | |x| | | | - New reply code following Section 4.2 |4.1.2.11 | | |x| | | -User-FTP use only high digit of reply |4.1.2.11 | |x| | | | -User-FTP handle multi-line reply lines |4.1.2.11 |x| | | | | -User-FTP handle 421 reply specially |4.1.2.11 | | | |x| | - | | | | | | | -Default data port same IP addr as ctl conn |4.1.2.12 |x| | | | | -User-FTP send Telnet cmds exc. SYNCH, IP |4.1.2.12 | | | | |x| -User-FTP negotiate Telnet options |4.1.2.12 | | | | |x| -Server-FTP handle Telnet options |4.1.2.12 |x| | | | | -Handle "Experimental" directory cmds |4.1.3.1 | |x| | | | -Idle timeout in server-FTP |4.1.3.2 | |x| | | | - Configurable idle timeout |4.1.3.2 | |x| | | | -Receiver checkpoint data at Restart Marker |4.1.3.4 | |x| | | | -Sender assume 110 replies are synchronous |4.1.3.4 | | | | |x| - | | | | | | | -Support TYPE: | | | | | | | - ASCII - Non-Print (AN) |4.1.2.13 |x| | | | | - ASCII - Telnet (AT) -- if same as AN |4.1.2.2 | |x| | | | - ASCII - Carriage Control (AC) |959 3.1.1.5.2 | | |x| | | - EBCDIC - (any form) |959 3.1.1.2 | | |x| | | - IMAGE |4.1.2.1 |x| | | | | - LOCAL 8 |4.1.2.1 |x| | | | | - - - -Internet Engineering Task Force [Page 41] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - LOCAL m |4.1.2.1 | | |x| | |2 - | | | | | | | -Support MODE: | | | | | | | - Stream |4.1.2.13 |x| | | | | - Block |959 3.4.2 | | |x| | | - | | | | | | | -Support STRUCTURE: | | | | | | | - File |4.1.2.13 |x| | | | | - Record |4.1.2.13 |x| | | | |3 - Page |4.1.2.3 | | | |x| | - | | | | | | | -Support commands: | | | | | | | - USER |4.1.2.13 |x| | | | | - PASS |4.1.2.13 |x| | | | | - ACCT |4.1.2.13 |x| | | | | - CWD |4.1.2.13 |x| | | | | - CDUP |4.1.2.13 |x| | | | | - SMNT |959 5.3.1 | | |x| | | - REIN |959 5.3.1 | | |x| | | - QUIT |4.1.2.13 |x| | | | | - | | | | | | | - PORT |4.1.2.13 |x| | | | | - PASV |4.1.2.6 |x| | | | | - TYPE |4.1.2.13 |x| | | | |1 - STRU |4.1.2.13 |x| | | | |1 - MODE |4.1.2.13 |x| | | | |1 - | | | | | | | - RETR |4.1.2.13 |x| | | | | - STOR |4.1.2.13 |x| | | | | - STOU |959 5.3.1 | | |x| | | - APPE |4.1.2.13 |x| | | | | - ALLO |959 5.3.1 | | |x| | | - REST |959 5.3.1 | | |x| | | - RNFR |4.1.2.13 |x| | | | | - RNTO |4.1.2.13 |x| | | | | - ABOR |959 5.3.1 | | |x| | | - DELE |4.1.2.13 |x| | | | | - RMD |4.1.2.13 |x| | | | | - MKD |4.1.2.13 |x| | | | | - PWD |4.1.2.13 |x| | | | | - LIST |4.1.2.13 |x| | | | | - NLST |4.1.2.13 |x| | | | | - SITE |4.1.2.8 | | |x| | | - STAT |4.1.2.13 |x| | | | | - SYST |4.1.2.13 |x| | | | | - HELP |4.1.2.13 |x| | | | | - NOOP |4.1.2.13 |x| | | | | - | | | | | | | - - - -Internet Engineering Task Force [Page 42] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - -User Interface: | | | | | | | - Arbitrary pathnames |4.1.4.1 |x| | | | | - Implement "QUOTE" command |4.1.4.2 |x| | | | | - Transfer control commands immediately |4.1.4.2 | |x| | | | - Display error messages to user |4.1.4.3 | |x| | | | - Verbose mode |4.1.4.3 | |x| | | | - Maintain synchronization with server |4.1.4.4 | |x| | | | - -Footnotes: - -(1) For the values shown earlier. - -(2) Here m is number of bits in a memory word. - -(3) Required for host with record-structured file system, optional - otherwise. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 43] - - - - -RFC1123 FILE TRANSFER -- TFTP October 1989 - - - 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP - - 4.2.1 INTRODUCTION - - The Trivial File Transfer Protocol TFTP is defined in RFC-783 - [TFTP:1]. - - TFTP provides its own reliable delivery with UDP as its - transport protocol, using a simple stop-and-wait acknowledgment - system. Since TFTP has an effective window of only one 512 - octet segment, it can provide good performance only over paths - that have a small delay*bandwidth product. The TFTP file - interface is very simple, providing no access control or - security. - - TFTP's most important application is bootstrapping a host over - a local network, since it is simple and small enough to be - easily implemented in EPROM [BOOT:1, BOOT:2]. Vendors are - urged to support TFTP for booting. - - 4.2.2 PROTOCOL WALK-THROUGH - - The TFTP specification [TFTP:1] is written in an open style, - and does not fully specify many parts of the protocol. - - 4.2.2.1 Transfer Modes: RFC-783, Page 3 - - The transfer mode "mail" SHOULD NOT be supported. - - 4.2.2.2 UDP Header: RFC-783, Page 17 - - The Length field of a UDP header is incorrectly defined; it - includes the UDP header length (8). - - 4.2.3 SPECIFIC ISSUES - - 4.2.3.1 Sorcerer's Apprentice Syndrome - - There is a serious bug, known as the "Sorcerer's Apprentice - Syndrome," in the protocol specification. While it does not - cause incorrect operation of the transfer (the file will - always be transferred correctly if the transfer completes), - this bug may cause excessive retransmission, which may cause - the transfer to time out. - - Implementations MUST contain the fix for this problem: the - sender (i.e., the side originating the DATA packets) must - never resend the current DATA packet on receipt of a - - - -Internet Engineering Task Force [Page 44] - - - - -RFC1123 FILE TRANSFER -- TFTP October 1989 - - - duplicate ACK. - - DISCUSSION: - The bug is caused by the protocol rule that either - side, on receiving an old duplicate datagram, may - resend the current datagram. If a packet is delayed in - the network but later successfully delivered after - either side has timed out and retransmitted a packet, a - duplicate copy of the response may be generated. If - the other side responds to this duplicate with a - duplicate of its own, then every datagram will be sent - in duplicate for the remainder of the transfer (unless - a datagram is lost, breaking the repetition). Worse - yet, since the delay is often caused by congestion, - this duplicate transmission will usually causes more - congestion, leading to more delayed packets, etc. - - The following example may help to clarify this problem. - - TFTP A TFTP B - - (1) Receive ACK X-1 - Send DATA X - (2) Receive DATA X - Send ACK X - (ACK X is delayed in network, - and A times out): - (3) Retransmit DATA X - - (4) Receive DATA X again - Send ACK X again - (5) Receive (delayed) ACK X - Send DATA X+1 - (6) Receive DATA X+1 - Send ACK X+1 - (7) Receive ACK X again - Send DATA X+1 again - (8) Receive DATA X+1 again - Send ACK X+1 again - (9) Receive ACK X+1 - Send DATA X+2 - (10) Receive DATA X+2 - Send ACK X+3 - (11) Receive ACK X+1 again - Send DATA X+2 again - (12) Receive DATA X+2 again - Send ACK X+3 again - - - - -Internet Engineering Task Force [Page 45] - - - - -RFC1123 FILE TRANSFER -- TFTP October 1989 - - - Notice that once the delayed ACK arrives, the protocol - settles down to duplicate all further packets - (sequences 5-8 and 9-12). The problem is caused not by - either side timing out, but by both sides - retransmitting the current packet when they receive a - duplicate. - - The fix is to break the retransmission loop, as - indicated above. This is analogous to the behavior of - TCP. It is then possible to remove the retransmission - timer on the receiver, since the resent ACK will never - cause any action; this is a useful simplification where - TFTP is used in a bootstrap program. It is OK to allow - the timer to remain, and it may be helpful if the - retransmitted ACK replaces one that was genuinely lost - in the network. The sender still requires a retransmit - timer, of course. - - 4.2.3.2 Timeout Algorithms - - A TFTP implementation MUST use an adaptive timeout. - - IMPLEMENTATION: - TCP retransmission algorithms provide a useful base to - work from. At least an exponential backoff of - retransmission timeout is necessary. - - 4.2.3.3 Extensions - - A variety of non-standard extensions have been made to TFTP, - including additional transfer modes and a secure operation - mode (with passwords). None of these have been - standardized. - - 4.2.3.4 Access Control - - A server TFTP implementation SHOULD include some - configurable access control over what pathnames are allowed - in TFTP operations. - - 4.2.3.5 Broadcast Request - - A TFTP request directed to a broadcast address SHOULD be - silently ignored. - - DISCUSSION: - Due to the weak access control capability of TFTP, - directed broadcasts of TFTP requests to random networks - - - -Internet Engineering Task Force [Page 46] - - - - -RFC1123 FILE TRANSFER -- TFTP October 1989 - - - could create a significant security hole. - - 4.2.4 TFTP REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e --------------------------------------------------|--------|-|-|-|-|-|-- -Fix Sorcerer's Apprentice Syndrome |4.2.3.1 |x| | | | | -Transfer modes: | | | | | | | - netascii |RFC-783 |x| | | | | - octet |RFC-783 |x| | | | | - mail |4.2.2.1 | | | |x| | - extensions |4.2.3.3 | | |x| | | -Use adaptive timeout |4.2.3.2 |x| | | | | -Configurable access control |4.2.3.4 | |x| | | | -Silently ignore broadcast request |4.2.3.5 | |x| | | | --------------------------------------------------|--------|-|-|-|-|-|-- --------------------------------------------------|--------|-|-|-|-|-|-- - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 47] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - -5. ELECTRONIC MAIL -- SMTP and RFC-822 - - 5.1 INTRODUCTION - - In the TCP/IP protocol suite, electronic mail in a format - specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail - Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1]. - - While SMTP has remained unchanged over the years, the Internet - community has made several changes in the way SMTP is used. In - particular, the conversion to the Domain Name System (DNS) has - caused changes in address formats and in mail routing. In this - section, we assume familiarity with the concepts and terminology - of the DNS, whose requirements are given in Section 6.1. - - RFC-822 specifies the Internet standard format for electronic mail - messages. RFC-822 supercedes an older standard, RFC-733, that may - still be in use in a few places, although it is obsolete. The two - formats are sometimes referred to simply by number ("822" and - "733"). - - RFC-822 is used in some non-Internet mail environments with - different mail transfer protocols than SMTP, and SMTP has also - been adapted for use in some non-Internet environments. Note that - this document presents the rules for the use of SMTP and RFC-822 - for the Internet environment only; other mail environments that - use these protocols may be expected to have their own rules. - - 5.2 PROTOCOL WALK-THROUGH - - This section covers both RFC-821 and RFC-822. - - The SMTP specification in RFC-821 is clear and contains numerous - examples, so implementors should not find it difficult to - understand. This section simply updates or annotates portions of - RFC-821 to conform with current usage. - - RFC-822 is a long and dense document, defining a rich syntax. - Unfortunately, incomplete or defective implementations of RFC-822 - are common. In fact, nearly all of the many formats of RFC-822 - are actually used, so an implementation generally needs to - recognize and correctly interpret all of the RFC-822 syntax. - - 5.2.1 The SMTP Model: RFC-821 Section 2 - - DISCUSSION: - Mail is sent by a series of request/response transactions - between a client, the "sender-SMTP," and a server, the - - - -Internet Engineering Task Force [Page 48] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - "receiver-SMTP". These transactions pass (1) the message - proper, which is composed of header and body, and (2) SMTP - source and destination addresses, referred to as the - "envelope". - - The SMTP programs are analogous to Message Transfer Agents - (MTAs) of X.400. There will be another level of protocol - software, closer to the end user, that is responsible for - composing and analyzing RFC-822 message headers; this - component is known as the "User Agent" in X.400, and we - use that term in this document. There is a clear logical - distinction between the User Agent and the SMTP - implementation, since they operate on different levels of - protocol. Note, however, that this distinction is may not - be exactly reflected the structure of typical - implementations of Internet mail. Often there is a - program known as the "mailer" that implements SMTP and - also some of the User Agent functions; the rest of the - User Agent functions are included in a user interface used - for entering and reading mail. - - The SMTP envelope is constructed at the originating site, - typically by the User Agent when the message is first - queued for the Sender-SMTP program. The envelope - addresses may be derived from information in the message - header, supplied by the user interface (e.g., to implement - a bcc: request), or derived from local configuration - information (e.g., expansion of a mailing list). The SMTP - envelope cannot in general be re-derived from the header - at a later stage in message delivery, so the envelope is - transmitted separately from the message itself using the - MAIL and RCPT commands of SMTP. - - The text of RFC-821 suggests that mail is to be delivered - to an individual user at a host. With the advent of the - domain system and of mail routing using mail-exchange (MX) - resource records, implementors should now think of - delivering mail to a user at a domain, which may or may - not be a particular host. This DOES NOT change the fact - that SMTP is a host-to-host mail exchange protocol. - - 5.2.2 Canonicalization: RFC-821 Section 3.1 - - The domain names that a Sender-SMTP sends in MAIL and RCPT - commands MUST have been "canonicalized," i.e., they must be - fully-qualified principal names or domain literals, not - nicknames or domain abbreviations. A canonicalized name either - identifies a host directly or is an MX name; it cannot be a - - - -Internet Engineering Task Force [Page 49] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - CNAME. - - 5.2.3 VRFY and EXPN Commands: RFC-821 Section 3.3 - - A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN - (this requirement overrides RFC-821). However, there MAY be - configuration information to disable VRFY and EXPN in a - particular installation; this might even allow EXPN to be - disabled for selected lists. - - A new reply code is defined for the VRFY command: - - 252 Cannot VRFY user (e.g., info is not local), but will - take message for this user and attempt delivery. - - DISCUSSION: - SMTP users and administrators make regular use of these - commands for diagnosing mail delivery problems. With the - increasing use of multi-level mailing list expansion - (sometimes more than two levels), EXPN has been - increasingly important for diagnosing inadvertent mail - loops. On the other hand, some feel that EXPN represents - a significant privacy, and perhaps even a security, - exposure. - - 5.2.4 SEND, SOML, and SAML Commands: RFC-821 Section 3.4 - - An SMTP MAY implement the commands to send a message to a - user's terminal: SEND, SOML, and SAML. - - DISCUSSION: - It has been suggested that the use of mail relaying - through an MX record is inconsistent with the intent of - SEND to deliver a message immediately and directly to a - user's terminal. However, an SMTP receiver that is unable - to write directly to the user terminal can return a "251 - User Not Local" reply to the RCPT following a SEND, to - inform the originator of possibly deferred delivery. - - 5.2.5 HELO Command: RFC-821 Section 3.5 - - The sender-SMTP MUST ensure that the <domain> parameter in a - HELO command is a valid principal host domain name for the - client host. As a result, the receiver-SMTP will not have to - perform MX resolution on this name in order to validate the - HELO parameter. - - The HELO receiver MAY verify that the HELO parameter really - - - -Internet Engineering Task Force [Page 50] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - corresponds to the IP address of the sender. However, the - receiver MUST NOT refuse to accept a message, even if the - sender's HELO command fails verification. - - DISCUSSION: - Verifying the HELO parameter requires a domain name lookup - and may therefore take considerable time. An alternative - tool for tracking bogus mail sources is suggested below - (see "DATA Command"). - - Note also that the HELO argument is still required to have - valid <domain> syntax, since it will appear in a Received: - line; otherwise, a 501 error is to be sent. - - IMPLEMENTATION: - When HELO parameter validation fails, a suggested - procedure is to insert a note about the unknown - authenticity of the sender into the message header (e.g., - in the "Received:" line). - - 5.2.6 Mail Relay: RFC-821 Section 3.6 - - We distinguish three types of mail (store-and-) forwarding: - - (1) A simple forwarder or "mail exchanger" forwards a message - using private knowledge about the recipient; see section - 3.2 of RFC-821. - - (2) An SMTP mail "relay" forwards a message within an SMTP - mail environment as the result of an explicit source route - (as defined in section 3.6 of RFC-821). The SMTP relay - function uses the "@...:" form of source route from RFC- - 822 (see Section 5.2.19 below). - - (3) A mail "gateway" passes a message between different - environments. The rules for mail gateways are discussed - below in Section 5.3.7. - - An Internet host that is forwarding a message but is not a - gateway to a different mail environment (i.e., it falls under - (1) or (2)) SHOULD NOT alter any existing header fields, - although the host will add an appropriate Received: line as - required in Section 5.2.8. - - A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an - explicit source route using the "@...:" address form. Thus, - the relay function defined in section 3.6 of RFC-821 should - not be used. - - - -Internet Engineering Task Force [Page 51] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - DISCUSSION: - The intent is to discourage all source routing and to - abolish explicit source routing for mail delivery within - the Internet environment. Source-routing is unnecessary; - the simple target address "user@domain" should always - suffice. This is the result of an explicit architectural - decision to use universal naming rather than source - routing for mail. Thus, SMTP provides end-to-end - connectivity, and the DNS provides globally-unique, - location-independent names. MX records handle the major - case where source routing might otherwise be needed. - - A receiver-SMTP MUST accept the explicit source route syntax in - the envelope, but it MAY implement the relay function as - defined in section 3.6 of RFC-821. If it does not implement - the relay function, it SHOULD attempt to deliver the message - directly to the host to the right of the right-most "@" sign. - - DISCUSSION: - For example, suppose a host that does not implement the - relay function receives a message with the SMTP command: - "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and - GAMMA represent domain names. Rather than immediately - refusing the message with a 550 error reply as suggested - on page 20 of RFC-821, the host should try to forward the - message to GAMMA directly, using: "RCPT TO:<joe@GAMMA>". - Since this host does not support relaying, it is not - required to update the reverse path. - - Some have suggested that source routing may be needed - occasionally for manually routing mail around failures; - however, the reality and importance of this need is - controversial. The use of explicit SMTP mail relaying for - this purpose is discouraged, and in fact it may not be - successful, as many host systems do not support it. Some - have used the "%-hack" (see Section 5.2.16) for this - purpose. - - 5.2.7 RCPT Command: RFC-821 Section 4.1.1 - - A host that supports a receiver-SMTP MUST support the reserved - mailbox "Postmaster". - - The receiver-SMTP MAY verify RCPT parameters as they arrive; - however, RCPT responses MUST NOT be delayed beyond a reasonable - time (see Section 5.3.2). - - Therefore, a "250 OK" response to a RCPT does not necessarily - - - -Internet Engineering Task Force [Page 52] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - imply that the delivery address(es) are valid. Errors found - after message acceptance will be reported by mailing a - notification message to an appropriate address (see Section - 5.3.3). - - DISCUSSION: - The set of conditions under which a RCPT parameter can be - validated immediately is an engineering design choice. - Reporting destination mailbox errors to the Sender-SMTP - before mail is transferred is generally desirable to save - time and network bandwidth, but this advantage is lost if - RCPT verification is lengthy. - - For example, the receiver can verify immediately any - simple local reference, such as a single locally- - registered mailbox. On the other hand, the "reasonable - time" limitation generally implies deferring verification - of a mailing list until after the message has been - transferred and accepted, since verifying a large mailing - list can take a very long time. An implementation might - or might not choose to defer validation of addresses that - are non-local and therefore require a DNS lookup. If a - DNS lookup is performed but a soft domain system error - (e.g., timeout) occurs, validity must be assumed. - - 5.2.8 DATA Command: RFC-821 Section 4.1.1 - - Every receiver-SMTP (not just one that "accepts a message for - relaying or for final delivery" [SMTP:1]) MUST insert a - "Received:" line at the beginning of a message. In this line, - called a "time stamp line" in RFC-821: - - * The FROM field SHOULD contain both (1) the name of the - source host as presented in the HELO command and (2) a - domain literal containing the IP address of the source, - determined from the TCP connection. - - * The ID field MAY contain an "@" as suggested in RFC-822, - but this is not required. - - * The FOR field MAY contain a list of <path> entries when - multiple RCPT commands have been given. - - - An Internet mail program MUST NOT change a Received: line that - was previously added to the message header. - - - - - -Internet Engineering Task Force [Page 53] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - DISCUSSION: - Including both the source host and the IP source address - in the Received: line may provide enough information for - tracking illicit mail sources and eliminate a need to - explicitly verify the HELO parameter. - - Received: lines are primarily intended for humans tracing - mail routes, primarily of diagnosis of faults. See also - the discussion under 5.3.7. - - When the receiver-SMTP makes "final delivery" of a message, - then it MUST pass the MAIL FROM: address from the SMTP envelope - with the message, for use if an error notification message must - be sent later (see Section 5.3.3). There is an analogous - requirement when gatewaying from the Internet into a different - mail environment; see Section 5.3.7. - - DISCUSSION: - Note that the final reply to the DATA command depends only - upon the successful transfer and storage of the message. - Any problem with the destination address(es) must either - (1) have been reported in an SMTP error reply to the RCPT - command(s), or (2) be reported in a later error message - mailed to the originator. - - IMPLEMENTATION: - The MAIL FROM: information may be passed as a parameter or - in a Return-Path: line inserted at the beginning of the - message. - - 5.2.9 Command Syntax: RFC-821 Section 4.1.2 - - The syntax shown in RFC-821 for the MAIL FROM: command omits - the case of an empty path: "MAIL FROM: <>" (see RFC-821 Page - 15). An empty reverse path MUST be supported. - - 5.2.10 SMTP Replies: RFC-821 Section 4.2 - - A receiver-SMTP SHOULD send only the reply codes listed in - section 4.2.2 of RFC-821 or in this document. A receiver-SMTP - SHOULD use the text shown in examples in RFC-821 whenever - appropriate. - - A sender-SMTP MUST determine its actions only by the reply - code, not by the text (except for 251 and 551 replies); any - text, including no text at all, must be acceptable. The space - (blank) following the reply code is considered part of the - text. Whenever possible, a sender-SMTP SHOULD test only the - - - -Internet Engineering Task Force [Page 54] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - first digit of the reply code, as specified in Appendix E of - RFC-821. - - DISCUSSION: - Interoperability problems have arisen with SMTP systems - using reply codes that are not listed explicitly in RFC- - 821 Section 4.3 but are legal according to the theory of - reply codes explained in Appendix E. - - 5.2.11 Transparency: RFC-821 Section 4.5.2 - - Implementors MUST be sure that their mail systems always add - and delete periods to ensure message transparency. - - 5.2.12 WKS Use in MX Processing: RFC-974, p. 5 - - RFC-974 [SMTP:3] recommended that the domain system be queried - for WKS ("Well-Known Service") records, to verify that each - proposed mail target does support SMTP. Later experience has - shown that WKS is not widely supported, so the WKS step in MX - processing SHOULD NOT be used. - - The following are notes on RFC-822, organized by section of that - document. - - 5.2.13 RFC-822 Message Specification: RFC-822 Section 4 - - The syntax shown for the Return-path line omits the possibility - of a null return path, which is used to prevent looping of - error notifications (see Section 5.3.3). The complete syntax - is: - - return = "Return-path" ":" route-addr - / "Return-path" ":" "<" ">" - - The set of optional header fields is hereby expanded to include - the Content-Type field defined in RFC-1049 [SMTP:7]. This - field "allows mail reading systems to automatically identify - the type of a structured message body and to process it for - display accordingly". [SMTP:7] A User Agent MAY support this - field. - - 5.2.14 RFC-822 Date and Time Specification: RFC-822 Section 5 - - The syntax for the date is hereby changed to: - - date = 1*2DIGIT month 2*4DIGIT - - - - -Internet Engineering Task Force [Page 55] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - All mail software SHOULD use 4-digit years in dates, to ease - the transition to the next century. - - There is a strong trend towards the use of numeric timezone - indicators, and implementations SHOULD use numeric timezones - instead of timezone names. However, all implementations MUST - accept either notation. If timezone names are used, they MUST - be exactly as defined in RFC-822. - - The military time zones are specified incorrectly in RFC-822: - they count the wrong way from UT (the signs are reversed). As - a result, military time zones in RFC-822 headers carry no - information. - - Finally, note that there is a typo in the definition of "zone" - in the syntax summary of appendix D; the correct definition - occurs in Section 3 of RFC-822. - - 5.2.15 RFC-822 Syntax Change: RFC-822 Section 6.1 - - The syntactic definition of "mailbox" in RFC-822 is hereby - changed to: - - mailbox = addr-spec ; simple address - / [phrase] route-addr ; name & addr-spec - - That is, the phrase preceding a route address is now OPTIONAL. - This change makes the following header field legal, for - example: - - From: <craig@nnsc.nsf.net> - - 5.2.16 RFC-822 Local-part: RFC-822 Section 6.2 - - The basic mailbox address specification has the form: "local- - part@domain". Here "local-part", sometimes called the "left- - hand side" of the address, is domain-dependent. - - A host that is forwarding the message but is not the - destination host implied by the right-hand side "domain" MUST - NOT interpret or modify the "local-part" of the address. - - When mail is to be gatewayed from the Internet mail environment - into a foreign mail environment (see Section 5.3.7), routing - information for that foreign environment MAY be embedded within - the "local-part" of the address. The gateway will then - interpret this local part appropriately for the foreign mail - environment. - - - -Internet Engineering Task Force [Page 56] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - DISCUSSION: - Although source routes are discouraged within the Internet - (see Section 5.2.6), there are non-Internet mail - environments whose delivery mechanisms do depend upon - source routes. Source routes for extra-Internet - environments can generally be buried in the "local-part" - of the address (see Section 5.2.16) while mail traverses - the Internet. When the mail reaches the appropriate - Internet mail gateway, the gateway will interpret the - local-part and build the necessary address or route for - the target mail environment. - - For example, an Internet host might send mail to: - "a!b!c!user@gateway-domain". The complex local part - "a!b!c!user" would be uninterpreted within the Internet - domain, but could be parsed and understood by the - specified mail gateway. - - An embedded source route is sometimes encoded in the - "local-part" using "%" as a right-binding routing - operator. For example, in: - - user%domain%relay3%relay2@relay1 - - the "%" convention implies that the mail is to be routed - from "relay1" through "relay2", "relay3", and finally to - "user" at "domain". This is commonly known as the "%- - hack". It is suggested that "%" have lower precedence - than any other routing operator (e.g., "!") hidden in the - local-part; for example, "a!b%c" would be interpreted as - "(a!b)%c". - - Only the target host (in this case, "relay1") is permitted - to analyze the local-part "user%domain%relay3%relay2". - - 5.2.17 Domain Literals: RFC-822 Section 6.2.3 - - A mailer MUST be able to accept and parse an Internet domain - literal whose content ("dtext"; see RFC-822) is a dotted- - decimal host address. This satisfies the requirement of - Section 2.1 for the case of mail. - - An SMTP MUST accept and recognize a domain literal for any of - its own IP addresses. - - - - - - - -Internet Engineering Task Force [Page 57] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - 5.2.18 Common Address Formatting Errors: RFC-822 Section 6.1 - - Errors in formatting or parsing 822 addresses are unfortunately - common. This section mentions only the most common errors. A - User Agent MUST accept all valid RFC-822 address formats, and - MUST NOT generate illegal address syntax. - - o A common error is to leave out the semicolon after a group - identifier. - - o Some systems fail to fully-qualify domain names in - messages they generate. The right-hand side of an "@" - sign in a header address field MUST be a fully-qualified - domain name. - - For example, some systems fail to fully-qualify the From: - address; this prevents a "reply" command in the user - interface from automatically constructing a return - address. - - DISCUSSION: - Although RFC-822 allows the local use of abbreviated - domain names within a domain, the application of - RFC-822 in Internet mail does not allow this. The - intent is that an Internet host must not send an SMTP - message header containing an abbreviated domain name - in an address field. This allows the address fields - of the header to be passed without alteration across - the Internet, as required in Section 5.2.6. - - o Some systems mis-parse multiple-hop explicit source routes - such as: - - @relay1,@relay2,@relay3:user@domain. - - - o Some systems over-qualify domain names by adding a - trailing dot to some or all domain names in addresses or - message-ids. This violates RFC-822 syntax. - - - 5.2.19 Explicit Source Routes: RFC-822 Section 6.2.7 - - Internet host software SHOULD NOT create an RFC-822 header - containing an address with an explicit source route, but MUST - accept such headers for compatibility with earlier systems. - - DISCUSSION: - - - -Internet Engineering Task Force [Page 58] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - In an understatement, RFC-822 says "The use of explicit - source routing is discouraged". Many hosts implemented - RFC-822 source routes incorrectly, so the syntax cannot be - used unambiguously in practice. Many users feel the - syntax is ugly. Explicit source routes are not needed in - the mail envelope for delivery; see Section 5.2.6. For - all these reasons, explicit source routes using the RFC- - 822 notations are not to be used in Internet mail headers. - - As stated in Section 5.2.16, it is necessary to allow an - explicit source route to be buried in the local-part of an - address, e.g., using the "%-hack", in order to allow mail - to be gatewayed into another environment in which explicit - source routing is necessary. The vigilant will observe - that there is no way for a User Agent to detect and - prevent the use of such implicit source routing when the - destination is within the Internet. We can only - discourage source routing of any kind within the Internet, - as unnecessary and undesirable. - - 5.3 SPECIFIC ISSUES - - 5.3.1 SMTP Queueing Strategies - - The common structure of a host SMTP implementation includes - user mailboxes, one or more areas for queueing messages in - transit, and one or more daemon processes for sending and - receiving mail. The exact structure will vary depending on the - needs of the users on the host and the number and size of - mailing lists supported by the host. We describe several - optimizations that have proved helpful, particularly for - mailers supporting high traffic levels. - - Any queueing strategy MUST include: - - o Timeouts on all activities. See Section 5.3.2. - - o Never sending error messages in response to error - messages. - - - 5.3.1.1 Sending Strategy - - The general model of a sender-SMTP is one or more processes - that periodically attempt to transmit outgoing mail. In a - typical system, the program that composes a message has some - method for requesting immediate attention for a new piece of - outgoing mail, while mail that cannot be transmitted - - - -Internet Engineering Task Force [Page 59] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - immediately MUST be queued and periodically retried by the - sender. A mail queue entry will include not only the - message itself but also the envelope information. - - The sender MUST delay retrying a particular destination - after one attempt has failed. In general, the retry - interval SHOULD be at least 30 minutes; however, more - sophisticated and variable strategies will be beneficial - when the sender-SMTP can determine the reason for non- - delivery. - - Retries continue until the message is transmitted or the - sender gives up; the give-up time generally needs to be at - least 4-5 days. The parameters to the retry algorithm MUST - be configurable. - - A sender SHOULD keep a list of hosts it cannot reach and - corresponding timeouts, rather than just retrying queued - mail items. - - DISCUSSION: - Experience suggests that failures are typically - transient (the target system has crashed), favoring a - policy of two connection attempts in the first hour the - message is in the queue, and then backing off to once - every two or three hours. - - The sender-SMTP can shorten the queueing delay by - cooperation with the receiver-SMTP. In particular, if - mail is received from a particular address, it is good - evidence that any mail queued for that host can now be - sent. - - The strategy may be further modified as a result of - multiple addresses per host (see Section 5.3.4), to - optimize delivery time vs. resource usage. - - A sender-SMTP may have a large queue of messages for - each unavailable destination host, and if it retried - all these messages in every retry cycle, there would be - excessive Internet overhead and the daemon would be - blocked for a long period. Note that an SMTP can - generally determine that a delivery attempt has failed - only after a timeout of a minute or more; a one minute - timeout per connection will result in a very large - delay if it is repeated for dozens or even hundreds of - queued messages. - - - - -Internet Engineering Task Force [Page 60] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - When the same message is to be delivered to several users on - the same host, only one copy of the message SHOULD be - transmitted. That is, the sender-SMTP should use the - command sequence: RCPT, RCPT,... RCPT, DATA instead of the - sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA. - Implementation of this efficiency feature is strongly urged. - - Similarly, the sender-SMTP MAY support multiple concurrent - outgoing mail transactions to achieve timely delivery. - However, some limit SHOULD be imposed to protect the host - from devoting all its resources to mail. - - The use of the different addresses of a multihomed host is - discussed below. - - 5.3.1.2 Receiving strategy - - The receiver-SMTP SHOULD attempt to keep a pending listen on - the SMTP port at all times. This will require the support - of multiple incoming TCP connections for SMTP. Some limit - MAY be imposed. - - IMPLEMENTATION: - When the receiver-SMTP receives mail from a particular - host address, it could notify the sender-SMTP to retry - any mail pending for that host address. - - 5.3.2 Timeouts in SMTP - - There are two approaches to timeouts in the sender-SMTP: (a) - limit the time for each SMTP command separately, or (b) limit - the time for the entire SMTP dialogue for a single mail - message. A sender-SMTP SHOULD use option (a), per-command - timeouts. Timeouts SHOULD be easily reconfigurable, preferably - without recompiling the SMTP code. - - DISCUSSION: - Timeouts are an essential feature of an SMTP - implementation. If the timeouts are too long (or worse, - there are no timeouts), Internet communication failures or - software bugs in receiver-SMTP programs can tie up SMTP - processes indefinitely. If the timeouts are too short, - resources will be wasted with attempts that time out part - way through message delivery. - - If option (b) is used, the timeout has to be very large, - e.g., an hour, to allow time to expand very large mailing - lists. The timeout may also need to increase linearly - - - -Internet Engineering Task Force [Page 61] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - with the size of the message, to account for the time to - transmit a very large message. A large fixed timeout - leads to two problems: a failure can still tie up the - sender for a very long time, and very large messages may - still spuriously time out (which is a wasteful failure!). - - Using the recommended option (a), a timer is set for each - SMTP command and for each buffer of the data transfer. - The latter means that the overall timeout is inherently - proportional to the size of the message. - - Based on extensive experience with busy mail-relay hosts, the - minimum per-command timeout values SHOULD be as follows: - - o Initial 220 Message: 5 minutes - - A Sender-SMTP process needs to distinguish between a - failed TCP connection and a delay in receiving the initial - 220 greeting message. Many receiver-SMTPs will accept a - TCP connection but delay delivery of the 220 message until - their system load will permit more mail to be processed. - - o MAIL Command: 5 minutes - - - o RCPT Command: 5 minutes - - A longer timeout would be required if processing of - mailing lists and aliases were not deferred until after - the message was accepted. - - o DATA Initiation: 2 minutes - - This is while awaiting the "354 Start Input" reply to a - DATA command. - - o Data Block: 3 minutes - - This is while awaiting the completion of each TCP SEND - call transmitting a chunk of data. - - o DATA Termination: 10 minutes. - - This is while awaiting the "250 OK" reply. When the - receiver gets the final period terminating the message - data, it typically performs processing to deliver the - message to a user mailbox. A spurious timeout at this - point would be very wasteful, since the message has been - - - -Internet Engineering Task Force [Page 62] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - successfully sent. - - A receiver-SMTP SHOULD have a timeout of at least 5 minutes - while it is awaiting the next command from the sender. - - 5.3.3 Reliable Mail Receipt - - When the receiver-SMTP accepts a piece of mail (by sending a - "250 OK" message in response to DATA), it is accepting - responsibility for delivering or relaying the message. It must - take this responsibility seriously, i.e., it MUST NOT lose the - message for frivolous reasons, e.g., because the host later - crashes or because of a predictable resource shortage. - - If there is a delivery failure after acceptance of a message, - the receiver-SMTP MUST formulate and mail a notification - message. This notification MUST be sent using a null ("<>") - reverse path in the envelope; see Section 3.6 of RFC-821. The - recipient of this notification SHOULD be the address from the - envelope return path (or the Return-Path: line). However, if - this address is null ("<>"), the receiver-SMTP MUST NOT send a - notification. If the address is an explicit source route, it - SHOULD be stripped down to its final hop. - - DISCUSSION: - For example, suppose that an error notification must be - sent for a message that arrived with: - "MAIL FROM:<@a,@b:user@d>". The notification message - should be sent to: "RCPT TO:<user@d>". - - Some delivery failures after the message is accepted by - SMTP will be unavoidable. For example, it may be - impossible for the receiver-SMTP to validate all the - delivery addresses in RCPT command(s) due to a "soft" - domain system error or because the target is a mailing - list (see earlier discussion of RCPT). - - To avoid receiving duplicate messages as the result of - timeouts, a receiver-SMTP MUST seek to minimize the time - required to respond to the final "." that ends a message - transfer. See RFC-1047 [SMTP:4] for a discussion of this - problem. - - 5.3.4 Reliable Mail Transmission - - To transmit a message, a sender-SMTP determines the IP address - of the target host from the destination address in the - envelope. Specifically, it maps the string to the right of the - - - -Internet Engineering Task Force [Page 63] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - "@" sign into an IP address. This mapping or the transfer - itself may fail with a soft error, in which case the sender- - SMTP will requeue the outgoing mail for a later retry, as - required in Section 5.3.1.1. - - When it succeeds, the mapping can result in a list of - alternative delivery addresses rather than a single address, - because of (a) multiple MX records, (b) multihoming, or both. - To provide reliable mail transmission, the sender-SMTP MUST be - able to try (and retry) each of the addresses in this list in - order, until a delivery attempt succeeds. However, there MAY - also be a configurable limit on the number of alternate - addresses that can be tried. In any case, a host SHOULD try at - least two addresses. - - The following information is to be used to rank the host - addresses: - - (1) Multiple MX Records -- these contain a preference - indication that should be used in sorting. If there are - multiple destinations with the same preference and there - is no clear reason to favor one (e.g., by address - preference), then the sender-SMTP SHOULD pick one at - random to spread the load across multiple mail exchanges - for a specific organization; note that this is a - refinement of the procedure in [DNS:3]. - - (2) Multihomed host -- The destination host (perhaps taken - from the preferred MX record) may be multihomed, in which - case the domain name resolver will return a list of - alternative IP addresses. It is the responsibility of the - domain name resolver interface (see Section 6.1.3.4 below) - to have ordered this list by decreasing preference, and - SMTP MUST try them in the order presented. - - DISCUSSION: - Although the capability to try multiple alternative - addresses is required, there may be circumstances where - specific installations want to limit or disable the use of - alternative addresses. The question of whether a sender - should attempt retries using the different addresses of a - multihomed host has been controversial. The main argument - for using the multiple addresses is that it maximizes the - probability of timely delivery, and indeed sometimes the - probability of any delivery; the counter argument is that - it may result in unnecessary resource use. - - Note that resource use is also strongly determined by the - - - -Internet Engineering Task Force [Page 64] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - sending strategy discussed in Section 5.3.1. - - 5.3.5 Domain Name Support - - SMTP implementations MUST use the mechanism defined in Section - 6.1 for mapping between domain names and IP addresses. This - means that every Internet SMTP MUST include support for the - Internet DNS. - - In particular, a sender-SMTP MUST support the MX record scheme - [SMTP:3]. See also Section 7.4 of [DNS:2] for information on - domain name support for SMTP. - - 5.3.6 Mailing Lists and Aliases - - An SMTP-capable host SHOULD support both the alias and the list - form of address expansion for multiple delivery. When a - message is delivered or forwarded to each address of an - expanded list form, the return address in the envelope - ("MAIL FROM:") MUST be changed to be the address of a person - who administers the list, but the message header MUST be left - unchanged; in particular, the "From" field of the message is - unaffected. - - DISCUSSION: - An important mail facility is a mechanism for multi- - destination delivery of a single message, by transforming - or "expanding" a pseudo-mailbox address into a list of - destination mailbox addresses. When a message is sent to - such a pseudo-mailbox (sometimes called an "exploder"), - copies are forwarded or redistributed to each mailbox in - the expanded list. We classify such a pseudo-mailbox as - an "alias" or a "list", depending upon the expansion - rules: - - (a) Alias - - To expand an alias, the recipient mailer simply - replaces the pseudo-mailbox address in the envelope - with each of the expanded addresses in turn; the rest - of the envelope and the message body are left - unchanged. The message is then delivered or - forwarded to each expanded address. - - (b) List - - A mailing list may be said to operate by - "redistribution" rather than by "forwarding". To - - - -Internet Engineering Task Force [Page 65] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - expand a list, the recipient mailer replaces the - pseudo-mailbox address in the envelope with each of - the expanded addresses in turn. The return address in - the envelope is changed so that all error messages - generated by the final deliveries will be returned to - a list administrator, not to the message originator, - who generally has no control over the contents of the - list and will typically find error messages annoying. - - - 5.3.7 Mail Gatewaying - - Gatewaying mail between different mail environments, i.e., - different mail formats and protocols, is complex and does not - easily yield to standardization. See for example [SMTP:5a], - [SMTP:5b]. However, some general requirements may be given for - a gateway between the Internet and another mail environment. - - (A) Header fields MAY be rewritten when necessary as messages - are gatewayed across mail environment boundaries. - - DISCUSSION: - This may involve interpreting the local-part of the - destination address, as suggested in Section 5.2.16. - - The other mail systems gatewayed to the Internet - generally use a subset of RFC-822 headers, but some - of them do not have an equivalent to the SMTP - envelope. Therefore, when a message leaves the - Internet environment, it may be necessary to fold the - SMTP envelope information into the message header. A - possible solution would be to create new header - fields to carry the envelope information (e.g., "X- - SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would - require changes in mail programs in the foreign - environment. - - (B) When forwarding a message into or out of the Internet - environment, a gateway MUST prepend a Received: line, but - it MUST NOT alter in any way a Received: line that is - already in the header. - - DISCUSSION: - This requirement is a subset of the general - "Received:" line requirement of Section 5.2.8; it is - restated here for emphasis. - - Received: fields of messages originating from other - - - -Internet Engineering Task Force [Page 66] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - environments may not conform exactly to RFC822. - However, the most important use of Received: lines is - for debugging mail faults, and this debugging can be - severely hampered by well-meaning gateways that try - to "fix" a Received: line. - - The gateway is strongly encouraged to indicate the - environment and protocol in the "via" clauses of - Received field(s) that it supplies. - - (C) From the Internet side, the gateway SHOULD accept all - valid address formats in SMTP commands and in RFC-822 - headers, and all valid RFC-822 messages. Although a - gateway must accept an RFC-822 explicit source route - ("@...:" format) in either the RFC-822 header or in the - envelope, it MAY or may not act on the source route; see - Sections 5.2.6 and 5.2.19. - - DISCUSSION: - It is often tempting to restrict the range of - addresses accepted at the mail gateway to simplify - the translation into addresses for the remote - environment. This practice is based on the - assumption that mail users have control over the - addresses their mailers send to the mail gateway. In - practice, however, users have little control over the - addresses that are finally sent; their mailers are - free to change addresses into any legal RFC-822 - format. - - (D) The gateway MUST ensure that all header fields of a - message that it forwards into the Internet meet the - requirements for Internet mail. In particular, all - addresses in "From:", "To:", "Cc:", etc., fields must be - transformed (if necessary) to satisfy RFC-822 syntax, and - they must be effective and useful for sending replies. - - - (E) The translation algorithm used to convert mail from the - Internet protocols to another environment's protocol - SHOULD try to ensure that error messages from the foreign - mail environment are delivered to the return path from the - SMTP envelope, not to the sender listed in the "From:" - field of the RFC-822 message. - - DISCUSSION: - Internet mail lists usually place the address of the - mail list maintainer in the envelope but leave the - - - -Internet Engineering Task Force [Page 67] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - original message header intact (with the "From:" - field containing the original sender). This yields - the behavior the average recipient expects: a reply - to the header gets sent to the original sender, not - to a mail list maintainer; however, errors get sent - to the maintainer (who can fix the problem) and not - the sender (who probably cannot). - - (F) Similarly, when forwarding a message from another - environment into the Internet, the gateway SHOULD set the - envelope return path in accordance with an error message - return address, if any, supplied by the foreign - environment. - - - 5.3.8 Maximum Message Size - - Mailer software MUST be able to send and receive messages of at - least 64K bytes in length (including header), and a much larger - maximum size is highly desirable. - - DISCUSSION: - Although SMTP does not define the maximum size of a - message, many systems impose implementation limits. - - The current de facto minimum limit in the Internet is 64K - bytes. However, electronic mail is used for a variety of - purposes that create much larger messages. For example, - mail is often used instead of FTP for transmitting ASCII - files, and in particular to transmit entire documents. As - a result, messages can be 1 megabyte or even larger. We - note that the present document together with its lower- - layer companion contains 0.5 megabytes. - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 68] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - 5.4 SMTP REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e ------------------------------------------------|----------|-|-|-|-|-|-- - | | | | | | | -RECEIVER-SMTP: | | | | | | | - Implement VRFY |5.2.3 |x| | | | | - Implement EXPN |5.2.3 | |x| | | | - EXPN, VRFY configurable |5.2.3 | | |x| | | - Implement SEND, SOML, SAML |5.2.4 | | |x| | | - Verify HELO parameter |5.2.5 | | |x| | | - Refuse message with bad HELO |5.2.5 | | | | |x| - Accept explicit src-route syntax in env. |5.2.6 |x| | | | | - Support "postmaster" |5.2.7 |x| | | | | - Process RCPT when received (except lists) |5.2.7 | | |x| | | - Long delay of RCPT responses |5.2.7 | | | | |x| - | | | | | | | - Add Received: line |5.2.8 |x| | | | | - Received: line include domain literal |5.2.8 | |x| | | | - Change previous Received: line |5.2.8 | | | | |x| - Pass Return-Path info (final deliv/gwy) |5.2.8 |x| | | | | - Support empty reverse path |5.2.9 |x| | | | | - Send only official reply codes |5.2.10 | |x| | | | - Send text from RFC-821 when appropriate |5.2.10 | |x| | | | - Delete "." for transparency |5.2.11 |x| | | | | - Accept and recognize self domain literal(s) |5.2.17 |x| | | | | - | | | | | | | - Error message about error message |5.3.1 | | | | |x| - Keep pending listen on SMTP port |5.3.1.2 | |x| | | | - Provide limit on recv concurrency |5.3.1.2 | | |x| | | - Wait at least 5 mins for next sender cmd |5.3.2 | |x| | | | - Avoidable delivery failure after "250 OK" |5.3.3 | | | | |x| - Send error notification msg after accept |5.3.3 |x| | | | | - Send using null return path |5.3.3 |x| | | | | - Send to envelope return path |5.3.3 | |x| | | | - Send to null address |5.3.3 | | | | |x| - Strip off explicit src route |5.3.3 | |x| | | | - Minimize acceptance delay (RFC-1047) |5.3.3 |x| | | | | ------------------------------------------------|----------|-|-|-|-|-|-- - - - -Internet Engineering Task Force [Page 69] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - | | | | | | | -SENDER-SMTP: | | | | | | | - Canonicalized domain names in MAIL, RCPT |5.2.2 |x| | | | | - Implement SEND, SOML, SAML |5.2.4 | | |x| | | - Send valid principal host name in HELO |5.2.5 |x| | | | | - Send explicit source route in RCPT TO: |5.2.6 | | | |x| | - Use only reply code to determine action |5.2.10 |x| | | | | - Use only high digit of reply code when poss. |5.2.10 | |x| | | | - Add "." for transparency |5.2.11 |x| | | | | - | | | | | | | - Retry messages after soft failure |5.3.1.1 |x| | | | | - Delay before retry |5.3.1.1 |x| | | | | - Configurable retry parameters |5.3.1.1 |x| | | | | - Retry once per each queued dest host |5.3.1.1 | |x| | | | - Multiple RCPT's for same DATA |5.3.1.1 | |x| | | | - Support multiple concurrent transactions |5.3.1.1 | | |x| | | - Provide limit on concurrency |5.3.1.1 | |x| | | | - | | | | | | | - Timeouts on all activities |5.3.1 |x| | | | | - Per-command timeouts |5.3.2 | |x| | | | - Timeouts easily reconfigurable |5.3.2 | |x| | | | - Recommended times |5.3.2 | |x| | | | - Try alternate addr's in order |5.3.4 |x| | | | | - Configurable limit on alternate tries |5.3.4 | | |x| | | - Try at least two alternates |5.3.4 | |x| | | | - Load-split across equal MX alternates |5.3.4 | |x| | | | - Use the Domain Name System |5.3.5 |x| | | | | - Support MX records |5.3.5 |x| | | | | - Use WKS records in MX processing |5.2.12 | | | |x| | ------------------------------------------------|----------|-|-|-|-|-|-- - | | | | | | | -MAIL FORWARDING: | | | | | | | - Alter existing header field(s) |5.2.6 | | | |x| | - Implement relay function: 821/section 3.6 |5.2.6 | | |x| | | - If not, deliver to RHS domain |5.2.6 | |x| | | | - Interpret 'local-part' of addr |5.2.16 | | | | |x| - | | | | | | | -MAILING LISTS AND ALIASES | | | | | | | - Support both |5.3.6 | |x| | | | - Report mail list error to local admin. |5.3.6 |x| | | | | - | | | | | | | -MAIL GATEWAYS: | | | | | | | - Embed foreign mail route in local-part |5.2.16 | | |x| | | - Rewrite header fields when necessary |5.3.7 | | |x| | | - Prepend Received: line |5.3.7 |x| | | | | - Change existing Received: line |5.3.7 | | | | |x| - Accept full RFC-822 on Internet side |5.3.7 | |x| | | | - Act on RFC-822 explicit source route |5.3.7 | | |x| | | - - - -Internet Engineering Task Force [Page 70] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - Send only valid RFC-822 on Internet side |5.3.7 |x| | | | | - Deliver error msgs to envelope addr |5.3.7 | |x| | | | - Set env return path from err return addr |5.3.7 | |x| | | | - | | | | | | | -USER AGENT -- RFC-822 | | | | | | | - Allow user to enter <route> address |5.2.6 | | | |x| | - Support RFC-1049 Content Type field |5.2.13 | | |x| | | - Use 4-digit years |5.2.14 | |x| | | | - Generate numeric timezones |5.2.14 | |x| | | | - Accept all timezones |5.2.14 |x| | | | | - Use non-num timezones from RFC-822 |5.2.14 |x| | | | | - Omit phrase before route-addr |5.2.15 | | |x| | | - Accept and parse dot.dec. domain literals |5.2.17 |x| | | | | - Accept all RFC-822 address formats |5.2.18 |x| | | | | - Generate invalid RFC-822 address format |5.2.18 | | | | |x| - Fully-qualified domain names in header |5.2.18 |x| | | | | - Create explicit src route in header |5.2.19 | | | |x| | - Accept explicit src route in header |5.2.19 |x| | | | | - | | | | | | | -Send/recv at least 64KB messages |5.3.8 |x| | | | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 71] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - -6. SUPPORT SERVICES - - 6.1 DOMAIN NAME TRANSLATION - - 6.1.1 INTRODUCTION - - Every host MUST implement a resolver for the Domain Name System - (DNS), and it MUST implement a mechanism using this DNS - resolver to convert host names to IP addresses and vice-versa - [DNS:1, DNS:2]. - - In addition to the DNS, a host MAY also implement a host name - translation mechanism that searches a local Internet host - table. See Section 6.1.3.8 for more information on this - option. - - DISCUSSION: - Internet host name translation was originally performed by - searching local copies of a table of all hosts. This - table became too large to update and distribute in a - timely manner and too large to fit into many hosts, so the - DNS was invented. - - The DNS creates a distributed database used primarily for - the translation between host names and host addresses. - Implementation of DNS software is required. The DNS - consists of two logically distinct parts: name servers and - resolvers (although implementations often combine these - two logical parts in the interest of efficiency) [DNS:2]. - - Domain name servers store authoritative data about certain - sections of the database and answer queries about the - data. Domain resolvers query domain name servers for data - on behalf of user processes. Every host therefore needs a - DNS resolver; some host machines will also need to run - domain name servers. Since no name server has complete - information, in general it is necessary to obtain - information from more than one name server to resolve a - query. - - 6.1.2 PROTOCOL WALK-THROUGH - - An implementor must study references [DNS:1] and [DNS:2] - carefully. They provide a thorough description of the theory, - protocol, and implementation of the domain name system, and - reflect several years of experience. - - - - - -Internet Engineering Task Force [Page 72] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - 6.1.2.1 Resource Records with Zero TTL: RFC-1035 Section 3.2.1 - - All DNS name servers and resolvers MUST properly handle RRs - with a zero TTL: return the RR to the client but do not - cache it. - - DISCUSSION: - Zero TTL values are interpreted to mean that the RR can - only be used for the transaction in progress, and - should not be cached; they are useful for extremely - volatile data. - - 6.1.2.2 QCLASS Values: RFC-1035 Section 3.2.5 - - A query with "QCLASS=*" SHOULD NOT be used unless the - requestor is seeking data from more than one class. In - particular, if the requestor is only interested in Internet - data types, QCLASS=IN MUST be used. - - 6.1.2.3 Unused Fields: RFC-1035 Section 4.1.1 - - Unused fields in a query or response message MUST be zero. - - 6.1.2.4 Compression: RFC-1035 Section 4.1.4 - - Name servers MUST use compression in responses. - - DISCUSSION: - Compression is essential to avoid overflowing UDP - datagrams; see Section 6.1.3.2. - - 6.1.2.5 Misusing Configuration Info: RFC-1035 Section 6.1.2 - - Recursive name servers and full-service resolvers generally - have some configuration information containing hints about - the location of root or local name servers. An - implementation MUST NOT include any of these hints in a - response. - - DISCUSSION: - Many implementors have found it convenient to store - these hints as if they were cached data, but some - neglected to ensure that this "cached data" was not - included in responses. This has caused serious - problems in the Internet when the hints were obsolete - or incorrect. - - - - - -Internet Engineering Task Force [Page 73] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - 6.1.3 SPECIFIC ISSUES - - 6.1.3.1 Resolver Implementation - - A name resolver SHOULD be able to multiplex concurrent - requests if the host supports concurrent processes. - - In implementing a DNS resolver, one of two different models - MAY optionally be chosen: a full-service resolver, or a stub - resolver. - - - (A) Full-Service Resolver - - A full-service resolver is a complete implementation of - the resolver service, and is capable of dealing with - communication failures, failure of individual name - servers, location of the proper name server for a given - name, etc. It must satisfy the following requirements: - - o The resolver MUST implement a local caching - function to avoid repeated remote access for - identical requests, and MUST time out information - in the cache. - - o The resolver SHOULD be configurable with start-up - information pointing to multiple root name servers - and multiple name servers for the local domain. - This insures that the resolver will be able to - access the whole name space in normal cases, and - will be able to access local domain information - should the local network become disconnected from - the rest of the Internet. - - - (B) Stub Resolver - - A "stub resolver" relies on the services of a recursive - name server on the connected network or a "nearby" - network. This scheme allows the host to pass on the - burden of the resolver function to a name server on - another host. This model is often essential for less - capable hosts, such as PCs, and is also recommended - when the host is one of several workstations on a local - network, because it allows all of the workstations to - share the cache of the recursive name server and hence - reduce the number of domain requests exported by the - local network. - - - -Internet Engineering Task Force [Page 74] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - At a minimum, the stub resolver MUST be capable of - directing its requests to redundant recursive name - servers. Note that recursive name servers are allowed - to restrict the sources of requests that they will - honor, so the host administrator must verify that the - service will be provided. Stub resolvers MAY implement - caching if they choose, but if so, MUST timeout cached - information. - - - 6.1.3.2 Transport Protocols - - DNS resolvers and recursive servers MUST support UDP, and - SHOULD support TCP, for sending (non-zone-transfer) queries. - Specifically, a DNS resolver or server that is sending a - non-zone-transfer query MUST send a UDP query first. If the - Answer section of the response is truncated and if the - requester supports TCP, it SHOULD try the query again using - TCP. - - DNS servers MUST be able to service UDP queries and SHOULD - be able to service TCP queries. A name server MAY limit the - resources it devotes to TCP queries, but it SHOULD NOT - refuse to service a TCP query just because it would have - succeeded with UDP. - - Truncated responses MUST NOT be saved (cached) and later - used in such a way that the fact that they are truncated is - lost. - - DISCUSSION: - UDP is preferred over TCP for queries because UDP - queries have much lower overhead, both in packet count - and in connection state. The use of UDP is essential - for heavily-loaded servers, especially the root - servers. UDP also offers additional robustness, since - a resolver can attempt several UDP queries to different - servers for the cost of a single TCP query. - - It is possible for a DNS response to be truncated, - although this is a very rare occurrence in the present - Internet DNS. Practically speaking, truncation cannot - be predicted, since it is data-dependent. The - dependencies include the number of RRs in the answer, - the size of each RR, and the savings in space realized - by the name compression algorithm. As a rule of thumb, - truncation in NS and MX lists should not occur for - answers containing 15 or fewer RRs. - - - -Internet Engineering Task Force [Page 75] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - Whether it is possible to use a truncated answer - depends on the application. A mailer must not use a - truncated MX response, since this could lead to mail - loops. - - Responsible practices can make UDP suffice in the vast - majority of cases. Name servers must use compression - in responses. Resolvers must differentiate truncation - of the Additional section of a response (which only - loses extra information) from truncation of the Answer - section (which for MX records renders the response - unusable by mailers). Database administrators should - list only a reasonable number of primary names in lists - of name servers, MX alternatives, etc. - - However, it is also clear that some new DNS record - types defined in the future will contain information - exceeding the 512 byte limit that applies to UDP, and - hence will require TCP. Thus, resolvers and name - servers should implement TCP services as a backup to - UDP today, with the knowledge that they will require - the TCP service in the future. - - By private agreement, name servers and resolvers MAY arrange - to use TCP for all traffic between themselves. TCP MUST be - used for zone transfers. - - A DNS server MUST have sufficient internal concurrency that - it can continue to process UDP queries while awaiting a - response or performing a zone transfer on an open TCP - connection [DNS:2]. - - A server MAY support a UDP query that is delivered using an - IP broadcast or multicast address. However, the Recursion - Desired bit MUST NOT be set in a query that is multicast, - and MUST be ignored by name servers receiving queries via a - broadcast or multicast address. A host that sends broadcast - or multicast DNS queries SHOULD send them only as occasional - probes, caching the IP address(es) it obtains from the - response(s) so it can normally send unicast queries. - - DISCUSSION: - Broadcast or (especially) IP multicast can provide a - way to locate nearby name servers without knowing their - IP addresses in advance. However, general broadcasting - of recursive queries can result in excessive and - unnecessary load on both network and servers. - - - - -Internet Engineering Task Force [Page 76] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - 6.1.3.3 Efficient Resource Usage - - The following requirements on servers and resolvers are very - important to the health of the Internet as a whole, - particularly when DNS services are invoked repeatedly by - higher level automatic servers, such as mailers. - - (1) The resolver MUST implement retransmission controls to - insure that it does not waste communication bandwidth, - and MUST impose finite bounds on the resources consumed - to respond to a single request. See [DNS:2] pages 43- - 44 for specific recommendations. - - (2) After a query has been retransmitted several times - without a response, an implementation MUST give up and - return a soft error to the application. - - (3) All DNS name servers and resolvers SHOULD cache - temporary failures, with a timeout period of the order - of minutes. - - DISCUSSION: - This will prevent applications that immediately - retry soft failures (in violation of Section 2.2 - of this document) from generating excessive DNS - traffic. - - (4) All DNS name servers and resolvers SHOULD cache - negative responses that indicate the specified name, or - data of the specified type, does not exist, as - described in [DNS:2]. - - (5) When a DNS server or resolver retries a UDP query, the - retry interval SHOULD be constrained by an exponential - backoff algorithm, and SHOULD also have upper and lower - bounds. - - IMPLEMENTATION: - A measured RTT and variance (if available) should - be used to calculate an initial retransmission - interval. If this information is not available, a - default of no less than 5 seconds should be used. - Implementations may limit the retransmission - interval, but this limit must exceed twice the - Internet maximum segment lifetime plus service - delay at the name server. - - (6) When a resolver or server receives a Source Quench for - - - -Internet Engineering Task Force [Page 77] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - a query it has issued, it SHOULD take steps to reduce - the rate of querying that server in the near future. A - server MAY ignore a Source Quench that it receives as - the result of sending a response datagram. - - IMPLEMENTATION: - One recommended action to reduce the rate is to - send the next query attempt to an alternate - server, if there is one available. Another is to - backoff the retry interval for the same server. - - - 6.1.3.4 Multihomed Hosts - - When the host name-to-address function encounters a host - with multiple addresses, it SHOULD rank or sort the - addresses using knowledge of the immediately connected - network number(s) and any other applicable performance or - history information. - - DISCUSSION: - The different addresses of a multihomed host generally - imply different Internet paths, and some paths may be - preferable to others in performance, reliability, or - administrative restrictions. There is no general way - for the domain system to determine the best path. A - recommended approach is to base this decision on local - configuration information set by the system - administrator. - - IMPLEMENTATION: - The following scheme has been used successfully: - - (a) Incorporate into the host configuration data a - Network-Preference List, that is simply a list of - networks in preferred order. This list may be - empty if there is no preference. - - (b) When a host name is mapped into a list of IP - addresses, these addresses should be sorted by - network number, into the same order as the - corresponding networks in the Network-Preference - List. IP addresses whose networks do not appear - in the Network-Preference List should be placed at - the end of the list. - - - - - - -Internet Engineering Task Force [Page 78] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - 6.1.3.5 Extensibility - - DNS software MUST support all well-known, class-independent - formats [DNS:2], and SHOULD be written to minimize the - trauma associated with the introduction of new well-known - types and local experimentation with non-standard types. - - DISCUSSION: - The data types and classes used by the DNS are - extensible, and thus new types will be added and old - types deleted or redefined. Introduction of new data - types ought to be dependent only upon the rules for - compression of domain names inside DNS messages, and - the translation between printable (i.e., master file) - and internal formats for Resource Records (RRs). - - Compression relies on knowledge of the format of data - inside a particular RR. Hence compression must only be - used for the contents of well-known, class-independent - RRs, and must never be used for class-specific RRs or - RR types that are not well-known. The owner name of an - RR is always eligible for compression. - - A name server may acquire, via zone transfer, RRs that - the server doesn't know how to convert to printable - format. A resolver can receive similar information as - the result of queries. For proper operation, this data - must be preserved, and hence the implication is that - DNS software cannot use textual formats for internal - storage. - - The DNS defines domain name syntax very generally -- a - string of labels each containing up to 63 8-bit octets, - separated by dots, and with a maximum total of 255 - octets. Particular applications of the DNS are - permitted to further constrain the syntax of the domain - names they use, although the DNS deployment has led to - some applications allowing more general names. In - particular, Section 2.1 of this document liberalizes - slightly the syntax of a legal Internet host name that - was defined in RFC-952 [DNS:4]. - - 6.1.3.6 Status of RR Types - - Name servers MUST be able to load all RR types except MD and - MF from configuration files. The MD and MF types are - obsolete and MUST NOT be implemented; in particular, name - servers MUST NOT load these types from configuration files. - - - -Internet Engineering Task Force [Page 79] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - DISCUSSION: - The RR types MB, MG, MR, NULL, MINFO and RP are - considered experimental, and applications that use the - DNS cannot expect these RR types to be supported by - most domains. Furthermore these types are subject to - redefinition. - - The TXT and WKS RR types have not been widely used by - Internet sites; as a result, an application cannot rely - on the the existence of a TXT or WKS RR in most - domains. - - 6.1.3.7 Robustness - - DNS software may need to operate in environments where the - root servers or other servers are unavailable due to network - connectivity or other problems. In this situation, DNS name - servers and resolvers MUST continue to provide service for - the reachable part of the name space, while giving temporary - failures for the rest. - - DISCUSSION: - Although the DNS is meant to be used primarily in the - connected Internet, it should be possible to use the - system in networks which are unconnected to the - Internet. Hence implementations must not depend on - access to root servers before providing service for - local names. - - 6.1.3.8 Local Host Table - - DISCUSSION: - A host may use a local host table as a backup or - supplement to the DNS. This raises the question of - which takes precedence, the DNS or the host table; the - most flexible approach would make this a configuration - option. - - Typically, the contents of such a supplementary host - table will be determined locally by the site. However, - a publically-available table of Internet hosts is - maintained by the DDN Network Information Center (DDN - NIC), with a format documented in [DNS:4]. This table - can be retrieved from the DDN NIC using a protocol - described in [DNS:5]. It must be noted that this table - contains only a small fraction of all Internet hosts. - Hosts using this protocol to retrieve the DDN NIC host - table should use the VERSION command to check if the - - - -Internet Engineering Task Force [Page 80] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - table has changed before requesting the entire table - with the ALL command. The VERSION identifier should be - treated as an arbitrary string and tested only for - equality; no numerical sequence may be assumed. - - The DDN NIC host table includes administrative - information that is not needed for host operation and - is therefore not currently included in the DNS - database; examples include network and gateway entries. - However, much of this additional information will be - added to the DNS in the future. Conversely, the DNS - provides essential services (in particular, MX records) - that are not available from the DDN NIC host table. - - 6.1.4 DNS USER INTERFACE - - 6.1.4.1 DNS Administration - - This document is concerned with design and implementation - issues in host software, not with administrative or - operational issues. However, administrative issues are of - particular importance in the DNS, since errors in particular - segments of this large distributed database can cause poor - or erroneous performance for many sites. These issues are - discussed in [DNS:6] and [DNS:7]. - - 6.1.4.2 DNS User Interface - - Hosts MUST provide an interface to the DNS for all - application programs running on the host. This interface - will typically direct requests to a system process to - perform the resolver function [DNS:1, 6.1:2]. - - At a minimum, the basic interface MUST support a request for - all information of a specific type and class associated with - a specific name, and it MUST return either all of the - requested information, a hard error code, or a soft error - indication. When there is no error, the basic interface - returns the complete response information without - modification, deletion, or ordering, so that the basic - interface will not need to be changed to accommodate new - data types. - - DISCUSSION: - The soft error indication is an essential part of the - interface, since it may not always be possible to - access particular information from the DNS; see Section - 6.1.3.3. - - - -Internet Engineering Task Force [Page 81] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - A host MAY provide other DNS interfaces tailored to - particular functions, transforming the raw domain data into - formats more suited to these functions. In particular, a - host MUST provide a DNS interface to facilitate translation - between host addresses and host names. - - 6.1.4.3 Interface Abbreviation Facilities - - User interfaces MAY provide a method for users to enter - abbreviations for commonly-used names. Although the - definition of such methods is outside of the scope of the - DNS specification, certain rules are necessary to insure - that these methods allow access to the entire DNS name space - and to prevent excessive use of Internet resources. - - If an abbreviation method is provided, then: - - (a) There MUST be some convention for denoting that a name - is already complete, so that the abbreviation method(s) - are suppressed. A trailing dot is the usual method. - - (b) Abbreviation expansion MUST be done exactly once, and - MUST be done in the context in which the name was - entered. - - - DISCUSSION: - For example, if an abbreviation is used in a mail - program for a destination, the abbreviation should be - expanded into a full domain name and stored in the - queued message with an indication that it is already - complete. Otherwise, the abbreviation might be - expanded with a mail system search list, not the - user's, or a name could grow due to repeated - canonicalizations attempts interacting with wildcards. - - The two most common abbreviation methods are: - - (1) Interface-level aliases - - Interface-level aliases are conceptually implemented as - a list of alias/domain name pairs. The list can be - per-user or per-host, and separate lists can be - associated with different functions, e.g. one list for - host name-to-address translation, and a different list - for mail domains. When the user enters a name, the - interface attempts to match the name to the alias - component of a list entry, and if a matching entry can - - - -Internet Engineering Task Force [Page 82] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - be found, the name is replaced by the domain name found - in the pair. - - Note that interface-level aliases and CNAMEs are - completely separate mechanisms; interface-level aliases - are a local matter while CNAMEs are an Internet-wide - aliasing mechanism which is a required part of any DNS - implementation. - - (2) Search Lists - - A search list is conceptually implemented as an ordered - list of domain names. When the user enters a name, the - domain names in the search list are used as suffixes to - the user-supplied name, one by one, until a domain name - with the desired associated data is found, or the - search list is exhausted. Search lists often contain - the name of the local host's parent domain or other - ancestor domains. Search lists are often per-user or - per-process. - - It SHOULD be possible for an administrator to disable a - DNS search-list facility. Administrative denial may be - warranted in some cases, to prevent abuse of the DNS. - - There is danger that a search-list mechanism will - generate excessive queries to the root servers while - testing whether user input is a complete domain name, - lacking a final period to mark it as complete. A - search-list mechanism MUST have one of, and SHOULD have - both of, the following two provisions to prevent this: - - (a) The local resolver/name server can implement - caching of negative responses (see Section - 6.1.3.3). - - (b) The search list expander can require two or more - interior dots in a generated domain name before it - tries using the name in a query to non-local - domain servers, such as the root. - - DISCUSSION: - The intent of this requirement is to avoid - excessive delay for the user as the search list is - tested, and more importantly to prevent excessive - traffic to the root and other high-level servers. - For example, if the user supplied a name "X" and - the search list contained the root as a component, - - - -Internet Engineering Task Force [Page 83] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - a query would have to consult a root server before - the next search list alternative could be tried. - The resulting load seen by the root servers and - gateways near the root would be multiplied by the - number of hosts in the Internet. - - The negative caching alternative limits the effect - to the first time a name is used. The interior - dot rule is simpler to implement but can prevent - easy use of some top-level names. - - - 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e ------------------------------------------------|-----------|-|-|-|-|-|-- -GENERAL ISSUES | | | | | | | - | | | | | | | -Implement DNS name-to-address conversion |6.1.1 |x| | | | | -Implement DNS address-to-name conversion |6.1.1 |x| | | | | -Support conversions using host table |6.1.1 | | |x| | | -Properly handle RR with zero TTL |6.1.2.1 |x| | | | | -Use QCLASS=* unnecessarily |6.1.2.2 | |x| | | | - Use QCLASS=IN for Internet class |6.1.2.2 |x| | | | | -Unused fields zero |6.1.2.3 |x| | | | | -Use compression in responses |6.1.2.4 |x| | | | | - | | | | | | | -Include config info in responses |6.1.2.5 | | | | |x| -Support all well-known, class-indep. types |6.1.3.5 |x| | | | | -Easily expand type list |6.1.3.5 | |x| | | | -Load all RR types (except MD and MF) |6.1.3.6 |x| | | | | -Load MD or MF type |6.1.3.6 | | | | |x| -Operate when root servers, etc. unavailable |6.1.3.7 |x| | | | | ------------------------------------------------|-----------|-|-|-|-|-|-- -RESOLVER ISSUES: | | | | | | | - | | | | | | | -Resolver support multiple concurrent requests |6.1.3.1 | |x| | | | -Full-service resolver: |6.1.3.1 | | |x| | | - Local caching |6.1.3.1 |x| | | | | - - - -Internet Engineering Task Force [Page 84] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - Information in local cache times out |6.1.3.1 |x| | | | | - Configurable with starting info |6.1.3.1 | |x| | | | -Stub resolver: |6.1.3.1 | | |x| | | - Use redundant recursive name servers |6.1.3.1 |x| | | | | - Local caching |6.1.3.1 | | |x| | | - Information in local cache times out |6.1.3.1 |x| | | | | -Support for remote multi-homed hosts: | | | | | | | - Sort multiple addresses by preference list |6.1.3.4 | |x| | | | - | | | | | | | ------------------------------------------------|-----------|-|-|-|-|-|-- -TRANSPORT PROTOCOLS: | | | | | | | - | | | | | | | -Support UDP queries |6.1.3.2 |x| | | | | -Support TCP queries |6.1.3.2 | |x| | | | - Send query using UDP first |6.1.3.2 |x| | | | |1 - Try TCP if UDP answers are truncated |6.1.3.2 | |x| | | | -Name server limit TCP query resources |6.1.3.2 | | |x| | | - Punish unnecessary TCP query |6.1.3.2 | | | |x| | -Use truncated data as if it were not |6.1.3.2 | | | | |x| -Private agreement to use only TCP |6.1.3.2 | | |x| | | -Use TCP for zone transfers |6.1.3.2 |x| | | | | -TCP usage not block UDP queries |6.1.3.2 |x| | | | | -Support broadcast or multicast queries |6.1.3.2 | | |x| | | - RD bit set in query |6.1.3.2 | | | | |x| - RD bit ignored by server is b'cast/m'cast |6.1.3.2 |x| | | | | - Send only as occasional probe for addr's |6.1.3.2 | |x| | | | ------------------------------------------------|-----------|-|-|-|-|-|-- -RESOURCE USAGE: | | | | | | | - | | | | | | | -Transmission controls, per [DNS:2] |6.1.3.3 |x| | | | | - Finite bounds per request |6.1.3.3 |x| | | | | -Failure after retries => soft error |6.1.3.3 |x| | | | | -Cache temporary failures |6.1.3.3 | |x| | | | -Cache negative responses |6.1.3.3 | |x| | | | -Retries use exponential backoff |6.1.3.3 | |x| | | | - Upper, lower bounds |6.1.3.3 | |x| | | | -Client handle Source Quench |6.1.3.3 | |x| | | | -Server ignore Source Quench |6.1.3.3 | | |x| | | ------------------------------------------------|-----------|-|-|-|-|-|-- -USER INTERFACE: | | | | | | | - | | | | | | | -All programs have access to DNS interface |6.1.4.2 |x| | | | | -Able to request all info for given name |6.1.4.2 |x| | | | | -Returns complete info or error |6.1.4.2 |x| | | | | -Special interfaces |6.1.4.2 | | |x| | | - Name<->Address translation |6.1.4.2 |x| | | | | - | | | | | | | -Abbreviation Facilities: |6.1.4.3 | | |x| | | - - - -Internet Engineering Task Force [Page 85] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - Convention for complete names |6.1.4.3 |x| | | | | - Conversion exactly once |6.1.4.3 |x| | | | | - Conversion in proper context |6.1.4.3 |x| | | | | - Search list: |6.1.4.3 | | |x| | | - Administrator can disable |6.1.4.3 | |x| | | | - Prevention of excessive root queries |6.1.4.3 |x| | | | | - Both methods |6.1.4.3 | |x| | | | ------------------------------------------------|-----------|-|-|-|-|-|-- ------------------------------------------------|-----------|-|-|-|-|-|-- - -1. Unless there is private agreement between particular resolver and - particular server. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 86] - - - - -RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 - - - 6.2 HOST INITIALIZATION - - 6.2.1 INTRODUCTION - - This section discusses the initialization of host software - across a connected network, or more generally across an - Internet path. This is necessary for a diskless host, and may - optionally be used for a host with disk drives. For a diskless - host, the initialization process is called "network booting" - and is controlled by a bootstrap program located in a boot ROM. - - To initialize a diskless host across the network, there are two - distinct phases: - - (1) Configure the IP layer. - - Diskless machines often have no permanent storage in which - to store network configuration information, so that - sufficient configuration information must be obtained - dynamically to support the loading phase that follows. - This information must include at least the IP addresses of - the host and of the boot server. To support booting - across a gateway, the address mask and a list of default - gateways are also required. - - (2) Load the host system code. - - During the loading phase, an appropriate file transfer - protocol is used to copy the system code across the - network from the boot server. - - A host with a disk may perform the first step, dynamic - configuration. This is important for microcomputers, whose - floppy disks allow network configuration information to be - mistakenly duplicated on more than one host. Also, - installation of new hosts is much simpler if they automatically - obtain their configuration information from a central server, - saving administrator time and decreasing the probability of - mistakes. - - 6.2.2 REQUIREMENTS - - 6.2.2.1 Dynamic Configuration - - A number of protocol provisions have been made for dynamic - configuration. - - o ICMP Information Request/Reply messages - - - -Internet Engineering Task Force [Page 87] - - - - -RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 - - - This obsolete message pair was designed to allow a host - to find the number of the network it is on. - Unfortunately, it was useful only if the host already - knew the host number part of its IP address, - information that hosts requiring dynamic configuration - seldom had. - - o Reverse Address Resolution Protocol (RARP) [BOOT:4] - - RARP is a link-layer protocol for a broadcast medium - that allows a host to find its IP address given its - link layer address. Unfortunately, RARP does not work - across IP gateways and therefore requires a RARP server - on every network. In addition, RARP does not provide - any other configuration information. - - o ICMP Address Mask Request/Reply messages - - These ICMP messages allow a host to learn the address - mask for a particular network interface. - - o BOOTP Protocol [BOOT:2] - - This protocol allows a host to determine the IP - addresses of the local host and the boot server, the - name of an appropriate boot file, and optionally the - address mask and list of default gateways. To locate a - BOOTP server, the host broadcasts a BOOTP request using - UDP. Ad hoc gateway extensions have been used to - transmit the BOOTP broadcast through gateways, and in - the future the IP Multicasting facility will provide a - standard mechanism for this purpose. - - - The suggested approach to dynamic configuration is to use - the BOOTP protocol with the extensions defined in "BOOTP - Vendor Information Extensions" RFC-1084 [BOOT:3]. RFC-1084 - defines some important general (not vendor-specific) - extensions. In particular, these extensions allow the - address mask to be supplied in BOOTP; we RECOMMEND that the - address mask be supplied in this manner. - - DISCUSSION: - Historically, subnetting was defined long after IP, and - so a separate mechanism (ICMP Address Mask messages) - was designed to supply the address mask to a host. - However, the IP address mask and the corresponding IP - address conceptually form a pair, and for operational - - - -Internet Engineering Task Force [Page 88] - - - - -RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 - - - simplicity they ought to be defined at the same time - and by the same mechanism, whether a configuration file - or a dynamic mechanism like BOOTP. - - Note that BOOTP is not sufficiently general to specify - the configurations of all interfaces of a multihomed - host. A multihomed host must either use BOOTP - separately for each interface, or configure one - interface using BOOTP to perform the loading, and - perform the complete initialization from a file later. - - Application layer configuration information is expected - to be obtained from files after loading of the system - code. - - 6.2.2.2 Loading Phase - - A suggested approach for the loading phase is to use TFTP - [BOOT:1] between the IP addresses established by BOOTP. - - TFTP to a broadcast address SHOULD NOT be used, for reasons - explained in Section 4.2.3.4. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 89] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - 6.3 REMOTE MANAGEMENT - - 6.3.1 INTRODUCTION - - The Internet community has recently put considerable effort - into the development of network management protocols. The - result has been a two-pronged approach [MGT:1, MGT:6]: the - Simple Network Management Protocol (SNMP) [MGT:4] and the - Common Management Information Protocol over TCP (CMOT) [MGT:5]. - - In order to be managed using SNMP or CMOT, a host will need to - implement an appropriate management agent. An Internet host - SHOULD include an agent for either SNMP or CMOT. - - Both SNMP and CMOT operate on a Management Information Base - (MIB) that defines a collection of management values. By - reading and setting these values, a remote application may - query and change the state of the managed system. - - A standard MIB [MGT:3] has been defined for use by both - management protocols, using data types defined by the Structure - of Management Information (SMI) defined in [MGT:2]. Additional - MIB variables can be introduced under the "enterprises" and - "experimental" subtrees of the MIB naming space [MGT:2]. - - Every protocol module in the host SHOULD implement the relevant - MIB variables. A host SHOULD implement the MIB variables as - defined in the most recent standard MIB, and MAY implement - other MIB variables when appropriate and useful. - - 6.3.2 PROTOCOL WALK-THROUGH - - The MIB is intended to cover both hosts and gateways, although - there may be detailed differences in MIB application to the two - cases. This section contains the appropriate interpretation of - the MIB for hosts. It is likely that later versions of the MIB - will include more entries for host management. - - A managed host must implement the following groups of MIB - object definitions: System, Interfaces, Address Translation, - IP, ICMP, TCP, and UDP. - - The following specific interpretations apply to hosts: - - o ipInHdrErrors - - Note that the error "time-to-live exceeded" can occur in a - host only when it is forwarding a source-routed datagram. - - - -Internet Engineering Task Force [Page 90] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - o ipOutNoRoutes - - This object counts datagrams discarded because no route - can be found. This may happen in a host if all the - default gateways in the host's configuration are down. - - o ipFragOKs, ipFragFails, ipFragCreates - - A host that does not implement intentional fragmentation - (see "Fragmentation" section of [INTRO:1]) MUST return the - value zero for these three objects. - - o icmpOutRedirects - - For a host, this object MUST always be zero, since hosts - do not send Redirects. - - o icmpOutAddrMaskReps - - For a host, this object MUST always be zero, unless the - host is an authoritative source of address mask - information. - - o ipAddrTable - - For a host, the "IP Address Table" object is effectively a - table of logical interfaces. - - o ipRoutingTable - - For a host, the "IP Routing Table" object is effectively a - combination of the host's Routing Cache and the static - route table described in "Routing Outbound Datagrams" - section of [INTRO:1]. - - Within each ipRouteEntry, ipRouteMetric1...4 normally will - have no meaning for a host and SHOULD always be -1, while - ipRouteType will normally have the value "remote". - - If destinations on the connected network do not appear in - the Route Cache (see "Routing Outbound Datagrams section - of [INTRO:1]), there will be no entries with ipRouteType - of "direct". - - - DISCUSSION: - The current MIB does not include Type-of-Service in an - ipRouteEntry, but a future revision is expected to make - - - -Internet Engineering Task Force [Page 91] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - this addition. - - We also expect the MIB to be expanded to allow the remote - management of applications (e.g., the ability to partially - reconfigure mail systems). Network service applications - such as mail systems should therefore be written with the - "hooks" for remote management. - - 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e ------------------------------------------------|-----------|-|-|-|-|-|-- -Support SNMP or CMOT agent |6.3.1 | |x| | | | -Implement specified objects in standard MIB |6.3.1 | |x| | | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 92] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - -7. REFERENCES - - This section lists the primary references with which every - implementer must be thoroughly familiar. It also lists some - secondary references that are suggested additional reading. - - INTRODUCTORY REFERENCES: - - - [INTRO:1] "Requirements for Internet Hosts -- Communication Layers," - IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122, - October 1989. - - [INTRO:2] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006, - (three volumes), SRI International, December 1985. - - [INTRO:3] "Official Internet Protocols," J. Reynolds and J. Postel, - RFC-1011, May 1987. - - This document is republished periodically with new RFC numbers; - the latest version must be used. - - [INTRO:4] "Protocol Document Order Information," O. Jacobsen and J. - Postel, RFC-980, March 1986. - - [INTRO:5] "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, - May 1987. - - This document is republished periodically with new RFC numbers; - the latest version must be used. - - - TELNET REFERENCES: - - - [TELNET:1] "Telnet Protocol Specification," J. Postel and J. - Reynolds, RFC-854, May 1983. - - [TELNET:2] "Telnet Option Specification," J. Postel and J. Reynolds, - RFC-855, May 1983. - - [TELNET:3] "Telnet Binary Transmission," J. Postel and J. Reynolds, - RFC-856, May 1983. - - [TELNET:4] "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857, - May 1983. - - [TELNET:5] "Telnet Suppress Go Ahead Option," J. Postel and J. - - - -Internet Engineering Task Force [Page 93] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - Reynolds, RFC-858, May 1983. - - [TELNET:6] "Telnet Status Option," J. Postel and J. Reynolds, RFC- - 859, May 1983. - - [TELNET:7] "Telnet Timing Mark Option," J. Postel and J. Reynolds, - RFC-860, May 1983. - - [TELNET:8] "Telnet Extended Options List," J. Postel and J. - Reynolds, RFC-861, May 1983. - - [TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-855, - December 1983. - - [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091, - February 1989. - - This document supercedes RFC-930. - - [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073, - October 1988. - - [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August - 1989. - - [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079, - December 1988. - - [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC- - 1080, November 1988. - - - SECONDARY TELNET REFERENCES: - - - [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of - Defense, May 1984. - - This document is intended to describe the same protocol as RFC- - 854. In case of conflict, RFC-854 takes precedence, and the - present document takes precedence over both. - - [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977. - - [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October - 1977. - - [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977. - - - -Internet Engineering Task Force [Page 94] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS - Implementation," A. Yasuda and T. Thompson, RFC-1043, February - 1988. - - - FTP REFERENCES: - - - [FTP:1] "File Transfer Protocol," J. Postel and J. Reynolds, RFC- - 959, October 1985. - - [FTP:2] "Document File Format Standards," J. Postel, RFC-678, - December 1974. - - [FTP:3] "File Transfer Protocol," MIL-STD-1780, U.S. Department of - Defense, May 1984. - - This document is based on an earlier version of the FTP - specification (RFC-765) and is obsolete. - - - TFTP REFERENCES: - - - [TFTP:1] "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June - 1981. - - - MAIL REFERENCES: - - - [SMTP:1] "Simple Mail Transfer Protocol," J. Postel, RFC-821, August - 1982. - - [SMTP:2] "Standard For The Format of ARPA Internet Text Messages," - D. Crocker, RFC-822, August 1982. - - This document obsoleted an earlier specification, RFC-733. - - [SMTP:3] "Mail Routing and the Domain System," C. Partridge, RFC- - 974, January 1986. - - This RFC describes the use of MX records, a mandatory extension - to the mail delivery process. - - [SMTP:4] "Duplicate Messages and SMTP," C. Partridge, RFC-1047, - February 1988. - - - - -Internet Engineering Task Force [Page 95] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - [SMTP:5a] "Mapping between X.400 and RFC 822," S. Kille, RFC-987, - June 1986. - - [SMTP:5b] "Addendum to RFC-987," S. Kille, RFC-???, September 1987. - - The two preceding RFC's define a proposed standard for - gatewaying mail between the Internet and the X.400 environments. - - [SMTP:6] "Simple Mail Transfer Protocol," MIL-STD-1781, U.S. - Department of Defense, May 1984. - - This specification is intended to describe the same protocol as - does RFC-821. However, MIL-STD-1781 is incomplete; in - particular, it does not include MX records [SMTP:3]. - - [SMTP:7] "A Content-Type Field for Internet Messages," M. Sirbu, - RFC-1049, March 1988. - - - DOMAIN NAME SYSTEM REFERENCES: - - - [DNS:1] "Domain Names - Concepts and Facilities," P. Mockapetris, - RFC-1034, November 1987. - - This document and the following one obsolete RFC-882, RFC-883, - and RFC-973. - - [DNS:2] "Domain Names - Implementation and Specification," RFC-1035, - P. Mockapetris, November 1987. - - - [DNS:3] "Mail Routing and the Domain System," C. Partridge, RFC-974, - January 1986. - - - [DNS:4] "DoD Internet Host Table Specification," K. Harrenstein, - RFC-952, M. Stahl, E. Feinler, October 1985. - - SECONDARY DNS REFERENCES: - - - [DNS:5] "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler, - RFC-953, October 1985. - - [DNS:6] "Domain Administrators Guide," M. Stahl, RFC-1032, November - 1987. - - - - -Internet Engineering Task Force [Page 96] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - [DNS:7] "Domain Administrators Operations Guide," M. Lottor, RFC- - 1033, November 1987. - - [DNS:8] "The Domain Name System Handbook," Vol. 4 of Internet - Protocol Handbook, NIC 50007, SRI Network Information Center, - August 1989. - - - SYSTEM INITIALIZATION REFERENCES: - - - [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June - 1984. - - [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC- - 951, September 1985. - - [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC- - 1084, December 1988. - - Note: this RFC revised and obsoleted RFC-1048. - - [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T. - Mann, J. Mogul, and M. Theimer, RFC-903, June 1984. - - - MANAGEMENT REFERENCES: - - - [MGT:1] "IAB Recommendations for the Development of Internet Network - Management Standards," V. Cerf, RFC-1052, April 1988. - - [MGT:2] "Structure and Identification of Management Information for - TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065, - August 1988. - - [MGT:3] "Management Information Base for Network Management of - TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066, - August 1988. - - [MGT:4] "A Simple Network Management Protocol," J. Case, M. Fedor, - M. Schoffstall, and C. Davin, RFC-1098, April 1989. - - [MGT:5] "The Common Management Information Services and Protocol - over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989. - - [MGT:6] "Report of the Second Ad Hoc Network Management Review - Group," V. Cerf, RFC-1109, August 1989. - - - -Internet Engineering Task Force [Page 97] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - -Security Considerations - - There are many security issues in the application and support - programs of host software, but a full discussion is beyond the scope - of this RFC. Security-related issues are mentioned in sections - concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and - EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the - SMTP DATA command (Section 5.2.8). - -Author's Address - - Robert Braden - USC/Information Sciences Institute - 4676 Admiralty Way - Marina del Rey, CA 90292-6695 - - Phone: (213) 822 1511 - - EMail: Braden@ISI.EDU - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 98] - diff --git a/contrib/bind9/doc/rfc/rfc1183.txt b/contrib/bind9/doc/rfc/rfc1183.txt deleted file mode 100644 index 6f080448bc72..000000000000 --- a/contrib/bind9/doc/rfc/rfc1183.txt +++ /dev/null @@ -1,619 +0,0 @@ - - - - - - -Network Working Group C. Everhart -Request for Comments: 1183 Transarc -Updates: RFCs 1034, 1035 L. Mamakos - University of Maryland - R. Ullmann - Prime Computer - P. Mockapetris, Editor - ISI - October 1990 - - - New DNS RR Definitions - -Status of this Memo - - This memo defines five new DNS types for experimental purposes. This - RFC describes an Experimental Protocol for the Internet community, - and requests discussion and suggestions for improvements. - Distribution of this memo is unlimited. - -Table of Contents - - Introduction.................................................... 1 - 1. AFS Data Base location....................................... 2 - 2. Responsible Person........................................... 3 - 2.1. Identification of the guilty party......................... 3 - 2.2. The Responsible Person RR.................................. 4 - 3. X.25 and ISDN addresses, Route Binding....................... 6 - 3.1. The X25 RR................................................. 6 - 3.2. The ISDN RR................................................ 7 - 3.3. The Route Through RR....................................... 8 - REFERENCES and BIBLIOGRAPHY..................................... 9 - Security Considerations......................................... 10 - Authors' Addresses.............................................. 11 - -Introduction - - This RFC defines the format of new Resource Records (RRs) for the - Domain Name System (DNS), and reserves corresponding DNS type - mnemonics and numerical codes. The definitions are in three - independent sections: (1) location of AFS database servers, (2) - location of responsible persons, and (3) representation of X.25 and - ISDN addresses and route binding. All are experimental. - - This RFC assumes that the reader is familiar with the DNS [3,4]. The - data shown is for pedagogical use and does not necessarily reflect - the real Internet. - - - - -Everhart, Mamakos, Ullmann & Mockapetris [Page 1] - -RFC 1183 New DNS RR Definitions October 1990 - - -1. AFS Data Base location - - This section defines an extension of the DNS to locate servers both - for AFS (AFS is a registered trademark of Transarc Corporation) and - for the Open Software Foundation's (OSF) Distributed Computing - Environment (DCE) authenticated naming system using HP/Apollo's NCA, - both to be components of the OSF DCE. The discussion assumes that - the reader is familiar with AFS [5] and NCA [6]. - - The AFS (originally the Andrew File System) system uses the DNS to - map from a domain name to the name of an AFS cell database server. - The DCE Naming service uses the DNS for a similar function: mapping - from the domain name of a cell to authenticated name servers for that - cell. The method uses a new RR type with mnemonic AFSDB and type - code of 18 (decimal). - - AFSDB has the following format: - - <owner> <ttl> <class> AFSDB <subtype> <hostname> - - Both RDATA fields are required in all AFSDB RRs. The <subtype> field - is a 16 bit integer. The <hostname> field is a domain name of a host - that has a server for the cell named by the owner name of the RR. - - The format of the AFSDB RR is class insensitive. AFSDB records cause - type A additional section processing for <hostname>. This, in fact, - is the rationale for using a new type code, rather than trying to - build the same functionality with TXT RRs. - - Note that the format of AFSDB in a master file is identical to MX. - For purposes of the DNS itself, the subtype is merely an integer. - The present subtype semantics are discussed below, but changes are - possible and will be announced in subsequent RFCs. - - In the case of subtype 1, the host has an AFS version 3.0 Volume - Location Server for the named AFS cell. In the case of subtype 2, - the host has an authenticated name server holding the cell-root - directory node for the named DCE/NCA cell. - - The use of subtypes is motivated by two considerations. First, the - space of DNS RR types is limited. Second, the services provided are - sufficiently distinct that it would continue to be confusing for a - client to attempt to connect to a cell's servers using the protocol - for one service, if the cell offered only the other service. - - As an example of the use of this RR, suppose that the Toaster - Corporation has deployed AFS 3.0 but not (yet) the OSF's DCE. Their - cell, named toaster.com, has three "AFS 3.0 cell database server" - - - -Everhart, Mamakos, Ullmann & Mockapetris [Page 2] - -RFC 1183 New DNS RR Definitions October 1990 - - - machines: bigbird.toaster.com, ernie.toaster.com, and - henson.toaster.com. These three machines would be listed in three - AFSDB RRs. These might appear in a master file as: - - toaster.com. AFSDB 1 bigbird.toaster.com. - toaster.com. AFSDB 1 ernie.toaster.com. - toaster.com. AFSDB 1 henson.toaster.com. - - As another example use of this RR, suppose that Femto College (domain - name femto.edu) has deployed DCE, and that their DCE cell root - directory is served by processes running on green.femto.edu and - turquoise.femto.edu. Furthermore, their DCE file servers also run - AFS 3.0-compatible volume location servers, on the hosts - turquoise.femto.edu and orange.femto.edu. These machines would be - listed in four AFSDB RRs, which might appear in a master file as: - - femto.edu. AFSDB 2 green.femto.edu. - femto.edu. AFSDB 2 turquoise.femto.edu. - femto.edu. AFSDB 1 turquoise.femto.edu. - femto.edu. AFSDB 1 orange.femto.edu. - -2. Responsible Person - - The purpose of this section is to provide a standard method for - associating responsible person identification to any name in the DNS. - - The domain name system functions as a distributed database which - contains many different form of information. For a particular name - or host, you can discover it's Internet address, mail forwarding - information, hardware type and operating system among others. - - A key aspect of the DNS is that the tree-structured namespace can be - divided into pieces, called zones, for purposes of distributing - control and responsibility. The responsible person for zone database - purposes is named in the SOA RR for that zone. This section - describes an extension which allows different responsible persons to - be specified for different names in a zone. - -2.1. Identification of the guilty party - - Often it is desirable to be able to identify the responsible entity - for a particular host. When that host is down or malfunctioning, it - is difficult to contact those parties which might resolve or repair - the host. Mail sent to POSTMASTER may not reach the person in a - timely fashion. If the host is one of a multitude of workstations, - there may be no responsible person which can be contacted on that - host. - - - - -Everhart, Mamakos, Ullmann & Mockapetris [Page 3] - -RFC 1183 New DNS RR Definitions October 1990 - - - The POSTMASTER mailbox on that host continues to be a good contact - point for mail problems, and the zone contact in the SOA record for - database problem, but the RP record allows us to associate a mailbox - to entities that don't receive mail or are not directly connected - (namespace-wise) to the problem (e.g., GATEWAY.ISI.EDU might want to - point at HOTLINE@BBN.COM, and GATEWAY doesn't get mail, nor does the - ISI zone administrator have a clue about fixing gateways). - -2.2. The Responsible Person RR - - The method uses a new RR type with mnemonic RP and type code of 17 - (decimal). - - RP has the following format: - - <owner> <ttl> <class> RP <mbox-dname> <txt-dname> - - Both RDATA fields are required in all RP RRs. - - The first field, <mbox-dname>, is a domain name that specifies the - mailbox for the responsible person. Its format in master files uses - the DNS convention for mailbox encoding, identical to that used for - the RNAME mailbox field in the SOA RR. The root domain name (just - ".") may be specified for <mbox-dname> to indicate that no mailbox is - available. - - The second field, <txt-dname>, is a domain name for which TXT RR's - exist. A subsequent query can be performed to retrieve the - associated TXT resource records at <txt-dname>. This provides a - level of indirection so that the entity can be referred to from - multiple places in the DNS. The root domain name (just ".") may be - specified for <txt-dname> to indicate that the TXT_DNAME is absent, - and no associated TXT RR exists. - - The format of the RP RR is class insensitive. RP records cause no - additional section processing. (TXT additional section processing - for <txt-dname> is allowed as an option, but only if it is disabled - for the root, i.e., "."). - - The Responsible Person RR can be associated with any node in the - Domain Name System hierarchy, not just at the leaves of the tree. - - The TXT RR associated with the TXT_DNAME contain free format text - suitable for humans. Refer to [4] for more details on the TXT RR. - - Multiple RP records at a single name may be present in the database. - They should have identical TTLs. - - - - -Everhart, Mamakos, Ullmann & Mockapetris [Page 4] - -RFC 1183 New DNS RR Definitions October 1990 - - - EXAMPLES - - Some examples of how the RP record might be used. - - sayshell.umd.edu. A 128.8.1.14 - MX 10 sayshell.umd.edu. - HINFO NeXT UNIX - WKS 128.8.1.14 tcp ftp telnet smtp - RP louie.trantor.umd.edu. LAM1.people.umd.edu. - - LAM1.people.umd.edu. TXT ( - "Louis A. Mamakos, (301) 454-2946, don't call me at home!" ) - - In this example, the responsible person's mailbox for the host - SAYSHELL.UMD.EDU is louie@trantor.umd.edu. The TXT RR at - LAM1.people.umd.edu provides additional information and advice. - - TERP.UMD.EDU. A 128.8.10.90 - MX 10 128.8.10.90 - HINFO MICROVAX-II UNIX - WKS 128.8.10.90 udp domain - WKS 128.8.10.90 tcp ftp telnet smtp domain - RP louie.trantor.umd.edu. LAM1.people.umd.edu. - RP root.terp.umd.edu. ops.CS.UMD.EDU. - - TRANTOR.UMD.EDU. A 128.8.10.14 - MX 10 trantor.umd.edu. - HINFO MICROVAX-II UNIX - WKS 128.8.10.14 udp domain - WKS 128.8.10.14 tcp ftp telnet smtp domain - RP louie.trantor.umd.edu. LAM1.people.umd.edu. - RP petry.netwolf.umd.edu. petry.people.UMD.EDU. - RP root.trantor.umd.edu. ops.CS.UMD.EDU. - RP gregh.sunset.umd.edu. . - - LAM1.people.umd.edu. TXT "Louis A. Mamakos (301) 454-2946" - petry.people.umd.edu. TXT "Michael G. Petry (301) 454-2946" - ops.CS.UMD.EDU. TXT "CS Operations Staff (301) 454-2943" - - This set of resource records has two hosts, TRANTOR.UMD.EDU and - TERP.UMD.EDU, as well as a number of TXT RRs. Note that TERP.UMD.EDU - and TRANTOR.UMD.EDU both reference the same pair of TXT resource - records, although the mail box names (root.terp.umd.edu and - root.trantor.umd.edu) differ. - - Here, we obviously care much more if the machine flakes out, as we've - specified four persons which might want to be notified of problems or - other events involving TRANTOR.UMD.EDU. In this example, the last RP - - - -Everhart, Mamakos, Ullmann & Mockapetris [Page 5] - -RFC 1183 New DNS RR Definitions October 1990 - - - RR for TRANTOR.UMD.EDU specifies a mailbox (gregh.sunset.umd.edu), - but no associated TXT RR. - -3. X.25 and ISDN addresses, Route Binding - - This section describes an experimental representation of X.25 and - ISDN addresses in the DNS, as well as a route binding method, - analogous to the MX for mail routing, for very large scale networks. - - There are several possible uses, all experimental at this time. - First, the RRs provide simple documentation of the correct addresses - to use in static configurations of IP/X.25 [11] and SMTP/X.25 [12]. - - The RRs could also be used automatically by an internet network-layer - router, typically IP. The procedure would be to map IP address to - domain name, then name to canonical name if needed, then following RT - records, and finally attempting an IP/X.25 call to the address found. - Alternately, configured domain names could be resolved to identify IP - to X.25/ISDN bindings for a static but periodically refreshed routing - table. - - This provides a function similar to ARP for wide area non-broadcast - networks that will scale well to a network with hundreds of millions - of hosts. - - Also, a standard address binding reference will facilitate other - experiments in the use of X.25 and ISDN, especially in serious - inter-operability testing. The majority of work in such a test is - establishing the n-squared entries in static tables. - - Finally, the RRs are intended for use in a proposal [13] by one of - the authors for a possible next-generation internet. - -3.1. The X25 RR - - The X25 RR is defined with mnemonic X25 and type code 19 (decimal). - - X25 has the following format: - - <owner> <ttl> <class> X25 <PSDN-address> - - <PSDN-address> is required in all X25 RRs. - - <PSDN-address> identifies the PSDN (Public Switched Data Network) - address in the X.121 [10] numbering plan associated with <owner>. - Its format in master files is a <character-string> syntactically - identical to that used in TXT and HINFO. - - - - -Everhart, Mamakos, Ullmann & Mockapetris [Page 6] - -RFC 1183 New DNS RR Definitions October 1990 - - - The format of X25 is class insensitive. X25 RRs cause no additional - section processing. - - The <PSDN-address> is a string of decimal digits, beginning with the - 4 digit DNIC (Data Network Identification Code), as specified in - X.121. National prefixes (such as a 0) MUST NOT be used. - - For example: - - Relay.Prime.COM. X25 311061700956 - -3.2. The ISDN RR - - The ISDN RR is defined with mnemonic ISDN and type code 20 (decimal). - - An ISDN (Integrated Service Digital Network) number is simply a - telephone number. The intent of the members of the CCITT is to - upgrade all telephone and data network service to a common service. - - The numbering plan (E.163/E.164) is the same as the familiar - international plan for POTS (an un-official acronym, meaning Plain - Old Telephone Service). In E.166, CCITT says "An E.163/E.164 - telephony subscriber may become an ISDN subscriber without a number - change." - - ISDN has the following format: - - <owner> <ttl> <class> ISDN <ISDN-address> <sa> - - The <ISDN-address> field is required; <sa> is optional. - - <ISDN-address> identifies the ISDN number of <owner> and DDI (Direct - Dial In) if any, as defined by E.164 [8] and E.163 [7], the ISDN and - PSTN (Public Switched Telephone Network) numbering plan. E.163 - defines the country codes, and E.164 the form of the addresses. Its - format in master files is a <character-string> syntactically - identical to that used in TXT and HINFO. - - <sa> specifies the subaddress (SA). The format of <sa> in master - files is a <character-string> syntactically identical to that used in - TXT and HINFO. - - The format of ISDN is class insensitive. ISDN RRs cause no - additional section processing. - - The <ISDN-address> is a string of characters, normally decimal - digits, beginning with the E.163 country code and ending with the DDI - if any. Note that ISDN, in Q.931, permits any IA5 character in the - - - -Everhart, Mamakos, Ullmann & Mockapetris [Page 7] - -RFC 1183 New DNS RR Definitions October 1990 - - - general case. - - The <sa> is a string of hexadecimal digits. For digits 0-9, the - concrete encoding in the Q.931 call setup information element is - identical to BCD. - - For example: - - Relay.Prime.COM. IN ISDN 150862028003217 - sh.Prime.COM. IN ISDN 150862028003217 004 - - (Note: "1" is the country code for the North American Integrated - Numbering Area, i.e., the system of "area codes" familiar to people - in those countries.) - - The RR data is the ASCII representation of the digits. It is encoded - as one or two <character-string>s, i.e., count followed by - characters. - - CCITT recommendation E.166 [9] defines prefix escape codes for the - representation of ISDN (E.163/E.164) addresses in X.121, and PSDN - (X.121) addresses in E.164. It specifies that the exact codes are a - "national matter", i.e., different on different networks. A host - connected to the ISDN may be able to use both the X25 and ISDN - addresses, with the local prefix added. - -3.3. The Route Through RR - - The Route Through RR is defined with mnemonic RT and type code 21 - (decimal). - - The RT resource record provides a route-through binding for hosts - that do not have their own direct wide area network addresses. It is - used in much the same way as the MX RR. - - RT has the following format: - - <owner> <ttl> <class> RT <preference> <intermediate-host> - - Both RDATA fields are required in all RT RRs. - - The first field, <preference>, is a 16 bit integer, representing the - preference of the route. Smaller numbers indicate more preferred - routes. - - <intermediate-host> is the domain name of a host which will serve as - an intermediate in reaching the host specified by <owner>. The DNS - RRs associated with <intermediate-host> are expected to include at - - - -Everhart, Mamakos, Ullmann & Mockapetris [Page 8] - -RFC 1183 New DNS RR Definitions October 1990 - - - least one A, X25, or ISDN record. - - The format of the RT RR is class insensitive. RT records cause type - X25, ISDN, and A additional section processing for <intermediate- - host>. - - For example, - - sh.prime.com. IN RT 2 Relay.Prime.COM. - IN RT 10 NET.Prime.COM. - *.prime.com. IN RT 90 Relay.Prime.COM. - - When a host is looking up DNS records to attempt to route a datagram, - it first looks for RT records for the destination host, which point - to hosts with address records (A, X25, ISDN) compatible with the wide - area networks available to the host. If it is itself in the set of - RT records, it discards any RTs with preferences higher or equal to - its own. If there are no (remaining) RTs, it can then use address - records of the destination itself. - - Wild-card RTs are used exactly as are wild-card MXs. RT's do not - "chain"; that is, it is not valid to use the RT RRs found for a host - referred to by an RT. - - The concrete encoding is identical to the MX RR. - -REFERENCES and BIBLIOGRAPHY - - [1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network - Information Center, SRI International, November 1987. - - [2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033, - Network Information Center, SRI International, November, 1987. - - [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC - 1034, USC/Information Sciences Institute, November 1987. - - [4] Mockapetris, P., "Domain Names - Implementation and - Specification", RFC 1035, USC/Information Sciences Institute, - November 1987. - - [5] Spector A., and M. Kazar, "Uniting File Systems", UNIX Review, - 7(3), pp. 61-69, March 1989. - - [6] Zahn, et al., "Network Computing Architecture", Prentice-Hall, - 1989. - - [7] International Telegraph and Telephone Consultative Committee, - - - -Everhart, Mamakos, Ullmann & Mockapetris [Page 9] - -RFC 1183 New DNS RR Definitions October 1990 - - - "Numbering Plan for the International Telephone Service", CCITT - Recommendations E.163., IXth Plenary Assembly, Melbourne, 1988, - Fascicle II.2 ("Blue Book"). - - [8] International Telegraph and Telephone Consultative Committee, - "Numbering Plan for the ISDN Era", CCITT Recommendations E.164., - IXth Plenary Assembly, Melbourne, 1988, Fascicle II.2 ("Blue - Book"). - - [9] International Telegraph and Telephone Consultative Committee. - "Numbering Plan Interworking in the ISDN Era", CCITT - Recommendations E.166., IXth Plenary Assembly, Melbourne, 1988, - Fascicle II.2 ("Blue Book"). - - [10] International Telegraph and Telephone Consultative Committee, - "International Numbering Plan for the Public Data Networks", - CCITT Recommendations X.121., IXth Plenary Assembly, Melbourne, - 1988, Fascicle VIII.3 ("Blue Book"); provisional, Geneva, 1978; - amended, Geneva, 1980, Malaga-Torremolinos, 1984 and Melborne, - 1988. - - [11] Korb, J., "Standard for the Transmission of IP datagrams Over - Public Data Networks", RFC 877, Purdue University, September - 1983. - - [12] Ullmann, R., "SMTP on X.25", RFC 1090, Prime Computer, February - 1989. - - [13] Ullmann, R., "TP/IX: The Next Internet", Prime Computer - (unpublished), July 1990. - - [14] Mockapetris, P., "DNS Encoding of Network Names and Other Types", - RFC 1101, USC/Information Sciences Institute, April 1989. - -Security Considerations - - Security issues are not addressed in this memo. - - - - - - - - - - - - - - -Everhart, Mamakos, Ullmann & Mockapetris [Page 10] - -RFC 1183 New DNS RR Definitions October 1990 - - -Authors' Addresses - - Craig F. Everhart - Transarc Corporation - The Gulf Tower - 707 Grant Street - Pittsburgh, PA 15219 - - Phone: +1 412 338 4467 - - EMail: Craig_Everhart@transarc.com - - - Louis A. Mamakos - Network Infrastructure Group - Computer Science Center - University of Maryland - College Park, MD 20742-2411 - - Phone: +1-301-405-7836 - - Email: louie@Sayshell.UMD.EDU - - - Robert Ullmann 10-30 - Prime Computer, Inc. - 500 Old Connecticut Path - Framingham, MA 01701 - - Phone: +1 508 620 2800 ext 1736 - - Email: Ariel@Relay.Prime.COM - - - Paul Mockapetris - USC Information Sciences Institute - 4676 Admiralty Way - Marina del Rey, CA 90292 - - Phone: 213-822-1511 - - EMail: pvm@isi.edu - - - - - - - - - -Everhart, Mamakos, Ullmann & Mockapetris [Page 11] -
\ No newline at end of file diff --git a/contrib/bind9/doc/rfc/rfc1348.txt b/contrib/bind9/doc/rfc/rfc1348.txt deleted file mode 100644 index d9e5dea040ee..000000000000 --- a/contrib/bind9/doc/rfc/rfc1348.txt +++ /dev/null @@ -1,227 +0,0 @@ - - - - - - -Network Working Group B. Manning -Request for Comments: 1348 Rice University -Updates: RFCs 1034, 1035 July 1992 - - - DNS NSAP RRs - -Status of this Memo - - This memo defines an Experimental Protocol for the Internet - community. Discussion and suggestions for improvement are requested. - Please refer to the current edition of the "IAB Official Protocol - Standards" for the standardization state and status of this protocol. - Distribution of this memo is unlimited. - -Table of Contents - - Introduction ..................................................... 1 - Background ....................................................... 1 - NSAP RR .......................................................... 2 - NSAP-PTR RR ...................................................... 2 - REFERENCES and BIBLIOGRAPHY ...................................... 3 - Security Considerations .......................................... 4 - Author's Address ................................................. 4 - -Introduction - - This RFC defines the format of two new Resource Records (RRs) for the - Domain Name System (DNS), and reserves corresponding DNS type - mnemonic and numerical codes. This format may be used with the any - proposal that has variable length addresses, but is targeted for CLNP - use. - - This memo assumes that the reader is familiar with the DNS [3,4]. - -Background - - This section describes an experimental representation of NSAP - addresses in the DNS. There are several reasons to take this approch. - First, it provides simple documentation of the correct addresses to - use in static configurations of CLNP compliant hosts and routers. - - NSAP support requires that a new DNS resource record entry type - ("NSAP") be defined, to store longer Internet (i.e., NSAP) addresses. - This resource record allows mapping from DNS names to NSAP addresses, - and will contain entries for systems which are able to run Internet - applications, over TCP or UDP, over CLNP. - - - - -Manning [Page 1] - -RFC 1348 DNS NSAP RRs July 1992 - - - The backward translation (from NSAP address to DNS name) is - facilitated by definition of an associated resource record. This - resource record is known as "NSAP-PTR", and is used in a manner - analogous to the existing "in-addr.arpa". - - These RRs are intended for use in a proposal [6] by one of the - members of the NOOP WG to address the next-generation internet. - -The NSAP RR - - The NSAP RR is defined with mnemonic NSAP and type code 22 (decimal). - - An NSAP (Network Service Access Protocol) number is a unique string - to OSI transport service. - - The numbering plan follows RFC 1237 and associated OSI definitions - for NSAP format. - - NSAP has the following format: - - <owner> <ttl> <class> NSAP <length> <NSAP-address> - - All fields are required. - - <length> identifies the number of octets in the <NSAP-address> as - defined by the various national and international authorities. - - <NSAP-address> enumerates the actual octet values assigned by the - assigning authority. Its format in master files is a <character- - string> syntactically identical to that used in TXT and HINFO. - - The format of NSAP is class insensitive. NSAP RR causes no - additional section processing. - - For example: - -foo.bar.com. IN NSAP 21 47000580ffff000000321099991111222233334444 -host.school.de IN NSAP 17 39276f3100111100002222333344449876 - - The RR data is the ASCII representation of the digits. It is encoded - as two <character-strings>, i.e., count followed by characters. - -The NSAP-PTR RR - - The NSAP-PTR RR is defined with mnemonic NSAP-PTR and a type code 23 - (decimal). - - Its function is analogous to the PTR record used for IP addresses - - - -Manning [Page 2] - -RFC 1348 DNS NSAP RRs July 1992 - - - [4,7]. - - NSAP-PTR has the following format: - - <NSAP-suffix> <ttl> <class> NSAP-PTR <owner> - - All fields are required. - - <NSAP-suffix> enumerates the actual octet values assigned by the - assigning authority for the LOCAL network. Its format in master - files is a <character-string> syntactically identical to that used in - TXT and HINFO. - - The format of NSAP-PTR is class insensitive. NSAP-PTR RR causes no - additional section processing. - - For example: - - In net ff08000574.nsap-in-addr.arpa: - - 444433332222111199990123000000ff NSAP-PTR foo.bar.com. - - Or in net 11110031f67293.nsap-in-addr.arpa: - - 67894444333322220000 NSAP-PTR host.school.de. - - The RR data is the ASCII representation of the digits. It is encoded - as a <character-string>. - -REFERENCES and BIBLIOGRAPHY - - [1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network - Information Center, SRI International, November 1987. - - [2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033, - Network Information Center, SRI International, November, 1987. - - [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC - 1034, USC/Information Sciences Institute, November 1987. - - [4] Mockapetris, P., "Domain Names - Implementation and - Specification", RFC 1035, USC/Information Sciences Institute, - November 1987. - - [5] Colella, R., Gardner, E., and R. Callon, "Guidelines for OSI - NSAP Allocation in the Internet", RFC 1237, NIST, Mitre, DEC, - July 1991. - - - - -Manning [Page 3] - -RFC 1348 DNS NSAP RRs July 1992 - - - [6] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), - A Simple Proposal for Internet Addressing and Routing", - Digital Equipment Corporation, RFC 1347, June 1992. - - [7] Mockapetris, P., "DNS Encoding of Network Names and Other Types", - RFC 1101, USC/Information Sciences Institute, April 1989. - - [8] ISO/IEC. Information Processing Systems -- Data Communications - -- Network Service Definition Addendum 2: Network Layer Address- - ing. International Standard 8348/Addendum 2, ISO/IEC JTC 1, - Switzerland, 1988. - - [9] Bryant, P., "NSAPs", PB660, IPTAG/92/23, SCIENCE AND ENGINEERING - RESEARCH COUNCIL, RUTHERFORD APPLETON LABORATORY May 1992. - -Security Considerations - - Security issues are not addressed in this memo. - -Author's Address - - Bill Manning - Rice University - ONCS - PO Box 1892 - 6100 South Main - Houston, Texas 77251-1892 - - Phone: +1.713.285.5415 - EMail: bmanning@rice.edu - - - - - - - - - - - - - - - - - - - - - - -Manning [Page 4] -
\ No newline at end of file diff --git a/contrib/bind9/doc/rfc/rfc1535.txt b/contrib/bind9/doc/rfc/rfc1535.txt deleted file mode 100644 index 03bddeebedcb..000000000000 --- a/contrib/bind9/doc/rfc/rfc1535.txt +++ /dev/null @@ -1,283 +0,0 @@ - - - - - - -Network Working Group E. Gavron -Request for Comments: 1535 ACES Research Inc. -Category: Informational October 1993 - - - A Security Problem and Proposed Correction - With Widely Deployed DNS Software - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard. Distribution of this memo is - unlimited. - -Abstract - - This document discusses a flaw in some of the currently distributed - name resolver clients. The flaw exposes a security weakness related - to the search heuristic invoked by these same resolvers when users - provide a partial domain name, and which is easy to exploit (although - not by the masses). This document points out the flaw, a case in - point, and a solution. - -Background - - Current Domain Name Server clients are designed to ease the burden of - remembering IP dotted quad addresses. As such they translate human- - readable names into addresses and other resource records. Part of - the translation process includes understanding and dealing with - hostnames that are not fully qualified domain names (FQDNs). - - An absolute "rooted" FQDN is of the format {name}{.} A non "rooted" - domain name is of the format {name} - - A domain name may have many parts and typically these include the - host, domain, and type. Example: foobar.company.com or - fooschool.university.edu. - -Flaw - - The problem with most widely distributed resolvers based on the BSD - BIND resolver is that they attempt to resolve a partial name by - processing a search list of partial domains to be added to portions - of the specified host name until a DNS record is found. This - "feature" is disabled by default in the official BIND 4.9.2 release. - - Example: A TELNET attempt by User@Machine.Tech.ACES.COM - to UnivHost.University.EDU - - - -Gavron [Page 1] - -RFC 1535 DNS Software Enhancements October 1993 - - - The resolver client will realize that since "UnivHost.University.EDU" - does not end with a ".", it is not an absolute "rooted" FQDN. It - will then try the following combinations until a resource record is - found: - - UnivHost.University.EDU.Tech.ACES.COM. - UnivHost.University.EDU.ACES.COM. - UnivHost.University.EDU.COM. - UnivHost.University.EDU. - -Security Issue - - After registering the EDU.COM domain, it was discovered that an - unliberal application of one wildcard CNAME record would cause *all* - connects from any .COM site to any .EDU site to terminate at one - target machine in the private edu.com sub-domain. - - Further, discussion reveals that specific hostnames registered in - this private subdomain, or any similarly named subdomain may be used - to spoof a host. - - Example: harvard.edu.com. CNAME targethost - - Thus all connects to Harvard.edu from all .com sites would end up at - targthost, a machine which could provide a Harvard.edu login banner. - - This is clearly unacceptable. Further, it could only be made worse - with domains like COM.EDU, MIL.GOV, GOV.COM, etc. - -Public vs. Local Name Space Administration - - The specification of the Domain Name System and the software that - implements it provides an undifferentiated hierarchy which permits - delegation of administration for subordinate portions of the name - space. Actual administration of the name space is divided between - "public" and "local" portions. Public administration pertains to all - top-level domains, such as .COM and .EDU. For some domains, it also - pertains to some number of sub-domain levels. The multi-level nature - of the public administration is most evident for top-level domains - for countries. For example in the Fully Qualified Domain Name, - dbc.mtview.ca.us., the portion "mtview.ca.us" represents three levels - of public administration. Only the left-most portion is subject to - local administration. - - - - - - - - -Gavron [Page 2] - -RFC 1535 DNS Software Enhancements October 1993 - - - The danger of the heuristic search common in current practise is that - it it is possible to "intercept" the search by matching against an - unintended value while walking up the search list. While this is - potentially dangerous at any level, it is entirely unacceptable when - the error impacts users outside of a local administration. - - When attempting to resolve a partial domain name, DNS resolvers use - the Domain Name of the searching host for deriving the search list. - Existing DNS resolvers do not distinguish the portion of that name - which is in the locally administered scope from the part that is - publically administered. - -Solution(s) - - At a minimum, DNS resolvers must honor the BOUNDARY between local and - public administration, by limiting any search lists to locally- - administered portions of the Domain Name space. This requires a - parameter which shows the scope of the name space controlled by the - local administrator. - - This would permit progressive searches from the most qualified to - less qualified up through the locally controlled domain, but not - beyond. - - For example, if the local user were trying to reach: - - User@chief.admin.DESERTU.EDU from - starburst,astro.DESERTU.EDU, - - it is reasonable to permit the user to enter just chief.admin, and - for the search to cover: - - chief.admin.astro.DESERTU.EDU - chief.admin.DESERTU.EDU - - but not - - chief.admin.EDU - - In this case, the value of "search" should be set to "DESERTU.EDU" - because that's the scope of the name space controlled by the local - DNS administrator. - - This is more than a mere optimization hack. The local administrator - has control over the assignment of names within the locally - administered domain, so the administrator can make sure that - abbreviations result in the right thing. Outside of the local - control, users are necessarily at risk. - - - -Gavron [Page 3] - -RFC 1535 DNS Software Enhancements October 1993 - - - A more stringent mechanism is implemented in BIND 4.9.2, to respond - to this problem: - - The DNS Name resolver clients narrows its IMPLICIT search list IF ANY - to only try the first and the last of the examples shown. - - Any additional search alternatives must be configured into the - resolver EXPLICITLY. - - DNS Name resolver software SHOULD NOT use implicit search lists in - attempts to resolve partial names into absolute FQDNs other than the - hosts's immediate parent domain. - - Resolvers which continue to use implicit search lists MUST limit - their scope to locally administered sub-domains. - - DNS Name resolver software SHOULD NOT come pre-configured with - explicit search lists that perpetuate this problem. - - Further, in any event where a "." exists in a specified name it - should be assumed to be a fully qualified domain name (FQDN) and - SHOULD be tried as a rooted name first. - - Example: Given user@a.b.c.d connecting to e.f.g.h only two tries - should be attempted as a result of using an implicit - search list: - - e.f.g.h. and e.f.g.h.b.c.d. - - Given user@a.b.c.d. connecting to host those same two - tries would appear as: - - x.b.c.d. and x. - - Some organizations make regular use of multi-part, partially - qualified Domain Names. For example, host foo.loc1.org.city.state.us - might be used to making references to bar.loc2, or mumble.loc3, all - of which refer to whatever.locN.org.city.state.us - - The stringent implicit search rules for BIND 4.9.2 will now cause - these searches to fail. To return the ability for them to succeed, - configuration of the client resolvers must be changed to include an - explicit search rule for org.city.state.us. That is, it must contain - an explicit rule for any -- and each -- portion of the locally- - administered sub-domain that it wishes to have as part of the search - list. - - - - - -Gavron [Page 4] - -RFC 1535 DNS Software Enhancements October 1993 - - -References - - [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13, - RFC 1034, USC/Information Sciences Institute, November 1987. - - [2] Mockapetris, P., "Domain Names Implementation and Specification", - STD 13, RFC 1035, USC/Information Sciences Institute, November - 1987. - - [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC - 974, CSNET CIC BBN, January 1986. - - [4] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller, - "Common DNS Implementation Errors and Suggested Fixes", RFC 1536, - USC/Information Sciences Institute, USC, October 1993. - - [5] Beertema, P., "Common DNS Data File Configuration Errors", RFC - 1537, CWI, October 1993. - -Security Considerations - - This memo indicates vulnerabilities with all too-forgiving DNS - clients. It points out a correction that would eliminate the future - potential of the problem. - -Author's Address - - Ehud Gavron - ACES Research Inc. - PO Box 14546 - Tucson, AZ 85711 - - Phone: (602) 743-9841 - EMail: gavron@aces.com - - - - - - - - - - - - - - - - - -Gavron [Page 5] - diff --git a/contrib/bind9/doc/rfc/rfc1536.txt b/contrib/bind9/doc/rfc/rfc1536.txt deleted file mode 100644 index 5ff2b25d0370..000000000000 --- a/contrib/bind9/doc/rfc/rfc1536.txt +++ /dev/null @@ -1,675 +0,0 @@ - - - - - - -Network Working Group A. Kumar -Request for Comments: 1536 J. Postel -Category: Informational C. Neuman - ISI - P. Danzig - S. Miller - USC - October 1993 - - - Common DNS Implementation Errors and Suggested Fixes - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard. Distribution of this memo is - unlimited. - -Abstract - - This memo describes common errors seen in DNS implementations and - suggests some fixes. Where applicable, violations of recommendations - from STD 13, RFC 1034 and STD 13, RFC 1035 are mentioned. The memo - also describes, where relevant, the algorithms followed in BIND - (versions 4.8.3 and 4.9 which the authors referred to) to serve as an - example. - -Introduction - - The last few years have seen, virtually, an explosion of DNS traffic - on the NSFnet backbone. Various DNS implementations and various - versions of these implementations interact with each other, producing - huge amounts of unnecessary traffic. Attempts are being made by - researchers all over the internet, to document the nature of these - interactions, the symptomatic traffic patterns and to devise remedies - for the sick pieces of software. - - This draft is an attempt to document fixes for known DNS problems so - people know what problems to watch out for and how to repair broken - software. - -1. Fast Retransmissions - - DNS implements the classic request-response scheme of client-server - interaction. UDP is, therefore, the chosen protocol for communication - though TCP is used for zone transfers. The onus of requerying in case - no response is seen in a "reasonable" period of time, lies with the - client. Although RFC 1034 and 1035 do not recommend any - - - -Kumar, Postel, Neuman, Danzig & Miller [Page 1] - -RFC 1536 Common DNS Implementation Errors October 1993 - - - retransmission policy, RFC 1035 does recommend that the resolvers - should cycle through a list of servers. Both name servers and stub - resolvers should, therefore, implement some kind of a retransmission - policy based on round trip time estimates of the name servers. The - client should back-off exponentially, probably to a maximum timeout - value. - - However, clients might not implement either of the two. They might - not wait a sufficient amount of time before retransmitting or they - might not back-off their inter-query times sufficiently. - - Thus, what the server would see will be a series of queries from the - same querying entity, spaced very close together. Of course, a - correctly implemented server discards all duplicate queries but the - queries contribute to wide-area traffic, nevertheless. - - We classify a retransmission of a query as a pure Fast retry timeout - problem when a series of query packets meet the following conditions. - - a. Query packets are seen within a time less than a "reasonable - waiting period" of each other. - - b. No response to the original query was seen i.e., we see two or - more queries, back to back. - - c. The query packets share the same query identifier. - - d. The server eventually responds to the query. - -A GOOD IMPLEMENTATION: - - BIND (we looked at versions 4.8.3 and 4.9) implements a good - retransmission algorithm which solves or limits all of these - problems. The Berkeley stub-resolver queries servers at an interval - that starts at the greater of 4 seconds and 5 seconds divided by the - number of servers the resolver queries. The resolver cycles through - servers and at the end of a cycle, backs off the time out - exponentially. - - The Berkeley full-service resolver (built in with the program - "named") starts with a time-out equal to the greater of 4 seconds and - two times the round-trip time estimate of the server. The time-out - is backed off with each cycle, exponentially, to a ceiling value of - 45 seconds. - - - - - - - -Kumar, Postel, Neuman, Danzig & Miller [Page 2] - -RFC 1536 Common DNS Implementation Errors October 1993 - - -FIXES: - - a. Estimate round-trip times or set a reasonably high initial - time-out. - - b. Back-off timeout periods exponentially. - - c. Yet another fundamental though difficult fix is to send the - client an acknowledgement of a query, with a round-trip time - estimate. - - Since UDP is used, no response is expected by the client until the - query is complete. Thus, it is less likely to have information about - previous packets on which to estimate its back-off time. Unless, you - maintain state across queries, so subsequent queries to the same - server use information from previous queries. Unfortunately, such - estimates are likely to be inaccurate for chained requests since the - variance is likely to be high. - - The fix chosen in the ARDP library used by Prospero is that the - server will send an initial acknowledgement to the client in those - cases where the server expects the query to take a long time (as - might be the case for chained queries). This initial acknowledgement - can include an expected time to wait before retrying. - - This fix is more difficult since it requires that the client software - also be trained to expect the acknowledgement packet. This, in an - internet of millions of hosts is at best a hard problem. - -2. Recursion Bugs - - When a server receives a client request, it first looks up its zone - data and the cache to check if the query can be answered. If the - answer is unavailable in either place, the server seeks names of - servers that are more likely to have the information, in its cache or - zone data. It then does one of two things. If the client desires the - server to recurse and the server architecture allows recursion, the - server chains this request to these known servers closest to the - queried name. If the client doesn't seek recursion or if the server - cannot handle recursion, it returns the list of name servers to the - client assuming the client knows what to do with these records. - - The client queries this new list of name servers to get either the - answer, or names of another set of name servers to query. This - process repeats until the client is satisfied. Servers might also go - through this chaining process if the server returns a CNAME record - for the queried name. Some servers reprocess this name to try and get - the desired record type. - - - -Kumar, Postel, Neuman, Danzig & Miller [Page 3] - -RFC 1536 Common DNS Implementation Errors October 1993 - - - However, in certain cases, this chain of events may not be good. For - example, a broken or malicious name server might list itself as one - of the name servers to query again. The unsuspecting client resends - the same query to the same server. - - In another situation, more difficult to detect, a set of servers - might form a loop wherein A refers to B and B refers to A. This loop - might involve more than two servers. - - Yet another error is where the client does not know how to process - the list of name servers returned, and requeries the same server - since that is one (of the few) servers it knows. - - We, therefore, classify recursion bugs into three distinct - categories: - - a. Ignored referral: Client did not know how to handle NS records - in the AUTHORITY section. - - b. Too many referrals: Client called on a server too many times, - beyond a "reasonable" number, with same query. This is - different from a Fast retransmission problem and a Server - Failure detection problem in that a response is seen for every - query. Also, the identifiers are always different. It implies - client is in a loop and should have detected that and broken - it. (RFC 1035 mentions that client should not recurse beyond - a certain depth.) - - c. Malicious Server: a server refers to itself in the authority - section. If a server does not have an answer now, it is very - unlikely it will be any better the next time you query it, - specially when it claims to be authoritative over a domain. - - RFC 1034 warns against such situations, on page 35. - - "Bound the amount of work (packets sent, parallel processes - started) so that a request can't get into an infinite loop or - start off a chain reaction of requests or queries with other - implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED - SOME DATA." - -A GOOD IMPLEMENTATION: - - BIND fixes at least one of these problems. It places an upper limit - on the number of recursive queries it will make, to answer a - question. It chases a maximum of 20 referral links and 8 canonical - name translations. - - - - -Kumar, Postel, Neuman, Danzig & Miller [Page 4] - -RFC 1536 Common DNS Implementation Errors October 1993 - - -FIXES: - - a. Set an upper limit on the number of referral links and CNAME - links you are willing to chase. - - Note that this is not guaranteed to break only recursion loops. - It could, in a rare case, prune off a very long search path, - prematurely. We know, however, with high probability, that if - the number of links cross a certain metric (two times the depth - of the DNS tree), it is a recursion problem. - - b. Watch out for self-referring servers. Avoid them whenever - possible. - - c. Make sure you never pass off an authority NS record with your - own name on it! - - d. Fix clients to accept iterative answers from servers not built - to provide recursion. Such clients should either be happy with - the non-authoritative answer or be willing to chase the - referral links themselves. - -3. Zero Answer Bugs: - - Name servers sometimes return an authoritative NOERROR with no - ANSWER, AUTHORITY or ADDITIONAL records. This happens when the - queried name is valid but it does not have a record of the desired - type. Of course, the server has authority over the domain. - - However, once again, some implementations of resolvers do not - interpret this kind of a response reasonably. They always expect an - answer record when they see an authoritative NOERROR. These entities - continue to resend their queries, possibly endlessly. - -A GOOD IMPLEMENTATION - - BIND resolver code does not query a server more than 3 times. If it - is unable to get an answer from 4 servers, querying them three times - each, it returns error. - - Of course, it treats a zero-answer response the way it should be - treated; with respect! - -FIXES: - - a. Set an upper limit on the number of retransmissions for a given - query, at the very least. - - - - -Kumar, Postel, Neuman, Danzig & Miller [Page 5] - -RFC 1536 Common DNS Implementation Errors October 1993 - - - b. Fix resolvers to interpret such a response as an authoritative - statement of non-existence of the record type for the given - name. - -4. Inability to detect server failure: - - Servers in the internet are not very reliable (they go down every - once in a while) and resolvers are expected to adapt to the changed - scenario by not querying the server for a while. Thus, when a server - does not respond to a query, resolvers should try another server. - Also, non-stub resolvers should update their round trip time estimate - for the server to a large value so that server is not tried again - before other, faster servers. - - Stub resolvers, however, cycle through a fixed set of servers and if, - unfortunately, a server is down while others do not respond for other - reasons (high load, recursive resolution of query is taking more time - than the resolver's time-out, ....), the resolver queries the dead - server again! In fact, some resolvers might not set an upper limit on - the number of query retransmissions they will send and continue to - query dead servers indefinitely. - - Name servers running system or chained queries might also suffer from - the same problem. They store names of servers they should query for a - given domain. They cycle through these names and in case none of them - answers, hit each one more than one. It is, once again, important - that there be an upper limit on the number of retransmissions, to - prevent network overload. - - This behavior is clearly in violation of the dictum in RFC 1035 (page - 46) - - "If a resolver gets a server error or other bizarre response - from a name server, it should remove it from SLIST, and may - wish to schedule an immediate transmission to the next - candidate server address." - - Removal from SLIST implies that the server is not queried again for - some time. - - Correctly implemented full-service resolvers should, as pointed out - before, update round trip time values for servers that do not respond - and query them only after other, good servers. Full-service resolvers - might, however, not follow any of these common sense directives. They - query dead servers, and they query them endlessly. - - - - - - -Kumar, Postel, Neuman, Danzig & Miller [Page 6] - -RFC 1536 Common DNS Implementation Errors October 1993 - - -A GOOD IMPLEMENTATION: - - BIND places an upper limit on the number of times it queries a - server. Both the stub-resolver and the full-service resolver code do - this. Also, since the full-service resolver estimates round-trip - times and sorts name server addresses by these estimates, it does not - query a dead server again, until and unless all the other servers in - the list are dead too! Further, BIND implements exponential back-off - too. - -FIXES: - - a. Set an upper limit on number of retransmissions. - - b. Measure round-trip time from servers (some estimate is better - than none). Treat no response as a "very large" round-trip - time. - - c. Maintain a weighted rtt estimate and decay the "large" value - slowly, with time, so that the server is eventually tested - again, but not after an indefinitely long period. - - d. Follow an exponential back-off scheme so that even if you do - not restrict the number of queries, you do not overload the - net excessively. - -5. Cache Leaks: - - Every resource record returned by a server is cached for TTL seconds, - where the TTL value is returned with the RR. Full-service (or stub) - resolvers cache the RR and answer any queries based on this cached - information, in the future, until the TTL expires. After that, one - more query to the wide-area network gets the RR in cache again. - - Full-service resolvers might not implement this caching mechanism - well. They might impose a limit on the cache size or might not - interpret the TTL value correctly. In either case, queries repeated - within a TTL period of a RR constitute a cache leak. - -A GOOD/BAD IMPLEMENTATION: - - BIND has no restriction on the cache size and the size is governed by - the limits on the virtual address space of the machine it is running - on. BIND caches RRs for the duration of the TTL returned with each - record. - - It does, however, not follow the RFCs with respect to interpretation - of a 0 TTL value. If a record has a TTL value of 0 seconds, BIND uses - - - -Kumar, Postel, Neuman, Danzig & Miller [Page 7] - -RFC 1536 Common DNS Implementation Errors October 1993 - - - the minimum TTL value, for that zone, from the SOA record and caches - it for that duration. This, though it saves some traffic on the - wide-area network, is not correct behavior. - -FIXES: - - a. Look over your caching mechanism to ensure TTLs are interpreted - correctly. - - b. Do not restrict cache sizes (come on, memory is cheap!). - Expired entries are reclaimed periodically, anyway. Of course, - the cache size is bound to have some physical limit. But, when - possible, this limit should be large (run your name server on - a machine with a large amount of physical memory). - - c. Possibly, a mechanism is needed to flush the cache, when it is - known or even suspected that the information has changed. - -6. Name Error Bugs: - - This bug is very similar to the Zero Answer bug. A server returns an - authoritative NXDOMAIN when the queried name is known to be bad, by - the server authoritative for the domain, in the absence of negative - caching. This authoritative NXDOMAIN response is usually accompanied - by the SOA record for the domain, in the authority section. - - Resolvers should recognize that the name they queried for was a bad - name and should stop querying further. - - Some resolvers might, however, not interpret this correctly and - continue to query servers, expecting an answer record. - - Some applications, in fact, prompt NXDOMAIN answers! When given a - perfectly good name to resolve, they append the local domain to it - e.g., an application in the domain "foo.bar.com", when trying to - resolve the name "usc.edu" first tries "usc.edu.foo.bar.com", then - "usc.edu.bar.com" and finally the good name "usc.edu". This causes at - least two queries that return NXDOMAIN, for every good query. The - problem is aggravated since the negative answers from the previous - queries are not cached. When the same name is sought again, the - process repeats. - - Some DNS resolver implementations suffer from this problem, too. They - append successive sub-parts of the local domain using an implicit - searchlist mechanism, when certain conditions are satisfied and try - the original name, only when this first set of iterations fails. This - behavior recently caused pandemonium in the Internet when the domain - "edu.com" was registered and a wildcard "CNAME" record placed at the - - - -Kumar, Postel, Neuman, Danzig & Miller [Page 8] - -RFC 1536 Common DNS Implementation Errors October 1993 - - - top level. All machines from "com" domains trying to connect to hosts - in the "edu" domain ended up with connections to the local machine in - the "edu.com" domain! - -GOOD/BAD IMPLEMENTATIONS: - - Some local versions of BIND already implement negative caching. They - typically cache negative answers with a very small TTL, sufficient to - answer a burst of queries spaced close together, as is typically - seen. - - The next official public release of BIND (4.9.2) will have negative - caching as an ifdef'd feature. - - The BIND resolver appends local domain to the given name, when one of - two conditions is met: - - i. The name has no periods and the flag RES_DEFNAME is set. - ii. There is no trailing period and the flag RES_DNSRCH is set. - - The flags RES_DEFNAME and RES_DNSRCH are default resolver options, in - BIND, but can be changed at compile time. - - Only if the name, so generated, returns an NXDOMAIN is the original - name tried as a Fully Qualified Domain Name. And only if it contains - at least one period. - -FIXES: - - a. Fix the resolver code. - - b. Negative Caching. Negative caching servers will restrict the - traffic seen on the wide-area network, even if not curb it - altogether. - - c. Applications and resolvers should not append the local domain to - names they seek to resolve, as far as possible. Names - interspersed with periods should be treated as Fully Qualified - Domain Names. - - In other words, Use searchlists only when explicitly specified. - No implicit searchlists should be used. A name that contains - any dots should first be tried as a FQDN and if that fails, with - the local domain name (or searchlist if specified) appended. A - name containing no dots can be appended with the searchlist right - away, but once again, no implicit searchlists should be used. - - - - - -Kumar, Postel, Neuman, Danzig & Miller [Page 9] - -RFC 1536 Common DNS Implementation Errors October 1993 - - - Associated with the name error bug is another problem where a server - might return an authoritative NXDOMAIN, although the name is valid. A - secondary server, on start-up, reads the zone information from the - primary, through a zone transfer. While it is in the process of - loading the zones, it does not have information about them, although - it is authoritative for them. Thus, any query for a name in that - domain is answered with an NXDOMAIN response code. This problem might - not be disastrous were it not for negative caching servers that cache - this answer and so propagate incorrect information over the internet. - -BAD IMPLEMENTATION: - - BIND apparently suffers from this problem. - - Also, a new name added to the primary database will take a while to - propagate to the secondaries. Until that time, they will return - NXDOMAIN answers for a good name. Negative caching servers store this - answer, too and aggravate this problem further. This is probably a - more general DNS problem but is apparently more harmful in this - situation. - -FIX: - - a. Servers should start answering only after loading all the zone - data. A failed server is better than a server handing out - incorrect information. - - b. Negative cache records for a very small time, sufficient only - to ward off a burst of requests for the same bad name. This - could be related to the round-trip time of the server from - which the negative answer was received. Alternatively, a - statistical measure of the amount of time for which queries - for such names are received could be used. Minimum TTL value - from the SOA record is not advisable since they tend to be - pretty large. - - c. A "PUSH" (or, at least, a "NOTIFY") mechanism should be allowed - and implemented, to allow the primary server to inform - secondaries that the database has been modified since it last - transferred zone data. To alleviate the problem of "too many - zone transfers" that this might cause, Incremental Zone - Transfers should also be part of DNS. Also, the primary should - not NOTIFY/PUSH with every update but bunch a good number - together. - - - - - - - -Kumar, Postel, Neuman, Danzig & Miller [Page 10] - -RFC 1536 Common DNS Implementation Errors October 1993 - - -7. Format Errors: - - Some resolvers issue query packets that do not necessarily conform to - standards as laid out in the relevant RFCs. This unnecessarily - increases net traffic and wastes server time. - -FIXES: - - a. Fix resolvers. - - b. Each resolver verify format of packets before sending them out, - using a mechanism outside of the resolver. This is, obviously, - needed only if step 1 cannot be followed. - -References - - [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13, - RFC 1034, USC/Information Sciences Institute, November 1987. - - [2] Mockapetris, P., "Domain Names Implementation and Specification", - STD 13, RFC 1035, USC/Information Sciences Institute, November - 1987. - - [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC - 974, CSNET CIC BBN, January 1986. - - [4] Gavron, E., "A Security Problem and Proposed Correction With - Widely Deployed DNS Software", RFC 1535, ACES Research Inc., - October 1993. - - [5] Beertema, P., "Common DNS Data File Configuration Errors", RFC - 1537, CWI, October 1993. - -Security Considerations - - Security issues are not discussed in this memo. - - - - - - - - - - - - - - - -Kumar, Postel, Neuman, Danzig & Miller [Page 11] - -RFC 1536 Common DNS Implementation Errors October 1993 - - -Authors' Addresses - - Anant Kumar - USC Information Sciences Institute - 4676 Admiralty Way - Marina Del Rey CA 90292-6695 - - Phone:(310) 822-1511 - FAX: (310) 823-6741 - EMail: anant@isi.edu - - - Jon Postel - USC Information Sciences Institute - 4676 Admiralty Way - Marina Del Rey CA 90292-6695 - - Phone:(310) 822-1511 - FAX: (310) 823-6714 - EMail: postel@isi.edu - - - Cliff Neuman - USC Information Sciences Institute - 4676 Admiralty Way - Marina Del Rey CA 90292-6695 - - Phone:(310) 822-1511 - FAX: (310) 823-6714 - EMail: bcn@isi.edu - - - Peter Danzig - Computer Science Department - University of Southern California - University Park - - EMail: danzig@caldera.usc.edu - - - Steve Miller - Computer Science Department - University of Southern California - University Park - Los Angeles CA 90089 - - EMail: smiller@caldera.usc.edu - - - - -Kumar, Postel, Neuman, Danzig & Miller [Page 12] - diff --git a/contrib/bind9/doc/rfc/rfc1537.txt b/contrib/bind9/doc/rfc/rfc1537.txt deleted file mode 100644 index 81b97683156b..000000000000 --- a/contrib/bind9/doc/rfc/rfc1537.txt +++ /dev/null @@ -1,507 +0,0 @@ - - - - - - -Network Working Group P. Beertema -Request for Comments: 1537 CWI -Category: Informational October 1993 - - - Common DNS Data File Configuration Errors - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard. Distribution of this memo is - unlimited. - -Abstract - - This memo describes errors often found in DNS data files. It points - out common mistakes system administrators tend to make and why they - often go unnoticed for long periods of time. - -Introduction - - Due to the lack of extensive documentation and automated tools, DNS - zone files have mostly been configured by system administrators, by - hand. Some of the rules for writing the data files are rather subtle - and a few common mistakes are seen in domains worldwide. - - This document is an attempt to list "surprises" that administrators - might find hidden in their zone files. It describes the symptoms of - the malady and prescribes medicine to cure that. It also gives some - general recommendations and advice on specific nameserver and zone - file issues and on the (proper) use of the Domain Name System. - -1. SOA records - - A problem I've found in quite some nameservers is that the various - timers have been set (far) too low. Especially for top level domain - nameservers this causes unnecessary traffic over international and - intercontinental links. - - Unfortunately the examples given in the BIND manual, in RFC's and in - some expert documents give those very short timer values, and that's - most likely what people have modeled their SOA records after. - - First of all a short explanation of the timers used in the SOA - record: - - - - - - -Beertema [Page 1] - -RFC 1537 Common DNS Data File Configuration Errors October 1993 - - - - Refresh: The SOA record of the primary server is checked - every "refresh" time by the secondary servers; - if it has changed, a zone transfer is done. - - - Retry: If a secondary server cannot reach the primary - server, it tries it again every "retry" time. - - - Expire: If for "expire" time the primary server cannot - be reached, all information about the zone is - invalidated on the secondary servers (i.e., they - are no longer authoritative for that zone). - - - Minimum TTL: The default TTL value for all records in the - zone file; a different TTL value may be given - explicitly in a record when necessary. - (This timer is named "Minimum", and that's - what it's function should be according to - STD 13, RFC 1035, but most (all?) - implementations take it as the default value - exported with records without an explicit TTL - value). - - For top level domain servers I would recommend the following values: - - 86400 ; Refresh 24 hours - 7200 ; Retry 2 hours - 2592000 ; Expire 30 days - 345600 ; Minimum TTL 4 days - - For other servers I would suggest: - - 28800 ; Refresh 8 hours - 7200 ; Retry 2 hours - 604800 ; Expire 7 days - 86400 ; Minimum TTL 1 day - - but here the frequency of changes, the required speed of propagation, - the reachability of the primary server etc. play a role in optimizing - the timer values. - -2. Glue records - - Quite often, people put unnecessary glue (A) records in their zone - files. Even worse is that I've even seen *wrong* glue records for an - external host in a primary zone file! Glue records need only be in a - zone file if the server host is within the zone and there is no A - record for that host elsewhere in the zone file. - - - - -Beertema [Page 2] - -RFC 1537 Common DNS Data File Configuration Errors October 1993 - - - Old BIND versions ("native" 4.8.3 and older versions) showed the - problem that wrong glue records could enter secondary servers in a - zone transfer. - -3. "Secondary server surprise" - - I've seen it happen on various occasions that hosts got bombarded by - nameserver requests without knowing why. On investigation it turned - out then that such a host was supposed to (i.e., the information was - in the root servers) run secondary for some domain (or reverse (in- - addr.arpa)) domain, without that host's nameserver manager having - been asked or even been told so! - - Newer BIND versions (4.9 and later) solved this problem. At the same - time though the fix has the disadvantage that it's far less easy to - spot this problem. - - Practice has shown that most domain registrars accept registrations - of nameservers without checking if primary (!) and secondary servers - have been set up, informed, or even asked. It should also be noted - that a combination of long-lasting unreachability of primary - nameservers, (therefore) expiration of zone information, plus static - IP routing, can lead to massive network traffic that can fill up - lines completely. - -4. "MX records surprise" - - In a sense similar to point 3. Sometimes nameserver managers enter MX - records in their zone files that point to external hosts, without - first asking or even informing the systems managers of those external - hosts. This has to be fought out between the nameserver manager and - the systems managers involved. Only as a last resort, if really - nothing helps to get the offending records removed, can the systems - manager turn to the naming authority of the domain above the - offending domain to get the problem sorted out. - -5. "Name extension surprise" - - Sometimes one encounters weird names, which appear to be an external - name extended with a local domain. This is caused by forgetting to - terminate a name with a dot: names in zone files that don't end with - a dot are always expanded with the name of the current zone (the - domain that the zone file stands for or the last $ORIGIN). - - Example: zone file for foo.xx: - - pqr MX 100 relay.yy. - xyz MX 100 relay.yy (no trailing dot!) - - - -Beertema [Page 3] - -RFC 1537 Common DNS Data File Configuration Errors October 1993 - - - When fully written out this stands for: - - pqr.foo.xx. MX 100 relay.yy. - xyz.foo.xx. MX 100 relay.yy.foo.xx. (name extension!) - -6. Missing secondary servers - - It is required that there be a least 2 nameservers for a domain. For - obvious reasons the nameservers for top level domains need to be very - well reachable from all over the Internet. This implies that there - must be more than just 2 of them; besides, most of the (secondary) - servers should be placed at "strategic" locations, e.g., close to a - point where international and/or intercontinental lines come - together. To keep things manageable, there shouldn't be too many - servers for a domain either. - - Important aspects in selecting the location of primary and secondary - servers are reliability (network, host) and expedient contacts: in - case of problems, changes/fixes must be carried out quickly. It - should be considered logical that primary servers for European top - level domains should run on a host in Europe, preferably (if - possible) in the country itself. For each top level domain there - should be 2 secondary servers in Europe and 2 in the USA, but there - may of course be more on either side. An excessive number of - nameservers is not a good idea though; a recommended maximum is 7 - nameservers. In Europe, EUnet has offered to run secondary server - for each European top level domain. - -7. Wildcard MX records - - Wildcard MX records should be avoided where possible. They often - cause confusion and errors: especially beginning nameserver managers - tend to overlook the fact that a host/domain listed with ANY type of - record in a zone file is NOT covered by an overall wildcard MX record - in that zone; this goes not only for simple domain/host names, but - also for names that cover one or more domains. Take the following - example in zone foo.bar: - - * MX 100 mailhost - pqr MX 100 mailhost - abc.def MX 100 mailhost - - This makes pqr.foo.bar, def.foo.bar and abd.def.foo.bar valid - domains, but the wildcard MX record covers NONE of them, nor anything - below them. To cover everything by MX records, the required entries - are: - - - - - -Beertema [Page 4] - -RFC 1537 Common DNS Data File Configuration Errors October 1993 - - - * MX 100 mailhost - pqr MX 100 mailhost - *.pqr MX 100 mailhost - abc.def MX 100 mailhost - *.def MX 100 mailhost - *.abc.def MX 100 mailhost - - An overall wildcard MX record is almost never useful. - - In particular the zone file of a top level domain should NEVER - contain only an overall wildcard MX record (*.XX). The effect of such - a wildcard MX record can be that mail is unnecessarily sent across - possibly expensive links, only to fail at the destination or gateway - that the record points to. Top level domain zone files should - explicitly list at least all the officially registered primary - subdomains. - - Whereas overall wildcard MX records should be avoided, wildcard MX - records are acceptable as an explicit part of subdomain entries, - provided they are allowed under a given subdomain (to be determined - by the naming authority for that domain). - - Example: - - foo.xx. MX 100 gateway.xx. - MX 200 fallback.yy. - *.foo.xx. MX 100 gateway.xx. - MX 200 fallback.yy. -8. Hostnames - - People appear to sometimes look only at STD 11, RFC 822 to determine - whether a particular hostname is correct or not. Hostnames should - strictly conform to the syntax given in STD 13, RFC 1034 (page 11), - with *addresses* in addition conforming to RFC 822. As an example - take "c&w.blues" which is perfectly legal according to RFC 822, but - which can have quite surprising effects on particular systems, e.g., - "telnet c&w.blues" on a Unix system. - -9. HINFO records - - There appears to be a common misunderstanding that one of the data - fields (usually the second field) in HINFO records is optional. A - recent scan of all reachable nameservers in only one country revealed - some 300 incomplete HINFO records. Specifying two data fields in a - HINFO record is mandatory (RFC 1033), but note that this does *not* - mean that HINFO records themselves are mandatory. - - - - - -Beertema [Page 5] - -RFC 1537 Common DNS Data File Configuration Errors October 1993 - - -10. Safety measures and specialties - - Nameservers and resolvers aren't flawless. Bogus queries should be - kept from being forwarded to the root servers, since they'll only - lead to unnecessary intercontinental traffic. Known bogus queries - that can easily be dealt with locally are queries for 0 and broadcast - addresses. To catch such queries, every nameserver should run - primary for the 0.in-addr.arpa and 255.in-addr.arpa zones; the zone - files need only contain a SOA and an NS record. - - Also each nameserver should run primary for 0.0.127.in-addr.arpa; - that zone file should contain a SOA and NS record and an entry: - - 1 PTR localhost. - - There has been extensive discussion about whether or not to append - the local domain to it. The conclusion was that "localhost." would be - the best solution; reasons given were: - - - "localhost" itself is used and expected to work on some systems. - - - translating 127.0.0.1 into "localhost.my_domain" can cause some - software to connect to itself using the loopback interface when - it didn't want to. - - Note that all domains that contain hosts should have a "localhost" A - record in them. - - People maintaining zone files with the Serial number given in dotted - decimal notation (e.g., when SCCS is used to maintain the files) - should beware of a bug in all BIND versions: if the serial number is - in Release.Version (dotted decimal) notation, then it is virtually - impossible to change to a higher release: because of the wrong way - that notation is turned into an integer, it results in a serial - number that is LOWER than that of the former release. - - For this reason and because the Serial is an (unsigned) integer - according to STD 13, RFC 1035, it is recommended not to use the - dotted decimal notation. A recommended notation is to use the date - (yyyymmdd), if necessary with an extra digit (yyyymmddn) if there is - or can be more than one change per day in a zone file. - - Very old versions of DNS resolver code have a bug that causes queries - for A records with domain names like "192.16.184.3" to go out. This - happens when users type in IP addresses and the resolver code does - not catch this case before sending out a DNS query. This problem has - been fixed in all resolver implementations known to us but if it - still pops up it is very serious because all those queries will go to - - - -Beertema [Page 6] - -RFC 1537 Common DNS Data File Configuration Errors October 1993 - - - the root servers looking for top level domains like "3" etc. It is - strongly recommended to install the latest (publicly) available BIND - version plus all available patches to get rid of these and other - problems. - - Running secondary nameserver off another secondary nameserver is - possible, but not recommended unless really necessary: there are - known cases where it has led to problems like bogus TTL values. This - can be caused by older or flawed implementations, but secondary - nameservers in principle should always transfer their zones from the - official primary nameserver. - -11. Some general points - - The Domain Name System and nameserver are purely technical tools, not - meant in any way to exert control or impose politics. The function of - a naming authority is that of a clearing house. Anyone registering a - subdomain under a particular (top level) domain becomes naming - authority and therewith the sole responsible for that subdomain. - Requests to enter MX or NS records concerning such a subdomain - therefore always MUST be honored by the registrar of the next higher - domain. - - Examples of practices that are not allowed are: - - - imposing specific mail routing (MX records) when registering - a subdomain. - - - making registration of a subdomain dependent on to the use of - certain networks or services. - - - using TXT records as a means of (free) commercial advertising. - - In the latter case a network service provider could decide to cut off - a particular site until the offending TXT records have been removed - from the site's zone file. - - Of course there are obvious cases where a naming authority can refuse - to register a particular subdomain and can require a proposed name to - be changed in order to get it registered (think of DEC trying to - register a domain IBM.XX). - - There are also cases were one has to probe the authority of the - person: sending in the application - not every systems manager should - be able to register a domain name for a whole university. The naming - authority can impose certain extra rules as long as they don't - violate or conflict with the rights and interest of the registrars of - subdomains; a top level domain registrar may e.g., require that there - - - -Beertema [Page 7] - -RFC 1537 Common DNS Data File Configuration Errors October 1993 - - - be primary subdomain "ac" and "co" only and that subdomains be - registered under those primary subdomains. - - The naming authority can also interfere in exceptional cases like the - one mentioned in point 4, e.g., by temporarily removing a domain's - entry from the nameserver zone files; this of course should be done - only with extreme care and only as a last resort. - - When adding NS records for subdomains, top level domain nameserver - managers should realize that the people setting up the nameserver for - a subdomain often are rather inexperienced and can make mistakes that - can easily lead to the subdomain becoming completely unreachable or - that can cause unnecessary DNS traffic (see point 1). It is therefore - highly recommended that, prior to entering such an NS record, the - (top level) nameserver manager does a couple of sanity checks on the - new nameserver (SOA record and timers OK?, MX records present where - needed? No obvious errors made? Listed secondary servers - operational?). Things that cannot be caught though by such checks - are: - - - resolvers set up to use external hosts as nameservers - - - nameservers set up to use external hosts as forwarders - without permission from those hosts. - - Care should also be taken when registering 2-letter subdomains. - Although this is allowed, an implication is that abbreviated - addressing (see STD 11, RFC 822, paragraph 6.2.2) is not possible in - and under that subdomain. When requested to register such a domain, - one should always notify the people of this consequence. As an - example take the name "cs", which is commonly used for Computer - Science departments: it is also the name of the top level domain for - Czecho-Slovakia, so within the domain cs.foo.bar the user@host.cs is - ambiguous in that in can denote both a user on the host - host.cs.foo.bar and a user on the host "host" in Czecho-Slovakia. - (This example does not take into account the recent political changes - in the mentioned country). - -References - - [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13, - RFC 1034, USC/Information Sciences Institute, November 1987. - - [2] Mockapetris, P., "Domain Names Implementation and Specification", - STD 13, RFC 1035, USC/Information Sciences Institute, November - 1987. - - - - - -Beertema [Page 8] - -RFC 1537 Common DNS Data File Configuration Errors October 1993 - - - [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC - 974, CSNET CIC BBN, January 1986. - - [4] Gavron, E., "A Security Problem and Proposed Correction With - Widely Deployed DNS Software", RFC 1535, ACES Research Inc., - October 1993. - - [5] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller, - "Common DNS Implementation Errors and Suggested Fixes", RFC 1536, - USC/Information Sciences Institute, USC, October 1993. - -Security Considerations - - Security issues are not discussed in this memo. - -Author's Address - - Piet Beertema - CWI - Kruislaan 413 - NL-1098 SJ Amsterdam - The Netherlands - - Phone: +31 20 592 4112 - FAX: +31 20 592 4199 - EMail: Piet.Beertema@cwi.nl - - -Editor's Address - - Anant Kumar - USC Information Sciences Institute - 4676 Admiralty Way - Marina Del Rey CA 90292-6695 - - Phone:(310) 822-1511 - FAX: (310) 823-6741 - EMail: anant@isi.edu - - - - - - - - - - - - - -Beertema [Page 9] -
\ No newline at end of file diff --git a/contrib/bind9/doc/rfc/rfc1591.txt b/contrib/bind9/doc/rfc/rfc1591.txt deleted file mode 100644 index 89e0a254a235..000000000000 --- a/contrib/bind9/doc/rfc/rfc1591.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -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 hostmaster@internic.net), 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 hostmaster@internic.net - APNIC hostmaster@apnic.net - RIPE NCC ncc@ripe.net - - 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: Postel@ISI.EDU - -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] - diff --git a/contrib/bind9/doc/rfc/rfc1611.txt b/contrib/bind9/doc/rfc/rfc1611.txt deleted file mode 100644 index ed5b93a83d8b..000000000000 --- a/contrib/bind9/doc/rfc/rfc1611.txt +++ /dev/null @@ -1,1683 +0,0 @@ - - - - - - -Network Working Group R. Austein -Request for Comments: 1611 Epilogue Technology Corporation -Category: Standards Track J. Saperia - Digital Equipment Corporation - May 1994 - - DNS Server MIB Extensions - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Table of Contents - - 1. Introduction .............................................. 1 - 2. The SNMPv2 Network Management Framework ................... 2 - 2.1 Object Definitions ....................................... 2 - 3. Overview .................................................. 2 - 3.1 Resolvers ................................................ 3 - 3.2 Name Servers ............................................. 3 - 3.3 Selected Objects ......................................... 4 - 3.4 Textual Conventions ...................................... 4 - 4. Definitions ............................................... 5 - 5. Acknowledgements .......................................... 28 - 6. References ................................................ 28 - 7. Security Considerations ................................... 29 - 8. Authors' Addresses ........................................ 30 - -1. Introduction - - This memo defines a portion of the Management Information Base (MIB) - for use with network management protocols in the Internet community. - In particular, it describes a set of extensions which instrument DNS - name server functions. This memo was produced by the DNS working - group. - - With the adoption of the Internet-standard Network Management - Framework [4,5,6,7], and with a large number of vendor - implementations of these standards in commercially available - products, it became possible to provide a higher level of effective - network management in TCP/IP-based internets than was previously - available. With the growth in the use of these standards, it has - become possible to consider the management of other elements of the - infrastructure beyond the basic TCP/IP protocols. A key element of - - - -Austein & Saperia [Page 1] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - the TCP/IP infrastructure is the DNS. - - Up to this point there has been no mechanism to integrate the - management of the DNS with SNMP-based managers. This memo provides - the mechanisms by which IP-based management stations can effectively - manage DNS name server software in an integrated fashion. - - We have defined DNS MIB objects to be used in conjunction with the - Internet MIB to allow access to and control of DNS name server - software via SNMP by the Internet community. - -2. The SNMPv2 Network Management Framework - - The SNMPv2 Network Management Framework consists of four major - components. They are: - - o RFC 1442 which defines the SMI, the mechanisms used for - describing and naming objects for the purpose of management. - - o STD 17, RFC 1213 defines MIB-II, the core set of managed objects - for the Internet suite of protocols. - - o RFC 1445 which defines the administrative and other architectural - aspects of the framework. - - o RFC 1448 which defines the protocol used for network access to - managed objects. - - The Framework permits new objects to be defined for the purpose of - experimentation and evaluation. - -2.1. Object Definitions - - Managed objects are accessed via a virtual information store, termed - the Management Information Base or MIB. Objects in the MIB are - defined using the subset of Abstract Syntax Notation One (ASN.1) - defined in the SMI. In particular, each object object type is named - by an OBJECT IDENTIFIER, an administratively assigned name. The - object type together with an object instance serves to uniquely - identify a specific instantiation of the object. For human - convenience, we often use a textual string, termed the descriptor, to - refer to the object type. - -3. Overview - - In theory, the DNS world is pretty simple. There are two kinds of - entities: resolvers and name servers. Resolvers ask questions. Name - servers answer them. The real world, however, is not so simple. - - - -Austein & Saperia [Page 2] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - Implementors have made widely differing choices about how to divide - DNS functions between resolvers and servers. They have also - constructed various sorts of exotic hybrids. The most difficult task - in defining this MIB was to accommodate this wide range of entities - without having to come up with a separate MIB for each. - - We divided up the various DNS functions into two, non-overlapping - classes, called "resolver functions" and "name server functions." A - DNS entity that performs what we define as resolver functions - contains a resolver, and therefore must implement the MIB groups - required of all resolvers which are defined in a separate MIB Module. - A DNS entity which implements name server functions is considered to - be a name server, and must implement the MIB groups required for name - servers in this module. If the same piece of software performs both - resolver and server functions, we imagine that it contains both a - resolver and a server and would thus implement both the DNS Server - and DNS Resolver MIBs. - -3.1. Resolvers - - In our model, a resolver is a program (or piece thereof) which - obtains resource records from servers. Normally it does so at the - behest of an application, but may also do so as part of its own - operation. A resolver sends DNS protocol queries and receives DNS - protocol replies. A resolver neither receives queries nor sends - replies. A full service resolver is one that knows how to resolve - queries: it obtains the needed resource records by contacting a - server authoritative for the records desired. A stub resolver does - not know how to resolve queries: it sends all queries to a local name - server, setting the "recursion desired" flag to indicate that it - hopes that the name server will be willing to resolve the query. A - resolver may (optionally) have a cache for remembering previously - acquired resource records. It may also have a negative cache for - remembering names or data that have been determined not to exist. - -3.2. Name Servers - - A name server is a program (or piece thereof) that provides resource - records to resolvers. All references in this document to "a name - server" imply "the name server's role"; in some cases the name - server's role and the resolver's role might be combined into a single - program. A name server receives DNS protocol queries and sends DNS - protocol replies. A name server neither sends queries nor receives - replies. As a consequence, name servers do not have caches. - Normally, a name server would expect to receive only those queries to - which it could respond with authoritative information. However, if a - name server receives a query that it cannot respond to with purely - authoritative information, it may choose to try to obtain the - - - -Austein & Saperia [Page 3] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - necessary additional information from a resolver which may or may not - be a separate process. - -3.3. Selected Objects - - Many of the objects included in this memo have been created from - information contained in the DNS specifications [1,2], as amended and - clarified by subsequent host requirements documents [3]. Other - objects have been created based on experience with existing DNS - management tools, expected operational needs, the statistics - generated by existing DNS implementations, and the configuration - files used by existing DNS implementations. These objects have been - ordered into groups as follows: - - o Server Configuration Group - - o Server Counter Group - - o Server Optional Counter Group - - o Server Zone Group - - This information has been converted into a standard form using the - SNMPv2 SMI defined in [9]. For the most part, the descriptions are - influenced by the DNS related RFCs noted above. For example, the - descriptions for counters used for the various types of queries of - DNS records are influenced by the definitions used for the various - record types found in [2]. - -3.4. Textual Conventions - - Several conceptual data types have been introduced as a textual - conventions in this DNS MIB document. These additions will - facilitate the common understanding of information used by the DNS. - No changes to the SMI or the SNMP are necessary to support these - conventions. - - Readers familiar with MIBs designed to manage entities in the lower - layers of the Internet protocol suite may be surprised at the number - of non-enumerated integers used in this MIB to represent values such - as DNS RR class and type numbers. The reason for this choice is - simple: the DNS itself is designed as an extensible protocol, - allowing new classes and types of resource records to be added to the - protocol without recoding the core DNS software. Using non- - enumerated integers to represent these data types in this MIB allows - the MIB to accommodate these changes as well. - - - - - -Austein & Saperia [Page 4] - -RFC 1611 DNS Server MIB Extensions May 1994 - - -4. Definitions - - DNS-SERVER-MIB DEFINITIONS ::= BEGIN - - IMPORTS - mib-2 - FROM RFC-1213 - MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, - IpAddress, Counter32, Gauge32 - FROM SNMPv2-SMI - TEXTUAL-CONVENTION, RowStatus, DisplayString, TruthValue - FROM SNMPv2-TC - MODULE-COMPLIANCE, OBJECT-GROUP - FROM SNMPv2-CONF; - - dns OBJECT-IDENTITY - STATUS current - DESCRIPTION - "The OID assigned to DNS MIB work by the IANA." - ::= { mib-2 32 } - - dnsServMIB MODULE-IDENTITY - LAST-UPDATED "9401282251Z" - ORGANIZATION "IETF DNS Working Group" - CONTACT-INFO - " Rob Austein - Postal: Epilogue Technology Corporation - 268 Main Street, Suite 283 - North Reading, MA 10864 - US - Tel: +1 617 245 0804 - Fax: +1 617 245 8122 - E-Mail: sra@epilogue.com - - Jon Saperia - Postal: Digital Equipment Corporation - 110 Spit Brook Road - ZKO1-3/H18 - Nashua, NH 03062-2698 - US - Tel: +1 603 881 0480 - Fax: +1 603 881 0120 - Email: saperia@zko.dec.com" - DESCRIPTION - "The MIB module for entities implementing the server side - of the Domain Name System (DNS) protocol." - ::= { dns 1 } - - - - -Austein & Saperia [Page 5] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - dnsServMIBObjects OBJECT IDENTIFIER ::= { dnsServMIB 1 } - - -- (Old-style) groups in the DNS server MIB. - - dnsServConfig OBJECT IDENTIFIER ::= { dnsServMIBObjects 1 } - dnsServCounter OBJECT IDENTIFIER ::= { dnsServMIBObjects 2 } - dnsServOptCounter OBJECT IDENTIFIER ::= { dnsServMIBObjects 3 } - dnsServZone OBJECT IDENTIFIER ::= { dnsServMIBObjects 4 } - - - -- Textual conventions - - DnsName ::= TEXTUAL-CONVENTION - -- A DISPLAY-HINT would be nice, but difficult to express. - STATUS current - DESCRIPTION - "A DNS name is a sequence of labels. When DNS names are - displayed, the boundaries between labels are typically - indicated by dots (e.g. `Acme' and `COM' are labels in - the name `Acme.COM'). In the DNS protocol, however, no - such separators are needed because each label is encoded - as a length octet followed by the indicated number of - octets of label. For example, `Acme.COM' is encoded as - the octet sequence { 4, 'A', 'c', 'm', 'e', 3, 'C', 'O', - 'M', 0 } (the final 0 is the length of the name of the - root domain, which appears implicitly at the end of any - DNS name). This MIB uses the same encoding as the DNS - protocol. - - A DnsName must always be a fully qualified name. It is - an error to encode a relative domain name as a DnsName - without first making it a fully qualified name." - REFERENCE - "RFC-1034 section 3.1." - SYNTAX OCTET STRING (SIZE (0..255)) - - DnsNameAsIndex ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION - "This textual convention is like a DnsName, but is used - as an index componant in tables. Alphabetic characters - in names of this type are restricted to uppercase: the - characters 'a' through 'z' are mapped to the characters - 'A' through 'Z'. This restriction is intended to make - the lexical ordering imposed by SNMP useful when applied - to DNS names. - - Note that it is theoretically possible for a valid DNS - - - -Austein & Saperia [Page 6] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - name to exceed the allowed length of an SNMP object - identifer, and thus be impossible to represent in tables - in this MIB that are indexed by DNS name. Sampling of - DNS names in current use on the Internet suggests that - this limit does not pose a serious problem in practice." - REFERENCE - "RFC-1034 section 3.1, RFC-1448 section 4.1." - SYNTAX DnsName - - DnsClass ::= TEXTUAL-CONVENTION - DISPLAY-HINT "2d" - STATUS current - DESCRIPTION - "This data type is used to represent the class values - which appear in Resource Records in the DNS. A 16-bit - unsigned integer is used to allow room for new classes - of records to be defined. Existing standard classes are - listed in the DNS specifications." - REFERENCE - "RFC-1035 section 3.2.4." - SYNTAX INTEGER (0..65535) - - DnsType ::= TEXTUAL-CONVENTION - DISPLAY-HINT "2d" - STATUS current - DESCRIPTION - "This data type is used to represent the type values - which appear in Resource Records in the DNS. A 16-bit - unsigned integer is used to allow room for new record - types to be defined. Existing standard types are listed - in the DNS specifications." - REFERENCE - "RFC-1035 section 3.2.2." - SYNTAX INTEGER (0..65535) - - DnsQClass ::= TEXTUAL-CONVENTION - DISPLAY-HINT "2d" - STATUS current - DESCRIPTION - "This data type is used to represent the QClass values - which appear in Resource Records in the DNS. A 16-bit - unsigned integer is used to allow room for new QClass - records to be defined. Existing standard QClasses are - listed in the DNS specification." - REFERENCE - "RFC-1035 section 3.2.5." - SYNTAX INTEGER (0..65535) - - - - -Austein & Saperia [Page 7] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - DnsQType ::= TEXTUAL-CONVENTION - DISPLAY-HINT "2d" - STATUS current - DESCRIPTION - "This data type is used to represent the QType values - which appear in Resource Records in the DNS. A 16-bit - unsigned integer is used to allow room for new QType - records to be defined. Existing standard QTypes are - listed in the DNS specification." - REFERENCE - "RFC-1035 section 3.2.3." - SYNTAX INTEGER (0..65535) - - DnsTime ::= TEXTUAL-CONVENTION - DISPLAY-HINT "4d" - STATUS current - DESCRIPTION - "DnsTime values are 32-bit unsigned integers which - measure time in seconds." - REFERENCE - "RFC-1035." - SYNTAX Gauge32 - - - DnsOpCode ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION - "This textual convention is used to represent the DNS - OPCODE values used in the header section of DNS - messages. Existing standard OPCODE values are listed in - the DNS specifications." - REFERENCE - "RFC-1035 section 4.1.1." - SYNTAX INTEGER (0..15) - - DnsRespCode ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION - "This data type is used to represent the DNS RCODE value - in DNS response messages. Existing standard RCODE - values are listed in the DNS specifications." - REFERENCE - "RFC-1035 section 4.1.1." - SYNTAX INTEGER (0..15) - - - - - - - -Austein & Saperia [Page 8] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - -- Server Configuration Group - - dnsServConfigImplementIdent OBJECT-TYPE - SYNTAX DisplayString - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The implementation identification string for the DNS - server software in use on the system, for example; - `FNS-2.1'" - ::= { dnsServConfig 1 } - - dnsServConfigRecurs OBJECT-TYPE - SYNTAX INTEGER { available(1), - restricted(2), - unavailable(3) } - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "This represents the recursion services offered by this - name server. The values that can be read or written - are: - - available(1) - performs recursion on requests from - clients. - - restricted(2) - recursion is performed on requests only - from certain clients, for example; clients on an access - control list. - - unavailable(3) - recursion is not available." - ::= { dnsServConfig 2 } - - dnsServConfigUpTime OBJECT-TYPE - SYNTAX DnsTime - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "If the server has a persistent state (e.g., a process), - this value will be the time elapsed since it started. - For software without persistant state, this value will - be zero." - ::= { dnsServConfig 3 } - - dnsServConfigResetTime OBJECT-TYPE - SYNTAX DnsTime - MAX-ACCESS read-only - STATUS current - - - -Austein & Saperia [Page 9] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - DESCRIPTION - "If the server has a persistent state (e.g., a process) - and supports a `reset' operation (e.g., can be told to - re-read configuration files), this value will be the - time elapsed since the last time the name server was - `reset.' For software that does not have persistence or - does not support a `reset' operation, this value will be - zero." - ::= { dnsServConfig 4 } - - dnsServConfigReset OBJECT-TYPE - SYNTAX INTEGER { other(1), - reset(2), - initializing(3), - running(4) } - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "Status/action object to reinitialize any persistant name - server state. When set to reset(2), any persistant - name server state (such as a process) is reinitialized as - if the name server had just been started. This value - will never be returned by a read operation. When read, - one of the following values will be returned: - other(1) - server in some unknown state; - initializing(3) - server (re)initializing; - running(4) - server currently running." - ::= { dnsServConfig 5 } - - - -- Server Counter Group - - dnsServCounterAuthAns OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of queries which were authoritatively answered." - ::= { dnsServCounter 2 } - - dnsServCounterAuthNoNames OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of queries for which `authoritative no such name' - responses were made." - ::= { dnsServCounter 3 } - - - -Austein & Saperia [Page 10] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - dnsServCounterAuthNoDataResps OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of queries for which `authoritative no such data' - (empty answer) responses were made." - ::= { dnsServCounter 4 } - - dnsServCounterNonAuthDatas OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of queries which were non-authoritatively - answered (cached data)." - ::= { dnsServCounter 5 } - - dnsServCounterNonAuthNoDatas OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of queries which were non-authoritatively - answered with no data (empty answer)." - ::= { dnsServCounter 6 } - - dnsServCounterReferrals OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests that were referred to other servers." - ::= { dnsServCounter 7 } - - dnsServCounterErrors OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests the server has processed that were - answered with errors (RCODE values other than 0 and 3)." - REFERENCE - "RFC-1035 section 4.1.1." - ::= { dnsServCounter 8 } - - dnsServCounterRelNames OBJECT-TYPE - SYNTAX Counter32 - - - -Austein & Saperia [Page 11] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests received by the server for names that - are only 1 label long (text form - no internal dots)." - ::= { dnsServCounter 9 } - - dnsServCounterReqRefusals OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of DNS requests refused by the server." - ::= { dnsServCounter 10 } - - dnsServCounterReqUnparses OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests received which were unparseable." - ::= { dnsServCounter 11 } - - dnsServCounterOtherErrors OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests which were aborted for other (local) - server errors." - ::= { dnsServCounter 12 } - - -- DNS Server Counter Table - - dnsServCounterTable OBJECT-TYPE - SYNTAX SEQUENCE OF DnsServCounterEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Counter information broken down by DNS class and type." - ::= { dnsServCounter 13 } - - dnsServCounterEntry OBJECT-TYPE - SYNTAX DnsServCounterEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "This table contains count information for each DNS class - - - -Austein & Saperia [Page 12] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - and type value known to the server. The index allows - management software to to create indices to the table to - get the specific information desired, e.g., number of - queries over UDP for records with type value `A' which - came to this server. In order to prevent an - uncontrolled expansion of rows in the table; if - dnsServCounterRequests is 0 and dnsServCounterResponses - is 0, then the row does not exist and `no such' is - returned when the agent is queried for such instances." - INDEX { dnsServCounterOpCode, - dnsServCounterQClass, - dnsServCounterQType, - dnsServCounterTransport } - ::= { dnsServCounterTable 1 } - - DnsServCounterEntry ::= - SEQUENCE { - dnsServCounterOpCode - DnsOpCode, - dnsServCounterQClass - DnsClass, - dnsServCounterQType - DnsType, - dnsServCounterTransport - INTEGER, - dnsServCounterRequests - Counter32, - dnsServCounterResponses - Counter32 - } - - dnsServCounterOpCode OBJECT-TYPE - SYNTAX DnsOpCode - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The DNS OPCODE being counted in this row of the table." - ::= { dnsServCounterEntry 1 } - - dnsServCounterQClass OBJECT-TYPE - SYNTAX DnsClass - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The class of record being counted in this row of the - table." - ::= { dnsServCounterEntry 2 } - - - - -Austein & Saperia [Page 13] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - dnsServCounterQType OBJECT-TYPE - SYNTAX DnsType - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The type of record which is being counted in this row in - the table." - ::= { dnsServCounterEntry 3 } - - dnsServCounterTransport OBJECT-TYPE - SYNTAX INTEGER { udp(1), tcp(2), other(3) } - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A value of udp(1) indicates that the queries reported on - this row were sent using UDP. - - A value of tcp(2) indicates that the queries reported on - this row were sent using TCP. - - A value of other(3) indicates that the queries reported - on this row were sent using a transport that was neither - TCP nor UDP." - ::= { dnsServCounterEntry 4 } - - dnsServCounterRequests OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests (queries) that have been recorded in - this row of the table." - ::= { dnsServCounterEntry 5 } - - dnsServCounterResponses OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of responses made by the server since - initialization for the kind of query identified on this - row of the table." - ::= { dnsServCounterEntry 6 } - - - - - - - - -Austein & Saperia [Page 14] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - -- Server Optional Counter Group - - -- The Server Optional Counter Group is intended for those systems - -- which make distinctions between the different sources of the DNS - -- queries as defined below. - -- - -- Objects in this group are implemented on servers which distinguish - -- between queries which originate from the same host as the server, - -- queries from one of an arbitrary group of hosts that are on an - -- access list defined by the server, and queries from hosts that do - -- not fit either of these descriptions. - -- - -- The objects found in the Server Counter group are totals. Thus if - -- one wanted to identify, for example, the number of queries from - -- `remote' hosts which have been given authoritative answers, one - -- would subtract the current values of ServOptCounterFriendsAuthAns - -- and ServOptCounterSelfAuthAns from servCounterAuthAns. - -- - -- The purpose of these distinctions is to allow for implementations - -- to group queries and responses on this basis. One way in which - -- servers may make these distinctions is by looking at the source IP - -- address of the DNS query. If the source of the query is `your - -- own' then the query should be counted as `yourself' (local host). - -- If the source of the query matches an `access list,' the query - -- came from a friend. What constitutes an `access list' is - -- implementation dependent and could be as simple as a rule that all - -- hosts on the same IP network as the DNS server are classed - -- `friends.' - -- - -- In order to avoid double counting, the following rules apply: - -- - -- 1. No host is in more than one of the three groups defined above. - -- - -- 2. All queries from the local host are always counted in the - -- `yourself' group regardless of what the access list, if any, - -- says. - -- - -- 3. The access list should not define `your friends' in such a way - -- that it includes all hosts. That is, not everybody is your - -- `friend.' - - dnsServOptCounterSelfAuthAns OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests the server has processed which - originated from a resolver on the same host for which - - - -Austein & Saperia [Page 15] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - there has been an authoritative answer." - ::= { dnsServOptCounter 1 } - - dnsServOptCounterSelfAuthNoNames OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests the server has processed which - originated from a resolver on the same host for which - there has been an authoritative no such name answer - given." - ::= { dnsServOptCounter 2 } - - dnsServOptCounterSelfAuthNoDataResps OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests the server has processed which - originated from a resolver on the same host for which - there has been an authoritative no such data answer - (empty answer) made." - ::= { dnsServOptCounter 3 } - - dnsServOptCounterSelfNonAuthDatas OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests the server has processed which - originated from a resolver on the same host for which a - non-authoritative answer (cached data) was made." - ::= { dnsServOptCounter 4 } - - dnsServOptCounterSelfNonAuthNoDatas OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests the server has processed which - originated from a resolver on the same host for which a - `non-authoritative, no such data' response was made - (empty answer)." - ::= { dnsServOptCounter 5 } - - dnsServOptCounterSelfReferrals OBJECT-TYPE - SYNTAX Counter32 - - - -Austein & Saperia [Page 16] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of queries the server has processed which - originated from a resolver on the same host and were - referred to other servers." - ::= { dnsServOptCounter 6 } - - dnsServOptCounterSelfErrors OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests the server has processed which - originated from a resolver on the same host which have - been answered with errors (RCODEs other than 0 and 3)." - REFERENCE - "RFC-1035 section 4.1.1." - ::= { dnsServOptCounter 7 } - - dnsServOptCounterSelfRelNames OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests received for names that are only 1 - label long (text form - no internal dots) the server has - processed which originated from a resolver on the same - host." - ::= { dnsServOptCounter 8 } - - dnsServOptCounterSelfReqRefusals OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of DNS requests refused by the server which - originated from a resolver on the same host." - ::= { dnsServOptCounter 9 } - - dnsServOptCounterSelfReqUnparses OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests received which were unparseable and - which originated from a resolver on the same host." - ::= { dnsServOptCounter 10 } - - - -Austein & Saperia [Page 17] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - dnsServOptCounterSelfOtherErrors OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests which were aborted for other (local) - server errors and which originated on the same host." - ::= { dnsServOptCounter 11 } - - dnsServOptCounterFriendsAuthAns OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of queries originating from friends which were - authoritatively answered. The definition of friends is - a locally defined matter." - ::= { dnsServOptCounter 12 } - - dnsServOptCounterFriendsAuthNoNames OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of queries originating from friends, for which - authoritative `no such name' responses were made. The - definition of friends is a locally defined matter." - ::= { dnsServOptCounter 13 } - - dnsServOptCounterFriendsAuthNoDataResps OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of queries originating from friends for which - authoritative no such data (empty answer) responses were - made. The definition of friends is a locally defined - matter." - ::= { dnsServOptCounter 14 } - - dnsServOptCounterFriendsNonAuthDatas OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of queries originating from friends which were - non-authoritatively answered (cached data). The - definition of friends is a locally defined matter." - - - -Austein & Saperia [Page 18] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - ::= { dnsServOptCounter 15 } - - dnsServOptCounterFriendsNonAuthNoDatas OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of queries originating from friends which were - non-authoritatively answered with no such data (empty - answer)." - ::= { dnsServOptCounter 16 } - - dnsServOptCounterFriendsReferrals OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests which originated from friends that - were referred to other servers. The definition of - friends is a locally defined matter." - ::= { dnsServOptCounter 17 } - - dnsServOptCounterFriendsErrors OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests the server has processed which - originated from friends and were answered with errors - (RCODE values other than 0 and 3). The definition of - friends is a locally defined matter." - REFERENCE - "RFC-1035 section 4.1.1." - ::= { dnsServOptCounter 18 } - - dnsServOptCounterFriendsRelNames OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests received for names from friends that - are only 1 label long (text form - no internal dots) the - server has processed." - ::= { dnsServOptCounter 19 } - - dnsServOptCounterFriendsReqRefusals OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - - - -Austein & Saperia [Page 19] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - STATUS current - DESCRIPTION - "Number of DNS requests refused by the server which were - received from `friends'." - ::= { dnsServOptCounter 20 } - - dnsServOptCounterFriendsReqUnparses OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests received which were unparseable and - which originated from `friends'." - ::= { dnsServOptCounter 21 } - - dnsServOptCounterFriendsOtherErrors OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests which were aborted for other (local) - server errors and which originated from `friends'." - ::= { dnsServOptCounter 22 } - - - -- Server Zone Group - - -- DNS Management Zone Configuration Table - - -- This table contains zone configuration information. - - dnsServZoneTable OBJECT-TYPE - SYNTAX SEQUENCE OF DnsServZoneEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Table of zones for which this name server provides - information. Each of the zones may be loaded from stable - storage via an implementation-specific mechanism or may - be obtained from another name server via a zone transfer. - - If name server doesn't load any zones, this table is - empty." - ::= { dnsServZone 1 } - - dnsServZoneEntry OBJECT-TYPE - SYNTAX DnsServZoneEntry - MAX-ACCESS not-accessible - - - -Austein & Saperia [Page 20] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - STATUS current - DESCRIPTION - "An entry in the name server zone table. New rows may be - added either via SNMP or by the name server itself." - INDEX { dnsServZoneName, - dnsServZoneClass } - ::= { dnsServZoneTable 1 } - - DnsServZoneEntry ::= - SEQUENCE { - dnsServZoneName - DnsNameAsIndex, - dnsServZoneClass - DnsClass, - dnsServZoneLastReloadSuccess - DnsTime, - dnsServZoneLastReloadAttempt - DnsTime, - dnsServZoneLastSourceAttempt - IpAddress, - dnsServZoneStatus - RowStatus, - dnsServZoneSerial - Counter32, - dnsServZoneCurrent - TruthValue, - dnsServZoneLastSourceSuccess - IpAddress - } - - dnsServZoneName OBJECT-TYPE - SYNTAX DnsNameAsIndex - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "DNS name of the zone described by this row of the table. - This is the owner name of the SOA RR that defines the - top of the zone. This is name is in uppercase: - characters 'a' through 'z' are mapped to 'A' through 'Z' - in order to make the lexical ordering useful." - ::= { dnsServZoneEntry 1 } - - dnsServZoneClass OBJECT-TYPE - SYNTAX DnsClass - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "DNS class of the RRs in this zone." - - - -Austein & Saperia [Page 21] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - ::= { dnsServZoneEntry 2 } - - dnsServZoneLastReloadSuccess OBJECT-TYPE - SYNTAX DnsTime - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Elapsed time in seconds since last successful reload of - this zone." - ::= { dnsServZoneEntry 3 } - - dnsServZoneLastReloadAttempt OBJECT-TYPE - SYNTAX DnsTime - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Elapsed time in seconds since last attempted reload of - this zone." - ::= { dnsServZoneEntry 4 } - - dnsServZoneLastSourceAttempt OBJECT-TYPE - SYNTAX IpAddress - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "IP address of host from which most recent zone transfer - of this zone was attempted. This value should match the - value of dnsServZoneSourceSuccess if the attempt was - succcessful. If zone transfer has not been attempted - within the memory of this name server, this value should - be 0.0.0.0." - ::= { dnsServZoneEntry 5 } - - dnsServZoneStatus OBJECT-TYPE - SYNTAX RowStatus - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The status of the information represented in this row of - the table." - ::= { dnsServZoneEntry 6 } - - dnsServZoneSerial OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Zone serial number (from the SOA RR) of the zone - - - -Austein & Saperia [Page 22] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - represented by this row of the table. If the zone has - not been successfully loaded within the memory of this - name server, the value of this variable is zero." - ::= { dnsServZoneEntry 7 } - - dnsServZoneCurrent OBJECT-TYPE - SYNTAX TruthValue - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Whether the server's copy of the zone represented by - this row of the table is currently valid. If the zone - has never been successfully loaded or has expired since - it was last succesfully loaded, this variable will have - the value false(2), otherwise this variable will have - the value true(1)." - ::= { dnsServZoneEntry 8 } - - dnsServZoneLastSourceSuccess OBJECT-TYPE - SYNTAX IpAddress - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "IP address of host which was the source of the most - recent successful zone transfer for this zone. If - unknown (e.g., zone has never been successfully - transfered) or irrelevant (e.g., zone was loaded from - stable storage), this value should be 0.0.0.0." - ::= { dnsServZoneEntry 9 } - - -- DNS Zone Source Table - - dnsServZoneSrcTable OBJECT-TYPE - SYNTAX SEQUENCE OF DnsServZoneSrcEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "This table is a list of IP addresses from which the - server will attempt to load zone information using DNS - zone transfer operations. A reload may occur due to SNMP - operations that create a row in dnsServZoneTable or a - SET to object dnsServZoneReload. This table is only - used when the zone is loaded via zone transfer." - ::= { dnsServZone 2 } - - dnsServZoneSrcEntry OBJECT-TYPE - SYNTAX DnsServZoneSrcEntry - MAX-ACCESS not-accessible - - - -Austein & Saperia [Page 23] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - STATUS current - DESCRIPTION - "An entry in the name server zone source table." - INDEX { dnsServZoneSrcName, - dnsServZoneSrcClass, - dnsServZoneSrcAddr } - ::= { dnsServZoneSrcTable 1 } - - DnsServZoneSrcEntry ::= - SEQUENCE { - dnsServZoneSrcName - DnsNameAsIndex, - dnsServZoneSrcClass - DnsClass, - dnsServZoneSrcAddr - IpAddress, - dnsServZoneSrcStatus - RowStatus - } - - dnsServZoneSrcName OBJECT-TYPE - SYNTAX DnsNameAsIndex - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "DNS name of the zone to which this entry applies." - ::= { dnsServZoneSrcEntry 1 } - - dnsServZoneSrcClass OBJECT-TYPE - SYNTAX DnsClass - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "DNS class of zone to which this entry applies." - ::= { dnsServZoneSrcEntry 2 } - - dnsServZoneSrcAddr OBJECT-TYPE - SYNTAX IpAddress - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "IP address of name server host from which this zone - might be obtainable." - ::= { dnsServZoneSrcEntry 3 } - - dnsServZoneSrcStatus OBJECT-TYPE - SYNTAX RowStatus - MAX-ACCESS read-create - - - -Austein & Saperia [Page 24] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - STATUS current - DESCRIPTION - "The status of the information represented in this row of - the table." - ::= { dnsServZoneSrcEntry 4 } - - - -- SNMPv2 groups. - - dnsServMIBGroups OBJECT IDENTIFIER ::= { dnsServMIB 2 } - - dnsServConfigGroup OBJECT-GROUP - OBJECTS { dnsServConfigImplementIdent, - dnsServConfigRecurs, - dnsServConfigUpTime, - dnsServConfigResetTime, - dnsServConfigReset } - STATUS current - DESCRIPTION - "A collection of objects providing basic configuration - control of a DNS name server." - ::= { dnsServMIBGroups 1 } - - dnsServCounterGroup OBJECT-GROUP - OBJECTS { dnsServCounterAuthAns, - dnsServCounterAuthNoNames, - dnsServCounterAuthNoDataResps, - dnsServCounterNonAuthDatas, - dnsServCounterNonAuthNoDatas, - dnsServCounterReferrals, - dnsServCounterErrors, - dnsServCounterRelNames, - dnsServCounterReqRefusals, - dnsServCounterReqUnparses, - dnsServCounterOtherErrors, - dnsServCounterOpCode, - dnsServCounterQClass, - dnsServCounterQType, - dnsServCounterTransport, - dnsServCounterRequests, - dnsServCounterResponses } - STATUS current - DESCRIPTION - "A collection of objects providing basic instrumentation - of a DNS name server." - ::= { dnsServMIBGroups 2 } - - - - - -Austein & Saperia [Page 25] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - dnsServOptCounterGroup OBJECT-GROUP - OBJECTS { dnsServOptCounterSelfAuthAns, - dnsServOptCounterSelfAuthNoNames, - dnsServOptCounterSelfAuthNoDataResps, - dnsServOptCounterSelfNonAuthDatas, - dnsServOptCounterSelfNonAuthNoDatas, - dnsServOptCounterSelfReferrals, - dnsServOptCounterSelfErrors, - dnsServOptCounterSelfRelNames, - dnsServOptCounterSelfReqRefusals, - dnsServOptCounterSelfReqUnparses, - dnsServOptCounterSelfOtherErrors, - dnsServOptCounterFriendsAuthAns, - dnsServOptCounterFriendsAuthNoNames, - dnsServOptCounterFriendsAuthNoDataResps, - dnsServOptCounterFriendsNonAuthDatas, - dnsServOptCounterFriendsNonAuthNoDatas, - dnsServOptCounterFriendsReferrals, - dnsServOptCounterFriendsErrors, - dnsServOptCounterFriendsRelNames, - dnsServOptCounterFriendsReqRefusals, - dnsServOptCounterFriendsReqUnparses, - dnsServOptCounterFriendsOtherErrors } - STATUS current - DESCRIPTION - "A collection of objects providing extended - instrumentation of a DNS name server." - ::= { dnsServMIBGroups 3 } - - dnsServZoneGroup OBJECT-GROUP - OBJECTS { dnsServZoneName, - dnsServZoneClass, - dnsServZoneLastReloadSuccess, - dnsServZoneLastReloadAttempt, - dnsServZoneLastSourceAttempt, - dnsServZoneLastSourceSuccess, - dnsServZoneStatus, - dnsServZoneSerial, - dnsServZoneCurrent, - dnsServZoneSrcName, - dnsServZoneSrcClass, - dnsServZoneSrcAddr, - dnsServZoneSrcStatus } - STATUS current - DESCRIPTION - "A collection of objects providing configuration control - of a DNS name server which loads authoritative zones." - ::= { dnsServMIBGroups 4 } - - - -Austein & Saperia [Page 26] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - -- Compliances. - - dnsServMIBCompliances OBJECT IDENTIFIER ::= { dnsServMIB 3 } - - dnsServMIBCompliance MODULE-COMPLIANCE - STATUS current - DESCRIPTION - "The compliance statement for agents implementing the DNS - name server MIB extensions." - MODULE -- This MIB module - MANDATORY-GROUPS { dnsServConfigGroup, dnsServCounterGroup } - GROUP dnsServOptCounterGroup - DESCRIPTION - "The server optional counter group is unconditionally - optional." - GROUP dnsServZoneGroup - DESCRIPTION - "The server zone group is mandatory for any name server - that acts as an authoritative server for any DNS zone." - OBJECT dnsServConfigRecurs - MIN-ACCESS read-only - DESCRIPTION - "This object need not be writable." - OBJECT dnsServConfigReset - MIN-ACCESS read-only - DESCRIPTION - "This object need not be writable." - ::= { dnsServMIBCompliances 1 } - - END - - - - - - - - - - - - - - - - - - - - - -Austein & Saperia [Page 27] - -RFC 1611 DNS Server MIB Extensions May 1994 - - -5. Acknowledgements - - This document is the result of work undertaken the by DNS working - group. The authors would particularly like to thank the following - people for their contributions to this document: Philip Almquist, - Frank Kastenholz (FTP Software), Joe Peck (DEC), Dave Perkins - (SynOptics), Win Treese (DEC), and Mimi Zohar (IBM). - -6. References - - [1] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD - 13, RFC 1034, USC/Information Sciences Institute, November 1987. - - [2] Mockapetris, P., "Domain Names -- Implementation and - Specification", STD 13, RFC 1035, USC/Information Sciences - Institute, November 1987. - - [3] Braden, R., Editor, "Requirements for Internet Hosts -- - Application and Support, STD 3, RFC 1123, USC/Information - Sciences Institute, October 1989. - - [4] Rose, M., and K. McCloghrie, "Structure and Identification of - Management Information for TCP/IP-based internets", STD 16, RFC - 1155, Performance Systems International, Hughes LAN Systems, May - 1990. - - [5] McCloghrie, K., and M. Rose, "Management Information Base for - Network Management of TCP/IP-based internets", RFC 1156, Hughes - LAN Systems, Performance Systems International, May 1990. - - [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple - Network Management Protocol", STD 15, RFC 1157, SNMP Research, - Performance Systems International, Performance Systems - International, MIT Laboratory for Computer Science, May 1990. - - [7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", - STD 16, RFC 1212, Performance Systems International, Hughes LAN - Systems, March 1991. - - [8] McCloghrie, K., and M. Rose, Editors, "Management Information - Base for Network Management of TCP/IP-based internets: MIB-II", - STD 17, RFC 1213, Hughes LAN Systems, Performance Systems - International, March 1991. - - [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure - of Management Information for version 2 of the Simple Network - Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., - Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon - - - -Austein & Saperia [Page 28] - -RFC 1611 DNS Server MIB Extensions May 1994 - - - University, April 1993. - - [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual - Conventions for version 2 of the the Simple Network Management - Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN - Systems, Dover Beach Consulting, Inc., Carnegie Mellon - University, April 1993. - - [11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, - "Conformance Statements for version 2 of the the Simple Network - Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc., - Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon - University, April 1993. - - [12] Galvin, J., and K. McCloghrie, "Administrative Model for version - 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, - Trusted Information Systems, Hughes LAN Systems, April 1993. - - [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol - Operations for version 2 of the Simple Network Management - Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN - Systems, Dover Beach Consulting, Inc., Carnegie Mellon - University, April 1993. - - [14] "Information processing systems - Open Systems Interconnection - - Specification of Abstract Syntax Notation One (ASN.1)", - International Organization for Standardization, International - Standard 8824, December 1987. - -7. Security Considerations - - Security issues are not discussed in this memo. - - - - - - - - - - - - - - - - - - - -Austein & Saperia [Page 29] - -RFC 1611 DNS Server MIB Extensions May 1994 - - -8. Authors' Addresses - - Rob Austein - Epilogue Technology Corporation - 268 Main Street, Suite 283 - North Reading, MA 01864 - USA - - Phone: +1-617-245-0804 - Fax: +1-617-245-8122 - EMail: sra@epilogue.com - - - Jon Saperia - Digital Equipment Corporation - 110 Spit Brook Road - ZKO1-3/H18 - Nashua, NH 03062-2698 - USA - - Phone: +1-603-881-0480 - Fax: +1-603-881-0120 - EMail: saperia@zko.dec.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein & Saperia [Page 30] - diff --git a/contrib/bind9/doc/rfc/rfc1612.txt b/contrib/bind9/doc/rfc/rfc1612.txt deleted file mode 100644 index 4ef23b0c659c..000000000000 --- a/contrib/bind9/doc/rfc/rfc1612.txt +++ /dev/null @@ -1,1795 +0,0 @@ - - - - - - -Network Working Group R. Austein -Request for Comments: 1612 Epilogue Technology Corporation -Category: Standards Track J. Saperia - Digital Equipment Corporation - May 1994 - - - DNS Resolver MIB Extensions - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Table of Contents - - 1. Introduction .............................................. 1 - 2. The SNMPv2 Network Management Framework ................... 2 - 2.1 Object Definitions ....................................... 2 - 3. Overview .................................................. 2 - 3.1 Resolvers ................................................ 3 - 3.2 Name Servers ............................................. 3 - 3.3 Selected Objects ......................................... 4 - 3.4 Textual Conventions ...................................... 4 - 4. Definitions ............................................... 5 - 5. Acknowledgements .......................................... 30 - 6. References ................................................ 30 - 7. Security Considerations ................................... 32 - 8. Authors' Addresses ........................................ 32 - -1. Introduction - - This memo defines a portion of the Management Information Base (MIB) - for use with network management protocols in the Internet community. - In particular, it describes a set of extensions which instrument DNS - resolver functions. This memo was produced by the DNS working group. - - With the adoption of the Internet-standard Network Management - Framework [4,5,6,7], and with a large number of vendor - implementations of these standards in commercially available - products, it became possible to provide a higher level of effective - network management in TCP/IP-based internets than was previously - available. With the growth in the use of these standards, it has - become possible to consider the management of other elements of the - infrastructure beyond the basic TCP/IP protocols. A key element of - - - -Austein & Saperia [Page 1] - -RFC 1612 DNS Resolver MIB May 1994 - - - the TCP/IP infrastructure is the DNS. - - Up to this point there has been no mechanism to integrate the - management of the DNS with SNMP-based managers. This memo provides - the mechanisms by which IP-based management stations can effectively - manage DNS resolver software in an integrated fashion. - - We have defined DNS MIB objects to be used in conjunction with the - Internet MIB to allow access to and control of DNS resolver software - via SNMP by the Internet community. - -2. The SNMPv2 Network Management Framework - - The SNMPv2 Network Management Framework consists of four major - components. They are: - - o RFC 1442 which defines the SMI, the mechanisms used for - describing and naming objects for the purpose of management. - - o STD 17, RFC 1213 defines MIB-II, the core set of managed - objects for the Internet suite of protocols. - - o RFC 1445 which defines the administrative and other - architectural aspects of the framework. - - o RFC 1448 which defines the protocol used for network access to - managed objects. - - The Framework permits new objects to be defined for the purpose of - experimentation and evaluation. - -2.1. Object Definitions - - Managed objects are accessed via a virtual information store, termed - the Management Information Base or MIB. Objects in the MIB are - defined using the subset of Abstract Syntax Notation One (ASN.1) - defined in the SMI. In particular, each object object type is named - by an OBJECT IDENTIFIER, an administratively assigned name. The - object type together with an object instance serves to uniquely - identify a specific instantiation of the object. For human - convenience, we often use a textual string, termed the descriptor, to - refer to the object type. - -3. Overview - - In theory, the DNS world is pretty simple. There are two kinds of - entities: resolvers and name servers. Resolvers ask questions. Name - servers answer them. The real world, however, is not so simple. - - - -Austein & Saperia [Page 2] - -RFC 1612 DNS Resolver MIB May 1994 - - - Implementors have made widely differing choices about how to divide - DNS functions between resolvers and servers. They have also - constructed various sorts of exotic hybrids. The most difficult task - in defining this MIB was to accommodate this wide range of entities - without having to come up with a separate MIB for each. - - We divided up the various DNS functions into two, non-overlapping - classes, called "resolver functions" and "name server functions." A - DNS entity that performs what we define as resolver functions - contains a resolver, and therefore must implement the MIB groups - required of all resolvers which are defined in this module. Some - resolvers also implement "optional" functions such as a cache, in - which case they must also implement the cache group contained in this - MIB. A DNS entity which implements name server functions is - considered to be a name server, and must implement the MIB groups - required for name servers which are defined in a separate module. If - the same piece of software performs both resolver and server - functions, we imagine that it contains both a resolver and a server - and would thus implement both the DNS Server and DNS Resolver MIBs. - -3.1. Resolvers - - In our model, a resolver is a program (or piece thereof) which - obtains resource records from servers. Normally it does so at the - behest of an application, but may also do so as part of its own - operation. A resolver sends DNS protocol queries and receives DNS - protocol replies. A resolver neither receives queries nor sends - replies. A full service resolver is one that knows how to resolve - queries: it obtains the needed resource records by contacting a - server authoritative for the records desired. A stub resolver does - not know how to resolve queries: it sends all queries to a local name - server, setting the "recursion desired" flag to indicate that it - hopes that the name server will be willing to resolve the query. A - resolver may (optionally) have a cache for remembering previously - acquired resource records. It may also have a negative cache for - remembering names or data that have been determined not to exist. - -3.2. Name Servers - - A name server is a program (or piece thereof) that provides resource - records to resolvers. All references in this document to "a name - server" imply "the name server's role"; in some cases the name - server's role and the resolver's role might be combined into a single - program. A name server receives DNS protocol queries and sends DNS - protocol replies. A name server neither sends queries nor receives - replies. As a consequence, name servers do not have caches. - Normally, a name server would expect to receive only those queries to - which it could respond with authoritative information. However, if a - - - -Austein & Saperia [Page 3] - -RFC 1612 DNS Resolver MIB May 1994 - - - name server receives a query that it cannot respond to with purely - authoritative information, it may choose to try to obtain the - necessary additional information from a resolver which may or may not - be a separate process. - -3.3. Selected Objects - - Many of the objects included in this memo have been created from - information contained in the DNS specifications [1,2], as amended and - clarified by subsequent host requirements documents [3]. Other - objects have been created based on experience with existing DNS - management tools, expected operational needs, the statistics - generated by existing DNS implementations, and the configuration - files used by existing DNS implementations. These objects have been - ordered into groups as follows: - - o Resolver Configuration Group - - o Resolver Counter Group - - o Resolver Lame Delegation Group - - o Resolver Cache Group - - o Resolver Negative Cache Group - - o Resolver Optional Counter Group - - This information has been converted into a standard form using the - SNMPv2 SMI defined in [9]. For the most part, the descriptions are - influenced by the DNS related RFCs noted above. For example, the - descriptions for counters used for the various types of queries of - DNS records are influenced by the definitions used for the various - record types found in [2]. - -3.4. Textual Conventions - - Several conceptual data types have been introduced as a textual - conventions in the DNS Server MIB document and have been imported - into this MIB module. These additions will facilitate the common - understanding of information used by the DNS. No changes to the SMI - or the SNMP are necessary to support these conventions. - - Readers familiar with MIBs designed to manage entities in the lower - layers of the Internet protocol suite may be surprised at the number - of non-enumerated integers used in this MIB to represent values such - as DNS RR class and type numbers. The reason for this choice is - simple: the DNS itself is designed as an extensible protocol, - - - -Austein & Saperia [Page 4] - -RFC 1612 DNS Resolver MIB May 1994 - - - allowing new classes and types of resource records to be added to the - protocol without recoding the core DNS software. Using non- - enumerated integers to represent these data types in this MIB allows - the MIB to accommodate these changes as well. - -4. Definitions - - DNS-RESOLVER-MIB DEFINITIONS ::= BEGIN - - IMPORTS - MODULE-IDENTITY, OBJECT-TYPE, IpAddress, Counter32, Integer32 - FROM SNMPv2-SMI - TEXTUAL-CONVENTION, RowStatus, DisplayString - FROM SNMPv2-TC - MODULE-COMPLIANCE, OBJECT-GROUP - FROM SNMPv2-CONF - dns, DnsName, DnsNameAsIndex, DnsClass, DnsType, DnsQClass, - DnsQType, DnsTime, DnsOpCode, DnsRespCode - FROM DNS-SERVER-MIB; - - -- DNS Resolver MIB - - dnsResMIB MODULE-IDENTITY - LAST-UPDATED "9401282250Z" - ORGANIZATION "IETF DNS Working Group" - CONTACT-INFO - " Rob Austein - Postal: Epilogue Technology Corporation - 268 Main Street, Suite 283 - North Reading, MA 10864 - US - Tel: +1 617 245 0804 - Fax: +1 617 245 8122 - E-Mail: sra@epilogue.com - - Jon Saperia - Postal: Digital Equipment Corporation - 110 Spit Brook Road - ZKO1-3/H18 - Nashua, NH 03062-2698 - US - Tel: +1 603 881 0480 - Fax: +1 603 881 0120 - E-mail: saperia@zko.dec.com" - DESCRIPTION - "The MIB module for entities implementing the client - (resolver) side of the Domain Name System (DNS) - protocol." - - - -Austein & Saperia [Page 5] - -RFC 1612 DNS Resolver MIB May 1994 - - - ::= { dns 2 } - - dnsResMIBObjects OBJECT IDENTIFIER ::= { dnsResMIB 1 } - - -- (Old-style) groups in the DNS resolver MIB. - - dnsResConfig OBJECT IDENTIFIER ::= { dnsResMIBObjects 1 } - dnsResCounter OBJECT IDENTIFIER ::= { dnsResMIBObjects 2 } - dnsResLameDelegation OBJECT IDENTIFIER ::= { dnsResMIBObjects 3 } - dnsResCache OBJECT IDENTIFIER ::= { dnsResMIBObjects 4 } - dnsResNCache OBJECT IDENTIFIER ::= { dnsResMIBObjects 5 } - dnsResOptCounter OBJECT IDENTIFIER ::= { dnsResMIBObjects 6 } - - - -- Resolver Configuration Group - - dnsResConfigImplementIdent OBJECT-TYPE - SYNTAX DisplayString - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The implementation identification string for the - resolver software in use on the system, for example; - `RES-2.1'" - ::= { dnsResConfig 1 } - - dnsResConfigService OBJECT-TYPE - SYNTAX INTEGER { recursiveOnly(1), - iterativeOnly(2), - recursiveAndIterative(3) } - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Kind of DNS resolution service provided: - - recursiveOnly(1) indicates a stub resolver. - - iterativeOnly(2) indicates a normal full service - resolver. - - recursiveAndIterative(3) indicates a full-service - resolver which performs a mix of recursive and iterative - queries." - ::= { dnsResConfig 2 } - - dnsResConfigMaxCnames OBJECT-TYPE - SYNTAX INTEGER (0..2147483647) - MAX-ACCESS read-write - - - -Austein & Saperia [Page 6] - -RFC 1612 DNS Resolver MIB May 1994 - - - STATUS current - DESCRIPTION - "Limit on how many CNAMEs the resolver should allow - before deciding that there's a CNAME loop. Zero means - that resolver has no explicit CNAME limit." - REFERENCE - "RFC-1035 section 7.1." - ::= { dnsResConfig 3 } - - -- DNS Resolver Safety Belt Table - - dnsResConfigSbeltTable OBJECT-TYPE - SYNTAX SEQUENCE OF DnsResConfigSbeltEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Table of safety belt information used by the resolver - when it hasn't got any better idea of where to send a - query, such as when the resolver is booting or is a stub - resolver." - ::= { dnsResConfig 4 } - - dnsResConfigSbeltEntry OBJECT-TYPE - SYNTAX DnsResConfigSbeltEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry in the resolver's Sbelt table. - Rows may be created or deleted at any time by the DNS - resolver and by SNMP SET requests. Whether the values - changed via SNMP are saved in stable storage across - `reset' operations is implementation-specific." - INDEX { dnsResConfigSbeltAddr, - dnsResConfigSbeltSubTree, - dnsResConfigSbeltClass } - ::= { dnsResConfigSbeltTable 1 } - - DnsResConfigSbeltEntry ::= - SEQUENCE { - dnsResConfigSbeltAddr - IpAddress, - dnsResConfigSbeltName - DnsName, - dnsResConfigSbeltRecursion - INTEGER, - dnsResConfigSbeltPref - INTEGER, - dnsResConfigSbeltSubTree - - - -Austein & Saperia [Page 7] - -RFC 1612 DNS Resolver MIB May 1994 - - - DnsNameAsIndex, - dnsResConfigSbeltClass - DnsClass, - dnsResConfigSbeltStatus - RowStatus - } - - dnsResConfigSbeltAddr OBJECT-TYPE - SYNTAX IpAddress - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The IP address of the Sbelt name server identified by - this row of the table." - ::= { dnsResConfigSbeltEntry 1 } - - dnsResConfigSbeltName OBJECT-TYPE - SYNTAX DnsName - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The DNS name of a Sbelt nameserver identified by this - row of the table. A zero-length string indicates that - the name is not known by the resolver." - ::= { dnsResConfigSbeltEntry 2 } - - dnsResConfigSbeltRecursion OBJECT-TYPE - SYNTAX INTEGER { iterative(1), - recursive(2), - recursiveAndIterative(3) } - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "Kind of queries resolver will be sending to the name - server identified in this row of the table: - - iterative(1) indicates that resolver will be directing - iterative queries to this name server (RD bit turned - off). - - recursive(2) indicates that resolver will be directing - recursive queries to this name server (RD bit turned - on). - - recursiveAndIterative(3) indicates that the resolver - will be directing both recursive and iterative queries - to the server identified in this row of the table." - ::= { dnsResConfigSbeltEntry 3 } - - - -Austein & Saperia [Page 8] - -RFC 1612 DNS Resolver MIB May 1994 - - - dnsResConfigSbeltPref OBJECT-TYPE - SYNTAX INTEGER (0..2147483647) - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "This value identifies the preference for the name server - identified in this row of the table. The lower the - value, the more desirable the resolver considers this - server." - ::= { dnsResConfigSbeltEntry 4 } - - dnsResConfigSbeltSubTree OBJECT-TYPE - SYNTAX DnsNameAsIndex - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Queries sent to the name server identified by this row - of the table are limited to those for names in the name - subtree identified by this variable. If no such - limitation applies, the value of this variable is the - name of the root domain (a DNS name consisting of a - single zero octet)." - ::= { dnsResConfigSbeltEntry 5 } - - dnsResConfigSbeltClass OBJECT-TYPE - SYNTAX DnsClass - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The class of DNS queries that will be sent to the server - identified by this row of the table." - ::= { dnsResConfigSbeltEntry 6 } - - dnsResConfigSbeltStatus OBJECT-TYPE - SYNTAX RowStatus - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "Row status column for this row of the Sbelt table." - ::= { dnsResConfigSbeltEntry 7 } - - dnsResConfigUpTime OBJECT-TYPE - SYNTAX DnsTime - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "If the resolver has a persistent state (e.g., a - process), this value will be the time elapsed since it - - - -Austein & Saperia [Page 9] - -RFC 1612 DNS Resolver MIB May 1994 - - - started. For software without persistant state, this - value will be 0." - ::= { dnsResConfig 5 } - - dnsResConfigResetTime OBJECT-TYPE - SYNTAX DnsTime - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "If the resolver has a persistent state (e.g., a process) - and supports a `reset' operation (e.g., can be told to - re-read configuration files), this value will be the - time elapsed since the last time the resolver was - `reset.' For software that does not have persistence or - does not support a `reset' operation, this value will be - zero." - ::= { dnsResConfig 6 } - - dnsResConfigReset OBJECT-TYPE - SYNTAX INTEGER { other(1), - reset(2), - initializing(3), - running(4) } - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "Status/action object to reinitialize any persistant - resolver state. When set to reset(2), any persistant - resolver state (such as a process) is reinitialized as if - the resolver had just been started. This value will - never be returned by a read operation. When read, one of - the following values will be returned: - other(1) - resolver in some unknown state; - initializing(3) - resolver (re)initializing; - running(4) - resolver currently running." - ::= { dnsResConfig 7 } - - - -- Resolver Counters Group - - -- Resolver Counter Table - - dnsResCounterByOpcodeTable OBJECT-TYPE - SYNTAX SEQUENCE OF DnsResCounterByOpcodeEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Table of the current count of resolver queries and - - - -Austein & Saperia [Page 10] - -RFC 1612 DNS Resolver MIB May 1994 - - - answers." - ::= { dnsResCounter 3 } - - dnsResCounterByOpcodeEntry OBJECT-TYPE - SYNTAX DnsResCounterByOpcodeEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Entry in the resolver counter table. Entries are - indexed by DNS OpCode." - INDEX { dnsResCounterByOpcodeCode } - ::= { dnsResCounterByOpcodeTable 1 } - - DnsResCounterByOpcodeEntry ::= - SEQUENCE { - dnsResCounterByOpcodeCode - DnsOpCode, - dnsResCounterByOpcodeQueries - Counter32, - dnsResCounterByOpcodeResponses - Counter32 - } - - dnsResCounterByOpcodeCode OBJECT-TYPE - SYNTAX DnsOpCode - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The index to this table. The OpCodes that have already - been defined are found in RFC-1035." - REFERENCE - "RFC-1035 section 4.1.1." - ::= { dnsResCounterByOpcodeEntry 1 } - - dnsResCounterByOpcodeQueries OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Total number of queries that have sent out by the - resolver since initialization for the OpCode which is - the index to this row of the table." - ::= { dnsResCounterByOpcodeEntry 2 } - - dnsResCounterByOpcodeResponses OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - - - -Austein & Saperia [Page 11] - -RFC 1612 DNS Resolver MIB May 1994 - - - DESCRIPTION - "Total number of responses that have been received by the - resolver since initialization for the OpCode which is - the index to this row of the table." - ::= { dnsResCounterByOpcodeEntry 3 } - - -- Resolver Response Code Counter Table - - dnsResCounterByRcodeTable OBJECT-TYPE - SYNTAX SEQUENCE OF DnsResCounterByRcodeEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Table of the current count of responses to resolver - queries." - ::= { dnsResCounter 4 } - - dnsResCounterByRcodeEntry OBJECT-TYPE - SYNTAX DnsResCounterByRcodeEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Entry in the resolver response table. Entries are - indexed by DNS response code." - INDEX { dnsResCounterByRcodeCode } - ::= { dnsResCounterByRcodeTable 1 } - - DnsResCounterByRcodeEntry ::= - SEQUENCE { - dnsResCounterByRcodeCode - DnsRespCode, - dnsResCounterByRcodeResponses - Counter32 - } - - dnsResCounterByRcodeCode OBJECT-TYPE - SYNTAX DnsRespCode - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The index to this table. The Response Codes that have - already been defined are found in RFC-1035." - REFERENCE - "RFC-1035 section 4.1.1." - ::= { dnsResCounterByRcodeEntry 1 } - - - - - - -Austein & Saperia [Page 12] - -RFC 1612 DNS Resolver MIB May 1994 - - - dnsResCounterByRcodeResponses OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of responses the resolver has received for the - response code value which identifies this row of the - table." - ::= { dnsResCounterByRcodeEntry 2 } - - -- Additional DNS Resolver Counter Objects - - dnsResCounterNonAuthDataResps OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests made by the resolver for which a - non-authoritative answer (cached data) was received." - ::= { dnsResCounter 5 } - - dnsResCounterNonAuthNoDataResps OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests made by the resolver for which a - non-authoritative answer - no such data response (empty - answer) was received." - ::= { dnsResCounter 6 } - - dnsResCounterMartians OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of responses received which were received from - servers that the resolver does not think it asked." - ::= { dnsResCounter 7 } - - dnsResCounterRecdResponses OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of responses received to all queries." - ::= { dnsResCounter 8 } - - - - -Austein & Saperia [Page 13] - -RFC 1612 DNS Resolver MIB May 1994 - - - dnsResCounterUnparseResps OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of responses received which were unparseable." - ::= { dnsResCounter 9 } - - dnsResCounterFallbacks OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of times the resolver had to fall back to its - seat belt information." - ::= { dnsResCounter 10 } - - - -- Lame Delegation Group - - dnsResLameDelegationOverflows OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of times the resolver attempted to add an entry - to the Lame Delegation table but was unable to for some - reason such as space constraints." - ::= { dnsResLameDelegation 1 } - - -- Lame Delegation Table - - dnsResLameDelegationTable OBJECT-TYPE - SYNTAX SEQUENCE OF DnsResLameDelegationEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Table of name servers returning lame delegations. - - A lame delegation has occured when a parent zone - delegates authority for a child zone to a server that - appears not to think that it is authoritative for the - child zone in question." - ::= { dnsResLameDelegation 2 } - - dnsResLameDelegationEntry OBJECT-TYPE - SYNTAX DnsResLameDelegationEntry - MAX-ACCESS not-accessible - - - -Austein & Saperia [Page 14] - -RFC 1612 DNS Resolver MIB May 1994 - - - STATUS current - DESCRIPTION - "Entry in lame delegation table. Only the resolver may - create rows in this table. SNMP SET requests may be used - to delete rows." - INDEX { dnsResLameDelegationSource, - dnsResLameDelegationName, - dnsResLameDelegationClass } - ::= { dnsResLameDelegationTable 1 } - - DnsResLameDelegationEntry ::= - SEQUENCE { - dnsResLameDelegationSource - IpAddress, - dnsResLameDelegationName - DnsNameAsIndex, - dnsResLameDelegationClass - DnsClass, - dnsResLameDelegationCounts - Counter32, - dnsResLameDelegationStatus - RowStatus - } - - dnsResLameDelegationSource OBJECT-TYPE - SYNTAX IpAddress - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Source of lame delegation." - ::= { dnsResLameDelegationEntry 1 } - - dnsResLameDelegationName OBJECT-TYPE - SYNTAX DnsNameAsIndex - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "DNS name for which lame delegation was received." - ::= { dnsResLameDelegationEntry 2 } - - dnsResLameDelegationClass OBJECT-TYPE - SYNTAX DnsClass - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "DNS class of received lame delegation." - ::= { dnsResLameDelegationEntry 3 } - - - - -Austein & Saperia [Page 15] - -RFC 1612 DNS Resolver MIB May 1994 - - - dnsResLameDelegationCounts OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "How many times this lame delegation has been received." - ::= { dnsResLameDelegationEntry 4 } - - dnsResLameDelegationStatus OBJECT-TYPE - SYNTAX RowStatus - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "Status column for the lame delegation table. Since only - the agent (DNS resolver) creates rows in this table, the - only values that a manager may write to this variable - are active(1) and destroy(6)." - ::= { dnsResLameDelegationEntry 5 } - - - -- Resolver Cache Group - - dnsResCacheStatus OBJECT-TYPE - SYNTAX INTEGER { enabled(1), disabled(2), clear(3) } - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "Status/action for the resolver's cache. - - enabled(1) means that the use of the cache is allowed. - Query operations can return this state. - - disabled(2) means that the cache is not being used. - Query operations can return this state. - - Setting this variable to clear(3) deletes the entire - contents of the resolver's cache, but does not otherwise - change the resolver's state. The status will retain its - previous value from before the clear operation (i.e., - enabled(1) or disabled(2)). The value of clear(3) can - NOT be returned by a query operation." - ::= { dnsResCache 1 } - - dnsResCacheMaxTTL OBJECT-TYPE - SYNTAX DnsTime - MAX-ACCESS read-write - STATUS current - DESCRIPTION - - - -Austein & Saperia [Page 16] - -RFC 1612 DNS Resolver MIB May 1994 - - - "Maximum Time-To-Live for RRs in this cache. If the - resolver does not implement a TTL ceiling, the value of - this field should be zero." - ::= { dnsResCache 2 } - - dnsResCacheGoodCaches OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of RRs the resolver has cached successfully." - ::= { dnsResCache 3 } - - dnsResCacheBadCaches OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of RRs the resolver has refused to cache because - they appear to be dangerous or irrelevant. E.g., RRs - with suspiciously high TTLs, unsolicited root - information, or that just don't appear to be relevant to - the question the resolver asked." - ::= { dnsResCache 4 } - - -- Resolver Cache Table - - dnsResCacheRRTable OBJECT-TYPE - SYNTAX SEQUENCE OF DnsResCacheRREntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "This table contains information about all the resource - records currently in the resolver's cache." - ::= { dnsResCache 5 } - - dnsResCacheRREntry OBJECT-TYPE - SYNTAX DnsResCacheRREntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry in the resolvers's cache. Rows may be created - only by the resolver. SNMP SET requests may be used to - delete rows." - INDEX { dnsResCacheRRName, - dnsResCacheRRClass, - dnsResCacheRRType, - dnsResCacheRRIndex } - - - -Austein & Saperia [Page 17] - -RFC 1612 DNS Resolver MIB May 1994 - - - ::= { dnsResCacheRRTable 1 } - - DnsResCacheRREntry ::= - SEQUENCE { - dnsResCacheRRName - DnsNameAsIndex, - dnsResCacheRRClass - DnsClass, - dnsResCacheRRType - DnsType, - dnsResCacheRRTTL - DnsTime, - dnsResCacheRRElapsedTTL - DnsTime, - dnsResCacheRRSource - IpAddress, - dnsResCacheRRData - OCTET STRING, - dnsResCacheRRStatus - RowStatus, - dnsResCacheRRIndex - Integer32, - dnsResCacheRRPrettyName - DnsName - } - - dnsResCacheRRName OBJECT-TYPE - SYNTAX DnsNameAsIndex - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Owner name of the Resource Record in the cache which is - identified in this row of the table. As described in - RFC-1034, the owner of the record is the domain name - were the RR is found." - REFERENCE - "RFC-1034 section 3.6." - ::= { dnsResCacheRREntry 1 } - - dnsResCacheRRClass OBJECT-TYPE - SYNTAX DnsClass - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "DNS class of the Resource Record in the cache which is - identified in this row of the table." - ::= { dnsResCacheRREntry 2 } - - - - -Austein & Saperia [Page 18] - -RFC 1612 DNS Resolver MIB May 1994 - - - dnsResCacheRRType OBJECT-TYPE - SYNTAX DnsType - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "DNS type of the Resource Record in the cache which is - identified in this row of the table." - ::= { dnsResCacheRREntry 3 } - - dnsResCacheRRTTL OBJECT-TYPE - SYNTAX DnsTime - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Time-To-Live of RR in DNS cache. This is the initial - TTL value which was received with the RR when it was - originally received." - ::= { dnsResCacheRREntry 4 } - - dnsResCacheRRElapsedTTL OBJECT-TYPE - SYNTAX DnsTime - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Elapsed seconds since RR was received." - ::= { dnsResCacheRREntry 5 } - - dnsResCacheRRSource OBJECT-TYPE - SYNTAX IpAddress - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Host from which RR was received, 0.0.0.0 if unknown." - ::= { dnsResCacheRREntry 6 } - - dnsResCacheRRData OBJECT-TYPE - SYNTAX OCTET STRING - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "RDATA portion of a cached RR. The value is in the - format defined for the particular DNS class and type of - the resource record." - REFERENCE - "RFC-1035 section 3.2.1." - ::= { dnsResCacheRREntry 7 } - - - - - -Austein & Saperia [Page 19] - -RFC 1612 DNS Resolver MIB May 1994 - - - dnsResCacheRRStatus OBJECT-TYPE - SYNTAX RowStatus - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "Status column for the resolver cache table. Since only - the agent (DNS resolver) creates rows in this table, the - only values that a manager may write to this variable - are active(1) and destroy(6)." - ::= { dnsResCacheRREntry 8 } - - dnsResCacheRRIndex OBJECT-TYPE - SYNTAX Integer32 - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A value which makes entries in the table unique when the - other index values (dnsResCacheRRName, - dnsResCacheRRClass, and dnsResCacheRRType) do not - provide a unique index." - ::= { dnsResCacheRREntry 9 } - - dnsResCacheRRPrettyName OBJECT-TYPE - SYNTAX DnsName - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Name of the RR at this row in the table. This is - identical to the dnsResCacheRRName variable, except that - character case is preserved in this variable, per DNS - conventions." - REFERENCE - "RFC-1035 section 2.3.3." - ::= { dnsResCacheRREntry 10 } - - -- Resolver Negative Cache Group - - dnsResNCacheStatus OBJECT-TYPE - SYNTAX INTEGER { enabled(1), disabled(2), clear(3) } - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "Status/action for the resolver's negative response - cache. - - enabled(1) means that the use of the negative response - cache is allowed. Query operations can return this - state. - - - -Austein & Saperia [Page 20] - -RFC 1612 DNS Resolver MIB May 1994 - - - disabled(2) means that the negative response cache is - not being used. Query operations can return this state. - - Setting this variable to clear(3) deletes the entire - contents of the resolver's negative response cache. The - status will retain its previous value from before the - clear operation (i.e., enabled(1) or disabled(2)). The - value of clear(3) can NOT be returned by a query - operation." - ::= { dnsResNCache 1 } - - dnsResNCacheMaxTTL OBJECT-TYPE - SYNTAX DnsTime - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "Maximum Time-To-Live for cached authoritative errors. - If the resolver does not implement a TTL ceiling, the - value of this field should be zero." - ::= { dnsResNCache 2 } - - dnsResNCacheGoodNCaches OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of authoritative errors the resolver has cached - successfully." - ::= { dnsResNCache 3 } - - dnsResNCacheBadNCaches OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of authoritative errors the resolver would have - liked to cache but was unable to because the appropriate - SOA RR was not supplied or looked suspicious." - REFERENCE - "RFC-1034 section 4.3.4." - ::= { dnsResNCache 4 } - - -- Resolver Negative Cache Table - - dnsResNCacheErrTable OBJECT-TYPE - SYNTAX SEQUENCE OF DnsResNCacheErrEntry - MAX-ACCESS not-accessible - STATUS current - - - -Austein & Saperia [Page 21] - -RFC 1612 DNS Resolver MIB May 1994 - - - DESCRIPTION - "The resolver's negative response cache. This table - contains information about authoritative errors that - have been cached by the resolver." - ::= { dnsResNCache 5 } - - dnsResNCacheErrEntry OBJECT-TYPE - SYNTAX DnsResNCacheErrEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry in the resolver's negative response cache - table. Only the resolver can create rows. SNMP SET - requests may be used to delete rows." - INDEX { dnsResNCacheErrQName, - dnsResNCacheErrQClass, - dnsResNCacheErrQType, - dnsResNCacheErrIndex } - ::= { dnsResNCacheErrTable 1 } - - DnsResNCacheErrEntry ::= - SEQUENCE { - dnsResNCacheErrQName - DnsNameAsIndex, - dnsResNCacheErrQClass - DnsQClass, - dnsResNCacheErrQType - DnsQType, - dnsResNCacheErrTTL - DnsTime, - dnsResNCacheErrElapsedTTL - DnsTime, - dnsResNCacheErrSource - IpAddress, - dnsResNCacheErrCode - INTEGER, - dnsResNCacheErrStatus - RowStatus, - dnsResNCacheErrIndex - Integer32, - dnsResNCacheErrPrettyName - DnsName - } - - dnsResNCacheErrQName OBJECT-TYPE - SYNTAX DnsNameAsIndex - MAX-ACCESS not-accessible - STATUS current - - - -Austein & Saperia [Page 22] - -RFC 1612 DNS Resolver MIB May 1994 - - - DESCRIPTION - "QNAME associated with a cached authoritative error." - REFERENCE - "RFC-1034 section 3.7.1." - ::= { dnsResNCacheErrEntry 1 } - - dnsResNCacheErrQClass OBJECT-TYPE - SYNTAX DnsQClass - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "DNS QCLASS associated with a cached authoritative - error." - ::= { dnsResNCacheErrEntry 2 } - - dnsResNCacheErrQType OBJECT-TYPE - SYNTAX DnsQType - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "DNS QTYPE associated with a cached authoritative error." - ::= { dnsResNCacheErrEntry 3 } - - dnsResNCacheErrTTL OBJECT-TYPE - SYNTAX DnsTime - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Time-To-Live of a cached authoritative error at the time - of the error, it should not be decremented by the number - of seconds since it was received. This should be the - TTL as copied from the MINIMUM field of the SOA that - accompanied the authoritative error, or a smaller value - if the resolver implements a ceiling on negative - response cache TTLs." - REFERENCE - "RFC-1034 section 4.3.4." - ::= { dnsResNCacheErrEntry 4 } - - dnsResNCacheErrElapsedTTL OBJECT-TYPE - SYNTAX DnsTime - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Elapsed seconds since authoritative error was received." - ::= { dnsResNCacheErrEntry 5 } - - - - - -Austein & Saperia [Page 23] - -RFC 1612 DNS Resolver MIB May 1994 - - - dnsResNCacheErrSource OBJECT-TYPE - SYNTAX IpAddress - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Host which sent the authoritative error, 0.0.0.0 if - unknown." - ::= { dnsResNCacheErrEntry 6 } - - dnsResNCacheErrCode OBJECT-TYPE - SYNTAX INTEGER { nonexistantName(1), noData(2), other(3) } - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The authoritative error that has been cached: - - nonexistantName(1) indicates an authoritative name error - (RCODE = 3). - - noData(2) indicates an authoritative response with no - error (RCODE = 0) and no relevant data. - - other(3) indicates some other cached authoritative - error. At present, no such errors are known to exist." - ::= { dnsResNCacheErrEntry 7 } - - dnsResNCacheErrStatus OBJECT-TYPE - SYNTAX RowStatus - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "Status column for the resolver negative response cache - table. Since only the agent (DNS resolver) creates rows - in this table, the only values that a manager may write - to this variable are active(1) and destroy(6)." - ::= { dnsResNCacheErrEntry 8 } - - dnsResNCacheErrIndex OBJECT-TYPE - SYNTAX Integer32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "A value which makes entries in the table unique when the - other index values (dnsResNCacheErrQName, - dnsResNCacheErrQClass, and dnsResNCacheErrQType) do not - provide a unique index." - ::= { dnsResNCacheErrEntry 9 } - - - - -Austein & Saperia [Page 24] - -RFC 1612 DNS Resolver MIB May 1994 - - - dnsResNCacheErrPrettyName OBJECT-TYPE - SYNTAX DnsName - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "QNAME associated with this row in the table. This is - identical to the dnsResNCacheErrQName variable, except - that character case is preserved in this variable, per - DNS conventions." - REFERENCE - "RFC-1035 section 2.3.3." - ::= { dnsResNCacheErrEntry 10 } - - - -- Resolver Optional Counters Group - - dnsResOptCounterReferals OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of responses which were received from servers - redirecting query to another server." - ::= { dnsResOptCounter 1 } - - dnsResOptCounterRetrans OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number requests retransmitted for all reasons." - ::= { dnsResOptCounter 2 } - - dnsResOptCounterNoResponses OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of queries that were retransmitted because of no - response." - ::= { dnsResOptCounter 3 } - - dnsResOptCounterRootRetrans OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of queries that were retransmitted that were to - - - -Austein & Saperia [Page 25] - -RFC 1612 DNS Resolver MIB May 1994 - - - root servers." - ::= { dnsResOptCounter 4 } - - dnsResOptCounterInternals OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests internally generated by the - resolver." - ::= { dnsResOptCounter 5 } - - dnsResOptCounterInternalTimeOuts OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests internally generated which timed - out." - ::= { dnsResOptCounter 6 } - - - -- SNMPv2 groups. - - dnsResMIBGroups OBJECT IDENTIFIER ::= { dnsResMIB 2 } - - dnsResConfigGroup OBJECT-GROUP - OBJECTS { dnsResConfigImplementIdent, - dnsResConfigService, - dnsResConfigMaxCnames, - dnsResConfigSbeltAddr, - dnsResConfigSbeltName, - dnsResConfigSbeltRecursion, - dnsResConfigSbeltPref, - dnsResConfigSbeltSubTree, - dnsResConfigSbeltClass, - dnsResConfigSbeltStatus, - dnsResConfigUpTime, - dnsResConfigResetTime } - STATUS current - DESCRIPTION - "A collection of objects providing basic configuration - information for a DNS resolver implementation." - ::= { dnsResMIBGroups 1 } - - dnsResCounterGroup OBJECT-GROUP - OBJECTS { dnsResCounterByOpcodeCode, - dnsResCounterByOpcodeQueries, - - - -Austein & Saperia [Page 26] - -RFC 1612 DNS Resolver MIB May 1994 - - - dnsResCounterByOpcodeResponses, - dnsResCounterByRcodeCode, - dnsResCounterByRcodeResponses, - dnsResCounterNonAuthDataResps, - dnsResCounterNonAuthNoDataResps, - dnsResCounterMartians, - dnsResCounterRecdResponses, - dnsResCounterUnparseResps, - dnsResCounterFallbacks } - STATUS current - DESCRIPTION - "A collection of objects providing basic instrumentation - of a DNS resolver implementation." - ::= { dnsResMIBGroups 2 } - - dnsResLameDelegationGroup OBJECT-GROUP - OBJECTS { dnsResLameDelegationOverflows, - dnsResLameDelegationSource, - dnsResLameDelegationName, - dnsResLameDelegationClass, - dnsResLameDelegationCounts, - dnsResLameDelegationStatus } - STATUS current - DESCRIPTION - "A collection of objects providing instrumentation of - `lame delegation' failures." - ::= { dnsResMIBGroups 3 } - - - dnsResCacheGroup OBJECT-GROUP - OBJECTS { dnsResCacheStatus, - dnsResCacheMaxTTL, - dnsResCacheGoodCaches, - dnsResCacheBadCaches, - dnsResCacheRRName, - dnsResCacheRRClass, - dnsResCacheRRType, - dnsResCacheRRTTL, - dnsResCacheRRElapsedTTL, - dnsResCacheRRSource, - dnsResCacheRRData, - dnsResCacheRRStatus, - dnsResCacheRRIndex, - dnsResCacheRRPrettyName } - STATUS current - DESCRIPTION - "A collection of objects providing access to and control - of a DNS resolver's cache." - - - -Austein & Saperia [Page 27] - -RFC 1612 DNS Resolver MIB May 1994 - - - ::= { dnsResMIBGroups 4 } - - dnsResNCacheGroup OBJECT-GROUP - OBJECTS { dnsResNCacheStatus, - dnsResNCacheMaxTTL, - dnsResNCacheGoodNCaches, - dnsResNCacheBadNCaches, - dnsResNCacheErrQName, - dnsResNCacheErrQClass, - dnsResNCacheErrQType, - dnsResNCacheErrTTL, - dnsResNCacheErrElapsedTTL, - dnsResNCacheErrSource, - dnsResNCacheErrCode, - dnsResNCacheErrStatus, - dnsResNCacheErrIndex, - dnsResNCacheErrPrettyName } - STATUS current - DESCRIPTION - "A collection of objects providing access to and control - of a DNS resolver's negative response cache." - ::= { dnsResMIBGroups 5 } - - dnsResOptCounterGroup OBJECT-GROUP - OBJECTS { dnsResOptCounterReferals, - dnsResOptCounterRetrans, - dnsResOptCounterNoResponses, - dnsResOptCounterRootRetrans, - dnsResOptCounterInternals, - dnsResOptCounterInternalTimeOuts } - STATUS current - DESCRIPTION - "A collection of objects providing further - instrumentation applicable to many but not all DNS - resolvers." - ::= { dnsResMIBGroups 6 } - - - -- Compliances. - - dnsResMIBCompliances OBJECT IDENTIFIER ::= { dnsResMIB 3 } - - dnsResMIBCompliance MODULE-COMPLIANCE - STATUS current - DESCRIPTION - "The compliance statement for agents implementing the DNS - resolver MIB extensions." - MODULE -- This MIB module - - - -Austein & Saperia [Page 28] - -RFC 1612 DNS Resolver MIB May 1994 - - - MANDATORY-GROUPS { dnsResConfigGroup, dnsResCounterGroup } - GROUP dnsResCacheGroup - DESCRIPTION - "The resolver cache group is mandatory for resolvers that - implement a cache." - GROUP dnsResNCacheGroup - DESCRIPTION - "The resolver negative cache group is mandatory for - resolvers that implement a negative response cache." - GROUP dnsResLameDelegationGroup - DESCRIPTION - "The lame delegation group is unconditionally optional." - GROUP dnsResOptCounterGroup - DESCRIPTION - "The optional counters group is unconditionally - optional." - OBJECT dnsResConfigMaxCnames - MIN-ACCESS read-only - DESCRIPTION - "This object need not be writable." - OBJECT dnsResConfigSbeltName - MIN-ACCESS read-only - DESCRIPTION - "This object need not be writable." - OBJECT dnsResConfigSbeltRecursion - MIN-ACCESS read-only - DESCRIPTION - "This object need not be writable." - OBJECT dnsResConfigSbeltPref - MIN-ACCESS read-only - DESCRIPTION - "This object need not be writable." - OBJECT dnsResConfigReset - MIN-ACCESS read-only - DESCRIPTION - "This object need not be writable." - OBJECT dnsResCacheStatus - MIN-ACCESS read-only - DESCRIPTION - "This object need not be writable." - OBJECT dnsResCacheMaxTTL - MIN-ACCESS read-only - DESCRIPTION - "This object need not be writable." - OBJECT dnsResNCacheStatus - MIN-ACCESS read-only - DESCRIPTION - "This object need not be writable." - - - -Austein & Saperia [Page 29] - -RFC 1612 DNS Resolver MIB May 1994 - - - OBJECT dnsResNCacheMaxTTL - MIN-ACCESS read-only - DESCRIPTION - "This object need not be writable." - ::= { dnsResMIBCompliances 1 } - - END - -5. Acknowledgements - - This document is the result of work undertaken the by DNS working - group. The authors would particularly like to thank the following - people for their contributions to this document: Philip Almquist, - Frank Kastenholz (FTP Software), Joe Peck (DEC), Dave Perkins - (SynOptics), Win Treese (DEC), and Mimi Zohar (IBM). - -6. References - - [1] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD - 13, RFC 1034, USC/Information Sciences Institute, November 1987. - - [2] Mockapetris, P., "Domain Names -- Implementation and - Specification", STD 13, RFC 1035, USC/Information Sciences - Institute, November 1987. - - [3] Braden, R., Editor, "Requirements for Internet Hosts -- - Application and Support, STD 3, RFC 1123, USC/Information - Sciences Institute, October 1989. - - [4] Rose, M., and K. McCloghrie, "Structure and Identification of - Management Information for TCP/IP-based internets", STD 16, RFC - 1155, Performance Systems International, Hughes LAN Systems, May - 1990. - - [5] McCloghrie, K., and M. Rose, "Management Information Base for - Network Management of TCP/IP-based internets", RFC 1156, Hughes - LAN Systems, Performance Systems International, May 1990. - - [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple - Network Management Protocol", STD 15, RFC 1157, SNMP Research, - Performance Systems International, Performance Systems - International, MIT Laboratory for Computer Science, May 1990. - - [7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", - STD 16, RFC 1212, Performance Systems International, Hughes LAN - Systems, March 1991. - - - - - -Austein & Saperia [Page 30] - -RFC 1612 DNS Resolver MIB May 1994 - - - [8] McCloghrie, K., and M. Rose, "Management Information Base for - Network Management of TCP/IP-based internets: MIB-II", STD 17, - RFC 1213, Hughes LAN Systems, Performance Systems International, - March 1991. - - [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure - of Management Information for version 2 of the Simple Network - Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc., - Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon - University, April 1993. - - [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual - Conventions for version 2 of the the Simple Network Management - Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN - Systems, Dover Beach Consulting, Inc., Carnegie Mellon - University, April 1993. - - [11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, - "Conformance Statements for version 2 of the the Simple Network - Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc., - Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon - University, April 1993. - - [12] Galvin, J., and K. McCloghrie, "Administrative Model for version - 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445, - Trusted Information Systems, Hughes LAN Systems, April 1993. - - [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol - Operations for version 2 of the Simple Network Management - Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN - Systems, Dover Beach Consulting, Inc., Carnegie Mellon - University, April 1993. - - [14] "Information processing systems - Open Systems Interconnection - - Specification of Abstract Syntax Notation One (ASN.1)", - International Organization for Standardization, International - Standard 8824, December 1987. - - - - - - - - - - - - - - -Austein & Saperia [Page 31] - -RFC 1612 DNS Resolver MIB May 1994 - - -7. Security Considerations - - Security issues are not discussed in this memo. - -8. Authors' Addresses - - Rob Austein - Epilogue Technology Corporation - 268 Main Street, Suite 283 - North Reading, MA 01864 - USA - - Phone: +1-617-245-0804 - Fax: +1-617-245-8122 - EMail: sra@epilogue.com - - - Jon Saperia - Digital Equipment Corporation - 110 Spit Brook Road - ZKO1-3/H18 - Nashua, NH 03062-2698 - USA - - Phone: +1-603-881-0480 - Fax: +1-603-881-0120 - EMail: saperia@zko.dec.com - - - - - - - - - - - - - - - - - - - - - - - - -Austein & Saperia [Page 32] - diff --git a/contrib/bind9/doc/rfc/rfc1706.txt b/contrib/bind9/doc/rfc/rfc1706.txt deleted file mode 100644 index 5b5d82194aff..000000000000 --- a/contrib/bind9/doc/rfc/rfc1706.txt +++ /dev/null @@ -1,563 +0,0 @@ - - - - - - -Network Working Group B. Manning -Request for Comments: 1706 ISI -Obsoletes: 1637, 1348 R. Colella -Category: Informational NIST - October 1994 - - - DNS NSAP Resource Records - - -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. - -Abstract - - OSI lower layer protocols, comprising the connectionless network - protocol (CLNP) and supporting routing protocols, are deployed in - some parts of the global Internet. Maintenance and debugging of CLNP - connectivity is greatly aided by support in the Domain Name System - (DNS) for mapping between names and NSAP addresses. - - This document defines the format of one new Resource Record (RR) for - the DNS for domain name-to-NSAP mapping. The RR may be used with any - NSAP address format. - - NSAP-to-name translation is accomplished through use of the PTR RR - (see STD 13, RFC 1035 for a description of the PTR RR). This paper - describes how PTR RRs are used to support this translation. - - This document obsoletes RFC 1348 and RFC 1637. - - - - - - - - - - - - - - - - - - -Manning & Colella [Page 1] - -RFC 1706 DNS NSAP RRs October 1994 - - -1. Introduction - - OSI lower layer protocols, comprising the connectionless network - protocol (CLNP) [5] and supporting routing protocols, are deployed in - some parts of the global Internet. Maintenance and debugging of CLNP - connectivity is greatly aided by support in the Domain Name System - (DNS) [7] [8] for mapping between names and NSAP (network service - access point) addresses [6] [Note: NSAP and NSAP address are used - interchangeably throughout this memo]. - - This document defines the format of one new Resource Record (RR) for - the DNS for domain name-to-NSAP mapping. The RR may be used with any - NSAP address format. - - NSAP-to-name translation is accomplished through use of the PTR RR - (see RFC 1035 for a description of the PTR RR). This paper describes - how PTR RRs are used to support this translation. - - This memo assumes that the reader is familiar with the DNS. Some - familiarity with NSAPs is useful; see [1] or Annex A of [6] for - additional information. - -2. Background - - The reason for defining DNS mappings for NSAPs is to support the - existing CLNP deployment in the Internet. Debugging with CLNP ping - and traceroute has become more difficult with only numeric NSAPs as - the scale of deployment has increased. Current debugging is supported - by maintaining and exchanging a configuration file with name/NSAP - mappings similar in function to hosts.txt. This suffers from the lack - of a central coordinator for this file and also from the perspective - of scaling. The former describes the most serious short-term - problem. Scaling of a hosts.txt-like solution has well-known long- - term scaling difficiencies. - -3. Scope - - The methods defined in this paper are applicable to all NSAP formats. - - As a point of reference, there is a distinction between registration - and publication of addresses. For IP addresses, the IANA is the root - registration authority and the DNS a publication method. For NSAPs, - Annex A of the network service definition, ISO8348 [6], describes the - root registration authority and this memo defines how the DNS is used - as a publication method. - - - - - - -Manning & Colella [Page 2] - -RFC 1706 DNS NSAP RRs October 1994 - - -4. Structure of NSAPs - - NSAPs are hierarchically structured to allow distributed - administration and efficient routing. Distributed administration - permits subdelegated addressing authorities to, as allowed by the - delegator, further structure the portion of the NSAP space under - their delegated control. Accomodating this distributed authority - requires that there be little or no a priori knowledge of the - structure of NSAPs built into DNS resolvers and servers. - - For the purposes of this memo, NSAPs can be thought of as a tree of - identifiers. The root of the tree is ISO8348 [6], and has as its - immediately registered subordinates the one-octet Authority and - Format Identifiers (AFIs) defined there. The size of subsequently- - defined fields depends on which branch of the tree is taken. The - depth of the tree varies according to the authority responsible for - defining subsequent fields. - - An example is the authority under which U.S. GOSIP defines NSAPs [2]. - Under the AFI of 47, NIST (National Institute of Standards and - Technology) obtained a value of 0005 (the AFI of 47 defines the next - field as being two octets consisting of four BCD digits from the - International Code Designator space [3]). NIST defined the subsequent - fields in [2], as shown in Figure 1. The field immediately following - 0005 is a format identifier for the rest of the U.S. GOSIP NSAP - structure, with a hex value of 80. Following this is the three-octet - field, values for which are allocated to network operators; the - registration authority for this field is delegated to GSA (General - Services Administration). - - The last octet of the NSAP is the NSelector (NSel). In practice, the - NSAP minus the NSel identifies the CLNP protocol machine on a given - system, and the NSel identifies the CLNP user. Since there can be - more than one CLNP user (meaning multiple NSel values for a given - "base" NSAP), the representation of the NSAP should be CLNP-user - independent. To achieve this, an NSel value of zero shall be used - with all NSAP values stored in the DNS. An NSAP with NSel=0 - identifies the network layer itself. It is left to the application - retrieving the NSAP to determine the appropriate value to use in that - instance of communication. - - When CLNP is used to support TCP and UDP services, the NSel value - used is the appropriate IP PROTO value as registered with the IANA. - For "standard" OSI, the selection of NSel values is left as a matter - of local administration. Administrators of systems that support the - OSI transport protocol [4] in addition to TCP/UDP must select NSels - for use by OSI Transport that do not conflict with the IP PROTO - values. - - - -Manning & Colella [Page 3] - -RFC 1706 DNS NSAP RRs October 1994 - - - |--------------| - | <-- IDP --> | - |--------------|-------------------------------------| - | AFI | IDI | <-- DSP --> | - |-----|--------|-------------------------------------| - | 47 | 0005 | DFI | AA |Rsvd | RD |Area | ID |Sel | - |-----|--------|-----|----|-----|----|-----|----|----| - octets | 1 | 2 | 1 | 3 | 2 | 2 | 2 | 6 | 1 | - |-----|--------|-----|----|-----|----|-----|----|----| - - IDP Initial Domain Part - AFI Authority and Format Identifier - IDI Initial Domain Identifier - DSP Domain Specific Part - DFI DSP Format Identifier - AA Administrative Authority - Rsvd Reserved - RD Routing Domain Identifier - Area Area Identifier - ID System Identifier - SEL NSAP Selector - - Figure 1: GOSIP Version 2 NSAP structure. - - - In the NSAP RRs in Master Files and in the printed text in this memo, - NSAPs are often represented as a string of "."-separated hex values. - The values correspond to convenient divisions of the NSAP to make it - more readable. For example, the "."-separated fields might correspond - to the NSAP fields as defined by the appropriate authority (RARE, - U.S. GOSIP, ANSI, etc.). The use of this notation is strictly for - readability. The "."s do not appear in DNS packets and DNS servers - can ignore them when reading Master Files. For example, a printable - representation of the first four fields of a U.S. GOSIP NSAP might - look like - - 47.0005.80.005a00 - - and a full U.S. GOSIP NSAP might appear as - - 47.0005.80.005a00.0000.1000.0020.00800a123456.00. - - Other NSAP formats have different lengths and different - administratively defined field widths to accomodate different - requirements. For more information on NSAP formats in use see RFC - 1629 [1]. - - - - - -Manning & Colella [Page 4] - -RFC 1706 DNS NSAP RRs October 1994 - - -5. The NSAP RR - - The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22 - (decimal) and is used to map from domain names to NSAPs. Name-to-NSAP - mapping in the DNS using the NSAP RR operates analogously to IP - address lookup. A query is generated by the resolver requesting an - NSAP RR for a provided domain name. - - NSAP RRs conform to the top level RR format and semantics as defined - in Section 3.2.1 of RFC 1035. - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | | - / / - / NAME / - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | TYPE = NSAP | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | CLASS = IN | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | TTL | - | | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | RDLENGTH | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / RDATA / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - where: - - * NAME: an owner name, i.e., the name of the node to which this - resource record pertains. - - * TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal). - - * CLASS: two octets containing the RR IN CLASS code of 1. - - * TTL: a 32 bit signed integer that specifies the time interval in - seconds 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. - - - -Manning & Colella [Page 5] - -RFC 1706 DNS NSAP RRs October 1994 - - - * RDLENGTH: an unsigned 16 bit integer that specifies the length in - octets of the RDATA field. - - * RDATA: a variable length string of octets containing the NSAP. - The value is the binary encoding of the NSAP as it would appear in - the CLNP source or destination address field. A typical example of - such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is - 20 (decimal); "."s have been omitted to emphasize that they don't - appear in the DNS packets. - - 39840f80005a0000000001e13708002010726e00 - - NSAP RRs cause no additional section processing. - -6. NSAP-to-name Mapping Using the PTR RR - - The PTR RR is defined in RFC 1035. This RR is typically used under - the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names. - - Similarly, the PTR RR is used to map from NSAPs to domain names under - the "NSAP.INT" domain. A domain name is generated from the NSAP - according to the rules described below. A query is sent by the - resolver requesting a PTR RR for the provided domain name. - - A domain name is generated from an NSAP by reversing the hex nibbles - of the NSAP, treating each nibble as a separate subdomain, and - appending the top-level subdomain name "NSAP.INT" to it. For example, - the domain name used in the reverse lookup for the NSAP - - 47.0005.80.005a00.0000.0001.e133.ffffff000162.00 - - would appear as - - 0.0.2.6.1.0.0.0.f.f.f.f.f.f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0. \ - 0.8.5.0.0.0.7.4.NSAP.INT. - - [Implementation note: For sanity's sake user interfaces should be - designed to allow users to enter NSAPs using their natural order, - i.e., as they are typically written on paper. Also, arbitrary "."s - should be allowed (and ignored) on input.] - -7. Master File Format - - The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files - conforms to Section 5, "Master Files," of RFC 1035. Below are - examples of the use of these RRs in Master Files to support name-to- - NSAP and NSAP-to-name mapping. - - - - -Manning & Colella [Page 6] - -RFC 1706 DNS NSAP RRs October 1994 - - - The NSAP RR introduces a new hex string format for the RDATA field. - The format is "0x" (i.e., a zero followed by an 'x' character) - followed by a variable length string of hex characters (0 to 9, a to - f). The hex string is case-insensitive. "."s (i.e., periods) may be - inserted in the hex string anywhere after the "0x" for readability. - The "."s have no significance other than for readability and are not - propagated in the protocol (e.g., queries or zone transfers). - - - ;;;;;; - ;;;;;; Master File for domain nsap.nist.gov. - ;;;;;; - - - @ IN SOA emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. ( - 1994041800 ; Serial - date - 1800 ; Refresh - 30 minutes - 300 ; Retry - 5 minutes - 604800 ; Expire - 7 days - 3600 ) ; Minimum - 1 hour - IN NS emu.ncsl.nist.gov. - IN NS tuba.nsap.lanl.gov. - ; - ; - $ORIGIN nsap.nist.gov. - ; - ; hosts - ; - bsdi1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00 - IN A 129.6.224.161 - IN HINFO PC_486 BSDi1.1 - ; - bsdi2 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00 - IN A 129.6.224.162 - IN HINFO PC_486 BSDi1.1 - ; - cursive IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00 - IN A 129.6.224.171 - IN HINFO PC_386 DOS_5.0/NCSA_Telnet(TUBA) - ; - infidel IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00 - IN A 129.6.55.164 - IN HINFO PC/486 BSDi1.0(TUBA) - ; - ; routers - ; - cisco1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00 - IN A 129.6.224.151 - - - -Manning & Colella [Page 7] - -RFC 1706 DNS NSAP RRs October 1994 - - - IN A 129.6.225.151 - IN A 129.6.229.151 - ; - 3com1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00 - IN A 129.6.224.111 - IN A 129.6.225.111 - IN A 129.6.228.111 - - - - - ;;;;;; - ;;;;;; Master File for reverse mapping of NSAPs under the - ;;;;;; NSAP prefix: - ;;;;;; - ;;;;;; 47.0005.80.005a00.0000.0001.e133 - ;;;;;; - - - @ IN SOA emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. ( - 1994041800 ; Serial - date - 1800 ; Refresh - 30 minutes - 300 ; Retry - 5 minutes - 604800 ; Expire - 7 days - 3600 ) ; Minimum - 1 hour - IN NS emu.ncsl.nist.gov. - IN NS tuba.nsap.lanl.gov. - ; - ; - $ORIGIN 3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT. - ; - 0.0.1.6.1.0.0.0.f.f.f.f.f.f IN PTR bsdi1.nsap.nist.gov. - ; - 0.0.2.6.1.0.0.0.f.f.f.f.f.f IN PTR bsdi2.nsap.nist.gov. - ; - 0.0.1.7.1.0.0.0.f.f.f.f.f.f IN PTR cursive.nsap.nist.gov. - ; - 0.0.4.6.1.0.0.0.f.f.f.f.f.f IN PTR infidel.nsap.nist.gov. - ; - 0.0.1.5.1.0.0.0.a.a.a.a.a.a IN PTR cisco1.nsap.nist.gov. - ; - 0.0.1.1.1.0.0.0.a.a.a.a.a.a IN PTR 3com1.nsap.nist.gov. - -8. Security Considerations - - Security issues are not discussed in this memo. - - - - - -Manning & Colella [Page 8] - -RFC 1706 DNS NSAP RRs October 1994 - - -9. Authors' Addresses - - Bill Manning - USC/Information Sciences Institute - 4676 Admiralty Way - Marina del Rey, CA. 90292 - USA - - Phone: +1.310.822.1511 - EMail: bmanning@isi.edu - - - Richard Colella - National Institute of Standards and Technology - Technology/B217 - Gaithersburg, MD 20899 - USA - - Phone: +1 301-975-3627 - Fax: +1 301 590-0932 - EMail: colella@nist.gov - -10. References - - [1] Colella, R., Gardner, E., Callon, R., and Y. Rekhter, "Guidelines - for OSI NSAP Allocation inh the Internet", RFC 1629, NIST, - Wellfleet, Mitre, T.J. Watson Research Center, IBM Corp., May - 1994. - - [2] GOSIP Advanced Requirements Group. Government Open Systems - Interconnection Profile (GOSIP) Version 2. Federal Information - Processing Standard 146-1, U.S. Department of Commerce, National - Institute of Standards and Technology, Gaithersburg, MD, April - 1991. - - [3] ISO/IEC. Data interchange - structures for the identification of - organization. International Standard 6523, ISO/IEC JTC 1, - Switzerland, 1984. - - [4] ISO/IEC. Connection oriented transport protocol specification. - International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986. - - [5] ISO/IEC. Protocol for Providing the Connectionless-mode Network - Service. International Standard 8473, ISO/IEC JTC 1, - Switzerland, 1986. - - - - - - -Manning & Colella [Page 9] - -RFC 1706 DNS NSAP RRs October 1994 - - - [6] ISO/IEC. Information Processing Systems -- Data Communications -- - Network Service Definition. International Standard 8348, ISO/IEC - JTC 1, Switzerland, 1993. - - [7] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD - 13, RFC 1034, USC/Information Sciences Institute, November 1987. - - [8] Mockapetris, P., "Domain Names -- Implementation and - Specification", STD 13, RFC 1035, USC/Information Sciences - Institute, November 1987. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Manning & Colella [Page 10] - diff --git a/contrib/bind9/doc/rfc/rfc1712.txt b/contrib/bind9/doc/rfc/rfc1712.txt deleted file mode 100644 index 40d88578e83f..000000000000 --- a/contrib/bind9/doc/rfc/rfc1712.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -Network Working Group C. Farrell -Request for Comments: 1712 M. Schulze -Category: Experimental S. Pleitner - D. Baldoni - Curtin University of Technology - November 1994 - - - DNS Encoding of Geographical Location - -Status of this Memo - - This memo defines an Experimental Protocol for the Internet - community. This memo does not specify an Internet standard of any - kind. Discussion and suggestions for improvement are requested. - Distribution of this memo is unlimited. - -Abstract - - This document defines the format of a new Resource Record (RR) for - the Domain Naming System (DNS), and reserves a corresponding DNS type - mnemonic and numerical code. This definition deals with associating - geographical host location mappings to host names within a domain. - The data shown in this document is fictitious and does not - necessarily reflect the real Internet. - -1. Introduction - - It has been a long standing problem to relate IP numbers to - geographical locations. The availability of Geographical location - information has immediate applications in network management. Such - information can be used to supplement the data already provided by - utilities such as whois [Har85], traceroute [VJ89], and nslookup - [UCB89]. The usefulness and functionality of these already widely - used tools would be greatly enhanced by the provision of reliable - geographical location information. - - The ideal way to manage and maintain a database of information, such - as geographical location of internet hosts, is to delegate - responsibility to local domain administrators. A large distributed - database could be implemented with a simple mechanism for updating - the local information. A query mechanism also has to be available - for checking local entries, as well as inquiring about data from - non-local domains. - - - - - - - -Farrell, Schulze, Pleitner & Baldoni [Page 1] - -RFC 1712 DNS Encoding of Geographical Location November 1994 - - -2. Background - - The Internet continues to grow at an ever increasing rate with IP - numbers allocated on a first-come-first-serve basis. Deciding when - and how to setup a database of geographical information about - internet hosts presented a number of options. The uumap project - [UU85] was the first serious attempt to collect geographical location - data from sites and store it centrally. This project met with - limited success because of the difficulty in maintaining and updating - a large central database. Another problem was the lack of tools for - the checking the data supplied, this problem resulted in some - erroneous data entering the database. - -2.1 SNMP: - - Using an SNMP get request on the sysLocation MIB (Management - Information Base) variable was also an option, however this would - require the host to be running an appropriate agent with public read - access. It was also felt that MIB data should reflect local - management data (e.g., "this" host is on level 5 room 74) rather than - a hosts geographical position. This view is supported in the - examples given in literature in this area [ROSE91]. - -2.2 X500: - - The X.500 Directory service [X.500.88] defined as part of the ISO - standards also appears as a potential provider of geographical - location data. However due to the limited implementations of this - service it was decided to defer this until this service gains wider - use and acceptance within the Internet community. - -2.3 BIND: - - The DNS [Mock87a][Mock87b] represents an existing system ideally - suited to the provision of host specific information. The DNS is a - widely used and well-understood mechanism for providing a distributed - database of such information and its extensible nature allows it to - be used to disseminate virtually any information. The most commonly - used DNS implementation is the Berkeley Internet Name Domain server - BIND [UCB89]. The information we wished to make available needed to - be updated locally but available globally; a perfect match with the - services provided by the DNS. Current DNS servers provide a variety - of useful information about hosts in their domain but lack the - ability to report a host's geographical location. - - - - - - - -Farrell, Schulze, Pleitner & Baldoni [Page 2] - -RFC 1712 DNS Encoding of Geographical Location November 1994 - - -3. RDATA Format - - MSB LSB - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / LONGITUDE / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / LATITUDE / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / ALTITUDE / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - where: - - LONGITUDE The real number describing the longitude encoded as a - printable string. The precision is limited by 256 charcters - within the range -90..90 degrees. Positive numbers - indicate locations north of the equator. - - LATITUDE The real number describing the latitude encoded as a - printable string. The precision is limited by 256 charcters - within the range -180..180 degrees. Positive numbers - indicate locations east of the prime meridian. - - ALTITUDE The real number describing the altitude (in meters) from - mean sea-level encoded as a printable string. The precision - is limited by 256 charcters. Positive numbers indicate - locations above mean sea-level. - - Latitude/Longitude/Altitude values are encoded as strings as to avoid - the precision limitations imposed by encoding as unsigned integers. - Although this might not be considered optimal, it allows for a very - high degree of precision with an acceptable average encoded record - length. - -4. The GPOS RR - - The geographical location is defined with the mnemonic GPOS and type - code 27. - - GPOS has the following format: - <owner> <ttl> <class> GPOS <longitude> <latitude> <altitude> - - A floating point format was chosen to specify geographical locations - for reasons of simplicity. This also guarantees a concise - unambiguous description of a location by enforcing three compulsory - numerical values to be specified. - - - - - -Farrell, Schulze, Pleitner & Baldoni [Page 3] - -RFC 1712 DNS Encoding of Geographical Location November 1994 - - - The owner, ttl, and class fields are optional and default to the last - defined value if omitted. The longitude is a floating point number - ranging from -90 to 90 with positive values indicating locations - north of the equator. For example Perth, Western Australia is - located at 32^ 7` 19" south of the equator which would be specified - as -32.68820. The latitude is a number ranging from -180.0 to 180.0. - For example Perth, Western Australia is located at 116^ 2' 25" east - of the prime meridian which would be specified as 116.86520. Curtin - University, Perth is also 10 meters above sea-level. - - The valid GPOS record for a host at Curtin University in Perth - Western Australia would therefore be: - - GPOS -32.6882 116.8652 10.0 - - There is no limit imposed on the number of decimal places, although - the length of the encoded string is limited to 256 characters for - each field. It is also suggested that administrators limit their - entries to the minimum number of necessary characters in each field. - -5. Master File Format - - Each host requires its own GPOS field in the corresponding DNS RR to - explicitly specify its geographical location and altitude. If the - GPOS field is omitted, a DNS enquiry will return no position - information for that host. - - Consider the following example: - -; Authoritative data for cs.curtin.edu.au. -; -@ IN SOA marsh.cs.curtin.edu.au. postmaster.cs.curtin.edu.au. - ( - 94070503 ; Serial (yymmddnn) - 10800 ; Refresh (3 hours) - 3600 ; Retry (1 hour) - 3600000 ; Expire (1000 hours) - 86400 ; Minimum (24 hours) - ) - - IN NS marsh.cs.curtin.edu.au. - -marsh IN A 134.7.1.1 - IN MX 0 marsh - IN HINFO SGI-Indigo IRIX-4.0.5F - IN GPOS -32.6882 116.8652 10.0 -ftp IN CNAME marsh - - - - -Farrell, Schulze, Pleitner & Baldoni [Page 4] - -RFC 1712 DNS Encoding of Geographical Location November 1994 - - -lillee IN A 134.7.1.2 - IN MX 0 marsh - IN HINFO SGI-Indigo IRIX-4.0.5F - IN GPOS -32.6882 116.8652 10.0 - -hinault IN A 134.7.1.23 - IN MX 0 marsh - IN HINFO SUN-IPC SunOS-4.1.3 - IN GPOS -22.6882 116.8652 250.0 - -merckx IN A 134.7.1.24 - IN MX 0 marsh - IN HINFO SUN-IPC SunOS-4.1.1 - -ambrose IN A 134.7.1.99 - IN MX 0 marsh - IN HINFO SGI-CHALLENGE_L IRIX-5.2 - IN GPOS -32.6882 116.8652 10.0 - - The hosts marsh, lillee, and ambrose are all at the same geographical - location, Perth Western Australia (-32.68820 116.86520). The host - hinault is at a different geographical location, 10 degrees north of - Perth in the mountains (-22.6882 116.8652 250.0). For security - reasons we do not wish to give the location of the host merckx. - - Although the GPOS clause is not a standard entry within BIND - configuration files, most vendor implementations seem to ignore - whatever is not understood upon startup of the DNS. Usually this - will result in a number of warnings appearing in system log files, - but in no way alters naming information or impedes the DNS from - performing its normal duties. - - - - - - - - - - - - - - - - - - - - -Farrell, Schulze, Pleitner & Baldoni [Page 5] - -RFC 1712 DNS Encoding of Geographical Location November 1994 - - -7. References - - [ROSE91] Rose M., "The Simple Book: An Introduction to - Management of TCP/IP-based Internets", Prentice-Hall, - Englewood Cliffs, New Jersey, 1991. - - [X.500.88] CCITT: The Directory - Overview of Concepts, Models - and Services", Recommendations X.500 - X.521. - - [Har82] Harrenstein K, Stahl M., and E. Feinler, - "NICNAME/WHOIS" RFC 812, SRI NIC, March 1982. - - [Mock87a] Mockapetris P., "Domain Names - Concepts and - Facilities", STD 13, RFC 1034, USC/Information - Sciences Institute, November 1987. - - [Mock87b] Mockapetris P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, USC/Information - Sciences Institute, November 1987. - - [FRB93] Ford P., Rekhter Y., and H-W. Braun, "Improving the - Routing and Addressing of IP", IEEE Network - Vol.7, No. 3, pp. 11-15, May 1993. - - [VJ89] Jacobsen V., "The Traceroute(8) Manual Page", - Lawrence Berkeley Laboratory, Berkeley, - CA, February 1989. - - [UCB89] University of California, "BIND: Berkeley Internet - Name Domain Server", 1989. - [UU85] UUCP Mapping Project, Software available via - anonymous FTP from ftp.uu.net., 1985. - -8. Security Considerations - - Once information has been entered into the DNS, it is considered - public. - - - - - - - - - - - - - - -Farrell, Schulze, Pleitner & Baldoni [Page 6] - -RFC 1712 DNS Encoding of Geographical Location November 1994 - - -9. Authors' Addresses - - Craig Farrell - Department of Computer Science - Curtin University of technology - GPO Box U1987 Perth, - Western Australia - - EMail: craig@cs.curtin.edu.au - - - Mike Schulze - Department of Computer Science - Curtin University of technology - GPO Box U1987 Perth, - Western Australia - - EMail: mike@cs.curtin.edu.au - - - Scott Pleitner - Department of Computer Science - Curtin University of technology - GPO Box U1987 Perth, - Western Australia - - EMail: pleitner@cs.curtin.edu.au - - - Daniel Baldoni - Department of Computer Science - Curtin University of technology - GPO Box U1987 Perth, - Western Australia - - EMail: flint@cs.curtin.edu.au - - - - - - - - - - - - - - - -Farrell, Schulze, Pleitner & Baldoni [Page 7] - diff --git a/contrib/bind9/doc/rfc/rfc1750.txt b/contrib/bind9/doc/rfc/rfc1750.txt deleted file mode 100644 index 56d478c7eef4..000000000000 --- a/contrib/bind9/doc/rfc/rfc1750.txt +++ /dev/null @@ -1,1683 +0,0 @@ - - - - - - -Network Working Group D. Eastlake, 3rd -Request for Comments: 1750 DEC -Category: Informational S. Crocker - Cybercash - J. Schiller - MIT - December 1994 - - - Randomness Recommendations for Security - -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. - -Abstract - - Security systems today are built on increasingly strong cryptographic - algorithms that foil pattern analysis attempts. However, the security - of these systems is dependent on generating secret quantities for - passwords, cryptographic keys, and similar quantities. The use of - pseudo-random processes to generate secret quantities can result in - pseudo-security. The sophisticated attacker of these security - systems may find it easier to reproduce the environment that produced - the secret quantities, searching the resulting small set of - possibilities, than to locate the quantities in the whole of the - number space. - - Choosing random quantities to foil a resourceful and motivated - adversary is surprisingly difficult. This paper points out many - pitfalls in using traditional pseudo-random number generation - techniques for choosing such quantities. It recommends the use of - truly random hardware techniques and shows that the existing hardware - on many systems can be used for this purpose. It provides - suggestions to ameliorate the problem when a hardware solution is not - available. And it gives examples of how large such quantities need - to be for some particular applications. - - - - - - - - - - - - -Eastlake, Crocker & Schiller [Page 1] - -RFC 1750 Randomness Recommendations for Security December 1994 - - -Acknowledgements - - Comments on this document that have been incorporated were received - from (in alphabetic order) the following: - - David M. Balenson (TIS) - Don Coppersmith (IBM) - Don T. Davis (consultant) - Carl Ellison (Stratus) - Marc Horowitz (MIT) - Christian Huitema (INRIA) - Charlie Kaufman (IRIS) - Steve Kent (BBN) - Hal Murray (DEC) - Neil Haller (Bellcore) - Richard Pitkin (DEC) - Tim Redmond (TIS) - Doug Tygar (CMU) - -Table of Contents - - 1. Introduction........................................... 3 - 2. Requirements........................................... 4 - 3. Traditional Pseudo-Random Sequences.................... 5 - 4. Unpredictability....................................... 7 - 4.1 Problems with Clocks and Serial Numbers............... 7 - 4.2 Timing and Content of External Events................ 8 - 4.3 The Fallacy of Complex Manipulation.................. 8 - 4.4 The Fallacy of Selection from a Large Database....... 9 - 5. Hardware for Randomness............................... 10 - 5.1 Volume Required...................................... 10 - 5.2 Sensitivity to Skew.................................. 10 - 5.2.1 Using Stream Parity to De-Skew..................... 11 - 5.2.2 Using Transition Mappings to De-Skew............... 12 - 5.2.3 Using FFT to De-Skew............................... 13 - 5.2.4 Using Compression to De-Skew....................... 13 - 5.3 Existing Hardware Can Be Used For Randomness......... 14 - 5.3.1 Using Existing Sound/Video Input................... 14 - 5.3.2 Using Existing Disk Drives......................... 14 - 6. Recommended Non-Hardware Strategy..................... 14 - 6.1 Mixing Functions..................................... 15 - 6.1.1 A Trivial Mixing Function.......................... 15 - 6.1.2 Stronger Mixing Functions.......................... 16 - 6.1.3 Diff-Hellman as a Mixing Function.................. 17 - 6.1.4 Using a Mixing Function to Stretch Random Bits..... 17 - 6.1.5 Other Factors in Choosing a Mixing Function........ 18 - 6.2 Non-Hardware Sources of Randomness................... 19 - 6.3 Cryptographically Strong Sequences................... 19 - - - -Eastlake, Crocker & Schiller [Page 2] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - 6.3.1 Traditional Strong Sequences....................... 20 - 6.3.2 The Blum Blum Shub Sequence Generator.............. 21 - 7. Key Generation Standards.............................. 22 - 7.1 US DoD Recommendations for Password Generation....... 23 - 7.2 X9.17 Key Generation................................. 23 - 8. Examples of Randomness Required....................... 24 - 8.1 Password Generation................................. 24 - 8.2 A Very High Security Cryptographic Key............... 25 - 8.2.1 Effort per Key Trial............................... 25 - 8.2.2 Meet in the Middle Attacks......................... 26 - 8.2.3 Other Considerations............................... 26 - 9. Conclusion............................................ 27 - 10. Security Considerations.............................. 27 - References............................................... 28 - Authors' Addresses....................................... 30 - -1. Introduction - - Software cryptography is coming into wider use. Systems like - Kerberos, PEM, PGP, etc. are maturing and becoming a part of the - network landscape [PEM]. These systems provide substantial - protection against snooping and spoofing. However, there is a - potential flaw. At the heart of all cryptographic systems is the - generation of secret, unguessable (i.e., random) numbers. - - For the present, the lack of generally available facilities for - generating such unpredictable numbers is an open wound in the design - of cryptographic software. For the software developer who wants to - build a key or password generation procedure that runs on a wide - range of hardware, the only safe strategy so far has been to force - the local installation to supply a suitable routine to generate - random numbers. To say the least, this is an awkward, error-prone - and unpalatable solution. - - It is important to keep in mind that the requirement is for data that - an adversary has a very low probability of guessing or determining. - This will fail if pseudo-random data is used which only meets - traditional statistical tests for randomness or which is based on - limited range sources, such as clocks. Frequently such random - quantities are determinable by an adversary searching through an - embarrassingly small space of possibilities. - - This informational document suggests techniques for producing random - quantities that will be resistant to such attack. It recommends that - future systems include hardware random number generation or provide - access to existing hardware that can be used for this purpose. It - suggests methods for use if such hardware is not available. And it - gives some estimates of the number of random bits required for sample - - - -Eastlake, Crocker & Schiller [Page 3] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - applications. - -2. Requirements - - Probably the most commonly encountered randomness requirement today - is the user password. This is usually a simple character string. - Obviously, if a password can be guessed, it does not provide - security. (For re-usable passwords, it is desirable that users be - able to remember the password. This may make it advisable to use - pronounceable character strings or phrases composed on ordinary - words. But this only affects the format of the password information, - not the requirement that the password be very hard to guess.) - - Many other requirements come from the cryptographic arena. - Cryptographic techniques can be used to provide a variety of services - including confidentiality and authentication. Such services are - based on quantities, traditionally called "keys", that are unknown to - and unguessable by an adversary. - - In some cases, such as the use of symmetric encryption with the one - time pads [CRYPTO*] or the US Data Encryption Standard [DES], the - parties who wish to communicate confidentially and/or with - authentication must all know the same secret key. In other cases, - using what are called asymmetric or "public key" cryptographic - techniques, keys come in pairs. One key of the pair is private and - must be kept secret by one party, the other is public and can be - published to the world. It is computationally infeasible to - determine the private key from the public key [ASYMMETRIC, CRYPTO*]. - - The frequency and volume of the requirement for random quantities - differs greatly for different cryptographic systems. Using pure RSA - [CRYPTO*], random quantities are required when the key pair is - generated, but thereafter any number of messages can be signed - without any further need for randomness. The public key Digital - Signature Algorithm that has been proposed by the US National - Institute of Standards and Technology (NIST) requires good random - numbers for each signature. And encrypting with a one time pad, in - principle the strongest possible encryption technique, requires a - volume of randomness equal to all the messages to be processed. - - In most of these cases, an adversary can try to determine the - "secret" key by trial and error. (This is possible as long as the - key is enough smaller than the message that the correct key can be - uniquely identified.) The probability of an adversary succeeding at - this must be made acceptably low, depending on the particular - application. The size of the space the adversary must search is - related to the amount of key "information" present in the information - theoretic sense [SHANNON]. This depends on the number of different - - - -Eastlake, Crocker & Schiller [Page 4] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - secret values possible and the probability of each value as follows: - - ----- - \ - Bits-of-info = \ - p * log ( p ) - / i 2 i - / - ----- - - where i varies from 1 to the number of possible secret values and p - sub i is the probability of the value numbered i. (Since p sub i is - less than one, the log will be negative so each term in the sum will - be non-negative.) - - If there are 2^n different values of equal probability, then n bits - of information are present and an adversary would, on the average, - have to try half of the values, or 2^(n-1) , before guessing the - secret quantity. If the probability of different values is unequal, - then there is less information present and fewer guesses will, on - average, be required by an adversary. In particular, any values that - the adversary can know are impossible, or are of low probability, can - be initially ignored by an adversary, who will search through the - more probable values first. - - For example, consider a cryptographic system that uses 56 bit keys. - If these 56 bit keys are derived by using a fixed pseudo-random - number generator that is seeded with an 8 bit seed, then an adversary - needs to search through only 256 keys (by running the pseudo-random - number generator with every possible seed), not the 2^56 keys that - may at first appear to be the case. Only 8 bits of "information" are - in these 56 bit keys. - -3. Traditional Pseudo-Random Sequences - - Most traditional sources of random numbers use deterministic sources - of "pseudo-random" numbers. These typically start with a "seed" - quantity and use numeric or logical operations to produce a sequence - of values. - - [KNUTH] has a classic exposition on pseudo-random numbers. - Applications he mentions are simulation of natural phenomena, - sampling, numerical analysis, testing computer programs, decision - making, and games. None of these have the same characteristics as - the sort of security uses we are talking about. Only in the last two - could there be an adversary trying to find the random quantity. - However, in these cases, the adversary normally has only a single - chance to use a guessed value. In guessing passwords or attempting - to break an encryption scheme, the adversary normally has many, - - - -Eastlake, Crocker & Schiller [Page 5] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - perhaps unlimited, chances at guessing the correct value and should - be assumed to be aided by a computer. - - For testing the "randomness" of numbers, Knuth suggests a variety of - measures including statistical and spectral. These tests check - things like autocorrelation between different parts of a "random" - sequence or distribution of its values. They could be met by a - constant stored random sequence, such as the "random" sequence - printed in the CRC Standard Mathematical Tables [CRC]. - - A typical pseudo-random number generation technique, known as a - linear congruence pseudo-random number generator, is modular - arithmetic where the N+1th value is calculated from the Nth value by - - V = ( V * a + b )(Mod c) - N+1 N - - The above technique has a strong relationship to linear shift - register pseudo-random number generators, which are well understood - cryptographically [SHIFT*]. In such generators bits are introduced - at one end of a shift register as the Exclusive Or (binary sum - without carry) of bits from selected fixed taps into the register. - - For example: - - +----+ +----+ +----+ +----+ - | B | <-- | B | <-- | B | <-- . . . . . . <-- | B | <-+ - | 0 | | 1 | | 2 | | n | | - +----+ +----+ +----+ +----+ | - | | | | - | | V +-----+ - | V +----------------> | | - V +-----------------------------> | XOR | - +---------------------------------------------------> | | - +-----+ - - - V = ( ( V * 2 ) + B .xor. B ... )(Mod 2^n) - N+1 N 0 2 - - The goodness of traditional pseudo-random number generator algorithms - is measured by statistical tests on such sequences. Carefully chosen - values of the initial V and a, b, and c or the placement of shift - register tap in the above simple processes can produce excellent - statistics. - - - - - - -Eastlake, Crocker & Schiller [Page 6] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - These sequences may be adequate in simulations (Monte Carlo - experiments) as long as the sequence is orthogonal to the structure - of the space being explored. Even there, subtle patterns may cause - problems. However, such sequences are clearly bad for use in - security applications. They are fully predictable if the initial - state is known. Depending on the form of the pseudo-random number - generator, the sequence may be determinable from observation of a - short portion of the sequence [CRYPTO*, STERN]. For example, with - the generators above, one can determine V(n+1) given knowledge of - V(n). In fact, it has been shown that with these techniques, even if - only one bit of the pseudo-random values is released, the seed can be - determined from short sequences. - - Not only have linear congruent generators been broken, but techniques - are now known for breaking all polynomial congruent generators - [KRAWCZYK]. - -4. Unpredictability - - Randomness in the traditional sense described in section 3 is NOT the - same as the unpredictability required for security use. - - For example, use of a widely available constant sequence, such as - that from the CRC tables, is very weak against an adversary. Once - they learn of or guess it, they can easily break all security, future - and past, based on the sequence [CRC]. Yet the statistical - properties of these tables are good. - - The following sections describe the limitations of some randomness - generation techniques and sources. - -4.1 Problems with Clocks and Serial Numbers - - Computer clocks, or similar operating system or hardware values, - provide significantly fewer real bits of unpredictability than might - appear from their specifications. - - Tests have been done on clocks on numerous systems and it was found - that their behavior can vary widely and in unexpected ways. One - version of an operating system running on one set of hardware may - actually provide, say, microsecond resolution in a clock while a - different configuration of the "same" system may always provide the - same lower bits and only count in the upper bits at much lower - resolution. This means that successive reads on the clock may - produce identical values even if enough time has passed that the - value "should" change based on the nominal clock resolution. There - are also cases where frequently reading a clock can produce - artificial sequential values because of extra code that checks for - - - -Eastlake, Crocker & Schiller [Page 7] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - the clock being unchanged between two reads and increases it by one! - Designing portable application code to generate unpredictable numbers - based on such system clocks is particularly challenging because the - system designer does not always know the properties of the system - clocks that the code will execute on. - - Use of a hardware serial number such as an Ethernet address may also - provide fewer bits of uniqueness than one would guess. Such - quantities are usually heavily structured and subfields may have only - a limited range of possible values or values easily guessable based - on approximate date of manufacture or other data. For example, it is - likely that most of the Ethernet cards installed on Digital Equipment - Corporation (DEC) hardware within DEC were manufactured by DEC - itself, which significantly limits the range of built in addresses. - - Problems such as those described above related to clocks and serial - numbers make code to produce unpredictable quantities difficult if - the code is to be ported across a variety of computer platforms and - systems. - -4.2 Timing and Content of External Events - - It is possible to measure the timing and content of mouse movement, - key strokes, and similar user events. This is a reasonable source of - unguessable data with some qualifications. On some machines, inputs - such as key strokes are buffered. Even though the user's inter- - keystroke timing may have sufficient variation and unpredictability, - there might not be an easy way to access that variation. Another - problem is that no standard method exists to sample timing details. - This makes it hard to build standard software intended for - distribution to a large range of machines based on this technique. - - The amount of mouse movement or the keys actually hit are usually - easier to access than timings but may yield less unpredictability as - the user may provide highly repetitive input. - - Other external events, such as network packet arrival times, can also - be used with care. In particular, the possibility of manipulation of - such times by an adversary must be considered. - -4.3 The Fallacy of Complex Manipulation - - One strategy which may give a misleading appearance of - unpredictability is to take a very complex algorithm (or an excellent - traditional pseudo-random number generator with good statistical - properties) and calculate a cryptographic key by starting with the - current value of a computer system clock as the seed. An adversary - who knew roughly when the generator was started would have a - - - -Eastlake, Crocker & Schiller [Page 8] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - relatively small number of seed values to test as they would know - likely values of the system clock. Large numbers of pseudo-random - bits could be generated but the search space an adversary would need - to check could be quite small. - - Thus very strong and/or complex manipulation of data will not help if - the adversary can learn what the manipulation is and there is not - enough unpredictability in the starting seed value. Even if they can - not learn what the manipulation is, they may be able to use the - limited number of results stemming from a limited number of seed - values to defeat security. - - Another serious strategy error is to assume that a very complex - pseudo-random number generation algorithm will produce strong random - numbers when there has been no theory behind or analysis of the - algorithm. There is a excellent example of this fallacy right near - the beginning of chapter 3 in [KNUTH] where the author describes a - complex algorithm. It was intended that the machine language program - corresponding to the algorithm would be so complicated that a person - trying to read the code without comments wouldn't know what the - program was doing. Unfortunately, actual use of this algorithm - showed that it almost immediately converged to a single repeated - value in one case and a small cycle of values in another case. - - Not only does complex manipulation not help you if you have a limited - range of seeds but blindly chosen complex manipulation can destroy - the randomness in a good seed! - -4.4 The Fallacy of Selection from a Large Database - - Another strategy that can give a misleading appearance of - unpredictability is selection of a quantity randomly from a database - and assume that its strength is related to the total number of bits - in the database. For example, typical USENET servers as of this date - process over 35 megabytes of information per day. Assume a random - quantity was selected by fetching 32 bytes of data from a random - starting point in this data. This does not yield 32*8 = 256 bits - worth of unguessability. Even after allowing that much of the data - is human language and probably has more like 2 or 3 bits of - information per byte, it doesn't yield 32*2.5 = 80 bits of - unguessability. For an adversary with access to the same 35 - megabytes the unguessability rests only on the starting point of the - selection. That is, at best, about 25 bits of unguessability in this - case. - - The same argument applies to selecting sequences from the data on a - CD ROM or Audio CD recording or any other large public database. If - the adversary has access to the same database, this "selection from a - - - -Eastlake, Crocker & Schiller [Page 9] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - large volume of data" step buys very little. However, if a selection - can be made from data to which the adversary has no access, such as - system buffers on an active multi-user system, it may be of some - help. - -5. Hardware for Randomness - - Is there any hope for strong portable randomness in the future? - There might be. All that's needed is a physical source of - unpredictable numbers. - - A thermal noise or radioactive decay source and a fast, free-running - oscillator would do the trick directly [GIFFORD]. This is a trivial - amount of hardware, and could easily be included as a standard part - of a computer system's architecture. Furthermore, any system with a - spinning disk or the like has an adequate source of randomness - [DAVIS]. All that's needed is the common perception among computer - vendors that this small additional hardware and the software to - access it is necessary and useful. - -5.1 Volume Required - - How much unpredictability is needed? Is it possible to quantify the - requirement in, say, number of random bits per second? - - The answer is not very much is needed. For DES, the key is 56 bits - and, as we show in an example in Section 8, even the highest security - system is unlikely to require a keying material of over 200 bits. If - a series of keys are needed, it can be generated from a strong random - seed using a cryptographically strong sequence as explained in - Section 6.3. A few hundred random bits generated once a day would be - enough using such techniques. Even if the random bits are generated - as slowly as one per second and it is not possible to overlap the - generation process, it should be tolerable in high security - applications to wait 200 seconds occasionally. - - These numbers are trivial to achieve. It could be done by a person - repeatedly tossing a coin. Almost any hardware process is likely to - be much faster. - -5.2 Sensitivity to Skew - - Is there any specific requirement on the shape of the distribution of - the random numbers? The good news is the distribution need not be - uniform. All that is needed is a conservative estimate of how non- - uniform it is to bound performance. Two simple techniques to de-skew - the bit stream are given below and stronger techniques are mentioned - in Section 6.1.2 below. - - - -Eastlake, Crocker & Schiller [Page 10] - -RFC 1750 Randomness Recommendations for Security December 1994 - - -5.2.1 Using Stream Parity to De-Skew - - Consider taking a sufficiently long string of bits and map the string - to "zero" or "one". The mapping will not yield a perfectly uniform - distribution, but it can be as close as desired. One mapping that - serves the purpose is to take the parity of the string. This has the - advantages that it is robust across all degrees of skew up to the - estimated maximum skew and is absolutely trivial to implement in - hardware. - - The following analysis gives the number of bits that must be sampled: - - Suppose the ratio of ones to zeros is 0.5 + e : 0.5 - e, where e is - between 0 and 0.5 and is a measure of the "eccentricity" of the - distribution. Consider the distribution of the parity function of N - bit samples. The probabilities that the parity will be one or zero - will be the sum of the odd or even terms in the binomial expansion of - (p + q)^N, where p = 0.5 + e, the probability of a one, and q = 0.5 - - e, the probability of a zero. - - These sums can be computed easily as - - N N - 1/2 * ( ( p + q ) + ( p - q ) ) - and - N N - 1/2 * ( ( p + q ) - ( p - q ) ). - - (Which one corresponds to the probability the parity will be 1 - depends on whether N is odd or even.) - - Since p + q = 1 and p - q = 2e, these expressions reduce to - - N - 1/2 * [1 + (2e) ] - and - N - 1/2 * [1 - (2e) ]. - - Neither of these will ever be exactly 0.5 unless e is zero, but we - can bring them arbitrarily close to 0.5. If we want the - probabilities to be within some delta d of 0.5, i.e. then - - N - ( 0.5 + ( 0.5 * (2e) ) ) < 0.5 + d. - - - - - - -Eastlake, Crocker & Schiller [Page 11] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - Solving for N yields N > log(2d)/log(2e). (Note that 2e is less than - 1, so its log is negative. Division by a negative number reverses - the sense of an inequality.) - - The following table gives the length of the string which must be - sampled for various degrees of skew in order to come within 0.001 of - a 50/50 distribution. - - +---------+--------+-------+ - | Prob(1) | e | N | - +---------+--------+-------+ - | 0.5 | 0.00 | 1 | - | 0.6 | 0.10 | 4 | - | 0.7 | 0.20 | 7 | - | 0.8 | 0.30 | 13 | - | 0.9 | 0.40 | 28 | - | 0.95 | 0.45 | 59 | - | 0.99 | 0.49 | 308 | - +---------+--------+-------+ - - The last entry shows that even if the distribution is skewed 99% in - favor of ones, the parity of a string of 308 samples will be within - 0.001 of a 50/50 distribution. - -5.2.2 Using Transition Mappings to De-Skew - - Another technique, originally due to von Neumann [VON NEUMANN], is to - examine a bit stream as a sequence of non-overlapping pairs. You - could then discard any 00 or 11 pairs found, interpret 01 as a 0 and - 10 as a 1. Assume the probability of a 1 is 0.5+e and the - probability of a 0 is 0.5-e where e is the eccentricity of the source - and described in the previous section. Then the probability of each - pair is as follows: - - +------+-----------------------------------------+ - | pair | probability | - +------+-----------------------------------------+ - | 00 | (0.5 - e)^2 = 0.25 - e + e^2 | - | 01 | (0.5 - e)*(0.5 + e) = 0.25 - e^2 | - | 10 | (0.5 + e)*(0.5 - e) = 0.25 - e^2 | - | 11 | (0.5 + e)^2 = 0.25 + e + e^2 | - +------+-----------------------------------------+ - - This technique will completely eliminate any bias but at the expense - of taking an indeterminate number of input bits for any particular - desired number of output bits. The probability of any particular - pair being discarded is 0.5 + 2e^2 so the expected number of input - bits to produce X output bits is X/(0.25 - e^2). - - - -Eastlake, Crocker & Schiller [Page 12] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - This technique assumes that the bits are from a stream where each bit - has the same probability of being a 0 or 1 as any other bit in the - stream and that bits are not correlated, i.e., that the bits are - identical independent distributions. If alternate bits were from two - correlated sources, for example, the above analysis breaks down. - - The above technique also provides another illustration of how a - simple statistical analysis can mislead if one is not always on the - lookout for patterns that could be exploited by an adversary. If the - algorithm were mis-read slightly so that overlapping successive bits - pairs were used instead of non-overlapping pairs, the statistical - analysis given is the same; however, instead of provided an unbiased - uncorrelated series of random 1's and 0's, it instead produces a - totally predictable sequence of exactly alternating 1's and 0's. - -5.2.3 Using FFT to De-Skew - - When real world data consists of strongly biased or correlated bits, - it may still contain useful amounts of randomness. This randomness - can be extracted through use of the discrete Fourier transform or its - optimized variant, the FFT. - - Using the Fourier transform of the data, strong correlations can be - discarded. If adequate data is processed and remaining correlations - decay, spectral lines approaching statistical independence and - normally distributed randomness can be produced [BRILLINGER]. - -5.2.4 Using Compression to De-Skew - - Reversible compression techniques also provide a crude method of de- - skewing a skewed bit stream. This follows directly from the - definition of reversible compression and the formula in Section 2 - above for the amount of information in a sequence. Since the - compression is reversible, the same amount of information must be - present in the shorter output than was present in the longer input. - By the Shannon information equation, this is only possible if, on - average, the probabilities of the different shorter sequences are - more uniformly distributed than were the probabilities of the longer - sequences. Thus the shorter sequences are de-skewed relative to the - input. - - However, many compression techniques add a somewhat predicatable - preface to their output stream and may insert such a sequence again - periodically in their output or otherwise introduce subtle patterns - of their own. They should be considered only a rough technique - compared with those described above or in Section 6.1.2. At a - minimum, the beginning of the compressed sequence should be skipped - and only later bits used for applications requiring random bits. - - - -Eastlake, Crocker & Schiller [Page 13] - -RFC 1750 Randomness Recommendations for Security December 1994 - - -5.3 Existing Hardware Can Be Used For Randomness - - As described below, many computers come with hardware that can, with - care, be used to generate truly random quantities. - -5.3.1 Using Existing Sound/Video Input - - Increasingly computers are being built with inputs that digitize some - real world analog source, such as sound from a microphone or video - input from a camera. Under appropriate circumstances, such input can - provide reasonably high quality random bits. The "input" from a - sound digitizer with no source plugged in or a camera with the lens - cap on, if the system has enough gain to detect anything, is - essentially thermal noise. - - For example, on a SPARCstation, one can read from the /dev/audio - device with nothing plugged into the microphone jack. Such data is - essentially random noise although it should not be trusted without - some checking in case of hardware failure. It will, in any case, - need to be de-skewed as described elsewhere. - - Combining this with compression to de-skew one can, in UNIXese, - generate a huge amount of medium quality random data by doing - - cat /dev/audio | compress - >random-bits-file - -5.3.2 Using Existing Disk Drives - - Disk drives have small random fluctuations in their rotational speed - due to chaotic air turbulence [DAVIS]. By adding low level disk seek - time instrumentation to a system, a series of measurements can be - obtained that include this randomness. Such data is usually highly - correlated so that significant processing is needed, including FFT - (see section 5.2.3). Nevertheless experimentation has shown that, - with such processing, disk drives easily produce 100 bits a minute or - more of excellent random data. - - Partly offsetting this need for processing is the fact that disk - drive failure will normally be rapidly noticed. Thus, problems with - this method of random number generation due to hardware failure are - very unlikely. - -6. Recommended Non-Hardware Strategy - - What is the best overall strategy for meeting the requirement for - unguessable random numbers in the absence of a reliable hardware - source? It is to obtain random input from a large number of - uncorrelated sources and to mix them with a strong mixing function. - - - -Eastlake, Crocker & Schiller [Page 14] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - Such a function will preserve the randomness present in any of the - sources even if other quantities being combined are fixed or easily - guessable. This may be advisable even with a good hardware source as - hardware can also fail, though this should be weighed against any - increase in the chance of overall failure due to added software - complexity. - -6.1 Mixing Functions - - A strong mixing function is one which combines two or more inputs and - produces an output where each output bit is a different complex non- - linear function of all the input bits. On average, changing any - input bit will change about half the output bits. But because the - relationship is complex and non-linear, no particular output bit is - guaranteed to change when any particular input bit is changed. - - Consider the problem of converting a stream of bits that is skewed - towards 0 or 1 to a shorter stream which is more random, as discussed - in Section 5.2 above. This is simply another case where a strong - mixing function is desired, mixing the input bits to produce a - smaller number of output bits. The technique given in Section 5.2.1 - of using the parity of a number of bits is simply the result of - successively Exclusive Or'ing them which is examined as a trivial - mixing function immediately below. Use of stronger mixing functions - to extract more of the randomness in a stream of skewed bits is - examined in Section 6.1.2. - -6.1.1 A Trivial Mixing Function - - A trivial example for single bit inputs is the Exclusive Or function, - which is equivalent to addition without carry, as show in the table - below. This is a degenerate case in which the one output bit always - changes for a change in either input bit. But, despite its - simplicity, it will still provide a useful illustration. - - +-----------+-----------+----------+ - | input 1 | input 2 | output | - +-----------+-----------+----------+ - | 0 | 0 | 0 | - | 0 | 1 | 1 | - | 1 | 0 | 1 | - | 1 | 1 | 0 | - +-----------+-----------+----------+ - - If inputs 1 and 2 are uncorrelated and combined in this fashion then - the output will be an even better (less skewed) random bit than the - inputs. If we assume an "eccentricity" e as defined in Section 5.2 - above, then the output eccentricity relates to the input eccentricity - - - -Eastlake, Crocker & Schiller [Page 15] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - as follows: - - e = 2 * e * e - output input 1 input 2 - - Since e is never greater than 1/2, the eccentricity is always - improved except in the case where at least one input is a totally - skewed constant. This is illustrated in the following table where - the top and left side values are the two input eccentricities and the - entries are the output eccentricity: - - +--------+--------+--------+--------+--------+--------+--------+ - | e | 0.00 | 0.10 | 0.20 | 0.30 | 0.40 | 0.50 | - +--------+--------+--------+--------+--------+--------+--------+ - | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | - | 0.10 | 0.00 | 0.02 | 0.04 | 0.06 | 0.08 | 0.10 | - | 0.20 | 0.00 | 0.04 | 0.08 | 0.12 | 0.16 | 0.20 | - | 0.30 | 0.00 | 0.06 | 0.12 | 0.18 | 0.24 | 0.30 | - | 0.40 | 0.00 | 0.08 | 0.16 | 0.24 | 0.32 | 0.40 | - | 0.50 | 0.00 | 0.10 | 0.20 | 0.30 | 0.40 | 0.50 | - +--------+--------+--------+--------+--------+--------+--------+ - - However, keep in mind that the above calculations assume that the - inputs are not correlated. If the inputs were, say, the parity of - the number of minutes from midnight on two clocks accurate to a few - seconds, then each might appear random if sampled at random intervals - much longer than a minute. Yet if they were both sampled and - combined with xor, the result would be zero most of the time. - -6.1.2 Stronger Mixing Functions - - The US Government Data Encryption Standard [DES] is an example of a - strong mixing function for multiple bit quantities. It takes up to - 120 bits of input (64 bits of "data" and 56 bits of "key") and - produces 64 bits of output each of which is dependent on a complex - non-linear function of all input bits. Other strong encryption - functions with this characteristic can also be used by considering - them to mix all of their key and data input bits. - - Another good family of mixing functions are the "message digest" or - hashing functions such as The US Government Secure Hash Standard - [SHS] and the MD2, MD4, MD5 [MD2, MD4, MD5] series. These functions - all take an arbitrary amount of input and produce an output mixing - all the input bits. The MD* series produce 128 bits of output and SHS - produces 160 bits. - - - - - - -Eastlake, Crocker & Schiller [Page 16] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - Although the message digest functions are designed for variable - amounts of input, DES and other encryption functions can also be used - to combine any number of inputs. If 64 bits of output is adequate, - the inputs can be packed into a 64 bit data quantity and successive - 56 bit keys, padding with zeros if needed, which are then used to - successively encrypt using DES in Electronic Codebook Mode [DES - MODES]. If more than 64 bits of output are needed, use more complex - mixing. For example, if inputs are packed into three quantities, A, - B, and C, use DES to encrypt A with B as a key and then with C as a - key to produce the 1st part of the output, then encrypt B with C and - then A for more output and, if necessary, encrypt C with A and then B - for yet more output. Still more output can be produced by reversing - the order of the keys given above to stretch things. The same can be - done with the hash functions by hashing various subsets of the input - data to produce multiple outputs. But keep in mind that it is - impossible to get more bits of "randomness" out than are put in. - - An example of using a strong mixing function would be to reconsider - the case of a string of 308 bits each of which is biased 99% towards - zero. The parity technique given in Section 5.2.1 above reduced this - to one bit with only a 1/1000 deviance from being equally likely a - zero or one. But, applying the equation for information given in - Section 2, this 308 bit sequence has 5 bits of information in it. - Thus hashing it with SHS or MD5 and taking the bottom 5 bits of the - result would yield 5 unbiased random bits as opposed to the single - bit given by calculating the parity of the string. - -6.1.3 Diffie-Hellman as a Mixing Function - - Diffie-Hellman exponential key exchange is a technique that yields a - shared secret between two parties that can be made computationally - infeasible for a third party to determine even if they can observe - all the messages between the two communicating parties. This shared - secret is a mixture of initial quantities generated by each of them - [D-H]. If these initial quantities are random, then the shared - secret contains the combined randomness of them both, assuming they - are uncorrelated. - -6.1.4 Using a Mixing Function to Stretch Random Bits - - While it is not necessary for a mixing function to produce the same - or fewer bits than its inputs, mixing bits cannot "stretch" the - amount of random unpredictability present in the inputs. Thus four - inputs of 32 bits each where there is 12 bits worth of - unpredicatability (such as 4,096 equally probable values) in each - input cannot produce more than 48 bits worth of unpredictable output. - The output can be expanded to hundreds or thousands of bits by, for - example, mixing with successive integers, but the clever adversary's - - - -Eastlake, Crocker & Schiller [Page 17] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - search space is still 2^48 possibilities. Furthermore, mixing to - fewer bits than are input will tend to strengthen the randomness of - the output the way using Exclusive Or to produce one bit from two did - above. - - The last table in Section 6.1.1 shows that mixing a random bit with a - constant bit with Exclusive Or will produce a random bit. While this - is true, it does not provide a way to "stretch" one random bit into - more than one. If, for example, a random bit is mixed with a 0 and - then with a 1, this produces a two bit sequence but it will always be - either 01 or 10. Since there are only two possible values, there is - still only the one bit of original randomness. - -6.1.5 Other Factors in Choosing a Mixing Function - - For local use, DES has the advantages that it has been widely tested - for flaws, is widely documented, and is widely implemented with - hardware and software implementations available all over the world - including source code available by anonymous FTP. The SHS and MD* - family are younger algorithms which have been less tested but there - is no particular reason to believe they are flawed. Both MD5 and SHS - were derived from the earlier MD4 algorithm. They all have source - code available by anonymous FTP [SHS, MD2, MD4, MD5]. - - DES and SHS have been vouched for the the US National Security Agency - (NSA) on the basis of criteria that primarily remain secret. While - this is the cause of much speculation and doubt, investigation of DES - over the years has indicated that NSA involvement in modifications to - its design, which originated with IBM, was primarily to strengthen - it. No concealed or special weakness has been found in DES. It is - almost certain that the NSA modification to MD4 to produce the SHS - similarly strengthened the algorithm, possibly against threats not - yet known in the public cryptographic community. - - DES, SHS, MD4, and MD5 are royalty free for all purposes. MD2 has - been freely licensed only for non-profit use in connection with - Privacy Enhanced Mail [PEM]. Between the MD* algorithms, some people - believe that, as with "Goldilocks and the Three Bears", MD2 is strong - but too slow, MD4 is fast but too weak, and MD5 is just right. - - Another advantage of the MD* or similar hashing algorithms over - encryption algorithms is that they are not subject to the same - regulations imposed by the US Government prohibiting the unlicensed - export or import of encryption/decryption software and hardware. The - same should be true of DES rigged to produce an irreversible hash - code but most DES packages are oriented to reversible encryption. - - - - - -Eastlake, Crocker & Schiller [Page 18] - -RFC 1750 Randomness Recommendations for Security December 1994 - - -6.2 Non-Hardware Sources of Randomness - - The best source of input for mixing would be a hardware randomness - such as disk drive timing affected by air turbulence, audio input - with thermal noise, or radioactive decay. However, if that is not - available there are other possibilities. These include system - clocks, system or input/output buffers, user/system/hardware/network - serial numbers and/or addresses and timing, and user input. - Unfortunately, any of these sources can produce limited or - predicatable values under some circumstances. - - Some of the sources listed above would be quite strong on multi-user - systems where, in essence, each user of the system is a source of - randomness. However, on a small single user system, such as a - typical IBM PC or Apple Macintosh, it might be possible for an - adversary to assemble a similar configuration. This could give the - adversary inputs to the mixing process that were sufficiently - correlated to those used originally as to make exhaustive search - practical. - - The use of multiple random inputs with a strong mixing function is - recommended and can overcome weakness in any particular input. For - example, the timing and content of requested "random" user keystrokes - can yield hundreds of random bits but conservative assumptions need - to be made. For example, assuming a few bits of randomness if the - inter-keystroke interval is unique in the sequence up to that point - and a similar assumption if the key hit is unique but assuming that - no bits of randomness are present in the initial key value or if the - timing or key value duplicate previous values. The results of mixing - these timings and characters typed could be further combined with - clock values and other inputs. - - This strategy may make practical portable code to produce good random - numbers for security even if some of the inputs are very weak on some - of the target systems. However, it may still fail against a high - grade attack on small single user systems, especially if the - adversary has ever been able to observe the generation process in the - past. A hardware based random source is still preferable. - -6.3 Cryptographically Strong Sequences - - In cases where a series of random quantities must be generated, an - adversary may learn some values in the sequence. In general, they - should not be able to predict other values from the ones that they - know. - - - - - - -Eastlake, Crocker & Schiller [Page 19] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - The correct technique is to start with a strong random seed, take - cryptographically strong steps from that seed [CRYPTO2, CRYPTO3], and - do not reveal the complete state of the generator in the sequence - elements. If each value in the sequence can be calculated in a fixed - way from the previous value, then when any value is compromised, all - future values can be determined. This would be the case, for - example, if each value were a constant function of the previously - used values, even if the function were a very strong, non-invertible - message digest function. - - It should be noted that if your technique for generating a sequence - of key values is fast enough, it can trivially be used as the basis - for a confidentiality system. If two parties use the same sequence - generating technique and start with the same seed material, they will - generate identical sequences. These could, for example, be xor'ed at - one end with data being send, encrypting it, and xor'ed with this - data as received, decrypting it due to the reversible properties of - the xor operation. - -6.3.1 Traditional Strong Sequences - - A traditional way to achieve a strong sequence has been to have the - values be produced by hashing the quantities produced by - concatenating the seed with successive integers or the like and then - mask the values obtained so as to limit the amount of generator state - available to the adversary. - - It may also be possible to use an "encryption" algorithm with a - random key and seed value to encrypt and feedback some or all of the - output encrypted value into the value to be encrypted for the next - iteration. Appropriate feedback techniques will usually be - recommended with the encryption algorithm. An example is shown below - where shifting and masking are used to combine the cypher output - feedback. This type of feedback is recommended by the US Government - in connection with DES [DES MODES]. - - - - - - - - - - - - - - - - -Eastlake, Crocker & Schiller [Page 20] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - +---------------+ - | V | - | | n | - +--+------------+ - | | +---------+ - | +---------> | | +-----+ - +--+ | Encrypt | <--- | Key | - | +-------- | | +-----+ - | | +---------+ - V V - +------------+--+ - | V | | - | n+1 | - +---------------+ - - Note that if a shift of one is used, this is the same as the shift - register technique described in Section 3 above but with the all - important difference that the feedback is determined by a complex - non-linear function of all bits rather than a simple linear or - polynomial combination of output from a few bit position taps. - - It has been shown by Donald W. Davies that this sort of shifted - partial output feedback significantly weakens an algorithm compared - will feeding all of the output bits back as input. In particular, - for DES, repeated encrypting a full 64 bit quantity will give an - expected repeat in about 2^63 iterations. Feeding back anything less - than 64 (and more than 0) bits will give an expected repeat in - between 2**31 and 2**32 iterations! - - To predict values of a sequence from others when the sequence was - generated by these techniques is equivalent to breaking the - cryptosystem or inverting the "non-invertible" hashing involved with - only partial information available. The less information revealed - each iteration, the harder it will be for an adversary to predict the - sequence. Thus it is best to use only one bit from each value. It - has been shown that in some cases this makes it impossible to break a - system even when the cryptographic system is invertible and can be - broken if all of each generated value was revealed. - -6.3.2 The Blum Blum Shub Sequence Generator - - Currently the generator which has the strongest public proof of - strength is called the Blum Blum Shub generator after its inventors - [BBS]. It is also very simple and is based on quadratic residues. - It's only disadvantage is that is is computationally intensive - compared with the traditional techniques give in 6.3.1 above. This - is not a serious draw back if it is used for moderately infrequent - purposes, such as generating session keys. - - - -Eastlake, Crocker & Schiller [Page 21] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - Simply choose two large prime numbers, say p and q, which both have - the property that you get a remainder of 3 if you divide them by 4. - Let n = p * q. Then you choose a random number x relatively prime to - n. The initial seed for the generator and the method for calculating - subsequent values are then - - 2 - s = ( x )(Mod n) - 0 - - 2 - s = ( s )(Mod n) - i+1 i - - You must be careful to use only a few bits from the bottom of each s. - It is always safe to use only the lowest order bit. If you use no - more than the - - log ( log ( s ) ) - 2 2 i - - low order bits, then predicting any additional bits from a sequence - generated in this manner is provable as hard as factoring n. As long - as the initial x is secret, you can even make n public if you want. - - An intersting characteristic of this generator is that you can - directly calculate any of the s values. In particular - - i - ( ( 2 )(Mod (( p - 1 ) * ( q - 1 )) ) ) - s = ( s )(Mod n) - i 0 - - This means that in applications where many keys are generated in this - fashion, it is not necessary to save them all. Each key can be - effectively indexed and recovered from that small index and the - initial s and n. - -7. Key Generation Standards - - Several public standards are now in place for the generation of keys. - Two of these are described below. Both use DES but any equally - strong or stronger mixing function could be substituted. - - - - - - - - -Eastlake, Crocker & Schiller [Page 22] - -RFC 1750 Randomness Recommendations for Security December 1994 - - -7.1 US DoD Recommendations for Password Generation - - The United States Department of Defense has specific recommendations - for password generation [DoD]. They suggest using the US Data - Encryption Standard [DES] in Output Feedback Mode [DES MODES] as - follows: - - use an initialization vector determined from - the system clock, - system ID, - user ID, and - date and time; - use a key determined from - system interrupt registers, - system status registers, and - system counters; and, - as plain text, use an external randomly generated 64 bit - quantity such as 8 characters typed in by a system - administrator. - - The password can then be calculated from the 64 bit "cipher text" - generated in 64-bit Output Feedback Mode. As many bits as are needed - can be taken from these 64 bits and expanded into a pronounceable - word, phrase, or other format if a human being needs to remember the - password. - -7.2 X9.17 Key Generation - - The American National Standards Institute has specified a method for - generating a sequence of keys as follows: - - s is the initial 64 bit seed - 0 - - g is the sequence of generated 64 bit key quantities - n - - k is a random key reserved for generating this key sequence - - t is the time at which a key is generated to as fine a resolution - as is available (up to 64 bits). - - DES ( K, Q ) is the DES encryption of quantity Q with key K - - - - - - - - -Eastlake, Crocker & Schiller [Page 23] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - g = DES ( k, DES ( k, t ) .xor. s ) - n n - - s = DES ( k, DES ( k, t ) .xor. g ) - n+1 n - - If g sub n is to be used as a DES key, then every eighth bit should - be adjusted for parity for that use but the entire 64 bit unmodified - g should be used in calculating the next s. - -8. Examples of Randomness Required - - Below are two examples showing rough calculations of needed - randomness for security. The first is for moderate security - passwords while the second assumes a need for a very high security - cryptographic key. - -8.1 Password Generation - - Assume that user passwords change once a year and it is desired that - the probability that an adversary could guess the password for a - particular account be less than one in a thousand. Further assume - that sending a password to the system is the only way to try a - password. Then the crucial question is how often an adversary can - try possibilities. Assume that delays have been introduced into a - system so that, at most, an adversary can make one password try every - six seconds. That's 600 per hour or about 15,000 per day or about - 5,000,000 tries in a year. Assuming any sort of monitoring, it is - unlikely someone could actually try continuously for a year. In - fact, even if log files are only checked monthly, 500,000 tries is - more plausible before the attack is noticed and steps taken to change - passwords and make it harder to try more passwords. - - To have a one in a thousand chance of guessing the password in - 500,000 tries implies a universe of at least 500,000,000 passwords or - about 2^29. Thus 29 bits of randomness are needed. This can probably - be achieved using the US DoD recommended inputs for password - generation as it has 8 inputs which probably average over 5 bits of - randomness each (see section 7.1). Using a list of 1000 words, the - password could be expressed as a three word phrase (1,000,000,000 - possibilities) or, using case insensitive letters and digits, six - would suffice ((26+10)^6 = 2,176,782,336 possibilities). - - For a higher security password, the number of bits required goes up. - To decrease the probability by 1,000 requires increasing the universe - of passwords by the same factor which adds about 10 bits. Thus to - have only a one in a million chance of a password being guessed under - the above scenario would require 39 bits of randomness and a password - - - -Eastlake, Crocker & Schiller [Page 24] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - that was a four word phrase from a 1000 word list or eight - letters/digits. To go to a one in 10^9 chance, 49 bits of randomness - are needed implying a five word phrase or ten letter/digit password. - - In a real system, of course, there are also other factors. For - example, the larger and harder to remember passwords are, the more - likely users are to write them down resulting in an additional risk - of compromise. - -8.2 A Very High Security Cryptographic Key - - Assume that a very high security key is needed for symmetric - encryption / decryption between two parties. Assume an adversary can - observe communications and knows the algorithm being used. Within - the field of random possibilities, the adversary can try key values - in hopes of finding the one in use. Assume further that brute force - trial of keys is the best the adversary can do. - -8.2.1 Effort per Key Trial - - How much effort will it take to try each key? For very high security - applications it is best to assume a low value of effort. Even if it - would clearly take tens of thousands of computer cycles or more to - try a single key, there may be some pattern that enables huge blocks - of key values to be tested with much less effort per key. Thus it is - probably best to assume no more than a couple hundred cycles per key. - (There is no clear lower bound on this as computers operate in - parallel on a number of bits and a poor encryption algorithm could - allow many keys or even groups of keys to be tested in parallel. - However, we need to assume some value and can hope that a reasonably - strong algorithm has been chosen for our hypothetical high security - task.) - - If the adversary can command a highly parallel processor or a large - network of work stations, 2*10^10 cycles per second is probably a - minimum assumption for availability today. Looking forward just a - couple years, there should be at least an order of magnitude - improvement. Thus assuming 10^9 keys could be checked per second or - 3.6*10^11 per hour or 6*10^13 per week or 2.4*10^14 per month is - reasonable. This implies a need for a minimum of 51 bits of - randomness in keys to be sure they cannot be found in a month. Even - then it is possible that, a few years from now, a highly determined - and resourceful adversary could break the key in 2 weeks (on average - they need try only half the keys). - - - - - - - -Eastlake, Crocker & Schiller [Page 25] - -RFC 1750 Randomness Recommendations for Security December 1994 - - -8.2.2 Meet in the Middle Attacks - - If chosen or known plain text and the resulting encrypted text are - available, a "meet in the middle" attack is possible if the structure - of the encryption algorithm allows it. (In a known plain text - attack, the adversary knows all or part of the messages being - encrypted, possibly some standard header or trailer fields. In a - chosen plain text attack, the adversary can force some chosen plain - text to be encrypted, possibly by "leaking" an exciting text that - would then be sent by the adversary over an encrypted channel.) - - An oversimplified explanation of the meet in the middle attack is as - follows: the adversary can half-encrypt the known or chosen plain - text with all possible first half-keys, sort the output, then half- - decrypt the encoded text with all the second half-keys. If a match - is found, the full key can be assembled from the halves and used to - decrypt other parts of the message or other messages. At its best, - this type of attack can halve the exponent of the work required by - the adversary while adding a large but roughly constant factor of - effort. To be assured of safety against this, a doubling of the - amount of randomness in the key to a minimum of 102 bits is required. - - The meet in the middle attack assumes that the cryptographic - algorithm can be decomposed in this way but we can not rule that out - without a deep knowledge of the algorithm. Even if a basic algorithm - is not subject to a meet in the middle attack, an attempt to produce - a stronger algorithm by applying the basic algorithm twice (or two - different algorithms sequentially) with different keys may gain less - added security than would be expected. Such a composite algorithm - would be subject to a meet in the middle attack. - - Enormous resources may be required to mount a meet in the middle - attack but they are probably within the range of the national - security services of a major nation. Essentially all nations spy on - other nations government traffic and several nations are believed to - spy on commercial traffic for economic advantage. - -8.2.3 Other Considerations - - Since we have not even considered the possibilities of special - purpose code breaking hardware or just how much of a safety margin we - want beyond our assumptions above, probably a good minimum for a very - high security cryptographic key is 128 bits of randomness which - implies a minimum key length of 128 bits. If the two parties agree - on a key by Diffie-Hellman exchange [D-H], then in principle only - half of this randomness would have to be supplied by each party. - However, there is probably some correlation between their random - inputs so it is probably best to assume that each party needs to - - - -Eastlake, Crocker & Schiller [Page 26] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - provide at least 96 bits worth of randomness for very high security - if Diffie-Hellman is used. - - This amount of randomness is beyond the limit of that in the inputs - recommended by the US DoD for password generation and could require - user typing timing, hardware random number generation, or other - sources. - - It should be noted that key length calculations such at those above - are controversial and depend on various assumptions about the - cryptographic algorithms in use. In some cases, a professional with - a deep knowledge of code breaking techniques and of the strength of - the algorithm in use could be satisfied with less than half of the - key size derived above. - -9. Conclusion - - Generation of unguessable "random" secret quantities for security use - is an essential but difficult task. - - We have shown that hardware techniques to produce such randomness - would be relatively simple. In particular, the volume and quality - would not need to be high and existing computer hardware, such as - disk drives, can be used. Computational techniques are available to - process low quality random quantities from multiple sources or a - larger quantity of such low quality input from one source and produce - a smaller quantity of higher quality, less predictable key material. - In the absence of hardware sources of randomness, a variety of user - and software sources can frequently be used instead with care; - however, most modern systems already have hardware, such as disk - drives or audio input, that could be used to produce high quality - randomness. - - Once a sufficient quantity of high quality seed key material (a few - hundred bits) is available, strong computational techniques are - available to produce cryptographically strong sequences of - unpredicatable quantities from this seed material. - -10. Security Considerations - - The entirety of this document concerns techniques and recommendations - for generating unguessable "random" quantities for use as passwords, - cryptographic keys, and similar security uses. - - - - - - - - -Eastlake, Crocker & Schiller [Page 27] - -RFC 1750 Randomness Recommendations for Security December 1994 - - -References - - [ASYMMETRIC] - Secure Communications and Asymmetric Cryptosystems, - edited by Gustavus J. Simmons, AAAS Selected Symposium 69, Westview - Press, Inc. - - [BBS] - A Simple Unpredictable Pseudo-Random Number Generator, SIAM - Journal on Computing, v. 15, n. 2, 1986, L. Blum, M. Blum, & M. Shub. - - [BRILLINGER] - Time Series: Data Analysis and Theory, Holden-Day, - 1981, David Brillinger. - - [CRC] - C.R.C. Standard Mathematical Tables, Chemical Rubber - Publishing Company. - - [CRYPTO1] - Cryptography: A Primer, A Wiley-Interscience Publication, - John Wiley & Sons, 1981, Alan G. Konheim. - - [CRYPTO2] - Cryptography: A New Dimension in Computer Data Security, - A Wiley-Interscience Publication, John Wiley & Sons, 1982, Carl H. - Meyer & Stephen M. Matyas. - - [CRYPTO3] - Applied Cryptography: Protocols, Algorithms, and Source - Code in C, John Wiley & Sons, 1994, Bruce Schneier. - - [DAVIS] - Cryptographic Randomness from Air Turbulence in Disk - Drives, Advances in Cryptology - Crypto '94, Springer-Verlag Lecture - Notes in Computer Science #839, 1984, Don Davis, Ross Ihaka, and - Philip Fenstermacher. - - [DES] - Data Encryption Standard, United States of America, - Department of Commerce, National Institute of Standards and - Technology, Federal Information Processing Standard (FIPS) 46-1. - - Data Encryption Algorithm, American National Standards Institute, - ANSI X3.92-1981. - (See also FIPS 112, Password Usage, which includes FORTRAN code for - performing DES.) - - [DES MODES] - DES Modes of Operation, United States of America, - Department of Commerce, National Institute of Standards and - Technology, Federal Information Processing Standard (FIPS) 81. - - Data Encryption Algorithm - Modes of Operation, American National - Standards Institute, ANSI X3.106-1983. - - [D-H] - New Directions in Cryptography, IEEE Transactions on - Information Technology, November, 1976, Whitfield Diffie and Martin - E. Hellman. - - - - -Eastlake, Crocker & Schiller [Page 28] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - [DoD] - Password Management Guideline, United States of America, - Department of Defense, Computer Security Center, CSC-STD-002-85. - (See also FIPS 112, Password Usage, which incorporates CSC-STD-002-85 - as one of its appendices.) - - [GIFFORD] - Natural Random Number, MIT/LCS/TM-371, September 1988, - David K. Gifford - - [KNUTH] - The Art of Computer Programming, Volume 2: Seminumerical - Algorithms, Chapter 3: Random Numbers. Addison Wesley Publishing - Company, Second Edition 1982, Donald E. Knuth. - - [KRAWCZYK] - How to Predict Congruential Generators, Journal of - Algorithms, V. 13, N. 4, December 1992, H. Krawczyk - - [MD2] - The MD2 Message-Digest Algorithm, RFC1319, April 1992, B. - Kaliski - [MD4] - The MD4 Message-Digest Algorithm, RFC1320, April 1992, R. - Rivest - [MD5] - The MD5 Message-Digest Algorithm, RFC1321, April 1992, R. - Rivest - - [PEM] - RFCs 1421 through 1424: - - RFC 1424, Privacy Enhancement for Internet Electronic Mail: Part - IV: Key Certification and Related Services, 02/10/1993, B. Kaliski - - RFC 1423, Privacy Enhancement for Internet Electronic Mail: Part - III: Algorithms, Modes, and Identifiers, 02/10/1993, D. Balenson - - RFC 1422, Privacy Enhancement for Internet Electronic Mail: Part - II: Certificate-Based Key Management, 02/10/1993, S. Kent - - RFC 1421, Privacy Enhancement for Internet Electronic Mail: Part I: - Message Encryption and Authentication Procedures, 02/10/1993, J. Linn - - [SHANNON] - The Mathematical Theory of Communication, University of - Illinois Press, 1963, Claude E. Shannon. (originally from: Bell - System Technical Journal, July and October 1948) - - [SHIFT1] - Shift Register Sequences, Aegean Park Press, Revised - Edition 1982, Solomon W. Golomb. - - [SHIFT2] - Cryptanalysis of Shift-Register Generated Stream Cypher - Systems, Aegean Park Press, 1984, Wayne G. Barker. - - [SHS] - Secure Hash Standard, United States of American, National - Institute of Science and Technology, Federal Information Processing - Standard (FIPS) 180, April 1993. - - [STERN] - Secret Linear Congruential Generators are not - Cryptograhically Secure, Proceedings of IEEE STOC, 1987, J. Stern. - - - -Eastlake, Crocker & Schiller [Page 29] - -RFC 1750 Randomness Recommendations for Security December 1994 - - - [VON NEUMANN] - Various techniques used in connection with random - digits, von Neumann's Collected Works, Vol. 5, Pergamon Press, 1963, - J. von Neumann. - -Authors' Addresses - - Donald E. Eastlake 3rd - Digital Equipment Corporation - 550 King Street, LKG2-1/BB3 - Littleton, MA 01460 - - Phone: +1 508 486 6577(w) +1 508 287 4877(h) - EMail: dee@lkg.dec.com - - - Stephen D. Crocker - CyberCash Inc. - 2086 Hunters Crest Way - Vienna, VA 22181 - - Phone: +1 703-620-1222(w) +1 703-391-2651 (fax) - EMail: crocker@cybercash.com - - - Jeffrey I. Schiller - Massachusetts Institute of Technology - 77 Massachusetts Avenue - Cambridge, MA 02139 - - Phone: +1 617 253 0161(w) - EMail: jis@mit.edu - - - - - - - - - - - - - - - - - - - - -Eastlake, Crocker & Schiller [Page 30] - diff --git a/contrib/bind9/doc/rfc/rfc1876.txt b/contrib/bind9/doc/rfc/rfc1876.txt deleted file mode 100644 index a289cffece25..000000000000 --- a/contrib/bind9/doc/rfc/rfc1876.txt +++ /dev/null @@ -1,1011 +0,0 @@ - - - - - - -Network Working Group C. Davis -Request for Comments: 1876 Kapor Enterprises -Updates: 1034, 1035 P. Vixie -Category: Experimental Vixie Enterprises - T. Goodwin - FORE Systems - I. Dickinson - University of Warwick - January 1996 - - - A Means for Expressing Location Information in the Domain Name System - -Status of this Memo - - This memo defines an Experimental Protocol for the Internet - community. This memo does not specify an Internet standard of any - kind. Discussion and suggestions for improvement are requested. - Distribution of this memo is unlimited. - -1. Abstract - - This memo defines a new DNS RR type for experimental purposes. This - RFC describes a mechanism to allow the DNS to carry location - information about hosts, networks, and subnets. Such information for - a small subset of hosts is currently contained in the flat-file UUCP - maps. However, just as the DNS replaced the use of HOSTS.TXT to - carry host and network address information, it is possible to replace - the UUCP maps as carriers of location information. - - This RFC defines the format of a new Resource Record (RR) for the - Domain Name System (DNS), and reserves a corresponding DNS type - mnemonic (LOC) and numerical code (29). - - This RFC assumes that the reader is familiar with the DNS [RFC 1034, - RFC 1035]. The data shown in our examples is for pedagogical use and - does not necessarily reflect the real Internet. - - - - - - - - - - - - - - -Davis, et al Experimental [Page 1] - -RFC 1876 Location Information in the DNS January 1996 - - -2. RDATA Format - - MSB LSB - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 0| VERSION | SIZE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 2| HORIZ PRE | VERT PRE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 4| LATITUDE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 6| LATITUDE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 8| LONGITUDE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 10| LONGITUDE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 12| ALTITUDE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 14| ALTITUDE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - (octet) - -where: - -VERSION Version number of the representation. This must be zero. - Implementations are required to check this field and make - no assumptions about the format of unrecognized versions. - -SIZE The diameter of a sphere enclosing the described entity, in - centimeters, expressed as a pair of four-bit unsigned - integers, each ranging from zero to nine, with the most - significant four bits representing the base and the second - number representing the power of ten by which to multiply - the base. This allows sizes from 0e0 (<1cm) to 9e9 - (90,000km) to be expressed. This representation was chosen - such that the hexadecimal representation can be read by - eye; 0x15 = 1e5. Four-bit values greater than 9 are - undefined, as are values with a base of zero and a non-zero - exponent. - - Since 20000000m (represented by the value 0x29) is greater - than the equatorial diameter of the WGS 84 ellipsoid - (12756274m), it is therefore suitable for use as a - "worldwide" size. - -HORIZ PRE The horizontal precision of the data, in centimeters, - expressed using the same representation as SIZE. This is - the diameter of the horizontal "circle of error", rather - - - -Davis, et al Experimental [Page 2] - -RFC 1876 Location Information in the DNS January 1996 - - - than a "plus or minus" value. (This was chosen to match - the interpretation of SIZE; to get a "plus or minus" value, - divide by 2.) - -VERT PRE The vertical precision of the data, in centimeters, - expressed using the sane representation as for SIZE. This - is the total potential vertical error, rather than a "plus - or minus" value. (This was chosen to match the - interpretation of SIZE; to get a "plus or minus" value, - divide by 2.) Note that if altitude above or below sea - level is used as an approximation for altitude relative to - the [WGS 84] ellipsoid, the precision value should be - adjusted. - -LATITUDE The latitude of the center of the sphere described by the - SIZE field, expressed as a 32-bit integer, most significant - octet first (network standard byte order), in thousandths - of a second of arc. 2^31 represents the equator; numbers - above that are north latitude. - -LONGITUDE The longitude of the center of the sphere described by the - SIZE field, expressed as a 32-bit integer, most significant - octet first (network standard byte order), in thousandths - of a second of arc, rounded away from the prime meridian. - 2^31 represents the prime meridian; numbers above that are - east longitude. - -ALTITUDE The altitude of the center of the sphere described by the - SIZE field, expressed as a 32-bit integer, most significant - octet first (network standard byte order), in centimeters, - from a base of 100,000m below the [WGS 84] reference - spheroid used by GPS (semimajor axis a=6378137.0, - reciprocal flattening rf=298.257223563). Altitude above - (or below) sea level may be used as an approximation of - altitude relative to the the [WGS 84] spheroid, though due - to the Earth's surface not being a perfect spheroid, there - will be differences. (For example, the geoid (which sea - level approximates) for the continental US ranges from 10 - meters to 50 meters below the [WGS 84] spheroid. - Adjustments to ALTITUDE and/or VERT PRE will be necessary - in most cases. The Defense Mapping Agency publishes geoid - height values relative to the [WGS 84] ellipsoid. - - - - - - - - - -Davis, et al Experimental [Page 3] - -RFC 1876 Location Information in the DNS January 1996 - - -3. Master File Format - - The LOC record is expressed in a master file in the following format: - - <owner> <TTL> <class> LOC ( d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]] - {"E"|"W"} alt["m"] [siz["m"] [hp["m"] - [vp["m"]]]] ) - - (The parentheses are used for multi-line data as specified in [RFC - 1035] section 5.1.) - - where: - - d1: [0 .. 90] (degrees latitude) - d2: [0 .. 180] (degrees longitude) - m1, m2: [0 .. 59] (minutes latitude/longitude) - s1, s2: [0 .. 59.999] (seconds latitude/longitude) - alt: [-100000.00 .. 42849672.95] BY .01 (altitude in meters) - siz, hp, vp: [0 .. 90000000.00] (size/precision in meters) - - If omitted, minutes and seconds default to zero, size defaults to 1m, - horizontal precision defaults to 10000m, and vertical precision - defaults to 10m. These defaults are chosen to represent typical - ZIP/postal code area sizes, since it is often easy to find - approximate geographical location by ZIP/postal code. - -4. Example Data - -;;; -;;; note that these data would not all appear in one zone file -;;; - -;; network LOC RR derived from ZIP data. note use of precision defaults -cambridge-net.kei.com. LOC 42 21 54 N 71 06 18 W -24m 30m - -;; higher-precision host LOC RR. note use of vertical precision default -loiosh.kei.com. LOC 42 21 43.952 N 71 5 6.344 W - -24m 1m 200m - -pipex.net. LOC 52 14 05 N 00 08 50 E 10m - -curtin.edu.au. LOC 32 7 19 S 116 2 25 E 10m - -rwy04L.logan-airport.boston. LOC 42 21 28.764 N 71 00 51.617 W - -44m 2000m - - - - - - -Davis, et al Experimental [Page 4] - -RFC 1876 Location Information in the DNS January 1996 - - -5. Application use of the LOC RR - -5.1 Suggested Uses - - Some uses for the LOC RR have already been suggested, including the - USENET backbone flow maps, a "visual traceroute" application showing - the geographical path of an IP packet, and network management - applications that could use LOC RRs to generate a map of hosts and - routers being managed. - -5.2 Search Algorithms - - This section specifies how to use the DNS to translate domain names - and/or IP addresses into location information. - - If an application wishes to have a "fallback" behavior, displaying a - less precise or larger area when a host does not have an associated - LOC RR, it MAY support use of the algorithm in section 5.2.3, as - noted in sections 5.2.1 and 5.2.2. If fallback is desired, this - behaviour is the RECOMMENDED default, but in some cases it may need - to be modified based on the specific requirements of the application - involved. - - This search algorithm is designed to allow network administrators to - specify the location of a network or subnet without requiring LOC RR - data for each individual host. For example, a computer lab with 24 - workstations, all of which are on the same subnet and in basically - the same location, would only need a LOC RR for the subnet. - (However, if the file server's location has been more precisely - measured, a separate LOC RR for it can be placed in the DNS.) - -5.2.1 Searching by Name - - If the application is beginning with a name, rather than an IP - address (as the USENET backbone flow maps do), it MUST check for a - LOC RR associated with that name. (CNAME records should be followed - as for any other RR type.) - - If there is no LOC RR for that name, all A records (if any) - associated with the name MAY be checked for network (or subnet) LOC - RRs using the "Searching by Network or Subnet" algorithm (5.2.3). If - multiple A records exist and have associated network or subnet LOC - RRs, the application may choose to use any, some, or all of the LOC - RRs found, possibly in combination. It is suggested that multi-homed - hosts have LOC RRs for their name in the DNS to avoid any ambiguity - in these cases. - - - - - -Davis, et al Experimental [Page 5] - -RFC 1876 Location Information in the DNS January 1996 - - - Note that domain names that do not have associated A records must - have a LOC RR associated with their name in order for location - information to be accessible. - -5.2.2 Searching by Address - - If the application is beginning with an IP address (as a "visual - traceroute" application might be) it MUST first map the address to a - name using the IN-ADDR.ARPA namespace (see [RFC 1034], section - 5.2.1), then check for a LOC RR associated with that name. - - If there is no LOC RR for the name, the address MAY be checked for - network (or subnet) LOC RRs using the "Searching by Network or - Subnet" algorithm (5.2.3). - -5.2.3 Searching by Network or Subnet - - Even if a host's name does not have any associated LOC RRs, the - network(s) or subnet(s) it is on may. If the application wishes to - search for such less specific data, the following algorithm SHOULD be - followed to find a network or subnet LOC RR associated with the IP - address. This algorithm is adapted slightly from that specified in - [RFC 1101], sections 4.3 and 4.4. - - Since subnet LOC RRs are (if present) more specific than network LOC - RRs, it is best to use them if available. In order to do so, we - build a stack of network and subnet names found while performing the - [RFC 1101] search, then work our way down the stack until a LOC RR is - found. - - 1. create a host-zero address using the network portion of the IP - address (one, two, or three bytes for class A, B, or C networks, - respectively). For example, for the host 128.9.2.17, on the class - B network 128.9, this would result in the address "128.9.0.0". - - 2. Reverse the octets, suffix IN-ADDR.ARPA, and query for PTR and A - records. Retrieve: - - 0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu. - A 255.255.255.0 - - Push the name "isi-net.isi.edu" onto the stack of names to be - searched for LOC RRs later. - - - - - - - - -Davis, et al Experimental [Page 6] - -RFC 1876 Location Information in the DNS January 1996 - - - 3. Since an A RR was found, repeat using mask from RR - (255.255.255.0), constructing a query for 0.2.9.128.IN-ADDR.ARPA. - Retrieve: - - 0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu. - A 255.255.255.240 - - Push the name "div2-subnet.isi.edu" onto the stack of names to be - searched for LOC RRs later. - - 4. Since another A RR was found, repeat using mask 255.255.255.240 - (x'FFFFFFF0'), constructing a query for 16.2.9.128.IN-ADDR.ARPA. - Retrieve: - - 16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu. - - Push the name "inc-subsubnet.isi.edu" onto the stack of names to - be searched for LOC RRs later. - - 5. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there are no - more subnet levels to search. We now pop the top name from the - stack and check for an associated LOC RR. Repeat until a LOC RR - is found. - - In this case, assume that inc-subsubnet.isi.edu does not have an - associated LOC RR, but that div2-subnet.isi.edu does. We will - then use div2-subnet.isi.edu's LOC RR as an approximation of this - host's location. (Note that even if isi-net.isi.edu has a LOC RR, - it will not be used if a subnet also has a LOC RR.) - -5.3 Applicability to non-IN Classes and non-IP Addresses - - The LOC record is defined for all RR classes, and may be used with - non-IN classes such as HS and CH. The semantics of such use are not - defined by this memo. - - The search algorithm in section 5.2.3 may be adapted to other - addressing schemes by extending [RFC 1101]'s encoding of network - names to cover those schemes. Such extensions are not defined by - this memo. - - - - - - - - - - - -Davis, et al Experimental [Page 7] - -RFC 1876 Location Information in the DNS January 1996 - - -6. References - - [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", - STD 13, RFC 1034, USC/Information Sciences Institute, - November 1987. - - [RFC 1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, USC/Information Sciences - Institute, November 1987. - - [RFC 1101] Mockapetris, P., "DNS Encoding of Network Names and Other - Types", RFC 1101, USC/Information Sciences Institute, - April 1989. - - [WGS 84] United States Department of Defense; DoD WGS-1984 - Its - Definition and Relationships with Local Geodetic Systems; - Washington, D.C.; 1985; Report AD-A188 815 DMA; 6127; 7-R- - 138-R; CV, KV; - -7. Security Considerations - - High-precision LOC RR information could be used to plan a penetration - of physical security, leading to potential denial-of-machine attacks. - To avoid any appearance of suggesting this method to potential - attackers, we declined the opportunity to name this RR "ICBM". - -8. Authors' Addresses - - The authors as a group can be reached as <loc@pipex.net>. - - Christopher Davis - Kapor Enterprises, Inc. - 238 Main Street, Suite 400 - Cambridge, MA 02142 - - Phone: +1 617 576 4532 - EMail: ckd@kei.com - - - Paul Vixie - Vixie Enterprises - Star Route Box 159A - Woodside, CA 94062 - - Phone: +1 415 747 0204 - EMail: paul@vix.com - - - - - -Davis, et al Experimental [Page 8] - -RFC 1876 Location Information in the DNS January 1996 - - - Tim Goodwin - Public IP Exchange Ltd (PIPEX) - 216 The Science Park - Cambridge CB4 4WA - UK - - Phone: +44 1223 250250 - EMail: tim@pipex.net - - - Ian Dickinson - FORE Systems - 2475 The Crescent - Solihull Parkway - Birmingham Business Park - B37 7YE - UK - - Phone: +44 121 717 4444 - EMail: idickins@fore.co.uk - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Davis, et al Experimental [Page 9] - -RFC 1876 Location Information in the DNS January 1996 - - -Appendix A: Sample Conversion Routines - -/* - * routines to convert between on-the-wire RR format and zone file - * format. Does not contain conversion to/from decimal degrees; - * divide or multiply by 60*60*1000 for that. - */ - -static unsigned int poweroften[10] = {1, 10, 100, 1000, 10000, 100000, - 1000000,10000000,100000000,1000000000}; - -/* takes an XeY precision/size value, returns a string representation.*/ -static const char * -precsize_ntoa(prec) - u_int8_t prec; -{ - static char retbuf[sizeof("90000000.00")]; - unsigned long val; - int mantissa, exponent; - - mantissa = (int)((prec >> 4) & 0x0f) % 10; - exponent = (int)((prec >> 0) & 0x0f) % 10; - - val = mantissa * poweroften[exponent]; - - (void) sprintf(retbuf,"%d.%.2d", val/100, val%100); - return (retbuf); -} - -/* converts ascii size/precision X * 10**Y(cm) to 0xXY. moves pointer.*/ -static u_int8_t -precsize_aton(strptr) - char **strptr; -{ - unsigned int mval = 0, cmval = 0; - u_int8_t retval = 0; - register char *cp; - register int exponent; - register int mantissa; - - cp = *strptr; - - while (isdigit(*cp)) - mval = mval * 10 + (*cp++ - '0'); - - if (*cp == '.') { /* centimeters */ - cp++; - if (isdigit(*cp)) { - - - -Davis, et al Experimental [Page 10] - -RFC 1876 Location Information in the DNS January 1996 - - - cmval = (*cp++ - '0') * 10; - if (isdigit(*cp)) { - cmval += (*cp++ - '0'); - } - } - } - cmval = (mval * 100) + cmval; - - for (exponent = 0; exponent < 9; exponent++) - if (cmval < poweroften[exponent+1]) - break; - - mantissa = cmval / poweroften[exponent]; - if (mantissa > 9) - mantissa = 9; - - retval = (mantissa << 4) | exponent; - - *strptr = cp; - - return (retval); -} - -/* converts ascii lat/lon to unsigned encoded 32-bit number. - * moves pointer. */ -static u_int32_t -latlon2ul(latlonstrptr,which) - char **latlonstrptr; - int *which; -{ - register char *cp; - u_int32_t retval; - int deg = 0, min = 0, secs = 0, secsfrac = 0; - - cp = *latlonstrptr; - - while (isdigit(*cp)) - deg = deg * 10 + (*cp++ - '0'); - - while (isspace(*cp)) - cp++; - - if (!(isdigit(*cp))) - goto fndhemi; - - while (isdigit(*cp)) - min = min * 10 + (*cp++ - '0'); - - - - -Davis, et al Experimental [Page 11] - -RFC 1876 Location Information in the DNS January 1996 - - - while (isspace(*cp)) - cp++; - - if (!(isdigit(*cp))) - goto fndhemi; - - while (isdigit(*cp)) - secs = secs * 10 + (*cp++ - '0'); - - if (*cp == '.') { /* decimal seconds */ - cp++; - if (isdigit(*cp)) { - secsfrac = (*cp++ - '0') * 100; - if (isdigit(*cp)) { - secsfrac += (*cp++ - '0') * 10; - if (isdigit(*cp)) { - secsfrac += (*cp++ - '0'); - } - } - } - } - - while (!isspace(*cp)) /* if any trailing garbage */ - cp++; - - while (isspace(*cp)) - cp++; - - fndhemi: - switch (*cp) { - case 'N': case 'n': - case 'E': case 'e': - retval = ((unsigned)1<<31) - + (((((deg * 60) + min) * 60) + secs) * 1000) - + secsfrac; - break; - case 'S': case 's': - case 'W': case 'w': - retval = ((unsigned)1<<31) - - (((((deg * 60) + min) * 60) + secs) * 1000) - - secsfrac; - break; - default: - retval = 0; /* invalid value -- indicates error */ - break; - } - - switch (*cp) { - - - -Davis, et al Experimental [Page 12] - -RFC 1876 Location Information in the DNS January 1996 - - - case 'N': case 'n': - case 'S': case 's': - *which = 1; /* latitude */ - break; - case 'E': case 'e': - case 'W': case 'w': - *which = 2; /* longitude */ - break; - default: - *which = 0; /* error */ - break; - } - - cp++; /* skip the hemisphere */ - - while (!isspace(*cp)) /* if any trailing garbage */ - cp++; - - while (isspace(*cp)) /* move to next field */ - cp++; - - *latlonstrptr = cp; - - return (retval); -} - -/* converts a zone file representation in a string to an RDATA - * on-the-wire representation. */ -u_int32_t -loc_aton(ascii, binary) - const char *ascii; - u_char *binary; -{ - const char *cp, *maxcp; - u_char *bcp; - - u_int32_t latit = 0, longit = 0, alt = 0; - u_int32_t lltemp1 = 0, lltemp2 = 0; - int altmeters = 0, altfrac = 0, altsign = 1; - u_int8_t hp = 0x16; /* default = 1e6 cm = 10000.00m = 10km */ - u_int8_t vp = 0x13; /* default = 1e3 cm = 10.00m */ - u_int8_t siz = 0x12; /* default = 1e2 cm = 1.00m */ - int which1 = 0, which2 = 0; - - cp = ascii; - maxcp = cp + strlen(ascii); - - lltemp1 = latlon2ul(&cp, &which1); - - - -Davis, et al Experimental [Page 13] - -RFC 1876 Location Information in the DNS January 1996 - - - lltemp2 = latlon2ul(&cp, &which2); - - switch (which1 + which2) { - case 3: /* 1 + 2, the only valid combination */ - if ((which1 == 1) && (which2 == 2)) { /* normal case */ - latit = lltemp1; - longit = lltemp2; - } else if ((which1 == 2) && (which2 == 1)) {/*reversed*/ - longit = lltemp1; - latit = lltemp2; - } else { /* some kind of brokenness */ - return 0; - } - break; - default: /* we didn't get one of each */ - return 0; - } - - /* altitude */ - if (*cp == '-') { - altsign = -1; - cp++; - } - - if (*cp == '+') - cp++; - - while (isdigit(*cp)) - altmeters = altmeters * 10 + (*cp++ - '0'); - - if (*cp == '.') { /* decimal meters */ - cp++; - if (isdigit(*cp)) { - altfrac = (*cp++ - '0') * 10; - if (isdigit(*cp)) { - altfrac += (*cp++ - '0'); - } - } - } - - alt = (10000000 + (altsign * (altmeters * 100 + altfrac))); - - while (!isspace(*cp) && (cp < maxcp)) - /* if trailing garbage or m */ - cp++; - - while (isspace(*cp) && (cp < maxcp)) - cp++; - - - -Davis, et al Experimental [Page 14] - -RFC 1876 Location Information in the DNS January 1996 - - - if (cp >= maxcp) - goto defaults; - - siz = precsize_aton(&cp); - - while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/ - cp++; - - while (isspace(*cp) && (cp < maxcp)) - cp++; - - if (cp >= maxcp) - goto defaults; - - hp = precsize_aton(&cp); - - while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/ - cp++; - - while (isspace(*cp) && (cp < maxcp)) - cp++; - - if (cp >= maxcp) - goto defaults; - - vp = precsize_aton(&cp); - - defaults: - - bcp = binary; - *bcp++ = (u_int8_t) 0; /* version byte */ - *bcp++ = siz; - *bcp++ = hp; - *bcp++ = vp; - PUTLONG(latit,bcp); - PUTLONG(longit,bcp); - PUTLONG(alt,bcp); - - return (16); /* size of RR in octets */ -} - -/* takes an on-the-wire LOC RR and prints it in zone file - * (human readable) format. */ -char * -loc_ntoa(binary,ascii) - const u_char *binary; - char *ascii; -{ - - - -Davis, et al Experimental [Page 15] - -RFC 1876 Location Information in the DNS January 1996 - - - static char tmpbuf[255*3]; - - register char *cp; - register const u_char *rcp; - - int latdeg, latmin, latsec, latsecfrac; - int longdeg, longmin, longsec, longsecfrac; - char northsouth, eastwest; - int altmeters, altfrac, altsign; - - const int referencealt = 100000 * 100; - - int32_t latval, longval, altval; - u_int32_t templ; - u_int8_t sizeval, hpval, vpval, versionval; - - char *sizestr, *hpstr, *vpstr; - - rcp = binary; - if (ascii) - cp = ascii; - else { - cp = tmpbuf; - } - - versionval = *rcp++; - - if (versionval) { - sprintf(cp,"; error: unknown LOC RR version"); - return (cp); - } - - sizeval = *rcp++; - - hpval = *rcp++; - vpval = *rcp++; - - GETLONG(templ,rcp); - latval = (templ - ((unsigned)1<<31)); - - GETLONG(templ,rcp); - longval = (templ - ((unsigned)1<<31)); - - GETLONG(templ,rcp); - if (templ < referencealt) { /* below WGS 84 spheroid */ - altval = referencealt - templ; - altsign = -1; - } else { - - - -Davis, et al Experimental [Page 16] - -RFC 1876 Location Information in the DNS January 1996 - - - altval = templ - referencealt; - altsign = 1; - } - - if (latval < 0) { - northsouth = 'S'; - latval = -latval; - } - else - northsouth = 'N'; - - latsecfrac = latval % 1000; - latval = latval / 1000; - latsec = latval % 60; - latval = latval / 60; - latmin = latval % 60; - latval = latval / 60; - latdeg = latval; - - if (longval < 0) { - eastwest = 'W'; - longval = -longval; - } - else - eastwest = 'E'; - - longsecfrac = longval % 1000; - longval = longval / 1000; - longsec = longval % 60; - longval = longval / 60; - longmin = longval % 60; - longval = longval / 60; - longdeg = longval; - - altfrac = altval % 100; - altmeters = (altval / 100) * altsign; - - sizestr = savestr(precsize_ntoa(sizeval)); - hpstr = savestr(precsize_ntoa(hpval)); - vpstr = savestr(precsize_ntoa(vpval)); - - sprintf(cp, - "%d %.2d %.2d.%.3d %c %d %.2d %.2d.%.3d %c %d.%.2dm - %sm %sm %sm", - latdeg, latmin, latsec, latsecfrac, northsouth, - longdeg, longmin, longsec, longsecfrac, eastwest, - altmeters, altfrac, sizestr, hpstr, vpstr); - - - - -Davis, et al Experimental [Page 17] - -RFC 1876 Location Information in the DNS January 1996 - - - free(sizestr); - free(hpstr); - free(vpstr); - - return (cp); -} - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Davis, et al Experimental [Page 18] - diff --git a/contrib/bind9/doc/rfc/rfc1886.txt b/contrib/bind9/doc/rfc/rfc1886.txt deleted file mode 100644 index 9874fddb17a5..000000000000 --- a/contrib/bind9/doc/rfc/rfc1886.txt +++ /dev/null @@ -1,268 +0,0 @@ - - - - - - -Network Working Group S. Thomson -Request for Comments: 1886 Bellcore -Category: Standards Track C. Huitema - INRIA - December 1995 - - - DNS Extensions to support IP version 6 - - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - - -Abstract - - This document defines the changes that need to be made to the Domain - Name System to support hosts running IP version 6 (IPv6). The - changes include a new resource record type to store an IPv6 address, - a new domain to support lookups based on an IPv6 address, and updated - definitions of existing query types that return Internet addresses as - part of additional section processing. The extensions are designed - to be compatible with existing applications and, in particular, DNS - implementations themselves. - - - - - - - - - - - - - - - - - - - -Thompson & Huitema Standards Track [Page 1] - -RFC 1886 IPv6 DNS Extensions December 1995 - - -1. INTRODUCTION - - Current support for the storage of Internet addresses in the Domain - Name System (DNS)[1,2] cannot easily be extended to support IPv6 - addresses[3] since applications assume that address queries return - 32-bit IPv4 addresses only. - - To support the storage of IPv6 addresses we define the following - extensions: - - o A new resource record type is defined to map a domain name to an - IPv6 address. - - o A new domain is defined to support lookups based on address. - - o Existing queries that perform additional section processing to - locate IPv4 addresses are redefined to perform additional - section processing on both IPv4 and IPv6 addresses. - - The changes are designed to be compatible with existing software. The - existing support for IPv4 addresses is retained. Transition issues - related to the co-existence of both IPv4 and IPv6 addresses in DNS - are discussed in [4]. - - -2. NEW RESOURCE RECORD DEFINITION AND DOMAIN - - A new record type is defined to store a host's IPv6 address. A host - that has more than one IPv6 address must have more than one such - record. - - -2.1 AAAA record type - - The AAAA resource record type is a new record specific to the - Internet class that stores a single IPv6 address. - - The value of the type is 28 (decimal). - - -2.2 AAAA data format - - A 128 bit IPv6 address is encoded in the data portion of an AAAA - resource record in network byte order (high-order byte first). - - - - -Thompson & Huitema Standards Track [Page 2] - -RFC 1886 IPv6 DNS Extensions December 1995 - - -2.3 AAAA query - - An AAAA query for a specified domain name in the Internet class - returns all associated AAAA resource records in the answer section of - a response. - - A type AAAA query does not perform additional section processing. - - -2.4 Textual format of AAAA records - - The textual representation of the data portion of the AAAA resource - record used in a master database file is the textual representation - of a IPv6 address as defined in [3]. - - -2.5 IP6.INT Domain - - A special domain is defined to look up a record given an address. The - intent of this domain is to provide a way of mapping an IPv6 address - to a host name, although it may be used for other purposes as well. - The domain is rooted at IP6.INT. - - An IPv6 address is represented as a name in the IP6.INT domain by a - sequence of nibbles separated by dots with the suffix ".IP6.INT". The - sequence of nibbles is encoded in reverse order, i.e. the low-order - nibble is encoded first, followed by the next low-order nibble and so - on. Each nibble is represented by a hexadecimal digit. For example, - the inverse lookup domain name corresponding to the address - - 4321:0:1:2:3:4:567:89ab - - would be - -b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT. - - - -3. MODIFICATIONS TO EXISTING QUERY TYPES - - All existing query types that perform type A additional section - processing, i.e. name server (NS), mail exchange (MX) and mailbox - (MB) query types, must be redefined to perform both type A and type - AAAA additional section processing. These new definitions mean that a - name server must add any relevant IPv4 addresses and any relevant - - - -Thompson & Huitema Standards Track [Page 3] - -RFC 1886 IPv6 DNS Extensions December 1995 - - - IPv6 addresses available locally to the additional section of a - response when processing any one of the above queries. - - -4. SECURITY CONSIDERATIONS - - Security issues are not discussed in this memo. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Thompson & Huitema Standards Track [Page 4] - -RFC 1886 IPv6 DNS Extensions December 1995 - - -5. REFERENCES - - - [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD - 13, RFC 1034, USC/Information Sciences Institute, November 1987. - - [2] Mockapetris, P., "Domain Names - Implementation and Specifica- - tion", STD 13, RFC 1035, USC/Information Sciences Institute, - November 1987. - - [3] Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing - Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December - 1995. - - - [4] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 - Hosts and Routers", Work in Progress. - - -Authors' Addresses - - Susan Thomson - Bellcore - MRE 2P343 - 445 South Street - Morristown, NJ 07960 - U.S.A. - - Phone: +1 201-829-4514 - EMail: set@thumper.bellcore.com - - - Christian Huitema - INRIA, Sophia-Antipolis - 2004 Route des Lucioles - BP 109 - F-06561 Valbonne Cedex - France - - Phone: +33 93 65 77 15 - EMail: Christian.Huitema@MIRSA.INRIA.FR - - - - - - - -Thompson & Huitema Standards Track [Page 5] - diff --git a/contrib/bind9/doc/rfc/rfc1982.txt b/contrib/bind9/doc/rfc/rfc1982.txt deleted file mode 100644 index 5a34bc42ab72..000000000000 --- a/contrib/bind9/doc/rfc/rfc1982.txt +++ /dev/null @@ -1,394 +0,0 @@ - - - - - - -Network Working Group R. Elz -Request for Comments: 1982 University of Melbourne -Updates: 1034, 1035 R. Bush -Category: Standards Track RGnet, Inc. - August 1996 - - - Serial Number Arithmetic - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - This memo defines serial number arithmetic, as used in the Domain - Name System. The DNS has long relied upon serial number arithmetic, - a concept which has never really been defined, certainly not in an - IETF document, though which has been widely understood. This memo - supplies the missing definition. It is intended to update RFC1034 - and RFC1035. - -1. Introduction - - The serial number field of the SOA resource record is defined in - RFC1035 as - - SERIAL The unsigned 32 bit version number of the original copy of - the zone. Zone transfers preserve this value. This value - wraps and should be compared using sequence space - arithmetic. - - RFC1034 uses the same terminology when defining secondary server zone - consistency procedures. - - Unfortunately the term "sequence space arithmetic" is not defined in - either RFC1034 or RFC1035, nor do any of their references provide - further information. - - This phrase seems to have been intending to specify arithmetic as - used in TCP sequence numbers [RFC793], and defined in [IEN-74]. - - Unfortunately, the arithmetic defined in [IEN-74] is not adequate for - the purposes of the DNS, as no general comparison operator is - - - -Elz & Bush Standards Track [Page 1] - -RFC 1982 Serial Number Arithmetic August 1996 - - - defined. - - To avoid further problems with this simple field, this document - defines the field and the operations available upon it. This - definition is intended merely to clarify the intent of RFC1034 and - RFC1035, and is believed to generally agree with current - implementations. However, older, superseded, implementations are - known to have treated the serial number as a simple unsigned integer, - with no attempt to implement any kind of "sequence space arithmetic", - however that may have been interpreted, and further, ignoring the - requirement that the value wraps. Nothing can be done with these - implementations, beyond extermination. - -2. Serial Number Arithmetic - - Serial numbers are formed from non-negative integers from a finite - subset of the range of all integer values. The lowest integer in - every subset used for this purpose is zero, the maximum is always one - less than a power of two. - - When considered as serial numbers however no value has any particular - significance, there is no minimum or maximum serial number, every - value has a successor and predecessor. - - To define a serial number to be used in this way, the size of the - serial number space must be given. This value, called "SERIAL_BITS", - gives the power of two which results in one larger than the largest - integer corresponding to a serial number value. This also specifies - the number of bits required to hold every possible value of a serial - number of the defined type. The operations permitted upon serial - numbers are defined in the following section. - -3. Operations upon the serial number - - Only two operations are defined upon serial numbers, addition of a - positive integer of limited range, and comparison with another serial - number. - -3.1. Addition - - Serial numbers may be incremented by the addition of a positive - integer n, where n is taken from the range of integers - [0 .. (2^(SERIAL_BITS - 1) - 1)]. For a sequence number s, the - result of such an addition, s', is defined as - - s' = (s + n) modulo (2 ^ SERIAL_BITS) - - - - - -Elz & Bush Standards Track [Page 2] - -RFC 1982 Serial Number Arithmetic August 1996 - - - where the addition and modulus operations here act upon values that - are non-negative values of unbounded size in the usual ways of - integer arithmetic. - - Addition of a value outside the range - [0 .. (2^(SERIAL_BITS - 1) - 1)] is undefined. - -3.2. Comparison - - Any two serial numbers, s1 and s2, may be compared. The definition - of the result of this comparison is as follows. - - For the purposes of this definition, consider two integers, i1 and - i2, from the unbounded set of non-negative integers, such that i1 and - s1 have the same numeric value, as do i2 and s2. Arithmetic and - comparisons applied to i1 and i2 use ordinary unbounded integer - arithmetic. - - Then, s1 is said to be equal to s2 if and only if i1 is equal to i2, - in all other cases, s1 is not equal to s2. - - s1 is said to be less than s2 if, and only if, s1 is not equal to s2, - and - - (i1 < i2 and i2 - i1 < 2^(SERIAL_BITS - 1)) or - (i1 > i2 and i1 - i2 > 2^(SERIAL_BITS - 1)) - - s1 is said to be greater than s2 if, and only if, s1 is not equal to - s2, and - - (i1 < i2 and i2 - i1 > 2^(SERIAL_BITS - 1)) or - (i1 > i2 and i1 - i2 < 2^(SERIAL_BITS - 1)) - - Note that there are some pairs of values s1 and s2 for which s1 is - not equal to s2, but for which s1 is neither greater than, nor less - than, s2. An attempt to use these ordering operators on such pairs - of values produces an undefined result. - - The reason for this is that those pairs of values are such that any - simple definition that were to define s1 to be less than s2 where - (s1, s2) is such a pair, would also usually cause s2 to be less than - s1, when the pair is (s2, s1). This would mean that the particular - order selected for a test could cause the result to differ, leading - to unpredictable implementations. - - While it would be possible to define the test in such a way that the - inequality would not have this surprising property, while being - defined for all pairs of values, such a definition would be - - - -Elz & Bush Standards Track [Page 3] - -RFC 1982 Serial Number Arithmetic August 1996 - - - unnecessarily burdensome to implement, and difficult to understand, - and would still allow cases where - - s1 < s2 and (s1 + 1) > (s2 + 1) - - which is just as non-intuitive. - - Thus the problem case is left undefined, implementations are free to - return either result, or to flag an error, and users must take care - not to depend on any particular outcome. Usually this will mean - avoiding allowing those particular pairs of numbers to co-exist. - - The relationships greater than or equal to, and less than or equal - to, follow in the natural way from the above definitions. - -4. Corollaries - - These definitions give rise to some results of note. - -4.1. Corollary 1 - - For any sequence number s and any integer n such that addition of n - to s is well defined, (s + n) >= s. Further (s + n) == s only when - n == 0, in all other defined cases, (s + n) > s. - -4.2. Corollary 2 - - If s' is the result of adding the non-zero integer n to the sequence - number s, and m is another integer from the range defined as able to - be added to a sequence number, and s" is the result of adding m to - s', then it is undefined whether s" is greater than, or less than s, - though it is known that s" is not equal to s. - -4.3. Corollary 3 - - If s" from the previous corollary is further incremented, then there - is no longer any known relationship between the result and s. - -4.4. Corollary 4 - - If in corollary 2 the value (n + m) is such that addition of the sum - to sequence number s would produce a defined result, then corollary 1 - applies, and s" is known to be greater than s. - - - - - - - - -Elz & Bush Standards Track [Page 4] - -RFC 1982 Serial Number Arithmetic August 1996 - - -5. Examples - -5.1. A trivial example - - The simplest meaningful serial number space has SERIAL_BITS == 2. In - this space, the integers that make up the serial number space are 0, - 1, 2, and 3. That is, 3 == 2^SERIAL_BITS - 1. - - In this space, the largest integer that it is meaningful to add to a - sequence number is 2^(SERIAL_BITS - 1) - 1, or 1. - - Then, as defined 0+1 == 1, 1+1 == 2, 2+1 == 3, and 3+1 == 0. - Further, 1 > 0, 2 > 1, 3 > 2, and 0 > 3. It is undefined whether - 2 > 0 or 0 > 2, and whether 1 > 3 or 3 > 1. - -5.2. A slightly larger example - - Consider the case where SERIAL_BITS == 8. In this space the integers - that make up the serial number space are 0, 1, 2, ... 254, 255. - 255 == 2^SERIAL_BITS - 1. - - In this space, the largest integer that it is meaningful to add to a - sequence number is 2^(SERIAL_BITS - 1) - 1, or 127. - - Addition is as expected in this space, for example: 255+1 == 0, - 100+100 == 200, and 200+100 == 44. - - Comparison is more interesting, 1 > 0, 44 > 0, 100 > 0, 100 > 44, - 200 > 100, 255 > 200, 0 > 255, 100 > 255, 0 > 200, and 44 > 200. - - Note that 100+100 > 100, but that (100+100)+100 < 100. Incrementing - a serial number can cause it to become "smaller". Of course, - incrementing by a smaller number will allow many more increments to - be made before this occurs. However this is always something to be - aware of, it can cause surprising errors, or be useful as it is the - only defined way to actually cause a serial number to decrease. - - The pairs of values 0 and 128, 1 and 129, 2 and 130, etc, to 127 and - 255 are not equal, but in each pair, neither number is defined as - being greater than, or less than, the other. - - It could be defined (arbitrarily) that 128 > 0, 129 > 1, - 130 > 2, ..., 255 > 127, by changing the comparison operator - definitions, as mentioned above. However note that that would cause - 255 > 127, while (255 + 1) < (127 + 1), as 0 < 128. Such a - definition, apart from being arbitrary, would also be more costly to - implement. - - - - -Elz & Bush Standards Track [Page 5] - -RFC 1982 Serial Number Arithmetic August 1996 - - -6. Citation - - As this defined arithmetic may be useful for purposes other than for - the DNS serial number, it may be referenced as Serial Number - Arithmetic from RFC1982. Any such reference shall be taken as - implying that the rules of sections 2 to 5 of this document apply to - the stated values. - -7. The DNS SOA serial number - - The serial number in the DNS SOA Resource Record is a Serial Number - as defined above, with SERIAL_BITS being 32. That is, the serial - number is a non negative integer with values taken from the range - [0 .. 4294967295]. That is, a 32 bit unsigned integer. - - The maximum defined increment is 2147483647 (2^31 - 1). - - Care should be taken that the serial number not be incremented, in - one or more steps, by more than this maximum within the period given - by the value of SOA.expire. Doing so may leave some secondary - servers with out of date copies of the zone, but with a serial number - "greater" than that of the primary server. Of course, special - circumstances may require this rule be set aside, for example, when - the serial number needs to be set lower for some reason. If this - must be done, then take special care to verify that ALL servers have - correctly succeeded in following the primary server's serial number - changes, at each step. - - Note that each, and every, increment to the serial number must be - treated as the start of a new sequence of increments for this - purpose, as well as being the continuation of all previous sequences - started within the period specified by SOA.expire. - - Caution should also be exercised before causing the serial number to - be set to the value zero. While this value is not in any way special - in serial number arithmetic, or to the DNS SOA serial number, many - DNS implementations have incorrectly treated zero as a special case, - with special properties, and unusual behaviour may be expected if - zero is used as a DNS SOA serial number. - - - - - - - - - - - - -Elz & Bush Standards Track [Page 6] - -RFC 1982 Serial Number Arithmetic August 1996 - - -8. Document Updates - - RFC1034 and RFC1035 are to be treated as if the references to - "sequence space arithmetic" therein are replaced by references to - serial number arithmetic, as defined in this document. - -9. Security Considerations - - This document does not consider security. - - It is not believed that anything in this document adds to any - security issues that may exist with the DNS, nor does it do anything - to lessen them. - -References - - [RFC1034] Domain Names - Concepts and Facilities, - P. Mockapetris, STD 13, ISI, November 1987. - - [RFC1035] Domain Names - Implementation and Specification - P. Mockapetris, STD 13, ISI, November 1987 - - [RFC793] Transmission Control protocol - Information Sciences Institute, STD 7, USC, September 1981 - - [IEN-74] Sequence Number Arithmetic - William W. Plummer, BB&N Inc, September 1978 - -Acknowledgements - - Thanks to Rob Austein for suggesting clarification of the undefined - comparison operators, and to Michael Patton for attempting to locate - another reference for this procedure. Thanks also to members of the - IETF DNSIND working group of 1995-6, in particular, Paul Mockapetris. - -Authors' Addresses - - Robert Elz Randy Bush - Computer Science RGnet, Inc. - University of Melbourne 10361 NE Sasquatch Lane - Parkville, Vic, 3052 Bainbridge Island, Washington, 98110 - Australia. United States. - - EMail: kre@munnari.OZ.AU EMail: randy@psg.com - - - - - - - -Elz & Bush Standards Track [Page 7] diff --git a/contrib/bind9/doc/rfc/rfc1995.txt b/contrib/bind9/doc/rfc/rfc1995.txt deleted file mode 100644 index b50bdc604870..000000000000 --- a/contrib/bind9/doc/rfc/rfc1995.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -Network Working Group M. Ohta -Request for Comments: 1995 Tokyo Institute of Technology -Updates: 1035 August 1996 -Category: Standards Track - - - Incremental Zone Transfer in DNS - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - This document proposes extensions to the DNS protocols to provide an - incremental zone transfer (IXFR) mechanism. - -1. Introduction - - For rapid propagation of changes to a DNS database [STD13], it is - necessary to reduce latency by actively notifying servers of the - change. This is accomplished by the NOTIFY extension of the DNS - [NOTIFY]. - - The current full zone transfer mechanism (AXFR) is not an efficient - means to propagate changes to a small part of a zone, as it transfers - the entire zone file. - - Incremental transfer (IXFR) as proposed is a more efficient - mechanism, as it transfers only the changed portion(s) of a zone. - - In this document, a secondary name server which requests IXFR is - called an IXFR client and a primary or secondary name server which - responds to the request is called an IXFR server. - -2. Brief Description of the Protocol - - If an IXFR client, which likely has an older version of a zone, - thinks it needs new information about the zone (typically through SOA - refresh timeout or the NOTIFY mechanism), it sends an IXFR message - containing the SOA serial number of its, presumably outdated, copy of - the zone. - - - - - -Ohta Standards Track [Page 1] - -RFC 1995 Incremental Zone Transfer in DNS August 1996 - - - An IXFR server should keep record of the newest version of the zone - and the differences between that copy and several older versions. - When an IXFR request with an older version number is received, the - IXFR server needs to send only the differences required to make that - version current. Alternatively, the server may choose to transfer - the entire zone just as in a normal full zone transfer. - - When a zone has been updated, it should be saved in stable storage - before the new version is used to respond to IXFR (or AXFR) queries. - Otherwise, if the server crashes, data which is no longer available - may have been distributed to secondary servers, which can cause - persistent database inconsistencies. - - If an IXFR query with the same or newer version number than that of - the server is received, it is replied to with a single SOA record of - the server's current version, just as in AXFR. - - Transport of a query may be by either UDP or TCP. If an IXFR query - is via UDP, the IXFR server may attempt to reply using UDP if the - entire response can be contained in a single DNS packet. If the UDP - reply does not fit, the query is responded to with a single SOA - record of the server's current version to inform the client that a - TCP query should be initiated. - - Thus, a client should first make an IXFR query using UDP. If the - query type is not recognized by the server, an AXFR (preceded by a - UDP SOA query) should be tried, ensuring backward compatibility. If - the query response is a single packet with the entire new zone, or if - the server does not have a newer version than the client, everything - is done. Otherwise, a TCP IXFR query should be tried. - - To ensure integrity, servers should use UDP checksums for all UDP - responses. A cautious client which receives a UDP packet with a - checksum value of zero should ignore the result and try a TCP IXFR - instead. - - The query type value of IXFR assigned by IANA is 251. - -3. Query Format - - The IXFR query packet format is the same as that of a normal DNS - query, but with the query type being IXFR and the authority section - containing the SOA record of client's version of the zone. - - - - - - - - -Ohta Standards Track [Page 2] - -RFC 1995 Incremental Zone Transfer in DNS August 1996 - - -4. Response Format - - If incremental zone transfer is not available, the entire zone is - returned. The first and the last RR of the response is the SOA - record of the zone. I.e. the behavior is the same as an AXFR - response except the query type is IXFR. - - If incremental zone transfer is available, one or more difference - sequences is returned. The list of difference sequences is preceded - and followed by a copy of the server's current version of the SOA. - - Each difference sequence represents one update to the zone (one SOA - serial change) consisting of deleted RRs and added RRs. The first RR - of the deleted RRs is the older SOA RR and the first RR of the added - RRs is the newer SOA RR. - - Modification of an RR is performed first by removing the original RR - and then adding the modified one. - - The sequences of differential information are ordered oldest first - newest last. Thus, the differential sequences are the history of - changes made since the version known by the IXFR client up to the - server's current version. - - RRs in the incremental transfer messages may be partial. That is, if - a single RR of multiple RRs of the same RR type changes, only the - changed RR is transferred. - - An IXFR client, should only replace an older version with a newer - version after all the differences have been successfully processed. - - An incremental response is different from that of a non-incremental - response in that it begins with two SOA RRs, the server's current SOA - followed by the SOA of the client's version which is about to be - replaced. - - 5. Purging Strategy - - An IXFR server can not be required to hold all previous versions - forever and may delete them anytime. In general, there is a trade-off - between the size of storage space and the possibility of using IXFR. - - Information about older versions should be purged if the total length - of an IXFR response would be longer than that of an AXFR response. - Given that the purpose of IXFR is to reduce AXFR overhead, this - strategy is quite reasonable. The strategy assures that the amount - of storage required is at most twice that of the current zone - information. - - - -Ohta Standards Track [Page 3] - -RFC 1995 Incremental Zone Transfer in DNS August 1996 - - - Information older than the SOA expire period may also be purged. - -6. Optional Condensation of Multiple Versions - - An IXFR server may optionally condense multiple difference sequences - into a single difference sequence, thus, dropping information on - intermediate versions. - - This may be beneficial if a lot of versions, not all of which are - useful, are generated. For example, if multiple ftp servers share a - single DNS name and the IP address associated with the name is - changed once a minute to balance load between the ftp servers, it is - not so important to keep track of all the history of changes. - - But, this feature may not be so useful if an IXFR client has access - to two IXFR servers: A and B, with inconsistent condensation results. - The current version of the IXFR client, received from server A, may - be unknown to server B. In such a case, server B can not provide - incremental data from the unknown version and a full zone transfer is - necessary. - - Condensation is completely optional. Clients can't detect from the - response whether the server has condensed the reply or not. - - For interoperability, IXFR servers, including those without the - condensation feature, should not flag an error even if it receives a - client's IXFR request with a unknown version number and should, - instead, attempt to perform a full zone transfer. - -7. Example - - Given the following three generations of data with the current serial - number of 3, - - JAIN.AD.JP. IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp. ( - 1 600 600 3600000 604800) - IN NS NS.JAIN.AD.JP. - NS.JAIN.AD.JP. IN A 133.69.136.1 - NEZU.JAIN.AD.JP. IN A 133.69.136.5 - - NEZU.JAIN.AD.JP. is removed and JAIN-BB.JAIN.AD.JP. is added. - - jain.ad.jp. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. ( - 2 600 600 3600000 604800) - IN NS NS.JAIN.AD.JP. - NS.JAIN.AD.JP. IN A 133.69.136.1 - JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 - IN A 192.41.197.2 - - - -Ohta Standards Track [Page 4] - -RFC 1995 Incremental Zone Transfer in DNS August 1996 - - - One of the IP addresses of JAIN-BB.JAIN.AD.JP. is changed. - - JAIN.AD.JP. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. ( - 3 600 600 3600000 604800) - IN NS NS.JAIN.AD.JP. - NS.JAIN.AD.JP. IN A 133.69.136.1 - JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 - IN A 192.41.197.2 - - The following IXFR query - - +---------------------------------------------------+ - Header | OPCODE=SQUERY | - +---------------------------------------------------+ - Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | - +---------------------------------------------------+ - Answer | <empty> | - +---------------------------------------------------+ - Authority | JAIN.AD.JP. IN SOA serial=1 | - +---------------------------------------------------+ - Additional | <empty> | - +---------------------------------------------------+ - - could be replied to with the following full zone transfer message: - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE | - +---------------------------------------------------+ - Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | - +---------------------------------------------------+ - Answer | JAIN.AD.JP. IN SOA serial=3 | - | JAIN.AD.JP. IN NS NS.JAIN.AD.JP. | - | NS.JAIN.AD.JP. IN A 133.69.136.1 | - | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 | - | JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 | - | JAIN.AD.JP. IN SOA serial=3 | - +---------------------------------------------------+ - Authority | <empty> | - +---------------------------------------------------+ - Additional | <empty> | - +---------------------------------------------------+ - - - - - - - - - - -Ohta Standards Track [Page 5] - -RFC 1995 Incremental Zone Transfer in DNS August 1996 - - - or with the following incremental message: - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE | - +---------------------------------------------------+ - Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | - +---------------------------------------------------+ - Answer | JAIN.AD.JP. IN SOA serial=3 | - | JAIN.AD.JP. IN SOA serial=1 | - | NEZU.JAIN.AD.JP. IN A 133.69.136.5 | - | JAIN.AD.JP. IN SOA serial=2 | - | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 | - | JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 | - | JAIN.AD.JP. IN SOA serial=2 | - | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.4 | - | JAIN.AD.JP. IN SOA serial=3 | - | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 | - | JAIN.AD.JP. IN SOA serial=3 | - +---------------------------------------------------+ - Authority | <empty> | - +---------------------------------------------------+ - Additional | <empty> | - +---------------------------------------------------+ - - or with the following condensed incremental message: - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE | - +---------------------------------------------------+ - Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | - +---------------------------------------------------+ - Answer | JAIN.AD.JP. IN SOA serial=3 | - | JAIN.AD.JP. IN SOA serial=1 | - | NEZU.JAIN.AD.JP. IN A 133.69.136.5 | - | JAIN.AD.JP. IN SOA serial=3 | - | JAIN-BB.JAIN.AD.JP. IN A 133.69.136.3 | - | JAIN-BB.JAIN.AD.JP. IN A 192.41.197.2 | - | JAIN.AD.JP. IN SOA serial=3 | - +---------------------------------------------------+ - Authority | <empty> | - +---------------------------------------------------+ - Additional | <empty> | - +---------------------------------------------------+ - - - - - - - - -Ohta Standards Track [Page 6] - -RFC 1995 Incremental Zone Transfer in DNS August 1996 - - - or, if UDP packet overflow occurs, with the following message: - - +---------------------------------------------------+ - Header | OPCODE=SQUERY, RESPONSE | - +---------------------------------------------------+ - Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR | - +---------------------------------------------------+ - Answer | JAIN.AD.JP. IN SOA serial=3 | - +---------------------------------------------------+ - Authority | <empty> | - +---------------------------------------------------+ - Additional | <empty> | - +---------------------------------------------------+ - -8. Acknowledgements - - The original idea of IXFR was conceived by Anant Kumar, Steve Hotz - and Jon Postel. - - For the refinement of the protocol and documentation, many people - have contributed including, but not limited to, Anant Kumar, Robert - Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz and the - members of the IETF DNSIND working group. - -9. References - - [NOTIFY] Vixie, P., "DNS NOTIFY: A Mechanism for Prompt - Notification of Zone Changes", RFC 1996, August 1996. - - [STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034 and - RFC 1035), November 1987. - -10. Security Considerations - - Though DNS is related to several security problems, no attempt is - made to fix them in this document. - - This document is believed to introduce no additional security - problems to the current DNS protocol. - - - - - - - - - - - - -Ohta Standards Track [Page 7] - -RFC 1995 Incremental Zone Transfer in DNS August 1996 - - -11. Author's Address - - Masataka Ohta - Computer Center - Tokyo Institute of Technology - 2-12-1, O-okayama, Meguro-ku, Tokyo 152, JAPAN - - Phone: +81-3-5734-3299 - Fax: +81-3-5734-3415 - EMail: mohta@necom830.hpcl.titech.ac.jp - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Ohta Standards Track [Page 8] - diff --git a/contrib/bind9/doc/rfc/rfc1996.txt b/contrib/bind9/doc/rfc/rfc1996.txt deleted file mode 100644 index b08f2007972f..000000000000 --- a/contrib/bind9/doc/rfc/rfc1996.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -Network Working Group P. Vixie -Request for Comments: 1996 ISC -Updates: 1035 August 1996 -Category: Standards Track - - - A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - This memo describes the NOTIFY opcode for DNS, by which a master - server advises a set of slave servers that the master's data has been - changed and that a query should be initiated to discover the new - data. - -1. Rationale and Scope - - 1.1. Slow propagation of new and changed data in a DNS zone can be - due to a zone's relatively long refresh times. Longer refresh times - are beneficial in that they reduce load on the master servers, but - that benefit comes at the cost of long intervals of incoherence among - authority servers whenever the zone is updated. - - 1.2. The DNS NOTIFY transaction allows master servers to inform slave - servers when the zone has changed -- an interrupt as opposed to poll - model -- which it is hoped will reduce propagation delay while not - unduly increasing the masters' load. This specification only allows - slaves to be notified of SOA RR changes, but the architechture of - NOTIFY is intended to be extensible to other RR types. - - 1.3. This document intentionally gives more definition to the roles - of "Master," "Slave" and "Stealth" servers, their enumeration in NS - RRs, and the SOA MNAME field. In that sense, this document can be - considered an addendum to [RFC1035]. - - - - - - - - - -Vixie Standards Track [Page 1] - -RFC 1996 DNS NOTIFY August 1996 - - -2. Definitions and Invariants - - 2.1. The following definitions are used in this document: - - Slave an authoritative server which uses zone transfer to - retrieve the zone. All slave servers are named in - the NS RRs for the zone. - - Master any authoritative server configured to be the source - of zone transfer for one or more slave servers. - - Primary Master master server at the root of the zone transfer - dependency graph. The primary master is named in the - zone's SOA MNAME field and optionally by an NS RR. - There is by definition only one primary master server - per zone. - - Stealth like a slave server except not listed in an NS RR for - the zone. A stealth server, unless explicitly - configured to do otherwise, will set the AA bit in - responses and be capable of acting as a master. A - stealth server will only be known by other servers if - they are given static configuration data indicating - its existence. - - Notify Set set of servers to be notified of changes to some - zone. Default is all servers named in the NS RRset, - except for any server also named in the SOA MNAME. - Some implementations will permit the name server - administrator to override this set or add elements to - it (such as, for example, stealth servers). - - 2.2. The zone's servers must be organized into a dependency graph - such that there is a primary master, and all other servers must use - AXFR or IXFR either from the primary master or from some slave which - is also a master. No loops are permitted in the AXFR dependency - graph. - -3. NOTIFY Message - - 3.1. When a master has updated one or more RRs in which slave servers - may be interested, the master may send the changed RR's name, class, - type, and optionally, new RDATA(s), to each known slave server using - a best efforts protocol based on the NOTIFY opcode. - - 3.2. NOTIFY uses the DNS Message Format, although it uses only a - subset of the available fields. Fields not otherwise described - herein are to be filled with binary zero (0), and implementations - - - -Vixie Standards Track [Page 2] - -RFC 1996 DNS NOTIFY August 1996 - - - must ignore all messages for which this is not the case. - - 3.3. NOTIFY is similar to QUERY in that it has a request message with - the header QR flag "clear" and a response message with QR "set". The - response message contains no useful information, but its reception by - the master is an indication that the slave has received the NOTIFY - and that the master can remove the slave from any retry queue for - this NOTIFY event. - - 3.4. The transport protocol used for a NOTIFY transaction will be UDP - unless the master has reason to believe that TCP is necessary; for - example, if a firewall has been installed between master and slave, - and only TCP has been allowed; or, if the changed RR is too large to - fit in a UDP/DNS datagram. - - 3.5. If TCP is used, both master and slave must continue to offer - name service during the transaction, even when the TCP transaction is - not making progress. The NOTIFY request is sent once, and a - "timeout" is said to have occurred if no NOTIFY response is received - within a reasonable interval. - - 3.6. If UDP is used, a master periodically sends a NOTIFY request to - a slave until either too many copies have been sent (a "timeout"), an - ICMP message indicating that the port is unreachable, or until a - NOTIFY response is received from the slave with a matching query ID, - QNAME, IP source address, and UDP source port number. - - Note: - The interval between transmissions, and the total number of - retransmissions, should be operational parameters specifiable by - the name server administrator, perhaps on a per-zone basis. - Reasonable defaults are a 60 second interval (or timeout if - using TCP), and a maximum of 5 retransmissions (for UDP). It is - considered reasonable to use additive or exponential backoff for - the retry interval. - - 3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0, - ADCOUNT>=0. If ANCOUNT>0, then the answer section represents an - unsecure hint at the new RRset for this <QNAME,QCLASS,QTYPE>. A - slave receiving such a hint is free to treat equivilence of this - answer section with its local data as a "no further work needs to be - done" indication. If ANCOUNT=0, or ANCOUNT>0 and the answer section - differs from the slave's local data, then the slave should query its - known masters to retrieve the new data. - - 3.8. In no case shall the answer section of a NOTIFY request be used - to update a slave's local data, or to indicate that a zone transfer - needs to be undertaken, or to change the slave's zone refresh timers. - - - -Vixie Standards Track [Page 3] - -RFC 1996 DNS NOTIFY August 1996 - - - Only a "data present; data same" condition can lead a slave to act - differently if ANCOUNT>0 than it would if ANCOUNT=0. - - 3.9. This version of the NOTIFY specification makes no use of the - authority or additional data sections, and so conforming - implementations should set AUCOUNT=0 and ADCOUNT=0 when transmitting - requests. Since a future revision of this specification may define a - backwards compatible use for either or both of these sections, - current implementations must ignore these sections, but not the - entire message, if AUCOUNT>0 and/or ADCOUNT>0. - - 3.10. If a slave receives a NOTIFY request from a host that is not a - known master for the zone containing the QNAME, it should ignore the - request and produce an error message in its operations log. - - Note: - This implies that slaves of a multihomed master must either know - their master by the "closest" of the master's interface - addresses, or must know all of the master's interface addresses. - Otherwise, a valid NOTIFY request might come from an address - that is not on the slave's state list of masters for the zone, - which would be an error. - - 3.11. The only defined NOTIFY event at this time is that the SOA RR - has changed. Upon completion of a NOTIFY transaction for QTYPE=SOA, - the slave should behave as though the zone given in the QNAME had - reached its REFRESH interval (see [RFC1035]), i.e., it should query - its masters for the SOA of the zone given in the NOTIFY QNAME, and - check the answer to see if the SOA SERIAL has been incremented since - the last time the zone was fetched. If so, a zone transfer (either - AXFR or IXFR) should be initiated. - - Note: - Because a deep server dependency graph may have multiple paths - from the primary master to any given slave, it is possible that - a slave will receive a NOTIFY from one of its known masters even - though the rest of its known masters have not yet updated their - copies of the zone. Therefore, when issuing a QUERY for the - zone's SOA, the query should be directed at the known master who - was the source of the NOTIFY event, and not at any of the other - known masters. This represents a departure from [RFC1035], - which specifies that upon expiry of the SOA REFRESH interval, - all known masters should be queried in turn. - - 3.12. If a NOTIFY request is received by a slave who does not - implement the NOTIFY opcode, it will respond with a NOTIMP - (unimplemented feature error) message. A master server who receives - such a NOTIMP should consider the NOTIFY transaction complete for - - - -Vixie Standards Track [Page 4] - -RFC 1996 DNS NOTIFY August 1996 - - - that slave. - -4. Details and Examples - - 4.1. Retaining query state information across host reboots is - optional, but it is reasonable to simply execute an SOA NOTIFY - transaction on each authority zone when a server first starts. - - 4.2. Each slave is likely to receive several copies of the same - NOTIFY request: One from the primary master, and one from each other - slave as that slave transfers the new zone and notifies its potential - peers. The NOTIFY protocol supports this multiplicity by requiring - that NOTIFY be sent by a slave/master only AFTER it has updated the - SOA RR or has determined that no update is necessary, which in - practice means after a successful zone transfer. Thus, barring - delivery reordering, the last NOTIFY any slave receives will be the - one indicating the latest change. Since a slave always requests SOAs - and AXFR/IXFRs only from its known masters, it will have an - opportunity to retry its QUERY for the SOA after each of its masters - have completed each zone update. - - 4.3. If a master server seeks to avoid causing a large number of - simultaneous outbound zone transfers, it may delay for an arbitrary - length of time before sending a NOTIFY message to any given slave. - It is expected that the time will be chosen at random, so that each - slave will begin its transfer at a unique time. The delay shall not - in any case be longer than the SOA REFRESH time. - - Note: - This delay should be a parameter that each primary master name - server can specify, perhaps on a per-zone basis. Random delays - of between 30 and 60 seconds would seem adequate if the servers - share a LAN and the zones are of moderate size. - - 4.4. A slave which receives a valid NOTIFY should defer action on any - subsequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has - completed the transaction begun by the first NOTIFY. This duplicate - rejection is necessary to avoid having multiple notifications lead to - pummeling the master server. - - - - - - - - - - - - -Vixie Standards Track [Page 5] - -RFC 1996 DNS NOTIFY August 1996 - - - 4.5 Zone has Updated on Primary Master - - Primary master sends a NOTIFY request to all servers named in Notify - Set. The NOTIFY request has the following characteristics: - - query ID: (new) - op: NOTIFY (4) - resp: NOERROR - flags: AA - qcount: 1 - qname: (zone name) - qclass: (zone class) - qtype: T_SOA - - 4.6 Zone has Updated on a Slave that is also a Master - - As above in 4.5, except that this server's Notify Set may be - different from the Primary Master's due to optional static - specification of local stealth servers. - - 4.7 Slave Receives a NOTIFY Request from a Master - - When a slave server receives a NOTIFY request from one of its locally - designated masters for the zone enclosing the given QNAME, with - QTYPE=SOA and QR=0, it should enter the state it would if the zone's - refresh timer had expired. It will also send a NOTIFY response back - to the NOTIFY request's source, with the following characteristics: - - query ID: (same) - op: NOTIFY (4) - resp: NOERROR - flags: QR AA - qcount: 1 - qname: (zone name) - qclass: (zone class) - qtype: T_SOA - - This is intended to be identical to the NOTIFY request, except that - the QR bit is also set. The query ID of the response must be the - same as was received in the request. - - 4.8 Master Receives a NOTIFY Response from Slave - - When a master server receives a NOTIFY response, it deletes this - query from the retry queue, thus completing the "notification - process" of "this" RRset change to "that" server. - - - - - -Vixie Standards Track [Page 6] - -RFC 1996 DNS NOTIFY August 1996 - - -5. Security Considerations - - We believe that the NOTIFY operation's only security considerations - are: - - 1. That a NOTIFY request with a forged IP/UDP source address can - cause a slave to send spurious SOA queries to its masters, - leading to a benign denial of service attack if the forged - requests are sent very often. - - 2. That TCP spoofing could be used against a slave server given - NOTIFY as a means of synchronizing an SOA query and UDP/DNS - spoofing as a means of forcing a zone transfer. - -6. References - - [RFC1035] - Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - [IXFR] - Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996. - -7. Author's Address - - Paul Vixie - Internet Software Consortium - Star Route Box 159A - Woodside, CA 94062 - - Phone: +1 415 747 0204 - EMail: paul@vix.com - - - - - - - - - - - - - - - - - - - -Vixie Standards Track [Page 7] - diff --git a/contrib/bind9/doc/rfc/rfc2052.txt b/contrib/bind9/doc/rfc/rfc2052.txt deleted file mode 100644 index 46ba36296b96..000000000000 --- a/contrib/bind9/doc/rfc/rfc2052.txt +++ /dev/null @@ -1,563 +0,0 @@ - - - - - - -Network Working Group A. Gulbrandsen -Request for Comments: 2052 Troll Technologies -Updates: 1035, 1183 P. Vixie -Category: Experimental Vixie Enterprises - October 1996 - - - A DNS RR for specifying the location of services (DNS SRV) - -Status of this Memo - - This memo defines an Experimental Protocol for the Internet - community. This memo does not specify an Internet standard of any - kind. Discussion and suggestions for improvement are requested. - Distribution of this memo is unlimited. - -Abstract - - This document describes a DNS RR which specifies the location of the - server(s) for a specific protocol and domain (like a more general - form of MX). - -Overview and rationale - - Currently, one must either know the exact address of a server to - contact it, or broadcast a question. This has led to, for example, - ftp.whatever.com aliases, the SMTP-specific MX RR, and using MAC- - level broadcasts to locate servers. - - The SRV RR allows administrators to use several servers for a single - domain, to move services from host to host with little fuss, and to - designate some hosts as primary servers for a service and others as - backups. - - Clients ask for a specific service/protocol for a specific domain - (the word domain is used here in the strict RFC 1034 sense), and get - back the names of any available servers. - -Introductory example - - When a SRV-cognizant web-browser wants to retrieve - - http://www.asdf.com/ - - it does a lookup of - - http.tcp.www.asdf.com - - - - -Gulbrandsen & Vixie Experimental [Page 1] - -RFC 2052 DNS SRV RR October 1996 - - - and retrieves the document from one of the servers in the reply. The - example zone file near the end of the memo contains answering RRs for - this query. - -The format of the SRV RR - - Here is the format of the SRV RR, whose DNS type code is 33: - - Service.Proto.Name TTL Class SRV Priority Weight Port Target - - (There is an example near the end of this document.) - - Service - The symbolic name of the desired service, as defined in Assigned - Numbers or locally. - - Some widely used services, notably POP, don't have a single - universal name. If Assigned Numbers names the service - indicated, that name is the only name which is legal for SRV - lookups. Only locally defined services may be named locally. - The Service is case insensitive. - - Proto - TCP and UDP are at present the most useful values - for this field, though any name defined by Assigned Numbers or - locally may be used (as for Service). The Proto is case - insensitive. - - Name - The domain this RR refers to. The SRV RR is unique in that the - name one searches for is not this name; the example near the end - shows this clearly. - - TTL - Standard DNS meaning. - - Class - Standard DNS meaning. - - Priority - As for MX, the priority of this target host. A client MUST - attempt to contact the target host with the lowest-numbered - priority it can reach; target hosts with the same priority - SHOULD be tried in pseudorandom order. The range is 0-65535. - - - - - - - -Gulbrandsen & Vixie Experimental [Page 2] - -RFC 2052 DNS SRV RR October 1996 - - - Weight - Load balancing mechanism. When selecting a target host among - the those that have the same priority, the chance of trying this - one first SHOULD be proportional to its weight. The range of - this number is 1-65535. Domain administrators are urged to use - Weight 0 when there isn't any load balancing to do, to make the - RR easier to read for humans (less noisy). - - Port - The port on this target host of this service. The range is - 0-65535. This is often as specified in Assigned Numbers but - need not be. - - Target - As for MX, the domain name of the target host. There MUST be - one or more A records for this name. Implementors are urged, but - not required, to return the A record(s) in the Additional Data - section. Name compression is to be used for this field. - - A Target of "." means that the service is decidedly not - available at this domain. - -Domain administrator advice - - Asking everyone to update their telnet (for example) clients when the - first internet site adds a SRV RR for Telnet/TCP is futile (even if - desirable). Therefore SRV will have to coexist with A record lookups - for a long time, and DNS administrators should try to provide A - records to support old clients: - - - Where the services for a single domain are spread over several - hosts, it seems advisable to have a list of A RRs at the same - DNS node as the SRV RR, listing reasonable (if perhaps - suboptimal) fallback hosts for Telnet, NNTP and other protocols - likely to be used with this name. Note that some programs only - try the first address they get back from e.g. gethostbyname(), - and we don't know how widespread this behaviour is. - - - Where one service is provided by several hosts, one can either - provide A records for all the hosts (in which case the round- - robin mechanism, where available, will share the load equally) - or just for one (presumably the fastest). - - - If a host is intended to provide a service only when the main - server(s) is/are down, it probably shouldn't be listed in A - records. - - - - - -Gulbrandsen & Vixie Experimental [Page 3] - -RFC 2052 DNS SRV RR October 1996 - - - - Hosts that are referenced by backup A records must use the port - number specified in Assigned Numbers for the service. - - Currently there's a practical limit of 512 bytes for DNS replies. - Until all resolvers can handle larger responses, domain - administrators are strongly advised to keep their SRV replies below - 512 bytes. - - All round numbers, wrote Dr. Johnson, are false, and these numbers - are very round: A reply packet has a 30-byte overhead plus the name - of the service ("telnet.tcp.asdf.com" for instance); each SRV RR adds - 20 bytes plus the name of the target host; each NS RR in the NS - section is 15 bytes plus the name of the name server host; and - finally each A RR in the additional data section is 20 bytes or so, - and there are A's for each SRV and NS RR mentioned in the answer. - This size estimate is extremely crude, but shouldn't underestimate - the actual answer size by much. If an answer may be close to the - limit, using e.g. "dig" to look at the actual answer is a good idea. - -The "Weight" field - - Weight, the load balancing field, is not quite satisfactory, but the - actual load on typical servers changes much too quickly to be kept - around in DNS caches. It seems to the authors that offering - administrators a way to say "this machine is three times as fast as - that one" is the best that can practically be done. - - The only way the authors can see of getting a "better" load figure is - asking a separate server when the client selects a server and - contacts it. For short-lived services like SMTP an extra step in the - connection establishment seems too expensive, and for long-lived - services like telnet, the load figure may well be thrown off a minute - after the connection is established when someone else starts or - finishes a heavy job. - -The Port number - - Currently, the translation from service name to port number happens - at the client, often using a file such as /etc/services. - - Moving this information to the DNS makes it less necessary to update - these files on every single computer of the net every time a new - service is added, and makes it possible to move standard services out - of the "root-only" port range on unix - - - - - - - -Gulbrandsen & Vixie Experimental [Page 4] - -RFC 2052 DNS SRV RR October 1996 - - -Usage rules - - A SRV-cognizant client SHOULD use this procedure to locate a list of - servers and connect to the preferred one: - - Do a lookup for QNAME=service.protocol.target, QCLASS=IN, - QTYPE=SRV. - - If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV - RR which specifies the requested Service and Protocol in the - reply: - - If there is precisely one SRV RR, and its Target is "." - (the root domain), abort. - - Else, for all such RR's, build a list of (Priority, Weight, - Target) tuples - - Sort the list by priority (lowest number first) - - Create a new empty list - - For each distinct priority level - While there are still elements left at this priority - level - Select an element randomly, with probability - Weight, and move it to the tail of the new list - - For each element in the new list - - query the DNS for A RR's for the Target or use any - RR's found in the Additional Data secion of the - earlier SRV query. - - for each A RR found, try to connect to the (protocol, - address, service). - - else if the service desired is SMTP - - skip to RFC 974 (MX). - - else - - Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A - - for each A RR found, try to connect to the (protocol, - address, service) - - - - -Gulbrandsen & Vixie Experimental [Page 5] - -RFC 2052 DNS SRV RR October 1996 - - - Notes: - - - Port numbers SHOULD NOT be used in place of the symbolic service - or protocol names (for the same reason why variant names cannot - be allowed: Applications would have to do two or more lookups). - - - If a truncated response comes back from an SRV query, and the - Additional Data section has at least one complete RR in it, the - answer MUST be considered complete and the client resolver - SHOULD NOT retry the query using TCP, but use normal UDP queries - for A RR's missing from the Additional Data section. - - - A client MAY use means other than Weight to choose among target - hosts with equal Priority. - - - A client MUST parse all of the RR's in the reply. - - - If the Additional Data section doesn't contain A RR's for all - the SRV RR's and the client may want to connect to the target - host(s) involved, the client MUST look up the A RR(s). (This - happens quite often when the A RR has shorter TTL than the SRV - or NS RR's.) - - - A future standard could specify that a SRV RR whose Protocol was - TCP and whose Service was SMTP would override RFC 974's rules - with regard to the use of an MX RR. This would allow firewalled - organizations with several SMTP relays to control the load - distribution using the Weight field. - - - Future protocols could be designed to use SRV RR lookups as the - means by which clients locate their servers. - -Fictional example - - This is (part of) the zone file for asdf.com, a still-unused domain: - - $ORIGIN asdf.com. - @ SOA server.asdf.com. root.asdf.com. ( - 1995032001 3600 3600 604800 86400 ) - NS server.asdf.com. - NS ns1.ip-provider.net. - NS ns2.ip-provider.net. - ftp.tcp SRV 0 0 21 server.asdf.com. - finger.tcp SRV 0 0 79 server.asdf.com. - ; telnet - use old-slow-box or new-fast-box if either is - ; available, make three quarters of the logins go to - ; new-fast-box. - telnet.tcp SRV 0 1 23 old-slow-box.asdf.com. - - - -Gulbrandsen & Vixie Experimental [Page 6] - -RFC 2052 DNS SRV RR October 1996 - - - SRV 0 3 23 new-fast-box.asdf.com. - ; if neither old-slow-box or new-fast-box is up, switch to - ; using the sysdmin's box and the server - SRV 1 0 23 sysadmins-box.asdf.com. - SRV 1 0 23 server.asdf.com. - ; HTTP - server is the main server, new-fast-box is the backup - ; (On new-fast-box, the HTTP daemon runs on port 8000) - http.tcp SRV 0 0 80 server.asdf.com. - SRV 10 0 8000 new-fast-box.asdf.com. - ; since we want to support both http://asdf.com/ and - ; http://www.asdf.com/ we need the next two RRs as well - http.tcp.www SRV 0 0 80 server.asdf.com. - SRV 10 0 8000 new-fast-box.asdf.com. - ; SMTP - mail goes to the server, and to the IP provider if - ; the net is down - smtp.tcp SRV 0 0 25 server.asdf.com. - SRV 1 0 25 mailhost.ip-provider.net. - @ MX 0 server.asdf.com. - MX 1 mailhost.ip-provider.net. - ; NNTP - use the IP providers's NNTP server - nntp.tcp SRV 0 0 119 nntphost.ip-provider.net. - ; IDB is an locally defined protocol - idb.tcp SRV 0 0 2025 new-fast-box.asdf.com. - ; addresses - server A 172.30.79.10 - old-slow-box A 172.30.79.11 - sysadmins-box A 172.30.79.12 - new-fast-box A 172.30.79.13 - ; backup A records - new-fast-box and old-slow-box are - ; included, naturally, and server is too, but might go - ; if the load got too bad - @ A 172.30.79.10 - A 172.30.79.11 - A 172.30.79.13 - ; backup A RR for www.asdf.com - www A 172.30.79.10 - ; NO other services are supported - *.tcp SRV 0 0 0 . - *.udp SRV 0 0 0 . - - In this example, a telnet connection to "asdf.com." needs an SRV - lookup of "telnet.tcp.asdf.com." and possibly A lookups of "new- - fast-box.asdf.com." and/or the other hosts named. The size of the - SRV reply is approximately 365 bytes: - - 30 bytes general overhead - 20 bytes for the query string, "telnet.tcp.asdf.com." - 130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new- - - - -Gulbrandsen & Vixie Experimental [Page 7] - -RFC 2052 DNS SRV RR October 1996 - - - fast-box", "old-slow-box", "server" and "sysadmins-box" - - "asdf.com" in the query section is quoted here and doesn't - need to be counted again. - 75 bytes for 3 NS RRs, 15 bytes each plus the lengths of - "server", "ns1.ip-provider.net." and "ns2" - again, "ip- - provider.net." is quoted and only needs to be counted once. - 120 bytes for the 6 A RR's mentioned by the SRV and NS RR's. - -Refererences - - RFC 1918: Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., - and E. Lear, "Address Allocation for Private Internets", - RFC 1918, February 1996. - - RFC 1916 Berkowitz, H., Ferguson, P, Leland, W. and P. Nesser, - "Enterprise Renumbering: Experience and Information - Solicitation", RFC 1916, February 1996. - - RFC 1912 Barr, D., "Common DNS Operational and Configuration - Errors", RFC 1912, February 1996. - - RFC 1900: Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", - RFC 1900, February 1996. - - RFC 1920: Postel, J., "INTERNET OFFICIAL PROTOCOL STANDARDS", - STD 1, RFC 1920, March 1996. - - RFC 1814: Gerich, E., "Unique Addresses are Good", RFC 1814, June - 1995. - - RFC 1794: Brisco, T., "DNS Support for Load Balancing", April 1995. - - RFC 1713: Romao, A., "Tools for DNS debugging", November 1994. - - RFC 1712: Farrell, C., Schulze, M., Pleitner, S., and D. Baldoni, - "DNS Encoding of Geographical Location", RFC 1712, November - 1994. - - RFC 1706: Manning, B. and R. Colella, "DNS NSAP Resource Records", - RFC 1706, October 1994. - - RFC 1700: Reynolds, J., and J. Postel, "ASSIGNED NUMBERS", - STD 2, RFC 1700, October 1994. - - RFC 1183: Ullmann, R., Mockapetris, P., Mamakos, L., and - C. Everhart, "New DNS RR Definitions", RFC 1183, November - 1990. - - - - -Gulbrandsen & Vixie Experimental [Page 8] - -RFC 2052 DNS SRV RR October 1996 - - - RFC 1101: Mockapetris, P., "DNS encoding of network names and other - types", RFC 1101, April 1989. - - RFC 1035: Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - RFC 1034: Mockapetris, P., "Domain names - concepts and - facilities", STD 13, RFC 1034, November 1987. - - RFC 1033: Lottor, M., "Domain administrators operations guide", - RFC 1033, November 1987. - - RFC 1032: Stahl, M., "Domain administrators guide", RFC 1032, - November 1987. - - RFC 974: Partridge, C., "Mail routing and the domain system", - STD 14, RFC 974, January 1986. - -Security Considerations - - The authors believes this RR to not cause any new security problems. - Some problems become more visible, though. - - - The ability to specify ports on a fine-grained basis obviously - changes how a router can filter packets. It becomes impossible - to block internal clients from accessing specific external - services, slightly harder to block internal users from running - unautorised services, and more important for the router - operations and DNS operations personnel to cooperate. - - - There is no way a site can keep its hosts from being referenced - as servers (as, indeed, some sites become unwilling secondary - MXes today). This could lead to denial of service. - - - With SRV, DNS spoofers can supply false port numbers, as well as - host names and addresses. The authors do not see any practical - effect of this. - - We assume that as the DNS-security people invent new features, DNS - servers will return the relevant RRs in the Additional Data section - when answering an SRV query. - - - - - - - - - - -Gulbrandsen & Vixie Experimental [Page 9] - -RFC 2052 DNS SRV RR October 1996 - - -Authors' Addresses - - Arnt Gulbrandsen - Troll Tech - Postboks 6133 Etterstad - N-0602 Oslo - Norway - - Phone: +47 22646966 - EMail: agulbra@troll.no - - - Paul Vixie - Vixie Enterprises - Star Route 159A - Woodside, CA 94062 - - Phone: (415) 747-0204 - EMail: paul@vix.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gulbrandsen & Vixie Experimental [Page 10] - diff --git a/contrib/bind9/doc/rfc/rfc2104.txt b/contrib/bind9/doc/rfc/rfc2104.txt deleted file mode 100644 index a205103a2ede..000000000000 --- a/contrib/bind9/doc/rfc/rfc2104.txt +++ /dev/null @@ -1,620 +0,0 @@ - - - - - - -Network Working Group H. Krawczyk -Request for Comments: 2104 IBM -Category: Informational M. Bellare - UCSD - R. Canetti - IBM - February 1997 - - - HMAC: Keyed-Hashing for Message Authentication - -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. - -Abstract - - This document describes HMAC, a mechanism for message authentication - using cryptographic hash functions. HMAC can be used with any - iterative cryptographic hash function, e.g., MD5, SHA-1, in - combination with a secret shared key. The cryptographic strength of - HMAC depends on the properties of the underlying hash function. - -1. Introduction - - Providing a way to check the integrity of information transmitted - over or stored in an unreliable medium is a prime necessity in the - world of open computing and communications. Mechanisms that provide - such integrity check based on a secret key are usually called - "message authentication codes" (MAC). Typically, message - authentication codes are used between two parties that share a secret - key in order to validate information transmitted between these - parties. In this document we present such a MAC mechanism based on - cryptographic hash functions. This mechanism, called HMAC, is based - on work by the authors [BCK1] where the construction is presented and - cryptographically analyzed. We refer to that work for the details on - the rationale and security analysis of HMAC, and its comparison to - other keyed-hash methods. - - - - - - - - - - - -Krawczyk, et. al. Informational [Page 1] - -RFC 2104 HMAC February 1997 - - - HMAC can be used in combination with any iterated cryptographic hash - function. MD5 and SHA-1 are examples of such hash functions. HMAC - also uses a secret key for calculation and verification of the - message authentication values. The main goals behind this - construction are - - * To use, without modifications, available hash functions. - In particular, hash functions that perform well in software, - and for which code is freely and widely available. - - * To preserve the original performance of the hash function without - incurring a significant degradation. - - * To use and handle keys in a simple way. - - * To have a well understood cryptographic analysis of the strength of - the authentication mechanism based on reasonable assumptions on the - underlying hash function. - - * To allow for easy replaceability of the underlying hash function in - case that faster or more secure hash functions are found or - required. - - This document specifies HMAC using a generic cryptographic hash - function (denoted by H). Specific instantiations of HMAC need to - define a particular hash function. Current candidates for such hash - functions include SHA-1 [SHA], MD5 [MD5], RIPEMD-128/160 [RIPEMD]. - These different realizations of HMAC will be denoted by HMAC-SHA1, - HMAC-MD5, HMAC-RIPEMD, etc. - - Note: To the date of writing of this document MD5 and SHA-1 are the - most widely used cryptographic hash functions. MD5 has been recently - shown to be vulnerable to collision search attacks [Dobb]. This - attack and other currently known weaknesses of MD5 do not compromise - the use of MD5 within HMAC as specified in this document (see - [Dobb]); however, SHA-1 appears to be a cryptographically stronger - function. To this date, MD5 can be considered for use in HMAC for - applications where the superior performance of MD5 is critical. In - any case, implementers and users need to be aware of possible - cryptanalytic developments regarding any of these cryptographic hash - functions, and the eventual need to replace the underlying hash - function. (See section 6 for more information on the security of - HMAC.) - - - - - - - - -Krawczyk, et. al. Informational [Page 2] - -RFC 2104 HMAC February 1997 - - -2. Definition of HMAC - - The definition of HMAC requires a cryptographic hash function, which - we denote by H, and a secret key K. We assume H to be a cryptographic - hash function where data is hashed by iterating a basic compression - function on blocks of data. We denote by B the byte-length of such - blocks (B=64 for all the above mentioned examples of hash functions), - and by L the byte-length of hash outputs (L=16 for MD5, L=20 for - SHA-1). The authentication key K can be of any length up to B, the - block length of the hash function. Applications that use keys longer - than B bytes will first hash the key using H and then use the - resultant L byte string as the actual key to HMAC. In any case the - minimal recommended length for K is L bytes (as the hash output - length). See section 3 for more information on keys. - - We define two fixed and different strings ipad and opad as follows - (the 'i' and 'o' are mnemonics for inner and outer): - - ipad = the byte 0x36 repeated B times - opad = the byte 0x5C repeated B times. - - To compute HMAC over the data `text' we perform - - H(K XOR opad, H(K XOR ipad, text)) - - Namely, - - (1) append zeros to the end of K to create a B byte string - (e.g., if K is of length 20 bytes and B=64, then K will be - appended with 44 zero bytes 0x00) - (2) XOR (bitwise exclusive-OR) the B byte string computed in step - (1) with ipad - (3) append the stream of data 'text' to the B byte string resulting - from step (2) - (4) apply H to the stream generated in step (3) - (5) XOR (bitwise exclusive-OR) the B byte string computed in - step (1) with opad - (6) append the H result from step (4) to the B byte string - resulting from step (5) - (7) apply H to the stream generated in step (6) and output - the result - - For illustration purposes, sample code based on MD5 is provided as an - appendix. - - - - - - - -Krawczyk, et. al. Informational [Page 3] - -RFC 2104 HMAC February 1997 - - -3. Keys - - The key for HMAC can be of any length (keys longer than B bytes are - first hashed using H). However, less than L bytes is strongly - discouraged as it would decrease the security strength of the - function. Keys longer than L bytes are acceptable but the extra - length would not significantly increase the function strength. (A - longer key may be advisable if the randomness of the key is - considered weak.) - - Keys need to be chosen at random (or using a cryptographically strong - pseudo-random generator seeded with a random seed), and periodically - refreshed. (Current attacks do not indicate a specific recommended - frequency for key changes as these attacks are practically - infeasible. However, periodic key refreshment is a fundamental - security practice that helps against potential weaknesses of the - function and keys, and limits the damage of an exposed key.) - -4. Implementation Note - - HMAC is defined in such a way that the underlying hash function H can - be used with no modification to its code. In particular, it uses the - function H with the pre-defined initial value IV (a fixed value - specified by each iterative hash function to initialize its - compression function). However, if desired, a performance - improvement can be achieved at the cost of (possibly) modifying the - code of H to support variable IVs. - - The idea is that the intermediate results of the compression function - on the B-byte blocks (K XOR ipad) and (K XOR opad) can be precomputed - only once at the time of generation of the key K, or before its first - use. These intermediate results are stored and then used to - initialize the IV of H each time that a message needs to be - authenticated. This method saves, for each authenticated message, - the application of the compression function of H on two B-byte blocks - (i.e., on (K XOR ipad) and (K XOR opad)). Such a savings may be - significant when authenticating short streams of data. We stress - that the stored intermediate values need to be treated and protected - the same as secret keys. - - Choosing to implement HMAC in the above way is a decision of the - local implementation and has no effect on inter-operability. - - - - - - - - - -Krawczyk, et. al. Informational [Page 4] - -RFC 2104 HMAC February 1997 - - -5. Truncated output - - A well-known practice with message authentication codes is to - truncate the output of the MAC and output only part of the bits - (e.g., [MM, ANSI]). Preneel and van Oorschot [PV] show some - analytical advantages of truncating the output of hash-based MAC - functions. The results in this area are not absolute as for the - overall security advantages of truncation. It has advantages (less - information on the hash result available to an attacker) and - disadvantages (less bits to predict for the attacker). Applications - of HMAC can choose to truncate the output of HMAC by outputting the t - leftmost bits of the HMAC computation for some parameter t (namely, - the computation is carried in the normal way as defined in section 2 - above but the end result is truncated to t bits). We recommend that - the output length t be not less than half the length of the hash - output (to match the birthday attack bound) and not less than 80 bits - (a suitable lower bound on the number of bits that need to be - predicted by an attacker). We propose denoting a realization of HMAC - that uses a hash function H with t bits of output as HMAC-H-t. For - example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function - and with the output truncated to 80 bits. (If the parameter t is not - specified, e.g. HMAC-MD5, then it is assumed that all the bits of the - hash are output.) - -6. Security - - The security of the message authentication mechanism presented here - depends on cryptographic properties of the hash function H: the - resistance to collision finding (limited to the case where the - initial value is secret and random, and where the output of the - function is not explicitly available to the attacker), and the - message authentication property of the compression function of H when - applied to single blocks (in HMAC these blocks are partially unknown - to an attacker as they contain the result of the inner H computation - and, in particular, cannot be fully chosen by the attacker). - - These properties, and actually stronger ones, are commonly assumed - for hash functions of the kind used with HMAC. In particular, a hash - function for which the above properties do not hold would become - unsuitable for most (probably, all) cryptographic applications, - including alternative message authentication schemes based on such - functions. (For a complete analysis and rationale of the HMAC - function the reader is referred to [BCK1].) - - - - - - - - -Krawczyk, et. al. Informational [Page 5] - -RFC 2104 HMAC February 1997 - - - Given the limited confidence gained so far as for the cryptographic - strength of candidate hash functions, it is important to observe the - following two properties of the HMAC construction and its secure use - for message authentication: - - 1. The construction is independent of the details of the particular - hash function H in use and then the latter can be replaced by any - other secure (iterative) cryptographic hash function. - - 2. Message authentication, as opposed to encryption, has a - "transient" effect. A published breaking of a message authentication - scheme would lead to the replacement of that scheme, but would have - no adversarial effect on information authenticated in the past. This - is in sharp contrast with encryption, where information encrypted - today may suffer from exposure in the future if, and when, the - encryption algorithm is broken. - - The strongest attack known against HMAC is based on the frequency of - collisions for the hash function H ("birthday attack") [PV,BCK2], and - is totally impractical for minimally reasonable hash functions. - - As an example, if we consider a hash function like MD5 where the - output length equals L=16 bytes (128 bits) the attacker needs to - acquire the correct message authentication tags computed (with the - _same_ secret key K!) on about 2**64 known plaintexts. This would - require the processing of at least 2**64 blocks under H, an - impossible task in any realistic scenario (for a block length of 64 - bytes this would take 250,000 years in a continuous 1Gbps link, and - without changing the secret key K during all this time). This attack - could become realistic only if serious flaws in the collision - behavior of the function H are discovered (e.g. collisions found - after 2**30 messages). Such a discovery would determine the immediate - replacement of the function H (the effects of such failure would be - far more severe for the traditional uses of H in the context of - digital signatures, public key certificates, etc.). - - Note: this attack needs to be strongly contrasted with regular - collision attacks on cryptographic hash functions where no secret key - is involved and where 2**64 off-line parallelizable (!) operations - suffice to find collisions. The latter attack is approaching - feasibility [VW] while the birthday attack on HMAC is totally - impractical. (In the above examples, if one uses a hash function - with, say, 160 bit of output then 2**64 should be replaced by 2**80.) - - - - - - - - -Krawczyk, et. al. Informational [Page 6] - -RFC 2104 HMAC February 1997 - - - A correct implementation of the above construction, the choice of - random (or cryptographically pseudorandom) keys, a secure key - exchange mechanism, frequent key refreshments, and good secrecy - protection of keys are all essential ingredients for the security of - the integrity verification mechanism provided by HMAC. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Krawczyk, et. al. Informational [Page 7] - -RFC 2104 HMAC February 1997 - - -Appendix -- Sample Code - - For the sake of illustration we provide the following sample code for - the implementation of HMAC-MD5 as well as some corresponding test - vectors (the code is based on MD5 code as described in [MD5]). - -/* -** Function: hmac_md5 -*/ - -void -hmac_md5(text, text_len, key, key_len, digest) -unsigned char* text; /* pointer to data stream */ -int text_len; /* length of data stream */ -unsigned char* key; /* pointer to authentication key */ -int key_len; /* length of authentication key */ -caddr_t digest; /* caller digest to be filled in */ - -{ - MD5_CTX context; - unsigned char k_ipad[65]; /* inner padding - - * key XORd with ipad - */ - unsigned char k_opad[65]; /* outer padding - - * key XORd with opad - */ - unsigned char tk[16]; - int i; - /* if key is longer than 64 bytes reset it to key=MD5(key) */ - if (key_len > 64) { - - MD5_CTX tctx; - - MD5Init(&tctx); - MD5Update(&tctx, key, key_len); - MD5Final(tk, &tctx); - - key = tk; - key_len = 16; - } - - /* - * the HMAC_MD5 transform looks like: - * - * MD5(K XOR opad, MD5(K XOR ipad, text)) - * - * where K is an n byte key - * ipad is the byte 0x36 repeated 64 times - - - -Krawczyk, et. al. Informational [Page 8] - -RFC 2104 HMAC February 1997 - - - * opad is the byte 0x5c repeated 64 times - * and text is the data being protected - */ - - /* start out by storing key in pads */ - bzero( k_ipad, sizeof k_ipad); - bzero( k_opad, sizeof k_opad); - bcopy( key, k_ipad, key_len); - bcopy( key, k_opad, key_len); - - /* XOR key with ipad and opad values */ - for (i=0; i<64; i++) { - k_ipad[i] ^= 0x36; - k_opad[i] ^= 0x5c; - } - /* - * perform inner MD5 - */ - MD5Init(&context); /* init context for 1st - * pass */ - MD5Update(&context, k_ipad, 64) /* start with inner pad */ - MD5Update(&context, text, text_len); /* then text of datagram */ - MD5Final(digest, &context); /* finish up 1st pass */ - /* - * perform outer MD5 - */ - MD5Init(&context); /* init context for 2nd - * pass */ - MD5Update(&context, k_opad, 64); /* start with outer pad */ - MD5Update(&context, digest, 16); /* then results of 1st - * hash */ - MD5Final(digest, &context); /* finish up 2nd pass */ -} - -Test Vectors (Trailing '\0' of a character string not included in test): - - key = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b - key_len = 16 bytes - data = "Hi There" - data_len = 8 bytes - digest = 0x9294727a3638bb1c13f48ef8158bfc9d - - key = "Jefe" - data = "what do ya want for nothing?" - data_len = 28 bytes - digest = 0x750c783e6ab0b503eaa86e310a5db738 - - key = 0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA - - - -Krawczyk, et. al. Informational [Page 9] - -RFC 2104 HMAC February 1997 - - - key_len 16 bytes - data = 0xDDDDDDDDDDDDDDDDDDDD... - ..DDDDDDDDDDDDDDDDDDDD... - ..DDDDDDDDDDDDDDDDDDDD... - ..DDDDDDDDDDDDDDDDDDDD... - ..DDDDDDDDDDDDDDDDDDDD - data_len = 50 bytes - digest = 0x56be34521d144c88dbb8c733f0e8b3f6 - -Acknowledgments - - Pau-Chen Cheng, Jeff Kraemer, and Michael Oehler, have provided - useful comments on early drafts, and ran the first interoperability - tests of this specification. Jeff and Pau-Chen kindly provided the - sample code and test vectors that appear in the appendix. Burt - Kaliski, Bart Preneel, Matt Robshaw, Adi Shamir, and Paul van - Oorschot have provided useful comments and suggestions during the - investigation of the HMAC construction. - -References - - [ANSI] ANSI X9.9, "American National Standard for Financial - Institution Message Authentication (Wholesale)," American - Bankers Association, 1981. Revised 1986. - - [Atk] Atkinson, R., "IP Authentication Header", RFC 1826, August - 1995. - - [BCK1] M. Bellare, R. Canetti, and H. Krawczyk, - "Keyed Hash Functions and Message Authentication", - Proceedings of Crypto'96, LNCS 1109, pp. 1-15. - (http://www.research.ibm.com/security/keyed-md5.html) - - [BCK2] M. Bellare, R. Canetti, and H. Krawczyk, - "Pseudorandom Functions Revisited: The Cascade Construction", - Proceedings of FOCS'96. - - [Dobb] H. Dobbertin, "The Status of MD5 After a Recent Attack", - RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996. - http://www.rsa.com/rsalabs/pubs/cryptobytes.html - - [PV] B. Preneel and P. van Oorschot, "Building fast MACs from hash - functions", Advances in Cryptology -- CRYPTO'95 Proceedings, - Lecture Notes in Computer Science, Springer-Verlag Vol.963, - 1995, pp. 1-14. - - [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", - RFC 1321, April 1992. - - - -Krawczyk, et. al. Informational [Page 10] - -RFC 2104 HMAC February 1997 - - - [MM] Meyer, S. and Matyas, S.M., Cryptography, New York Wiley, - 1982. - - [RIPEMD] H. Dobbertin, A. Bosselaers, and B. Preneel, "RIPEMD-160: A - strengthened version of RIPEMD", Fast Software Encryption, - LNCS Vol 1039, pp. 71-82. - ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/. - - [SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. - - [Tsu] G. Tsudik, "Message authentication with one-way hash - functions", In Proceedings of Infocom'92, May 1992. - (Also in "Access Control and Policy Enforcement in - Internetworks", Ph.D. Dissertation, Computer Science - Department, University of Southern California, April 1991.) - - [VW] P. van Oorschot and M. Wiener, "Parallel Collision - Search with Applications to Hash Functions and Discrete - Logarithms", Proceedings of the 2nd ACM Conf. Computer and - Communications Security, Fairfax, VA, November 1994. - -Authors' Addresses - - Hugo Krawczyk - IBM T.J. Watson Research Center - P.O.Box 704 - Yorktown Heights, NY 10598 - - EMail: hugo@watson.ibm.com - - Mihir Bellare - Dept of Computer Science and Engineering - Mail Code 0114 - University of California at San Diego - 9500 Gilman Drive - La Jolla, CA 92093 - - EMail: mihir@cs.ucsd.edu - - Ran Canetti - IBM T.J. Watson Research Center - P.O.Box 704 - Yorktown Heights, NY 10598 - - EMail: canetti@watson.ibm.com - - - - - - -Krawczyk, et. al. Informational [Page 11] - - diff --git a/contrib/bind9/doc/rfc/rfc2119.txt b/contrib/bind9/doc/rfc/rfc2119.txt deleted file mode 100644 index e31fae47fd1f..000000000000 --- a/contrib/bind9/doc/rfc/rfc2119.txt +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - -Network Working Group S. Bradner -Request for Comments: 2119 Harvard University -BCP: 14 March 1997 -Category: Best Current Practice - - - Key words for use in RFCs to Indicate Requirement Levels - -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. - -Abstract - - In many standards track documents several words are used to signify - the requirements in the specification. These words are often - capitalized. This document defines these words as they should be - interpreted in IETF documents. Authors who follow these guidelines - should incorporate this phrase near the beginning of their document: - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL - NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in - RFC 2119. - - Note that the force of these words is modified by the requirement - level of the document in which they are used. - -1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the - definition is an absolute requirement of the specification. - -2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the - definition is an absolute prohibition of the specification. - -3. SHOULD This word, or the adjective "RECOMMENDED", mean that there - may exist valid reasons in particular circumstances to ignore a - particular item, but the full implications must be understood and - carefully weighed before choosing a different course. - -4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that - there may exist valid reasons in particular circumstances when the - particular behavior is acceptable or even useful, but the full - implications should be understood and the case carefully weighed - before implementing any behavior described with this label. - - - - - -Bradner Best Current Practice [Page 1] - -RFC 2119 RFC Key Words March 1997 - - -5. MAY This word, or the adjective "OPTIONAL", mean that an item is - truly optional. One vendor may choose to include the item because a - particular marketplace requires it or because the vendor feels that - it enhances the product while another vendor may omit the same item. - An implementation which does not include a particular option MUST be - prepared to interoperate with another implementation which does - include the option, though perhaps with reduced functionality. In the - same vein an implementation which does include a particular option - MUST be prepared to interoperate with another implementation which - does not include the option (except, of course, for the feature the - option provides.) - -6. Guidance in the use of these Imperatives - - Imperatives of the type defined in this memo must be used with care - and sparingly. In particular, they MUST only be used where it is - actually required for interoperation or to limit behavior which has - potential for causing harm (e.g., limiting retransmisssions) For - example, they must not be used to try to impose a particular method - on implementors where the method is not required for - interoperability. - -7. Security Considerations - - These terms are frequently used to specify behavior with security - implications. The effects on security of not implementing a MUST or - SHOULD, or doing something the specification says MUST NOT or SHOULD - NOT be done may be very subtle. Document authors should take the time - to elaborate the security implications of not following - recommendations or requirements as most implementors will not have - had the benefit of the experience and discussion that produced the - specification. - -8. Acknowledgments - - The definitions of these terms are an amalgam of definitions taken - from a number of RFCs. In addition, suggestions have been - incorporated from a number of people including Robert Ullmann, Thomas - Narten, Neal McBurnett, and Robert Elz. - - - - - - - - - - - - -Bradner Best Current Practice [Page 2] - -RFC 2119 RFC Key Words March 1997 - - -9. Author's Address - - Scott Bradner - Harvard University - 1350 Mass. Ave. - Cambridge, MA 02138 - - phone - +1 617 495 3864 - - email - sob@harvard.edu - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Bradner Best Current Practice [Page 3] - diff --git a/contrib/bind9/doc/rfc/rfc2133.txt b/contrib/bind9/doc/rfc/rfc2133.txt deleted file mode 100644 index ea66cf012679..000000000000 --- a/contrib/bind9/doc/rfc/rfc2133.txt +++ /dev/null @@ -1,1795 +0,0 @@ - - - - - - -Network Working Group R. Gilligan -Request for Comments: 2133 Freegate -Category: Informational S. Thomson - Bellcore - J. Bound - Digital - W. Stevens - Consultant - April 1997 - - Basic Socket Interface Extensions for IPv6 - -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. - -Abstract - - The de facto standard application program interface (API) for TCP/IP - applications is the "sockets" interface. Although this API was - developed for Unix in the early 1980s it has also been implemented on - a wide variety of non-Unix systems. TCP/IP applications written - using the sockets API have in the past enjoyed a high degree of - portability and we would like the same portability with IPv6 - applications. But changes are required to the sockets API to support - IPv6 and this memo describes these changes. These include a new - socket address structure to carry IPv6 addresses, new address - conversion functions, and some new socket options. These extensions - are designed to provide access to the basic IPv6 features required by - TCP and UDP applications, including multicasting, while introducing a - minimum of change into the system and providing complete - compatibility for existing IPv4 applications. Additional extensions - for advanced IPv6 features (raw sockets and access to the IPv6 - extension headers) are defined in another document [5]. - -Table of Contents - - 1. Introduction ................................................ 2 - 2. Design Considerations ....................................... 3 - 2.1. What Needs to be Changed .................................. 3 - 2.2. Data Types ................................................ 5 - 2.3. Headers ................................................... 5 - 2.4. Structures ................................................ 5 - 3. Socket Interface ............................................ 5 - 3.1. IPv6 Address Family and Protocol Family ................... 5 - 3.2. IPv6 Address Structure .................................... 6 - - - -Gilligan, et. al. Informational [Page 1] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - 3.3. Socket Address Structure for 4.3BSD-Based Systems ......... 6 - 3.4. Socket Address Structure for 4.4BSD-Based Systems ......... 7 - 3.5. The Socket Functions ...................................... 8 - 3.6. Compatibility with IPv4 Applications ...................... 9 - 3.7. Compatibility with IPv4 Nodes ............................. 9 - 3.8. IPv6 Wildcard Address ..................................... 10 - 3.9. IPv6 Loopback Address ..................................... 11 - 4. Interface Identification .................................... 12 - 4.1. Name-to-Index ............................................. 13 - 4.2. Index-to-Name ............................................. 13 - 4.3. Return All Interface Names and Indexes .................... 14 - 4.4. Free Memory ............................................... 14 - 5. Socket Options .............................................. 14 - 5.1. Changing Socket Type ...................................... 15 - 5.2. Unicast Hop Limit ......................................... 16 - 5.3. Sending and Receiving Multicast Packets ................... 17 - 6. Library Functions ........................................... 19 - 6.1. Hostname-to-Address Translation ........................... 19 - 6.2. Address To Hostname Translation ........................... 22 - 6.3. Protocol-Independent Hostname and Service Name Translation 22 - 6.4. Socket Address Structure to Hostname and Service Name ..... 25 - 6.5. Address Conversion Functions .............................. 27 - 6.6. Address Testing Macros .................................... 28 - 7. Summary of New Definitions .................................. 29 - 8. Security Considerations ..................................... 31 - 9. Acknowledgments ............................................. 31 - 10. References ................................................. 31 - 11. Authors' Addresses ......................................... 32 - -1. Introduction - - While IPv4 addresses are 32 bits long, IPv6 interfaces are identified - by 128-bit addresses. The socket interface make the size of an IP - address quite visible to an application; virtually all TCP/IP - applications for BSD-based systems have knowledge of the size of an - IP address. Those parts of the API that expose the addresses must be - changed to accommodate the larger IPv6 address size. IPv6 also - introduces new features (e.g., flow label and priority), some of - which must be made visible to applications via the API. This memo - defines a set of extensions to the socket interface to support the - larger address size and new features of IPv6. - - - - - - - - - - -Gilligan, et. al. Informational [Page 2] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - -2. Design Considerations - - There are a number of important considerations in designing changes - to this well-worn API: - - - The API changes should provide both source and binary - compatibility for programs written to the original API. That is, - existing program binaries should continue to operate when run on - a system supporting the new API. In addition, existing - applications that are re-compiled and run on a system supporting - the new API should continue to operate. Simply put, the API - changes for IPv6 should not break existing programs. - - - The changes to the API should be as small as possible in order to - simplify the task of converting existing IPv4 applications to - IPv6. - - - Where possible, applications should be able to use this API to - interoperate with both IPv6 and IPv4 hosts. Applications should - not need to know which type of host they are communicating with. - - - IPv6 addresses carried in data structures should be 64-bit - aligned. This is necessary in order to obtain optimum - performance on 64-bit machine architectures. - - Because of the importance of providing IPv4 compatibility in the API, - these extensions are explicitly designed to operate on machines that - provide complete support for both IPv4 and IPv6. A subset of this - API could probably be designed for operation on systems that support - only IPv6. However, this is not addressed in this memo. - -2.1. What Needs to be Changed - - The socket interface API consists of a few distinct components: - - - Core socket functions. - - - Address data structures. - - - Name-to-address translation functions. - - - Address conversion functions. - - The core socket functions -- those functions that deal with such - things as setting up and tearing down TCP connections, and sending - and receiving UDP packets -- were designed to be transport - independent. Where protocol addresses are passed as function - arguments, they are carried via opaque pointers. A protocol-specific - - - -Gilligan, et. al. Informational [Page 3] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - address data structure is defined for each protocol that the socket - functions support. Applications must cast pointers to these - protocol-specific address structures into pointers to the generic - "sockaddr" address structure when using the socket functions. These - functions need not change for IPv6, but a new IPv6-specific address - data structure is needed. - - The "sockaddr_in" structure is the protocol-specific data structure - for IPv4. This data structure actually includes 8-octets of unused - space, and it is tempting to try to use this space to adapt the - sockaddr_in structure to IPv6. Unfortunately, the sockaddr_in - structure is not large enough to hold the 16-octet IPv6 address as - well as the other information (address family and port number) that - is needed. So a new address data structure must be defined for IPv6. - - The name-to-address translation functions in the socket interface are - gethostbyname() and gethostbyaddr(). These must be modified to - support IPv6 and the semantics defined must provide 100% backward - compatibility for all existing IPv4 applications, along with IPv6 - support for new applications. Additionally, the POSIX 1003.g work in - progress [4] specifies a new hostname-to-address translation function - which is protocol independent. This function can also be used with - IPv6. - - The address conversion functions -- inet_ntoa() and inet_addr() -- - convert IPv4 addresses between binary and printable form. These - functions are quite specific to 32-bit IPv4 addresses. We have - designed two analogous functions that convert both IPv4 and IPv6 - addresses, and carry an address type parameter so that they can be - extended to other protocol families as well. - - Finally, a few miscellaneous features are needed to support IPv6. - New interfaces are needed to support the IPv6 flow label, priority, - and hop limit header fields. New socket options are needed to - control the sending and receiving of IPv6 multicast packets. - - The socket interface will be enhanced in the future to provide access - to other IPv6 features. These extensions are described in [5]. - - - - - - - - - - - - - -Gilligan, et. al. Informational [Page 4] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - -2.2. Data Types - - The data types of the structure elements given in this memo are - intended to be examples, not absolute requirements. Whenever - possible, POSIX 1003.1g data types are used: u_intN_t means an - unsigned integer of exactly N bits (e.g., u_int16_t) and u_intNm_t - means an unsigned integer of at least N bits (e.g., u_int32m_t). We - also assume the argument data types from 1003.1g when possible (e.g., - the final argument to setsockopt() is a size_t value). Whenever - buffer sizes are specified, the POSIX 1003.1 size_t data type is used - (e.g., the two length arguments to getnameinfo()). - -2.3. Headers - - When function prototypes and structures are shown we show the headers - that must be #included to cause that item to be defined. - -2.4. Structures - - When structures are described the members shown are the ones that - must appear in an implementation. Additional, nonstandard members - may also be defined by an implementation. - - The ordering shown for the members of a structure is the recommended - ordering, given alignment considerations of multibyte members, but an - implementation may order the members differently. - -3. Socket Interface - - This section specifies the socket interface changes for IPv6. - -3.1. IPv6 Address Family and Protocol Family - - A new address family name, AF_INET6, is defined in <sys/socket.h>. - The AF_INET6 definition distinguishes between the original - sockaddr_in address data structure, and the new sockaddr_in6 data - structure. - - A new protocol family name, PF_INET6, is defined in <sys/socket.h>. - Like most of the other protocol family names, this will usually be - defined to have the same value as the corresponding address family - name: - - #define PF_INET6 AF_INET6 - - The PF_INET6 is used in the first argument to the socket() function - to indicate that an IPv6 socket is being created. - - - - -Gilligan, et. al. Informational [Page 5] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - -3.2. IPv6 Address Structure - - A new data structure to hold a single IPv6 address is defined as - follows: - - #include <netinet/in.h> - - struct in6_addr { - u_int8_t s6_addr[16]; /* IPv6 address */ - } - - This data structure contains an array of sixteen 8-bit elements, - which make up one 128-bit IPv6 address. The IPv6 address is stored - in network byte order. - -3.3. Socket Address Structure for 4.3BSD-Based Systems - - In the socket interface, a different protocol-specific data structure - is defined to carry the addresses for each protocol suite. Each - protocol-specific data structure is designed so it can be cast into a - protocol-independent data structure -- the "sockaddr" structure. - Each has a "family" field that overlays the "sa_family" of the - sockaddr data structure. This field identifies the type of the data - structure. - - The sockaddr_in structure is the protocol-specific address data - structure for IPv4. It is used to pass addresses between - applications and the system in the socket functions. The following - structure is defined to carry IPv6 addresses: - - #include <netinet/in.h> - - struct sockaddr_in6 { - u_int16m_t sin6_family; /* AF_INET6 */ - u_int16m_t sin6_port; /* transport layer port # */ - u_int32m_t sin6_flowinfo; /* IPv6 flow information */ - struct in6_addr sin6_addr; /* IPv6 address */ - }; - - This structure is designed to be compatible with the sockaddr data - structure used in the 4.3BSD release. - - The sin6_family field identifies this as a sockaddr_in6 structure. - This field overlays the sa_family field when the buffer is cast to a - sockaddr data structure. The value of this field must be AF_INET6. - - - - - - -Gilligan, et. al. Informational [Page 6] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - The sin6_port field contains the 16-bit UDP or TCP port number. This - field is used in the same way as the sin_port field of the - sockaddr_in structure. The port number is stored in network byte - order. - - The sin6_flowinfo field is a 32-bit field that contains two pieces of - information: the 24-bit IPv6 flow label and the 4-bit priority field. - The contents and interpretation of this member is unspecified at this - time. - - The sin6_addr field is a single in6_addr structure (defined in the - previous section). This field holds one 128-bit IPv6 address. The - address is stored in network byte order. - - The ordering of elements in this structure is specifically designed - so that the sin6_addr field will be aligned on a 64-bit boundary. - This is done for optimum performance on 64-bit architectures. - - Notice that the sockaddr_in6 structure will normally be larger than - the generic sockaddr structure. On many existing implementations the - sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both - being 16 bytes. Any existing code that makes this assumption needs - to be examined carefully when converting to IPv6. - -3.4. Socket Address Structure for 4.4BSD-Based Systems - - The 4.4BSD release includes a small, but incompatible change to the - socket interface. The "sa_family" field of the sockaddr data - structure was changed from a 16-bit value to an 8-bit value, and the - space saved used to hold a length field, named "sa_len". The - sockaddr_in6 data structure given in the previous section cannot be - correctly cast into the newer sockaddr data structure. For this - reason, the following alternative IPv6 address data structure is - provided to be used on systems based on 4.4BSD: - - #include <netinet/in.h> - - #define SIN6_LEN - - struct sockaddr_in6 { - u_char sin6_len; /* length of this struct */ - u_char sin6_family; /* AF_INET6 */ - u_int16m_t sin6_port; /* transport layer port # */ - u_int32m_t sin6_flowinfo; /* IPv6 flow information */ - struct in6_addr sin6_addr; /* IPv6 address */ - }; - - - - - -Gilligan, et. al. Informational [Page 7] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - The only differences between this data structure and the 4.3BSD - variant are the inclusion of the length field, and the change of the - family field to a 8-bit data type. The definitions of all the other - fields are identical to the structure defined in the previous - section. - - Systems that provide this version of the sockaddr_in6 data structure - must also declare SIN6_LEN as a result of including the - <netinet/in.h> header. This macro allows applications to determine - whether they are being built on a system that supports the 4.3BSD or - 4.4BSD variants of the data structure. - -3.5. The Socket Functions - - Applications call the socket() function to create a socket descriptor - that represents a communication endpoint. The arguments to the - socket() function tell the system which protocol to use, and what - format address structure will be used in subsequent functions. For - example, to create an IPv4/TCP socket, applications make the call: - - s = socket(PF_INET, SOCK_STREAM, 0); - - To create an IPv4/UDP socket, applications make the call: - - s = socket(PF_INET, SOCK_DGRAM, 0); - - Applications may create IPv6/TCP and IPv6/UDP sockets by simply using - the constant PF_INET6 instead of PF_INET in the first argument. For - example, to create an IPv6/TCP socket, applications make the call: - - s = socket(PF_INET6, SOCK_STREAM, 0); - - To create an IPv6/UDP socket, applications make the call: - - s = socket(PF_INET6, SOCK_DGRAM, 0); - - Once the application has created a PF_INET6 socket, it must use the - sockaddr_in6 address structure when passing addresses in to the - system. The functions that the application uses to pass addresses - into the system are: - - bind() - connect() - sendmsg() - sendto() - - - - - - -Gilligan, et. al. Informational [Page 8] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - The system will use the sockaddr_in6 address structure to return - addresses to applications that are using PF_INET6 sockets. The - functions that return an address from the system to an application - are: - - accept() - recvfrom() - recvmsg() - getpeername() - getsockname() - - No changes to the syntax of the socket functions are needed to - support IPv6, since all of the "address carrying" functions use an - opaque address pointer, and carry an address length as a function - argument. - -3.6. Compatibility with IPv4 Applications - - In order to support the large base of applications using the original - API, system implementations must provide complete source and binary - compatibility with the original API. This means that systems must - continue to support PF_INET sockets and the sockaddr_in address - structure. Applications must be able to create IPv4/TCP and IPv4/UDP - sockets using the PF_INET constant in the socket() function, as - described in the previous section. Applications should be able to - hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP - sockets simultaneously within the same process. - - Applications using the original API should continue to operate as - they did on systems supporting only IPv4. That is, they should - continue to interoperate with IPv4 nodes. - -3.7. Compatibility with IPv4 Nodes - - The API also provides a different type of compatibility: the ability - for IPv6 applications to interoperate with IPv4 applications. This - feature uses the IPv4-mapped IPv6 address format defined in the IPv6 - addressing architecture specification [2]. This address format - allows the IPv4 address of an IPv4 node to be represented as an IPv6 - address. The IPv4 address is encoded into the low-order 32 bits of - the IPv6 address, and the high-order 96 bits hold the fixed prefix - 0:0:0:0:0:FFFF. IPv4-mapped addresses are written as follows: - - ::FFFF:<IPv4-address> - - These addresses are often generated automatically by the - gethostbyname() function when the specified host has only IPv4 - addresses (as described in Section 6.1). - - - -Gilligan, et. al. Informational [Page 9] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - Applications may use PF_INET6 sockets to open TCP connections to IPv4 - nodes, or send UDP packets to IPv4 nodes, by simply encoding the - destination's IPv4 address as an IPv4-mapped IPv6 address, and - passing that address, within a sockaddr_in6 structure, in the - connect() or sendto() call. When applications use PF_INET6 sockets - to accept TCP connections from IPv4 nodes, or receive UDP packets - from IPv4 nodes, the system returns the peer's address to the - application in the accept(), recvfrom(), or getpeername() call using - a sockaddr_in6 structure encoded this way. - - Few applications will likely need to know which type of node they are - interoperating with. However, for those applications that do need to - know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.6, is - provided. - -3.8. IPv6 Wildcard Address - - While the bind() function allows applications to select the source IP - address of UDP packets and TCP connections, applications often want - the system to select the source address for them. With IPv4, one - specifies the address as the symbolic constant INADDR_ANY (called the - "wildcard" address) in the bind() call, or simply omits the bind() - entirely. - - Since the IPv6 address type is a structure (struct in6_addr), a - symbolic constant can be used to initialize an IPv6 address variable, - but cannot be used in an assignment. Therefore systems provide the - IPv6 wildcard address in two forms. - - The first version is a global variable named "in6addr_any" that is an - in6_addr structure. The extern declaration for this variable is - defined in <netinet/in.h>: - - extern const struct in6_addr in6addr_any; - - - - - - - - - - - - - - - - - -Gilligan, et. al. Informational [Page 10] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - Applications use in6addr_any similarly to the way they use INADDR_ANY - in IPv4. For example, to bind a socket to port number 23, but let - the system select the source address, an application could use the - following code: - - struct sockaddr_in6 sin6; - . . . - sin6.sin6_family = AF_INET6; - sin6.sin6_flowinfo = 0; - sin6.sin6_port = htons(23); - sin6.sin6_addr = in6addr_any; /* structure assignment */ - . . . - if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1) - . . . - - The other version is a symbolic constant named IN6ADDR_ANY_INIT and - is defined in <netinet/in.h>. This constant can be used to - initialize an in6_addr structure: - - struct in6_addr anyaddr = IN6ADDR_ANY_INIT; - - Note that this constant can be used ONLY at declaration time. It can - not be used to assign a previously declared in6_addr structure. For - example, the following code will not work: - - /* This is the WRONG way to assign an unspecified address */ - struct sockaddr_in6 sin6; - . . . - sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */ - - Be aware that the IPv4 INADDR_xxx constants are all defined in host - byte order but the IPv6 IN6ADDR_xxx constants and the IPv6 - in6addr_xxx externals are defined in network byte order. - -3.9. IPv6 Loopback Address - - Applications may need to send UDP packets to, or originate TCP - connections to, services residing on the local node. In IPv4, they - can do this by using the constant IPv4 address INADDR_LOOPBACK in - their connect(), sendto(), or sendmsg() call. - - IPv6 also provides a loopback address to contact local TCP and UDP - services. Like the unspecified address, the IPv6 loopback address is - provided in two forms -- a global variable and a symbolic constant. - - - - - - - -Gilligan, et. al. Informational [Page 11] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - The global variable is an in6_addr structure named - "in6addr_loopback." The extern declaration for this variable is - defined in <netinet/in.h>: - - extern const struct in6_addr in6addr_loopback; - - Applications use in6addr_loopback as they would use INADDR_LOOPBACK - in IPv4 applications (but beware of the byte ordering difference - mentioned at the end of the previous section). For example, to open - a TCP connection to the local telnet server, an application could use - the following code: - - struct sockaddr_in6 sin6; - . . . - sin6.sin6_family = AF_INET6; - sin6.sin6_flowinfo = 0; - sin6.sin6_port = htons(23); - sin6.sin6_addr = in6addr_loopback; /* structure assignment */ - . . . - if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1) - . . . - - The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined - in <netinet/in.h>. It can be used at declaration time ONLY; for - example: - - struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT; - - Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment - to a previously declared IPv6 address variable. - -4. Interface Identification - - This API uses an interface index (a small positive integer) to - identify the local interface on which a multicast group is joined - (Section 5.3). Additionally, the advanced API [5] uses these same - interface indexes to identify the interface on which a datagram is - received, or to specify the interface on which a datagram is to be - sent. - - Interfaces are normally known by names such as "le0", "sl1", "ppp2", - and the like. On Berkeley-derived implementations, when an interface - is made known to the system, the kernel assigns a unique positive - integer value (called the interface index) to that interface. These - are small positive integers that start at 1. (Note that 0 is never - used for an interface index.) There may be gaps so that there is no - current interface for a particular positive interface index. - - - - -Gilligan, et. al. Informational [Page 12] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - This API defines two functions that map between an interface name and - index, a third function that returns all the interface names and - indexes, and a fourth function to return the dynamic memory allocated - by the previous function. How these functions are implemented is - left up to the implementation. 4.4BSD implementations can implement - these functions using the existing sysctl() function with the - NET_RT_LIST command. Other implementations may wish to use ioctl() - for this purpose. - -4.1. Name-to-Index - - The first function maps an interface name into its corresponding - index. - - #include <net/if.h> - - unsigned int if_nametoindex(const char *ifname); - - If the specified interface does not exist, the return value is 0. - -4.2. Index-to-Name - - The second function maps an interface index into its corresponding - name. - - #include <net/if.h> - - char *if_indextoname(unsigned int ifindex, char *ifname); - - The ifname argument must point to a buffer of at least IFNAMSIZ bytes - into which the interface name corresponding to the specified index is - returned. (IFNAMSIZ is also defined in <net/if.h> and its value - includes a terminating null byte at the end of the interface name.) - This pointer is also the return value of the function. If there is - no interface corresponding to the specified index, NULL is returned. - - - - - - - - - - - - - - - - -Gilligan, et. al. Informational [Page 13] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - -4.3. Return All Interface Names and Indexes - - The final function returns an array of if_nameindex structures, one - structure per interface. - - #include <net/if.h> - - struct if_nameindex { - unsigned int if_index; /* 1, 2, ... */ - char *if_name; /* null terminated name: "le0", ... */ - }; - - struct if_nameindex *if_nameindex(void); - - The end of the array of structures is indicated by a structure with - an if_index of 0 and an if_name of NULL. The function returns a NULL - pointer upon an error. - - The memory used for this array of structures along with the interface - names pointed to by the if_name members is obtained dynamically. - This memory is freed by the next function. - -4.4. Free Memory - - The following function frees the dynamic memory that was allocated by - if_nameindex(). - - #include <net/if.h> - - void if_freenameindex(struct if_nameindex *ptr); - - The argument to this function must be a pointer that was returned by - if_nameindex(). - -5. Socket Options - - A number of new socket options are defined for IPv6. All of these - new options are at the IPPROTO_IPV6 level. That is, the "level" - parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6 - when using these options. The constant name prefix IPV6_ is used in - all of the new socket options. This serves to clearly identify these - options as applying to IPv6. - - The declaration for IPPROTO_IPV6, the new IPv6 socket options, and - related constants defined in this section are obtained by including - the header <netinet/in.h>. - - - - - -Gilligan, et. al. Informational [Page 14] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - -5.1. Changing Socket Type - - Unix allows open sockets to be passed between processes via the - exec() call and other means. It is a relatively common application - practice to pass open sockets across exec() calls. Thus it is - possible for an application using the original API to pass an open - PF_INET socket to an application that is expecting to receive a - PF_INET6 socket. Similarly, it is possible for an application using - the extended API to pass an open PF_INET6 socket to an application - using the original API, which would be equipped only to deal with - PF_INET sockets. Either of these cases could cause problems, because - the application that is passed the open socket might not know how to - decode the address structures returned in subsequent socket - functions. - - To remedy this problem, a new setsockopt() option is defined that - allows an application to "convert" a PF_INET6 socket into a PF_INET - socket and vice versa. - - An IPv6 application that is passed an open socket from an unknown - process may use the IPV6_ADDRFORM setsockopt() option to "convert" - the socket to PF_INET6. Once that has been done, the system will - return sockaddr_in6 address structures in subsequent socket - functions. - - An IPv6 application that is about to pass an open PF_INET6 socket to - a program that is not be IPv6 capable can "downgrade" the socket to - PF_INET before calling exec(). After that, the system will return - sockaddr_in address structures to the application that was exec()'ed. - Be aware that you cannot downgrade an IPv6 socket to an IPv4 socket - unless all nonwildcard addresses already associated with the IPv6 - socket are IPv4-mapped IPv6 addresses. - - The IPV6_ADDRFORM option is valid at both the IPPROTO_IP and - IPPROTO_IPV6 levels. The only valid option values are PF_INET6 and - PF_INET. For example, to convert a PF_INET6 socket to PF_INET, a - program would call: - - int addrform = PF_INET; - - if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDRFORM, - (char *) &addrform, sizeof(addrform)) == -1) - perror("setsockopt IPV6_ADDRFORM"); - - - - - - - - -Gilligan, et. al. Informational [Page 15] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - An application may use IPV6_ADDRFORM with getsockopt() to learn - whether an open socket is a PF_INET of PF_INET6 socket. For example: - - int addrform; - size_t len = sizeof(addrform); - - if (getsockopt(s, IPPROTO_IPV6, IPV6_ADDRFORM, - (char *) &addrform, &len) == -1) - perror("getsockopt IPV6_ADDRFORM"); - else if (addrform == PF_INET) - printf("This is an IPv4 socket.\n"); - else if (addrform == PF_INET6) - printf("This is an IPv6 socket.\n"); - else - printf("This system is broken.\n"); - -5.2. Unicast Hop Limit - - A new setsockopt() option controls the hop limit used in outgoing - unicast IPv6 packets. The name of this option is IPV6_UNICAST_HOPS, - and it is used at the IPPROTO_IPV6 layer. The following example - illustrates how it is used: - - int hoplimit = 10; - - if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, - (char *) &hoplimit, sizeof(hoplimit)) == -1) - perror("setsockopt IPV6_UNICAST_HOPS"); - - When the IPV6_UNICAST_HOPS option is set with setsockopt(), the - option value given is used as the hop limit for all subsequent - unicast packets sent via that socket. If the option is not set, the - system selects a default value. The integer hop limit value (called - x) is interpreted as follows: - - x < -1: return an error of EINVAL - x == -1: use kernel default - 0 <= x <= 255: use x - x >= 256: return an error of EINVAL - - - - - - - - - - - - -Gilligan, et. al. Informational [Page 16] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - The IPV6_UNICAST_HOPS option may be used with getsockopt() to - determine the hop limit value that the system will use for subsequent - unicast packets sent via that socket. For example: - - int hoplimit; - size_t len = sizeof(hoplimit); - - if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, - (char *) &hoplimit, &len) == -1) - perror("getsockopt IPV6_UNICAST_HOPS"); - else - printf("Using %d for hop limit.\n", hoplimit); - -5.3. Sending and Receiving Multicast Packets - - IPv6 applications may send UDP multicast packets by simply specifying - an IPv6 multicast address in the address argument of the sendto() - function. - - Three socket options at the IPPROTO_IPV6 layer control some of the - parameters for sending multicast packets. Setting these options is - not required: applications may send multicast packets without using - these options. The setsockopt() options for controlling the sending - of multicast packets are summarized below: - - IPV6_MULTICAST_IF - - Set the interface to use for outgoing multicast packets. The - argument is the index of the interface to use. - - Argument type: unsigned int - - IPV6_MULTICAST_HOPS - - Set the hop limit to use for outgoing multicast packets. - (Note a separate option - IPV6_UNICAST_HOPS - is provided to - set the hop limit to use for outgoing unicast packets.) The - interpretation of the argument is the same as for the - IPV6_UNICAST_HOPS option: - - x < -1: return an error of EINVAL - x == -1: use kernel default - 0 <= x <= 255: use x - x >= 256: return an error of EINVAL - - Argument type: int - - - - - -Gilligan, et. al. Informational [Page 17] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - IPV6_MULTICAST_LOOP - - Controls whether outgoing multicast packets sent should be - delivered back to the local application. A toggle. If the - option is set to 1, multicast packets are looped back. If it - is set to 0, they are not. - - Argument type: unsigned int - - The reception of multicast packets is controlled by the two - setsockopt() options summarized below: - - IPV6_ADD_MEMBERSHIP - - Join a multicast group on a specified local interface. If - the interface index is specified as 0, the kernel chooses the - local interface. For example, some kernels look up the - multicast group in the normal IPv6 routing table and using - the resulting interface. - - Argument type: struct ipv6_mreq - - IPV6_DROP_MEMBERSHIP - - Leave a multicast group on a specified interface. - - Argument type: struct ipv6_mreq - - The argument type of both of these options is the ipv6_mreq - structure, defined as: - - #include <netinet/in.h> - - struct ipv6_mreq { - struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */ - unsigned int ipv6mr_interface; /* interface index */ - }; - - Note that to receive multicast datagrams a process must join the - multicast group and bind the UDP port to which datagrams will be - sent. Some processes also bind the multicast group address to the - socket, in addition to the port, to prevent other datagrams destined - to that same port from being delivered to the socket. - - - - - - - - -Gilligan, et. al. Informational [Page 18] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - -6. Library Functions - - New library functions are needed to perform a variety of operations - with IPv6 addresses. Functions are needed to lookup IPv6 addresses - in the Domain Name System (DNS). Both forward lookup (hostname-to- - address translation) and reverse lookup (address-to-hostname - translation) need to be supported. Functions are also needed to - convert IPv6 addresses between their binary and textual form. - -6.1. Hostname-to-Address Translation - - The commonly used function gethostbyname() remains unchanged as does - the hostent structure to which it returns a pointer. Existing - applications that call this function continue to receive only IPv4 - addresses that are the result of a query in the DNS for A records. - (We assume the DNS is being used; some environments may be using a - hosts file or some other name resolution system, either of which may - impede renumbering. We also assume that the RES_USE_INET6 resolver - option is not set, which we describe in more detail shortly.) - - Two new changes are made to support IPv6 addresses. First, the - following function is new: - - #include <sys/socket.h> - #include <netdb.h> - - struct hostent *gethostbyname2(const char *name, int af); - - The af argument specifies the address family. The default operation - of this function is simple: - - - If the af argument is AF_INET, then a query is made for A - records. If successful, IPv4 addresses are returned and the - h_length member of the hostent structure will be 4, else the - function returns a NULL pointer. - - - If the af argument is AF_INET6, then a query is made for AAAA - records. If successful, IPv6 addresses are returned and the - h_length member of the hostent structure will be 16, else the - function returns a NULL pointer. - - - - - - - - - - - -Gilligan, et. al. Informational [Page 19] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - The second change, that provides additional functionality, is a new - resolver option RES_USE_INET6, which is defined as a result of - including the <resolv.h> header. (This option is provided starting - with the BIND 4.9.4 release.) There are three ways to set this - option. - - - The first way is - - res_init(); - _res.options |= RES_USE_INET6; - - and then call either gethostbyname() or gethostbyname2(). This - option then affects only the process that is calling the - resolver. - - - The second way to set this option is to set the environment - variable RES_OPTIONS, as in RES_OPTIONS=inet6. (This example is - for the Bourne and Korn shells.) This method affects any - processes that see this environment variable. - - - The third way is to set this option in the resolver configuration - file (normally /etc/resolv.conf) and the option then affects all - applications on the host. This final method should not be done - until all applications on the host are capable of dealing with - IPv6 addresses. - - There is no priority among these three methods. When the - RES_USE_INET6 option is set, two changes occur: - - - gethostbyname(host) first calls gethostbyname2(host, AF_INET6) - looking for AAAA records, and if this fails it then calls - gethostbyname2(host, AF_INET) looking for A records. - - - gethostbyname2(host, AF_INET) always returns IPv4-mapped IPv6 - addresses with the h_length member of the hostent structure set - to 16. - - An application must not enable the RES_USE_INET6 option until it is - prepared to deal with 16-byte addresses in the returned hostent - structure. - - - - - - - - - - - -Gilligan, et. al. Informational [Page 20] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - The following table summarizes the operation of the existing - gethostbyname() function, the new function gethostbyname2(), along - with the new resolver option RES_USE_INET6. - -+------------------+---------------------------------------------------+ -| | RES_USE_INET6 option | -| +-------------------------+-------------------------+ -| | off | on | -+------------------+-------------------------+-------------------------+ -| |Search for A records. |Search for AAAA records. | -| gethostbyname | If found, return IPv4 | If found, return IPv6 | -| (host) | addresses (h_length=4). | addresses (h_length=16).| -| | Else error. | Else search for A | -| | | records. If found, | -| |Provides backward | return IPv4-mapped IPv6 | -| | compatibility with all | addresses (h_length=16).| -| | existing IPv4 appls. | Else error. | -+------------------+-------------------------+-------------------------+ -| |Search for A records. |Search for A records. | -| gethostbyname2 | If found, return IPv4 | If found, return | -| (host, AF_INET) | addresses (h_length=4). | IPv4-mapped IPv6 | -| | Else error. | addresses (h_length=16).| -| | | Else error. | -+------------------+-------------------------+-------------------------+ -| |Search for AAAA records. |Search for AAAA records. | -| gethostbyname2 | If found, return IPv6 | If found, return IPv6 | -| (host, AF_INET6) | addresses (h_length=16).| addresses (h_length=16).| -| | Else error. | Else error. | -+------------------+-------------------------+-------------------------+ - - It is expected that when a typical naive application that calls - gethostbyname() today is modified to use IPv6, it simply changes the - program to use IPv6 sockets and then enables the RES_USE_INET6 - resolver option before calling gethostbyname(). This application - will then work with either IPv4 or IPv6 peers. - - Note that gethostbyname() and gethostbyname2() are not thread-safe, - since both return a pointer to a static hostent structure. But - several vendors have defined a thread-safe gethostbyname_r() function - that requires four additional arguments. We expect these vendors to - also define a gethostbyname2_r() function. - - - - - - - - - - -Gilligan, et. al. Informational [Page 21] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - -6.2. Address To Hostname Translation - - The existing gethostbyaddr() function already requires an address - family argument and can therefore work with IPv6 addresses: - - #include <sys/socket.h> - #include <netdb.h> - - struct hostent *gethostbyaddr(const char *src, int len, int af); - - One possible source of confusion is the handling of IPv4-mapped IPv6 - addresses and IPv4-compatible IPv6 addresses. This is addressed in - [6] and involves the following logic: - - 1. If af is AF_INET6, and if len equals 16, and if the IPv6 address - is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6 - address, then skip over the first 12 bytes of the IPv6 address, - set af to AF_INET, and set len to 4. - - 2. If af is AF_INET, then query for a PTR record in the in- - addr.arpa domain. - - 3. If af is AF_INET6, then query for a PTR record in the ip6.int - domain. - - 4. If the function is returning success, and if af equals AF_INET, - and if the RES_USE_INET6 option was set, then the single address - that is returned in the hostent structure (a copy of the first - argument to the function) is returned as an IPv4-mapped IPv6 - address and the h_length member is set to 16. - - All four steps listed are performed, in order. The same caveats - regarding a thread-safe version of gethostbyname() that were made at - the end of the previous section apply here as well. - -6.3. Protocol-Independent Hostname and Service Name Translation - - Hostname-to-address translation is done in a protocol-independent - fashion using the getaddrinfo() function that is taken from the - Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g - (Protocol Independent Interfaces) work in progress specification [4]. - - The official specification for this function will be the final POSIX - standard. We are providing this independent description of the - function because POSIX standards are not freely available (as are - IETF documents). Should there be any discrepancies between this - description and the POSIX description, the POSIX description takes - precedence. - - - -Gilligan, et. al. Informational [Page 22] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - #include <sys/socket.h> - #include <netdb.h> - - int getaddrinfo(const char *hostname, const char *servname, - const struct addrinfo *hints, - struct addrinfo **res); - - The addrinfo structure is defined as: - - #include <sys/socket.h> - #include <netdb.h> - - struct addrinfo { - int ai_flags; /* AI_PASSIVE, AI_CANONNAME */ - int ai_family; /* PF_xxx */ - int ai_socktype; /* SOCK_xxx */ - int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */ - size_t ai_addrlen; /* length of ai_addr */ - char *ai_canonname; /* canonical name for hostname */ - struct sockaddr *ai_addr; /* binary address */ - struct addrinfo *ai_next; /* next structure in linked list */ - }; - - The return value from the function is 0 upon success or a nonzero - error code. The following names are the nonzero error codes from - getaddrinfo(), and are defined in <netdb.h>: - - EAI_ADDRFAMILY address family for hostname not supported - EAI_AGAIN temporary failure in name resolution - EAI_BADFLAGS invalid value for ai_flags - EAI_FAIL non-recoverable failure in name resolution - EAI_FAMILY ai_family not supported - EAI_MEMORY memory allocation failure - EAI_NODATA no address associated with hostname - EAI_NONAME hostname nor servname provided, or not known - EAI_SERVICE servname not supported for ai_socktype - EAI_SOCKTYPE ai_socktype not supported - EAI_SYSTEM system error returned in errno - - The hostname and servname arguments are pointers to null-terminated - strings or NULL. One or both of these two arguments must be a non- - NULL pointer. In the normal client scenario, both the hostname and - servname are specified. In the normal server scenario, only the - servname is specified. A non-NULL hostname string can be either a - host name or a numeric host address string (i.e., a dotted-decimal - IPv4 address or an IPv6 hex address). A non-NULL servname string can - be either a service name or a decimal port number. - - - - -Gilligan, et. al. Informational [Page 23] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - The caller can optionally pass an addrinfo structure, pointed to by - the third argument, to provide hints concerning the type of socket - that the caller supports. In this hints structure all members other - than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero - or a NULL pointer. A value of PF_UNSPEC for ai_family means the - caller will accept any protocol family. A value of 0 for ai_socktype - means the caller will accept any socket type. A value of 0 for - ai_protocol means the caller will accept any protocol. For example, - if the caller handles only TCP and not UDP, then the ai_socktype - member of the hints structure should be set to SOCK_STREAM when - getaddrinfo() is called. If the caller handles only IPv4 and not - IPv6, then the ai_family member of the hints structure should be set - to PF_INET when getaddrinfo() is called. If the third argument to - getaddrinfo() is a NULL pointer, this is the same as if the caller - had filled in an addrinfo structure initialized to zero with - ai_family set to PF_UNSPEC. - - Upon successful return a pointer to a linked list of one or more - addrinfo structures is returned through the final argument. The - caller can process each addrinfo structure in this list by following - the ai_next pointer, until a NULL pointer is encountered. In each - returned addrinfo structure the three members ai_family, ai_socktype, - and ai_protocol are the corresponding arguments for a call to the - socket() function. In each addrinfo structure the ai_addr member - points to a filled-in socket address structure whose length is - specified by the ai_addrlen member. - - If the AI_PASSIVE bit is set in the ai_flags member of the hints - structure, then the caller plans to use the returned socket address - structure in a call to bind(). In this case, if the hostname - argument is a NULL pointer, then the IP address portion of the socket - address structure will be set to INADDR_ANY for an IPv4 address or - IN6ADDR_ANY_INIT for an IPv6 address. - - If the AI_PASSIVE bit is not set in the ai_flags member of the hints - structure, then the returned socket address structure will be ready - for a call to connect() (for a connection-oriented protocol) or - either connect(), sendto(), or sendmsg() (for a connectionless - protocol). In this case, if the hostname argument is a NULL pointer, - then the IP address portion of the socket address structure will be - set to the loopback address. - - If the AI_CANONNAME bit is set in the ai_flags member of the hints - structure, then upon successful return the ai_canonname member of the - first addrinfo structure in the linked list will point to a null- - terminated string containing the canonical name of the specified - hostname. - - - - -Gilligan, et. al. Informational [Page 24] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - All of the information returned by getaddrinfo() is dynamically - allocated: the addrinfo structures, and the socket address structures - and canonical host name strings pointed to by the addrinfo - structures. To return this information to the system the function - freeaddrinfo() is called: - - #include <sys/socket.h> - #include <netdb.h> - - void freeaddrinfo(struct addrinfo *ai); - - The addrinfo structure pointed to by the ai argument is freed, along - with any dynamic storage pointed to by the structure. This operation - is repeated until a NULL ai_next pointer is encountered. - - To aid applications in printing error messages based on the EAI_xxx - codes returned by getaddrinfo(), the following function is defined. - - #include <sys/socket.h> - #include <netdb.h> - - char *gai_strerror(int ecode); - - The argument is one of the EAI_xxx values defined earlier and the - eturn value points to a string describing the error. If the argument - is not one of the EAI_xxx values, the function still returns a - pointer to a string whose contents indicate an unknown error. - -6.4. Socket Address Structure to Hostname and Service Name - - The POSIX 1003.1g specification includes no function to perform the - reverse conversion from getaddrinfo(): to look up a hostname and - service name, given the binary address and port. Therefore, we - define the following function: - - #include <sys/socket.h> - #include <netdb.h> - - int getnameinfo(const struct sockaddr *sa, size_t salen, - char *host, size_t hostlen, - char *serv, size_t servlen, - int flags); - - This function looks up an IP address and port number provided by the - caller in the DNS and system-specific database, and returns text - strings for both in buffers provided by the caller. The function - indicates successful completion by a zero return value; a non-zero - return value indicates failure. - - - -Gilligan, et. al. Informational [Page 25] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - The first argument, sa, points to either a sockaddr_in structure (for - IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP - address and port number. The salen argument gives the length of the - sockaddr_in or sockaddr_in6 structure. - - The function returns the hostname associated with the IP address in - the buffer pointed to by the host argument. The caller provides the - size of this buffer via the hostlen argument. The service name - associated with the port number is returned in the buffer pointed to - by serv, and the servlen argument gives the length of this buffer. - The caller specifies not to return either string by providing a zero - value for the hostlen or servlen arguments. Otherwise, the caller - must provide buffers large enough to hold the hostname and the - service name, including the terminating null characters. - - Unfortunately most systems do not provide constants that specify the - maximum size of either a fully-qualified domain name or a service - name. Therefore to aid the application in allocating buffers for - these two returned strings the following constants are defined in - <netdb.h>: - - #define NI_MAXHOST 1025 - #define NI_MAXSERV 32 - - The first value is actually defined as the constant MAXDNAME in - recent versions of BIND's <arpa/nameser.h> header (older versions of - BIND define this constant to be 256) and the second is a guess based - on the services listed in the current Assigned Numbers RFC. - - The final argument is a flag that changes the default actions of this - function. By default the fully-qualified domain name (FQDN) for the - host is looked up in the DNS and returned. If the flag bit NI_NOFQDN - is set, only the hostname portion of the FQDN is returned for local - hosts. - - If the flag bit NI_NUMERICHOST is set, or if the host's name cannot - be located in the DNS, the numeric form of the host's address is - returned instead of its name (e.g., by calling inet_ntop() instead of - gethostbyaddr()). If the flag bit NI_NAMEREQD is set, an error is - returned if the host's name cannot be located in the DNS. - - If the flag bit NI_NUMERICSERV is set, the numeric form of the - service address is returned (e.g., its port number) instead of its - name. The two NI_NUMERICxxx flags are required to support the "-n" - flag that many commands provide. - - - - - - -Gilligan, et. al. Informational [Page 26] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - A fifth flag bit, NI_DGRAM, specifies that the service is a datagram - service, and causes getservbyport() to be called with a second - argument of "udp" instead of its default of "tcp". This is required - for the few ports (512-514) that have different services for UDP and - TCP. - - These NI_xxx flags are defined in <netdb.h> along with the AI_xxx - flags already defined for getaddrinfo(). - -6.5. Address Conversion Functions - - The two functions inet_addr() and inet_ntoa() convert an IPv4 address - between binary and text form. IPv6 applications need similar - functions. The following two functions convert both IPv6 and IPv4 - addresses: - - #include <sys/socket.h> - #include <arpa/inet.h> - - int inet_pton(int af, const char *src, void *dst); - - const char *inet_ntop(int af, const void *src, - char *dst, size_t size); - - The inet_pton() function converts an address in its standard text - presentation form into its numeric binary form. The af argument - specifies the family of the address. Currently the AF_INET and - AF_INET6 address families are supported. The src argument points to - the string being passed in. The dst argument points to a buffer into - which the function stores the numeric address. The address is - returned in network byte order. Inet_pton() returns 1 if the - conversion succeeds, 0 if the input is not a valid IPv4 dotted- - decimal string or a valid IPv6 address string, or -1 with errno set - to EAFNOSUPPORT if the af argument is unknown. The calling - application must ensure that the buffer referred to by dst is large - enough to hold the numeric address (e.g., 4 bytes for AF_INET or 16 - bytes for AF_INET6). - - If the af argument is AF_INET, the function accepts a string in the - standard IPv4 dotted-decimal form: - - ddd.ddd.ddd.ddd - - where ddd is a one to three digit decimal number between 0 and 255. - Note that many implementations of the existing inet_addr() and - inet_aton() functions accept nonstandard input: octal numbers, - hexadecimal numbers, and fewer than four numbers. inet_pton() does - not accept these formats. - - - -Gilligan, et. al. Informational [Page 27] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - If the af argument is AF_INET6, then the function accepts a string in - one of the standard IPv6 text forms defined in Section 2.2 of the - addressing architecture specification [2]. - - The inet_ntop() function converts a numeric address into a text - string suitable for presentation. The af argument specifies the - family of the address. This can be AF_INET or AF_INET6. The src - argument points to a buffer holding an IPv4 address if the af - argument is AF_INET, or an IPv6 address if the af argument is - AF_INET6. The dst argument points to a buffer where the function - will store the resulting text string. The size argument specifies - the size of this buffer. The application must specify a non-NULL dst - argument. For IPv6 addresses, the buffer must be at least 46-octets. - For IPv4 addresses, the buffer must be at least 16-octets. In order - to allow applications to easily declare buffers of the proper size to - store IPv4 and IPv6 addresses in string form, the following two - constants are defined in <netinet/in.h>: - - #define INET_ADDRSTRLEN 16 - #define INET6_ADDRSTRLEN 46 - - The inet_ntop() function returns a pointer to the buffer containing - the text string if the conversion succeeds, and NULL otherwise. Upon - failure, errno is set to EAFNOSUPPORT if the af argument is invalid - or ENOSPC if the size of the result buffer is inadequate. - -6.6. Address Testing Macros - - The following macros can be used to test for special IPv6 addresses. - - #include <netinet/in.h> - - int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *); - int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *); - int IN6_IS_ADDR_MULTICAST (const struct in6_addr *); - int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *); - int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *); - int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *); - int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *); - - int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); - int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); - int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); - int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *); - int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *); - - - - - - -Gilligan, et. al. Informational [Page 28] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - The first seven macros return true if the address is of the specified - type, or false otherwise. The last five test the scope of a - multicast address and return true if the address is a multicast - address of the specified scope or false if the address is either not - a multicast address or not of the specified scope. - -7. Summary of New Definitions - - The following list summarizes the constants, structure, and extern - definitions discussed in this memo, sorted by header. - - <net/if.h> IFNAMSIZ - <net/if.h> struct if_nameindex{}; - - <netdb.h> AI_CANONNAME - <netdb.h> AI_PASSIVE - <netdb.h> EAI_ADDRFAMILY - <netdb.h> EAI_AGAIN - <netdb.h> EAI_BADFLAGS - <netdb.h> EAI_FAIL - <netdb.h> EAI_FAMILY - <netdb.h> EAI_MEMORY - <netdb.h> EAI_NODATA - <netdb.h> EAI_NONAME - <netdb.h> EAI_SERVICE - <netdb.h> EAI_SOCKTYPE - <netdb.h> EAI_SYSTEM - <netdb.h> NI_DGRAM - <netdb.h> NI_MAXHOST - <netdb.h> NI_MAXSERV - <netdb.h> NI_NAMEREQD - <netdb.h> NI_NOFQDN - <netdb.h> NI_NUMERICHOST - <netdb.h> NI_NUMERICSERV - <netdb.h> struct addrinfo{}; - - <netinet/in.h> IN6ADDR_ANY_INIT - <netinet/in.h> IN6ADDR_LOOPBACK_INIT - <netinet/in.h> INET6_ADDRSTRLEN - <netinet/in.h> INET_ADDRSTRLEN - <netinet/in.h> IPPROTO_IPV6 - <netinet/in.h> IPV6_ADDRFORM - <netinet/in.h> IPV6_ADD_MEMBERSHIP - <netinet/in.h> IPV6_DROP_MEMBERSHIP - <netinet/in.h> IPV6_MULTICAST_HOPS - <netinet/in.h> IPV6_MULTICAST_IF - <netinet/in.h> IPV6_MULTICAST_LOOP - <netinet/in.h> IPV6_UNICAST_HOPS - - - -Gilligan, et. al. Informational [Page 29] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - <netinet/in.h> SIN6_LEN - <netinet/in.h> extern const struct in6_addr in6addr_any; - <netinet/in.h> extern const struct in6_addr in6addr_loopback; - <netinet/in.h> struct in6_addr{}; - <netinet/in.h> struct ipv6_mreq{}; - <netinet/in.h> struct sockaddr_in6{}; - - <resolv.h> RES_USE_INET6 - - <sys/socket.h> AF_INET6 - <sys/socket.h> PF_INET6 - - - The following list summarizes the function and macro prototypes - discussed in this memo, sorted by header. - -<arpa/inet.h> int inet_pton(int, const char *, void *); -<arpa/inet.h> const char *inet_ntop(int, const void *, - char *, size_t); - -<net/if.h> char *if_indextoname(unsigned int, char *); -<net/if.h> unsigned int if_nametoindex(const char *); -<net/if.h> void if_freenameindex(struct if_nameindex *); -<net/if.h> struct if_nameindex *if_nameindex(void); - -<netdb.h> int getaddrinfo(const char *, const char *, - const struct addrinfo *, - struct addrinfo **); -<netdb.h> int getnameinfo(const struct sockaddr *, size_t, - char *, size_t, char *, size_t, int); -<netdb.h> void freeaddrinfo(struct addrinfo *); -<netdb.h> char *gai_strerror(int); -<netdb.h> struct hostent *gethostbyname(const char *); -<netdb.h> struct hostent *gethostbyaddr(const char *, int, int); -<netdb.h> struct hostent *gethostbyname2(const char *, int); - -<netinet/in.h> int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_MULTICAST(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *); - - - -Gilligan, et. al. Informational [Page 30] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - -8. Security Considerations - - IPv6 provides a number of new security mechanisms, many of which need - to be accessible to applications. A companion memo detailing the - extensions to the socket interfaces to support IPv6 security is being - written [3]. - -9. Acknowledgments - - Thanks to the many people who made suggestions and provided feedback - to to the numerous revisions of this document, including: Werner - Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew Cherenson, - Alex Conta, Alan Cox, Steve Deering, Richard Draves, Francis Dupont, - Robert Elz, Marc Hasson, Tim Hartrick, Tom Herbert, Bob Hinden, Wan- - Yen Hsu, Christian Huitema, Koji Imada, Markus Jork, Ron Lee, Alan - Lloyd, Charles Lynn, Jack McCann, Dan McDonald, Dave Mitton, Thomas - Narten, Erik Nordmark, Josh Osborne, Craig Partridge, Jean-Luc - Richier, Erik Scoredos, Keith Sklower, Matt Thomas, Harvey Thompson, - Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David - Waitzman, Carl Williams, and Kazuhiko Yamamoto, - - The getaddrinfo() and getnameinfo() functions are taken from an - earlier Work in Progress by Keith Sklower. As noted in that - document, William Durst, Steven Wise, Michael Karels, and Eric Allman - provided many useful discussions on the subject of protocol- - independent name-to-address translation, and reviewed early versions - of Keith Sklower's original proposal. Eric Allman implemented the - first prototype of getaddrinfo(). The observation that specifying - the pair of name and service would suffice for connecting to a - service independent of protocol details was made by Marshall Rose in - a proposal to X/Open for a "Uniform Network Interface". - - Craig Metz made many contributions to this document. Ramesh Govindan - made a number of contributions and co-authored an earlier version of - this memo. - -10. References - - [1] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) - Specification", RFC 1883, December 1995. - - [2] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", - RFC 1884, December 1995. - - [3] McDonald, D., "A Simple IP Security API Extension to BSD Sockets", - Work in Progress. - - - - - -Gilligan, et. al. Informational [Page 31] - -RFC 2133 IPv6 Socket Interface Extensions April 1997 - - - [4] IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT - 6.3, November 1995. - - [5] Stevens, W., and M. Thomas, "Advanced Sockets API for IPv6", - Work in Progress. - - [6] Vixie, P., "Reverse Name Lookups of Encapsulated IPv4 Addresses in - IPv6", Work in Progress. - -11. Authors' Addresses - - Robert E. Gilligan - Freegate Corporation - 710 Lakeway Dr. STE 230 - Sunnyvale, CA 94086 - - Phone: +1 408 524 4804 - EMail: gilligan@freegate.net - - - Susan Thomson - Bell Communications Research - MRE 2P-343, 445 South Street - Morristown, NJ 07960 - - Phone: +1 201 829 4514 - EMail: set@thumper.bellcore.com - - - Jim Bound - Digital Equipment Corporation - 110 Spitbrook Road ZK3-3/U14 - Nashua, NH 03062-2698 - - Phone: +1 603 881 0400 - Email: bound@zk3.dec.com - - - W. Richard Stevens - 1202 E. Paseo del Zorro - Tucson, AZ 85718-2826 - - Phone: +1 520 297 9416 - EMail: rstevens@kohala.com - - - - - - - -Gilligan, et. al. Informational [Page 32] - diff --git a/contrib/bind9/doc/rfc/rfc2136.txt b/contrib/bind9/doc/rfc/rfc2136.txt deleted file mode 100644 index 4d62702e0d4b..000000000000 --- a/contrib/bind9/doc/rfc/rfc2136.txt +++ /dev/null @@ -1,1460 +0,0 @@ - - - - - - -Network Working Group P. Vixie, Editor -Request for Comments: 2136 ISC -Updates: 1035 S. Thomson -Category: Standards Track Bellcore - Y. Rekhter - Cisco - J. Bound - DEC - April 1997 - - Dynamic Updates in the Domain Name System (DNS UPDATE) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - The Domain Name System was originally designed to support queries of - a statically configured database. While the data was expected to - change, the frequency of those changes was expected to be fairly low, - and all updates were made as external edits to a zone's Master File. - - Using this specification of the UPDATE opcode, it is possible to add - or delete RRs or RRsets from a specified zone. Prerequisites are - specified separately from update operations, and can specify a - dependency upon either the previous existence or nonexistence of an - RRset, or the existence of a single RR. - - UPDATE is atomic, i.e., all prerequisites must be satisfied or else - no update operations will take place. There are no data dependent - error conditions defined after the prerequisites have been met. - -1 - Definitions - - This document intentionally gives more definition to the roles of - "Master," "Slave," and "Primary Master" servers, and their - enumeration in NS RRs, and the SOA MNAME field. In that sense, the - following server type definitions can be considered an addendum to - [RFC1035], and are intended to be consistent with [RFC1996]: - - Slave an authoritative server that uses AXFR or IXFR to - retrieve the zone and is named in the zone's NS - RRset. - - - -Vixie, et. al. Standards Track [Page 1] - -RFC 2136 DNS Update April 1997 - - - Master an authoritative server configured to be the - source of AXFR or IXFR data for one or more slave - servers. - - Primary Master master server at the root of the AXFR/IXFR - dependency graph. The primary master is named in - the zone's SOA MNAME field and optionally by an NS - RR. There is by definition only one primary master - server per zone. - - A domain name identifies a node within the domain name space tree - structure. Each node has a set (possibly empty) of Resource Records - (RRs). All RRs having the same NAME, CLASS and TYPE are called a - Resource Record Set (RRset). - - The pseudocode used in this document is for example purposes only. - If it is found to disagree with the text, the text shall be - considered authoritative. If the text is found to be ambiguous, the - pseudocode can be used to help resolve the ambiguity. - - 1.1 - Comparison Rules - - 1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE, - RDLENGTH and RDATA fields are equal. Note that the time-to-live - (TTL) field is explicitly excluded from the comparison. - - 1.1.2. The rules for comparison of character strings in names are - specified in [RFC1035 2.3.3]. - - 1.1.3. Wildcarding is disabled. That is, a wildcard ("*") in an - update only matches a wildcard ("*") in the zone, and vice versa. - - 1.1.4. Aliasing is disabled: A CNAME in the zone matches a CNAME in - the update, and will not otherwise be followed. All UPDATE - operations are done on the basis of canonical names. - - 1.1.5. The following RR types cannot be appended to an RRset. If the - following comparison rules are met, then an attempt to add the new RR - will result in the replacement of the previous RR: - - SOA compare only NAME, CLASS and TYPE -- it is not possible to - have more than one SOA per zone, even if any of the data - fields differ. - - WKS compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL - -- only one WKS RR is possible for this tuple, even if the - services masks differ. - - - - -Vixie, et. al. Standards Track [Page 2] - -RFC 2136 DNS Update April 1997 - - - CNAME compare only NAME, CLASS, and TYPE -- it is not possible - to have more than one CNAME RR, even if their data fields - differ. - - 1.2 - Glue RRs - - For the purpose of determining whether a domain name used in the - UPDATE protocol is contained within a specified zone, a domain name - is "in" a zone if it is owned by that zone's domain name. See - section 7.18 for details. - - 1.3 - New Assigned Numbers - - CLASS = NONE (254) - RCODE = YXDOMAIN (6) - RCODE = YXRRSET (7) - RCODE = NXRRSET (8) - RCODE = NOTAUTH (9) - RCODE = NOTZONE (10) - Opcode = UPDATE (5) - -2 - Update Message Format - - The DNS Message Format is defined by [RFC1035 4.1]. Some extensions - are necessary (for example, more error codes are possible under - UPDATE than under QUERY) and some fields must be overloaded (see - description of CLASS fields below). - - The overall format of an UPDATE message is, following [ibid]: - - +---------------------+ - | Header | - +---------------------+ - | Zone | specifies the zone to be updated - +---------------------+ - | Prerequisite | RRs or RRsets which must (not) preexist - +---------------------+ - | Update | RRs or RRsets to be added or deleted - +---------------------+ - | Additional Data | additional data - +---------------------+ - - - - - - - - - - -Vixie, et. al. Standards Track [Page 3] - -RFC 2136 DNS Update April 1997 - - - The Header Section specifies that this message is an UPDATE, and - describes the size of the other sections. The Zone Section names the - zone that is to be updated by this message. The Prerequisite Section - specifies the starting invariants (in terms of zone content) required - for this update. The Update Section contains the edits to be made, - and the Additional Data Section contains data which may be necessary - to complete, but is not part of, this update. - - 2.1 - Transport Issues - - An update transaction may be carried in a UDP datagram, if the - request fits, or in a TCP connection (at the discretion of the - requestor). When TCP is used, the message is in the format described - in [RFC1035 4.2.2]. - - 2.2 - Message Header - - The header of the DNS Message Format is defined by [RFC 1035 4.1]. - Not all opcodes define the same set of flag bits, though as a - practical matter most of the bits defined for QUERY (in [ibid]) are - identically defined by the other opcodes. UPDATE uses only one flag - bit (QR). - - The DNS Message Format specifies record counts for its four sections - (Question, Answer, Authority, and Additional). UPDATE uses the same - fields, and the same section formats, but the naming and use of these - sections differs as shown in the following modified header, after - [RFC1035 4.1.1]: - - 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 | Z | RCODE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ZOCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | PRCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | UPCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ADCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - - - - - - -Vixie, et. al. Standards Track [Page 4] - -RFC 2136 DNS Update April 1997 - - - These fields are used as follows: - - ID A 16-bit identifier assigned by the entity that generates any - kind of request. This identifier is copied in the - corresponding reply and can be used by the requestor to match - replies to outstanding requests, or by the server to detect - duplicated requests from some requestor. - - QR A one bit field that specifies whether this message is a - request (0), or a response (1). - - Opcode A four bit field that specifies the kind of request in this - message. This value is set by the originator of a request - and copied into the response. The Opcode value that - identifies an UPDATE message is five (5). - - Z Reserved for future use. Should be zero (0) in all requests - and responses. A non-zero Z field should be ignored by - implementations of this specification. - - RCODE Response code - this four bit field is undefined in requests - and set in responses. The values and meanings of this field - within responses are as follows: - - Mneumonic Value Description - ------------------------------------------------------------ - NOERROR 0 No error condition. - FORMERR 1 The name server was unable to interpret - the request due to a format error. - SERVFAIL 2 The name server encountered an internal - failure while processing this request, - for example an operating system error - or a forwarding timeout. - NXDOMAIN 3 Some name that ought to exist, - does not exist. - NOTIMP 4 The name server does not support - the specified Opcode. - REFUSED 5 The name server refuses to perform the - specified operation for policy or - security reasons. - YXDOMAIN 6 Some name that ought not to exist, - does exist. - YXRRSET 7 Some RRset that ought not to exist, - does exist. - NXRRSET 8 Some RRset that ought to exist, - does not exist. - - - - - -Vixie, et. al. Standards Track [Page 5] - -RFC 2136 DNS Update April 1997 - - - NOTAUTH 9 The server is not authoritative for - the zone named in the Zone Section. - NOTZONE 10 A name used in the Prerequisite or - Update Section is not within the - zone denoted by the Zone Section. - - ZOCOUNT The number of RRs in the Zone Section. - - PRCOUNT The number of RRs in the Prerequisite Section. - - UPCOUNT The number of RRs in the Update Section. - - ADCOUNT The number of RRs in the Additional Data Section. - - 2.3 - Zone Section - - The Zone Section has the same format as that specified in [RFC1035 - 4.1.2], with the fields redefined as follows: - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | | - / ZNAME / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ZTYPE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ZCLASS | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - UPDATE uses this section to denote the zone of the records being - updated. All records to be updated must be in the same zone, and - therefore the Zone Section is allowed to contain exactly one record. - The ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS is - the zone's class. - - 2.4 - Prerequisite Section - - This section contains a set of RRset prerequisites which must be - satisfied at the time the UPDATE packet is received by the primary - master server. The format of this section is as specified by - [RFC1035 4.1.3]. There are five possible sets of semantics that can - be expressed here, summarized as follows and then explained below. - - (1) RRset exists (value independent). At least one RR with a - specified NAME and TYPE (in the zone and class specified by - the Zone Section) must exist. - - - -Vixie, et. al. Standards Track [Page 6] - -RFC 2136 DNS Update April 1997 - - - (2) RRset exists (value dependent). A set of RRs with a - specified NAME and TYPE exists and has the same members - with the same RDATAs as the RRset specified here in this - Section. - - (3) RRset does not exist. No RRs with a specified NAME and TYPE - (in the zone and class denoted by the Zone Section) can exist. - - (4) Name is in use. At least one RR with a specified NAME (in - the zone and class specified by the Zone Section) must exist. - Note that this prerequisite is NOT satisfied by empty - nonterminals. - - (5) Name is not in use. No RR of any type is owned by a - specified NAME. Note that this prerequisite IS satisfied by - empty nonterminals. - - The syntax of these is as follows: - - 2.4.1 - RRset Exists (Value Independent) - - At least one RR with a specified NAME and TYPE (in the zone and class - specified in the Zone Section) must exist. - - For this prerequisite, a requestor adds to the section a single RR - whose NAME and TYPE are equal to that of the zone RRset whose - existence is required. RDLENGTH is zero and RDATA is therefore - empty. CLASS must be specified as ANY to differentiate this - condition from that of an actual RR whose RDLENGTH is naturally zero - (0) (e.g., NULL). TTL is specified as zero (0). - - 2.4.2 - RRset Exists (Value Dependent) - - A set of RRs with a specified NAME and TYPE exists and has the same - members with the same RDATAs as the RRset specified here in this - section. While RRset ordering is undefined and therefore not - significant to this comparison, the sets be identical in their - extent. - - For this prerequisite, a requestor adds to the section an entire - RRset whose preexistence is required. NAME and TYPE are that of the - RRset being denoted. CLASS is that of the zone. TTL must be - specified as zero (0) and is ignored when comparing RRsets for - identity. - - - - - - - -Vixie, et. al. Standards Track [Page 7] - -RFC 2136 DNS Update April 1997 - - - 2.4.3 - RRset Does Not Exist - - No RRs with a specified NAME and TYPE (in the zone and class denoted - by the Zone Section) can exist. - - For this prerequisite, a requestor adds to the section a single RR - whose NAME and TYPE are equal to that of the RRset whose nonexistence - is required. The RDLENGTH of this record is zero (0), and RDATA - field is therefore empty. CLASS must be specified as NONE in order - to distinguish this condition from a valid RR whose RDLENGTH is - naturally zero (0) (for example, the NULL RR). TTL must be specified - as zero (0). - - 2.4.4 - Name Is In Use - - Name is in use. At least one RR with a specified NAME (in the zone - and class specified by the Zone Section) must exist. Note that this - prerequisite is NOT satisfied by empty nonterminals. - - For this prerequisite, a requestor adds to the section a single RR - whose NAME is equal to that of the name whose ownership of an RR is - required. RDLENGTH is zero and RDATA is therefore empty. CLASS must - be specified as ANY to differentiate this condition from that of an - actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL). TYPE - must be specified as ANY to differentiate this case from that of an - RRset existence test. TTL is specified as zero (0). - - 2.4.5 - Name Is Not In Use - - Name is not in use. No RR of any type is owned by a specified NAME. - Note that this prerequisite IS satisfied by empty nonterminals. - - For this prerequisite, a requestor adds to the section a single RR - whose NAME is equal to that of the name whose nonownership of any RRs - is required. RDLENGTH is zero and RDATA is therefore empty. CLASS - must be specified as NONE. TYPE must be specified as ANY. TTL must - be specified as zero (0). - - 2.5 - Update Section - - This section contains RRs to be added to or deleted from the zone. - The format of this section is as specified by [RFC1035 4.1.3]. There - are four possible sets of semantics, summarized below and with - details to follow. - - - - - - - -Vixie, et. al. Standards Track [Page 8] - -RFC 2136 DNS Update April 1997 - - - (1) Add RRs to an RRset. - (2) Delete an RRset. - (3) Delete all RRsets from a name. - (4) Delete an RR from an RRset. - - The syntax of these is as follows: - - 2.5.1 - Add To An RRset - - RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH - and RDATA are those being added, and CLASS is the same as the zone - class. Any duplicate RRs will be silently ignored by the primary - master. - - 2.5.2 - Delete An RRset - - One RR is added to the Update Section whose NAME and TYPE are those - of the RRset to be deleted. TTL must be specified as zero (0) and is - otherwise not used by the primary master. CLASS must be specified as - ANY. RDLENGTH must be zero (0) and RDATA must therefore be empty. - If no such RRset exists, then this Update RR will be silently ignored - by the primary master. - - 2.5.3 - Delete All RRsets From A Name - - One RR is added to the Update Section whose NAME is that of the name - to be cleansed of RRsets. TYPE must be specified as ANY. TTL must - be specified as zero (0) and is otherwise not used by the primary - master. CLASS must be specified as ANY. RDLENGTH must be zero (0) - and RDATA must therefore be empty. If no such RRsets exist, then - this Update RR will be silently ignored by the primary master. - - 2.5.4 - Delete An RR From An RRset - - RRs to be deleted are added to the Update Section. The NAME, TYPE, - RDLENGTH and RDATA must match the RR being deleted. TTL must be - specified as zero (0) and will otherwise be ignored by the primary - master. CLASS must be specified as NONE to distinguish this from an - RR addition. If no such RRs exist, then this Update RR will be - silently ignored by the primary master. - - - - - - - - - - - -Vixie, et. al. Standards Track [Page 9] - -RFC 2136 DNS Update April 1997 - - - 2.6 - Additional Data Section - - This section contains RRs which are related to the update itself, or - to new RRs being added by the update. For example, out of zone glue - (A RRs referred to by new NS RRs) should be presented here. The - server can use or ignore out of zone glue, at the discretion of the - server implementor. The format of this section is as specified by - [RFC1035 4.1.3]. - -3 - Server Behavior - - A server, upon receiving an UPDATE request, will signal NOTIMP to the - requestor if the UPDATE opcode is not recognized or if it is - recognized but has not been implemented. Otherwise, processing - continues as follows. - - 3.1 - Process Zone Section - - 3.1.1. The Zone Section is checked to see that there is exactly one - RR therein and that the RR's ZTYPE is SOA, else signal FORMERR to the - requestor. Next, the ZNAME and ZCLASS are checked to see if the zone - so named is one of this server's authority zones, else signal NOTAUTH - to the requestor. If the server is a zone slave, the request will be - forwarded toward the primary master. - - 3.1.2 - Pseudocode For Zone Section Processing - - if (zcount != 1 || ztype != SOA) - return (FORMERR) - if (zone_type(zname, zclass) == SLAVE) - return forward() - if (zone_type(zname, zclass) == MASTER) - return update() - return (NOTAUTH) - - Sections 3.2 through 3.8 describe the primary master's behaviour, - whereas Section 6 describes a forwarder's behaviour. - - 3.2 - Process Prerequisite Section - - Next, the Prerequisite Section is checked to see that all - prerequisites are satisfied by the current state of the zone. Using - the definitions expressed in Section 1.2, if any RR's NAME is not - within the zone specified in the Zone Section, signal NOTZONE to the - requestor. - - - - - - -Vixie, et. al. Standards Track [Page 10] - -RFC 2136 DNS Update April 1997 - - - 3.2.1. For RRs in this section whose CLASS is ANY, test to see that - TTL and RDLENGTH are both zero (0), else signal FORMERR to the - requestor. If TYPE is ANY, test to see that there is at least one RR - in the zone whose NAME is the same as that of the Prerequisite RR, - else signal NXDOMAIN to the requestor. If TYPE is not ANY, test to - see that there is at least one RR in the zone whose NAME and TYPE are - the same as that of the Prerequisite RR, else signal NXRRSET to the - requestor. - - 3.2.2. For RRs in this section whose CLASS is NONE, test to see that - the TTL and RDLENGTH are both zero (0), else signal FORMERR to the - requestor. If the TYPE is ANY, test to see that there are no RRs in - the zone whose NAME is the same as that of the Prerequisite RR, else - signal YXDOMAIN to the requestor. If the TYPE is not ANY, test to - see that there are no RRs in the zone whose NAME and TYPE are the - same as that of the Prerequisite RR, else signal YXRRSET to the - requestor. - - 3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS, - test to see that the TTL is zero (0), else signal FORMERR to the - requestor. Then, build an RRset for each unique <NAME,TYPE> and - compare each resulting RRset for set equality (same members, no more, - no less) with RRsets in the zone. If any Prerequisite RRset is not - entirely and exactly matched by a zone RRset, signal NXRRSET to the - requestor. If any RR in this section has a CLASS other than ZCLASS - or NONE or ANY, signal FORMERR to the requestor. - - 3.2.4 - Table Of Metavalues Used In Prerequisite Section - - CLASS TYPE RDATA Meaning - ------------------------------------------------------------ - ANY ANY empty Name is in use - ANY rrset empty RRset exists (value independent) - NONE ANY empty Name is not in use - NONE rrset empty RRset does not exist - zone rrset rr RRset exists (value dependent) - - - - - - - - - - - - - - - -Vixie, et. al. Standards Track [Page 11] - -RFC 2136 DNS Update April 1997 - - - 3.2.5 - Pseudocode for Prerequisite Section Processing - - for rr in prerequisites - if (rr.ttl != 0) - return (FORMERR) - if (zone_of(rr.name) != ZNAME) - return (NOTZONE); - if (rr.class == ANY) - if (rr.rdlength != 0) - return (FORMERR) - if (rr.type == ANY) - if (!zone_name<rr.name>) - return (NXDOMAIN) - else - if (!zone_rrset<rr.name, rr.type>) - return (NXRRSET) - if (rr.class == NONE) - if (rr.rdlength != 0) - return (FORMERR) - if (rr.type == ANY) - if (zone_name<rr.name>) - return (YXDOMAIN) - else - if (zone_rrset<rr.name, rr.type>) - return (YXRRSET) - if (rr.class == zclass) - temp<rr.name, rr.type> += rr - else - return (FORMERR) - - for rrset in temp - if (zone_rrset<rrset.name, rrset.type> != rrset) - return (NXRRSET) - - 3.3 - Check Requestor's Permissions - - 3.3.1. Next, the requestor's permission to update the RRs named in - the Update Section may be tested in an implementation dependent - fashion or using mechanisms specified in a subsequent Secure DNS - Update protocol. If the requestor does not have permission to - perform these updates, the server may write a warning message in its - operations log, and may either signal REFUSED to the requestor, or - ignore the permission problem and proceed with the update. - - - - - - - - -Vixie, et. al. Standards Track [Page 12] - -RFC 2136 DNS Update April 1997 - - - 3.3.2. While the exact processing is implementation defined, if these - verification activities are to be performed, this is the point in the - server's processing where such performance should take place, since - if a REFUSED condition is encountered after an update has been - partially applied, it will be necessary to undo the partial update - and restore the zone to its original state before answering the - requestor. - - 3.3.3 - Pseudocode for Permission Checking - - if (security policy exists) - if (this update is not permitted) - if (local option) - log a message about permission problem - if (local option) - return (REFUSED) - - 3.4 - Process Update Section - - Next, the Update Section is processed as follows. - - 3.4.1 - Prescan - - The Update Section is parsed into RRs and each RR's CLASS is checked - to see if it is ANY, NONE, or the same as the Zone Class, else signal - a FORMERR to the requestor. Using the definitions in Section 1.2, - each RR's NAME must be in the zone specified by the Zone Section, - else signal NOTZONE to the requestor. - - 3.4.1.2. For RRs whose CLASS is not ANY, check the TYPE and if it is - ANY, AXFR, MAILA, MAILB, or any other QUERY metatype, or any - unrecognized type, then signal FORMERR to the requestor. For RRs - whose CLASS is ANY or NONE, check the TTL to see that it is zero (0), - else signal a FORMERR to the requestor. For any RR whose CLASS is - ANY, check the RDLENGTH to make sure that it is zero (0) (that is, - the RDATA field is empty), and that the TYPE is not AXFR, MAILA, - MAILB, or any other QUERY metatype besides ANY, or any unrecognized - type, else signal FORMERR to the requestor. - - - - - - - - - - - - - -Vixie, et. al. Standards Track [Page 13] - -RFC 2136 DNS Update April 1997 - - - 3.4.1.3 - Pseudocode For Update Section Prescan - - [rr] for rr in updates - if (zone_of(rr.name) != ZNAME) - return (NOTZONE); - if (rr.class == zclass) - if (rr.type & ANY|AXFR|MAILA|MAILB) - return (FORMERR) - elsif (rr.class == ANY) - if (rr.ttl != 0 || rr.rdlength != 0 - || rr.type & AXFR|MAILA|MAILB) - return (FORMERR) - elsif (rr.class == NONE) - if (rr.ttl != 0 || rr.type & ANY|AXFR|MAILA|MAILB) - return (FORMERR) - else - return (FORMERR) - - 3.4.2 - Update - - The Update Section is parsed into RRs and these RRs are processed in - order. - - 3.4.2.1. If any system failure (such as an out of memory condition, - or a hardware error in persistent storage) occurs during the - processing of this section, signal SERVFAIL to the requestor and undo - all updates applied to the zone during this transaction. - - 3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to - the zone. In case of duplicate RDATAs (which for SOA RRs is always - the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL - fields both match), the Zone RR is replaced by Update RR. If the - TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is - lower (according to [RFC1982]) than or equal to the current Zone SOA - RR's SOA.SERIAL, the Update RR is ignored. In the case of a CNAME - Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME - Update RR, otherwise replace the CNAME Zone RR with the CNAME Update - RR. - - 3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY, - all Zone RRs with the same NAME are deleted, unless the NAME is the - same as ZNAME in which case only those RRs whose TYPE is other than - SOA or NS are deleted. For any Update RR whose CLASS is ANY and - whose TYPE is not ANY all Zone RRs with the same NAME and TYPE are - deleted, unless the NAME is the same as ZNAME in which case neither - SOA or NS RRs will be deleted. - - - - - -Vixie, et. al. Standards Track [Page 14] - -RFC 2136 DNS Update April 1997 - - - 3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose - NAME, TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted, - unless the NAME is the same as ZNAME and either the TYPE is SOA or - the TYPE is NS and the matching Zone RR is the only NS remaining in - the RRset, in which case this Update RR is ignored. - - 3.4.2.5. Signal NOERROR to the requestor. - - 3.4.2.6 - Table Of Metavalues Used In Update Section - - CLASS TYPE RDATA Meaning - --------------------------------------------------------- - ANY ANY empty Delete all RRsets from a name - ANY rrset empty Delete an RRset - NONE rrset rr Delete an RR from an RRset - zone rrset rr Add to an RRset - - 3.4.2.7 - Pseudocode For Update Section Processing - - [rr] for rr in updates - if (rr.class == zclass) - if (rr.type == CNAME) - if (zone_rrset<rr.name, ~CNAME>) - next [rr] - elsif (zone_rrset<rr.name, CNAME>) - next [rr] - if (rr.type == SOA) - if (!zone_rrset<rr.name, SOA> || - zone_rr<rr.name, SOA>.serial > rr.soa.serial) - next [rr] - for zrr in zone_rrset<rr.name, rr.type> - if (rr.type == CNAME || rr.type == SOA || - (rr.type == WKS && rr.proto == zrr.proto && - rr.address == zrr.address) || - rr.rdata == zrr.rdata) - zrr = rr - next [rr] - zone_rrset<rr.name, rr.type> += rr - elsif (rr.class == ANY) - if (rr.type == ANY) - if (rr.name == zname) - zone_rrset<rr.name, ~(SOA|NS)> = Nil - else - zone_rrset<rr.name, *> = Nil - elsif (rr.name == zname && - (rr.type == SOA || rr.type == NS)) - next [rr] - else - - - -Vixie, et. al. Standards Track [Page 15] - -RFC 2136 DNS Update April 1997 - - - zone_rrset<rr.name, rr.type> = Nil - elsif (rr.class == NONE) - if (rr.type == SOA) - next [rr] - if (rr.type == NS && zone_rrset<rr.name, NS> == rr) - next [rr] - zone_rr<rr.name, rr.type, rr.data> = Nil - return (NOERROR) - - 3.5 - Stability - - When a zone is modified by an UPDATE operation, the server must - commit the change to nonvolatile storage before sending a response to - the requestor or answering any queries or transfers for the modified - zone. It is reasonable for a server to store only the update records - as long as a system reboot or power failure will cause these update - records to be incorporated into the zone the next time the server is - started. It is also reasonable for the server to copy the entire - modified zone to nonvolatile storage after each update operation, - though this would have suboptimal performance for large zones. - - 3.6 - Zone Identity - - If the zone's SOA SERIAL is changed by an update operation, that - change must be in a positive direction (using modulo 2**32 arithmetic - as specified by [RFC1982]). Attempts to replace an SOA with one - whose SERIAL is less than the current one will be silently ignored by - the primary master server. - - If the zone's SOA's SERIAL is not changed as a result of an update - operation, then the server shall increment it automatically before - the SOA or any changed name or RR or RRset is included in any - response or transfer. The primary master server's implementor might - choose to autoincrement the SOA SERIAL if any of the following events - occurs: - - (1) Each update operation. - - (2) A name, RR or RRset in the zone has changed and has subsequently - been visible to a DNS client since the unincremented SOA was - visible to a DNS client, and the SOA is about to become visible - to a DNS client. - - (3) A configurable period of time has elapsed since the last update - operation. This period shall be less than or equal to one third - of the zone refresh time, and the default shall be the lesser of - that maximum and 300 seconds. - - - - -Vixie, et. al. Standards Track [Page 16] - -RFC 2136 DNS Update April 1997 - - - (4) A configurable number of updates has been applied since the last - SOA change. The default value for this configuration parameter - shall be one hundred (100). - - It is imperative that the zone's contents and the SOA's SERIAL be - tightly synchronized. If the zone appears to change, the SOA must - appear to change as well. - - 3.7 - Atomicity - - During the processing of an UPDATE transaction, the server must - ensure atomicity with respect to other (concurrent) UPDATE or QUERY - transactions. No two transactions can be processed concurrently if - either depends on the final results of the other; in particular, a - QUERY should not be able to retrieve RRsets which have been partially - modified by a concurrent UPDATE, and an UPDATE should not be able to - start from prerequisites that might not still hold at the completion - of some other concurrent UPDATE. Finally, if two UPDATE transactions - would modify the same names, RRs or RRsets, then such UPDATE - transactions must be serialized. - - 3.8 - Response - - At the end of UPDATE processing, a response code will be known. A - response message is generated by copying the ID and Opcode fields - from the request, and either copying the ZOCOUNT, PRCOUNT, UPCOUNT, - and ADCOUNT fields and associated sections, or placing zeros (0) in - the these "count" fields and not including any part of the original - update. The QR bit is set to one (1), and the response is sent back - to the requestor. If the requestor used UDP, then the response will - be sent to the requestor's source UDP port. If the requestor used - TCP, then the response will be sent back on the requestor's open TCP - connection. - -4 - Requestor Behaviour - - 4.1. From a requestor's point of view, any authoritative server for - the zone can appear to be able to process update requests, even - though only the primary master server is actually able to modify the - zone's master file. Requestors are expected to know the name of the - zone they intend to update and to know or be able to determine the - name servers for that zone. - - - - - - - - - -Vixie, et. al. Standards Track [Page 17] - -RFC 2136 DNS Update April 1997 - - - 4.2. If update ordering is desired, the requestor will need to know - the value of the existing SOA RR. Requestors who update the SOA RR - must update the SOA SERIAL field in a positive direction (as defined - by [RFC1982]) and also preserve the other SOA fields unless the - requestor's explicit intent is to change them. The SOA SERIAL field - must never be set to zero (0). - - 4.3. If the requestor has reasonable cause to believe that all of a - zone's servers will be equally reachable, then it should arrange to - try the primary master server (as given by the SOA MNAME field if - matched by some NS NSDNAME) first to avoid unnecessary forwarding - inside the slave servers. (Note that the primary master will in some - cases not be reachable by all requestors, due to firewalls or network - partitioning.) - - 4.4. Once the zone's name servers been found and possibly sorted so - that the ones more likely to be reachable and/or support the UPDATE - opcode are listed first, the requestor composes an UPDATE message of - the following form and sends it to the first name server on its list: - - ID: (new) - Opcode: UPDATE - Zone zcount: 1 - Zone zname: (zone name) - Zone zclass: (zone class) - Zone ztype: T_SOA - Prerequisite Section: (see previous text) - Update Section: (see previous text) - Additional Data Section: (empty) - - 4.5. If the requestor receives a response, and the response has an - RCODE other than SERVFAIL or NOTIMP, then the requestor returns an - appropriate response to its caller. - - 4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or - if no response is received within an implementation dependent timeout - period, or if an ICMP error is received indicating that the server's - port is unreachable, then the requestor will delete the unusable - server from its internal name server list and try the next one, - repeating until the name server list is empty. If the requestor runs - out of servers to try, an appropriate error will be returned to the - requestor's caller. - - - - - - - - - -Vixie, et. al. Standards Track [Page 18] - -RFC 2136 DNS Update April 1997 - - -5 - Duplicate Detection, Ordering and Mutual Exclusion - - 5.1. For correct operation, mechanisms may be needed to ensure - idempotence, order UPDATE requests and provide mutual exclusion. An - UPDATE message or response might be delivered zero times, one time, - or multiple times. Datagram duplication is of particular interest - since it covers the case of the so-called "replay attack" where a - correct request is duplicated maliciously by an intruder. - - 5.2. Multiple UPDATE requests or responses in transit might be - delivered in any order, due to network topology changes or load - balancing, or to multipath forwarding graphs wherein several slave - servers all forward to the primary master. In some cases, it might - be required that the earlier update not be applied after the later - update, where "earlier" and "later" are defined by an external time - base visible to some set of requestors, rather than by the order of - request receipt at the primary master. - - 5.3. A requestor can ensure transaction idempotence by explicitly - deleting some "marker RR" (rather than deleting the RRset of which it - is a part) and then adding a new "marker RR" with a different RDATA - field. The Prerequisite Section should specify that the original - "marker RR" must be present in order for this UPDATE message to be - accepted by the server. - - 5.4. If the request is duplicated by a network error, all duplicate - requests will fail since only the first will find the original - "marker RR" present and having its known previous value. The - decisions of whether to use such a "marker RR" and what RR to use are - left up to the application programmer, though one obvious choice is - the zone's SOA RR as described below. - - 5.5. Requestors can ensure update ordering by externally - synchronizing their use of successive values of the "marker RR." - Mutual exclusion can be addressed as a degenerate case, in that a - single succession of the "marker RR" is all that is needed. - - 5.6. A special case where update ordering and datagram duplication - intersect is when an RR validly changes to some new value and then - back to its previous value. Without a "marker RR" as described - above, this sequence of updates can leave the zone in an undefined - state if datagrams are duplicated. - - 5.7. To achieve an atomic multitransaction "read-modify-write" cycle, - a requestor could first retrieve the SOA RR, and build an UPDATE - message one of whose prerequisites was the old SOA RR. It would then - specify updates that would delete this SOA RR and add a new one with - an incremented SOA SERIAL, along with whatever actual prerequisites - - - -Vixie, et. al. Standards Track [Page 19] - -RFC 2136 DNS Update April 1997 - - - and updates were the object of the transaction. If the transaction - succeeds, the requestor knows that the RRs being changed were not - otherwise altered by any other requestor. - -6 - Forwarding - - When a zone slave forwards an UPDATE message upward toward the zone's - primary master server, it must allocate a new ID and prepare to enter - the role of "forwarding server," which is a requestor with respect to - the forward server. - - 6.1. The set of forward servers will be same as the set of servers - this zone slave would use as the source of AXFR or IXFR data. So, - while the original requestor might have used the zone's NS RRset to - locate its update server, a forwarder always forwards toward its - designated zone master servers. - - 6.2. If the original requestor used TCP, then the TCP connection from - the requestor is still open and the forwarder must use TCP to forward - the message. If the original requestor used UDP, the forwarder may - use either UDP or TCP to forward the message, at the whim of the - implementor. - - 6.3. It is reasonable for forward servers to be forwarders - themselves, if the AXFR dependency graph being followed is a deep one - involving firewalls and multiple connectivity realms. In most cases - the AXFR dependency graph will be shallow and the forward server will - be the primary master server. - - 6.4. The forwarder will not respond to its requestor until it - receives a response from its forward server. UPDATE transactions - involving forwarders are therefore time synchronized with respect to - the original requestor and the primary master server. - - 6.5. When there are multiple possible sources of AXFR data and - therefore multiple possible forward servers, a forwarder will use the - same fallback strategy with respect to connectivity or timeout errors - that it would use when performing an AXFR. This is implementation - dependent. - - 6.6. When a forwarder receives a response from a forward server, it - copies this response into a new response message, assigns its - requestor's ID to that message, and sends the response back to the - requestor. - - - - - - - -Vixie, et. al. Standards Track [Page 20] - -RFC 2136 DNS Update April 1997 - - -7 - Design, Implementation, Operation, and Protocol Notes - - Some of the principles which guided the design of this UPDATE - specification are as follows. Note that these are not part of the - formal specification and any disagreement between this section and - any other section of this document should be resolved in favour of - the other section. - - 7.1. Using metavalues for CLASS is possible only because all RRs in - the packet are assumed to be in the same zone, and CLASS is an - attribute of a zone rather than of an RRset. (It is for this reason - that the Zone Section is not optional.) - - 7.2. Since there are no data-present or data-absent errors possible - from processing the Update Section, any necessary data-present and - data- absent dependencies should be specified in the Prerequisite - Section. - - 7.3. The Additional Data Section can be used to supply a server with - out of zone glue that will be needed in referrals. For example, if - adding a new NS RR to HOME.VIX.COM specifying a nameserver called - NS.AU.OZ, the A RR for NS.AU.OZ can be included in the Additional - Data Section. Servers can use this information or ignore it, at the - discretion of the implementor. We discourage caching this - information for use in subsequent DNS responses. - - 7.4. The Additional Data Section might be used if some of the RRs - later needed for Secure DNS Update are not actually zone updates, but - rather ancillary keys or signatures not intended to be stored in the - zone (as an update would be), yet necessary for validating the update - operation. - - 7.5. It is expected that in the absence of Secure DNS Update, a - server will only accept updates if they come from a source address - that has been statically configured in the server's description of a - primary master zone. DHCP servers would be likely candidates for - inclusion in this statically configured list. - - 7.6. It is not possible to create a zone using this protocol, since - there is no provision for a slave server to be told who its master - servers are. It is expected that this protocol will be extended in - the future to cover this case. Therefore, at this time, the addition - of SOA RRs is unsupported. For similar reasons, deletion of SOA RRs - is also unsupported. - - - - - - - -Vixie, et. al. Standards Track [Page 21] - -RFC 2136 DNS Update April 1997 - - - 7.7. The prerequisite for specifying that a name own at least one RR - differs semantically from QUERY, in that QUERY would return - <NOERROR,ANCOUNT=0> rather than NXDOMAIN if queried for an RRset at - this name, while UPDATE's prerequisite condition [Section 2.4.4] - would NOT be satisfied. - - 7.8. It is possible for a UDP response to be lost in transit and for - a request to be retried due to a timeout condition. In this case an - UPDATE that was successful the first time it was received by the - primary master might ultimately appear to have failed when the - response to a duplicate request is finally received by the requestor. - (This is because the original prerequisites may no longer be - satisfied after the update has been applied.) For this reason, - requestors who require an accurate response code must use TCP. - - 7.9. Because a requestor who requires an accurate response code will - initiate their UPDATE transaction using TCP, a forwarder who receives - a request via TCP must forward it using TCP. - - 7.10. Deferral of SOA SERIAL autoincrements is made possible so that - serial numbers can be conserved and wraparound at 2**32 can be made - an infrequent occurance. Visible (to DNS clients) SOA SERIALs need - to differ if the zone differs. Note that the Authority Section SOA - in a QUERY response is a form of visibility, for the purposes of this - prerequisite. - - 7.11. A zone's SOA SERIAL should never be set to zero (0) due to - interoperability problems with some older but widely installed - implementations of DNS. When incrementing an SOA SERIAL, if the - result of the increment is zero (0) (as will be true when wrapping - around 2**32), it is necessary to increment it again or set it to one - (1). See [RFC1982] for more detail on this subject. - - 7.12. Due to the TTL minimalization necessary when caching an RRset, - it is recommended that all TTLs in an RRset be set to the same value. - While the DNS Message Format permits variant TTLs to exist in the - same RRset, and this variance can exist inside a zone, such variance - will have counterintuitive results and its use is discouraged. - - 7.13. Zone cut management presents some obscure corner cases to the - add and delete operations in the Update Section. It is possible to - delete an NS RR as long as it is not the last NS RR at the root of a - zone. If deleting all RRs from a name, SOA and NS RRs at the root of - a zone are unaffected. If deleting RRsets, it is not possible to - delete either SOA or NS RRsets at the top of a zone. An attempt to - add an SOA will be treated as a replace operation if an SOA already - exists, or as a no-op if the SOA would be new. - - - - -Vixie, et. al. Standards Track [Page 22] - -RFC 2136 DNS Update April 1997 - - - 7.14. No semantic checking is required in the primary master server - when adding new RRs. Therefore a requestor can cause CNAME or NS or - any other kind of RR to be added even if their target name does not - exist or does not have the proper RRsets to make the original RR - useful. Primary master servers that DO implement this kind of - checking should take great care to avoid out-of-zone dependencies - (whose veracity cannot be authoritatively checked) and should - implement all such checking during the prescan phase. - - 7.15. Nonterminal or wildcard CNAMEs are not well specified by - [RFC1035] and their use will probably lead to unpredictable results. - Their use is discouraged. - - 7.16. Empty nonterminals (nodes with children but no RRs of their - own) will cause <NOERROR,ANCOUNT=0> responses to be sent in response - to a query of any type for that name. There is no provision for - empty terminal nodes -- so if all RRs of a terminal node are deleted, - the name is no longer in use, and queries of any type for that name - will result in an NXDOMAIN response. - - 7.17. In a deep AXFR dependency graph, it has not historically been - an error for slaves to depend mutually upon each other. This - configuration has been used to enable a zone to flow from the primary - master to all slaves even though not all slaves have continuous - connectivity to the primary master. UPDATE's use of the AXFR - dependency graph for forwarding prohibits this kind of dependency - loop, since UPDATE forwarding has no loop detection analagous to the - SOA SERIAL pretest used by AXFR. - - 7.18. Previously existing names which are occluded by a new zone cut - are still considered part of the parent zone, for the purposes of - zone transfers, even though queries for such names will be referred - to the new subzone's servers. If a zone cut is removed, all parent - zone names that were occluded by it will again become visible to - queries. (This is a clarification of [RFC1034].) - - 7.19. If a server is authoritative for both a zone and its child, - then queries for names at the zone cut between them will be answered - authoritatively using only data from the child zone. (This is a - clarification of [RFC1034].) - - - - - - - - - - - -Vixie, et. al. Standards Track [Page 23] - -RFC 2136 DNS Update April 1997 - - - 7.20. Update ordering using the SOA RR is problematic since there is - no way to know which of a zone's NS RRs represents the primary - master, and the zone slaves can be out of date if their SOA.REFRESH - timers have not elapsed since the last time the zone was changed on - the primary master. We recommend that a zone needing ordered updates - use only servers which implement NOTIFY (see [RFC1996]) and IXFR (see - [RFC1995]), and that a client receiving a prerequisite error while - attempting an ordered update simply retry after a random delay period - to allow the zone to settle. - -8 - Security Considerations - - 8.1. In the absence of [RFC2137] or equivilent technology, the - protocol described by this document makes it possible for anyone who - can reach an authoritative name server to alter the contents of any - zones on that server. This is a serious increase in vulnerability - from the current technology. Therefore it is very strongly - recommended that the protocols described in this document not be used - without [RFC2137] or other equivalently strong security measures, - e.g. IPsec. - - 8.2. A denial of service attack can be launched by flooding an update - forwarder with TCP sessions containing updates that the primary - master server will ultimately refuse due to permission problems. - This arises due to the requirement that an update forwarder receiving - a request via TCP use a synchronous TCP session for its forwarding - operation. The connection management mechanisms of [RFC1035 4.2.2] - are sufficient to prevent large scale damage from such an attack, but - not to prevent some queries from going unanswered during the attack. - -Acknowledgements - - We would like to thank the IETF DNSIND working group for their input - and assistance, in particular, Rob Austein, Randy Bush, Donald - Eastlake, Masataka Ohta, Mark Andrews, and Robert Elz. Special - thanks to Bill Simpson, Ken Wallich and Bob Halley for reviewing this - document. - - - - - - - - - - - - - - -Vixie, et. al. Standards Track [Page 24] - -RFC 2136 DNS Update April 1997 - - -References - - [RFC1035] - Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, USC/Information Sciences - Institute, November 1987. - - [RFC1982] - Elz, R., "Serial Number Arithmetic", RFC 1982, University of - Melbourne, August 1996. - - [RFC1995] - Ohta, M., "Incremental Zone Transfer", RFC 1995, Tokyo Institute - of Technology, August 1996. - - [RFC1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone Changes", - RFC 1996, Internet Software Consortium, August 1996. - - [RFC2065] - Eastlake, D., and C. Kaufman, "Domain Name System Protocol - Security Extensions", RFC 2065, January 1997. - - [RFC2137] - Eastlake, D., "Secure Domain Name System Dynamic Update", RFC - 2137, April 1997. - -Authors' Addresses - - Yakov Rekhter - Cisco Systems - 170 West Tasman Drive - San Jose, CA 95134-1706 - - Phone: +1 914 528 0090 - EMail: yakov@cisco.com - - - Susan Thomson - Bellcore - 445 South Street - Morristown, NJ 07960 - - Phone: +1 201 829 4514 - EMail: set@thumper.bellcore.com - - - - - - -Vixie, et. al. Standards Track [Page 25] - -RFC 2136 DNS Update April 1997 - - - Jim Bound - Digital Equipment Corp. - 110 Spitbrook Rd ZK3-3/U14 - Nashua, NH 03062-2698 - - Phone: +1 603 881 0400 - EMail: bound@zk3.dec.com - - - Paul Vixie - Internet Software Consortium - Star Route Box 159A - Woodside, CA 94062 - - Phone: +1 415 747 0204 - EMail: paul@vix.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Vixie, et. al. Standards Track [Page 26] - - diff --git a/contrib/bind9/doc/rfc/rfc2137.txt b/contrib/bind9/doc/rfc/rfc2137.txt deleted file mode 100644 index ceb3613dde7d..000000000000 --- a/contrib/bind9/doc/rfc/rfc2137.txt +++ /dev/null @@ -1,619 +0,0 @@ - - - - - - -Network Working Group D. Eastlake 3rd -Request for Comments: 2137 CyberCash, Inc. -Updates: 1035 April 1997 -Category: Standards Track - - - Secure Domain Name System Dynamic Update - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - Domain Name System (DNS) protocol extensions have been defined to - authenticate the data in DNS and provide key distribution services - [RFC2065]. DNS Dynamic Update operations have also been defined - [RFC2136], but without a detailed description of security for the - update operation. This memo describes how to use DNSSEC digital - signatures covering requests and data to secure updates and restrict - updates to those authorized to perform them as indicated by the - updater's possession of cryptographic keys. - -Acknowledgements - - The contributions of the following persons (who are listed in - alphabetic order) to this memo are gratefully acknowledged: - - Olafur Gudmundsson (ogud@tis.com> - Charlie Kaufman <Charlie_Kaufman@iris.com> - Stuart Kwan <skwan@microsoft.com> - Edward Lewis <lewis@tis.com> - -Table of Contents - - 1. Introduction............................................2 - 1.1 Overview of DNS Dynamic Update.........................2 - 1.2 Overview of DNS Security...............................2 - 2. Two Basic Modes.........................................3 - 3. Keys....................................................5 - 3.1 Update Keys............................................6 - 3.1.1 Update Key Name Scope................................6 - 3.1.2 Update Key Class Scope...............................6 - 3.1.3 Update Key Signatory Field...........................6 - - - -Eastlake Standards Track [Page 1] - -RFC 2137 SDNSDU April 1997 - - - 3.2 Zone Keys and Update Modes.............................8 - 3.3 Wildcard Key Punch Through.............................9 - 4. Update Signatures.......................................9 - 4.1 Update Request Signatures..............................9 - 4.2 Update Data Signatures................................10 - 5. Security Considerations................................10 - References................................................10 - Author's Address..........................................11 - -1. Introduction - - Dynamic update operations have been defined for the Domain Name - System (DNS) in RFC 2136, but without a detailed description of - security for those updates. Means of securing the DNS and using it - for key distribution have been defined in RFC 2065. - - This memo proposes techniques based on the defined DNS security - mechanisms to authenticate DNS updates. - - Familiarity with the DNS system [RFC 1034, 1035] is assumed. - Familiarity with the DNS security and dynamic update proposals will - be helpful. - -1.1 Overview of DNS Dynamic Update - - DNS dynamic update defines a new DNS opcode, new DNS request and - response structure if that opcode is used, and new error codes. An - update can specify complex combinations of deletion and insertion - (with or without pre-existence testing) of resource records (RRs) - with one or more owner names; however, all testing and changes for - any particular DNS update request are restricted to a single zone. - Updates occur at the primary server for a zone. - - The primary server for a secure dynamic zone must increment the zone - SOA serial number when an update occurs or the next time the SOA is - retrieved if one or more updates have occurred since the previous SOA - retrieval and the updates themselves did not update the SOA. - -1.2 Overview of DNS Security - - DNS security authenticates data in the DNS by also storing digital - signatures in the DNS as SIG resource records (RRs). A SIG RR - provides a digital signature on the set of all RRs with the same - owner name and class as the SIG and whose type is the type covered by - the SIG. The SIG RR cryptographically binds the covered RR set to - the signer, time signed, signature expiration date, etc. There are - one or more keys associated with every secure zone and all data in - the secure zone is signed either by a zone key or by a dynamic update - - - -Eastlake Standards Track [Page 2] - -RFC 2137 SDNSDU April 1997 - - - key tracing its authority to a zone key. - - DNS security also defines transaction SIGs and request SIGs. - Transaction SIGs appear at the end of a response. Transaction SIGs - authenticate the response and bind it to the corresponding request - with the key of the host where the responding DNS server is. Request - SIGs appear at the end of a request and authenticate the request with - the key of the submitting entity. - - Request SIGs are the primary means of authenticating update requests. - - DNS security also permits the storage of public keys in the DNS via - KEY RRs. These KEY RRs are also, of course, authenticated by SIG - RRs. KEY RRs for zones are stored in their superzone and subzone - servers, if any, so that the secure DNS tree of zones can be - traversed by a security aware resolver. - -2. Two Basic Modes - - A dynamic secure zone is any secure DNS zone containing one or more - KEY RRs that can authorize dynamic updates, i.e., entity or user KEY - RRs with the signatory field non-zero, and whose zone KEY RR - signatory field indicates that updates are implemented. There are two - basic modes of dynamic secure zone which relate to the update - strategy, mode A and mode B. A summary comparison table is given - below and then each mode is described. - - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake Standards Track [Page 3] - -RFC 2137 SDNSDU April 1997 - - - SUMMARY OF DYNAMIC SECURE ZONE MODES - - CRITERIA: | MODE A | MODE B - =========================+====================+=================== - Definition: | Zone Key Off line | Zone Key On line - =========================+====================+=================== - Server Workload | Low | High - -------------------------+--------------------+------------------- - Static Data Security | Very High | Medium-High - -------------------------+--------------------+------------------- - Dynamic Data Security | Medium | Medium-High - -------------------------+--------------------+------------------- - Key Restrictions | Fine grain | Coarse grain - -------------------------+--------------------+------------------- - Dynamic Data Temporality | Transient | Permanent - -------------------------+--------------------+------------------- - Dynamic Key Rollover | No | Yes - -------------------------+--------------------+------------------- - - For mode A, the zone owner key and static zone master file are always - kept off-line for maximum security of the static zone contents. - - As a consequence, any dynamicly added or changed RRs are signed in - the secure zone by their authorizing dynamic update key and they are - backed up, along with this SIG RR, in a separate online dynamic - master file. In this type of zone, server computation is minimized - since the server need only check signatures on the update data and - request, which have already been signed by the updater, generally a - much faster operation than signing data. However, the AXFR SIG and - NXT RRs which covers the zone under the zone key will not cover - dynamically added data. Thus, for type A dynamic secure zones, zone - transfer security is not automatically provided for dynamically added - RRs, where they could be omitted, and authentication is not provided - for the server denial of the existence of a dynamically added type. - Because the dynamicly added RRs retain their update KEY signed SIG, - finer grained control of updates can be implemented via bits in the - KEY RR signatory field. Because dynamic data is only stored in the - online dynamic master file and only authenticated by dynamic keys - which expire, updates are transient in nature. Key rollover for an - entity that can authorize dynamic updates is more cumbersome since - the authority of their key must be traceable to a zone key and so, in - general, they must securely communicate a new key to the zone - authority for manual transfer to the off line static master file. - NOTE: for this mode the zone SOA must be signed by a dynamic update - key and that private key must be kept on line so that the SOA can be - changed for updates. - - - - - -Eastlake Standards Track [Page 4] - -RFC 2137 SDNSDU April 1997 - - - For mode B, the zone owner key and master file are kept on-line at - the zone primary server. When authenticated updates succeed, SIGs - under the zone key for the resulting data (including the possible NXT - type bit map changes) are calculated and these SIG (and possible NXT) - changes are entered into the zone and the unified on-line master - file. (The zone transfer AXFR SIG may be recalculated for each - update or on demand when a zone transfer is requested and it is out - of date.) - - As a consequence, this mode requires considerably more computational - effort on the part of the server as the public/private keys are - generally arranged so that signing (calculating a SIG) is more effort - than verifying a signature. The security of static data in the zone - is decreased because the ultimate state of the static data being - served and the ultimate zone authority private key are all on-line on - the net. This means that if the primary server is subverted, false - data could be authenticated to secondaries and other - servers/resolvers. On the other hand, this mode of operation means - that data added dynamically is more secure than in mode A. Dynamic - data will be covered by the AXFR SIG and thus always protected during - zone transfers and will be included in NXT RRs so that it can be - falsely denied by a server only to the same extent that static data - can (i.e., if it is within a wild card scope). Because the zone key - is used to sign all the zone data, the information as to who - originated the current state of dynamic RR sets is lost, making - unavailable the effects of some of the update control bits in the KEY - RR signatory field. In addition, the incorporation of the updates - into the primary master file and their authentication by the zone key - makes then permanent in nature. Maintaining the zone key on-line - also means that dynamic update keys which are signed by the zone key - can be dynamically updated since the zone key is available to - dynamically sign new values. - - NOTE: The Mode A / Mode B distinction only effects the validation - and performance of update requests. It has no effect on retrievals. - One reasonable operational scheme may be to keep a mostly static main - zone operating in Mode A and have one or more dynamic subzones - operating in Mode B. - -3. Keys - - Dynamic update requests depend on update keys as described in section - 3.1 below. In addition, the zone secure dynamic update mode and - availability of some options is indicated in the zone key. Finally, - a special rule is used in searching for KEYs to validate updates as - described in section 3.3. - - - - - -Eastlake Standards Track [Page 5] - -RFC 2137 SDNSDU April 1997 - - -3.1 Update Keys - - All update requests to a secure zone must include signatures by one - or more key(s) that together can authorize that update. In order for - the Domain Name System (DNS) server receiving the request to confirm - this, the key or keys must be available to and authenticated by that - server as a specially flagged KEY Resource Record. - - The scope of authority of such keys is indicated by their KEY RR - owner name, class, and signatory field flags as described below. In - addition, such KEY RRs must be entity or user keys and not have the - authentication use prohibited bit on. All parts of the actual update - must be within the scope of at least one of the keys used for a - request SIG on the update request as described in section 4. - -3.1.1 Update Key Name Scope - - The owner name of any update authorizing KEY RR must (1) be the same - as the owner name of any RRs being added or deleted or (2) a wildcard - name including within its extended scope (see section 3.3) the name - of any RRs being added or deleted and those RRs must be in the same - zone. - -3.1.2 Update Key Class Scope - - The class of any update authorizing KEY RR must be the same as the - class of any RR's being added or deleted. - -3.1.3 Update Key Signatory Field - - The four bit "signatory field" (see RFC 2065) of any update - authorizing KEY RR must be non-zero. The bits have the meanings - described below for non-zone keys (see section 3.2 for zone type - keys). - - UPDATE KEY RR SIGNATORY FIELD BITS - - 0 1 2 3 - +-----------+-----------+-----------+-----------+ - | zone | strong | unique | general | - +-----------+-----------+-----------+-----------+ - - Bit 0, zone control - If nonzero, this key is authorized to attach, - detach, and move zones by creating and deleting NS, glue A, and - zone KEY RR(s). If zero, the key can not authorize any update - that would effect such RRs. This bit is meaningful for both - type A and type B dynamic secure zones. - - - - -Eastlake Standards Track [Page 6] - -RFC 2137 SDNSDU April 1997 - - - NOTE: do not confuse the "zone" signatory field bit with the - "zone" key type bit. - - Bit 1, strong update - If nonzero, this key is authorized to add and - delete RRs even if there are other RRs with the same owner name - and class that are authenticated by a SIG signed with a - different dynamic update KEY. If zero, the key can only - authorize updates where any existing RRs of the same owner and - class are authenticated by a SIG using the same key. This bit - is meaningful only for type A dynamic zones and is ignored in - type B dynamic zones. - - Keeping this bit zero on multiple KEY RRs with the same or - nested wild card owner names permits multiple entities to exist - that can create and delete names but can not effect RRs with - different owner names from any they created. In effect, this - creates two levels of dynamic update key, strong and weak, where - weak keys are limited in interfering with each other but a - strong key can interfere with any weak keys or other strong - keys. - - Bit 2, unique name update - If nonzero, this key is authorized to add - and update RRs for only a single owner name. If there already - exist RRs with one or more names signed by this key, they may be - updated but no new name created until the number of existing - names is reduced to zero. This bit is meaningful only for mode - A dynamic zones and is ignored in mode B dynamic zones. This bit - is meaningful only if the owner name is a wildcard. (Any - dynamic update KEY with a non-wildcard name is, in effect, a - unique name update key.) - - This bit can be used to restrict a KEY from flooding a zone with - new names. In conjunction with a local administratively imposed - limit on the number of dynamic RRs with a particular name, it - can completely restrict a KEY from flooding a zone with RRs. - - Bit 3, general update - The general update signatory field bit has no - special meaning. If the other three bits are all zero, it must - be one so that the field is non-zero to designate that the key - is an update key. The meaning of all values of the signatory - field with the general bit and one or more other signatory field - bits on is reserved. - - All the signatory bit update authorizations described above only - apply if the update is within the name and class scope as per - sections 3.1.1 and 3.1.2. - - - - - -Eastlake Standards Track [Page 7] - -RFC 2137 SDNSDU April 1997 - - -3.2 Zone Keys and Update Modes - - Zone type keys are automatically authorized to sign anything in their - zone, of course, regardless of the value of their signatory field. - For zone keys, the signatory field bits have different means than - they they do for update keys, as shown below. The signatory field - MUST be zero if dynamic update is not supported for a zone and MUST - be non-zero if it is. - - ZONE KEY RR SIGNATORY FIELD BITS - - 0 1 2 3 - +-----------+-----------+-----------+-----------+ - | mode | strong | unique | general | - +-----------+-----------+-----------+-----------+ - - Bit 0, mode - This bit indicates the update mode for this zone. Zero - indicates mode A while a one indicates mode B. - - Bit 1, strong update - If nonzero, this indicates that the "strong" - key feature described in section 3.1.3 above is implemented and - enabled for this secure zone. If zero, the feature is not - available. Has no effect if the zone is a mode B secure update - zone. - - Bit 2, unique name update - If nonzero, this indicates that the - "unique name" feature described in section 3.1.3 above is - implemented and enabled for this secure zone. If zero, this - feature is not available. Has no effect if the zone is a mode B - secure update zone. - - Bit 3, general - This bit has no special meeting. If dynamic update - for a zone is supported and the other bits in the zone key - signatory field are zero, it must be a one. The meaning of zone - keys where the signatory field has the general bit and one or - more other bits on is reserved. - - If there are multiple dynamic update KEY RRs for a zone and zone - policy is in transition, they might have different non-zero signatory - fields. In that case, strong and unique name restrictions must be - enforced as long as there is a non-expired zone key being advertised - that indicates mode A with the strong or unique name bit on - respectively. Mode B updates MUST be supported as long as there is a - non-expired zone key that indicates mode B. Mode A updates may be - treated as mode B updates at server option if non-expired zone keys - indicate that both are supported. - - - - - -Eastlake Standards Track [Page 8] - -RFC 2137 SDNSDU April 1997 - - - A server that will be executing update operations on a zone, that is, - the primary master server, MUST not advertize a zone key that will - attract requests for a mode or features that it can not support. - -3.3 Wildcard Key Punch Through - - Just as a zone key is valid throughout the entire zone, update keys - with wildcard names are valid throughout their extended scope, within - the zone. That is, they remain valid for any name that would match - them, even existing specific names within their apparent scope. - - If this were not so, then whenever a name within a wildcard scope was - created by dynamic update, it would be necessary to first create a - copy of the KEY RR with this name, because otherwise the existence of - the more specific name would hide the authorizing KEY RR and would - make later updates impossible. An updater could create such a KEY RR - but could not zone sign it with their authorizing signer. They would - have to sign it with the same key using the wildcard name as signer. - Thus in creating, for example, one hundred type A RRs authorized by a - *.1.1.1.in-addr.arpa. KEY RR, without key punch through 100 As, 100 - KEYs, and 200 SIGs would have to be created as opposed to merely 100 - As and 100 SIGs with key punch through. - -4. Update Signatures - - Two kinds of signatures can appear in updates. Request signatures, - which are always required, cover the entire request and authenticate - the DNS header, including opcode, counts, etc., as well as the data. - Data signatures, on the other hand, appear only among the RRs to be - added and are only required for mode A operation. These two types of - signatures are described further below. - -4.1 Update Request Signatures - - An update can effect multiple owner names in a zone. It may be that - these different names are covered by different dynamic update keys. - For every owner name effected, the updater must know a private key - valid for that name (and the zone's class) and must prove this by - appending request SIG RRs under each such key. - - As specified in RFC 2065, a request signature is a SIG RR occurring - at the end of a request with a type covered field of zero. For an - update, request signatures occur in the Additional information - section. Each request SIG signs the entire request, including DNS - header, but excluding any other request SIG(s) and with the ARCOUNT - in the DNS header set to what it wold be without the request SIGs. - - - - - -Eastlake Standards Track [Page 9] - -RFC 2137 SDNSDU April 1997 - - -4.2 Update Data Signatures - - Mode A dynamic secure zones require that the update requester provide - SIG RRs that will authenticate the after update state of all RR sets - that are changed by the update and are non-empty after the update. - These SIG RRs appear in the request as RRs to be added and the - request must delete any previous data SIG RRs that are invalidated by - the request. - - In Mode B dynamic secure zones, all zone data is authenticated by - zone key SIG RRs. In this case, data signatures need not be included - with the update. A resolver can determine which mode an updatable - secure zone is using by examining the signatory field bits of the - zone KEY RR (see section 3.2). - -5. Security Considerations - - Any zone permitting dynamic updates is inherently less secure than a - static secure zone maintained off line as recommended in RFC 2065. If - nothing else, secure dynamic update requires on line change to and - re-signing of the zone SOA resource record (RR) to increase the SOA - serial number. This means that compromise of the primary server host - could lead to arbitrary serial number changes. - - Isolation of dynamic RRs to separate zones from those holding most - static RRs can limit the damage that could occur from breach of a - dynamic zone's security. - -References - - [RFC2065] Eastlake, D., and C. Kaufman, "Domain Name System Security - Extensions", RFC 2065, CyberCash, Iris, January 1997. - - [RFC2136] Vixie, P., Editor, Thomson, T., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specifications", STD 13, RFC 1035, November 1987. - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", - STD 13, RFC 1034, November 1987. - - - - - - - - - -Eastlake Standards Track [Page 10] - -RFC 2137 SDNSDU April 1997 - - -Author's Address - - Donald E. Eastlake, 3rd - CyberCash, Inc. - 318 Acton Street - Carlisle, MA 01741 USA - - Phone: +1 508-287-4877 - +1 508-371-7148 (fax) - +1 703-620-4200 (main office, Reston, Virginia, USA) - EMail: dee@cybercash.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake Standards Track [Page 11] - diff --git a/contrib/bind9/doc/rfc/rfc2163.txt b/contrib/bind9/doc/rfc/rfc2163.txt deleted file mode 100644 index 00fcee7c8843..000000000000 --- a/contrib/bind9/doc/rfc/rfc2163.txt +++ /dev/null @@ -1,1459 +0,0 @@ - - - - - - -Network Working Group C. Allocchio -Request for Comments: 2163 GARR-Italy -Obsoletes: 1664 January 1998 -Category: Standards Track - - - Using the Internet DNS to Distribute - MIXER Conformant Global Address Mapping (MCGAM) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -Abstract - - This memo is the complete technical specification to store in the - Internet Domain Name System (DNS) the mapping information (MCGAM) - needed by MIXER conformant e-mail gateways and other tools to map - RFC822 domain names into X.400 O/R names and vice versa. Mapping - information can be managed in a distributed rather than a centralised - way. Organizations can publish their MIXER mapping or preferred - gateway routing information using just local resources (their local - DNS server), avoiding the need for a strong coordination with any - centralised organization. MIXER conformant gateways and tools located - on Internet hosts can retrieve the mapping information querying the - DNS instead of having fixed tables which need to be centrally updated - and distributed. - - This memo obsoletes RFC1664. It includes the changes introduced by - MIXER specification with respect to RFC1327: the new 'gate1' (O/R - addresses to domain) table is fully supported. Full backward - compatibility with RFC1664 specification is mantained, too. - - RFC1664 was a joint effort of IETF X400 operation working group - (x400ops) and TERENA (formely named "RARE") Mail and Messaging - working group (WG-MSG). This update was performed by the IETF MIXER - working group. - - - - - - -Allocchio Standards Track [Page 1] - -RFC 2163 MIXER MCGAM January 1998 - - -1. Introduction - - The connectivity between the Internet SMTP mail and other mail - services, including the Internet X.400 mail and the commercial X.400 - service providers, is assured by the Mail eXchanger (MX) record - information distributed via the Internet Domain Name System (DNS). A - number of documents then specify in details how to convert or encode - addresses from/to RFC822 style to the other mail system syntax. - However, only conversion methods provide, via some algorithm or a set - of mapping rules, a smooth translation, resulting in addresses - indistinguishable from the native ones in both RFC822 and foreign - world. - - MIXER describes a set of mappings (MIXER Conformant Global Address - Mapping - MCGAM) which will enable interworking between systems - operating the CCITT X.400 (1984/88/92) Recommendations and systems - using using the RFC822 mail protocol, or protocols derived from - RFC822. That document addresses conversion of services, addresses, - message envelopes, and message bodies between the two mail systems. - This document is concerned with one aspect of MIXER: the mechanism - for mapping between X.400 O/R addresses and RFC822 domain names. As - described in Appendix F of MIXER, implementation of the mappings - requires a database which maps between X.400 O/R addresses and domain - names; in RFC1327 this database was statically defined. - - The original approach in RFC1327 required many efforts to maintain - the correct mapping: all the gateways needed to get coherent tables - to apply the same mappings, the conversion tables had to be - distributed among all the operational gateways, and also every update - needed to be distributed. - - The concept of mapping rules distribution and use has been revised in - the new MIXER specification, introducing the concept of MIXER - Conformant Global Address Mapping (MCGAM). A MCGAM does not need to - be globally installed by any MIXER conformant gateway in the world - any more. However MIXER requires now efficient methods to publish its - MCGAM. - - Static tables are one of the possible methods to publish MCGAM. - However this static mechanism requires quite a long time to be spent - modifying and distributing the information, putting heavy constraints - on the time schedule of every update. In fact it does not appear - efficient compared to the Internet Domain Name Service (DNS). More - over it does not look feasible to distribute the database to a large - number of other useful applications, like local address converters, - e-mail User Agents or any other tool requiring the mapping rules to - produce correct results. - - - - -Allocchio Standards Track [Page 2] - -RFC 2163 MIXER MCGAM January 1998 - - - Two much more efficient methods are proposed by MIXER for publication - of MCGAM: the Internet DNS and X.500. This memo is the complete - technical specification for publishing MCGAM via Internet DNS. - - A first proposal to use the Internet DNS to store, retrieve and - maintain those mappings was introduced by two of the authors of - RFC1664 (B. Cole and R. Hagens) adopting two new DNS resource record - (RR) types: TO-X400 and TO-822. This proposal now adopts a more - complete strategy, and requires one new RR only. The distribution of - MCGAMs via DNS is in fact an important service for the whole Internet - community: it completes the information given by MX resource record - and it allows to produce clean addresses when messages are exchanged - among the Internet RFC822 world and the X.400 one (both Internet and - Public X.400 service providers). - - A first experiment in using the DNS without expanding the current set - of RR and using available ones was deployed by some of the authors of - RFC1664 at the time of its development. The existing PTR resource - records were used to store the mapping rules, and a new DNS tree was - created under the ".it" top level domain. The result of the - experiment was positive, and a few test applications ran under this - provisional set up. This test was also very useful in order to define - a possible migration strategy during the deployment of the new DNS - containing the new RR. The Internet DNS nameservers wishing to - provide this mapping information need in fact to be modified to - support the new RR type, and in the real Internet, due to the large - number of different implementations, this takes some time. - - The basic idea is to adopt a new DNS RR to store the mapping - information. The RFC822 to X.400 mapping rules (including the so - called 'gate2' rules) will be stored in the ordinary DNS tree, while - the definition of a new branch of the name space defined under each - national top level domain is envisaged in order to contain the X.400 - to RFC822 mappings ('table1' and 'gate1'). A "two-way" mapping - resolution schema is thus fully implemented. - - The creation of the new domain name space representing the X.400 O/R - names structure also provides the chance to use the DNS to distribute - dynamically other X.400 related information, thus solving other - efficiency problems currently affecting the X.400 MHS service. - - In this paper we will adopt the MCGAM syntax, showing how it can be - stored into the Internet DNS. - - - - - - - - -Allocchio Standards Track [Page 3] - -RFC 2163 MIXER MCGAM January 1998 - - -1.1 Definitions syntax - - The definitions in this document is given in BNF-like syntax, using - the following conventions: - - | means choice - \ is used for continuation of a definition over several lines - [] means optional - {} means repeated one or more times - - The definitions, however, are detailed only until a certain level, - and below it self-explaining character text strings will be used. - -2. Motivation - - Implementations of MIXER gateways require that a database store - address mapping information for X.400 and RFC822. This information - must be made available (published) to all MIXER gateways. In the - Internet community, the DNS has proven to be a practical mean for - providing a distributed name service. Advantages of using a DNS based - system over a table based approach for mapping between O/R addresses - and domain names are: - - - It avoids fetching and storing of entire mapping tables by every - host that wishes to implement MIXER gateways and/or tools - - - Modifications to the DNS based mapping information can be made - available in a more timely manner than with a table driven - approach. - - - It allows full authority delegation, in agreement with the - Internet regionalization process. - - - Table management is not necessarily required for DNS-based - MIXER gateways. - - - One can determine the mappings in use by a remote gateway by - querying the DNS (remote debugging). - - Also many other tools, like address converters and User Agents can - take advantage of the real-time availability of MIXER tables, - allowing a much easier maintenance of the information. - -3. The domain space for X.400 O/R name addresses - - Usual domain names (the ones normally used as the global part of an - RFC822 e-mail address) and their associated information, i.e., host - IP addresses, mail exchanger names, etc., are stored in the DNS as a - - - -Allocchio Standards Track [Page 4] - -RFC 2163 MIXER MCGAM January 1998 - - - distributed database under a number of top-level domains. Some top- - level domains are used for traditional categories or international - organisations (EDU, COM, NET, ORG, INT, MIL...). On the other hand - any country has its own two letter ISO country code as top-level - domain (FR, DE, GB, IT, RU, ...), including "US" for USA. The - special top-level/second-level couple IN-ADDR.ARPA is used to store - the IP address to domain name relationship. This memo defines in the - above structure the appropriate way to locate the X.400 O/R name - space, thus enabling to store in DNS the MIXER mappings (MCGAMs). - - The MIXER mapping information is composed by four tables: - - - 'table1' and 'gate1' gives the translation from X.400 to RFC822; - - 'table2' and 'gate2' tables map RFC822 into X.400. - - Each mapping table is composed by mapping rules, and a single mapping - rule is composed by a keyword (the argument of the mapping function - derived from the address to be translated) and a translator (the - mapping function parameter): - - keyword#translator# - - the '#' sign is a delimiter enclosing the translator. An example: - - foo.bar.us#PRMD$foo\.bar.ADMD$intx.C$us# - - Local mappings are not intended for use outside their restricted - environment, thus they should not be included in DNS. If local - mappings are used, they should be stored using static local tables, - exactly as local static host tables can be used with DNS. - - The keyword of a 'table2' and 'gate2' table entry is a valid RFC822 - domain; thus the usual domain name space can be used without problems - to store these entries. - On the other hand, the keyword of a 'table1' and 'gate1' entry - belongs to the X.400 O/R name space. The X.400 O/R name space does - not usually fit into the usual domain name space, although there are - a number of similarities; a new name structure is thus needed to - represent it. This new name structure contains the X.400 mail - domains. - - To ensure the correct functioning of the DNS system, the new X.400 - name structure must be hooked to the existing domain name space in a - way which respects the existing name hierarchy. - - A possible solution was to create another special branch, starting - from the root of the DNS tree, somehow similar to the in-addr.arpa - tree. This idea would have required to establish a central authority - - - -Allocchio Standards Track [Page 5] - -RFC 2163 MIXER MCGAM January 1998 - - - to coordinate at international level the management of each national - X.400 name tree, including the X.400 public service providers. This - coordination problem is a heavy burden if approached globally. More - over the X.400 name structure is very 'country oriented': thus while - it requires a coordination at national level, it does not have - concepts like the international root. In fact the X.400 international - service is based on a large number of bilateral agreements, and only - within some communities an international coordination service exists. - - The X.400 two letter ISO country codes, however, are the same used - for the RFC822 country top-level domains and this gives us an - appropriate hook to insert the new branches. The proposal is, in - fact, to create under each national top level ISO country code a new - branch in the name space. This branch represents exactly the X.400 - O/R name structure as defined in each single country, following the - ADMD, PRMD, O, OU hierarchy. A unique reserved label 'X42D' is placed - under each country top-level domain, and hence the national X.400 - name space derives its own structure: - - . (root) - | - +-----------------+-----------+--------+-----------------+... - | | | | - edu it us fr - | | | | - +---+---+... +-----+-----+... +-----+-----+... +--+---+... - | | | | | | | | | | - ... ... cnr X42D infn va ca X42D X42D inria - | | | | - +------------+------------+... ... ... +----+-------+... - | | | | | - ADMD-PtPostel ADMD-garr ADMD-Master400 ADMD-atlas ADMD-red - | | | | - +----------+----+... ... +-------+------+... ... - | | | | - PRMD-infn PRMD-STET PRMD-Telecom PRMD-Renault - | | | | - ... ... ... ... - - - The creation of the X.400 new name tree at national level solves the - problem of the international coordination. Actually the coordination - problem is just moved at national level, but it thus becomes easier - to solve. The coordination at national level between the X.400 - communities and the Internet world is already a requirement for the - creation of the national static MIXER mapping tables; the use of the - Internet DNS gives further motivations for this coordination. - - - - -Allocchio Standards Track [Page 6] - -RFC 2163 MIXER MCGAM January 1998 - - - The coordination at national level also fits in the new concept of - MCGAM pubblication. The DNS in fact allows a step by step authority - distribution, up to a final complete delegation: thus organizations - whishing to publish their MCGAM just need to receive delegation also - for their branch of the new X.400 name space. A further advantage of - the national based solution is to allow each country to set up its - own X.400 name structure in DNS and to deploy its own authority - delegation according to its local time scale and requirements, with - no loss of global service in the mean time. And last, placing the new - X.400 name tree and coordination process at national level fits into - the Internet regionalization and internationalisation process, as it - requires local bodies to take care of local coordination problems. - - The DNS name space thus contains completely the information required - by an e-mail gateway or tool to perform the X.400-RFC822 mapping: a - simple query to the nearest nameserver provides it. Moreover there is - no more any need to store, maintain and distribute manually any - mapping table. The new X.400 name space can also contain further - information about the X.400 community, as DNS allows for it a - complete set of resource records, and thus it allows further - developments. This set of RRs in the new X.400 name space must be - considered 'reserved' and thus not used until further specifications. - - The construction of the new domain space trees will follow the same - procedures used when organising at first the already existing DNS - space: at first the information will be stored in a quite centralised - way, and distribution of authority will be gradually achieved. A - separate document will describe the implementation phase and the - methods to assure a smooth introduction of the new service. - -4. The new DNS resource record for MIXER mapping rules: PX - - The specification of the Internet DNS (RFC1035) provides a number of - specific resource records (RRs) to contain specific pieces of - information. In particular they contain the Mail eXchanger (MX) RR - and the host Address (A) records which are used by the Internet SMTP - mailers. As we will store the RFC822 to X.400 mapping information in - the already existing DNS name tree, we need to define a new DNS RR in - order to avoid any possible clash or misuse of already existing data - structures. The same new RR will also be used to store the mappings - from X.400 to RFC822. More over the mapping information, i.e., the - MCGAMs, has a specific format and syntax which require an appropriate - data structure and processing. A further advantage of defining a new - RR is the ability to include flexibility for some eventual future - development. - - - - - - -Allocchio Standards Track [Page 7] - -RFC 2163 MIXER MCGAM January 1998 - - - The definition of the new 'PX' DNS resource record is: - - class: IN (Internet) - - name: PX (pointer to X.400/RFC822 mapping information) - - value: 26 - - The PX RDATA format is: - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | PREFERENCE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / MAP822 / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / MAPX400 / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - where: - - PREFERENCE A 16 bit integer which specifies the preference given to - this RR among others at the same owner. Lower values - are preferred; - - MAP822 A <domain-name> element containing <rfc822-domain>, the - RFC822 part of the MCGAM; - - MAPX400 A <domain-name> element containing the value of - <x400-in-domain-syntax> derived from the X.400 part of - the MCGAM (see sect. 4.2); - - PX records cause no additional section processing. The PX RR format - is the usual one: - - <name> [<class>] [<TTL>] <type> <RDATA> - - When we store in DNS a 'table1' or a 'gate1' entry, then <name> will - be an X.400 mail domain name in DNS syntax (see sect. 4.2). When we - store a 'table2' or a 'gate2' table entry, <name> will be an RFC822 - mail domain name, including both fully qualified DNS domains and mail - only domains (MX-only domains). All normal DNS conventions, like - default values, wildcards, abbreviations and message compression, - apply also for all the components of the PX RR. In particular <name>, - MAP822 and MAPX400, as <domain-name> elements, must have the final - "." (root) when they are fully qualified. - - - - -Allocchio Standards Track [Page 8] - -RFC 2163 MIXER MCGAM January 1998 - - -4.1 Additional features of the PX resource record - - The definition of the RDATA for the PX resource record, and the fact - that DNS allows a distinction between an exact value and a wildcard - match for the <name> parameter, represent an extension of the MIXER - specification for mapping rules. In fact, any MCGAM entry is an - implicit wildcard entry, i.e., the rule - - net2.it#PRMD$net2.ADMD$p400.C$it# - - covers any RFC822 domain ending with 'net2.it', unless more detailed - rules for some subdomain in 'net2.it' are present. Thus there is no - possibility to specify explicitly a MCGAM as an exact match only - rule. In DNS an entry like - - *.net2.it. IN PX 10 net2.it. PRMD-net2.ADMD-p400.C-it. - - specify the usual wildcard match as for MIXER tables. However an - entry like - - ab.net2.it. IN PX 10 ab.net2.it. O-ab.PRMD-net2.ADMDb.C-it. - - is valid only for an exact match of 'ab.net2.it' RFC822 domain. - - Note also that in DNS syntax there is no '#' delimiter around MAP822 - and MAPX400 fields: the syntax defined in sect. 4.2 in fact does not - allow the <blank> (ASCII decimal 32) character within these fields, - making unneeded the use of an explicit delimiter as required in the - MIXER original syntax. - - Another extension to the MIXER specifications is the PREFERENCE value - defined as part of the PX RDATA section. This numeric value has - exactly the same meaning than the similar one used for the MX RR. It - is thus possible to specify more than one single mapping for a domain - (both from RFC822 to X.400 and vice versa), giving as the preference - order. In MIXER static tables, however, you cannot specify more than - one mapping per each RFC822 domain, and the same restriction apply - for any X.400 domain mapping to an RFC822 one. - - More over, in the X.400 recommendations a note suggests than an - ADMD=<blank> should be reserved for some special cases. Various - national functional profile specifications for an X.400 MHS states - that if an X.400 PRMD is reachable via any of its national ADMDs, - independently of its actual single or multiple connectivity with - them, it should use ADMD=<blank> to advertise this fact. Again, if a - PRMD has no connections to any ADMD it should use ADMD=0 to notify - its status, etc. However, in most of the current real situations, the - ADMD service providers do not accept messages coming from their - - - -Allocchio Standards Track [Page 9] - -RFC 2163 MIXER MCGAM January 1998 - - - subscribers if they have a blank ADMD, forcing them to have their own - ADMD value. In such a situation there are problems in indicating - properly the actually working mappings for domains with multiple - connectivity. The PX RDATA 'PREFERENCE' extension was introduced to - take in consideration these problems. - - However, as these extensions are not available with MIXER static - tables, it is strongly discouraged to use them when interworking with - any table based gateway or application. The extensions were in fact - introduced just to add more flexibility, like the PREFERENCE value, - or they were already implicit in the DNS mechanism, like the - wildcard specification. They should be used very carefully or just - considered 'reserved for future use'. In particular, for current use, - the PREFERENCE value in the PX record specification should be fixed - to a value of 50, and only wildcard specifications should be used - when specifying <name> values. - -4.2 The DNS syntax for an X.400 'domain' - - The syntax definition of the MCGAM rules is defined in appendix F of - that document. However that syntax is not very human oriented and - contains a number of characters which have a special meaning in other - fields of the Internet DNS. Thus in order to avoid any possible - problem, especially due to some old DNS implementations still being - used in the Internet, we define a syntax for the X.400 part of any - MCGAM rules (and hence for any X.400 O/R name) which makes it - compatible with a <domain-name> element, i.e., - - <domain-name> ::= <subdomain> | " " - <subdomain> ::= <label> | <label> "." <subdomain> - <label> ::= <alphanum>| - <alphanum> {<alphanumhyphen>} <alphanum> - <alphanum> ::= "0".."9" | "A".."Z" | "a".."z" - <alphanumhyphen> ::= "0".."9" | "A".."Z" | "a".."z" | "-" - - (see RFC1035, section 2.3.1, page 8). The legal character set for - <label> does not correspond to the IA5 Printablestring one used in - MIXER to define MCGAM rules. However a very simple "escape mechanism" - can be applied in order to bypass the problem. We can in fact simply - describe the X.400 part of a MCGAM rule format as: - - <map-rule> ::= <map-elem> | <map-elem> { "." <map-elem> } - <map-elem> ::= <attr-label> "$" <attr-value> - <attr-label> ::= "C" | "ADMD" | "PRMD" | "O" | "OU" - <attr-value> ::= " " | "@" | IA5-Printablestring - - - - - - -Allocchio Standards Track [Page 10] - -RFC 2163 MIXER MCGAM January 1998 - - - As you can notice <domain-name> and <map-rule> look similar, and also - <label> and <map-elem> look the same. If we define the correct method - to transform a <map-elem> into a <label> and vice versa the problem - to write a MCGAM rule in <domain-name> syntax is solved. - - The RFC822 domain part of any MCGAM rule is of course already in - <domain-name> syntax, and thus remains unchanged. - - In particular, in a 'table1' or 'gate1' mapping rule the 'keyword' - value must be converted into <x400-in-domain-syntax> (X.400 mail DNS - mail domain), while the 'translator' value is already a valid RFC822 - domain. Vice versa in a 'table2' or 'gate2' mapping rule, the - 'translator' must be converted into <x400-in-domain-syntax>, while - the 'keyword' is already a valid RFC822 domain. - -4.2.1 IA5-Printablestring to <alphanumhyphen> mappings - - The problem of unmatching IA5-Printablestring and <label> character - set definition is solved by a simple character mapping rule: whenever - an IA5 character does not belong to <alphanumhyphen>, then it is - mapped using its 3 digit decimal ASCII code, enclosed in hyphens. A - small set of special rules is also defined for the most frequent - cases. Moreover some frequent characters combinations used in MIXER - rules are also mapped as special cases. - - Let's then define the following simple rules: - - MCGAM rule DNS store translation conditions - ----------------------------------------------------------------- - <attr-label>$@ <attr-label> missing attribute - <attr-label>$<blank> <attr-label>"b" blank attribute - <attr-label>$xxx <attr-label>-xxx elsewhere - - Non <alphanumhyphen> characters in <attr-value>: - - MCGAM rule DNS store translation conditions - ----------------------------------------------------------------- - - -h- hyphen - \. -d- quoted dot - <blank> -b- blank - <non A/N character> -<3digit-decimal>- elsewhere - - If the DNS store translation of <attr-value> happens to end with an - hyphen, then this last hyphen is omitted. - - Let's now have some examples: - - - - - -Allocchio Standards Track [Page 11] - -RFC 2163 MIXER MCGAM January 1998 - - - MCGAM rule DNS store translation conditions - ----------------------------------------------------------------- - PRMD$@ PRMD missing attribute - ADMD$<blank> ADMDb blank attribute - ADMD$400-net ADMD-400-h-net hyphen mapping - PRMD$UK\.BD PRMD-UK-d-BD quoted dot mapping - O$ACME Inc\. O-ACME-b-Inc-d blank & final hyphen - PRMD$main-400-a PRMD-main-h-400-h-a hyphen mapping - O$-123-b O--h-123-h-b hyphen mapping - OU$123-x OU-123-h-x hyphen mapping - PRMD$Adis+co PRMD-Adis-043-co 3digit mapping - - Thus, an X.400 part from a MCGAM like - - OU$uuu.O$@.PRMD$ppp\.rrr.ADMD$aaa ddd-mmm.C$cc - - translates to - - OU-uuu.O.PRMD-ppp-d-rrr.ADMD-aaa-b-ddd-h-mmm.C-cc - - Another example: - - OU$sales dept\..O$@.PRMD$ACME.ADMD$ .C$GB - - translates to - - OU-sales-b-dept-d.O.PRMD-ACME.ADMDb.C-GB - -4.2.2 Flow chart - - In order to achieve the proper DNS store translations of the X.400 - part of a MCGAM or any other X.400 O/R name, some software tools will - be used. It is in fact evident that the above rules for converting - mapping table from MIXER to DNS format (and vice versa) are not user - friendly enough to think of a human made conversion. - - To help in designing such tools, we describe hereunder a small flow - chart. The fundamental rule to be applied during translation is, - however, the following: - - "A string must be parsed from left to right, moving appropriately - the pointer in order not to consider again the already translated - left section of the string in subsequent analysis." - - - - - - - - -Allocchio Standards Track [Page 12] - -RFC 2163 MIXER MCGAM January 1998 - - - Flow chart 1 - Translation from MIXER to DNS format: - - parse single attribute - (enclosed in "." separators) - | - (yes) --- <label>$@ ? --- (no) - | | - map to <label> (no) <label>$<blank> ? (yes) - | | | - | map to <label>- map to <label>"b" - | | | - | map "\." to -d- | - | | | - | map "-" to -h- | - | | | - | map non A/N char to -<3digit>- | - restart | | | - ^ | remove (if any) last "-" | - | | | | - | \-------> add a "." <--------------/ - | | - \---------- take next attribute (if any) - - - Flow chart 2 - Translation from DNS to MIXER format: - - - parse single attribute - (enclosed in "." separators) - | - (yes) ---- <label> ? ---- (no) - | | - map to <label>$@ (no) <label>"b" ? (yes) - | | | - | map to <label>$ map to <label>$<blank> - | | | - | map -d- to "\." | - | | | - | map -h- to "-" | - | | | - | map -b- to " " | - restart | | | - ^ | map -<3digit>- to non A/N char | - | | | | - | \--------> add a "." <----------/ - | | - \------------- take next attribute (if any) - - - - -Allocchio Standards Track [Page 13] - -RFC 2163 MIXER MCGAM January 1998 - - - Note that the above flow charts deal with the translation of the - attributes syntax, only. - -4.2.3 The Country Code convention in the <name> value. - - The RFC822 domain space and the X.400 O/R address space, as said in - section 3, have one specific common feature: the X.400 ISO country - codes are the same as the RFC822 ISO top level domains for countries. - In the previous sections we have also defined a method to write in - <domain-name> syntax any X.400 domain, while in section 3 we - described the new name space starting at each country top level - domain under the X42D.cc (where 'cc' is then two letter ISO country - code). - - The <name> value for a 'table1' or 'gate1' entry in DNS should thus - be derived from the X.400 domain value, translated to <domain-name> - syntax, adding the 'X42D.cc.' post-fix to it, i.e., - - ADMD$acme.C$fr - - produces in <domain-name> syntax the key: - - ADMD-acme.C-fr - - which is post-fixed by 'X42D.fr.' resulting in: - - ADMD-acme.C-fr.X42D.fr. - - However, due to the identical encoding for X.400 country codes and - RFC822 country top level domains, the string 'C-fr.X42D.fr.' is - clearly redundant. - - We thus define the 'Country Code convention' for the <name> key, - i.e., - - "The C-cc section of an X.400 domain in <domain-name> syntax must - be omitted when creating a <name> key, as it is identical to the - top level country code used to identify the DNS zone where the - information is stored". - - Thus we obtain the following <name> key examples: - - X.400 domain DNS <name> key - -------------------------------------------------------------------- - ADMD$acme.C$fr ADMD-acme.X42D.fr. - PRMD$ux\.av.ADMD$ .C$gb PRMD-ux-d-av.ADMDb.X42D.gb. - PRMD$ppb.ADMD$Dat 400.C$de PRMD-ppb.ADMD-Dat-b-400.X42D.de. - - - - -Allocchio Standards Track [Page 14] - -RFC 2163 MIXER MCGAM January 1998 - - -4.3 Creating the appropriate DNS files - - Using MIXER's assumption of an asymmetric mapping between X.400 and - RFC822 addresses, two separate relations are required to store the - mapping database: MIXER 'table1' and MIXER 'table2'; thus also in DNS - we will maintain the two different sections, even if they will both - use the PX resource record. More over MIXER also specify two - additional tables: MIXER 'gate1' and 'gate2' tables. These additional - tables, however, have the same syntax rules than MIXER 'table1' and - 'table2' respectively, and thus the same translation procedure as - 'table1' and 'table2' will be applied; some details about the MIXER - 'gate1' and 'gate2' tables are discussed in section 4.4. - - Let's now check how to create, from an MCGAM entry, the appropriate - DNS entry in a DNS data file. We can again define an MCGAM entry as - defined in appendix F of that document as: - - <x400-domain>#<rfc822-domain># (case A: 'table1' and 'gate1' - entry) - - and - - <rfc822-domain>#<x400-domain># (case B: 'table2' and 'gate2' - entry) - - The two cases must be considered separately. Let's consider case A. - - - take <x400-domain> and translate it into <domain-name> syntax, - obtaining <x400-in-domain-syntax>; - - create the <name> key from <x400-in-domain-syntax> i.e., apply - the Country Code convention described in sect. 4.2.3; - - construct the DNS PX record as: - - *.<name> IN PX 50 <rfc822-domain> <x400-in-domain-syntax> - - Please note that within PX RDATA the <rfc822-domain> precedes the - <x400-in-domain-syntax> also for a 'table1' and 'gate1' entry. - - an example: from the 'table1' rule - - PRMD$ab.ADMD$ac.C$fr#ab.fr# - - we obtain - - *.PRMD-ab.ADMD-ac.X42D.fr. IN PX 50 ab.fr. PRMD-ab.ADMD-ac.C-fr. - - Note that <name>, <rfc822-domain> and <x400-in-domain-syntax> are - fully qualified <domain-name> elements, thus ending with a ".". - - - -Allocchio Standards Track [Page 15] - -RFC 2163 MIXER MCGAM January 1998 - - - Let's now consider case B. - - - take <rfc822-domain> as <name> key; - - translate <x400-domain> into <x400-in-domain-syntax>; - - construct the DNS PX record as: - - *.<name> IN PX 50 <rfc822-domain> <x400-in-domain-syntax> - - an example: from the 'table2' rule - - ab.fr#PRMD$ab.ADMD$ac.C$fr# - - we obtain - - *.ab.fr. IN PX 50 ab.fr. PRMD-ab.ADMD-ac.C-fr. - - Again note the fully qualified <domain-name> elements. - - A file containing the MIXER mapping rules and MIXER 'gate1' and - 'gate2' table written in DNS format will look like the following - fictious example: - - ! - ! MIXER table 1: X.400 --> RFC822 - ! - *.ADMD-acme.X42D.it. IN PX 50 it. ADMD-acme.C-it. - *.PRMD-accred.ADMD-tx400.X42D.it. IN PX 50 \ - accred.it. PRMD-accred.ADMD-tx400.C-it. - *.O-u-h-newcity.PRMD-x4net.ADMDb.X42D.it. IN PX 50 \ - cs.ncty.it. O-u-h-newcity.PRMD-x4net.ADMDb.C-it. - ! - ! MIXER table 2: RFC822 --> X.400 - ! - *.nrc.it. IN PX 50 nrc.it. PRMD-nrc.ADMD-acme.C-it. - *.ninp.it. IN PX 50 ninp.it. O.PRMD-ninp.ADMD-acme.C-it. - *.bd.it. IN PX 50 bd.it. PRMD-uk-d-bd.ADMDb.C-it. - ! - ! MIXER Gate 1 Table - ! - *.ADMD-XKW-h-Mail.X42D.it. IN PX 50 \ - XKW-gateway.it. ADMD-XKW-h-Mail.C-it.G. - *.PRMD-Super-b-Inc.ADMDb.X42D.it. IN PX 50 \ - GlobalGw.it. PRMD-Super-b-Inc.ADMDb.C-it.G. - ! - ! MIXER Gate 2 Table - ! - my.it. IN PX 50 my.it. OU-int-h-gw.O.PRMD-ninp.ADMD-acme.C-it.G. - co.it. IN PX 50 co.it. O-mhs-h-relay.PRMD-x4net.ADMDb.C-it.G. - - - -Allocchio Standards Track [Page 16] - -RFC 2163 MIXER MCGAM January 1998 - - - (here the "\" indicates continuation on the same line, as wrapping is - done only due to typographical reasons). - - Note the special suffix ".G." on the right side of the 'gate1' and - 'gate2' Tables section whose aim is described in section 4.4. The - corresponding MIXER tables are: - - # - # MIXER table 1: X.400 --> RFC822 - # - ADMD$acme.C$it#it# - PRMD$accred.ADMD$tx400.C$it#accred.it# - O$u-newcity.PRMD$x4net.ADMD$ .C$it#cs.ncty.it# - # - # MIXER table 2: RFC822 --> X.400 - # - nrc.it#PRMD$nrc.ADMD$acme.C$it# - ninp.it#O.PRMD$ninp.ADMD$acme.C$it# - bd.it#PRMD$uk\.bd.ADMD$ .C$it# - # - # MIXER Gate 1 Table - # - ADMD$XKW-Mail.C$it#XKW-gateway.it# - PRMD$Super Inc.ADMD$ .C$it#GlobalGw.it# - # - # MIXER Gate 2 Table - # - my.it#OU$int-gw.O$@.PRMD$ninp.ADMD$acme.C$it# - co.it#O$mhs-relay.PRMD$x4net.ADMD$ .C$t# - -4.4 Storing the MIXER 'gate1' and 'gate2' tables - - Section 4.3.4 of MIXER also specify how an address should be - converted between RFC822 and X.400 in case a complete mapping is - impossible. To allow the use of DDAs for non mappable domains, the - MIXER 'gate2' table is thus introduced. - - In a totally similar way, when an X.400 address cannot be completely - converted in RFC822, section 4.3.5 of MIXER specifies how to encode - (LHS encoding) the address itself, pointing then to the appropriate - MIXER conformant gateway, indicated in the MIXER 'gate1' table. - - DNS must store and distribute also these 'gate1' and 'gate2' data. - - One of the major features of the DNS is the ability to distribute the - authority: a certain site runs the "primary" nameserver for one - determined sub-tree and thus it is also the only place allowed to - update information regarding that sub-tree. This fact allows, in our - - - -Allocchio Standards Track [Page 17] - -RFC 2163 MIXER MCGAM January 1998 - - - case, a further additional feature to the table based approach. In - fact we can avoid one possible ambiguity about the use of the 'gate1' - and 'gate2' tables (and thus of LHS and DDAs encoding). - - The authority maintaining a DNS entry in the usual RFC822 domain - space is the only one allowed to decide if its domain should be - mapped using Standard Attributes (SA) syntax or Domain Defined - Attributes (DDA) one. If the authority decides that its RFC822 domain - should be mapped using SA, then the PX RDATA will be a 'table2' - entry, otherwise it will be a 'gate2' table entry. Thus for an RFC822 - domain we cannot have any more two possible entries, one from 'table2 - and another one from 'gate2' table, and the action for a gateway - results clearly stated. - - Similarly, the authority mantaining a DNS entry in the new X.400 name - space is the only one allowed to decide if its X.400 domain should be - mapped using SA syntax or Left Hand Side (LHS) encoding. If the - authority decides that its X.400 domain should be mapped using SA, - then the PX RDATA will be a 'table1' entry, otherwise it will be a - 'gate1' table entry. Thus also for an X.400 domain we cannot have any - more two possible entries, one from 'table1' and another one from - 'gate1' table, and the action for a gateway results clearly stated. - - The MIXER 'gate1' table syntax is actually identical to MIXER - 'table1', and 'gate2' table syntax is identical to MIXER 'table2'. - Thus the same syntax translation rules from MIXER to DNS format can - be applied in both cases. However a gateway or any other application - must know if the answer it got from DNS contains some 'table1', - 'table2' or some 'gate1', 'gate2' table information. This is easily - obtained flagging with an additional ".G." post-fix the PX RDATA - value when it contains a 'gate1' or 'gate2' table entry. The example - in section 4.3 shows clearly the result. As any X.400 O/R domain must - end with a country code ("C-xx" in our DNS syntax) the additional - ".G." creates no conflicts or ambiguities at all. This postfix must - obviously be removed before using the MIXER 'gate1' or 'gate2' table - data. - -5. Finding MIXER mapping information from DNS - - The MIXER mapping information is stored in DNS both in the normal - RFC822 domain name space, and in the newly defined X.400 name space. - The information, stored in PX resource records, does not represent a - full RFC822 or X.400 O/R address: it is a template which specifies - the fields of the domain that are used by the mapping algorithm. - - When mapping information is stored in the DNS, queries to the DNS are - issued whenever an iterative search through the mapping table would - be performed (MIXER: section 4.3.4, State I; section 4.3.5, mapping - - - -Allocchio Standards Track [Page 18] - -RFC 2163 MIXER MCGAM January 1998 - - - B). Due to the DNS search mechanism, DNS by itself returns the - longest possible match in the stored mapping rule with a single - query, thus no iteration and/or multiple queries are needed. As - specified in MIXER, a search of the mapping table will result in - either success (mapping found) or failure (query failed, mapping not - found). - - When a DNS query is issued, a third possible result is timeout. If - the result is timeout, the gateway operation is delayed and then - retried at a later time. A result of success or failure is processed - according to the algorithms specified in MIXER. If a DNS error code - is returned, an error message should be logged and the gateway - operation is delayed as for timeout. These pathological situations, - however, should be avoided with a careful duplication and chaching - mechanism which DNS itself provides. - - Searching the nameserver which can authoritatively solve the query is - automatically performed by the DNS distributed name service. - -5.1 A DNS query example - - An MIXER mail-gateway located in the Internet, when translating - addresses from RFC822 to X.400, can get information about the MCGAM - rule asking the DNS. As an example, when translating the address - SUN.CCE.NRC.IT, the gateway will just query DNS for the associated PX - resource record. The DNS should contain a PX record like this: - - *.cce.nrc.it. IN PX 50 cce.nrc.it. O-cce.PRMD-nrc.ADMD-acme.C-it. - - The first query will return immediately the appropriate mapping rule - in DNS store format. - - There is no ".G." at the end of the obtained PX RDATA value, thus - applying the syntax translation specified in paragraph 4.2 the MIXER - Table 2 mapping rule will be obtained. - - Let's now take another example where a 'gate2' table rule is - returned. If we are looking for an RFC822 domain ending with top - level domain "MW", and the DNS contains a PX record like this, - - *.mw. IN PX 50 mw. O-cce.PRMD-nrc.ADMD-acme.C-it.G. - - DNS will return 'mw.' and 'O-cce.PRMD-nrc.ADMD-acme.C-it.G.', i.e., a - 'gate2' table entry in DNS store format. Dropping the final ".G." and - applying the syntax translation specified in paragraph 4.2 the - original rule will be available. More over, the ".G." flag also tells - the gateway to use DDA encoding for the inquired RFC822 domain. - - - - -Allocchio Standards Track [Page 19] - -RFC 2163 MIXER MCGAM January 1998 - - - On the other hand, translating from X.400 to RFC822 the address - - C=de; ADMD=pkz; PRMD=nfc; O=top; - - the mail gateway should convert the syntax according to paragraph - 4.2, apply the 'Country code convention' described in 4.2.3 to derive - the appropriate DNS translation of the X.400 O/R name and then query - DNS for the corresponding PX resource record. The obtained record for - which the PX record must be queried is thus: - - O-top.PRMD-nfc.ADMD-pkz.X42D.de. - - The DNS could contain: - - *.ADMD-pkz.X42D.de. IN PX 50 pkz.de. ADMD-pkz.C-de. - - Assuming that there are not more specific records in DNS, the - wildcard mechanism will return the MIXER 'table1' rule in encoded - format. - - Finally, an example where a 'gate1' rule is involved. If we are - looking for an X.400 domain ending with ADMD=PWT400; C=US; , and the - DNS contains a PX record like this, - - *.ADMD-PWT400.X42D.us. IN PX 50 intGw.com. ADMD-PWT400.C-us.G. - - DNS will return 'intGw.com.' and 'ADMD-PWT400.C-us.G.', i.e., a - 'gate1' table entry in DNS store format. Dropping the final ".G." and - applying the syntax translation specified in paragraph 4.2 the - original rule will be available. More over, the ".G." flag also tells - the gateway to use LHS encoding for the inquired X.400 domain. - -6. Administration of mapping information - - The DNS, using the PX RR, is able to distribute the MCGAM rules to - all MIXER gateways located on the Internet. However, not all MIXER - gateways will be able to use the Internet DNS. It is expected that - some gateways in a particular management domain will conform to one - of the following models: - - (a) Table-based, (b) DNS-based, (c) X.500-based - - Table-based management domains will continue to publish their MCGAM - rules and retrieve the mapping tables via the International Mapping - Table coordinator, manually or via some automated procedures. Their - MCGAM information can be made available also in DNS by the - appropriate DNS authorities, using the same mechanism already in - place for MX records: if a branch has not yet in place its own DNS - - - -Allocchio Standards Track [Page 20] - -RFC 2163 MIXER MCGAM January 1998 - - - server, some higher authority in the DNS tree will provide the - service for it. A transition procedure similar to the one used to - migrate from the 'hosts.txt' tables to DNS can be applied also to the - deployment phase of this specification. An informational document - describing the implementation phase and the detailed coordination - procedures is expected. - - Another distributed directory service which can distribute the MCGAM - information is X.500. Coordination with table-based domains can be - obtained in an identical way as for the DNS case. - - Coordination of MCGAM information between DNS and X.500 is more - complex, as it requies some kind of uploading information between the - two systems. The ideal solution is a dynamic alignment mechanism - which transparently makes the DNS mapping information available in - X.500 and vice versa. Some work in this specific field is already - being done [see Costa] which can result in a global transparent - directory service, where the information is stored in DNS or in - X.500, but is visible completely by any of the two systems. - - However we must remind that MIXER concept of MCGAM rules publication - is different from the old RFC1327 concept of globally distributed, - coordinated and unique mapping rules. In fact MIXER does not requires - any more for any conformant gateway or tool to know the complete set - of MCGAM: it only requires to use some set (eventually empty) of - valid MCGAM rules, published either by Tables, DNS or X.500 - mechanisms or any combination of these methods. More over MIXER - specifies that also incomplete sets of MCGAM can be used, and - supplementary local unpublished (but valid) MCGAM can also be used. - As a consequence, the problem of coordination between the three - systems proposed by MIXER for MCGAM publication is non essential, and - important only for efficient operational matters. It does not in fact - affect the correct behaviour of MIXER conformant gateways and tools. - -7. Conclusion - - The introduction of the new PX resource record and the definition of - the X.400 O/R name space in the DNS structure provide a good - repository for MCGAM information. The mapping information is stored - in the DNS tree structure so that it can be easily obtained using the - DNS distributed name service. At the same time the definition of the - appropriate DNS space for X.400 O/R names provide a repository where - to store and distribute some other X.400 MHS information. The use of - the DNS has many known advantages in storing, managing and updating - the information. A successful number of tests were been performed - under the provisional top level domain "X400.IT" when RFC1664 was - developed, and their results confirmed the advantages of the method. - Operational exeprience for over 2 years with RFC1664 specification - - - -Allocchio Standards Track [Page 21] - -RFC 2163 MIXER MCGAM January 1998 - - - confirmed the feasibility of the method, and helped identifying some - operational procedures to deploy the insertion of MCGAM into DNS. - - Software to query the DNS and then to convert between the textual - representation of DNS resource records and the address format defined - in MIXER was developed with RFC1664. This software also allows a - smooth implementation and deployment period, eventually taking care - of the transition phase. This software can be easily used (with - little or null modification) also for this updated specification, - supporting the new 'gate1' MIXER table. DNS software implementations - supporting RFC1664 also supports with no modification this memo new - specification. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Allocchio Standards Track [Page 22] - -RFC 2163 MIXER MCGAM January 1998 - - - A further informational document describing operational and - implementation of the service is expected. - -8. Acknowledgements - - We wish to thanks all those who contributed to the discussion and - revision of this document: many of their ideas and suggestions - constitute essential parts of this work. In particular thanks to Jon - Postel, Paul Mockapetris, Rob Austin and the whole IETF x400ops, - TERENA wg-msg and IETF namedroppers groups. A special mention to - Christian Huitema for his fundamental contribution to this work. - - This document is a revision of RFC1664, edited by one of its authors - on behalf of the IETF MIXER working group. The current editor wishes - to thank here also the authors of RFC1664: - - Antonio Blasco Bonito RFC822: bonito@cnuce.cnr.it - CNUCE - CNR X.400: C=it;A=garr;P=cnr; - Reparto infr. reti O=cnuce;S=bonito; - Viale S. Maria 36 - I 56126 Pisa - Italy - - - Bruce Cole RFC822: bcole@cisco.com - Cisco Systems Inc. X.400: C=us;A= ;P=Internet; - P.O. Box 3075 DD.rfc-822=bcole(a)cisco.com; - 1525 O'Brien Drive - Menlo Park, CA 94026 - U.S.A. - - - Silvia Giordano RFC822: giordano@cscs.ch - Centro Svizzero di X.400: C=ch;A=arcom;P=switch;O=cscs; - Calcolo Scientifico S=giordano; - Via Cantonale - CH 6928 Manno - Switzerland - - - Robert Hagens RFC822: hagens@ans.net - Advanced Network and Services X.400: C=us;A= ;P=Internet; - 1875 Campus Commons Drive DD.rfc-822=hagens(a)ans.net; - Reston, VA 22091 - U.S.A. - - - - - - -Allocchio Standards Track [Page 23] - -RFC 2163 MIXER MCGAM January 1998 - - -9. References - - [CCITT] CCITT SG 5/VII, "Recommendation X.400, Message Handling - Systems: System Model - Service Elements", October 1988. - - [RFC 1327] Kille, S., "Mapping between X.400(1988)/ISO 10021 and RFC - 822", RFC 1327, March 1992. - - [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", - STD 13, RFC 1034, USC/Information Sciences Institute, November - 1987. - - [RFC 1035] Mockapetris, P., "Domain names - Implementation and - Specification", STD 13, RFC 1035, USC/Information Sciences - Institute, November 1987. - - [RFC 1033] Lottor, M., "Domain Administrators Operation Guide", RFC - 1033, SRI International, November 1987. - - [RFC 2156] Kille, S. E., " MIXER (Mime Internet X.400 Enhanced - Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, - January 1998. - - [Costa] Costa, A., Macedo, J., and V. Freitas, "Accessing and - Managing DNS Information in the X.500 Directory", Proceeding of - the 4th Joint European Networking Conference, Trondheim, NO, May - 1993. - -10. Security Considerations - - This document specifies a means by which DNS "PX" records can direct - the translation between X.400 and Internet mail addresses. - - This can indirectly affect the routing of mail across an gateway - between X.400 and Internet Mail. A succesful attack on this service - could cause incorrect translation of an originator address (thus - "forging" the originator address), or incorrect translation of a - recipient address (thus directing the mail to an unauthorized - recipient, or making it appear to an authorized recipient, that the - message was intended for recipients other than those chosen by the - originator) or could force the mail path via some particular gateway - or message transfer agent where mail security can be affected by - compromised software. - - - - - - - - -Allocchio Standards Track [Page 24] - -RFC 2163 MIXER MCGAM January 1998 - - - There are several means by which an attacker might be able to deliver - incorrect PX records to a client. These include: (a) compromise of a - DNS server, (b) generating a counterfeit response to a client's DNS - query, (c) returning incorrect "additional information" in response - to an unrelated query. - - Clients using PX records SHOULD ensure that routing and address - translations are based only on authoritative answers. Once DNS - Security mechanisms [RFC 2065] become more widely deployed, clients - SHOULD employ those mechanisms to verify the authenticity and - integrity of PX records. - -11. Author's Address - - Claudio Allocchio - Sincrotrone Trieste - SS 14 Km 163.5 Basovizza - I 34012 Trieste - Italy - - RFC822: Claudio.Allocchio@elettra.trieste.it - X.400: C=it;A=garr;P=Trieste;O=Elettra; - S=Allocchio;G=Claudio; - Phone: +39 40 3758523 - Fax: +39 40 3758565 - - - - - - - - - - - - - - - - - - - - - - - - - - -Allocchio Standards Track [Page 25] - -RFC 2163 MIXER MCGAM January 1998 - - -12. Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Allocchio Standards Track [Page 26] - diff --git a/contrib/bind9/doc/rfc/rfc2168.txt b/contrib/bind9/doc/rfc/rfc2168.txt deleted file mode 100644 index 3eed1bdb4d11..000000000000 --- a/contrib/bind9/doc/rfc/rfc2168.txt +++ /dev/null @@ -1,1123 +0,0 @@ - - - - - - -Network Working Group R. Daniel -Request for Comments: 2168 Los Alamos National Laboratory -Category: Experimental M. Mealling - Network Solutions, Inc. - June 1997 - - - Resolution of Uniform Resource Identifiers - using the Domain Name System - -Status of this Memo -=================== - - This memo defines an Experimental Protocol for the Internet - community. This memo does not specify an Internet standard of any - kind. Discussion and suggestions for improvement are requested. - Distribution of this memo is unlimited. - -Abstract: -========= - - Uniform Resource Locators (URLs) are the foundation of the World Wide - Web, and are a vital Internet technology. However, they have proven - to be brittle in practice. The basic problem is that URLs typically - identify a particular path to a file on a particular host. There is - no graceful way of changing the path or host once the URL has been - assigned. Neither is there a graceful way of replicating the resource - located by the URL to achieve better network utilization and/or fault - tolerance. Uniform Resource Names (URNs) have been hypothesized as a - adjunct to URLs that would overcome such problems. URNs and URLs are - both instances of a broader class of identifiers known as Uniform - Resource Identifiers (URIs). - - The requirements document for URN resolution systems[15] defines the - concept of a "resolver discovery service". This document describes - the first, experimental, RDS. It is implemented by a new DNS Resource - Record, NAPTR (Naming Authority PoinTeR), that provides rules for - mapping parts of URIs to domain names. By changing the mapping - rules, we can change the host that is contacted to resolve a URI. - This will allow a more graceful handling of URLs over long time - periods, and forms the foundation for a new proposal for Uniform - Resource Names. - - - - - - - - - -Daniel & Mealling Experimental [Page 1] - -RFC 2168 Resolution of URIs Using the DNS June 1997 - - - In addition to locating resolvers, the NAPTR provides for other - naming systems to be grandfathered into the URN world, provides - independence between the name assignment system and the resolution - protocol system, and allows multiple services (Name to Location, Name - to Description, Name to Resource, ...) to be offered. In conjunction - with the SRV RR, the NAPTR record allows those services to be - replicated for the purposes of fault tolerance and load balancing. - -Introduction: -============= - - Uniform Resource Locators have been a significant advance in - retrieving Internet-accessible resources. However, their brittle - nature over time has been recognized for several years. The Uniform - Resource Identifier working group proposed the development of Uniform - Resource Names to serve as persistent, location-independent - identifiers for Internet resources in order to overcome most of the - problems with URLs. RFC-1737 [1] sets forth requirements on URNs. - - During the lifetime of the URI-WG, a number of URN proposals were - generated. The developers of several of those proposals met in a - series of meetings, resulting in a compromise known as the Knoxville - framework. The major principle behind the Knoxville framework is - that the resolution system must be separate from the way names are - assigned. This is in marked contrast to most URLs, which identify the - host to contact and the protocol to use. Readers are referred to [2] - for background on the Knoxville framework and for additional - information on the context and purpose of this proposal. - - Separating the way names are resolved from the way they are - constructed provides several benefits. It allows multiple naming - approaches and resolution approaches to compete, as it allows - different protocols and resolvers to be used. There is just one - problem with such a separation - how do we resolve a name when it - can't give us directions to its resolver? - - For the short term, DNS is the obvious candidate for the resolution - framework, since it is widely deployed and understood. However, it is - not appropriate to use DNS to maintain information on a per-resource - basis. First of all, DNS was never intended to handle that many - records. Second, the limited record size is inappropriate for catalog - information. Third, domain names are not appropriate as URNs. - - Therefore our approach is to use DNS to locate "resolvers" that can - provide information on individual resources, potentially including - the resource itself. To accomplish this, we "rewrite" the URI into a - domain name following the rules provided in NAPTR records. Rewrite - rules provide considerable power, which is important when trying to - - - -Daniel & Mealling Experimental [Page 2] - -RFC 2168 Resolution of URIs Using the DNS June 1997 - - - meet the goals listed above. However, collections of rules can become - difficult to understand. To lessen this problem, the NAPTR rules are - *always* applied to the original URI, *never* to the output of - previous rules. - - Locating a resolver through the rewrite procedure may take multiple - steps, but the beginning is always the same. The start of the URI is - scanned to extract its colon-delimited prefix. (For URNs, the prefix - is always "urn:" and we extract the following colon-delimited - namespace identifier [3]). NAPTR resolution begins by taking the - extracted string, appending the well-known suffix ".urn.net", and - querying the DNS for NAPTR records at that domain name. Based on the - results of this query, zero or more additional DNS queries may be - needed to locate resolvers for the URI. The details of the - conversation between the client and the resolver thus located are - outside the bounds of this draft. Three brief examples of this - procedure are given in the next section. - - The NAPTR RR provides the level of indirection needed to keep the - naming system independent of the resolution system, its protocols, - and services. Coupled with the new SRV resource record proposal[4] - there is also the potential for replicating the resolver on multiple - hosts, overcoming some of the most significant problems of URLs. This - is an important and subtle point. Not only do the NAPTR and SRV - records allow us to replicate the resource, we can replicate the - resolvers that know about the replicated resource. Preventing a - single point of failure at the resolver level is a significant - benefit. Separating the resolution procedure from the way names are - constructed has additional benefits. Different resolution procedures - can be used over time, and resolution procedures that are determined - to be useful can be extended to deal with additional namespaces. - -Caveats -======= - - The NAPTR proposal is the first resolution procedure to be considered - by the URN-WG. There are several concerns about the proposal which - have motivated the group to recommend it for publication as an - Experimental rather than a standards-track RFC. - - First, URN resolution is new to the IETF and we wish to gain - operational experience before recommending any procedure for the - standards track. Second, the NAPTR proposal is based on DNS and - consequently inherits concerns about security and administration. The - recent advancement of the DNSSEC and secure update drafts to Proposed - Standard reduce these concerns, but we wish to experiment with those - new capabilities in the context of URN administration. A third area - of concern is the potential for a noticeable impact on the DNS. We - - - -Daniel & Mealling Experimental [Page 3] - -RFC 2168 Resolution of URIs Using the DNS June 1997 - - - believe that the proposal makes appropriate use of caching and - additional information, but it is best to go slow where the potential - for impact on a core system like the DNS is concerned. Fourth, the - rewrite rules in the NAPTR proposal are based on regular expressions. - Since regular expressions are difficult for humans to construct - correctly, concerns exist about the usability and maintainability of - the rules. This is especially true where international character sets - are concerned. Finally, the URN-WG is developing a requirements - document for URN Resolution Services[15], but that document is not - complete. That document needs to precede any resolution service - proposals on the standards track. - -Terminology -=========== - - "Must" or "Shall" - Software that does not behave in the manner that - this document says it must is not conformant to this - document. - "Should" - Software that does not follow the behavior that this - document says it should may still be conformant, but is - probably broken in some fundamental way. - "May" - Implementations may or may not provide the described - behavior, while still remaining conformant to this - document. - -Brief overview and examples of the NAPTR RR: -============================================ - - A detailed description of the NAPTR RR will be given later, but to - give a flavor for the proposal we first give a simple description of - the record and three examples of its use. - - The key fields in the NAPTR RR are order, preference, service, flags, - regexp, and replacement: - - * The order field specifies the order in which records MUST be - processed when multiple NAPTR records are returned in response to a - single query. A naming authority may have delegated a portion of - its namespace to another agency. Evaluating the NAPTR records in - the correct order is necessary for delegation to work properly. - - * The preference field specifies the order in which records SHOULD be - processed when multiple NAPTR records have the same value of - "order". This field lets a service provider specify the order in - which resolvers are contacted, so that more capable machines are - contacted in preference to less capable ones. - - - - - -Daniel & Mealling Experimental [Page 4] - -RFC 2168 Resolution of URIs Using the DNS June 1997 - - - * The service field specifies the resolution protocol and resolution - service(s) that will be available if the rewrite specified by the - regexp or replacement fields is applied. Resolution protocols are - the protocols used to talk with a resolver. They will be specified - in other documents, such as [5]. Resolution services are operations - such as N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC), - etc. These will be discussed in the URN Resolution Services - document[6], and their behavior in a particular resolution protocol - will be given in the specification for that protocol (see [5] for a - concrete example). - - * The flags field contains modifiers that affect what happens in the - next DNS lookup, typically for optimizing the process. Flags may - also affect the interpretation of the other fields in the record, - therefore, clients MUST skip NAPTR records which contain an unknown - flag value. - - * The regexp field is one of two fields used for the rewrite rules, - and is the core concept of the NAPTR record. The regexp field is a - String containing a sed-like substitution expression. (The actual - grammar for the substitution expressions is given later in this - draft). The substitution expression is applied to the original URN - to determine the next domain name to be queried. The regexp field - should be used when the domain name to be generated is conditional - on information in the URI. If the next domain name is always known, - which is anticipated to be a common occurrence, the replacement - field should be used instead. - - * The replacement field is the other field that may be used for the - rewrite rule. It is an optimization of the rewrite process for the - case where the next domain name is fixed instead of being - conditional on the content of the URI. The replacement field is a - domain name (subject to compression if a DNS sender knows that a - given recipient is able to decompress names in this RR type's RDATA - field). If the rewrite is more complex than a simple substitution - of a domain name, the replacement field should be set to . and the - regexp field used. - - - - - - - - - - - - - - -Daniel & Mealling Experimental [Page 5] - -RFC 2168 Resolution of URIs Using the DNS June 1997 - - - Note that the client applies all the substitutions and performs all - lookups, they are not performed in the DNS servers. Note also that it - is the belief of the developers of this document that regexps should - rarely be used. The replacement field seems adequate for the vast - majority of situations. Regexps are only necessary when portions of a - namespace are to be delegated to different resolvers. Finally, note - that the regexp and replacement fields are, at present, mutually - exclusive. However, developers of client software should be aware - that a new flag might be defined which requires values in both - fields. - -Example 1 ---------- - - Consider a URN that uses the hypothetical DUNS namespace. DUNS - numbers are identifiers for approximately 30 million registered - businesses around the world, assigned and maintained by Dunn and - Bradstreet. The URN might look like: - - urn:duns:002372413:annual-report-1997 - - The first step in the resolution process is to find out about the - DUNS namespace. The namespace identifier, "duns", is extracted from - the URN, prepended to urn.net, and the NAPTRs for duns.urn.net looked - up. It might return records of the form: - -duns.urn.net -;; order pref flags service regexp replacement - IN NAPTR 100 10 "s" "dunslink+N2L+N2C" "" dunslink.udp.isi.dandb.com - IN NAPTR 100 20 "s" "rcds+N2C" "" rcds.udp.isi.dandb.com - IN NAPTR 100 30 "s" "http+N2L+N2C+N2R" "" http.tcp.isi.dandb.com - - The order field contains equal values, indicating that no name - delegation order has to be followed. The preference field indicates - that the provider would like clients to use the special dunslink - protocol, followed by the RCDS protocol, and that HTTP is offered as - a last resort. All the records specify the "s" flag, which will be - explained momentarily. The service fields say that if we speak - dunslink, we will be able to issue either the N2L or N2C requests to - obtain a URL or a URC (description) of the resource. The Resource - Cataloging and Distribution Service (RCDS)[7] could be used to get a - URC for the resource, while HTTP could be used to get a URL, URC, or - the resource itself. All the records supply the next domain name to - query, none of them need to be rewritten with the aid of regular - expressions. - - - - - - -Daniel & Mealling Experimental [Page 6] - -RFC 2168 Resolution of URIs Using the DNS June 1997 - - - The general case might require multiple NAPTR rewrites to locate a - resolver, but eventually we will come to the "terminal NAPTR". Once - we have the terminal NAPTR, our next probe into the DNS will be for a - SRV or A record instead of another NAPTR. Rather than probing for a - non-existent NAPTR record to terminate the loop, the flags field is - used to indicate a terminal lookup. If it has a value of "s", the - next lookup should be for SRV RRs, "a" denotes that A records should - sought. A "p" flag is also provided to indicate that the next action - is Protocol-specific, but that looking up another NAPTR will not be - part of it. - - Since our example RR specified the "s" flag, it was terminal. - Assuming our client does not know the dunslink protocol, our next - action is to lookup SRV RRs for rcds.udp.isi.dandb.com, which will - tell us hosts that can provide the necessary resolution service. That - lookup might return: - - ;; Pref Weight Port Target - rcds.udp.isi.dandb.com IN SRV 0 0 1000 defduns.isi.dandb.com - IN SRV 0 0 1000 dbmirror.com.au - IN SRV 0 0 1000 ukmirror.com.uk - - telling us three hosts that could actually do the resolution, and - giving us the port we should use to talk to their RCDS server. (The - reader is referred to the SRV proposal [4] for the interpretation of - the fields above). - - There is opportunity for significant optimization here. We can return - the SRV records as additional information for terminal NAPTRs (and - the A records as additional information for those SRVs). While this - recursive provision of additional information is not explicitly - blessed in the DNS specifications, it is not forbidden, and BIND does - take advantage of it [8]. This is a significant optimization. In - conjunction with a long TTL for *.urn.net records, the average number - of probes to DNS for resolving DUNS URNs would approach one. - Therefore, DNS server implementors SHOULD provide additional - information with NAPTR responses. The additional information will be - either SRV or A records. If SRV records are available, their A - records should be provided as recursive additional information. - - Note that the example NAPTR records above are intended to represent - the reply the client will see. They are not quite identical to what - the domain administrator would put into the zone files. For one - thing, the administrator should supply the trailing '.' character on - any FQDNs. - - - - - - -Daniel & Mealling Experimental [Page 7] - -RFC 2168 Resolution of URIs Using the DNS June 1997 - - -Example 2 ---------- - - Consider a URN namespace based on MIME Content-Ids. The URN might - look like this: - - urn:cid:199606121851.1@mordred.gatech.edu - - (Note that this example is chosen for pedagogical purposes, and does - not conform to the recently-approved CID URL scheme.) - - The first step in the resolution process is to find out about the CID - namespace. The namespace identifier, cid, is extracted from the URN, - prepended to urn.net, and the NAPTR for cid.urn.net looked up. It - might return records of the form: - - cid.urn.net - ;; order pref flags service regexp replacement - IN NAPTR 100 10 "" "" "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i" . - - We have only one NAPTR response, so ordering the responses is not a - problem. The replacement field is empty, so we check the regexp - field and use the pattern provided there. We apply that regexp to the - entire URN to see if it matches, which it does. The \2 part of the - substitution expression returns the string "gatech.edu". Since the - flags field does not contain "s" or "a", the lookup is not terminal - and our next probe to DNS is for more NAPTR records: - lookup(query=NAPTR, "gatech.edu"). - - Note that the rule does not extract the full domain name from the - CID, instead it assumes the CID comes from a host and extracts its - domain. While all hosts, such as mordred, could have their very own - NAPTR, maintaining those records for all the machines at a site as - large as Georgia Tech would be an intolerable burden. Wildcards are - not appropriate here since they only return results when there is no - exactly matching names already in the system. - - The record returned from the query on "gatech.edu" might look like: - -gatech.edu IN NAPTR -;; order pref flags service regexp replacement - IN NAPTR 100 50 "s" "z3950+N2L+N2C" "" z3950.tcp.gatech.edu - IN NAPTR 100 50 "s" "rcds+N2C" "" rcds.udp.gatech.edu - IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" http.tcp.gatech.edu - - - - - - - -Daniel & Mealling Experimental [Page 8] - -RFC 2168 Resolution of URIs Using the DNS June 1997 - - - Continuing with our example, we note that the values of the order and - preference fields are equal in all records, so the client is free to - pick any record. The flags field tells us that these are the last - NAPTR patterns we should see, and after the rewrite (a simple - replacement in this case) we should look up SRV records to get - information on the hosts that can provide the necessary service. - - Assuming we prefer the Z39.50 protocol, our lookup might return: - - ;; Pref Weight Port Target - z3950.tcp.gatech.edu IN SRV 0 0 1000 z3950.gatech.edu - IN SRV 0 0 1000 z3950.cc.gatech.edu - IN SRV 0 0 1000 z3950.uga.edu - - telling us three hosts that could actually do the resolution, and - giving us the port we should use to talk to their Z39.50 server. - - Recall that the regular expression used \2 to extract a domain name - from the CID, and \. for matching the literal '.' characters - seperating the domain name components. Since '\' is the escape - character, literal occurances of a backslash must be escaped by - another backslash. For the case of the cid.urn.net record above, the - regular expression entered into the zone file should be - "/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i". When the client code actually - receives the record, the pattern will have been converted to - "/urn:cid:.+@([^.]+\.)(.*)$/\2/i". - -Example 3 ---------- - - Even if URN systems were in place now, there would still be a - tremendous number of URLs. It should be possible to develop a URN - resolution system that can also provide location independence for - those URLs. This is related to the requirement in [1] to be able to - grandfather in names from other naming systems, such as ISO Formal - Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs, - etc. - - The NAPTR RR could also be used for URLs that have already been - assigned. Assume we have the URL for a very popular piece of - software that the publisher wishes to mirror at multiple sites around - the world: - - http://www.foo.com/software/latest-beta.exe - - - - - - - -Daniel & Mealling Experimental [Page 9] - -RFC 2168 Resolution of URIs Using the DNS June 1997 - - - We extract the prefix, "http", and lookup NAPTR records for - http.urn.net. This might return a record of the form - - http.urn.net IN NAPTR - ;; order pref flags service regexp replacement - 100 90 "" "" "!http://([^/:]+)!\1!i" . - - This expression returns everything after the first double slash and - before the next slash or colon. (We use the '!' character to delimit - the parts of the substitution expression. Otherwise we would have to - use backslashes to escape the forward slashes, and would have a - regexp in the zone file that looked like - "/http:\\/\\/([^\\/:]+)/\\1/i".). - - Applying this pattern to the URL extracts "www.foo.com". Looking up - NAPTR records for that might return: - - www.foo.com - ;; order pref flags service regexp replacement - IN NAPTR 100 100 "s" "http+L2R" "" http.tcp.foo.com - IN NAPTR 100 100 "s" "ftp+L2R" "" ftp.tcp.foo.com - - Looking up SRV records for http.tcp.foo.com would return information - on the hosts that foo.com has designated to be its mirror sites. The - client can then pick one for the user. - -NAPTR RR Format -=============== - - The format of the NAPTR RR is given below. The DNS type code for - NAPTR is 35. - - Domain TTL Class Order Preference Flags Service Regexp - Replacement - - where: - - Domain - The domain name this resource record refers to. - TTL - Standard DNS Time To Live field - Class - Standard DNS meaning - - - - - - - - -Daniel & Mealling Experimental [Page 10] - -RFC 2168 Resolution of URIs Using the DNS June 1997 - - - Order - A 16-bit integer specifying the order in which the NAPTR - records MUST be processed to ensure correct delegation of - portions of the namespace over time. Low numbers are processed - before high numbers, and once a NAPTR is found that "matches" - a URN, the client MUST NOT consider any NAPTRs with a higher - value for order. - - Preference - A 16-bit integer which specifies the order in which NAPTR - records with equal "order" values SHOULD be processed, low - numbers being processed before high numbers. This is similar - to the preference field in an MX record, and is used so domain - administrators can direct clients towards more capable hosts - or lighter weight protocols. - - Flags - A String giving flags to control aspects of the rewriting and - interpretation of the fields in the record. Flags are single - characters from the set [A-Z0-9]. The case of the alphabetic - characters is not significant. - - At this time only three flags, "S", "A", and "P", are defined. - "S" means that the next lookup should be for SRV records - instead of NAPTR records. "A" means that the next lookup - should be for A records. The "P" flag says that the remainder - of the resolution shall be carried out in a Protocol-specific - fashion, and we should not do any more DNS queries. - - The remaining alphabetic flags are reserved. The numeric flags - may be used for local experimentation. The S, A, and P flags - are all mutually exclusive, and resolution libraries MAY - signal an error if more than one is given. (Experimental code - and code for assisting in the creation of NAPTRs would be more - likely to signal such an error than a client such as a - browser). We anticipate that multiple flags will be allowed in - the future, so implementers MUST NOT assume that the flags - field can only contain 0 or 1 characters. Finally, if a client - encounters a record with an unknown flag, it MUST ignore it - and move to the next record. This test takes precedence even - over the "order" field. Since flags can control the - interpretation placed on fields, a novel flag might change the - interpretation of the regexp and/or replacement fields such - that it is impossible to determine if a record matched a URN. - - - - - - - -Daniel & Mealling Experimental [Page 11] - -RFC 2168 Resolution of URIs Using the DNS June 1997 - - - Service - Specifies the resolution service(s) available down this - rewrite path. It may also specify the particular protocol that - is used to talk with a resolver. A protocol MUST be specified - if the flags field states that the NAPTR is terminal. If a - protocol is specified, but the flags field does not state that - the NAPTR is terminal, the next lookup MUST be for a NAPTR. - The client MAY choose not to perform the next lookup if the - protocol is unknown, but that behavior MUST NOT be relied - upon. - - The service field may take any of the values below (using the - Augmented BNF of RFC 822[9]): - - service_field = [ [protocol] *("+" rs)] - protocol = ALPHA *31ALPHANUM - rs = ALPHA *31ALPHANUM - // The protocol and rs fields are limited to 32 - // characters and must start with an alphabetic. - // The current set of "known" strings are: - // protocol = "rcds" / "thttp" / "hdl" / "rwhois" / "z3950" - // rs = "N2L" / "N2Ls" / "N2R" / "N2Rs" / "N2C" - // / "N2Ns" / "L2R" / "L2Ns" / "L2Ls" / "L2C" - - i.e. an optional protocol specification followed by 0 or more - resolution services. Each resolution service is indicated by - an initial '+' character. - - Note that the empty string is also a valid service field. This - will typically be seen at the top levels of a namespace, when - it is impossible to know what services and protocols will be - offered by a particular publisher within that name space. - - At this time the known protocols are rcds[7], hdl[10] (binary, - UDP-based protocols), thttp[5] (a textual, TCP-based - protocol), rwhois[11] (textual, UDP or TCP based), and - Z39.50[12] (binary, TCP-based). More will be allowed later. - The names of the protocols must be formed from the characters - [a-Z0-9]. Case of the characters is not significant. - - The service requests currently allowed will be described in - more detail in [6], but in brief they are: - N2L - Given a URN, return a URL - N2Ls - Given a URN, return a set of URLs - N2R - Given a URN, return an instance of the resource. - N2Rs - Given a URN, return multiple instances of the - resource, typically encoded using - multipart/alternative. - - - -Daniel & Mealling Experimental [Page 12] - -RFC 2168 Resolution of URIs Using the DNS June 1997 - - - N2C - Given a URN, return a collection of meta- - information on the named resource. The format of - this response is the subject of another document. - N2Ns - Given a URN, return all URNs that are also - identifers for the resource. - L2R - Given a URL, return the resource. - L2Ns - Given a URL, return all the URNs that are - identifiers for the resource. - L2Ls - Given a URL, return all the URLs for instances of - of the same resource. - L2C - Given a URL, return a description of the - resource. - - The actual format of the service request and response will be - determined by the resolution protocol, and is the subject for - other documents (e.g. [5]). Protocols need not offer all - services. The labels for service requests shall be formed from - the set of characters [A-Z0-9]. The case of the alphabetic - characters is not significant. - - Regexp - A STRING containing a substitution expression that is applied - to the original URI in order to construct the next domain name - to lookup. The grammar of the substitution expression is given - in the next section. - - Replacement - The next NAME to query for NAPTR, SRV, or A records depending - on the value of the flags field. As mentioned above, this may - be compressed. - -Substitution Expression Grammar: -================================ - - The content of the regexp field is a substitution expression. True - sed(1) substitution expressions are not appropriate for use in this - application for a variety of reasons, therefore the contents of the - regexp field MUST follow the grammar below: - -subst_expr = delim-char ere delim-char repl delim-char *flags -delim-char = "/" / "!" / ... (Any non-digit or non-flag character other - than backslash '\'. All occurances of a delim_char in a - subst_expr must be the same character.) -ere = POSIX Extended Regular Expression (see [13], section - 2.8.4) -repl = dns_str / backref / repl dns_str / repl backref -dns_str = 1*DNS_CHAR -backref = "\" 1POS_DIGIT - - - -Daniel & Mealling Experimental [Page 13] - -RFC 2168 Resolution of URIs Using the DNS June 1997 - - -flags = "i" -DNS_CHAR = "-" / "0" / ... / "9" / "a" / ... / "z" / "A" / ... / "Z" -POS_DIGIT = "1" / "2" / ... / "9" ; 0 is not an allowed backref -value domain name (see RFC-1123 [14]). - - The result of applying the substitution expression to the original - URI MUST result in a string that obeys the syntax for DNS host names - [14]. Since it is possible for the regexp field to be improperly - specified, such that a non-conforming host name can be constructed, - client software SHOULD verify that the result is a legal host name - before making queries on it. - - Backref expressions in the repl portion of the substitution - expression are replaced by the (possibly empty) string of characters - enclosed by '(' and ')' in the ERE portion of the substitution - expression. N is a single digit from 1 through 9, inclusive. It - specifies the N'th backref expression, the one that begins with the - N'th '(' and continues to the matching ')'. For example, the ERE - (A(B(C)DE)(F)G) - has backref expressions: - \1 = ABCDEFG - \2 = BCDE - \3 = C - \4 = F - \5..\9 = error - no matching subexpression - - The "i" flag indicates that the ERE matching SHALL be performed in a - case-insensitive fashion. Furthermore, any backref replacements MAY - be normalized to lower case when the "i" flag is given. - - The first character in the substitution expression shall be used as - the character that delimits the components of the substitution - expression. There must be exactly three non-escaped occurrences of - the delimiter character in a substitution expression. Since escaped - occurrences of the delimiter character will be interpreted as - occurrences of that character, digits MUST NOT be used as delimiters. - Backrefs would be confused with literal digits were this allowed. - Similarly, if flags are specified in the substitution expression, the - delimiter character must not also be a flag character. - - - - - - - - - - - - -Daniel & Mealling Experimental [Page 14] - -RFC 2168 Resolution of URIs Using the DNS June 1997 - - -Advice to domain administrators: -================================ - - Beware of regular expressions. Not only are they a pain to get - correct on their own, but there is the previously mentioned - interaction with DNS. Any backslashes in a regexp must be entered - twice in a zone file in order to appear once in a query response. - More seriously, the need for double backslashes has probably not been - tested by all implementors of DNS servers. We anticipate that urn.net - will be the heaviest user of regexps. Only when delegating portions - of namespaces should the typical domain administrator need to use - regexps. - - On a related note, beware of interactions with the shell when - manipulating regexps from the command line. Since '\' is a common - escape character in shells, there is a good chance that when you - think you are saying "\\" you are actually saying "\". Similar - caveats apply to characters such as - - The "a" flag allows the next lookup to be for A records rather than - SRV records. Since there is no place for a port specification in the - NAPTR record, when the "A" flag is used the specified protocol must - be running on its default port. - - The URN Sytnax draft defines a canonical form for each URN, which - requires %encoding characters outside a limited repertoire. The - regular expressions MUST be written to operate on that canonical - form. Since international character sets will end up with extensive - use of %encoded characters, regular expressions operating on them - will be essentially impossible to read or write by hand. - -Usage -===== - - For the edification of implementers, pseudocode for a client routine - using NAPTRs is given below. This code is provided merely as a - convience, it does not have any weight as a standard way to process - NAPTR records. Also, as is the case with pseudocode, it has never - been executed and may contain logical errors. You have been warned. - - // - // findResolver(URN) - // Given a URN, find a host that can resolve it. - // - findResolver(string URN) { - // prepend prefix to urn.net - sprintf(key, "%s.urn.net", extractNS(URN)); - do { - - - -Daniel & Mealling Experimental [Page 15] - -RFC 2168 Resolution of URIs Using the DNS June 1997 - - - rewrite_flag = false; - terminal = false; - if (key has been seen) { - quit with a loop detected error - } - add key to list of "seens" - records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key' - - discard any records with an unknown value in the "flags" field. - sort NAPTR records by "order" field and "preference" field - (with "order" being more significant than "preference"). - n_naptrs = number of NAPTR records in response. - curr_order = records[0].order; - max_order = records[n_naptrs-1].order; - - // Process current batch of NAPTRs according to "order" field. - for (j=0; j < n_naptrs && records[j].order <= max_order; j++) { - if (unknown_flag) // skip this record and go to next one - continue; - newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp); - if (!newkey) // Skip to next record if the rewrite didn't - match continue; - // We did do a rewrite, shrink max_order to current value - // so that delegation works properly - max_order = naptr[j].order; - // Will we know what to do with the protocol and services - // specified in the NAPTR? If not, try next record. - if(!isKnownProto(naptr[j].services)) { - continue; - } - if(!isKnownService(naptr[j].services)) { - continue; - } - - // At this point we have a successful rewrite and we will - // know how to speak the protocol and request a known - // resolution service. Before we do the next lookup, check - // some optimization possibilities. - - if (strcasecmp(flags, "S") - || strcasecmp(flags, "P")) - || strcasecmp(flags, "A")) { - terminal = true; - services = naptr[j].services; - addnl = any SRV and/or A records returned as additional - info for naptr[j]. - } - key = newkey; - - - -Daniel & Mealling Experimental [Page 16] - -RFC 2168 Resolution of URIs Using the DNS June 1997 - - - rewriteflag = true; - break; - } - } while (rewriteflag && !terminal); - - // Did we not find our way to a resolver? - if (!rewrite_flag) { - report an error - return NULL; - } - - - // Leave rest to another protocol? - if (strcasecmp(flags, "P")) { - return key as host to talk to; - } - - // If not, keep plugging - if (!addnl) { // No SRVs came in as additional info, look them up - srvs = lookup(type=SRV, key); - } - - sort SRV records by preference, weight, ... - foreach (SRV record) { // in order of preference - try contacting srv[j].target using the protocol and one of the - resolution service requests from the "services" field of the - last NAPTR record. - if (successful) - return (target, protocol, service); - // Actually we would probably return a result, but this - // code was supposed to just tell us a good host to talk to. - } - die with an "unable to find a host" error; - } - -Notes: -====== - - - A client MUST process multiple NAPTR records in the order - specified by the "order" field, it MUST NOT simply use the first - record that provides a known protocol and service combination. - - - - - - - - - - -Daniel & Mealling Experimental [Page 17] - -RFC 2168 Resolution of URIs Using the DNS June 1997 - - - - If a record at a particular order matches the URI, but the - client doesn't know the specified protocol and service, the - client SHOULD continue to examine records that have the same - order. The client MUST NOT consider records with a higher value - of order. This is necessary to make delegation of portions of - the namespace work. The order field is what lets site - administrators say "all requests for URIs matching pattern x go - to server 1, all others go to server 2". - (A match is defined as: - 1) The NAPTR provides a replacement domain name - or - 2) The regular expression matches the URN - ) - - - When multiple RRs have the same "order", the client should use - the value of the preference field to select the next NAPTR to - consider. However, because of preferred protocols or services, - estimates of network distance and bandwidth, etc. clients may - use different criteria to sort the records. - - If the lookup after a rewrite fails, clients are strongly - encouraged to report a failure, rather than backing up to pursue - other rewrite paths. - - When a namespace is to be delegated among a set of resolvers, - regexps must be used. Each regexp appears in a separate NAPTR - RR. Administrators should do as little delegation as possible, - because of limitations on the size of DNS responses. - - Note that SRV RRs impose additional requirements on clients. - -Acknowledgments: -================= - - The editors would like to thank Keith Moore for all his consultations - during the development of this draft. We would also like to thank - Paul Vixie for his assistance in debugging our implementation, and - his answers on our questions. Finally, we would like to acknowledge - our enormous intellectual debt to the participants in the Knoxville - series of meetings, as well as to the participants in the URI and URN - working groups. - -References: -=========== - - [1] Sollins, Karen and Larry Masinter, "Functional Requirements - for Uniform Resource Names", RFC-1737, Dec. 1994. - - [2] The URN Implementors, Uniform Resource Names: A Progress Report, - http://www.dlib.org/dlib/february96/02arms.html, D-Lib Magazine, - February 1996. - - - -Daniel & Mealling Experimental [Page 18] - -RFC 2168 Resolution of URIs Using the DNS June 1997 - - - [3] Moats, Ryan, "URN Syntax", RFC-2141, May 1997. - - [4] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying - the location of services (DNS SRV)", RFC-2052, October 1996. - - [5] Daniel, Jr., Ron, "A Trivial Convention for using HTTP in URN - Resolution", RFC-2169, June 1997. - - [6] URN-WG, "URN Resolution Services", Work in Progress. - - [7] Moore, Keith, Shirley Browne, Jason Cox, and Jonathan Gettler, - Resource Cataloging and Distribution System, Technical Report - CS-97-346, University of Tennessee, Knoxville, December 1996 - - [8] Paul Vixie, personal communication. - - [9] Crocker, Dave H. "Standard for the Format of ARPA Internet Text - Messages", RFC-822, August 1982. - - [10] Orth, Charles and Bill Arms; Handle Resolution Protocol - Specification, http://www.handle.net/docs/client_spec.html - - [11] Williamson, S., M. Kosters, D. Blacka, J. Singh, K. Zeilstra, - "Referral Whois Protocol (RWhois)", RFC-2167, June 1997. - - [12] Information Retrieval (Z39.50): Application Service Definition - and Protocol Specification, ANSI/NISO Z39.50-1995, July 1995. - - [13] IEEE Standard for Information Technology - Portable Operating - System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1); - IEEE Std 1003.2-1992; The Institute of Electrical and - Electronics Engineers; New York; 1993. ISBN:1-55937-255-9 - - [14] Braden, R., "Requirements for Internet Hosts - Application and - and Support", RFC-1123, Oct. 1989. - - [15] Sollins, Karen, "Requirements and a Framework for URN Resolution - Systems", November 1996, Work in Progress. - - - - - - - - - - - - - -Daniel & Mealling Experimental [Page 19] - -RFC 2168 Resolution of URIs Using the DNS June 1997 - - -Security Considerations -======================= - - The use of "urn.net" as the registry for URN namespaces is subject to - denial of service attacks, as well as other DNS spoofing attacks. The - interactions with DNSSEC are currently being studied. It is expected - that NAPTR records will be signed with SIG records once the DNSSEC - work is deployed. - - The rewrite rules make identifiers from other namespaces subject to - the same attacks as normal domain names. Since they have not been - easily resolvable before, this may or may not be considered a - problem. - - Regular expressions should be checked for sanity, not blindly passed - to something like PERL. - - This document has discussed a way of locating a resolver, but has not - discussed any detail of how the communication with the resolver takes - place. There are significant security considerations attached to the - communication with a resolver. Those considerations are outside the - scope of this document, and must be addressed by the specifications - for particular resolver communication protocols. - -Author Contact Information: -=========================== - - Ron Daniel - Los Alamos National Laboratory - MS B287 - Los Alamos, NM, USA, 87545 - voice: +1 505 665 0597 - fax: +1 505 665 4939 - email: rdaniel@lanl.gov - - - Michael Mealling - Network Solutions - 505 Huntmar Park Drive - Herndon, VA 22070 - voice: (703) 742-0400 - fax: (703) 742-9552 - email: michaelm@internic.net - URL: http://www.netsol.com/ - - - - - - - -Daniel & Mealling Experimental [Page 20] - diff --git a/contrib/bind9/doc/rfc/rfc2181.txt b/contrib/bind9/doc/rfc/rfc2181.txt deleted file mode 100644 index 7899e1cbf412..000000000000 --- a/contrib/bind9/doc/rfc/rfc2181.txt +++ /dev/null @@ -1,842 +0,0 @@ - - - - - - -Network Working Group R. Elz -Request for Comments: 2181 University of Melbourne -Updates: 1034, 1035, 1123 R. Bush -Category: Standards Track RGnet, Inc. - July 1997 - - - Clarifications to the DNS Specification - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -1. Abstract - - This document considers some areas that have been identified as - problems with the specification of the Domain Name System, and - proposes remedies for the defects identified. Eight separate issues - are considered: - - + IP packet header address usage from multi-homed servers, - + TTLs in sets of records with the same name, class, and type, - + correct handling of zone cuts, - + three minor issues concerning SOA records and their use, - + the precise definition of the Time to Live (TTL) - + Use of the TC (truncated) header bit - + the issue of what is an authoritative, or canonical, name, - + and the issue of what makes a valid DNS label. - - The first six of these are areas where the correct behaviour has been - somewhat unclear, we seek to rectify that. The other two are already - adequately specified, however the specifications seem to be sometimes - ignored. We seek to reinforce the existing specifications. - - - - - - - - - - - - - - -Elz & Bush Standards Track [Page 1] - -RFC 2181 Clarifications to the DNS Specification July 1997 - - - - -Contents - - 1 Abstract ................................................... 1 - 2 Introduction ............................................... 2 - 3 Terminology ................................................ 3 - 4 Server Reply Source Address Selection ...................... 3 - 5 Resource Record Sets ....................................... 4 - 6 Zone Cuts .................................................. 8 - 7 SOA RRs .................................................... 10 - 8 Time to Live (TTL) ......................................... 10 - 9 The TC (truncated) header bit .............................. 11 - 10 Naming issues .............................................. 11 - 11 Name syntax ................................................ 13 - 12 Security Considerations .................................... 14 - 13 References ................................................. 14 - 14 Acknowledgements ........................................... 15 - 15 Authors' Addresses ......................................... 15 - - - - -2. Introduction - - Several problem areas in the Domain Name System specification - [RFC1034, RFC1035] have been noted through the years [RFC1123]. This - document addresses several additional problem areas. The issues here - are independent. Those issues are the question of which source - address a multi-homed DNS server should use when replying to a query, - the issue of differing TTLs for DNS records with the same label, - class and type, and the issue of canonical names, what they are, how - CNAME records relate, what names are legal in what parts of the DNS, - and what is the valid syntax of a DNS name. - - Clarifications to the DNS specification to avoid these problems are - made in this memo. A minor ambiguity in RFC1034 concerned with SOA - records is also corrected, as is one in the definition of the TTL - (Time To Live) and some possible confusion in use of the TC bit. - - - - - - - - - - - - -Elz & Bush Standards Track [Page 2] - -RFC 2181 Clarifications to the DNS Specification July 1997 - - -3. Terminology - - This memo does not use the oft used expressions MUST, SHOULD, MAY, or - their negative forms. In some sections it may seem that a - specification is worded mildly, and hence some may infer that the - specification is optional. That is not correct. Anywhere that this - memo suggests that some action should be carried out, or must be - carried out, or that some behaviour is acceptable, or not, that is to - be considered as a fundamental aspect of this specification, - regardless of the specific words used. If some behaviour or action - is truly optional, that will be clearly specified by the text. - -4. Server Reply Source Address Selection - - Most, if not all, DNS clients, expect the address from which a reply - is received to be the same address as that to which the query - eliciting the reply was sent. This is true for servers acting as - clients for the purposes of recursive query resolution, as well as - simple resolver clients. The address, along with the identifier (ID) - in the reply is used for disambiguating replies, and filtering - spurious responses. This may, or may not, have been intended when - the DNS was designed, but is now a fact of life. - - Some multi-homed hosts running DNS servers generate a reply using a - source address that is not the same as the destination address from - the client's request packet. Such replies will be discarded by the - client because the source address of the reply does not match that of - a host to which the client sent the original request. That is, it - appears to be an unsolicited response. - -4.1. UDP Source Address Selection - - To avoid these problems, servers when responding to queries using UDP - must cause the reply to be sent with the source address field in the - IP header set to the address that was in the destination address - field of the IP header of the packet containing the query causing the - response. If this would cause the response to be sent from an IP - address that is not permitted for this purpose, then the response may - be sent from any legal IP address allocated to the server. That - address should be chosen to maximise the possibility that the client - will be able to use it for further queries. Servers configured in - such a way that not all their addresses are equally reachable from - all potential clients need take particular care when responding to - queries sent to anycast, multicast, or similar, addresses. - - - - - - - -Elz & Bush Standards Track [Page 3] - -RFC 2181 Clarifications to the DNS Specification July 1997 - - -4.2. Port Number Selection - - Replies to all queries must be directed to the port from which they - were sent. When queries are received via TCP this is an inherent - part of the transport protocol. For queries received by UDP the - server must take note of the source port and use that as the - destination port in the response. Replies should always be sent from - the port to which they were directed. Except in extraordinary - circumstances, this will be the well known port assigned for DNS - queries [RFC1700]. - -5. Resource Record Sets - - Each DNS Resource Record (RR) has a label, class, type, and data. It - is meaningless for two records to ever have label, class, type and - data all equal - servers should suppress such duplicates if - encountered. It is however possible for most record types to exist - with the same label, class and type, but with different data. Such a - group of records is hereby defined to be a Resource Record Set - (RRSet). - -5.1. Sending RRs from an RRSet - - A query for a specific (or non-specific) label, class, and type, will - always return all records in the associated RRSet - whether that be - one or more RRs. The response must be marked as "truncated" if the - entire RRSet will not fit in the response. - -5.2. TTLs of RRs in an RRSet - - Resource Records also have a time to live (TTL). It is possible for - the RRs in an RRSet to have different TTLs. No uses for this have - been found that cannot be better accomplished in other ways. This - can, however, cause partial replies (not marked "truncated") from a - caching server, where the TTLs for some but not all the RRs in the - RRSet have expired. - - Consequently the use of differing TTLs in an RRSet is hereby - deprecated, the TTLs of all RRs in an RRSet must be the same. - - Should a client receive a response containing RRs from an RRSet with - differing TTLs, it should treat this as an error. If the RRSet - concerned is from a non-authoritative source for this data, the - client should simply ignore the RRSet, and if the values were - required, seek to acquire them from an authoritative source. Clients - that are configured to send all queries to one, or more, particular - servers should treat those servers as authoritative for this purpose. - Should an authoritative source send such a malformed RRSet, the - - - -Elz & Bush Standards Track [Page 4] - -RFC 2181 Clarifications to the DNS Specification July 1997 - - - client should treat the RRs for all purposes as if all TTLs in the - RRSet had been set to the value of the lowest TTL in the RRSet. In - no case may a server send an RRSet with TTLs not all equal. - -5.3. DNSSEC Special Cases - - Two of the record types added by DNS Security (DNSSEC) [RFC2065] - require special attention when considering the formation of Resource - Record Sets. Those are the SIG and NXT records. It should be noted - that DNS Security is still very new, and there is, as yet, little - experience with it. Readers should be prepared for the information - related to DNSSEC contained in this document to become outdated as - the DNS Security specification matures. - -5.3.1. SIG records and RRSets - - A SIG record provides signature (validation) data for another RRSet - in the DNS. Where a zone has been signed, every RRSet in the zone - will have had a SIG record associated with it. The data type of the - RRSet is included in the data of the SIG RR, to indicate with which - particular RRSet this SIG record is associated. Were the rules above - applied, whenever a SIG record was included with a response to - validate that response, the SIG records for all other RRSets - associated with the appropriate node would also need to be included. - In some cases, this could be a very large number of records, not - helped by their being rather large RRs. - - Thus, it is specifically permitted for the authority section to - contain only those SIG RRs with the "type covered" field equal to the - type field of an answer being returned. However, where SIG records - are being returned in the answer section, in response to a query for - SIG records, or a query for all records associated with a name - (type=ANY) the entire SIG RRSet must be included, as for any other RR - type. - - Servers that receive responses containing SIG records in the - authority section, or (probably incorrectly) as additional data, must - understand that the entire RRSet has almost certainly not been - included. Thus, they must not cache that SIG record in a way that - would permit it to be returned should a query for SIG records be - received at that server. RFC2065 actually requires that SIG queries - be directed only to authoritative servers to avoid the problems that - could be caused here, and while servers exist that do not understand - the special properties of SIG records, this will remain necessary. - However, careful design of SIG record processing in new - implementations should permit this restriction to be relaxed in the - future, so resolvers do not need to treat SIG record queries - specially. - - - -Elz & Bush Standards Track [Page 5] - -RFC 2181 Clarifications to the DNS Specification July 1997 - - - It has been occasionally stated that a received request for a SIG - record should be forwarded to an authoritative server, rather than - being answered from data in the cache. This is not necessary - a - server that has the knowledge of SIG as a special case for processing - this way would be better to correctly cache SIG records, taking into - account their characteristics. Then the server can determine when it - is safe to reply from the cache, and when the answer is not available - and the query must be forwarded. - -5.3.2. NXT RRs - - Next Resource Records (NXT) are even more peculiar. There will only - ever be one NXT record in a zone for a particular label, so - superficially, the RRSet problem is trivial. However, at a zone cut, - both the parent zone, and the child zone (superzone and subzone in - RFC2065 terminology) will have NXT records for the same name. Those - two NXT records do not form an RRSet, even where both zones are - housed at the same server. NXT RRSets always contain just a single - RR. Where both NXT records are visible, two RRSets exist. However, - servers are not required to treat this as a special case when - receiving NXT records in a response. They may elect to notice the - existence of two different NXT RRSets, and treat that as they would - two different RRSets of any other type. That is, cache one, and - ignore the other. Security aware servers will need to correctly - process the NXT record in the received response though. - -5.4. Receiving RRSets - - Servers must never merge RRs from a response with RRs in their cache - to form an RRSet. If a response contains data that would form an - RRSet with data in a server's cache the server must either ignore the - RRs in the response, or discard the entire RRSet currently in the - cache, as appropriate. Consequently the issue of TTLs varying - between the cache and a response does not cause concern, one will be - ignored. That is, one of the data sets is always incorrect if the - data from an answer differs from the data in the cache. The - challenge for the server is to determine which of the data sets is - correct, if one is, and retain that, while ignoring the other. Note - that if a server receives an answer containing an RRSet that is - identical to that in its cache, with the possible exception of the - TTL value, it may, optionally, update the TTL in its cache with the - TTL of the received answer. It should do this if the received answer - would be considered more authoritative (as discussed in the next - section) than the previously cached answer. - - - - - - - -Elz & Bush Standards Track [Page 6] - -RFC 2181 Clarifications to the DNS Specification July 1997 - - -5.4.1. Ranking data - - When considering whether to accept an RRSet in a reply, or retain an - RRSet already in its cache instead, a server should consider the - relative likely trustworthiness of the various data. An - authoritative answer from a reply should replace cached data that had - been obtained from additional information in an earlier reply. - However additional information from a reply will be ignored if the - cache contains data from an authoritative answer or a zone file. - - The accuracy of data available is assumed from its source. - Trustworthiness shall be, in order from most to least: - - + Data from a primary zone file, other than glue data, - + Data from a zone transfer, other than glue, - + The authoritative data included in the answer section of an - authoritative reply. - + Data from the authority section of an authoritative answer, - + Glue from a primary zone, or glue from a zone transfer, - + Data from the answer section of a non-authoritative answer, and - non-authoritative data from the answer section of authoritative - answers, - + Additional information from an authoritative answer, - Data from the authority section of a non-authoritative answer, - Additional information from non-authoritative answers. - - Note that the answer section of an authoritative answer normally - contains only authoritative data. However when the name sought is an - alias (see section 10.1.1) only the record describing that alias is - necessarily authoritative. Clients should assume that other records - may have come from the server's cache. Where authoritative answers - are required, the client should query again, using the canonical name - associated with the alias. - - Unauthenticated RRs received and cached from the least trustworthy of - those groupings, that is data from the additional data section, and - data from the authority section of a non-authoritative answer, should - not be cached in such a way that they would ever be returned as - answers to a received query. They may be returned as additional - information where appropriate. Ignoring this would allow the - trustworthiness of relatively untrustworthy data to be increased - without cause or excuse. - - When DNS security [RFC2065] is in use, and an authenticated reply has - been received and verified, the data thus authenticated shall be - considered more trustworthy than unauthenticated data of the same - type. Note that throughout this document, "authoritative" means a - reply with the AA bit set. DNSSEC uses trusted chains of SIG and KEY - - - -Elz & Bush Standards Track [Page 7] - -RFC 2181 Clarifications to the DNS Specification July 1997 - - - records to determine the authenticity of data, the AA bit is almost - irrelevant. However DNSSEC aware servers must still correctly set - the AA bit in responses to enable correct operation with servers that - are not security aware (almost all currently). - - Note that, glue excluded, it is impossible for data from two - correctly configured primary zone files, two correctly configured - secondary zones (data from zone transfers) or data from correctly - configured primary and secondary zones to ever conflict. Where glue - for the same name exists in multiple zones, and differs in value, the - nameserver should select data from a primary zone file in preference - to secondary, but otherwise may choose any single set of such data. - Choosing that which appears to come from a source nearer the - authoritative data source may make sense where that can be - determined. Choosing primary data over secondary allows the source - of incorrect glue data to be discovered more readily, when a problem - with such data exists. Where a server can detect from two zone files - that one or more are incorrectly configured, so as to create - conflicts, it should refuse to load the zones determined to be - erroneous, and issue suitable diagnostics. - - "Glue" above includes any record in a zone file that is not properly - part of that zone, including nameserver records of delegated sub- - zones (NS records), address records that accompany those NS records - (A, AAAA, etc), and any other stray data that might appear. - -5.5. Sending RRSets (reprise) - - A Resource Record Set should only be included once in any DNS reply. - It may occur in any of the Answer, Authority, or Additional - Information sections, as required. However it should not be repeated - in the same, or any other, section, except where explicitly required - by a specification. For example, an AXFR response requires the SOA - record (always an RRSet containing a single RR) be both the first and - last record of the reply. Where duplicates are required this way, - the TTL transmitted in each case must be the same. - -6. Zone Cuts - - The DNS tree is divided into "zones", which are collections of - domains that are treated as a unit for certain management purposes. - Zones are delimited by "zone cuts". Each zone cut separates a - "child" zone (below the cut) from a "parent" zone (above the cut). - The domain name that appears at the top of a zone (just below the cut - that separates the zone from its parent) is called the zone's - "origin". The name of the zone is the same as the name of the domain - at the zone's origin. Each zone comprises that subset of the DNS - tree that is at or below the zone's origin, and that is above the - - - -Elz & Bush Standards Track [Page 8] - -RFC 2181 Clarifications to the DNS Specification July 1997 - - - cuts that separate the zone from its children (if any). The - existence of a zone cut is indicated in the parent zone by the - existence of NS records specifying the origin of the child zone. A - child zone does not contain any explicit reference to its parent. - -6.1. Zone authority - - The authoritative servers for a zone are enumerated in the NS records - for the origin of the zone, which, along with a Start of Authority - (SOA) record are the mandatory records in every zone. Such a server - is authoritative for all resource records in a zone that are not in - another zone. The NS records that indicate a zone cut are the - property of the child zone created, as are any other records for the - origin of that child zone, or any sub-domains of it. A server for a - zone should not return authoritative answers for queries related to - names in another zone, which includes the NS, and perhaps A, records - at a zone cut, unless it also happens to be a server for the other - zone. - - Other than the DNSSEC cases mentioned immediately below, servers - should ignore data other than NS records, and necessary A records to - locate the servers listed in the NS records, that may happen to be - configured in a zone at a zone cut. - -6.2. DNSSEC issues - - The DNS security mechanisms [RFC2065] complicate this somewhat, as - some of the new resource record types added are very unusual when - compared with other DNS RRs. In particular the NXT ("next") RR type - contains information about which names exist in a zone, and hence - which do not, and thus must necessarily relate to the zone in which - it exists. The same domain name may have different NXT records in - the parent zone and the child zone, and both are valid, and are not - an RRSet. See also section 5.3.2. - - Since NXT records are intended to be automatically generated, rather - than configured by DNS operators, servers may, but are not required - to, retain all differing NXT records they receive regardless of the - rules in section 5.4. - - For a secure parent zone to securely indicate that a subzone is - insecure, DNSSEC requires that a KEY RR indicating that the subzone - is insecure, and the parent zone's authenticating SIG RR(s) be - present in the parent zone, as they by definition cannot be in the - subzone. Where a subzone is secure, the KEY and SIG records will be - present, and authoritative, in that zone, but should also always be - present in the parent zone (if secure). - - - - -Elz & Bush Standards Track [Page 9] - -RFC 2181 Clarifications to the DNS Specification July 1997 - - - Note that in none of these cases should a server for the parent zone, - not also being a server for the subzone, set the AA bit in any - response for a label at a zone cut. - -7. SOA RRs - - Three minor issues concerning the Start of Zone of Authority (SOA) - Resource Record need some clarification. - -7.1. Placement of SOA RRs in authoritative answers - - RFC1034, in section 3.7, indicates that the authority section of an - authoritative answer may contain the SOA record for the zone from - which the answer was obtained. When discussing negative caching, - RFC1034 section 4.3.4 refers to this technique but mentions the - additional section of the response. The former is correct, as is - implied by the example shown in section 6.2.5 of RFC1034. SOA - records, if added, are to be placed in the authority section. - -7.2. TTLs on SOA RRs - - It may be observed that in section 3.2.1 of RFC1035, which defines - the format of a Resource Record, that the definition of the TTL field - contains a throw away line which states that the TTL of an SOA record - should always be sent as zero to prevent caching. This is mentioned - nowhere else, and has not generally been implemented. - Implementations should not assume that SOA records will have a TTL of - zero, nor are they required to send SOA records with a TTL of zero. - -7.3. The SOA.MNAME field - - It is quite clear in the specifications, yet seems to have been - widely ignored, that the MNAME field of the SOA record should contain - the name of the primary (master) server for the zone identified by - the SOA. It should not contain the name of the zone itself. That - information would be useless, as to discover it, one needs to start - with the domain name of the SOA record - that is the name of the - zone. - -8. Time to Live (TTL) - - The definition of values appropriate to the TTL field in STD 13 is - not as clear as it could be, with respect to how many significant - bits exist, and whether the value is signed or unsigned. It is - hereby specified that a TTL value is an unsigned number, with a - minimum value of 0, and a maximum value of 2147483647. That is, a - maximum of 2^31 - 1. When transmitted, this value shall be encoded - in the less significant 31 bits of the 32 bit TTL field, with the - - - -Elz & Bush Standards Track [Page 10] - -RFC 2181 Clarifications to the DNS Specification July 1997 - - - most significant, or sign, bit set to zero. - - Implementations should treat TTL values received with the most - significant bit set as if the entire value received was zero. - - Implementations are always free to place an upper bound on any TTL - received, and treat any larger values as if they were that upper - bound. The TTL specifies a maximum time to live, not a mandatory - time to live. - -9. The TC (truncated) header bit - - The TC bit should be set in responses only when an RRSet is required - as a part of the response, but could not be included in its entirety. - The TC bit should not be set merely because some extra information - could have been included, but there was insufficient room. This - includes the results of additional section processing. In such cases - the entire RRSet that will not fit in the response should be omitted, - and the reply sent as is, with the TC bit clear. If the recipient of - the reply needs the omitted data, it can construct a query for that - data and send that separately. - - Where TC is set, the partial RRSet that would not completely fit may - be left in the response. When a DNS client receives a reply with TC - set, it should ignore that response, and query again, using a - mechanism, such as a TCP connection, that will permit larger replies. - -10. Naming issues - - It has sometimes been inferred from some sections of the DNS - specification [RFC1034, RFC1035] that a host, or perhaps an interface - of a host, is permitted exactly one authoritative, or official, name, - called the canonical name. There is no such requirement in the DNS. - -10.1. CNAME resource records - - The DNS CNAME ("canonical name") record exists to provide the - canonical name associated with an alias name. There may be only one - such canonical name for any one alias. That name should generally be - a name that exists elsewhere in the DNS, though there are some rare - applications for aliases with the accompanying canonical name - undefined in the DNS. An alias name (label of a CNAME record) may, - if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no - other data. That is, for any label in the DNS (any domain name) - exactly one of the following is true: - - - - - - -Elz & Bush Standards Track [Page 11] - -RFC 2181 Clarifications to the DNS Specification July 1997 - - - + one CNAME record exists, optionally accompanied by SIG, NXT, and - KEY RRs, - + one or more records exist, none being CNAME records, - + the name exists, but has no associated RRs of any type, - + the name does not exist at all. - -10.1.1. CNAME terminology - - It has been traditional to refer to the label of a CNAME record as "a - CNAME". This is unfortunate, as "CNAME" is an abbreviation of - "canonical name", and the label of a CNAME record is most certainly - not a canonical name. It is, however, an entrenched usage. Care - must therefore be taken to be very clear whether the label, or the - value (the canonical name) of a CNAME resource record is intended. - In this document, the label of a CNAME resource record will always be - referred to as an alias. - -10.2. PTR records - - Confusion about canonical names has lead to a belief that a PTR - record should have exactly one RR in its RRSet. This is incorrect, - the relevant section of RFC1034 (section 3.6.2) indicates that the - value of a PTR record should be a canonical name. That is, it should - not be an alias. There is no implication in that section that only - one PTR record is permitted for a name. No such restriction should - be inferred. - - Note that while the value of a PTR record must not be an alias, there - is no requirement that the process of resolving a PTR record not - encounter any aliases. The label that is being looked up for a PTR - value might have a CNAME record. That is, it might be an alias. The - value of that CNAME RR, if not another alias, which it should not be, - will give the location where the PTR record is found. That record - gives the result of the PTR type lookup. This final result, the - value of the PTR RR, is the label which must not be an alias. - -10.3. MX and NS records - - The domain name used as the value of a NS resource record, or part of - the value of a MX resource record must not be an alias. Not only is - the specification clear on this point, but using an alias in either - of these positions neither works as well as might be hoped, nor well - fulfills the ambition that may have led to this approach. This - domain name must have as its value one or more address records. - Currently those will be A records, however in the future other record - types giving addressing information may be acceptable. It can also - have other RRs, but never a CNAME RR. - - - - -Elz & Bush Standards Track [Page 12] - -RFC 2181 Clarifications to the DNS Specification July 1997 - - - Searching for either NS or MX records causes "additional section - processing" in which address records associated with the value of the - record sought are appended to the answer. This helps avoid needless - extra queries that are easily anticipated when the first was made. - - Additional section processing does not include CNAME records, let - alone the address records that may be associated with the canonical - name derived from the alias. Thus, if an alias is used as the value - of an NS or MX record, no address will be returned with the NS or MX - value. This can cause extra queries, and extra network burden, on - every query. It is trivial for the DNS administrator to avoid this - by resolving the alias and placing the canonical name directly in the - affected record just once when it is updated or installed. In some - particular hard cases the lack of the additional section address - records in the results of a NS lookup can cause the request to fail. - -11. Name syntax - - Occasionally it is assumed that the Domain Name System serves only - the purpose of mapping Internet host names to data, and mapping - Internet addresses to host names. This is not correct, the DNS is a - general (if somewhat limited) hierarchical database, and can store - almost any kind of data, for almost any purpose. - - The DNS itself places only one restriction on the particular labels - that can be used to identify resource records. That one restriction - relates to the length of the label and the full name. The length of - any one label is limited to between 1 and 63 octets. A full domain - name is limited to 255 octets (including the separators). The zero - length full name is defined as representing the root of the DNS tree, - and is typically written and displayed as ".". Those restrictions - aside, any binary string whatever can be used as the label of any - resource record. Similarly, any binary string can serve as the value - of any record that includes a domain name as some or all of its value - (SOA, NS, MX, PTR, CNAME, and any others that may be added). - Implementations of the DNS protocols must not place any restrictions - on the labels that can be used. In particular, DNS servers must not - refuse to serve a zone because it contains labels that might not be - acceptable to some DNS client programs. A DNS server may be - configurable to issue warnings when loading, or even to refuse to - load, a primary zone containing labels that might be considered - questionable, however this should not happen by default. - - Note however, that the various applications that make use of DNS data - can have restrictions imposed on what particular values are - acceptable in their environment. For example, that any binary label - can have an MX record does not imply that any binary name can be used - as the host part of an e-mail address. Clients of the DNS can impose - - - -Elz & Bush Standards Track [Page 13] - -RFC 2181 Clarifications to the DNS Specification July 1997 - - - whatever restrictions are appropriate to their circumstances on the - values they use as keys for DNS lookup requests, and on the values - returned by the DNS. If the client has such restrictions, it is - solely responsible for validating the data from the DNS to ensure - that it conforms before it makes any use of that data. - - See also [RFC1123] section 6.1.3.5. - -12. Security Considerations - - This document does not consider security. - - In particular, nothing in section 4 is any way related to, or useful - for, any security related purposes. - - Section 5.4.1 is also not related to security. Security of DNS data - will be obtained by the Secure DNS [RFC2065], which is mostly - orthogonal to this memo. - - It is not believed that anything in this document adds to any - security issues that may exist with the DNS, nor does it do anything - to that will necessarily lessen them. Correct implementation of the - clarifications in this document might play some small part in - limiting the spread of non-malicious bad data in the DNS, but only - DNSSEC can help with deliberate attempts to subvert DNS data. - -13. References - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - [RFC1123] Braden, R., "Requirements for Internet Hosts - application - and support", STD 3, RFC 1123, January 1989. - - [RFC1700] Reynolds, J., Postel, J., "Assigned Numbers", - STD 2, RFC 1700, October 1994. - - [RFC2065] Eastlake, D., Kaufman, C., "Domain Name System Security - Extensions", RFC 2065, January 1997. - - - - - - - - - -Elz & Bush Standards Track [Page 14] - -RFC 2181 Clarifications to the DNS Specification July 1997 - - -14. Acknowledgements - - This memo arose from discussions in the DNSIND working group of the - IETF in 1995 and 1996, the members of that working group are largely - responsible for the ideas captured herein. Particular thanks to - Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the - DNSSEC issues in this document, and to John Gilmore for pointing out - where the clarifications were not necessarily clarifying. Bob Halley - suggested clarifying the placement of SOA records in authoritative - answers, and provided the references. Michael Patton, as usual, and - Mark Andrews, Alan Barrett and Stan Barber provided much assistance - with many details. Josh Littlefield helped make sure that the - clarifications didn't cause problems in some irritating corner cases. - -15. Authors' Addresses - - Robert Elz - Computer Science - University of Melbourne - Parkville, Victoria, 3052 - Australia. - - EMail: kre@munnari.OZ.AU - - - Randy Bush - RGnet, Inc. - 5147 Crystal Springs Drive NE - Bainbridge Island, Washington, 98110 - United States. - - EMail: randy@psg.com - - - - - - - - - - - - - - - - - - - -Elz & Bush Standards Track [Page 15] diff --git a/contrib/bind9/doc/rfc/rfc2230.txt b/contrib/bind9/doc/rfc/rfc2230.txt deleted file mode 100644 index 03995fe25bd1..000000000000 --- a/contrib/bind9/doc/rfc/rfc2230.txt +++ /dev/null @@ -1,619 +0,0 @@ - - - - - - -Network Working Group R. Atkinson -Request for Comments: 2230 NRL -Category: Informational November 1997 - - - Key Exchange Delegation Record for the DNS - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1997). All Rights Reserved. - -ABSTRACT - - This note describes a mechanism whereby authorisation for one node to - act as key exchanger for a second node is delegated and made - available via the Secure DNS. This mechanism is intended to be used - only with the Secure DNS. It can be used with several security - services. For example, a system seeking to use IP Security [RFC- - 1825, RFC-1826, RFC-1827] to protect IP packets for a given - destination can use this mechanism to determine the set of authorised - remote key exchanger systems for that destination. - -1. INTRODUCTION - - - The Domain Name System (DNS) is the standard way that Internet nodes - locate information about addresses, mail exchangers, and other data - relating to remote Internet nodes. [RFC-1035, RFC-1034] More - recently, Eastlake and Kaufman have defined standards-track security - extensions to the DNS. [RFC-2065] These security extensions can be - used to authenticate signed DNS data records and can also be used to - store signed public keys in the DNS. - - The KX record is useful in providing an authenticatible method of - delegating authorisation for one node to provide key exchange - services on behalf of one or more, possibly different, nodes. This - note specifies the syntax and semantics of the KX record, which is - currently in limited deployment in certain IP-based networks. The - - - - - - - -Atkinson Informational [Page 1] - -RFC 2230 DNS Key Exchange Delegation Record November 1997 - - - reader is assumed to be familiar with the basics of DNS, including - familiarity with [RFC-1035, RFC-1034]. This document is not on the - IETF standards-track and does not specify any level of standard. - This document merely provides information for the Internet community. - -1.1 Identity Terminology - - This document relies upon the concept of "identity domination". This - concept might be new to the reader and so is explained in this - section. The subject of endpoint naming for security associations - has historically been somewhat contentious. This document takes no - position on what forms of identity should be used. In a network, - there are several forms of identity that are possible. - - For example, IP Security has defined notions of identity that - include: IP Address, IP Address Range, Connection ID, Fully-Qualified - Domain Name (FQDN), and User with Fully Qualified Domain Name (USER - FQDN). - - A USER FQDN identity dominates a FQDN identity. A FQDN identity in - turn dominates an IP Address identity. Similarly, a Connection ID - dominates an IP Address identity. An IP Address Range dominates each - IP Address identity for each IP address within that IP address range. - Also, for completeness, an IP Address identity is considered to - dominate itself. - -2. APPROACH - - This document specifies a new kind of DNS Resource Record (RR), known - as the Key Exchanger (KX) record. A Key Exchanger Record has the - mnemonic "KX" and the type code of 36. Each KX record is associated - with a fully-qualified domain name. The KX record is modeled on the - MX record described in [Part86]. Any given domain, subdomain, or host - entry in the DNS might have a KX record. - -2.1 IPsec Examples - - In these two examples, let S be the originating node and let D be the - destination node. S2 is another node on the same subnet as S. D2 is - another node on the same subnet as D. R1 and R2 are IPsec-capable - routers. The path from S to D goes via first R1 and later R2. The - return path from D to S goes via first R2 and later R1. - - IETF-standard IP Security uses unidirectional Security Associations - [RFC-1825]. Therefore, a typical IP session will use a pair of - related Security Associations, one in each direction. The examples - below talk about how to setup an example Security Association, but in - practice a pair of matched Security Associations will normally be - - - -Atkinson Informational [Page 2] - -RFC 2230 DNS Key Exchange Delegation Record November 1997 - - - used. - -2.1.1 Subnet-to-Subnet Example - - If neither S nor D implements IPsec, security can still be provided - between R1 and R2 by building a secure tunnel. This can use either - AH or ESP. - - S ---+ +----D - | | - +- R1 -----[zero or more routers]-------R2-+ - | | - S2---+ +----D2 - - Figure 1: Network Diagram for Subnet-to-Subnet Example - - In this example, R1 makes the policy decision to provide the IPsec - service for traffic from R1 destined for R2. Once R1 has decided - that the packet from S to D should be protected, it performs a secure - DNS lookup for the records associated with domain D. If R1 only - knows the IP address for D, then a secure reverse DNS lookup will be - necessary to determine the domain D, before that forward secure DNS - lookup for records associated with domain D. If these DNS records of - domain D include a KX record for the IPsec service, then R1 knows - which set of nodes are authorised key exchanger nodes for the - destination D. - - In this example, let there be at least one KX record for D and let - the most preferred KX record for D point at R2. R1 then selects a - key exchanger (in this example, R2) for D from the list obtained from - the secure DNS. Then R1 initiates a key management session with that - key exchanger (in this example, R2) to setup an IPsec Security - Association between R1 and D. In this example, R1 knows (either by - seeing an outbound packet arriving from S destined to D or via other - methods) that S will be sending traffic to D. In this example R1's - policy requires that traffic from S to D should be segregated at - least on a host-to-host basis, so R1 desires an IPsec Security - Association with source identity that dominates S, proxy identity - that dominates R1, and destination identity that dominates R2. - - In turn, R2 is able to authenticate the delegation of Key Exchanger - authorisation for target S to R1 by making an authenticated forward - DNS lookup for KX records associated with S and verifying that at - least one such record points to R1. The identity S is typically - given to R2 as part of the key management process between R1 and R2. - - - - - - -Atkinson Informational [Page 3] - -RFC 2230 DNS Key Exchange Delegation Record November 1997 - - - If D initially only knows the IP address of S, then it will need to - perform a secure reverse DNS lookup to obtain the fully-qualified - domain name for S prior to that secure forward DNS lookup. - - If R2 does not receive an authenticated DNS response indicating that - R1 is an authorised key exchanger for S, then D will not accept the - SA negotiation from R1 on behalf of identity S. - - If the proposed IPsec Security Association is acceptable to both R1 - and R2, each of which might have separate policies, then they create - that IPsec Security Association via Key Management. - - Note that for unicast traffic, Key Management will typically also - setup a separate (but related) IPsec Security Association for the - return traffic. That return IPsec Security Association will have - equivalent identities. In this example, that return IPsec Security - Association will have a source identity that dominates D, a proxy - identity that dominates R2, and a destination identity that dominates - R1. - - Once the IPsec Security Association has been created, then R1 uses it - to protect traffic from S destined for D via a secure tunnel that - originates at R1 and terminates at R2. For the case of unicast, R2 - will use the return IPsec Security Association to protect traffic - from D destined for S via a secure tunnel that originates at R2 and - terminates at R1. - -2.1.2 Subnet-to-Host Example - - Consider the case where D and R1 implement IPsec, but S does not - implement IPsec, which is an interesting variation on the previous - example. This example is shown in Figure 2 below. - - S ---+ - | - +- R1 -----[zero or more routers]-------D - | - S2---+ - - Figure 2: Network Diagram for Subnet-to-Host Example - - In this example, R1 makes the policy decision that IP Security is - needed for the packet travelling from S to D. Then, R1 performs the - secure DNS lookup for D and determines that D is its own key - exchanger, either from the existence of a KX record for D pointing to - D or from an authenticated DNS response indicating that no KX record - exists for D. If R1 does not initially know the domain name of D, - then prior to the above forward secure DNS lookup, R1 performs a - - - -Atkinson Informational [Page 4] - -RFC 2230 DNS Key Exchange Delegation Record November 1997 - - - secure reverse DNS lookup on the IP address of D to determine the - fully-qualified domain name for that IP address. R1 then initiates - key management with D to create an IPsec Security Association on - behalf of S. - - In turn, D can verify that R1 is authorised to create an IPsec - Security Association on behalf of S by performing a DNS KX record - lookup for target S. R1 usually provides identity S to D via key - management. If D only has the IP address of S, then D will need to - perform a secure reverse lookup on the IP address of S to determine - domain name S prior to the secure forward DNS lookup on S to locate - the KX records for S. - - If D does not receive an authenticated DNS response indicating that - R1 is an authorised key exchanger for S, then D will not accept the - SA negotiation from R1 on behalf of identity S. - - If the IPsec Security Association is successfully established between - R1 and D, that IPsec Security Association has a source identity that - dominates S's IP address, a proxy identity that dominates R1's IP - address, and a destination identity that dominates D's IP address. - - Finally, R1 begins providing the security service for packets from S - that transit R1 destined for D. When D receives such packets, D - examines the SA information during IPsec input processing and sees - that R1's address is listed as valid proxy address for that SA and - that S is the source address for that SA. Hence, D knows at input - processing time that R1 is authorised to provide security on behalf - of S. Therefore packets coming from R1 with valid IP security that - claim to be from S are trusted by D to have really come from S. - -2.1.3 Host to Subnet Example - - Now consider the above case from D's perspective (i.e. where D is - sending IP packets to S). This variant is sometimes known as the - Mobile Host or "roadwarrier" case. The same basic concepts apply, but - the details are covered here in hope of improved clarity. - - S ---+ - | - +- R1 -----[zero or more routers]-------D - | - S2---+ - - Figure 3: Network Diagram for Host-to-Subnet Example - - - - - - -Atkinson Informational [Page 5] - -RFC 2230 DNS Key Exchange Delegation Record November 1997 - - - In this example, D makes the policy decision that IP Security is - needed for the packets from D to S. Then D performs the secure DNS - lookup for S and discovers that a KX record for S exists and points - at R1. If D only has the IP address of S, then it performs a secure - reverse DNS lookup on the IP address of S prior to the forward secure - DNS lookup for S. - - D then initiates key management with R1, where R1 is acting on behalf - of S, to create an appropriate Security Association. Because D is - acting as its own key exchanger, R1 does not need to perform a secure - DNS lookup for KX records associated with D. - - D and R1 then create an appropriate IPsec Security Security - Association. This IPsec Security Association is setup as a secure - tunnel with a source identity that dominates D's IP Address and a - destination identity that dominates R1's IP Address. Because D - performs IPsec for itself, no proxy identity is needed in this IPsec - Security Association. If the proxy identity is non-null in this - situation, then the proxy identity must dominate D's IP Address. - - Finally, D sends secured IP packets to R1. R1 receives those - packets, provides IPsec input processing (including appropriate - inner/outer IP address validation), and forwards valid packets along - to S. - -2.2 Other Examples - - This mechanism can be extended for use with other services as well. - To give some insight into other possible uses, this section discusses - use of KX records in environments using a Key Distribution Center - (KDC), such as Kerberos [KN93], and a possible use of KX records in - conjunction with mobile nodes accessing the network via a dialup - service. - -2.2.1 KDC Examples - - This example considers the situation of a destination node - implementing IPsec that can only obtain its Security Association - information from a Key Distribution Center (KDC). Let the KDC - implement both the KDC protocol and also a non-KDC key management - protocol (e.g. ISAKMP). In such a case, each client node of the KDC - might have its own KX record pointing at the KDC so that nodes not - implementing the KDC protocol can still create Security Associations - with each of the client nodes of the KDC. - - In the event the session initiator were not using the KDC but the - session target was an IPsec node that only used the KDC, the - initiator would find the KX record for the target pointing at the - - - -Atkinson Informational [Page 6] - -RFC 2230 DNS Key Exchange Delegation Record November 1997 - - - KDC. Then, the external key management exchange (e.g. ISAKMP) would - be between the initiator and the KDC. Then the KDC would distribute - the IPsec SA to the KDC-only IPsec node using the KDC. The IPsec - traffic itself could travel directly between the initiator and the - destination node. - - In the event the initiator node could only use the KDC and the target - were not using the KDC, the initiator would send its request for a - key to the KDC. The KDC would then initiate an external key - management exchange (e.g. ISAKMP) with a node that the target's KX - record(s) pointed to, on behalf of the initiator node. - - The target node could verify that the KDC were allowed to proxy for - the initiator node by looking up the KX records for the initiator - node and finding a KX record for the initiator that listed the KDC. - - Then the external key exchange would be performed between the KDC and - the target node. Then the KDC would distribute the resulting IPsec - Security Association to the initiator. Again, IPsec traffic itself - could travel directly between the initiator and the destination. - -2.2.2 Dial-Up Host Example - - This example outlines a possible use of KX records with mobile hosts - that dial into the network via PPP and are dynamically assigned an IP - address and domain-name at dial-in time. - - Consider the situation where each mobile node is dynamically assigned - both a domain name and an IP address at the time that node dials into - the network. Let the policy require that each mobile node act as its - own Key Exchanger. In this case, it is important that dial-in nodes - use addresses from one or more well known IP subnets or address pools - dedicated to dial-in access. If that is true, then no KX record or - other action is needed to ensure that each node will act as its own - Key Exchanger because lack of a KX record indicates that the node is - its own Key Exchanger. - - Consider the situation where the mobile node's domain name remains - constant but its IP address changes. Let the policy require that - each mobile node act as its own Key Exchanger. In this case, there - might be operational problems when another node attempts to perform a - secure reverse DNS lookup on the IP address to determine the - corresponding domain name. The authenticated DNS binding (in the - form of a PTR record) between the mobile node's currently assigned IP - address and its permanent domain name will need to be securely - updated each time the node is assigned a new IP address. There are - no mechanisms for accomplishing this that are both IETF-standard and - widely deployed as of the time this note was written. Use of Dynamic - - - -Atkinson Informational [Page 7] - -RFC 2230 DNS Key Exchange Delegation Record November 1997 - - - DNS Update without authentication is a significant security risk and - hence is not recommended for this situation. - -3. SYNTAX OF KX RECORD - - A KX record has the DNS TYPE of "KX" and a numeric value of 36. A KX - record is a member of the Internet ("IN") CLASS in the DNS. Each KX - record is associated with a <domain-name> entry in the DNS. A KX - record has the following textual syntax: - - <domain-name> IN KX <preference> <domain-name> - - For this description, let the <domain-name> item to the left of the - "KX" string be called <domain-name 1> and the <domain-name> item to - the right of the "KX" string be called <domain-name 2>. <preference> - is a non-negative integer. - - Internet nodes about to initiate a key exchange with <domain-name 1> - should instead contact <domain-name 2> to initiate the key exchange - for a security service between the initiator and <domain-name 2>. If - more than one KX record exists for <domain-name 1>, then the - <preference> field is used to indicate preference among the systems - delegated to. Lower values are preferred over higher values. The - <domain-name 2> is authorised to provide key exchange services on - behalf of <domain-name 1>. The <domain-name 2> MUST have a CNAME - record, an A record, or an AAAA record associated with it. - -3.1 KX RDATA format - - The KX DNS record has the following RDATA format: - - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | PREFERENCE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / EXCHANGER / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - where: - - PREFERENCE A 16 bit non-negative integer which specifies the - preference given to this RR among other KX records - at the same owner. Lower values are preferred. - - EXCHANGER A <domain-name> which specifies a host willing to - act as a mail exchange for the owner name. - - - - - -Atkinson Informational [Page 8] - -RFC 2230 DNS Key Exchange Delegation Record November 1997 - - - KX records MUST cause type A additional section processing for the - host specified by EXCHANGER. In the event that the host processing - the DNS transaction supports IPv6, KX records MUST also cause type - AAAA additional section processing. - - The KX RDATA field MUST NOT be compressed. - -4. SECURITY CONSIDERATIONS - - KX records MUST always be signed using the method(s) defined by the - DNS Security extensions specified in [RFC-2065]. All unsigned KX - records MUST be ignored because of the security vulnerability caused - by assuming that unsigned records are valid. All signed KX records - whose signatures do not correctly validate MUST be ignored because of - the potential security vulnerability in trusting an invalid KX - record. - - KX records MUST be ignored by systems not implementing Secure DNS - because such systems have no mechanism to authenticate the KX record. - - If a node does not have a permanent DNS entry and some form of - Dynamic DNS Update is in use, then those dynamic DNS updates MUST be - fully authenticated to prevent an adversary from injecting false DNS - records (especially the KX, A, and PTR records) into the Domain Name - System. If false records were inserted into the DNS without being - signed by the Secure DNS mechanisms, then a denial-of-service attack - results. If false records were inserted into the DNS and were - (erroneously) signed by the signing authority, then an active attack - results. - - Myriad serious security vulnerabilities can arise if the restrictions - throuhout this document are not strictly adhered to. Implementers - should carefully consider the openly published issues relating to DNS - security [Bell95,Vixie95] as they build their implementations. - Readers should also consider the security considerations discussed in - the DNS Security Extensions document [RFC-2065]. - -5. REFERENCES - - - [RFC-1825] Atkinson, R., "IP Authentication Header", RFC 1826, - August 1995. - - [RFC-1827] Atkinson, R., "IP Encapsulating Security Payload", - RFC 1827, August 1995. - - - - - - -Atkinson Informational [Page 9] - -RFC 2230 DNS Key Exchange Delegation Record November 1997 - - - [Bell95] Bellovin, S., "Using the Domain Name System for System - Break-ins", Proceedings of 5th USENIX UNIX Security - Symposium, USENIX Association, Berkeley, CA, June 1995. - ftp://ftp.research.att.com/dist/smb/dnshack.ps - - [RFC-2065] Eastlake, D., and C. Kaufman, "Domain Name System - Security Extensions", RFC 2065, January 1997. - - [RFC-1510] Kohl J., and C. Neuman, "The Kerberos Network - Authentication Service", RFC 1510, September 1993. - - [RFC-1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC-1034] Mockapetris, P., "Domain names - concepts and - facilities", STD 13, RFC 1034, November 1987. - - [Vixie95] P. Vixie, "DNS and BIND Security Issues", Proceedings of - the 5th USENIX UNIX Security Symposium, USENIX - Association, Berkeley, CA, June 1995. - ftp://ftp.vix.com/pri/vixie/bindsec.psf - -ACKNOWLEDGEMENTS - - Development of this DNS record was primarily performed during 1993 - through 1995. The author's work on this was sponsored jointly by the - Computing Systems Technology Office (CSTO) of the Advanced Research - Projects Agency (ARPA) and by the Information Security Program Office - (PD71E), Space & Naval Warface Systems Command (SPAWAR). In that - era, Dave Mihelcic and others provided detailed review and - constructive feedback. More recently, Bob Moscowitz and Todd Welch - provided detailed review and constructive feedback of a work in - progress version of this document. - -AUTHOR'S ADDRESS - - Randall Atkinson - Code 5544 - Naval Research Laboratory - 4555 Overlook Avenue, SW - Washington, DC 20375-5337 - - Phone: (DSN) 354-8590 - EMail: atkinson@itd.nrl.navy.mil - - - - - - - -Atkinson Informational [Page 10] - -RFC 2230 DNS Key Exchange Delegation Record November 1997 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1997). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implmentation may be prepared, copied, published - andand distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Atkinson Informational [Page 11] - diff --git a/contrib/bind9/doc/rfc/rfc2308.txt b/contrib/bind9/doc/rfc/rfc2308.txt deleted file mode 100644 index 9123a9527a81..000000000000 --- a/contrib/bind9/doc/rfc/rfc2308.txt +++ /dev/null @@ -1,1067 +0,0 @@ - - - - - - -Network Working Group M. Andrews -Request for Comments: 2308 CSIRO -Updates: 1034, 1035 March 1998 -Category: Standards Track - - - Negative Caching of DNS Queries (DNS NCACHE) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -Abstract - - [RFC1034] provided a description of how to cache negative responses. - It however had a fundamental flaw in that it did not allow a name - server to hand out those cached responses to other resolvers, thereby - greatly reducing the effect of the caching. This document addresses - issues raise in the light of experience and replaces [RFC1034 Section - 4.3.4]. - - Negative caching was an optional part of the DNS specification and - deals with the caching of the non-existence of an RRset [RFC2181] or - domain name. - - Negative caching is useful as it reduces the response time for - negative answers. It also reduces the number of messages that have - to be sent between resolvers and name servers hence overall network - traffic. A large proportion of DNS traffic on the Internet could be - eliminated if all resolvers implemented negative caching. With this - in mind negative caching should no longer be seen as an optional part - of a DNS resolver. - - - - - - - - - - - -Andrews Standards Track [Page 1] - -RFC 2308 DNS NCACHE March 1998 - - -1 - Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - "Negative caching" - the storage of knowledge that something does not - exist. We can store the knowledge that a record has a particular - value. We can also do the reverse, that is, to store the knowledge - that a record does not exist. It is the storage of knowledge that - something does not exist, cannot or does not give an answer that we - call negative caching. - - "QNAME" - the name in the query section of an answer, or where this - resolves to a CNAME, or CNAME chain, the data field of the last - CNAME. The last CNAME in this sense is that which contains a value - which does not resolve to another CNAME. Implementations should note - that including CNAME records in responses in order, so that the first - has the label from the query section, and then each in sequence has - the label from the data section of the previous (where more than one - CNAME is needed) allows the sequence to be processed in one pass, and - considerably eases the task of the receiver. Other relevant records - (such as SIG RRs [RFC2065]) can be interspersed amongst the CNAMEs. - - "NXDOMAIN" - an alternate expression for the "Name Error" RCODE as - described in [RFC1035 Section 4.1.1] and the two terms are used - interchangeably in this document. - - "NODATA" - a pseudo RCODE which indicates that the name is valid, for - the given class, but are no records of the given type. A NODATA - response has to be inferred from the answer. - - "FORWARDER" - a nameserver used to resolve queries instead of - directly using the authoritative nameserver chain. The forwarder - typically either has better access to the internet, or maintains a - bigger cache which may be shared amongst many resolvers. How a - server is identified as a FORWARDER, or knows it is a FORWARDER is - outside the scope of this document. However if you are being used as - a forwarder the query will have the recursion desired flag set. - - An understanding of [RFC1034], [RFC1035] and [RFC2065] is expected - when reading this document. - - - - - - - - - -Andrews Standards Track [Page 2] - -RFC 2308 DNS NCACHE March 1998 - - -2 - Negative Responses - - The most common negative responses indicate that a particular RRset - does not exist in the DNS. The first sections of this document deal - with this case. Other negative responses can indicate failures of a - nameserver, those are dealt with in section 7 (Other Negative - Responses). - - A negative response is indicated by one of the following conditions: - -2.1 - Name Error - - Name errors (NXDOMAIN) are indicated by the presence of "Name Error" - in the RCODE field. In this case the domain referred to by the QNAME - does not exist. Note: the answer section may have SIG and CNAME RRs - and the authority section may have SOA, NXT [RFC2065] and SIG RRsets. - - It is possible to distinguish between a referral and a NXDOMAIN - response by the presense of NXDOMAIN in the RCODE regardless of the - presence of NS or SOA records in the authority section. - - NXDOMAIN responses can be categorised into four types by the contents - of the authority section. These are shown below along with a - referral for comparison. Fields not mentioned are not important in - terms of the examples. - - NXDOMAIN RESPONSE: TYPE 1. - - Header: - RDCODE=NXDOMAIN - Query: - AN.EXAMPLE. A - Answer: - AN.EXAMPLE. CNAME TRIPPLE.XX. - Authority: - XX. SOA NS1.XX. HOSTMASTER.NS1.XX. .... - XX. NS NS1.XX. - XX. NS NS2.XX. - Additional: - NS1.XX. A 127.0.0.2 - NS2.XX. A 127.0.0.3 - - NXDOMAIN RESPONSE: TYPE 2. - - Header: - RDCODE=NXDOMAIN - Query: - AN.EXAMPLE. A - - - -Andrews Standards Track [Page 3] - -RFC 2308 DNS NCACHE March 1998 - - - Answer: - AN.EXAMPLE. CNAME TRIPPLE.XX. - Authority: - XX. SOA NS1.XX. HOSTMASTER.NS1.XX. .... - Additional: - <empty> - - NXDOMAIN RESPONSE: TYPE 3. - - Header: - RDCODE=NXDOMAIN - Query: - AN.EXAMPLE. A - Answer: - AN.EXAMPLE. CNAME TRIPPLE.XX. - Authority: - <empty> - Additional: - <empty> - - NXDOMAIN RESPONSE: TYPE 4 - - Header: - RDCODE=NXDOMAIN - Query: - AN.EXAMPLE. A - Answer: - AN.EXAMPLE. CNAME TRIPPLE.XX. - Authority: - XX. NS NS1.XX. - XX. NS NS2.XX. - Additional: - NS1.XX. A 127.0.0.2 - NS2.XX. A 127.0.0.3 - - REFERRAL RESPONSE. - - Header: - RDCODE=NOERROR - Query: - AN.EXAMPLE. A - Answer: - AN.EXAMPLE. CNAME TRIPPLE.XX. - Authority: - XX. NS NS1.XX. - XX. NS NS2.XX. - Additional: - NS1.XX. A 127.0.0.2 - - - -Andrews Standards Track [Page 4] - -RFC 2308 DNS NCACHE March 1998 - - - NS2.XX. A 127.0.0.3 - - Note, in the four examples of NXDOMAIN responses, it is known that - the name "AN.EXAMPLE." exists, and has as its value a CNAME record. - The NXDOMAIN refers to "TRIPPLE.XX", which is then known not to - exist. On the other hand, in the referral example, it is shown that - "AN.EXAMPLE" exists, and has a CNAME RR as its value, but nothing is - known one way or the other about the existence of "TRIPPLE.XX", other - than that "NS1.XX" or "NS2.XX" can be consulted as the next step in - obtaining information about it. - - Where no CNAME records appear, the NXDOMAIN response refers to the - name in the label of the RR in the question section. - -2.1.1 Special Handling of Name Error - - This section deals with errors encountered when implementing negative - caching of NXDOMAIN responses. - - There are a large number of resolvers currently in existence that - fail to correctly detect and process all forms of NXDOMAIN response. - Some resolvers treat a TYPE 1 NXDOMAIN response as a referral. To - alleviate this problem it is recommended that servers that are - authoritative for the NXDOMAIN response only send TYPE 2 NXDOMAIN - responses, that is the authority section contains a SOA record and no - NS records. If a non- authoritative server sends a type 1 NXDOMAIN - response to one of these old resolvers, the result will be an - unnecessary query to an authoritative server. This is undesirable, - but not fatal except when the server is being used a FORWARDER. If - however the resolver is using the server as a FORWARDER to such a - resolver it will be necessary to disable the sending of TYPE 1 - NXDOMAIN response to it, use TYPE 2 NXDOMAIN instead. - - Some resolvers incorrectly continue processing if the authoritative - answer flag is not set, looping until the query retry threshold is - exceeded and then returning SERVFAIL. This is a problem when your - nameserver is listed as a FORWARDER for such resolvers. If the - nameserver is used as a FORWARDER by such resolver, the authority - flag will have to be forced on for NXDOMAIN responses to these - resolvers. In practice this causes no problems even if turned on - always, and has been the default behaviour in BIND from 4.9.3 - onwards. - -2.2 - No Data - - NODATA is indicated by an answer with the RCODE set to NOERROR and no - relevant answers in the answer section. The authority section will - contain an SOA record, or there will be no NS records there. - - - -Andrews Standards Track [Page 5] - -RFC 2308 DNS NCACHE March 1998 - - - NODATA responses have to be algorithmically determined from the - response's contents as there is no RCODE value to indicate NODATA. - In some cases to determine with certainty that NODATA is the correct - response it can be necessary to send another query. - - The authority section may contain NXT and SIG RRsets in addition to - NS and SOA records. CNAME and SIG records may exist in the answer - section. - - It is possible to distinguish between a NODATA and a referral - response by the presence of a SOA record in the authority section or - the absence of NS records in the authority section. - - NODATA responses can be categorised into three types by the contents - of the authority section. These are shown below along with a - referral for comparison. Fields not mentioned are not important in - terms of the examples. - - NODATA RESPONSE: TYPE 1. - - Header: - RDCODE=NOERROR - Query: - ANOTHER.EXAMPLE. A - Answer: - <empty> - Authority: - EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. .... - EXAMPLE. NS NS1.XX. - EXAMPLE. NS NS2.XX. - Additional: - NS1.XX. A 127.0.0.2 - NS2.XX. A 127.0.0.3 - - NO DATA RESPONSE: TYPE 2. - - Header: - RDCODE=NOERROR - Query: - ANOTHER.EXAMPLE. A - Answer: - <empty> - Authority: - EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. .... - Additional: - <empty> - - - - - -Andrews Standards Track [Page 6] - -RFC 2308 DNS NCACHE March 1998 - - - NO DATA RESPONSE: TYPE 3. - - Header: - RDCODE=NOERROR - Query: - ANOTHER.EXAMPLE. A - Answer: - <empty> - Authority: - <empty> - Additional: - <empty> - - REFERRAL RESPONSE. - - Header: - RDCODE=NOERROR - Query: - ANOTHER.EXAMPLE. A - Answer: - <empty> - Authority: - EXAMPLE. NS NS1.XX. - EXAMPLE. NS NS2.XX. - Additional: - NS1.XX. A 127.0.0.2 - NS2.XX. A 127.0.0.3 - - - These examples, unlike the NXDOMAIN examples above, have no CNAME - records, however they could, in just the same way that the NXDOMAIN - examples did, in which case it would be the value of the last CNAME - (the QNAME) for which NODATA would be concluded. - -2.2.1 - Special Handling of No Data - - There are a large number of resolvers currently in existence that - fail to correctly detect and process all forms of NODATA response. - Some resolvers treat a TYPE 1 NODATA response as a referral. To - alleviate this problem it is recommended that servers that are - authoritative for the NODATA response only send TYPE 2 NODATA - responses, that is the authority section contains a SOA record and no - NS records. Sending a TYPE 1 NODATA response from a non- - authoritative server to one of these resolvers will only result in an - unnecessary query. If a server is listed as a FORWARDER for another - resolver it may also be necessary to disable the sending of TYPE 1 - NODATA response for non-authoritative NODATA responses. - - - - -Andrews Standards Track [Page 7] - -RFC 2308 DNS NCACHE March 1998 - - - Some name servers fail to set the RCODE to NXDOMAIN in the presence - of CNAMEs in the answer section. If a definitive NXDOMAIN / NODATA - answer is required in this case the resolver must query again using - the QNAME as the query label. - -3 - Negative Answers from Authoritative Servers - - Name servers authoritative for a zone MUST include the SOA record of - the zone in the authority section of the response when reporting an - NXDOMAIN or indicating that no data of the requested type exists. - This is required so that the response may be cached. The TTL of this - record is set from the minimum of the MINIMUM field of the SOA record - and the TTL of the SOA itself, and indicates how long a resolver may - cache the negative answer. The TTL SIG record associated with the - SOA record should also be trimmed in line with the SOA's TTL. - - If the containing zone is signed [RFC2065] the SOA and appropriate - NXT and SIG records MUST be added. - -4 - SOA Minimum Field - - The SOA minimum field has been overloaded in the past to have three - different meanings, the minimum TTL value of all RRs in a zone, the - default TTL of RRs which did not contain a TTL value and the TTL of - negative responses. - - Despite being the original defined meaning, the first of these, the - minimum TTL value of all RRs in a zone, has never in practice been - used and is hereby deprecated. - - The second, the default TTL of RRs which contain no explicit TTL in - the master zone file, is relevant only at the primary server. After - a zone transfer all RRs have explicit TTLs and it is impossible to - determine whether the TTL for a record was explicitly set or derived - from the default after a zone transfer. Where a server does not - require RRs to include the TTL value explicitly, it should provide a - mechanism, not being the value of the MINIMUM field of the SOA - record, from which the missing TTL values are obtained. How this is - done is implementation dependent. - - The Master File format [RFC 1035 Section 5] is extended to include - the following directive: - - $TTL <TTL> [comment] - - - - - - - -Andrews Standards Track [Page 8] - -RFC 2308 DNS NCACHE March 1998 - - - All resource records appearing after the directive, and which do not - explicitly include a TTL value, have their TTL set to the TTL given - in the $TTL directive. SIG records without a explicit TTL get their - TTL from the "original TTL" of the SIG record [RFC 2065 Section 4.5]. - - The remaining of the current meanings, of being the TTL to be used - for negative responses, is the new defined meaning of the SOA minimum - field. - -5 - Caching Negative Answers - - Like normal answers negative answers have a time to live (TTL). As - there is no record in the answer section to which this TTL can be - applied, the TTL must be carried by another method. This is done by - including the SOA record from the zone in the authority section of - the reply. When the authoritative server creates this record its TTL - is taken from the minimum of the SOA.MINIMUM field and SOA's TTL. - This TTL decrements in a similar manner to a normal cached answer and - upon reaching zero (0) indicates the cached negative answer MUST NOT - be used again. - - A negative answer that resulted from a name error (NXDOMAIN) should - be cached such that it can be retrieved and returned in response to - another query for the same <QNAME, QCLASS> that resulted in the - cached negative response. - - A negative answer that resulted from a no data error (NODATA) should - be cached such that it can be retrieved and returned in response to - another query for the same <QNAME, QTYPE, QCLASS> that resulted in - the cached negative response. - - The NXT record, if it exists in the authority section of a negative - answer received, MUST be stored such that it can be be located and - returned with SOA record in the authority section, as should any SIG - records in the authority section. For NXDOMAIN answers there is no - "necessary" obvious relationship between the NXT records and the - QNAME. The NXT record MUST have the same owner name as the query - name for NODATA responses. - - Negative responses without SOA records SHOULD NOT be cached as there - is no way to prevent the negative responses looping forever between a - pair of servers even with a short TTL. - - Despite the DNS forming a tree of servers, with various mis- - configurations it is possible to form a loop in the query graph, e.g. - two servers listing each other as forwarders, various lame server - configurations. Without a TTL count down a cache negative response - - - - -Andrews Standards Track [Page 9] - -RFC 2308 DNS NCACHE March 1998 - - - when received by the next server would have its TTL reset. This - negative indication could then live forever circulating between the - servers involved. - - As with caching positive responses it is sensible for a resolver to - limit for how long it will cache a negative response as the protocol - supports caching for up to 68 years. Such a limit should not be - greater than that applied to positive answers and preferably be - tunable. Values of one to three hours have been found to work well - and would make sensible a default. Values exceeding one day have - been found to be problematic. - -6 - Negative answers from the cache - - When a server, in answering a query, encounters a cached negative - response it MUST add the cached SOA record to the authority section - of the response with the TTL decremented by the amount of time it was - stored in the cache. This allows the NXDOMAIN / NODATA response to - time out correctly. - - If a NXT record was cached along with SOA record it MUST be added to - the authority section. If a SIG record was cached along with a NXT - record it SHOULD be added to the authority section. - - As with all answers coming from the cache, negative answers SHOULD - have an implicit referral built into the answer. This enables the - resolver to locate an authoritative source. An implicit referral is - characterised by NS records in the authority section referring the - resolver towards a authoritative source. NXDOMAIN types 1 and 4 - responses contain implicit referrals as does NODATA type 1 response. - -7 - Other Negative Responses - - Caching of other negative responses is not covered by any existing - RFC. There is no way to indicate a desired TTL in these responses. - Care needs to be taken to ensure that there are not forwarding loops. - -7.1 Server Failure (OPTIONAL) - - Server failures fall into two major classes. The first is where a - server can determine that it has been misconfigured for a zone. This - may be where it has been listed as a server, but not configured to be - a server for the zone, or where it has been configured to be a server - for the zone, but cannot obtain the zone data for some reason. This - can occur either because the zone file does not exist or contains - errors, or because another server from which the zone should have - been available either did not respond or was unable or unwilling to - supply the zone. - - - -Andrews Standards Track [Page 10] - -RFC 2308 DNS NCACHE March 1998 - - - The second class is where the server needs to obtain an answer from - elsewhere, but is unable to do so, due to network failures, other - servers that don't reply, or return server failure errors, or - similar. - - In either case a resolver MAY cache a server failure response. If it - does so it MUST NOT cache it for longer than five (5) minutes, and it - MUST be cached against the specific query tuple <query name, type, - class, server IP address>. - -7.2 Dead / Unreachable Server (OPTIONAL) - - Dead / Unreachable servers are servers that fail to respond in any - way to a query or where the transport layer has provided an - indication that the server does not exist or is unreachable. A - server may be deemed to be dead or unreachable if it has not - responded to an outstanding query within 120 seconds. - - Examples of transport layer indications are: - - ICMP error messages indicating host, net or port unreachable. - TCP resets - IP stack error messages providing similar indications to those above. - - A server MAY cache a dead server indication. If it does so it MUST - NOT be deemed dead for longer than five (5) minutes. The indication - MUST be stored against query tuple <query name, type, class, server - IP address> unless there was a transport layer indication that the - server does not exist, in which case it applies to all queries to - that specific IP address. - -8 - Changes from RFC 1034 - - Negative caching in resolvers is no-longer optional, if a resolver - caches anything it must also cache negative answers. - - Non-authoritative negative answers MAY be cached. - - The SOA record from the authority section MUST be cached. Name error - indications must be cached against the tuple <query name, QCLASS>. - No data indications must be cached against <query name, QTYPE, - QCLASS> tuple. - - A cached SOA record must be added to the response. This was - explicitly not allowed because previously the distinction between a - normal cached SOA record, and the SOA cached as a result of a - negative response was not made, and simply extracting a normal cached - SOA and adding that to a cached negative response causes problems. - - - -Andrews Standards Track [Page 11] - -RFC 2308 DNS NCACHE March 1998 - - - The $TTL TTL directive was added to the master file format. - -9 - History of Negative Caching - - This section presents a potted history of negative caching in the DNS - and forms no part of the technical specification of negative caching. - - It is interesting to note that the same concepts were re-invented in - both the CHIVES and BIND servers. - - The history of the early CHIVES work (Section 9.1) was supplied by - Rob Austein <sra@epilogue.com> and is reproduced here in the form in - which he supplied it [MPA]. - - Sometime around the spring of 1985, I mentioned to Paul Mockapetris - that our experience with his JEEVES DNS resolver had pointed out the - need for some kind of negative caching scheme. Paul suggested that - we simply cache authoritative errors, using the SOA MINIMUM value for - the zone that would have contained the target RRs. I'm pretty sure - that this conversation took place before RFC-973 was written, but it - was never clear to me whether this idea was something that Paul came - up with on the spot in response to my question or something he'd - already been planning to put into the document that became RFC-973. - In any case, neither of us was entirely sure that the SOA MINIMUM - value was really the right metric to use, but it was available and - was under the control of the administrator of the target zone, both - of which seemed to us at the time to be important feature. - - Late in 1987, I released the initial beta-test version of CHIVES, the - DNS resolver I'd written to replace Paul's JEEVES resolver. CHIVES - included a search path mechanism that was used pretty heavily at - several sites (including my own), so CHIVES also included a negative - caching mechanism based on SOA MINIMUM values. The basic strategy - was to cache authoritative error codes keyed by the exact query - parameters (QNAME, QCLASS, and QTYPE), with a cache TTL equal to the - SOA MINIMUM value. CHIVES did not attempt to track down SOA RRs if - they weren't supplied in the authoritative response, so it never - managed to completely eliminate the gratuitous DNS error message - traffic, but it did help considerably. Keep in mind that this was - happening at about the same time as the near-collapse of the ARPANET - due to congestion caused by exponential growth and the the "old" - (pre-VJ) TCP retransmission algorithm, so negative caching resulted - in drasticly better DNS response time for our users, mailer daemons, - etcetera. - - - - - - - -Andrews Standards Track [Page 12] - -RFC 2308 DNS NCACHE March 1998 - - - As far as I know, CHIVES was the first resolver to implement negative - caching. CHIVES was developed during the twilight years of TOPS-20, - so it never ran on very many machines, but the few machines that it - did run on were the ones that were too critical to shut down quickly - no matter how much it cost to keep them running. So what few users - we did have tended to drive CHIVES pretty hard. Several interesting - bits of DNS technology resulted from that, but the one that's - relevant here is the MAXTTL configuration parameter. - - Experience with JEEVES had already shown that RRs often showed up - with ridiculously long TTLs (99999999 was particularly popular for - many years, due to bugs in the code and documentation of several - early versions of BIND), and that robust software that blindly - believed such TTLs could create so many strange failures that it was - often necessary to reboot the resolver frequently just to clear this - garbage out of the cache. So CHIVES had a configuration parameter - "MAXTTL", which specified the maximum "reasonable" TTL in a received - RR. RRs with TTLs greater than MAXTTL would either have their TTLs - reduced to MAXTTL or would be discarded entirely, depending on the - setting of another configuration parameter. - - When we started getting field experience with CHIVES's negative - caching code, it became clear that the SOA MINIMUM value was often - large enough to cause the same kinds of problems for negative caching - as the huge TTLs in RRs had for normal caching (again, this was in - part due to a bug in several early versions of BIND, where a - secondary server would authoritatively deny all knowledge of its - zones if it couldn't contact the primaries on reboot). So we started - running the negative cache TTLs through the MAXTTL check too, and - continued to experiment. - - The configuration that seemed to work best on WSMR-SIMTEL20.ARMY.MIL - (last of the major Internet TOPS-20 machines to be shut down, thus - the last major user of CHIVES, thus the place where we had the - longest experimental baseline) was to set MAXTTL to about three days. - Most of the traffic initiated by SIMTEL20 in its last years was - mail-related, and the mail queue timeout was set to one week, so this - gave a "stuck" message several tries at complete DNS resolution, - without bogging down the system with a lot of useless queries. Since - (for reasons that now escape me) we only had the single MAXTTL - parameter rather than separate ones for positive and negative - caching, it's not clear how much effect this setting of MAXTTL had on - the negative caching code. - - CHIVES also included a second, somewhat controversial mechanism which - took the place of negative caching in some cases. The CHIVES - resolver daemon could be configured to load DNS master files, giving - it the ability to act as what today would be called a "stealth - - - -Andrews Standards Track [Page 13] - -RFC 2308 DNS NCACHE March 1998 - - - secondary". That is, when configured in this way, the resolver had - direct access to authoritative information for heavily-used zones. - The search path mechanisms in CHIVES reflected this: there were - actually two separate search paths, one of which only searched local - authoritative zone data, and one which could generate normal - iterative queries. This cut down on the need for negative caching in - cases where usage was predictably heavy (e.g., the resolver on - XX.LCS.MIT.EDU always loaded the zone files for both LCS.MIT.EDU and - AI.MIT.EDU and put both of these suffixes into the "local" search - path, since between them the hosts in these two zones accounted for - the bulk of the DNS traffic). Not all sites running CHIVES chose to - use this feature; C.CS.CMU.EDU, for example, chose to use the - "remote" search path for everything because there were too many - different sub-zones at CMU for zone shadowing to be practical for - them, so they relied pretty heavily on negative caching even for - local traffic. - - Overall, I still think the basic design we used for negative caching - was pretty reasonable: the zone administrator specified how long to - cache negative answers, and the resolver configuration chose the - actual cache time from the range between zero and the period - specified by the zone administrator. There are a lot of details I'd - do differently now (like using a new SOA field instead of overloading - the MINIMUM field), but after more than a decade, I'd be more worried - if we couldn't think of at least a few improvements. - -9.2 BIND - - While not the first attempt to get negative caching into BIND, in - July 1993, BIND 4.9.2 ALPHA, Anant Kumar of ISI supplied code that - implemented, validation and negative caching (NCACHE). This code had - a 10 minute TTL for negative caching and only cached the indication - that there was a negative response, NXDOMAIN or NOERROR_NODATA. This - is the origin of the NODATA pseudo response code mentioned above. - - Mark Andrews of CSIRO added code (RETURNSOA) that stored the SOA - record such that it could be retrieved by a similar query. UUnet - complained that they were getting old answers after loading a new - zone, and the option was turned off, BIND 4.9.3-alpha5, April 1994. - In reality this indicated that the named needed to purge the space - the zone would occupy. Functionality to do this was added in BIND - 4.9.3 BETA11 patch2, December 1994. - - RETURNSOA was re-enabled by default, BIND 4.9.5-T1A, August 1996. - - - - - - - -Andrews Standards Track [Page 14] - -RFC 2308 DNS NCACHE March 1998 - - -10 Example - - The following example is based on a signed zone that is empty apart - from the nameservers. We will query for WWW.XX.EXAMPLE showing - initial response and again 10 minutes later. Note 1: during the - intervening 10 minutes the NS records for XX.EXAMPLE have expired. - Note 2: the TTL of the SIG records are not explicitly set in the zone - file and are hence the TTL of the RRset they are the signature for. - - Zone File: - - $TTL 86400 - $ORIGIN XX.EXAMPLE. - @ IN SOA NS1.XX.EXAMPLE. HOSTMATER.XX.EXAMPLE. ( - 1997102000 ; serial - 1800 ; refresh (30 mins) - 900 ; retry (15 mins) - 604800 ; expire (7 days) - 1200 ) ; minimum (20 mins) - IN SIG SOA ... - 1200 IN NXT NS1.XX.EXAMPLE. A NXT SIG SOA NS KEY - IN SIG NXT ... XX.EXAMPLE. ... - 300 IN NS NS1.XX.EXAMPLE. - 300 IN NS NS2.XX.EXAMPLE. - IN SIG NS ... XX.EXAMPLE. ... - IN KEY 0x4100 1 1 ... - IN SIG KEY ... XX.EXAMPLE. ... - IN SIG KEY ... EXAMPLE. ... - NS1 IN A 10.0.0.1 - IN SIG A ... XX.EXAMPLE. ... - 1200 IN NXT NS2.XX.EXAMPLE. A NXT SIG - IN SIG NXT ... - NS2 IN A 10.0.0.2 - IN SIG A ... XX.EXAMPLE. ... - 1200 IN NXT XX.EXAMPLE. A NXT SIG - IN SIG NXT ... XX.EXAMPLE. ... - - Initial Response: - - Header: - RDCODE=NXDOMAIN, AA=1, QR=1, TC=0 - Query: - WWW.XX.EXAMPLE. IN A - Answer: - <empty> - Authority: - XX.EXAMPLE. 1200 IN SOA NS1.XX.EXAMPLE. ... - XX.EXAMPLE. 1200 IN SIG SOA ... XX.EXAMPLE. ... - - - -Andrews Standards Track [Page 15] - -RFC 2308 DNS NCACHE March 1998 - - - NS2.XX.EXAMPLE. 1200 IN NXT XX.EXAMPLE. NXT A NXT SIG - NS2.XX.EXAMPLE. 1200 IN SIG NXT ... XX.EXAMPLE. ... - XX.EXAMPLE. 86400 IN NS NS1.XX.EXAMPLE. - XX.EXAMPLE. 86400 IN NS NS2.XX.EXAMPLE. - XX.EXAMPLE. 86400 IN SIG NS ... XX.EXAMPLE. ... - Additional - XX.EXAMPLE. 86400 IN KEY 0x4100 1 1 ... - XX.EXAMPLE. 86400 IN SIG KEY ... EXAMPLE. ... - NS1.XX.EXAMPLE. 86400 IN A 10.0.0.1 - NS1.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ... - NS2.XX.EXAMPLE. 86400 IN A 10.0.0.2 - NS3.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ... - - After 10 Minutes: - - Header: - RDCODE=NXDOMAIN, AA=0, QR=1, TC=0 - Query: - WWW.XX.EXAMPLE. IN A - Answer: - <empty> - Authority: - XX.EXAMPLE. 600 IN SOA NS1.XX.EXAMPLE. ... - XX.EXAMPLE. 600 IN SIG SOA ... XX.EXAMPLE. ... - NS2.XX.EXAMPLE. 600 IN NXT XX.EXAMPLE. NXT A NXT SIG - NS2.XX.EXAMPLE. 600 IN SIG NXT ... XX.EXAMPLE. ... - EXAMPLE. 65799 IN NS NS1.YY.EXAMPLE. - EXAMPLE. 65799 IN NS NS2.YY.EXAMPLE. - EXAMPLE. 65799 IN SIG NS ... XX.EXAMPLE. ... - Additional - XX.EXAMPLE. 65800 IN KEY 0x4100 1 1 ... - XX.EXAMPLE. 65800 IN SIG KEY ... EXAMPLE. ... - NS1.YY.EXAMPLE. 65799 IN A 10.100.0.1 - NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ... - NS2.YY.EXAMPLE. 65799 IN A 10.100.0.2 - NS3.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ... - EXAMPLE. 65799 IN KEY 0x4100 1 1 ... - EXAMPLE. 65799 IN SIG KEY ... . ... - - -11 Security Considerations - - It is believed that this document does not introduce any significant - additional security threats other that those that already exist when - using data from the DNS. - - - - - - -Andrews Standards Track [Page 16] - -RFC 2308 DNS NCACHE March 1998 - - - With negative caching it might be possible to propagate a denial of - service attack by spreading a NXDOMAIN message with a very high TTL. - Without negative caching that would be much harder. A similar effect - could be achieved previously by spreading a bad A record, so that the - server could not be reached - which is almost the same. It has the - same effect as far as what the end user is able to do, but with a - different psychological effect. With the bad A, I feel "damn the - network is broken again" and try again tomorrow. With the "NXDOMAIN" - I feel "Oh, they've turned off the server and it doesn't exist any - more" and probably never bother trying this server again. - - A practical example of this is a SMTP server where this behaviour is - encoded. With a NXDOMAIN attack the mail message would bounce - immediately, where as with a bad A attack the mail would be queued - and could potentially get through after the attack was suspended. - - For such an attack to be successful, the NXDOMAIN indiction must be - injected into a parent server (or a busy caching resolver). One way - this might be done by the use of a CNAME which results in the parent - server querying an attackers server. Resolvers that wish to prevent - such attacks can query again the final QNAME ignoring any NS data in - the query responses it has received for this query. - - Implementing TTL sanity checking will reduce the effectiveness of - such an attack, because a successful attack would require re- - injection of the bogus data at more frequent intervals. - - DNS Security [RFC2065] provides a mechanism to verify whether a - negative response is valid or not, through the use of NXT and SIG - records. This document supports the use of that mechanism by - promoting the transmission of the relevant security records even in a - non security aware server. - -Acknowledgments - - I would like to thank Rob Austein for his history of the CHIVES - nameserver. The DNSIND working group, in particular Robert Elz for - his valuable technical and editorial contributions to this document. - - - - - - - - - - - - - -Andrews Standards Track [Page 17] - -RFC 2308 DNS NCACHE March 1998 - - -References - - [RFC1034] - Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES," - STD 13, RFC 1034, November 1987. - - [RFC1035] - Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND - SPECIFICATION," STD 13, RFC 1035, November 1987. - - [RFC2065] - Eastlake, D., and C. Kaufman, "Domain Name System Security - Extensions," RFC 2065, January 1997. - - [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels," BCP 14, RFC 2119, March 1997. - - [RFC2181] - Elz, R., and R. Bush, "Clarifications to the DNS - Specification," RFC 2181, July 1997. - -Author's Address - - Mark Andrews - CSIRO - Mathematical and Information Sciences - Locked Bag 17 - North Ryde NSW 2113 - AUSTRALIA - - Phone: +61 2 9325 3148 - EMail: Mark.Andrews@cmis.csiro.au - - - - - - - - - - - - - - - - - - - -Andrews Standards Track [Page 18] - -RFC 2308 DNS NCACHE March 1998 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Andrews Standards Track [Page 19] - diff --git a/contrib/bind9/doc/rfc/rfc2317.txt b/contrib/bind9/doc/rfc/rfc2317.txt deleted file mode 100644 index c17bb41f29f3..000000000000 --- a/contrib/bind9/doc/rfc/rfc2317.txt +++ /dev/null @@ -1,563 +0,0 @@ - - - - - - -Network Working Group H. Eidnes -Request for Comments: 2317 SINTEF RUNIT -BCP: 20 G. de Groot -Category: Best Current Practice Berkeley Software Design, Inc. - P. Vixie - Internet Software Consortium - March 1998 - - - Classless IN-ADDR.ARPA delegation - -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. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -2. Introduction - - This document describes a way to do IN-ADDR.ARPA delegation on non- - octet boundaries for address spaces covering fewer than 256 - addresses. The proposed method should thus remove one of the - objections to subnet on non-octet boundaries but perhaps more - significantly, make it possible to assign IP address space in smaller - chunks than 24-bit prefixes, without losing the ability to delegate - authority for the corresponding IN-ADDR.ARPA mappings. The proposed - method is fully compatible with the original DNS lookup mechanisms - specified in [1], i.e. there is no need to modify the lookup - algorithm used, and there should be no need to modify any software - which does DNS lookups. - - The document also discusses some operational considerations to - provide some guidance in implementing this method. - -3. Motivation - - With the proliferation of classless routing technology, it has become - feasible to assign address space on non-octet boundaries. In case of - a very small organization with only a few hosts, assigning a full - 24-bit prefix (what was traditionally referred to as a "class C - network number") often leads to inefficient address space - utilization. - - - - - -Eidnes, et. al. Best Current Practice [Page 1] - -RFC 2317 Classless IN-ADDR.ARPA delegation March 1998 - - - One of the problems encountered when assigning a longer prefix (less - address space) is that it seems impossible for such an organization - to maintain its own reverse ("IN-ADDR.ARPA") zone autonomously. By - use of the reverse delegation method described below, the most - important objection to assignment of longer prefixes to unrelated - organizations can be removed. - - Let us assume we have assigned the address spaces to three different - parties as follows: - - 192.0.2.0/25 to organization A - 192.0.2.128/26 to organization B - 192.0.2.192/26 to organization C - - In the classical approach, this would lead to a single zone like - this: - - $ORIGIN 2.0.192.in-addr.arpa. - ; - 1 PTR host1.A.domain. - 2 PTR host2.A.domain. - 3 PTR host3.A.domain. - ; - 129 PTR host1.B.domain. - 130 PTR host2.B.domain. - 131 PTR host3.B.domain. - ; - 193 PTR host1.C.domain. - 194 PTR host2.C.domain. - 195 PTR host3.C.domain. - - The administration of this zone is problematic. Authority for this - zone can only be delegated once, and this usually translates into - "this zone can only be administered by one organization." The other - organizations with address space that corresponds to entries in this - zone would thus have to depend on another organization for their - address to name translation. With the proposed method, this - potential problem can be avoided. - -4. Classless IN-ADDR.ARPA delegation - - Since a single zone can only be delegated once, we need more points - to do delegation on to solve the problem above. These extra points - of delegation can be introduced by extending the IN-ADDR.ARPA tree - downwards, e.g. by using the first address or the first address and - the network mask length (as shown below) in the corresponding address - - - - - -Eidnes, et. al. Best Current Practice [Page 2] - -RFC 2317 Classless IN-ADDR.ARPA delegation March 1998 - - - space to form the the first component in the name for the zones. The - following four zone files show how the problem in the motivation - section could be solved using this method. - - $ORIGIN 2.0.192.in-addr.arpa. - @ IN SOA my-ns.my.domain. hostmaster.my.domain. (...) - ;... - ; <<0-127>> /25 - 0/25 NS ns.A.domain. - 0/25 NS some.other.name.server. - ; - 1 CNAME 1.0/25.2.0.192.in-addr.arpa. - 2 CNAME 2.0/25.2.0.192.in-addr.arpa. - 3 CNAME 3.0/25.2.0.192.in-addr.arpa. - ; - ; <<128-191>> /26 - 128/26 NS ns.B.domain. - 128/26 NS some.other.name.server.too. - ; - 129 CNAME 129.128/26.2.0.192.in-addr.arpa. - 130 CNAME 130.128/26.2.0.192.in-addr.arpa. - 131 CNAME 131.128/26.2.0.192.in-addr.arpa. - ; - ; <<192-255>> /26 - 192/26 NS ns.C.domain. - 192/26 NS some.other.third.name.server. - ; - 193 CNAME 193.192/26.2.0.192.in-addr.arpa. - 194 CNAME 194.192/26.2.0.192.in-addr.arpa. - 195 CNAME 195.192/26.2.0.192.in-addr.arpa. - - $ORIGIN 0/25.2.0.192.in-addr.arpa. - @ IN SOA ns.A.domain. hostmaster.A.domain. (...) - @ NS ns.A.domain. - @ NS some.other.name.server. - ; - 1 PTR host1.A.domain. - 2 PTR host2.A.domain. - 3 PTR host3.A.domain. - - - - - - - - - - - - -Eidnes, et. al. Best Current Practice [Page 3] - -RFC 2317 Classless IN-ADDR.ARPA delegation March 1998 - - - $ORIGIN 128/26.2.0.192.in-addr.arpa. - @ IN SOA ns.B.domain. hostmaster.B.domain. (...) - @ NS ns.B.domain. - @ NS some.other.name.server.too. - ; - 129 PTR host1.B.domain. - 130 PTR host2.B.domain. - 131 PTR host3.B.domain. - - - $ORIGIN 192/26.2.0.192.in-addr.arpa. - @ IN SOA ns.C.domain. hostmaster.C.domain. (...) - @ NS ns.C.domain. - @ NS some.other.third.name.server. - ; - 193 PTR host1.C.domain. - 194 PTR host2.C.domain. - 195 PTR host3.C.domain. - - For each size-256 chunk split up using this method, there is a need - to install close to 256 CNAME records in the parent zone. Some - people might view this as ugly; we will not argue that particular - point. It is however quite easy to automatically generate the CNAME - resource records in the parent zone once and for all, if the way the - address space is partitioned is known. - - The advantage of this approach over the other proposed approaches for - dealing with this problem is that there should be no need to modify - any already-deployed software. In particular, the lookup mechanism - in the DNS does not have to be modified to accommodate this splitting - of the responsibility for the IPv4 address to name translation on - "non-dot" boundaries. Furthermore, this technique has been in use - for several years in many installations, apparently with no ill - effects. - - As usual, a resource record like - - $ORIGIN 2.0.192.in-addr.arpa. - 129 CNAME 129.128/26.2.0.192.in-addr.arpa. - - can be convienently abbreviated to - - $ORIGIN 2.0.192.in-addr.arpa. - 129 CNAME 129.128/26 - - - - - - - -Eidnes, et. al. Best Current Practice [Page 4] - -RFC 2317 Classless IN-ADDR.ARPA delegation March 1998 - - - Some DNS implementations are not kind to special characters in domain - names, e.g. the "/" used in the above examples. As [3] makes clear, - these are legal, though some might feel unsightly. Because these are - not host names the restriction of [2] does not apply. Modern clients - and servers have an option to act in the liberal and correct fashion. - - The examples here use "/" because it was felt to be more visible and - pedantic reviewers felt that the 'these are not hostnames' argument - needed to be repeated. We advise you not to be so pedantic, and to - not precisely copy the above examples, e.g. substitute a more - conservative character, such as hyphen, for "/". - -5. Operational considerations - - This technique is intended to be used for delegating address spaces - covering fewer than 256 addresses. For delegations covering larger - blocks of addresses the traditional methods (multiple delegations) - can be used instead. - -5.1 Recommended secondary name service - - Some older versions of name server software will make no effort to - find and return the pointed-to name in CNAME records if the pointed- - to name is not already known locally as cached or as authoritative - data. This can cause some confusion in resolvers, as only the CNAME - record will be returned in the response. To avoid this problem it is - recommended that the authoritative name servers for the delegating - zone (the zone containing all the CNAME records) all run as slave - (secondary) name servers for the "child" zones delegated and pointed - into via the CNAME records. - -5.2 Alternative naming conventions - - As a result of this method, the location of the zone containing the - actual PTR records is no longer predefined. This gives flexibility - and some examples will be presented here. - - An alternative to using the first address, or the first address and - the network mask length in the corresponding address space, to name - the new zones is to use some other (non-numeric) name. Thus it is - also possible to point to an entirely different part of the DNS tree - (i.e. outside of the IN-ADDR.ARPA tree). It would be necessary to - use one of these alternate methods if two organizations somehow - shared the same physical subnet (and corresponding IP address space) - with no "neat" alignment of the addresses, but still wanted to - administrate their own IN-ADDR.ARPA mappings. - - - - - -Eidnes, et. al. Best Current Practice [Page 5] - -RFC 2317 Classless IN-ADDR.ARPA delegation March 1998 - - - The following short example shows how you can point out of the IN- - ADDR.ARPA tree: - - $ORIGIN 2.0.192.in-addr.arpa. - @ IN SOA my-ns.my.domain. hostmaster.my.domain. (...) - ; ... - 1 CNAME 1.A.domain. - 2 CNAME 2.A.domain. - ; ... - 129 CNAME 129.B.domain. - 130 CNAME 130.B.domain. - ; - - - $ORIGIN A.domain. - @ IN SOA my-ns.A.domain. hostmaster.A.domain. (...) - ; ... - ; - host1 A 192.0.2.1 - 1 PTR host1 - ; - host2 A 192.0.2.2 - 2 PTR host2 - ; - - etc. - - This way you can actually end up with the name->address and the - (pointed-to) address->name mapping data in the same zone file - some - may view this as an added bonus as no separate set of secondaries for - the reverse zone is required. Do however note that the traversal via - the IN-ADDR.ARPA tree will still be done, so the CNAME records - inserted there need to point in the right direction for this to work. - - Sketched below is an alternative approach using the same solution: - - $ORIGIN 2.0.192.in-addr.arpa. - @ SOA my-ns.my.domain. hostmaster.my.domain. (...) - ; ... - 1 CNAME 1.2.0.192.in-addr.A.domain. - 2 CNAME 2.2.0.192.in-addr.A.domain. - - $ORIGIN A.domain. - @ SOA my-ns.A.domain. hostmaster.A.domain. (...) - ; ... - ; - host1 A 192.0.2.1 - 1.2.0.192.in-addr PTR host1 - - - -Eidnes, et. al. Best Current Practice [Page 6] - -RFC 2317 Classless IN-ADDR.ARPA delegation March 1998 - - - host2 A 192.0.2.2 - 2.2.0.192.in-addr PTR host2 - - It is clear that many possibilities exist which can be adapted to the - specific requirements of the situation at hand. - -5.3 Other operational issues - - Note that one cannot provide CNAME referrals twice for the same - address space, i.e. you cannot allocate a /25 prefix to one - organisation, and run IN-ADDR.ARPA this way, and then have the - organisation subnet the /25 into longer prefixes, and attempt to - employ the same technique to give each subnet control of its own - number space. This would result in a CNAME record pointing to a CNAME - record, which may be less robust overall. - - Unfortunately, some old beta releases of the popular DNS name server - implementation BIND 4.9.3 had a bug which caused problems if a CNAME - record was encountered when a reverse lookup was made. The beta - releases involved have since been obsoleted, and this issue is - resolved in the released code. Some software manufacturers have - included the defective beta code in their product. In the few cases - we know of, patches from the manufacturers are available or planned - to replace the obsolete beta code involved. - -6. Security Considerations - - With this scheme, the "leaf sites" will need to rely on one more site - running their DNS name service correctly than they would be if they - had a /24 allocation of their own, and this may add an extra - component which will need to work for reliable name resolution. - - Other than that, the authors are not aware of any additional security - issues introduced by this mechanism. - -7. Conclusion - - The suggested scheme gives more flexibility in delegating authority - in the IN-ADDR.ARPA domain, thus making it possible to assign address - space more efficiently without losing the ability to delegate the DNS - authority over the corresponding address to name mappings. - -8. Acknowledgments - - Glen A. Herrmannsfeldt described this trick on comp.protocols.tcp- - ip.domains some time ago. Alan Barrett and Sam Wilson provided - valuable comments on the newsgroup. - - - - -Eidnes, et. al. Best Current Practice [Page 7] - -RFC 2317 Classless IN-ADDR.ARPA delegation March 1998 - - - We would like to thank Rob Austein, Randy Bush, Matt Crawford, Robert - Elz, Glen A. Herrmannsfeldt, Daniel Karrenberg, David Kessens, Tony - Li, Paul Mockapetris, Eric Wassenaar, Michael Patton, Hans Maurer, - and Peter Koch for their review and constructive comments. - -9. References - - [1] Mockapetris, P., "Domain Names - Concepts and Facilities", - STD 13, RFC 1034, November 1987. - - [2] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet Host - Table Specification", RFC 952, October 1985. - - [3] Elz, R., and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Eidnes, et. al. Best Current Practice [Page 8] - -RFC 2317 Classless IN-ADDR.ARPA delegation March 1998 - - -10. Authors' Addresses - - Havard Eidnes - SINTEF RUNIT - N-7034 Trondheim - Norway - - Phone: +47 73 59 44 68 - Fax: +47 73 59 17 00 - EMail: Havard.Eidnes@runit.sintef.no - - - Geert Jan de Groot - Berkeley Software Design, Inc. (BSDI) - Hendrik Staetslaan 69 - 5622 HM Eindhoven - The Netherlands - - Phone: +31 40 2960509 - Fax: +31 40 2960309 - EMail: GeertJan.deGroot@bsdi.com - - - Paul Vixie - Internet Software Consortium - Star Route Box 159A - Woodside, CA 94062 - USA - - Phone: +1 415 747 0204 - EMail: paul@vix.com - - - - - - - - - - - - - - - - - - - - -Eidnes, et. al. Best Current Practice [Page 9] - -RFC 2317 Classless IN-ADDR.ARPA delegation March 1998 - - -11. Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Eidnes, et. al. Best Current Practice [Page 10] - diff --git a/contrib/bind9/doc/rfc/rfc2373.txt b/contrib/bind9/doc/rfc/rfc2373.txt deleted file mode 100644 index 59fcff80f140..000000000000 --- a/contrib/bind9/doc/rfc/rfc2373.txt +++ /dev/null @@ -1,1459 +0,0 @@ - - - - - - -Network Working Group R. Hinden -Request for Comments: 2373 Nokia -Obsoletes: 1884 S. Deering -Category: Standards Track Cisco Systems - July 1998 - - IP Version 6 Addressing Architecture - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -Abstract - - This specification defines the addressing architecture of the IP - Version 6 protocol [IPV6]. The document includes the IPv6 addressing - model, text representations of IPv6 addresses, definition of IPv6 - unicast addresses, anycast addresses, and multicast addresses, and an - IPv6 node's required addresses. - -Table of Contents - - 1. Introduction.................................................2 - 2. IPv6 Addressing..............................................2 - 2.1 Addressing Model.........................................3 - 2.2 Text Representation of Addresses.........................3 - 2.3 Text Representation of Address Prefixes..................5 - 2.4 Address Type Representation..............................6 - 2.5 Unicast Addresses........................................7 - 2.5.1 Interface Identifiers................................8 - 2.5.2 The Unspecified Address..............................9 - 2.5.3 The Loopback Address.................................9 - 2.5.4 IPv6 Addresses with Embedded IPv4 Addresses.........10 - 2.5.5 NSAP Addresses......................................10 - 2.5.6 IPX Addresses.......................................10 - 2.5.7 Aggregatable Global Unicast Addresses...............11 - 2.5.8 Local-use IPv6 Unicast Addresses....................11 - 2.6 Anycast Addresses.......................................12 - 2.6.1 Required Anycast Address............................13 - 2.7 Multicast Addresses.....................................14 - - - -Hinden & Deering Standards Track [Page 1] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - 2.7.1 Pre-Defined Multicast Addresses.....................15 - 2.7.2 Assignment of New IPv6 Multicast Addresses..........17 - 2.8 A Node's Required Addresses.............................17 - 3. Security Considerations.....................................18 - APPENDIX A: Creating EUI-64 based Interface Identifiers........19 - APPENDIX B: ABNF Description of Text Representations...........22 - APPENDIX C: CHANGES FROM RFC-1884..............................23 - REFERENCES.....................................................24 - AUTHORS' ADDRESSES.............................................25 - FULL COPYRIGHT STATEMENT.......................................26 - - -1.0 INTRODUCTION - - This specification defines the addressing architecture of the IP - Version 6 protocol. It includes a detailed description of the - currently defined address formats for IPv6 [IPV6]. - - The authors would like to acknowledge the contributions of Paul - Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, - Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, - Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg - Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, - and Sue Thomson. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC 2119]. - -2.0 IPv6 ADDRESSING - - IPv6 addresses are 128-bit identifiers for interfaces and sets of - interfaces. There are three types of addresses: - - Unicast: An identifier for a single interface. A packet sent to - a unicast address is delivered to the interface - identified by that address. - - Anycast: An identifier for a set of interfaces (typically - belonging to different nodes). A packet sent to an - anycast address is delivered to one of the interfaces - identified by that address (the "nearest" one, according - to the routing protocols' measure of distance). - - Multicast: An identifier for a set of interfaces (typically - belonging to different nodes). A packet sent to a - multicast address is delivered to all interfaces - identified by that address. - - - -Hinden & Deering Standards Track [Page 2] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - There are no broadcast addresses in IPv6, their function being - superseded by multicast addresses. - - In this document, fields in addresses are given a specific name, for - example "subscriber". When this name is used with the term "ID" for - identifier after the name (e.g., "subscriber ID"), it refers to the - contents of the named field. When it is used with the term "prefix" - (e.g. "subscriber prefix") it refers to all of the address up to and - including this field. - - In IPv6, all zeros and all ones are legal values for any field, - unless specifically excluded. Specifically, prefixes may contain - zero-valued fields or end in zeros. - -2.1 Addressing Model - - IPv6 addresses of all types are assigned to interfaces, not nodes. - An IPv6 unicast address refers to a single interface. Since each - interface belongs to a single node, any of that node's interfaces' - unicast addresses may be used as an identifier for the node. - - All interfaces are required to have at least one link-local unicast - address (see section 2.8 for additional required addresses). A - single interface may also be assigned multiple IPv6 addresses of any - type (unicast, anycast, and multicast) or scope. Unicast addresses - with scope greater than link-scope are not needed for interfaces that - are not used as the origin or destination of any IPv6 packets to or - from non-neighbors. This is sometimes convenient for point-to-point - interfaces. There is one exception to this addressing model: - - An unicast address or a set of unicast addresses may be assigned to - multiple physical interfaces if the implementation treats the - multiple physical interfaces as one interface when presenting it to - the internet layer. This is useful for load-sharing over multiple - physical interfaces. - - Currently IPv6 continues the IPv4 model that a subnet prefix is - associated with one link. Multiple subnet prefixes may be assigned - to the same link. - -2.2 Text Representation of Addresses - - There are three conventional forms for representing IPv6 addresses as - text strings: - - 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the - hexadecimal values of the eight 16-bit pieces of the address. - Examples: - - - -Hinden & Deering Standards Track [Page 3] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 - - 1080:0:0:0:8:800:200C:417A - - Note that it is not necessary to write the leading zeros in an - individual field, but there must be at least one numeral in every - field (except for the case described in 2.). - - 2. Due to some methods of allocating certain styles of IPv6 - addresses, it will be common for addresses to contain long strings - of zero bits. In order to make writing addresses containing zero - bits easier a special syntax is available to compress the zeros. - The use of "::" indicates multiple groups of 16-bits of zeros. - The "::" can only appear once in an address. The "::" can also be - used to compress the leading and/or trailing zeros in an address. - - For example the following addresses: - - 1080:0:0:0:8:800:200C:417A a unicast address - FF01:0:0:0:0:0:0:101 a multicast address - 0:0:0:0:0:0:0:1 the loopback address - 0:0:0:0:0:0:0:0 the unspecified addresses - - may be represented as: - - 1080::8:800:200C:417A a unicast address - FF01::101 a multicast address - ::1 the loopback address - :: the unspecified addresses - - 3. An alternative form that is sometimes more convenient when dealing - with a mixed environment of IPv4 and IPv6 nodes is - x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of - the six high-order 16-bit pieces of the address, and the 'd's are - the decimal values of the four low-order 8-bit pieces of the - address (standard IPv4 representation). Examples: - - 0:0:0:0:0:0:13.1.68.3 - - 0:0:0:0:0:FFFF:129.144.52.38 - - or in compressed form: - - ::13.1.68.3 - - ::FFFF:129.144.52.38 - - - - - -Hinden & Deering Standards Track [Page 4] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -2.3 Text Representation of Address Prefixes - - The text representation of IPv6 address prefixes is similar to the - way IPv4 addresses prefixes are written in CIDR notation. An IPv6 - address prefix is represented by the notation: - - ipv6-address/prefix-length - - where - - ipv6-address is an IPv6 address in any of the notations listed - in section 2.2. - - prefix-length is a decimal value specifying how many of the - leftmost contiguous bits of the address comprise - the prefix. - - For example, the following are legal representations of the 60-bit - prefix 12AB00000000CD3 (hexadecimal): - - 12AB:0000:0000:CD30:0000:0000:0000:0000/60 - 12AB::CD30:0:0:0:0/60 - 12AB:0:0:CD30::/60 - - The following are NOT legal representations of the above prefix: - - 12AB:0:0:CD3/60 may drop leading zeros, but not trailing zeros, - within any 16-bit chunk of the address - - 12AB::CD30/60 address to left of "/" expands to - 12AB:0000:0000:0000:0000:000:0000:CD30 - - 12AB::CD3/60 address to left of "/" expands to - 12AB:0000:0000:0000:0000:000:0000:0CD3 - - When writing both a node address and a prefix of that node address - (e.g., the node's subnet prefix), the two can combined as follows: - - the node address 12AB:0:0:CD30:123:4567:89AB:CDEF - and its subnet number 12AB:0:0:CD30::/60 - - can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60 - - - - - - - - - -Hinden & Deering Standards Track [Page 5] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -2.4 Address Type Representation - - The specific type of an IPv6 address is indicated by the leading bits - in the address. The variable-length field comprising these leading - bits is called the Format Prefix (FP). The initial allocation of - these prefixes is as follows: - - Allocation Prefix Fraction of - (binary) Address Space - ----------------------------------- -------- ------------- - Reserved 0000 0000 1/256 - Unassigned 0000 0001 1/256 - - Reserved for NSAP Allocation 0000 001 1/128 - Reserved for IPX Allocation 0000 010 1/128 - - Unassigned 0000 011 1/128 - Unassigned 0000 1 1/32 - Unassigned 0001 1/16 - - Aggregatable Global Unicast Addresses 001 1/8 - Unassigned 010 1/8 - Unassigned 011 1/8 - Unassigned 100 1/8 - Unassigned 101 1/8 - Unassigned 110 1/8 - - Unassigned 1110 1/16 - Unassigned 1111 0 1/32 - Unassigned 1111 10 1/64 - Unassigned 1111 110 1/128 - Unassigned 1111 1110 0 1/512 - - Link-Local Unicast Addresses 1111 1110 10 1/1024 - Site-Local Unicast Addresses 1111 1110 11 1/1024 - - Multicast Addresses 1111 1111 1/256 - - Notes: - - (1) The "unspecified address" (see section 2.5.2), the loopback - address (see section 2.5.3), and the IPv6 Addresses with - Embedded IPv4 Addresses (see section 2.5.4), are assigned out - of the 0000 0000 format prefix space. - - - - - - - -Hinden & Deering Standards Track [Page 6] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - (2) The format prefixes 001 through 111, except for Multicast - Addresses (1111 1111), are all required to have to have 64-bit - interface identifiers in EUI-64 format. See section 2.5.1 for - definitions. - - This allocation supports the direct allocation of aggregation - addresses, local use addresses, and multicast addresses. Space is - reserved for NSAP addresses and IPX addresses. The remainder of the - address space is unassigned for future use. This can be used for - expansion of existing use (e.g., additional aggregatable addresses, - etc.) or new uses (e.g., separate locators and identifiers). Fifteen - percent of the address space is initially allocated. The remaining - 85% is reserved for future use. - - Unicast addresses are distinguished from multicast addresses by the - value of the high-order octet of the addresses: a value of FF - (11111111) identifies an address as a multicast address; any other - value identifies an address as a unicast address. Anycast addresses - are taken from the unicast address space, and are not syntactically - distinguishable from unicast addresses. - -2.5 Unicast Addresses - - IPv6 unicast addresses are aggregatable with contiguous bit-wise - masks similar to IPv4 addresses under Class-less Interdomain Routing - [CIDR]. - - There are several forms of unicast address assignment in IPv6, - including the global aggregatable global unicast address, the NSAP - address, the IPX hierarchical address, the site-local address, the - link-local address, and the IPv4-capable host address. Additional - address types can be defined in the future. - - IPv6 nodes may have considerable or little knowledge of the internal - structure of the IPv6 address, depending on the role the node plays - (for instance, host versus router). At a minimum, a node may - consider that unicast addresses (including its own) have no internal - structure: - - | 128 bits | - +-----------------------------------------------------------------+ - | node address | - +-----------------------------------------------------------------+ - - A slightly sophisticated host (but still rather simple) may - additionally be aware of subnet prefix(es) for the link(s) it is - attached to, where different addresses may have different values for - n: - - - -Hinden & Deering Standards Track [Page 7] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - | n bits | 128-n bits | - +------------------------------------------------+----------------+ - | subnet prefix | interface ID | - +------------------------------------------------+----------------+ - - Still more sophisticated hosts may be aware of other hierarchical - boundaries in the unicast address. Though a very simple router may - have no knowledge of the internal structure of IPv6 unicast - addresses, routers will more generally have knowledge of one or more - of the hierarchical boundaries for the operation of routing - protocols. The known boundaries will differ from router to router, - depending on what positions the router holds in the routing - hierarchy. - -2.5.1 Interface Identifiers - - Interface identifiers in IPv6 unicast addresses are used to identify - interfaces on a link. They are required to be unique on that link. - They may also be unique over a broader scope. In many cases an - interface's identifier will be the same as that interface's link- - layer address. The same interface identifier may be used on multiple - interfaces on a single node. - - Note that the use of the same interface identifier on multiple - interfaces of a single node does not affect the interface - identifier's global uniqueness or each IPv6 addresses global - uniqueness created using that interface identifier. - - In a number of the format prefixes (see section 2.4) Interface IDs - are required to be 64 bits long and to be constructed in IEEE EUI-64 - format [EUI64]. EUI-64 based Interface identifiers may have global - scope when a global token is available (e.g., IEEE 48bit MAC) or may - have local scope where a global token is not available (e.g., serial - links, tunnel end-points, etc.). It is required that the "u" bit - (universal/local bit in IEEE EUI-64 terminology) be inverted when - forming the interface identifier from the EUI-64. The "u" bit is set - to one (1) to indicate global scope, and it is set to zero (0) to - indicate local scope. The first three octets in binary of an EUI-64 - identifier are as follows: - - 0 0 0 1 1 2 - |0 7 8 5 6 3| - +----+----+----+----+----+----+ - |cccc|ccug|cccc|cccc|cccc|cccc| - +----+----+----+----+----+----+ - - - - - - -Hinden & Deering Standards Track [Page 8] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - written in Internet standard bit-order , where "u" is the - universal/local bit, "g" is the individual/group bit, and "c" are the - bits of the company_id. Appendix A: "Creating EUI-64 based Interface - Identifiers" provides examples on the creation of different EUI-64 - based interface identifiers. - - The motivation for inverting the "u" bit when forming the interface - identifier is to make it easy for system administrators to hand - configure local scope identifiers when hardware tokens are not - available. This is expected to be case for serial links, tunnel end- - points, etc. The alternative would have been for these to be of the - form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler ::1, - ::2, etc. - - The use of the universal/local bit in the IEEE EUI-64 identifier is - to allow development of future technology that can take advantage of - interface identifiers with global scope. - - The details of forming interface identifiers are defined in the - appropriate "IPv6 over <link>" specification such as "IPv6 over - Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. - -2.5.2 The Unspecified Address - - The address 0:0:0:0:0:0:0:0 is called the unspecified address. It - must never be assigned to any node. It indicates the absence of an - address. One example of its use is in the Source Address field of - any IPv6 packets sent by an initializing host before it has learned - its own address. - - The unspecified address must not be used as the destination address - of IPv6 packets or in IPv6 Routing Headers. - -2.5.3 The Loopback Address - - The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. - It may be used by a node to send an IPv6 packet to itself. It may - never be assigned to any physical interface. It may be thought of as - being associated with a virtual interface (e.g., the loopback - interface). - - The loopback address must not be used as the source address in IPv6 - packets that are sent outside of a single node. An IPv6 packet with - a destination address of loopback must never be sent outside of a - single node and must never be forwarded by an IPv6 router. - - - - - - -Hinden & Deering Standards Track [Page 9] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -2.5.4 IPv6 Addresses with Embedded IPv4 Addresses - - The IPv6 transition mechanisms [TRAN] include a technique for hosts - and routers to dynamically tunnel IPv6 packets over IPv4 routing - infrastructure. IPv6 nodes that utilize this technique are assigned - special IPv6 unicast addresses that carry an IPv4 address in the low- - order 32-bits. This type of address is termed an "IPv4-compatible - IPv6 address" and has the format: - - | 80 bits | 16 | 32 bits | - +--------------------------------------+--------------------------+ - |0000..............................0000|0000| IPv4 address | - +--------------------------------------+----+---------------------+ - - A second type of IPv6 address which holds an embedded IPv4 address is - also defined. This address is used to represent the addresses of - IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses. - This type of address is termed an "IPv4-mapped IPv6 address" and has - the format: - - | 80 bits | 16 | 32 bits | - +--------------------------------------+--------------------------+ - |0000..............................0000|FFFF| IPv4 address | - +--------------------------------------+----+---------------------+ - -2.5.5 NSAP Addresses - - This mapping of NSAP address into IPv6 addresses is defined in - [NSAP]. This document recommends that network implementors who have - planned or deployed an OSI NSAP addressing plan, and who wish to - deploy or transition to IPv6, should redesign a native IPv6 - addressing plan to meet their needs. However, it also defines a set - of mechanisms for the support of OSI NSAP addressing in an IPv6 - network. These mechanisms are the ones that must be used if such - support is required. This document also defines a mapping of IPv6 - addresses within the OSI address format, should this be required. - -2.5.6 IPX Addresses - - This mapping of IPX address into IPv6 addresses is as follows: - - | 7 | 121 bits | - +-------+---------------------------------------------------------+ - |0000010| to be defined | - +-------+---------------------------------------------------------+ - - The draft definition, motivation, and usage are under study. - - - - -Hinden & Deering Standards Track [Page 10] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -2.5.7 Aggregatable Global Unicast Addresses - - The global aggregatable global unicast address is defined in [AGGR]. - This address format is designed to support both the current provider - based aggregation and a new type of aggregation called exchanges. - The combination will allow efficient routing aggregation for both - sites which connect directly to providers and who connect to - exchanges. Sites will have the choice to connect to either type of - aggregation point. - - The IPv6 aggregatable global unicast address format is as follows: - - | 3| 13 | 8 | 24 | 16 | 64 bits | - +--+-----+---+--------+--------+--------------------------------+ - |FP| TLA |RES| NLA | SLA | Interface ID | - | | ID | | ID | ID | | - +--+-----+---+--------+--------+--------------------------------+ - - Where - - 001 Format Prefix (3 bit) for Aggregatable Global - Unicast Addresses - TLA ID Top-Level Aggregation Identifier - RES Reserved for future use - NLA ID Next-Level Aggregation Identifier - SLA ID Site-Level Aggregation Identifier - INTERFACE ID Interface Identifier - - The contents, field sizes, and assignment rules are defined in - [AGGR]. - -2.5.8 Local-Use IPv6 Unicast Addresses - - There are two types of local-use unicast addresses defined. These - are Link-Local and Site-Local. The Link-Local is for use on a single - link and the Site-Local is for use in a single site. Link-Local - addresses have the following format: - - | 10 | - | bits | 54 bits | 64 bits | - +----------+-------------------------+----------------------------+ - |1111111010| 0 | interface ID | - +----------+-------------------------+----------------------------+ - - Link-Local addresses are designed to be used for addressing on a - single link for purposes such as auto-address configuration, neighbor - discovery, or when no routers are present. - - - - -Hinden & Deering Standards Track [Page 11] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - Routers must not forward any packets with link-local source or - destination addresses to other links. - - Site-Local addresses have the following format: - - | 10 | - | bits | 38 bits | 16 bits | 64 bits | - +----------+-------------+-----------+----------------------------+ - |1111111011| 0 | subnet ID | interface ID | - +----------+-------------+-----------+----------------------------+ - - Site-Local addresses are designed to be used for addressing inside of - a site without the need for a global prefix. - - Routers must not forward any packets with site-local source or - destination addresses outside of the site. - -2.6 Anycast Addresses - - An IPv6 anycast address is an address that is assigned to more than - one interface (typically belonging to different nodes), with the - property that a packet sent to an anycast address is routed to the - "nearest" interface having that address, according to the routing - protocols' measure of distance. - - Anycast addresses are allocated from the unicast address space, using - any of the defined unicast address formats. Thus, anycast addresses - are syntactically indistinguishable from unicast addresses. When a - unicast address is assigned to more than one interface, thus turning - it into an anycast address, the nodes to which the address is - assigned must be explicitly configured to know that it is an anycast - address. - - For any assigned anycast address, there is a longest address prefix P - that identifies the topological region in which all interfaces - belonging to that anycast address reside. Within the region - identified by P, each member of the anycast set must be advertised as - a separate entry in the routing system (commonly referred to as a - "host route"); outside the region identified by P, the anycast - address may be aggregated into the routing advertisement for prefix - P. - - Note that in, the worst case, the prefix P of an anycast set may be - the null prefix, i.e., the members of the set may have no topological - locality. In that case, the anycast address must be advertised as a - separate routing entry throughout the entire internet, which presents - - - - - -Hinden & Deering Standards Track [Page 12] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - a severe scaling limit on how many such "global" anycast sets may be - supported. Therefore, it is expected that support for global anycast - sets may be unavailable or very restricted. - - One expected use of anycast addresses is to identify the set of - routers belonging to an organization providing internet service. - Such addresses could be used as intermediate addresses in an IPv6 - Routing header, to cause a packet to be delivered via a particular - aggregation or sequence of aggregations. Some other possible uses - are to identify the set of routers attached to a particular subnet, - or the set of routers providing entry into a particular routing - domain. - - There is little experience with widespread, arbitrary use of internet - anycast addresses, and some known complications and hazards when - using them in their full generality [ANYCST]. Until more experience - has been gained and solutions agreed upon for those problems, the - following restrictions are imposed on IPv6 anycast addresses: - - o An anycast address must not be used as the source address of an - IPv6 packet. - - o An anycast address must not be assigned to an IPv6 host, that - is, it may be assigned to an IPv6 router only. - -2.6.1 Required Anycast Address - - The Subnet-Router anycast address is predefined. Its format is as - follows: - - | n bits | 128-n bits | - +------------------------------------------------+----------------+ - | subnet prefix | 00000000000000 | - +------------------------------------------------+----------------+ - - The "subnet prefix" in an anycast address is the prefix which - identifies a specific link. This anycast address is syntactically - the same as a unicast address for an interface on the link with the - interface identifier set to zero. - - Packets sent to the Subnet-Router anycast address will be delivered - to one router on the subnet. All routers are required to support the - Subnet-Router anycast addresses for the subnets which they have - interfaces. - - - - - - - -Hinden & Deering Standards Track [Page 13] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - The subnet-router anycast address is intended to be used for - applications where a node needs to communicate with one of a set of - routers on a remote subnet. For example when a mobile host needs to - communicate with one of the mobile agents on its "home" subnet. - -2.7 Multicast Addresses - - An IPv6 multicast address is an identifier for a group of nodes. A - node may belong to any number of multicast groups. Multicast - addresses have the following format: - - | 8 | 4 | 4 | 112 bits | - +------ -+----+----+---------------------------------------------+ - |11111111|flgs|scop| group ID | - +--------+----+----+---------------------------------------------+ - - 11111111 at the start of the address identifies the address as - being a multicast address. - - +-+-+-+-+ - flgs is a set of 4 flags: |0|0|0|T| - +-+-+-+-+ - - The high-order 3 flags are reserved, and must be initialized to - 0. - - T = 0 indicates a permanently-assigned ("well-known") multicast - address, assigned by the global internet numbering authority. - - T = 1 indicates a non-permanently-assigned ("transient") - multicast address. - - scop is a 4-bit multicast scope value used to limit the scope of - the multicast group. The values are: - - 0 reserved - 1 node-local scope - 2 link-local scope - 3 (unassigned) - 4 (unassigned) - 5 site-local scope - 6 (unassigned) - 7 (unassigned) - 8 organization-local scope - 9 (unassigned) - A (unassigned) - B (unassigned) - C (unassigned) - - - -Hinden & Deering Standards Track [Page 14] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - D (unassigned) - E global scope - F reserved - - group ID identifies the multicast group, either permanent or - transient, within the given scope. - - The "meaning" of a permanently-assigned multicast address is - independent of the scope value. For example, if the "NTP servers - group" is assigned a permanent multicast address with a group ID of - 101 (hex), then: - - FF01:0:0:0:0:0:0:101 means all NTP servers on the same node as the - sender. - - FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the - sender. - - FF05:0:0:0:0:0:0:101 means all NTP servers at the same site as the - sender. - - FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet. - - Non-permanently-assigned multicast addresses are meaningful only - within a given scope. For example, a group identified by the non- - permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one - site bears no relationship to a group using the same address at a - different site, nor to a non-permanent group using the same group ID - with different scope, nor to a permanent group with the same group - ID. - - Multicast addresses must not be used as source addresses in IPv6 - packets or appear in any routing header. - -2.7.1 Pre-Defined Multicast Addresses - - The following well-known multicast addresses are pre-defined: - - Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 - FF01:0:0:0:0:0:0:0 - FF02:0:0:0:0:0:0:0 - FF03:0:0:0:0:0:0:0 - FF04:0:0:0:0:0:0:0 - FF05:0:0:0:0:0:0:0 - FF06:0:0:0:0:0:0:0 - FF07:0:0:0:0:0:0:0 - FF08:0:0:0:0:0:0:0 - FF09:0:0:0:0:0:0:0 - - - -Hinden & Deering Standards Track [Page 15] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - FF0A:0:0:0:0:0:0:0 - FF0B:0:0:0:0:0:0:0 - FF0C:0:0:0:0:0:0:0 - FF0D:0:0:0:0:0:0:0 - FF0E:0:0:0:0:0:0:0 - FF0F:0:0:0:0:0:0:0 - - The above multicast addresses are reserved and shall never be - assigned to any multicast group. - - All Nodes Addresses: FF01:0:0:0:0:0:0:1 - FF02:0:0:0:0:0:0:1 - - The above multicast addresses identify the group of all IPv6 nodes, - within scope 1 (node-local) or 2 (link-local). - - All Routers Addresses: FF01:0:0:0:0:0:0:2 - FF02:0:0:0:0:0:0:2 - FF05:0:0:0:0:0:0:2 - - The above multicast addresses identify the group of all IPv6 routers, - within scope 1 (node-local), 2 (link-local), or 5 (site-local). - - Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX - - The above multicast address is computed as a function of a node's - unicast and anycast addresses. The solicited-node multicast address - is formed by taking the low-order 24 bits of the address (unicast or - anycast) and appending those bits to the prefix - FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the - range - - FF02:0:0:0:0:1:FF00:0000 - - to - - FF02:0:0:0:0:1:FFFF:FFFF - - For example, the solicited node multicast address corresponding to - the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6 - addresses that differ only in the high-order bits, e.g. due to - multiple high-order prefixes associated with different aggregations, - will map to the same solicited-node address thereby reducing the - number of multicast addresses a node must join. - - A node is required to compute and join the associated Solicited-Node - multicast addresses for every unicast and anycast address it is - assigned. - - - -Hinden & Deering Standards Track [Page 16] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -2.7.2 Assignment of New IPv6 Multicast Addresses - - The current approach [ETHER] to map IPv6 multicast addresses into - IEEE 802 MAC addresses takes the low order 32 bits of the IPv6 - multicast address and uses it to create a MAC address. Note that - Token Ring networks are handled differently. This is defined in - [TOKEN]. Group ID's less than or equal to 32 bits will generate - unique MAC addresses. Due to this new IPv6 multicast addresses - should be assigned so that the group identifier is always in the low - order 32 bits as shown in the following: - - | 8 | 4 | 4 | 80 bits | 32 bits | - +------ -+----+----+---------------------------+-----------------+ - |11111111|flgs|scop| reserved must be zero | group ID | - +--------+----+----+---------------------------+-----------------+ - - While this limits the number of permanent IPv6 multicast groups to - 2^32 this is unlikely to be a limitation in the future. If it - becomes necessary to exceed this limit in the future multicast will - still work but the processing will be sightly slower. - - Additional IPv6 multicast addresses are defined and registered by the - IANA [MASGN]. - -2.8 A Node's Required Addresses - - A host is required to recognize the following addresses as - identifying itself: - - o Its Link-Local Address for each interface - o Assigned Unicast Addresses - o Loopback Address - o All-Nodes Multicast Addresses - o Solicited-Node Multicast Address for each of its assigned - unicast and anycast addresses - o Multicast Addresses of all other groups to which the host - belongs. - - A router is required to recognize all addresses that a host is - required to recognize, plus the following addresses as identifying - itself: - - o The Subnet-Router anycast addresses for the interfaces it is - configured to act as a router on. - o All other Anycast addresses with which the router has been - configured. - o All-Routers Multicast Addresses - - - - -Hinden & Deering Standards Track [Page 17] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - o Multicast Addresses of all other groups to which the router - belongs. - - The only address prefixes which should be predefined in an - implementation are the: - - o Unspecified Address - o Loopback Address - o Multicast Prefix (FF) - o Local-Use Prefixes (Link-Local and Site-Local) - o Pre-Defined Multicast Addresses - o IPv4-Compatible Prefixes - - Implementations should assume all other addresses are unicast unless - specifically configured (e.g., anycast addresses). - -3. Security Considerations - - IPv6 addressing documents do not have any direct impact on Internet - infrastructure security. Authentication of IPv6 packets is defined - in [AUTH]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 18] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -APPENDIX A : Creating EUI-64 based Interface Identifiers --------------------------------------------------------- - - Depending on the characteristics of a specific link or node there are - a number of approaches for creating EUI-64 based interface - identifiers. This appendix describes some of these approaches. - -Links or Nodes with EUI-64 Identifiers - - The only change needed to transform an EUI-64 identifier to an - interface identifier is to invert the "u" (universal/local) bit. For - example, a globally unique EUI-64 identifier of the form: - - |0 1|1 3|3 4|4 6| - |0 5|6 1|2 7|8 3| - +----------------+----------------+----------------+----------------+ - |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| - +----------------+----------------+----------------+----------------+ - - where "c" are the bits of the assigned company_id, "0" is the value - of the universal/local bit to indicate global scope, "g" is - individual/group bit, and "m" are the bits of the manufacturer- - selected extension identifier. The IPv6 interface identifier would - be of the form: - - |0 1|1 3|3 4|4 6| - |0 5|6 1|2 7|8 3| - +----------------+----------------+----------------+----------------+ - |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| - +----------------+----------------+----------------+----------------+ - - The only change is inverting the value of the universal/local bit. - -Links or Nodes with IEEE 802 48 bit MAC's - - [EUI64] defines a method to create a EUI-64 identifier from an IEEE - 48bit MAC identifier. This is to insert two octets, with hexadecimal - values of 0xFF and 0xFE, in the middle of the 48 bit MAC (between the - company_id and vendor supplied id). For example the 48 bit MAC with - global scope: - - |0 1|1 3|3 4| - |0 5|6 1|2 7| - +----------------+----------------+----------------+ - |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| - +----------------+----------------+----------------+ - - - - - -Hinden & Deering Standards Track [Page 19] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - where "c" are the bits of the assigned company_id, "0" is the value - of the universal/local bit to indicate global scope, "g" is - individual/group bit, and "m" are the bits of the manufacturer- - selected extension identifier. The interface identifier would be of - the form: - - |0 1|1 3|3 4|4 6| - |0 5|6 1|2 7|8 3| - +----------------+----------------+----------------+----------------+ - |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| - +----------------+----------------+----------------+----------------+ - - When IEEE 802 48bit MAC addresses are available (on an interface or a - node), an implementation should use them to create interface - identifiers due to their availability and uniqueness properties. - -Links with Non-Global Identifiers - - There are a number of types of links that, while multi-access, do not - have globally unique link identifiers. Examples include LocalTalk - and Arcnet. The method to create an EUI-64 formatted identifier is - to take the link identifier (e.g., the LocalTalk 8 bit node - identifier) and zero fill it to the left. For example a LocalTalk 8 - bit node identifier of hexadecimal value 0x4F results in the - following interface identifier: - - |0 1|1 3|3 4|4 6| - |0 5|6 1|2 7|8 3| - +----------------+----------------+----------------+----------------+ - |0000000000000000|0000000000000000|0000000000000000|0000000001001111| - +----------------+----------------+----------------+----------------+ - - Note that this results in the universal/local bit set to "0" to - indicate local scope. - -Links without Identifiers - - There are a number of links that do not have any type of built-in - identifier. The most common of these are serial links and configured - tunnels. Interface identifiers must be chosen that are unique for - the link. - - When no built-in identifier is available on a link the preferred - approach is to use a global interface identifier from another - interface or one which is assigned to the node itself. To use this - approach no other interface connecting the same node to the same link - may use the same identifier. - - - - -Hinden & Deering Standards Track [Page 20] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - - If there is no global interface identifier available for use on the - link the implementation needs to create a local scope interface - identifier. The only requirement is that it be unique on the link. - There are many possible approaches to select a link-unique interface - identifier. They include: - - Manual Configuration - Generated Random Number - Node Serial Number (or other node-specific token) - - The link-unique interface identifier should be generated in a manner - that it does not change after a reboot of a node or if interfaces are - added or deleted from the node. - - The selection of the appropriate algorithm is link and implementation - dependent. The details on forming interface identifiers are defined - in the appropriate "IPv6 over <link>" specification. It is strongly - recommended that a collision detection algorithm be implemented as - part of any automatic algorithm. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 21] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -APPENDIX B: ABNF Description of Text Representations ----------------------------------------------------- - - This appendix defines the text representation of IPv6 addresses and - prefixes in Augmented BNF [ABNF] for reference purposes. - - IPv6address = hexpart [ ":" IPv4address ] - IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT - - IPv6prefix = hexpart "/" 1*2DIGIT - - hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] - hexseq = hex4 *( ":" hex4) - hex4 = 1*4HEXDIG - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 22] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -APPENDIX C: CHANGES FROM RFC-1884 ---------------------------------- - - The following changes were made from RFC-1884 "IP Version 6 - Addressing Architecture": - - - Added an appendix providing a ABNF description of text - representations. - - Clarification that link unique identifiers not change after - reboot or other interface reconfigurations. - - Clarification of Address Model based on comments. - - Changed aggregation format terminology to be consistent with - aggregation draft. - - Added text to allow interface identifier to be used on more than - one interface on same node. - - Added rules for defining new multicast addresses. - - Added appendix describing procedures for creating EUI-64 based - interface ID's. - - Added notation for defining IPv6 prefixes. - - Changed solicited node multicast definition to use a longer - prefix. - - Added site scope all routers multicast address. - - Defined Aggregatable Global Unicast Addresses to use "001" Format - Prefix. - - Changed "010" (Provider-Based Unicast) and "100" (Reserved for - Geographic) Format Prefixes to Unassigned. - - Added section on Interface ID definition for unicast addresses. - Requires use of EUI-64 in range of format prefixes and rules for - setting global/local scope bit in EUI-64. - - Updated NSAP text to reflect working in RFC1888. - - Removed protocol specific IPv6 multicast addresses (e.g., DHCP) - and referenced the IANA definitions. - - Removed section "Unicast Address Example". Had become OBE. - - Added new and updated references. - - Minor text clarifications and improvements. - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 23] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -REFERENCES - - [ABNF] Crocker, D., and P. Overell, "Augmented BNF for - Syntax Specifications: ABNF", RFC 2234, November 1997. - - [AGGR] Hinden, R., O'Dell, M., and S. Deering, "An - Aggregatable Global Unicast Address Format", RFC 2374, July - 1998. - - [AUTH] Atkinson, R., "IP Authentication Header", RFC 1826, August - 1995. - - [ANYCST] Partridge, C., Mendez, T., and W. Milliken, "Host - Anycasting Service", RFC 1546, November 1993. - - [CIDR] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless - Inter-Domain Routing (CIDR): An Address Assignment and - Aggregation Strategy", RFC 1519, September 1993. - - [ETHER] Crawford, M., "Transmission of IPv6 Pacekts over Ethernet - Networks", Work in Progress. - - [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) - Registration Authority", - http://standards.ieee.org/db/oui/tutorials/EUI64.html, - March 1997. - - [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI - Networks", Work in Progress. - - [IPV6] Deering, S., and R. Hinden, Editors, "Internet Protocol, - Version 6 (IPv6) Specification", RFC 1883, December 1995. - - [MASGN] Hinden, R., and S. Deering, "IPv6 Multicast Address - Assignments", RFC 2375, July 1998. - - [NSAP] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J., - and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [TOKEN] Thomas, S., "Transmission of IPv6 Packets over Token Ring - Networks", Work in Progress. - - [TRAN] Gilligan, R., and E. Nordmark, "Transition Mechanisms for - IPv6 Hosts and Routers", RFC 1993, April 1996. - - - - -Hinden & Deering Standards Track [Page 24] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -AUTHORS' ADDRESSES - - Robert M. Hinden - Nokia - 232 Java Drive - Sunnyvale, CA 94089 - USA - - Phone: +1 408 990-2004 - Fax: +1 408 743-5677 - EMail: hinden@iprg.nokia.com - - - Stephen E. Deering - Cisco Systems, Inc. - 170 West Tasman Drive - San Jose, CA 95134-1706 - USA - - Phone: +1 408 527-8213 - Fax: +1 408 527-8254 - EMail: deering@cisco.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 25] - -RFC 2373 IPv6 Addressing Architecture July 1998 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 26] - diff --git a/contrib/bind9/doc/rfc/rfc2374.txt b/contrib/bind9/doc/rfc/rfc2374.txt deleted file mode 100644 index e3c7f0de490a..000000000000 --- a/contrib/bind9/doc/rfc/rfc2374.txt +++ /dev/null @@ -1,675 +0,0 @@ - - - - - - -Network Working Group R. Hinden -Request for Comments: 2374 Nokia -Obsoletes: 2073 M. O'Dell -Category: Standards Track UUNET - S. Deering - Cisco - July 1998 - - - An IPv6 Aggregatable Global Unicast Address Format - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -1.0 Introduction - - This document defines an IPv6 aggregatable global unicast address - format for use in the Internet. The address format defined in this - document is consistent with the IPv6 Protocol [IPV6] and the "IPv6 - Addressing Architecture" [ARCH]. It is designed to facilitate - scalable Internet routing. - - This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast - Address Format". RFC 2073 will become historic. The Aggregatable - Global Unicast Address Format is an improvement over RFC 2073 in a - number of areas. The major changes include removal of the registry - bits because they are not needed for route aggregation, support of - EUI-64 based interface identifiers, support of provider and exchange - based aggregation, separation of public and site topology, and new - aggregation based terminology. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC 2119]. - - - - - - - - -Hinden, et. al. Standards Track [Page 1] - -RFC 2374 IPv6 Global Unicast Address Format July 1998 - - -2.0 Overview of the IPv6 Address - - IPv6 addresses are 128-bit identifiers for interfaces and sets of - interfaces. There are three types of addresses: Unicast, Anycast, - and Multicast. This document defines a specific type of Unicast - address. - - In this document, fields in addresses are given specific names, for - example "subnet". When this name is used with the term "ID" (for - "identifier") after the name (e.g., "subnet ID"), it refers to the - contents of the named field. When it is used with the term "prefix" - (e.g. "subnet prefix") it refers to all of the addressing bits to - the left of and including this field. - - IPv6 unicast addresses are designed assuming that the Internet - routing system makes forwarding decisions based on a "longest prefix - match" algorithm on arbitrary bit boundaries and does not have any - knowledge of the internal structure of IPv6 addresses. The structure - in IPv6 addresses is for assignment and allocation. The only - exception to this is the distinction made between unicast and - multicast addresses. - - The specific type of an IPv6 address is indicated by the leading bits - in the address. The variable-length field comprising these leading - bits is called the Format Prefix (FP). - - This document defines an address format for the 001 (binary) Format - Prefix for Aggregatable Global Unicast addresses. The same address - format could be used for other Format Prefixes, as long as these - Format Prefixes also identify IPv6 unicast addresses. Only the "001" - Format Prefix is defined here. - -3.0 IPv6 Aggregatable Global Unicast Address Format - - This document defines an address format for the IPv6 aggregatable - global unicast address assignment. The authors believe that this - address format will be widely used for IPv6 nodes connected to the - Internet. This address format is designed to support both the - current provider-based aggregation and a new type of exchange-based - aggregation. The combination will allow efficient routing - aggregation for sites that connect directly to providers and for - sites that connect to exchanges. Sites will have the choice to - connect to either type of aggregation entity. - - - - - - - - -Hinden, et. al. Standards Track [Page 2] - -RFC 2374 IPv6 Global Unicast Address Format July 1998 - - - While this address format is designed to support exchange-based - aggregation (in addition to current provider-based aggregation) it is - not dependent on exchanges for it's overall route aggregation - properties. It will provide efficient route aggregation with only - provider-based aggregation. - - Aggregatable addresses are organized into a three level hierarchy: - - - Public Topology - - Site Topology - - Interface Identifier - - Public topology is the collection of providers and exchanges who - provide public Internet transit services. Site topology is local to - a specific site or organization which does not provide public transit - service to nodes outside of the site. Interface identifiers identify - interfaces on links. - - ______________ ______________ - --+/ \+--------------+/ \+---------- - ( P1 ) +----+ ( P3 ) +----+ - +\______________/ | |----+\______________/+--| |-- - | +--| X1 | +| X2 | - | ______________ / | |-+ ______________ / | |-- - +/ \+ +-+--+ \ / \+ +----+ - ( P2 ) / \ +( P4 ) - --+\______________/ / \ \______________/ - | / \ | | - | / | | | - | / | | | - _|_ _/_ _|_ _|_ _|_ - / \ / \ / \ / \ / \ - ( S.A ) ( S.B ) ( P5 ) ( P6 )( S.C ) - \___/ \___/ \___/ \___/ \___/ - | / \ - _|_ _/_ \ ___ - / \ / \ +-/ \ - ( S.D ) ( S.E ) ( S.F ) - \___/ \___/ \___/ - - As shown in the figure above, the aggregatable address format is - designed to support long-haul providers (shown as P1, P2, P3, and - P4), exchanges (shown as X1 and X2), multiple levels of providers - (shown at P5 and P6), and subscribers (shown as S.x) Exchanges - (unlike current NAPs, FIXes, etc.) will allocate IPv6 addresses. - Organizations who connect to these exchanges will also subscribe - (directly, indirectly via the exchange, etc.) for long-haul service - from one or more long-haul providers. Doing so, they will achieve - - - -Hinden, et. al. Standards Track [Page 3] - -RFC 2374 IPv6 Global Unicast Address Format July 1998 - - - addressing independence from long-haul transit providers. They will - be able to change long-haul providers without having to renumber - their organization. They can also be multihomed via the exchange to - more than one long-haul provider without having to have address - prefixes from each long-haul provider. Note that the mechanisms used - for this type of provider selection and portability are not discussed - in the document. - -3.1 Aggregatable Global Unicast Address Structure - - The aggregatable global unicast address format is as follows: - - | 3| 13 | 8 | 24 | 16 | 64 bits | - +--+-----+---+--------+--------+--------------------------------+ - |FP| TLA |RES| NLA | SLA | Interface ID | - | | ID | | ID | ID | | - +--+-----+---+--------+--------+--------------------------------+ - - <--Public Topology---> Site - <--------> - Topology - <------Interface Identifier-----> - - Where - - FP Format Prefix (001) - TLA ID Top-Level Aggregation Identifier - RES Reserved for future use - NLA ID Next-Level Aggregation Identifier - SLA ID Site-Level Aggregation Identifier - INTERFACE ID Interface Identifier - - The following sections specify each part of the IPv6 Aggregatable - Global Unicast address format. - -3.2 Top-Level Aggregation ID - - Top-Level Aggregation Identifiers (TLA ID) are the top level in the - routing hierarchy. Default-free routers must have a routing table - entry for every active TLA ID and will probably have additional - entries providing routing information for the TLA ID in which they - are located. They may have additional entries in order to optimize - routing for their specific topology, but the routing topology at all - levels must be designed to minimize the number of additional entries - fed into the default free routing tables. - - - - - - -Hinden, et. al. Standards Track [Page 4] - -RFC 2374 IPv6 Global Unicast Address Format July 1998 - - - This addressing format supports 8,192 (2^13) TLA ID's. Additional - TLA ID's may be added by either growing the TLA field to the right - into the reserved field or by using this format for additional format - prefixes. - - The issues relating to TLA ID assignment are beyond the scope of this - document. They will be described in a document under preparation. - -3.3 Reserved - - The Reserved field is reserved for future use and must be set to - zero. - - The Reserved field allows for future growth of the TLA and NLA fields - as appropriate. See section 4.0 for a discussion. - -3.4 Next-Level Aggregation Identifier - - Next-Level Aggregation Identifier's are used by organizations - assigned a TLA ID to create an addressing hierarchy and to identify - sites. The organization can assign the top part of the NLA ID in a - manner to create an addressing hierarchy appropriate to its network. - It can use the remainder of the bits in the field to identify sites - it wishes to serve. This is shown as follows: - - | n | 24-n bits | 16 | 64 bits | - +-----+--------------------+--------+-----------------+ - |NLA1 | Site ID | SLA ID | Interface ID | - +-----+--------------------+--------+-----------------+ - - Each organization assigned a TLA ID receives 24 bits of NLA ID space. - This NLA ID space allows each organization to provide service to - approximately as many organizations as the current IPv4 Internet can - support total networks. - - Organizations assigned TLA ID's may also support NLA ID's in their - own Site ID space. This allows the organization assigned a TLA ID to - provide service to organizations providing public transit service and - to organizations who do not provide public transit service. These - organizations receiving an NLA ID may also choose to use their Site - ID space to support other NLA ID's. This is shown as follows: - - - - - - - - - - -Hinden, et. al. Standards Track [Page 5] - -RFC 2374 IPv6 Global Unicast Address Format July 1998 - - - | n | 24-n bits | 16 | 64 bits | - +-----+--------------------+--------+-----------------+ - |NLA1 | Site ID | SLA ID | Interface ID | - +-----+--------------------+--------+-----------------+ - - | m | 24-n-m | 16 | 64 bits | - +-----+--------------+--------+-----------------+ - |NLA2 | Site ID | SLA ID | Interface ID | - +-----+--------------+--------+-----------------+ - - | o |24-n-m-o| 16 | 64 bits | - +-----+--------+--------+-----------------+ - |NLA3 | Site ID| SLA ID | Interface ID | - +-----+--------+--------+-----------------+ - - The design of the bit layout of the NLA ID space for a specific TLA - ID is left to the organization responsible for that TLA ID. Likewise - the design of the bit layout of the next level NLA ID is the - responsibility of the previous level NLA ID. It is recommended that - organizations assigning NLA address space use "slow start" allocation - procedures similar to [RFC2050]. - - The design of an NLA ID allocation plan is a tradeoff between routing - aggregation efficiency and flexibility. Creating hierarchies allows - for greater amount of aggregation and results in smaller routing - tables. Flat NLA ID assignment provides for easier allocation and - attachment flexibility, but results in larger routing tables. - -3.5 Site-Level Aggregation Identifier - - The SLA ID field is used by an individual organization to create its - own local addressing hierarchy and to identify subnets. This is - analogous to subnets in IPv4 except that each organization has a much - greater number of subnets. The 16 bit SLA ID field support 65,535 - individual subnets. - - Organizations may choose to either route their SLA ID "flat" (e.g., - not create any logical relationship between the SLA identifiers that - results in larger routing tables), or to create a two or more level - hierarchy (that results in smaller routing tables) in the SLA ID - field. The latter is shown as follows: - - - - - - - - - - -Hinden, et. al. Standards Track [Page 6] - -RFC 2374 IPv6 Global Unicast Address Format July 1998 - - - | n | 16-n | 64 bits | - +-----+------------+-------------------------------------+ - |SLA1 | Subnet | Interface ID | - +-----+------------+-------------------------------------+ - - | m |16-n-m | 64 bits | - +----+-------+-------------------------------------+ - |SLA2|Subnet | Interface ID | - +----+-------+-------------------------------------+ - - The approach chosen for structuring an SLA ID field is the - responsibility of the individual organization. - - The number of subnets supported in this address format should be - sufficient for all but the largest of organizations. Organizations - which need additional subnets can arrange with the organization they - are obtaining Internet service from to obtain additional site - identifiers and use this to create additional subnets. - -3.6 Interface ID - - Interface identifiers are used to identify interfaces on a link. - They are required to be unique on that link. They may also be unique - over a broader scope. In many cases an interfaces identifier will be - the same or be based on the interface's link-layer address. - Interface IDs used in the aggregatable global unicast address format - are required to be 64 bits long and to be constructed in IEEE EUI-64 - format [EUI-64]. These identifiers may have global scope when a - global token (e.g., IEEE 48bit MAC) is available or may have local - scope where a global token is not available (e.g., serial links, - tunnel end-points, etc.). The "u" bit (universal/local bit in IEEE - EUI-64 terminology) in the EUI-64 identifier must be set correctly, - as defined in [ARCH], to indicate global or local scope. - - The procedures for creating EUI-64 based Interface Identifiers is - defined in [ARCH]. The details on forming interface identifiers is - defined in the appropriate "IPv6 over <link>" specification such as - "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. - -4.0 Technical Motivation - - The design choices for the size of the fields in the aggregatable - address format were based on the need to meet a number of technical - requirements. These are described in the following paragraphs. - - The size of the Top-Level Aggregation Identifier is 13 bits. This - allows for 8,192 TLA ID's. This size was chosen to insure that the - default-free routing table in top level routers in the Internet is - - - -Hinden, et. al. Standards Track [Page 7] - -RFC 2374 IPv6 Global Unicast Address Format July 1998 - - - kept within the limits, with a reasonable margin, of the current - routing technology. The margin is important because default-free - routers will also carry a significant number of longer (i.e., more- - specific) prefixes for optimizing paths internal to a TLA and between - TLAs. - - The important issue is not only the size of the default-free routing - table, but the complexity of the topology that determines the number - of copies of the default-free routes that a router must examine while - computing a forwarding table. Current practice with IPv4 it is - common to see a prefix announced fifteen times via different paths. - - The complexity of Internet topology is very likely to increase in the - future. It is important that IPv6 default-free routing support - additional complexity as well as a considerably larger internet. - - It should be noted for comparison that at the time of this writing - (spring, 1998) the IPv4 default-free routing table contains - approximately 50,000 prefixes. While this shows that it is possible - to support more routes than 8,192 it is matter of debate if the - number of prefixes supported today in IPv4 is already too high for - current routing technology. There are serious issues of route - stability as well as cases of providers not supporting all top level - prefixes. The technical requirement was to pick a TLA ID size that - was below, with a reasonable margin, what was being done with IPv4. - - The choice of 13 bits for the TLA field was an engineering - compromise. Fewer bits would have been too small by not supporting - enough top level organizations. More bits would have exceeded what - can be reasonably accommodated, with a reasonable margin, with - current routing technology in order to deal with the issues described - in the previous paragraphs. - - If in the future, routing technology improves to support a larger - number of top level routes in the default-free routing tables there - are two choices on how to increase the number TLA identifiers. The - first is to expand the TLA ID field into the reserved field. This - would increase the number of TLA ID's to approximately 2 million. - The second approach is to allocate another format prefix (FP) for use - with this address format. Either or a combination of these - approaches allows the number of TLA ID's to increase significantly. - - The size of the Reserved field is 8 bits. This size was chosen to - allow significant growth of either the TLA ID and/or the NLA ID - fields. - - The size of the Next-Level Aggregation Identifier field is 24 bits. - - - - -Hinden, et. al. Standards Track [Page 8] - -RFC 2374 IPv6 Global Unicast Address Format July 1998 - - - This allows for approximately sixteen million NLA ID's if used in a - flat manner. Used hierarchically it allows for a complexity roughly - equivalent to the IPv4 address space (assuming an average network - size of 254 interfaces). If in the future additional room for - complexity is needed in the NLA ID, this may be accommodated by - extending the NLA ID into the Reserved field. - - The size of the Site-Level Aggregation Identifier field is 16 bits. - This supports 65,535 individual subnets per site. The design goal - for the size of this field was to be sufficient for all but the - largest of organizations. Organizations which need additional - subnets can arrange with the organization they are obtaining Internet - service from to obtain additional site identifiers and use this to - create additional subnets. - - The Site-Level Aggregation Identifier field was given a fixed size in - order to force the length of all prefixes identifying a particular - site to be the same length (i.e., 48 bits). This facilitates - movement of sites in the topology (e.g., changing service providers - and multi-homing to multiple service providers). - - The Interface ID Interface Identifier field is 64 bits. This size - was chosen to meet the requirement specified in [ARCH] to support - EUI-64 based Interface Identifiers. - -5.0 Acknowledgments - - The authors would like to express our thanks to Thomas Narten, Bob - Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema, - Scott Bradner, Brian Carpenter, John Stewart, and Daniel Karrenberg - for their review and constructive comments. - -6.0 References - - [ALLOC] IAB and IESG, "IPv6 Address Allocation Management", - RFC 1881, December 1995. - - [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", - RFC 2373, July 1998. - - [AUTH] Atkinson, R., "IP Authentication Header", RFC 1826, August - 1995. - - [AUTO] Thompson, S., and T. Narten., "IPv6 Stateless Address - Autoconfiguration", RFC 1971, August 1996. - - [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet - Networks", Work in Progress. - - - -Hinden, et. al. Standards Track [Page 9] - -RFC 2374 IPv6 Global Unicast Address Format July 1998 - - - [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) - Registration Authority", - http://standards.ieee.org/db/oui/tutorials/EUI64.html, - March 1997. - - [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI - Networks", Work in Progress. - - [IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 - (IPv6) Specification", RFC 1883, December 1995. - - [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., - and J. Postel, "Internet Registry IP Allocation - Guidelines", BCP 12, RFC 1466, November 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - -7.0 Security Considerations - - IPv6 addressing documents do not have any direct impact on Internet - infrastructure security. Authentication of IPv6 packets is defined - in [AUTH]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hinden, et. al. Standards Track [Page 10] - -RFC 2374 IPv6 Global Unicast Address Format July 1998 - - -8.0 Authors' Addresses - - Robert M. Hinden - Nokia - 232 Java Drive - Sunnyvale, CA 94089 - USA - - Phone: 1 408 990-2004 - EMail: hinden@iprg.nokia.com - - - Mike O'Dell - UUNET Technologies, Inc. - 3060 Williams Drive - Fairfax, VA 22030 - USA - - Phone: 1 703 206-5890 - EMail: mo@uunet.uu.net - - - Stephen E. Deering - Cisco Systems, Inc. - 170 West Tasman Drive - San Jose, CA 95134-1706 - USA - - Phone: 1 408 527-8213 - EMail: deering@cisco.com - - - - - - - - - - - - - - - - - - - - - -Hinden, et. al. Standards Track [Page 11] - -RFC 2374 IPv6 Global Unicast Address Format July 1998 - - -9.0 Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Hinden, et. al. Standards Track [Page 12] - diff --git a/contrib/bind9/doc/rfc/rfc2375.txt b/contrib/bind9/doc/rfc/rfc2375.txt deleted file mode 100644 index a1fe8b9a40d8..000000000000 --- a/contrib/bind9/doc/rfc/rfc2375.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -Network Working Group R. Hinden -Request for Comments: 2375 Ipsilon Networks -Category: Informational S. Deering - Cisco - July 1998 - - - IPv6 Multicast Address Assignments - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -1.0 Introduction - - This document defines the initial assignment of IPv6 multicast - addresses. It is based on the "IP Version 6 Addressing Architecture" - [ADDARCH] and current IPv4 multicast address assignment found in - <ftp://venera.isi.edu/in-notes/iana/assignments/multicast-addresses>. - It adapts the IPv4 assignments that are relevant to IPv6 assignments. - IPv4 assignments that were not relevant were not converted into IPv6 - assignments. Comments are solicited on this conversion. - - All other IPv6 multicast addresses are reserved. - - Sections 2 and 3 specify reserved and preassigned IPv6 multicast - addresses. - - [ADDRARCH] defines rules for assigning new IPv6 multicast addresses. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC 2119]. - -2. Fixed Scope Multicast Addresses - - These permanently assigned multicast addresses are valid over a - specified scope value. - - - - - - - -Hinden & Deering Informational [Page 1] - -RFC 2375 IPv6 Multicast Address Assignments July 1998 - - -2.1 Node-Local Scope - - FF01:0:0:0:0:0:0:1 All Nodes Address [ADDARCH] - FF01:0:0:0:0:0:0:2 All Routers Address [ADDARCH] - -2.2 Link-Local Scope - - FF02:0:0:0:0:0:0:1 All Nodes Address [ADDARCH] - FF02:0:0:0:0:0:0:2 All Routers Address [ADDARCH] - FF02:0:0:0:0:0:0:3 Unassigned [JBP] - FF02:0:0:0:0:0:0:4 DVMRP Routers [RFC1075,JBP] - FF02:0:0:0:0:0:0:5 OSPFIGP [RFC2328,Moy] - FF02:0:0:0:0:0:0:6 OSPFIGP Designated Routers [RFC2328,Moy] - FF02:0:0:0:0:0:0:7 ST Routers [RFC1190,KS14] - FF02:0:0:0:0:0:0:8 ST Hosts [RFC1190,KS14] - FF02:0:0:0:0:0:0:9 RIP Routers [RFC2080] - FF02:0:0:0:0:0:0:A EIGRP Routers [Farinacci] - FF02:0:0:0:0:0:0:B Mobile-Agents [Bill Simpson] - - FF02:0:0:0:0:0:0:D All PIM Routers [Farinacci] - FF02:0:0:0:0:0:0:E RSVP-ENCAPSULATION [Braden] - - FF02:0:0:0:0:0:1:1 Link Name [Harrington] - FF02:0:0:0:0:0:1:2 All-dhcp-agents [Bound,Perkins] - - FF02:0:0:0:0:1:FFXX:XXXX Solicited-Node Address [ADDARCH] - -2.3 Site-Local Scope - - FF05:0:0:0:0:0:0:2 All Routers Address [ADDARCH] - - FF05:0:0:0:0:0:1:3 All-dhcp-servers [Bound,Perkins] - FF05:0:0:0:0:0:1:4 All-dhcp-relays [Bound,Perkins] - FF05:0:0:0:0:0:1:1000 Service Location [RFC2165] - -FF05:0:0:0:0:0:1:13FF - -3.0 All Scope Multicast Addresses - - These permanently assigned multicast addresses are valid over all - scope ranges. This is shown by an "X" in the scope field of the - address that means any legal scope value. - - Note that, as defined in [ADDARCH], IPv6 multicast addresses which - are only different in scope represent different groups. Nodes must - join each group individually. - - The IPv6 multicast addresses with variable scope are as follows: - - - - -Hinden & Deering Informational [Page 2] - -RFC 2375 IPv6 Multicast Address Assignments July 1998 - - - FF0X:0:0:0:0:0:0:0 Reserved Multicast Address [ADDARCH] - - FF0X:0:0:0:0:0:0:100 VMTP Managers Group [RFC1045,DRC3] - FF0X:0:0:0:0:0:0:101 Network Time Protocol (NTP) [RFC1119,DLM1] - FF0X:0:0:0:0:0:0:102 SGI-Dogfight [AXC] - FF0X:0:0:0:0:0:0:103 Rwhod [SXD] - FF0X:0:0:0:0:0:0:104 VNP [DRC3] - FF0X:0:0:0:0:0:0:105 Artificial Horizons - Aviator [BXF] - FF0X:0:0:0:0:0:0:106 NSS - Name Service Server [BXS2] - FF0X:0:0:0:0:0:0:107 AUDIONEWS - Audio News Multicast [MXF2] - FF0X:0:0:0:0:0:0:108 SUN NIS+ Information Service [CXM3] - FF0X:0:0:0:0:0:0:109 MTP Multicast Transport Protocol [SXA] - FF0X:0:0:0:0:0:0:10A IETF-1-LOW-AUDIO [SC3] - FF0X:0:0:0:0:0:0:10B IETF-1-AUDIO [SC3] - FF0X:0:0:0:0:0:0:10C IETF-1-VIDEO [SC3] - FF0X:0:0:0:0:0:0:10D IETF-2-LOW-AUDIO [SC3] - FF0X:0:0:0:0:0:0:10E IETF-2-AUDIO [SC3] - FF0X:0:0:0:0:0:0:10F IETF-2-VIDEO [SC3] - - FF0X:0:0:0:0:0:0:110 MUSIC-SERVICE [Guido van Rossum] - FF0X:0:0:0:0:0:0:111 SEANET-TELEMETRY [Andrew Maffei] - FF0X:0:0:0:0:0:0:112 SEANET-IMAGE [Andrew Maffei] - FF0X:0:0:0:0:0:0:113 MLOADD [Braden] - FF0X:0:0:0:0:0:0:114 any private experiment [JBP] - FF0X:0:0:0:0:0:0:115 DVMRP on MOSPF [Moy] - FF0X:0:0:0:0:0:0:116 SVRLOC [Veizades] - FF0X:0:0:0:0:0:0:117 XINGTV <hgxing@aol.com> - FF0X:0:0:0:0:0:0:118 microsoft-ds <arnoldm@microsoft.com> - FF0X:0:0:0:0:0:0:119 nbc-pro <bloomer@birch.crd.ge.com> - FF0X:0:0:0:0:0:0:11A nbc-pfn <bloomer@birch.crd.ge.com> - FF0X:0:0:0:0:0:0:11B lmsc-calren-1 [Uang] - FF0X:0:0:0:0:0:0:11C lmsc-calren-2 [Uang] - FF0X:0:0:0:0:0:0:11D lmsc-calren-3 [Uang] - FF0X:0:0:0:0:0:0:11E lmsc-calren-4 [Uang] - FF0X:0:0:0:0:0:0:11F ampr-info [Janssen] - - FF0X:0:0:0:0:0:0:120 mtrace [Casner] - FF0X:0:0:0:0:0:0:121 RSVP-encap-1 [Braden] - FF0X:0:0:0:0:0:0:122 RSVP-encap-2 [Braden] - FF0X:0:0:0:0:0:0:123 SVRLOC-DA [Veizades] - FF0X:0:0:0:0:0:0:124 rln-server [Kean] - FF0X:0:0:0:0:0:0:125 proshare-mc [Lewis] - FF0X:0:0:0:0:0:0:126 dantz [Yackle] - FF0X:0:0:0:0:0:0:127 cisco-rp-announce [Farinacci] - FF0X:0:0:0:0:0:0:128 cisco-rp-discovery [Farinacci] - FF0X:0:0:0:0:0:0:129 gatekeeper [Toga] - FF0X:0:0:0:0:0:0:12A iberiagames [Marocho] - - - - -Hinden & Deering Informational [Page 3] - -RFC 2375 IPv6 Multicast Address Assignments July 1998 - - - FF0X:0:0:0:0:0:0:201 "rwho" Group (BSD) (unofficial) [JBP] - FF0X:0:0:0:0:0:0:202 SUN RPC PMAPPROC_CALLIT [BXE1] - - FF0X:0:0:0:0:0:2:0000 - -FF0X:0:0:0:0:0:2:7FFD Multimedia Conference Calls [SC3] - FF0X:0:0:0:0:0:2:7FFE SAPv1 Announcements [SC3] - FF0X:0:0:0:0:0:2:7FFF SAPv0 Announcements (deprecated) [SC3] - FF0X:0:0:0:0:0:2:8000 - -FF0X:0:0:0:0:0:2:FFFF SAP Dynamic Assignments [SC3] - -5.0 References - - [ADDARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing - Architecture", RFC 2373, July 1998. - - [AUTORFC] Thompson, S., and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 1971, August 1996. - - [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet - Networks", Work in Progress. - - [RFC1045] Cheriton, D., "VMTP: Versatile Message Transaction Protocol - Specification", RFC 1045, February 1988. - - [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance - Vector Multicast Routing Protocol", RFC 1075, November - 1988. - - [RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, - RFC 1112, Stanford University, August 1989. - - [RFC1119] Mills, D., "Network Time Protocol (Version 1), - Specification and Implementation", STD 12, RFC 1119, July - 1988. - - [RFC1190] Topolcic, C., Editor, "Experimental Internet Stream - Protocol, Version 2 (ST-II)", RFC 1190, October 1990. - - [RFC2080] Malkin, G., and R. Minnear, "RIPng for IPv6", RFC 2080, - January 1997. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2165] Veizades, J., Guttman, E., Perkins, C., and S. Kaplan - "Service Location Protocol", RFC 2165 June 1997. - - [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. - - - -Hinden & Deering Informational [Page 4] - -RFC 2375 IPv6 Multicast Address Assignments July 1998 - - -6. People - - <arnoldm@microsoft.com> - - [AXC] Andrew Cherenson <arc@SGI.COM> - - [Braden] Bob Braden, <braden@isi.edu>, April 1996. - - [Bob Brenner] - - [Bressler] David J. Bressler, <bressler@tss.com>, April 1996. - - <bloomer@birch.crd.ge.com> - - [Bound] Jim Bound <bound@zk3.dec.com> - - [BXE1] Brendan Eic <brendan@illyria.wpd.sgi.com> - - [BXF] Bruce Factor <ahi!bigapple!bruce@uunet.UU.NET> - - [BXS2] Bill Schilit <schilit@parc.xerox.com> - - [Casner] Steve Casner, <casner@isi.edu>, January 1995. - - [CXM3] Chuck McManis <cmcmanis@sun.com> - - [Tim Clark] - - [DLM1] David Mills <Mills@HUEY.UDEL.EDU> - - [DRC3] Dave Cheriton <cheriton@PESCADERO.STANFORD.EDU> - - [DXS3] Daniel Steinber <Daniel.Steinberg@Eng.Sun.COM> - - [Farinacci] Dino Farinacci, <dino@cisco.com> - - [GSM11] Gary S. Malkin <GMALKIN@XYLOGICS.COM> - - [Harrington] Dan Harrington, <dan@lucent.com>, July 1996. - - <hgxing@aol.com> - - [IANA] IANA <iana@iana.org> - - [Janssen] Rob Janssen, <rob@pe1chl.ampr.org>, January 1995. - - [JBP] Jon Postel <postel@isi.edu> - - - - -Hinden & Deering Informational [Page 5] - -RFC 2375 IPv6 Multicast Address Assignments July 1998 - - - [JXM1] Jim Miner <miner@star.com> - - [Kean] Brian Kean, <bkean@dca.com>, August 1995. - - [KS14] <mystery contact> - - [Lee] Choon Lee, <cwl@nsd.3com.com>, April 1996. - - [Lewis] Mark Lewis, <Mark_Lewis@ccm.jf.intel.com>, October 1995. - - [Malamud] Carl Malamud, <carl@radio.com>, January 1996. - - [Andrew Maffei] - - [Marohco] Jose Luis Marocho, <73374.313@compuserve.com>, July 1996. - - [Moy] John Moy <jmoy@casc.com> - - [MXF2] Martin Forssen <maf@dtek.chalmers.se> - - [Perkins] Charlie Perkins, <cperkins@corp.sun.com> - - [Guido van Rossum] - - [SC3] Steve Casner <casner@isi.edu> - - [Simpson] Bill Simpson <bill.simpson@um.cc.umich.edu> November 1994. - - [Joel Snyder] - - [SXA] Susie Armstrong <Armstrong.wbst128@XEROX.COM> - - [SXD] Steve Deering <deering@PARC.XEROX.COM> - - [tynan] Dermot Tynan, <dtynan@claddagh.ie>, August 1995. - - [Toga] Jim Toga, <jtoga@ibeam.jf.intel.com>, May 1996. - - [Uang] Yea Uang <uang@force.decnet.lockheed.com> November 1994. - - [Veizades] John Veizades, <veizades@tgv.com>, May 1995. - - [Yackle] Dotty Yackle, <ditty_yackle@dantz.com>, February 1996. - - - - - - - - -Hinden & Deering Informational [Page 6] - -RFC 2375 IPv6 Multicast Address Assignments July 1998 - - -7.0 Security Considerations - - This document defines the initial assignment of IPv6 multicast - addresses. As such it does not directly impact the security of the - Internet infrastructure or its applications. - -8.0 Authors' Addresses - - Robert M. Hinden - Ipsilon Networks, Inc. - 232 Java Drive - Sunnyvale, CA 94089 - USA - - Phone: +1 415 990 2004 - EMail: hinden@ipsilon.com - - - Stephen E. Deering - Cisco Systems, Inc. - 170 West Tasman Drive - San Jose, CA 95134-1706 - USA - - Phone: +1 408 527-8213 - EMail: deering@cisco.com - - - - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Informational [Page 7] - -RFC 2375 IPv6 Multicast Address Assignments July 1998 - - -9.0 Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Informational [Page 8] - diff --git a/contrib/bind9/doc/rfc/rfc2418.txt b/contrib/bind9/doc/rfc/rfc2418.txt deleted file mode 100644 index 9bdb2c536783..000000000000 --- a/contrib/bind9/doc/rfc/rfc2418.txt +++ /dev/null @@ -1,1459 +0,0 @@ - - - - - - -Network Working Group S. Bradner -Request for Comments: 2418 Editor -Obsoletes: 1603 Harvard University -BCP: 25 September 1998 -Category: Best Current Practice - - - IETF Working Group - Guidelines and Procedures - -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. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -Abstract - - The Internet Engineering Task Force (IETF) has responsibility for - developing and reviewing specifications intended as Internet - Standards. IETF activities are organized into working groups (WGs). - This document describes the guidelines and procedures for formation - and operation of IETF working groups. It also describes the formal - relationship between IETF participants WG and the Internet - Engineering Steering Group (IESG) and the basic duties of IETF - participants, including WG Chairs, WG participants, and IETF Area - Directors. - -Table of Contents - - Abstract ......................................................... 1 - 1. Introduction .................................................. 2 - 1.1. IETF approach to standardization .......................... 4 - 1.2. Roles within a Working Group .............................. 4 - 2. Working group formation ....................................... 4 - 2.1. Criteria for formation .................................... 4 - 2.2. Charter ................................................... 6 - 2.3. Charter review & approval ................................. 8 - 2.4. Birds of a feather (BOF) .................................. 9 - 3. Working Group Operation ....................................... 10 - 3.1. Session planning .......................................... 11 - 3.2. Session venue ............................................. 11 - 3.3. Session management ........................................ 13 - 3.4. Contention and appeals .................................... 15 - - - -Bradner Best Current Practice [Page 1] - -RFC 2418 Working Group Guidelines September 1998 - - - 4. Working Group Termination ..................................... 15 - 5. Rechartering a Working Group .................................. 15 - 6. Staff Roles ................................................... 16 - 6.1. WG Chair .................................................. 16 - 6.2. WG Secretary .............................................. 18 - 6.3. Document Editor ........................................... 18 - 6.4. WG Facilitator ............................................ 18 - 6.5. Design teams .............................................. 19 - 6.6. Working Group Consultant .................................. 19 - 6.7. Area Director ............................................. 19 - 7. Working Group Documents ....................................... 19 - 7.1. Session documents ......................................... 19 - 7.2. Internet-Drafts (I-D) ..................................... 19 - 7.3. Request For Comments (RFC) ................................ 20 - 7.4. Working Group Last-Call ................................... 20 - 7.5. Submission of documents ................................... 21 - 8. Review of documents ........................................... 21 - 9. Security Considerations ....................................... 22 - 10. Acknowledgments .............................................. 23 - 11. References ................................................... 23 - 12. Editor's Address ............................................. 23 - Appendix: Sample Working Group Charter .......................... 24 - Full Copyright Statement ......................................... 26 - -1. Introduction - - The Internet, a loosely-organized international collaboration of - autonomous, interconnected networks, supports host-to-host - communication through voluntary adherence to open protocols and - procedures defined by Internet Standards. There are also many - isolated interconnected networks, which are not connected to the - global Internet but use the Internet Standards. Internet Standards - are developed in the Internet Engineering Task Force (IETF). This - document defines guidelines and procedures for IETF working groups. - The Internet Standards Process of the IETF is defined in [1]. The - organizations involved in the IETF Standards Process are described in - [2] as are the roles of specific individuals. - - The IETF is a large, open community of network designers, operators, - vendors, users, and researchers concerned with the Internet and the - technology used on it. The primary activities of the IETF are - performed by committees known as working groups. There are currently - more than 100 working groups. (See the IETF web page for an up-to- - date list of IETF Working Groups - http://www.ietf.org.) Working - groups tend to have a narrow focus and a lifetime bounded by the - completion of a specific set of tasks, although there are exceptions. - - - - - -Bradner Best Current Practice [Page 2] - -RFC 2418 Working Group Guidelines September 1998 - - - For management purposes, the IETF working groups are collected - together into areas, with each area having a separate focus. For - example, the security area deals with the development of security- - related technology. Each IETF area is managed by one or two Area - Directors (ADs). There are currently 8 areas in the IETF but the - number changes from time to time. (See the IETF web page for a list - of the current areas, the Area Directors for each area, and a list of - which working groups are assigned to each area.) - - In many areas, the Area Directors have formed an advisory group or - directorate. These comprise experienced members of the IETF and the - technical community represented by the area. The specific name and - the details of the role for each group differ from area to area, but - the primary intent is that these groups assist the Area Director(s), - e.g., with the review of specifications produced in the area. - - The IETF area directors are selected by a nominating committee, which - also selects an overall chair for the IETF. The nominations process - is described in [3]. - - The area directors sitting as a body, along with the IETF Chair, - comprise the Internet Engineering Steering Group (IESG). The IETF - Executive Director is an ex-officio participant of the IESG, as are - the IAB Chair and a designated Internet Architecture Board (IAB) - liaison. The IESG approves IETF Standards and approves the - publication of other IETF documents. (See [1].) - - A small IETF Secretariat provides staff and administrative support - for the operation of the IETF. - - There is no formal membership in the IETF. Participation is open to - all. This participation may be by on-line contribution, attendance - at face-to-face sessions, or both. Anyone from the Internet - community who has the time and interest is urged to participate in - IETF meetings and any of its on-line working group discussions. - Participation is by individual technical contributors, rather than by - formal representatives of organizations. - - This document defines procedures and guidelines for the formation and - operation of working groups in the IETF. It defines the relations of - working groups to other bodies within the IETF. The duties of working - group Chairs and Area Directors with respect to the operation of the - working group are also defined. When used in this document the key - words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", - "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be - interpreted as described in RFC 2119 [6]. RFC 2119 defines the use - of these key words to help make the intent of standards track - documents as clear as possible. The same key words are used in this - - - -Bradner Best Current Practice [Page 3] - -RFC 2418 Working Group Guidelines September 1998 - - - document to help smooth WG operation and reduce the chance for - confusion about the processes. - -1.1. IETF approach to standardization - - Familiarity with The Internet Standards Process [1] is essential for - a complete understanding of the philosophy, procedures and guidelines - described in this document. - -1.2. Roles within a Working Group - - The document, "Organizations Involved in the IETF Standards Process" - [2] describes the roles of a number of individuals within a working - group, including the working group chair and the document editor. - These descriptions are expanded later in this document. - -2. Working group formation - - IETF working groups (WGs) are the primary mechanism for development - of IETF specifications and guidelines, many of which are intended to - be standards or recommendations. A working group may be established - at the initiative of an Area Director or it may be initiated by an - individual or group of individuals. Anyone interested in creating an - IETF working group MUST obtain the advice and consent of the IETF - Area Director(s) in whose area the working group would fall and MUST - proceed through the formal steps detailed in this section. - - Working groups are typically created to address a specific problem or - to produce one or more specific deliverables (a guideline, standards - specification, etc.). Working groups are generally expected to be - short-lived in nature. Upon completion of its goals and achievement - of its objectives, the working group is terminated. A working group - may also be terminated for other reasons (see section 4). - Alternatively, with the concurrence of the IESG, Area Director, the - WG Chair, and the WG participants, the objectives or assignment of - the working group may be extended by modifying the working group's - charter through a rechartering process (see section 5). - -2.1. Criteria for formation - - When determining whether it is appropriate to create a working group, - the Area Director(s) and the IESG will consider several issues: - - - Are the issues that the working group plans to address clear and - relevant to the Internet community? - - - Are the goals specific and reasonably achievable, and achievable - within a reasonable time frame? - - - -Bradner Best Current Practice [Page 4] - -RFC 2418 Working Group Guidelines September 1998 - - - - What are the risks and urgency of the work, to determine the level - of effort required? - - - Do the working group's activities overlap with those of another - working group? If so, it may still be appropriate to create the - working group, but this question must be considered carefully by - the Area Directors as subdividing efforts often dilutes the - available technical expertise. - - - Is there sufficient interest within the IETF in the working - group's topic with enough people willing to expend the effort to - produce the desired result (e.g., a protocol specification)? - Working groups require considerable effort, including management - of the working group process, editing of working group documents, - and contributing to the document text. IETF experience suggests - that these roles typically cannot all be handled by one person; a - minimum of four or five active participants in the management - positions are typically required in addition to a minimum of one - or two dozen people that will attend the working group meetings - and contribute on the mailing list. NOTE: The interest must be - broad enough that a working group would not be seen as merely the - activity of a single vendor. - - - Is there enough expertise within the IETF in the working group's - topic, and are those people interested in contributing in the - working group? - - - Does a base of interested consumers (end-users) appear to exist - for the planned work? Consumer interest can be measured by - participation of end-users within the IETF process, as well as by - less direct means. - - - Does the IETF have a reasonable role to play in the determination - of the technology? There are many Internet-related technologies - that may be interesting to IETF members but in some cases the IETF - may not be in a position to effect the course of the technology in - the "real world". This can happen, for example, if the technology - is being developed by another standards body or an industry - consortium. - - - Are all known intellectual property rights relevant to the - proposed working group's efforts issues understood? - - - Is the proposed work plan an open IETF effort or is it an attempt - to "bless" non-IETF technology where the effect of input from IETF - participants may be limited? - - - - - -Bradner Best Current Practice [Page 5] - -RFC 2418 Working Group Guidelines September 1998 - - - - Is there a good understanding of any existing work that is - relevant to the topics that the proposed working group is to - pursue? This includes work within the IETF and elsewhere. - - - Do the working group's goals overlap with known work in another - standards body, and if so is adequate liaison in place? - - Considering the above criteria, the Area Director(s), using his or - her best judgement, will decide whether to pursue the formation of - the group through the chartering process. - -2.2. Charter - - The formation of a working group requires a charter which is - primarily negotiated between a prospective working group Chair and - the relevant Area Director(s), although final approval is made by the - IESG with advice from the Internet Architecture Board (IAB). A - charter is a contract between a working group and the IETF to perform - a set of tasks. A charter: - - 1. Lists relevant administrative information for the working group; - 2. Specifies the direction or objectives of the working group and - describes the approach that will be taken to achieve the goals; - and - 3. Enumerates a set of milestones together with time frames for their - completion. - - When the prospective Chair(s), the Area Director and the IETF - Secretariat are satisfied with the charter form and content, it - becomes the basis for forming a working group. Note that an Area - Director MAY require holding an exploratory Birds of a Feather (BOF) - meeting, as described below, to gage the level of support for a - working group before submitting the charter to the IESG and IAB for - approval. - - Charters may be renegotiated periodically to reflect the current - status, organization or goals of the working group (see section 5). - Hence, a charter is a contract between the IETF and the working group - which is committing to meet explicit milestones and delivering - specific "products". - - Specifically, each charter consists of the following sections: - - Working group name - A working group name should be reasonably descriptive or - identifiable. Additionally, the group shall define an acronym - (maximum 8 printable ASCII characters) to reference the group in - the IETF directories, mailing lists, and general documents. - - - -Bradner Best Current Practice [Page 6] - -RFC 2418 Working Group Guidelines September 1998 - - - Chair(s) - The working group may have one or more Chairs to perform the - administrative functions of the group. The email address(es) of - the Chair(s) shall be included. Generally, a working group is - limited to two chairs. - - Area and Area Director(s) - The name of the IETF area with which the working group is - affiliated and the name and electronic mail address of the - associated Area Director(s). - - Responsible Area Director - The Area Director who acts as the primary IESG contact for the - working group. - - Mailing list - An IETF working group MUST have a general Internet mailing list. - Most of the work of an IETF working group will be conducted on the - mailing list. The working group charter MUST include: - - 1. The address to which a participant sends a subscription request - and the procedures to follow when subscribing, - - 2. The address to which a participant sends submissions and - special procedures, if any, and - - 3. The location of the mailing list archive. A message archive - MUST be maintained in a public place which can be accessed via - FTP or via the web. - - As a service to the community, the IETF Secretariat operates a - mailing list archive for working group mailing lists. In order - to take advantage of this service, working group mailing lists - MUST include the address "wg_acronym-archive@lists.ietf.org" - (where "wg_acronym" is the working group acronym) in the - mailing list in order that a copy of all mailing list messages - be recorded in the Secretariat's archive. Those archives are - located at ftp://ftp.ietf.org/ietf-mail-archive. For - robustness, WGs SHOULD maintain an additional archive separate - from that maintained by the Secretariat. - - Description of working group - The focus and intent of the group shall be set forth briefly. By - reading this section alone, an individual should be able to decide - whether this group is relevant to their own work. The first - paragraph must give a brief summary of the problem area, basis, - goal(s) and approach(es) planned for the working group. This - paragraph can be used as an overview of the working group's - - - -Bradner Best Current Practice [Page 7] - -RFC 2418 Working Group Guidelines September 1998 - - - effort. - - To facilitate evaluation of the intended work and to provide on- - going guidance to the working group, the charter must describe the - problem being solved and should discuss objectives and expected - impact with respect to: - - - Architecture - - Operations - - Security - - Network management - - Scaling - - Transition (where applicable) - - Goals and milestones - The working group charter MUST establish a timetable for specific - work items. While this may be renegotiated over time, the list of - milestones and dates facilitates the Area Director's tracking of - working group progress and status, and it is indispensable to - potential participants identifying the critical moments for input. - Milestones shall consist of deliverables that can be qualified as - showing specific achievement; e.g., "Internet-Draft finished" is - fine, but "discuss via email" is not. It is helpful to specify - milestones for every 3-6 months, so that progress can be gauged - easily. This milestone list is expected to be updated - periodically (see section 5). - - An example of a WG charter is included as Appendix A. - -2.3. Charter review & approval - - Proposed working groups often comprise technically competent - participants who are not familiar with the history of Internet - architecture or IETF processes. This can, unfortunately, lead to - good working group consensus about a bad design. To facilitate - working group efforts, an Area Director may assign a Consultant from - among the ranks of senior IETF participants. (Consultants are - described in section 6.) At the discretion of the Area Director, - approval of a new WG may be withheld in the absence of sufficient - consultant resources. - - Once the Area Director (and the Area Directorate, as the Area - Director deems appropriate) has approved the working group charter, - the charter is submitted for review by the IAB and approval by the - IESG. After a review period of at least a week the proposed charter - is posted to the IETF-announce mailing list as a public notice that - the formation of the working group is being considered. At the same - time the proposed charter is also posted to the "new-work" mailing - - - -Bradner Best Current Practice [Page 8] - -RFC 2418 Working Group Guidelines September 1998 - - - list. This mailing list has been created to let qualified - representatives from other standards organizations know about pending - IETF working groups. After another review period lasting at least a - week the IESG MAY approve the charter as-is, it MAY request that - changes be made in the charter, or MAY decline to approve chartering - of the working group - - If the IESG approves the formation of the working group it remands - the approved charter to the IETF Secretariat who records and enters - the information into the IETF tracking database. The working group - is announced to the IETF-announce a by the IETF Secretariat. - -2.4. Birds of a Feather (BOF) - - Often it is not clear whether an issue merits the formation of a - working group. To facilitate exploration of the issues the IETF - offers the possibility of a Birds of a Feather (BOF) session, as well - as the early formation of an email list for preliminary discussion. - In addition, a BOF may serve as a forum for a single presentation or - discussion, without any intent to form a working group. - - A BOF is a session at an IETF meeting which permits "market research" - and technical "brainstorming". Any individual may request permission - to hold a BOF on a subject. The request MUST be filed with a relevant - Area Director who must approve a BOF before it can be scheduled. The - person who requests the BOF may be asked to serve as Chair of the - BOF. - - The Chair of the BOF is also responsible for providing a report on - the outcome of the BOF. If the Area Director approves, the BOF is - then scheduled by submitting a request to agenda@ietf.org with copies - to the Area Director(s). A BOF description and agenda are required - before a BOF can be scheduled. - - Available time for BOFs is limited, and BOFs are held at the - discretion of the ADs for an area. The AD(s) may require additional - assurances before authorizing a BOF. For example, - - - The Area Director MAY require the establishment of an open email - list prior to authorizing a BOF. This permits initial exchanges - and sharing of framework, vocabulary and approaches, in order to - make the time spent in the BOF more productive. - - - The Area Director MAY require that a BOF be held, prior to - establishing a working group (see section 2.2). - - - The Area Director MAY require that there be a draft of the WG - charter prior to holding a BOF. - - - -Bradner Best Current Practice [Page 9] - -RFC 2418 Working Group Guidelines September 1998 - - - - The Area Director MAY require that a BOF not be held until an - Internet-Draft describing the proposed technology has been - published so it can be used as a basis for discussion in the BOF. - - In general, a BOF on a particular topic is held only once (ONE slot - at one IETF Plenary meeting). Under unusual circumstances Area - Directors may, at their discretion, allow a BOF to meet for a second - time. BOFs are not permitted to meet three times. Note that all - other things being equal, WGs will be given priority for meeting - space over BOFs. Also, occasionally BOFs may be held for other - purposes than to discuss formation of a working group. - - Usually the outcome of a BOF will be one of the following: - - - There was enough interest and focus in the subject to warrant the - formation of a WG; - - - While there was a reasonable level of interest expressed in the - BOF some other criteria for working group formation was not met - (see section 2.1). - - - The discussion came to a fruitful conclusion, with results to be - written down and published, however there is no need to establish - a WG; or - - - There was not enough interest in the subject to warrant the - formation of a WG. - -3. Working Group Operation - - The IETF has basic requirements for open and fair participation and - for thorough consideration of technical alternatives. Within those - constraints, working groups are autonomous and each determines most - of the details of its own operation with respect to session - participation, reaching closure, etc. The core rule for operation is - that acceptance or agreement is achieved via working group "rough - consensus". WG participants should specifically note the - requirements for disclosure of conflicts of interest in [2]. - - A number of procedural questions and issues will arise over time, and - it is the function of the Working Group Chair(s) to manage the group - process, keeping in mind that the overall purpose of the group is to - make progress towards reaching rough consensus in realizing the - working group's goals and objectives. - - There are few hard and fast rules on organizing or conducting working - group activities, but a set of guidelines and practices has evolved - over time that have proven successful. These are listed here, with - - - -Bradner Best Current Practice [Page 10] - -RFC 2418 Working Group Guidelines September 1998 - - - actual choices typically determined by the working group participants - and the Chair(s). - -3.1. Session planning - - For coordinated, structured WG interactions, the Chair(s) MUST - publish a draft agenda well in advance of the actual session. The - agenda should contain at least: - - - The items for discussion; - - The estimated time necessary per item; and - - A clear indication of what documents the participants will need to - read before the session in order to be well prepared. - - Publication of the working group agenda shall include sending a copy - of the agenda to the working group mailing list and to - agenda@ietf.org. - - All working group actions shall be taken in a public forum, and wide - participation is encouraged. A working group will conduct much of its - business via electronic mail distribution lists but may meet - periodically to discuss and review task status and progress, to - resolve specific issues and to direct future activities. IETF - Plenary meetings are the primary venue for these face-to-face working - group sessions, and it is common (though not required) that active - "interim" face-to-face meetings, telephone conferences, or video - conferences may also be held. Interim meetings are subject to the - same rules for advance notification, reporting, open participation, - and process, which apply to other working group meetings. - - All working group sessions (including those held outside of the IETF - meetings) shall be reported by making minutes available. These - minutes should include the agenda for the session, an account of the - discussion including any decisions made, and a list of attendees. The - Working Group Chair is responsible for insuring that session minutes - are written and distributed, though the actual task may be performed - by someone designated by the Working Group Chair. The minutes shall - be submitted in printable ASCII text for publication in the IETF - Proceedings, and for posting in the IETF Directories and are to be - sent to: minutes@ietf.org - -3.2. Session venue - - Each working group will determine the balance of email and face-to- - face sessions that is appropriate for achieving its milestones. - Electronic mail permits the widest participation; face-to-face - meetings often permit better focus and therefore can be more - efficient for reaching a consensus among a core of the working group - - - -Bradner Best Current Practice [Page 11] - -RFC 2418 Working Group Guidelines September 1998 - - - participants. In determining the balance, the WG must ensure that - its process does not serve to exclude contribution by email-only - participants. Decisions reached during a face-to-face meeting about - topics or issues which have not been discussed on the mailing list, - or are significantly different from previously arrived mailing list - consensus MUST be reviewed on the mailing list. - - IETF Meetings - If a WG needs a session at an IETF meeting, the Chair must apply for - time-slots as soon as the first announcement of that IETF meeting is - made by the IETF Secretariat to the WG-chairs list. Session time is - a scarce resource at IETF meetings, so placing requests early will - facilitate schedule coordination for WGs requiring the same set of - experts. - - The application for a WG session at an IETF meeting MUST be made to - the IETF Secretariat at the address agenda@ietf.org. Some Area - Directors may want to coordinate WG sessions in their area and - request that time slots be coordinated through them. If this is the - case it will be noted in the IETF meeting announcement. A WG - scheduling request MUST contain: - - - The working group name and full title; - - The amount of time requested; - - The rough outline of the WG agenda that is expected to be covered; - - The estimated number of people that will attend the WG session; - - Related WGs that should not be scheduled for the same time slot(s); - and - - Optionally a request can be added for the WG session to be - transmitted over the Internet in audio and video. - - NOTE: While open discussion and contribution is essential to working - group success, the Chair is responsible for ensuring forward - progress. When acceptable to the WG, the Chair may call for - restricted participation (but not restricted attendance!) at IETF - working group sessions for the purpose of achieving progress. The - Working Group Chair then has the authority to refuse to grant the - floor to any individual who is unprepared or otherwise covering - inappropriate material, or who, in the opinion of the Chair is - disrupting the WG process. The Chair should consult with the Area - Director(s) if the individual persists in disruptive behavior. - - On-line - It can be quite useful to conduct email exchanges in the same manner - as a face-to-face session, with published schedule and agenda, as - well as on-going summarization and consensus polling. - - - - - -Bradner Best Current Practice [Page 12] - -RFC 2418 Working Group Guidelines September 1998 - - - Many working group participants hold that mailing list discussion is - the best place to consider and resolve issues and make decisions. The - choice of operational style is made by the working group itself. It - is important to note, however, that Internet email discussion is - possible for a much wider base of interested persons than is - attendance at IETF meetings, due to the time and expense required to - attend. - - As with face-to-face sessions occasionally one or more individuals - may engage in behavior on a mailing list which disrupts the WG's - progress. In these cases the Chair should attempt to discourage the - behavior by communication directly with the offending individual - rather than on the open mailing list. If the behavior persists then - the Chair must involve the Area Director in the issue. As a last - resort and after explicit warnings, the Area Director, with the - approval of the IESG, may request that the mailing list maintainer - block the ability of the offending individual to post to the mailing - list. (If the mailing list software permits this type of operation.) - Even if this is done, the individual must not be prevented from - receiving messages posted to the list. Other methods of mailing list - control may be considered but must be approved by the AD(s) and the - IESG. - -3.3. Session management - - Working groups make decisions through a "rough consensus" process. - IETF consensus does not require that all participants agree although - this is, of course, preferred. In general, the dominant view of the - working group shall prevail. (However, it must be noted that - "dominance" is not to be determined on the basis of volume or - persistence, but rather a more general sense of agreement.) Consensus - can be determined by a show of hands, humming, or any other means on - which the WG agrees (by rough consensus, of course). Note that 51% - of the working group does not qualify as "rough consensus" and 99% is - better than rough. It is up to the Chair to determine if rough - consensus has been reached. - - It can be particularly challenging to gauge the level of consensus on - a mailing list. There are two different cases where a working group - may be trying to understand the level of consensus via a mailing list - discussion. But in both cases the volume of messages on a topic is - not, by itself, a good indicator of consensus since one or two - individuals may be generating much of the traffic. - - In the case where a consensus which has been reached during a face- - to-face meeting is being verified on a mailing list the people who - were in the meeting and expressed agreement must be taken into - account. If there were 100 people in a meeting and only a few people - - - -Bradner Best Current Practice [Page 13] - -RFC 2418 Working Group Guidelines September 1998 - - - on the mailing list disagree with the consensus of the meeting then - the consensus should be seen as being verified. Note that enough - time should be given to the verification process for the mailing list - readers to understand and consider any objections that may be raised - on the list. The normal two week last-call period should be - sufficient for this. - - The other case is where the discussion has been held entirely over - the mailing list. The determination of the level of consensus may be - harder to do in this case since most people subscribed to mailing - lists do not actively participate in discussions on the list. It is - left to the discretion of the working group chair how to evaluate the - level of consensus. The most common method used is for the working - group chair to state what he or she believes to be the consensus view - and. at the same time, requests comments from the list about the - stated conclusion. - - The challenge to managing working group sessions is to balance the - need for open and fair consideration of the issues against the need - to make forward progress. The working group, as a whole, has the - final responsibility for striking this balance. The Chair has the - responsibility for overseeing the process but may delegate direct - process management to a formally-designated Facilitator. - - It is occasionally appropriate to revisit a topic, to re-evaluate - alternatives or to improve the group's understanding of a relevant - decision. However, unnecessary repeated discussions on issues can be - avoided if the Chair makes sure that the main arguments in the - discussion (and the outcome) are summarized and archived after a - discussion has come to conclusion. It is also good practice to note - important decisions/consensus reached by email in the minutes of the - next 'live' session, and to summarize briefly the decision-making - history in the final documents the WG produces. - - To facilitate making forward progress, a Working Group Chair may wish - to decide to reject or defer the input from a member, based upon the - following criteria: - - Old - The input pertains to a topic that already has been resolved and is - redundant with information previously available; - - Minor - The input is new and pertains to a topic that has already been - resolved, but it is felt to be of minor import to the existing - decision; - - - - - -Bradner Best Current Practice [Page 14] - -RFC 2418 Working Group Guidelines September 1998 - - - Timing - The input pertains to a topic that the working group has not yet - opened for discussion; or - - Scope - The input is outside of the scope of the working group charter. - -3.4. Contention and appeals - - Disputes are possible at various stages during the IETF process. As - much as possible the process is designed so that compromises can be - made, and genuine consensus achieved; however, there are times when - even the most reasonable and knowledgeable people are unable to - agree. To achieve the goals of openness and fairness, such conflicts - must be resolved by a process of open review and discussion. - - Formal procedures for requesting a review of WG, Chair, Area Director - or IESG actions and conducting appeals are documented in The Internet - Standards Process [1]. - -4. Working Group Termination - - Working groups are typically chartered to accomplish a specific task - or tasks. After the tasks are complete, the group will be disbanded. - However, if a WG produces a Proposed or Draft Standard, the WG will - frequently become dormant rather than disband (i.e., the WG will no - longer conduct formal activities, but the mailing list will remain - available to review the work as it moves to Draft Standard and - Standard status.) - - If, at some point, it becomes evident that a working group is unable - to complete the work outlined in the charter, or if the assumptions - which that work was based have been modified in discussion or by - experience, the Area Director, in consultation with the working group - can either: - - 1. Recharter to refocus its tasks, - 2. Choose new Chair(s), or - 3. Disband. - - If the working group disagrees with the Area Director's choice, it - may appeal to the IESG (see section 3.4). - -5. Rechartering a Working Group - - Updated milestones are renegotiated with the Area Director and the - IESG, as needed, and then are submitted to the IESG Secretariat: - iesg-secretary@ietf.org. - - - -Bradner Best Current Practice [Page 15] - -RFC 2418 Working Group Guidelines September 1998 - - - Rechartering (other than revising milestones) a working group follows - the same procedures that the initial chartering does (see section 2). - The revised charter must be submitted to the IESG and IAB for - approval. As with the initial chartering, the IESG may approve new - charter as-is, it may request that changes be made in the new charter - (including having the Working Group continue to use the old charter), - or it may decline to approve the rechartered working group. In the - latter case, the working group is disbanded. - -6. Staff Roles - - Working groups require considerable care and feeding. In addition to - general participation, successful working groups benefit from the - efforts of participants filling specific functional roles. The Area - Director must agree to the specific people performing the WG Chair, - and Working Group Consultant roles, and they serve at the discretion - of the Area Director. - -6.1. WG Chair - - The Working Group Chair is concerned with making forward progress - through a fair and open process, and has wide discretion in the - conduct of WG business. The Chair must ensure that a number of tasks - are performed, either directly or by others assigned to the tasks. - - The Chair has the responsibility and the authority to make decisions, - on behalf of the working group, regarding all matters of working - group process and staffing, in conformance with the rules of the - IETF. The AD has the authority and the responsibility to assist in - making those decisions at the request of the Chair or when - circumstances warrant such an intervention. - - The Chair's responsibility encompasses at least the following: - - Ensure WG process and content management - - The Chair has ultimate responsibility for ensuring that a working - group achieves forward progress and meets its milestones. The - Chair is also responsible to ensure that the working group - operates in an open and fair manner. For some working groups, - this can be accomplished by having the Chair perform all - management-related activities. In other working groups -- - particularly those with large or divisive participation -- it is - helpful to allocate process and/or secretarial functions to other - participants. Process management pertains strictly to the style - of working group interaction and not to its content. It ensures - fairness and detects redundancy. The secretarial function - encompasses document editing. It is quite common for a working - - - -Bradner Best Current Practice [Page 16] - -RFC 2418 Working Group Guidelines September 1998 - - - group to assign the task of specification Editor to one or two - participants. Sometimes, they also are part of the design team, - described below. - - Moderate the WG email list - - The Chair should attempt to ensure that the discussions on this - list are relevant and that they converge to consensus agreements. - The Chair should make sure that discussions on the list are - summarized and that the outcome is well documented (to avoid - repetition). The Chair also may choose to schedule organized on- - line "sessions" with agenda and deliverables. These can be - structured as true meetings, conducted over the course of several - days (to allow participation across the Internet). - - Organize, prepare and chair face-to-face and on-line formal - sessions. - - Plan WG Sessions - - The Chair must plan and announce all WG sessions well in advance - (see section 3.1). - - Communicate results of sessions - - The Chair and/or Secretary must ensure that minutes of a session - are taken and that an attendance list is circulated (see section - 3.1). - - Immediately after a session, the WG Chair MUST provide the Area - Director with a very short report (approximately one paragraph, - via email) on the session. - - Distribute the workload - - Of course, each WG will have participants who may not be able (or - want) to do any work at all. Most of the time the bulk of the work - is done by a few dedicated participants. It is the task of the - Chair to motivate enough experts to allow for a fair distribution - of the workload. - - Document development - - Working groups produce documents and documents need authors. The - Chair must make sure that authors of WG documents incorporate - changes as agreed to by the WG (see section 6.3). - - - - - -Bradner Best Current Practice [Page 17] - -RFC 2418 Working Group Guidelines September 1998 - - - Document publication - - The Chair and/or Document Editor will work with the RFC Editor to - ensure document conformance with RFC publication requirements [5] - and to coordinate any editorial changes suggested by the RFC - Editor. A particular concern is that all participants are working - from the same version of a document at the same time. - - Document implementations - - Under the procedures described in [1], the Chair is responsible - for documenting the specific implementations which qualify the - specification for Draft or Internet Standard status along with - documentation about testing of the interoperation of these - implementations. - -6.2. WG Secretary - - Taking minutes and editing working group documents often is performed - by a specifically-designated participant or set of participants. In - this role, the Secretary's job is to record WG decisions, rather than - to perform basic specification. - -6.3. Document Editor - - Most IETF working groups focus their efforts on a document, or set of - documents, that capture the results of the group's work. A working - group generally designates a person or persons to serve as the Editor - for a particular document. The Document Editor is responsible for - ensuring that the contents of the document accurately reflect the - decisions that have been made by the working group. - - As a general practice, the Working Group Chair and Document Editor - positions are filled by different individuals to help ensure that the - resulting documents accurately reflect the consensus of the working - group and that all processes are followed. - -6.4. WG Facilitator - - When meetings tend to become distracted or divisive, it often is - helpful to assign the task of "process management" to one - participant. Their job is to oversee the nature, rather than the - content, of participant interactions. That is, they attend to the - style of the discussion and to the schedule of the agenda, rather - than making direct technical contributions themselves. - - - - - - -Bradner Best Current Practice [Page 18] - -RFC 2418 Working Group Guidelines September 1998 - - -6.5. Design teams - - It is often useful, and perhaps inevitable, for a sub-group of a - working group to develop a proposal to solve a particular problem. - Such a sub-group is called a design team. In order for a design team - to remain small and agile, it is acceptable to have closed membership - and private meetings. Design teams may range from an informal chat - between people in a hallway to a formal set of expert volunteers that - the WG chair or AD appoints to attack a controversial problem. The - output of a design team is always subject to approval, rejection or - modification by the WG as a whole. - -6.6. Working Group Consultant - - At the discretion of the Area Director, a Consultant may be assigned - to a working group. Consultants have specific technical background - appropriate to the WG and experience in Internet architecture and - IETF process. - -6.7. Area Director - - Area Directors are responsible for ensuring that working groups in - their area produce coherent, coordinated, architecturally consistent - and timely output as a contribution to the overall results of the - IETF. - -7. Working Group Documents - -7.1. Session documents - - All relevant documents to be discussed at a session should be - published and available as Internet-Drafts at least two weeks before - a session starts. Any document which does not meet this publication - deadline can only be discussed in a working group session with the - specific approval of the working group chair(s). Since it is - important that working group members have adequate time to review all - documents, granting such an exception should only be done under - unusual conditions. The final session agenda should be posted to the - working group mailing list at least two weeks before the session and - sent at that time to agenda@ietf.org for publication on the IETF web - site. - -7.2. Internet-Drafts (I-D) - - The Internet-Drafts directory is provided to working groups as a - resource for posting and disseminating in-process copies of working - group documents. This repository is replicated at various locations - around the Internet. It is encouraged that draft documents be posted - - - -Bradner Best Current Practice [Page 19] - -RFC 2418 Working Group Guidelines September 1998 - - - as soon as they become reasonably stable. - - It is stressed here that Internet-Drafts are working documents and - have no official standards status whatsoever. They may, eventually, - turn into a standards-track document or they may sink from sight. - Internet-Drafts are submitted to: internet-drafts@ietf.org - - The format of an Internet-Draft must be the same as for an RFC [2]. - Further, an I-D must contain: - - - Beginning, standard, boilerplate text which is provided by the - Secretariat on their web site and in the ftp directory; - - The I-D filename; and - - The expiration date for the I-D. - - Complete specification of requirements for an Internet-Draft are - found in the file "1id-guidelines.txt" in the Internet-Drafts - directory at an Internet Repository site. The organization of the - Internet-Drafts directory is found in the file "1id-organization" in - the Internet-Drafts directory at an Internet Repository site. This - file also contains the rules for naming Internet-Drafts. (See [1] - for more information about Internet-Drafts.) - -7.3. Request For Comments (RFC) - - The work of an IETF working group often results in publication of one - or more documents, as part of the Request For Comments (RFCs) [1] - series. This series is the archival publication record for the - Internet community. A document can be written by an individual in a - working group, by a group as a whole with a designated Editor, or by - others not involved with the IETF. - - NOTE: The RFC series is a publication mechanism only and publication - does not determine the IETF status of a document. Status is - determined through separate, explicit status labels assigned by the - IESG on behalf of the IETF. In other words, the reader is reminded - that all Internet Standards are published as RFCs, but NOT all RFCs - specify standards [4]. - -7.4. Working Group Last-Call - - When a WG decides that a document is ready for publication it may be - submitted to the IESG for consideration. In most cases the - determination that a WG feels that a document is ready for - publication is done by the WG Chair issuing a working group Last- - Call. The decision to issue a working group Last-Call is at the - discretion of the WG Chair working with the Area Director. A working - group Last-Call serves the same purpose within a working group that - - - -Bradner Best Current Practice [Page 20] - -RFC 2418 Working Group Guidelines September 1998 - - - an IESG Last-Call does in the broader IETF community (see [1]). - -7.5. Submission of documents - - Once that a WG has determined at least rough consensus exists within - the WG for the advancement of a document the following must be done: - - - The version of the relevant document exactly as agreed to by the WG - MUST be in the Internet-Drafts directory. - - - The relevant document MUST be formatted according to section 7.3. - - - The WG Chair MUST send email to the relevant Area Director. A copy - of the request MUST be also sent to the IESG Secretariat. The mail - MUST contain the reference to the document's ID filename, and the - action requested. The copy of the message to the IESG Secretariat - is to ensure that the request gets recorded by the Secretariat so - that they can monitor the progress of the document through the - process. - - Unless returned by the IESG to the WG for further development, - progressing of the document is then the responsibility of the IESG. - After IESG approval, responsibility for final disposition is the - joint responsibility of the RFC Editor, the WG Chair and the Document - Editor. - -8. Review of documents - - The IESG reviews all documents submitted for publication as RFCs. - Usually minimal IESG review is necessary in the case of a submission - from a WG intended as an Informational or Experimental RFC. More - extensive review is undertaken in the case of standards-track - documents. - - Prior to the IESG beginning their deliberations on standards-track - documents, IETF Secretariat will issue a "Last-Call" to the IETF - mailing list (see [1]). This Last Call will announce the intention of - the IESG to consider the document, and it will solicit final comments - from the IETF within a period of two weeks. It is important to note - that a Last-Call is intended as a brief, final check with the - Internet community, to make sure that no important concerns have been - missed or misunderstood. The Last-Call should not serve as a more - general, in-depth review. - - The IESG review takes into account responses to the Last-Call and - will lead to one of these possible conclusions: - - - - - -Bradner Best Current Practice [Page 21] - -RFC 2418 Working Group Guidelines September 1998 - - - 1. The document is accepted as is for the status requested. - This fact will be announced by the IETF Secretariat to the IETF - mailing list and to the RFC Editor. - - 2. The document is accepted as-is but not for the status requested. - This fact will be announced by the IETF Secretariat to the IETF - mailing list and to the RFC Editor (see [1] for more details). - - 3. Changes regarding content are suggested to the author(s)/WG. - Suggestions from the IESG must be clear and direct, so as to - facilitate working group and author correction of the - specification. If the author(s)/WG can explain to the - satisfaction of the IESG why the changes are not necessary, the - document will be accepted for publication as under point 1, above. - If the changes are made the revised document may be resubmitted - for IESG review. - - 4. Changes are suggested by the IESG and a change in status is - recommended. - The process described above for 3 and 2 are followed in that - order. - - 5. The document is rejected. - Any document rejection will be accompanied by specific and - thorough arguments from the IESG. Although the IETF and working - group process is structured such that this alternative is not - likely to arise for documents coming from a working group, the - IESG has the right and responsibility to reject documents that the - IESG feels are fatally flawed in some way. - - If any individual or group of individuals feels that the review - treatment has been unfair, there is the opportunity to make a - procedural complaint. The mechanism for this type of complaints is - described in [1]. - -9. Security Considerations - - Documents describing IETF processes, such as this one, do not have an - impact on the security of the network infrastructure or of Internet - applications. - - It should be noted that all IETF working groups are required to - examine and understand the security implications of any technology - they develop. This analysis must be included in any resulting RFCs - in a Security Considerations section. Note that merely noting a - significant security hole is no longer sufficient. IETF developed - technologies should not add insecurity to the environment in which - they are run. - - - -Bradner Best Current Practice [Page 22] - -RFC 2418 Working Group Guidelines September 1998 - - -10. Acknowledgments - - This revision of this document relies heavily on the previous version - (RFC 1603) which was edited by Erik Huizer and Dave Crocker. It has - been reviewed by the Poisson Working Group. - -11. References - - [1] Bradner, S., Editor, "The Internet Standards Process -- Revision - 3", BCP 9, RFC 2026, October 1996. - - [2] Hovey, R., and S. Bradner, "The Organizations involved in the - IETF Standards Process", BCP 11, RFC 2028, October 1996. - - [3] Gavin, J., "IAB and IESG Selection, Confirmation, and Recall - Process: Operation of the Nominating and Recall Committees", BCP - 10, RFC 2282, February 1998. - - [4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards", - RFC 1796, April 1995. - - [5] Postel, J., and J. Reynolds, "Instructions to RFC Authors", RFC - 2223, October 1997. - - [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Level", BCP 14, RFC 2119, March 1997. - - -12. Editor's Address - - Scott Bradner - Harvard University - 1350 Mass Ave. - Cambridge MA - 02138 - USA - - Phone +1 617 495 3864 - EMail: sob@harvard.edu - - - - - - - - - - - - -Bradner Best Current Practice [Page 23] - -RFC 2418 Working Group Guidelines September 1998 - - - Appendix: Sample Working Group Charter - - Working Group Name: - IP Telephony (iptel) - - IETF Area: - Transport Area - - Chair(s): - Jonathan Rosenberg <jdrosen@bell-labs.com> - - Transport Area Director(s): - Scott Bradner <sob@harvard.edu> - Allyn Romanow <allyn@mci.net> - - Responsible Area Director: - Allyn Romanow <allyn@mci.net> - - Mailing Lists: - General Discussion:iptel@lists.research.bell-labs.com - To Subscribe: iptel-request@lists.research.bell-labs.com - Archive: http://www.bell-labs.com/mailing-lists/siptel - - Description of Working Group: - - Before Internet telephony can become a widely deployed service, a - number of protocols must be deployed. These include signaling and - capabilities exchange, but also include a number of "peripheral" - protocols for providing related services. - - The primary purpose of this working group is to develop two such - supportive protocols and a frameword document. They are: - - 1. Call Processing Syntax. When a call is setup between two - endpoints, the signaling will generally pass through several servers - (such as an H.323 gatekeeper) which are responsible for forwarding, - redirecting, or proxying the signaling messages. For example, a user - may make a call to j.doe@bigcompany.com. The signaling message to - initiate the call will arrive at some server at bigcompany. This - server can inform the caller that the callee is busy, forward the - call initiation request to another server closer to the user, or drop - the call completely (among other possibilities). It is very desirable - to allow the callee to provide input to this process, guiding the - server in its decision on how to act. This can enable a wide variety - of advanced personal mobility and call agent services. - - - - - - -Bradner Best Current Practice [Page 24] - -RFC 2418 Working Group Guidelines September 1998 - - - Such preferences can be expressed in a call processing syntax, which - can be authored by the user (or generated automatically by some - tool), and then uploaded to the server. The group will develop this - syntax, and specify means of securely transporting and extending it. - The result will be a single standards track RFC. - - 2. In addition, the group will write a service model document, which - describes the services that are enabled by the call processing - syntax, and discusses how the syntax can be used. This document will - result in a single RFC. - - 3. Gateway Attribute Distribution Protocol. When making a call - between an IP host and a PSTN user, a telephony gateway must be used. - The selection of such gateways can be based on many criteria, - including client expressed preferences, service provider preferences, - and availability of gateways, in addition to destination telephone - number. Since gateways outside of the hosts' administrative domain - might be used, a protocol is required to allow gateways in remote - domains to distribute their attributes (such as PSTN connectivity, - supported codecs, etc.) to entities in other domains which must make - a selection of a gateway. The protocol must allow for scalable, - bandwidth efficient, and very secure transmission of these - attributes. The group will investigate and design a protocol for this - purpose, generate an Internet Draft, and advance it to RFC as - appropriate. - - Goals and Milestones: - - May 98 Issue first Internet-Draft on service framework - Jul 98 Submit framework ID to IESG for publication as an RFC. - Aug 98 Issue first Internet-Draft on Call Processing Syntax - Oct 98 Submit Call processing syntax to IESG for consideration - as a Proposed Standard. - Dec 98 Achieve consensus on basics of gateway attribute - distribution protocol - Jan 99 Submit Gateway Attribute Distribution protocol to IESG - for consideration as a RFC (info, exp, stds track TB - - - - - - - - - - - - - - -Bradner Best Current Practice [Page 25] - -RFC 2418 Working Group Guidelines September 1998 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Bradner Best Current Practice [Page 26] - diff --git a/contrib/bind9/doc/rfc/rfc2535.txt b/contrib/bind9/doc/rfc/rfc2535.txt deleted file mode 100644 index fe0b3d07f4ae..000000000000 --- a/contrib/bind9/doc/rfc/rfc2535.txt +++ /dev/null @@ -1,2635 +0,0 @@ - - - - - - -Network Working Group D. Eastlake -Request for Comments: 2535 IBM -Obsoletes: 2065 March 1999 -Updates: 2181, 1035, 1034 -Category: Standards Track - - Domain Name System Security Extensions - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - -Abstract - - Extensions to the Domain Name System (DNS) are described that provide - data integrity and authentication to security aware resolvers and - applications through the use of cryptographic digital signatures. - These digital signatures are included in secured zones as resource - records. Security can also be provided through non-security aware - DNS servers in some cases. - - The extensions provide for the storage of authenticated public keys - in the DNS. This storage of keys can support general public key - distribution services as well as DNS security. The stored keys - enable security aware resolvers to learn the authenticating key of - zones in addition to those for which they are initially configured. - Keys associated with DNS names can be retrieved to support other - protocols. Provision is made for a variety of key types and - algorithms. - - In addition, the security extensions provide for the optional - authentication of DNS protocol transactions and requests. - - This document incorporates feedback on RFC 2065 from early - implementers and potential users. - - - - - - - - -Eastlake Standards Track [Page 1] - -RFC 2535 DNS Security Extensions March 1999 - - -Acknowledgments - - The significant contributions and suggestions of the following - persons (in alphabetic order) to DNS security are gratefully - acknowledged: - - James M. Galvin - John Gilmore - Olafur Gudmundsson - Charlie Kaufman - Edward Lewis - Thomas Narten - Radia J. Perlman - Jeffrey I. Schiller - Steven (Xunhua) Wang - Brian Wellington - -Table of Contents - - Abstract...................................................1 - Acknowledgments............................................2 - 1. Overview of Contents....................................4 - 2. Overview of the DNS Extensions..........................5 - 2.1 Services Not Provided..................................5 - 2.2 Key Distribution.......................................5 - 2.3 Data Origin Authentication and Integrity...............6 - 2.3.1 The SIG Resource Record..............................7 - 2.3.2 Authenticating Name and Type Non-existence...........7 - 2.3.3 Special Considerations With Time-to-Live.............7 - 2.3.4 Special Considerations at Delegation Points..........8 - 2.3.5 Special Considerations with CNAME....................8 - 2.3.6 Signers Other Than The Zone..........................9 - 2.4 DNS Transaction and Request Authentication.............9 - 3. The KEY Resource Record................................10 - 3.1 KEY RDATA format......................................10 - 3.1.1 Object Types, DNS Names, and Keys...................11 - 3.1.2 The KEY RR Flag Field...............................11 - 3.1.3 The Protocol Octet..................................13 - 3.2 The KEY Algorithm Number Specification................14 - 3.3 Interaction of Flags, Algorithm, and Protocol Bytes...15 - 3.4 Determination of Zone Secure/Unsecured Status.........15 - 3.5 KEY RRs in the Construction of Responses..............17 - 4. The SIG Resource Record................................17 - 4.1 SIG RDATA Format......................................17 - 4.1.1 Type Covered Field..................................18 - 4.1.2 Algorithm Number Field..............................18 - 4.1.3 Labels Field........................................18 - 4.1.4 Original TTL Field..................................19 - - - -Eastlake Standards Track [Page 2] - -RFC 2535 DNS Security Extensions March 1999 - - - 4.1.5 Signature Expiration and Inception Fields...........19 - 4.1.6 Key Tag Field.......................................20 - 4.1.7 Signer's Name Field.................................20 - 4.1.8 Signature Field.....................................20 - 4.1.8.1 Calculating Transaction and Request SIGs..........21 - 4.2 SIG RRs in the Construction of Responses..............21 - 4.3 Processing Responses and SIG RRs......................22 - 4.4 Signature Lifetime, Expiration, TTLs, and Validity....23 - 5. Non-existent Names and Types...........................24 - 5.1 The NXT Resource Record...............................24 - 5.2 NXT RDATA Format......................................25 - 5.3 Additional Complexity Due to Wildcards................26 - 5.4 Example...............................................26 - 5.5 Special Considerations at Delegation Points...........27 - 5.6 Zone Transfers........................................27 - 5.6.1 Full Zone Transfers.................................28 - 5.6.2 Incremental Zone Transfers..........................28 - 6. How to Resolve Securely and the AD and CD Bits.........29 - 6.1 The AD and CD Header Bits.............................29 - 6.2 Staticly Configured Keys..............................31 - 6.3 Chaining Through The DNS..............................31 - 6.3.1 Chaining Through KEYs...............................31 - 6.3.2 Conflicting Data....................................33 - 6.4 Secure Time...........................................33 - 7. ASCII Representation of Security RRs...................34 - 7.1 Presentation of KEY RRs...............................34 - 7.2 Presentation of SIG RRs...............................35 - 7.3 Presentation of NXT RRs...............................36 - 8. Canonical Form and Order of Resource Records...........36 - 8.1 Canonical RR Form.....................................36 - 8.2 Canonical DNS Name Order..............................37 - 8.3 Canonical RR Ordering Within An RRset.................37 - 8.4 Canonical Ordering of RR Types........................37 - 9. Conformance............................................37 - 9.1 Server Conformance....................................37 - 9.2 Resolver Conformance..................................38 - 10. Security Considerations...............................38 - 11. IANA Considerations...................................39 - References................................................39 - Author's Address..........................................41 - Appendix A: Base 64 Encoding..............................42 - Appendix B: Changes from RFC 2065.........................44 - Appendix C: Key Tag Calculation...........................46 - Full Copyright Statement..................................47 - - - - - - - -Eastlake Standards Track [Page 3] - -RFC 2535 DNS Security Extensions March 1999 - - -1. Overview of Contents - - This document standardizes extensions of the Domain Name System (DNS) - protocol to support DNS security and public key distribution. It - assumes that the reader is familiar with the Domain Name System, - particularly as described in RFCs 1033, 1034, 1035 and later RFCs. An - earlier version of these extensions appears in RFC 2065. This - replacement for that RFC incorporates early implementation experience - and requests from potential users. - - Section 2 provides an overview of the extensions and the key - distribution, data origin authentication, and transaction and request - security they provide. - - Section 3 discusses the KEY resource record, its structure, and use - in DNS responses. These resource records represent the public keys - of entities named in the DNS and are used for key distribution. - - Section 4 discusses the SIG digital signature resource record, its - structure, and use in DNS responses. These resource records are used - to authenticate other resource records in the DNS and optionally to - authenticate DNS transactions and requests. - - Section 5 discusses the NXT resource record (RR) and its use in DNS - responses including full and incremental zone transfers. The NXT RR - permits authenticated denial of the existence of a name or of an RR - type for an existing name. - - Section 6 discusses how a resolver can be configured with a starting - key or keys and proceed to securely resolve DNS requests. - Interactions between resolvers and servers are discussed for various - combinations of security aware and security non-aware. Two - additional DNS header bits are defined for signaling between - resolvers and servers. - - Section 7 describes the ASCII representation of the security resource - records for use in master files and elsewhere. - - Section 8 defines the canonical form and order of RRs for DNS - security purposes. - - Section 9 defines levels of conformance for resolvers and servers. - - Section 10 provides a few paragraphs on overall security - considerations. - - Section 11 specified IANA considerations for allocation of additional - values of paramters defined in this document. - - - -Eastlake Standards Track [Page 4] - -RFC 2535 DNS Security Extensions March 1999 - - - Appendix A gives details of base 64 encoding which is used in the - file representation of some RRs defined in this document. - - Appendix B summarizes changes between this memo and RFC 2065. - - Appendix C specified how to calculate the simple checksum used as a - key tag in most SIG RRs. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - -2. Overview of the DNS Extensions - - The Domain Name System (DNS) protocol security extensions provide - three distinct services: key distribution as described in Section 2.2 - below, data origin authentication as described in Section 2.3 below, - and transaction and request authentication, described in Section 2.4 - below. - - Special considerations related to "time to live", CNAMEs, and - delegation points are also discussed in Section 2.3. - -2.1 Services Not Provided - - It is part of the design philosophy of the DNS that the data in it is - public and that the DNS gives the same answers to all inquirers. - Following this philosophy, no attempt has been made to include any - sort of access control lists or other means to differentiate - inquirers. - - No effort has been made to provide for any confidentiality for - queries or responses. (This service may be available via IPSEC [RFC - 2401], TLS, or other security protocols.) - - Protection is not provided against denial of service. - -2.2 Key Distribution - - A resource record format is defined to associate keys with DNS names. - This permits the DNS to be used as a public key distribution - mechanism in support of DNS security itself and other protocols. - - The syntax of a KEY resource record (RR) is described in Section 3. - It includes an algorithm identifier, the actual public key - parameter(s), and a variety of flags including those indicating the - type of entity the key is associated with and/or asserting that there - is no key associated with that entity. - - - -Eastlake Standards Track [Page 5] - -RFC 2535 DNS Security Extensions March 1999 - - - Under conditions described in Section 3.5, security aware DNS servers - will automatically attempt to return KEY resources as additional - information, along with those resource records actually requested, to - minimize the number of queries needed. - -2.3 Data Origin Authentication and Integrity - - Authentication is provided by associating with resource record sets - (RRsets [RFC 2181]) in the DNS cryptographically generated digital - signatures. Commonly, there will be a single private key that - authenticates an entire zone but there might be multiple keys for - different algorithms, signers, etc. If a security aware resolver - reliably learns a public key of the zone, it can authenticate, for - signed data read from that zone, that it is properly authorized. The - most secure implementation is for the zone private key(s) to be kept - off-line and used to re-sign all of the records in the zone - periodically. However, there are cases, for example dynamic update - [RFCs 2136, 2137], where DNS private keys need to be on-line [RFC - 2541]. - - The data origin authentication key(s) are associated with the zone - and not with the servers that store copies of the data. That means - compromise of a secondary server or, if the key(s) are kept off line, - even the primary server for a zone, will not necessarily affect the - degree of assurance that a resolver has that it can determine whether - data is genuine. - - A resolver could learn a public key of a zone either by reading it - from the DNS or by having it staticly configured. To reliably learn - a public key by reading it from the DNS, the key itself must be - signed with a key the resolver trusts. The resolver must be - configured with at least a public key which authenticates one zone as - a starting point. From there, it can securely read public keys of - other zones, if the intervening zones in the DNS tree are secure and - their signed keys accessible. - - Adding data origin authentication and integrity requires no change to - the "on-the-wire" DNS protocol beyond the addition of the signature - resource type and the key resource type needed for key distribution. - (Data non-existence authentication also requires the NXT RR as - described in 2.3.2.) This service can be supported by existing - resolver and caching server implementations so long as they can - support the additional resource types (see Section 9). The one - exception is that CNAME referrals in a secure zone can not be - authenticated if they are from non-security aware servers (see - Section 2.3.5). - - - - - -Eastlake Standards Track [Page 6] - -RFC 2535 DNS Security Extensions March 1999 - - - If signatures are separately retrieved and verified when retrieving - the information they authenticate, there will be more trips to the - server and performance will suffer. Security aware servers mitigate - that degradation by attempting to send the signature(s) needed (see - Section 4.2). - -2.3.1 The SIG Resource Record - - The syntax of a SIG resource record (signature) is described in - Section 4. It cryptographicly binds the RRset being signed to the - signer and a validity interval. - - Every name in a secured zone will have associated with it at least - one SIG resource record for each resource type under that name except - for glue address RRs and delegation point NS RRs. A security aware - server will attempt to return, with RRs retrieved, the corresponding - SIGs. If a server is not security aware, the resolver must retrieve - all the SIG records for a name and select the one or ones that sign - the resource record set(s) that resolver is interested in. - -2.3.2 Authenticating Name and Type Non-existence - - The above security mechanism only provides a way to sign existing - RRsets in a zone. "Data origin" authentication is not obviously - provided for the non-existence of a domain name in a zone or the - non-existence of a type for an existing name. This gap is filled by - the NXT RR which authenticatably asserts a range of non-existent - names in a zone and the non-existence of types for the existing name - just before that range. - - Section 5 below covers the NXT RR. - -2.3.3 Special Considerations With Time-to-Live - - A digital signature will fail to verify if any change has occurred to - the data between the time it was originally signed and the time the - signature is verified. This conflicts with our desire to have the - time-to-live (TTL) field of resource records tick down while they are - cached. - - This could be avoided by leaving the time-to-live out of the digital - signature, but that would allow unscrupulous servers to set - arbitrarily long TTL values undetected. Instead, we include the - "original" TTL in the signature and communicate that data along with - the current TTL. Unscrupulous servers under this scheme can - manipulate the TTL but a security aware resolver will bound the TTL - value it uses at the original signed value. Separately, signatures - include a signature inception time and a signature expiration time. A - - - -Eastlake Standards Track [Page 7] - -RFC 2535 DNS Security Extensions March 1999 - - - resolver that knows the absolute time can determine securely whether - a signature is in effect. It is not possible to rely solely on the - signature expiration as a substitute for the TTL, however, since the - TTL is primarily a database consistency mechanism and non-security - aware servers that depend on TTL must still be supported. - -2.3.4 Special Considerations at Delegation Points - - DNS security would like to view each zone as a unit of data - completely under the control of the zone owner with each entry - (RRset) signed by a special private key held by the zone manager. - But the DNS protocol views the leaf nodes in a zone, which are also - the apex nodes of a subzone (i.e., delegation points), as "really" - belonging to the subzone. These nodes occur in two master files and - might have RRs signed by both the upper and lower zone's keys. A - retrieval could get a mixture of these RRs and SIGs, especially since - one server could be serving both the zone above and below a - delegation point. [RFC 2181] - - There MUST be a zone KEY RR, signed by its superzone, for every - subzone if the superzone is secure. This will normally appear in the - subzone and may also be included in the superzone. But, in the case - of an unsecured subzone which can not or will not be modified to add - any security RRs, a KEY declaring the subzone to be unsecured MUST - appear with the superzone signature in the superzone, if the - superzone is secure. For all but one other RR type the data from the - subzone is more authoritative so only the subzone KEY RR should be - signed in the superzone if it appears there. The NS and any glue - address RRs SHOULD only be signed in the subzone. The SOA and any - other RRs that have the zone name as owner should appear only in the - subzone and thus are signed only there. The NXT RR type is the - exceptional case that will always appear differently and - authoritatively in both the superzone and subzone, if both are - secure, as described in Section 5. - -2.3.5 Special Considerations with CNAME - - There is a problem when security related RRs with the same owner name - as a CNAME RR are retrieved from a non-security-aware server. In - particular, an initial retrieval for the CNAME or any other type may - not retrieve any associated SIG, KEY, or NXT RR. For retrieved types - other than CNAME, it will retrieve that type at the target name of - the CNAME (or chain of CNAMEs) and will also return the CNAME. In - particular, a specific retrieval for type SIG will not get the SIG, - if any, at the original CNAME domain name but rather a SIG at the - target name. - - - - - -Eastlake Standards Track [Page 8] - -RFC 2535 DNS Security Extensions March 1999 - - - Security aware servers must be used to securely CNAME in DNS. - Security aware servers MUST (1) allow KEY, SIG, and NXT RRs along - with CNAME RRs, (2) suppress CNAME processing on retrieval of these - types as well as on retrieval of the type CNAME, and (3) - automatically return SIG RRs authenticating the CNAME or CNAMEs - encountered in resolving a query. This is a change from the previous - DNS standard [RFCs 1034/1035] which prohibited any other RR type at a - node where a CNAME RR was present. - -2.3.6 Signers Other Than The Zone - - There are cases where the signer in a SIG resource record is other - than one of the private key(s) used to authenticate a zone. - - One is for support of dynamic update [RFC 2136] (or future requests - which require secure authentication) where an entity is permitted to - authenticate/update its records [RFC 2137] and the zone is operating - in a mode where the zone key is not on line. The public key of the - entity must be present in the DNS and be signed by a zone level key - but the other RR(s) may be signed with the entity's key. - - A second case is support of transaction and request authentication as - described in Section 2.4. - - In additions, signatures can be included on resource records within - the DNS for use by applications other than DNS. DNS related - signatures authenticate that data originated with the authority of a - zone owner or that a request or transaction originated with the - relevant entity. Other signatures can provide other types of - assurances. - -2.4 DNS Transaction and Request Authentication - - The data origin authentication service described above protects - retrieved resource records and the non-existence of resource records - but provides no protection for DNS requests or for message headers. - - If header bits are falsely set by a bad server, there is little that - can be done. However, it is possible to add transaction - authentication. Such authentication means that a resolver can be - sure it is at least getting messages from the server it thinks it - queried and that the response is from the query it sent (i.e., that - these messages have not been diddled in transit). This is - accomplished by optionally adding a special SIG resource record at - the end of the reply which digitally signs the concatenation of the - server's response and the resolver's query. - - - - - -Eastlake Standards Track [Page 9] - -RFC 2535 DNS Security Extensions March 1999 - - - Requests can also be authenticated by including a special SIG RR at - the end of the request. Authenticating requests serves no function - in older DNS servers and requests with a non-empty additional - information section produce error returns or may even be ignored by - many of them. However, this syntax for signing requests is defined as - a way of authenticating secure dynamic update requests [RFC 2137] or - future requests requiring authentication. - - The private keys used in transaction security belong to the entity - composing the reply, not to the zone involved. Request - authentication may also involve the private key of the host or other - entity composing the request or other private keys depending on the - request authority it is sought to establish. The corresponding public - key(s) are normally stored in and retrieved from the DNS for - verification. - - Because requests and replies are highly variable, message - authentication SIGs can not be pre-calculated. Thus it will be - necessary to keep the private key on-line, for example in software or - in a directly connected piece of hardware. - -3. The KEY Resource Record - - The KEY resource record (RR) is used to store a public key that is - associated with a Domain Name System (DNS) name. This can be the - public key of a zone, a user, or a host or other end entity. Security - aware DNS implementations MUST be designed to handle at least two - simultaneously valid keys of the same type associated with the same - name. - - The type number for the KEY RR is 25. - - A KEY RR is, like any other RR, authenticated by a SIG RR. KEY RRs - must be signed by a zone level key. - -3.1 KEY RDATA format - - The RDATA for a KEY RR consists of flags, a protocol octet, the - algorithm number octet, and the public key itself. The format is as - follows: - - - - - - - - - - - -Eastlake Standards Track [Page 10] - -RFC 2535 DNS Security Extensions March 1999 - - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | flags | protocol | algorithm | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | / - / public key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - - The KEY RR is not intended for storage of certificates and a separate - certificate RR has been developed for that purpose, defined in [RFC - 2538]. - - The meaning of the KEY RR owner name, flags, and protocol octet are - described in Sections 3.1.1 through 3.1.5 below. The flags and - algorithm must be examined before any data following the algorithm - octet as they control the existence and format of any following data. - The algorithm and public key fields are described in Section 3.2. - The format of the public key is algorithm dependent. - - KEY RRs do not specify their validity period but their authenticating - SIG RR(s) do as described in Section 4 below. - -3.1.1 Object Types, DNS Names, and Keys - - The public key in a KEY RR is for the object named in the owner name. - - A DNS name may refer to three different categories of things. For - example, foo.host.example could be (1) a zone, (2) a host or other - end entity , or (3) the mapping into a DNS name of the user or - account foo@host.example. Thus, there are flag bits, as described - below, in the KEY RR to indicate with which of these roles the owner - name and public key are associated. Note that an appropriate zone - KEY RR MUST occur at the apex node of a secure zone and zone KEY RRs - occur only at delegation points. - -3.1.2 The KEY RR Flag Field - - In the "flags" field: - - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - | A/C | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z | SIG | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - Bit 0 and 1 are the key "type" bits whose values have the following - meanings: - - - -Eastlake Standards Track [Page 11] - -RFC 2535 DNS Security Extensions March 1999 - - - 10: Use of the key is prohibited for authentication. - 01: Use of the key is prohibited for confidentiality. - 00: Use of the key for authentication and/or confidentiality - is permitted. Note that DNS security makes use of keys - for authentication only. Confidentiality use flagging is - provided for use of keys in other protocols. - Implementations not intended to support key distribution - for confidentiality MAY require that the confidentiality - use prohibited bit be on for keys they serve. - 11: If both bits are one, the "no key" value, there is no key - information and the RR stops after the algorithm octet. - By the use of this "no key" value, a signed KEY RR can - authenticatably assert that, for example, a zone is not - secured. See section 3.4 below. - - Bits 2 is reserved and must be zero. - - Bits 3 is reserved as a flag extension bit. If it is a one, a second - 16 bit flag field is added after the algorithm octet and - before the key data. This bit MUST NOT be set unless one or - more such additional bits have been defined and are non-zero. - - Bits 4-5 are reserved and must be zero. - - Bits 6 and 7 form a field that encodes the name type. Field values - have the following meanings: - - 00: indicates that this is a key associated with a "user" or - "account" at an end entity, usually a host. The coding - of the owner name is that used for the responsible - individual mailbox in the SOA and RP RRs: The owner name - is the user name as the name of a node under the entity - name. For example, "j_random_user" on - host.subdomain.example could have a public key associated - through a KEY RR with name - j_random_user.host.subdomain.example. It could be used - in a security protocol where authentication of a user was - desired. This key might be useful in IP or other - security for a user level service such a telnet, ftp, - rlogin, etc. - 01: indicates that this is a zone key for the zone whose name - is the KEY RR owner name. This is the public key used - for the primary DNS security feature of data origin - authentication. Zone KEY RRs occur only at delegation - points. - 10: indicates that this is a key associated with the non-zone - "entity" whose name is the RR owner name. This will - commonly be a host but could, in some parts of the DNS - - - -Eastlake Standards Track [Page 12] - -RFC 2535 DNS Security Extensions March 1999 - - - tree, be some other type of entity such as a telephone - number [RFC 1530] or numeric IP address. This is the - public key used in connection with DNS request and - transaction authentication services. It could also be - used in an IP-security protocol where authentication at - the host, rather than user, level was desired, such as - routing, NTP, etc. - 11: reserved. - - Bits 8-11 are reserved and must be zero. - - Bits 12-15 are the "signatory" field. If non-zero, they indicate - that the key can validly sign things as specified in DNS - dynamic update [RFC 2137]. Note that zone keys (see bits - 6 and 7 above) always have authority to sign any RRs in - the zone regardless of the value of the signatory field. - -3.1.3 The Protocol Octet - - It is anticipated that keys stored in DNS will be used in conjunction - with a variety of Internet protocols. It is intended that the - protocol octet and possibly some of the currently unused (must be - zero) bits in the KEY RR flags as specified in the future will be - used to indicate a key's validity for different protocols. - - The following values of the Protocol Octet are reserved as indicated: - - VALUE Protocol - - 0 -reserved - 1 TLS - 2 email - 3 dnssec - 4 IPSEC - 5-254 - available for assignment by IANA - 255 All - - In more detail: - 1 is reserved for use in connection with TLS. - 2 is reserved for use in connection with email. - 3 is used for DNS security. The protocol field SHOULD be set to - this value for zone keys and other keys used in DNS security. - Implementations that can determine that a key is a DNS - security key by the fact that flags label it a zone key or the - signatory flag field is non-zero are NOT REQUIRED to check the - protocol field. - 4 is reserved to refer to the Oakley/IPSEC [RFC 2401] protocol - and indicates that this key is valid for use in conjunction - - - -Eastlake Standards Track [Page 13] - -RFC 2535 DNS Security Extensions March 1999 - - - with that security standard. This key could be used in - connection with secured communication on behalf of an end - entity or user whose name is the owner name of the KEY RR if - the entity or user flag bits are set. The presence of a KEY - resource with this protocol value is an assertion that the - host speaks Oakley/IPSEC. - 255 indicates that the key can be used in connection with any - protocol for which KEY RR protocol octet values have been - defined. The use of this value is discouraged and the use of - different keys for different protocols is encouraged. - -3.2 The KEY Algorithm Number Specification - - This octet is the key algorithm parallel to the same field for the - SIG resource as described in Section 4.1. The following values are - assigned: - - VALUE Algorithm - - 0 - reserved, see Section 11 - 1 RSA/MD5 [RFC 2537] - recommended - 2 Diffie-Hellman [RFC 2539] - optional, key only - 3 DSA [RFC 2536] - MANDATORY - 4 reserved for elliptic curve crypto - 5-251 - available, see Section 11 - 252 reserved for indirect keys - 253 private - domain name (see below) - 254 private - OID (see below) - 255 - reserved, see Section 11 - - Algorithm specific formats and procedures are given in separate - documents. The mandatory to implement for interoperability algorithm - is number 3, DSA. It is recommended that the RSA/MD5 algorithm, - number 1, also be implemented. Algorithm 2 is used to indicate - Diffie-Hellman keys and algorithm 4 is reserved for elliptic curve. - - Algorithm number 252 indicates an indirect key format where the - actual key material is elsewhere. This format is to be defined in a - separate document. - - Algorithm numbers 253 and 254 are reserved for private use and will - never be assigned a specific algorithm. For number 253, the public - key area and the signature begin with a wire encoded domain name. - Only local domain name compression is permitted. The domain name - indicates the private algorithm to use and the remainder of the - public key area is whatever is required by that algorithm. For - number 254, the public key area for the KEY RR and the signature - begin with an unsigned length byte followed by a BER encoded Object - - - -Eastlake Standards Track [Page 14] - -RFC 2535 DNS Security Extensions March 1999 - - - Identifier (ISO OID) of that length. The OID indicates the private - algorithm in use and the remainder of the area is whatever is - required by that algorithm. Entities should only use domain names - and OIDs they control to designate their private algorithms. - - Values 0 and 255 are reserved but the value 0 is used in the - algorithm field when that field is not used. An example is in a KEY - RR with the top two flag bits on, the "no-key" value, where no key is - present. - -3.3 Interaction of Flags, Algorithm, and Protocol Bytes - - Various combinations of the no-key type flags, algorithm byte, - protocol byte, and any future assigned protocol indicating flags are - possible. The meaning of these combinations is indicated below: - - NK = no key type (flags bits 0 and 1 on) - AL = algorithm byte - PR = protocols indicated by protocol byte or future assigned flags - - x represents any valid non-zero value(s). - - AL PR NK Meaning - 0 0 0 Illegal, claims key but has bad algorithm field. - 0 0 1 Specifies total lack of security for owner zone. - 0 x 0 Illegal, claims key but has bad algorithm field. - 0 x 1 Specified protocols unsecured, others may be secure. - x 0 0 Gives key but no protocols to use it. - x 0 1 Denies key for specific algorithm. - x x 0 Specifies key for protocols. - x x 1 Algorithm not understood for protocol. - -3.4 Determination of Zone Secure/Unsecured Status - - A zone KEY RR with the "no-key" type field value (both key type flag - bits 0 and 1 on) indicates that the zone named is unsecured while a - zone KEY RR with a key present indicates that the zone named is - secure. The secured versus unsecured status of a zone may vary with - different cryptographic algorithms. Even for the same algorithm, - conflicting zone KEY RRs may be present. - - Zone KEY RRs, like all RRs, are only trusted if they are - authenticated by a SIG RR whose signer field is a signer for which - the resolver has a public key they trust and where resolver policy - permits that signer to sign for the KEY owner name. Untrusted zone - KEY RRs MUST be ignored in determining the security status of the - zone. However, there can be multiple sets of trusted zone KEY RRs - for a zone with different algorithms, signers, etc. - - - -Eastlake Standards Track [Page 15] - -RFC 2535 DNS Security Extensions March 1999 - - - For any particular algorithm, zones can be (1) secure, indicating - that any retrieved RR must be authenticated by a SIG RR or it will be - discarded as bogus, (2) unsecured, indicating that SIG RRs are not - expected or required for RRs retrieved from the zone, or (3) - experimentally secure, which indicates that SIG RRs might or might - not be present but must be checked if found. The status of a zone is - determined as follows: - - 1. If, for a zone and algorithm, every trusted zone KEY RR for the - zone says there is no key for that zone, it is unsecured for that - algorithm. - - 2. If, there is at least one trusted no-key zone KEY RR and one - trusted key specifying zone KEY RR, then that zone is only - experimentally secure for the algorithm. Both authenticated and - non-authenticated RRs for it should be accepted by the resolver. - - 3. If every trusted zone KEY RR that the zone and algorithm has is - key specifying, then it is secure for that algorithm and only - authenticated RRs from it will be accepted. - - Examples: - - (1) A resolver initially trusts only signatures by the superzone of - zone Z within the DNS hierarchy. Thus it will look only at the KEY - RRs that are signed by the superzone. If it finds only no-key KEY - RRs, it will assume the zone is not secure. If it finds only key - specifying KEY RRs, it will assume the zone is secure and reject any - unsigned responses. If it finds both, it will assume the zone is - experimentally secure - - (2) A resolver trusts the superzone of zone Z (to which it got - securely from its local zone) and a third party, cert-auth.example. - When considering data from zone Z, it may be signed by the superzone - of Z, by cert-auth.example, by both, or by neither. The following - table indicates whether zone Z will be considered secure, - experimentally secure, or unsecured, depending on the signed zone KEY - RRs for Z; - - c e r t - a u t h . e x a m p l e - - KEY RRs| None | NoKeys | Mixed | Keys | - S --+-----------+-----------+----------+----------+ - u None | illegal | unsecured | experim. | secure | - p --+-----------+-----------+----------+----------+ - e NoKeys | unsecured | unsecured | experim. | secure | - r --+-----------+-----------+----------+----------+ - Z Mixed | experim. | experim. | experim. | secure | - - - -Eastlake Standards Track [Page 16] - -RFC 2535 DNS Security Extensions March 1999 - - - o --+-----------+-----------+----------+----------+ - n Keys | secure | secure | secure | secure | - e +-----------+-----------+----------+----------+ - -3.5 KEY RRs in the Construction of Responses - - An explicit request for KEY RRs does not cause any special additional - information processing except, of course, for the corresponding SIG - RR from a security aware server (see Section 4.2). - - Security aware DNS servers include KEY RRs as additional information - in responses, where a KEY is available, in the following cases: - - (1) On the retrieval of SOA or NS RRs, the KEY RRset with the same - name (perhaps just a zone key) SHOULD be included as additional - information if space is available. If not all additional information - will fit, type A and AAAA glue RRs have higher priority than KEY - RR(s). - - (2) On retrieval of type A or AAAA RRs, the KEY RRset with the same - name (usually just a host RR and NOT the zone key (which usually - would have a different name)) SHOULD be included if space is - available. On inclusion of A or AAAA RRs as additional information, - the KEY RRset with the same name should also be included but with - lower priority than the A or AAAA RRs. - -4. The SIG Resource Record - - The SIG or "signature" resource record (RR) is the fundamental way - that data is authenticated in the secure Domain Name System (DNS). As - such it is the heart of the security provided. - - The SIG RR unforgably authenticates an RRset [RFC 2181] of a - particular type, class, and name and binds it to a time interval and - the signer's domain name. This is done using cryptographic - techniques and the signer's private key. The signer is frequently - the owner of the zone from which the RR originated. - - The type number for the SIG RR type is 24. - -4.1 SIG RDATA Format - - The RDATA portion of a SIG RR is as shown below. The integrity of - the RDATA information is protected by the signature field. - - - - - - - -Eastlake Standards Track [Page 17] - -RFC 2535 DNS Security Extensions March 1999 - - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | type covered | algorithm | labels | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | original TTL | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | signature expiration | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | signature inception | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | key tag | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name + - | / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ - / / - / signature / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -4.1.1 Type Covered Field - - The "type covered" is the type of the other RRs covered by this SIG. - -4.1.2 Algorithm Number Field - - This octet is as described in section 3.2. - -4.1.3 Labels Field - - The "labels" octet is an unsigned count of how many labels there are - in the original SIG RR owner name not counting the null label for - root and not counting any initial "*" for a wildcard. If a secured - retrieval is the result of wild card substitution, it is necessary - for the resolver to use the original form of the name in verifying - the digital signature. This field makes it easy to determine the - original form. - - If, on retrieval, the RR appears to have a longer name than indicated - by "labels", the resolver can tell it is the result of wildcard - substitution. If the RR owner name appears to be shorter than the - labels count, the SIG RR must be considered corrupt and ignored. The - maximum number of labels allowed in the current DNS is 127 but the - entire octet is reserved and would be required should DNS names ever - be expanded to 255 labels. The following table gives some examples. - The value of "labels" is at the top, the retrieved owner name on the - left, and the table entry is the name to use in signature - verification except that "bad" means the RR is corrupt. - - - -Eastlake Standards Track [Page 18] - -RFC 2535 DNS Security Extensions March 1999 - - - labels= | 0 | 1 | 2 | 3 | 4 | - --------+-----+------+--------+----------+----------+ - .| . | bad | bad | bad | bad | - d.| *. | d. | bad | bad | bad | - c.d.| *. | *.d. | c.d. | bad | bad | - b.c.d.| *. | *.d. | *.c.d. | b.c.d. | bad | - a.b.c.d.| *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. | - -4.1.4 Original TTL Field - - The "original TTL" field is included in the RDATA portion to avoid - (1) authentication problems that caching servers would otherwise - cause by decrementing the real TTL field and (2) security problems - that unscrupulous servers could otherwise cause by manipulating the - real TTL field. This original TTL is protected by the signature - while the current TTL field is not. - - NOTE: The "original TTL" must be restored into the covered RRs when - the signature is verified (see Section 8). This generaly implies - that all RRs for a particular type, name, and class, that is, all the - RRs in any particular RRset, must have the same TTL to start with. - -4.1.5 Signature Expiration and Inception Fields - - The SIG is valid from the "signature inception" time until the - "signature expiration" time. Both are unsigned numbers of seconds - since the start of 1 January 1970, GMT, ignoring leap seconds. (See - also Section 4.4.) Ring arithmetic is used as for DNS SOA serial - numbers [RFC 1982] which means that these times can never be more - than about 68 years in the past or the future. This means that these - times are ambiguous modulo ~136.09 years. However there is no - security flaw because keys are required to be changed to new random - keys by [RFC 2541] at least every five years. This means that the - probability that the same key is in use N*136.09 years later should - be the same as the probability that a random guess will work. - - A SIG RR may have an expiration time numerically less than the - inception time if the expiration time is near the 32 bit wrap around - point and/or the signature is long lived. - - (To prevent misordering of network requests to update a zone - dynamically, monotonically increasing "signature inception" times may - be necessary.) - - A secure zone must be considered changed for SOA serial number - purposes not only when its data is updated but also when new SIG RRs - are inserted (ie, the zone or any part of it is re-signed). - - - - -Eastlake Standards Track [Page 19] - -RFC 2535 DNS Security Extensions March 1999 - - -4.1.6 Key Tag Field - - The "key Tag" is a two octet quantity that is used to efficiently - select between multiple keys which may be applicable and thus check - that a public key about to be used for the computationally expensive - effort to check the signature is possibly valid. For algorithm 1 - (MD5/RSA) as defined in [RFC 2537], it is the next to the bottom two - octets of the public key modulus needed to decode the signature - field. That is to say, the most significant 16 of the least - significant 24 bits of the modulus in network (big endian) order. For - all other algorithms, including private algorithms, it is calculated - as a simple checksum of the KEY RR as described in Appendix C. - -4.1.7 Signer's Name Field - - The "signer's name" field is the domain name of the signer generating - the SIG RR. This is the owner name of the public KEY RR that can be - used to verify the signature. It is frequently the zone which - contained the RRset being authenticated. Which signers should be - authorized to sign what is a significant resolver policy question as - discussed in Section 6. The signer's name may be compressed with - standard DNS name compression when being transmitted over the - network. - -4.1.8 Signature Field - - The actual signature portion of the SIG RR binds the other RDATA - fields to the RRset of the "type covered" RRs with that owner name - and class. This covered RRset is thereby authenticated. To - accomplish this, a data sequence is constructed as follows: - - data = RDATA | RR(s)... - - where "|" is concatenation, - - RDATA is the wire format of all the RDATA fields in the SIG RR itself - (including the canonical form of the signer's name) before but not - including the signature, and - - RR(s) is the RRset of the RR(s) of the type covered with the same - owner name and class as the SIG RR in canonical form and order as - defined in Section 8. - - How this data sequence is processed into the signature is algorithm - dependent. These algorithm dependent formats and procedures are - described in separate documents (Section 3.2). - - - - - -Eastlake Standards Track [Page 20] - -RFC 2535 DNS Security Extensions March 1999 - - - SIGs SHOULD NOT be included in a zone for any "meta-type" such as - ANY, AXFR, etc. (but see section 5.6.2 with regard to IXFR). - -4.1.8.1 Calculating Transaction and Request SIGs - - A response message from a security aware server may optionally - contain a special SIG at the end of the additional information - section to authenticate the transaction. - - This SIG has a "type covered" field of zero, which is not a valid RR - type. It is calculated by using a "data" (see Section 4.1.8) of the - entire preceding DNS reply message, including DNS header but not the - IP header and before the reply RR counts have been adjusted for the - inclusion of any transaction SIG, concatenated with the entire DNS - query message that produced this response, including the query's DNS - header and any request SIGs but not its IP header. That is - - data = full response (less transaction SIG) | full query - - Verification of the transaction SIG (which is signed by the server - host key, not the zone key) by the requesting resolver shows that the - query and response were not tampered with in transit, that the - response corresponds to the intended query, and that the response - comes from the queried server. - - A DNS request may be optionally signed by including one or more SIGs - at the end of the query. Such SIGs are identified by having a "type - covered" field of zero. They sign the preceding DNS request message - including DNS header but not including the IP header or any request - SIGs at the end and before the request RR counts have been adjusted - for the inclusions of any request SIG(s). - - WARNING: Request SIGs are unnecessary for any currently defined - request other than update [RFC 2136, 2137] and will cause some old - DNS servers to give an error return or ignore a query. However, such - SIGs may in the future be needed for other requests. - - Except where needed to authenticate an update or similar privileged - request, servers are not required to check request SIGs. - -4.2 SIG RRs in the Construction of Responses - - Security aware DNS servers SHOULD, for every authenticated RRset the - query will return, attempt to send the available SIG RRs which - authenticate the requested RRset. The following rules apply to the - inclusion of SIG RRs in responses: - - - - - -Eastlake Standards Track [Page 21] - -RFC 2535 DNS Security Extensions March 1999 - - - 1. when an RRset is placed in a response, its SIG RR has a higher - priority for inclusion than additional RRs that may need to be - included. If space does not permit its inclusion, the response - MUST be considered truncated except as provided in 2 below. - - 2. When a SIG RR is present in the zone for an additional - information section RR, the response MUST NOT be considered - truncated merely because space does not permit the inclusion of - the SIG RR with the additional information. - - 3. SIGs to authenticate glue records and NS RRs for subzones at a - delegation point are unnecessary and MUST NOT be sent. - - 4. If a SIG covers any RR that would be in the answer section of - the response, its automatic inclusion MUST be in the answer - section. If it covers an RR that would appear in the authority - section, its automatic inclusion MUST be in the authority - section. If it covers an RR that would appear in the additional - information section it MUST appear in the additional information - section. This is a change in the existing standard [RFCs 1034, - 1035] which contemplates only NS and SOA RRs in the authority - section. - - 5. Optionally, DNS transactions may be authenticated by a SIG RR at - the end of the response in the additional information section - (Section 4.1.8.1). Such SIG RRs are signed by the DNS server - originating the response. Although the signer field MUST be a - name of the originating server host, the owner name, class, TTL, - and original TTL, are meaningless. The class and TTL fields - SHOULD be zero. To conserve space, the owner name SHOULD be - root (a single zero octet). If transaction authentication is - desired, that SIG RR must be considered the highest priority for - inclusion. - -4.3 Processing Responses and SIG RRs - - The following rules apply to the processing of SIG RRs included in a - response: - - 1. A security aware resolver that receives a response from a - security aware server via a secure communication with the AD bit - (see Section 6.1) set, MAY choose to accept the RRs as received - without verifying the zone SIG RRs. - - 2. In other cases, a security aware resolver SHOULD verify the SIG - RRs for the RRs of interest. This may involve initiating - additional queries for SIG or KEY RRs, especially in the case of - - - - -Eastlake Standards Track [Page 22] - -RFC 2535 DNS Security Extensions March 1999 - - - getting a response from a server that does not implement - security. (As explained in 2.3.5 above, it will not be possible - to secure CNAMEs being served up by non-secure resolvers.) - - NOTE: Implementers might expect the above SHOULD to be a MUST. - However, local policy or the calling application may not require - the security services. - - 3. If SIG RRs are received in response to a user query explicitly - specifying the SIG type, no special processing is required. - - If the message does not pass integrity checks or the SIG does not - check against the signed RRs, the SIG RR is invalid and should be - ignored. If all of the SIG RR(s) purporting to authenticate an RRset - are invalid, then the RRset is not authenticated. - - If the SIG RR is the last RR in a response in the additional - information section and has a type covered of zero, it is a - transaction signature of the response and the query that produced the - response. It MAY be optionally checked and the message rejected if - the checks fail. But even if the checks succeed, such a transaction - authentication SIG does NOT directly authenticate any RRs in the - message. Only a proper SIG RR signed by the zone or a key tracing - its authority to the zone or to static resolver configuration can - directly authenticate RRs, depending on resolver policy (see Section - 6). If a resolver does not implement transaction and/or request - SIGs, it MUST ignore them without error. - - If all checks indicate that the SIG RR is valid then RRs verified by - it should be considered authenticated. - -4.4 Signature Lifetime, Expiration, TTLs, and Validity - - Security aware servers MUST NOT consider SIG RRs to authenticate - anything before their signature inception or after its expiration - time (see also Section 6). Security aware servers MUST NOT consider - any RR to be authenticated after all its signatures have expired. - When a secure server caches authenticated data, if the TTL would - expire at a time further in the future than the authentication - expiration time, the server SHOULD trim the TTL in the cache entry - not to extent beyond the authentication expiration time. Within - these constraints, servers should continue to follow DNS TTL aging. - Thus authoritative servers should continue to follow the zone refresh - and expire parameters and a non-authoritative server should count - down the TTL and discard RRs when the TTL is zero (even for a SIG - that has not yet reached its authentication expiration time). In - addition, when RRs are transmitted in a query response, the TTL - - - - -Eastlake Standards Track [Page 23] - -RFC 2535 DNS Security Extensions March 1999 - - - should be trimmed so that current time plus the TTL does not extend - beyond the authentication expiration time. Thus, in general, the TTL - on a transmitted RR would be - - min(authExpTim,max(zoneMinTTL,min(originalTTL,currentTTL))) - - When signatures are generated, signature expiration times should be - set far enough in the future that it is quite certain that new - signatures can be generated before the old ones expire. However, - setting expiration too far into the future could mean a long time to - flush any bad data or signatures that may have been generated. - - It is recommended that signature lifetime be a small multiple of the - TTL (ie, 4 to 16 times the TTL) but not less than a reasonable - maximum re-signing interval and not less than the zone expiry time. - -5. Non-existent Names and Types - - The SIG RR mechanism described in Section 4 above provides strong - authentication of RRs that exist in a zone. But it is not clear - above how to verifiably deny the existence of a name in a zone or a - type for an existent name. - - The nonexistence of a name in a zone is indicated by the NXT ("next") - RR for a name interval containing the nonexistent name. An NXT RR or - RRs and its or their SIG(s) are returned in the authority section, - along with the error, if the server is security aware. The same is - true for a non-existent type under an existing name except that there - is no error indication other than an empty answer section - accompanying the NXT(s). This is a change in the existing standard - [RFCs 1034/1035] which contemplates only NS and SOA RRs in the - authority section. NXT RRs will also be returned if an explicit query - is made for the NXT type. - - The existence of a complete set of NXT records in a zone means that - any query for any name and any type to a security aware server - serving the zone will result in an reply containing at least one - signed RR unless it is a query for delegation point NS or glue A or - AAAA RRs. - -5.1 The NXT Resource Record - - The NXT resource record is used to securely indicate that RRs with an - owner name in a certain name interval do not exist in a zone and to - indicate what RR types are present for an existing name. - - - - - - -Eastlake Standards Track [Page 24] - -RFC 2535 DNS Security Extensions March 1999 - - - The owner name of the NXT RR is an existing name in the zone. It's - RDATA is a "next" name and a type bit map. Thus the NXT RRs in a zone - create a chain of all of the literal owner names in that zone, - including unexpanded wildcards but omitting the owner name of glue - address records unless they would otherwise be included. This implies - a canonical ordering of all domain names in a zone as described in - Section 8. The presence of the NXT RR means that no name between its - owner name and the name in its RDATA area exists and that no other - types exist under its owner name. - - There is a potential problem with the last NXT in a zone as it wants - to have an owner name which is the last existing name in canonical - order, which is easy, but it is not obvious what name to put in its - RDATA to indicate the entire remainder of the name space. This is - handled by treating the name space as circular and putting the zone - name in the RDATA of the last NXT in a zone. - - The NXT RRs for a zone SHOULD be automatically calculated and added - to the zone when SIGs are added. The NXT RR's TTL SHOULD NOT exceed - the zone minimum TTL. - - The type number for the NXT RR is 30. - - NXT RRs are only signed by zone level keys. - -5.2 NXT RDATA Format - - The RDATA for an NXT RR consists simply of a domain name followed by - a bit map, as shown below. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | next domain name / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | type bit map / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The NXT RR type bit map format currently defined is one bit per RR - type present for the owner name. A one bit indicates that at least - one RR of that type is present for the owner name. A zero indicates - that no such RR is present. All bits not specified because they are - beyond the end of the bit map are assumed to be zero. Note that bit - 30, for NXT, will always be on so the minimum bit map length is - actually four octets. Trailing zero octets are prohibited in this - format. The first bit represents RR type zero (an illegal type which - can not be present) and so will be zero in this format. This format - is not used if there exists an RR with a type number greater than - - - -Eastlake Standards Track [Page 25] - -RFC 2535 DNS Security Extensions March 1999 - - - 127. If the zero bit of the type bit map is a one, it indicates that - a different format is being used which will always be the case if a - type number greater than 127 is present. - - The domain name may be compressed with standard DNS name compression - when being transmitted over the network. The size of the bit map can - be inferred from the RDLENGTH and the length of the next domain name. - -5.3 Additional Complexity Due to Wildcards - - Proving that a non-existent name response is correct or that a - wildcard expansion response is correct makes things a little more - complex. - - In particular, when a non-existent name response is returned, an NXT - must be returned showing that the exact name queried did not exist - and, in general, one or more additional NXT's need to be returned to - also prove that there wasn't a wildcard whose expansion should have - been returned. (There is no need to return multiple copies of the - same NXT.) These NXTs, if any, are returned in the authority section - of the response. - - Furthermore, if a wildcard expansion is returned in a response, in - general one or more NXTs needs to also be returned in the authority - section to prove that no more specific name (including possibly more - specific wildcards in the zone) existed on which the response should - have been based. - -5.4 Example - - Assume zone foo.nil has entries for - - big.foo.nil, - medium.foo.nil. - small.foo.nil. - tiny.foo.nil. - - Then a query to a security aware server for huge.foo.nil would - produce an error reply with an RCODE of NXDOMAIN and the authority - section data including something like the following: - - - - - - - - - - - -Eastlake Standards Track [Page 26] - -RFC 2535 DNS Security Extensions March 1999 - - - foo.nil. NXT big.foo.nil NS KEY SOA NXT ;prove no *.foo.nil - foo.nil. SIG NXT 1 2 ( ;type-cov=NXT, alg=1, labels=2 - 19970102030405 ;signature expiration - 19961211100908 ;signature inception - 2143 ;key identifier - foo.nil. ;signer - AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfBeH1El4ixPFhpfHFElxbvKoWmvjDTCm - fiYy2X+8XpFjwICHc398kzWsTMKlxovpz2FnCTM= ;signature (640 bits) - ) - big.foo.nil. NXT medium.foo.nil. A MX SIG NXT ;prove no huge.foo.nil - big.foo.nil. SIG NXT 1 3 ( ;type-cov=NXT, alg=1, labels=3 - 19970102030405 ;signature expiration - 19961211100908 ;signature inception - 2143 ;key identifier - foo.nil. ;signer - MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU - 1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature (640 bits) - ) - Note that this response implies that big.foo.nil is an existing name - in the zone and thus has other RR types associated with it than NXT. - However, only the NXT (and its SIG) RR appear in the response to this - query for huge.foo.nil, which is a non-existent name. - -5.5 Special Considerations at Delegation Points - - A name (other than root) which is the head of a zone also appears as - the leaf in a superzone. If both are secure, there will always be - two different NXT RRs with the same name. They can be easily - distinguished by their signers, the next domain name fields, the - presence of the SOA type bit, etc. Security aware servers should - return the correct NXT automatically when required to authenticate - the non-existence of a name and both NXTs, if available, on explicit - query for type NXT. - - Non-security aware servers will never automatically return an NXT and - some old implementations may only return the NXT from the subzone on - explicit queries. - -5.6 Zone Transfers - - The subsections below describe how full and incremental zone - transfers are secured. - - SIG RRs secure all authoritative RRs transferred for both full and - incremental [RFC 1995] zone transfers. NXT RRs are an essential - element in secure zone transfers and assure that every authoritative - name and type will be present; however, if there are multiple SIGs - with the same name and type covered, a subset of the SIGs could be - - - -Eastlake Standards Track [Page 27] - -RFC 2535 DNS Security Extensions March 1999 - - - sent as long as at least one is present and, in the case of unsigned - delegation point NS or glue A or AAAA RRs a subset of these RRs or - simply a modified set could be sent as long as at least one of each - type is included. - - When an incremental or full zone transfer request is received with - the same or newer version number than that of the server's copy of - the zone, it is replied to with just the SOA RR of the server's - current version and the SIG RRset verifying that SOA RR. - - The complete NXT chains specified in this document enable a resolver - to obtain, by successive queries chaining through NXTs, all of the - names in a zone even if zone transfers are prohibited. Different - format NXTs may be specified in the future to avoid this. - -5.6.1 Full Zone Transfers - - To provide server authentication that a complete transfer has - occurred, transaction authentication SHOULD be used on full zone - transfers. This provides strong server based protection for the - entire zone in transit. - -5.6.2 Incremental Zone Transfers - - Individual RRs in an incremental (IXFR) transfer [RFC 1995] can be - verified in the same way as for a full zone transfer and the - integrity of the NXT name chain and correctness of the NXT type bits - for the zone after the incremental RR deletes and adds can check each - disjoint area of the zone updated. But the completeness of an - incremental transfer can not be confirmed because usually neither the - deleted RR section nor the added RR section has a compete zone NXT - chain. As a result, a server which securely supports IXFR must - handle IXFR SIG RRs for each incremental transfer set that it - maintains. - - The IXFR SIG is calculated over the incremental zone update - collection of RRs in the order in which it is transmitted: old SOA, - then deleted RRs, then new SOA and added RRs. Within each section, - RRs must be ordered as specified in Section 8. If condensation of - adjacent incremental update sets is done by the zone owner, the - original IXFR SIG for each set included in the condensation must be - discarded and a new on IXFR SIG calculated to cover the resulting - condensed set. - - The IXFR SIG really belongs to the zone as a whole, not to the zone - name. Although it SHOULD be correct for the zone name, the labels - field of an IXFR SIG is otherwise meaningless. The IXFR SIG is only - sent as part of an incremental zone transfer. After validation of - - - -Eastlake Standards Track [Page 28] - -RFC 2535 DNS Security Extensions March 1999 - - - the IXFR SIG, the transferred RRs MAY be considered valid without - verification of the internal SIGs if such trust in the server - conforms to local policy. - -6. How to Resolve Securely and the AD and CD Bits - - Retrieving or resolving secure data from the Domain Name System (DNS) - involves starting with one or more trusted public keys that have been - staticly configured at the resolver. With starting trusted keys, a - resolver willing to perform cryptography can progress securely - through the secure DNS structure to the zone of interest as described - in Section 6.3. Such trusted public keys would normally be configured - in a manner similar to that described in Section 6.2. However, as a - practical matter, a security aware resolver would still gain some - confidence in the results it returns even if it was not configured - with any keys but trusted what it got from a local well known server - as if it were staticly configured. - - Data stored at a security aware server needs to be internally - categorized as Authenticated, Pending, or Insecure. There is also a - fourth transient state of Bad which indicates that all SIG checks - have explicitly failed on the data. Such Bad data is not retained at - a security aware server. Authenticated means that the data has a - valid SIG under a KEY traceable via a chain of zero or more SIG and - KEY RRs allowed by the resolvers policies to a KEY staticly - configured at the resolver. Pending data has no authenticated SIGs - and at least one additional SIG the resolver is still trying to - authenticate. Insecure data is data which it is known can never be - either Authenticated or found Bad in the zone where it was found - because it is in or has been reached via a unsecured zone or because - it is unsigned glue address or delegation point NS data. Behavior in - terms of control of and flagging based on such data labels is - described in Section 6.1. - - The proper validation of signatures requires a reasonably secure - shared opinion of the absolute time between resolvers and servers as - described in Section 6.4. - -6.1 The AD and CD Header Bits - - Two previously unused bits are allocated out of the DNS - query/response format header. The AD (authentic data) bit indicates - in a response that all the data included in the answer and authority - portion of the response has been authenticated by the server - according to the policies of that server. The CD (checking disabled) - bit indicates in a query that Pending (non-authenticated) data is - acceptable to the resolver sending the query. - - - - -Eastlake Standards Track [Page 29] - -RFC 2535 DNS Security Extensions March 1999 - - - These bits are allocated from the previously must-be-zero Z field as - follows: - - 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| Z|AD|CD| RCODE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | QDCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ANCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | NSCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ARCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - These bits are zero in old servers and resolvers. Thus the responses - of old servers are not flagged as authenticated to security aware - resolvers and queries from non-security aware resolvers do not assert - the checking disabled bit and thus will be answered by security aware - servers only with Authenticated or Insecure data. Security aware - resolvers MUST NOT trust the AD bit unless they trust the server they - are talking to and either have a secure path to it or use DNS - transaction security. - - Any security aware resolver willing to do cryptography SHOULD assert - the CD bit on all queries to permit it to impose its own policies and - to reduce DNS latency time by allowing security aware servers to - answer with Pending data. - - Security aware servers MUST NOT return Bad data. For non-security - aware resolvers or security aware resolvers requesting service by - having the CD bit clear, security aware servers MUST return only - Authenticated or Insecure data in the answer and authority sections - with the AD bit set in the response. Security aware servers SHOULD - return Pending data, with the AD bit clear in the response, to - security aware resolvers requesting this service by asserting the CD - bit in their request. The AD bit MUST NOT be set on a response - unless all of the RRs in the answer and authority sections of the - response are either Authenticated or Insecure. The AD bit does not - cover the additional information section. - - - - - - - -Eastlake Standards Track [Page 30] - -RFC 2535 DNS Security Extensions March 1999 - - -6.2 Staticly Configured Keys - - The public key to authenticate a zone SHOULD be defined in local - configuration files before that zone is loaded at the primary server - so the zone can be authenticated. - - While it might seem logical for everyone to start with a public key - associated with the root zone and staticly configure this in every - resolver, this has problems. The logistics of updating every DNS - resolver in the world should this key ever change would be severe. - Furthermore, many organizations will explicitly wish their "interior" - DNS implementations to completely trust only their own DNS servers. - Interior resolvers of such organizations can then go through the - organization's zone servers to access data outside the organization's - domain and need not be configured with keys above the organization's - DNS apex. - - Host resolvers that are not part of a larger organization may be - configured with a key for the domain of their local ISP whose - recursive secure DNS caching server they use. - -6.3 Chaining Through The DNS - - Starting with one or more trusted keys for any zone, it should be - possible to retrieve signed keys for that zone's subzones which have - a key. A secure sub-zone is indicated by a KEY RR with non-null key - information appearing with the NS RRs in the sub-zone and which may - also be present in the parent. These make it possible to descend - within the tree of zones. - -6.3.1 Chaining Through KEYs - - In general, some RRset that you wish to validate in the secure DNS - will be signed by one or more SIG RRs. Each of these SIG RRs has a - signer under whose name is stored the public KEY to use in - authenticating the SIG. Each of those KEYs will, generally, also be - signed with a SIG. And those SIGs will have signer names also - referring to KEYs. And so on. As a result, authentication leads to - chains of alternating SIG and KEY RRs with the first SIG signing the - original data whose authenticity is to be shown and the final KEY - being some trusted key staticly configured at the resolver performing - the authentication. - - In testing such a chain, the validity periods of the SIGs encountered - must be intersected to determine the validity period of the - authentication of the data, a purely algorithmic process. In - addition, the validation of each SIG over the data with reference to - a KEY must meet the objective cryptographic test implied by the - - - -Eastlake Standards Track [Page 31] - -RFC 2535 DNS Security Extensions March 1999 - - - cryptographic algorithm used (although even here the resolver may - have policies as to trusted algorithms and key lengths). Finally, - the judgement that a SIG with a particular signer name can - authenticate data (possibly a KEY RRset) with a particular owner - name, is primarily a policy question. Ultimately, this is a policy - local to the resolver and any clients that depend on that resolver's - decisions. It is, however, recommended, that the policy below be - adopted: - - Let A < B mean that A is a shorter domain name than B formed by - dropping one or more whole labels from the left end of B, i.e., - A is a direct or indirect superdomain of B. Let A = B mean that - A and B are the same domain name (i.e., are identical after - letter case canonicalization). Let A > B mean that A is a - longer domain name than B formed by adding one or more whole - labels on the left end of B, i.e., A is a direct or indirect - subdomain of B - - Let Static be the owner names of the set of staticly configured - trusted keys at a resolver. - - Then Signer is a valid signer name for a SIG authenticating an - RRset (possibly a KEY RRset) with owner name Owner at the - resolver if any of the following three rules apply: - - (1) Owner > or = Signer (except that if Signer is root, Owner - must be root or a top level domain name). That is, Owner is the - same as or a subdomain of Signer. - - (2) ( Owner < Signer ) and ( Signer > or = some Static ). That - is, Owner is a superdomain of Signer and Signer is staticly - configured or a subdomain of a staticly configured key. - - (3) Signer = some Static. That is, the signer is exactly some - staticly configured key. - - Rule 1 is the rule for descending the DNS tree and includes a special - prohibition on the root zone key due to the restriction that the root - zone be only one label deep. This is the most fundamental rule. - - Rule 2 is the rule for ascending the DNS tree from one or more - staticly configured keys. Rule 2 has no effect if only root zone - keys are staticly configured. - - Rule 3 is a rule permitting direct cross certification. Rule 3 has - no effect if only root zone keys are staticly configured. - - - - - -Eastlake Standards Track [Page 32] - -RFC 2535 DNS Security Extensions March 1999 - - - Great care should be taken that the consequences have been fully - considered before making any local policy adjustments to these rules - (other than dispensing with rules 2 and 3 if only root zone keys are - staticly configured). - -6.3.2 Conflicting Data - - It is possible that there will be multiple SIG-KEY chains that appear - to authenticate conflicting RRset answers to the same query. A - resolver should choose only the most reliable answer to return and - discard other data. This choice of most reliable is a matter of - local policy which could take into account differing trust in - algorithms, key sizes, staticly configured keys, zones traversed, - etc. The technique given below is recommended for taking into - account SIG-KEY chain length. - - A resolver should keep track of the number of successive secure zones - traversed from a staticly configured key starting point to any secure - zone it can reach. In general, the lower such a distance number is, - the greater the confidence in the data. Staticly configured data - should be given a distance number of zero. If a query encounters - different Authenticated data for the same query with different - distance values, that with a larger value should be ignored unless - some other local policy covers the case. - - A security conscious resolver should completely refuse to step from a - secure zone into a unsecured zone unless the unsecured zone is - certified to be non-secure by the presence of an authenticated KEY RR - for the unsecured zone with the no-key type value. Otherwise the - resolver is getting bogus or spoofed data. - - If legitimate unsecured zones are encountered in traversing the DNS - tree, then no zone can be trusted as secure that can be reached only - via information from such non-secure zones. Since the unsecured zone - data could have been spoofed, the "secure" zone reached via it could - be counterfeit. The "distance" to data in such zones or zones - reached via such zones could be set to 256 or more as this exceeds - the largest possible distance through secure zones in the DNS. - -6.4 Secure Time - - Coordinated interpretation of the time fields in SIG RRs requires - that reasonably consistent time be available to the hosts - implementing the DNS security extensions. - - A variety of time synchronization protocols exist including the - Network Time Protocol (NTP [RFC 1305, 2030]). If such protocols are - used, they MUST be used securely so that time can not be spoofed. - - - -Eastlake Standards Track [Page 33] - -RFC 2535 DNS Security Extensions March 1999 - - - Otherwise, for example, a host could get its clock turned back and - might then believe old SIG RRs, and the data they authenticate, which - were valid but are no longer. - -7. ASCII Representation of Security RRs - - This section discusses the format for master file and other ASCII - presentation of the three DNS security resource records. - - The algorithm field in KEY and SIG RRs can be represented as either - an unsigned integer or symbolicly. The following initial symbols are - defined as indicated: - - Value Symbol - - 001 RSAMD5 - 002 DH - 003 DSA - 004 ECC - 252 INDIRECT - 253 PRIVATEDNS - 254 PRIVATEOID - -7.1 Presentation of KEY RRs - - KEY RRs may appear as single logical lines in a zone data master file - [RFC 1033]. - - The flag field is represented as an unsigned integer or a sequence of - mnemonics as follows separated by instances of the verticle bar ("|") - character: - - BIT Mnemonic Explanation - 0-1 key type - NOCONF =1 confidentiality use prohibited - NOAUTH =2 authentication use prohibited - NOKEY =3 no key present - 2 FLAG2 - reserved - 3 EXTEND flags extension - 4 FLAG4 - reserved - 5 FLAG5 - reserved - 6-7 name type - USER =0 (default, may be omitted) - ZONE =1 - HOST =2 (host or other end entity) - NTYP3 - reserved - 8 FLAG8 - reserved - 9 FLAG9 - reserved - - - -Eastlake Standards Track [Page 34] - -RFC 2535 DNS Security Extensions March 1999 - - - 10 FLAG10 - reserved - 11 FLAG11 - reserved - 12-15 signatory field, values 0 to 15 - can be represented by SIG0, SIG1, ... SIG15 - - No flag mnemonic need be present if the bit or field it represents is - zero. - - The protocol octet can be represented as either an unsigned integer - or symbolicly. The following initial symbols are defined: - - 000 NONE - 001 TLS - 002 EMAIL - 003 DNSSEC - 004 IPSEC - 255 ALL - - Note that if the type flags field has the NOKEY value, nothing - appears after the algorithm octet. - - The remaining public key portion is represented in base 64 (see - Appendix A) and may be divided up into any number of white space - separated substrings, down to single base 64 digits, which are - concatenated to obtain the full signature. These substrings can span - lines using the standard parenthesis. - - Note that the public key may have internal sub-fields but these do - not appear in the master file representation. For example, with - algorithm 1 there is a public exponent size, then a public exponent, - and then a modulus. With algorithm 254, there will be an OID size, - an OID, and algorithm dependent information. But in both cases only a - single logical base 64 string will appear in the master file. - -7.2 Presentation of SIG RRs - - A data SIG RR may be represented as a single logical line in a zone - data file [RFC 1033] but there are some special considerations as - described below. (It does not make sense to include a transaction or - request authenticating SIG RR in a file as they are a transient - authentication that covers data including an ephemeral transaction - number and so must be calculated in real time.) - - There is no particular problem with the signer, covered type, and - times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY - is the year, the first MM is the month number (01-12), DD is the day - of the month (01-31), HH is the hour in 24 hours notation (00-23), - the second MM is the minute (00-59), and SS is the second (00-59). - - - -Eastlake Standards Track [Page 35] - -RFC 2535 DNS Security Extensions March 1999 - - - The original TTL field appears as an unsigned integer. - - If the original TTL, which applies to the type signed, is the same as - the TTL of the SIG RR itself, it may be omitted. The date field - which follows it is larger than the maximum possible TTL so there is - no ambiguity. - - The "labels" field appears as an unsigned integer. - - The key tag appears as an unsigned number. - - However, the signature itself can be very long. It is the last data - field and is represented in base 64 (see Appendix A) and may be - divided up into any number of white space separated substrings, down - to single base 64 digits, which are concatenated to obtain the full - signature. These substrings can be split between lines using the - standard parenthesis. - -7.3 Presentation of NXT RRs - - NXT RRs do not appear in original unsigned zone master files since - they should be derived from the zone as it is being signed. If a - signed file with NXTs added is printed or NXTs are printed by - debugging code, they appear as the next domain name followed by the - RR type present bits as an unsigned interger or sequence of RR - mnemonics. - -8. Canonical Form and Order of Resource Records - - This section specifies, for purposes of domain name system (DNS) - security, the canonical form of resource records (RRs), their name - order, and their overall order. A canonical name order is necessary - to construct the NXT name chain. A canonical form and ordering - within an RRset is necessary in consistently constructing and - verifying SIG RRs. A canonical ordering of types within a name is - required in connection with incremental transfer (Section 5.6.2). - -8.1 Canonical RR Form - - For purposes of DNS security, the canonical form for an RR is the - wire format of the RR with domain names (1) fully expanded (no name - compression via pointers), (2) all domain name letters set to lower - case, (3) owner name wild cards in master file form (no substitution - made for *), and (4) the original TTL substituted for the current - TTL. - - - - - - -Eastlake Standards Track [Page 36] - -RFC 2535 DNS Security Extensions March 1999 - - -8.2 Canonical DNS Name Order - - For purposes of DNS security, the canonical ordering of owner names - is to sort individual labels as unsigned left justified octet strings - where the absence of a octet sorts before a zero value octet and - upper case letters are treated as lower case letters. Names in a - zone are sorted by sorting on the highest level label and then, - within those names with the same highest level label by the next - lower label, etc. down to leaf node labels. Within a zone, the zone - name itself always exists and all other names are the zone name with - some prefix of lower level labels. Thus the zone name itself always - sorts first. - - Example: - foo.example - a.foo.example - yljkjljk.a.foo.example - Z.a.foo.example - zABC.a.FOO.EXAMPLE - z.foo.example - *.z.foo.example - \200.z.foo.example - -8.3 Canonical RR Ordering Within An RRset - - Within any particular owner name and type, RRs are sorted by RDATA as - a left justified unsigned octet sequence where the absence of an - octet sorts before the zero octet. - -8.4 Canonical Ordering of RR Types - - When RRs of the same name but different types must be ordered, they - are ordered by type, considering the type to be an unsigned integer, - except that SIG RRs are placed immediately after the type they cover. - Thus, for example, an A record would be put before an MX record - because A is type 1 and MX is type 15 but if both were signed, the - order would be A < SIG(A) < MX < SIG(MX). - -9. Conformance - - Levels of server and resolver conformance are defined below. - -9.1 Server Conformance - - Two levels of server conformance for DNS security are defined as - follows: - - - - - -Eastlake Standards Track [Page 37] - -RFC 2535 DNS Security Extensions March 1999 - - - BASIC: Basic server compliance is the ability to store and retrieve - (including zone transfer) SIG, KEY, and NXT RRs. Any secondary or - caching server for a secure zone MUST have at least basic compliance - and even then some things, such as secure CNAMEs, will not work - without full compliance. - - FULL: Full server compliance adds the following to basic compliance: - (1) ability to read SIG, KEY, and NXT RRs in zone files and (2) - ability, given a zone file and private key, to add appropriate SIG - and NXT RRs, possibly via a separate application, (3) proper - automatic inclusion of SIG, KEY, and NXT RRs in responses, (4) - suppression of CNAME following on retrieval of the security type RRs, - (5) recognize the CD query header bit and set the AD query header - bit, as appropriate, and (6) proper handling of the two NXT RRs at - delegation points. Primary servers for secure zones MUST be fully - compliant and for complete secure operation, all secondary, caching, - and other servers handling the zone SHOULD be fully compliant as - well. - -9.2 Resolver Conformance - - Two levels of resolver compliance (including the resolver portion of - a server) are defined for DNS Security: - - BASIC: A basic compliance resolver can handle SIG, KEY, and NXT RRs - when they are explicitly requested. - - FULL: A fully compliant resolver (1) understands KEY, SIG, and NXT - RRs including verification of SIGs at least for the mandatory - algorithm, (2) maintains appropriate information in its local caches - and database to indicate which RRs have been authenticated and to - what extent they have been authenticated, (3) performs additional - queries as necessary to attempt to obtain KEY, SIG, or NXT RRs when - needed, (4) normally sets the CD query header bit on its queries. - -10. Security Considerations - - This document specifies extensions to the Domain Name System (DNS) - protocol to provide data integrity and data origin authentication, - public key distribution, and optional transaction and request - security. - - It should be noted that, at most, these extensions guarantee the - validity of resource records, including KEY resource records, - retrieved from the DNS. They do not magically solve other security - problems. For example, using secure DNS you can have high confidence - in the IP address you retrieve for a host name; however, this does - not stop someone for substituting an unauthorized host at that - - - -Eastlake Standards Track [Page 38] - -RFC 2535 DNS Security Extensions March 1999 - - - address or capturing packets sent to that address and falsely - responding with packets apparently from that address. Any reasonably - complete security system will require the protection of many - additional facets of the Internet beyond DNS. - - The implementation of NXT RRs as described herein enables a resolver - to determine all the names in a zone even if zone transfers are - prohibited (section 5.6). This is an active area of work and may - change. - - A number of precautions in DNS implementation have evolved over the - years to harden the insecure DNS against spoofing. These precautions - should not be abandoned but should be considered to provide - additional protection in case of key compromise in secure DNS. - -11. IANA Considerations - - KEY RR flag bits 2 and 8-11 and all flag extension field bits can be - assigned by IETF consensus as defined in RFC 2434. The remaining - values of the NAMTYP flag field and flag bits 4 and 5 (which could - conceivably become an extension of the NAMTYP field) can only be - assigned by an IETF Standards Action [RFC 2434]. - - Algorithm numbers 5 through 251 are available for assignment should - sufficient reason arise. However, the designation of a new algorithm - could have a major impact on interoperability and requires an IETF - Standards Action [RFC 2434]. The existence of the private algorithm - types 253 and 254 should satify most needs for private or proprietary - algorithms. - - Additional values of the Protocol Octet (5-254) can be assigned by - IETF Consensus [RFC 2434]. - - The meaning of the first bit of the NXT RR "type bit map" being a one - can only be assigned by a standards action. - -References - - [RFC 1033] Lottor, M., "Domain Administrators Operations Guide", RFC - 1033, November 1987. - - [RFC 1034] Mockapetris, P., "Domain Names - Concepts and - Facilities", STD 13, RFC 1034, November 1987. - - [RFC 1035] Mockapetris, P., "Domain Names - Implementation and - Specifications", STD 13, RFC 1035, November 1987. - - - - - -Eastlake Standards Track [Page 39] - -RFC 2535 DNS Security Extensions March 1999 - - - [RFC 1305] Mills, D., "Network Time Protocol (v3)", RFC 1305, March - 1992. - - [RFC 1530] Malamud, C. and M. Rose, "Principles of Operation for the - TPC.INT Subdomain: General Principles and Policy", RFC - 1530, October 1993. - - [RFC 2401] Kent, S. and R. Atkinson, "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. - - [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC - 1982, September 1996. - - [RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, - August 1996. - - [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 - for IPv4, IPv6 and OSI", RFC 2030, October 1996. - - [RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) Part One: Format of Internet Message - Bodies", RFC 2045, November 1996. - - [RFC 2065] Eastlake, D. and C. Kaufman, "Domain Name System Security - Extensions", RFC 2065, January 1997. - - [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - [RFC 2137] Eastlake, D., "Secure Domain Name System Dynamic Update", - RFC 2137, April 1997. - - [RFC 2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - - [RFC 2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name - System (DNS)", RFC 2537, March 1999. - - [RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the - Domain Name System (DNS)", RFC 2539, March 1999. - - - -Eastlake Standards Track [Page 40] - -RFC 2535 DNS Security Extensions March 1999 - - - [RFC 2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name - System (DNS)", RFC 2536, March 1999. - - [RFC 2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in - the Domain Name System", RFC 2538, March 1999. - - [RFC 2541] Eastlake, D., "DNS Operational Security Considerations", - RFC 2541, March 1999. - - [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting. - -Author's Address - - Donald E. Eastlake 3rd - IBM - 65 Shindegan Hill Road - RR #1 - Carmel, NY 10512 - - Phone: +1-914-784-7913 (w) - +1-914-276-2668 (h) - Fax: +1-914-784-3833 (w-fax) - EMail: dee3@us.ibm.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake Standards Track [Page 41] - -RFC 2535 DNS Security Extensions March 1999 - - -Appendix A: Base 64 Encoding - - The following encoding technique is taken from [RFC 2045] by N. - Borenstein and N. Freed. It is reproduced here in an edited form for - convenience. - - A 65-character subset of US-ASCII is used, enabling 6 bits to be - represented per printable character. (The extra 65th character, "=", - is used to signify a special processing function.) - - The encoding process represents 24-bit groups of input bits as output - strings of 4 encoded characters. Proceeding from left to right, a - 24-bit input group is formed by concatenating 3 8-bit input groups. - These 24 bits are then treated as 4 concatenated 6-bit groups, each - of which is translated into a single digit in the base 64 alphabet. - - Each 6-bit group is used as an index into an array of 64 printable - characters. The character referenced by the index is placed in the - output string. - - Table 1: The Base 64 Alphabet - - Value Encoding Value Encoding Value Encoding Value Encoding - 0 A 17 R 34 i 51 z - 1 B 18 S 35 j 52 0 - 2 C 19 T 36 k 53 1 - 3 D 20 U 37 l 54 2 - 4 E 21 V 38 m 55 3 - 5 F 22 W 39 n 56 4 - 6 G 23 X 40 o 57 5 - 7 H 24 Y 41 p 58 6 - 8 I 25 Z 42 q 59 7 - 9 J 26 a 43 r 60 8 - 10 K 27 b 44 s 61 9 - 11 L 28 c 45 t 62 + - 12 M 29 d 46 u 63 / - 13 N 30 e 47 v - 14 O 31 f 48 w (pad) = - 15 P 32 g 49 x - 16 Q 33 h 50 y - - Special processing is performed if fewer than 24 bits are available - at the end of the data being encoded. A full encoding quantum is - always completed at the end of a quantity. When fewer than 24 input - bits are available in an input group, zero bits are added (on the - right) to form an integral number of 6-bit groups. Padding at the - end of the data is performed using the '=' character. Since all base - 64 input is an integral number of octets, only the following cases - - - -Eastlake Standards Track [Page 42] - -RFC 2535 DNS Security Extensions March 1999 - - - can arise: (1) the final quantum of encoding input is an integral - multiple of 24 bits; here, the final unit of encoded output will be - an integral multiple of 4 characters with no "=" padding, (2) the - final quantum of encoding input is exactly 8 bits; here, the final - unit of encoded output will be two characters followed by two "=" - padding characters, or (3) the final quantum of encoding input is - exactly 16 bits; here, the final unit of encoded output will be three - characters followed by one "=" padding character. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake Standards Track [Page 43] - -RFC 2535 DNS Security Extensions March 1999 - - -Appendix B: Changes from RFC 2065 - - This section summarizes the most important changes that have been - made since RFC 2065. - - 1. Most of Section 7 of [RFC 2065] called "Operational - Considerations", has been removed and may be made into a separate - document [RFC 2541]. - - 2. The KEY RR has been changed by (2a) eliminating the "experimental" - flag as unnecessary, (2b) reserving a flag bit for flags - expansion, (2c) more compactly encoding a number of bit fields in - such a way as to leave unchanged bits actually used by the limited - code currently deployed, (2d) eliminating the IPSEC and email flag - bits which are replaced by values of the protocol field and adding - a protocol field value for DNS security itself, (2e) adding - material to indicate that zone KEY RRs occur only at delegation - points, and (2f) removing the description of the RSA/MD5 algorithm - to a separate document [RFC 2537]. Section 3.4 describing the - meaning of various combinations of "no-key" and key present KEY - RRs has been added and the secure / unsecure status of a zone has - been clarified as being per algorithm. - - 3. The SIG RR has been changed by (3a) renaming the "time signed" - field to be the "signature inception" field, (3b) clarifying that - signature expiration and inception use serial number ring - arithmetic, (3c) changing the definition of the key footprint/tag - for algorithms other than 1 and adding Appendix C to specify its - calculation. In addition, the SIG covering type AXFR has been - eliminated while one covering IXFR [RFC 1995] has been added (see - section 5.6). - - 4. Algorithm 3, the DSA algorithm, is now designated as the mandatory - to implement algorithm. Algorithm 1, the RSA/MD5 algorithm, is - now a recommended option. Algorithm 2 and 4 are designated as the - Diffie-Hellman key and elliptic cryptography algorithms - respectively, all to be defined in separate documents. Algorithm - code point 252 is designated to indicate "indirect" keys, to be - defined in a separate document, where the actual key is elsewhere. - Both the KEY and SIG RR definitions have been simplified by - eliminating the "null" algorithm 253 as defined in [RFC 2065]. - That algorithm had been included because at the time it was - thought it might be useful in DNS dynamic update [RFC 2136]. It - was in fact not so used and it is dropped to simplify DNS - security. Howver, that algorithm number has been re-used to - indicate private algorithms where a domain name specifies the - algorithm. - - - - -Eastlake Standards Track [Page 44] - -RFC 2535 DNS Security Extensions March 1999 - - - 5. The NXT RR has been changed so that (5a) the NXT RRs in a zone - cover all names, including wildcards as literal names without - expansion, except for glue address records whose names would not - otherwise appear, (5b) all NXT bit map areas whose first octet has - bit zero set have been reserved for future definition, (5c) the - number of and circumstances under which an NXT must be returned in - connection with wildcard names has been extended, and (5d) in - connection with the bit map, references to the WKS RR have been - removed and verticle bars ("|") have been added between the RR - type mnemonics in the ASCII representation. - - 6. Information on the canonical form and ordering of RRs has been - moved into a separate Section 8. - - 7. A subsection covering incremental and full zone transfer has been - added in Section 5. - - 8. Concerning DNS chaining: Further specification and policy - recommendations on secure resolution have been added, primarily in - Section 6.3.1. It is now clearly stated that authenticated data - has a validity period of the intersection of the validity periods - of the SIG RRs in its authentication chain. The requirement to - staticly configure a superzone's key signed by a zone in all of - the zone's authoritative servers has been removed. The - recommendation to continue DNS security checks in a secure island - of DNS data that is separated from other parts of the DNS tree by - insecure zones and does not contain a zone for which a key has - been staticly configured was dropped. - - 9. It was clarified that the presence of the AD bit in a response - does not apply to the additional information section or to glue - address or delegation point NS RRs. The AD bit only indicates - that the answer and authority sections of the response are - authoritative. - - 10. It is now required that KEY RRs and NXT RRs be signed only with - zone-level keys. - - 11. Add IANA Considerations section and references to RFC 2434. - - - - - - - - - - - - -Eastlake Standards Track [Page 45] - -RFC 2535 DNS Security Extensions March 1999 - - -Appendix C: Key Tag Calculation - - The key tag field in the SIG RR is just a means of more efficiently - selecting the correct KEY RR to use when there is more than one KEY - RR candidate available, for example, in verifying a signature. It is - possible for more than one candidate key to have the same tag, in - which case each must be tried until one works or all fail. The - following reference implementation of how to calculate the Key Tag, - for all algorithms other than algorithm 1, is in ANSI C. It is coded - for clarity, not efficiency. (See section 4.1.6 for how to determine - the Key Tag of an algorithm 1 key.) - - /* assumes int is at least 16 bits - first byte of the key tag is the most significant byte of return - value - second byte of the key tag is the least significant byte of - return value - */ - - int keytag ( - - unsigned char key[], /* the RDATA part of the KEY RR */ - unsigned int keysize, /* the RDLENGTH */ - ) - { - long int ac; /* assumed to be 32 bits or larger */ - - for ( ac = 0, i = 0; i < keysize; ++i ) - ac += (i&1) ? key[i] : key[i]<<8; - ac += (ac>>16) & 0xFFFF; - return ac & 0xFFFF; - } - - - - - - - - - - - - - - - - - - - -Eastlake Standards Track [Page 46] - -RFC 2535 DNS Security Extensions March 1999 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake Standards Track [Page 47] - diff --git a/contrib/bind9/doc/rfc/rfc2536.txt b/contrib/bind9/doc/rfc/rfc2536.txt deleted file mode 100644 index 88be242bb7d0..000000000000 --- a/contrib/bind9/doc/rfc/rfc2536.txt +++ /dev/null @@ -1,339 +0,0 @@ - - - - - - -Network Working Group D. EastLake -Request for Comments: 2536 IBM -Category: Standards Track March 1999 - - - DSA KEYs and SIGs in the Domain Name System (DNS) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - -Abstract - - A standard method for storing US Government Digital Signature - Algorithm keys and signatures in the Domain Name System is described - which utilizes DNS KEY and SIG resource records. - -Table of Contents - - Abstract...................................................1 - 1. Introduction............................................1 - 2. DSA KEY Resource Records................................2 - 3. DSA SIG Resource Records................................3 - 4. Performance Considerations..............................3 - 5. Security Considerations.................................4 - 6. IANA Considerations.....................................4 - References.................................................5 - Author's Address...........................................5 - Full Copyright Statement...................................6 - -1. Introduction - - The Domain Name System (DNS) is the global hierarchical replicated - distributed database system for Internet addressing, mail proxy, and - other information. The DNS has been extended to include digital - signatures and cryptographic keys as described in [RFC 2535]. Thus - the DNS can now be secured and can be used for secure key - distribution. - - - - - -Eastlake Standards Track [Page 1] - -RFC 2536 DSA in the DNS March 1999 - - - This document describes how to store US Government Digital Signature - Algorithm (DSA) keys and signatures in the DNS. Familiarity with the - US Digital Signature Algorithm is assumed [Schneier]. Implementation - of DSA is mandatory for DNS security. - -2. DSA KEY Resource Records - - DSA public keys are stored in the DNS as KEY RRs using algorithm - number 3 [RFC 2535]. The structure of the algorithm specific portion - of the RDATA part of this RR is as shown below. These fields, from Q - through Y are the "public key" part of the DSA KEY RR. - - The period of key validity is not in the KEY RR but is indicated by - the SIG RR(s) which signs and authenticates the KEY RR(s) at that - domain name. - - Field Size - ----- ---- - T 1 octet - Q 20 octets - P 64 + T*8 octets - G 64 + T*8 octets - Y 64 + T*8 octets - - As described in [FIPS 186] and [Schneier]: T is a key size parameter - chosen such that 0 <= T <= 8. (The meaning for algorithm 3 if the T - octet is greater than 8 is reserved and the remainder of the RDATA - portion may have a different format in that case.) Q is a prime - number selected at key generation time such that 2**159 < Q < 2**160 - so Q is always 20 octets long and, as with all other fields, is - stored in "big-endian" network order. P, G, and Y are calculated as - directed by the FIPS 186 key generation algorithm [Schneier]. P is - in the range 2**(511+64T) < P < 2**(512+64T) and so is 64 + 8*T - octets long. G and Y are quantities modulus P and so can be up to - the same length as P and are allocated fixed size fields with the - same number of octets as P. - - During the key generation process, a random number X must be - generated such that 1 <= X <= Q-1. X is the private key and is used - in the final step of public key generation where Y is computed as - - Y = G**X mod P - - - - - - - - - -Eastlake Standards Track [Page 2] - -RFC 2536 DSA in the DNS March 1999 - - -3. DSA SIG Resource Records - - The signature portion of the SIG RR RDATA area, when using the US - Digital Signature Algorithm, is shown below with fields in the order - they occur. See [RFC 2535] for fields in the SIG RR RDATA which - precede the signature itself. - - Field Size - ----- ---- - T 1 octet - R 20 octets - S 20 octets - - The data signed is determined as specified in [RFC 2535]. Then the - following steps are taken, as specified in [FIPS 186], where Q, P, G, - and Y are as specified in the public key [Schneier]: - - hash = SHA-1 ( data ) - - Generate a random K such that 0 < K < Q. - - R = ( G**K mod P ) mod Q - - S = ( K**(-1) * (hash + X*R) ) mod Q - - Since Q is 160 bits long, R and S can not be larger than 20 octets, - which is the space allocated. - - T is copied from the public key. It is not logically necessary in - the SIG but is present so that values of T > 8 can more conveniently - be used as an escape for extended versions of DSA or other algorithms - as later specified. - -4. Performance Considerations - - General signature generation speeds are roughly the same for RSA [RFC - 2537] and DSA. With sufficient pre-computation, signature generation - with DSA is faster than RSA. Key generation is also faster for DSA. - However, signature verification is an order of magnitude slower than - RSA when the RSA public exponent is chosen to be small as is - recommended for KEY RRs used in domain name system (DNS) data - authentication. - - Current DNS implementations are optimized for small transfers, - typically less than 512 bytes including overhead. While larger - transfers will perform correctly and work is underway to make larger - transfers more efficient, it is still advisable at this time to make - reasonable efforts to minimize the size of KEY RR sets stored within - - - -Eastlake Standards Track [Page 3] - -RFC 2536 DSA in the DNS March 1999 - - - the DNS consistent with adequate security. Keep in mind that in a - secure zone, at least one authenticating SIG RR will also be - returned. - -5. Security Considerations - - Many of the general security consideration in [RFC 2535] apply. Keys - retrieved from the DNS should not be trusted unless (1) they have - been securely obtained from a secure resolver or independently - verified by the user and (2) this secure resolver and secure - obtainment or independent verification conform to security policies - acceptable to the user. As with all cryptographic algorithms, - evaluating the necessary strength of the key is essential and - dependent on local policy. - - The key size limitation of a maximum of 1024 bits ( T = 8 ) in the - current DSA standard may limit the security of DSA. For particularly - critical applications, implementors are encouraged to consider the - range of available algorithms and key sizes. - - DSA assumes the ability to frequently generate high quality random - numbers. See [RFC 1750] for guidance. DSA is designed so that if - manipulated rather than random numbers are used, very high bandwidth - covert channels are possible. See [Schneier] and more recent - research. The leakage of an entire DSA private key in only two DSA - signatures has been demonstrated. DSA provides security only if - trusted implementations, including trusted random number generation, - are used. - -6. IANA Considerations - - Allocation of meaning to values of the T parameter that are not - defined herein requires an IETF standards actions. It is intended - that values unallocated herein be used to cover future extensions of - the DSS standard. - - - - - - - - - - - - - - - - -Eastlake Standards Track [Page 4] - -RFC 2536 DSA in the DNS March 1999 - - -References - - [FIPS 186] U.S. Federal Information Processing Standard: Digital - Signature Standard. - - [RFC 1034] Mockapetris, P., "Domain Names - Concepts and - Facilities", STD 13, RFC 1034, November 1987. - - [RFC 1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - [RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness - Recommendations for Security", RFC 1750, December 1994. - - [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC 2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name - System (DNS)", RFC 2537, March 1999. - - [Schneier] Schneier, B., "Applied Cryptography Second Edition: - protocols, algorithms, and source code in C", 1996. - -Author's Address - - Donald E. Eastlake 3rd - IBM - 65 Shindegan Hill Road, RR #1 - Carmel, NY 10512 - - Phone: +1-914-276-2668(h) - +1-914-784-7913(w) - Fax: +1-914-784-3833(w) - EMail: dee3@us.ibm.com - - - - - - - - - - - - - - - - - -Eastlake Standards Track [Page 5] - -RFC 2536 DSA in the DNS March 1999 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake Standards Track [Page 6] - diff --git a/contrib/bind9/doc/rfc/rfc2537.txt b/contrib/bind9/doc/rfc/rfc2537.txt deleted file mode 100644 index cb75cf5b3b81..000000000000 --- a/contrib/bind9/doc/rfc/rfc2537.txt +++ /dev/null @@ -1,339 +0,0 @@ - - - - - - -Network Working Group D. Eastlake -Request for Comments: 2537 IBM -Category: Standards Track March 1999 - - - RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - -Abstract - - A standard method for storing RSA keys and and RSA/MD5 based - signatures in the Domain Name System is described which utilizes DNS - KEY and SIG resource records. - -Table of Contents - - Abstract...................................................1 - 1. Introduction............................................1 - 2. RSA Public KEY Resource Records.........................2 - 3. RSA/MD5 SIG Resource Records............................2 - 4. Performance Considerations..............................3 - 5. Security Considerations.................................4 - References.................................................4 - Author's Address...........................................5 - Full Copyright Statement...................................6 - -1. Introduction - - The Domain Name System (DNS) is the global hierarchical replicated - distributed database system for Internet addressing, mail proxy, and - other information. The DNS has been extended to include digital - signatures and cryptographic keys as described in [RFC 2535]. Thus - the DNS can now be secured and used for secure key distribution. - - - - - - - -Eastlake Standards Track [Page 1] - -RFC 2537 RSA/MD5 KEYs and SIGs in the DNS March 1999 - - - This document describes how to store RSA keys and and RSA/MD5 based - signatures in the DNS. Familiarity with the RSA algorithm is assumed - [Schneier]. Implementation of the RSA algorithm in DNS is - recommended. - - The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" - in this document are to be interpreted as described in RFC 2119. - -2. RSA Public KEY Resource Records - - RSA public keys are stored in the DNS as KEY RRs using algorithm - number 1 [RFC 2535]. The structure of the algorithm specific portion - of the RDATA part of such RRs is as shown below. - - Field Size - ----- ---- - exponent length 1 or 3 octets (see text) - exponent as specified by length field - modulus remaining space - - For interoperability, the exponent and modulus are each currently - limited to 4096 bits in length. The public key exponent is a - variable length unsigned integer. Its length in octets is - represented as one octet if it is in the range of 1 to 255 and by a - zero octet followed by a two octet unsigned length if it is longer - than 255 bytes. The public key modulus field is a multiprecision - unsigned integer. The length of the modulus can be determined from - the RDLENGTH and the preceding RDATA fields including the exponent. - Leading zero octets are prohibited in the exponent and modulus. - -3. RSA/MD5 SIG Resource Records - - The signature portion of the SIG RR RDATA area, when using the - RSA/MD5 algorithm, is calculated as shown below. The data signed is - determined as specified in [RFC 2535]. See [RFC 2535] for fields in - the SIG RR RDATA which precede the signature itself. - - - hash = MD5 ( data ) - - signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) - - - - - - - - - - -Eastlake Standards Track [Page 2] - -RFC 2537 RSA/MD5 KEYs and SIGs in the DNS March 1999 - - - where MD5 is the message digest algorithm documented in [RFC 1321], - "|" is concatenation, "e" is the private key exponent of the signer, - and "n" is the modulus of the signer's public key. 01, FF, and 00 - are fixed octets of the corresponding hexadecimal value. "prefix" is - the ASN.1 BER MD5 algorithm designator prefix specified in [RFC - 2437], that is, - - hex 3020300c06082a864886f70d020505000410 [NETSEC]. - - This prefix is included to make it easier to use RSAREF (or similar - packages such as EuroRef). The FF octet MUST be repeated the maximum - number of times such that the value of the quantity being - exponentiated is the same length in octets as the value of n. - - (The above specifications are identical to the corresponding part of - Public Key Cryptographic Standard #1 [RFC 2437].) - - The size of n, including most and least significant bits (which will - be 1) MUST be not less than 512 bits and not more than 4096 bits. n - and e SHOULD be chosen such that the public exponent is small. - - Leading zero bytes are permitted in the RSA/MD5 algorithm signature. - - A public exponent of 3 minimizes the effort needed to verify a - signature. Use of 3 as the public exponent is weak for - confidentiality uses since, if the same data can be collected - encrypted under three different keys with an exponent of 3 then, - using the Chinese Remainder Theorem [NETSEC], the original plain text - can be easily recovered. This weakness is not significant for DNS - security because we seek only authentication, not confidentiality. - -4. Performance Considerations - - General signature generation speeds are roughly the same for RSA and - DSA [RFC 2536]. With sufficient pre-computation, signature - generation with DSA is faster than RSA. Key generation is also - faster for DSA. However, signature verification is an order of - magnitude slower with DSA when the RSA public exponent is chosen to - be small as is recommended for KEY RRs used in domain name system - (DNS) data authentication. - - Current DNS implementations are optimized for small transfers, - typically less than 512 bytes including overhead. While larger - transfers will perform correctly and work is underway to make larger - - - - - - - -Eastlake Standards Track [Page 3] - -RFC 2537 RSA/MD5 KEYs and SIGs in the DNS March 1999 - - - transfers more efficient, it is still advisable at this time to make - reasonable efforts to minimize the size of KEY RR sets stored within - the DNS consistent with adequate security. Keep in mind that in a - secure zone, at least one authenticating SIG RR will also be - returned. - -5. Security Considerations - - Many of the general security consideration in [RFC 2535] apply. Keys - retrieved from the DNS should not be trusted unless (1) they have - been securely obtained from a secure resolver or independently - verified by the user and (2) this secure resolver and secure - obtainment or independent verification conform to security policies - acceptable to the user. As with all cryptographic algorithms, - evaluating the necessary strength of the key is essential and - dependent on local policy. - - For interoperability, the RSA key size is limited to 4096 bits. For - particularly critical applications, implementors are encouraged to - consider the range of available algorithms and key sizes. - -References - - [NETSEC] Kaufman, C., Perlman, R. and M. Speciner, "Network - Security: PRIVATE Communications in a PUBLIC World", - Series in Computer Networking and Distributed - Communications, 1995. - - [RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography - Specifications Version 2.0", RFC 2437, October 1998. - - [RFC 1034] Mockapetris, P., "Domain Names - Concepts and - Facilities", STD 13, RFC 1034, November 1987. - - [RFC 1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321 - April 1992. - - [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC 2536] EastLake, D., "DSA KEYs and SIGs in the Domain Name - System (DNS)", RFC 2536, March 1999. - - - - - - -Eastlake Standards Track [Page 4] - -RFC 2537 RSA/MD5 KEYs and SIGs in the DNS March 1999 - - - [Schneier] Bruce Schneier, "Applied Cryptography Second Edition: - protocols, algorithms, and source code in C", 1996, John - Wiley and Sons, ISBN 0-471-11709-9. - -Author's Address - - Donald E. Eastlake 3rd - IBM - 65 Shindegan Hill Road, RR #1 - Carmel, NY 10512 - - Phone: +1-914-276-2668(h) - +1-914-784-7913(w) - Fax: +1-914-784-3833(w) - EMail: dee3@us.ibm.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake Standards Track [Page 5] - -RFC 2537 RSA/MD5 KEYs and SIGs in the DNS March 1999 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake Standards Track [Page 6] - diff --git a/contrib/bind9/doc/rfc/rfc2538.txt b/contrib/bind9/doc/rfc/rfc2538.txt deleted file mode 100644 index c53e3efd15b5..000000000000 --- a/contrib/bind9/doc/rfc/rfc2538.txt +++ /dev/null @@ -1,563 +0,0 @@ - - - - - - -Network Working Group D. Eastlake -Request for Comments: 2538 IBM -Category: Standards Track O. Gudmundsson - TIS Labs - March 1999 - - - Storing Certificates in the Domain Name System (DNS) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - -Abstract - - Cryptographic public key are frequently published and their - authenticity demonstrated by certificates. A CERT resource record - (RR) is defined so that such certificates and related certificate - revocation lists can be stored in the Domain Name System (DNS). - -Table of Contents - - Abstract...................................................1 - 1. Introduction............................................2 - 2. The CERT Resource Record................................2 - 2.1 Certificate Type Values................................3 - 2.2 Text Representation of CERT RRs........................4 - 2.3 X.509 OIDs.............................................4 - 3. Appropriate Owner Names for CERT RRs....................5 - 3.1 X.509 CERT RR Names....................................5 - 3.2 PGP CERT RR Names......................................6 - 4. Performance Considerations..............................6 - 5. IANA Considerations.....................................7 - 6. Security Considerations.................................7 - References.................................................8 - Authors' Addresses.........................................9 - Full Copyright Notice.....................................10 - - - - - - -Eastlake & Gudmundsson Standards Track [Page 1] - -RFC 2538 Storing Certificates in the DNS March 1999 - - -1. Introduction - - Public keys are frequently published in the form of a certificate and - their authenticity is commonly demonstrated by certificates and - related certificate revocation lists (CRLs). A certificate is a - binding, through a cryptographic digital signature, of a public key, - a validity interval and/or conditions, and identity, authorization, - or other information. A certificate revocation list is a list of - certificates that are revoked, and incidental information, all signed - by the signer (issuer) of the revoked certificates. Examples are - X.509 certificates/CRLs in the X.500 directory system or PGP - certificates/revocations used by PGP software. - - Section 2 below specifies a CERT resource record (RR) for the storage - of certificates in the Domain Name System. - - Section 3 discusses appropriate owner names for CERT RRs. - - Sections 4, 5, and 6 below cover performance, IANA, and security - considerations, respectively. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - -2. The CERT Resource Record - - The CERT resource record (RR) has the structure given below. Its RR - type code is 37. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | type | key tag | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | algorithm | / - +---------------+ certificate or CRL / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - - The type field is the certificate type as define in section 2.1 - below. - - The algorithm field has the same meaning as the algorithm field in - KEY and SIG RRs [RFC 2535] except that a zero algorithm field - indicates the algorithm is unknown to a secure DNS, which may simply - be the result of the algorithm not having been standardized for - secure DNS. - - - -Eastlake & Gudmundsson Standards Track [Page 2] - -RFC 2538 Storing Certificates in the DNS March 1999 - - - The key tag field is the 16 bit value computed for the key embedded - in the certificate as specified in the DNSSEC Standard [RFC 2535]. - This field is used as an efficiency measure to pick which CERT RRs - may be applicable to a particular key. The key tag can be calculated - for the key in question and then only CERT RRs with the same key tag - need be examined. However, the key must always be transformed to the - format it would have as the public key portion of a KEY RR before the - key tag is computed. This is only possible if the key is applicable - to an algorithm (and limits such as key size limits) defined for DNS - security. If it is not, the algorithm field MUST BE zero and the tag - field is meaningless and SHOULD BE zero. - -2.1 Certificate Type Values - - The following values are defined or reserved: - - Value Mnemonic Certificate Type - ----- -------- ----------- ---- - 0 reserved - 1 PKIX X.509 as per PKIX - 2 SPKI SPKI cert - 3 PGP PGP cert - 4-252 available for IANA assignment - 253 URI URI private - 254 OID OID private - 255-65534 available for IANA assignment - 65535 reserved - - The PKIX type is reserved to indicate an X.509 certificate conforming - to the profile being defined by the IETF PKIX working group. The - certificate section will start with a one byte unsigned OID length - and then an X.500 OID indicating the nature of the remainder of the - certificate section (see 2.3 below). (NOTE: X.509 certificates do - not include their X.500 directory type designating OID as a prefix.) - - The SPKI type is reserved to indicate a certificate formated as to be - specified by the IETF SPKI working group. - - The PGP type indicates a Pretty Good Privacy certificate as described - in RFC 2440 and its extensions and successors. - - The URI private type indicates a certificate format defined by an - absolute URI. The certificate portion of the CERT RR MUST begin with - a null terminated URI [RFC 2396] and the data after the null is the - private format certificate itself. The URI SHOULD be such that a - retrieval from it will lead to documentation on the format of the - certificate. Recognition of private certificate types need not be - based on URI equality but can use various forms of pattern matching - - - -Eastlake & Gudmundsson Standards Track [Page 3] - -RFC 2538 Storing Certificates in the DNS March 1999 - - - so that, for example, subtype or version information can also be - encoded into the URI. - - The OID private type indicates a private format certificate specified - by a an ISO OID prefix. The certificate section will start with a - one byte unsigned OID length and then a BER encoded OID indicating - the nature of the remainder of the certificate section. This can be - an X.509 certificate format or some other format. X.509 certificates - that conform to the IETF PKIX profile SHOULD be indicated by the PKIX - type, not the OID private type. Recognition of private certificate - types need not be based on OID equality but can use various forms of - pattern matching such as OID prefix. - -2.2 Text Representation of CERT RRs - - The RDATA portion of a CERT RR has the type field as an unsigned - integer or as a mnemonic symbol as listed in section 2.1 above. - - The key tag field is represented as an unsigned integer. - - The algorithm field is represented as an unsigned integer or a - mnemonic symbol as listed in [RFC 2535]. - - The certificate / CRL portion is represented in base 64 and may be - divided up into any number of white space separated substrings, down - to single base 64 digits, which are concatenated to obtain the full - signature. These substrings can span lines using the standard - parenthesis. - - Note that the certificate / CRL portion may have internal sub-fields - but these do not appear in the master file representation. For - example, with type 254, there will be an OID size, an OID, and then - the certificate / CRL proper. But only a single logical base 64 - string will appear in the text representation. - -2.3 X.509 OIDs - - OIDs have been defined in connection with the X.500 directory for - user certificates, certification authority certificates, revocations - of certification authority, and revocations of user certificates. - The following table lists the OIDs, their BER encoding, and their - length prefixed hex format for use in CERT RRs: - - - - - - - - - -Eastlake & Gudmundsson Standards Track [Page 4] - -RFC 2538 Storing Certificates in the DNS March 1999 - - - id-at-userCertificate - = { joint-iso-ccitt(2) ds(5) at(4) 36 } - == 0x 03 55 04 24 - id-at-cACertificate - = { joint-iso-ccitt(2) ds(5) at(4) 37 } - == 0x 03 55 04 25 - id-at-authorityRevocationList - = { joint-iso-ccitt(2) ds(5) at(4) 38 } - == 0x 03 55 04 26 - id-at-certificateRevocationList - = { joint-iso-ccitt(2) ds(5) at(4) 39 } - == 0x 03 55 04 27 - -3. Appropriate Owner Names for CERT RRs - - It is recommended that certificate CERT RRs be stored under a domain - name related to their subject, i.e., the name of the entity intended - to control the private key corresponding to the public key being - certified. It is recommended that certificate revocation list CERT - RRs be stored under a domain name related to their issuer. - - Following some of the guidelines below may result in the use in DNS - names of characters that require DNS quoting which is to use a - backslash followed by the octal representation of the ASCII code for - the character such as \000 for NULL. - -3.1 X.509 CERT RR Names - - Some X.509 versions permit multiple names to be associated with - subjects and issuers under "Subject Alternate Name" and "Issuer - Alternate Name". For example, x.509v3 has such Alternate Names with - an ASN.1 specification as follows: - - GeneralName ::= CHOICE { - otherName [0] INSTANCE OF OTHER-NAME, - rfc822Name [1] IA5String, - dNSName [2] IA5String, - x400Address [3] EXPLICIT OR-ADDRESS.&Type, - directoryName [4] EXPLICIT Name, - ediPartyName [5] EDIPartyName, - uniformResourceIdentifier [6] IA5String, - iPAddress [7] OCTET STRING, - registeredID [8] OBJECT IDENTIFIER - } - - The recommended locations of CERT storage are as follows, in priority - order: - - - - -Eastlake & Gudmundsson Standards Track [Page 5] - -RFC 2538 Storing Certificates in the DNS March 1999 - - - (1) If a domain name is included in the identification in the - certificate or CRL, that should be used. - (2) If a domain name is not included but an IP address is included, - then the translation of that IP address into the appropriate - inverse domain name should be used. - (3) If neither of the above it used but a URI containing a domain - name is present, that domain name should be used. - (4) If none of the above is included but a character string name is - included, then it should be treated as described for PGP names in - 3.2 below. - (5) If none of the above apply, then the distinguished name (DN) - should be mapped into a domain name as specified in RFC 2247. - - Example 1: Assume that an X.509v3 certificate is issued to /CN=John - Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative - names of (a) string "John (the Man) Doe", (b) domain name john- - doe.com, and (c) uri <https://www.secure.john-doe.com:8080/>. Then - the storage locations recommended, in priority order, would be - (1) john-doe.com, - (2) www.secure.john-doe.com, and - (3) Doe.com.xy. - - Example 2: Assume that an X.509v3 certificate is issued to /CN=James - Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names - of (a) domain name widget.foo.example, (b) IPv4 address - 10.251.13.201, and (c) string "James Hacker - <hacker@mail.widget.foo.example>". Then the storage locations - recommended, in priority order, would be - (1) widget.foo.example, - (2) 201.13.251.10.in-addr.arpa, and - (3) hacker.mail.widget.foo.example. - -3.2 PGP CERT RR Names - - PGP signed keys (certificates) use a general character string User ID - [RFC 2440]. However, it is recommended by PGP that such names include - the RFC 822 email address of the party, as in "Leslie Example - <Leslie@host.example>". If such a format is used, the CERT should be - under the standard translation of the email address into a domain - name, which would be leslie.host.example in this case. If no RFC 822 - name can be extracted from the string name no specific domain name is - recommended. - -4. Performance Considerations - - Current Domain Name System (DNS) implementations are optimized for - small transfers, typically not more than 512 bytes including - overhead. While larger transfers will perform correctly and work is - - - -Eastlake & Gudmundsson Standards Track [Page 6] - -RFC 2538 Storing Certificates in the DNS March 1999 - - - underway to make larger transfers more efficient, it is still - advisable at this time to make every reasonable effort to minimize - the size of certificates stored within the DNS. Steps that can be - taken may include using the fewest possible optional or extensions - fields and using short field values for variable length fields that - must be included. - -5. IANA Considerations - - Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can - only be assigned by an IETF standards action [RFC 2434] (and this - document assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE). - Certificate types 0x0100 through 0xFEFF are assigned through IETF - Consensus [RFC 2434] based on RFC documentation of the certificate - type. The availability of private types under 0x00FD and 0x00FE - should satisfy most requirements for proprietary or private types. - -6. Security Considerations - - By definition, certificates contain their own authenticating - signature. Thus it is reasonable to store certificates in non-secure - DNS zones or to retrieve certificates from DNS with DNS security - checking not implemented or deferred for efficiency. The results MAY - be trusted if the certificate chain is verified back to a known - trusted key and this conforms with the user's security policy. - - Alternatively, if certificates are retrieved from a secure DNS zone - with DNS security checking enabled and are verified by DNS security, - the key within the retrieved certificate MAY be trusted without - verifying the certificate chain if this conforms with the user's - security policy. - - CERT RRs are not used in connection with securing the DNS security - additions so there are no security considerations related to CERT RRs - and securing the DNS itself. - - - - - - - - - - - - - - - - -Eastlake & Gudmundsson Standards Track [Page 7] - -RFC 2538 Storing Certificates in the DNS March 1999 - - -References - - RFC 1034 Mockapetris, P., "Domain Names - Concepts and Facilities", - STD 13, RFC 1034, November 1987. - - RFC 1035 Mockapetris, P., "Domain Names - Implementation and - Specifications", STD 13, RFC 1035, November 1987. - - RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - RFC 2247 Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. - Sataluri, "Using Domains in LDAP/X.500 Distinguished - Names", RFC 2247, January 1998. - - RFC 2396 Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform - Resource Identifiers (URI): Generic Syntax", RFC 2396, - August 1998. - - RFC 2440 Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, - "OpenPGP Message Format", RFC 2240, November 1998. - - RFC 2434 Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - - RFC 2535 Eastlake, D., "Domain Name System (DNS) Security - Extensions", RFC 2535, March 1999. - - RFC 2459 Housley, R., Ford, W., Polk, W. and D. Solo, "Internet - X.509 Public Key Infrastructure Certificate and CRL - Profile", RFC 2459, January 1999. - - - - - - - - - - - - - - - - - - - -Eastlake & Gudmundsson Standards Track [Page 8] - -RFC 2538 Storing Certificates in the DNS March 1999 - - -Authors' Addresses - - Donald E. Eastlake 3rd - IBM - 65 Shindegan Hill Road - RR#1 - Carmel, NY 10512 USA - - Phone: +1-914-784-7913 (w) - +1-914-276-2668 (h) - Fax: +1-914-784-3833 (w-fax) - EMail: dee3@us.ibm.com - - - Olafur Gudmundsson - TIS Labs at Network Associates - 3060 Washington Rd, Route 97 - Glenwood MD 21738 - - Phone: +1 443-259-2389 - EMail: ogud@tislabs.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake & Gudmundsson Standards Track [Page 9] - -RFC 2538 Storing Certificates in the DNS March 1999 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake & Gudmundsson Standards Track [Page 10] - diff --git a/contrib/bind9/doc/rfc/rfc2539.txt b/contrib/bind9/doc/rfc/rfc2539.txt deleted file mode 100644 index cf32523d9fa1..000000000000 --- a/contrib/bind9/doc/rfc/rfc2539.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -Network Working Group D. Eastlake -Request for Comments: 2539 IBM -Category: Standards Track March 1999 - - - Storage of Diffie-Hellman Keys in the Domain Name System (DNS) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - -Abstract - - A standard method for storing Diffie-Hellman keys in the Domain Name - System is described which utilizes DNS KEY resource records. - -Acknowledgements - - Part of the format for Diffie-Hellman keys and the description - thereof was taken from a work in progress by: - - Ashar Aziz <ashar.aziz@eng.sun.com> - Tom Markson <markson@incog.com> - Hemma Prafullchandra <hemma@eng.sun.com> - - In addition, the following person provided useful comments that have - been incorporated: - - Ran Atkinson <rja@inet.org> - Thomas Narten <narten@raleigh.ibm.com> - - - - - - - - - - - - - -Eastlake Standards Track [Page 1] - -RFC 2539 Diffie-Hellman Keys in the DNS March 1999 - - -Table of Contents - - Abstract...................................................1 - Acknowledgements...........................................1 - 1. Introduction............................................2 - 1.1 About This Document....................................2 - 1.2 About Diffie-Hellman...................................2 - 2. Diffie-Hellman KEY Resource Records.....................3 - 3. Performance Considerations..............................4 - 4. IANA Considerations.....................................4 - 5. Security Considerations.................................4 - References.................................................5 - Author's Address...........................................5 - Appendix A: Well known prime/generator pairs...............6 - A.1. Well-Known Group 1: A 768 bit prime..................6 - A.2. Well-Known Group 2: A 1024 bit prime.................6 - Full Copyright Notice......................................7 - -1. Introduction - - The Domain Name System (DNS) is the current global hierarchical - replicated distributed database system for Internet addressing, mail - proxy, and similar information. The DNS has been extended to include - digital signatures and cryptographic keys as described in [RFC 2535]. - Thus the DNS can now be used for secure key distribution. - -1.1 About This Document - - This document describes how to store Diffie-Hellman keys in the DNS. - Familiarity with the Diffie-Hellman key exchange algorithm is assumed - [Schneier]. - -1.2 About Diffie-Hellman - - Diffie-Hellman requires two parties to interact to derive keying - information which can then be used for authentication. Since DNS SIG - RRs are primarily used as stored authenticators of zone information - for many different resolvers, no Diffie-Hellman algorithm SIG RR is - defined. For example, assume that two parties have local secrets "i" - and "j". Assume they each respectively calculate X and Y as follows: - - X = g**i ( mod p ) Y = g**j ( mod p ) - - They exchange these quantities and then each calculates a Z as - follows: - - Zi = Y**i ( mod p ) Zj = X**j ( mod p ) - - - - -Eastlake Standards Track [Page 2] - -RFC 2539 Diffie-Hellman Keys in the DNS March 1999 - - - shared secret between the two parties that an adversary who does not - know i or j will not be able to learn from the exchanged messages - (unless the adversary can derive i or j by performing a discrete - logarithm mod p which is hard for strong p and g). - - The private key for each party is their secret i (or j). The public - key is the pair p and g, which must be the same for the parties, and - their individual X (or Y). - -2. Diffie-Hellman KEY Resource Records - - Diffie-Hellman keys are stored in the DNS as KEY RRs using algorithm - number 2. The structure of the RDATA portion of this RR is as shown - below. The first 4 octets, including the flags, protocol, and - algorithm fields are common to all KEY RRs as described in [RFC - 2535]. The remainder, from prime length through public value is the - "public key" part of the KEY RR. The period of key validity is not in - the KEY RR but is indicated by the SIG RR(s) which signs and - authenticates the KEY RR(s) at that domain name. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | KEY flags | protocol | algorithm=2 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | prime length (or flag) | prime (p) (or special) / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / prime (p) (variable length) | generator length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | generator (g) (variable length) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | public value length | public value (variable length)/ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / public value (g^i mod p) (variable length) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Prime length is length of the Diffie-Hellman prime (p) in bytes if it - is 16 or greater. Prime contains the binary representation of the - Diffie-Hellman prime with most significant byte first (i.e., in - network order). If "prime length" field is 1 or 2, then the "prime" - field is actually an unsigned index into a table of 65,536 - prime/generator pairs and the generator length SHOULD be zero. See - Appedix A for defined table entries and Section 4 for information on - allocating additional table entries. The meaning of a zero or 3 - through 15 value for "prime length" is reserved. - - - - - - -Eastlake Standards Track [Page 3] - -RFC 2539 Diffie-Hellman Keys in the DNS March 1999 - - - Generator length is the length of the generator (g) in bytes. - Generator is the binary representation of generator with most - significant byte first. PublicValueLen is the Length of the Public - Value (g**i (mod p)) in bytes. PublicValue is the binary - representation of the DH public value with most significant byte - first. - - The corresponding algorithm=2 SIG resource record is not used so no - format for it is defined. - -3. Performance Considerations - - Current DNS implementations are optimized for small transfers, - typically less than 512 bytes including overhead. While larger - transfers will perform correctly and work is underway to make larger - transfers more efficient, it is still advisable to make reasonable - efforts to minimize the size of KEY RR sets stored within the DNS - consistent with adequate security. Keep in mind that in a secure - zone, an authenticating SIG RR will also be returned. - -4. IANA Considerations - - Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires - an IETF consensus. - - Well known prime/generator pairs number 0x0000 through 0x07FF can - only be assigned by an IETF standards action and this Proposed - Standard assigns 0x0001 through 0x0002. Pairs number 0s0800 through - 0xBFFF can be assigned based on RFC documentation. Pairs number - 0xC000 through 0xFFFF are available for private use and are not - centrally coordinated. Use of such private pairs outside of a closed - environment may result in conflicts. - -5. Security Considerations - - Many of the general security consideration in [RFC 2535] apply. Keys - retrieved from the DNS should not be trusted unless (1) they have - been securely obtained from a secure resolver or independently - verified by the user and (2) this secure resolver and secure - obtainment or independent verification conform to security policies - acceptable to the user. As with all cryptographic algorithms, - evaluating the necessary strength of the key is important and - dependent on local policy. - - In addition, the usual Diffie-Hellman key strength considerations - apply. (p-1)/2 should also be prime, g should be primitive mod p, p - should be "large", etc. [Schneier] - - - - -Eastlake Standards Track [Page 4] - -RFC 2539 Diffie-Hellman Keys in the DNS March 1999 - - -References - - [RFC 1034] Mockapetris, P., "Domain Names - Concepts and - Facilities", STD 13, RFC 1034, November 1987. - - [RFC 1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [Schneier] Bruce Schneier, "Applied Cryptography: Protocols, - Algorithms, and Source Code in C", 1996, John Wiley and - Sons - -Author's Address - - Donald E. Eastlake 3rd - IBM - 65 Shindegan Hill Road, RR #1 - Carmel, NY 10512 - - Phone: +1-914-276-2668(h) - +1-914-784-7913(w) - Fax: +1-914-784-3833(w) - EMail: dee3@us.ibm.com - - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake Standards Track [Page 5] - -RFC 2539 Diffie-Hellman Keys in the DNS March 1999 - - -Appendix A: Well known prime/generator pairs - - These numbers are copied from the IPSEC effort where the derivation - of these values is more fully explained and additional information is - available. Richard Schroeppel performed all the mathematical and - computational work for this appendix. - -A.1. Well-Known Group 1: A 768 bit prime - - The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its - decimal value is - 155251809230070893513091813125848175563133404943451431320235 - 119490296623994910210725866945387659164244291000768028886422 - 915080371891804634263272761303128298374438082089019628850917 - 0691316593175367469551763119843371637221007210577919 - - Prime modulus: Length (32 bit words): 24, Data (hex): - FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 - 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD - EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 - E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF - - Generator: Length (32 bit words): 1, Data (hex): 2 - -A.2. Well-Known Group 2: A 1024 bit prime - - The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. - Its decimal value is - 179769313486231590770839156793787453197860296048756011706444 - 423684197180216158519368947833795864925541502180565485980503 - 646440548199239100050792877003355816639229553136239076508735 - 759914822574862575007425302077447712589550957937778424442426 - 617334727629299387668709205606050270810842907692932019128194 - 467627007 - - Prime modulus: Length (32 bit words): 32, Data (hex): - FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 - 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD - EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 - E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED - EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 - FFFFFFFF FFFFFFFF - - Generator: Length (32 bit words): 1, Data (hex): 2 - - - - - - - -Eastlake Standards Track [Page 6] - -RFC 2539 Diffie-Hellman Keys in the DNS March 1999 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake Standards Track [Page 7] - diff --git a/contrib/bind9/doc/rfc/rfc2540.txt b/contrib/bind9/doc/rfc/rfc2540.txt deleted file mode 100644 index 631480618867..000000000000 --- a/contrib/bind9/doc/rfc/rfc2540.txt +++ /dev/null @@ -1,339 +0,0 @@ - - - - - - -Network Working Group D. Eastlake -Request for Comments: 2540 IBM -Category: Experimental March 1999 - - - Detached Domain Name System (DNS) Information - -Status of this Memo - - This memo defines an Experimental Protocol for the Internet - community. It does not specify an Internet standard of any kind. - Discussion and suggestions for improvement are requested. - Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - -Abstract - - A standard format is defined for representing detached DNS - information. This is anticipated to be of use for storing - information retrieved from the Domain Name System (DNS), including - security information, in archival contexts or contexts not connected - to the Internet. - -Table of Contents - - Abstract...................................................1 - 1. Introduction............................................1 - 2. General Format..........................................2 - 2.1 Binary Format..........................................3 - 2.2. Text Format...........................................4 - 3. Usage Example...........................................4 - 4. IANA Considerations.....................................4 - 5. Security Considerations.................................4 - References.................................................5 - Author's Address...........................................5 - Full Copyright Statement...................................6 - -1. Introduction - - The Domain Name System (DNS) is a replicated hierarchical distributed - database system [RFC 1034, 1035] that can provide highly available - service. It provides the operational basis for Internet host name to - address translation, automatic SMTP mail routing, and other basic - Internet functions. The DNS has been extended as described in [RFC - 2535] to permit the general storage of public cryptographic keys in - - - -Eastlake Experimental [Page 1] - -RFC 2540 Detached DNS Information March 1999 - - - the DNS and to enable the authentication of information retrieved - from the DNS though digital signatures. - - The DNS was not originally designed for storage of information - outside of the active zones and authoritative master files that are - part of the connected DNS. However there may be cases where this is - useful, particularly in connection with archived security - information. - -2. General Format - - The formats used for detached Domain Name System (DNS) information - are similar to those used for connected DNS information. The primary - difference is that elements of the connected DNS system (unless they - are an authoritative server for the zone containing the information) - are required to count down the Time To Live (TTL) associated with - each DNS Resource Record (RR) and discard them (possibly fetching a - fresh copy) when the TTL reaches zero. In contrast to this, detached - information may be stored in a off-line file, where it can not be - updated, and perhaps used to authenticate historic data or it might - be received via non-DNS protocols long after it was retrieved from - the DNS. Therefore, it is not practical to count down detached DNS - information TTL and it may be necessary to keep the data beyond the - point where the TTL (which is defined as an unsigned field) would - underflow. To preserve information as to the freshness of this - detached data, it is accompanied by its retrieval time. - - Whatever retrieves the information from the DNS must associate this - retrieval time with it. The retrieval time remains fixed thereafter. - When the current time minus the retrieval time exceeds the TTL for - any particular detached RR, it is no longer a valid copy within the - normal connected DNS scheme. This may make it invalid in context for - some detached purposes as well. If the RR is a SIG (signature) RR it - also has an expiration time. Regardless of the TTL, it and any RRs - it signs can not be considered authenticated after the signature - expiration time. - - - - - - - - - - - - - - - -Eastlake Experimental [Page 2] - -RFC 2540 Detached DNS Information March 1999 - - -2.1 Binary Format - - The standard binary format for detached DNS information is as - follows: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | first retrieval time | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | RR count | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Resource Records (RRs) | - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - | next retrieval time | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | RR count | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Resource Records (RRs) | - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / ... / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | hex 20 | - +-+-+-+-+-+-+-+-+ - - Retrieval time - the time that the immediately following information - was obtained from the connected DNS system. It is an unsigned - number of seconds since the start of 1 January 1970, GMT, - ignoring leap seconds, in network (big-endian) order. Note that - this time can not be before the initial proposal of this - standard. Therefore, the initial byte of an actual retrieval - time, considered as a 32 bit unsigned quantity, would always be - larger than 20 hex. The end of detached DNS information is - indicated by a "retrieval time" field initial byte equal to 0x20. - Use of a "retrieval time" field with a leading unsigned byte of - zero indicates a 64 bit (actually 8 leading zero bits plus a 56 - bit quantity). This 64 bit format will be required when - retrieval time is larger than 0xFFFFFFFF, which is some time in - the year 2106. The meaning of retrieval times with an initial - byte between 0x01 and 0x1F is reserved (see section 5). - Retrieval times will not generally be 32 bit aligned with respect - to each other due to the variable length nature of RRs. - - RR count - an unsigned integer number (with bytes in network order) - of following resource records retrieved at the preceding - retrieval time. - - - - - -Eastlake Experimental [Page 3] - -RFC 2540 Detached DNS Information March 1999 - - - Resource Records - the actual data which is in the same format as if - it were being transmitted in a DNS response. In particular, name - compression via pointers is permitted with the origin at the - beginning of the particular detached information data section, - just after the RR count. - -2.2. Text Format - - The standard text format for detached DNS information is as - prescribed for zone master files [RFC 1035] except that the $INCLUDE - control entry is prohibited and the new $DATE entry is required - (unless the information set is empty). $DATE is followed by the date - and time that the following information was obtained from the DNS - system as described for retrieval time in section 2.1 above. It is - in the text format YYYYMMDDHHMMSS where YYYY is the year (which may - be more than four digits to cover years after 9999), the first MM is - the month number (01-12), DD is the day of the month (01-31), HH is - the hour in 24 hours notation (00-23), the second MM is the minute - (00-59), and SS is the second (00-59). Thus a $DATE must appear - before the first RR and at every change in retrieval time through the - detached information. - -3. Usage Example - - A document might be authenticated by a key retrieved from the DNS in - a KEY resource record (RR). To later prove the authenticity of this - document, it would be desirable to preserve the KEY RR for that - public key, the SIG RR signing that KEY RR, the KEY RR for the key - used to authenticate that SIG, and so on through SIG and KEY RRs - until a well known trusted key is reached, perhaps the key for the - DNS root or some third party authentication service. (In some cases - these KEY RRs will actually be sets of KEY RRs with the same owner - and class because SIGs actually sign such record sets.) - - This information could be preserved as a set of detached DNS - information blocks. - -4. IANA Considerations - - Allocation of meanings to retrieval time fields with a initial byte - of between 0x01 and 0x1F requires an IETF consensus. - -5. Security Considerations - - The entirety of this document concerns a means to represent detached - DNS information. Such detached resource records may be security - relevant and/or secured information as described in [RFC 2535]. The - detached format provides no overall security for sets of detached - - - -Eastlake Experimental [Page 4] - -RFC 2540 Detached DNS Information March 1999 - - - information or for the association between retrieval time and - information. This can be provided by wrapping the detached - information format with some other form of signature. However, if - the detached information is accompanied by SIG RRs, its validity - period is indicated in those SIG RRs so the retrieval time might be - of secondary importance. - -References - - [RFC 1034] Mockapetris, P., "Domain Names - Concepts and - Facilities", STD 13, RFC 1034, November 1987. - - [RFC 1035] Mockapetris, P., " Domain Names - Implementation and - Specifications", STD 13, RFC 1035, November 1987. - - [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - -Author's Address - - Donald E. Eastlake 3rd - IBM - 65 Shindegan Hill Road, RR #1 - Carmel, NY 10512 - - Phone: +1-914-276-2668(h) - +1-914-784-7913(w) - Fax: +1-914-784-3833(w) - EMail: dee3@us.ibm.com - - - - - - - - - - - - - - - - - - - - - - -Eastlake Experimental [Page 5] - -RFC 2540 Detached DNS Information March 1999 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake Experimental [Page 6] - diff --git a/contrib/bind9/doc/rfc/rfc2541.txt b/contrib/bind9/doc/rfc/rfc2541.txt deleted file mode 100644 index a62ed2b48677..000000000000 --- a/contrib/bind9/doc/rfc/rfc2541.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -Network Working Group D. Eastlake -Request for Comments: 2541 IBM -Category: Informational March 1999 - - - DNS Security Operational Considerations - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - -Abstract - - Secure DNS is based on cryptographic techniques. A necessary part of - the strength of these techniques is careful attention to the - operational aspects of key and signature generation, lifetime, size, - and storage. In addition, special attention must be paid to the - security of the high level zones, particularly the root zone. This - document discusses these operational aspects for keys and signatures - used in connection with the KEY and SIG DNS resource records. - -Acknowledgments - - The contributions and suggestions of the following persons (in - alphabetic order) are gratefully acknowledged: - - John Gilmore - Olafur Gudmundsson - Charlie Kaufman - - - - - - - - - - - - - - - - -Eastlake Informational [Page 1] - -RFC 2541 DNS Security Operational Considerations March 1999 - - -Table of Contents - - Abstract...................................................1 - Acknowledgments............................................1 - 1. Introduction............................................2 - 2. Public/Private Key Generation...........................2 - 3. Public/Private Key Lifetimes............................2 - 4. Public/Private Key Size Considerations..................3 - 4.1 RSA Key Sizes..........................................3 - 4.2 DSS Key Sizes..........................................4 - 5. Private Key Storage.....................................4 - 6. High Level Zones, The Root Zone, and The Meta-Root Key..5 - 7. Security Considerations.................................5 - References.................................................6 - Author's Address...........................................6 - Full Copyright Statement...................................7 - -1. Introduction - - This document describes operational considerations for the - generation, lifetime, size, and storage of DNS cryptographic keys and - signatures for use in the KEY and SIG resource records [RFC 2535]. - Particular attention is paid to high level zones and the root zone. - -2. Public/Private Key Generation - - Careful generation of all keys is a sometimes overlooked but - absolutely essential element in any cryptographically secure system. - The strongest algorithms used with the longest keys are still of no - use if an adversary can guess enough to lower the size of the likely - key space so that it can be exhaustively searched. Technical - suggestions for the generation of random keys will be found in [RFC - 1750]. - - Long term keys are particularly sensitive as they will represent a - more valuable target and be subject to attack for a longer time than - short period keys. It is strongly recommended that long term key - generation occur off-line in a manner isolated from the network via - an air gap or, at a minimum, high level secure hardware. - -3. Public/Private Key Lifetimes - - No key should be used forever. The longer a key is in use, the - greater the probability that it will have been compromised through - carelessness, accident, espionage, or cryptanalysis. Furthermore, if - - - - - - -Eastlake Informational [Page 2] - -RFC 2541 DNS Security Operational Considerations March 1999 - - - key rollover is a rare event, there is an increased risk that, when - the time does come to change the key, no one at the site will - remember how to do it or operational problems will have developed in - the key rollover procedures. - - While public key lifetime is a matter of local policy, these - considerations imply that, unless there are extraordinary - circumstances, no long term key should have a lifetime significantly - over four years. In fact, a reasonable guideline for long term keys - that are kept off-line and carefully guarded is a 13 month lifetime - with the intent that they be replaced every year. A reasonable - maximum lifetime for keys that are used for transaction security or - the like and are kept on line is 36 days with the intent that they be - replaced monthly or more often. In many cases, a key lifetime of - somewhat over a day may be reasonable. - - On the other hand, public keys with too short a lifetime can lead to - excessive resource consumption in re-signing data and retrieving - fresh information because cached information becomes stale. In the - Internet environment, almost all public keys should have lifetimes no - shorter than three minutes, which is a reasonable estimate of maximum - packet delay even in unusual circumstances. - -4. Public/Private Key Size Considerations - - There are a number of factors that effect public key size choice for - use in the DNS security extension. Unfortunately, these factors - usually do not all point in the same direction. Choice of zone key - size should generally be made by the zone administrator depending on - their local conditions. - - For most schemes, larger keys are more secure but slower. In - addition, larger keys increase the size of the KEY and SIG RRs. This - increases the chance of DNS UDP packet overflow and the possible - necessity for using higher overhead TCP in responses. - -4.1 RSA Key Sizes - - Given a small public exponent, verification (the most common - operation) for the MD5/RSA algorithm will vary roughly with the - square of the modulus length, signing will vary with the cube of the - modulus length, and key generation (the least common operation) will - vary with the fourth power of the modulus length. The current best - algorithms for factoring a modulus and breaking RSA security vary - roughly with the 1.6 power of the modulus itself. Thus going from a - 640 bit modulus to a 1280 bit modulus only increases the verification - time by a factor of 4 but may increase the work factor of breaking - the key by over 2^900. - - - -Eastlake Informational [Page 3] - -RFC 2541 DNS Security Operational Considerations March 1999 - - - The recommended minimum RSA algorithm modulus size is 704 bits which - is believed by the author to be secure at this time. But high level - zones in the DNS tree may wish to set a higher minimum, perhaps 1000 - bits, for security reasons. (Since the United States National - Security Agency generally permits export of encryption systems using - an RSA modulus of up to 512 bits, use of that small a modulus, i.e. - n, must be considered weak.) - - For an RSA key used only to secure data and not to secure other keys, - 704 bits should be adequate at this time. - -4.2 DSS Key Sizes - - DSS keys are probably roughly as strong as an RSA key of the same - length but DSS signatures are significantly smaller. - -5. Private Key Storage - - It is recommended that, where possible, zone private keys and the - zone file master copy be kept and used in off-line, non-network - connected, physically secure machines only. Periodically an - application can be run to add authentication to a zone by adding SIG - and NXT RRs and adding no-key type KEY RRs for subzones/algorithms - where a real KEY RR for the subzone with that algorithm is not - provided. Then the augmented file can be transferred, perhaps by - sneaker-net, to the networked zone primary server machine. - - The idea is to have a one way information flow to the network to - avoid the possibility of tampering from the network. Keeping the - zone master file on-line on the network and simply cycling it through - an off-line signer does not do this. The on-line version could still - be tampered with if the host it resides on is compromised. For - maximum security, the master copy of the zone file should be off net - and should not be updated based on an unsecured network mediated - communication. - - This is not possible if the zone is to be dynamically updated - securely [RFC 2137]. At least a private key capable of updating the - SOA and NXT chain must be on line in that case. - - Secure resolvers must be configured with some trusted on-line public - key information (or a secure path to such a resolver) or they will be - unable to authenticate. Although on line, this public key - information must be protected or it could be altered so that spoofed - DNS data would appear authentic. - - - - - - -Eastlake Informational [Page 4] - -RFC 2541 DNS Security Operational Considerations March 1999 - - - Non-zone private keys, such as host or user keys, generally have to - be kept on line to be used for real-time purposes such as DNS - transaction security. - -6. High Level Zones, The Root Zone, and The Meta-Root Key - - Higher level zones are generally more sensitive than lower level - zones. Anyone controlling or breaking the security of a zone thereby - obtains authority over all of its subdomains (except in the case of - resolvers that have locally configured the public key of a - subdomain). Therefore, extra care should be taken with high level - zones and strong keys used. - - The root zone is the most critical of all zones. Someone controlling - or compromising the security of the root zone would control the - entire DNS name space of all resolvers using that root zone (except - in the case of resolvers that have locally configured the public key - of a subdomain). Therefore, the utmost care must be taken in the - securing of the root zone. The strongest and most carefully handled - keys should be used. The root zone private key should always be kept - off line. - - Many resolvers will start at a root server for their access to and - authentication of DNS data. Securely updating an enormous population - of resolvers around the world will be extremely difficult. Yet the - guidelines in section 3 above would imply that the root zone private - key be changed annually or more often and if it were staticly - configured at all these resolvers, it would have to be updated when - changed. - - To permit relatively frequent change to the root zone key yet - minimize exposure of the ultimate key of the DNS tree, there will be - a "meta-root" key used very rarely and then only to sign a sequence - of regular root key RRsets with overlapping time validity periods - that are to be rolled out. The root zone contains the meta-root and - current regular root KEY RR(s) signed by SIG RRs under both the - meta-root and other root private key(s) themselves. - - The utmost security in the storage and use of the meta-root key is - essential. The exact techniques are precautions to be used are - beyond the scope of this document. Because of its special position, - it may be best to continue with the same meta-root key for an - extended period of time such as ten to fifteen years. - -7. Security Considerations - - The entirety of this document is concerned with operational - considerations of public/private key pair DNS Security. - - - -Eastlake Informational [Page 5] - -RFC 2541 DNS Security Operational Considerations March 1999 - - -References - - [RFC 1034] Mockapetris, P., "Domain Names - Concepts and - Facilities", STD 13, RFC 1034, November 1987. - - [RFC 1035] Mockapetris, P., "Domain Names - Implementation and - Specifications", STD 13, RFC 1035, November 1987. - - [RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness - Requirements for Security", RFC 1750, December 1994. - - [RFC 2065] Eastlake, D. and C. Kaufman, "Domain Name System - Security Extensions", RFC 2065, January 1997. - - [RFC 2137] Eastlake, D., "Secure Domain Name System Dynamic - Update", RFC 2137, April 1997. - - [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RSA FAQ] RSADSI Frequently Asked Questions periodic posting. - -Author's Address - - Donald E. Eastlake 3rd - IBM - 65 Shindegan Hill Road, RR #1 - Carmel, NY 10512 - - Phone: +1-914-276-2668(h) - +1-914-784-7913(w) - Fax: +1-914-784-3833(w) - EMail: dee3@us.ibm.com - - - - - - - - - - - - - - - - - - -Eastlake Informational [Page 6] - -RFC 2541 DNS Security Operational Considerations March 1999 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake Informational [Page 7] - diff --git a/contrib/bind9/doc/rfc/rfc2553.txt b/contrib/bind9/doc/rfc/rfc2553.txt deleted file mode 100644 index 6989bf3045e5..000000000000 --- a/contrib/bind9/doc/rfc/rfc2553.txt +++ /dev/null @@ -1,2299 +0,0 @@ - - - - - - -Network Working Group R. Gilligan -Request for Comments: 2553 FreeGate -Obsoletes: 2133 S. Thomson -Category: Informational Bellcore - J. Bound - Compaq - W. Stevens - Consultant - March 1999 - - - Basic Socket Interface Extensions for IPv6 - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - -Abstract - - The de facto standard application program interface (API) for TCP/IP - applications is the "sockets" interface. Although this API was - developed for Unix in the early 1980s it has also been implemented on - a wide variety of non-Unix systems. TCP/IP applications written - using the sockets API have in the past enjoyed a high degree of - portability and we would like the same portability with IPv6 - applications. But changes are required to the sockets API to support - IPv6 and this memo describes these changes. These include a new - socket address structure to carry IPv6 addresses, new address - conversion functions, and some new socket options. These extensions - are designed to provide access to the basic IPv6 features required by - TCP and UDP applications, including multicasting, while introducing a - minimum of change into the system and providing complete - compatibility for existing IPv4 applications. Additional extensions - for advanced IPv6 features (raw sockets and access to the IPv6 - extension headers) are defined in another document [4]. - - - - - - - - - - -Gilligan, et. al. Informational [Page 1] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - -Table of Contents - - 1. Introduction.................................................3 - 2. Design Considerations........................................3 - 2.1 What Needs to be Changed....................................4 - 2.2 Data Types..................................................5 - 2.3 Headers.....................................................5 - 2.4 Structures..................................................5 - 3. Socket Interface.............................................6 - 3.1 IPv6 Address Family and Protocol Family.....................6 - 3.2 IPv6 Address Structure......................................6 - 3.3 Socket Address Structure for 4.3BSD-Based Systems...........7 - 3.4 Socket Address Structure for 4.4BSD-Based Systems...........8 - 3.5 The Socket Functions........................................9 - 3.6 Compatibility with IPv4 Applications.......................10 - 3.7 Compatibility with IPv4 Nodes..............................10 - 3.8 IPv6 Wildcard Address......................................11 - 3.9 IPv6 Loopback Address......................................12 - 3.10 Portability Additions.....................................13 - 4. Interface Identification....................................16 - 4.1 Name-to-Index..............................................16 - 4.2 Index-to-Name..............................................17 - 4.3 Return All Interface Names and Indexes.....................17 - 4.4 Free Memory................................................18 - 5. Socket Options..............................................18 - 5.1 Unicast Hop Limit..........................................18 - 5.2 Sending and Receiving Multicast Packets....................19 - 6. Library Functions...........................................21 - 6.1 Nodename-to-Address Translation............................21 - 6.2 Address-To-Nodename Translation............................24 - 6.3 Freeing memory for getipnodebyname and getipnodebyaddr.....26 - 6.4 Protocol-Independent Nodename and Service Name Translation.26 - 6.5 Socket Address Structure to Nodename and Service Name......29 - 6.6 Address Conversion Functions...............................31 - 6.7 Address Testing Macros.....................................32 - 7. Summary of New Definitions..................................33 - 8. Security Considerations.....................................35 - 9. Year 2000 Considerations....................................35 - Changes From RFC 2133..........................................35 - Acknowledgments................................................38 - References.....................................................39 - Authors' Addresses.............................................40 - Full Copyright Statement.......................................41 - - - - - - - - -Gilligan, et. al. Informational [Page 2] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - -1. Introduction - - While IPv4 addresses are 32 bits long, IPv6 interfaces are identified - by 128-bit addresses. The socket interface makes the size of an IP - address quite visible to an application; virtually all TCP/IP - applications for BSD-based systems have knowledge of the size of an - IP address. Those parts of the API that expose the addresses must be - changed to accommodate the larger IPv6 address size. IPv6 also - introduces new features (e.g., traffic class and flowlabel), some of - which must be made visible to applications via the API. This memo - defines a set of extensions to the socket interface to support the - larger address size and new features of IPv6. - -2. Design Considerations - - There are a number of important considerations in designing changes - to this well-worn API: - - - The API changes should provide both source and binary - compatibility for programs written to the original API. That - is, existing program binaries should continue to operate when - run on a system supporting the new API. In addition, existing - applications that are re-compiled and run on a system supporting - the new API should continue to operate. Simply put, the API - changes for IPv6 should not break existing programs. An - additonal mechanism for implementations to verify this is to - verify the new symbols are protected by Feature Test Macros as - described in IEEE Std 1003.1. (Such Feature Test Macros are not - defined by this RFC.) - - - The changes to the API should be as small as possible in order - to simplify the task of converting existing IPv4 applications to - IPv6. - - - Where possible, applications should be able to use this API to - interoperate with both IPv6 and IPv4 hosts. Applications should - not need to know which type of host they are communicating with. - - - IPv6 addresses carried in data structures should be 64-bit - aligned. This is necessary in order to obtain optimum - performance on 64-bit machine architectures. - - Because of the importance of providing IPv4 compatibility in the API, - these extensions are explicitly designed to operate on machines that - provide complete support for both IPv4 and IPv6. A subset of this - API could probably be designed for operation on systems that support - only IPv6. However, this is not addressed in this memo. - - - - -Gilligan, et. al. Informational [Page 3] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - -2.1 What Needs to be Changed - - The socket interface API consists of a few distinct components: - - - Core socket functions. - - - Address data structures. - - - Name-to-address translation functions. - - - Address conversion functions. - - The core socket functions -- those functions that deal with such - things as setting up and tearing down TCP connections, and sending - and receiving UDP packets -- were designed to be transport - independent. Where protocol addresses are passed as function - arguments, they are carried via opaque pointers. A protocol-specific - address data structure is defined for each protocol that the socket - functions support. Applications must cast pointers to these - protocol-specific address structures into pointers to the generic - "sockaddr" address structure when using the socket functions. These - functions need not change for IPv6, but a new IPv6-specific address - data structure is needed. - - The "sockaddr_in" structure is the protocol-specific data structure - for IPv4. This data structure actually includes 8-octets of unused - space, and it is tempting to try to use this space to adapt the - sockaddr_in structure to IPv6. Unfortunately, the sockaddr_in - structure is not large enough to hold the 16-octet IPv6 address as - well as the other information (address family and port number) that - is needed. So a new address data structure must be defined for IPv6. - - IPv6 addresses are scoped [2] so they could be link-local, site, - organization, global, or other scopes at this time undefined. To - support applications that want to be able to identify a set of - interfaces for a specific scope, the IPv6 sockaddr_in structure must - support a field that can be used by an implementation to identify a - set of interfaces identifying the scope for an IPv6 address. - - The name-to-address translation functions in the socket interface are - gethostbyname() and gethostbyaddr(). These are left as is and new - functions are defined to support IPv4 and IPv6. Additionally, the - POSIX 1003.g draft [3] specifies a new nodename-to-address - translation function which is protocol independent. This function - can also be used with IPv4 and IPv6. - - - - - - -Gilligan, et. al. Informational [Page 4] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - The address conversion functions -- inet_ntoa() and inet_addr() -- - convert IPv4 addresses between binary and printable form. These - functions are quite specific to 32-bit IPv4 addresses. We have - designed two analogous functions that convert both IPv4 and IPv6 - addresses, and carry an address type parameter so that they can be - extended to other protocol families as well. - - Finally, a few miscellaneous features are needed to support IPv6. - New interfaces are needed to support the IPv6 traffic class, flow - label, and hop limit header fields. New socket options are needed to - control the sending and receiving of IPv6 multicast packets. - - The socket interface will be enhanced in the future to provide access - to other IPv6 features. These extensions are described in [4]. - -2.2 Data Types - - The data types of the structure elements given in this memo are - intended to be examples, not absolute requirements. Whenever - possible, data types from Draft 6.6 (March 1997) of POSIX 1003.1g are - used: uintN_t means an unsigned integer of exactly N bits (e.g., - uint16_t). We also assume the argument data types from 1003.1g when - possible (e.g., the final argument to setsockopt() is a size_t - value). Whenever buffer sizes are specified, the POSIX 1003.1 size_t - data type is used (e.g., the two length arguments to getnameinfo()). - -2.3 Headers - - When function prototypes and structures are shown we show the headers - that must be #included to cause that item to be defined. - -2.4 Structures - - When structures are described the members shown are the ones that - must appear in an implementation. Additional, nonstandard members - may also be defined by an implementation. As an additional - precaution nonstandard members could be verified by Feature Test - Macros as described in IEEE Std 1003.1. (Such Feature Test Macros - are not defined by this RFC.) - - The ordering shown for the members of a structure is the recommended - ordering, given alignment considerations of multibyte members, but an - implementation may order the members differently. - - - - - - - - -Gilligan, et. al. Informational [Page 5] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - -3. Socket Interface - - This section specifies the socket interface changes for IPv6. - -3.1 IPv6 Address Family and Protocol Family - - A new address family name, AF_INET6, is defined in <sys/socket.h>. - The AF_INET6 definition distinguishes between the original - sockaddr_in address data structure, and the new sockaddr_in6 data - structure. - - A new protocol family name, PF_INET6, is defined in <sys/socket.h>. - Like most of the other protocol family names, this will usually be - defined to have the same value as the corresponding address family - name: - - #define PF_INET6 AF_INET6 - - The PF_INET6 is used in the first argument to the socket() function - to indicate that an IPv6 socket is being created. - -3.2 IPv6 Address Structure - - A new in6_addr structure holds a single IPv6 address and is defined - as a result of including <netinet/in.h>: - - struct in6_addr { - uint8_t s6_addr[16]; /* IPv6 address */ - }; - - This data structure contains an array of sixteen 8-bit elements, - which make up one 128-bit IPv6 address. The IPv6 address is stored - in network byte order. - - The structure in6_addr above is usually implemented with an embedded - union with extra fields that force the desired alignment level in a - manner similar to BSD implementations of "struct in_addr". Those - additional implementation details are omitted here for simplicity. - - An example is as follows: - - - - - - - - - - - -Gilligan, et. al. Informational [Page 6] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - struct in6_addr { - union { - uint8_t _S6_u8[16]; - uint32_t _S6_u32[4]; - uint64_t _S6_u64[2]; - } _S6_un; - }; - #define s6_addr _S6_un._S6_u8 - -3.3 Socket Address Structure for 4.3BSD-Based Systems - - In the socket interface, a different protocol-specific data structure - is defined to carry the addresses for each protocol suite. Each - protocol- specific data structure is designed so it can be cast into a - protocol- independent data structure -- the "sockaddr" structure. - Each has a "family" field that overlays the "sa_family" of the - sockaddr data structure. This field identifies the type of the data - structure. - - The sockaddr_in structure is the protocol-specific address data - structure for IPv4. It is used to pass addresses between applications - and the system in the socket functions. The following sockaddr_in6 - structure holds IPv6 addresses and is defined as a result of including - the <netinet/in.h> header: - -struct sockaddr_in6 { - sa_family_t sin6_family; /* AF_INET6 */ - in_port_t sin6_port; /* transport layer port # */ - uint32_t sin6_flowinfo; /* IPv6 traffic class & flow info */ - struct in6_addr sin6_addr; /* IPv6 address */ - uint32_t sin6_scope_id; /* set of interfaces for a scope */ -}; - - This structure is designed to be compatible with the sockaddr data - structure used in the 4.3BSD release. - - The sin6_family field identifies this as a sockaddr_in6 structure. - This field overlays the sa_family field when the buffer is cast to a - sockaddr data structure. The value of this field must be AF_INET6. - - The sin6_port field contains the 16-bit UDP or TCP port number. This - field is used in the same way as the sin_port field of the - sockaddr_in structure. The port number is stored in network byte - order. - - - - - - - -Gilligan, et. al. Informational [Page 7] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - The sin6_flowinfo field is a 32-bit field that contains two pieces of - information: the traffic class and the flow label. The contents and - interpretation of this member is specified in [1]. The sin6_flowinfo - field SHOULD be set to zero by an implementation prior to using the - sockaddr_in6 structure by an application on receive operations. - - The sin6_addr field is a single in6_addr structure (defined in the - previous section). This field holds one 128-bit IPv6 address. The - address is stored in network byte order. - - The ordering of elements in this structure is specifically designed - so that when sin6_addr field is aligned on a 64-bit boundary, the - start of the structure will also be aligned on a 64-bit boundary. - This is done for optimum performance on 64-bit architectures. - - The sin6_scope_id field is a 32-bit integer that identifies a set of - interfaces as appropriate for the scope of the address carried in the - sin6_addr field. For a link scope sin6_addr sin6_scope_id would be - an interface index. For a site scope sin6_addr, sin6_scope_id would - be a site identifier. The mapping of sin6_scope_id to an interface - or set of interfaces is left to implementation and future - specifications on the subject of site identifiers. - - Notice that the sockaddr_in6 structure will normally be larger than - the generic sockaddr structure. On many existing implementations the - sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both - being 16 bytes. Any existing code that makes this assumption needs - to be examined carefully when converting to IPv6. - -3.4 Socket Address Structure for 4.4BSD-Based Systems - - The 4.4BSD release includes a small, but incompatible change to the - socket interface. The "sa_family" field of the sockaddr data - structure was changed from a 16-bit value to an 8-bit value, and the - space saved used to hold a length field, named "sa_len". The - sockaddr_in6 data structure given in the previous section cannot be - correctly cast into the newer sockaddr data structure. For this - reason, the following alternative IPv6 address data structure is - provided to be used on systems based on 4.4BSD. It is defined as a - result of including the <netinet/in.h> header. - - - - - - - - - - - -Gilligan, et. al. Informational [Page 8] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - -struct sockaddr_in6 { - uint8_t sin6_len; /* length of this struct */ - sa_family_t sin6_family; /* AF_INET6 */ - in_port_t sin6_port; /* transport layer port # */ - uint32_t sin6_flowinfo; /* IPv6 flow information */ - struct in6_addr sin6_addr; /* IPv6 address */ - uint32_t sin6_scope_id; /* set of interfaces for a scope */ -}; - - The only differences between this data structure and the 4.3BSD - variant are the inclusion of the length field, and the change of the - family field to a 8-bit data type. The definitions of all the other - fields are identical to the structure defined in the previous - section. - - Systems that provide this version of the sockaddr_in6 data structure - must also declare SIN6_LEN as a result of including the - <netinet/in.h> header. This macro allows applications to determine - whether they are being built on a system that supports the 4.3BSD or - 4.4BSD variants of the data structure. - -3.5 The Socket Functions - - Applications call the socket() function to create a socket descriptor - that represents a communication endpoint. The arguments to the - socket() function tell the system which protocol to use, and what - format address structure will be used in subsequent functions. For - example, to create an IPv4/TCP socket, applications make the call: - - s = socket(PF_INET, SOCK_STREAM, 0); - - To create an IPv4/UDP socket, applications make the call: - - s = socket(PF_INET, SOCK_DGRAM, 0); - - Applications may create IPv6/TCP and IPv6/UDP sockets by simply using - the constant PF_INET6 instead of PF_INET in the first argument. For - example, to create an IPv6/TCP socket, applications make the call: - - s = socket(PF_INET6, SOCK_STREAM, 0); - - To create an IPv6/UDP socket, applications make the call: - - s = socket(PF_INET6, SOCK_DGRAM, 0); - - - - - - - -Gilligan, et. al. Informational [Page 9] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - Once the application has created a PF_INET6 socket, it must use the - sockaddr_in6 address structure when passing addresses in to the - system. The functions that the application uses to pass addresses - into the system are: - - bind() - connect() - sendmsg() - sendto() - - The system will use the sockaddr_in6 address structure to return - addresses to applications that are using PF_INET6 sockets. The - functions that return an address from the system to an application - are: - - accept() - recvfrom() - recvmsg() - getpeername() - getsockname() - - No changes to the syntax of the socket functions are needed to - support IPv6, since all of the "address carrying" functions use an - opaque address pointer, and carry an address length as a function - argument. - -3.6 Compatibility with IPv4 Applications - - In order to support the large base of applications using the original - API, system implementations must provide complete source and binary - compatibility with the original API. This means that systems must - continue to support PF_INET sockets and the sockaddr_in address - structure. Applications must be able to create IPv4/TCP and IPv4/UDP - sockets using the PF_INET constant in the socket() function, as - described in the previous section. Applications should be able to - hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP - sockets simultaneously within the same process. - - Applications using the original API should continue to operate as - they did on systems supporting only IPv4. That is, they should - continue to interoperate with IPv4 nodes. - -3.7 Compatibility with IPv4 Nodes - - The API also provides a different type of compatibility: the ability - for IPv6 applications to interoperate with IPv4 applications. This - feature uses the IPv4-mapped IPv6 address format defined in the IPv6 - addressing architecture specification [2]. This address format - - - -Gilligan, et. al. Informational [Page 10] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - allows the IPv4 address of an IPv4 node to be represented as an IPv6 - address. The IPv4 address is encoded into the low-order 32 bits of - the IPv6 address, and the high-order 96 bits hold the fixed prefix - 0:0:0:0:0:FFFF. IPv4- mapped addresses are written as follows: - - ::FFFF:<IPv4-address> - - These addresses can be generated automatically by the - getipnodebyname() function when the specified host has only IPv4 - addresses (as described in Section 6.1). - - Applications may use PF_INET6 sockets to open TCP connections to IPv4 - nodes, or send UDP packets to IPv4 nodes, by simply encoding the - destination's IPv4 address as an IPv4-mapped IPv6 address, and - passing that address, within a sockaddr_in6 structure, in the - connect() or sendto() call. When applications use PF_INET6 sockets - to accept TCP connections from IPv4 nodes, or receive UDP packets - from IPv4 nodes, the system returns the peer's address to the - application in the accept(), recvfrom(), or getpeername() call using - a sockaddr_in6 structure encoded this way. - - Few applications will likely need to know which type of node they are - interoperating with. However, for those applications that do need to - know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.7, is - provided. - -3.8 IPv6 Wildcard Address - - While the bind() function allows applications to select the source IP - address of UDP packets and TCP connections, applications often want - the system to select the source address for them. With IPv4, one - specifies the address as the symbolic constant INADDR_ANY (called the - "wildcard" address) in the bind() call, or simply omits the bind() - entirely. - - Since the IPv6 address type is a structure (struct in6_addr), a - symbolic constant can be used to initialize an IPv6 address variable, - but cannot be used in an assignment. Therefore systems provide the - IPv6 wildcard address in two forms. - - The first version is a global variable named "in6addr_any" that is an - in6_addr structure. The extern declaration for this variable is - defined in <netinet/in.h>: - - extern const struct in6_addr in6addr_any; - - - - - - -Gilligan, et. al. Informational [Page 11] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - Applications use in6addr_any similarly to the way they use INADDR_ANY - in IPv4. For example, to bind a socket to port number 23, but let - the system select the source address, an application could use the - following code: - - struct sockaddr_in6 sin6; - . . . - sin6.sin6_family = AF_INET6; - sin6.sin6_flowinfo = 0; - sin6.sin6_port = htons(23); - sin6.sin6_addr = in6addr_any; /* structure assignment */ - . . . - if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1) - . . . - - The other version is a symbolic constant named IN6ADDR_ANY_INIT and - is defined in <netinet/in.h>. This constant can be used to - initialize an in6_addr structure: - - struct in6_addr anyaddr = IN6ADDR_ANY_INIT; - - Note that this constant can be used ONLY at declaration time. It can - not be used to assign a previously declared in6_addr structure. For - example, the following code will not work: - - /* This is the WRONG way to assign an unspecified address */ - struct sockaddr_in6 sin6; - . . . - sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */ - - Be aware that the IPv4 INADDR_xxx constants are all defined in host - byte order but the IPv6 IN6ADDR_xxx constants and the IPv6 - in6addr_xxx externals are defined in network byte order. - -3.9 IPv6 Loopback Address - - Applications may need to send UDP packets to, or originate TCP - connections to, services residing on the local node. In IPv4, they - can do this by using the constant IPv4 address INADDR_LOOPBACK in - their connect(), sendto(), or sendmsg() call. - - IPv6 also provides a loopback address to contact local TCP and UDP - services. Like the unspecified address, the IPv6 loopback address is - provided in two forms -- a global variable and a symbolic constant. - - - - - - - -Gilligan, et. al. Informational [Page 12] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - The global variable is an in6_addr structure named - "in6addr_loopback." The extern declaration for this variable is - defined in <netinet/in.h>: - - extern const struct in6_addr in6addr_loopback; - - Applications use in6addr_loopback as they would use INADDR_LOOPBACK - in IPv4 applications (but beware of the byte ordering difference - mentioned at the end of the previous section). For example, to open - a TCP connection to the local telnet server, an application could use - the following code: - - struct sockaddr_in6 sin6; - . . . - sin6.sin6_family = AF_INET6; - sin6.sin6_flowinfo = 0; - sin6.sin6_port = htons(23); - sin6.sin6_addr = in6addr_loopback; /* structure assignment */ - . . . - if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1) - . . . - - The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined - in <netinet/in.h>. It can be used at declaration time ONLY; for - example: - - struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT; - - Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment - to a previously declared IPv6 address variable. - -3.10 Portability Additions - - One simple addition to the sockets API that can help application - writers is the "struct sockaddr_storage". This data structure can - simplify writing code portable across multiple address families and - platforms. This data structure is designed with the following goals. - - - It has a large enough implementation specific maximum size to - store the desired set of protocol specific socket address data - structures. Specifically, it is at least large enough to - accommodate sockaddr_in and sockaddr_in6 and possibly other - protocol specific socket addresses too. - - It is aligned at an appropriate boundary so protocol specific - socket address data structure pointers can be cast to it and - access their fields without alignment problems. (e.g. pointers - to sockaddr_in6 and/or sockaddr_in can be cast to it and access - fields without alignment problems). - - - -Gilligan, et. al. Informational [Page 13] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - - It has the initial field(s) isomorphic to the fields of the - "struct sockaddr" data structure on that implementation which - can be used as a discriminants for deriving the protocol in use. - These initial field(s) would on most implementations either be a - single field of type "sa_family_t" (isomorphic to sa_family - field, 16 bits) or two fields of type uint8_t and sa_family_t - respectively, (isomorphic to sa_len and sa_family_t, 8 bits - each). - - An example implementation design of such a data structure would be as - follows. - -/* - * Desired design of maximum size and alignment - */ -#define _SS_MAXSIZE 128 /* Implementation specific max size */ -#define _SS_ALIGNSIZE (sizeof (int64_t)) - /* Implementation specific desired alignment */ -/* - * Definitions used for sockaddr_storage structure paddings design. - */ -#define _SS_PAD1SIZE (_SS_ALIGNSIZE - sizeof (sa_family_t)) -#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+ - _SS_PAD1SIZE + _SS_ALIGNSIZE)) -struct sockaddr_storage { - sa_family_t __ss_family; /* address family */ - /* Following fields are implementation specific */ - char __ss_pad1[_SS_PAD1SIZE]; - /* 6 byte pad, this is to make implementation - /* specific pad up to alignment field that */ - /* follows explicit in the data structure */ - int64_t __ss_align; /* field to force desired structure */ - /* storage alignment */ - char __ss_pad2[_SS_PAD2SIZE]; - /* 112 byte pad to achieve desired size, */ - /* _SS_MAXSIZE value minus size of ss_family */ - /* __ss_pad1, __ss_align fields is 112 */ -}; - - On implementations where sockaddr data structure includes a "sa_len", - field this data structure would look like this: - -/* - * Definitions used for sockaddr_storage structure paddings design. - */ -#define _SS_PAD1SIZE (_SS_ALIGNSIZE - - (sizeof (uint8_t) + sizeof (sa_family_t)) -#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+ - - - -Gilligan, et. al. Informational [Page 14] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - _SS_PAD1SIZE + _SS_ALIGNSIZE)) -struct sockaddr_storage { - uint8_t __ss_len; /* address length */ - sa_family_t __ss_family; /* address family */ - /* Following fields are implementation specific */ - char __ss_pad1[_SS_PAD1SIZE]; - /* 6 byte pad, this is to make implementation - /* specific pad up to alignment field that */ - /* follows explicit in the data structure */ - int64_t __ss_align; /* field to force desired structure */ - /* storage alignment */ - char __ss_pad2[_SS_PAD2SIZE]; - /* 112 byte pad to achieve desired size, */ - /* _SS_MAXSIZE value minus size of ss_len, */ - /* __ss_family, __ss_pad1, __ss_align fields is 112 */ -}; - - The above example implementation illustrates a data structure which - will align on a 64 bit boundary. An implementation specific field - "__ss_align" along "__ss_pad1" is used to force a 64-bit alignment - which covers proper alignment good enough for needs of sockaddr_in6 - (IPv6), sockaddr_in (IPv4) address data structures. The size of - padding fields __ss_pad1 depends on the chosen alignment boundary. - The size of padding field __ss_pad2 depends on the value of overall - size chosen for the total size of the structure. This size and - alignment are represented in the above example by implementation - specific (not required) constants _SS_MAXSIZE (chosen value 128) and - _SS_ALIGNMENT (with chosen value 8). Constants _SS_PAD1SIZE (derived - value 6) and _SS_PAD2SIZE (derived value 112) are also for - illustration and not required. The implementation specific - definitions and structure field names above start with an underscore - to denote implementation private namespace. Portable code is not - expected to access or reference those fields or constants. - - The sockaddr_storage structure solves the problem of declaring - storage for automatic variables which is large enough and aligned - enough for storing socket address data structure of any family. For - example, code with a file descriptor and without the context of the - address family can pass a pointer to a variable of this type where a - pointer to a socket address structure is expected in calls such as - getpeername() and determine the address family by accessing the - received content after the call. - - The sockaddr_storage structure may also be useful and applied to - certain other interfaces where a generic socket address large enough - and aligned for use with multiple address families may be needed. A - discussion of those interfaces is outside the scope of this document. - - - - -Gilligan, et. al. Informational [Page 15] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - Also, much existing code assumes that any socket address structure - can fit in a generic sockaddr structure. While this has been true - for IPv4 socket address structures, it has always been false for Unix - domain socket address structures (but in practice this has not been a - problem) and it is also false for IPv6 socket address structures - (which can be a problem). - - So now an application can do the following: - - struct sockaddr_storage __ss; - struct sockaddr_in6 *sin6; - sin6 = (struct sockaddr_in6 *) &__ss; - -4. Interface Identification - - This API uses an interface index (a small positive integer) to - identify the local interface on which a multicast group is joined - (Section 5.3). Additionally, the advanced API [4] uses these same - interface indexes to identify the interface on which a datagram is - received, or to specify the interface on which a datagram is to be - sent. - - Interfaces are normally known by names such as "le0", "sl1", "ppp2", - and the like. On Berkeley-derived implementations, when an interface - is made known to the system, the kernel assigns a unique positive - integer value (called the interface index) to that interface. These - are small positive integers that start at 1. (Note that 0 is never - used for an interface index.) There may be gaps so that there is no - current interface for a particular positive interface index. - - This API defines two functions that map between an interface name and - index, a third function that returns all the interface names and - indexes, and a fourth function to return the dynamic memory allocated - by the previous function. How these functions are implemented is - left up to the implementation. 4.4BSD implementations can implement - these functions using the existing sysctl() function with the - NET_RT_IFLIST command. Other implementations may wish to use ioctl() - for this purpose. - -4.1 Name-to-Index - - The first function maps an interface name into its corresponding - index. - - #include <net/if.h> - - unsigned int if_nametoindex(const char *ifname); - - - - -Gilligan, et. al. Informational [Page 16] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - If the specified interface name does not exist, the return value is - 0, and errno is set to ENXIO. If there was a system error (such as - running out of memory), the return value is 0 and errno is set to the - proper value (e.g., ENOMEM). - -4.2 Index-to-Name - - The second function maps an interface index into its corresponding - name. - - #include <net/if.h> - - char *if_indextoname(unsigned int ifindex, char *ifname); - - The ifname argument must point to a buffer of at least IF_NAMESIZE - bytes into which the interface name corresponding to the specified - index is returned. (IF_NAMESIZE is also defined in <net/if.h> and - its value includes a terminating null byte at the end of the - interface name.) This pointer is also the return value of the - function. If there is no interface corresponding to the specified - index, NULL is returned, and errno is set to ENXIO, if there was a - system error (such as running out of memory), if_indextoname returns - NULL and errno would be set to the proper value (e.g., ENOMEM). - -4.3 Return All Interface Names and Indexes - - The if_nameindex structure holds the information about a single - interface and is defined as a result of including the <net/if.h> - header. - - struct if_nameindex { - unsigned int if_index; /* 1, 2, ... */ - char *if_name; /* null terminated name: "le0", ... */ - }; - - The final function returns an array of if_nameindex structures, one - structure per interface. - - struct if_nameindex *if_nameindex(void); - - The end of the array of structures is indicated by a structure with - an if_index of 0 and an if_name of NULL. The function returns a NULL - pointer upon an error, and would set errno to the appropriate value. - - The memory used for this array of structures along with the interface - names pointed to by the if_name members is obtained dynamically. - This memory is freed by the next function. - - - - -Gilligan, et. al. Informational [Page 17] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - -4.4 Free Memory - - The following function frees the dynamic memory that was allocated by - if_nameindex(). - - #include <net/if.h> - - void if_freenameindex(struct if_nameindex *ptr); - - The argument to this function must be a pointer that was returned by - if_nameindex(). - - Currently net/if.h doesn't have prototype definitions for functions - and it is recommended that these definitions be defined in net/if.h - as well and the struct if_nameindex{}. - -5. Socket Options - - A number of new socket options are defined for IPv6. All of these - new options are at the IPPROTO_IPV6 level. That is, the "level" - parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6 - when using these options. The constant name prefix IPV6_ is used in - all of the new socket options. This serves to clearly identify these - options as applying to IPv6. - - The declaration for IPPROTO_IPV6, the new IPv6 socket options, and - related constants defined in this section are obtained by including - the header <netinet/in.h>. - -5.1 Unicast Hop Limit - - A new setsockopt() option controls the hop limit used in outgoing - unicast IPv6 packets. The name of this option is IPV6_UNICAST_HOPS, - and it is used at the IPPROTO_IPV6 layer. The following example - illustrates how it is used: - - int hoplimit = 10; - - if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, - (char *) &hoplimit, sizeof(hoplimit)) == -1) - perror("setsockopt IPV6_UNICAST_HOPS"); - - When the IPV6_UNICAST_HOPS option is set with setsockopt(), the - option value given is used as the hop limit for all subsequent - unicast packets sent via that socket. If the option is not set, the - system selects a default value. The integer hop limit value (called - x) is interpreted as follows: - - - - -Gilligan, et. al. Informational [Page 18] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - x < -1: return an error of EINVAL - x == -1: use kernel default - 0 <= x <= 255: use x - x >= 256: return an error of EINVAL - - The IPV6_UNICAST_HOPS option may be used with getsockopt() to - determine the hop limit value that the system will use for subsequent - unicast packets sent via that socket. For example: - - int hoplimit; - size_t len = sizeof(hoplimit); - - if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, - (char *) &hoplimit, &len) == -1) - perror("getsockopt IPV6_UNICAST_HOPS"); - else - printf("Using %d for hop limit.\n", hoplimit); - -5.2 Sending and Receiving Multicast Packets - - IPv6 applications may send UDP multicast packets by simply specifying - an IPv6 multicast address in the address argument of the sendto() - function. - - Three socket options at the IPPROTO_IPV6 layer control some of the - parameters for sending multicast packets. Setting these options is - not required: applications may send multicast packets without using - these options. The setsockopt() options for controlling the sending - of multicast packets are summarized below. These three options can - also be used with getsockopt(). - - IPV6_MULTICAST_IF - - Set the interface to use for outgoing multicast packets. The - argument is the index of the interface to use. - - Argument type: unsigned int - - IPV6_MULTICAST_HOPS - - Set the hop limit to use for outgoing multicast packets. (Note - a separate option - IPV6_UNICAST_HOPS - is provided to set the - hop limit to use for outgoing unicast packets.) - - The interpretation of the argument is the same as for the - IPV6_UNICAST_HOPS option: - - - - - -Gilligan, et. al. Informational [Page 19] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - x < -1: return an error of EINVAL - x == -1: use kernel default - 0 <= x <= 255: use x - x >= 256: return an error of EINVAL - - If IPV6_MULTICAST_HOPS is not set, the default is 1 - (same as IPv4 today) - - Argument type: int - - IPV6_MULTICAST_LOOP - - If a multicast datagram is sent to a group to which the sending - host itself belongs (on the outgoing interface), a copy of the - datagram is looped back by the IP layer for local delivery if - this option is set to 1. If this option is set to 0 a copy - is not looped back. Other option values return an error of - EINVAL. - - If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback; - same as IPv4 today). - - Argument type: unsigned int - - The reception of multicast packets is controlled by the two - setsockopt() options summarized below. An error of EOPNOTSUPP is - returned if these two options are used with getsockopt(). - - IPV6_JOIN_GROUP - - Join a multicast group on a specified local interface. If the - interface index is specified as 0, the kernel chooses the local - interface. For example, some kernels look up the multicast - group in the normal IPv6 routing table and using the resulting - interface. - - Argument type: struct ipv6_mreq - - IPV6_LEAVE_GROUP - - Leave a multicast group on a specified interface. - - Argument type: struct ipv6_mreq - - The argument type of both of these options is the ipv6_mreq structure, - defined as a result of including the <netinet/in.h> header; - - - - - -Gilligan, et. al. Informational [Page 20] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - struct ipv6_mreq { - struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */ - unsigned int ipv6mr_interface; /* interface index */ - }; - - Note that to receive multicast datagrams a process must join the - multicast group and bind the UDP port to which datagrams will be - sent. Some processes also bind the multicast group address to the - socket, in addition to the port, to prevent other datagrams destined - to that same port from being delivered to the socket. - -6. Library Functions - - New library functions are needed to perform a variety of operations - with IPv6 addresses. Functions are needed to lookup IPv6 addresses - in the Domain Name System (DNS). Both forward lookup (nodename-to- - address translation) and reverse lookup (address-to-nodename - translation) need to be supported. Functions are also needed to - convert IPv6 addresses between their binary and textual form. - - We note that the two existing functions, gethostbyname() and - gethostbyaddr(), are left as-is. New functions are defined to handle - both IPv4 and IPv6 addresses. - -6.1 Nodename-to-Address Translation - - The commonly used function gethostbyname() is inadequate for many - applications, first because it provides no way for the caller to - specify anything about the types of addresses desired (IPv4 only, - IPv6 only, IPv4-mapped IPv6 are OK, etc.), and second because many - implementations of this function are not thread safe. RFC 2133 - defined a function named gethostbyname2() but this function was also - inadequate, first because its use required setting a global option - (RES_USE_INET6) when IPv6 addresses were required, and second because - a flag argument is needed to provide the caller with additional - control over the types of addresses required. - - The following function is new and must be thread safe: - - #include <sys/socket.h> - #include <netdb.h> - - struct hostent *getipnodebyname(const char *name, int af, int flags - int *error_num); - - The name argument can be either a node name or a numeric address - string (i.e., a dotted-decimal IPv4 address or an IPv6 hex address). - The af argument specifies the address family, either AF_INET or - - - -Gilligan, et. al. Informational [Page 21] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - AF_INET6. The error_num value is returned to the caller, via a - pointer, with the appropriate error code in error_num, to support - thread safe error code returns. error_num will be set to one of the - following values: - - HOST_NOT_FOUND - - No such host is known. - - NO_ADDRESS - - The server recognised the request and the name but no address is - available. Another type of request to the name server for the - domain might return an answer. - - NO_RECOVERY - - An unexpected server failure occurred which cannot be recovered. - - TRY_AGAIN - - A temporary and possibly transient error occurred, such as a - failure of a server to respond. - - The flags argument specifies the types of addresses that are searched - for, and the types of addresses that are returned. We note that a - special flags value of AI_DEFAULT (defined below) should handle most - applications. - - That is, porting simple applications to use IPv6 replaces the call - - hptr = gethostbyname(name); - - with - - hptr = getipnodebyname(name, AF_INET6, AI_DEFAULT, &error_num); - - and changes any subsequent error diagnosis code to use error_num - instead of externally declared variables, such as h_errno. - - Applications desiring finer control over the types of addresses - searched for and returned, can specify other combinations of the - flags argument. - - - - - - - - -Gilligan, et. al. Informational [Page 22] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - A flags of 0 implies a strict interpretation of the af argument: - - - If flags is 0 and af is AF_INET, then the caller wants only - IPv4 addresses. A query is made for A records. If successful, - the IPv4 addresses are returned and the h_length member of the - hostent structure will be 4, else the function returns a NULL - pointer. - - - If flags is 0 and if af is AF_INET6, then the caller wants only - IPv6 addresses. A query is made for AAAA records. If - successful, the IPv6 addresses are returned and the h_length - member of the hostent structure will be 16, else the function - returns a NULL pointer. - - Other constants can be logically-ORed into the flags argument, to - modify the behavior of the function. - - - If the AI_V4MAPPED flag is specified along with an af of - AF_INET6, then the caller will accept IPv4-mapped IPv6 - addresses. That is, if no AAAA records are found then a query - is made for A records and any found are returned as IPv4-mapped - IPv6 addresses (h_length will be 16). The AI_V4MAPPED flag is - ignored unless af equals AF_INET6. - - - The AI_ALL flag is used in conjunction with the AI_V4MAPPED - flag, and is only used with the IPv6 address family. When AI_ALL - is logically or'd with AI_V4MAPPED flag then the caller wants - all addresses: IPv6 and IPv4-mapped IPv6. A query is first made - for AAAA records and if successful, the IPv6 addresses are - returned. Another query is then made for A records and any found - are returned as IPv4-mapped IPv6 addresses. h_length will be 16. - Only if both queries fail does the function return a NULL pointer. - This flag is ignored unless af equals AF_INET6. - - - The AI_ADDRCONFIG flag specifies that a query for AAAA records - should occur only if the node has at least one IPv6 source - address configured and a query for A records should occur only - if the node has at least one IPv4 source address configured. - - For example, if the node has no IPv6 source addresses - configured, and af equals AF_INET6, and the node name being - looked up has both AAAA and A records, then: - - (a) if only AI_ADDRCONFIG is specified, the function - returns a NULL pointer; - (b) if AI_ADDRCONFIG | AI_V4MAPPED is specified, the A - records are returned as IPv4-mapped IPv6 addresses; - - - - -Gilligan, et. al. Informational [Page 23] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - The special flags value of AI_DEFAULT is defined as - - #define AI_DEFAULT (AI_V4MAPPED | AI_ADDRCONFIG) - - We noted that the getipnodebyname() function must allow the name - argument to be either a node name or a literal address string (i.e., - a dotted-decimal IPv4 address or an IPv6 hex address). This saves - applications from having to call inet_pton() to handle literal - address strings. - - There are four scenarios based on the type of literal address string - and the value of the af argument. - - The two simple cases are: - - When name is a dotted-decimal IPv4 address and af equals AF_INET, or - when name is an IPv6 hex address and af equals AF_INET6. The members - of the returned hostent structure are: h_name points to a copy of the - name argument, h_aliases is a NULL pointer, h_addrtype is a copy of - the af argument, h_length is either 4 (for AF_INET) or 16 (for - AF_INET6), h_addr_list[0] is a pointer to the 4-byte or 16-byte - binary address, and h_addr_list[1] is a NULL pointer. - - When name is a dotted-decimal IPv4 address and af equals AF_INET6, - and flags equals AI_V4MAPPED, an IPv4-mapped IPv6 address is - returned: h_name points to an IPv6 hex address containing the IPv4- - mapped IPv6 address, h_aliases is a NULL pointer, h_addrtype is - AF_INET6, h_length is 16, h_addr_list[0] is a pointer to the 16-byte - binary address, and h_addr_list[1] is a NULL pointer. If AI_V4MAPPED - is set (with or without AI_ALL) return IPv4-mapped otherwise return - NULL. - - It is an error when name is an IPv6 hex address and af equals - AF_INET. The function's return value is a NULL pointer and error_num - equals HOST_NOT_FOUND. - -6.2 Address-To-Nodename Translation - - The following function has the same arguments as the existing - gethostbyaddr() function, but adds an error number. - - #include <sys/socket.h> #include <netdb.h> - - struct hostent *getipnodebyaddr(const void *src, size_t len, - int af, int *error_num); - - - - - - -Gilligan, et. al. Informational [Page 24] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - As with getipnodebyname(), getipnodebyaddr() must be thread safe. - The error_num value is returned to the caller with the appropriate - error code, to support thread safe error code returns. The following - error conditions may be returned for error_num: - - HOST_NOT_FOUND - - No such host is known. - - NO_ADDRESS - - The server recognized the request and the name but no address - is available. Another type of request to the name server for - the domain might return an answer. - - NO_RECOVERY - - An unexpected server failure occurred which cannot be - recovered. - - TRY_AGAIN - - A temporary and possibly transient error occurred, such as a - failure of a server to respond. - - One possible source of confusion is the handling of IPv4-mapped IPv6 - addresses and IPv4-compatible IPv6 addresses, but the following logic - should apply. - - 1. If af is AF_INET6, and if len equals 16, and if the IPv6 - address is an IPv4-mapped IPv6 address or an IPv4-compatible - IPv6 address, then skip over the first 12 bytes of the IPv6 - address, set af to AF_INET, and set len to 4. - - 2. If af is AF_INET, lookup the name for the given IPv4 address - (e.g., query for a PTR record in the in-addr.arpa domain). - - 3. If af is AF_INET6, lookup the name for the given IPv6 address - (e.g., query for a PTR record in the ip6.int domain). - - 4. If the function is returning success, then the single address - that is returned in the hostent structure is a copy of the - first argument to the function with the same address family - that was passed as an argument to this function. - - - - - - - -Gilligan, et. al. Informational [Page 25] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - All four steps listed are performed, in order. Also note that the - IPv6 hex addresses "::" and "::1" MUST NOT be treated as IPv4- - compatible addresses, and if the address is "::", HOST_NOT_FOUND MUST - be returned and a query of the address not performed. - - Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return - false for "::" and "::1". - -6.3 Freeing memory for getipnodebyname and getipnodebyaddr - - The hostent structure does not change from its existing definition. - This structure, and the information pointed to by this structure, are - dynamically allocated by getipnodebyname and getipnodebyaddr. The - following function frees this memory: - - #include <netdb.h> - - void freehostent(struct hostent *ptr); - -6.4 Protocol-Independent Nodename and Service Name Translation - - Nodename-to-address translation is done in a protocol-independent - fashion using the getaddrinfo() function that is taken from the - Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g - (Protocol Independent Interfaces) draft specification [3]. - - The official specification for this function will be the final POSIX - standard, with the following additional requirements: - - - getaddrinfo() (along with the getnameinfo() function described - in the next section) must be thread safe. - - - The AI_NUMERICHOST is new with this document. - - - All fields in socket address structures returned by - getaddrinfo() that are not filled in through an explicit - argument (e.g., sin6_flowinfo and sin_zero) must be set to 0. - (This makes it easier to compare socket address structures.) - - - getaddrinfo() must fill in the length field of a socket address - structure (e.g., sin6_len) on systems that support this field. - - We are providing this independent description of the function because - POSIX standards are not freely available (as are IETF documents). - - #include <sys/socket.h> - #include <netdb.h> - - - - -Gilligan, et. al. Informational [Page 26] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - int getaddrinfo(const char *nodename, const char *servname, - const struct addrinfo *hints, - struct addrinfo **res); - - The addrinfo structure is defined as a result of including the - <netdb.h> header. - - struct addrinfo { - int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */ - int ai_family; /* PF_xxx */ - int ai_socktype; /* SOCK_xxx */ - int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */ - size_t ai_addrlen; /* length of ai_addr */ - char *ai_canonname; /* canonical name for nodename */ - struct sockaddr *ai_addr; /* binary address */ - struct addrinfo *ai_next; /* next structure in linked list */ - }; - - The return value from the function is 0 upon success or a nonzero - error code. The following names are the nonzero error codes from - getaddrinfo(), and are defined in <netdb.h>: - - EAI_ADDRFAMILY address family for nodename not supported - EAI_AGAIN temporary failure in name resolution - EAI_BADFLAGS invalid value for ai_flags - EAI_FAIL non-recoverable failure in name resolution - EAI_FAMILY ai_family not supported - EAI_MEMORY memory allocation failure - EAI_NODATA no address associated with nodename - EAI_NONAME nodename nor servname provided, or not known - EAI_SERVICE servname not supported for ai_socktype - EAI_SOCKTYPE ai_socktype not supported - EAI_SYSTEM system error returned in errno - - The nodename and servname arguments are pointers to null-terminated - strings or NULL. One or both of these two arguments must be a non- - NULL pointer. In the normal client scenario, both the nodename and - servname are specified. In the normal server scenario, only the - servname is specified. A non-NULL nodename string can be either a - node name or a numeric host address string (i.e., a dotted-decimal - IPv4 address or an IPv6 hex address). A non-NULL servname string can - be either a service name or a decimal port number. - - The caller can optionally pass an addrinfo structure, pointed to by - the third argument, to provide hints concerning the type of socket - that the caller supports. In this hints structure all members other - than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero - or a NULL pointer. A value of PF_UNSPEC for ai_family means the - - - -Gilligan, et. al. Informational [Page 27] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - caller will accept any protocol family. A value of 0 for ai_socktype - means the caller will accept any socket type. A value of 0 for - ai_protocol means the caller will accept any protocol. For example, - if the caller handles only TCP and not UDP, then the ai_socktype - member of the hints structure should be set to SOCK_STREAM when - getaddrinfo() is called. If the caller handles only IPv4 and not - IPv6, then the ai_family member of the hints structure should be set - to PF_INET when getaddrinfo() is called. If the third argument to - getaddrinfo() is a NULL pointer, this is the same as if the caller - had filled in an addrinfo structure initialized to zero with - ai_family set to PF_UNSPEC. - - Upon successful return a pointer to a linked list of one or more - addrinfo structures is returned through the final argument. The - caller can process each addrinfo structure in this list by following - the ai_next pointer, until a NULL pointer is encountered. In each - returned addrinfo structure the three members ai_family, ai_socktype, - and ai_protocol are the corresponding arguments for a call to the - socket() function. In each addrinfo structure the ai_addr member - points to a filled-in socket address structure whose length is - specified by the ai_addrlen member. - - If the AI_PASSIVE bit is set in the ai_flags member of the hints - structure, then the caller plans to use the returned socket address - structure in a call to bind(). In this case, if the nodename - argument is a NULL pointer, then the IP address portion of the socket - address structure will be set to INADDR_ANY for an IPv4 address or - IN6ADDR_ANY_INIT for an IPv6 address. - - If the AI_PASSIVE bit is not set in the ai_flags member of the hints - structure, then the returned socket address structure will be ready - for a call to connect() (for a connection-oriented protocol) or - either connect(), sendto(), or sendmsg() (for a connectionless - protocol). In this case, if the nodename argument is a NULL pointer, - then the IP address portion of the socket address structure will be - set to the loopback address. - - If the AI_CANONNAME bit is set in the ai_flags member of the hints - structure, then upon successful return the ai_canonname member of the - first addrinfo structure in the linked list will point to a null- - terminated string containing the canonical name of the specified - nodename. - - If the AI_NUMERICHOST bit is set in the ai_flags member of the hints - structure, then a non-NULL nodename string must be a numeric host - address string. Otherwise an error of EAI_NONAME is returned. This - flag prevents any type of name resolution service (e.g., the DNS) - from being called. - - - -Gilligan, et. al. Informational [Page 28] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - All of the information returned by getaddrinfo() is dynamically - allocated: the addrinfo structures, and the socket address structures - and canonical node name strings pointed to by the addrinfo - structures. To return this information to the system the function - freeaddrinfo() is called: - - #include <sys/socket.h> #include <netdb.h> - - void freeaddrinfo(struct addrinfo *ai); - - The addrinfo structure pointed to by the ai argument is freed, along - with any dynamic storage pointed to by the structure. This operation - is repeated until a NULL ai_next pointer is encountered. - - To aid applications in printing error messages based on the EAI_xxx - codes returned by getaddrinfo(), the following function is defined. - - #include <sys/socket.h> #include <netdb.h> - - char *gai_strerror(int ecode); - - The argument is one of the EAI_xxx values defined earlier and the - return value points to a string describing the error. If the - argument is not one of the EAI_xxx values, the function still returns - a pointer to a string whose contents indicate an unknown error. - -6.5 Socket Address Structure to Nodename and Service Name - - The POSIX 1003.1g specification includes no function to perform the - reverse conversion from getaddrinfo(): to look up a nodename and - service name, given the binary address and port. Therefore, we - define the following function: - - #include <sys/socket.h> - #include <netdb.h> - - int getnameinfo(const struct sockaddr *sa, socklen_t salen, - char *host, size_t hostlen, - char *serv, size_t servlen, - int flags); - - This function looks up an IP address and port number provided by the - caller in the DNS and system-specific database, and returns text - strings for both in buffers provided by the caller. The function - indicates successful completion by a zero return value; a non-zero - return value indicates failure. - - - - - -Gilligan, et. al. Informational [Page 29] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - The first argument, sa, points to either a sockaddr_in structure (for - IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP - address and port number. The salen argument gives the length of the - sockaddr_in or sockaddr_in6 structure. - - The function returns the nodename associated with the IP address in - the buffer pointed to by the host argument. The caller provides the - size of this buffer via the hostlen argument. The service name - associated with the port number is returned in the buffer pointed to - by serv, and the servlen argument gives the length of this buffer. - The caller specifies not to return either string by providing a zero - value for the hostlen or servlen arguments. Otherwise, the caller - must provide buffers large enough to hold the nodename and the - service name, including the terminating null characters. - - Unfortunately most systems do not provide constants that specify the - maximum size of either a fully-qualified domain name or a service - name. Therefore to aid the application in allocating buffers for - these two returned strings the following constants are defined in - <netdb.h>: - - #define NI_MAXHOST 1025 - #define NI_MAXSERV 32 - - The first value is actually defined as the constant MAXDNAME in recent - versions of BIND's <arpa/nameser.h> header (older versions of BIND - define this constant to be 256) and the second is a guess based on the - services listed in the current Assigned Numbers RFC. - - The final argument is a flag that changes the default actions of this - function. By default the fully-qualified domain name (FQDN) for the - host is looked up in the DNS and returned. If the flag bit NI_NOFQDN - is set, only the nodename portion of the FQDN is returned for local - hosts. - - If the flag bit NI_NUMERICHOST is set, or if the host's name cannot be - located in the DNS, the numeric form of the host's address is returned - instead of its name (e.g., by calling inet_ntop() instead of - getipnodebyaddr()). If the flag bit NI_NAMEREQD is set, an error is - returned if the host's name cannot be located in the DNS. - - If the flag bit NI_NUMERICSERV is set, the numeric form of the service - address is returned (e.g., its port number) instead of its name. The - two NI_NUMERICxxx flags are required to support the "-n" flag that - many commands provide. - - - - - - -Gilligan, et. al. Informational [Page 30] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - A fifth flag bit, NI_DGRAM, specifies that the service is a datagram - service, and causes getservbyport() to be called with a second - argument of "udp" instead of its default of "tcp". This is required - for the few ports (e.g. 512-514) that have different services for UDP - and TCP. - - These NI_xxx flags are defined in <netdb.h> along with the AI_xxx - flags already defined for getaddrinfo(). - -6.6 Address Conversion Functions - - The two functions inet_addr() and inet_ntoa() convert an IPv4 address - between binary and text form. IPv6 applications need similar - functions. The following two functions convert both IPv6 and IPv4 - addresses: - - #include <sys/socket.h> - #include <arpa/inet.h> - - int inet_pton(int af, const char *src, void *dst); - - const char *inet_ntop(int af, const void *src, - char *dst, size_t size); - - The inet_pton() function converts an address in its standard text - presentation form into its numeric binary form. The af argument - specifies the family of the address. Currently the AF_INET and - AF_INET6 address families are supported. The src argument points to - the string being passed in. The dst argument points to a buffer into - which the function stores the numeric address. The address is - returned in network byte order. Inet_pton() returns 1 if the - conversion succeeds, 0 if the input is not a valid IPv4 dotted- - decimal string or a valid IPv6 address string, or -1 with errno set - to EAFNOSUPPORT if the af argument is unknown. The calling - application must ensure that the buffer referred to by dst is large - enough to hold the numeric address (e.g., 4 bytes for AF_INET or 16 - bytes for AF_INET6). - - If the af argument is AF_INET, the function accepts a string in the - standard IPv4 dotted-decimal form: - - ddd.ddd.ddd.ddd - - where ddd is a one to three digit decimal number between 0 and 255. - Note that many implementations of the existing inet_addr() and - inet_aton() functions accept nonstandard input: octal numbers, - hexadecimal numbers, and fewer than four numbers. inet_pton() does - not accept these formats. - - - -Gilligan, et. al. Informational [Page 31] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - If the af argument is AF_INET6, then the function accepts a string in - one of the standard IPv6 text forms defined in Section 2.2 of the - addressing architecture specification [2]. - - The inet_ntop() function converts a numeric address into a text - string suitable for presentation. The af argument specifies the - family of the address. This can be AF_INET or AF_INET6. The src - argument points to a buffer holding an IPv4 address if the af - argument is AF_INET, or an IPv6 address if the af argument is - AF_INET6, the address must be in network byte order. The dst - argument points to a buffer where the function will store the - resulting text string. The size argument specifies the size of this - buffer. The application must specify a non-NULL dst argument. For - IPv6 addresses, the buffer must be at least 46-octets. For IPv4 - addresses, the buffer must be at least 16-octets. In order to allow - applications to easily declare buffers of the proper size to store - IPv4 and IPv6 addresses in string form, the following two constants - are defined in <netinet/in.h>: - - #define INET_ADDRSTRLEN 16 - #define INET6_ADDRSTRLEN 46 - - The inet_ntop() function returns a pointer to the buffer containing - the text string if the conversion succeeds, and NULL otherwise. Upon - failure, errno is set to EAFNOSUPPORT if the af argument is invalid or - ENOSPC if the size of the result buffer is inadequate. - -6.7 Address Testing Macros - - The following macros can be used to test for special IPv6 addresses. - - #include <netinet/in.h> - - int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *); - int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *); - int IN6_IS_ADDR_MULTICAST (const struct in6_addr *); - int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *); - int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *); - int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *); - int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *); - - int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); - int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); - int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); - int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *); - int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *); - - - - - -Gilligan, et. al. Informational [Page 32] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - The first seven macros return true if the address is of the specified - type, or false otherwise. The last five test the scope of a - multicast address and return true if the address is a multicast - address of the specified scope or false if the address is either not - a multicast address or not of the specified scope. Note that - IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true only for - the two local-use IPv6 unicast addresses. These two macros do not - return true for IPv6 multicast addresses of either link-local scope - or site-local scope. - -7. Summary of New Definitions - - The following list summarizes the constants, structure, and extern - definitions discussed in this memo, sorted by header. - - <net/if.h> IF_NAMESIZE - <net/if.h> struct if_nameindex{}; - - <netdb.h> AI_ADDRCONFIG - <netdb.h> AI_DEFAULT - <netdb.h> AI_ALL - <netdb.h> AI_CANONNAME - <netdb.h> AI_NUMERICHOST - <netdb.h> AI_PASSIVE - <netdb.h> AI_V4MAPPED - <netdb.h> EAI_ADDRFAMILY - <netdb.h> EAI_AGAIN - <netdb.h> EAI_BADFLAGS - <netdb.h> EAI_FAIL - <netdb.h> EAI_FAMILY - <netdb.h> EAI_MEMORY - <netdb.h> EAI_NODATA - <netdb.h> EAI_NONAME - <netdb.h> EAI_SERVICE - <netdb.h> EAI_SOCKTYPE - <netdb.h> EAI_SYSTEM - <netdb.h> NI_DGRAM - <netdb.h> NI_MAXHOST - <netdb.h> NI_MAXSERV - <netdb.h> NI_NAMEREQD - <netdb.h> NI_NOFQDN - <netdb.h> NI_NUMERICHOST - <netdb.h> NI_NUMERICSERV - <netdb.h> struct addrinfo{}; - - <netinet/in.h> IN6ADDR_ANY_INIT - <netinet/in.h> IN6ADDR_LOOPBACK_INIT - <netinet/in.h> INET6_ADDRSTRLEN - - - -Gilligan, et. al. Informational [Page 33] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - <netinet/in.h> INET_ADDRSTRLEN - <netinet/in.h> IPPROTO_IPV6 - <netinet/in.h> IPV6_JOIN_GROUP - <netinet/in.h> IPV6_LEAVE_GROUP - <netinet/in.h> IPV6_MULTICAST_HOPS - <netinet/in.h> IPV6_MULTICAST_IF - <netinet/in.h> IPV6_MULTICAST_LOOP - <netinet/in.h> IPV6_UNICAST_HOPS - <netinet/in.h> SIN6_LEN - <netinet/in.h> extern const struct in6_addr in6addr_any; - <netinet/in.h> extern const struct in6_addr in6addr_loopback; - <netinet/in.h> struct in6_addr{}; - <netinet/in.h> struct ipv6_mreq{}; - <netinet/in.h> struct sockaddr_in6{}; - - <sys/socket.h> AF_INET6 - <sys/socket.h> PF_INET6 - <sys/socket.h> struct sockaddr_storage; - - The following list summarizes the function and macro prototypes - discussed in this memo, sorted by header. - -<arpa/inet.h> int inet_pton(int, const char *, void *); -<arpa/inet.h> const char *inet_ntop(int, const void *, - char *, size_t); - -<net/if.h> char *if_indextoname(unsigned int, char *); -<net/if.h> unsigned int if_nametoindex(const char *); -<net/if.h> void if_freenameindex(struct if_nameindex *); -<net/if.h> struct if_nameindex *if_nameindex(void); - -<netdb.h> int getaddrinfo(const char *, const char *, - const struct addrinfo *, - struct addrinfo **); -<netdb.h> int getnameinfo(const struct sockaddr *, socklen_t, - char *, size_t, char *, size_t, int); -<netdb.h> void freeaddrinfo(struct addrinfo *); -<netdb.h> char *gai_strerror(int); -<netdb.h> struct hostent *getipnodebyname(const char *, int, int, - int *); -<netdb.h> struct hostent *getipnodebyaddr(const void *, size_t, - int, int *); -<netdb.h> void freehostent(struct hostent *); - -<netinet/in.h> int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); - - - -Gilligan, et. al. Informational [Page 34] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - -<netinet/in.h> int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_MULTICAST(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *); - -8. Security Considerations - - IPv6 provides a number of new security mechanisms, many of which need - to be accessible to applications. Companion memos detailing the - extensions to the socket interfaces to support IPv6 security are - being written. - -9. Year 2000 Considerations - - There are no issues for this memo concerning the Year 2000 issue - regarding the use of dates. - -Changes From RFC 2133 - - Changes made in the March 1998 Edition (-01 draft): - - Changed all "hostname" to "nodename" for consistency with other - IPv6 documents. - - Section 3.3: changed comment for sin6_flowinfo to be "traffic - class & flow info" and updated corresponding text description to - current definition of these two fields. - - Section 3.10 ("Portability Additions") is new. - - Section 6: a new paragraph was added reiterating that the existing - gethostbyname() and gethostbyaddr() are not changed. - - Section 6.1: change gethostbyname3() to getnodebyname(). Add - AI_DEFAULT to handle majority of applications. Renamed - AI_V6ADDRCONFIG to AI_ADDRCONFIG and define it for A records and - IPv4 addresses too. Defined exactly what getnodebyname() must - return if the name argument is a numeric address string. - - Section 6.2: change gethostbyaddr() to getnodebyaddr(). Reword - items 2 and 3 in the description of how to handle IPv4-mapped and - IPv4- compatible addresses to "lookup a name" for a given address, - instead of specifying what type of DNS query to issue. - - - - -Gilligan, et. al. Informational [Page 35] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - Section 6.3: added two more requirements to getaddrinfo(). - - Section 7: added the following constants to the list for - <netdb.h>: AI_ADDRCONFIG, AI_ALL, and AI_V4MAPPED. Add union - sockaddr_union and SA_LEN to the lists for <sys/socket.h>. - - Updated references. - - Changes made in the November 1997 Edition (-00 draft): - - The data types have been changed to conform with Draft 6.6 of the - Posix 1003.1g standard. - - Section 3.2: data type of s6_addr changed to "uint8_t". - - Section 3.3: data type of sin6_family changed to "sa_family_t". - data type of sin6_port changed to "in_port_t", data type of - sin6_flowinfo changed to "uint32_t". - - Section 3.4: same as Section 3.3, plus data type of sin6_len - changed to "uint8_t". - - Section 6.2: first argument of gethostbyaddr() changed from "const - char *" to "const void *" and second argument changed from "int" - to "size_t". - - Section 6.4: second argument of getnameinfo() changed from - "size_t" to "socklen_t". - - The wording was changed when new structures were defined, to be - more explicit as to which header must be included to define the - structure: - - Section 3.2 (in6_addr{}), Section 3.3 (sockaddr_in6{}), Section - 3.4 (sockaddr_in6{}), Section 4.3 (if_nameindex{}), Section 5.3 - (ipv6_mreq{}), and Section 6.3 (addrinfo{}). - - Section 4: NET_RT_LIST changed to NET_RT_IFLIST. - - Section 5.1: The IPV6_ADDRFORM socket option was removed. - - Section 5.3: Added a note that an option value other than 0 or 1 - for IPV6_MULTICAST_LOOP returns an error. Added a note that - IPV6_MULTICAST_IF, IPV6_MULTICAST_HOPS, and IPV6_MULTICAST_LOOP - can also be used with getsockopt(), but IPV6_ADD_MEMBERSHIP and - IPV6_DROP_MEMBERSHIP cannot be used with getsockopt(). - - - - - -Gilligan, et. al. Informational [Page 36] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - Section 6.1: Removed the description of gethostbyname2() and its - associated RES_USE_INET6 option, replacing it with - gethostbyname3(). - - Section 6.2: Added requirement that gethostbyaddr() be thread - safe. Reworded step 4 to avoid using the RES_USE_INET6 option. - - Section 6.3: Added the requirement that getaddrinfo() and - getnameinfo() be thread safe. Added the AI_NUMERICHOST flag. - - Section 6.6: Added clarification about IN6_IS_ADDR_LINKLOCAL and - IN6_IS_ADDR_SITELOCAL macros. - - Changes made to the draft -01 specification Sept 98 - - Changed priority to traffic class in the spec. - - Added the need for scope identification in section 2.1. - - Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and - 3.4. - - Changed 3.10 to use generic storage structure to support holding - IPv6 addresses and removed the SA_LEN macro. - - Distinguished between invalid input parameters and system failures - for Interface Identification in Section 4.1 and 4.2. - - Added defaults for multicast operations in section 5.2 and changed - the names from ADD to JOIN and DROP to LEAVE to be consistent with - IPv6 multicast terminology. - - Changed getnodebyname to getipnodebyname, getnodebyaddr to - getipnodebyaddr, and added MT safe error code to function - parameters in section 6. - - Moved freehostent to its own sub-section after getipnodebyaddr now - 6.3 (so this bumps all remaining sections in section 6. - - Clarified the use of AI_ALL and AI_V4MAPPED that these are - dependent on the AF parameter and must be used as a conjunction in - section 6.1. - - Removed the restriction that literal addresses cannot be used with - a flags argument in section 6.1. - - Added Year 2000 Section to the draft - - - - -Gilligan, et. al. Informational [Page 37] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - Deleted Reference to the following because the attached is deleted - from the ID directory and has expired. But the logic from the - aforementioned draft still applies, so that was kept in Section - 6.2 bullets after 3rd paragraph. - - [7] P. Vixie, "Reverse Name Lookups of Encapsulated IPv4 - Addresses in IPv6", Internet-Draft, <draft-vixie-ipng- - ipv4ptr-00.txt>, May 1996. - - Deleted the following reference as it is no longer referenced. - And the draft has expired. - - [3] D. McDonald, "A Simple IP Security API Extension to BSD - Sockets", Internet-Draft, <draft-mcdonald-simple-ipsec-api- - 01.txt>, March 1997. - - Deleted the following reference as it is no longer referenced. - - [4] C. Metz, "Network Security API for Sockets", - Internet-Draft, <draft-metz-net-security-api-01.txt>, January - 1998. - - Update current references to current status. - - Added alignment notes for in6_addr and sin6_addr. - - Clarified further that AI_V4MAPPED must be used with a dotted IPv4 - literal address for getipnodebyname(), when address family is - AF_INET6. - - Added text to clarify "::" and "::1" when used by - getipnodebyaddr(). - -Acknowledgments - - Thanks to the many people who made suggestions and provided feedback - to this document, including: Werner Almesberger, Ran Atkinson, Fred - Baker, Dave Borman, Andrew Cherenson, Alex Conta, Alan Cox, Steve - Deering, Richard Draves, Francis Dupont, Robert Elz, Marc Hasson, Tom - Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema, Koji Imada, - Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan McDonald, Dave - Mitton, Thomas Narten, Josh Osborne, Craig Partridge, Jean-Luc - Richier, Erik Scoredos, Keith Sklower, Matt Thomas, Harvey Thompson, - Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David - Waitzman, Carl Williams, and Kazu Yamamoto, - - - - - - -Gilligan, et. al. Informational [Page 38] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - - The getaddrinfo() and getnameinfo() functions are taken from an - earlier Internet Draft by Keith Sklower. As noted in that draft, - William Durst, Steven Wise, Michael Karels, and Eric Allman provided - many useful discussions on the subject of protocol-independent name- - to-address translation, and reviewed early versions of Keith - Sklower's original proposal. Eric Allman implemented the first - prototype of getaddrinfo(). The observation that specifying the pair - of name and service would suffice for connecting to a service - independent of protocol details was made by Marshall Rose in a - proposal to X/Open for a "Uniform Network Interface". - - Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh - Kacker made many contributions to this document. Ramesh Govindan - made a number of contributions and co-authored an earlier version of - this memo. - -References - - [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) - Specification", RFC 2460, December 1998. - - [2] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 2373, July 1998. - - [3] IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT - 6.6, March 1997. - - [4] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC - 2292, February 1998. - - - - - - - - - - - - - - - - - - - - - - -Gilligan, et. al. Informational [Page 39] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - -Authors' Addresses - - Robert E. Gilligan - FreeGate Corporation - 1208 E. Arques Ave. - Sunnyvale, CA 94086 - - Phone: +1 408 617 1004 - EMail: gilligan@freegate.com - - - Susan Thomson - Bell Communications Research - MRE 2P-343, 445 South Street - Morristown, NJ 07960 - - Phone: +1 201 829 4514 - EMail: set@thumper.bellcore.com - - - Jim Bound - Compaq Computer Corporation - 110 Spitbrook Road ZK3-3/U14 - Nashua, NH 03062-2698 - - Phone: +1 603 884 0400 - EMail: bound@zk3.dec.com - - - W. Richard Stevens - 1202 E. Paseo del Zorro - Tucson, AZ 85718-2826 - - Phone: +1 520 297 9416 - EMail: rstevens@kohala.com - - - - - - - - - - - - - - - - -Gilligan, et. al. Informational [Page 40] - -RFC 2553 Basic Socket Interface Extensions for IPv6 March 1999 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Gilligan, et. al. Informational [Page 41] - diff --git a/contrib/bind9/doc/rfc/rfc2671.txt b/contrib/bind9/doc/rfc/rfc2671.txt deleted file mode 100644 index ec05f80829cf..000000000000 --- a/contrib/bind9/doc/rfc/rfc2671.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -Network Working Group P. Vixie -Request for Comments: 2671 ISC -Category: Standards Track August 1999 - - - Extension Mechanisms for DNS (EDNS0) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - -Abstract - - The Domain Name System's wire protocol includes a number of fixed - fields whose range has been or soon will be exhausted and does not - allow clients to advertise their capabilities to servers. This - document describes backward compatible mechanisms for allowing the - protocol to grow. - -1 - Rationale and Scope - -1.1. DNS (see [RFC1035]) specifies a Message Format and within such - messages there are standard formats for encoding options, errors, - and name compression. The maximum allowable size of a DNS Message - is fixed. Many of DNS's protocol limits are too small for uses - which are or which are desired to become common. There is no way - for implementations to advertise their capabilities. - -1.2. Existing clients will not know how to interpret the protocol - extensions detailed here. In practice, these clients will be - upgraded when they have need of a new feature, and only new - features will make use of the extensions. We must however take - account of client behaviour in the face of extra fields, and design - a fallback scheme for interoperability with these clients. - - - - - - - - - -Vixie Standards Track [Page 1] - -RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999 - - -2 - Affected Protocol Elements - -2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit - word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of - 1-bit flags. The original reserved Z bits have been allocated to - various purposes, and most of the RCODE values are now in use. - More flags and more possible RCODEs are needed. - -2.2. The first two bits of a wire format domain label are used to denote - the type of the label. [RFC1035 4.1.4] allocates two of the four - possible types and reserves the other two. Proposals for use of - the remaining types far outnumber those available. More label - types are needed. - -2.3. DNS Messages are limited to 512 octets in size when sent over UDP. - While the minimum maximum reassembly buffer size still allows a - limit of 512 octets of UDP payload, most of the hosts now connected - to the Internet are able to reassemble larger datagrams. Some - mechanism must be created to allow requestors to advertise larger - buffer sizes to responders. - -3 - Extended Label Types - -3.1. The "0 1" label type will now indicate an extended label type, - whose value is encoded in the lower six bits of the first octet of - a label. All subsequently developed label types should be encoded - using an extended label type. - -3.2. The "1 1 1 1 1 1" extended label type will be reserved for future - expansion of the extended label type code space. - -4 - OPT pseudo-RR - -4.1. One OPT pseudo-RR can be added to the additional data section of - either a request or a response. An OPT is called a pseudo-RR - because it pertains to a particular transport level message and not - to any actual DNS data. OPT RRs shall never be cached, forwarded, - or stored in or loaded from master files. The quantity of OPT - pseudo-RRs per message shall be either zero or one, but not - greater. - -4.2. An OPT RR has a fixed part and a variable set of options expressed - as {attribute, value} pairs. The fixed part holds some DNS meta - data and also a small collection of new protocol elements which we - expect to be so popular that it would be a waste of wire space to - encode them as {attribute, value} pairs. - - - - - -Vixie Standards Track [Page 2] - -RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999 - - -4.3. The fixed part of an OPT RR is structured as follows: - - Field Name Field Type Description - ------------------------------------------------------ - NAME domain name empty (root domain) - TYPE u_int16_t OPT - CLASS u_int16_t sender's UDP payload size - TTL u_int32_t extended RCODE and flags - RDLEN u_int16_t describes RDATA - RDATA octet stream {attribute,value} pairs - -4.4. The variable part of an OPT RR is encoded in its RDATA and is - structured as zero or more of the following: - - +0 (MSB) +1 (LSB) - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 0: | OPTION-CODE | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 2: | OPTION-LENGTH | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 4: | | - / OPTION-DATA / - / / - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - OPTION-CODE (Assigned by IANA.) - - OPTION-LENGTH Size (in octets) of OPTION-DATA. - - OPTION-DATA Varies per OPTION-CODE. - -4.5. The sender's UDP payload size (which OPT stores in the RR CLASS - field) is the number of octets of the largest UDP payload that can - be reassembled and delivered in the sender's network stack. Note - that path MTU, with or without fragmentation, may be smaller than - this. - -4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP - reassembly buffer. Choosing 1280 on an Ethernet connected - requestor would be reasonable. The consequence of choosing too - large a value may be an ICMP message from an intermediate - gateway, or even a silent drop of the response message. - -4.5.2. Both requestors and responders are advised to take account of the - path's discovered MTU (if already known) when considering message - sizes. - - - - - -Vixie Standards Track [Page 3] - -RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999 - - -4.5.3. The requestor's maximum payload size can change over time, and - should therefore not be cached for use beyond the transaction in - which it is advertised. - -4.5.4. The responder's maximum payload size can change over time, but - can be reasonably expected to remain constant between two - sequential transactions; for example, a meaningless QUERY to - discover a responder's maximum UDP payload size, followed - immediately by an UPDATE which takes advantage of this size. - (This is considered preferrable to the outright use of TCP for - oversized requests, if there is any reason to suspect that the - responder implements EDNS, and if a request will not fit in the - default 512 payload size limit.) - -4.5.5. Due to transaction overhead, it is unwise to advertise an - architectural limit as a maximum UDP payload size. Just because - your stack can reassemble 64KB datagrams, don't assume that you - want to spend more than about 4KB of state memory per ongoing - transaction. - -4.6. The extended RCODE and flags (which OPT stores in the RR TTL field) - are structured as follows: - - +0 (MSB) +1 (LSB) - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 0: | EXTENDED-RCODE | VERSION | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 2: | Z | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note - that EXTENDED-RCODE value "0" indicates that an - unextended RCODE is in use (values "0" through "15"). - - VERSION Indicates the implementation level of whoever sets - it. Full conformance with this specification is - indicated by version "0." Requestors are encouraged - to set this to the lowest implemented level capable - of expressing a transaction, to minimize the - responder and network load of discovering the - greatest common implementation level between - requestor and responder. A requestor's version - numbering strategy should ideally be a run time - configuration option. - - If a responder does not implement the VERSION level - of the request, then it answers with RCODE=BADVERS. - All responses will be limited in format to the - - - -Vixie Standards Track [Page 4] - -RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999 - - - VERSION level of the request, but the VERSION of each - response will be the highest implementation level of - the responder. In this way a requestor will learn - the implementation level of a responder as a side - effect of every response, including error responses, - including RCODE=BADVERS. - - Z Set to zero by senders and ignored by receivers, - unless modified in a subsequent specification. - -5 - Transport Considerations - -5.1. The presence of an OPT pseudo-RR in a request should be taken as an - indication that the requestor fully implements the given version of - EDNS, and can correctly understand any response that conforms to - that feature's specification. - -5.2. Lack of use of these features in a request must be taken as an - indication that the requestor does not implement any part of this - specification and that the responder may make no use of any - protocol extension described here in its response. - -5.3. Responders who do not understand these protocol extensions are - expected to send a response with RCODE NOTIMPL, FORMERR, or - SERVFAIL. Therefore use of extensions should be "probed" such that - a responder who isn't known to support them be allowed a retry with - no extensions if it responds with such an RCODE. If a responder's - capability level is cached by a requestor, a new probe should be - sent periodically to test for changes to responder capability. - -6 - Security Considerations - - Requestor-side specification of the maximum buffer size may open a - new DNS denial of service attack if responders can be made to send - messages which are too large for intermediate gateways to forward, - thus leading to potential ICMP storms between gateways and - responders. - -7 - IANA Considerations - - The IANA has assigned RR type code 41 for OPT. - - It is the recommendation of this document and its working group - that IANA create a registry for EDNS Extended Label Types, for EDNS - Option Codes, and for EDNS Version Numbers. - - This document assigns label type 0b01xxxxxx as "EDNS Extended Label - Type." We request that IANA record this assignment. - - - -Vixie Standards Track [Page 5] - -RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999 - - - This document assigns extended label type 0bxx111111 as "Reserved - for future extended label types." We request that IANA record this - assignment. - - This document assigns option code 65535 to "Reserved for future - expansion." - - This document expands the RCODE space from 4 bits to 12 bits. This - will allow IANA to assign more than the 16 distinct RCODE values - allowed in [RFC1035]. - - This document assigns EDNS Extended RCODE "16" to "BADVERS". - - IESG approval should be required to create new entries in the EDNS - Extended Label Type or EDNS Version Number registries, while any - published RFC (including Informational, Experimental, or BCP) - should be grounds for allocation of an EDNS Option Code. - -8 - Acknowledgements - - Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, - Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas - Narten were each instrumental in creating and refining this - specification. - -9 - References - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - -10 - Author's Address - - Paul Vixie - Internet Software Consortium - 950 Charter Street - Redwood City, CA 94063 - - Phone: +1 650 779 7001 - EMail: vixie@isc.org - - - - - - - - - - - - -Vixie Standards Track [Page 6] - -RFC 2671 Extension Mechanisms for DNS (EDNS0) August 1999 - - -11 - Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Vixie Standards Track [Page 7] - diff --git a/contrib/bind9/doc/rfc/rfc2672.txt b/contrib/bind9/doc/rfc/rfc2672.txt deleted file mode 100644 index 11030168dcd0..000000000000 --- a/contrib/bind9/doc/rfc/rfc2672.txt +++ /dev/null @@ -1,507 +0,0 @@ - - - - - - -Network Working Group M. Crawford -Request for Comments: 2672 Fermilab -Category: Standards Track August 1999 - - - Non-Terminal DNS Name Redirection - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - -1. Introduction - - This document defines a new DNS Resource Record called "DNAME", which - provides the capability to map an entire subtree of the DNS name - space to another domain. It differs from the CNAME record which maps - a single node of the name space. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [KWORD]. - -2. Motivation - - This Resource Record and its processing rules were conceived as a - solution to the problem of maintaining address-to-name mappings in a - context of network renumbering. Without the DNAME mechanism, an - authoritative DNS server for the address-to-name mappings of some - network must be reconfigured when that network is renumbered. With - DNAME, the zone can be constructed so that it needs no modification - when renumbered. DNAME can also be useful in other situations, such - as when an organizational unit is renamed. - -3. The DNAME Resource Record - - The DNAME RR has mnemonic DNAME and type code 39 (decimal). - - - - - - - -Crawford Standards Track [Page 1] - -RFC 2672 Non-Terminal DNS Name Redirection August 1999 - - - DNAME has the following format: - - <owner> <ttl> <class> DNAME <target> - - The format is not class-sensitive. All fields are required. The - RDATA field <target> is a <domain-name> [DNSIS]. - - The DNAME RR causes type NS additional section processing. - - The effect of the DNAME record is the substitution of the record's - <target> for its <owner> as a suffix of a domain name. A "no- - descendants" limitation governs the use of DNAMEs in a zone file: - - If a DNAME RR is present at a node N, there may be other data at N - (except a CNAME or another DNAME), but there MUST be no data at - any descendant of N. This restriction applies only to records of - the same class as the DNAME record. - - This rule assures predictable results when a DNAME record is cached - by a server which is not authoritative for the record's zone. It - MUST be enforced when authoritative zone data is loaded. Together - with the rules for DNS zone authority [DNSCLR] it implies that DNAME - and NS records can only coexist at the top of a zone which has only - one node. - - The compression scheme of [DNSIS] MUST NOT be applied to the RDATA - portion of a DNAME record unless the sending server has some way of - knowing that the receiver understands the DNAME record format. - Signalling such understanding is expected to be the subject of future - DNS Extensions. - - Naming loops can be created with DNAME records or a combination of - DNAME and CNAME records, just as they can with CNAME records alone. - Resolvers, including resolvers embedded in DNS servers, MUST limit - the resources they devote to any query. Implementors should note, - however, that fairly lengthy chains of DNAME records may be valid. - -4. Query Processing - - To exploit the DNAME mechanism the name resolution algorithms [DNSCF] - must be modified slightly for both servers and resolvers. - - Both modified algorithms incorporate the operation of making a - substitution on a name (either QNAME or SNAME) under control of a - DNAME record. This operation will be referred to as "the DNAME - substitution". - - - - - -Crawford Standards Track [Page 2] - -RFC 2672 Non-Terminal DNS Name Redirection August 1999 - - -4.1. Processing by Servers - - For a server performing non-recursive service steps 3.c and 4 of - section 4.3.2 [DNSCF] are changed to check for a DNAME record before - checking for a wildcard ("*") label, and to return certain DNAME - records from zone data and the cache. - - DNS clients sending Extended DNS [EDNS0] queries with Version 0 or - non-extended queries are presumed not to understand the semantics of - the DNAME record, so a server which implements this specification, - when answering a non-extended query, SHOULD synthesize a CNAME record - for each DNAME record encountered during query processing to help the - client reach the correct DNS data. The behavior of clients and - servers under Extended DNS versions greater than 0 will be specified - when those versions are defined. - - The synthesized CNAME RR, if provided, MUST have - - The same CLASS as the QCLASS of the query, - - TTL equal to zero, - - An <owner> equal to the QNAME in effect at the moment the DNAME RR - was encountered, and - - An RDATA field containing the new QNAME formed by the action of - the DNAME substitution. - - If the server has the appropriate key on-line [DNSSEC, SECDYN], it - MAY generate and return a SIG RR for the synthesized CNAME RR. - - The revised server algorithm is: - - 1. Set or clear the value of recursion available in the response - depending on whether the name server is willing to provide - recursive service. If recursive service is available and - requested via the RD bit in the query, go to step 5, otherwise - step 2. - - 2. Search the available zones for the zone which is the nearest - ancestor to QNAME. If such a zone is found, go to step 3, - otherwise step 4. - - 3. Start matching down, label by label, in the zone. The matching - process can terminate several ways: - - - - - - -Crawford Standards Track [Page 3] - -RFC 2672 Non-Terminal DNS Name Redirection August 1999 - - - a. If the whole of QNAME is matched, we have found the node. - - If the data at the node is a CNAME, and QTYPE doesn't match - CNAME, copy the CNAME RR into the answer section of the - response, change QNAME to the canonical name in the CNAME RR, - and go back to step 1. - - Otherwise, copy all RRs which match QTYPE into the answer - section and go to step 6. - - b. If a match would take us out of the authoritative data, we have - a referral. This happens when we encounter a node with NS RRs - marking cuts along the bottom of a zone. - - Copy the NS RRs for the subzone into the authority section of - the reply. Put whatever addresses are available into the - additional section, using glue RRs if the addresses are not - available from authoritative data or the cache. Go to step 4. - - c. If at some label, a match is impossible (i.e., the - corresponding label does not exist), look to see whether the - last label matched has a DNAME record. - - If a DNAME record exists at that point, copy that record into - the answer section. If substitution of its <target> for its - <owner> in QNAME would overflow the legal size for a <domain- - name>, set RCODE to YXDOMAIN [DNSUPD] and exit; otherwise - perform the substitution and continue. If the query was not - extended [EDNS0] with a Version indicating understanding of the - DNAME record, the server SHOULD synthesize a CNAME record as - described above and include it in the answer section. Go back - to step 1. - - If there was no DNAME record, look to see if the "*" label - exists. - - If the "*" label does not exist, check whether the name we are - looking for is the original QNAME in the query or a name we - have followed due to a CNAME. If the name is original, set an - authoritative name error in the response and exit. Otherwise - just exit. - - If the "*" label does exist, match RRs at that node against - QTYPE. If any match, copy them into the answer section, but - set the owner of the RR to be QNAME, and not the node with the - "*" label. Go to step 6. - - - - - -Crawford Standards Track [Page 4] - -RFC 2672 Non-Terminal DNS Name Redirection August 1999 - - - 4. Start matching down in the cache. If QNAME is found in the cache, - copy all RRs attached to it that match QTYPE into the answer - section. If QNAME is not found in the cache but a DNAME record is - present at an ancestor of QNAME, copy that DNAME record into the - answer section. If there was no delegation from authoritative - data, look for the best one from the cache, and put it in the - authority section. Go to step 6. - - 5. Use the local resolver or a copy of its algorithm (see resolver - section of this memo) to answer the query. Store the results, - including any intermediate CNAMEs and DNAMEs, in the answer - section of the response. - - 6. Using local data only, attempt to add other RRs which may be - useful to the additional section of the query. Exit. - - Note that there will be at most one ancestor with a DNAME as - described in step 4 unless some zone's data is in violation of the - no-descendants limitation in section 3. An implementation might take - advantage of this limitation by stopping the search of step 3c or - step 4 when a DNAME record is encountered. - -4.2. Processing by Resolvers - - A resolver or a server providing recursive service must be modified - to treat a DNAME as somewhat analogous to a CNAME. The resolver - algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d - as 4.e and insert a new 4.d. The complete algorithm becomes: - - 1. See if the answer is in local information, and if so return it to - the client. - - 2. Find the best servers to ask. - - 3. Send them queries until one returns a response. - - 4. Analyze the response, either: - - a. if the response answers the question or contains a name error, - cache the data as well as returning it back to the client. - - b. if the response contains a better delegation to other servers, - cache the delegation information, and go to step 2. - - c. if the response shows a CNAME and that is not the answer - itself, cache the CNAME, change the SNAME to the canonical name - in the CNAME RR and go to step 1. - - - - -Crawford Standards Track [Page 5] - -RFC 2672 Non-Terminal DNS Name Redirection August 1999 - - - d. if the response shows a DNAME and that is not the answer - itself, cache the DNAME. If substitution of the DNAME's - <target> for its <owner> in the SNAME would overflow the legal - size for a <domain-name>, return an implementation-dependent - error to the application; otherwise perform the substitution - and go to step 1. - - e. if the response shows a server failure or other bizarre - contents, delete the server from the SLIST and go back to step - 3. - - A resolver or recursive server which understands DNAME records but - sends non-extended queries MUST augment step 4.c by deleting from the - reply any CNAME records which have an <owner> which is a subdomain of - the <owner> of any DNAME record in the response. - -5. Examples of Use - -5.1. Organizational Renaming - - If an organization with domain name FROBOZZ.EXAMPLE became part of an - organization with domain name ACME.EXAMPLE, it might ease transition - by placing information such as this in its old zone. - - frobozz.example. DNAME frobozz-division.acme.example. - MX 10 mailhub.acme.example. - - The response to an extended recursive query for www.frobozz.example - would contain, in the answer section, the DNAME record shown above - and the relevant RRs for www.frobozz-division.acme.example. - -5.2. Classless Delegation of Shorter Prefixes - - The classless scheme for in-addr.arpa delegation [INADDR] can be - extended to prefixes shorter than 24 bits by use of the DNAME record. - For example, the prefix 192.0.8.0/22 can be delegated by the - following records. - - $ORIGIN 0.192.in-addr.arpa. - 8/22 NS ns.slash-22-holder.example. - 8 DNAME 8.8/22 - 9 DNAME 9.8/22 - 10 DNAME 10.8/22 - 11 DNAME 11.8/22 - - - - - - - -Crawford Standards Track [Page 6] - -RFC 2672 Non-Terminal DNS Name Redirection August 1999 - - - A typical entry in the resulting reverse zone for some host with - address 192.0.9.33 might be - - $ORIGIN 8/22.0.192.in-addr.arpa. - 33.9 PTR somehost.slash-22-holder.example. - - The same advisory remarks concerning the choice of the "/" character - apply here as in [INADDR]. - -5.3. Network Renumbering Support - - If IPv4 network renumbering were common, maintenance of address space - delegation could be simplified by using DNAME records instead of NS - records to delegate. - - $ORIGIN new-style.in-addr.arpa. - 189.190 DNAME in-addr.example.net. - - $ORIGIN in-addr.example.net. - 188 DNAME in-addr.customer.example. - - $ORIGIN in-addr.customer.example. - 1 PTR www.customer.example. - 2 PTR mailhub.customer.example. - ; etc ... - - This would allow the address space 190.189.0.0/16 assigned to the ISP - "example.net" to be changed without the necessity of altering the - zone files describing the use of that space by the ISP and its - customers. - - Renumbering IPv4 networks is currently so arduous a task that - updating the DNS is only a small part of the labor, so this scheme - may have a low value. But it is hoped that in IPv6 the renumbering - task will be quite different and the DNAME mechanism may play a - useful part. - -6. IANA Considerations - - This document defines a new DNS Resource Record type with the - mnemonic DNAME and type code 39 (decimal). The naming/numbering - space is defined in [DNSIS]. This name and number have already been - registered with the IANA. - - - - - - - - -Crawford Standards Track [Page 7] - -RFC 2672 Non-Terminal DNS Name Redirection August 1999 - - -7. Security Considerations - - The DNAME record is similar to the CNAME record with regard to the - consequences of insertion of a spoofed record into a DNS server or - resolver, differing in that the DNAME's effect covers a whole subtree - of the name space. The facilities of [DNSSEC] are available to - authenticate this record type. - -8. References - - [DNSCF] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [DNSCLR] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [DNSIS] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [DNSSEC] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System - Security Extensions", RFC 2065, January 1997. - - [DNSUPD] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound, - "Dynamic Updates in the Domain Name System", RFC 2136, April - 1997. - - [EDNS0] Vixie, P., "Extensions mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [INADDR] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN- - ADDR.ARPA delegation", RFC 2317, March 1998. - - [KWORD] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels," BCP 14, RFC 2119, March 1997. - - [SECDYN] D. Eastlake, 3rd, "Secure Domain Name System Dynamic - Update", RFC 2137, April 1997. - -9. Author's Address - - Matt Crawford - Fermilab MS 368 - PO Box 500 - Batavia, IL 60510 - USA - - Phone: +1 630 840-3461 - EMail: crawdad@fnal.gov - - - -Crawford Standards Track [Page 8] - -RFC 2672 Non-Terminal DNS Name Redirection August 1999 - - -10. Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Crawford Standards Track [Page 9] - diff --git a/contrib/bind9/doc/rfc/rfc2673.txt b/contrib/bind9/doc/rfc/rfc2673.txt deleted file mode 100644 index 19d272e92999..000000000000 --- a/contrib/bind9/doc/rfc/rfc2673.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -Network Working Group M. Crawford -Request for Comments: 2673 Fermilab -Category: Standards Track August 1999 - - - Binary Labels in the Domain Name System - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - -1. Introduction and Terminology - - This document defines a "Bit-String Label" which may appear within - domain names. This new label type compactly represents a sequence of - "One-Bit Labels" and enables resource records to be stored at any - bit-boundary in a binary-named section of the domain name tree. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [KWORD]. - -2. Motivation - - Binary labels are intended to efficiently solve the problem of - storing data and delegating authority on arbitrary boundaries when - the structure of underlying name space is most naturally represented - in binary. - -3. Label Format - - Up to 256 One-Bit Labels can be grouped into a single Bit-String - Label. Within a Bit-String Label the most significant or "highest - level" bit appears first. This is unlike the ordering of DNS labels - themselves, which has the least significant or "lowest level" label - first. Nonetheless, this ordering seems to be the most natural and - efficient for representing binary labels. - - - - - - -Crawford Standards Track [Page 1] - -RFC 2673 Binary Labels in the Domain Name System August 1999 - - - Among consecutive Bit-String Labels, the bits in the first-appearing - label are less significant or "at a lower level" than the bits in - subsequent Bit-String Labels, just as ASCII labels are ordered. - -3.1. Encoding - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 . . . - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+ - |0 1| ELT | Count | Label ... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+ - - (Each tic mark represents one bit.) - - - ELT 000001 binary, the six-bit extended label type [EDNS0] - assigned to the Bit-String Label. - - Count The number of significant bits in the Label field. A Count - value of zero indicates that 256 bits are significant. - (Thus the null label representing the DNS root cannot be - represented as a Bit String Label.) - - Label The bit string representing a sequence of One-Bit Labels, - with the most significant bit first. That is, the One-Bit - Label in position 17 in the diagram above represents a - subdomain of the domain represented by the One-Bit Label in - position 16, and so on. - - The Label field is padded on the right with zero to seven - pad bits to make the entire field occupy an integral number - of octets. These pad bits MUST be zero on transmission and - ignored on reception. - - A sequence of bits may be split into two or more Bit-String Labels, - but the division points have no significance and need not be - preserved. An excessively clever server implementation might split - Bit-String Labels so as to maximize the effectiveness of message - compression [DNSIS]. A simpler server might divide Bit-String Labels - at zone boundaries, if any zone boundaries happen to fall between - One-Bit Labels. - -3.2. Textual Representation - - A Bit-String Label is represented in text -- in a zone file, for - example -- as a <bit-spec> surrounded by the delimiters "\[" and "]". - The <bit-spec> is either a dotted quad or a base indicator and a - sequence of digits appropriate to that base, optionally followed by a - - - -Crawford Standards Track [Page 2] - -RFC 2673 Binary Labels in the Domain Name System August 1999 - - - slash and a length. The base indicators are "b", "o" and "x", - denoting base 2, 8 and 16 respectively. The length counts the - significant bits and MUST be between 1 and 32, inclusive, after a - dotted quad, or between 1 and 256, inclusive, after one of the other - forms. If the length is omitted, the implicit length is 32 for a - dotted quad or 1, 3 or 4 times the number of binary, octal or - hexadecimal digits supplied, respectively, for the other forms. - - In augmented Backus-Naur form [ABNF], - - bit-string-label = "\[" bit-spec "]" - - bit-spec = bit-data [ "/" length ] - / dotted-quad [ "/" slength ] - - bit-data = "x" 1*64HEXDIG - / "o" 1*86OCTDIG - / "b" 1*256BIT - - dotted-quad = decbyte "." decbyte "." decbyte "." decbyte - - decbyte = 1*3DIGIT - - length = NZDIGIT *2DIGIT - - slength = NZDIGIT [ DIGIT ] - - OCTDIG = %x30-37 - - NZDIGIT = %x31-39 - - If a <length> is present, the number of digits in the <bit-data> MUST - be just sufficient to contain the number of bits specified by the - <length>. If there are insignificant bits in a final hexadecimal or - octal digit, they MUST be zero. A <dotted-quad> always has all four - parts even if the associated <slength> is less than 24, but, like the - other forms, insignificant bits MUST be zero. - - Each number represented by a <decbyte> must be between 0 and 255, - inclusive. - - The number represented by <length> must be between 1 and 256 - inclusive. - - The number represented by <slength> must be between 1 and 32 - inclusive. - - - - - -Crawford Standards Track [Page 3] - -RFC 2673 Binary Labels in the Domain Name System August 1999 - - - When the textual form of a Bit-String Label is generated by machine, - the length SHOULD be explicit, not implicit. - -3.2.1. Examples - - The following four textual forms represent the same Bit-String Label. - - \[b11010000011101] - \[o64072/14] - \[xd074/14] - \[208.116.0.0/14] - - The following represents two consecutive Bit-String Labels which - denote the same relative point in the DNS tree as any of the above - single Bit-String Labels. - - \[b11101].\[o640] - -3.3. Canonical Representation and Sort Order - - Both the wire form and the text form of binary labels have a degree - of flexibility in their grouping into multiple consecutive Bit-String - Labels. For generating and checking DNS signature records [DNSSEC] - binary labels must be in a predictable form. This canonical form is - defined as the form which has the fewest possible Bit-String Labels - and in which all except possibly the first (least significant) label - in any sequence of consecutive Bit-String Labels is of maximum - length. - - For example, the canonical form of any sequence of up to 256 One-Bit - Labels has a single Bit-String Label, and the canonical form of a - sequence of 513 to 768 One-Bit Labels has three Bit-String Labels of - which the second and third contain 256 label bits. - - The canonical sort order of domain names [DNSSEC] is extended to - encompass binary labels as follows. Sorting is still label-by-label, - from most to least significant, where a label may now be a One-Bit - Label or a standard (code 00) label. Any One-Bit Label sorts before - any standard label, and a 0 bit sorts before a 1 bit. The absence of - a label sorts before any label, as specified in [DNSSEC]. - - - - - - - - - - - -Crawford Standards Track [Page 4] - -RFC 2673 Binary Labels in the Domain Name System August 1999 - - - For example, the following domain names are correctly sorted. - - foo.example - \[b1].foo.example - \[b100].foo.example - \[b101].foo.example - bravo.\[b10].foo.example - alpha.foo.example - -4. Processing Rules - - A One-Bit Label never matches any other kind of label. In - particular, the DNS labels represented by the single ASCII characters - "0" and "1" do not match One-Bit Labels represented by the bit values - 0 and 1. - -5. Discussion - - A Count of zero in the wire-form represents a 256-bit sequence, not - to optimize that particular case, but to make it completely - impossible to have a zero-bit label. - -6. IANA Considerations - - This document defines one Extended Label Type, termed the Bit-String - Label, and requests registration of the code point 000001 binary in - the space defined by [EDNS0]. - -7. Security Considerations - - All security considerations which apply to traditional ASCII DNS - labels apply equally to binary labels. he canonicalization and - sorting rules of section 3.3 allow these to be addressed by DNS - Security [DNSSEC]. - - - - - - - - - - - - - - - - - -Crawford Standards Track [Page 5] - -RFC 2673 Binary Labels in the Domain Name System August 1999 - - -8. References - - [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [DNSIS] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [DNSSEC] Eastlake, D., 3rd, C. Kaufman, "Domain Name System Security - Extensions", RFC 2065, January 1997 - - [EDNS0] Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC 2671, - August 1999. - - [KWORD] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels," BCP 14, RFC 2119, March 1997. - -9. Author's Address - - Matt Crawford - Fermilab MS 368 - PO Box 500 - Batavia, IL 60510 - USA - - Phone: +1 630 840-3461 - EMail: crawdad@fnal.gov - - - - - - - - - - - - - - - - - - - - - - - - -Crawford Standards Track [Page 6] - -RFC 2673 Binary Labels in the Domain Name System August 1999 - - -10. Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Crawford Standards Track [Page 7] - diff --git a/contrib/bind9/doc/rfc/rfc2782.txt b/contrib/bind9/doc/rfc/rfc2782.txt deleted file mode 100644 index 1827f104c838..000000000000 --- a/contrib/bind9/doc/rfc/rfc2782.txt +++ /dev/null @@ -1,675 +0,0 @@ - - - - - - -Network Working Group A. Gulbrandsen -Request for Comments: 2782 Troll Technologies -Obsoletes: 2052 P. Vixie -Category: Standards Track Internet Software Consortium - L. Esibov - Microsoft Corp. - February 2000 - - - A DNS RR for specifying the location of services (DNS SRV) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - This document describes a DNS RR which specifies the location of the - server(s) for a specific protocol and domain. - -Overview and rationale - - Currently, one must either know the exact address of a server to - contact it, or broadcast a question. - - The SRV RR allows administrators to use several servers for a single - domain, to move services from host to host with little fuss, and to - designate some hosts as primary servers for a service and others as - backups. - - Clients ask for a specific service/protocol for a specific domain - (the word domain is used here in the strict RFC 1034 sense), and get - back the names of any available servers. - - Note that where this document refers to "address records", it means A - RR's, AAAA RR's, or their most modern equivalent. - - - - - - - -Gulbrandsen, et al. Standards Track [Page 1] - -RFC 2782 DNS SRV RR February 2000 - - -Definitions - - The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" - used in this document are to be interpreted as specified in [BCP 14]. - Other terms used in this document are defined in the DNS - specification, RFC 1034. - -Applicability Statement - - In general, it is expected that SRV records will be used by clients - for applications where the relevant protocol specification indicates - that clients should use the SRV record. Such specification MUST - define the symbolic name to be used in the Service field of the SRV - record as described below. It also MUST include security - considerations. Service SRV records SHOULD NOT be used in the absence - of such specification. - -Introductory example - - If a SRV-cognizant LDAP client wants to discover a LDAP server that - supports TCP protocol and provides LDAP service for the domain - example.com., it does a lookup of - - _ldap._tcp.example.com - - as described in [ARM]. The example zone file near the end of this - memo contains answering RRs for an SRV query. - - Note: LDAP is chosen as an example for illustrative purposes only, - and the LDAP examples used in this document should not be considered - a definitive statement on the recommended way for LDAP to use SRV - records. As described in the earlier applicability section, consult - the appropriate LDAP documents for the recommended procedures. - -The format of the SRV RR - - Here is the format of the SRV RR, whose DNS type code is 33: - - _Service._Proto.Name TTL Class SRV Priority Weight Port Target - - (There is an example near the end of this document.) - - Service - The symbolic name of the desired service, as defined in Assigned - Numbers [STD 2] or locally. An underscore (_) is prepended to - the service identifier to avoid collisions with DNS labels that - occur in nature. - - - - -Gulbrandsen, et al. Standards Track [Page 2] - -RFC 2782 DNS SRV RR February 2000 - - - Some widely used services, notably POP, don't have a single - universal name. If Assigned Numbers names the service - indicated, that name is the only name which is legal for SRV - lookups. The Service is case insensitive. - - Proto - The symbolic name of the desired protocol, with an underscore - (_) prepended to prevent collisions with DNS labels that occur - in nature. _TCP and _UDP are at present the most useful values - for this field, though any name defined by Assigned Numbers or - locally may be used (as for Service). The Proto is case - insensitive. - - Name - The domain this RR refers to. The SRV RR is unique in that the - name one searches for is not this name; the example near the end - shows this clearly. - - TTL - Standard DNS meaning [RFC 1035]. - - Class - Standard DNS meaning [RFC 1035]. SRV records occur in the IN - Class. - - Priority - The priority of this target host. A client MUST attempt to - contact the target host with the lowest-numbered priority it can - reach; target hosts with the same priority SHOULD be tried in an - order defined by the weight field. The range is 0-65535. This - is a 16 bit unsigned integer in network byte order. - - Weight - A server selection mechanism. The weight field specifies a - relative weight for entries with the same priority. Larger - weights SHOULD be given a proportionately higher probability of - being selected. The range of this number is 0-65535. This is a - 16 bit unsigned integer in network byte order. Domain - administrators SHOULD use Weight 0 when there isn't any server - selection to do, to make the RR easier to read for humans (less - noisy). In the presence of records containing weights greater - than 0, records with weight 0 should have a very small chance of - being selected. - - In the absence of a protocol whose specification calls for the - use of other weighting information, a client arranges the SRV - RRs of the same Priority in the order in which target hosts, - - - - -Gulbrandsen, et al. Standards Track [Page 3] - -RFC 2782 DNS SRV RR February 2000 - - - specified by the SRV RRs, will be contacted. The following - algorithm SHOULD be used to order the SRV RRs of the same - priority: - - To select a target to be contacted next, arrange all SRV RRs - (that have not been ordered yet) in any order, except that all - those with weight 0 are placed at the beginning of the list. - - Compute the sum of the weights of those RRs, and with each RR - associate the running sum in the selected order. Then choose a - uniform random number between 0 and the sum computed - (inclusive), and select the RR whose running sum value is the - first in the selected order which is greater than or equal to - the random number selected. The target host specified in the - selected SRV RR is the next one to be contacted by the client. - Remove this SRV RR from the set of the unordered SRV RRs and - apply the described algorithm to the unordered SRV RRs to select - the next target host. Continue the ordering process until there - are no unordered SRV RRs. This process is repeated for each - Priority. - - Port - The port on this target host of this service. The range is 0- - 65535. This is a 16 bit unsigned integer in network byte order. - This is often as specified in Assigned Numbers but need not be. - - Target - The domain name of the target host. There MUST be one or more - address records for this name, the name MUST NOT be an alias (in - the sense of RFC 1034 or RFC 2181). Implementors are urged, but - not required, to return the address record(s) in the Additional - Data section. Unless and until permitted by future standards - action, name compression is not to be used for this field. - - A Target of "." means that the service is decidedly not - available at this domain. - -Domain administrator advice - - Expecting everyone to update their client applications when the first - server publishes a SRV RR is futile (even if desirable). Therefore - SRV would have to coexist with address record lookups for existing - protocols, and DNS administrators should try to provide address - records to support old clients: - - - Where the services for a single domain are spread over several - hosts, it seems advisable to have a list of address records at - the same DNS node as the SRV RR, listing reasonable (if perhaps - - - -Gulbrandsen, et al. Standards Track [Page 4] - -RFC 2782 DNS SRV RR February 2000 - - - suboptimal) fallback hosts for Telnet, NNTP and other protocols - likely to be used with this name. Note that some programs only - try the first address they get back from e.g. gethostbyname(), - and we don't know how widespread this behavior is. - - - Where one service is provided by several hosts, one can either - provide address records for all the hosts (in which case the - round-robin mechanism, where available, will share the load - equally) or just for one (presumably the fastest). - - - If a host is intended to provide a service only when the main - server(s) is/are down, it probably shouldn't be listed in - address records. - - - Hosts that are referenced by backup address records must use the - port number specified in Assigned Numbers for the service. - - - Designers of future protocols for which "secondary servers" is - not useful (or meaningful) may choose to not use SRV's support - for secondary servers. Clients for such protocols may use or - ignore SRV RRs with Priority higher than the RR with the lowest - Priority for a domain. - - Currently there's a practical limit of 512 bytes for DNS replies. - Until all resolvers can handle larger responses, domain - administrators are strongly advised to keep their SRV replies below - 512 bytes. - - All round numbers, wrote Dr. Johnson, are false, and these numbers - are very round: A reply packet has a 30-byte overhead plus the name - of the service ("_ldap._tcp.example.com" for instance); each SRV RR - adds 20 bytes plus the name of the target host; each NS RR in the NS - section is 15 bytes plus the name of the name server host; and - finally each A RR in the additional data section is 20 bytes or so, - and there are A's for each SRV and NS RR mentioned in the answer. - This size estimate is extremely crude, but shouldn't underestimate - the actual answer size by much. If an answer may be close to the - limit, using a DNS query tool (e.g. "dig") to look at the actual - answer is a good idea. - -The "Weight" field - - Weight, the server selection field, is not quite satisfactory, but - the actual load on typical servers changes much too quickly to be - kept around in DNS caches. It seems to the authors that offering - administrators a way to say "this machine is three times as fast as - that one" is the best that can practically be done. - - - - -Gulbrandsen, et al. Standards Track [Page 5] - -RFC 2782 DNS SRV RR February 2000 - - - The only way the authors can see of getting a "better" load figure is - asking a separate server when the client selects a server and - contacts it. For short-lived services an extra step in the - connection establishment seems too expensive, and for long-lived - services, the load figure may well be thrown off a minute after the - connection is established when someone else starts or finishes a - heavy job. - - Note: There are currently various experiments at providing relative - network proximity estimation, available bandwidth estimation, and - similar services. Use of the SRV record with such facilities, and in - particular the interpretation of the Weight field when these - facilities are used, is for further study. Weight is only intended - for static, not dynamic, server selection. Using SRV weight for - dynamic server selection would require assigning unreasonably short - TTLs to the SRV RRs, which would limit the usefulness of the DNS - caching mechanism, thus increasing overall network load and - decreasing overall reliability. Server selection via SRV is only - intended to express static information such as "this server has a - faster CPU than that one" or "this server has a much better network - connection than that one". - -The Port number - - Currently, the translation from service name to port number happens - at the client, often using a file such as /etc/services. - - Moving this information to the DNS makes it less necessary to update - these files on every single computer of the net every time a new - service is added, and makes it possible to move standard services out - of the "root-only" port range on unix. - -Usage rules - - A SRV-cognizant client SHOULD use this procedure to locate a list of - servers and connect to the preferred one: - - Do a lookup for QNAME=_service._protocol.target, QCLASS=IN, - QTYPE=SRV. - - If the reply is NOERROR, ANCOUNT>0 and there is at least one - SRV RR which specifies the requested Service and Protocol in - the reply: - - If there is precisely one SRV RR, and its Target is "." - (the root domain), abort. - - - - - -Gulbrandsen, et al. Standards Track [Page 6] - -RFC 2782 DNS SRV RR February 2000 - - - Else, for all such RR's, build a list of (Priority, Weight, - Target) tuples - - Sort the list by priority (lowest number first) - - Create a new empty list - - For each distinct priority level - While there are still elements left at this priority - level - - Select an element as specified above, in the - description of Weight in "The format of the SRV - RR" Section, and move it to the tail of the new - list - - For each element in the new list - - query the DNS for address records for the Target or - use any such records found in the Additional Data - section of the earlier SRV response. - - for each address record found, try to connect to the - (protocol, address, service). - - else - - Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A - - for each address record found, try to connect to the - (protocol, address, service) - -Notes: - - - Port numbers SHOULD NOT be used in place of the symbolic service - or protocol names (for the same reason why variant names cannot - be allowed: Applications would have to do two or more lookups). - - - If a truncated response comes back from an SRV query, the rules - described in [RFC 2181] shall apply. - - - A client MUST parse all of the RR's in the reply. - - - If the Additional Data section doesn't contain address records - for all the SRV RR's and the client may want to connect to the - target host(s) involved, the client MUST look up the address - record(s). (This happens quite often when the address record - has shorter TTL than the SRV or NS RR's.) - - - -Gulbrandsen, et al. Standards Track [Page 7] - -RFC 2782 DNS SRV RR February 2000 - - - - Future protocols could be designed to use SRV RR lookups as the - means by which clients locate their servers. - -Fictional example - - This example uses fictional service "foobar" as an aid in - understanding SRV records. If ever service "foobar" is implemented, - it is not intended that it will necessarily use SRV records. This is - (part of) the zone file for example.com, a still-unused domain: - - $ORIGIN example.com. - @ SOA server.example.com. root.example.com. ( - 1995032001 3600 3600 604800 86400 ) - NS server.example.com. - NS ns1.ip-provider.net. - NS ns2.ip-provider.net. - ; foobar - use old-slow-box or new-fast-box if either is - ; available, make three quarters of the logins go to - ; new-fast-box. - _foobar._tcp SRV 0 1 9 old-slow-box.example.com. - SRV 0 3 9 new-fast-box.example.com. - ; if neither old-slow-box or new-fast-box is up, switch to - ; using the sysdmin's box and the server - SRV 1 0 9 sysadmins-box.example.com. - SRV 1 0 9 server.example.com. - server A 172.30.79.10 - old-slow-box A 172.30.79.11 - sysadmins-box A 172.30.79.12 - new-fast-box A 172.30.79.13 - ; NO other services are supported - *._tcp SRV 0 0 0 . - *._udp SRV 0 0 0 . - - - - - - - - - - - - - - - - - - - -Gulbrandsen, et al. Standards Track [Page 8] - -RFC 2782 DNS SRV RR February 2000 - - - In this example, a client of the "foobar" service in the - "example.com." domain needs an SRV lookup of - "_foobar._tcp.example.com." and possibly A lookups of "new-fast- - box.example.com." and/or the other hosts named. The size of the SRV - reply is approximately 365 bytes: - - 30 bytes general overhead - 20 bytes for the query string, "_foobar._tcp.example.com." - 130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new- - fast-box", "old-slow-box", "server" and "sysadmins-box" - - "example.com" in the query section is quoted here and doesn't - need to be counted again. - 75 bytes for 3 NS RRs, 15 bytes each plus the lengths of "server", - "ns1.ip-provider.net." and "ns2" - again, "ip-provider.net." is - quoted and only needs to be counted once. - 120 bytes for the 6 address records (assuming IPv4 only) mentioned - by the SRV and NS RR's. - -IANA Considerations - - The IANA has assigned RR type value 33 to the SRV RR. No other IANA - services are required by this document. - -Changes from RFC 2052 - - This document obsoletes RFC 2052. The major change from that - previous, experimental, version of this specification is that now the - protocol and service labels are prepended with an underscore, to - lower the probability of an accidental clash with a similar name used - for unrelated purposes. Aside from that, changes are only intended - to increase the clarity and completeness of the document. This - document especially clarifies the use of the Weight field of the SRV - records. - -Security Considerations - - The authors believe this RR to not cause any new security problems. - Some problems become more visible, though. - - - The ability to specify ports on a fine-grained basis obviously - changes how a router can filter packets. It becomes impossible - to block internal clients from accessing specific external - services, slightly harder to block internal users from running - unauthorized services, and more important for the router - operations and DNS operations personnel to cooperate. - - - There is no way a site can keep its hosts from being referenced - as servers. This could lead to denial of service. - - - -Gulbrandsen, et al. Standards Track [Page 9] - -RFC 2782 DNS SRV RR February 2000 - - - - With SRV, DNS spoofers can supply false port numbers, as well as - host names and addresses. Because this vulnerability exists - already, with names and addresses, this is not a new - vulnerability, merely a slightly extended one, with little - practical effect. - -References - - STD 2: Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC - 1700, October 1994. - - RFC 1034: Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - RFC 1035: Mockapetris, P., "Domain names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - RFC 974: Partridge, C., "Mail routing and the domain system", STD - 14, RFC 974, January 1986. - - BCP 14: Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - RFC 2181: Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - RFC 2219: Hamilton, M. and R. Wright, "Use of DNS Aliases for Network - Services", BCP 17, RFC 2219, October 1997. - - BCP 14: Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - ARM: Armijo, M., Esibov, L. and P. Leach, "Discovering LDAP - Services with DNS", Work in Progress. - - KDC-DNS: Hornstein, K. and J. Altman, "Distributing Kerberos KDC and - Realm Information with DNS", Work in Progress. - - - - - - - - - - - - - - -Gulbrandsen, et al. Standards Track [Page 10] - -RFC 2782 DNS SRV RR February 2000 - - -Acknowledgements - - The algorithm used to select from the weighted SRV RRs of equal - priority is adapted from one supplied by Dan Bernstein. - -Authors' Addresses - - Arnt Gulbrandsen - Troll Tech - Waldemar Thranes gate 98B - N-0175 Oslo, Norway - - Fax: +47 22806380 - Phone: +47 22806390 - EMail: arnt@troll.no - - - Paul Vixie - Internet Software Consortium - 950 Charter Street - Redwood City, CA 94063 - - Phone: +1 650 779 7001 - - - Levon Esibov - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - - EMail: levone@microsoft.com - - - - - - - - - - - - - - - - - - - - -Gulbrandsen, et al. Standards Track [Page 11] - -RFC 2782 DNS SRV RR February 2000 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Gulbrandsen, et al. Standards Track [Page 12] - diff --git a/contrib/bind9/doc/rfc/rfc2825.txt b/contrib/bind9/doc/rfc/rfc2825.txt deleted file mode 100644 index fd8ef7c892da..000000000000 --- a/contrib/bind9/doc/rfc/rfc2825.txt +++ /dev/null @@ -1,395 +0,0 @@ -
-
-
-
-
-
-Network Working Group Internet Architecture Board (IAB)
-Request for Comments: 2825 L. Daigle, Editor
-Category: Informational May 2000
-
-
- A Tangled Web: Issues of I18N, Domain Names, and the
- Other Internet protocols
-
-Status of this Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard of any kind. Distribution of this
- memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-Abstract
-
- The goals of the work to "internationalize" Internet protocols
- include providing all users of the Internet with the capability of
- using their own language and its standard character set to express
- themselves, write names, and to navigate the network. This impacts
- the domain names visible in e-mail addresses and so many of today's
- URLs used to locate information on the World Wide Web, etc. However,
- domain names are used by Internet protocols that are used across
- national boundaries. These services must interoperate worldwide, or
- we risk isolating components of the network from each other along
- locale boundaries. This type of isolation could impede not only
- communications among people, but opportunities of the areas involved
- to participate effectively in e-commerce, distance learning, and
- other activities at an international scale, thereby retarding
- economic development.
-
- There are several proposals for internationalizing domain names,
- however it it is still to be determined whether any of them will
- ensure this interoperability and global reach while addressing
- visible-name representation. Some of them obviously do not. This
- document does not attempt to review any specific proposals, as that
- is the work of the Internationalized Domain Name (IDN) Working Group
- of the IETF, which is tasked with evaluating them in consideration of
- the continued global network interoperation that is the deserved
- expectation of all Internet users.
-
-
-
-
-
-
-
-IAB Informational [Page 1]
-
-RFC 2825 Issues: I18N, Domain Names, and Internet Protocols May 2000
-
-
- This document is a statement by the Internet Architecture Board. It
- is not a protocol specification, but an attempt to clarify the range
- of architectural issues that the internationalization of domain names
- faces.
-
-1. A Definition of Success
-
- The Internationalized Domain Names (IDN) Working Group is one
- component of the IETF's continuing comprehensive effort to
- internationalize language representation facilities in the protocols
- that support the global functioning of the Internet.
-
- In keeping with the principles of rough consensus, running code,
- architectural integrity, and in the interest of ensuring the global
- stability of the Internet, the IAB emphasizes that all solutions
- proposed to the (IDN) Working Group will have to be evaluated not
- only on their individual technical features, but also in terms of
- impact on existing standards and operations of the Internet and the
- total effect for end-users: solutions must not cause users to become
- more isolated from their global neighbors even if they appear to
- solve a local problem. In some cases, existing protocols have
- limitations on allowable characters, and in other cases
- implementations of protocols used in the core of the Internet (beyond
- individual organizations) have in practice not implemented all the
- requisite options of the standards.
-
-2. Technical Challenges within the Domain Name System (DNS)
-
- In many technical respects, the IDN work is not different from any
- other effort to enable multiple character set representations in
- textual elements that were traditionally restricted to English
- language characters.
-
- One aspect of the challenge is to decide how to represent the names
- users want in the DNS in a way that is clear, technically feasible,
- and ensures that a name always means the same thing. Several
- proposals have been suggested to address these issues.
-
- These issues are being outlined in more detail in the IDN WG's
- evolving draft requirements document; further discussion is deferred
- to the WG and its documents.
-
-3. Integrating with Current Realities
-
- Nevertheless, issues faced by the IDN working group are complex and
- intricately intertwined with other operational components of the
- Internet. A key challenge in evaluating any proposed solution is the
- analysis of the impact on existing critical operational standards
-
-
-
-IAB Informational [Page 2]
-
-RFC 2825 Issues: I18N, Domain Names, and Internet Protocols May 2000
-
-
- which use fully-qualified domain names [RFC1034], or simply host
- names [RFC1123]. Standards-changes can be effected, but the best
- path forward is one that takes into account current realities and
- (re)deployment latencies. In the Internet's global context, it is not
- enough to update a few isolated systems, or even most of the systems
- in a country or region. Deployment must be nearly universal in order
- to avoid the creation of "islands" of interoperation that provide
- users with less access to and connection from the rest of the world.
-
- These are not esoteric or ephemeral concerns. Some specific issues
- have already been identified as part of the IDN WG's efforts. These
- include (but are not limited to) the following examples.
-
-3.1 Domain Names and E-mail
-
- As indicated in the IDN WG's draft requirements document, the issue
- goes beyond standardization of DNS usage. Electronic mail has long
- been one of the most-used and most important applications of the
- Internet. Internet e-mail is also used as the bridge that permits
- the users of a variety of local and proprietary mail systems to
- communicate. The standard protocols that define its use (e.g., SMTP
- [RFC821, RFC822] and MIME [RFC2045]) do not permit the full range of
- characters allowed in the DNS specification. Certain characters are
- not allowed in e-mail address domain portions of these
- specifications. Some mailers, built to adhere to these
- specifications, are known to fail when on mail having non-ASCII
- domain names in its address -- by discarding, misrouting or damaging
- the mail. Thus, it's not possible to simply switch to
- internationalized domain names and expect global e-mail to continue
- to work until most of the servers in the world are upgraded.
-
-3.2 Domain Names and Routing
-
- At a lower level, the Routing Policy Specification Language (RPLS)
- [RFC2622] makes use of "named objects" -- and inherits object naming
- restrictions from older standards ([RFC822] for the same e-mail
- address restrictions, [RFC1034] for hostnames). This means that
- until routing registries and their protocols are updated, it is not
- possible to enter or retrieve network descriptions utilizing
- internationalized domain names.
-
-3.3 Domain Names and Network Management
-
- Also, the Simple Network Management Protocol (SNMP) uses the textual
- representation defined in [RFC2579]. While that specification does
- allow for UTF-8-based domain names, an informal survey of deployed
- implementations of software libraries being used to build SNMP-
- compliant software uncovered the fact that few (if any) implement it.
-
-
-
-IAB Informational [Page 3]
-
-RFC 2825 Issues: I18N, Domain Names, and Internet Protocols May 2000
-
-
- This may cause inability to enter or display correct data in network
- management tools, if such names are internationalized domain names.
-
-3.4 Domain Names and Security
-
- Critical components of Internet public key technologies (PKIX,
- [RFC2459], IKE [RFC2409]) rely heavily on identification of servers
- (hostnames, or fully qualified domain names) and users (e-mail
- addresses). Failure to respect the character restrictions in these
- protocols will impact security tools built to use them -- Transport
- Layer Security protocol (TLS, [RFC2246]), and IPsec [RFC2401] to name
- two.
-
- Failure may not be obvious. For example, in TLS, it is common usage
- for a server to display a certificate containing a domain name
- purporting to be the domain name of the server, which the client can
- then match with the server name he thought he used to reach the
- service.
-
- Unless comparison of domain names is properly defined, the client may
- either fail to match the domain name of a legitimate server, or match
- incorrectly the domain name of a server performing a man-in-the-
- middle attack. Either failure could enable attacks on systems that
- are now impossible or at least far more difficult.
-
-4. Conclusion
-
- It is therefore clear that, although there are many possible ways to
- assign internationalized names that are compatible with today's DNS
- (or a version that is easily-deployable in the near future), not all
- of them are compatible with the full range of necessary networking
- tools. When designing a solution for internationalization of domain
- names, the effects on the current Internet must be carefully
- evaluated. Some types of solutions proposed would, if put into effect
- immediately, cause Internet communications to fail in ways that would
- be hard to detect by and pose problems for those who deploy the new
- services, but also for those who do not; this would have the effect
- of cutting those who deploy them off from effective use of the
- Internet.
-
- The IDN WG has been identified as the appropriate forum for
- identifying and discussing solutions for such potential
- interoperability issues.
-
- Experience with deployment of other protocols has indicated that it
- will take years before a new protocol or enhancement is used all over
- the Internet. So far, the IDN WG has benefited from proposed
- solutions from all quarters, including organizations hoping to
-
-
-
-IAB Informational [Page 4]
-
-RFC 2825 Issues: I18N, Domain Names, and Internet Protocols May 2000
-
-
- provide services that address visible-name representation and
- registration -- continuing this process with the aim of getting a
- single, scalable and deployable solution to this problem is the only
- way to ensure the continued global interoperation that is the
- deserved expectation of all Internet users.
-
-5. Security Considerations
-
- In general, assignment and use of names does not raise any special
- security problems. However, as noted above, some existing security
- mechanisms are reliant on the current specification of domain names
- and may not be expected to work, as is, with Internationalized domain
- names. Additionally, deployment of non-standard systems (e.g., in
- response to current pressures to address national or regional
- characterset representation) might result in name strings that are
- not globally unique, thereby opening up the possibility of "spoofing"
- hosts from one domain in another, as described in [RFC2826].
-
-6. Acknowledgements
-
- This document is the outcome of the joint effort of the members of
- the IAB. Additionally, valuable remarks were provided by Randy Bush,
- Patrik Faltstrom, Ted Hardie, Paul Hoffman, and Mark Kosters.
-
-7. References
-
- [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
- 821, August 1982.
-
- [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
- Messages", STD 11, RFC 822, August 1982.
-
- [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1123] Braden, R., "Requirements for Internet Hosts -- Application
- and Support", STD 3, RFC 1123, November 1989.
-
- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
- Internet Protocol", RFC 2401, November 1998.
-
- [RFC2409] Harkins, D and D. Carrel, "The Internet Key Exchange
- (IKE)", RFC 2409, November 1998.
-
- [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part One: Format of Internet Message
- Bodies", RFC 2045, November 1996.
-
-
-
-
-IAB Informational [Page 5]
-
-RFC 2825 Issues: I18N, Domain Names, and Internet Protocols May 2000
-
-
- [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
- RFC 2246, January 1999.
-
- [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
- X.509 Public Key Infrastructure Certificate and CRL
- Profile", RFC 2459, January 1999.
-
- [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.
- and M. Rose, "Textual Conventions for SMIv2", RFC 2579,
- April 1999.
-
- [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
- Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra,
- "Routing Policy Specification Language (RPSL)", RFC 2622,
- June 1999.
-
- [RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root", RFC
- 2826, May 2000.
-
-8. Author's Address
-
- Internet Architecture Board
-
- EMail: iab@iab.org
-
-
- Membership at time this document was completed:
-
- Harald Alvestrand
- Ran Atkinson
- Rob Austein
- Brian Carpenter
- Steve Bellovin
- Jon Crowcroft
- Leslie Daigle
- Steve Deering
- Tony Hain
- Geoff Huston
- John Klensin
- Henning Schulzrinne
-
-
-
-
-
-
-
-
-
-
-
-IAB Informational [Page 6]
-
-RFC 2825 Issues: I18N, Domain Names, and Internet Protocols May 2000
-
-
-9. Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-IAB Informational [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc2826.txt b/contrib/bind9/doc/rfc/rfc2826.txt deleted file mode 100644 index b4d886968fc8..000000000000 --- a/contrib/bind9/doc/rfc/rfc2826.txt +++ /dev/null @@ -1,339 +0,0 @@ -
-
-
-
-
-
-Network Working Group Internet Architecture Board
-Request for Comments: 2826 May 2000
-Category: Informational
-
-
- IAB Technical Comment on the Unique DNS Root
-
-Status of this Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard of any kind. Distribution of this
- memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-Summary
-
- To remain a global network, the Internet requires the existence of a
- globally unique public name space. The DNS name space is a
- hierarchical name space derived from a single, globally unique root.
- This is a technical constraint inherent in the design of the DNS.
- Therefore it is not technically feasible for there to be more than
- one root in the public DNS. That one root must be supported by a set
- of coordinated root servers administered by a unique naming
- authority.
-
- Put simply, deploying multiple public DNS roots would raise a very
- strong possibility that users of different ISPs who click on the same
- link on a web page could end up at different destinations, against
- the will of the web page designers.
-
- This does not preclude private networks from operating their own
- private name spaces, but if they wish to make use of names uniquely
- defined for the global Internet, they have to fetch that information
- from the global DNS naming hierarchy, and in particular from the
- coordinated root servers of the global DNS naming hierarchy.
-
-1. Detailed Explanation
-
- There are several distinct reasons why the DNS requires a single root
- in order to operate properly.
-
-1.1. Maintenance of a Common Symbol Set
-
- Effective communications between two parties requires two essential
- preconditions:
-
-
-
-IAB Informational [Page 1]
-
-RFC 2826 IAB Technical Comment on the Unique DNS Root May 2000
-
-
- - The existence of a common symbol set, and
-
- - The existence of a common semantic interpretation of these
- symbols.
-
- Failure to meet the first condition implies a failure to communicate
- at all, while failure to meet the second implies that the meaning of
- the communication is lost.
-
- In the case of a public communications system this condition of a
- common symbol set with a common semantic interpretation must be
- further strengthened to that of a unique symbol set with a unique
- semantic interpretation. This condition of uniqueness allows any
- party to initiate a communication that can be received and understood
- by any other party. Such a condition rules out the ability to define
- a symbol within some bounded context. In such a case, once the
- communication moves out of the context of interpretation in which it
- was defined, the meaning of the symbol becomes lost.
-
- Within public digital communications networks such as the Internet
- this requirement for a uniquely defined symbol set with a uniquely
- defined meaning exists at many levels, commencing with the binary
- encoding scheme, extending to packet headers and payload formats and
- the protocol that an application uses to interact. In each case a
- variation of the symbol set or a difference of interpretation of the
- symbols being used within the interaction causes a protocol failure,
- and the communication fails. The property of uniqueness allows a
- symbol to be used unambiguously in any context, allowing the symbol
- to be passed on, referred to, and reused, while still preserving the
- meaning of the original use.
-
- The DNS fulfills an essential role within the Internet protocol
- environment, allowing network locations to be referred to using a
- label other than a protocol address. As with any other such symbol
- set, DNS names are designed to be globally unique, that is, for any
- one DNS name at any one time there must be a single set of DNS
- records uniquely describing protocol addresses, network resources and
- services associated with that DNS name. All of the applications
- deployed on the Internet which use the DNS assume this, and Internet
- users expect such behavior from DNS names. Names are then constant
- symbols, whose interpretation does not specifically require knowledge
- of the context of any individual party. A DNS name can be passed
- from one party to another without altering the semantic intent of the
- name.
-
- Since the DNS is hierarchically structured into domains, the
- uniqueness requirement for DNS names in their entirety implies that
- each of the names (sub-domains) defined within a domain has a unique
-
-
-
-IAB Informational [Page 2]
-
-RFC 2826 IAB Technical Comment on the Unique DNS Root May 2000
-
-
- meaning (i.e., set of DNS records) within that domain. This is as
- true for the root domain as for any other DNS domain. The
- requirement for uniqueness within a domain further implies that there
- be some mechanism to prevent name conflicts within a domain. In DNS
- this is accomplished by assigning a single owner or maintainer to
- every domain, including the root domain, who is responsible for
- ensuring that each sub-domain of that domain has the proper records
- associated with it. This is a technical requirement, not a policy
- choice.
-
-1.2. Coordination of Updates
-
- Both the design and implementations of the DNS protocol are heavily
- based on the assumption that there is a single owner or maintainer
- for every domain, and that any set of resources records associated
- with a domain is modified in a single-copy serializable fashion.
- That is, even assuming that a single domain could somehow be "shared"
- by uncooperating parties, there is no means within the DNS protocol
- by which a user or client could discover, and choose between,
- conflicting definitions of a DNS name made by different parties. The
- client will simply return the first set of resource records that it
- finds that matches the requested domain, and assume that these are
- valid. This protocol is embedded in the operating software of
- hundreds of millions of computer systems, and is not easily updated
- to support a shared domain scenario.
-
- Moreover, even supposing that some other means of resolving
- conflicting definitions could be provided in the future, it would
- have to be based on objective rules established in advance. For
- example, zone A.B could declare that naming authority Y had been
- delegated all subdomains of A.B with an odd number of characters, and
- that naming authority Z had been delegated authority to define
- subdomains of A.B with an even number of characters. Thus, a single
- set of rules would have to be agreed to prevent Y and Z from making
- conflicting assignments, and with this train of actions a single
- unique space has been created in any case. Even this would not allow
- multiple non-cooperating authorities to assign arbitrary sub-domains
- within a single domain.
-
- It seems that a degree of cooperation and agreed technical rules are
- required in order to guarantee the uniqueness of names. In the DNS,
- these rules are established independently for each part of the naming
- hierarchy, and the root domain is no exception. Thus, there must be
- a generally agreed single set of rules for the root.
-
-
-
-
-
-
-
-IAB Informational [Page 3]
-
-RFC 2826 IAB Technical Comment on the Unique DNS Root May 2000
-
-
-1.3. Difficulty of Relocating the Root Zone
-
- There is one specific technical respect in which the root zone
- differs from all other DNS zones: the addresses of the name servers
- for the root zone come primarily from out-of-band information. This
- out-of-band information is often poorly maintained and, unlike all
- other data in the DNS, the out-of-band information has no automatic
- timeout mechanism. It is not uncommon for this information to be
- years out of date at many sites.
-
- Like any other zone, the root zone contains a set of "name server"
- resource records listing its servers, but a resolver with no valid
- addresses for the current set of root servers will never be able to
- obtain these records. More insidiously, a resolver that has a mixed
- set of partially valid and partially stale out-of-band configuration
- information will not be able to tell which are the "real" root
- servers if it gets back conflicting answers; thus, it is very
- difficult to revoke the status of a malicious root server, or even to
- route around a buggy root server.
-
- In effect, every full-service resolver in the world "delegates" the
- root of the public tree to the public root server(s) of its choice.
-
- As a direct consequence, any change to the list of IP addresses that
- specify the public root zone is significantly more difficult than
- changing any other aspect of the DNS delegation chain. Thus,
- stability of the system calls for extremely conservative and cautious
- management of the public root zone: the frequency of updates to the
- root zone must be kept low, and the servers for the root zone must be
- closely coordinated.
-
- These problems can be ameliorated to some extent by the DNS Security
- Extensions [DNSSEC], but a similar out-of-band configuration problem
- exists for the cryptographic signature key to the root zone, so the
- root zone still requires tight coupling and coordinated management
- even in the presence of DNSSEC.
-
-2. Conclusion
-
- The DNS type of unique naming and name-mapping system may not be
- ideal for a number of purposes for which it was never designed, such
- a locating information when the user doesn't precisely know the
- correct names. As the Internet continues to expand, we would expect
- directory systems to evolve which can assist the user in dealing with
- vague or ambiguous references. To preserve the many important
- features of the DNS and its multiple record types -- including the
- Internet's equivalent of telephone number portability -- we would
- expect the result of directory lookups and identification of the
-
-
-
-IAB Informational [Page 4]
-
-RFC 2826 IAB Technical Comment on the Unique DNS Root May 2000
-
-
- correct names for a particular purpose to be unique DNS names that
- are then resolved normally, rather than having directory systems
- "replace" the DNS.
-
- There is no getting away from the unique root of the public DNS.
-
-3. Security Considerations
-
- This memo does not introduce any new security issues, but it does
- attempt to identify some of the problems inherent in a family of
- recurring technically naive proposals.
-
-4. IANA Considerations
-
- This memo is not intended to create any new issues for IANA.
-
-5. References
-
- [DNS-CONCEPTS] Mockapetris, P., "Domain Names - Concepts and
- Facilities", STD 13, RFC 1034, November 1987.
-
- [DNS-IMPLEMENTATION] Mockapetris, P., "Domain Names - Implementation
- and Specification", STD 13, RFC 1035, November
- 1987.
-
- [DNSSEC] Eastlake, D., "Domain Name System Security
- Extensions", RFC 2535, March 1999.
-
-6. Author's Address
-
- Internet Architecture Board
-
- EMail: iab@iab.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-IAB Informational [Page 5]
-
-RFC 2826 IAB Technical Comment on the Unique DNS Root May 2000
-
-
-7. Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-IAB Informational [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc2845.txt b/contrib/bind9/doc/rfc/rfc2845.txt deleted file mode 100644 index aa9f385ae354..000000000000 --- a/contrib/bind9/doc/rfc/rfc2845.txt +++ /dev/null @@ -1,843 +0,0 @@ - - - - - - -Network Working Group P. Vixie -Request for Comments: 2845 ISC -Category: Standards Track O. Gudmundsson -Updates: 1035 NAI Labs - D. Eastlake 3rd - Motorola - B. Wellington - Nominum - May 2000 - - - Secret Key Transaction Authentication for DNS (TSIG) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - This protocol allows for transaction level authentication using - shared secrets and one way hashing. It can be used to authenticate - dynamic updates as coming from an approved client, or to authenticate - responses as coming from an approved recursive name server. - - No provision has been made here for distributing the shared secrets; - it is expected that a network administrator will statically configure - name servers and clients using some out of band mechanism such as - sneaker-net until a secure automated mechanism for key distribution - is available. - -1 - Introduction - - 1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated - hierarchical distributed database system that provides information - fundamental to Internet operations, such as name <=> address - translation and mail handling information. DNS has recently been - extended [RFC2535] to provide for data origin authentication, and - public key distribution, all based on public key cryptography and - public key based digital signatures. To be practical, this form of - - - - -Vixie, et al. Standards Track [Page 1] - -RFC 2845 DNS TSIG May 2000 - - - security generally requires extensive local caching of keys and - tracing of authentication through multiple keys and signatures to a - pre-trusted locally configured key. - - 1.2. One difficulty with the [RFC2535] scheme is that common DNS - implementations include simple "stub" resolvers which do not have - caches. Such resolvers typically rely on a caching DNS server on - another host. It is impractical for these stub resolvers to perform - general [RFC2535] authentication and they would naturally depend on - their caching DNS server to perform such services for them. To do so - securely requires secure communication of queries and responses. - [RFC2535] provides public key transaction signatures to support this, - but such signatures are very expensive computationally to generate. - In general, these require the same complex public key logic that is - impractical for stubs. This document specifies use of a message - authentication code (MAC), specifically HMAC-MD5 (a keyed hash - function), to provide an efficient means of point-to-point - authentication and integrity checking for transactions. - - 1.3. A second area where use of straight [RFC2535] public key based - mechanisms may be impractical is authenticating dynamic update - [RFC2136] requests. [RFC2535] provides for request signatures but - with [RFC2535] they, like transaction signatures, require - computationally expensive public key cryptography and complex - authentication logic. Secure Domain Name System Dynamic Update - ([RFC2137]) describes how different keys are used in dynamically - updated zones. This document's secret key based MACs can be used to - authenticate DNS update requests as well as transaction responses, - providing a lightweight alternative to the protocol described by - [RFC2137]. - - 1.4. A further use of this mechanism is to protect zone transfers. - In this case the data covered would be the whole zone transfer - including any glue records sent. The protocol described by [RFC2535] - does not protect glue records and unsigned records unless SIG(0) - (transaction signature) is used. - - 1.5. The authentication mechanism proposed in this document uses - shared secret keys to establish a trust relationship between two - entities. Such keys must be protected in a fashion similar to - private keys, lest a third party masquerade as one of the intended - parties (forge MACs). There is an urgent need to provide simple and - efficient authentication between clients and local servers and this - proposal addresses that need. This proposal is unsuitable for - general server to server authentication for servers which speak with - many other servers, since key management would become unwieldy with - - - - - -Vixie, et al. Standards Track [Page 2] - -RFC 2845 DNS TSIG May 2000 - - - the number of shared keys going up quadratically. But it is suitable - for many resolvers on hosts that only talk to a few recursive - servers. - - 1.6. A server acting as an indirect caching resolver -- a "forwarder" - in common usage -- might use transaction-based authentication when - communicating with its small number of preconfigured "upstream" - servers. Other uses of DNS secret key authentication and possible - systems for automatic secret key distribution may be proposed in - separate future documents. - - 1.7. New Assigned Numbers - - RRTYPE = TSIG (250) - ERROR = 0..15 (a DNS RCODE) - ERROR = 16 (BADSIG) - ERROR = 17 (BADKEY) - ERROR = 18 (BADTIME) - - 1.8. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and - "MAY" in this document are to be interpreted as described in [RFC - 2119]. - -2 - TSIG RR Format - - 2.1 TSIG RR Type - - To provide secret key authentication, we use a new RR type whose - mnemonic is TSIG and whose type code is 250. TSIG is a meta-RR and - MUST not be cached. TSIG RRs are used for authentication between DNS - entities that have established a shared secret key. TSIG RRs are - dynamically computed to cover a particular DNS transaction and are - not DNS RRs in the usual sense. - - 2.2 TSIG Calculation - - As the TSIG RRs are related to one DNS request/response, there is no - value in storing or retransmitting them, thus the TSIG RR is - discarded once it has been used to authenticate a DNS message. The - only message digest algorithm specified in this document is "HMAC- - MD5" (see [RFC1321], [RFC2104]). The "HMAC-MD5" algorithm is - mandatory to implement for interoperability. Other algorithms can be - specified at a later date. Names and definitions of new algorithms - MUST be registered with IANA. All multi-octet integers in the TSIG - record are sent in network byte order (see [RFC1035 2.3.2]). - - - - - - -Vixie, et al. Standards Track [Page 3] - -RFC 2845 DNS TSIG May 2000 - - - 2.3. Record Format - - NAME The name of the key used in domain name syntax. The name - should reflect the names of the hosts and uniquely identify - the key among a set of keys these two hosts may share at any - given time. If hosts A.site.example and B.example.net share a - key, possibilities for the key name include - <id>.A.site.example, <id>.B.example.net, and - <id>.A.site.example.B.example.net. It should be possible for - more than one key to be in simultaneous use among a set of - interacting hosts. The name only needs to be meaningful to - the communicating hosts but a meaningful mnemonic name as - above is strongly recommended. - - The name may be used as a local index to the key involved and - it is recommended that it be globally unique. Where a key is - just shared between two hosts, its name actually only need - only be meaningful to them but it is recommended that the key - name be mnemonic and incorporate the resolver and server host - names in that order. - - TYPE TSIG (250: Transaction SIGnature) - - CLASS ANY - - TTL 0 - - RdLen (variable) - - RDATA - - Field Name Data Type Notes - -------------------------------------------------------------- - Algorithm Name domain-name Name of the algorithm - in domain name syntax. - Time Signed u_int48_t seconds since 1-Jan-70 UTC. - Fudge u_int16_t seconds of error permitted - in Time Signed. - MAC Size u_int16_t number of octets in MAC. - MAC octet stream defined by Algorithm Name. - Original ID u_int16_t original message ID - Error u_int16_t expanded RCODE covering - TSIG processing. - Other Len u_int16_t length, in octets, of - Other Data. - Other Data octet stream empty unless Error == BADTIME - - - - - -Vixie, et al. Standards Track [Page 4] - -RFC 2845 DNS TSIG May 2000 - - - 2.4. Example - - NAME HOST.EXAMPLE. - - TYPE TSIG - - CLASS ANY - - TTL 0 - - RdLen as appropriate - - RDATA - - Field Name Contents - ------------------------------------- - Algorithm Name SAMPLE-ALG.EXAMPLE. - Time Signed 853804800 - Fudge 300 - MAC Size as appropriate - MAC as appropriate - Original ID as appropriate - Error 0 (NOERROR) - Other Len 0 - Other Data empty - -3 - Protocol Operation - - 3.1. Effects of adding TSIG to outgoing message - - Once the outgoing message has been constructed, the keyed message - digest operation can be performed. The resulting message digest will - then be stored in a TSIG which is appended to the additional data - section (the ARCOUNT is incremented to reflect this). If the TSIG - record cannot be added without causing the message to be truncated, - the server MUST alter the response so that a TSIG can be included. - This response consists of only the question and a TSIG record, and - has the TC bit set and RCODE 0 (NOERROR). The client SHOULD at this - point retry the request using TCP (per [RFC1035 4.2.2]). - - 3.2. TSIG processing on incoming messages - - If an incoming message contains a TSIG record, it MUST be the last - record in the additional section. Multiple TSIG records are not - allowed. If a TSIG record is present in any other position, the - packet is dropped and a response with RCODE 1 (FORMERR) MUST be - returned. Upon receipt of a message with a correctly placed TSIG RR, - the TSIG RR is copied to a safe location, removed from the DNS - - - -Vixie, et al. Standards Track [Page 5] - -RFC 2845 DNS TSIG May 2000 - - - Message, and decremented out of the DNS message header's ARCOUNT. At - this point the keyed message digest operation is performed. If the - algorithm name or key name is unknown to the recipient, or if the - message digests do not match, the whole DNS message MUST be - discarded. If the message is a query, a response with RCODE 9 - (NOTAUTH) MUST be sent back to the originator with TSIG ERROR 17 - (BADKEY) or TSIG ERROR 16 (BADSIG). If no key is available to sign - this message it MUST be sent unsigned (MAC size == 0 and empty MAC). - A message to the system operations log SHOULD be generated, to warn - the operations staff of a possible security incident in progress. - Care should be taken to ensure that logging of this type of event - does not open the system to a denial of service attack. - - 3.3. Time values used in TSIG calculations - - The data digested includes the two timer values in the TSIG header in - order to defend against replay attacks. If this were not done, an - attacker could replay old messages but update the "Time Signed" and - "Fudge" fields to make the message look new. This data is named - "TSIG Timers", and for the purpose of digest calculation they are - invoked in their "on the wire" format, in the following order: first - Time Signed, then Fudge. For example: - -Field Name Value Wire Format Meaning ----------------------------------------------------------------------- -Time Signed 853804800 00 00 32 e4 07 00 Tue Jan 21 00:00:00 1997 -Fudge 300 01 2C 5 minutes - - 3.4. TSIG Variables and Coverage - - When generating or verifying the contents of a TSIG record, the - following data are digested, in network byte order or wire format, as - appropriate: - - 3.4.1. DNS Message - - A whole and complete DNS message in wire format, before the TSIG RR - has been added to the additional data section and before the DNS - Message Header's ARCOUNT field has been incremented to contain the - TSIG RR. If the message ID differs from the original message ID, the - original message ID is substituted for the message ID. This could - happen when forwarding a dynamic update request, for example. - - - - - - - - - -Vixie, et al. Standards Track [Page 6] - -RFC 2845 DNS TSIG May 2000 - - - 3.4.2. TSIG Variables - -Source Field Name Notes ------------------------------------------------------------------------ -TSIG RR NAME Key name, in canonical wire format -TSIG RR CLASS (Always ANY in the current specification) -TSIG RR TTL (Always 0 in the current specification) -TSIG RDATA Algorithm Name in canonical wire format -TSIG RDATA Time Signed in network byte order -TSIG RDATA Fudge in network byte order -TSIG RDATA Error in network byte order -TSIG RDATA Other Len in network byte order -TSIG RDATA Other Data exactly as transmitted - - The RR RDLEN and RDATA MAC Length are not included in the hash since - they are not guaranteed to be knowable before the MAC is generated. - - The Original ID field is not included in this section, as it has - already been substituted for the message ID in the DNS header and - hashed. - - For each label type, there must be a defined "Canonical wire format" - that specifies how to express a label in an unambiguous way. For - label type 00, this is defined in [RFC2535], for label type 01, this - is defined in [RFC2673]. The use of label types other than 00 and 01 - is not defined for this specification. - - 3.4.3. Request MAC - - When generating the MAC to be included in a response, the request MAC - must be included in the digest. The request's MAC is digested in - wire format, including the following fields: - - Field Type Description - --------------------------------------------------- - MAC Length u_int16_t in network byte order - MAC Data octet stream exactly as transmitted - - 3.5. Padding - - Digested components are fed into the hashing function as a continuous - octet stream with no interfield padding. - - - - - - - - - -Vixie, et al. Standards Track [Page 7] - -RFC 2845 DNS TSIG May 2000 - - -4 - Protocol Details - - 4.1. TSIG generation on requests - - Client performs the message digest operation and appends a TSIG - record to the additional data section and transmits the request to - the server. The client MUST store the message digest from the - request while awaiting an answer. The digest components for a - request are: - - DNS Message (request) - TSIG Variables (request) - - Note that some older name servers will not accept requests with a - nonempty additional data section. Clients SHOULD only attempt signed - transactions with servers who are known to support TSIG and share - some secret key with the client -- so, this is not a problem in - practice. - - 4.2. TSIG on Answers - - When a server has generated a response to a signed request, it signs - the response using the same algorithm and key. The server MUST not - generate a signed response to an unsigned request. The digest - components are: - - Request MAC - DNS Message (response) - TSIG Variables (response) - - 4.3. TSIG on TSIG Error returns - - When a server detects an error relating to the key or MAC, the server - SHOULD send back an unsigned error message (MAC size == 0 and empty - MAC). If an error is detected relating to the TSIG validity period, - the server SHOULD send back a signed error message. The digest - components are: - - Request MAC (if the request MAC validated) - DNS Message (response) - TSIG Variables (response) - - The reason that the request is not included in this digest in some - cases is to make it possible for the client to verify the error. If - the error is not a TSIG error the response MUST be generated as - specified in [4.2]. - - - - - -Vixie, et al. Standards Track [Page 8] - -RFC 2845 DNS TSIG May 2000 - - - 4.4. TSIG on TCP connection - - A DNS TCP session can include multiple DNS envelopes. This is, for - example, commonly used by zone transfer. Using TSIG on such a - connection can protect the connection from hijacking and provide data - integrity. The TSIG MUST be included on the first and last DNS - envelopes. It can be optionally placed on any intermediary - envelopes. It is expensive to include it on every envelopes, but it - MUST be placed on at least every 100'th envelope. The first envelope - is processed as a standard answer, and subsequent messages have the - following digest components: - - Prior Digest (running) - DNS Messages (any unsigned messages since the last TSIG) - TSIG Timers (current message) - - This allows the client to rapidly detect when the session has been - altered; at which point it can close the connection and retry. If a - client TSIG verification fails, the client MUST close the connection. - If the client does not receive TSIG records frequently enough (as - specified above) it SHOULD assume the connection has been hijacked - and it SHOULD close the connection. The client SHOULD treat this the - same way as they would any other interrupted transfer (although the - exact behavior is not specified). - - 4.5. Server TSIG checks - - Upon receipt of a message, server will check if there is a TSIG RR. - If one exists, the server is REQUIRED to return a TSIG RR in the - response. The server MUST perform the following checks in the - following order, check KEY, check TIME values, check MAC. - - 4.5.1. KEY check and error handling - - If a non-forwarding server does not recognize the key used by the - client, the server MUST generate an error response with RCODE 9 - (NOTAUTH) and TSIG ERROR 17 (BADKEY). This response MUST be unsigned - as specified in [4.3]. The server SHOULD log the error. - - 4.5.2. TIME check and error handling - - If the server time is outside the time interval specified by the - request (which is: Time Signed, plus/minus Fudge), the server MUST - generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18 - (BADTIME). The server SHOULD also cache the most recent time signed - value in a message generated by a key, and SHOULD return BADTIME if a - message received later has an earlier time signed value. A response - indicating a BADTIME error MUST be signed by the same key as the - - - -Vixie, et al. Standards Track [Page 9] - -RFC 2845 DNS TSIG May 2000 - - - request. It MUST include the client's current time in the time - signed field, the server's current time (a u_int48_t) in the other - data field, and 6 in the other data length field. This is done so - that the client can verify a message with a BADTIME error without the - verification failing due to another BADTIME error. The data signed - is specified in [4.3]. The server SHOULD log the error. - - 4.5.3. MAC check and error handling - - If a TSIG fails to verify, the server MUST generate an error response - as specified in [4.3] with RCODE 9 (NOTAUTH) and TSIG ERROR 16 - (BADSIG). This response MUST be unsigned as specified in [4.3]. The - server SHOULD log the error. - - 4.6. Client processing of answer - - When a client receives a response from a server and expects to see a - TSIG, it first checks if the TSIG RR is present in the response. - Otherwise, the response is treated as having a format error and - discarded. The client then extracts the TSIG, adjusts the ARCOUNT, - and calculates the keyed digest in the same way as the server. If - the TSIG does not validate, that response MUST be discarded, unless - the RCODE is 9 (NOTAUTH), in which case the client SHOULD attempt to - verify the response as if it were a TSIG Error response, as specified - in [4.3]. A message containing an unsigned TSIG record or a TSIG - record which fails verification SHOULD not be considered an - acceptable response; the client SHOULD log an error and continue to - wait for a signed response until the request times out. - - 4.6.1. Key error handling - - If an RCODE on a response is 9 (NOTAUTH), and the response TSIG - validates, and the TSIG key is different from the key used on the - request, then this is a KEY error. The client MAY retry the request - using the key specified by the server. This should never occur, as a - server MUST NOT sign a response with a different key than signed the - request. - - 4.6.2. Time error handling - - If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 18 - (BADTIME), or the current time does not fall in the range specified - in the TSIG record, then this is a TIME error. This is an indication - that the client and server clocks are not synchronized. In this case - the client SHOULD log the event. DNS resolvers MUST NOT adjust any - clocks in the client based on BADTIME errors, but the server's time - in the other data field SHOULD be logged. - - - - -Vixie, et al. Standards Track [Page 10] - -RFC 2845 DNS TSIG May 2000 - - - 4.6.3. MAC error handling - - If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG), - this is a MAC error, and client MAY retry the request with a new - request ID but it would be better to try a different shared key if - one is available. Client SHOULD keep track of how many MAC errors - are associated with each key. Clients SHOULD log this event. - - 4.7. Special considerations for forwarding servers - - A server acting as a forwarding server of a DNS message SHOULD check - for the existence of a TSIG record. If the name on the TSIG is not - of a secret that the server shares with the originator the server - MUST forward the message unchanged including the TSIG. If the name - of the TSIG is of a key this server shares with the originator, it - MUST process the TSIG. If the TSIG passes all checks, the forwarding - server MUST, if possible, include a TSIG of his own, to the - destination or the next forwarder. If no transaction security is - available to the destination and the response has the AD flag (see - [RFC2535]), the forwarder MUST unset the AD flag before adding the - TSIG to the answer. - -5 - Shared Secrets - - 5.1. Secret keys are very sensitive information and all available - steps should be taken to protect them on every host on which they are - stored. Generally such hosts need to be physically protected. If - they are multi-user machines, great care should be taken that - unprivileged users have no access to keying material. Resolvers - often run unprivileged, which means all users of a host would be able - to see whatever configuration data is used by the resolver. - - 5.2. A name server usually runs privileged, which means its - configuration data need not be visible to all users of the host. For - this reason, a host that implements transaction-based authentication - should probably be configured with a "stub resolver" and a local - caching and forwarding name server. This presents a special problem - for [RFC2136] which otherwise depends on clients to communicate only - with a zone's authoritative name servers. - - 5.3. Use of strong random shared secrets is essential to the security - of TSIG. See [RFC1750] for a discussion of this issue. The secret - should be at least as long as the keyed message digest, i.e. 16 bytes - for HMAC-MD5 or 20 bytes for HMAC-SHA1. - - - - - - - -Vixie, et al. Standards Track [Page 11] - -RFC 2845 DNS TSIG May 2000 - - -6 - Security Considerations - - 6.1. The approach specified here is computationally much less - expensive than the signatures specified in [RFC2535]. As long as the - shared secret key is not compromised, strong authentication is - provided for the last hop from a local name server to the user - resolver. - - 6.2. Secret keys should be changed periodically. If the client host - has been compromised, the server should suspend the use of all - secrets known to that client. If possible, secrets should be stored - in encrypted form. Secrets should never be transmitted in the clear - over any network. This document does not address the issue on how to - distribute secrets. Secrets should never be shared by more than two - entities. - - 6.3. This mechanism does not authenticate source data, only its - transmission between two parties who share some secret. The original - source data can come from a compromised zone master or can be - corrupted during transit from an authentic zone master to some - "caching forwarder." However, if the server is faithfully performing - the full [RFC2535] security checks, then only security checked data - will be available to the client. - - 6.4. A fudge value that is too large may leave the server open to - replay attacks. A fudge value that is too small may cause failures - if machines are not time synchronized or there are unexpected network - delays. The recommended value in most situation is 300 seconds. - -7 - IANA Considerations - - IANA is expected to create and maintain a registry of algorithm names - to be used as "Algorithm Names" as defined in Section 2.3. The - initial value should be "HMAC-MD5.SIG-ALG.REG.INT". Algorithm names - are text strings encoded using the syntax of a domain name. There is - no structure required other than names for different algorithms must - be unique when compared as DNS names, i.e., comparison is case - insensitive. Note that the initial value mentioned above is not a - domain name, and therefore need not be a registered name within the - DNS. New algorithms are assigned using the IETF Consensus policy - defined in RFC 2434. The algorithm name HMAC-MD5.SIG-ALG.REG.INT - looks like a FQDN for historical reasons; future algorithm names are - expected to be simple (i.e., single-component) names. - - - - - - - - -Vixie, et al. Standards Track [Page 12] - -RFC 2845 DNS TSIG May 2000 - - - IANA is expected to create and maintain a registry of "TSIG Error - values" to be used for "Error" values as defined in section 2.3. - Initial values should be those defined in section 1.7. New TSIG - error codes for the TSIG error field are assigned using the IETF - Consensus policy defined in RFC 2434. - -8 - References - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1034, November 1987. - - [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, - April 1992. - - [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness - Recommendations for Security", RFC 1750, December 1995. - - [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC-MD5: - Keyed-MD5 for Message Authentication", RFC 2104, February - 1997. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound "Dynamic - Updates in the Domain Name System", RFC 2136, April 1997. - - [RFC2137] Eastlake 3rd, D., "Secure Domain Name System Dynamic - Update", RFC 2137, April 1997. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", - RFC 2673, August 1999. - - - - - - - - - - - - - -Vixie, et al. Standards Track [Page 13] - -RFC 2845 DNS TSIG May 2000 - - -9 - Authors' Addresses - - Paul Vixie - Internet Software Consortium - 950 Charter Street - Redwood City, CA 94063 - - Phone: +1 650 779 7001 - EMail: vixie@isc.org - - - Olafur Gudmundsson - NAI Labs - 3060 Washington Road, Route 97 - Glenwood, MD 21738 - - Phone: +1 443 259 2389 - EMail: ogud@tislabs.com - - - Donald E. Eastlake 3rd - Motorola - 140 Forest Avenue - Hudson, MA 01749 USA - - Phone: +1 508 261 5434 - EMail: dee3@torque.pothole.com - - - Brian Wellington - Nominum, Inc. - 950 Charter Street - Redwood City, CA 94063 - - Phone: +1 650 779 6022 - EMail: Brian.Wellington@nominum.com - - - - - - - - - - - - - - - -Vixie, et al. Standards Track [Page 14] - -RFC 2845 DNS TSIG May 2000 - - -10 Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Vixie, et al. Standards Track [Page 15] - diff --git a/contrib/bind9/doc/rfc/rfc2874.txt b/contrib/bind9/doc/rfc/rfc2874.txt deleted file mode 100644 index 915c104aa161..000000000000 --- a/contrib/bind9/doc/rfc/rfc2874.txt +++ /dev/null @@ -1,1123 +0,0 @@ - - - - - - -Network Working Group M. Crawford -Request for Comments: 2874 Fermilab -Category: Standards Track C. Huitema - Microsoft Corporation - July 2000 - - - DNS Extensions to Support IPv6 Address Aggregation and Renumbering - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - This document defines changes to the Domain Name System to support - renumberable and aggregatable IPv6 addressing. The changes include a - new resource record type to store an IPv6 address in a manner which - expedites network renumbering and updated definitions of existing - query types that return Internet addresses as part of additional - section processing. - - For lookups keyed on IPv6 addresses (often called reverse lookups), - this document defines a new zone structure which allows a zone to be - used without modification for parallel copies of an address space (as - for a multihomed provider or site) and across network renumbering - events. - - - - - - - - - - - - - - - - -Crawford, et al. Standards Track [Page 1] - -RFC 2874 IPv6 DNS July 2000 - - -Table of Contents - - 1. Introduction ............................................... 2 - 2. Overview ................................................... 3 - 2.1. Name-to-Address Lookup ............................... 4 - 2.2. Underlying Mechanisms for Reverse Lookups ............ 4 - 2.2.1. Delegation on Arbitrary Boundaries ............. 4 - 2.2.2. Reusable Zones ................................. 5 - 3. Specifications ............................................. 5 - 3.1. The A6 Record Type ................................... 5 - 3.1.1. Format ......................................... 6 - 3.1.2. Processing ..................................... 6 - 3.1.3. Textual Representation ......................... 7 - 3.1.4. Name Resolution Procedure ...................... 7 - 3.2. Zone Structure for Reverse Lookups ................... 7 - 4. Modifications to Existing Query Types ...................... 8 - 5. Usage Illustrations ........................................ 8 - 5.1. A6 Record Chains ..................................... 9 - 5.1.1. Authoritative Data ............................. 9 - 5.1.2. Glue ........................................... 10 - 5.1.3. Variations ..................................... 12 - 5.2. Reverse Mapping Zones ................................ 13 - 5.2.1. The TLA level .................................. 13 - 5.2.2. The ISP level .................................. 13 - 5.2.3. The Site Level ................................. 13 - 5.3. Lookups .............................................. 14 - 5.4. Operational Note ..................................... 15 - 6. Transition from RFC 1886 and Deployment Notes .............. 15 - 6.1. Transition from AAAA and Coexistence with A Records .. 16 - 6.2. Transition from Nibble Labels to Binary Labels ....... 17 - 7. Security Considerations .................................... 17 - 8. IANA Considerations ........................................ 17 - 9. Acknowledgments ............................................ 18 - 10. References ................................................ 18 - 11. Authors' Addresses ........................................ 19 - 12. Full Copyright Statement .................................. 20 - -1. Introduction - - Maintenance of address information in the DNS is one of several - obstacles which have prevented site and provider renumbering from - being feasible in IP version 4. Arguments about the importance of - network renumbering for the preservation of a stable routing system - and for other purposes may be read in [RENUM1, RENUM2, RENUM3]. To - support the storage of IPv6 addresses without impeding renumbering we - define the following extensions. - - - - - -Crawford, et al. Standards Track [Page 2] - -RFC 2874 IPv6 DNS July 2000 - - - o A new resource record type, "A6", is defined to map a domain name - to an IPv6 address, with a provision for indirection for leading - "prefix" bits. - - o Existing queries that perform additional section processing to - locate IPv4 addresses are redefined to do that processing for both - IPv4 and IPv6 addresses. - - o A new domain, IP6.ARPA, is defined to support lookups based on - IPv6 address. - - o A new prefix-delegation method is defined, relying on new DNS - features [BITLBL, DNAME]. - - The changes are designed to be compatible with existing application - programming interfaces. The existing support for IPv4 addresses is - retained. Transition issues related to the coexistence of both IPv4 - and IPv6 addresses in DNS are discussed in [TRANS]. - - This memo proposes a replacement for the specification in RFC 1886 - [AAAA] and a departure from current implementation practices. The - changes are designed to facilitate network renumbering and - multihoming. Domains employing the A6 record for IPv6 addresses can - insert automatically-generated AAAA records in zone files to ease - transition. It is expected that after a reasonable period, RFC 1886 - will become Historic. - - The next three major sections of this document are an overview of the - facilities defined or employed by this specification, the - specification itself, and examples of use. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [KWORD]. The key word - "SUGGESTED" signifies a strength between MAY and SHOULD: it is - believed that compliance with the suggestion has tangible benefits in - most instances. - -2. Overview - - This section provides an overview of the DNS facilities for storage - of IPv6 addresses and for lookups based on IPv6 address, including - those defined here and elsewhere. - - - - - - - - -Crawford, et al. Standards Track [Page 3] - -RFC 2874 IPv6 DNS July 2000 - - -2.1. Name-to-Address Lookup - - IPv6 addresses are stored in one or more A6 resource records. A - single A6 record may include a complete IPv6 address, or a contiguous - portion of an address and information leading to one or more - prefixes. Prefix information comprises a prefix length and a DNS - name which is in turn the owner of one or more A6 records defining - the prefix or prefixes which are needed to form one or more complete - IPv6 addresses. When the prefix length is zero, no DNS name is - present and all the leading bits of the address are significant. - There may be multiple levels of indirection and the existence of - multiple A6 records at any level multiplies the number of IPv6 - addresses which are formed. - - An application looking up an IPv6 address will generally cause the - DNS resolver to access several A6 records, and multiple IPv6 - addresses may be returned even if the queried name was the owner of - only one A6 record. The authenticity of the returned address(es) - cannot be directly verified by DNS Security [DNSSEC]. The A6 records - which contributed to the address(es) may of course be verified if - signed. - - Implementers are reminded of the necessity to limit the amount of - work a resolver will perform in response to a client request. This - principle MUST be extended to also limit the generation of DNS - requests in response to one name-to-address (or address-to-name) - lookup request. - -2.2. Underlying Mechanisms for Reverse Lookups - - This section describes the new DNS features which this document - exploits. This section is an overview, not a specification of those - features. The reader is directed to the referenced documents for - more details on each. - -2.2.1. Delegation on Arbitrary Boundaries - - This new scheme for reverse lookups relies on a new type of DNS label - called the "bit-string label" [BITLBL]. This label compactly - represents an arbitrary string of bits which is treated as a - hierarchical sequence of one-bit domain labels. Resource records can - thereby be stored at arbitrary bit-boundaries. - - Examples in section 5 will employ the following textual - representation for bit-string labels, which is a subset of the syntax - defined in [BITLBL]. A base indicator "x" for hexadecimal and a - sequence of hexadecimal digits is enclosed between "\[" and "]". The - bits denoted by the digits represent a sequence of one-bit domain - - - -Crawford, et al. Standards Track [Page 4] - -RFC 2874 IPv6 DNS July 2000 - - - labels ordered from most to least significant. (This is the opposite - of the order they would appear if listed one bit at a time, but it - appears to be a convenient notation.) The digit string may be - followed by a slash ("/") and a decimal count. If omitted, the - implicit count is equal to four times the number of hexadecimal - digits. - - Consecutive bit-string labels are equivalent (up to the limit imposed - by the size of the bit count field) to a single bit-string label - containing all the bits of the consecutive labels in the proper - order. As an example, either of the following domain names could be - used in a QCLASS=IN, QTYPE=PTR query to find the name of the node - with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32. - - \[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA. - - \[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA. - -2.2.2. Reusable Zones - - DNS address space delegation is implemented not by zone cuts and NS - records, but by a new analogue to the CNAME record, called the DNAME - resource record [DNAME]. The DNAME record provides alternate naming - to an entire subtree of the domain name space, rather than to a - single node. It causes some suffix of a queried name to be - substituted with a name from the DNAME record's RDATA. - - For example, a resolver or server providing recursion, while looking - up a QNAME a.b.c.d.e.f may encounter a DNAME record - - d.e.f. DNAME w.xy. - - which will cause it to look for a.b.c.w.xy. - -3. Specifications - -3.1. The A6 Record Type - - The A6 record type is specific to the IN (Internet) class and has - type number 38 (decimal). - - - - - - - - - - - -Crawford, et al. Standards Track [Page 5] - -RFC 2874 IPv6 DNS July 2000 - - -3.1.1. Format - - The RDATA portion of the A6 record contains two or three fields. - - +-----------+------------------+-------------------+ - |Prefix len.| Address suffix | Prefix name | - | (1 octet) | (0..16 octets) | (0..255 octets) | - +-----------+------------------+-------------------+ - - o A prefix length, encoded as an eight-bit unsigned integer with - value between 0 and 128 inclusive. - - o An IPv6 address suffix, encoded in network order (high-order octet - first). There MUST be exactly enough octets in this field to - contain a number of bits equal to 128 minus prefix length, with 0 - to 7 leading pad bits to make this field an integral number of - octets. Pad bits, if present, MUST be set to zero when loading a - zone file and ignored (other than for SIG [DNSSEC] verification) - on reception. - - o The name of the prefix, encoded as a domain name. By the rules of - [DNSIS], this name MUST NOT be compressed. - - The domain name component SHALL NOT be present if the prefix length - is zero. The address suffix component SHALL NOT be present if the - prefix length is 128. - - It is SUGGESTED that an A6 record intended for use as a prefix for - other A6 records have all the insignificant trailing bits in its - address suffix field set to zero. - -3.1.2. Processing - - A query with QTYPE=A6 causes type A6 and type NS additional section - processing for the prefix names, if any, in the RDATA field of the A6 - records in the answer section. This processing SHOULD be recursively - applied to the prefix names of A6 records included as additional - data. When space in the reply packet is a limit, inclusion of - additional A6 records takes priority over NS records. - - It is an error for an A6 record with prefix length L1 > 0 to refer to - a domain name which owns an A6 record with a prefix length L2 > L1. - If such a situation is encountered by a resolver, the A6 record with - the offending (larger) prefix length MUST be ignored. Robustness - precludes signaling an error if addresses can still be formed from - valid A6 records, but it is SUGGESTED that zone maintainers from time - to time check all the A6 records their zones reference. - - - - -Crawford, et al. Standards Track [Page 6] - -RFC 2874 IPv6 DNS July 2000 - - -3.1.3. Textual Representation - - The textual representation of the RDATA portion of the A6 resource - record in a zone file comprises two or three fields separated by - whitespace. - - o A prefix length, represented as a decimal number between 0 and 128 - inclusive, - - o the textual representation of an IPv6 address as defined in - [AARCH] (although some leading and/or trailing bits may not be - significant), - - o a domain name, if the prefix length is not zero. - - The domain name MUST be absent if the prefix length is zero. The - IPv6 address MAY be be absent if the prefix length is 128. A number - of leading address bits equal to the prefix length SHOULD be zero, - either implicitly (through the :: notation) or explicitly, as - specified in section 3.1.1. - -3.1.4. Name Resolution Procedure - - To obtain the IPv6 address or addresses which belong to a given name, - a DNS client MUST obtain one or more complete chains of A6 records, - each chain beginning with a record owned by the given name and - including a record owned by the prefix name in that record, and so on - recursively, ending with an A6 record with a prefix length of zero. - One IPv6 address is formed from one such chain by taking the value of - each bit position from the earliest A6 record in the chain which - validly covers that position, as indicated by the prefix length. The - set of all IPv6 addresses for the given name comprises the addresses - formed from all complete chains of A6 records beginning at that name, - discarding records which have invalid prefix lengths as defined in - section 3.1.2. - - If some A6 queries fail and others succeed, a client might obtain a - non-empty but incomplete set of IPv6 addresses for a host. In many - situations this may be acceptable. The completeness of a set of A6 - records may always be determined by inspection. - -3.2. Zone Structure for Reverse Lookups - - Very little of the new scheme's data actually appears under IP6.ARPA; - only the first level of delegation needs to be under that domain. - More levels of delegation could be placed under IP6.ARPA if some - top-level delegations were done via NS records instead of DNAME - records, but this would incur some cost in renumbering ease at the - - - -Crawford, et al. Standards Track [Page 7] - -RFC 2874 IPv6 DNS July 2000 - - - level of TLAs [AGGR]. Therefore, it is declared here that all - address space delegations SHOULD be done by the DNAME mechanism - rather than NS. - - In addition, since uniformity in deployment will simplify maintenance - of address delegations, it is SUGGESTED that address and prefix - information be stored immediately below a DNS label "IP6". Stated - another way, conformance with this suggestion would mean that "IP6" - is the first label in the RDATA field of DNAME records which support - IPv6 reverse lookups. - - When any "reserved" or "must be zero" bits are adjacent to a - delegation boundary, the higher-level entity MUST retain those bits - in its own control and delegate only the bits over which the lower- - level entity has authority. - - To find the name of a node given its IPv6 address, a DNS client MUST - perform a query with QCLASS=IN, QTYPE=PTR on the name formed from the - 128 bit address as one or more bit-string labels [BITLBL], followed - by the two standard labels "IP6.ARPA". If recursive service was not - obtained from a server and the desired PTR record was not returned, - the resolver MUST handle returned DNAME records as specified in - [DNAME], and NS records as specified in [DNSCF], and iterate. - -4. Modifications to Existing Query Types - - All existing query types that perform type A additional section - processing, i.e. the name server (NS), mail exchange (MX), and - mailbox (MB) query types, and the experimental AFS data base (AFSDB) - and route through (RT) types, must be redefined to perform type A, A6 - and AAAA additional section processing, with type A having the - highest priority for inclusion and type AAAA the lowest. This - redefinition means that a name server may add any relevant IPv4 and - IPv6 address information available locally to the additional section - of a response when processing any one of the above queries. The - recursive inclusion of A6 records referenced by A6 records already - included in the additional section is OPTIONAL. - -5. Usage Illustrations - - This section provides examples of use of the mechanisms defined in - the previous section. All addresses and domains mentioned here are - intended to be fictitious and for illustrative purposes only. - Example delegations will be on 4-bit boundaries solely for - readability; this specification is indifferent to bit alignment. - - Use of the IPv6 aggregatable address format [AGGR] is assumed in the - examples. - - - -Crawford, et al. Standards Track [Page 8] - -RFC 2874 IPv6 DNS July 2000 - - -5.1. A6 Record Chains - - Let's take the example of a site X that is multi-homed to two - "intermediate" providers A and B. The provider A is itself multi- - homed to two "transit" providers, C and D. The provider B gets its - transit service from a single provider, E. For simplicity suppose - that C, D and E all belong to the same top-level aggregate (TLA) with - identifier (including format prefix) '2345', and the TLA authority at - ALPHA-TLA.ORG assigns to C, D and E respectively the next level - aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28 and - 2345:000E::/32. - - C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the - prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to - B. - - A assigns to X the subscriber identification '11' and B assigns the - subscriber identification '22'. As a result, the site X inherits - three address prefixes: - - o 2345:00C1:CA11::/48 from A, for routes through C. - o 2345:00D2:DA11::/48 from A, for routes through D. - o 2345:000E:EB22::/48 from B, for routes through E. - - Let us suppose that N is a node in the site X, that it is assigned to - subnet number 1 in this site, and that it uses the interface - identifier '1234:5678:9ABC:DEF0'. In our configuration, this node - will have three addresses: - - o 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 - o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0 - o 2345:000E:EB22:0001:1234:5678:9ABC:DEF0 - -5.1.1. Authoritative Data - - We will assume that the site X is represented in the DNS by the - domain name X.EXAMPLE, while A, B, C, D and E are represented by - A.NET, B.NET, C.NET, D.NET and E.NET. In each of these domains, we - assume a subdomain "IP6" that will hold the corresponding prefixes. - The node N is identified by the domain name N.X.EXAMPLE. The - following records would then appear in X's DNS. - - $ORIGIN X.EXAMPLE. - N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 - SUBNET-1.IP6 A6 48 0:0:0:1:: IP6 - IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. - IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET. - - - - -Crawford, et al. Standards Track [Page 9] - -RFC 2874 IPv6 DNS July 2000 - - - And elsewhere there would appear - - SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET. - SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET. - - SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET. - - A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG. - - A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG. - - B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG. - - C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0:: - D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0:: - E.NET.ALPHA-TLA.ORG. A6 0 2345:000E:: - -5.1.2. Glue - - When, as is common, some or all DNS servers for X.EXAMPLE are within - the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry - enough "glue" information to enable DNS clients to reach those - nameservers. This is true in IPv6 just as in IPv4. However, the A6 - record affords the DNS administrator some choices. The glue could be - any of - - o a minimal set of A6 records duplicated from the X.EXAMPLE zone, - - o a (possibly smaller) set of records which collapse the structure - of that minimal set, - - o or a set of A6 records with prefix length zero, giving the entire - global addresses of the servers. - - The trade-off is ease of maintenance against robustness. The best - and worst of both may be had together by implementing either the - first or second option together with the third. To illustrate the - glue options, suppose that X.EXAMPLE is served by two nameservers - NS1.X.EXAMPLE and NS2.X.EXAMPLE, having interface identifiers - ::1:11:111:1111 and ::2:22:222:2222 on subnets 1 and 2 respectively. - Then the top-level zone EXAMPLE would include one (or more) of the - following sets of A6 records as glue. - - - - - - - - - -Crawford, et al. Standards Track [Page 10] - -RFC 2874 IPv6 DNS July 2000 - - - $ORIGIN EXAMPLE. ; first option - X NS NS1.X - NS NS2.X - NS1.X A6 64 ::1:11:111:1111 SUBNET-1.IP6.X - NS2.X A6 64 ::2:22:222:2222 SUBNET-2.IP6.X - SUBNET-1.IP6.X A6 48 0:0:0:1:: IP6.X - SUBNET-2.IP6.X A6 48 0:0:0:2:: IP6.X - IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. - IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.B.NET. - - - $ORIGIN EXAMPLE. ; second option - X NS NS1.X - NS NS2.X - NS1.X A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET. - A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET. - NS2.X A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET. - A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET. - - - $ORIGIN EXAMPLE. ; third option - X NS NS1.X - NS NS2.X - NS1.X A6 0 2345:00C1:CA11:1:1:11:111:1111 - A6 0 2345:00D2:DA11:1:1:11:111:1111 - A6 0 2345:000E:EB22:1:1:11:111:1111 - NS2.X A6 0 2345:00C1:CA11:2:2:22:222:2222 - A6 0 2345:00D2:DA11:2:2:22:222:2222 - A6 0 2345:000E:EB22:2:2:22:222:2222 - - The first and second glue options are robust against renumbering of - X.EXAMPLE's prefixes by providers A.NET and B.NET, but will fail if - those providers' own DNS is unreachable. The glue records of the - third option are robust against DNS failures elsewhere than the zones - EXAMPLE and X.EXAMPLE themselves, but must be updated when X's - address space is renumbered. - - If the EXAMPLE zone includes redundant glue, for instance the union - of the A6 records of the first and third options, then under normal - circumstances duplicate IPv6 addresses will be derived by DNS - clients. But if provider DNS fails, addresses will still be obtained - from the zero-prefix-length records, while if the EXAMPLE zone lags - behind a renumbering of X.EXAMPLE, half of the addresses obtained by - DNS clients will still be up-to-date. - - The zero-prefix-length glue records can of course be automatically - generated and/or checked in practice. - - - - -Crawford, et al. Standards Track [Page 11] - -RFC 2874 IPv6 DNS July 2000 - - -5.1.3. Variations - - Several more-or-less arbitrary assumptions are reflected in the above - structure. All of the following choices could have been made - differently, according to someone's notion of convenience or an - agreement between two parties. - - First, that site X has chosen to put subnet information in a - separate A6 record rather than incorporate it into each node's A6 - records. - - Second, that site X is referred to as "SUBSCRIBER-X" by both of - its providers A and B. - - Third, that site X chose to indirect its provider information - through A6 records at IP6.X.EXAMPLE containing no significant - bits. An alternative would have been to replicate each subnet - record for each provider. - - Fourth, B and E used a slightly different prefix naming convention - between themselves than did A, C and D. Each hierarchical pair of - network entities must arrange this naming between themselves. - - Fifth, that the upward prefix referral chain topped out at ALPHA- - TLA.ORG. There could have been another level which assigned the - TLA values and holds A6 records containing those bits. - - Finally, the above structure reflects an assumption that address - fields assigned by a given entity are recorded only in A6 records - held by that entity. Those bits could be entered into A6 records in - the lower-level entity's zone instead, thus: - - IP6.X.EXAMPLE. A6 40 0:0:11:: IP6.A.NET. - IP6.X.EXAMPLE. A6 40 0:0:22:: IP6.B.NET. - - IP6.A.NET. A6 28 0:1:CA00:: IP6.C.NET. - and so on. - - Or the higher-level entities could hold both sorts of A6 records - (with different DNS owner names) and allow the lower-level entities - to choose either mode of A6 chaining. But the general principle of - avoiding data duplication suggests that the proper place to store - assigned values is with the entity that assigned them. - - It is possible, but not necessarily recommended, for a zone - maintainer to forego the renumbering support afforded by the chaining - of A6 records and to record entire IPv6 addresses within one zone - file. - - - -Crawford, et al. Standards Track [Page 12] - -RFC 2874 IPv6 DNS July 2000 - - -5.2. Reverse Mapping Zones - - Supposing that address space assignments in the TLAs with Format - Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in - zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then - the IP6.ARPA zone would include - - $ORIGIN IP6.ARPA. - \[x234500/24] DNAME IP6.ALPHA-TLA.ORG. - \[x267800/24] DNAME IP6.BRAVO-TLA.ORG. - \[x29AB00/24] DNAME IP6.CHARLIE-TLA.XY. - - Eight trailing zero bits have been included in each TLA ID to reflect - the eight reserved bits in the current aggregatable global unicast - addresses format [AGGR]. - -5.2.1. The TLA level - - ALPHA-TLA's assignments to network providers C, D and E are reflected - in the reverse data as follows. - - \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET. - \[xD/4].IP6.ALPHA-TLA.ORG. DNAME IP6.D.NET. - \[x0E/8].IP6.ALPHA-TLA.ORG. DNAME IP6.E.NET. - -5.2.2. The ISP level - - The providers A through E carry the following delegation information - in their zone files. - - \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET. - \[x2DA/12].IP6.D.NET. DNAME IP6.A.NET. - \[xEB/8].IP6.E.NET. DNAME IP6.B.NET. - \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE. - \[x22/8].IP6.B.NET. DNAME IP6.X.EXAMPLE. - - Note that some domain names appear in the RDATA of more than one - DNAME record. In those cases, one zone is being used to map multiple - prefixes. - -5.2.3. The Site Level - - Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to- - name translations. This domain is now referenced by two different - DNAME records held by two different providers. - - - - - - -Crawford, et al. Standards Track [Page 13] - -RFC 2874 IPv6 DNS July 2000 - - - $ORIGIN IP6.X.EXAMPLE. - \[x0001/16] DNAME SUBNET-1 - \[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE. - and so on. - - SUBNET-1 need not have been named in a DNAME record; the subnet bits - could have been joined with the interface identifier. But if subnets - are treated alike in both the A6 records and in the reverse zone, it - will always be possible to keep the forward and reverse definition - data for each prefix in one zone. - -5.3. Lookups - - A DNS resolver looking for a hostname for the address - 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the - DNAME records shown above and would form new queries. Assuming that - it began the process knowing servers for IP6.ARPA, but that no server - it consulted provided recursion and none had other useful additional - information cached, the sequence of queried names and responses would - be (all with QCLASS=IN, QTYPE=PTR): - - To a server for IP6.ARPA: - QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA. - - Answer: - \[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG. - - To a server for IP6.ALPHA-TLA.ORG: - QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG. - - Answer: - \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET. - - To a server for IP6.C.NET.: - QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET. - - Answer: - \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET. - - To a server for IP6.A.NET.: - QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET. - - Answer: - \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE. - - To a server for IP6.X.EXAMPLE.: - QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE. - - - - -Crawford, et al. Standards Track [Page 14] - -RFC 2874 IPv6 DNS July 2000 - - - Answer: - \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE. - \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE. - - All the DNAME (and NS) records acquired along the way can be cached - to expedite resolution of addresses topologically near to this - address. And if another global address of N.X.EXAMPLE were resolved - within the TTL of the final PTR record, that record would not have to - be fetched again. - -5.4. Operational Note - - In the illustrations in section 5.1, hierarchically adjacent - entities, such as a network provider and a customer, must agree on a - DNS name which will own the definition of the delegated prefix(es). - One simple convention would be to use a bit-string label representing - exactly the bits which are assigned to the lower-level entity by the - higher. For example, "SUBSCRIBER-X" could be replaced by "\[x11/8]". - This would place the A6 record(s) defining the delegated prefix at - exactly the same point in the DNS tree as the DNAME record associated - with that delegation. The cost of this simplification is that the - lower-level zone must update its upward-pointing A6 records when it - is renumbered. This cost may be found quite acceptable in practice. - -6. Transition from RFC 1886 and Deployment Notes - - When prefixes have been "delegated upward" with A6 records, the - number of DNS resource records required to establish a single IPv6 - address increases by some non-trivial factor. Those records will - typically, but not necessarily, come from different DNS zones (which - can independently suffer failures for all the usual reasons). When - obtaining multiple IPv6 addresses together, this increase in RR count - will be proportionally less -- and the total size of a DNS reply - might even decrease -- if the addresses are topologically clustered. - But the records could still easily exceed the space available in a - UDP response which returns a large RRset [DNSCLAR] to an MX, NS, or - SRV query, for example. The possibilities for overall degradation of - performance and reliability of DNS lookups are numerous, and increase - with the number of prefix delegations involved, especially when those - delegations point to records in other zones. - - DNS Security [DNSSEC] addresses the trustworthiness of cached data, - which is a problem intrinsic to DNS, but the cost of applying this to - an IPv6 address is multiplied by a factor which may be greater than - the number of prefix delegations involved if different signature - chains must be verified for different A6 records. If a trusted - centralized caching server (as in [TSIG], for example) is used, this - cost might be amortized to acceptable levels. One new phenomenon is - - - -Crawford, et al. Standards Track [Page 15] - -RFC 2874 IPv6 DNS July 2000 - - - the possibility that IPv6 addresses may be formed from a A6 records - from a combination of secure and unsecured zones. - - Until more deployment experience is gained with the A6 record, it is - recommended that prefix delegations be limited to one or two levels. - A reasonable phasing-in mechanism would be to start with no prefix - delegations (all A6 records having prefix length 0) and then to move - to the use of a single level of delegation within a single zone. (If - the TTL of the "prefix" A6 records is kept to an appropriate duration - the capability for rapid renumbering is not lost.) More aggressively - flexible delegation could be introduced for a subset of hosts for - experimentation. - -6.1. Transition from AAAA and Coexistence with A Records - - Administrators of zones which contain A6 records can easily - accommodate deployed resolvers which understand AAAA records but not - A6 records. Such administrators can do automatic generation of AAAA - records for all of a zone's names which own A6 records by a process - which mimics the resolution of a hostname to an IPv6 address (see - section 3.1.4). Attention must be paid to the TTL assigned to a - generated AAAA record, which MUST be no more than the minimum of the - TTLs of the A6 records that were used to form the IPv6 address in - that record. For full robustness, those A6 records which were in - different zones should be monitored for changes (in TTL or RDATA) - even when there are no changes to zone for which AAAA records are - being generated. If the zone is secure [DNSSEC], the generated AAAA - records MUST be signed along with the rest of the zone data. - - A zone-specific heuristic MAY be used to avoid generation of AAAA - records for A6 records which record prefixes, although such - superfluous records would be relatively few in number and harmless. - Examples of such heuristics include omitting A6 records with a prefix - length less than the largest value found in the zone file, or records - with an address suffix field with a certain number of trailing zero - bits. - - On the client side, when looking up and IPv6 address, the order of A6 - and AAAA queries MAY be configurable to be one of: A6, then AAAA; - AAAA, then A6; A6 only; or both in parallel. The default order (or - only order, if not configurable) MUST be to try A6 first, then AAAA. - If and when the AAAA becomes deprecated a new document will change - the default. - - The guidelines and options for precedence between IPv4 and IPv6 - addresses are specified in [TRANS]. All mentions of AAAA records in - that document are henceforth to be interpreted as meaning A6 and/or - AAAA records in the order specified in the previous paragraph. - - - -Crawford, et al. Standards Track [Page 16] - -RFC 2874 IPv6 DNS July 2000 - - -6.2. Transition from Nibble Labels to Binary Labels - - Implementations conforming to RFC 1886 [AAAA] perform reverse lookups - as follows: - - An IPv6 address is represented as a name in the IP6.INT domain by - a sequence of nibbles separated by dots with the suffix - ".IP6.INT". The sequence of nibbles is encoded in reverse order, - i.e. the low-order nibble is encoded first, followed by the next - low-order nibble and so on. Each nibble is represented by a - hexadecimal digit. For example, a name for the address - 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 of the example in section - 5.3 would be sought at the DNS name "0.f.e.d.c.b.a.9.- - 8.7.6.5.4.3.2.1.1.0.0.0.1.1.a.c.1.c.0.0.5.4.3.2.ip6.int." - - Implementations conforming to this specification will perform a - lookup of a binary label in IP6.ARPA as specified in Section 3.2. It - is RECOMMENDED that for a transition period implementations first - lookup the binary label in IP6.ARPA and if this fails try to lookup - the 'nibble' label in IP6.INT. - -7. Security Considerations - - The signing authority [DNSSEC] for the A6 records which determine an - IPv6 address is distributed among several entities, reflecting the - delegation path of the address space which that address occupies. - DNS Security is fully applicable to bit-string labels and DNAME - records. And just as in IPv4, verification of name-to-address - mappings is logically independent of verification of address-to-name - mappings. - - With or without DNSSEC, the incomplete but non-empty address set - scenario of section 3.1.4 could be caused by selective interference - with DNS lookups. If in some situation this would be more harmful - than complete DNS failure, it might be mitigated on the client side - by refusing to act on an incomplete set, or on the server side by - listing all addresses in A6 records with prefix length 0. - -8. IANA Considerations - - The A6 resource record has been assigned a Type value of 38. - - - - - - - - - - -Crawford, et al. Standards Track [Page 17] - -RFC 2874 IPv6 DNS July 2000 - - -9. Acknowledgments - - The authors would like to thank the following persons for valuable - discussions and reviews: Mark Andrews, Rob Austein, Jim Bound, Randy - Bush, Brian Carpenter, David Conrad, Steve Deering, Francis Dupont, - Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob Hinden, - Edward Lewis, Bill Manning, Keith Moore, Thomas Narten, Erik - Nordmark, Mike O'Dell, Michael Patton and Ken Powell. - -10. References - - [AAAA] Thomson, S. and C. Huitema, "DNS Extensions to support IP - version 6, RFC 1886, December 1995. - - [AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 2373, July 1998. - - [AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 - Aggregatable Global Unicast Address Format", RFC 2374, July - 1998. - - [BITLBL] Crawford, M., "Binary Labels in the Domain Name System", - RFC 2673, August 1999. - - [DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC - 2672, August 1999. - - [DNSCLAR] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [DNSIS] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System - Security Extensions", RFC 2535, March 1999. - - [KWORD] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RENUM1] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC - 1900, February 1996. - - [RENUM2] Ferguson, P. and H. Berkowitz, "Network Renumbering - Overview: Why would I want it and what is it anyway?", RFC - 2071, January 1997. - - [RENUM3] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address - Behaviour Today", RFC 2101, February 1997. - - - -Crawford, et al. Standards Track [Page 18] - -RFC 2874 IPv6 DNS July 2000 - - - [TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for - IPv6 Hosts and Routers", RFC 1933, April 1996. - - [TSIG] Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - -11. Authors' Addresses - - Matt Crawford - Fermilab - MS 368 - PO Box 500 - Batavia, IL 60510 - USA - - Phone: +1 630 840-3461 - EMail: crawdad@fnal.gov - - - Christian Huitema - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052-6399 - - EMail: huitema@microsoft.com - - - - - - - - - - - - - - - - - - - - - - - - - -Crawford, et al. Standards Track [Page 19] - -RFC 2874 IPv6 DNS July 2000 - - -12. Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Crawford, et al. Standards Track [Page 20] - diff --git a/contrib/bind9/doc/rfc/rfc2915.txt b/contrib/bind9/doc/rfc/rfc2915.txt deleted file mode 100644 index 2022ba115724..000000000000 --- a/contrib/bind9/doc/rfc/rfc2915.txt +++ /dev/null @@ -1,1011 +0,0 @@ - - - - - - -Network Working Group M. Mealling -Request for Comments: 2915 Network Solutions, Inc. -Updates: 2168 R. Daniel -Category: Standards Track DATAFUSION, Inc. - September 2000 - - - The Naming Authority Pointer (NAPTR) DNS Resource Record - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - This document describes a Domain Name System (DNS) resource record - which specifies a regular expression based rewrite rule that, when - applied to an existing string, will produce a new domain label or - Uniform Resource Identifier (URI). Depending on the value of the - flags field of the resource record, the resulting domain label or URI - may be used in subsequent queries for the Naming Authority Pointer - (NAPTR) resource records (to delegate the name lookup) or as the - output of the entire process for which this system is used (a - resolution server for URI resolution, a service URI for ENUM style - e.164 number to URI mapping, etc). - - This allows the DNS to be used to lookup services for a wide variety - of resource names (including URIs) which are not in domain name - syntax. Reasons for doing this range from URN Resource Discovery - Systems to moving out-of-date services to new domains. - - This document updates the portions of RFC 2168 specifically dealing - with the definition of the NAPTR records and how other, non-URI - specific applications, might use NAPTR. - - - - - - - - - -Mealling & Daniel Standards Track [Page 1] - -RFC 2915 NAPTR DNS RR September 2000 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. NAPTR RR Format . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Substitution Expression Grammar . . . . . . . . . . . . . . 7 - 4. The Basic NAPTR Algorithm . . . . . . . . . . . . . . . . . 8 - 5. Concerning How NAPTR Uses SRV Records . . . . . . . . . . . 9 - 6. Application Specifications . . . . . . . . . . . . . . . . . 10 - 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 7.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 7.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 7.3 Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 8. DNS Packet Format . . . . . . . . . . . . . . . . . . . . . 13 - 9. Master File Format . . . . . . . . . . . . . . . . . . . . . 14 - 10. Advice for DNS Administrators . . . . . . . . . . . . . . . 14 - 11. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 - 13. Security Considerations . . . . . . . . . . . . . . . . . . 15 - 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16 - References . . . . . . . . . . . . . . . . . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 - Full Copyright Statement . . . . . . . . . . . . . . . . . . 18 - -1. Introduction - - This RR was originally produced by the URN Working Group [3] as a way - to encode rule-sets in DNS so that the delegated sections of a URI - could be decomposed in such a way that they could be changed and re- - delegated over time. The result was a Resource Record that included - a regular expression that would be used by a client program to - rewrite a string into a domain name. Regular expressions were chosen - for their compactness to expressivity ratio allowing for a great deal - of information to be encoded in a rather small DNS packet. - - The function of rewriting a string according to the rules in a record - has usefulness in several different applications. This document - defines the basic assumptions to which all of those applications must - adhere to. It does not define the reasons the rewrite is used, what - the expected outcomes are, or what they are used for. Those are - specified by applications that define how they use the NAPTR record - and algorithms within their contexts. - - Flags and other fields are also specified in the RR to control the - rewrite procedure in various ways or to provide information on how to - communicate with the host at the domain name that was the result of - the rewrite. - - - - - -Mealling & Daniel Standards Track [Page 2] - -RFC 2915 NAPTR DNS RR September 2000 - - - The final result is a RR that has several fields that interact in a - non-trivial but implementable way. This document specifies those - fields and their values. - - This document does not define applications that utilizes this rewrite - functionality. Instead it specifies just the mechanics of how it is - done. Why its done, what the rules concerning the inputs, and the - types of rules used are reserved for other documents that fully - specify a particular application. This separation is due to several - different applications all wanting to take advantage of the rewrite - rule lookup process. Each one has vastly different reasons for why - and how it uses the service, thus requiring that the definition of - the service be generic. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL - NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" - in this document are to be interpreted as described in RFC 2119. - - All references to Uniform Resource Identifiers in this document - adhere to the 'absoluteURI' production of the "Collected ABNF" - found in RFC 2396 [9]. Specifically, the semantics of URI - References do not apply since the concept of a Base makes no sense - here. - -2. NAPTR RR Format - - The format of the NAPTR RR is given below. The DNS type code [1] for - NAPTR is 35. - - Domain TTL Class Type Order Preference Flags Service Regexp - Replacement - - Domain - The domain name to which this resource record refers. This is the - 'key' for this entry in the rule database. This value will either - be the first well known key (<something>.uri.arpa for example) or - a new key that is the output of a replacement or regexp rewrite. - Beyond this, it has the standard DNS requirements [1]. - - TTL - Standard DNS meaning [1]. - - Class - Standard DNS meaning [1]. - - Type - The Type Code [1] for NAPTR is 35. - - - - -Mealling & Daniel Standards Track [Page 3] - -RFC 2915 NAPTR DNS RR September 2000 - - - Order - A 16-bit unsigned integer specifying the order in which the NAPTR - records MUST be processed to ensure the correct ordering of - rules. Low numbers are processed before high numbers, and once a - NAPTR is found whose rule "matches" the target, the client MUST - NOT consider any NAPTRs with a higher value for order (except as - noted below for the Flags field). - - Preference - A 16-bit unsigned integer that specifies the order in which NAPTR - records with equal "order" values SHOULD be processed, low - numbers being processed before high numbers. This is similar to - the preference field in an MX record, and is used so domain - administrators can direct clients towards more capable hosts or - lighter weight protocols. A client MAY look at records with - higher preference values if it has a good reason to do so such as - not understanding the preferred protocol or service. - - The important difference between Order and Preference is that - once a match is found the client MUST NOT consider records with a - different Order but they MAY process records with the same Order - but different Preferences. I.e., Preference is used to give weight - to rules that are considered the same from an authority - standpoint but not from a simple load balancing standpoint. - - Flags - A <character-string> containing flags to control aspects of the - rewriting and interpretation of the fields in the record. Flags - are single characters from the set [A-Z0-9]. The case of the - alphabetic characters is not significant. - - At this time only four flags, "S", "A", "U", and "P", are - defined. The "S", "A" and "U" flags denote a terminal lookup. - This means that this NAPTR record is the last one and that the - flag determines what the next stage should be. The "S" flag - means that the next lookup should be for SRV records [4]. See - Section 5 for additional information on how NAPTR uses the SRV - record type. "A" means that the next lookup should be for either - an A, AAAA, or A6 record. The "U" flag means that the next step - is not a DNS lookup but that the output of the Regexp field is an - URI that adheres to the 'absoluteURI' production found in the - ABNF of RFC 2396 [9]. Since there may be applications that use - NAPTR to also lookup aspects of URIs, implementors should be - aware that this may cause loop conditions and should act - accordingly. - - - - - - -Mealling & Daniel Standards Track [Page 4] - -RFC 2915 NAPTR DNS RR September 2000 - - - The "P" flag says that the remainder of the application side - algorithm shall be carried out in a Protocol-specific fashion. - The new set of rules is identified by the Protocol specified in - the Services field. The record that contains the 'P' flag is the - last record that is interpreted by the rules specified in this - document. The new rules are dependent on the application for - which they are being used and the protocol specified. For - example, if the application is a URI RDS and the protocol is WIRE - then the new set of rules are governed by the algorithms - surrounding the WIRE HTTP specification and not this document. - - The remaining alphabetic flags are reserved for future versions - of the NAPTR specification. The numeric flags may be used for - local experimentation. The S, A, U and P flags are all mutually - exclusive, and resolution libraries MAY signal an error if more - than one is given. (Experimental code and code for assisting in - the creation of NAPTRs would be more likely to signal such an - error than a client such as a browser). It is anticipated that - multiple flags will be allowed in the future, so implementers - MUST NOT assume that the flags field can only contain 0 or 1 - characters. Finally, if a client encounters a record with an - unknown flag, it MUST ignore it and move to the next record. This - test takes precedence even over the "order" field. Since flags - can control the interpretation placed on fields, a novel flag - might change the interpretation of the regexp and/or replacement - fields such that it is impossible to determine if a record - matched a given target. - - The "S", "A", and "U" flags are called 'terminal' flags since - they halt the looping rewrite algorithm. If those flags are not - present, clients may assume that another NAPTR RR exists at the - domain name produced by the current rewrite rule. Since the "P" - flag specifies a new algorithm, it may or may not be 'terminal'. - Thus, the client cannot assume that another NAPTR exists since - this case is determined elsewhere. - - DNS servers MAY interpret these flags and values and use that - information to include appropriate SRV and A,AAAA, or A6 records - in the additional information portion of the DNS packet. Clients - are encouraged to check for additional information but are not - required to do so. - - Service - Specifies the service(s) available down this rewrite path. It may - also specify the particular protocol that is used to talk with a - service. A protocol MUST be specified if the flags field states - that the NAPTR is terminal. If a protocol is specified, but the - flags field does not state that the NAPTR is terminal, the next - - - -Mealling & Daniel Standards Track [Page 5] - -RFC 2915 NAPTR DNS RR September 2000 - - - lookup MUST be for a NAPTR. The client MAY choose not to perform - the next lookup if the protocol is unknown, but that behavior - MUST NOT be relied upon. - - The service field may take any of the values below (using the - Augmented BNF of RFC 2234 [5]): - - service_field = [ [protocol] *("+" rs)] - protocol = ALPHA *31ALPHANUM - rs = ALPHA *31ALPHANUM - ; The protocol and rs fields are limited to 32 - ; characters and must start with an alphabetic. - - For example, an optional protocol specification followed by 0 or - more resolution services. Each resolution service is indicated by - an initial '+' character. - - Note that the empty string is also a valid service field. This - will typically be seen at the beginning of a series of rules, - when it is impossible to know what services and protocols will be - offered by a particular service. - - The actual format of the service request and response will be - determined by the resolution protocol, and is the subject for - other documents. Protocols need not offer all services. The - labels for service requests shall be formed from the set of - characters [A-Z0-9]. The case of the alphabetic characters is - not significant. - - The list of "valid" protocols for any given NAPTR record is any - protocol that implements some or all of the services defined for - a NAPTR application. Currently, THTTP [6] is the only protocol - that is known to make that claim at the time of publication. Any - other protocol that is to be used must have documentation - specifying: - - * how it implements the services of the application - - * how it is to appear in the NAPTR record (i.e., the string id - of the protocol) - - The list of valid Resolution Services is defined by the documents - that specify individual NAPTR based applications. - - It is worth noting that the interpretation of this field is - subject to being changed by new flags, and that the current - specification is oriented towards telling clients how to talk - with a URN resolver. - - - -Mealling & Daniel Standards Track [Page 6] - -RFC 2915 NAPTR DNS RR September 2000 - - - Regexp - A STRING containing a substitution expression that is applied to - the original string held by the client in order to construct the - next domain name to lookup. The grammar of the substitution - expression is given in the next section. - - The regular expressions MUST NOT be used in a cumulative fashion, - that is, they should only be applied to the original string held - by the client, never to the domain name produced by a previous - NAPTR rewrite. The latter is tempting in some applications but - experience has shown such use to be extremely fault sensitive, - very error prone, and extremely difficult to debug. - - Replacement - The next NAME to query for NAPTR, SRV, or address records - depending on the value of the flags field. This MUST be a fully - qualified domain-name. Unless and until permitted by future - standards action, name compression is not to be used for this - field. - -3. Substitution Expression Grammar - - The content of the regexp field is a substitution expression. True - sed(1) and Perl style substitution expressions are not appropriate - for use in this application for a variety of reasons stemming from - internationalization requirements and backref limitations, therefore - the contents of the regexp field MUST follow the grammar below: - -subst_expr = delim-char ere delim-char repl delim-char *flags -delim-char = "/" / "!" / ... <Any non-digit or non-flag character - other than backslash '\'. All occurances of a delim_char - in a subst_expr must be the same character.> -ere = POSIX Extended Regular Expression -repl = 1 * ( OCTET / backref ) -backref = "\" 1POS_DIGIT -flags = "i" -POS_DIGIT = %x31-39 ; 0 is not an allowed backref - - The definition of a POSIX Extended Regular Expression can be found in - [8], section 2.8.4. - - The result of applying the substitution expression to the original - URI MUST result in either a string that obeys the syntax for DNS - domain-names [1] or a URI [9] if the Flags field contains a 'u'. - Since it is possible for the regexp field to be improperly specified, - such that a non-conforming domain-name can be constructed, client - software SHOULD verify that the result is a legal DNS domain-name - before making queries on it. - - - -Mealling & Daniel Standards Track [Page 7] - -RFC 2915 NAPTR DNS RR September 2000 - - - Backref expressions in the repl portion of the substitution - expression are replaced by the (possibly empty) string of characters - enclosed by '(' and ')' in the ERE portion of the substitution - expression. N is a single digit from 1 through 9, inclusive. It - specifies the N'th backref expression, the one that begins with the - N'th '(' and continues to the matching ')'. For example, the ERE - - (A(B(C)DE)(F)G) - - has backref expressions: - - \1 = ABCDEFG - \2 = BCDE - \3 = C - \4 = F - \5..\9 = error - no matching subexpression - - The "i" flag indicates that the ERE matching SHALL be performed in a - case-insensitive fashion. Furthermore, any backref replacements MAY - be normalized to lower case when the "i" flag is given. - - The first character in the substitution expression shall be used as - the character that delimits the components of the substitution - expression. There must be exactly three non-escaped occurrences of - the delimiter character in a substitution expression. Since escaped - occurrences of the delimiter character will be interpreted as - occurrences of that character, digits MUST NOT be used as delimiters. - Backrefs would be confused with literal digits were this allowed. - Similarly, if flags are specified in the substitution expression, the - delimiter character must not also be a flag character. - -4. The Basic NAPTR Algorithm - - The behavior and meaning of the flags and services assume an - algorithm where the output of one rewrite is a new key that points to - another rule. This looping algorithm allows NAPTR records to - incrementally specify a complete rule. These incremental rules can - be delegated which allows other entities to specify rules so that one - entity does not need to understand _all_ rules. - - The algorithm starts with a string and some known key (domain). - NAPTR records for this key are retrieved, those with unknown Flags or - inappropriate Services are discarded and the remaining records are - sorted by their Order field. Within each value of Order, the records - are further sorted by the Preferences field. - - The records are examined in sorted order until a matching record is - found. A record is considered a match iff: - - - -Mealling & Daniel Standards Track [Page 8] - -RFC 2915 NAPTR DNS RR September 2000 - - - o it has a Replacement field value instead of a Regexp field value. - - o or the Regexp field matches the string held by the client. - - The first match MUST be the match that is used. Once a match is - found, the Services field is examined for whether or not this rule - advances toward the desired result. If so, the rule is applied to - the target string. If not, the process halts. The domain that - results from the regular expression is then used as the domain of the - next loop through the NAPTR algorithm. Note that the same target - string is used throughout the algorithm. - - This looping is extremely important since it is the method by which - complex rules are broken down into manageable delegated chunks. The - flags fields simply determine at which point the looping should stop - (or other specialized behavior). - - Since flags are valid at any level of the algorithm, the degenerative - case is to never loop but to look up the NAPTR and then stop. In - many specialized cases this is all that is needed. Implementors - should be aware that the degenerative case should not become the - common case. - -5. Concerning How NAPTR Uses SRV Records - - When the SRV record type was originally specified it assumed that the - client did not know the specific domain-name before hand. The client - would construct a domain-name more in the form of a question than the - usual case of knowing ahead of time that the domain-name should - exist. I.e., if the client wants to know if there is a TCP based - HTTP server running at a particular domain, the client would - construct the domain-name _http._tcp.somedomain.com and ask the DNS - if that records exists. The underscores are used to avoid collisions - with potentially 'real' domain-names. - - In the case of NAPTR, the actual domain-name is specified by the - various fields in the NAPTR record. In this case the client isn't - asking a question but is instead attempting to get at information - that it has been told exists in an SRV record at that particular - domain-name. While this usage of SRV is slightly different than the - SRV authors originally intended it does not break any of the - assumptions concerning what SRV contains. Also, since the NAPTR - explicitly spells out the domain-name for which an SRV exists, that - domain-name MUST be used in SRV queries with NO transformations. Any - given NAPTR record may result in a domain-name to be used for SRV - queries that may or may not contain the SRV standardized underscore - - - - - -Mealling & Daniel Standards Track [Page 9] - -RFC 2915 NAPTR DNS RR September 2000 - - - characters. NAPTR applications that make use of SRV MUST NOT attempt - to understand these domains or use them according to how the SRV - specification structures its query domains. - -6. Application Specifications - - It should be noted that the NAPTR algorithm is the basic assumption - about how NAPTR works. The reasons for the rewrite and the expected - output and its use are specified by documents that define what - applications the NAPTR record and algorithm are used for. Any - document that defines such an application must define the following: - - o The first known domain-name or how to build it - - o The valid Services and Protocols - - o What the expected use is for the output of the last rewrite - - o The validity and/or behavior of any 'P' flag protocols. - - o The general semantics surrounding why and how NAPTR and its - algorithm are being used. - -7. Examples - - NOTE: These are examples only. They are taken from ongoing work and - may not represent the end result of that work. They are here for - pedagogical reasons only. - -7.1 Example 1 - - NAPTR was originally specified for use with the a Uniform Resource - Name Resolver Discovery System. This example details how a - particular URN would use the NAPTR record to find a resolver service. - - Consider a URN namespace based on MIME Content-Ids. The URN might - look like this: - - urn:cid:39CB83F7.A8450130@fake.gatech.edu - - (Note that this example is chosen for pedagogical purposes, and does - not conform to the CID URL scheme.) - - The first step in the resolution process is to find out about the CID - namespace. The namespace identifier [3], 'cid', is extracted from - the URN, prepended to urn.arpa. 'cid.urn.arpa' then becomes the first - 'known' key in the NAPTR algorithm. The NAPTR records for - cid.urn.arpa looked up and return a single record: - - - -Mealling & Daniel Standards Track [Page 10] - -RFC 2915 NAPTR DNS RR September 2000 - - - cid.urn.arpa. - ;; order pref flags service regexp replacement - IN NAPTR 100 10 "" "" "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i" . - - There is only one NAPTR response, so ordering the responses is not a - problem. The replacement field is empty, so the pattern provided in - the regexp field is used. We apply that regexp to the entire URN to - see if it matches, which it does. The \2 part of the substitution - expression returns the string "gatech.edu". Since the flags field - does not contain "s" or "a", the lookup is not terminal and our next - probe to DNS is for more NAPTR records where the new domain is ' - gatech.edu' and the string is the same string as before. - - Note that the rule does not extract the full domain name from the - CID, instead it assumes the CID comes from a host and extracts its - domain. While all hosts, such as mordred, could have their very own - NAPTR, maintaining those records for all the machines at a site as - large as Georgia Tech would be an intolerable burden. Wildcards are - not appropriate here since they only return results when there is no - exactly matching names already in the system. - - The record returned from the query on "gatech.edu" might look like: - -;; order pref flags service regexp replacement - IN NAPTR 100 50 "s" "z3950+I2L+I2C" "" _z3950._tcp.gatech.edu. - IN NAPTR 100 50 "s" "rcds+I2C" "" _rcds._udp.gatech.edu. - IN NAPTR 100 50 "s" "http+I2L+I2C+I2R" "" _http._tcp.gatech.edu. - - Continuing with the example, note that the values of the order and - preference fields are equal in all records, so the client is free to - pick any record. The flags field tells us that these are the last - NAPTR patterns we should see, and after the rewrite (a simple - replacement in this case) we should look up SRV records to get - information on the hosts that can provide the necessary service. - - Assuming we prefer the Z39.50 protocol, our lookup might return: - - ;; Pref Weight Port Target - _z3950._tcp.gatech.edu. IN SRV 0 0 1000 z3950.gatech.edu. - IN SRV 0 0 1000 z3950.cc.gatech.edu. - IN SRV 0 0 1000 z3950.uga.edu. - - telling us three hosts that could actually do the resolution, and - giving us the port we should use to talk to their Z39.50 server. - - Recall that the regular expression used \2 to extract a domain name - from the CID, and \. for matching the literal '.' characters - separating the domain name components. Since '\' is the escape - - - -Mealling & Daniel Standards Track [Page 11] - -RFC 2915 NAPTR DNS RR September 2000 - - - character, literal occurances of a backslash must be escaped by - another backslash. For the case of the cid.urn.arpa record above, - the regular expression entered into the master file should be - "/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i". When the client code actually - receives the record, the pattern will have been converted to - "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i". - -7.2 Example 2 - - Even if URN systems were in place now, there would still be a - tremendous number of URLs. It should be possible to develop a URN - resolution system that can also provide location independence for - those URLs. This is related to the requirement that URNs be able to - grandfather in names from other naming systems, such as ISO Formal - Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs, - etc. - - The NAPTR RR could also be used for URLs that have already been - assigned. Assume we have the URL for a very popular piece of - software that the publisher wishes to mirror at multiple sites around - the world: - - Using the rules specified for this application we extract the prefix, - "http", and lookup NAPTR records for http.uri.arpa. This might - return a record of the form - - http.uri.arpa. IN NAPTR - ;; order pref flags service regexp replacement - 100 90 "" "" "!http://([^/:]+)!\1!i" . - - This expression returns everything after the first double slash and - before the next slash or colon. (We use the '!' character to delimit - the parts of the substitution expression. Otherwise we would have to - use backslashes to escape the forward slashes and would have a regexp - in the zone file that looked like "/http:\\/\\/([^\\/:]+)/\\1/i".). - - Applying this pattern to the URL extracts "www.foo.com". Looking up - NAPTR records for that might return: - - www.foo.com. - ;; order pref flags service regexp replacement - IN NAPTR 100 100 "s" "http+I2R" "" _http._tcp.foo.com. - IN NAPTR 100 100 "s" "ftp+I2R" "" _ftp._tcp.foo.com. - - Looking up SRV records for http.tcp.foo.com would return information - on the hosts that foo.com has designated to be its mirror sites. The - client can then pick one for the user. - - - - -Mealling & Daniel Standards Track [Page 12] - -RFC 2915 NAPTR DNS RR September 2000 - - -7.3 Example 3 - - A non-URI example is the ENUM application which uses a NAPTR record - to map an e.164 telephone number to a URI. In order to convert the - phone number to a domain name for the first iteration all characters - other than digits are removed from the the telephone number, the - entire number is inverted, periods are put between each digit and the - string ".e164.arpa" is put on the left-hand side. For example, the - E.164 phone number "+1-770-555-1212" converted to a domain-name it - would be "2.1.2.1.5.5.5.0.7.7.1.e164.arpa." - - For this example telephone number we might get back the following - NAPTR records: - -$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa. - IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information@tele2.se!" . - IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:information@tele2.se!" . - - This application uses the same 'u' flag as the URI Resolution - application. This flag states that the Rule is terminal and that the - output is a URI which contains the information needed to contact that - telephone service. ENUM also uses the same format for its Service - field except that it defines the 'E2U' service instead of the 'I2*' - services that URI resolution uses. The example above states that the - available protocols used to access that telephone's service are - either the Session Initiation Protocol or SMTP mail. - -8. DNS Packet Format - - The packet format for the NAPTR record is: - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ORDER | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | PREFERENCE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / FLAGS / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / SERVICES / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / REGEXP / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / REPLACEMENT / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - - - -Mealling & Daniel Standards Track [Page 13] - -RFC 2915 NAPTR DNS RR September 2000 - - - where: - - FLAGS A <character-string> which contains various flags. - - SERVICES A <character-string> which contains protocol and service - identifiers. - - REGEXP A <character-string> which contains a regular expression. - - REPLACEMENT A <domain-name> which specifies the new value in the - case where the regular expression is a simple replacement - operation. - - <character-string> and <domain-name> as used here are defined in - RFC1035 [1]. - -9. Master File Format - - The master file format follows the standard rules in RFC-1035 [1]. - Order and preference, being 16-bit unsigned integers, shall be an - integer between 0 and 65535. The Flags and Services and Regexp - fields are all quoted <character-string>s. Since the Regexp field - can contain numerous backslashes and thus should be treated with - care. See Section 10 for how to correctly enter and escape the - regular expression. - -10. Advice for DNS Administrators - - Beware of regular expressions. Not only are they difficult to get - correct on their own, but there is the previously mentioned - interaction with DNS. Any backslashes in a regexp must be entered - twice in a zone file in order to appear once in a query response. - More seriously, the need for double backslashes has probably not been - tested by all implementors of DNS servers. - - The "a" flag allows the next lookup to be for address records (A, - AAAA, A6) rather than SRV records. Since there is no place for a - port specification in the NAPTR record, when the "A" flag is used the - specified protocol must be running on its default port. - - The URN Syntax draft defines a canonical form for each URN, which - requires %encoding characters outside a limited repertoire. The - regular expressions MUST be written to operate on that canonical - form. Since international character sets will end up with extensive - use of %encoded characters, regular expressions operating on them - will be essentially impossible to read or write by hand. - - - - - -Mealling & Daniel Standards Track [Page 14] - -RFC 2915 NAPTR DNS RR September 2000 - - -11. Notes - - o A client MUST process multiple NAPTR records in the order - specified by the "order" field, it MUST NOT simply use the first - record that provides a known protocol and service combination. - - o When multiple RRs have the same "order" and all other criteria - being equal, the client should use the value of the preference - field to select the next NAPTR to consider. However, because it - will often be the case where preferred protocols or services - exist, clients may use this additional criteria to sort - the records. - - o If the lookup after a rewrite fails, clients are strongly - encouraged to report a failure, rather than backing up to pursue - other rewrite paths. - - o Note that SRV RRs impose additional requirements on clients. - -12. IANA Considerations - - The only registration function that impacts the IANA is for the - values that are standardized for the Services and Flags fields. To - extend the valid values of the Flags field beyond what is specified - in this document requires a published specification that is approved - by the IESG. - - The values for the Services field will be determined by the - application that makes use of the NAPTR record. Those values must be - specified in a published specification and approved by the IESG. - -13. Security Considerations - - The interactions with DNSSEC are currently being studied. It is - expected that NAPTR records will be signed with SIG records once the - DNSSEC work is deployed. - - The rewrite rules make identifiers from other namespaces subject to - the same attacks as normal domain names. Since they have not been - easily resolvable before, this may or may not be considered a - problem. - - Regular expressions should be checked for sanity, not blindly passed - to something like PERL. - - This document has discussed a way of locating a service, but has not - discussed any detail of how the communication with that service takes - place. There are significant security considerations attached to the - - - -Mealling & Daniel Standards Track [Page 15] - -RFC 2915 NAPTR DNS RR September 2000 - - - communication with a service. Those considerations are outside the - scope of this document, and must be addressed by the specifications - for particular communication protocols. - -14. Acknowledgments - - The editors would like to thank Keith Moore for all his consultations - during the development of this memo. We would also like to thank - Paul Vixie for his assistance in debugging our implementation, and - his answers on our questions. Finally, we would like to acknowledge - our enormous intellectual debt to the participants in the Knoxville - series of meetings, as well as to the participants in the URI and URN - working groups. - -References - - [1] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [2] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [3] Moats, R., "URN Syntax", RFC 2141, May 1997. - - [4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for - specifying the location of services (DNS SRV)", RFC 2782, - February 2000. - - [5] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", - RFC 2234, November 1997. - - [6] Daniel, R., "A Trivial Convention for using HTTP in URN - Resolution", RFC 2169, June 1997. - - [7] Daniel, R. and M. Mealling, "Resolution of Uniform Resource - Identifiers using the Domain Name System", RFC 2168, June 1997. - - [8] IEEE, "IEEE Standard for Information Technology - Portable - Operating System Interface (POSIX) - Part 2: Shell and Utilities - (Vol. 1)", IEEE Std 1003.2-1992, January 1993. - - [9] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform - Resource Identifiers (URI): Generic Syntax", RFC 2396, August - 1998. - - - - - - - -Mealling & Daniel Standards Track [Page 16] - -RFC 2915 NAPTR DNS RR September 2000 - - -Authors' Addresses - - Michael Mealling - Network Solutions, Inc. - 505 Huntmar Park Drive - Herndon, VA 22070 - US - - Phone: +1 770 921 2251 - EMail: michaelm@netsol.com - URI: http://www.netsol.com - - - Ron Daniel - DATAFUSION, Inc. - 139 Townsend Street, Ste. 100 - San Francisco, CA 94107 - US - - Phone: +1 415 222 0100 - EMail: rdaniel@datafusion.net - URI: http://www.datafusion.net - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Mealling & Daniel Standards Track [Page 17] - -RFC 2915 NAPTR DNS RR September 2000 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Mealling & Daniel Standards Track [Page 18] - diff --git a/contrib/bind9/doc/rfc/rfc2929.txt b/contrib/bind9/doc/rfc/rfc2929.txt deleted file mode 100644 index f055968935b8..000000000000 --- a/contrib/bind9/doc/rfc/rfc2929.txt +++ /dev/null @@ -1,675 +0,0 @@ - - - - - - -Network Working Group D. Eastlake, 3rd -Request for Comments: 2929 Motorola -BCP: 42 E. Brunner-Williams -Category: Best Current Practice Engage - B. Manning - ISI - September 2000 - - Domain Name System (DNS) IANA Considerations - -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. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - Internet Assigned Number Authority (IANA) parameter assignment - considerations are given for the allocation of Domain Name System - (DNS) classes, Resource Record (RR) types, operation codes, error - codes, etc. - -Table of Contents - - 1. Introduction................................................. 2 - 2. DNS Query/Response Headers................................... 2 - 2.1 One Spare Bit?.............................................. 3 - 2.2 Opcode Assignment........................................... 3 - 2.3 RCODE Assignment............................................ 4 - 3. DNS Resource Records......................................... 5 - 3.1 RR TYPE IANA Considerations................................. 6 - 3.1.1 Special Note on the OPT RR................................ 7 - 3.2 RR CLASS IANA Considerations................................ 7 - 3.3 RR NAME Considerations...................................... 8 - 4. Security Considerations...................................... 9 - References...................................................... 9 - Authors' Addresses.............................................. 11 - Full Copyright Statement........................................ 12 - - - - - - - - -Eastlake, et al. Best Current Practice [Page 1] - -RFC 2929 DNS IANA Considerations September 2000 - - -1. Introduction - - The Domain Name System (DNS) provides replicated distributed secure - hierarchical databases which hierarchically store "resource records" - (RRs) under domain names. - - This data is structured into CLASSes and zones which can be - independently maintained. See [RFC 1034, 1035, 2136, 2181, 2535] - familiarity with which is assumed. - - This document covers, either directly or by reference, general IANA - parameter assignment considerations applying across DNS query and - response headers and all RRs. There may be additional IANA - considerations that apply to only a particular RR type or - query/response opcode. See the specific RFC defining that RR type or - query/response opcode for such considerations if they have been - defined. - - IANA currently maintains a web page of DNS parameters. See - <http://www.iana.org/numbers.htm>. - - "IETF Standards Action", "IETF Consensus", "Specification Required", - and "Private Use" are as defined in [RFC 2434]. - -2. DNS Query/Response Headers - - The header for DNS queries and responses contains field/bits in the - following diagram taken from [RFC 2136, 2535]: - - 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| Z|AD|CD| RCODE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | QDCOUNT/ZOCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ANCOUNT/PRCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | NSCOUNT/UPCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ARCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - The ID field identifies the query and is echoed in the response so - they can be matched. - - - - -Eastlake, et al. Best Current Practice [Page 2] - -RFC 2929 DNS IANA Considerations September 2000 - - - The QR bit indicates whether the header is for a query or a response. - - The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful - only in queries or only in responses, depending on the bit. However, - many DNS implementations copy the query header as the initial value - of the response header without clearing bits. Thus any attempt to - use a "query" bit with a different meaning in a response or to define - a query meaning for a "response" bit is dangerous given existing - implementation. Such meanings may only be assigned by an IETF - Standards Action. - - The unsigned fields query count (QDCOUNT), answer count (ANCOUNT), - authority count (NSCOUNT), and additional information count (ARCOUNT) - express the number of records in each section for all opcodes except - Update. These fields have the same structure and data type for - Update but are instead the counts for the zone (ZOCOUNT), - prerequisite (PRCOUNT), update (UPCOUNT), and additional information - (ARCOUNT) sections. - -2.1 One Spare Bit? - - There have been ancient DNS implementations for which the Z bit being - on in a query meant that only a response from the primary server for - a zone is acceptable. It is believed that current DNS - implementations ignore this bit. - - Assigning a meaning to the Z bit requires an IETF Standards Action. - -2.2 Opcode Assignment - - New OpCode assignments require an IETF Standards Action. - - Currently DNS OpCodes are assigned as follows: - - OpCode Name Reference - - 0 Query [RFC 1035] - 1 IQuery (Inverse Query) [RFC 1035] - 2 Status [RFC 1035] - 3 available for assignment - 4 Notify [RFC 1996] - 5 Update [RFC 2136] - 6-15 available for assignment - - - - - - - - -Eastlake, et al. Best Current Practice [Page 3] - -RFC 2929 DNS IANA Considerations September 2000 - - -2.3 RCODE Assignment - - It would appear from the DNS header above that only four bits of - RCODE, or response/error code are available. However, RCODEs can - appear not only at the top level of a DNS response but also inside - OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930]. - The OPT RR provides an eight bit extension resulting in a 12 bit - RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field. - - Error codes appearing in the DNS header and in these three RR types - all refer to the same error code space with the single exception of - error code 16 which has a different meaning in the OPT RR from its - meaning in other contexts. See table below. - - RCODE Name Description Reference - Decimal - Hexadecimal - 0 NoError No Error [RFC 1035] - 1 FormErr Format Error [RFC 1035] - 2 ServFail Server Failure [RFC 1035] - 3 NXDomain Non-Existent Domain [RFC 1035] - 4 NotImp Not Implemented [RFC 1035] - 5 Refused Query Refused [RFC 1035] - 6 YXDomain Name Exists when it should not [RFC 2136] - 7 YXRRSet RR Set Exists when it should not [RFC 2136] - 8 NXRRSet RR Set that should exist does not [RFC 2136] - 9 NotAuth Server Not Authoritative for zone [RFC 2136] - 10 NotZone Name not contained in zone [RFC 2136] - 11-15 available for assignment - 16 BADVERS Bad OPT Version [RFC 2671] - 16 BADSIG TSIG Signature Failure [RFC 2845] - 17 BADKEY Key not recognized [RFC 2845] - 18 BADTIME Signature out of time window [RFC 2845] - 19 BADMODE Bad TKEY Mode [RFC 2930] - 20 BADNAME Duplicate key name [RFC 2930] - 21 BADALG Algorithm not supported [RFC 2930] - 22-3840 available for assignment - 0x0016-0x0F00 - 3841-4095 Private Use - 0x0F01-0x0FFF - 4096-65535 available for assignment - 0x1000-0xFFFF - - Since it is important that RCODEs be understood for interoperability, - assignment of new RCODE listed above as "available for assignment" - requires an IETF Consensus. - - - - - -Eastlake, et al. Best Current Practice [Page 4] - -RFC 2929 DNS IANA Considerations September 2000 - - -3. DNS Resource Records - - All RRs have the same top level format shown in the figure below - taken from [RFC 1035]: - - 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 / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - NAME is an owner name, i.e., the name of the node to which this - resource record pertains. NAMEs are specific to a CLASS as described - in section 3.2. NAMEs consist of an ordered sequence of one or more - labels each of which has a label type [RFC 1035, 2671]. - - TYPE is a two octet unsigned integer containing one of the RR TYPE - codes. See section 3.1. - - CLASS is a two octet unsigned integer containing one of the RR CLASS - codes. See section 3.2. - - TTL is a four octet (32 bit) bit unsigned integer that specifies the - number of seconds that the resource record may be cached before the - source of the information should again be consulted. Zero is - interpreted to mean that the RR can only be used for the transaction - in progress. - - RDLENGTH is an unsigned 16 bit integer that specifies the length in - octets of the RDATA field. - - - - - - -Eastlake, et al. Best Current Practice [Page 5] - -RFC 2929 DNS IANA Considerations September 2000 - - - RDATA is a variable length string of octets that constitutes the - resource. The format of this information varies according to the - TYPE and in some cases the CLASS of the resource record. - -3.1 RR TYPE IANA Considerations - - There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs, - and MetaTYPEs. - - Data TYPEs are the primary means of storing data. QTYPES can only be - used in queries. Meta-TYPEs designate transient data associated with - an particular DNS message and in some cases can also be used in - queries. Thus far, data TYPEs have been assigned from 1 upwards plus - the block from 100 through 103 while Q and Meta Types have been - assigned from 255 downwards (except for the OPT Meta-RR which is - assigned TYPE 41). There have been DNS implementations which made - caching decisions based on the top bit of the bottom byte of the RR - TYPE. - - There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG - [RFC 2845], and TKEY [RFC 2930]. - - There are currently five QTYPEs assigned: * (all), MAILA, MAILB, - AXFR, and IXFR. - - Considerations for the allocation of new RR TYPEs are as follows: - - Decimal - Hexadecimal - - 0 - 0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC - 2535] and in other circumstances and must never be allocated - for ordinary use. - - 1 - 127 - 0x0001 - 0x007F - remaining TYPEs in this range are assigned for data - TYPEs by IETF Consensus. - - 128 - 255 - 0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and - Meta TYPEs by IETF Consensus. - - 256 - 32767 - 0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF - Consensus. - - - - - -Eastlake, et al. Best Current Practice [Page 6] - -RFC 2929 DNS IANA Considerations September 2000 - - - 32768 - 65279 - 0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434]. - - 65280 - 65535 - 0xFF00 - 0xFFFF - Private Use. - -3.1.1 Special Note on the OPT RR - - The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its - primary purpose is to extend the effective field size of various DNS - fields including RCODE, label type, flag bits, and RDATA size. In - particular, for resolvers and servers that recognize it, it extends - the RCODE field from 4 to 12 bits. - -3.2 RR CLASS IANA Considerations - - DNS CLASSes have been little used but constitute another dimension of - the DNS distributed database. In particular, there is no necessary - relationship between the name space or root servers for one CLASS and - those for another CLASS. The same name can have completely different - meanings in different CLASSes although the label types are the same - and the null label is usable only as root in every CLASS. However, - as global networking and DNS have evolved, the IN, or Internet, CLASS - has dominated DNS use. - - There are two subcategories of DNS CLASSes: normal data containing - classes and QCLASSes that are only meaningful in queries or updates. - - The current CLASS assignments and considerations for future - assignments are as follows: - - Decimal - Hexadecimal - - 0 - 0x0000 - assignment requires an IETF Standards Action. - - 1 - 0x0001 - Internet (IN). - - 2 - 0x0002 - available for assignment by IETF Consensus as a data CLASS. - - 3 - 0x0003 - Chaos (CH) [Moon 1981]. - - 4 - 0x0004 - Hesiod (HS) [Dyer 1987]. - - - -Eastlake, et al. Best Current Practice [Page 7] - -RFC 2929 DNS IANA Considerations September 2000 - - - 5 - 127 - 0x0005 - 0x007F - available for assignment by IETF Consensus as data - CLASSes only. - - 128 - 253 - 0x0080 - 0x00FD - available for assignment by IETF Consensus as - QCLASSes only. - - 254 - 0x00FE - QCLASS None [RFC 2136]. - - 255 - 0x00FF - QCLASS Any [RFC 1035]. - - 256 - 32767 - 0x0100 - 0x7FFF - assigned by IETF Consensus. - - 32768 - 65280 - 0x8000 - 0xFEFF - assigned based on Specification Required as defined - in [RFC 2434]. - - 65280 - 65534 - 0xFF00 - 0xFFFE - Private Use. - - 65535 - 0xFFFF - can only be assigned by an IETF Standards Action. - -3.3 RR NAME Considerations - - DNS NAMEs are sequences of labels [RFC 1035]. The last label in each - NAME is "ROOT" which is the zero length label. By definition, the - null or ROOT label can not be used for any other NAME purpose. - - At the present time, there are two categories of label types, data - labels and compression labels. Compression labels are pointers to - data labels elsewhere within an RR or DNS message and are intended to - shorten the wire encoding of NAMEs. The two existing data label - types are sometimes referred to as Text and Binary. Text labels can, - in fact, include any octet value including zero octets but most - current uses involve only [US-ASCII]. For retrieval, Text labels are - defined to treat ASCII upper and lower case letter codes as matching. - Binary labels are bit sequences [RFC 2673]. - - IANA considerations for label types are given in [RFC 2671]. - - - - - - - -Eastlake, et al. Best Current Practice [Page 8] - -RFC 2929 DNS IANA Considerations September 2000 - - - NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon - 1981] CLASSes are essentially for local use. The IN or Internet - CLASS is thus the only DNS CLASS in global use on the Internet at - this time. - - A somewhat dated description of name allocation in the IN Class is - given in [RFC 1591]. Some information on reserved top level domain - names is in Best Current Practice 32 [RFC 2606]. - -4. Security Considerations - - This document addresses IANA considerations in the allocation of - general DNS parameters, not security. See [RFC 2535] for secure DNS - considerations. - -References - - [Dyer 1987] Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical - Plan - Name Service, April 1987, - - [Moon 1981] D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts - Institute of Technology Artificial Intelligence - Laboratory, June 1981. - - [RFC 1034] Mockapetris, P., "Domain Names - Concepts and - Facilities", STD 13, RFC 1034, November 1987. - - [RFC 1035] Mockapetris, P., "Domain Names - Implementation and - Specifications", STD 13, RFC 1035, November 1987. - - [RFC 1591] Postel, J., "Domain Name System Structure and - Delegation", RFC 1591, March 1994. - - [RFC 1996] Vixie, P., "A Mechanism for Prompt Notification of Zone - Changes (DNS NOTIFY)", RFC 1996, August 1996. - - [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - [RFC 2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - - - - - -Eastlake, et al. Best Current Practice [Page 9] - -RFC 2929 DNS IANA Considerations September 2000 - - - [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC 2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS - Names", RFC 2606, June 1999. - - [RFC 2671] Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC 2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC - 2672, August 1999. - - [RFC 2673] Crawford, M., "Binary Labels in the Domain Name System", - RFC 2673, August 1999. - - [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. - Wellington, "Secret Key Transaction Authentication for - DNS (TSIG)", RFC 2845, May 2000. - - [RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - [US-ASCII] ANSI, "USA Standard Code for Information Interchange", - X3.4, American National Standards Institute: New York, - 1968. - - - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake, et al. Best Current Practice [Page 10] - -RFC 2929 DNS IANA Considerations September 2000 - - -Authors' Addresses - - Donald E. Eastlake 3rd - Motorola - 140 Forest Avenue - Hudson, MA 01749 USA - - Phone: +1-978-562-2827 (h) - +1-508-261-5434 (w) - Fax: +1-508-261-4447 (w) - EMail: Donald.Eastlake@motorola.com - - - Eric Brunner-Williams - Engage - 100 Brickstone Square, 2nd Floor - Andover, MA 01810 - - Phone: +1-207-797-0525 (h) - +1-978-684-7796 (w) - Fax: +1-978-684-3118 - EMail: brunner@engage.com - - - Bill Manning - USC/ISI - 4676 Admiralty Way, #1001 - Marina del Rey, CA 90292 USA - - Phone: +1-310-822-1511 - EMail: bmanning@isi.edu - - - - - - - - - - - - - - - - - - - - -Eastlake, et al. Best Current Practice [Page 11] - -RFC 2929 DNS IANA Considerations September 2000 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Eastlake, et al. Best Current Practice [Page 12] - diff --git a/contrib/bind9/doc/rfc/rfc2930.txt b/contrib/bind9/doc/rfc/rfc2930.txt deleted file mode 100644 index f99573dd1cdf..000000000000 --- a/contrib/bind9/doc/rfc/rfc2930.txt +++ /dev/null @@ -1,899 +0,0 @@ - - - - - - -Network Working Group D. Eastlake, 3rd -Request for Comments: 2930 Motorola -Category: Standards Track September 2000 - - - Secret Key Establishment for DNS (TKEY RR) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - [RFC 2845] provides a means of authenticating Domain Name System - (DNS) queries and responses using shared secret keys via the - Transaction Signature (TSIG) resource record (RR). However, it - provides no mechanism for setting up such keys other than manual - exchange. This document describes a Transaction Key (TKEY) RR that - can be used in a number of different modes to establish shared secret - keys between a DNS resolver and server. - -Acknowledgments - - The comments and ideas of the following persons (listed in alphabetic - order) have been incorporated herein and are gratefully acknowledged: - - Olafur Gudmundsson (TIS) - - Stuart Kwan (Microsoft) - - Ed Lewis (TIS) - - Erik Nordmark (SUN) - - Brian Wellington (Nominum) - - - - - - - - -Eastlake Standards Track [Page 1] - -RFC 2930 The DNS TKEY RR September 2000 - - -Table of Contents - - 1. Introduction............................................... 2 - 1.1 Overview of Contents...................................... 3 - 2. The TKEY Resource Record................................... 4 - 2.1 The Name Field............................................ 4 - 2.2 The TTL Field............................................. 5 - 2.3 The Algorithm Field....................................... 5 - 2.4 The Inception and Expiration Fields....................... 5 - 2.5 The Mode Field............................................ 5 - 2.6 The Error Field........................................... 6 - 2.7 The Key Size and Data Fields.............................. 6 - 2.8 The Other Size and Data Fields............................ 6 - 3. General TKEY Considerations................................ 7 - 4. Exchange via Resolver Query................................ 8 - 4.1 Query for Diffie-Hellman Exchanged Keying................. 8 - 4.2 Query for TKEY Deletion................................... 9 - 4.3 Query for GSS-API Establishment........................... 10 - 4.4 Query for Server Assigned Keying.......................... 10 - 4.5 Query for Resolver Assigned Keying........................ 11 - 5. Spontaneous Server Inclusion............................... 12 - 5.1 Spontaneous Server Key Deletion........................... 12 - 6. Methods of Encryption...................................... 12 - 7. IANA Considerations........................................ 13 - 8. Security Considerations.................................... 13 - References.................................................... 14 - Author's Address.............................................. 15 - Full Copyright Statement...................................... 16 - -1. Introduction - - The Domain Name System (DNS) is a hierarchical, distributed, highly - available database used for bi-directional mapping between domain - names and addresses, for email routing, and for other information - [RFC 1034, 1035]. It has been extended to provide for public key - security and dynamic update [RFC 2535, RFC 2136]. Familiarity with - these RFCs is assumed. - - [RFC 2845] provides a means of efficiently authenticating DNS - messages using shared secret keys via the TSIG resource record (RR) - but provides no mechanism for setting up such keys other than manual - exchange. This document specifies a TKEY RR that can be used in a - number of different modes to establish and delete such shared secret - keys between a DNS resolver and server. - - - - - - - -Eastlake Standards Track [Page 2] - -RFC 2930 The DNS TKEY RR September 2000 - - - Note that TKEY established keying material and TSIGs that use it are - associated with DNS servers or resolvers. They are not associated - with zones. They may be used to authenticate queries and responses - but they do not provide zone based DNS data origin or denial - authentication [RFC 2535]. - - Certain modes of TKEY perform encryption which may affect their - export or import status for some countries. The affected modes - specified in this document are the server assigned mode and the - resolver assigned mode. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC 2119]. - - In all cases herein, the term "resolver" includes that part of a - server which may make full and incremental [RFC 1995] zone transfer - queries, forwards recursive queries, etc. - -1.1 Overview of Contents - - Section 2 below specifies the TKEY RR and provides a description of - and considerations for its constituent fields. - - Section 3 describes general principles of operations with TKEY. - - Section 4 discusses key agreement and deletion via DNS requests with - the Query opcode for RR type TKEY. This method is applicable to all - currently defined TKEY modes, although in some cases it is not what - would intuitively be called a "query". - - Section 5 discusses spontaneous inclusion of TKEY RRs in responses by - servers which is currently used only for key deletion. - - Section 6 describes encryption methods for transmitting secret key - information. In this document these are used only for the server - assigned mode and the resolver assigned mode. - - Section 7 covers IANA considerations in assignment of TKEY modes. - - Finally, Section 8 provides the required security considerations - section. - - - - - - - - - -Eastlake Standards Track [Page 3] - -RFC 2930 The DNS TKEY RR September 2000 - - -2. The TKEY Resource Record - - The TKEY resource record (RR) has the structure given below. Its RR - type code is 249. - - Field Type Comment - ----- ---- ------- - - NAME domain see description below - TTYPE u_int16_t TKEY = 249 - CLASS u_int16_t ignored, SHOULD be 255 (ANY) - TTL u_int32_t ignored, SHOULD be zero - RDLEN u_int16_t size of RDATA - RDATA: - Algorithm: domain - Inception: u_int32_t - Expiration: u_int32_t - Mode: u_int16_t - Error: u_int16_t - Key Size: u_int16_t - Key Data: octet-stream - Other Size: u_int16_t - Other Data: octet-stream undefined by this specification - -2.1 The Name Field - - The Name field relates to naming keys. Its meaning differs somewhat - with mode and context as explained in subsequent sections. - - At any DNS server or resolver only one octet string of keying - material may be in place for any particular key name. An attempt to - establish another set of keying material at a server for an existing - name returns a BADNAME error. - - For a TKEY with a non-root name appearing in a query, the TKEY RR - name SHOULD be a domain locally unique at the resolver, less than 128 - octets long in wire encoding, and meaningful to the resolver to - assist in distinguishing keys and/or key agreement sessions. For - TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD - be a globally unique server assigned domain. - - A reasonable key naming strategy is as follows: - - If the key is generated as the result of a query with root as its - owner name, then the server SHOULD create a globally unique domain - name, to be the key name, by suffixing a pseudo-random [RFC 1750] - label with a domain name of the server. For example - 89n3mDgX072pp.server1.example.com. If generation of a new - - - -Eastlake Standards Track [Page 4] - -RFC 2930 The DNS TKEY RR September 2000 - - - pseudo-random name in each case is an excessive computation load - or entropy drain, a serial number prefix can be added to a fixed - pseudo-random name generated an DNS server start time, such as - 1001.89n3mDgX072pp.server1.example.com. - - If the key is generated as the result of a query with a non-root - name, say 789.resolver.example.net, then use the concatenation of - that with a name of the server. For example - 789.resolver.example.net.server1.example.com. - -2.2 The TTL Field - - The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to - be sure that older DNS implementations do not cache TKEY RRs. - -2.3 The Algorithm Field - - The algorithm name is in the form of a domain name with the same - meaning as in [RFC 2845]. The algorithm determines how the secret - keying material agreed to using the TKEY RR is actually used to - derive the algorithm specific key. - -2.4 The Inception and Expiration Fields - - The inception time and expiration times are in number of seconds - since the beginning of 1 January 1970 GMT ignoring leap seconds - treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages - between a DNS resolver and a DNS server where these fields are - meaningful, they are either the requested validity interval for the - keying material asked for or specify the validity interval of keying - material provided. - - To avoid different interpretations of the inception and expiration - times in TKEY RRs, resolvers and servers exchanging them must have - the same idea of what time it is. One way of doing this is with the - NTP protocol [RFC 2030] but that or any other time synchronization - used for this purpose MUST be done securely. - -2.5 The Mode Field - - The mode field specifies the general scheme for key agreement or the - purpose of the TKEY DNS message. Servers and resolvers supporting - this specification MUST implement the Diffie-Hellman key agreement - mode and the key deletion mode for queries. All other modes are - OPTIONAL. A server supporting TKEY that receives a TKEY request with - a mode it does not support returns the BADMODE error. The following - values of the Mode octet are defined, available, or reserved: - - - - -Eastlake Standards Track [Page 5] - -RFC 2930 The DNS TKEY RR September 2000 - - - Value Description - ----- ----------- - 0 - reserved, see section 7 - 1 server assignment - 2 Diffie-Hellman exchange - 3 GSS-API negotiation - 4 resolver assignment - 5 key deletion - 6-65534 - available, see section 7 - 65535 - reserved, see section 7 - -2.6 The Error Field - - The error code field is an extended RCODE. The following values are - defined: - - Value Description - ----- ----------- - 0 - no error - 1-15 a non-extended RCODE - 16 BADSIG (TSIG) - 17 BADKEY (TSIG) - 18 BADTIME (TSIG) - 19 BADMODE - 20 BADNAME - 21 BADALG - - When the TKEY Error Field is non-zero in a response to a TKEY query, - the DNS header RCODE field indicates no error. However, it is - possible if a TKEY is spontaneously included in a response the TKEY - RR and DNS header error field could have unrelated non-zero error - codes. - -2.7 The Key Size and Data Fields - - The key data size field is an unsigned 16 bit integer in network - order which specifies the size of the key exchange data field in - octets. The meaning of this data depends on the mode. - -2.8 The Other Size and Data Fields - - The Other Size and Other Data fields are not used in this - specification but may be used in future extensions. The RDLEN field - MUST equal the length of the RDATA section through the end of Other - Data or the RR is to be considered malformed and rejected. - - - - - - -Eastlake Standards Track [Page 6] - -RFC 2930 The DNS TKEY RR September 2000 - - -3. General TKEY Considerations - - TKEY is a meta-RR that is not stored or cached in the DNS and does - not appear in zone files. It supports a variety of modes for the - establishment and deletion of shared secret keys information between - DNS resolvers and servers. The establishment of such a shared key - requires that state be maintained at both ends and the allocation of - the resources to maintain such state may require mutual agreement. In - the absence of willingness to provide such state, servers MUST return - errors such as NOTIMP or REFUSED for an attempt to use TKEY and - resolvers are free to ignore any TKEY RRs they receive. - - The shared secret keying material developed by using TKEY is a plain - octet sequence. The means by which this shared secret keying - material, exchanged via TKEY, is actually used in any particular TSIG - algorithm is algorithm dependent and is defined in connection with - that algorithm. For example, see [RFC 2104] for how TKEY agreed - shared secret keying material is used in the HMAC-MD5 algorithm or - other HMAC algorithms. - - There MUST NOT be more than one TKEY RR in a DNS query or response. - - Except for GSS-API mode, TKEY responses MUST always have DNS - transaction authentication to protect the integrity of any keying - data, error codes, etc. This authentication MUST use a previously - established secret (TSIG) or public (SIG(0) [RFC 2931]) key and MUST - NOT use any key that the response to be verified is itself providing. - - TKEY queries MUST be authenticated for all modes except GSS-API and, - under some circumstances, server assignment mode. In particular, if - the query for a server assigned key is for a key to assert some - privilege, such as update authority, then the query must be - authenticated to avoid spoofing. However, if the key is just to be - used for transaction security, then spoofing will lead at worst to - denial of service. Query authentication SHOULD use an established - secret (TSIG) key authenticator if available. Otherwise, it must use - a public (SIG(0)) key signature. It MUST NOT use any key that the - query is itself providing. - - In the absence of required TKEY authentication, a NOTAUTH error MUST - be returned. - - To avoid replay attacks, it is necessary that a TKEY response or - query not be valid if replayed on the order of 2**32 second (about - 136 years), or a multiple thereof, later. To accomplish this, the - keying material used in any TSIG or SIG(0) RR that authenticates a - TKEY message MUST NOT have a lifetime of more then 2**31 - 1 seconds - - - - -Eastlake Standards Track [Page 7] - -RFC 2930 The DNS TKEY RR September 2000 - - - (about 68 years). Thus, on attempted replay, the authenticating TSIG - or SIG(0) RR will not be verifiable due to key expiration and the - replay will fail. - -4. Exchange via Resolver Query - - One method for a resolver and a server to agree about shared secret - keying material for use in TSIG is through DNS requests from the - resolver which are syntactically DNS queries for type TKEY. Such - queries MUST be accompanied by a TKEY RR in the additional - information section to indicate the mode in use and accompanied by - other information where required. - - Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY - ignore the recursive header bit in TKEY queries they receive. - -4.1 Query for Diffie-Hellman Exchanged Keying - - Diffie-Hellman (DH) key exchange is a means whereby two parties can - derive some shared secret information without requiring any secrecy - of the messages they exchange [Schneier]. Provisions have been made - for the storage of DH public keys in the DNS [RFC 2539]. - - A resolver sends a query for type TKEY accompanied by a TKEY RR in - the additional information section specifying the Diffie-Hellman mode - and accompanied by a KEY RR also in the additional information - section specifying a resolver Diffie-Hellman key. The TKEY RR - algorithm field is set to the authentication algorithm the resolver - plans to use. The "key data" provided in the TKEY is used as a random - [RFC 1750] nonce to avoid always deriving the same keying material - for the same pair of DH KEYs. - - The server response contains a TKEY in its answer section with the - Diffie-Hellman mode. The "key data" provided in this TKEY is used as - an additional nonce to avoid always deriving the same keying material - for the same pair of DH KEYs. If the TKEY error field is non-zero, - the query failed for the reason given. FORMERR is given if the query - included no DH KEY and BADKEY is given if the query included an - incompatible DH KEY. - - If the TKEY error field is zero, the resolver supplied Diffie-Hellman - KEY RR SHOULD be echoed in the additional information section and a - server Diffie-Hellman KEY RR will also be present in the answer - section of the response. Both parties can then calculate the same - shared secret quantity from the pair of Diffie-Hellman (DH) keys used - [Schneier] (provided these DH keys use the same generator and - modulus) and the data in the TKEY RRs. The TKEY RR data is mixed - with the DH result as follows: - - - -Eastlake Standards Track [Page 8] - -RFC 2930 The DNS TKEY RR September 2000 - - - keying material = - XOR ( DH value, MD5 ( query data | DH value ) | - MD5 ( server data | DH value ) ) - - Where XOR is an exclusive-OR operation and "|" is byte-stream - concatenation. The shorter of the two operands to XOR is byte-wise - left justified and padded with zero-valued bytes to match the length - of the other operand. "DH value" is the Diffie-Hellman value derived - from the KEY RRs. Query data and server data are the values sent in - the TKEY RR data fields. These "query data" and "server data" nonces - are suffixed by the DH value, digested by MD5, the results - concatenated, and then XORed with the DH value. - - The inception and expiry times in the query TKEY RR are those - requested for the keying material. The inception and expiry times in - the response TKEY RR are the maximum period the server will consider - the keying material valid. Servers may pre-expire keys so this is - not a guarantee. - -4.2 Query for TKEY Deletion - - Keys established via TKEY can be treated as soft state. Since DNS - transactions are originated by the resolver, the resolver can simply - toss keys, although it may have to go through another key exchange if - it later needs one. Similarly, the server can discard keys although - that will result in an error on receiving a query with a TSIG using - the discarded key. - - To avoid attempted reliance in requests on keys no longer in effect, - servers MUST implement key deletion whereby the server "discards" a - key on receipt from a resolver of an authenticated delete request for - a TKEY RR with the key's name. If the server has no record of a key - with that name, it returns BADNAME. - - Key deletion TKEY queries MUST be authenticated. This authentication - MAY be a TSIG RR using the key to be deleted. - - For querier assigned and Diffie-Hellman keys, the server MUST truly - "discard" all active state associated with the key. For server - assigned keys, the server MAY simply mark the key as no longer - retained by the client and may re-send it in response to a future - query for server assigned keying material. - - - - - - - - - -Eastlake Standards Track [Page 9] - -RFC 2930 The DNS TKEY RR September 2000 - - -4.3 Query for GSS-API Establishment - - This mode is described in a separate document under preparation which - should be seen for the full description. Basically the resolver and - server can exchange queries and responses for type TKEY with a TKEY - RR specifying the GSS-API mode in the additional information section - and a GSS-API token in the key data portion of the TKEY RR. - - Any issues of possible encryption of parts the GSS-API token data - being transmitted are handled by the GSS-API level. In addition, the - GSS-API level provides its own authentication so that this mode of - TKEY query and response MAY be, but do not need to be, authenticated - with TSIG RR or SIG(0) RR [RFC 2931]. - - The inception and expiry times in a GSS-API mode TKEY RR are ignored. - -4.4 Query for Server Assigned Keying - - Optionally, the server can assign keying for the resolver. It is - sent to the resolver encrypted under a resolver public key. See - section 6 for description of encryption methods. - - A resolver sends a query for type TKEY accompanied by a TKEY RR - specifying the "server assignment" mode and a resolver KEY RR to be - used in encrypting the response, both in the additional information - section. The TKEY algorithm field is set to the authentication - algorithm the resolver plans to use. It is RECOMMENDED that any "key - data" provided in the query TKEY RR by the resolver be strongly mixed - by the server with server generated randomness [RFC 1750] to derive - the keying material to be used. The KEY RR that appears in the query - need not be accompanied by a SIG(KEY) RR. If the query is - authenticated by the resolver with a TSIG RR [RFC 2845] or SIG(0) RR - and that authentication is verified, then any SIG(KEY) provided in - the query SHOULD be ignored. The KEY RR in such a query SHOULD have - a name that corresponds to the resolver but it is only essential that - it be a public key for which the resolver has the corresponding - private key so it can decrypt the response data. - - The server response contains a TKEY RR in its answer section with the - server assigned mode and echoes the KEY RR provided in the query in - its additional information section. - - If the response TKEY error field is zero, the key data portion of the - response TKEY RR will be the server assigned keying data encrypted - under the public key in the resolver provided KEY RR. In this case, - the owner name of the answer TKEY RR will be the server assigned name - of the key. - - - - -Eastlake Standards Track [Page 10] - -RFC 2930 The DNS TKEY RR September 2000 - - - If the error field of the response TKEY is non-zero, the query failed - for the reason given. FORMERR is given if the query specified no - encryption key. - - The inception and expiry times in the query TKEY RR are those - requested for the keying material. The inception and expiry times in - the response TKEY are the maximum period the server will consider the - keying material valid. Servers may pre-expire keys so this is not a - guarantee. - - The resolver KEY RR MUST be authenticated, through the authentication - of this query with a TSIG or SIG(0) or the signing of the resolver - KEY with a SIG(KEY). Otherwise, an attacker can forge a resolver KEY - for which they know the private key, and thereby the attacker could - obtain a valid shared secret key from the server. - -4.5 Query for Resolver Assigned Keying - - Optionally, a server can accept resolver assigned keys. The keying - material MUST be encrypted under a server key for protection in - transmission as described in Section 6. - - The resolver sends a TKEY query with a TKEY RR that specifies the - encrypted keying material and a KEY RR specifying the server public - key used to encrypt the data, both in the additional information - section. The name of the key and the keying data are completely - controlled by the sending resolver so a globally unique key name - SHOULD be used. The KEY RR used MUST be one for which the server has - the corresponding private key, or it will not be able to decrypt the - keying material and will return a FORMERR. It is also important that - no untrusted party (preferably no other party than the server) has - the private key corresponding to the KEY RR because, if they do, they - can capture the messages to the server, learn the shared secret, and - spoof valid TSIGs. - - The query TKEY RR inception and expiry give the time period the - querier intends to consider the keying material valid. The server - can return a lesser time interval to advise that it will not maintain - state for that long and can pre-expire keys in any case. - - This mode of query MUST be authenticated with a TSIG or SIG(0). - Otherwise, an attacker can forge a resolver assigned TKEY query, and - thereby the attacker could specify a shared secret key that would be - accepted, used, and honored by the server. - - - - - - - -Eastlake Standards Track [Page 11] - -RFC 2930 The DNS TKEY RR September 2000 - - -5. Spontaneous Server Inclusion - - A DNS server may include a TKEY RR spontaneously as additional - information in responses. This SHOULD only be done if the server - knows the querier understands TKEY and has this option implemented. - This technique can be used to delete a key and may be specified for - modes defined in the future. A disadvantage of this technique is - that there is no way for the server to get any error or success - indication back and, in the case of UDP, no way to even know if the - DNS response reached the resolver. - -5.1 Spontaneous Server Key Deletion - - A server can optionally tell a client that it has deleted a secret - key by spontaneously including a TKEY RR in the additional - information section of a response with the key's name and specifying - the key deletion mode. Such a response SHOULD be authenticated. If - authenticated, it "deletes" the key with the given name. The - inception and expiry times of the delete TKEY RR are ignored. Failure - by a client to receive or properly process such additional - information in a response would mean that the client might use a key - that the server had discarded and would then get an error indication. - - For server assigned and Diffie-Hellman keys, the client MUST - "discard" active state associated with the key. For querier assigned - keys, the querier MAY simply mark the key as no longer retained by - the server and may re-send it in a future query specifying querier - assigned keying material. - -6. Methods of Encryption - - For the server assigned and resolver assigned key agreement modes, - the keying material is sent within the key data field of a TKEY RR - encrypted under the public key in an accompanying KEY RR [RFC 2535]. - This KEY RR MUST be for a public key algorithm where the public and - private keys can be used for encryption and the corresponding - decryption which recovers the originally encrypted data. The KEY RR - SHOULD correspond to a name for the decrypting resolver/server such - that the decrypting process has access to the corresponding private - key to decrypt the data. The secret keying material being sent will - generally be fairly short, usually less than 256 bits, because that - is adequate for very strong protection with modern keyed hash or - symmetric algorithms. - - If the KEY RR specifies the RSA algorithm, then the keying material - is encrypted as per the description of RSAES-PKCS1-v1_5 encryption in - PKCS#1 [RFC 2437]. (Note, the secret keying material being sent is - directly RSA encrypted in PKCS#1 format. It is not "enveloped" under - - - -Eastlake Standards Track [Page 12] - -RFC 2930 The DNS TKEY RR September 2000 - - - some other symmetric algorithm.) In the unlikely event that the - keying material will not fit within one RSA modulus of the chosen - public key, additional RSA encryption blocks are included. The - length of each block is clear from the public RSA key specified and - the RSAES-PKCS1-v1_5 padding makes it clear what part of the - encrypted data is actually keying material and what part is - formatting or the required at least eight bytes of random [RFC 1750] - padding. - -7. IANA Considerations - - This section is to be interpreted as provided in [RFC 2434]. - - Mode field values 0x0000 and 0xFFFF are reserved. - - Mode field values 0x0001 through 0x00FF, and 0XFF00 through 0XFFFE - can only be assigned by an IETF Standards Action. - - Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF - are allocated by IESG approval or IETF consensus. - - Mode field values 0x1000 through 0xEFFF are allocated based on - Specification Required as defined in [RFC 2434]. - - Mode values should not be changed when the status of their use - changes. For example, a mode value assigned based just on providing - a specification should not be changed later just because that use's - status is changed to standards track. - - The following assignments are documented herein: - - RR Type 249 for TKEY. - - TKEY Modes 1 through 5 as listed in section 2.5. - - Extended RCODE Error values of 19, 20, and 21 as listed in section - 2.6. - -8. Security Considerations - - The entirety of this specification is concerned with the secure - establishment of a shared secret between DNS clients and servers in - support of TSIG [RFC 2845]. - - Protection against denial of service via the use of TKEY is not - provided. - - - - - -Eastlake Standards Track [Page 13] - -RFC 2930 The DNS TKEY RR September 2000 - - -References - - [Schneier] Bruce Schneier, "Applied Cryptography: Protocols, - Algorithms, and Source Code in C", 1996, John Wiley and - Sons - - [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", - STD 13, RFC 1034, November 1987. - - [RFC 1035] Mockapetris, P., "Domain Names - Implementation and - Specifications", STD 13, RFC 1035, November 1987. - - [RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness - Recommendations for Security", RFC 1750, December 1994. - - [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, - September 1996. - - [RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, - August 1996. - - [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 - for IPv4, IPv6 and OSI", RFC 2030, October 1996. - - [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, February - 1997. - - [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - - [RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography - Specifications Version 2.0", RFC 2437, October 1998. - - [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the - Domain Name System (DNS)", RFC 2539, March 1999. - - - - -Eastlake Standards Track [Page 14] - -RFC 2930 The DNS TKEY RR September 2000 - - - [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC 2931] Eastlake, D., "DNS Request and Transaction Signatures - (SIG(0)s )", RFC 2931, September 2000. - -Author's Address - - Donald E. Eastlake 3rd - Motorola - 140 Forest Avenue - Hudson, MA 01749 USA - - Phone: +1 978-562-2827 (h) - +1 508-261-5434 (w) - Fax: +1 508-261-4447 (w) - EMail: Donald.Eastlake@motorola.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake Standards Track [Page 15] - -RFC 2930 The DNS TKEY RR September 2000 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Eastlake Standards Track [Page 16] - diff --git a/contrib/bind9/doc/rfc/rfc2931.txt b/contrib/bind9/doc/rfc/rfc2931.txt deleted file mode 100644 index 84cc97e2d26e..000000000000 --- a/contrib/bind9/doc/rfc/rfc2931.txt +++ /dev/null @@ -1,563 +0,0 @@ - - - - - - -Network Working Group D. Eastlake 3rd -Request for Comments: 2931 Motorola -Updates: 2535 September 2000 -Category: Standards Track - - - DNS Request and Transaction Signatures ( SIG(0)s ) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - Extensions to the Domain Name System (DNS) are described in [RFC - 2535] that can provide data origin and transaction integrity and - authentication to security aware resolvers and applications through - the use of cryptographic digital signatures. - - Implementation experience has indicated the need for minor but non- - interoperable changes in Request and Transaction signature resource - records ( SIG(0)s ). These changes are documented herein. - -Acknowledgments - - The contributions and suggestions of the following persons (in - alphabetic order) to this memo are gratefully acknowledged: - - Olafur Gudmundsson - - Ed Lewis - - Erik Nordmark - - Brian Wellington - - - - - - - - -Eastlake Standards Track [Page 1] - -RFC 2931 DNS SIG(0) September 2000 - - -Table of Contents - - 1. Introduction................................................. 2 - 2. SIG(0) Design Rationale...................................... 3 - 2.1 Transaction Authentication.................................. 3 - 2.2 Request Authentication...................................... 3 - 2.3 Keying...................................................... 3 - 2.4 Differences Between TSIG and SIG(0)......................... 4 - 3. The SIG(0) Resource Record................................... 4 - 3.1 Calculating Request and Transaction SIGs.................... 5 - 3.2 Processing Responses and SIG(0) RRs......................... 6 - 3.3 SIG(0) Lifetime and Expiration.............................. 7 - 4. Security Considerations...................................... 7 - 5. IANA Considerations.......................................... 7 - References...................................................... 7 - Author's Address................................................ 8 - Appendix: SIG(0) Changes from RFC 2535.......................... 9 - Full Copyright Statement........................................ 10 - -1. Introduction - - This document makes minor but non-interoperable changes to part of - [RFC 2535], familiarity with which is assumed, and includes - additional explanatory text. These changes concern SIG Resource - Records (RRs) that are used to digitally sign DNS requests and - transactions / responses. Such a resource record, because it has a - type covered field of zero, is frequently called a SIG(0). The - changes are based on implementation and attempted implementation - experience with TSIG [RFC 2845] and the [RFC 2535] specification for - SIG(0). - - Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2 - and 4.3. No changes are made herein related to the KEY or NXT RRs or - to the processing involved with data origin and denial authentication - for DNS data. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC 2119]. - - - - - - - - - - - - -Eastlake Standards Track [Page 2] - -RFC 2931 DNS SIG(0) September 2000 - - -2. SIG(0) Design Rationale - - SIG(0) provides protection for DNS transactions and requests that is - not provided by the regular SIG, KEY, and NXT RRs specified in [RFC - 2535]. The authenticated data origin services of secure DNS either - provide protected data resource records (RRs) or authenticatably deny - their nonexistence. These services provide no protection for glue - records, DNS requests, no protection for message headers on requests - or responses, and no protection of the overall integrity of a - response. - -2.1 Transaction Authentication - - Transaction authentication means that a requester can be sure it is - at least getting the messages from the server it queried and that the - received messages are in response to the query it sent. This is - accomplished by optionally adding either a TSIG RR [RFC 2845] or, as - described herein, a SIG(0) resource record at the end of the response - which digitally signs the concatenation of the server's response and - the corresponding resolver query. - -2.2 Request Authentication - - Requests can also be authenticated by including a TSIG or, as - described herein, a special SIG(0) RR at the end of the request. - Authenticating requests serves no function in DNS servers that - predate the specification of dynamic update. Requests with a non- - empty additional information section produce error returns or may - even be ignored by a few such older DNS servers. However, this syntax - for signing requests is defined for authenticating dynamic update - requests [RFC 2136], TKEY requests [RFC 2930], or future requests - requiring authentication. - -2.3 Keying - - The private keys used in transaction security belong to the host - composing the DNS response message, not to the zone involved. - Request authentication may also involve the private key of the host - or other entity composing the request or of a zone to be affected by - the request or other private keys depending on the request authority - it is sought to establish. The corresponding public key(s) are - normally stored in and retrieved from the DNS for verification as KEY - RRs with a protocol byte of 3 (DNSSEC) or 255 (ANY). - - Because requests and replies are highly variable, message - authentication SIGs can not be pre-calculated. Thus it will be - necessary to keep the private key on-line, for example in software or - in a directly connected piece of hardware. - - - -Eastlake Standards Track [Page 3] - -RFC 2931 DNS SIG(0) September 2000 - - -2.4 Differences Between TSIG and SIG(0) - - There are significant differences between TSIG and SIG(0). - - Because TSIG involves secret keys installed at both the requester and - server the presence of such a key implies that the other party - understands TSIG and very likely has the same key installed. - Furthermore, TSIG uses keyed hash authentication codes which are - relatively inexpensive to compute. Thus it is common to authenticate - requests with TSIG and responses are authenticated with TSIG if the - corresponding request is authenticated. - - SIG(0) on the other hand, uses public key authentication, where the - public keys are stored in DNS as KEY RRs and a private key is stored - at the signer. Existence of such a KEY RR does not necessarily imply - implementation of SIG(0). In addition, SIG(0) involves relatively - expensive public key cryptographic operations that should be - minimized and the verification of a SIG(0) involves obtaining and - verifying the corresponding KEY which can be an expensive and lengthy - operation. Indeed, a policy of using SIG(0) on all requests and - verifying it before responding would, for some configurations, lead - to a deadly embrace with the attempt to obtain and verify the KEY - needed to authenticate the request SIG(0) resulting in additional - requests accompanied by a SIG(0) leading to further requests - accompanied by a SIG(0), etc. Furthermore, omitting SIG(0)s when not - required on requests halves the number of public key operations - required by the transaction. - - For these reasons, SIG(0)s SHOULD only be used on requests when - necessary to authenticate that the requester has some required - privilege or identity. SIG(0)s on replies are defined in such a way - as to not require a SIG(0) on the corresponding request and still - provide transaction protection. For other replies, whether they are - authenticated by the server or required to be authenticated by the - requester SHOULD be a local configuration option. - -3. The SIG(0) Resource Record - - The structure of and type number of SIG resource records (RRs) is - given in [RFC 2535] Section 4.1. However all of Section 4.1.8.1 and - the parts of Sections 4.2 and 4.3 related to SIG(0) should be - considered replaced by the material below. Any conflict between [RFC - 2535] and this document concerning SIG(0) RRs should be resolved in - favor of this document. - - For all transaction SIG(0)s, the signer field MUST be a name of the - originating host and there MUST be a KEY RR at that name with the - public key corresponding to the private key used to calculate the - - - -Eastlake Standards Track [Page 4] - -RFC 2931 DNS SIG(0) September 2000 - - - signature. (The host domain name used may be the inverse IP address - mapping name for an IP address of the host if the relevant KEY is - stored there.) - - For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are - meaningless. The TTL fields SHOULD be zero and the CLASS field - SHOULD be ANY. To conserve space, the owner name SHOULD be root (a - single zero octet). When SIG(0) authentication on a response is - desired, that SIG RR MUST be considered the highest priority of any - additional information for inclusion in the response. If the SIG(0) - RR cannot be added without causing the message to be truncated, the - server MUST alter the response so that a SIG(0) can be included. - This response consists of only the question and a SIG(0) record, and - has the TC bit set and RCODE 0 (NOERROR). The client should at this - point retry the request using TCP. - -3.1 Calculating Request and Transaction SIGs - - A DNS request may be optionally signed by including one SIG(0)s at - the end of the query additional information section. Such a SIG is - identified by having a "type covered" field of zero. It signs the - preceding DNS request message including DNS header but not including - the UDP/IP header and before the request RR counts have been adjusted - for the inclusions of the request SIG(0). - - It is calculated by using a "data" (see [RFC 2535], Section 4.1.8) of - (1) the SIG's RDATA section entirely omitting (not just zeroing) the - signature subfield itself, (2) the DNS query messages, including DNS - header, but not the UDP/IP header and before the reply RR counts have - been adjusted for the inclusion of the SIG(0). That is - - data = RDATA | request - SIG(0) - - where "|" is concatenation and RDATA is the RDATA of the SIG(0) being - calculated less the signature itself. - - Similarly, a SIG(0) can be used to secure a response and the request - that produced it. Such transaction signatures are calculated by - using a "data" of (1) the SIG's RDATA section omitting the signature - itself, (2) the entire DNS query message that produced this response, - including the query's DNS header but not its UDP/IP header, and (3) - the entire DNS response message, including DNS header but not the - UDP/IP header and before the response RR counts have been adjusted - for the inclusion of the SIG(0). - - - - - - - -Eastlake Standards Track [Page 5] - -RFC 2931 DNS SIG(0) September 2000 - - - That is - - data = RDATA | full query | response - SIG(0) - - where "|" is concatenation and RDATA is the RDATA of the SIG(0) being - calculated less the signature itself. - - Verification of a response SIG(0) (which is signed by the server host - key, not the zone key) by the requesting resolver shows that the - query and response were not tampered with in transit, that the - response corresponds to the intended query, and that the response - comes from the queried server. - - In the case of a DNS message via TCP, a SIG(0) on the first data - packet is calculated with "data" as above and for each subsequent - packet, it is calculated as follows: - - data = RDATA | DNS payload - SIG(0) | previous packet - - where "|" is concatenations, RDATA is as above, and previous packet - is the previous DNS payload including DNS header and the SIG(0) but - not the TCP/IP header. Support of SIG(0) for TCP is OPTIONAL. As an - alternative, TSIG may be used after, if necessary, setting up a key - with TKEY [RFC 2930]. - - Except where needed to authenticate an update, TKEY, or similar - privileged request, servers are not required to check a request - SIG(0). - - Note: requests and responses can either have a single TSIG or one - SIG(0) but not both a TSIG and a SIG(0). - -3.2 Processing Responses and SIG(0) RRs - - If a SIG RR is at the end of the additional information section of a - response and has a type covered of zero, it is a transaction - signature covering the response and the query that produced the - response. For TKEY responses, it MUST be checked and the message - rejected if the checks fail unless otherwise specified for the TKEY - mode in use. For all other responses, it MAY be checked and the - message rejected if the checks fail. - - If a response's SIG(0) check succeed, such a transaction - authentication SIG does NOT directly authenticate the validity any - data-RRs in the message. However, it authenticates that they were - sent by the queried server and have not been diddled. (Only a proper - SIG(0) RR signed by the zone or a key tracing its authority to the - zone or to static resolver configuration can directly authenticate - - - -Eastlake Standards Track [Page 6] - -RFC 2931 DNS SIG(0) September 2000 - - - data-RRs, depending on resolver policy.) If a resolver or server does - not implement transaction and/or request SIGs, it MUST ignore them - without error where they are optional and treat them as failing where - they are required. - -3.3 SIG(0) Lifetime and Expiration - - The inception and expiration times in SIG(0)s are for the purpose of - resisting replay attacks. They should be set to form a time bracket - such that messages outside that bracket can be ignored. In IP - networks, this time bracket should not normally extend further than 5 - minutes into the past and 5 minutes into the future. - -4. Security Considerations - - No additional considerations beyond those in [RFC 2535]. - - The inclusion of the SIG(0) inception and expiration time under the - signature improves resistance to replay attacks. - -5. IANA Considerations - - No new parameters are created or parameter values assigned by this - document. - -References - - [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, - September 1996. - - [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. - Wellington, "Secret Key Transaction Signatures for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (RR)", RFC - 2930, September 2000. - - - - - -Eastlake Standards Track [Page 7] - -RFC 2931 DNS SIG(0) September 2000 - - -Author's Address - - Donald E. Eastlake 3rd - Motorola - 140 Forest Avenue - Hudson, MA 01749 USA - - Phone: +1-978-562-2827(h) - +1-508-261-5434(w) - Fax: +1 978-567-7941(h) - +1-508-261-4447(w) - EMail: Donald.Eastlake@motorola.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake Standards Track [Page 8] - -RFC 2931 DNS SIG(0) September 2000 - - -Appendix: SIG(0) Changes from RFC 2535 - - Add explanatory text concerning the differences between TSIG and - SIG(0). - - Change the data over which SIG(0) is calculated to include the SIG(0) - RDATA other than the signature itself so as to secure the signature - inception and expiration times and resist replay attacks. Specify - SIG(0) for TCP. - - Add discussion of appropriate inception and expiration times for - SIG(0). - - Add wording to indicate that either a TSIG or one or more SIG(0)s may - be present but not both. - - Reword some areas for clarity. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake Standards Track [Page 9] - -RFC 2931 DNS SIG(0) September 2000 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Eastlake Standards Track [Page 10] - diff --git a/contrib/bind9/doc/rfc/rfc3007.txt b/contrib/bind9/doc/rfc/rfc3007.txt deleted file mode 100644 index 1697475355d3..000000000000 --- a/contrib/bind9/doc/rfc/rfc3007.txt +++ /dev/null @@ -1,507 +0,0 @@ - - - - - - -Network Working Group B. Wellington -Request for Comments: 3007 Nominum -Updates: 2535, 2136 November 2000 -Obsoletes: 2137 -Category: Standards Track - - - Secure Domain Name System (DNS) Dynamic Update - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - This document proposes a method for performing secure Domain Name - System (DNS) dynamic updates. The method described here is intended - to be flexible and useful while requiring as few changes to the - protocol as possible. The authentication of the dynamic update - message is separate from later DNSSEC validation of the data. Secure - communication based on authenticated requests and transactions is - used to provide authorization. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - -1 - Introduction - - This document defines a means to secure dynamic updates of the Domain - Name System (DNS), allowing only authorized sources to make changes - to a zone's contents. The existing unsecured dynamic update - operations form the basis for this work. - - Familiarity with the DNS system [RFC1034, RFC1035] and dynamic update - [RFC2136] is helpful and is assumed by this document. In addition, - knowledge of DNS security extensions [RFC2535], SIG(0) transaction - security [RFC2535, RFC2931], and TSIG transaction security [RFC2845] - is recommended. - - - - -Wellington Standards Track [Page 1] - -RFC 3007 Secure Dynamic Update November 2000 - - - This document updates portions of RFC 2535, in particular section - 3.1.2, and RFC 2136. This document obsoletes RFC 2137, an alternate - proposal for secure dynamic update, due to implementation experience. - -1.1 - Overview of DNS Dynamic Update - - DNS dynamic update defines a new DNS opcode and a new interpretation - of the DNS message if that opcode is used. An update can specify - insertions or deletions of data, along with prerequisites necessary - for the updates to occur. All tests and changes for a DNS update - request are restricted to a single zone, and are performed at the - primary server for the zone. The primary server for a dynamic zone - must increment the zone SOA serial number when an update occurs or - before the next retrieval of the SOA. - -1.2 - Overview of DNS Transaction Security - - Exchanges of DNS messages which include TSIG [RFC2845] or SIG(0) - [RFC2535, RFC2931] records allow two DNS entities to authenticate DNS - requests and responses sent between them. A TSIG MAC (message - authentication code) is derived from a shared secret, and a SIG(0) is - generated from a private key whose public counterpart is stored in - DNS. In both cases, a record containing the message signature/MAC is - included as the final resource record in a DNS message. Keyed - hashes, used in TSIG, are inexpensive to calculate and verify. - Public key encryption, as used in SIG(0), is more scalable as the - public keys are stored in DNS. - -1.3 - Comparison of data authentication and message authentication - - Message based authentication, using TSIG or SIG(0), provides - protection for the entire message with a single signing and single - verification which, in the case of TSIG, is a relatively inexpensive - MAC creation and check. For update requests, this signature can - establish, based on policy or key negotiation, the authority to make - the request. - - DNSSEC SIG records can be used to protect the integrity of individual - RRs or RRsets in a DNS message with the authority of the zone owner. - However, this cannot sufficiently protect the dynamic update request. - - Using SIG records to secure RRsets in an update request is - incompatible with the design of update, as described below, and would - in any case require multiple expensive public key signatures and - verifications. - - - - - - -Wellington Standards Track [Page 2] - -RFC 3007 Secure Dynamic Update November 2000 - - - SIG records do not cover the message header, which includes record - counts. Therefore, it is possible to maliciously insert or remove - RRsets in an update request without causing a verification failure. - - If SIG records were used to protect the prerequisite section, it - would be impossible to determine whether the SIGs themselves were a - prerequisite or simply used for validation. - - In the update section of an update request, signing requests to add - an RRset is straightforward, and this signature could be permanently - used to protect the data, as specified in [RFC2535]. However, if an - RRset is deleted, there is no data for a SIG to cover. - -1.4 - Data and message signatures - - As specified in [RFC3008], the DNSSEC validation process performed by - a resolver MUST NOT process any non-zone keys unless local policy - dictates otherwise. When performing secure dynamic update, all zone - data modified in a signed zone MUST be signed by a relevant zone key. - This completely disassociates authentication of an update request - from authentication of the data itself. - - The primary usefulness of host and user keys, with respect to DNSSEC, - is to authenticate messages, including dynamic updates. Thus, host - and user keys MAY be used to generate SIG(0) records to authenticate - updates and MAY be used in the TKEY [RFC2930] process to generate - TSIG shared secrets. In both cases, no SIG records generated by - non-zone keys will be used in a DNSSEC validation process unless - local policy dictates. - - Authentication of data, once it is present in DNS, only involves - DNSSEC zone keys and signatures generated by them. - -1.5 - Signatory strength - - [RFC2535, section 3.1.2] defines the signatory field of a key as the - final 4 bits of the flags field, but does not define its value. This - proposal leaves this field undefined. Updating [RFC2535], this field - SHOULD be set to 0 in KEY records, and MUST be ignored. - -2 - Authentication - - TSIG or SIG(0) records MUST be included in all secure dynamic update - messages. This allows the server to verifiably determine the - originator of a message. If the message contains authentication in - the form of a SIG(0), the identity of the sender (that is, the - principal) is the owner of the KEY RR that generated the SIG(0). If - the message contains a TSIG generated by a statically configured - - - -Wellington Standards Track [Page 3] - -RFC 3007 Secure Dynamic Update November 2000 - - - shared secret, the principal is the same as or derived from the - shared secret name. If the message contains a TSIG generated by a - dynamically configured shared secret, the principal is the same as - the one that authenticated the TKEY process; if the TKEY process was - unauthenticated, no information is known about the principal, and the - associated TSIG shared secret MUST NOT be used for secure dynamic - update. - - SIG(0) signatures SHOULD NOT be generated by zone keys, since - transactions are initiated by a host or user, not a zone. - - DNSSEC SIG records (other than SIG(0)) MAY be included in an update - message, but MUST NOT be used to authenticate the update request. - - If an update fails because it is signed with an unauthorized key, the - server MUST indicate failure by returning a message with RCODE - REFUSED. Other TSIG, SIG(0), or dynamic update errors are returned - as specified in the appropriate protocol description. - -3 - Policy - - All policy is configured by the zone administrator and enforced by - the zone's primary name server. Policy dictates the authorized - actions that an authenticated principal can take. Policy checks are - based on the principal and the desired action, where the principal is - derived from the message signing key and applied to dynamic update - messages signed with that key. - - The server's policy defines criteria which determine if the key used - to sign the update is permitted to perform the requested updates. By - default, a principal MUST NOT be permitted to make any changes to - zone data; any permissions MUST be enabled though configuration. - - The policy is fully implemented in the primary zone server's - configuration for several reasons. This removes limitations imposed - by encoding policy into a fixed number of bits (such as the KEY RR's - signatory field). Policy is only relevant in the server applying it, - so there is no reason to expose it. Finally, a change in policy or a - new type of policy should not affect the DNS protocol or data format, - and should not cause interoperability failures. - -3.1 - Standard policies - - Implementations SHOULD allow access control policies to use the - principal as an authorization token, and MAY also allow policies to - grant permission to a signed message regardless of principal. - - - - - -Wellington Standards Track [Page 4] - -RFC 3007 Secure Dynamic Update November 2000 - - - A common practice would be to restrict the permissions of a principal - by domain name. That is, a principal could be permitted to add, - delete, or modify entries corresponding to one or more domain names. - Implementations SHOULD allow per-name access control, and SHOULD - provide a concise representation of the principal's own name, its - subdomains, and all names in the zone. - - Additionally, a server SHOULD allow restricting updates by RR type, - so that a principal could add, delete, or modify specific record - types at certain names. Implementations SHOULD allow per-type access - control, and SHOULD provide concise representations of all types and - all "user" types, where a user type is defined as one that does not - affect the operation of DNS itself. - -3.1.1 - User types - - User types include all data types except SOA, NS, SIG, and NXT. SOA - and NS records SHOULD NOT be modified by normal users, since these - types create or modify delegation points. The addition of SIG - records can lead to attacks resulting in additional workload for - resolvers, and the deletion of SIG records could lead to extra work - for the server if the zone SIG was deleted. Note that these records - are not forbidden, but not recommended for normal users. - - NXT records MUST NOT be created, modified, or deleted by dynamic - update, as their update may cause instability in the protocol. This - is an update to RFC 2136. - - Issues concerning updates of KEY records are discussed in the - Security Considerations section. - -3.2 - Additional policies - - Users are free to implement any policies. Policies may be as - specific or general as desired, and as complex as desired. They may - depend on the principal or any other characteristics of the signed - message. - -4 - Interaction with DNSSEC - - Although this protocol does not change the way updates to secure - zones are processed, there are a number of issues that should be - clarified. - - - - - - - - -Wellington Standards Track [Page 5] - -RFC 3007 Secure Dynamic Update November 2000 - - -4.1 - Adding SIGs - - An authorized update request MAY include SIG records with each RRset. - Since SIG records (except SIG(0) records) MUST NOT be used for - authentication of the update message, they are not required. - - If a principal is authorized to update SIG records and there are SIG - records in the update, the SIG records are added without - verification. The server MAY examine SIG records and drop SIGs with - a temporal validity period in the past. - -4.2 - Deleting SIGs - - If a principal is authorized to update SIG records and the update - specifies the deletion of SIG records, the server MAY choose to - override the authority and refuse the update. For example, the - server may allow all SIG records not generated by a zone key to be - deleted. - -4.3 - Non-explicit updates to SIGs - - If the updated zone is secured, the RRset affected by an update - operation MUST, at the completion of the update, be signed in - accordance with the zone's signing policy. This will usually require - one or more SIG records to be generated by one or more zone keys - whose private components MUST be online [RFC3008]. - - When the contents of an RRset are updated, the server MAY delete all - associated SIG records, since they will no longer be valid. - -4.4 - Effects on the zone - - If any changes are made, the server MUST, if necessary, generate a - new SOA record and new NXT records, and sign these with the - appropriate zone keys. Changes to NXT records by secure dynamic - update are explicitly forbidden. SOA updates are allowed, since the - maintenance of SOA parameters is outside of the scope of the DNS - protocol. - -5 - Security Considerations - - This document requires that a zone key and possibly other - cryptographic secret material be held in an on-line, network- - connected host, most likely a name server. This material is at the - mercy of host security to remain a secret. Exposing this secret puts - DNS data at risk of masquerade attacks. The data at risk is that in - both zones served by the machine and delegated from this machine. - - - - -Wellington Standards Track [Page 6] - -RFC 3007 Secure Dynamic Update November 2000 - - - Allowing updates of KEY records may lead to undesirable results, - since a principal may be allowed to insert a public key without - holding the private key, and possibly masquerade as the key owner. - -6 - Acknowledgements - - The author would like to thank the following people for review and - informative comments (in alphabetical order): - - Harald Alvestrand - Donald Eastlake - Olafur Gudmundsson - Andreas Gustafsson - Bob Halley - Stuart Kwan - Ed Lewis - -7 - References - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - [RFC2136] Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound, - "Dynamic Updates in the Domain Name System", RFC 2136, - April 1997. - - [RFC2137] Eastlake, D., "Secure Domain Name System Dynamic Update", - RFC 2137, April 1997. - - [RFC2535] Eastlake, G., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. - Wellington, "Secret Key Transaction Signatures for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures - (SIG(0)s)", RFC 2931, September 2000. - - [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) - Signing Authority", RFC 3008, November 2000. - - - - -Wellington Standards Track [Page 7] - -RFC 3007 Secure Dynamic Update November 2000 - - -8 - Author's Address - - Brian Wellington - Nominum, Inc. - 950 Charter Street - Redwood City, CA 94063 - - Phone: +1 650 381 6022 - EMail: Brian.Wellington@nominum.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Wellington Standards Track [Page 8] - -RFC 3007 Secure Dynamic Update November 2000 - - -9. Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Wellington Standards Track [Page 9] - diff --git a/contrib/bind9/doc/rfc/rfc3008.txt b/contrib/bind9/doc/rfc/rfc3008.txt deleted file mode 100644 index 08a4a8fabedb..000000000000 --- a/contrib/bind9/doc/rfc/rfc3008.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -Network Working Group B. Wellington -Request for Comments: 3008 Nominum -Updates: 2535 November 2000 -Category: Standards Track - - - Domain Name System Security (DNSSEC) Signing Authority - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - This document proposes a revised model of Domain Name System Security - (DNSSEC) Signing Authority. The revised model is designed to clarify - earlier documents and add additional restrictions to simplify the - secure resolution process. Specifically, this affects the - authorization of keys to sign sets of records. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - -1 - Introduction - - This document defines additional restrictions on DNSSEC signatures - (SIG) records relating to their authority to sign associated data. - The intent is to establish a standard policy followed by a secure - resolver; this policy can be augmented by local rules. This builds - upon [RFC2535], updating section 2.3.6 of that document. - - The most significant change is that in a secure zone, zone data is - required to be signed by the zone key. - - Familiarity with the DNS system [RFC1034, RFC1035] and the DNS - security extensions [RFC2535] is assumed. - - - - - - -Wellington Standards Track [Page 1] - -RFC 3008 DNSSEC Signing Authority November 2000 - - -2 - The SIG Record - - A SIG record is normally associated with an RRset, and "covers" (that - is, demonstrates the authenticity and integrity of) the RRset. This - is referred to as a "data SIG". Note that there can be multiple SIG - records covering an RRset, and the same validation process should be - repeated for each of them. Some data SIGs are considered "material", - that is, relevant to a DNSSEC capable resolver, and some are - "immaterial" or "extra-DNSSEC", as they are not relevant to DNSSEC - validation. Immaterial SIGs may have application defined roles. SIG - records may exist which are not bound to any RRset; these are also - considered immaterial. The validation process determines which SIGs - are material; once a SIG is shown to be immaterial, no other - validation is necessary. - - SIGs may also be used for transaction security. In this case, a SIG - record with a type covered field of 0 is attached to a message, and - is used to protect message integrity. This is referred to as a - SIG(0) [RFC2535, RFC2931]. - - The following sections define requirements for all of the fields of a - SIG record. These requirements MUST be met in order for a DNSSEC - capable resolver to process this signature. If any of these - requirements are not met, the SIG cannot be further processed. - Additionally, once a KEY has been identified as having generated this - SIG, there are requirements that it MUST meet. - -2.1 - Type Covered - - For a data SIG, the type covered MUST be the same as the type of data - in the associated RRset. For a SIG(0), the type covered MUST be 0. - -2.2 - Algorithm Number - - The algorithm specified in a SIG MUST be recognized by the client, - and it MUST be an algorithm that has a defined SIG rdata format. - -2.3 - Labels - - The labels count MUST be less than or equal to the number of labels - in the SIG owner name, as specified in [RFC2535, section 4.1.3]. - -2.4 - Original TTL - - The original TTL MUST be greater than or equal to the TTL of the SIG - record itself, since the TTL cannot be increased by intermediate - servers. This field can be ignored for SIG(0) records. - - - - -Wellington Standards Track [Page 2] - -RFC 3008 DNSSEC Signing Authority November 2000 - - -2.5 - Signature Expiration and Inception - - The current time at the time of validation MUST lie within the - validity period bounded by the inception and expiration times. - -2.6 - Key Tag - - There are no restrictions on the Key Tag field, although it is - possible that future algorithms will impose constraints. - -2.7 - Signer's Name - - The signer's name field of a data SIG MUST contain the name of the - zone to which the data and signature belong. The combination of - signer's name, key tag, and algorithm MUST identify a zone key if the - SIG is to be considered material. The only exception that the - signer's name field in a SIG KEY at a zone apex SHOULD contain the - parent zone's name, unless the KEY set is self-signed. This document - defines a standard policy for DNSSEC validation; local policy may - override the standard policy. - - There are no restrictions on the signer field of a SIG(0) record. - The combination of signer's name, key tag, and algorithm MUST - identify a key if this SIG(0) is to be processed. - -2.8 - Signature - - There are no restrictions on the signature field. The signature will - be verified at some point, but does not need to be examined prior to - verification unless a future algorithm imposes constraints. - -3 - The Signing KEY Record - - Once a signature has been examined and its fields validated (but - before the signature has been verified), the resolver attempts to - locate a KEY that matches the signer name, key tag, and algorithm - fields in the SIG. If one is not found, the SIG cannot be verified - and is considered immaterial. If KEYs are found, several fields of - the KEY record MUST have specific values if the SIG is to be - considered material and authorized. If there are multiple KEYs, the - following checks are performed on all of them, as there is no way to - determine which one generated the signature until the verification is - performed. - - - - - - - - -Wellington Standards Track [Page 3] - -RFC 3008 DNSSEC Signing Authority November 2000 - - -3.1 - Type Flags - - The signing KEY record MUST have a flags value of 00 or 01 - (authentication allowed, confidentiality optional) [RFC2535, 3.1.2]. - A DNSSEC resolver MUST only trust signatures generated by keys that - are permitted to authenticate data. - -3.2 - Name Flags - - The interpretation of this field is considerably different for data - SIGs and SIG(0) records. - -3.2.1 - Data SIG - - If the SIG record covers an RRset, the name type of the associated - KEY MUST be 01 (zone) [RFC2535, 3.1.2]. This updates RFC 2535, - section 2.3.6. The DNSSEC validation process performed by a resolver - MUST ignore all keys that are not zone keys unless local policy - dictates otherwise. - - The primary reason that RFC 2535 allows host and user keys to - generate material DNSSEC signatures is to allow dynamic update - without online zone keys; that is, avoid storing private keys in an - online server. The desire to avoid online signing keys cannot be - achieved, though, because they are necessary to sign NXT and SOA sets - [RFC3007]. These online zone keys can sign any incoming data. - Removing the goal of having no online keys removes the reason to - allow host and user keys to generate material signatures. - - Limiting material signatures to zone keys simplifies the validation - process. The length of the verification chain is bounded by the - name's label depth. The authority of a key is clearly defined; a - resolver does not need to make a potentially complicated decision to - determine whether a key has the proper authority to sign data. - - Finally, there is no additional flexibility granted by allowing - host/user key generated material signatures. As long as users and - hosts have the ability to authenticate update requests to the primary - zone server, signatures by zone keys are sufficient to protect the - integrity of the data to the world at large. - -3.2.2 - SIG(0) - - If the SIG record is a SIG(0) protecting a message, the name type of - the associated KEY SHOULD be 00 (user) or 10 (host/entity). - Transactions are initiated by a host or user, not a zone, so zone - keys SHOULD not generate SIG(0) records. - - - - -Wellington Standards Track [Page 4] - -RFC 3008 DNSSEC Signing Authority November 2000 - - - A client is either explicitly executed by a user or on behalf of a - host, therefore the name type of a SIG(0) generated by a client - SHOULD be either user or host. A nameserver is associated with a - host, and its use of SIG(0) is not associated with a particular zone, - so the name type of a SIG(0) generated by a nameserver SHOULD be - host. - -3.3 - Signatory Flags - - This document does not assign any values to the signatory field, nor - require any values to be present. - -3.4 - Protocol - - The signing KEY record MUST have a protocol value of 3 (DNSSEC) or - 255 (ALL). If a key is not specified for use with DNSSEC, a DNSSEC - resolver MUST NOT trust any signature that it generates. - -3.5 - Algorithm Number - - The algorithm field MUST be identical to that of the generated SIG - record, and MUST meet all requirements for an algorithm value in a - SIG record. - -4 - Security Considerations - - This document defines a standard baseline for a DNSSEC capable - resolver. This is necessary for a thorough security analysis of - DNSSEC, if one is to be done. - - Specifically, this document places additional restrictions on SIG - records that a resolver must validate before the signature can be - considered worthy of DNSSEC trust. This simplifies the protocol, - making it more robust and able to withstand scrutiny by the security - community. - -5 - Acknowledgements - - The author would like to thank the following people for review and - informative comments (in alphabetical order): - - Olafur Gudmundsson - Ed Lewis - - - - - - - - -Wellington Standards Track [Page 5] - -RFC 3008 DNSSEC Signing Authority November 2000 - - -6 - References - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2136] Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound, - "Dynamic Updates in the Domain Name System", RFC 2136, - April 1997. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures - (SIG(0)s )", RFC 2931, September 2000. - - [RFC3007] Wellington, B., "Simple Secure Domain Name System - (DNS) Dynamic Update", RFC 3007, November 2000. - -7 - Author's Address - - Brian Wellington - Nominum, Inc. - 950 Charter Street - Redwood City, CA 94063 - - Phone: +1 650 381 6022 - EMail: Brian.Wellington@nominum.com - - - - - - - - - - - - - - - - - - -Wellington Standards Track [Page 6] - -RFC 3008 DNSSEC Signing Authority November 2000 - - -8 Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Wellington Standards Track [Page 7] - diff --git a/contrib/bind9/doc/rfc/rfc3071.txt b/contrib/bind9/doc/rfc/rfc3071.txt deleted file mode 100644 index 2c4d52fc1141..000000000000 --- a/contrib/bind9/doc/rfc/rfc3071.txt +++ /dev/null @@ -1,563 +0,0 @@ - - - - - - -Network Working Group J. Klensin -Request for Comments: 3071 February 2001 -Category: Informational - - - Reflections on the DNS, RFC 1591, and Categories of Domains - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2001). All Rights Reserved. - -Abstract - - RFC 1591, "Domain Name System Structure and Delegation", laid out the - basic administrative design and principles for the allocation and - administration of domains, from the top level down. It was written - before the introduction of the world wide web (WWW) and rapid growth - of the Internet put significant market, social, and political - pressure on domain name allocations. In recent years, 1591 has been - cited by all sides in various debates, and attempts have been made by - various bodies to update it or adjust its provisions, sometimes under - pressures that have arguably produced policies that are less well - thought out than the original. Some of those efforts have begun from - misconceptions about the provisions of 1591 or the motivation for - those provisions. The current directions of the Internet Corporation - for Assigned Names and Numbers (ICANN) and other groups who now - determine the Domain Name System (DNS) policy directions appear to be - drifting away from the policies and philosophy of 1591. This - document is being published primarily for historical context and - comparative purposes, essentially to document some thoughts about how - 1591 might have been interpreted and adjusted by the Internet - Assigned Numbers Authority (IANA) and ICANN to better reflect today's - world while retaining characteristics and policies that have proven - to be effective in supporting Internet growth and stability. An - earlier variation of this memo was submitted to ICANN as a comment on - its evolving Top-level Domain (TLD) policies. - - - - - - - - - -Klensin Informational [Page 1] - -RFC 3071 Reflections on the DNS and RFC 1591 February 2001 - - -1. Introduction - - RFC 1591 [1] has been heavily discussed and referenced in the last - year or two, especially in discussions within ICANN and its - predecessors about the creation, delegation, and management of top- - level domains. In particular, the ICANN Domain Name Supporting - Organization (DNSO), and especially its ccTLD constituency, have been - the home of many discussions in which 1591 and interpretations of it - have been cited in support of a variety of sometimes-contradictory - positions. During that period, other discussions have gone on to try - to reconstruct the thinking that went into RFC 1591. Those in turn - have led me and others to muse on how that original thinking might - relate to some of the issues being raised. 1591 is, I believe, one - of Jon Postel's masterpieces, drawing together very different - philosophies (e.g., his traditional view that people are basically - reasonable and will do the right thing if told what it is with some - stronger mechanisms when that model is not successful) into a single - whole. - - RFC 1591 was written in the context of the assumption that what it - described as generic TLDs would be bound to policies and categories - of registration (see the "This domain is intended..." text in - section 2) while ccTLDs were expected to be used primarily to support - users and uses within and for a country and its residents. The - notion that different domains would be run in different ways --albeit - within the broad contexts of "public service on behalf of the - Internet community" and "trustee... for the global Internet - community"-- was considered a design feature and a safeguard against - a variety of potential abuses. Obviously the world has changed in - many ways in the seven or eight years since 1591 was written. In - particular, the Internet has become more heavily used and, because - the design of the world wide web has put domain names in front of - users, top-level domain names and registrations in them have been - heavily in demand: not only has the number of hosts increased - dramatically during that time, but the ratio between registered - domain names and physical hosts has increased very significantly. - - The issues 1591 attempted to address when it was written and those we - face today have not changed significantly in principle. But one - alternative to present trends would be to take a step back to refine - it into a model that can function effectively today. Therefore, it - may be useful to try to reconstruct 1591's principles and think about - their applicability today as a model that could continue to be - applied: not because it is historically significant, but because many - of its elements have proven to work reasonably well, even in - difficult situations. In particular, for many domains (some in - 1591's "generic" list and others in its "country code" category) the - notion of "public service" --expected then to imply being carried out - - - -Klensin Informational [Page 2] - -RFC 3071 Reflections on the DNS and RFC 1591 February 2001 - - - at no or minimal cost to the users, not merely on a non-profit - basis-- has yielded to profitability calculations. And, in most of - the rest, considerations of at least calculating and recovering costs - have crept in. While many of us feel some nostalgia for the old - system, it is clear that its days are waning if not gone: perhaps the - public service notions as understood when 1591 was written just don't - scale to rapid internet growth and very large numbers of - yregistrations. - - In particular, some ccTLDs have advertised for registrations outside - the designated countries (or other entities), while others have made - clear decisions to allow registrations by non-nationals. These - decisions and others have produced protests from many sides, - suggesting, in turn, that a recategorization is in order. For - example, we have heard concerns by governments and managers of - traditional, "public service", in-country, ccTLDs about excessive - ICANN interference and fears of being forced to conform to - internationally-set policies for dispute resolution when their - domestic ones are considered more appropriate. We have also heard - concerns from registrars and operators of externally-marketed ccTLDs - about unreasonable government interference and from gTLD registrars - and registries about unreasonable competition from aggressively - marketed ccTLDs. The appropriate distinction is no longer between - what RFC 1591 described as "generic" TLDs (but which were really - intended to be "purpose-specific", a term I will use again below) and - ccTLDs but among: - - (i) true "generic" TLDs, in which any registration is acceptable - and, ordinarily, registrations from all sources are actively - promoted. This list currently includes (the formerly purpose- - specific) COM, NET, and ORG, and some ccTLDs. There have been - proposals from time to time for additional TLDs of this variety in - which, as with COM (and, more recently, NET and ORG) anyone - (generally subject only to name conflicts and national law) could - register who could pay the fees. - - (ii) purpose-specific TLDs, in which registration is accepted only - from organizations or individuals meeting particular - qualifications, but where those qualifications are not tied to - national boundaries. This list currently includes INT, EDU, the - infrastructure domain ARPA, and, arguably, the specialized US - Government TLDs MIL and GOV. There have been proposals from time - to time for other international TLDs of this variety, e.g., for - medical entities such as physicians and hospitals and for museums. - ICANN has recently approved several TLDs of this type and - describes them as "sponsored" TLDs. - - - - - -Klensin Informational [Page 3] - -RFC 3071 Reflections on the DNS and RFC 1591 February 2001 - - - (iii) Country domains, operated according to the original - underlying assumptions of 1591, i.e., registrants are largely - expected to be people or other entities within the country. While - external registrations might be accepted by some of these, the - country does not aggressively advertise for such registrations, - nor does anyone expect to derive significant fee revenue from - them. All current domains in this category are ccTLDs, but not - all ccTLDs are in this category. - - These categories are clearly orthogonal to the association between - the use of the IS 3166-1 registered code list [2] and two-letter - "country" domain names. If that relationship is to be maintained - (and I believe it is desirable), the only inherent requirement is - that no two-letter TLDs be created except from that list (in order to - avoid future conflicts). ICANN should control the allocation and - delegation of TLDs using these, and other, criteria, but only - registered 3166-1 two letter codes should be used as two-letter TLDs. - -2. Implications of the Categories - - If we had adopted this type of three-way categorization and could - make it work, I believe it would have presented several opportunities - for ICANN and the community more generally to reduce controversies - and move forward. Of course, there will be cases where the - categorization of a particular domain and its operating style will - not be completely clear-cut (see section 3, below). But having ICANN - work out procedures for dealing with those (probably few) situations - appears preferable to strategies that would tend to propel ICANN into - areas that are beyond its competence or that might require - significant expansion of its mandate. - - First, the internally-operated ccTLDs (category iii above) should not - be required to have much interaction with ICANN or vice versa. Once - a domain of this sort is established and delegated, and assuming that - the "admin contact in the country" rule is strictly observed, the - domain should be able to function effectively without ICANN - intervention or oversight. In particular, while a country might - choose to adopt the general ICANN policies about dispute resolution - or name management, issues that arise in these areas might equally - well be dealt with exclusively under applicable national laws. If a - domain chooses to use ICANN services that cost resources to provide, - it should contribute to ICANN's support, but, if it does not, ICANN - should not presume to charge it for other than a reasonable fraction - of the costs to ICANN of operating the root, root servers, and any - directory systems that are generally agreed upon to be necessary and - in which the domain participates. - - - - - -Klensin Informational [Page 4] - -RFC 3071 Reflections on the DNS and RFC 1591 February 2001 - - - By contrast, ccTLDs operated as generic domains ought to be treated - as generic domains. ICANN dispute resolution and name management - policies and any special rules developed to protect the Internet - public in multiple registrar or registry situations should reasonably - apply. - -3. Telling TLD types apart - - If appropriate policies are adopted, ccTLDs operated as generic - domains (category (i) above) and those operated as country domains - (category (iii) above) ought to be able to be self-identified. There - are several criteria that could be applied to make this - determination. For example, either a domain is aggressively seeking - outside registrations or it is not and either the vast majority of - registrants in a domain are in-country or they are not. One could - also think of this as the issue of having some tangible level of - presence in the jurisdiction - e.g., is the administrative contact - subject, in practical terms, to the in-country laws, or are the - registration rules such that it is reasonably likely that a court in - the jurisdiction of the country associated with the domain can - exercise jurisdiction and enforce a judgment against the registrant. - - One (fairly non-intrusive) rule ICANN might well impose on all top- - level domains is that they identify and publish the policies they - intend to use. E.g., registrants in a domain that will use the laws - of one particular country to resolve disputes should have a - reasonable opportunity to understand those policies prior to - registration and to make other arrangements (e.g., to register - elsewhere) if that mechanism for dispute resolution is not - acceptable. Giving IANA (as the root registrar) incorrect - information about the purpose and use of a domain should be subject - to challenge, and should be grounds for reviewing the appropriateness - of the domain delegation, just as not acting consistently and - equitably provides such grounds under the original provisions of RFC - 1591. - - In order to ensure the availability of accurate and up-to-date - registration information the criteria must be consistent, and - consistent with more traditional gTLDs, for all nominally country - code domains operating as generic TLDs. - -4. The role of ICANN in country domains - - ICANN (and IANA) should, as described above, have as little - involvement as possible in the direction of true country [code] - domains (i.e., category (iii)). There is no particular reason why - - - - - -Klensin Informational [Page 5] - -RFC 3071 Reflections on the DNS and RFC 1591 February 2001 - - - these domains should be subject to ICANN regulation beyond the basic - principles of 1591 and associated arrangements needed to ensure - Internet interoperability and stability. - - ICANN's avoiding such involvement strengthens it: the desirability of - avoiding collisions with national sovereignty, determinations about - government legitimacy, and the authority of someone purportedly - writing on behalf of a government, is as important today as it was - when 1591 was written. The alternatives take us quickly from - "administration" into "internet governance" or, in the case of - determining which claimant is the legitimate government of a country, - "international relations", and the reasons for not moving in that - particular direction are legion. - -5. The role of governments - - The history of IANA strategy in handling ccTLDs included three major - "things to avoid" considerations: - - * Never get involved in determining which entities were countries - and which ones were not. - - * Never get involved in determining who was, or was not, the - legitimate government of a country. And, more generally, avoid - deciding what entity --government, religion, commercial, - academic, etc.-- has what legitimacy or rights. - - * If possible, never become involved in in-country disputes. - Instead, very strongly encourage internal parties to work - problems out among themselves. At most, adopt a role as - mediator and educator, rather than judge, unless abuses are very - clear and clearly will not be settled by any internal mechanism. - - All three considerations were obviously intended to avoid IANA's - being dragged into a political morass in which it had (and, I - suggest, has) no competence to resolve the issues and could only get - bogged down. The first consideration was the most visible (and the - easiest) and was implemented by strict and careful adherence (see - below) to the ISO 3166 registered Country Code list. If an entity - had a code, it was eligible to be registered with a TLD (although - IANA was free to apply additional criteria-most of them stated in - 1591). If it did not, there were no exceptions: the applicant's only - recourse was a discussion with the 3166 Registration Authority (now - Maintenance Agency, often known just as "3166/MA") or the UN - Statistical Office (now Statistics Bureau), not with IANA. - - - - - - -Klensin Informational [Page 6] - -RFC 3071 Reflections on the DNS and RFC 1591 February 2001 - - - There are actually five ccTLD exceptions to the strict rules. One, - "UK", is historical: it predates the adoption of ISO 3166 for this - purpose. The others --Ascension Island, Guernsey, Isle of Man, and - Jersey --are arguably, at least in retrospect, just mistakes. - Regardless of the historical reasons (about which there has been much - speculation), it is almost certainly the case that the right way to - handle mistakes of this sort is to acknowledge them and move on, - rather than trying to use them as precedents to justify more - mistakes. - - This, obviously, is also the argument against use of the "reserved" - list (technically internal to the 3166 maintenance activity, and not - part of the Standard): since IANA (or ICANN) can ask that a name be - placed on that list, there is no rule of an absolute determination by - an external organization. Purported countries can come to ICANN, - insist on having delegations made and persuade ICANN to ask that the - names be reserved. Then, since the reserved name would exist, they - could insist that the domain be delegated. Worse, someone could use - another organization to request reservation of the name by 3166/MA; - once it was reserved, ICANN might be hard-pressed not to do the - delegation. Of course, ICANN could (and probably would be forced to) - adopt additional criteria other than appearance on the "reserved - list" in order to delegate such domains. But those criteria would - almost certainly be nearly equivalent to determining which applicants - were legitimate and stable enough to be considered a country, the - exact decision process that 1591 strove to avoid. - - The other two considerations were more subtle and not always - successful: from time to time, both before and after the formal - policy shifted toward "governments could have their way", IANA - received letters from people purporting to be competent government - authorities asking for changes. Some of them turned out later to not - have that authority or appropriate qualifications. The assumption of - 1591 itself was that, if the "administrative contact in country" rule - was strictly observed, as was the rule that delegation changes - requested by the administrative contact would be honored, then, if a - government _really_ wanted to assert itself, it could pressure the - administrative contact into requesting the changes it wanted, using - whatever would pass for due process in that country. And the ability - to apply that process and pressure would effectively determine who - was the government and who wasn't, and would do so far more - effectively than any IANA evaluation of, e.g., whether the letterhead - on a request looked authentic (and far more safely for ICANN than - asking the opinion of any particular other government or selection of - governments). - - - - - - -Klensin Informational [Page 7] - -RFC 3071 Reflections on the DNS and RFC 1591 February 2001 - - - Specific language in 1591 permitted IANA to adopt a "work it out - yourselves; if we have to decide, we will strive for a solution that - is not satisfactory to any party" stance. That approach was used - successfully, along with large doses of education, on many occasions - over the years, to avoid IANA's having to assume the role of judge - between conflicting parties. - - Similar principles could be applied to the boundary between country- - code-based generic TLDs and country domains. Different countries, - under different circumstances, might prefer to operate the ccTLD - either as a national service or as a profit center where the - "customers" were largely external. Whatever decisions were made - historically, general Internet stability argues that changes should - not be made lightly. At the same time, if a government wishes to - make a change, the best mechanism for doing so is not to involve - ICANN in a potential determination of legitimacy (or even to have - ICANN's Government Advisory Committee (GAC) try to formally make that - decision for individual countries) but for the relevant government to - use its own procedures to persuade the administrative contact to - request the change and for IANA to promptly and efficiently carry out - requests made by administrative contacts. - -6. Implications for the current ICANN DNSO structure. - - The arguments by some of the ccTLD administrators that they are - different from the rest of the ICANN and DNSO structures are (in this - model) correct: they are different. The ccTLDs that are operating as - generic TLDs should be separated from the ccTLD constituency and - joined to the gTLD constituency. The country ccTLDs should be - separated from ICANN's immediate Supporting Organization structure, - and operate in a parallel and advisory capacity to ICANN, similar to - the arrangements used with the GAC. The DNSO and country TLDs should - not be required to interact with each other except on a mutually - voluntary basis and, if ICANN needs interaction or advice from some - of all of those TLDs, it would be more appropriate to get it in the - form of an advisory body like the GAC rather than as DNSO - constituency. - -7. References - - [1] Postel, J., "Domain Name System Structure and Delegation", RFC - 1591, March 1994. - - [2] ISO 3166. ISO 3166-1. Codes for the representation of names of - countries and their subdivisions - Part 1: Country codes (1997). - - - - - - -Klensin Informational [Page 8] - -RFC 3071 Reflections on the DNS and RFC 1591 February 2001 - - -8. Acknowledgements and disclaimer - - These reflections have been prepared in my individual capacity and do - not necessarily reflect the views of my past or present employers. - Several people, including Randy Bush, Theresa Swinehart, Zita Wenzel, - Geoff Huston, Havard Eidnes, and several anonymous reviewers, made - suggestions or offered editorial comments about earlier versions of - this document. Cord Wischhoefer, of the ISO 3166/MA, was also kind - enough to look at the draft and supplied some useful details. Those - comments contributed significantly to whatever clarity the document - has, but the author bears responsibility for the selection of - comments which were ultimately incorporated and the way in which the - conclusions were presented. - -9. Security Considerations - - This memo addresses the context for a set of administrative decisions - and procedures, and does not raise or address security issues. - -10. Author's Address - - John C. Klensin - 1770 Massachusetts Ave, Suite 322 - Cambridge, MA 02140, USA - - EMail: klensin@jck.com - - - - - - - - - - - - - - - - - - - - - - - - - -Klensin Informational [Page 9] - -RFC 3071 Reflections on the DNS and RFC 1591 February 2001 - - -11. Full Copyright Statement - - Copyright (C) The Internet Society 2001. All Rights Reserved. - - This document and translations of it may be copied and furnished to - others provided that the above copyright notice and this paragraph - are included on all such copies. However, this document itself may - not be modified in any way, such as by removing the copyright notice - or references to the Internet Society or other Internet - organizations, except as required to translate it into languages - other than English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - -Klensin Informational [Page 10] - diff --git a/contrib/bind9/doc/rfc/rfc3090.txt b/contrib/bind9/doc/rfc/rfc3090.txt deleted file mode 100644 index 08008f7a3ddd..000000000000 --- a/contrib/bind9/doc/rfc/rfc3090.txt +++ /dev/null @@ -1,619 +0,0 @@ - - - - - - -Network Working Group E. Lewis -Request for Comments: 3090 NAI Labs -Category: Standards Track March 2001 - - - DNS Security Extension Clarification on Zone Status - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2001). All Rights Reserved. - -Abstract - - The definition of a secured zone is presented, clarifying and - updating sections of RFC 2535. RFC 2535 defines a zone to be secured - based on a per algorithm basis, e.g., a zone can be secured with RSA - keys, and not secured with DSA keys. This document changes this to - define a zone to be secured or not secured regardless of the key - algorithm used (or not used). To further simplify the determination - of a zone's status, "experimentally secure" status is deprecated. - -1 Introduction - - Whether a DNS zone is "secured" or not is a question asked in at - least four contexts. A zone administrator asks the question when - configuring a zone to use DNSSEC. A dynamic update server asks the - question when an update request arrives, which may require DNSSEC - processing. A delegating zone asks the question of a child zone when - the parent enters data indicating the status the child. A resolver - asks the question upon receipt of data belonging to the zone. - -1.1 When a Zone's Status is Important - - A zone administrator needs to be able to determine what steps are - needed to make the zone as secure as it can be. Realizing that due - to the distributed nature of DNS and its administration, any single - zone is at the mercy of other zones when it comes to the appearance - of security. This document will define what makes a zone qualify as - secure. - - - - -Lewis Standards Track [Page 1] - -RFC 3090 DNS Security Extension on Zone Status March 2001 - - - A name server performing dynamic updates needs to know whether a zone - being updated is to have signatures added to the updated data, NXT - records applied, and other required processing. In this case, it is - conceivable that the name server is configured with the knowledge, - but being able to determine the status of a zone by examining the - data is a desirable alternative to configuration parameters. - - A delegating zone is required to indicate whether a child zone is - secured. The reason for this requirement lies in the way in which a - resolver makes its own determination about a zone (next paragraph). - To shorten a long story, a parent needs to know whether a child - should be considered secured. This is a two part question. Under - what circumstances does a parent consider a child zone to be secure, - and how does a parent know if the child conforms? - - A resolver needs to know if a zone is secured when the resolver is - processing data from the zone. Ultimately, a resolver needs to know - whether or not to expect a usable signature covering the data. How - this determination is done is out of the scope of this document, - except that, in some cases, the resolver will need to contact the - parent of the zone to see if the parent states that the child is - secured. - -1.2 Islands of Security - - The goal of DNSSEC is to have each zone secured, from the root zone - and the top-level domains down the hierarchy to the leaf zones. - Transitioning from an unsecured DNS, as we have now, to a fully - secured - or "as much as will be secured" - tree will take some time. - During this time, DNSSEC will be applied in various locations in the - tree, not necessarily "top down." - - For example, at a particular instant, the root zone and the "test." - TLD might be secured, but region1.test. might not be. (For - reference, let's assume that region2.test. is secured.) However, - subarea1.region1.test. may have gone through the process of becoming - secured, along with its delegations. The dilemma here is that - subarea1 cannot get its zone keys properly signed as its parent zone, - region1, is not secured. - - The colloquial phrase describing the collection of contiguous secured - zones at or below subarea1.region1.test. is an "island of security." - The only way in which a DNSSEC resolver will come to trust any data - from this island is if the resolver is pre-configured with the zone - key(s) for subarea1.region1.test., i.e., the root of the island of - security. Other resolvers (not so configured) will recognize this - island as unsecured. - - - - -Lewis Standards Track [Page 2] - -RFC 3090 DNS Security Extension on Zone Status March 2001 - - - An island of security begins with one zone whose public key is pre- - configured in resolvers. Within this island are subzones which are - also secured. The "bottom" of the island is defined by delegations - to unsecured zones. One island may also be on top of another - - meaning that there is at least one unsecured zone between the bottom - of the upper island and the root of the lower secured island. - - Although both subarea1.region1.test. and region2.test. have both been - properly brought to a secured state by the administering staff, only - the latter of the two is actually "globally" secured - in the sense - that all DNSSEC resolvers can and will verify its data. The former, - subarea1, will be seen as secured by a subset of those resolvers, - just those appropriately configured. This document refers to such - zones as being "locally" secured. - - In RFC 2535, there is a provision for "certification authorities," - entities that will sign public keys for zones such as subarea1. - There is another document, [RFC3008], that restricts this activity. - Regardless of the other document, resolvers would still need proper - configuration to be able to use the certification authority to verify - the data for the subarea1 island. - -1.2.1 Determining the closest security root - - Given a domain, in order to determine whether it is secure or not, - the first step is to determine the closest security root. The - closest security root is the top of an island of security whose name - has the most matching (in order from the root) right-most labels to - the given domain. - - For example, given a name "sub.domain.testing.signed.exp.test.", and - given the secure roots "exp.test.", "testing.signed.exp.test." and - "not-the-same.xy.", the middle one is the closest. The first secure - root shares 2 labels, the middle 4, and the last 0. - - The reason why the closest is desired is to eliminate false senses of - insecurity because of a NULL key. Continuing with the example, the - reason both "testing..." and "exp.test." are listed as secure root is - presumably because "signed.exp.test." is unsecured (has a NULL key). - If we started to descend from "exp.test." to our given domain - (sub...), we would encounter a NULL key and conclude that sub... was - unsigned. However, if we descend from "testing..." and find keys - "domain...." then we can conclude that "sub..." is secured. - - Note that this example assumes one-label deep zones, and assumes that - we do not configure overlapping islands of security. To be clear, - the definition given should exclude "short.xy.test." from being a - closest security root for "short.xy." even though 2 labels match. - - - -Lewis Standards Track [Page 3] - -RFC 3090 DNS Security Extension on Zone Status March 2001 - - - Overlapping islands of security introduce no conceptually interesting - ideas and do not impact the protocol in anyway. However, protocol - implementers are advised to make sure their code is not thrown for a - loop by overlaps. Overlaps are sure to be configuration problems as - islands of security grow to encompass larger regions of the name - space. - -1.3 Parent Statement of Child Security - - In 1.1 of this document, there is the comment "the parent states that - the child is secured." This has caused quite a bit of confusion. - - The need to have the parent "state" the status of a child is derived - from the following observation. If you are looking to see if an - answer is secured, that it comes from an "island of security" and is - properly signed, you must begin at the (appropriate) root of the - island of security. - - To find the answer you are inspecting, you may have to descend - through zones within the island of security. Beginning with the - trusted root of the island, you descend into the next zone down. As - you trust the upper zone, you need to get data from it about the next - zone down, otherwise there is a vulnerable point in which a zone can - be hijacked. When or if you reach a point of traversing from a - secured zone to an unsecured zone, you have left the island of - security and should conclude that the answer is unsecured. - - However, in RFC 2535, section 2.3.4, these words seem to conflict - with the need to have the parent "state" something about a child: - - There MUST be a zone KEY RR, signed by its superzone, for every - subzone if the superzone is secure. This will normally appear in - the subzone and may also be included in the superzone. But, in - the case of an unsecured subzone which can not or will not be - modified to add any security RRs, a KEY declaring the subzone to - be unsecured MUST appear with the superzone signature in the - superzone, if the superzone is secure. - - The confusion here is that in RFC 2535, a secured parent states that - a child is secured by SAYING NOTHING ("may also be" as opposed to - "MUST also be"). This is counter intuitive, the fact that an absence - of data means something is "secured." This notion, while acceptable - in a theoretic setting has met with some discomfort in an operation - setting. However, the use of "silence" to state something does - indeed work in this case, so there hasn't been sufficient need - demonstrated to change the definition. - - - - - -Lewis Standards Track [Page 4] - -RFC 3090 DNS Security Extension on Zone Status March 2001 - - -1.4 Impact on RFC 2535 - - This document updates sections of RFC 2535. The definition of a - secured zone is an update to section 3.4 of the RFC. Section 3.4 is - updated to eliminate the definition of experimental keys and - illustrate a way to still achieve the functionality they were - designed to provide. Section 3.1.3 is updated by the specifying the - value of the protocol octet in a zone key. - -1.5 "MUST" and other key words - - The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" - in this document are to be interpreted as described in [RFC 2119]. - Currently, only "MUST" is used in this document. - -2 Status of a Zone - - In this section, rules governing a zone's DNSSEC status are - presented. There are three levels of security defined: global, - local, and unsecured. A zone is globally secure when it complies - with the strictest set of DNSSEC processing rules. A zone is locally - secured when it is configured in such a way that only resolvers that - are appropriately configured see the zone as secured. All other - zones are unsecured. - - Note: there currently is no document completely defining DNSSEC - verification rules. For the purposes of this document, the strictest - rules are assumed to state that the verification chain of zone keys - parallels the delegation tree up to the root zone. (See 2.b below.) - This is not intended to disallow alternate verification paths, just - to establish a baseline definition. - - To avoid repetition in the rules below, the following terms are - defined. - - 2.a Zone signing KEY RR - A KEY RR whose flag field has the value 01 - for name type (indicating a zone key) and either value 00 or value 01 - for key type (indicating a key permitted to authenticate data). (See - RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value - of DNSSEC (3) or ALL (255). - - The definition updates RFC 2535's definition of a zone key. The - requirement that the protocol field be either DNSSEC or ALL is a new - requirement (a change to section 3.1.3.) - - 2.b On-tree Validation - The authorization model in which only the - parent zone is recognized to supply a DNSSEC-meaningful signature - that is used by a resolver to build a chain of trust from the child's - - - -Lewis Standards Track [Page 5] - -RFC 3090 DNS Security Extension on Zone Status March 2001 - - - keys to a recognized root of security. The term "on-tree" refers to - following the DNS domain hierarchy (upwards) to reach a trusted key, - presumably the root key if no other key is available. The term - "validation" refers to the digital signature by the parent to prove - the integrity, authentication and authorization of the child's key to - sign the child's zone data. - - 2.c Off-tree Validation - Any authorization model that permits domain - names other than the parent's to provide a signature over a child's - zone keys that will enable a resolver to trust the keys. - -2.1 Globally Secured - - A globally secured zone, in a nutshell, is a zone that uses only - mandatory to implement algorithms (RFC 2535, section 3.2) and relies - on a key certification chain that parallels the delegation tree (on- - tree validation). Globally secured zones are defined by the - following rules. - - 2.1.a. The zone's apex MUST have a KEY RR set. There MUST be at - least one zone signing KEY RR (2.a) of a mandatory to implement - algorithm in the set. - - 2.1.b. The zone's apex KEY RR set MUST be signed by a private key - belonging to the parent zone. The private key's public companion - MUST be a zone signing KEY RR (2.a) of a mandatory to implement - algorithm and owned by the parent's apex. - - If a zone cannot get a conforming signature from the parent zone, the - child zone cannot be considered globally secured. The only exception - to this is the root zone, for which there is no parent zone. - - 2.1.c. NXT records MUST be deployed throughout the zone. (Clarifies - RFC 2535, section 2.3.2.) Note: there is some operational discomfort - with the current NXT record. This requirement is open to - modification when two things happen. First, an alternate mechanism - to the NXT is defined and second, a means by which a zone can - indicate that it is using an alternate method. - - 2.1.d. Each RR set that qualifies for zone membership MUST be signed - by a key that is in the apex's KEY RR set and is a zone signing KEY - RR (2.a) of a mandatory to implement algorithm. (Updates 2535, - section 2.3.1.) - - Mentioned earlier, the root zone is a special case. The root zone - will be considered to be globally secured provided that if conforms - to the rules for locally secured, with the exception that rule 2.1.a. - be also met (mandatory to implement requirement). - - - -Lewis Standards Track [Page 6] - -RFC 3090 DNS Security Extension on Zone Status March 2001 - - -2.2 Locally Secured - - The term "locally" stems from the likely hood that the only resolvers - to be configured for a particular zone will be resolvers "local" to - an organization. - - A locally secured zone is a zone that complies with rules like those - for a globally secured zone with the following exceptions. The - signing keys may be of an algorithm that is not mandatory to - implement and/or the verification of the zone keys in use may rely on - a verification chain that is not parallel to the delegation tree - (off-tree validation). - - 2.2.a. The zone's apex MUST have a KEY RR set. There MUST be at - least one zone signing KEY RR (2.a) in the set. - - 2.2.b. The zone's apex KEY RR set MUST be signed by a private key and - one of the following two subclauses MUST hold true. - - 2.2.b.1 The private key's public companion MUST be pre-configured in - all the resolvers of interest. - - 2.2.b.2 The private key's public companion MUST be a zone signing KEY - RR (2.a) authorized to provide validation of the zone's apex KEY RR - set, as recognized by resolvers of interest. - - The previous sentence is trying to convey the notion of using a - trusted third party to provide validation of keys. If the domain - name owning the validating key is not the parent zone, the domain - name must represent someone the resolver trusts to provide - validation. - - 2.2.c. NXT records MUST be deployed throughout the zone. Note: see - the discussion following 2.1.c. - - 2.2.d. Each RR set that qualifies for zone membership MUST be signed - by a key that is in the apex's KEY RR set and is a zone signing KEY - RR (2.a). (Updates 2535, section 2.3.1.) - -2.3 Unsecured - - All other zones qualify as unsecured. This includes zones that are - designed to be experimentally secure, as defined in a later section - on that topic. - - - - - - - -Lewis Standards Track [Page 7] - -RFC 3090 DNS Security Extension on Zone Status March 2001 - - -2.4 Wrap up - - The designation of globally secured, locally secured, and unsecured - are merely labels to apply to zones, based on their contents. - Resolvers, when determining whether a signature is expected or not, - will only see a zone as secured or unsecured. - - Resolvers that follow the most restrictive DNSSEC verification rules - will only see globally secured zones as secured, and all others as - unsecured, including zones which are locally secured. Resolvers that - are not as restrictive, such as those that implement algorithms in - addition to the mandatory to implement algorithms, will see some - locally secured zones as secured. - - The intent of the labels "global" and "local" is to identify the - specific attributes of a zone. The words are chosen to assist in the - writing of a document recommending the actions a zone administrator - take in making use of the DNS security extensions. The words are - explicitly not intended to convey a state of compliance with DNS - security standards. - -3 Experimental Status - - The purpose of an experimentally secured zone is to facilitate the - migration from an unsecured zone to a secured zone. This distinction - is dropped. - - The objective of facilitating the migration can be achieved without a - special designation of an experimentally secure status. - Experimentally secured is a special case of locally secured. A zone - administrator can achieve this by publishing a zone with signatures - and configuring a set of test resolvers with the corresponding public - keys. Even if the public key is published in a KEY RR, as long as - there is no parent signature, the resolvers will need some pre- - configuration to know to process the signatures. This allows a zone - to be secured with in the sphere of the experiment, yet still be - registered as unsecured in the general Internet. - -4 IANA Considerations - - This document does not request any action from an assigned number - authority nor recommends any actions. - - - - - - - - - -Lewis Standards Track [Page 8] - -RFC 3090 DNS Security Extension on Zone Status March 2001 - - -5 Security Considerations - - Without a means to enforce compliance with specified protocols or - recommended actions, declaring a DNS zone to be "completely" secured - is impossible. Even if, assuming an omnipotent view of DNS, one can - declare a zone to be properly configured for security, and all of the - zones up to the root too, a misbehaving resolver could be duped into - believing bad data. If a zone and resolver comply, a non-compliant - or subverted parent could interrupt operations. The best that can be - hoped for is that all parties are prepared to be judged secure and - that security incidents can be traced to the cause in short order. - -6 Acknowledgements - - The need to refine the definition of a secured zone has become - apparent through the efforts of the participants at two DNSSEC - workshops, sponsored by the NIC-SE (.se registrar), CAIRN (a DARPA- - funded research network), and other workshops. Further discussions - leading to the document include Olafur Gudmundsson, Russ Mundy, - Robert Watson, and Brian Wellington. Roy Arends, Ted Lindgreen and - others have contributed significant input via the namedroppers - mailing list. - -7 References - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2136] Vixie, P., (Ed.), Thomson, S., Rekhter, Y. and J. Bound, - "Dynamic Updates in the Domain Name System", RFC 2136, - April 1997. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS) - Dynamic Update", RFC 3007, November 2000. - - [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) - Signing Authority", RFC 3008, November 2000. - - - - - -Lewis Standards Track [Page 9] - -RFC 3090 DNS Security Extension on Zone Status March 2001 - - -10 Author's Address - - Edward Lewis - NAI Labs - 3060 Washington Road Glenwood - MD 21738 - - Phone: +1 443 259 2352 - EMail: lewis@tislabs.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lewis Standards Track [Page 10] - -RFC 3090 DNS Security Extension on Zone Status March 2001 - - -11 Full Copyright Statement - - Copyright (C) The Internet Society (2001). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Lewis Standards Track [Page 11] - diff --git a/contrib/bind9/doc/rfc/rfc3110.txt b/contrib/bind9/doc/rfc/rfc3110.txt deleted file mode 100644 index 764694860c60..000000000000 --- a/contrib/bind9/doc/rfc/rfc3110.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -Network Working Group D. Eastlake 3rd -Request for Comments: 3110 Motorola -Obsoletes: 2537 May 2001 -Category: Standards Track - - - RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2001). All Rights Reserved. - -Abstract - - This document describes how to produce RSA/SHA1 SIG resource records - (RRs) in Section 3 and, so as to completely replace RFC 2537, - describes how to produce RSA KEY RRs in Section 2. - - Since the adoption of a Proposed Standard for RSA signatures in the - DNS (Domain Name Space), advances in hashing have been made. A new - DNS signature algorithm is defined to make these advances available - in SIG RRs. The use of the previously specified weaker mechanism is - deprecated. The algorithm number of the RSA KEY RR is changed to - correspond to this new SIG algorithm. No other changes are made to - DNS security. - -Acknowledgements - - Material and comments from the following have been incorporated and - are gratefully acknowledged: - - Olafur Gudmundsson - - The IESG - - Charlie Kaufman - - Steve Wang - - - - - -D. Eastlake 3rd Standards Track [Page 1] - -RFC 3110 RSA SIGs and KEYs in the DNS May 2001 - - -Table of Contents - - 1. Introduction................................................... 2 - 2. RSA Public KEY Resource Records................................ 3 - 3. RSA/SHA1 SIG Resource Records.................................. 3 - 4. Performance Considerations..................................... 4 - 5. IANA Considerations............................................ 5 - 6. Security Considerations........................................ 5 - References........................................................ 5 - Author's Address.................................................. 6 - Full Copyright Statement.......................................... 7 - -1. Introduction - - The Domain Name System (DNS) is the global hierarchical replicated - distributed database system for Internet addressing, mail proxy, and - other information [RFC1034, 1035, etc.]. The DNS has been extended - to include digital signatures and cryptographic keys as described in - [RFC2535]. Thus the DNS can now be secured and used for secure key - distribution. - - Familiarity with the RSA and SHA-1 algorithms is assumed [Schneier, - FIP180] in this document. - - RFC 2537 described how to store RSA keys and RSA/MD5 based signatures - in the DNS. However, since the adoption of RFC 2537, continued - cryptographic research has revealed hints of weakness in the MD5 - [RFC1321] algorithm used in RFC 2537. The SHA1 Secure Hash Algorithm - [FIP180], which produces a larger hash, has been developed. By now - there has been sufficient experience with SHA1 that it is generally - acknowledged to be stronger than MD5. While this stronger hash is - probably not needed today in most secure DNS zones, critical zones - such a root, most top level domains, and some second and third level - domains, are sufficiently valuable targets that it would be negligent - not to provide what are generally agreed to be stronger mechanisms. - Furthermore, future advances in cryptanalysis and/or computer speeds - may require a stronger hash everywhere. In addition, the additional - computation required by SHA1 above that required by MD5 is - insignificant compared with the computational effort required by the - RSA modular exponentiation. - - This document describes how to produce RSA/SHA1 SIG RRs in Section 3 - and, so as to completely replace RFC 2537, describes how to produce - RSA KEY RRs in Section 2. - - Implementation of the RSA algorithm in DNS with SHA1 is MANDATORY for - DNSSEC. The generation of RSA/MD5 SIG RRs as described in RFC 2537 - is NOT RECOMMENDED. - - - -D. Eastlake 3rd Standards Track [Page 2] - -RFC 3110 RSA SIGs and KEYs in the DNS May 2001 - - - The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", "NOT - RECOMMENDED", and "MAY" in this document are to be interpreted as - described in RFC 2119. - -2. RSA Public KEY Resource Records - - RSA public keys are stored in the DNS as KEY RRs using algorithm - number 5 [RFC2535]. The structure of the algorithm specific portion - of the RDATA part of such RRs is as shown below. - - Field Size - ----- ---- - exponent length 1 or 3 octets (see text) - exponent as specified by length field - modulus remaining space - - For interoperability, the exponent and modulus are each limited to - 4096 bits in length. The public key exponent is a variable length - unsigned integer. Its length in octets is represented as one octet - if it is in the range of 1 to 255 and by a zero octet followed by a - two octet unsigned length if it is longer than 255 bytes. The public - key modulus field is a multiprecision unsigned integer. The length - of the modulus can be determined from the RDLENGTH and the preceding - RDATA fields including the exponent. Leading zero octets are - prohibited in the exponent and modulus. - - Note: KEY RRs for use with RSA/SHA1 DNS signatures MUST use this - algorithm number (rather than the algorithm number specified in the - obsoleted RFC 2537). - - Note: This changes the algorithm number for RSA KEY RRs to be the - same as the new algorithm number for RSA/SHA1 SIGs. - -3. RSA/SHA1 SIG Resource Records - - RSA/SHA1 signatures are stored in the DNS using SIG resource records - (RRs) with algorithm number 5. - - The signature portion of the SIG RR RDATA area, when using the - RSA/SHA1 algorithm, is calculated as shown below. The data signed is - determined as specified in RFC 2535. See RFC 2535 for fields in the - SIG RR RDATA which precede the signature itself. - - hash = SHA1 ( data ) - - signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n) - - - - - -D. Eastlake 3rd Standards Track [Page 3] - -RFC 3110 RSA SIGs and KEYs in the DNS May 2001 - - - where SHA1 is the message digest algorithm documented in [FIP180], - "|" is concatenation, "e" is the private key exponent of the signer, - and "n" is the modulus of the signer's public key. 01, FF, and 00 - are fixed octets of the corresponding hexadecimal value. "prefix" is - the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1 - [RFC2437], that is, - - hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 - - This prefix is included to make it easier to use standard - cryptographic libraries. The FF octet MUST be repeated the maximum - number of times such that the value of the quantity being - exponentiated is one octet shorter than the value of n. - - (The above specifications are identical to the corresponding parts of - Public Key Cryptographic Standard #1 [RFC2437].) - - The size of "n", including most and least significant bits (which - will be 1) MUST be not less than 512 bits and not more than 4096 - bits. "n" and "e" SHOULD be chosen such that the public exponent is - small. These are protocol limits. For a discussion of key size see - RFC 2541. - - Leading zero bytes are permitted in the RSA/SHA1 algorithm signature. - -4. Performance Considerations - - General signature generation speeds are roughly the same for RSA and - DSA [RFC2536]. With sufficient pre-computation, signature generation - with DSA is faster than RSA. Key generation is also faster for DSA. - However, signature verification is an order of magnitude slower with - DSA when the RSA public exponent is chosen to be small as is - recommended for KEY RRs used in domain name system (DNS) data - authentication. - - A public exponent of 3 minimizes the effort needed to verify a - signature. Use of 3 as the public exponent is weak for - confidentiality uses since, if the same data can be collected - encrypted under three different keys with an exponent of 3 then, - using the Chinese Remainder Theorem [NETSEC], the original plain text - can be easily recovered. If a key is known to be used only for - authentication, as is the case with DNSSEC, then an exponent of 3 is - acceptable. However other applications in the future may wish to - leverage DNS distributed keys for applications that do require - confidentiality. For keys which might have such other uses, a more - conservative choice would be 65537 (F4, the fourth fermat number). - - - - - -D. Eastlake 3rd Standards Track [Page 4] - -RFC 3110 RSA SIGs and KEYs in the DNS May 2001 - - - Current DNS implementations are optimized for small transfers, - typically less than 512 bytes including DNS overhead. Larger - transfers will perform correctly and extensions have been - standardized [RFC2671] to make larger transfers more efficient, it is - still advisable at this time to make reasonable efforts to minimize - the size of KEY RR sets stored within the DNS consistent with - adequate security. Keep in mind that in a secure zone, at least one - authenticating SIG RR will also be returned. - -5. IANA Considerations - - The DNSSEC algorithm number 5 is allocated for RSA/SHA1 SIG RRs and - RSA KEY RRs. - -6. Security Considerations - - Many of the general security considerations in RFC 2535 apply. Keys - retrieved from the DNS should not be trusted unless (1) they have - been securely obtained from a secure resolver or independently - verified by the user and (2) this secure resolver and secure - obtainment or independent verification conform to security policies - acceptable to the user. As with all cryptographic algorithms, - evaluating the necessary strength of the key is essential and - dependent on local policy. For particularly critical applications, - implementers are encouraged to consider the range of available - algorithms and key sizes. See also RFC 2541, "DNS Security - Operational Considerations". - -References - - [FIP180] U.S. Department of Commerce, "Secure Hash Standard", FIPS - PUB 180-1, 17 Apr 1995. - - [NETSEC] Network Security: PRIVATE Communications in a PUBLIC - World, Charlie Kaufman, Radia Perlman, & Mike Speciner, - Prentice Hall Series in Computer Networking and - Distributed Communications, 1995. - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, - April 1992. - - - - - -D. Eastlake 3rd Standards Track [Page 5] - -RFC 3110 RSA SIGs and KEYs in the DNS May 2001 - - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography - Specifications Version 2.0", RFC 2437, October 1998. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System - (DNS)", RFC 2536, March 1999. - - [RFC2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name - System (DNS)", RFC 2537, March 1999. - - [RFC2541] Eastlake, D., "DNS Security Operational Considerations", - RFC 2541, March 1999. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [Schneier] Bruce Schneier, "Applied Cryptography Second Edition: - protocols, algorithms, and source code in C", 1996, John - Wiley and Sons, ISBN 0-471-11709-9. - -Author's Address - - Donald E. Eastlake 3rd - Motorola - 155 Beaver Street - Milford, MA 01757 USA - - Phone: +1-508-261-5434 (w) - +1-508-634-2066 (h) - Fax +1-508-261-4777 (w) - EMail: Donald.Eastlake@motorola.com - - - - - - - - - - - - - - - -D. Eastlake 3rd Standards Track [Page 6] - -RFC 3110 RSA SIGs and KEYs in the DNS May 2001 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2001). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd Standards Track [Page 7] - diff --git a/contrib/bind9/doc/rfc/rfc3123.txt b/contrib/bind9/doc/rfc/rfc3123.txt deleted file mode 100644 index 3b2fe00e5ee8..000000000000 --- a/contrib/bind9/doc/rfc/rfc3123.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -Network Working Group P. Koch -Request for Comments: 3123 Universitaet Bielefeld -Category: Experimental June 2001 - - - A DNS RR Type for Lists of Address Prefixes (APL RR) - -Status of this Memo - - This memo defines an Experimental Protocol for the Internet - community. It does not specify an Internet standard of any kind. - Discussion and suggestions for improvement are requested. - Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2001). All Rights Reserved. - -Abstract - - The Domain Name System (DNS) is primarily used to translate domain - names into IPv4 addresses using A RRs (Resource Records). Several - approaches exist to describe networks or address ranges. This - document specifies a new DNS RR type "APL" for address prefix lists. - -1. Conventions used in this document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - Domain names herein are for explanatory purposes only and should not - be expected to lead to useful information in real life [RFC2606]. - -2. Background - - The Domain Name System [RFC1034], [RFC1035] provides a mechanism to - associate addresses and other Internet infrastructure elements with - hierarchically built domain names. Various types of resource records - have been defined, especially those for IPv4 and IPv6 [RFC2874] - addresses. In [RFC1101] a method is described to publish information - about the address space allocated to an organisation. In older BIND - versions, a weak form of controlling access to zone data was - implemented using TXT RRs describing address ranges. - - This document specifies a new RR type for address prefix lists. - - - - - -Koch Experimental [Page 1] - -RFC 3123 DNS APL RR June 2001 - - -3. APL RR Type - - An APL record has the DNS type of "APL" and a numeric value of 42 - [IANA]. The APL RR is defined in the IN class only. APL RRs cause - no additional section processing. - -4. APL RDATA format - - The RDATA section consists of zero or more items (<apitem>) of the - form - - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - | ADDRESSFAMILY | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - | PREFIX | N | AFDLENGTH | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - / AFDPART / - | | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - ADDRESSFAMILY 16 bit unsigned value as assigned by IANA - (see IANA Considerations) - PREFIX 8 bit unsigned binary coded prefix length. - Upper and lower bounds and interpretation of - this value are address family specific. - N negation flag, indicates the presence of the - "!" character in the textual format. It has - the value "1" if the "!" was given, "0" else. - AFDLENGTH length in octets of the following address - family dependent part (7 bit unsigned). - AFDPART address family dependent part. See below. - - This document defines the AFDPARTs for address families 1 (IPv4) and - 2 (IPv6). Future revisions may deal with additional address - families. - -4.1. AFDPART for IPv4 - - The encoding of an IPv4 address (address family 1) follows the - encoding specified for the A RR by [RFC1035], section 3.4.1. - - PREFIX specifies the number of bits of the IPv4 address starting at - the most significant bit. Legal values range from 0 to 32. - - Trailing zero octets do not bear any information (e.g., there is no - semantic difference between 10.0.0.0/16 and 10/16) in an address - prefix, so the shortest possible AFDLENGTH can be used to encode it. - However, for DNSSEC [RFC2535] a single wire encoding must be used by - - - -Koch Experimental [Page 2] - -RFC 3123 DNS APL RR June 2001 - - - all. Therefore the sender MUST NOT include trailing zero octets in - the AFDPART regardless of the value of PREFIX. This includes cases - in which AFDLENGTH times 8 results in a value less than PREFIX. The - AFDPART is padded with zero bits to match a full octet boundary. - - An IPv4 AFDPART has a variable length of 0 to 4 octets. - -4.2. AFDPART for IPv6 - - The 128 bit IPv6 address (address family 2) is encoded in network - byte order (high-order byte first). - - PREFIX specifies the number of bits of the IPv6 address starting at - the most significant bit. Legal values range from 0 to 128. - - With the same reasoning as in 4.1 above, the sender MUST NOT include - trailing zero octets in the AFDPART regardless of the value of - PREFIX. This includes cases in which AFDLENGTH times 8 results in a - value less than PREFIX. The AFDPART is padded with zero bits to - match a full octet boundary. - - An IPv6 AFDPART has a variable length of 0 to 16 octets. - -5. Zone File Syntax - - The textual representation of an APL RR in a DNS zone file is as - follows: - - <owner> IN <TTL> APL {[!]afi:address/prefix}* - - The data consists of zero or more strings of the address family - indicator <afi>, immediately followed by a colon ":", an address, - immediately followed by the "/" character, immediately followed by a - decimal numeric value for the prefix length. Any such string may be - preceded by a "!" character. The strings are separated by - whitespace. The <afi> is the decimal numeric value of that - particular address family. - -5.1. Textual Representation of IPv4 Addresses - - An IPv4 address in the <address> part of an <apitem> is in dotted - quad notation, just as in an A RR. The <prefix> has values from the - interval 0..32 (decimal). - - - - - - - - -Koch Experimental [Page 3] - -RFC 3123 DNS APL RR June 2001 - - -5.2. Textual Representation of IPv6 Addresses - - The representation of an IPv6 address in the <address> part of an - <apitem> follows [RFC2373], section 2.2. Legal values for <prefix> - are from the interval 0..128 (decimal). - -6. APL RR usage - - An APL RR with empty RDATA is valid and implements an empty list. - Multiple occurrences of the same <apitem> in a single APL RR are - allowed and MUST NOT be merged by a DNS server or resolver. - <apitems> MUST be kept in order and MUST NOT be rearranged or - aggregated. - - A single APL RR may contain <apitems> belonging to different address - families. The maximum number of <apitems> is upper bounded by the - available RDATA space. - - RRSets consisting of more than one APL RR are legal but the - interpretation is left to the particular application. - -7. Applicability Statement - - The APL RR defines a framework without specifying any particular - meaning for the list of prefixes. It is expected that APL RRs will - be used in different application scenarios which have to be - documented separately. Those scenarios may be distinguished by - characteristic prefixes placed in front of the DNS owner name. - - An APL application specification MUST include information on - - o the characteristic prefix, if any - - o how to interpret APL RRSets consisting of more than one RR - - o how to interpret an empty APL RR - - o which address families are expected to appear in the APL RRs for - that application - - o how to deal with APL RR list elements which belong to other - address families, including those not yet defined - - o the exact semantics of list elements negated by the "!" character - - - - - - - -Koch Experimental [Page 4] - -RFC 3123 DNS APL RR June 2001 - - - Possible applications include the publication of address ranges - similar to [RFC1101], description of zones built following [RFC2317] - and in-band access control to limit general access or zone transfer - (AXFR) availability for zone data held in DNS servers. - - The specification of particular application scenarios is out of the - scope of this document. - -8. Examples - - The following examples only illustrate some of the possible usages - outlined in the previous section. None of those applications are - hereby specified nor is it implied that any particular APL RR based - application does exist now or will exist in the future. - - ; RFC 1101-like announcement of address ranges for foo.example - foo.example. IN APL 1:192.168.32.0/21 !1:192.168.38.0/28 - - ; CIDR blocks covered by classless delegation - 42.168.192.IN-ADDR.ARPA. IN APL ( 1:192.168.42.0/26 1:192.168.42.64/26 - 1:192.168.42.128/25 ) - - ; Zone transfer restriction - _axfr.sbo.example. IN APL 1:127.0.0.1/32 1:172.16.64.0/22 - - ; List of address ranges for multicast - multicast.example. IN APL 1:224.0.0.0/4 2:FF00:0:0:0:0:0:0:0/8 - - Note that since trailing zeroes are ignored in the first APL RR the - AFDLENGTH of both <apitems> is three. - -9. Security Considerations - - Any information obtained from the DNS should be regarded as unsafe - unless techniques specified in [RFC2535] or [RFC2845] were used. The - definition of a new RR type does not introduce security problems into - the DNS, but usage of information made available by APL RRs may - compromise security. This includes disclosure of network topology - information and in particular the use of APL RRs to construct access - control lists. - - - - - - - - - - - -Koch Experimental [Page 5] - -RFC 3123 DNS APL RR June 2001 - - -10. IANA Considerations - - This section is to be interpreted as following [RFC2434]. - - This document does not define any new namespaces. It uses the 16 bit - identifiers for address families maintained by IANA in - http://www.iana.org/numbers.html. - - The IANA assigned numeric RR type value 42 for APL [IANA]. - -11. Acknowledgements - - The author would like to thank Mark Andrews, Olafur Gudmundsson, Ed - Lewis, Thomas Narten, Erik Nordmark, and Paul Vixie for their review - and constructive comments. - -12. References - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - [RFC1101] Mockapetris, P., "DNS Encoding of Network Names and Other - Types", RFC 1101, April 1989. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2317] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN- - ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998. - - [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 2373, July 1998. - - [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", - BCP 32, RFC 2606, June 1999. - - - -Koch Experimental [Page 6] - -RFC 3123 DNS APL RR June 2001 - - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC - 2845, May 2000. - - [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support - IPv6 Address Aggregation and Renumbering", RFC 2874, July - 2000. - - [IANA] http://www.iana.org/assignments/dns-parameters - -13. Author's Address - - Peter Koch - Universitaet Bielefeld - Technische Fakultaet - D-33594 Bielefeld - Germany - - Phone: +49 521 106 2902 - EMail: pk@TechFak.Uni-Bielefeld.DE - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Koch Experimental [Page 7] - -RFC 3123 DNS APL RR June 2001 - - -14. Full Copyright Statement - - Copyright (C) The Internet Society (2001). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Koch Experimental [Page 8] - diff --git a/contrib/bind9/doc/rfc/rfc3152.txt b/contrib/bind9/doc/rfc/rfc3152.txt deleted file mode 100644 index b226ce6451f9..000000000000 --- a/contrib/bind9/doc/rfc/rfc3152.txt +++ /dev/null @@ -1,227 +0,0 @@ - - - - - - -Network Working Group R. Bush -Request for Comments: 3152 RGnet -BCP: 49 August 2001 -Updates: 2874, 2772, 2766, 2553, 1886 -Category: Best Current Practice - - - Delegation of IP6.ARPA - -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. - -Copyright Notice - - Copyright (C) The Internet Society (2001). All Rights Reserved. - -Abstract - - This document discusses the need for delegation of the IP6.ARPA DNS - zone, and specifies a plan for the technical operation thereof. - -1. Why IP6.ARPA? - - In the IPv6 address space, there is a need for 'reverse mapping' of - addresses to DNS names analogous to that provided by the IN-ADDR.ARPA - zone for IPv4. - - The IAB recommended that the ARPA top level domain (the name is now - considered an acronym for "Address and Routing Parameters Area") be - used for technical infrastructure sub-domains when possible. It is - already in use for IPv4 reverse mapping and has been established as - the location for E.164 numbering on the Internet [RFC2916 RFC3026]. - - IETF consensus was reached that the IP6.ARPA domain be used for - address to DNS name mapping for the IPv6 address space [RFC2874]. - -2. Obsoleted Usage - - This document deprecates references to IP6.INT in [RFC1886] section - 2.5, [RFC2553] section 6.2.3, [RFC2766] section 4.1, [RFC2772] - section 7.1.c, and [RFC2874] section 2.5. - - In this context, 'deprecate' means that the old usage is not - appropriate for new implementations, and IP6.INT will likely be - phased out in an orderly fashion. - - - -Bush Best Current Practice [Page 1] - -RFC 3152 Delegation of IP6.ARPA August 2001 - - -3. IANA Considerations - - This memo requests that the IANA delegate the IP6.ARPA domain - following instructions to be provided by the IAB. Names within this - zone are to be further delegated to the regional IP registries in - accordance with the delegation of IPv6 address space to those - registries. The names allocated should be hierarchic in accordance - with the address space assignment. - -4. Security Considerations - - While DNS spoofing of address to name mapping has been exploited in - IPv4, delegation of the IP6.ARPA zone creates no new threats to the - security of the internet. - -5. References - - [RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP - version 6", RFC 1886, December 1995. - - [RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, - "Basic Socket Interface Extensions for IPv6", RFC 2553, - March 1999. - - [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address - Translation - Protocol Translation (NAT-PT)", RFC 2766, - February 2000. - - [RFC2772] Rockell, R. and R. Fink, "6Bone Backbone Routing - Guidelines", RFC 2772, February 2000. - - [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support - IPv6 Address Aggregation and Renumbering", RFC 2874, July - 2001. - - [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, - September 2000. - - [RFC3026] Blane, R., "Liaison to IETF/ISOC on ENUM", RFC 3026, - January 2001. - - - - - - - - - - - -Bush Best Current Practice [Page 2] - -RFC 3152 Delegation of IP6.ARPA August 2001 - - -6. Author's Address - - Randy Bush - 5147 Crystal Springs - Bainbridge Island, WA US-98110 - - Phone: +1 206 780 0431 - EMail: randy@psg.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Bush Best Current Practice [Page 3] - -RFC 3152 Delegation of IP6.ARPA August 2001 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2001). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Bush Best Current Practice [Page 4] - diff --git a/contrib/bind9/doc/rfc/rfc3197.txt b/contrib/bind9/doc/rfc/rfc3197.txt deleted file mode 100644 index 94cefa4c6b71..000000000000 --- a/contrib/bind9/doc/rfc/rfc3197.txt +++ /dev/null @@ -1,283 +0,0 @@ - - - - - - -Network Working Group R. Austein -Request for Comments: 3197 InterNetShare -Category: Informational November 2001 - - - Applicability Statement for DNS MIB Extensions - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2001). All Rights Reserved. - -Abstract - - This document explains why, after more than six years as proposed - standards, the DNS Server and Resolver MIB extensions were never - deployed, and recommends retiring these MIB extensions by moving them - to Historical status. - -1. History - - The road to the DNS MIB extensions was paved with good intentions. - - In retrospect, it's obvious that the working group never had much - agreement on what belonged in the MIB extensions, just that we should - have some. This happened during the height of the craze for MIB - extensions in virtually every protocol that the IETF was working on - at the time, so the question of why we were doing this in the first - place never got a lot of scrutiny. Very late in the development - cycle we discovered that much of the support for writing the MIB - extensions in the first place had come from people who wanted to use - SNMP SET operations to update DNS zones on the fly. Examination of - the security model involved, however, led us to conclude that this - was not a good way to do dynamic update and that a separate DNS - Dynamic Update protocol would be necessary. - - The MIB extensions started out being fairly specific to one - particular DNS implementation (BIND-4.8.3); as work progressed, the - BIND-specific portions were rewritten to be as implementation-neutral - as we knew how to make them, but somehow every revision of the MIB - extensions managed to create new counters that just happened to - closely match statistics kept by some version of BIND. As a result, - the MIB extensions ended up being much too big, which raised a number - - - -Austein Informational [Page 1] - -RFC 3197 Applicability Statement - DNS MIB Extensions November 2001 - - - of concerns with the network management directorate, but the WG - resisted every attempt to remove any of these variables. In the end, - large portions of the MIB extensions were moved into optional groups - in an attempt to get the required subset down to a manageable size. - - The DNS Server and Resolver MIB extensions were one of the first - attempts to write MIB extensions for a protocol usually considered to - be at the application layer. Fairly early on it became clear that, - while it was certainly possible to write MIB extensions for DNS, the - SMI was not really designed with this sort of thing in mind. A case - in point was the attempt to provide direct indexing into the caches - in the resolver MIB extensions: while arguably the only sane way to - do this for a large cache, this required much more complex indexing - clauses than is usual, and ended up running into known length limits - for object identifiers in some SNMP implementations. - - Furthermore, the lack of either real proxy MIB support in SNMP - managers or a standard subagent protocol meant that there was no - reasonable way to implement the MIB extensions in the dominant - implementation (BIND). When the AgentX subagent protocol was - developed a few years later, we initially hoped that this would - finally clear the way for an implementation of the DNS MIB - extensions, but by the time AgentX was a viable protocol it had - become clear that nobody really wanted to implement these MIB - extensions. - - Finally, the MIB extensions took much too long to produce. In - retrospect, this should have been a clear warning sign, particularly - when the WG had clearly become so tired of the project that the - authors found it impossible to elicit any comments whatsoever on the - documents. - -2. Lessons - - Observations based on the preceding list of mistakes, for the benefit - of anyone else who ever attempts to write DNS MIB extensions again: - - - Define a clear set of goals before writing any MIB extensions. - Know who the constituency is and make sure that what you write - solves their problem. - - - Keep the MIB extensions short, and don't add variables just - because somebody in the WG thinks they'd be a cool thing to - measure. - - - If some portion of the task seems to be very hard to do within the - SMI, that's a strong hint that SNMP is not the right tool for - whatever it is that you're trying to do. - - - -Austein Informational [Page 2] - -RFC 3197 Applicability Statement - DNS MIB Extensions November 2001 - - - - If the entire project is taking too long, perhaps that's a hint - too. - -3. Recommendation - - In view of the community's apparent total lack of interest in - deploying these MIB extensions, we recommend that RFCs 1611 and 1612 - be reclassified as Historical documents. - -4. Security Considerations - - Re-classifying an existing MIB document from Proposed Standard to - Historic should not have any negative impact on security for the - Internet. - -5. IANA Considerations - - Getting rid of the DNS MIB extensions should not impose any new work - on IANA. - -6. Acknowledgments - - The author would like to thank all the people who were involved in - this project over the years for their optimism and patience, - misguided though it may have been. - -7. References - - [DNS-SERVER-MIB] Austein, R. and J. Saperia, "DNS Server MIB - Extensions", RFC 1611, May 1994. - - [DNS-RESOLVER-MIB] Austein, R. and J. Saperia, "DNS Resolver MIB - Extensions", RFC 1612, May 1994. - - [DNS-DYNAMIC-UPDATE] Vixie, P., Thomson, S., Rekhter, Y. and J. - Bound, "Dynamic Updates in the Domain Name - System (DNS UPDATE)", RFC 2136, April 1997. - - [AGENTX] Daniele, M., Wijnen, B., Ellison, M., and D. - Francisco, "Agent Extensibility (AgentX) - Protocol Version 1", RFC 2741, January 2000. - - - - - - - - - - -Austein Informational [Page 3] - -RFC 3197 Applicability Statement - DNS MIB Extensions November 2001 - - -8. Author's Address - - Rob Austein - InterNetShare, Incorporated - 325M Sharon Park Drive, Suite 308 - Menlo Park, CA 94025 - USA - - EMail: sra@hactrn.net - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Informational [Page 4] - -RFC 3197 Applicability Statement - DNS MIB Extensions November 2001 - - -9. Full Copyright Statement - - Copyright (C) The Internet Society (2001). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Austein Informational [Page 5] - diff --git a/contrib/bind9/doc/rfc/rfc3225.txt b/contrib/bind9/doc/rfc/rfc3225.txt deleted file mode 100644 index 13e6768c37a9..000000000000 --- a/contrib/bind9/doc/rfc/rfc3225.txt +++ /dev/null @@ -1,339 +0,0 @@ - - - - - - -Network Working Group D. Conrad -Request for Comments: 3225 Nominum, Inc. -Category: Standards Track December 2001 - - - Indicating Resolver Support of DNSSEC - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2001). All Rights Reserved. - -Abstract - - In order to deploy DNSSEC (Domain Name System Security Extensions) - operationally, DNSSEC aware servers should only perform automatic - inclusion of DNSSEC RRs when there is an explicit indication that the - resolver can understand those RRs. This document proposes the use of - a bit in the EDNS0 header to provide that explicit indication and - describes the necessary protocol changes to implement that - notification. - -1. Introduction - - DNSSEC [RFC2535] has been specified to provide data integrity and - authentication to security aware resolvers and applications through - the use of cryptographic digital signatures. However, as DNSSEC is - deployed, non-DNSSEC-aware clients will likely query DNSSEC-aware - servers. In such situations, the DNSSEC-aware server (responding to - a request for data in a signed zone) will respond with SIG, KEY, - and/or NXT records. For reasons described in the subsequent section, - such responses can have significant negative operational impacts for - the DNS infrastructure. - - This document discusses a method to avoid these negative impacts, - namely DNSSEC-aware servers should only respond with SIG, KEY, and/or - NXT RRs when there is an explicit indication from the resolver that - it can understand those RRs. - - For the purposes of this document, "DNSSEC security RRs" are - considered RRs of type SIG, KEY, or NXT. - - - -Conrad Standards Track [Page 1] - -RFC 3225 Indicating Resolver Support of DNSSEC December 2001 - - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - -2. Rationale - - Initially, as DNSSEC is deployed, the vast majority of queries will - be from resolvers that are not DNSSEC aware and thus do not - understand or support the DNSSEC security RRs. When a query from - such a resolver is received for a DNSSEC signed zone, the DNSSEC - specification indicates the nameserver must respond with the - appropriate DNSSEC security RRs. As DNS UDP datagrams are limited to - 512 bytes [RFC1035], responses including DNSSEC security RRs have a - high probability of resulting in a truncated response being returned - and the resolver retrying the query using TCP. - - TCP DNS queries result in significant overhead due to connection - setup and teardown. Operationally, the impact of these TCP queries - will likely be quite detrimental in terms of increased network - traffic (typically five packets for a single query/response instead - of two), increased latency resulting from the additional round trip - times, increased incidences of queries failing due to timeouts, and - significantly increased load on nameservers. - - In addition, in preliminary and experimental deployment of DNSSEC, - there have been reports of non-DNSSEC aware resolvers being unable to - handle responses which contain DNSSEC security RRs, resulting in the - resolver failing (in the worst case) or entire responses being - ignored (in the better case). - - Given these operational implications, explicitly notifying the - nameserver that the client is prepared to receive (if not understand) - DNSSEC security RRs would be prudent. - - Client-side support of DNSSEC is assumed to be binary -- either the - client is willing to receive all DNSSEC security RRs or it is not - willing to accept any. As such, a single bit is sufficient to - indicate client-side DNSSEC support. As effective use of DNSSEC - implies the need of EDNS0 [RFC2671], bits in the "classic" (non-EDNS - enhanced DNS header) are scarce, and there may be situations in which - non-compliant caching or forwarding servers inappropriately copy data - from classic headers as queries are passed on to authoritative - servers, the use of a bit from the EDNS0 header is proposed. - - An alternative approach would be to use the existence of an EDNS0 - header as an implicit indication of client-side support of DNSSEC. - This approach was not chosen as there may be applications in which - EDNS0 is supported but in which the use of DNSSEC is inappropriate. - - - -Conrad Standards Track [Page 2] - -RFC 3225 Indicating Resolver Support of DNSSEC December 2001 - - -3. Protocol Changes - - The mechanism chosen for the explicit notification of the ability of - the client to accept (if not understand) DNSSEC security RRs is using - the most significant bit of the Z field on the EDNS0 OPT header in - the query. This bit is referred to as the "DNSSEC OK" (DO) bit. In - the context of the EDNS0 OPT meta-RR, the DO bit is the first bit of - the third and fourth bytes of the "extended RCODE and flags" portion - of the EDNS0 OPT meta-RR, structured as follows: - - +0 (MSB) +1 (LSB) - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 0: | EXTENDED-RCODE | VERSION | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 2: |DO| Z | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - Setting the DO bit to one in a query indicates to the server that the - resolver is able to accept DNSSEC security RRs. The DO bit cleared - (set to zero) indicates the resolver is unprepared to handle DNSSEC - security RRs and those RRs MUST NOT be returned in the response - (unless DNSSEC security RRs are explicitly queried for). The DO bit - of the query MUST be copied in the response. - - More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY, - or NXT RRs to authenticate a response as specified in [RFC2535] - unless the DO bit was set on the request. Security records that - match an explicit SIG, KEY, NXT, or ANY query, or are part of the - zone data for an AXFR or IXFR query, are included whether or not the - DO bit was set. - - A recursive DNSSEC-aware server MUST set the DO bit on recursive - requests, regardless of the status of the DO bit on the initiating - resolver request. If the initiating resolver request does not have - the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC - security RRs before returning the data to the client, however cached - data MUST NOT be modified. - - In the event a server returns a NOTIMP, FORMERR or SERVFAIL response - to a query that has the DO bit set, the resolver SHOULD NOT expect - DNSSEC security RRs and SHOULD retry the query without EDNS0 in - accordance with section 5.3 of [RFC2671]. - - - - - - - - - -Conrad Standards Track [Page 3] - -RFC 3225 Indicating Resolver Support of DNSSEC December 2001 - - -Security Considerations - - The absence of DNSSEC data in response to a query with the DO bit set - MUST NOT be taken to mean no security information is available for - that zone as the response may be forged or a non-forged response of - an altered (DO bit cleared) query. - -IANA Considerations - - EDNS0 [RFC2671] defines 16 bits as extended flags in the OPT record, - these bits are encoded into the TTL field of the OPT record (RFC2671 - section 4.6). - - This document reserves one of these bits as the OK bit. It is - requested that the left most bit be allocated. Thus the USE of the - OPT record TTL field would look like - - +0 (MSB) +1 (LSB) - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 0: | EXTENDED-RCODE | VERSION | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - 2: |DO| Z | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -Acknowledgements - - This document is based on a rough draft by Bob Halley with input from - Olafur Gudmundsson, Andreas Gustafsson, Brian Wellington, Randy Bush, - Rob Austein, Steve Bellovin, and Erik Nordmark. - -References - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specifications", STD 13, RFC 1035, November 1987. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - - - - -Conrad Standards Track [Page 4] - -RFC 3225 Indicating Resolver Support of DNSSEC December 2001 - - -Author's Address - - David Conrad - Nominum Inc. - 950 Charter Street - Redwood City, CA 94063 - USA - - Phone: +1 650 381 6003 - EMail: david.conrad@nominum.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Conrad Standards Track [Page 5] - -RFC 3225 Indicating Resolver Support of DNSSEC December 2001 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2001). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Conrad Standards Track [Page 6] - diff --git a/contrib/bind9/doc/rfc/rfc3226.txt b/contrib/bind9/doc/rfc/rfc3226.txt deleted file mode 100644 index dac0e11c1575..000000000000 --- a/contrib/bind9/doc/rfc/rfc3226.txt +++ /dev/null @@ -1,339 +0,0 @@ - - - - - - -Network Working Group O. Gudmundsson -Request for Comments: 3226 December 2001 -Updates: 2874, 2535 -Category: Standards Track - - - DNSSEC and IPv6 A6 aware server/resolver message size requirements - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2001). All Rights Reserved. - -Abstract - - This document mandates support for EDNS0 (Extension Mechanisms for - DNS) in DNS entities claiming to support either DNS Security - Extensions or A6 records. This requirement is necessary because - these new features increase the size of DNS messages. If EDNS0 is - not supported fall back to TCP will happen, having a detrimental - impact on query latency and DNS server load. This document updates - RFC 2535 and RFC 2874, by adding new requirements. - -1. Introduction - - Familiarity with the DNS [RFC1034, RFC1035], DNS Security Extensions - [RFC2535], EDNS0 [RFC2671] and A6 [RFC2874] is helpful. - - STD 13, RFC 1035 Section 2.3.4 requires that DNS messages over UDP - have a data payload of 512 octets or less. Most DNS software today - will not accept larger UDP datagrams. Any answer that requires more - than 512 octets, results in a partial and sometimes useless reply - with the Truncation Bit set; in most cases the requester will then - retry using TCP. Furthermore, server delivery of truncated responses - varies widely and resolver handling of these responses also varies, - leading to additional inefficiencies in handling truncation. - - Compared to UDP, TCP is an expensive protocol to use for a simple - transaction like DNS: a TCP connection requires 5 packets for setup - and tear down, excluding data packets, thus requiring at least 3 - round trips on top of the one for the original UDP query. The DNS - - - -Gudmundsson Standards Track [Page 1] - -RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 - - - server also needs to keep a state of the connection during this - transaction. Many DNS servers answer thousands of queries per - second, requiring them to use TCP will cause significant overhead and - delays. - -1.1. Requirements - - The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" - in this document are to be interpreted as described in RFC 2119. - -2. Motivating factors - -2.1. DNSSEC motivations - - DNSSEC [RFC2535] secures DNS by adding a Public Key signature on each - RR set. These signatures range in size from about 80 octets to 800 - octets, most are going to be in the range of 80 to 200 octets. The - addition of signatures on each or most RR sets in an answer - significantly increases the size of DNS answers from secure zones. - - For performance reasons and to reduce load on DNS servers, it is - important that security aware servers and resolvers get all the data - in Answer and Authority section in one query without truncation. - Sending Additional Data in the same query is helpful when the server - is authoritative for the data, and this reduces round trips. - - DNSSEC OK[OK] specifies how a client can, using EDNS0, indicate that - it is interested in receiving DNSSEC records. The OK bit does not - eliminate the need for large answers for DNSSEC capable clients. - -2.1.1. Message authentication or TSIG motivation - - TSIG [RFC2845] allows for the light weight authentication of DNS - messages, but increases the size of the messages by at least 70 - octets. DNSSEC specifies for computationally expensive message - authentication SIG(0) using a standard public key signature. As only - one TSIG or SIG(0) can be attached to each DNS answer the size - increase of message authentication is not significant, but may still - lead to a truncation. - -2.2. IPv6 Motivations - - IPv6 addresses [RFC2874] are 128 bits and can be represented in the - DNS by multiple A6 records, each consisting of a domain name and a - bit field. The domain name refers to an address prefix that may - require additional A6 RRs to be included in the answer. Answers - where the queried name has multiple A6 addresses may overflow a 512- - octet UDP packet size. - - - -Gudmundsson Standards Track [Page 2] - -RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 - - -2.3. Root server and TLD server motivations - - The current number of root servers is limited to 13 as that is the - maximum number of name servers and their address records that fit in - one 512-octet answer for a SOA record. If root servers start - advertising A6 or KEY records then the answer for the root NS records - will not fit in a single 512-octet DNS message, resulting in a large - number of TCP query connections to the root servers. Even if all - client resolver query their local name server for information, there - are millions of these servers. Each name server must periodically - update its information about the high level servers. - - For redundancy, latency and load balancing reasons, large numbers of - DNS servers are required for some zones. Since the root zone is used - by the entire net, it is important to have as many servers as - possible. Large TLDs (and many high-visibility SLDs) often have - enough servers that either A6 or KEY records would cause the NS - response to overflow the 512 byte limit. Note that these zones with - large numbers of servers are often exactly those zones that are - critical to network operation and that already sustain fairly high - loads. - -2.4. UDP vs TCP for DNS messages - - Given all these factors, it is essential that any implementation that - supports DNSSEC and or A6 be able to use larger DNS messages than 512 - octets. - - The original 512 restriction was put in place to reduce the - probability of fragmentation of DNS responses. A fragmented UDP - message that suffers a loss of one of the fragments renders the - answer useless and the query must be retried. A TCP connection - requires a larger number of round trips for establishment, data - transfer and tear down, but only the lost data segments are - retransmitted. - - In the early days a number of IP implementations did not handle - fragmentation well, but all modern operating systems have overcome - that issue thus sending fragmented messages is fine from that - standpoint. The open issue is the effect of losses on fragmented - messages. If connection has high loss ratio only TCP will allow - reliable transfer of DNS data, most links have low loss ratios thus - sending fragmented UDP packet in one round trip is better than - establishing a TCP connection to transfer a few thousand octets. - - - - - - - -Gudmundsson Standards Track [Page 3] - -RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 - - -2.5. EDNS0 and large UDP messages - - EDNS0 [RFC2671] allows clients to declare the maximum size of UDP - message they are willing to handle. Thus, if the expected answer is - between 512 octets and the maximum size that the client can accept, - the additional overhead of a TCP connection can be avoided. - -3. Protocol changes: - - This document updates RFC 2535 and RFC 2874, by adding new - requirements. - - All RFC 2535 compliant servers and resolvers MUST support EDNS0 and - advertise message size of at least 1220 octets, but SHOULD advertise - message size of 4000. This value might be too low to get full - answers for high level servers and successor of this document may - require a larger value. - - All RFC 2874 compliant servers and resolver MUST support EDNS0 and - advertise message size of at least 1024 octets, but SHOULD advertise - message size of 2048. The IPv6 datagrams should be 1024 octets, - unless the MTU of the path is known. (Note that this is smaller than - the minimum IPv6 MTU to allow for some extension headers and/or - encapsulation without exceeding the minimum MTU.) - - All RFC 2535 and RFC 2874 compliant entities MUST be able to handle - fragmented IPv4 and IPv6 UDP packets. - - All hosts supporting both RFC 2535 and RFC 2874 MUST use the larger - required value in EDNS0 advertisements. - -4. Acknowledgments - - Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas - Gustafsson, Jun-ichiro itojun Hagino, Bob Halley, Edward Lewis - Michael Patton and Kazu Yamamoto were instrumental in motivating and - shaping this document. - -5. Security Considerations: - - There are no additional security considerations other than those in - RFC 2671. - -6. IANA Considerations: - - None - - - - - -Gudmundsson Standards Track [Page 4] - -RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 - - -7. References - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - [RFC2535] Eastlake, D. "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support - IPv6 Address Aggregation and Renumbering", RFC 2874, July - 2000. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC - 3225, December 2001. - -8. Author Address - - Olafur Gudmundsson - 3826 Legation Street, NW - Washington, DC 20015 - USA - - EMail: ogud@ogud.com - - - - - - - - - - - - - - - - - - -Gudmundsson Standards Track [Page 5] - -RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 - - -9. Full Copyright Statement - - Copyright (C) The Internet Society (2001). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Gudmundsson Standards Track [Page 6] - diff --git a/contrib/bind9/doc/rfc/rfc3258.txt b/contrib/bind9/doc/rfc/rfc3258.txt deleted file mode 100644 index dcd4b34b2b6e..000000000000 --- a/contrib/bind9/doc/rfc/rfc3258.txt +++ /dev/null @@ -1,619 +0,0 @@ - - - - - - -Network Working Group T. Hardie -Request for Comments: 3258 Nominum, Inc. -Category: Informational April 2002 - - - Distributing Authoritative Name Servers via Shared Unicast Addresses - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2002). All Rights Reserved. - -Abstract - - This memo describes a set of practices intended to enable an - authoritative name server operator to provide access to a single - named server in multiple locations. The primary motivation for the - development and deployment of these practices is to increase the - distribution of Domain Name System (DNS) servers to previously - under-served areas of the network topology and to reduce the latency - for DNS query responses in those areas. - -1. Introduction - - This memo describes a set of practices intended to enable an - authoritative name server operator to provide access to a single - named server in multiple locations. The primary motivation for the - development and deployment of these practices is to increase the - distribution of DNS servers to previously under-served areas of the - network topology and to reduce the latency for DNS query responses in - those areas. This document presumes a one-to-one mapping between - named authoritative servers and administrative entities (operators). - This document contains no guidelines or recommendations for caching - name servers. The shared unicast system described here is specific - to IPv4; applicability to IPv6 is an area for further study. It - should also be noted that the system described here is related to - that described in [ANYCAST], but it does not require dedicated - address space, routing changes, or the other elements of a full - anycast infrastructure which that document describes. - - - - - - - -Hardie Informational [Page 1] - -RFC 3258 Distributing Authoritative Name Servers April 2002 - - -2. Architecture - -2.1 Server Requirements - - Operators of authoritative name servers may wish to refer to - [SECONDARY] and [ROOT] for general guidance on appropriate practice - for authoritative name servers. In addition to proper configuration - as a standard authoritative name server, each of the hosts - participating in a shared-unicast system should be configured with - two network interfaces. These interfaces may be either two physical - interfaces or one physical interface mapped to two logical - interfaces. One of the network interfaces should use the IPv4 shared - unicast address associated with the authoritative name server. The - other interface, referred to as the administrative interface below, - should use a distinct IPv4 address specific to that host. The host - should respond to DNS queries only on the shared-unicast interface. - In order to provide the most consistent set of responses from the - mesh of anycast hosts, it is good practice to limit responses on that - interface to zones for which the host is authoritative. - -2.2 Zone file delivery - - In order to minimize the risk of man-in-the-middle attacks, zone - files should be delivered to the administrative interface of the - servers participating in the mesh. Secure file transfer methods and - strong authentication should be used for all transfers. If the hosts - in the mesh make their zones available for zone transfer, the - administrative interfaces should be used for those transfers as well, - in order to avoid the problems with potential routing changes for TCP - traffic noted in section 2.5 below. - -2.3 Synchronization - - Authoritative name servers may be loosely or tightly synchronized, - depending on the practices set by the operating organization. As - noted below in section 4.1.2, lack of synchronization among servers - using the same shared unicast address could create problems for some - users of this service. In order to minimize that risk, switch-overs - from one data set to another data set should be coordinated as much - as possible. The use of synchronized clocks on the participating - hosts and set times for switch-overs provides a basic level of - coordination. A more complete coordination process would involve: - - a) receipt of zones at a distribution host - b) confirmation of the integrity of zones received - c) distribution of the zones to all of the servers in the mesh - d) confirmation of the integrity of the zones at each server - - - - -Hardie Informational [Page 2] - -RFC 3258 Distributing Authoritative Name Servers April 2002 - - - e) coordination of the switchover times for the servers in the - mesh - f) institution of a failure process to ensure that servers that - did not receive correct data or could not switchover to the new - data ceased to respond to incoming queries until the problem - could be resolved. - - Depending on the size of the mesh, the distribution host may also be - a participant; for authoritative servers, it may also be the host on - which zones are generated. - - This document presumes that the usual DNS failover methods are the - only ones used to ensure reachability of the data for clients. It - does not advise that the routes be withdrawn in the case of failure; - it advises instead that the DNS process shutdown so that servers on - other addresses are queried. This recommendation reflects a choice - between performance and operational complexity. While it would be - possible to have some process withdraw the route for a specific - server instance when it is not available, there is considerable - operational complexity involved in ensuring that this occurs - reliably. Given the existing DNS failover methods, the marginal - improvement in performance will not be sufficient to justify the - additional complexity for most uses. - -2.4 Server Placement - - Though the geographic diversity of server placement helps reduce the - effects of service disruptions due to local problems, it is diversity - of placement in the network topology which is the driving force - behind these distribution practices. Server placement should - emphasize that diversity. Ideally, servers should be placed - topologically near the points at which the operator exchanges routes - and traffic with other networks. - -2.5 Routing - - The organization administering the mesh of servers sharing a unicast - address must have an autonomous system number and speak BGP to its - peers. To those peers, the organization announces a route to the - network containing the shared-unicast address of the name server. - The organization's border routers must then deliver the traffic - destined for the name server to the nearest instantiation. Routing - to the administrative interfaces for the servers can use the normal - routing methods for the administering organization. - - One potential problem with using shared unicast addresses is that - routers forwarding traffic to them may have more than one available - route, and those routes may, in fact, reach different instances of - - - -Hardie Informational [Page 3] - -RFC 3258 Distributing Authoritative Name Servers April 2002 - - - the shared unicast address. Applications like the DNS, whose - communication typically consists of independent request-response - messages each fitting in a single UDP packet present no problem. - Other applications, in which multiple packets must reach the same - endpoint (e.g., TCP) may fail or present unworkable performance - characteristics in some circumstances. Split-destination failures - may occur when a router does per-packet (or round-robin) load - sharing, a topology change occurs that changes the relative metrics - of two paths to the same anycast destination, etc. - - Four things mitigate the severity of this problem. The first is that - UDP is a fairly high proportion of the query traffic to name servers. - The second is that the aim of this proposal is to diversify - topological placement; for most users, this means that the - coordination of placement will ensure that new instances of a name - server will be at a significantly different cost metric from existing - instances. Some set of users may end up in the middle, but that - should be relatively rare. The third is that per packet load sharing - is only one of the possible load sharing mechanisms, and other - mechanisms are increasing in popularity. - - Lastly, in the case where the traffic is TCP, per packet load sharing - is used, and equal cost routes to different instances of a name - server are available, any DNS implementation which measures the - performance of servers to select a preferred server will quickly - prefer a server for which this problem does not occur. For the DNS - failover mechanisms to reliably avoid this problem, however, those - using shared unicast distribution mechanisms must take care that all - of the servers for a specific zone are not participants in the same - shared-unicast mesh. To guard even against the case where multiple - meshes have a set of users affected by per packet load sharing along - equal cost routes, organizations implementing these practices should - always provide at least one authoritative server which is not a - participant in any shared unicast mesh. Those deploying shared- - unicast meshes should note that any specific host may become - unreachable to a client should a server fail, a path fail, or the - route to that host be withdrawn. These error conditions are, - however, not specific to shared-unicast distributions, but would - occur for standard unicast hosts. - - Since ICMP response packets might go to a different member of the - mesh than that sending a packet, packets sent with a shared unicast - source address should also avoid using path MTU discovery. - - Appendix A. contains an ASCII diagram of an example of a simple - implementation of this system. In it, the odd numbered routers - deliver traffic to the shared-unicast interface network and filter - traffic from the administrative network; the even numbered routers - - - -Hardie Informational [Page 4] - -RFC 3258 Distributing Authoritative Name Servers April 2002 - - - deliver traffic to the administrative network and filter traffic from - the shared-unicast network. These are depicted as separate routers - for the ease this gives in explanation, but they could easily be - separate interfaces on the same router. Similarly, a local NTP - source is depicted for synchronization, but the level of - synchronization needed would not require that source to be either - local or a stratum one NTP server. - -3. Administration - -3.1 Points of Contact - - A single point of contact for reporting problems is crucial to the - correct administration of this system. If an external user of the - system needs to report a problem related to the service, there must - be no ambiguity about whom to contact. If internal monitoring does - not indicate a problem, the contact may, of course, need to work with - the external user to identify which server generated the error. - -4. Security Considerations - - As a core piece of Internet infrastructure, authoritative name - servers are common targets of attack. The practices outlined here - increase the risk of certain kinds of attacks and reduce the risk of - others. - -4.1 Increased Risks - -4.1.1 Increase in physical servers - - The architecture outlined in this document increases the number of - physical servers, which could increase the possibility that a server - mis-configuration will occur which allows for a security breach. In - general, the entity administering a mesh should ensure that patches - and security mechanisms applied to a single member of the mesh are - appropriate for and applied to all of the members of a mesh. - "Genetic diversity" (code from different code bases) can be a useful - security measure in avoiding attacks based on vulnerabilities in a - specific code base; in order to ensure consistency of responses from - a single named server, however, that diversity should be applied to - different shared-unicast meshes or between a mesh and a related - unicast authoritative server. - -4.1.2 Data synchronization problems - - The level of systemic synchronization described above should be - augmented by synchronization of the data present at each of the - servers. While the DNS itself is a loosely coupled system, debugging - - - -Hardie Informational [Page 5] - -RFC 3258 Distributing Authoritative Name Servers April 2002 - - - problems with data in specific zones would be far more difficult if - two different servers sharing a single unicast address might return - different responses to the same query. For example, if the data - associated with www.example.com has changed and the administrators of - the domain are testing for the changes at the example.com - authoritative name servers, they should not need to check each - instance of a named authoritative server. The use of NTP to provide - a synchronized time for switch-over eliminates some aspects of this - problem, but mechanisms to handle failure during the switchover are - required. In particular, a server which cannot make the switchover - must not roll-back to a previous version; it must cease to respond to - queries so that other servers are queried. - -4.1.3 Distribution risks - - If the mechanism used to distribute zone files among the servers is - not well secured, a man-in-the-middle attack could result in the - injection of false information. Digital signatures will alleviate - this risk, but encrypted transport and tight access lists are a - necessary adjunct to them. Since zone files will be distributed to - the administrative interfaces of meshed servers, the access control - list for distribution of the zone files should include the - administrative interface of the server or servers, rather than their - shared unicast addresses. - -4.2 Decreased Risks - - The increase in number of physical servers reduces the likelihood - that a denial-of-service attack will take out a significant portion - of the DNS infrastructure. The increase in servers also reduces the - effect of machine crashes, fiber cuts, and localized disasters by - reducing the number of users dependent on a specific machine. - -5. Acknowledgments - - Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak, - Mark Andrews, Robert Elz, Geoff Huston, Bill Norton, Akira Kato, - Suzanne Woolf, Bernard Aboba, Casey Ajalat, and Gunnar Lindberg all - provided input and commentary on this work. The editor wishes to - remember in particular the contribution of the late Scott Tucker, - whose extensive systems experience and plain common sense both - contributed greatly to the editor's own deployment experience and are - missed by all who knew him. - - - - - - - - -Hardie Informational [Page 6] - -RFC 3258 Distributing Authoritative Name Servers April 2002 - - -6. References - - [SECONDARY] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection - and Operation of Secondary DNS Servers", BCP 16, RFC - 2182, July 1997. - - [ROOT] Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root - Name Server Operational Requirements", BCP 40, RFC 2870, - June 2000. - - [ANYCAST] Patridge, C., Mendez, T. and W. Milliken, "Host - Anycasting Service", RFC 1546, November 1993. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hardie Informational [Page 7] - -RFC 3258 Distributing Authoritative Name Servers April 2002 - - -Appendix A. - - __________________ -Peer 1-| | -Peer 2-| | -Peer 3-| Switch | -Transit| | _________ _________ -etc | |--|Router1|---|----|----------|Router2|---WAN-| - | | --------- | | --------- | - | | | | | - | | | | | - ------------------ [NTP] [DNS] | - | - | - | - | - __________________ | -Peer 1-| | | -Peer 2-| | | -Peer 3-| Switch | | -Transit| | _________ _________ | -etc | |--|Router3|---|----|----------|Router4|---WAN-| - | | --------- | | --------- | - | | | | | - | | | | | - ------------------ [NTP] [DNS] | - | - | - | - | - __________________ | -Peer 1-| | | -Peer 2-| | | -Peer 3-| Switch | | -Transit| | _________ _________ | -etc | |--|Router5|---|----|----------|Router6|---WAN-| - | | --------- | | --------- | - | | | | | - | | | | | - ------------------ [NTP] [DNS] | - | - | - | - - - - - - - - -Hardie Informational [Page 8] - -RFC 3258 Distributing Authoritative Name Servers April 2002 - - - | - __________________ | -Peer 1-| | | -Peer 2-| | | -Peer 3-| Switch | | -Transit| | _________ _________ | -etc | |--|Router7|---|----|----------|Router8|---WAN-| - | | --------- | | --------- - | | | | - | | | | - ------------------ [NTP] [DNS] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hardie Informational [Page 9] - -RFC 3258 Distributing Authoritative Name Servers April 2002 - - -7. Editor's Address - - Ted Hardie - Nominum, Inc. - 2385 Bay Road. - Redwood City, CA 94063 - - Phone: 1.650.381.6226 - EMail: Ted.Hardie@nominum.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hardie Informational [Page 10] - -RFC 3258 Distributing Authoritative Name Servers April 2002 - - -8. Full Copyright Statement - - Copyright (C) The Internet Society (2002). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Hardie Informational [Page 11] - diff --git a/contrib/bind9/doc/rfc/rfc3363.txt b/contrib/bind9/doc/rfc/rfc3363.txt deleted file mode 100644 index 9d7a39c208cb..000000000000 --- a/contrib/bind9/doc/rfc/rfc3363.txt +++ /dev/null @@ -1,339 +0,0 @@ - - - - - - -Network Working Group R. Bush -Request for Comments: 3363 A. Durand -Updates: 2673, 2874 B. Fink -Category: Informational O. Gudmundsson - T. Hain - Editors - August 2002 - - - Representing Internet Protocol version 6 (IPv6) - Addresses in the Domain Name System (DNS) - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2002). All Rights Reserved. - -Abstract - - This document clarifies and updates the standards status of RFCs that - define direct and reverse map of IPv6 addresses in DNS. This - document moves the A6 and Bit label specifications to experimental - status. - -1. Introduction - - The IETF had begun the process of standardizing two different address - formats for IPv6 addresses AAAA [RFC1886] and A6 [RFC2874] and both - are at proposed standard. This had led to confusion and conflicts on - which one to deploy. It is important for deployment that any - confusion in this area be cleared up, as there is a feeling in the - community that having more than one choice will lead to delays in the - deployment of IPv6. The goal of this document is to clarify the - situation. - - This document also discusses issues relating to the usage of Binary - Labels [RFC 2673] to support the reverse mapping of IPv6 addresses. - - This document is based on extensive technical discussion on various - relevant working groups mailing lists and a joint DNSEXT and NGTRANS - meeting at the 51st IETF in August 2001. This document attempts to - capture the sense of the discussions and reflect them in this - document to represent the consensus of the community. - - - -Bush, et. al. Informational [Page 1] - -RFC 3363 Representation of IPv6 Addresses in DNS August 2002 - - - The main arguments and the issues are covered in a separate document - [RFC3364] that reflects the current understanding of the issues. - This document summarizes the outcome of these discussions. - - The issue of the root of reverse IPv6 address map is outside the - scope of this document and is covered in a different document - [RFC3152]. - -1.1 Standards Action Taken - - This document changes the status of RFCs 2673 and 2874 from Proposed - Standard to Experimental. - -2. IPv6 Addresses: AAAA RR vs A6 RR - - Working group consensus as perceived by the chairs of the DNSEXT and - NGTRANS working groups is that: - - a) AAAA records are preferable at the moment for production - deployment of IPv6, and - - b) that A6 records have interesting properties that need to be better - understood before deployment. - - c) It is not known if the benefits of A6 outweigh the costs and - risks. - -2.1 Rationale - - There are several potential issues with A6 RRs that stem directly - from the feature that makes them different from AAAA RRs: the ability - to build up addresses via chaining. - - Resolving a chain of A6 RRs involves resolving a series of what are - nearly-independent queries. Each of these sub-queries takes some - non-zero amount of time, unless the answer happens to be in the - resolver's local cache already. Other things being equal, we expect - that the time it takes to resolve an N-link chain of A6 RRs will be - roughly proportional to N. What data we have suggests that users are - already impatient with the length of time it takes to resolve A RRs - in the IPv4 Internet, which suggests that users are not likely to be - patient with significantly longer delays in the IPv6 Internet, but - terminating queries prematurely is both a waste of resources and - another source of user frustration. Thus, we are forced to conclude - that indiscriminate use of long A6 chains is likely to lead to - increased user frustration. - - - - - -Bush, et. al. Informational [Page 2] - -RFC 3363 Representation of IPv6 Addresses in DNS August 2002 - - - The probability of failure during the process of resolving an N-link - A6 chain also appears to be roughly proportional to N, since each of - the queries involved in resolving an A6 chain has roughly the same - probability of failure as a single AAAA query. - - Last, several of the most interesting potential applications for A6 - RRs involve situations where the prefix name field in the A6 RR - points to a target that is not only outside the DNS zone containing - the A6 RR, but is administered by a different organization entirely. - While pointers out of zone are not a problem per se, experience both - with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that - pointers to other organizations are often not maintained properly, - perhaps because they're less susceptible to automation than pointers - within a single organization would be. - -2.2 Recommended Standard Action - - Based on the perceived consensus, this document recommends that RFC - 1886 stay on standards track and be advanced, while moving RFC 2874 - to Experimental status. - -3. Bitlabels in the Reverse DNS Tree - - RFC 2673 defines a new DNS label type. This was the first new type - defined since RFC 1035 [RFC1035]. Since the development of 2673 it - has been learned that deployment of a new type is difficult since DNS - servers that do not support bitlabels reject queries containing bit - labels as being malformed. The community has also indicated that - this new label type is not needed for mapping reverse addresses. - -3.1 Rationale - - The hexadecimal text representation of IPv6 addresses appears to be - capable of expressing all of the delegation schemes that we expect to - be used in the DNS reverse tree. - -3.2 Recommended Standard Action - - RFC 2673 standard status is to be changed from Proposed to - Experimental. Future standardization of these documents is to be - done by the DNSEXT working group or its successor. - - - - - - - - - - -Bush, et. al. Informational [Page 3] - -RFC 3363 Representation of IPv6 Addresses in DNS August 2002 - - -4. DNAME in IPv6 Reverse Tree - - The issues for DNAME in the reverse mapping tree appears to be - closely tied to the need to use fragmented A6 in the main tree: if - one is necessary, so is the other, and if one isn't necessary, the - other isn't either. Therefore, in moving RFC 2874 to experimental, - the intent of this document is that use of DNAME RRs in the reverse - tree be deprecated. - -5. Acknowledgments - - This document is based on input from many members of the various IETF - working groups involved in this issues. Special thanks go to the - people that prepared reading material for the joint DNSEXT and - NGTRANS working group meeting at the 51st IETF in London, Rob - Austein, Dan Bernstein, Matt Crawford, Jun-ichiro itojun Hagino, - Christian Huitema. Number of other people have made number of - comments on mailing lists about this issue including Andrew W. - Barclay, Robert Elz, Johan Ihren, Edward Lewis, Bill Manning, Pekka - Savola, Paul Vixie. - -6. Security Considerations - - As this document specifies a course of action, there are no direct - security considerations. There is an indirect security impact of the - choice, in that the relationship between A6 and DNSSEC is not well - understood throughout the community, while the choice of AAAA does - leads to a model for use of DNSSEC in IPv6 networks which parallels - current IPv4 practice. - -7. IANA Considerations - - None. - -Normative References - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - [RFC1886] Thompson, S. and C. Huitema, "DNS Extensions to support IP - version 6", RFC 1886, December 1995. - - [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", - RFC 2673, August 1999. - - [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support - IPv6 Address Aggregation and Renumbering", RFC 2874, July - 2000. - - - -Bush, et. al. Informational [Page 4] - -RFC 3363 Representation of IPv6 Addresses in DNS August 2002 - - - [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152 - August 2001. - -Informative References - - [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) - Support for Internet Protocol version 6 (IPv6)", RFC 3364, - August 2002. - -Editors' Addresses - - Randy Bush - EMail: randy@psg.com - - - Alain Durand - EMail: alain.durand@sun.com - - - Bob Fink - EMail: fink@es.net - - - Olafur Gudmundsson - EMail: ogud@ogud.com - - - Tony Hain - EMail: hain@tndh.net - - - - - - - - - - - - - - - - - - - - - - -Bush, et. al. Informational [Page 5] - -RFC 3363 Representation of IPv6 Addresses in DNS August 2002 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2002). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Bush, et. al. Informational [Page 6] - diff --git a/contrib/bind9/doc/rfc/rfc3364.txt b/contrib/bind9/doc/rfc/rfc3364.txt deleted file mode 100644 index 189c0d2aa055..000000000000 --- a/contrib/bind9/doc/rfc/rfc3364.txt +++ /dev/null @@ -1,619 +0,0 @@ - - - - - - -Network Working Group R. Austein -Request for Comments: 3364 Bourgeois Dilettant -Updates: 2673, 2874 August 2002 -Category: Informational - - - Tradeoffs in Domain Name System (DNS) Support - for Internet Protocol version 6 (IPv6) - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2002). All Rights Reserved. - -Abstract - - The IETF has two different proposals on the table for how to do DNS - support for IPv6, and has thus far failed to reach a clear consensus - on which approach is better. This note attempts to examine the pros - and cons of each approach, in the hope of clarifying the debate so - that we can reach closure and move on. - -Introduction - - RFC 1886 [RFC1886] specified straightforward mechanisms to support - IPv6 addresses in the DNS. These mechanisms closely resemble the - mechanisms used to support IPv4, with a minor improvement to the - reverse mapping mechanism based on experience with CIDR. RFC 1886 is - currently listed as a Proposed Standard. - - RFC 2874 [RFC2874] specified enhanced mechanisms to support IPv6 - addresses in the DNS. These mechanisms provide new features that - make it possible for an IPv6 address stored in the DNS to be broken - up into multiple DNS resource records in ways that can reflect the - network topology underlying the address, thus making it possible for - the data stored in the DNS to reflect certain kinds of network - topology changes or routing architectures that are either impossible - or more difficult to represent without these mechanisms. RFC 2874 is - also currently listed as a Proposed Standard. - - - - - - - -Austein Informational [Page 1] - -RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 - - - Both of these Proposed Standards were the output of the IPNG Working - Group. Both have been implemented, although implementation of - [RFC1886] is more widespread, both because it was specified earlier - and because it's simpler to implement. - - There's little question that the mechanisms proposed in [RFC2874] are - more general than the mechanisms proposed in [RFC1886], and that - these enhanced mechanisms might be valuable if IPv6's evolution goes - in certain directions. The questions are whether we really need the - more general mechanism, what new usage problems might come along with - the enhanced mechanisms, and what effect all this will have on IPv6 - deployment. - - The one thing on which there does seem to be widespread agreement is - that we should make up our minds about all this Real Soon Now. - -Main Advantages of Going with A6 - - While the A6 RR proposed in [RFC2874] is very general and provides a - superset of the functionality provided by the AAAA RR in [RFC1886], - many of the features of A6 can also be implemented with AAAA RRs via - preprocessing during zone file generation. - - There is one specific area where A6 RRs provide something that cannot - be provided using AAAA RRs: A6 RRs can represent addresses in which a - prefix portion of the address can change without any action (or - perhaps even knowledge) by the parties controlling the DNS zone - containing the terminal portion (least significant bits) of the - address. This includes both so-called "rapid renumbering" scenarios - (where an entire network's prefix may change very quickly) and - routing architectures such as the former "GSE" proposal [GSE] (where - the "routing goop" portion of an address may be subject to change - without warning). A6 RRs do not completely remove the need to update - leaf zones during all renumbering events (for example, changing ISPs - would usually require a change to the upward delegation pointer), but - careful use of A6 RRs could keep the number of RRs that need to - change during such an event to a minimum. - - Note that constructing AAAA RRs via preprocessing during zone file - generation requires exactly the sort of information that A6 RRs store - in the DNS. This begs the question of where the hypothetical - preprocessor obtains that information if it's not getting it from the - DNS. - - Note also that the A6 RR, when restricted to its zero-length-prefix - form ("A6 0"), is semantically equivalent to an AAAA RR (with one - "wasted" octet in the wire representation), so anything that can be - done with an AAAA RR can also be done with an A6 RR. - - - -Austein Informational [Page 2] - -RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 - - -Main Advantages of Going with AAAA - - The AAAA RR proposed in [RFC1886], while providing only a subset of - the functionality provided by the A6 RR proposed in [RFC2874], has - two main points to recommend it: - - - AAAA RRs are essentially identical (other than their length) to - IPv4's A RRs, so we have more than 15 years of experience to help - us predict the usage patterns, failure scenarios and so forth - associated with AAAA RRs. - - - The AAAA RR is "optimized for read", in the sense that, by storing - a complete address rather than making the resolver fetch the - address in pieces, it minimizes the effort involved in fetching - addresses from the DNS (at the expense of increasing the effort - involved in injecting new data into the DNS). - -Less Compelling Arguments in Favor of A6 - - Since the A6 RR allows a zone administrator to write zone files whose - description of addresses maps to the underlying network topology, A6 - RRs can be construed as a "better" way of representing addresses than - AAAA. This may well be a useful capability, but in and of itself - it's more of an argument for better tools for zone administrators to - use when constructing zone files than a justification for changing - the resolution protocol used on the wire. - -Less Compelling Arguments in Favor of AAAA - - Some of the pressure to go with AAAA instead of A6 appears to be - based on the wider deployment of AAAA. Since it is possible to - construct transition tools (see discussion of AAAA synthesis, later - in this note), this does not appear to be a compelling argument if A6 - provides features that we really need. - - Another argument in favor of AAAA RRs over A6 RRs appears to be that - the A6 RR's advanced capabilities increase the number of ways in - which a zone administrator could build a non-working configuration. - While operational issues are certainly important, this is more of - argument that we need better tools for zone administrators than it is - a justification for turning away from A6 if A6 provides features that - we really need. - - - - - - - - - -Austein Informational [Page 3] - -RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 - - -Potential Problems with A6 - - The enhanced capabilities of the A6 RR, while interesting, are not in - themselves justification for choosing A6 if we don't really need - those capabilities. The A6 RR is "optimized for write", in the sense - that, by making it possible to store fragmented IPv6 addresses in the - DNS, it makes it possible to reduce the effort that it takes to - inject new data into the DNS (at the expense of increasing the effort - involved in fetching data from the DNS). This may be justified if we - expect the effort involved in maintaining AAAA-style DNS entries to - be prohibitive, but in general, we expect the DNS data to be read - more frequently than it is written, so we need to evaluate this - particular tradeoff very carefully. - - There are also several potential issues with A6 RRs that stem - directly from the feature that makes them different from AAAA RRs: - the ability to build up address via chaining. - - Resolving a chain of A6 RRs involves resolving a series of what are - almost independent queries, but not quite. Each of these sub-queries - takes some non-zero amount of time, unless the answer happens to be - in the resolver's local cache already. Assuming that resolving an - AAAA RR takes time T as a baseline, we can guess that, on the - average, it will take something approaching time N*T to resolve an - N-link chain of A6 RRs, although we would expect to see a fairly good - caching factor for the A6 fragments representing the more significant - bits of an address. This leaves us with two choices, neither of - which is very good: we can decrease the amount of time that the - resolver is willing to wait for each fragment, or we can increase the - amount of time that a resolver is willing to wait before returning - failure to a client. What little data we have on this subject - suggests that users are already impatient with the length of time it - takes to resolve A RRs in the IPv4 Internet, which suggests that they - are not likely to be patient with significantly longer delays in the - IPv6 Internet. At the same time, terminating queries prematurely is - both a waste of resources and another source of user frustration. - Thus, we are forced to conclude that indiscriminate use of long A6 - chains is likely to lead to problems. - - To make matters worse, the places where A6 RRs are likely to be most - critical for rapid renumbering or GSE-like routing are situations - where the prefix name field in the A6 RR points to a target that is - not only outside the DNS zone containing the A6 RR, but is - administered by a different organization (for example, in the case of - an end user's site, the prefix name will most likely point to a name - belonging to an ISP that provides connectivity for the site). While - pointers out of zone are not a problem per se, pointers to other - organizations are somewhat more difficult to maintain and less - - - -Austein Informational [Page 4] - -RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 - - - susceptible to automation than pointers within a single organization - would be. Experience both with glue RRs and with PTR RRs in the IN- - ADDR.ARPA tree suggests that many zone administrators do not really - understand how to set up and maintain these pointers properly, and we - have no particular reason to believe that these zone administrators - will do a better job with A6 chains than they do today. To be fair, - however, the alternative case of building AAAA RRs via preprocessing - before loading zones has many of the same problems; at best, one can - claim that using AAAA RRs for this purpose would allow DNS clients to - get the wrong answer somewhat more efficiently than with A6 RRs. - - Finally, assuming near total ignorance of how likely a query is to - fail, the probability of failure with an N-link A6 chain would appear - to be roughly proportional to N, since each of the queries involved - in resolving an A6 chain would have the same probability of failure - as a single AAAA query. Note again that this comment applies to - failures in the the process of resolving a query, not to the data - obtained via that process. Arguably, in an ideal world, A6 RRs would - increase the probability of the answer a client (finally) gets being - right, assuming that nothing goes wrong in the query process, but we - have no real idea how to quantify that assumption at this point even - to the hand-wavey extent used elsewhere in this note. - - One potential problem that has been raised in the past regarding A6 - RRs turns out not to be a serious issue. The A6 design includes the - possibility of there being more than one A6 RR matching the prefix - name portion of a leaf A6 RR. That is, an A6 chain may not be a - simple linked list, it may in fact be a tree, where each branch - represents a possible prefix. Some critics of A6 have been concerned - that this will lead to a wild expansion of queries, but this turns - out not to be a problem if a resolver simply follows the "bounded - work per query" rule described in RFC 1034 (page 35). That rule - applies to all work resulting from attempts to process a query, - regardless of whether it's a simple query, a CNAME chain, an A6 tree, - or an infinite loop. The client may not get back a useful answer in - cases where the zone has been configured badly, but a proper - implementation should not produce a query explosion as a result of - processing even the most perverse A6 tree, chain, or loop. - -Interactions with DNSSEC - - One of the areas where AAAA and A6 RRs differ is in the precise - details of how they interact with DNSSEC. The following comments - apply only to non-zero-prefix A6 RRs (A6 0 RRs, once again, are - semantically equivalent to AAAA RRs). - - - - - - -Austein Informational [Page 5] - -RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 - - - Other things being equal, the time it takes to re-sign all of the - addresses in a zone after a renumbering event is longer with AAAA RRs - than with A6 RRs (because each address record has to be re-signed - rather than just signing a common prefix A6 RR and a few A6 0 RRs - associated with the zone's name servers). Note, however, that in - general this does not present a serious scaling problem, because the - re-signing is performed in the leaf zones. - - Other things being equal, there's more work involved in verifying the - signatures received back for A6 RRs, because each address fragment - has a separate associated signature. Similarly, a DNS message - containing a set of A6 address fragments and their associated - signatures will be larger than the equivalent packet with a single - AAAA (or A6 0) and a single associated signature. - - Since AAAA RRs cannot really represent rapid renumbering or GSE-style - routing scenarios very well, it should not be surprising that DNSSEC - signatures of AAAA RRs are also somewhat problematic. In cases where - the AAAA RRs would have to be changing very quickly to keep up with - prefix changes, the time required to re-sign the AAAA RRs may be - prohibitive. - - Empirical testing by Bill Sommerfeld [Sommerfeld] suggests that - 333MHz Celeron laptop with 128KB L2 cache and 64MB RAM running the - BIND-9 dnssec-signzone program under NetBSD can generate roughly 40 - 1024-bit RSA signatures per second. Extrapolating from this, - assuming one A RR, one AAAA RR, and one NXT RR per host, this - suggests that it would take this laptop a few hours to sign a zone - listing 10**5 hosts, or about a day to sign a zone listing 10**6 - hosts using AAAA RRs. - - This suggests that the additional effort of re-signing a large zone - full of AAAA RRs during a re-numbering event, while noticeable, is - only likely to be prohibitive in the rapid renumbering case where - AAAA RRs don't work well anyway. - -Interactions with Dynamic Update - - DNS dynamic update appears to work equally well for AAAA or A6 RRs, - with one minor exception: with A6 RRs, the dynamic update client - needs to know the prefix length and prefix name. At present, no - mechanism exists to inform a dynamic update client of these values, - but presumably such a mechanism could be provided via an extension to - DHCP, or some other equivalent could be devised. - - - - - - - -Austein Informational [Page 6] - -RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 - - -Transition from AAAA to A6 Via AAAA Synthesis - - While AAAA is at present more widely deployed than A6, it is possible - to transition from AAAA-aware DNS software to A6-aware DNS software. - A rough plan for this was presented at IETF-50 in Minneapolis and has - been discussed on the ipng mailing list. So if the IETF concludes - that A6's enhanced capabilities are necessary, it should be possible - to transition from AAAA to A6. - - The details of this transition have been left to a separate document, - but the general idea is that the resolver that is performing - iterative resolution on behalf of a DNS client program could - synthesize AAAA RRs representing the result of performing the - equivalent A6 queries. Note that in this case it is not possible to - generate an equivalent DNSSEC signature for the AAAA RR, so clients - that care about performing DNSSEC validation for themselves would - have to issue A6 queries directly rather than relying on AAAA - synthesis. - -Bitlabels - - While the differences between AAAA and A6 RRs have generated most of - the discussion to date, there are also two proposed mechanisms for - building the reverse mapping tree (the IPv6 equivalent of IPv4's IN- - ADDR.ARPA tree). - - [RFC1886] proposes a mechanism very similar to the IN-ADDR.ARPA - mechanism used for IPv4 addresses: the RR name is the hexadecimal - representation of the IPv6 address, reversed and concatenated with a - well-known suffix, broken up with a dot between each hexadecimal - digit. The resulting DNS names are somewhat tedious for humans to - type, but are very easy for programs to generate. Making each - hexadecimal digit a separate label means that delegation on arbitrary - bit boundaries will result in a maximum of 16 NS RRsets per label - level; again, the mechanism is somewhat tedious for humans, but is - very easy to program. As with IPv4's IN-ADDR.ARPA tree, the one - place where this scheme is weak is in handling delegations in the - least significant label; however, since there appears to be no real - need to delegate the least significant four bits of an IPv6 address, - this does not appear to be a serious restriction. - - [RFC2874] proposed a radically different way of naming entries in the - reverse mapping tree: rather than using textual representations of - addresses, it proposes to use a new kind of DNS label (a "bit label") - to represent binary addresses directly in the DNS. This has the - advantage of being significantly more compact than the textual - representation, and arguably might have been a better solution for - DNS to use for this purpose if it had been designed into the protocol - - - -Austein Informational [Page 7] - -RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 - - - from the outset. Unfortunately, experience to date suggests that - deploying a new DNS label type is very hard: all of the DNS name - servers that are authoritative for any portion of the name in - question must be upgraded before the new label type can be used, as - must any resolvers involved in the resolution process. Any name - server that has not been upgraded to understand the new label type - will reject the query as being malformed. - - Since the main benefit of the bit label approach appears to be an - ability that we don't really need (delegation in the least - significant four bits of an IPv6 address), and since the upgrade - problem is likely to render bit labels unusable until a significant - portion of the DNS code base has been upgraded, it is difficult to - escape the conclusion that the textual solution is good enough. - -DNAME RRs - - [RFC2874] also proposes using DNAME RRs as a way of providing the - equivalent of A6's fragmented addresses in the reverse mapping tree. - That is, by using DNAME RRs, one can write zone files for the reverse - mapping tree that have the same ability to cope with rapid - renumbering or GSE-style routing that the A6 RR offers in the main - portion of the DNS tree. Consequently, the need to use DNAME in the - reverse mapping tree appears to be closely tied to the need to use - fragmented A6 in the main tree: if one is necessary, so is the other, - and if one isn't necessary, the other isn't either. - - Other uses have also been proposed for the DNAME RR, but since they - are outside the scope of the IPv6 address discussion, they will not - be addressed here. - -Recommendation - - Distilling the above feature comparisons down to their key elements, - the important questions appear to be: - - (a) Is IPv6 going to do rapid renumbering or GSE-like routing? - - (b) Is the reverse mapping tree for IPv6 going to require delegation - in the least significant four bits of the address? - - Question (a) appears to be the key to the debate. This is really a - decision for the IPv6 community to make, not the DNS community. - - Question (b) is also for the IPv6 community to make, but it seems - fairly obvious that the answer is "no". - - - - - -Austein Informational [Page 8] - -RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 - - - Recommendations based on these questions: - - (1) If the IPv6 working groups seriously intend to specify and deploy - rapid renumbering or GSE-like routing, we should transition to - using the A6 RR in the main tree and to using DNAME RRs as - necessary in the reverse tree. - - (2) Otherwise, we should keep the simpler AAAA solution in the main - tree and should not use DNAME RRs in the reverse tree. - - (3) In either case, the reverse tree should use the textual - representation described in [RFC1886] rather than the bit label - representation described in [RFC2874]. - - (4) If we do go to using A6 RRs in the main tree and to using DNAME - RRs in the reverse tree, we should write applicability statements - and implementation guidelines designed to discourage excessively - complex uses of these features; in general, any network that can - be described adequately using A6 0 RRs and without using DNAME - RRs should be described that way, and the enhanced features - should be used only when absolutely necessary, at least until we - have much more experience with them and have a better - understanding of their failure modes. - -Security Considerations - - This note compares two mechanisms with similar security - characteristics, but there are a few security implications to the - choice between these two mechanisms: - - (1) The two mechanisms have similar but not identical interactions - with DNSSEC. Please see the section entitled "Interactions with - DNSSEC" (above) for a discussion of these issues. - - (2) To the extent that operational complexity is the enemy of - security, the tradeoffs in operational complexity discussed - throughout this note have an impact on security. - - (3) To the extent that protocol complexity is the enemy of security, - the additional protocol complexity of [RFC2874] as compared to - [RFC1886] has some impact on security. - -IANA Considerations - - None, since all of these RR types have already been allocated. - - - - - - -Austein Informational [Page 9] - -RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 - - -Acknowledgments - - This note is based on a number of discussions both public and private - over a period of (at least) eight years, but particular thanks go to - Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun - Hagino, Mark Andrews, Matt Crawford, Olafur Gudmundsson, Randy Bush, - and Sue Thomson, none of whom are responsible for what the author did - with their ideas. - -References - - [RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support - IP version 6", RFC 1886, December 1995. - - [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support - IPv6 Address Aggregation and Renumbering", RFC 2874, - July 2000. - - [Sommerfeld] Private message to the author from Bill Sommerfeld dated - 21 March 2001, summarizing the result of experiments he - performed on a copy of the MIT.EDU zone. - - [GSE] "GSE" was an evolution of the so-called "8+8" proposal - discussed by the IPng working group in 1996 and 1997. - The GSE proposal itself was written up as an Internet- - Draft, which has long since expired. Readers interested - in the details and history of GSE should review the IPng - working group's mailing list archives and minutes from - that period. - -Author's Address - - Rob Austein - - EMail: sra@hactrn.net - - - - - - - - - - - - - - - - -Austein Informational [Page 10] - -RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2002). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Austein Informational [Page 11] - diff --git a/contrib/bind9/doc/rfc/rfc3425.txt b/contrib/bind9/doc/rfc/rfc3425.txt deleted file mode 100644 index 707cafd18aa1..000000000000 --- a/contrib/bind9/doc/rfc/rfc3425.txt +++ /dev/null @@ -1,283 +0,0 @@ - - - - - - -Network Working Group D. Lawrence -Request for Comments: 3425 Nominum -Updates: 1035 November 2002 -Category: Standards Track - - - Obsoleting IQUERY - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2002). All Rights Reserved. - -Abstract - - The IQUERY method of performing inverse DNS lookups, specified in RFC - 1035, has not been generally implemented and has usually been - operationally disabled where it has been implemented. Both reflect a - general view in the community that the concept was unwise and that - the widely-used alternate approach of using pointer (PTR) queries and - reverse-mapping records is preferable. Consequently, this document - deprecates the IQUERY operation, declaring it entirely obsolete. - This document updates RFC 1035. - -1 - Introduction - - As specified in RFC 1035 (section 6.4), the IQUERY operation for DNS - queries is used to look up the name(s) which are associated with the - given value. The value being sought is provided in the query's - answer section and the response fills in the question section with - one or more 3-tuples of type, name and class. - - As noted in [RFC1035], section 6.4.3, inverse query processing can - put quite an arduous burden on a server. A server would need to - perform either an exhaustive search of its database or maintain a - separate database that is keyed by the values of the primary - database. Both of these approaches could strain system resource use, - particularly for servers that are authoritative for millions of - names. - - - - - -Lawrence Standards Track [Page 1] - -RFC 3425 Obsoleting IQUERY November 2002 - - - Response packets from these megaservers could be exceptionally large, - and easily run into megabyte sizes. For example, using IQUERY to - find every domain that is delegated to one of the nameservers of a - large ISP could return tens of thousands of 3-tuples in the question - section. This could easily be used to launch denial of service - attacks. - - Operators of servers that do support IQUERY in some form (such as - very old BIND 4 servers) generally opt to disable it. This is - largely due to bugs in insufficiently-exercised code, or concerns - about exposure of large blocks of names in their zones by probes such - as inverse MX queries. - - IQUERY is also somewhat inherently crippled by being unable to tell a - requester where it needs to go to get the information that was - requested. The answer is very specific to the single server that was - queried. This is sometimes a handy diagnostic tool, but apparently - not enough so that server operators like to enable it, or request - implementation where it is lacking. - - No known clients use IQUERY to provide any meaningful service. The - only common reverse mapping support on the Internet, mapping address - records to names, is provided through the use of pointer (PTR) - records in the in-addr.arpa tree and has served the community well - for many years. - - Based on all of these factors, this document recommends that the - IQUERY operation for DNS servers be officially obsoleted. - -2 - Requirements - - The key word "SHOULD" in this document is to be interpreted as - described in BCP 14, RFC 2119, namely that there may exist valid - reasons to ignore a particular item, but the full implications must - be understood and carefully weighed before choosing a different - course. - -3 - Effect on RFC 1035 - - The effect of this document is to change the definition of opcode 1 - from that originally defined in section 4.1.1 of RFC 1035, and to - entirely supersede section 6.4 (including subsections) of RFC 1035. - - The definition of opcode 1 is hereby changed to: - - "1 an inverse query (IQUERY) (obsolete)" - - - - - -Lawrence Standards Track [Page 2] - -RFC 3425 Obsoleting IQUERY November 2002 - - - The text in section 6.4 of RFC 1035 is now considered obsolete. The - following is an applicability statement regarding the IQUERY opcode: - - Inverse queries using the IQUERY opcode were originally described as - the ability to look up the names that are associated with a - particular Resource Record (RR). Their implementation was optional - and never achieved widespread use. Therefore IQUERY is now obsolete, - and name servers SHOULD return a "Not Implemented" error when an - IQUERY request is received. - -4 - Security Considerations - - Since this document obsoletes an operation that was once available, - it is conceivable that someone was using it as the basis of a - security policy. However, since the most logical course for such a - policy to take in the face of a lack of positive response from a - server is to deny authentication/authorization, it is highly unlikely - that removing support for IQUERY will open any new security holes. - - Note that if IQUERY is not obsoleted, securing the responses with DNS - Security (DNSSEC) is extremely difficult without out-on-the-fly - digital signing. - -5 - IANA Considerations - - The IQUERY opcode of 1 should be permanently retired, not to be - assigned to any future opcode. - -6 - Acknowledgments - - Olafur Gudmundsson instigated this action. Matt Crawford, John - Klensin, Erik Nordmark and Keith Moore contributed some improved - wording in how to handle obsoleting functionality described by an - Internet Standard. - -7 - References - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - [RFC2026] Bradner, S., "The Internet Standards Process -- Revision - 3", BCP 9, RFC 2026, October 1996. - - [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - - - - - -Lawrence Standards Track [Page 3] - -RFC 3425 Obsoleting IQUERY November 2002 - - -8 - Author's Address - - David C Lawrence - Nominum, Inc. - 2385 Bay Rd - Redwood City CA 94063 - USA - - Phone: +1.650.779.6042 - EMail: tale@nominum.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lawrence Standards Track [Page 4] - -RFC 3425 Obsoleting IQUERY November 2002 - - -9 - Full Copyright Statement - - Copyright (C) The Internet Society (2002). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Lawrence Standards Track [Page 5] - diff --git a/contrib/bind9/doc/rfc/rfc3445.txt b/contrib/bind9/doc/rfc/rfc3445.txt deleted file mode 100644 index 67f9b2d6e573..000000000000 --- a/contrib/bind9/doc/rfc/rfc3445.txt +++ /dev/null @@ -1,563 +0,0 @@ - - - - - - -Network Working Group D. Massey -Request for Comments: 3445 USC/ISI -Updates: 2535 S. Rose -Category: Standards Track NIST - December 2002 - - - Limiting the Scope of the KEY Resource Record (RR) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2002). All Rights Reserved. - -Abstract - - This document limits the Domain Name System (DNS) KEY Resource Record - (RR) to only keys used by the Domain Name System Security Extensions - (DNSSEC). The original KEY RR used sub-typing to store both DNSSEC - keys and arbitrary application keys. Storing both DNSSEC and - application keys with the same record type is a mistake. This - document removes application keys from the KEY record by redefining - the Protocol Octet field in the KEY RR Data. As a result of removing - application keys, all but one of the flags in the KEY record become - unnecessary and are redefined. Three existing application key sub- - types are changed to reserved, but the format of the KEY record is - not changed. This document updates RFC 2535. - -1. Introduction - - This document limits the scope of the KEY Resource Record (RR). The - KEY RR was defined in [3] and used resource record sub-typing to hold - arbitrary public keys such as Email, IPSEC, DNSSEC, and TLS keys. - This document eliminates the existing Email, IPSEC, and TLS sub-types - and prohibits the introduction of new sub-types. DNSSEC will be the - only allowable sub-type for the KEY RR (hence sub-typing is - essentially eliminated) and all but one of the KEY RR flags are also - eliminated. - - - - - - -Massey & Rose Standards Track [Page 1] - -RFC 3445 Limiting the KEY Resource Record (RR) December 2002 - - - Section 2 presents the motivation for restricting the KEY record and - Section 3 defines the revised KEY RR. Sections 4 and 5 summarize the - changes from RFC 2535 and discuss backwards compatibility. It is - important to note that this document restricts the use of the KEY RR - and simplifies the flags, but does not change the definition or use - of DNSSEC keys. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [1]. - -2. Motivation for Restricting the KEY RR - - The KEY RR RDATA [3] consists of Flags, a Protocol Octet, an - Algorithm type, and a Public Key. The Protocol Octet identifies the - KEY RR sub-type. DNSSEC public keys are stored in the KEY RR using a - Protocol Octet value of 3. Email, IPSEC, and TLS keys were also - stored in the KEY RR and used Protocol Octet values of 1,2, and 4 - (respectively). Protocol Octet values 5-254 were available for - assignment by IANA and values were requested (but not assigned) for - applications such as SSH. - - Any use of sub-typing has inherent limitations. A resolver can not - specify the desired sub-type in a DNS query and most DNS operations - apply only to resource records sets. For example, a resolver can not - directly request the DNSSEC subtype KEY RRs. Instead, the resolver - has to request all KEY RRs associated with a DNS name and then search - the set for the desired DNSSEC sub-type. DNSSEC signatures also - apply to the set of all KEY RRs associated with the DNS name, - regardless of sub-type. - - In the case of the KEY RR, the inherent sub-type limitations are - exacerbated since the sub-type is used to distinguish between DNSSEC - keys and application keys. DNSSEC keys and application keys differ - in virtually every respect and Section 2.1 discusses these - differences in more detail. Combining these very different types of - keys into a single sub-typed resource record adds unnecessary - complexity and increases the potential for implementation and - deployment errors. Limited experimental deployment has shown that - application keys stored in KEY RRs are problematic. - - This document addresses these issues by removing all application keys - from the KEY RR. Note that the scope of this document is strictly - limited to the KEY RR and this document does not endorse or restrict - the storage of application keys in other, yet undefined, resource - records. - - - - - -Massey & Rose Standards Track [Page 2] - -RFC 3445 Limiting the KEY Resource Record (RR) December 2002 - - -2.1 Differences Between DNSSEC and Application Keys - - DNSSEC keys are an essential part of the DNSSEC protocol and are used - by both name servers and resolvers in order to perform DNS tasks. A - DNS zone key, used to sign and authenticate RR sets, is the most - common example of a DNSSEC key. SIG(0) [4] and TKEY [3] also use - DNSSEC keys. - - Application keys such as Email keys, IPSEC keys, and TLS keys are - simply another type of data. These keys have no special meaning to a - name server or resolver. - - The following table summarizes some of the differences between DNSSEC - keys and application keys: - - 1. They serve different purposes. - - 2. They are managed by different administrators. - - 3. They are authenticated according to different rules. - - 4. Nameservers use different rules when including them in - responses. - - 5. Resolvers process them in different ways. - - 6. Faults/key compromises have different consequences. - - 1. The purpose of a DNSSEC key is to sign resource records - associated with a DNS zone (or generate DNS transaction signatures in - the case of SIG(0)/TKEY). But the purpose of an application key is - specific to the application. Application keys, such as PGP/email, - IPSEC, TLS, and SSH keys, are not a mandatory part of any zone and - the purpose and proper use of application keys is outside the scope - of DNS. - - 2. DNSSEC keys are managed by DNS administrators, but application - keys are managed by application administrators. The DNS zone - administrator determines the key lifetime, handles any suspected key - compromises, and manages any DNSSEC key changes. Likewise, the - application administrator is responsible for the same functions for - the application keys related to the application. For example, a user - typically manages her own PGP key and a server manages its own TLS - key. Application key management tasks are outside the scope of DNS - administration. - - - - - - -Massey & Rose Standards Track [Page 3] - -RFC 3445 Limiting the KEY Resource Record (RR) December 2002 - - - 3. DNSSEC zone keys are used to authenticate application keys, but - by definition, application keys are not allowed to authenticate DNS - zone keys. A DNS zone key is either configured as a trusted key or - authenticated by constructing a chain of trust in the DNS hierarchy. - To participate in the chain of trust, a DNS zone needs to exchange - zone key information with its parent zone [3]. Application keys are - not configured as trusted keys in the DNS and are never part of any - DNS chain of trust. Application key data is not needed by the parent - and does not need to be exchanged with the parent zone for secure DNS - resolution to work. A resolver considers an application key RRset as - authenticated DNS information if it has a valid signature from the - local DNS zone keys, but applications could impose additional - security requirements before the application key is accepted as - authentic for use with the application. - - 4. It may be useful for nameservers to include DNS zone keys in the - additional section of a response, but application keys are typically - not useful unless they have been specifically requested. For - example, it could be useful to include the example.com zone key along - with a response that contains the www.example.com A record and SIG - record. A secure resolver will need the example.com zone key in - order to check the SIG and authenticate the www.example.com A record. - It is typically not useful to include the IPSEC, email, and TLS keys - along with the A record. Note that by placing application keys in - the KEY record, a resolver would need the IPSEC, email, TLS, and - other key associated with example.com if the resolver intends to - authenticate the example.com zone key (since signatures only apply to - the entire KEY RR set). Depending on the number of protocols - involved, the KEY RR set could grow unwieldy for resolvers, and DNS - administrators to manage. - - 5. DNS zone keys require special handling by resolvers, but - application keys are treated the same as any other type of DNS data. - The DNSSEC keys are of no value to end applications, unless the - applications plan to do their own DNS authentication. By definition, - secure resolvers are not allowed to use application keys as part of - the authentication process. Application keys have no unique meaning - to resolvers and are only useful to the application requesting the - key. Note that if sub-types are used to identify the application - key, then either the interface to the resolver needs to specify the - sub-type or the application needs to be able to accept all KEY RRs - and pick out the desired sub-type. - - 6. A fault or compromise of a DNS zone key can lead to invalid or - forged DNS data, but a fault or compromise of an application key - should have no impact on other DNS data. Incorrectly adding or - changing a DNS zone key can invalidate all of the DNS data in the - zone and in all of its subzones. By using a compromised key, an - - - -Massey & Rose Standards Track [Page 4] - -RFC 3445 Limiting the KEY Resource Record (RR) December 2002 - - - attacker can forge data from the effected zone and for any of its - sub-zones. A fault or compromise of an application key has - implications for that application, but it should not have an impact - on the DNS. Note that application key faults and key compromises can - have an impact on the entire DNS if the application key and DNS zone - keys are both stored in the KEY RR. - - In summary, DNSSEC keys and application keys differ in most every - respect. DNSSEC keys are an essential part of the DNS infrastructure - and require special handling by DNS administrators and DNS resolvers. - Application keys are simply another type of data and have no special - meaning to DNS administrators or resolvers. These two different - types of data do not belong in the same resource record. - -3. Definition of the KEY RR - - The KEY RR uses type 25 and is used as resource record for storing - DNSSEC keys. The RDATA for a KEY RR consists of flags, a protocol - octet, the algorithm number octet, and the public key itself. The - format is as follows: - - --------------------------------------------------------------------- - - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | flags | protocol | algorithm | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | / - / public key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - KEY RR Format - - --------------------------------------------------------------------- - - In the flags field, all bits except bit 7 are reserved and MUST be - zero. If Bit 7 (Zone bit) is set to 1, then the KEY is a DNS Zone - key. If Bit 7 is set to 0, the KEY is not a zone key. SIG(0)/TKEY - are examples of DNSSEC keys that are not zone keys. - - The protocol field MUST be set to 3. - - The algorithm and public key fields are not changed. - - - - - -Massey & Rose Standards Track [Page 5] - -RFC 3445 Limiting the KEY Resource Record (RR) December 2002 - - -4. Changes from RFC 2535 KEY RR - - The KEY RDATA format is not changed. - - All flags except for the zone key flag are eliminated: - - The A/C bits (bits 0 and 1) are eliminated. They MUST be set to 0 - and MUST be ignored by the receiver. - - The extended flags bit (bit 3) is eliminated. It MUST be set to 0 - and MUST be ignored by the receiver. - - The host/user bit (bit 6) is eliminated. It MUST be set to 0 and - MUST be ignored by the receiver. - - The zone bit (bit 7) remains unchanged. - - The signatory field (bits 12-15) are eliminated by [5]. They MUST - be set to 0 and MUST be ignored by the receiver. - - Bits 2,4,5,8,9,10,11 remain unchanged. They are reserved, MUST be - set to zero and MUST be ignored by the receiver. - - Assignment of any future KEY RR Flag values requires a standards - action. - - All Protocol Octet values except DNSSEC (3) are eliminated: - - Value 1 (Email) is renamed to RESERVED. - - Value 2 (IPSEC) is renamed to RESERVED. - - Value 3 (DNSSEC) is unchanged. - - Value 4 (TLS) is renamed to RESERVED. - - Value 5-254 remains unchanged (reserved). - - Value 255 (ANY) is renamed to RESERVED. - - The authoritative data for a zone MUST NOT include any KEY records - with a protocol octet other than 3. The registry maintained by IANA - for protocol values is closed for new assignments. - - Name servers and resolvers SHOULD accept KEY RR sets that contain KEY - RRs with a value other than 3. If out of date DNS zones contain - deprecated KEY RRs with a protocol octet value other than 3, then - simply dropping the deprecated KEY RRs from the KEY RR set would - - - -Massey & Rose Standards Track [Page 6] - -RFC 3445 Limiting the KEY Resource Record (RR) December 2002 - - - invalidate any associated SIG record(s) and could create caching - consistency problems. Note that KEY RRs with a protocol octet value - other than 3 MUST NOT be used to authenticate DNS data. - - The algorithm and public key fields are not changed. - -5. Backward Compatibility - - DNSSEC zone KEY RRs are not changed and remain backwards compatible. - A properly formatted RFC 2535 zone KEY would have all flag bits, - other than the Zone Bit (Bit 7), set to 0 and would have the Protocol - Octet set to 3. This remains true under the restricted KEY. - - DNSSEC non-zone KEY RRs (SIG(0)/TKEY keys) are backwards compatible, - but the distinction between host and user keys (flag bit 6) is lost. - - No backwards compatibility is provided for application keys. Any - Email, IPSEC, or TLS keys are now deprecated. Storing application - keys in the KEY RR created problems such as keys at the apex and - large RR sets and some change in the definition and/or usage of the - KEY RR would have been required even if the approach described here - were not adopted. - - Overall, existing nameservers and resolvers will continue to - correctly process KEY RRs with a sub-type of DNSSEC keys. - -6. Storing Application Keys in the DNS - - The scope of this document is strictly limited to the KEY record. - This document prohibits storing application keys in the KEY record, - but it does not endorse or restrict the storing application keys in - other record types. Other documents can describe how DNS handles - application keys. - -7. IANA Considerations - - RFC 2535 created an IANA registry for DNS KEY RR Protocol Octet - values. Values 1, 2, 3, 4, and 255 were assigned by RFC 2535 and - values 5-254 were made available for assignment by IANA. This - document makes two sets of changes to this registry. - - First, this document re-assigns DNS KEY RR Protocol Octet values 1, - 2, 4, and 255 to "reserved". DNS Key RR Protocol Octet Value 3 - remains unchanged as "DNSSEC". - - - - - - - -Massey & Rose Standards Track [Page 7] - -RFC 3445 Limiting the KEY Resource Record (RR) December 2002 - - - Second, new values are no longer available for assignment by IANA and - this document closes the IANA registry for DNS KEY RR Protocol Octet - Values. Assignment of any future KEY RR Protocol Octet values - requires a standards action. - -8. Security Considerations - - This document eliminates potential security problems that could arise - due to the coupling of DNS zone keys and application keys. Prior to - the change described in this document, a correctly authenticated KEY - set could include both application keys and DNSSEC keys. This - document restricts the KEY RR to DNS security usage only. This is an - attempt to simplify the security model and make it less user-error - prone. If one of the application keys is compromised, it could be - used as a false zone key to create false DNS signatures (SIG - records). Resolvers that do not carefully check the KEY sub-type - could believe these false signatures and incorrectly authenticate DNS - data. With this change, application keys cannot appear in an - authenticated KEY set and this vulnerability is eliminated. - - The format and correct usage of DNSSEC keys is not changed by this - document and no new security considerations are introduced. - -9. Normative References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [2] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [3] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC - 2930, September 2000. - - [4] Eastlake, D., "DNS Request and Transaction Signatures - (SIG(0)s)", RFC 2931, September 2000. - - [5] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - - - - - - - - - - - -Massey & Rose Standards Track [Page 8] - -RFC 3445 Limiting the KEY Resource Record (RR) December 2002 - - -10. Authors' Addresses - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.edu - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-3460 - USA - - EMail: scott.rose@nist.gov - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Massey & Rose Standards Track [Page 9] - -RFC 3445 Limiting the KEY Resource Record (RR) December 2002 - - -11. Full Copyright Statement - - Copyright (C) The Internet Society (2002). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Massey & Rose Standards Track [Page 10] - diff --git a/contrib/bind9/doc/rfc/rfc3467.txt b/contrib/bind9/doc/rfc/rfc3467.txt deleted file mode 100644 index 37ac7ec1d930..000000000000 --- a/contrib/bind9/doc/rfc/rfc3467.txt +++ /dev/null @@ -1,1739 +0,0 @@ - - - - - - -Network Working Group J. Klensin -Request for Comments: 3467 February 2003 -Category: Informational - - - Role of the Domain Name System (DNS) - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - This document reviews the original function and purpose of the domain - name system (DNS). It contrasts that history with some of the - purposes for which the DNS has recently been applied and some of the - newer demands being placed upon it or suggested for it. A framework - for an alternative to placing these additional stresses on the DNS is - then outlined. This document and that framework are not a proposed - solution, only a strong suggestion that the time has come to begin - thinking more broadly about the problems we are encountering and - possible approaches to solving them. - -Table of Contents - - 1. Introduction and History ..................................... 2 - 1.1 Context for DNS Development ............................... 3 - 1.2 Review of the DNS and Its Role as Designed ................ 4 - 1.3 The Web and User-visible Domain Names ..................... 6 - 1.4 Internet Applications Protocols and Their Evolution ....... 7 - 2. Signs of DNS Overloading ..................................... 8 - 3. Searching, Directories, and the DNS .......................... 12 - 3.1 Overview ................................................. 12 - 3.2 Some Details and Comments ................................. 14 - 4. Internationalization ......................................... 15 - 4.1 ASCII Isn't Just Because of English ....................... 16 - 4.2 The "ASCII Encoding" Approaches ........................... 17 - 4.3 "Stringprep" and Its Complexities ......................... 17 - 4.4 The Unicode Stability Problem ............................. 19 - 4.5 Audiences, End Users, and the User Interface Problem ...... 20 - 4.6 Business Cards and Other Natural Uses of Natural Languages. 22 - 4.7 ASCII Encodings and the Roman Keyboard Assumption ......... 22 - - - -Klensin Informational [Page 1] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - 4.8 Intra-DNS Approaches for "Multilingual Names" ............. 23 - 5. Search-based Systems: The Key Controversies .................. 23 - 6. Security Considerations ...................................... 24 - 7. References ................................................... 25 - 7.1 Normative References ...................................... 25 - 7.2 Explanatory and Informative References .................... 25 - 8. Acknowledgements ............................................. 30 - 9. Author's Address ............................................. 30 - 10. Full Copyright Statement ..................................... 31 - -1. Introduction and History - - The DNS was designed as a replacement for the older "host table" - system. Both were intended to provide names for network resources at - a more abstract level than network (IP) addresses (see, e.g., - [RFC625], [RFC811], [RFC819], [RFC830], [RFC882]). In recent years, - the DNS has become a database of convenience for the Internet, with - many proposals to add new features. Only some of these proposals - have been successful. Often the main (or only) motivation for using - the DNS is because it exists and is widely deployed, not because its - existing structure, facilities, and content are appropriate for the - particular application of data involved. This document reviews the - history of the DNS, including examination of some of those newer - applications. It then argues that the overloading process is often - inappropriate. Instead, it suggests that the DNS should be - supplemented by systems better matched to the intended applications - and outlines a framework and rationale for one such system. - - Several of the comments that follow are somewhat revisionist. Good - design and engineering often requires a level of intuition by the - designers about things that will be necessary in the future; the - reasons for some of these design decisions are not made explicit at - the time because no one is able to articulate them. The discussion - below reconstructs some of the decisions about the Internet's primary - namespace (the "Class=IN" DNS) in the light of subsequent development - and experience. In addition, the historical reasons for particular - decisions about the Internet were often severely underdocumented - contemporaneously and, not surprisingly, different participants have - different recollections about what happened and what was considered - important. Consequently, the quasi-historical story below is just - one story. There may be (indeed, almost certainly are) other stories - about how the DNS evolved to its present state, but those variants do - not invalidate the inferences and conclusions. - - This document presumes a general understanding of the terminology of - RFC 1034 [RFC1034] or of any good DNS tutorial (see, e.g., [Albitz]). - - - - - -Klensin Informational [Page 2] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - -1.1 Context for DNS Development - - During the entire post-startup-period life of the ARPANET and nearly - the first decade or so of operation of the Internet, the list of host - names and their mapping to and from addresses was maintained in a - frequently-updated "host table" [RFC625], [RFC811], [RFC952]. The - names themselves were restricted to a subset of ASCII [ASCII] chosen - to avoid ambiguities in printed form, to permit interoperation with - systems using other character codings (notably EBCDIC), and to avoid - the "national use" code positions of ISO 646 [IS646]. These - restrictions later became collectively known as the "LDH" rules for - "letter-digit-hyphen", the permitted characters. The table was just - a list with a common format that was eventually agreed upon; sites - were expected to frequently obtain copies of, and install, new - versions. The host tables themselves were introduced to: - - o Eliminate the requirement for people to remember host numbers - (addresses). Despite apparent experience to the contrary in the - conventional telephone system, numeric numbering systems, - including the numeric host number strategy, did not (and do not) - work well for more than a (large) handful of hosts. - - o Provide stability when addresses changed. Since addresses -- to - some degree in the ARPANET and more importantly in the - contemporary Internet -- are a function of network topology and - routing, they often had to be changed when connectivity or - topology changed. The names could be kept stable even as - addresses changed. - - o Provide the capability to have multiple addresses associated with - a given host to reflect different types of connectivity and - topology. Use of names, rather than explicit addresses, avoided - the requirement that would otherwise exist for users and other - hosts to track these multiple host numbers and addresses and the - topological considerations for selecting one over others. - - After several years of using the host table approach, the community - concluded that model did not scale adequately and that it would not - adequately support new service variations. A number of discussions - and meetings were held which drew several ideas and incomplete - proposals together. The DNS was the result of that effort. It - continued to evolve during the design and initial implementation - period, with a number of documents recording the changes (see - [RFC819], [RFC830], and [RFC1034]). - - - - - - - -Klensin Informational [Page 3] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - The goals for the DNS included: - - o Preservation of the capabilities of the host table arrangements - (especially unique, unambiguous, host names), - - o Provision for addition of additional services (e.g., the special - record types for electronic mail routing which quickly followed - introduction of the DNS), and - - o Creation of a robust, hierarchical, distributed, name lookup - system to accomplish the other goals. - - The DNS design also permitted distribution of name administration, - rather than requiring that each host be entered into a single, - central, table by a central administration. - -1.2 Review of the DNS and Its Role as Designed - - The DNS was designed to identify network resources. Although there - was speculation about including, e.g., personal names and email - addresses, it was not designed primarily to identify people, brands, - etc. At the same time, the system was designed with the flexibility - to accommodate new data types and structures, both through the - addition of new record types to the initial "INternet" class, and, - potentially, through the introduction of new classes. Since the - appropriate identifiers and content of those future extensions could - not be anticipated, the design provided that these fields could - contain any (binary) information, not just the restricted text forms - of the host table. - - However, the DNS, as it is actually used, is intimately tied to the - applications and application protocols that utilize it, often at a - fairly low level. - - In particular, despite the ability of the protocols and data - structures themselves to accommodate any binary representation, DNS - names as used were historically not even unrestricted ASCII, but a - very restricted subset of it, a subset that derives from the original - host table naming rules. Selection of that subset was driven in part - by human factors considerations, including a desire to eliminate - possible ambiguities in an international context. Hence character - codes that had international variations in interpretation were - excluded, the underscore character and case distinctions were - eliminated as being confusing (in the underscore's case, with the - hyphen character) when written or read by people, and so on. These - considerations appear to be very similar to those that resulted in - similarly restricted character sets being used as protocol elements - in many ITU and ISO protocols (cf. [X29]). - - - -Klensin Informational [Page 4] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - Another assumption was that there would be a high ratio of physical - hosts to second level domains and, more generally, that the system - would be deeply hierarchical, with most systems (and names) at the - third level or below and a very large percentage of the total names - representing physical hosts. There are domains that follow this - model: many university and corporate domains use fairly deep - hierarchies, as do a few country-oriented top level domains - ("ccTLDs"). Historically, the "US." domain has been an excellent - example of the deeply hierarchical approach. However, by 1998, - comparison of several efforts to survey the DNS showed a count of SOA - records that approached (and may have passed) the number of distinct - hosts. Looked at differently, we appear to be moving toward a - situation in which the number of delegated domains on the Internet is - approaching or exceeding the number of hosts, or at least the number - of hosts able to provide services to others on the network. This - presumably results from synonyms or aliases that map a great many - names onto a smaller number of hosts. While experience up to this - time has shown that the DNS is robust enough -- given contemporary - machines as servers and current bandwidth norms -- to be able to - continue to operate reasonably well when those historical assumptions - are not met (e.g., with a flat, structure under ".COM" containing - well over ten million delegated subdomains [COMSIZE]), it is still - useful to remember that the system could have been designed to work - optimally with a flat structure (and very large zones) rather than a - deeply hierarchical one, and was not. - - Similarly, despite some early speculation about entering people's - names and email addresses into the DNS directly (e.g., see - [RFC1034]), electronic mail addresses in the Internet have preserved - the original, pre-DNS, "user (or mailbox) at location" conceptual - format rather than a flatter or strictly dot-separated one. - Location, in that instance, is a reference to a host. The sole - exception, at least in the "IN" class, has been one field of the SOA - record. - - Both the DNS architecture itself and the two-level (host name and - mailbox name) provisions for email and similar functions (e.g., see - the finger protocol [FINGER]), also anticipated a relatively high - ratio of users to actual hosts. Despite the observation in RFC 1034 - that the DNS was expected to grow to be proportional to the number of - users (section 2.3), it has never been clear that the DNS was - seriously designed for, or could, scale to the order of magnitude of - number of users (or, more recently, products or document objects), - rather than that of physical hosts. - - Just as was the case for the host table before it, the DNS provided - critical uniqueness for names, and universal accessibility to them, - as part of overall "single internet" and "end to end" models (cf. - - - -Klensin Informational [Page 5] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - [RFC2826]). However, there are many signs that, as new uses evolved - and original assumptions were abused (if not violated outright), the - system was being stretched to, or beyond, its practical limits. - - The original design effort that led to the DNS included examination - of the directory technologies available at the time. The design - group concluded that the DNS design, with its simplifying assumptions - and restricted capabilities, would be feasible to deploy and make - adequately robust, which the more comprehensive directory approaches - were not. At the same time, some of the participants feared that the - limitations might cause future problems; this document essentially - takes the position that they were probably correct. On the other - hand, directory technology and implementations have evolved - significantly in the ensuing years: it may be time to revisit the - assumptions, either in the context of the two- (or more) level - mechanism contemplated by the rest of this document or, even more - radically, as a path toward a DNS replacement. - -1.3 The Web and User-visible Domain Names - - From the standpoint of the integrity of the domain name system -- and - scaling of the Internet, including optimal accessibility to content - -- the web design decision to use "A record" domain names directly in - URLs, rather than some system of indirection, has proven to be a - serious mistake in several respects. Convenience of typing, and the - desire to make domain names out of easily-remembered product names, - has led to a flattening of the DNS, with many people now perceiving - that second-level names under COM (or in some countries, second- or - third-level names under the relevant ccTLD) are all that is - meaningful. This perception has been reinforced by some domain name - registrars [REGISTRAR] who have been anxious to "sell" additional - names. And, of course, the perception that one needed a second-level - (or even top-level) domain per product, rather than having names - associated with a (usually organizational) collection of network - resources, has led to a rapid acceleration in the number of names - being registered. That acceleration has, in turn, clearly benefited - registrars charging on a per-name basis, "cybersquatters", and others - in the business of "selling" names, but it has not obviously - benefited the Internet as a whole. - - This emphasis on second-level domain names has also created a problem - for the trademark community. Since the Internet is international, - and names are being populated in a flat and unqualified space, - similarly-named entities are in conflict even if there would - ordinarily be no chance of confusing them in the marketplace. The - problem appears to be unsolvable except by a choice between draconian - measures. These might include significant changes to the legislation - and conventions that govern disputes over "names" and "marks". Or - - - -Klensin Informational [Page 6] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - they might result in a situation in which the "rights" to a name are - typically not settled using the subtle and traditional product (or - industry) type and geopolitical scope rules of the trademark system. - Instead they have depended largely on political or economic power, - e.g., the organization with the greatest resources to invest in - defending (or attacking) names will ultimately win out. The latter - raises not only important issues of equity, but also the risk of - backlash as the numerous small players are forced to relinquish names - they find attractive and to adopt less-desirable naming conventions. - - Independent of these sociopolitical problems, content distribution - issues have made it clear that it should be possible for an - organization to have copies of data it wishes to make available - distributed around the network, with a user who asks for the - information by name getting the topologically-closest copy. This is - not possible with simple, as-designed, use of the DNS: DNS names - identify target resources or, in the case of email "MX" records, a - preferentially-ordered list of resources "closest" to a target (not - to the source/user). Several technologies (and, in some cases, - corresponding business models) have arisen to work around these - problems, including intercepting and altering DNS requests so as to - point to other locations. - - Additional implications are still being discovered and evaluated. - - Approaches that involve interception of DNS queries and rewriting of - DNS names (or otherwise altering the resolution process based on the - topological location of the user) seem, however, to risk disrupting - end-to-end applications in the general case and raise many of the - issues discussed by the IAB in [IAB-OPES]. These problems occur even - if the rewriting machinery is accompanied by additional workarounds - for particular applications. For example, security associations and - applications that need to identify "the same host" often run into - problems if DNS names or other references are changed in the network - without participation of the applications that are trying to invoke - the associated services. - -1.4 Internet Applications Protocols and Their Evolution - - At the applications level, few of the protocols in active, - widespread, use on the Internet reflect either contemporary knowledge - in computer science or human factors or experience accumulated - through deployment and use. Instead, protocols tend to be deployed - at a just-past-prototype level, typically including the types of - expedient compromises typical with prototypes. If they prove useful, - the nature of the network permits very rapid dissemination (i.e., - they fill a vacuum, even if a vacuum that no one previously knew - existed). But, once the vacuum is filled, the installed base - - - -Klensin Informational [Page 7] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - provides its own inertia: unless the design is so seriously faulty as - to prevent effective use (or there is a widely-perceived sense of - impending disaster unless the protocol is replaced), future - developments must maintain backward compatibility and workarounds for - problematic characteristics rather than benefiting from redesign in - the light of experience. Applications that are "almost good enough" - prevent development and deployment of high-quality replacements. - - The DNS is both an illustration of, and an exception to, parts of - this pessimistic interpretation. It was a second-generation - development, with the host table system being seen as at the end of - its useful life. There was a serious attempt made to reflect the - computing state of the art at the time. However, deployment was much - slower than expected (and very painful for many sites) and some fixed - (although relaxed several times) deadlines from a central network - administration were necessary for deployment to occur at all. - Replacing it now, in order to add functionality, while it continues - to perform its core functions at least reasonably well, would - presumably be extremely difficult. - - There are many, perhaps obvious, examples of this. Despite many - known deficiencies and weaknesses of definition, the "finger" and - "whois" [WHOIS] protocols have not been replaced (despite many - efforts to update or replace the latter [WHOIS-UPDATE]). The Telnet - protocol and its many options drove out the SUPDUP [RFC734] one, - which was arguably much better designed for a diverse collection of - network hosts. A number of efforts to replace the email or file - transfer protocols with models which their advocates considered much - better have failed. And, more recently and below the applications - level, there is some reason to believe that this resistance to change - has been one of the factors impeding IPv6 deployment. - -2. Signs of DNS Overloading - - Parts of the historical discussion above identify areas in which the - DNS has become overloaded (semantically if not in the mechanical - ability to resolve names). Despite this overloading, it appears that - DNS performance and reliability are still within an acceptable range: - there is little evidence of serious performance degradation. Recent - proposals and mechanisms to better respond to overloading and scaling - issues have all focused on patching or working around limitations - that develop when the DNS is utilized for out-of-design functions, - rather than on dramatic rethinking of either DNS design or those - uses. The number of these issues that have arisen at much the same - time may argue for just that type of rethinking, and not just for - adding complexity and attempting to incrementally alter the design - (see, for example, the discussion of simplicity in section 2 of - [RFC3439]). - - - -Klensin Informational [Page 8] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - For example: - - o While technical approaches such as larger and higher-powered - servers and more bandwidth, and legal/political mechanisms such as - dispute resolution policies, have arguably kept the problems from - becoming critical, the DNS has not proven adequately responsive to - business and individual needs to describe or identify things (such - as product names and names of individuals) other than strict - network resources. - - o While stacks have been modified to better handle multiple - addresses on a physical interface and some protocols have been - extended to include DNS names for determining context, the DNS - does not deal especially well with many names associated with a - given host (e.g., web hosting facilities with multiple domains on - a server). - - o Efforts to add names deriving from languages or character sets - based on other than simple ASCII and English-like names (see - below), or even to utilize complex company or product names - without the use of hierarchy, have created apparent requirements - for names (labels) that are over 63 octets long. This requirement - will undoubtedly increase over time; while there are workarounds - to accommodate longer names, they impose their own restrictions - and cause their own problems. - - o Increasing commercialization of the Internet, and visibility of - domain names that are assumed to match names of companies or - products, has turned the DNS and DNS names into a trademark - battleground. The traditional trademark system in (at least) most - countries makes careful distinctions about fields of - applicability. When the space is flattened, without - differentiation by either geography or industry sector, not only - are there likely conflicts between "Joe's Pizza" (of Boston) and - "Joe's Pizza" (of San Francisco) but between both and "Joe's Auto - Repair" (of Los Angeles). All three would like to control - "Joes.com" (and would prefer, if it were permitted by DNS naming - rules, to also spell it as "Joe's.com" and have both resolve the - same way) and may claim trademark rights to do so, even though - conflict or confusion would not occur with traditional trademark - principles. - - o Many organizations wish to have different web sites under the same - URL and domain name. Sometimes this is to create local variations - -- the Widget Company might want to present different material to - a UK user relative to a US one -- and sometimes it is to provide - higher performance by supplying information from the server - topologically closest to the user. If the name resolution - - - -Klensin Informational [Page 9] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - mechanism is expected to provide this functionality, there are - three possible models (which might be combined): - - - supply information about multiple sites (or locations or - references). Those sites would, in turn, provide information - associated with the name and sufficient site-specific - attributes to permit the application to make a sensible choice - of destination, or - - - accept client-site attributes and utilize them in the search - process, or - - - return different answers based on the location or identity of - the requestor. - - While there are some tricks that can provide partial simulations of - these types of function, DNS responses cannot be reliably conditioned - in this way. - - These, and similar, issues of performance or content choices can, of - course, be thought of as not involving the DNS at all. For example, - the commonly-cited alternate approach of coupling these issues to - HTTP content negotiation (cf. [RFC2295]), requires that an HTTP - connection first be opened to some "common" or "primary" host so that - preferences can be negotiated and then the client redirected or sent - alternate data. At least from the standpoint of improving - performance by accessing a "closer" location, both initially and - thereafter, this approach sacrifices the desired result before the - client initiates any action. It could even be argued that some of - the characteristics of common content negotiation approaches are - workarounds for the non-optimal use of the DNS in web URLs. - - o Many existing and proposed systems for "finding things on the - Internet" require a true search capability in which near matches - can be reported to the user (or to some user agent with an - appropriate rule-set) and to which queries may be ambiguous or - fuzzy. The DNS, by contrast, can accommodate only one set of - (quite rigid) matching rules. Proposals to permit different rules - in different localities (e.g., matching rules that are TLD- or - zone-specific) help to identify the problem. But they cannot be - applied directly to the DNS without either abandoning the desired - level of flexibility or isolating different parts of the Internet - from each other (or both). Fuzzy or ambiguous searches are - desirable for resolution of names that might have spelling - variations and for names that can be resolved into different sets - of glyphs depending on context. Especially when - internationalization is considered, variant name problems go - beyond simple differences in representation of a character or - - - -Klensin Informational [Page 10] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - ordering of a string. Instead, avoiding user astonishment and - confusion requires consideration of relationships such as - languages that can be written with different alphabets, Kanji- - Hiragana relationships, Simplified and Traditional Chinese, etc. - See [Seng] for a discussion and suggestions for addressing a - subset of these issues in the context of characters based on - Chinese ones. But that document essentially illustrates the - difficulty of providing the type of flexible matching that would - be anticipated by users; instead, it tries to protect against the - worst types of confusion (and opportunities for fraud). - - o The historical DNS, and applications that make assumptions about - how it works, impose significant risk (or forces technical kludges - and consequent odd restrictions), when one considers adding - mechanisms for use with various multi-character-set and - multilingual "internationalization" systems. See the IAB's - discussion of some of these issues [RFC2825] for more information. - - o In order to provide proper functionality to the Internet, the DNS - must have a single unique root (the IAB provides more discussion - of this issue [RFC2826]). There are many desires for local - treatment of names or character sets that cannot be accommodated - without either multiple roots (e.g., a separate root for - multilingual names, proposed at various times by MINC [MINC] and - others), or mechanisms that would have similar effects in terms of - Internet fragmentation and isolation. - - o For some purposes, it is desirable to be able to search not only - an index entry (labels or fully-qualified names in the DNS case), - but their values or targets (DNS data). One might, for example, - want to locate all of the host (and virtual host) names which - cause mail to be directed to a given server via MX records. The - DNS does not support this capability (see the discussion in - [IQUERY]) and it can be simulated only by extracting all of the - relevant records (perhaps by zone transfer if the source permits - doing so, but that permission is becoming less frequently - available) and then searching a file built from those records. - - o Finally, as additional types of personal or identifying - information are added to the DNS, issues arise with protection of - that information. There are increasing calls to make different - information available based on the credentials and authorization - of the source of the inquiry. As with information keyed to site - locations or proximity (as discussed above), the DNS protocols - make providing these differentiated services quite difficult if - not impossible. - - - - - -Klensin Informational [Page 11] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - In each of these cases, it is, or might be, possible to devise ways - to trick the DNS system into supporting mechanisms that were not - designed into it. Several ingenious solutions have been proposed in - many of these areas already, and some have been deployed into the - marketplace with some success. But the price of each of these - changes is added complexity and, with it, added risk of unexpected - and destabilizing problems. - - Several of the above problems are addressed well by a good directory - system (supported by the LDAP protocol or some protocol more - precisely suited to these specific applications) or searching - environment (such as common web search engines) although not by the - DNS. Given the difficulty of deploying new applications discussed - above, an important question is whether the tricks and kludges are - bad enough, or will become bad enough as usage grows, that new - solutions are needed and can be deployed. - -3. Searching, Directories, and the DNS - -3.1 Overview - - The constraints of the DNS and the discussion above suggest the - introduction of an intermediate protocol mechanism, referred to below - as a "search layer" or "searchable system". The terms "directory" - and "directory system" are used interchangeably with "searchable - system" in this document, although the latter is far more precise. - Search layer proposals would use a two (or more) stage lookup, not - unlike several of the proposals for internationalized names in the - DNS (see section 4), but all operations but the final one would - involve searching other systems, rather than looking up identifiers - in the DNS itself. As explained below, this would permit relaxation - of several constraints, leading to a more capable and comprehensive - overall system. - - Ultimately, many of the issues with domain names arise as the result - of efforts to use the DNS as a directory. While, at the time this - document was written, sufficient pressure or demand had not occurred - to justify a change, it was already quite clear that, as a directory - system, the DNS is a good deal less than ideal. This document - suggests that there actually is a requirement for a directory system, - and that the right solution to a searchable system requirement is a - searchable system, not a series of DNS patches, kludges, or - workarounds. - - - - - - - - -Klensin Informational [Page 12] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - The following points illustrate particular aspects of this - conclusion. - - o A directory system would not require imposition of particular - length limits on names. - - o A directory system could permit explicit association of - attributes, e.g., language and country, with a name, without - having to utilize trick encodings to incorporate that information - in DNS labels (or creating artificial hierarchy for doing so). - - o There is considerable experience (albeit not much of it very - successful) in doing fuzzy and "sonex" (similar-sounding) matching - in directory systems. Moreover, it is plausible to think about - different matching rules for different areas and sets of names so - that these can be adapted to local cultural requirements. - Specifically, it might be possible to have a single form of a name - in a directory, but to have great flexibility about what queries - matched that name (and even have different variations in different - areas). Of course, the more flexibility that a system provides, - the greater the possibility of real or imagined trademark - conflicts. But the opportunity would exist to design a directory - structure that dealt with those issues in an intelligent way, - while DNS constraints almost certainly make a general and - equitable DNS-only solution impossible. - - o If a directory system is used to translate to DNS names, and then - DNS names are looked up in the normal fashion, it may be possible - to relax several of the constraints that have been traditional - (and perhaps necessary) with the DNS. For example, reverse- - mapping of addresses to directory names may not be a requirement - even if mapping of addresses to DNS names continues to be, since - the DNS name(s) would (continue to) uniquely identify the host. - - o Solutions to multilingual transcription problems that are common - in "normal life" (e.g., two-sided business cards to be sure that - recipients trying to contact a person can access romanized - spellings and numbers if the original language is not - comprehensible to them) can be easily handled in a directory - system by inserting both sets of entries. - - o A directory system could be designed that would return, not a - single name, but a set of names paired with network-locational - information or other context-establishing attributes. This type - of information might be of considerable use in resolving the - "nearest (or best) server for a particular named resource" - - - - - -Klensin Informational [Page 13] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - problems that are a significant concern for organizations hosting - web and other sites that are accessed from a wide range of - locations and subnets. - - o Names bound to countries and languages might help to manage - trademark realities, while, as discussed in section 1.3 above, use - of the DNS in trademark-significant contexts tends to require - worldwide "flattening" of the trademark system. - - Many of these issues are a consequence of another property of the - DNS: names must be unique across the Internet. The need to have a - system of unique identifiers is fairly obvious (see [RFC2826]). - However, if that requirement were to be eliminated in a search or - directory system that was visible to users instead of the DNS, many - difficult problems -- of both an engineering and a policy nature -- - would be likely to vanish. - -3.2 Some Details and Comments - - Almost any internationalization proposal for names that are in, or - map into, the DNS will require changing DNS resolver API calls - ("gethostbyname" or equivalent), or adding some pre-resolution - preparation mechanism, in almost all Internet applications -- whether - to cause the API to take a different character set (no matter how it - is then mapped into the bits used in the DNS or another system), to - accept or return more arguments with qualifying or identifying - information, or otherwise. Once applications must be opened to make - such changes, it is a relatively small matter to switch from calling - into the DNS to calling a directory service and then the DNS (in many - situations, both actions could be accomplished in a single API call). - - A directory approach can be consistent both with "flat" models and - multi-attribute ones. The DNS requires strict hierarchies, limiting - its ability to differentiate among names by their properties. By - contrast, modern directories can utilize independently-searched - attributes and other structured schema to provide flexibilities not - present in a strictly hierarchical system. - - There is a strong historical argument for a single directory - structure (implying a need for mechanisms for registration, - delegation, etc.). But a single structure is not a strict - requirement, especially if in-depth case analysis and design work - leads to the conclusion that reverse-mapping to directory names is - not a requirement (see section 5). If a single structure is not - needed, then, unlike the DNS, there would be no requirement for a - global organization to authorize or delegate operation of portions of - the structure. - - - - -Klensin Informational [Page 14] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - The "no single structure" concept could be taken further by moving - away from simple "names" in favor of, e.g., multiattribute, - multihierarchical, faceted systems in which most of the facets use - restricted vocabularies. (These terms are fairly standard in the - information retrieval and classification system literature, see, - e.g., [IS5127].) Such systems could be designed to avoid the need - for procedures to ensure uniqueness across, or even within, providers - and databases of the faceted entities for which the search is to be - performed. (See [DNS-Search] for further discussion.) - - While the discussion above includes very general comments about - attributes, it appears that only a very small number of attributes - would be needed. The list would almost certainly include country and - language for internationalization purposes. It might require - "charset" if we cannot agree on a character set and encoding, - although there are strong arguments for simply using ISO 10646 (also - known as Unicode or "UCS" (for Universal Character Set) [UNICODE], - [IS10646] coding in interchange. Trademark issues might motivate - "commercial" and "non-commercial" (or other) attributes if they would - be helpful in bypassing trademark problems. And applications to - resource location, such as those contemplated for Uniform Resource - Identifiers (URIs) [RFC2396, RFC3305] or the Service Location - Protocol [RFC2608], might argue for a few other attributes (as - outlined above). - -4. Internationalization - - Much of the thinking underlying this document was driven by - considerations of internationalizing the DNS or, more specifically, - providing access to the functions of the DNS from languages and - naming systems that cannot be accurately expressed in the traditional - DNS subset of ASCII. Much of the relevant work was done in the - IETF's "Internationalized Domain Names" Working Group (IDN-WG), - although this document also draws on extensive parallel discussions - in other forums. This section contains an evaluation of what was - learned as an "internationalized DNS" or "multilingual DNS" was - explored and suggests future steps based on that evaluation. - - When the IDN-WG was initiated, it was obvious to several of the - participants that its first important task was an undocumented one: - to increase the understanding of the complexities of the problem - sufficiently that naive solutions could be rejected and people could - go to work on the harder problems. The IDN-WG clearly accomplished - that task. The beliefs that the problems were simple, and in the - corresponding simplistic approaches and their promises of quick and - painless deployment, effectively disappeared as the WG's efforts - matured. - - - - -Klensin Informational [Page 15] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - Some of the lessons learned from increased understanding and the - dissipation of naive beliefs should be taken as cautions by the wider - community: the problems are not simple. Specifically, extracting - small elements for solution rather than looking at whole systems, may - result in obscuring the problems but not solving any problem that is - worth the trouble. - -4.1 ASCII Isn't Just Because of English - - The hostname rules chosen in the mid-70s weren't just "ASCII because - English uses ASCII", although that was a starting point. We have - discovered that almost every other script (and even ASCII if we - permit the rest of the characters specified in the ISO 646 - International Reference Version) is more complex than hostname- - restricted-ASCII (the "LDH" form, see section 1.1). And ASCII isn't - sufficient to completely represent English -- there are several words - in the language that are correctly spelled only with characters or - diacritical marks that do not appear in ASCII. With a broader - selection of scripts, in some examples, case mapping works from one - case to the other but is not reversible. In others, there are - conventions about alternate ways to represent characters (in the - language, not [only] in character coding) that work most of the time, - but not always. And there are issues in coding, with Unicode/10646 - providing different ways to represent the same character - ("character", rather than "glyph", is used deliberately here). And, - in still others, there are questions as to whether two glyphs - "match", which may be a distance-function question, not one with a - binary answer. The IETF approach to these problems is to require - pre-matching canonicalization (see the "stringprep" discussion - below). - - The IETF has resisted the temptations to either try to specify an - entirely new coded character set, or to pick and choose Unicode/10646 - characters on a per-character basis rather than by using well-defined - blocks. While it may appear that a character set designed to meet - Internet-specific needs would be very attractive, the IETF has never - had the expertise, resources, and representation from critically- - important communities to actually take on that job. Perhaps more - important, a new effort might have chosen to make some of the many - complex tradeoffs differently than the Unicode committee did, - producing a code with somewhat different characteristics. But there - is no evidence that doing so would produce a code with fewer problems - and side-effects. It is much more likely that making tradeoffs - differently would simply result in a different set of problems, which - would be equally or more difficult. - - - - - - -Klensin Informational [Page 16] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - -4.2 The "ASCII Encoding" Approaches - - While the DNS can handle arbitrary binary strings without known - internal problems (see [RFC2181]), some restrictions are imposed by - the requirement that text be interpreted in a case-independent way - ([RFC1034], [RFC1035]). More important, most internet applications - assume the hostname-restricted "LDH" syntax that is specified in the - host table RFCs and as "prudent" in RFC 1035. If those assumptions - are not met, many conforming implementations of those applications - may exhibit behavior that would surprise implementors and users. To - avoid these potential problems, IETF internationalization work has - focused on "ASCII-Compatible Encodings" (ACE). These encodings - preserve the LDH conventions in the DNS itself. Implementations of - applications that have not been upgraded utilize the encoded forms, - while newer ones can be written to recognize the special codings and - map them into non-ASCII characters. These approaches are, however, - not problem-free even if human interface issues are ignored. Among - other issues, they rely on what is ultimately a heuristic to - determine whether a DNS label is to be considered as an - internationalized name (i.e., encoded Unicode) or interpreted as an - actual LDH name in its own right. And, while all determinations of - whether a particular query matches a stored object are traditionally - made by DNS servers, the ACE systems, when combined with the - complexities of international scripts and names, require that much of - the matching work be separated into a separate, client-side, - canonicalization or "preparation" process before the DNS matching - mechanisms are invoked [STRINGPREP]. - -4.3 "Stringprep" and Its Complexities - - As outlined above, the model for avoiding problems associated with - putting non-ASCII names in the DNS and elsewhere evolved into the - principle that strings are to be placed into the DNS only after being - passed through a string preparation function that eliminates or - rejects spurious character codes, maps some characters onto others, - performs some sequence canonicalization, and generally creates forms - that can be accurately compared. The impact of this process on - hostname-restricted ASCII (i.e., "LDH") strings is trivial and - essentially adds only overhead. For other scripts, the impact is, of - necessity, quite significant. - - Although the general notion underlying stringprep is simple, the many - details are quite subtle and the associated tradeoffs are complex. A - design team worked on it for months, with considerable effort placed - into clarifying and fine-tuning the protocol and tables. Despite - general agreement that the IETF would avoid getting into the business - of defining character sets, character codings, and the associated - conventions, the group several times considered and rejected special - - - -Klensin Informational [Page 17] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - treatment of code positions to more nearly match the distinctions - made by Unicode with user perceptions about similarities and - differences between characters. But there were intense temptations - (and pressures) to incorporate language-specific or country-specific - rules. Those temptations, even when resisted, were indicative of - parts of the ongoing controversy or of the basic unsuitability of the - DNS for fully internationalized names that are visible, - comprehensible, and predictable for end users. - - There have also been controversies about how far one should go in - these processes of preparation and transformation and, ultimately, - about the validity of various analogies. For example, each of the - following operations has been claimed to be similar to case-mapping - in ASCII: - - o stripping of vowels in Arabic or Hebrew - - o matching of "look-alike" characters such as upper-case Alpha in - Greek and upper-case A in Roman-based alphabets - - o matching of Traditional and Simplified Chinese characters that - represent the same words, - - o matching of Serbo-Croatian words whether written in Roman-derived - or Cyrillic characters - - A decision to support any of these operations would have implications - for other scripts or languages and would increase the overall - complexity of the process. For example, unless language-specific - information is somehow available, performing matching between - Traditional and Simplified Chinese has impacts on Japanese and Korean - uses of the same "traditional" characters (e.g., it would not be - appropriate to map Kanji into Simplified Chinese). - - Even were the IDN-WG's other work to have been abandoned completely - or if it were to fail in the marketplace, the stringprep and nameprep - work will continue to be extremely useful, both in identifying issues - and problem code points and in providing a reasonable set of basic - rules. Where problems remain, they are arguably not with nameprep, - but with the DNS-imposed requirement that its results, as with all - other parts of the matching and comparison process, yield a binary - "match or no match" answer, rather than, e.g., a value on a - similarity scale that can be evaluated by the user or by user-driven - heuristic functions. - - - - - - - -Klensin Informational [Page 18] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - -4.4 The Unicode Stability Problem - - ISO 10646 basically defines only code points, and not rules for using - or comparing the characters. This is part of a long-standing - tradition with the work of what is now ISO/IEC JTC1/SC2: they have - performed code point assignments and have typically treated the ways - in which characters are used as beyond their scope. Consequently, - they have not dealt effectively with the broader range of - internationalization issues. By contrast, the Unicode Technical - Committee (UTC) has defined, in annexes and technical reports (see, - e.g., [UTR15]), some additional rules for canonicalization and - comparison. Many of those rules and conventions have been factored - into the "stringprep" and "nameprep" work, but it is not - straightforward to make or define them in a fashion that is - sufficiently precise and permanent to be relied on by the DNS. - - Perhaps more important, the discussions leading to nameprep also - identified several areas in which the UTC definitions are inadequate, - at least without additional information, to make matching precise and - unambiguous. In some of these cases, the Unicode Standard permits - several alternate approaches, none of which are an exact and obvious - match to DNS needs. That has left these sensitive choices up to - IETF, which lacks sufficient in-depth expertise, much less any - mechanism for deciding to optimize one language at the expense of - another. - - For example, it is tempting to define some rules on the basis of - membership in particular scripts, or for punctuation characters, but - there is no precise definition of what characters belong to which - script or which ones are, or are not, punctuation. The existence of - these areas of vagueness raises two issues: whether trying to do - precise matching at the character set level is actually possible - (addressed below) and whether driving toward more precision could - create issues that cause instability in the implementation and - resolution models for the DNS. - - The Unicode definition also evolves. Version 3.2 appeared shortly - after work on this document was initiated. It added some characters - and functionality and included a few minor incompatible code point - changes. IETF has secured an agreement about constraints on future - changes, but it remains to be seen how that agreement will work out - in practice. The prognosis actually appears poor at this stage, - since UTC chose to ballot a recent possible change which should have - been prohibited by the agreement (the outcome of the ballot is not - relevant, only that the ballot was issued rather than having the - result be a foregone conclusion). However, some members of the - community consider some of the changes between Unicode 3.0 and 3.1 - and between 3.1 and 3.2, as well as this recent ballot, to be - - - -Klensin Informational [Page 19] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - evidence of instability and that these instabilities are better - handled in a system that can be more flexible about handling of - characters, scripts, and ancillary information than the DNS. - - In addition, because the systems implications of internationalization - are considered out of scope in SC2, ISO/IEC JTC1 has assigned some of - those issues to its SC22/WG20 (the Internationalization working group - within the subcommittee that deals with programming languages, - systems, and environments). WG20 has historically dealt with - internationalization issues thoughtfully and in depth, but its status - has several times been in doubt in recent years. However, assignment - of these matters to WG20 increases the risk of eventual ISO - internationalization standards that specify different behavior than - the UTC specifications. - -4.5 Audiences, End Users, and the User Interface Problem - - Part of what has "caused" the DNS internationalization problem, as - well as the DNS trademark problem and several others, is that we have - stopped thinking about "identifiers for objects" -- which normal - people are not expected to see -- and started thinking about "names" - -- strings that are expected not only to be readable, but to have - linguistically-sensible and culturally-dependent meaning to non- - specialist users. - - Within the IETF, the IDN-WG, and sometimes other groups, avoided - addressing the implications of that transition by taking "outside our - scope -- someone else's problem" approaches or by suggesting that - people will just become accustomed to whatever conventions are - adopted. The realities of user and vendor behavior suggest that - these approaches will not serve the Internet community well in the - long term: - - o If we want to make it a problem in a different part of the user - interface structure, we need to figure out where it goes in order - to have proof of concept of our solution. Unlike vendors whose - sole [business] model is the selling or registering of names, the - IETF must produce solutions that actually work, in the - applications context as seen by the end user. - - o The principle that "they will get used to our conventions and - adapt" is fine if we are writing rules for programming languages - or an API. But the conventions under discussion are not part of a - semi-mathematical system, they are deeply ingrained in culture. - No matter how often an English-speaking American is told that the - Internet requires that the correct spelling of "colour" be used, - he or she isn't going to be convinced. Getting a French-speaker in - Lyon to use exactly the same lexical conventions as a French- - - - -Klensin Informational [Page 20] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - speaker in Quebec in order to accommodate the decisions of the - IETF or of a registrar or registry is just not likely. "Montreal" - is either a misspelling or an anglicization of a similar word with - an acute accent mark over the "e" (i.e., using the Unicode - character U+00E9 or one of its equivalents). But global agreement - on a rule that will determine whether the two forms should match - -- and that won't astonish end users and speakers of one language - or the other -- is as unlikely as agreement on whether - "misspelling" or "anglicization" is the greater travesty. - - More generally, it is not clear that the outcome of any conceivable - nameprep-like process is going to be good enough for practical, - user-level, use. In the use of human languages by humans, there are - many cases in which things that do not match are nonetheless - interpreted as matching. The Norwegian/Danish character that appears - in U+00F8 (visually, a lower case 'o' overstruck with a forward - slash) and the "o-umlaut" German character that appears in U+00F6 - (visually, a lower case 'o' with diaeresis (or umlaut)) are clearly - different and no matching program should yield an "equal" comparison. - But they are more similar to each other than either of them is to, - e.g., "e". Humans are able to mentally make the correction in - context, and do so easily, and they can be surprised if computers - cannot do so. Worse, there is a Swedish character whose appearance - is identical to the German o-umlaut, and which shares code point - U+00F6, but that, if the languages are known and the sounds of the - letters or meanings of words including the character are considered, - actually should match the Norwegian/Danish use of U+00F8. - - This text uses examples in Roman scripts because it is being written - in English and those examples are relatively easy to render. But one - of the important lessons of the discussions about domain name - internationalization in recent years is that problems similar to - those described above exist in almost every language and script. - Each one has its idiosyncrasies, and each set of idiosyncracies is - tied to common usage and cultural issues that are very familiar in - the relevant group, and often deeply held as cultural values. As - long as a schoolchild in the US can get a bad grade on a spelling - test for using a perfectly valid British spelling, or one in France - or Germany can get a poor grade for leaving off a diacritical mark, - there are issues with the relevant language. Similarly, if children - in Egypt or Israel are taught that it is acceptable to write a word - with or without vowels or stress marks, but that, if those marks are - included, they must be the correct ones, or a user in Korea is - potentially offended or astonished by out-of-order sequences of Jamo, - systems based on character-at-a-time processing and simplistic - matching, with no contextual information, are not going to satisfy - user needs. - - - - -Klensin Informational [Page 21] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - Users are demanding solutions that deal with language and culture. - Systems of identifier symbol-strings that serve specialists or - computers are, at best, a solution to a rather different (and, at the - time this document was written, somewhat ill-defined), problem. The - recent efforts have made it ever more clear that, if we ignore the - distinction between the user requirements and narrowly-defined - identifiers, we are solving an insufficient problem. And, - conversely, the approaches that have been proposed to approximate - solutions to the user requirement may be far more complex than simple - identifiers require. - -4.6 Business Cards and Other Natural Uses of Natural Languages - - Over the last few centuries, local conventions have been established - in various parts of the world for dealing with multilingual - situations. It may be helpful to examine some of these. For - example, if one visits a country where the language is different from - ones own, business cards are often printed on two sides, one side in - each language. The conventions are not completely consistent and the - technique assumes that recipients will be tolerant. Translations of - names or places are attempted in some situations and transliterations - in others. Since it is widely understood that exact translations or - transliterations are often not possible, people typically smile at - errors, appreciate the effort, and move on. - - The DNS situation differs from these practices in at least two ways. - Since a global solution is required, the business card would need a - number of sides approximating the number of languages in the world, - which is probably impossible without violating laws of physics. More - important, the opportunities for tolerance don't exist: the DNS - requires a exact match or the lookup fails. - -4.7 ASCII Encodings and the Roman Keyboard Assumption - - Part of the argument for ACE-based solutions is that they provide an - escape for multilingual environments when applications have not been - upgraded. When an older application encounters an ACE-based name, - the assumption is that the (admittedly ugly) ASCII-coded string will - be displayed and can be typed in. This argument is reasonable from - the standpoint of mixtures of Roman-based alphabets, but may not be - relevant if user-level systems and devices are involved that do not - support the entry of Roman-based characters or which cannot - conveniently render such characters. Such systems are few in the - world today, but the number can reasonably be expected to rise as the - Internet is increasingly used by populations whose primary concern is - with local issues, local information, and local languages. It is, - - - - - -Klensin Informational [Page 22] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - for example, fairly easy to imagine populations who use Arabic or - Thai scripts and who do not have routine access to scripts or input - devices based on Roman-derived alphabets. - -4.8 Intra-DNS Approaches for "Multilingual Names" - - It appears, from the cases above and others, that none of the intra- - DNS-based solutions for "multilingual names" are workable. They rest - on too many assumptions that do not appear to be feasible -- that - people will adapt deeply-entrenched language habits to conventions - laid down to make the lives of computers easy; that we can make - "freeze it now, no need for changes in these areas" decisions about - Unicode and nameprep; that ACE will smooth over applications - problems, even in environments without the ability to key or render - Roman-based glyphs (or where user experience is such that such glyphs - cannot easily be distinguished from each other); that the Unicode - Consortium will never decide to repair an error in a way that creates - a risk of DNS incompatibility; that we can either deploy EDNS - [RFC2671] or that long names are not really important; that Japanese - and Chinese computer users (and others) will either give up their - local or IS 2022-based character coding solutions (for which addition - of a large fraction of a million new code points to Unicode is almost - certainly a necessary, but probably not sufficient, condition) or - build leakproof and completely accurate boundary conversion - mechanisms; that out of band or contextual information will always be - sufficient for the "map glyph onto script" problem; and so on. In - each case, it is likely that about 80% or 90% of cases will work - satisfactorily, but it is unlikely that such partial solutions will - be good enough. For example, suppose someone can spell her name 90% - correctly, or a company name is matched correctly 80% of the time but - the other 20% of attempts identify a competitor: are either likely to - be considered adequate? - -5. Search-based Systems: The Key Controversies - - For many years, a common response to requirements to locate people or - resources on the Internet has been to invoke the term "directory". - While an in-depth analysis of the reasons would require a separate - document, the history of failure of these invocations has given - "directory" efforts a bad reputation. The effort proposed here is - different from those predecessors for several reasons, perhaps the - most important of which is that it focuses on a fairly-well- - understood set of problems and needs, rather than on finding uses for - a particular technology. - - As suggested in some of the text above, it is an open question as to - whether the needs of the community would be best served by a single - (even if functionally, and perhaps administratively, distributed) - - - -Klensin Informational [Page 23] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - directory with universal applicability, a single directory that - supports locally-tailored search (and, most important, matching) - functions, or multiple, locally-determined, directories. Each has - its attractions. Any but the first would essentially prevent - reverse-mapping (determination of the user-visible name of the host - or resource from target information such as an address or DNS name). - But reverse mapping has become less useful over the years --at least - to users -- as more and more names have been associated with many - host addresses and as CIDR [CIDR] has proven problematic for mapping - smaller address blocks to meaningful names. - - Locally-tailored searches and mappings would permit national - variations on interpretation of which strings matched which other - ones, an arrangement that is especially important when different - localities apply different rules to, e.g., matching of characters - with and without diacriticals. But, of course, this implies that a - URL may evaluate properly or not depending on either settings on a - client machine or the network connectivity of the user. That is not, - in general, a desirable situation, since it implies that users could - not, in the general case, share URLs (or other host references) and - that a particular user might not be able to carry references from one - host or location to another. - - And, of course, completely separate directories would permit - translation and transliteration functions to be embedded in the - directory, giving much of the Internet a different appearance - depending on which directory was chosen. The attractions of this are - obvious, but, unless things were very carefully designed to preserve - uniqueness and precise identities at the right points (which may or - may not be possible), such a system would have many of the - difficulties associated with multiple DNS roots. - - Finally, a system of separate directories and databases, if coupled - with removal of the DNS-imposed requirement for unique names, would - largely eliminate the need for a single worldwide authority to manage - the top of the naming hierarchy. - -6. Security Considerations - - The set of proposals implied by this document suggests an interesting - set of security issues (i.e., nothing important is ever easy). A - directory system used for locating network resources would presumably - need to be as carefully protected against unauthorized changes as the - DNS itself. There also might be new opportunities for problems in an - arrangement involving two or more (sub)layers, especially if such a - system were designed without central authority or uniqueness of - names. It is uncertain how much greater those risks would be as - compared to a DNS lookup sequence that involved looking up one name, - - - -Klensin Informational [Page 24] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - getting back information, and then doing additional lookups - potentially in different subtrees. That multistage lookup will often - be the case with, e.g., NAPTR records [RFC 2915] unless additional - restrictions are imposed. But additional steps, systems, and - databases almost certainly involve some additional risks of - compromise. - -7. References - -7.1 Normative References - - None - -7.2 Explanatory and Informative References - - [Albitz] Any of the editions of Albitz, P. and C. Liu, DNS and - BIND, O'Reilly and Associates, 1992, 1997, 1998, 2001. - - [ASCII] American National Standards Institute (formerly United - States of America Standards Institute), X3.4, 1968, - "USA Code for Information Interchange". ANSI X3.4-1968 - has been replaced by newer versions with slight - modifications, but the 1968 version remains definitive - for the Internet. Some time after ASCII was first - formulated as a standard, ISO adopted international - standard 646, which uses ASCII as a base. IS 646 - actually contained two code tables: an "International - Reference Version" (often referenced as ISO 646-IRV) - which was essentially identical to the ASCII of the - time, and a "Basic Version" (ISO 646-BV), which - designates a number of character positions for - national use. - - [CIDR] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless - Inter-Domain Routing (CIDR): an Address Assignment and - Aggregation Strategy", RFC 1519, September 1993. - - Eidnes, H., de Groot, G. and P. Vixie, "Classless IN- - ADDR.ARPA delegation", RFC 2317, March 1998. - - [COM-SIZE] Size information supplied by Verisign Global Registry - Services (the zone administrator, or "registry - operator", for COM, see [REGISTRAR], below) to ICANN, - third quarter 2002. - - [DNS-Search] Klensin, J., "A Search-based access model for the - DNS", Work in Progress. - - - - -Klensin Informational [Page 25] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - [FINGER] Zimmerman, D., "The Finger User Information Protocol", - RFC 1288, December 1991. - - Harrenstien, K., "NAME/FINGER Protocol", RFC 742, - December 1977. - - [IAB-OPES] Floyd, S. and L. Daigle, "IAB Architectural and Policy - Considerations for Open Pluggable Edge Services", RFC - 3238, January 2002. - - [IQUERY] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November - 2002. - - [IS646] ISO/IEC 646:1991 Information technology -- ISO 7-bit - coded character set for information interchange - - [IS10646] ISO/IEC 10646-1:2000 Information technology -- - Universal Multiple-Octet Coded Character Set (UCS) -- - Part 1: Architecture and Basic Multilingual Plane and - ISO/IEC 10646-2:2001 Information technology -- - Universal Multiple-Octet Coded Character Set (UCS) -- - Part 2: Supplementary Planes - - [MINC] The Multilingual Internet Names Consortium, - http://www.minc.org/ has been an early advocate for - the importance of expansion of DNS names to - accommodate non-ASCII characters. Some of their - specific proposals, while helping people to understand - the problems better, were not compatible with the - design of the DNS. - - [NAPTR] Mealling, M. and R. Daniel, "The Naming Authority - Pointer (NAPTR) DNS Resource Record", RFC 2915, - September 2000. - - Mealling, M., "Dynamic Delegation Discovery System - (DDDS) Part One: The Comprehensive DDDS", RFC 3401, - October 2002. - - Mealling, M., "Dynamic Delegation Discovery System - (DDDS) Part Two: The Algorithm", RFC 3402, October - 2002. - - Mealling, M., "Dynamic Delegation Discovery System - (DDDS) Part Three: The Domain Name System (DNS) - Database", RFC 3403, October 2002. - - - - - -Klensin Informational [Page 26] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - [REGISTRAR] In an early stage of the process that created the - Internet Corporation for Assigned Names and Numbers - (ICANN), a "Green Paper" was released by the US - Government. That paper introduced new terminology - and some concepts not needed by traditional DNS - operations. The term "registry" was applied to the - actual operator and database holder of a domain - (typically at the top level, since the Green Paper was - little concerned with anything else), while - organizations that marketed names and made them - available to "registrants" were known as "registrars". - In the classic DNS model, the function of "zone - administrator" encompassed both registry and registrar - roles, although that model did not anticipate a - commercial market in names. - - [RFC625] Kudlick, M. and E. Feinler, "On-line hostnames - service", RFC 625, March 1974. - - [RFC734] Crispin, M., "SUPDUP Protocol", RFC 734, October 1977. - - [RFC811] Harrenstien, K., White, V. and E. Feinler, "Hostnames - Server", RFC 811, March 1982. - - [RFC819] Su, Z. and J. Postel, "Domain naming convention for - Internet user applications", RFC 819, August 1982. - - [RFC830] Su, Z., "Distributed system for Internet name - service", RFC 830, October 1982. - - [RFC882] Mockapetris, P., "Domain names: Concepts and - facilities", RFC 882, November 1983. - - [RFC883] Mockapetris, P., "Domain names: Implementation - specification", RFC 883, November 1983. - - [RFC952] Harrenstien, K, Stahl, M. and E. Feinler, "DoD - Internet host table specification", RFC 952, October - 1985. - - [RFC953] Harrenstien, K., Stahl, M. and E. Feinler, "HOSTNAME - SERVER", RFC 953, October 1985. - - [RFC1034] Mockapetris, P., "Domain names, Concepts and - facilities", STD 13, RFC 1034, November 1987. - - - - - - -Klensin Informational [Page 27] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1591] Postel, J., "Domain Name System Structure and - Delegation", RFC 1591, March 1994. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2295] Holtman, K. and A. Mutz, "Transparent Content - Negotiation in HTTP", RFC 2295, March 1998 - - [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, - "Uniform Resource Identifiers (URI): Generic Syntax", - RFC 2396, August 1998. - - [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, - "Service Location Protocol, Version 2", RFC 2608, June - 1999. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC2825] IAB, Daigle, L., Ed., "A Tangled Web: Issues of I18N, - Domain Names, and the Other Internet protocols", RFC - 2825, May 2000. - - [RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root", - RFC 2826, May 2000. - - [RFC2972] Popp, N., Mealling, M., Masinter, L. and K. Sollins, - "Context and Goals for Common Name Resolution", RFC - 2972, October 2000. - - [RFC3305] Mealling, M. and R. Denenberg, Eds., "Report from the - Joint W3C/IETF URI Planning Interest Group: Uniform - Resource Identifiers (URIs), URLs, and Uniform - Resource Names (URNs): Clarifications and - Recommendations", RFC 3305, August 2002. - - [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural - Guidelines and Philosophy", RFC 3439, December 2002. - - [Seng] Seng, J., et al., Eds., "Internationalized Domain - Names: Registration and Administration Guideline for - Chinese, Japanese, and Korean", Work in Progress. - - - - - -Klensin Informational [Page 28] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of - Internationalized Strings (stringprep)", RFC 3454, - December 2002. - - The particular profile used for placing - internationalized strings in the DNS is called - "nameprep", described in Hoffman, P. and M. Blanchet, - "Nameprep: A Stringprep Profile for Internationalized - Domain Names", Work in Progress. - - [TELNET] Postel, J. and J. Reynolds, "Telnet Protocol - Specification", STD 8, RFC 854, May 1983. - - Postel, J. and J. Reynolds, "Telnet Option - Specifications", STD 8, RFC 855, May 1983. - - [UNICODE] The Unicode Consortium, The Unicode Standard, Version - 3.0, Addison-Wesley: Reading, MA, 2000. Update to - version 3.1, 2001. Update to version 3.2, 2002. - - [UTR15] Davis, M. and M. Duerst, "Unicode Standard Annex #15: - Unicode Normalization Forms", Unicode Consortium, - March 2002. An integral part of The Unicode Standard, - Version 3.1.1. Available at - (http://www.unicode.org/reports/tr15/tr15-21.html). - - [WHOIS] Harrenstien, K, Stahl, M. and E. Feinler, - "NICNAME/WHOIS", RFC 954, October 1985. - - [WHOIS-UPDATE] Gargano, J. and K. Weiss, "Whois and Network - Information Lookup Service, Whois++", RFC 1834, August - 1995. - - Weider, C., Fullton, J. and S. Spero, "Architecture of - the Whois++ Index Service", RFC 1913, February 1996. - - Williamson, S., Kosters, M., Blacka, D., Singh, J. and - K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5", - RFC 2167, June 1997; - - Daigle, L. and P. Faltstrom, "The - application/whoispp-query Content-Type", RFC 2957, - October 2000. - - Daigle, L. and P. Falstrom, "The application/whoispp- - response Content-type", RFC 2958, October 2000. - - - - - -Klensin Informational [Page 29] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - - [X29] International Telecommuncations Union, "Recommendation - X.29: Procedures for the exchange of control - information and user data between a Packet - Assembly/Disassembly (PAD) facility and a packet mode - DTE or another PAD", December 1997. - -8. Acknowledgements - - Many people have contributed to versions of this document or the - thinking that went into it. The author would particularly like to - thank Harald Alvestrand, Rob Austein, Bob Braden, Vinton Cerf, Matt - Crawford, Leslie Daigle, Patrik Faltstrom, Eric A. Hall, Ted Hardie, - Paul Hoffman, Erik Nordmark, and Zita Wenzel for making specific - suggestions and/or challenging the assumptions and presentation of - earlier versions and suggesting ways to improve them. - -9. Author's Address - - John C. Klensin - 1770 Massachusetts Ave, #322 - Cambridge, MA 02140 - - EMail: klensin+srch@jck.com - - A mailing list has been initiated for discussion of the topics - discussed in this document, and closely-related issues, at - ietf-irnss@lists.elistx.com. See http://lists.elistx.com/archives/ - for subscription and archival information. - - - - - - - - - - - - - - - - - - - - - - - -Klensin Informational [Page 30] - -RFC 3467 Role of the Domain Name System (DNS) February 2003 - - -10. Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Klensin Informational [Page 31] - diff --git a/contrib/bind9/doc/rfc/rfc3490.txt b/contrib/bind9/doc/rfc/rfc3490.txt deleted file mode 100644 index d2e0b3b75a14..000000000000 --- a/contrib/bind9/doc/rfc/rfc3490.txt +++ /dev/null @@ -1,1235 +0,0 @@ - - - - - - -Network Working Group P. Faltstrom -Request for Comments: 3490 Cisco -Category: Standards Track P. Hoffman - IMC & VPNC - A. Costello - UC Berkeley - March 2003 - - - Internationalizing Domain Names in Applications (IDNA) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - Until now, there has been no standard method for domain names to use - characters outside the ASCII repertoire. This document defines - internationalized domain names (IDNs) and a mechanism called - Internationalizing Domain Names in Applications (IDNA) for handling - them in a standard fashion. IDNs use characters drawn from a large - repertoire (Unicode), but IDNA allows the non-ASCII characters to be - represented using only the ASCII characters already allowed in so- - called host names today. This backward-compatible representation is - required in existing protocols like DNS, so that IDNs can be - introduced with no changes to the existing infrastructure. IDNA is - only meant for processing domain names, not free text. - -Table of Contents - - 1. Introduction.................................................. 2 - 1.1 Problem Statement......................................... 3 - 1.2 Limitations of IDNA....................................... 3 - 1.3 Brief overview for application developers................. 4 - 2. Terminology................................................... 5 - 3. Requirements and applicability................................ 7 - 3.1 Requirements.............................................. 7 - 3.2 Applicability............................................. 8 - 3.2.1. DNS resource records................................ 8 - - - -Faltstrom, et al. Standards Track [Page 1] - -RFC 3490 IDNA March 2003 - - - 3.2.2. Non-domain-name data types stored in domain names... 9 - 4. Conversion operations......................................... 9 - 4.1 ToASCII................................................... 10 - 4.2 ToUnicode................................................. 11 - 5. ACE prefix.................................................... 12 - 6. Implications for typical applications using DNS............... 13 - 6.1 Entry and display in applications......................... 14 - 6.2 Applications and resolver libraries....................... 15 - 6.3 DNS servers............................................... 15 - 6.4 Avoiding exposing users to the raw ACE encoding........... 16 - 6.5 DNSSEC authentication of IDN domain names................ 16 - 7. Name server considerations.................................... 17 - 8. Root server considerations.................................... 17 - 9. References.................................................... 18 - 9.1 Normative References...................................... 18 - 9.2 Informative References.................................... 18 - 10. Security Considerations...................................... 19 - 11. IANA Considerations.......................................... 20 - 12. Authors' Addresses........................................... 21 - 13. Full Copyright Statement..................................... 22 - -1. Introduction - - IDNA works by allowing applications to use certain ASCII name labels - (beginning with a special prefix) to represent non-ASCII name labels. - Lower-layer protocols need not be aware of this; therefore IDNA does - not depend on changes to any infrastructure. In particular, IDNA - does not depend on any changes to DNS servers, resolvers, or protocol - elements, because the ASCII name service provided by the existing DNS - is entirely sufficient for IDNA. - - This document does not require any applications to conform to IDNA, - but applications can elect to use IDNA in order to support IDN while - maintaining interoperability with existing infrastructure. If an - application wants to use non-ASCII characters in domain names, IDNA - is the only currently-defined option. Adding IDNA support to an - existing application entails changes to the application only, and - leaves room for flexibility in the user interface. - - A great deal of the discussion of IDN solutions has focused on - transition issues and how IDN will work in a world where not all of - the components have been updated. Proposals that were not chosen by - the IDN Working Group would depend on user applications, resolvers, - and DNS servers being updated in order for a user to use an - internationalized domain name. Rather than rely on widespread - updating of all components, IDNA depends on updates to user - applications only; no changes are needed to the DNS protocol or any - DNS servers or the resolvers on user's computers. - - - -Faltstrom, et al. Standards Track [Page 2] - -RFC 3490 IDNA March 2003 - - -1.1 Problem Statement - - The IDNA specification solves the problem of extending the repertoire - of characters that can be used in domain names to include the Unicode - repertoire (with some restrictions). - - IDNA does not extend the service offered by DNS to the applications. - Instead, the applications (and, by implication, the users) continue - to see an exact-match lookup service. Either there is a single - exactly-matching name or there is no match. This model has served - the existing applications well, but it requires, with or without - internationalized domain names, that users know the exact spelling of - the domain names that the users type into applications such as web - browsers and mail user agents. The introduction of the larger - repertoire of characters potentially makes the set of misspellings - larger, especially given that in some cases the same appearance, for - example on a business card, might visually match several Unicode code - points or several sequences of code points. - - IDNA allows the graceful introduction of IDNs not only by avoiding - upgrades to existing infrastructure (such as DNS servers and mail - transport agents), but also by allowing some rudimentary use of IDNs - in applications by using the ASCII representation of the non-ASCII - name labels. While such names are very user-unfriendly to read and - type, and hence are not suitable for user input, they allow (for - instance) replying to email and clicking on URLs even though the - domain name displayed is incomprehensible to the user. In order to - allow user-friendly input and output of the IDNs, the applications - need to be modified to conform to this specification. - - IDNA uses the Unicode character repertoire, which avoids the - significant delays that would be inherent in waiting for a different - and specific character set be defined for IDN purposes by some other - standards developing organization. - -1.2 Limitations of IDNA - - The IDNA protocol does not solve all linguistic issues with users - inputting names in different scripts. Many important language-based - and script-based mappings are not covered in IDNA and need to be - handled outside the protocol. For example, names that are entered in - a mix of traditional and simplified Chinese characters will not be - mapped to a single canonical name. Another example is Scandinavian - names that are entered with U+00F6 (LATIN SMALL LETTER O WITH - DIAERESIS) will not be mapped to U+00F8 (LATIN SMALL LETTER O WITH - STROKE). - - - - - -Faltstrom, et al. Standards Track [Page 3] - -RFC 3490 IDNA March 2003 - - - An example of an important issue that is not considered in detail in - IDNA is how to provide a high probability that a user who is entering - a domain name based on visual information (such as from a business - card or billboard) or aural information (such as from a telephone or - radio) would correctly enter the IDN. Similar issues exist for ASCII - domain names, for example the possible visual confusion between the - letter 'O' and the digit zero, but the introduction of the larger - repertoire of characters creates more opportunities of similar - looking and similar sounding names. Note that this is a complex - issue relating to languages, input methods on computers, and so on. - Furthermore, the kind of matching and searching necessary for a high - probability of success would not fit the role of the DNS and its - exact matching function. - -1.3 Brief overview for application developers - - Applications can use IDNA to support internationalized domain names - anywhere that ASCII domain names are already supported, including DNS - master files and resolver interfaces. (Applications can also define - protocols and interfaces that support IDNs directly using non-ASCII - representations. IDNA does not prescribe any particular - representation for new protocols, but it still defines which names - are valid and how they are compared.) - - The IDNA protocol is contained completely within applications. It is - not a client-server or peer-to-peer protocol: everything is done - inside the application itself. When used with a DNS resolver - library, IDNA is inserted as a "shim" between the application and the - resolver library. When used for writing names into a DNS zone, IDNA - is used just before the name is committed to the zone. - - There are two operations described in section 4 of this document: - - - The ToASCII operation is used before sending an IDN to something - that expects ASCII names (such as a resolver) or writing an IDN - into a place that expects ASCII names (such as a DNS master file). - - - The ToUnicode operation is used when displaying names to users, - for example names obtained from a DNS zone. - - It is important to note that the ToASCII operation can fail. If it - fails when processing a domain name, that domain name cannot be used - as an internationalized domain name and the application has to have - some method of dealing with this failure. - - IDNA requires that implementations process input strings with - Nameprep [NAMEPREP], which is a profile of Stringprep [STRINGPREP], - and then with Punycode [PUNYCODE]. Implementations of IDNA MUST - - - -Faltstrom, et al. Standards Track [Page 4] - -RFC 3490 IDNA March 2003 - - - fully implement Nameprep and Punycode; neither Nameprep nor Punycode - are optional. - -2. Terminology - - The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", - and "MAY" in this document are to be interpreted as described in BCP - 14, RFC 2119 [RFC2119]. - - A code point is an integer value associated with a character in a - coded character set. - - Unicode [UNICODE] is a coded character set containing tens of - thousands of characters. A single Unicode code point is denoted by - "U+" followed by four to six hexadecimal digits, while a range of - Unicode code points is denoted by two hexadecimal numbers separated - by "..", with no prefixes. - - ASCII means US-ASCII [USASCII], a coded character set containing 128 - characters associated with code points in the range 0..7F. Unicode - is an extension of ASCII: it includes all the ASCII characters and - associates them with the same code points. - - The term "LDH code points" is defined in this document to mean the - code points associated with ASCII letters, digits, and the hyphen- - minus; that is, U+002D, 30..39, 41..5A, and 61..7A. "LDH" is an - abbreviation for "letters, digits, hyphen". - - [STD13] talks about "domain names" and "host names", but many people - use the terms interchangeably. Further, because [STD13] was not - terribly clear, many people who are sure they know the exact - definitions of each of these terms disagree on the definitions. In - this document the term "domain name" is used in general. This - document explicitly cites [STD3] whenever referring to the host name - syntax restrictions defined therein. - - A label is an individual part of a domain name. Labels are usually - shown separated by dots; for example, the domain name - "www.example.com" is composed of three labels: "www", "example", and - "com". (The zero-length root label described in [STD13], which can - be explicit as in "www.example.com." or implicit as in - "www.example.com", is not considered a label in this specification.) - IDNA extends the set of usable characters in labels that are text. - For the rest of this document, the term "label" is shorthand for - "text label", and "every label" means "every text label". - - - - - - -Faltstrom, et al. Standards Track [Page 5] - -RFC 3490 IDNA March 2003 - - - An "internationalized label" is a label to which the ToASCII - operation (see section 4) can be applied without failing (with the - UseSTD3ASCIIRules flag unset). This implies that every ASCII label - that satisfies the [STD13] length restriction is an internationalized - label. Therefore the term "internationalized label" is a - generalization, embracing both old ASCII labels and new non-ASCII - labels. Although most Unicode characters can appear in - internationalized labels, ToASCII will fail for some input strings, - and such strings are not valid internationalized labels. - - An "internationalized domain name" (IDN) is a domain name in which - every label is an internationalized label. This implies that every - ASCII domain name is an IDN (which implies that it is possible for a - name to be an IDN without it containing any non-ASCII characters). - This document does not attempt to define an "internationalized host - name". Just as has been the case with ASCII names, some DNS zone - administrators may impose restrictions, beyond those imposed by DNS - or IDNA, on the characters or strings that may be registered as - labels in their zones. Such restrictions have no impact on the - syntax or semantics of DNS protocol messages; a query for a name that - matches no records will yield the same response regardless of the - reason why it is not in the zone. Clients issuing queries or - interpreting responses cannot be assumed to have any knowledge of - zone-specific restrictions or conventions. - - In IDNA, equivalence of labels is defined in terms of the ToASCII - operation, which constructs an ASCII form for a given label, whether - or not the label was already an ASCII label. Labels are defined to - be equivalent if and only if their ASCII forms produced by ToASCII - match using a case-insensitive ASCII comparison. ASCII labels - already have a notion of equivalence: upper case and lower case are - considered equivalent. The IDNA notion of equivalence is an - extension of that older notion. Equivalent labels in IDNA are - treated as alternate forms of the same label, just as "foo" and "Foo" - are treated as alternate forms of the same label. - - To allow internationalized labels to be handled by existing - applications, IDNA uses an "ACE label" (ACE stands for ASCII - Compatible Encoding). An ACE label is an internationalized label - that can be rendered in ASCII and is equivalent to an - internationalized label that cannot be rendered in ASCII. Given any - internationalized label that cannot be rendered in ASCII, the ToASCII - operation will convert it to an equivalent ACE label (whereas an - ASCII label will be left unaltered by ToASCII). ACE labels are - unsuitable for display to users. The ToUnicode operation will - convert any label to an equivalent non-ACE label. In fact, an ACE - label is formally defined to be any label that the ToUnicode - operation would alter (whereas non-ACE labels are left unaltered by - - - -Faltstrom, et al. Standards Track [Page 6] - -RFC 3490 IDNA March 2003 - - - ToUnicode). Every ACE label begins with the ACE prefix specified in - section 5. The ToASCII and ToUnicode operations are specified in - section 4. - - The "ACE prefix" is defined in this document to be a string of ASCII - characters that appears at the beginning of every ACE label. It is - specified in section 5. - - A "domain name slot" is defined in this document to be a protocol - element or a function argument or a return value (and so on) - explicitly designated for carrying a domain name. Examples of domain - name slots include: the QNAME field of a DNS query; the name argument - of the gethostbyname() library function; the part of an email address - following the at-sign (@) in the From: field of an email message - header; and the host portion of the URI in the src attribute of an - HTML <IMG> tag. General text that just happens to contain a domain - name is not a domain name slot; for example, a domain name appearing - in the plain text body of an email message is not occupying a domain - name slot. - - An "IDN-aware domain name slot" is defined in this document to be a - domain name slot explicitly designated for carrying an - internationalized domain name as defined in this document. The - designation may be static (for example, in the specification of the - protocol or interface) or dynamic (for example, as a result of - negotiation in an interactive session). - - An "IDN-unaware domain name slot" is defined in this document to be - any domain name slot that is not an IDN-aware domain name slot. - Obviously, this includes any domain name slot whose specification - predates IDNA. - -3. Requirements and applicability - -3.1 Requirements - - IDNA conformance means adherence to the following four requirements: - - 1) Whenever dots are used as label separators, the following - characters MUST be recognized as dots: U+002E (full stop), U+3002 - (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61 - (halfwidth ideographic full stop). - - 2) Whenever a domain name is put into an IDN-unaware domain name slot - (see section 2), it MUST contain only ASCII characters. Given an - internationalized domain name (IDN), an equivalent domain name - satisfying this requirement can be obtained by applying the - - - - -Faltstrom, et al. Standards Track [Page 7] - -RFC 3490 IDNA March 2003 - - - ToASCII operation (see section 4) to each label and, if dots are - used as label separators, changing all the label separators to - U+002E. - - 3) ACE labels obtained from domain name slots SHOULD be hidden from - users when it is known that the environment can handle the non-ACE - form, except when the ACE form is explicitly requested. When it - is not known whether or not the environment can handle the non-ACE - form, the application MAY use the non-ACE form (which might fail, - such as by not being displayed properly), or it MAY use the ACE - form (which will look unintelligle to the user). Given an - internationalized domain name, an equivalent domain name - containing no ACE labels can be obtained by applying the ToUnicode - operation (see section 4) to each label. When requirements 2 and - 3 both apply, requirement 2 takes precedence. - - 4) Whenever two labels are compared, they MUST be considered to match - if and only if they are equivalent, that is, their ASCII forms - (obtained by applying ToASCII) match using a case-insensitive - ASCII comparison. Whenever two names are compared, they MUST be - considered to match if and only if their corresponding labels - match, regardless of whether the names use the same forms of label - separators. - -3.2 Applicability - - IDNA is applicable to all domain names in all domain name slots - except where it is explicitly excluded. - - This implies that IDNA is applicable to many protocols that predate - IDNA. Note that IDNs occupying domain name slots in those protocols - MUST be in ASCII form (see section 3.1, requirement 2). - -3.2.1. DNS resource records - - IDNA does not apply to domain names in the NAME and RDATA fields of - DNS resource records whose CLASS is not IN. This exclusion applies - to every non-IN class, present and future, except where future - standards override this exclusion by explicitly inviting the use of - IDNA. - - There are currently no other exclusions on the applicability of IDNA - to DNS resource records; it depends entirely on the CLASS, and not on - the TYPE. This will remain true, even as new types are defined, - unless there is a compelling reason for a new type to complicate - matters by imposing type-specific rules. - - - - - -Faltstrom, et al. Standards Track [Page 8] - -RFC 3490 IDNA March 2003 - - -3.2.2. Non-domain-name data types stored in domain names - - Although IDNA enables the representation of non-ASCII characters in - domain names, that does not imply that IDNA enables the - representation of non-ASCII characters in other data types that are - stored in domain names. For example, an email address local part is - sometimes stored in a domain label (hostmaster@example.com would be - represented as hostmaster.example.com in the RDATA field of an SOA - record). IDNA does not update the existing email standards, which - allow only ASCII characters in local parts. Therefore, unless the - email standards are revised to invite the use of IDNA for local - parts, a domain label that holds the local part of an email address - SHOULD NOT begin with the ACE prefix, and even if it does, it is to - be interpreted literally as a local part that happens to begin with - the ACE prefix. - -4. Conversion operations - - An application converts a domain name put into an IDN-unaware slot or - displayed to a user. This section specifies the steps to perform in - the conversion, and the ToASCII and ToUnicode operations. - - The input to ToASCII or ToUnicode is a single label that is a - sequence of Unicode code points (remember that all ASCII code points - are also Unicode code points). If a domain name is represented using - a character set other than Unicode or US-ASCII, it will first need to - be transcoded to Unicode. - - Starting from a whole domain name, the steps that an application - takes to do the conversions are: - - 1) Decide whether the domain name is a "stored string" or a "query - string" as described in [STRINGPREP]. If this conversion follows - the "queries" rule from [STRINGPREP], set the flag called - "AllowUnassigned". - - 2) Split the domain name into individual labels as described in - section 3.1. The labels do not include the separator. - - 3) For each label, decide whether or not to enforce the restrictions - on ASCII characters in host names [STD3]. (Applications already - faced this choice before the introduction of IDNA, and can - continue to make the decision the same way they always have; IDNA - makes no new recommendations regarding this choice.) If the - restrictions are to be enforced, set the flag called - "UseSTD3ASCIIRules" for that label. - - - - - -Faltstrom, et al. Standards Track [Page 9] - -RFC 3490 IDNA March 2003 - - - 4) Process each label with either the ToASCII or the ToUnicode - operation as appropriate. Typically, you use the ToASCII - operation if you are about to put the name into an IDN-unaware - slot, and you use the ToUnicode operation if you are displaying - the name to a user; section 3.1 gives greater detail on the - applicable requirements. - - 5) If ToASCII was applied in step 4 and dots are used as label - separators, change all the label separators to U+002E (full stop). - - The following two subsections define the ToASCII and ToUnicode - operations that are used in step 4. - - This description of the protocol uses specific procedure names, names - of flags, and so on, in order to facilitate the specification of the - protocol. These names, as well as the actual steps of the - procedures, are not required of an implementation. In fact, any - implementation which has the same external behavior as specified in - this document conforms to this specification. - -4.1 ToASCII - - The ToASCII operation takes a sequence of Unicode code points that - make up one label and transforms it into a sequence of code points in - the ASCII range (0..7F). If ToASCII succeeds, the original sequence - and the resulting sequence are equivalent labels. - - It is important to note that the ToASCII operation can fail. ToASCII - fails if any step of it fails. If any step of the ToASCII operation - fails on any label in a domain name, that domain name MUST NOT be - used as an internationalized domain name. The method for dealing - with this failure is application-specific. - - The inputs to ToASCII are a sequence of code points, the - AllowUnassigned flag, and the UseSTD3ASCIIRules flag. The output of - ToASCII is either a sequence of ASCII code points or a failure - condition. - - ToASCII never alters a sequence of code points that are all in the - ASCII range to begin with (although it could fail). Applying the - ToASCII operation multiple times has exactly the same effect as - applying it just once. - - ToASCII consists of the following steps: - - 1. If the sequence contains any code points outside the ASCII range - (0..7F) then proceed to step 2, otherwise skip to step 3. - - - - -Faltstrom, et al. Standards Track [Page 10] - -RFC 3490 IDNA March 2003 - - - 2. Perform the steps specified in [NAMEPREP] and fail if there is an - error. The AllowUnassigned flag is used in [NAMEPREP]. - - 3. If the UseSTD3ASCIIRules flag is set, then perform these checks: - - (a) Verify the absence of non-LDH ASCII code points; that is, the - absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F. - - (b) Verify the absence of leading and trailing hyphen-minus; that - is, the absence of U+002D at the beginning and end of the - sequence. - - 4. If the sequence contains any code points outside the ASCII range - (0..7F) then proceed to step 5, otherwise skip to step 8. - - 5. Verify that the sequence does NOT begin with the ACE prefix. - - 6. Encode the sequence using the encoding algorithm in [PUNYCODE] and - fail if there is an error. - - 7. Prepend the ACE prefix. - - 8. Verify that the number of code points is in the range 1 to 63 - inclusive. - -4.2 ToUnicode - - The ToUnicode operation takes a sequence of Unicode code points that - make up one label and returns a sequence of Unicode code points. If - the input sequence is a label in ACE form, then the result is an - equivalent internationalized label that is not in ACE form, otherwise - the original sequence is returned unaltered. - - ToUnicode never fails. If any step fails, then the original input - sequence is returned immediately in that step. - - The ToUnicode output never contains more code points than its input. - Note that the number of octets needed to represent a sequence of code - points depends on the particular character encoding used. - - The inputs to ToUnicode are a sequence of code points, the - AllowUnassigned flag, and the UseSTD3ASCIIRules flag. The output of - ToUnicode is always a sequence of Unicode code points. - - 1. If all code points in the sequence are in the ASCII range (0..7F) - then skip to step 3. - - - - - -Faltstrom, et al. Standards Track [Page 11] - -RFC 3490 IDNA March 2003 - - - 2. Perform the steps specified in [NAMEPREP] and fail if there is an - error. (If step 3 of ToASCII is also performed here, it will not - affect the overall behavior of ToUnicode, but it is not - necessary.) The AllowUnassigned flag is used in [NAMEPREP]. - - 3. Verify that the sequence begins with the ACE prefix, and save a - copy of the sequence. - - 4. Remove the ACE prefix. - - 5. Decode the sequence using the decoding algorithm in [PUNYCODE] and - fail if there is an error. Save a copy of the result of this - step. - - 6. Apply ToASCII. - - 7. Verify that the result of step 6 matches the saved copy from step - 3, using a case-insensitive ASCII comparison. - - 8. Return the saved copy from step 5. - -5. ACE prefix - - The ACE prefix, used in the conversion operations (section 4), is two - alphanumeric ASCII characters followed by two hyphen-minuses. It - cannot be any of the prefixes already used in earlier documents, - which includes the following: "bl--", "bq--", "dq--", "lq--", "mq--", - "ra--", "wq--" and "zq--". The ToASCII and ToUnicode operations MUST - recognize the ACE prefix in a case-insensitive manner. - - The ACE prefix for IDNA is "xn--" or any capitalization thereof. - - This means that an ACE label might be "xn--de-jg4avhby1noc0d", where - "de-jg4avhby1noc0d" is the part of the ACE label that is generated by - the encoding steps in [PUNYCODE]. - - While all ACE labels begin with the ACE prefix, not all labels - beginning with the ACE prefix are necessarily ACE labels. Non-ACE - labels that begin with the ACE prefix will confuse users and SHOULD - NOT be allowed in DNS zones. - - - - - - - - - - - -Faltstrom, et al. Standards Track [Page 12] - -RFC 3490 IDNA March 2003 - - -6. Implications for typical applications using DNS - - In IDNA, applications perform the processing needed to input - internationalized domain names from users, display internationalized - domain names to users, and process the inputs and outputs from DNS - and other protocols that carry domain names. - - The components and interfaces between them can be represented - pictorially as: - - +------+ - | User | - +------+ - ^ - | Input and display: local interface methods - | (pen, keyboard, glowing phosphorus, ...) - +-------------------|-------------------------------+ - | v | - | +-----------------------------+ | - | | Application | | - | | (ToASCII and ToUnicode | | - | | operations may be | | - | | called here) | | - | +-----------------------------+ | - | ^ ^ | End system - | | | | - | Call to resolver: | | Application-specific | - | ACE | | protocol: | - | v | ACE unless the | - | +----------+ | protocol is updated | - | | Resolver | | to handle other | - | +----------+ | encodings | - | ^ | | - +-----------------|----------|----------------------+ - DNS protocol: | | - ACE | | - v v - +-------------+ +---------------------+ - | DNS servers | | Application servers | - +-------------+ +---------------------+ - - The box labeled "Application" is where the application splits a - domain name into labels, sets the appropriate flags, and performs the - ToASCII and ToUnicode operations. This is described in section 4. - - - - - - - -Faltstrom, et al. Standards Track [Page 13] - -RFC 3490 IDNA March 2003 - - -6.1 Entry and display in applications - - Applications can accept domain names using any character set or sets - desired by the application developer, and can display domain names in - any charset. That is, the IDNA protocol does not affect the - interface between users and applications. - - An IDNA-aware application can accept and display internationalized - domain names in two formats: the internationalized character set(s) - supported by the application, and as an ACE label. ACE labels that - are displayed or input MUST always include the ACE prefix. - Applications MAY allow input and display of ACE labels, but are not - encouraged to do so except as an interface for special purposes, - possibly for debugging, or to cope with display limitations as - described in section 6.4.. ACE encoding is opaque and ugly, and - should thus only be exposed to users who absolutely need it. Because - name labels encoded as ACE name labels can be rendered either as the - encoded ASCII characters or the proper decoded characters, the - application MAY have an option for the user to select the preferred - method of display; if it does, rendering the ACE SHOULD NOT be the - default. - - Domain names are often stored and transported in many places. For - example, they are part of documents such as mail messages and web - pages. They are transported in many parts of many protocols, such as - both the control commands and the RFC 2822 body parts of SMTP, and - the headers and the body content in HTTP. It is important to - remember that domain names appear both in domain name slots and in - the content that is passed over protocols. - - In protocols and document formats that define how to handle - specification or negotiation of charsets, labels can be encoded in - any charset allowed by the protocol or document format. If a - protocol or document format only allows one charset, the labels MUST - be given in that charset. - - In any place where a protocol or document format allows transmission - of the characters in internationalized labels, internationalized - labels SHOULD be transmitted using whatever character encoding and - escape mechanism that the protocol or document format uses at that - place. - - All protocols that use domain name slots already have the capacity - for handling domain names in the ASCII charset. Thus, ACE labels - (internationalized labels that have been processed with the ToASCII - operation) can inherently be handled by those protocols. - - - - - -Faltstrom, et al. Standards Track [Page 14] - -RFC 3490 IDNA March 2003 - - -6.2 Applications and resolver libraries - - Applications normally use functions in the operating system when they - resolve DNS queries. Those functions in the operating system are - often called "the resolver library", and the applications communicate - with the resolver libraries through a programming interface (API). - - Because these resolver libraries today expect only domain names in - ASCII, applications MUST prepare labels that are passed to the - resolver library using the ToASCII operation. Labels received from - the resolver library contain only ASCII characters; internationalized - labels that cannot be represented directly in ASCII use the ACE form. - ACE labels always include the ACE prefix. - - An operating system might have a set of libraries for performing the - ToASCII operation. The input to such a library might be in one or - more charsets that are used in applications (UTF-8 and UTF-16 are - likely candidates for almost any operating system, and script- - specific charsets are likely for localized operating systems). - - IDNA-aware applications MUST be able to work with both non- - internationalized labels (those that conform to [STD13] and [STD3]) - and internationalized labels. - - It is expected that new versions of the resolver libraries in the - future will be able to accept domain names in other charsets than - ASCII, and application developers might one day pass not only domain - names in Unicode, but also in local script to a new API for the - resolver libraries in the operating system. Thus the ToASCII and - ToUnicode operations might be performed inside these new versions of - the resolver libraries. - - Domain names passed to resolvers or put into the question section of - DNS requests follow the rules for "queries" from [STRINGPREP]. - -6.3 DNS servers - - Domain names stored in zones follow the rules for "stored strings" - from [STRINGPREP]. - - For internationalized labels that cannot be represented directly in - ASCII, DNS servers MUST use the ACE form produced by the ToASCII - operation. All IDNs served by DNS servers MUST contain only ASCII - characters. - - If a signaling system which makes negotiation possible between old - and new DNS clients and servers is standardized in the future, the - encoding of the query in the DNS protocol itself can be changed from - - - -Faltstrom, et al. Standards Track [Page 15] - -RFC 3490 IDNA March 2003 - - - ACE to something else, such as UTF-8. The question whether or not - this should be used is, however, a separate problem and is not - discussed in this memo. - -6.4 Avoiding exposing users to the raw ACE encoding - - Any application that might show the user a domain name obtained from - a domain name slot, such as from gethostbyaddr or part of a mail - header, will need to be updated if it is to prevent users from seeing - the ACE. - - If an application decodes an ACE name using ToUnicode but cannot show - all of the characters in the decoded name, such as if the name - contains characters that the output system cannot display, the - application SHOULD show the name in ACE format (which always includes - the ACE prefix) instead of displaying the name with the replacement - character (U+FFFD). This is to make it easier for the user to - transfer the name correctly to other programs. Programs that by - default show the ACE form when they cannot show all the characters in - a name label SHOULD also have a mechanism to show the name that is - produced by the ToUnicode operation with as many characters as - possible and replacement characters in the positions where characters - cannot be displayed. - - The ToUnicode operation does not alter labels that are not valid ACE - labels, even if they begin with the ACE prefix. After ToUnicode has - been applied, if a label still begins with the ACE prefix, then it is - not a valid ACE label, and is not equivalent to any of the - intermediate Unicode strings constructed by ToUnicode. - -6.5 DNSSEC authentication of IDN domain names - - DNS Security [RFC2535] is a method for supplying cryptographic - verification information along with DNS messages. Public Key - Cryptography is used in conjunction with digital signatures to - provide a means for a requester of domain information to authenticate - the source of the data. This ensures that it can be traced back to a - trusted source, either directly, or via a chain of trust linking the - source of the information to the top of the DNS hierarchy. - - IDNA specifies that all internationalized domain names served by DNS - servers that cannot be represented directly in ASCII must use the ACE - form produced by the ToASCII operation. This operation must be - performed prior to a zone being signed by the private key for that - zone. Because of this ordering, it is important to recognize that - DNSSEC authenticates the ASCII domain name, not the Unicode form or - - - - - -Faltstrom, et al. Standards Track [Page 16] - -RFC 3490 IDNA March 2003 - - - the mapping between the Unicode form and the ASCII form. In the - presence of DNSSEC, this is the name that MUST be signed in the zone - and MUST be validated against. - - One consequence of this for sites deploying IDNA in the presence of - DNSSEC is that any special purpose proxies or forwarders used to - transform user input into IDNs must be earlier in the resolution flow - than DNSSEC authenticating nameservers for DNSSEC to work. - -7. Name server considerations - - Existing DNS servers do not know the IDNA rules for handling non- - ASCII forms of IDNs, and therefore need to be shielded from them. - All existing channels through which names can enter a DNS server - database (for example, master files [STD13] and DNS update messages - [RFC2136]) are IDN-unaware because they predate IDNA, and therefore - requirement 2 of section 3.1 of this document provides the needed - shielding, by ensuring that internationalized domain names entering - DNS server databases through such channels have already been - converted to their equivalent ASCII forms. - - It is imperative that there be only one ASCII encoding for a - particular domain name. Because of the design of the ToASCII and - ToUnicode operations, there are no ACE labels that decode to ASCII - labels, and therefore name servers cannot contain multiple ASCII - encodings of the same domain name. - - [RFC2181] explicitly allows domain labels to contain octets beyond - the ASCII range (0..7F), and this document does not change that. - Note, however, that there is no defined interpretation of octets - 80..FF as characters. If labels containing these octets are returned - to applications, unpredictable behavior could result. The ASCII form - defined by ToASCII is the only standard representation for - internationalized labels in the current DNS protocol. - -8. Root server considerations - - IDNs are likely to be somewhat longer than current domain names, so - the bandwidth needed by the root servers is likely to go up by a - small amount. Also, queries and responses for IDNs will probably be - somewhat longer than typical queries today, so more queries and - responses may be forced to go to TCP instead of UDP. - - - - - - - - - -Faltstrom, et al. Standards Track [Page 17] - -RFC 3490 IDNA March 2003 - - -9. References - -9.1 Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of - Internationalized Strings ("stringprep")", RFC 3454, - December 2002. - - [NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep - Profile for Internationalized Domain Names (IDN)", RFC - 3491, March 2003. - - [PUNYCODE] Costello, A., "Punycode: A Bootstring encoding of - Unicode for use with Internationalized Domain Names in - Applications (IDNA)", RFC 3492, March 2003. - - [STD3] Braden, R., "Requirements for Internet Hosts -- - Communication Layers", STD 3, RFC 1122, and - "Requirements for Internet Hosts -- Application and - Support", STD 3, RFC 1123, October 1989. - - [STD13] Mockapetris, P., "Domain names - concepts and - facilities", STD 13, RFC 1034 and "Domain names - - implementation and specification", STD 13, RFC 1035, - November 1987. - -9.2 Informative References - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [UAX9] Unicode Standard Annex #9, The Bidirectional Algorithm, - <http://www.unicode.org/unicode/reports/tr9/>. - - [UNICODE] The Unicode Consortium. The Unicode Standard, Version - 3.2.0 is defined by The Unicode Standard, Version 3.0 - (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), - as amended by the Unicode Standard Annex #27: Unicode - 3.1 (http://www.unicode.org/reports/tr27/) and by the - Unicode Standard Annex #28: Unicode 3.2 - (http://www.unicode.org/reports/tr28/). - - - - -Faltstrom, et al. Standards Track [Page 18] - -RFC 3490 IDNA March 2003 - - - [USASCII] Cerf, V., "ASCII format for Network Interchange", RFC - 20, October 1969. - -10. Security Considerations - - Security on the Internet partly relies on the DNS. Thus, any change - to the characteristics of the DNS can change the security of much of - the Internet. - - This memo describes an algorithm which encodes characters that are - not valid according to STD3 and STD13 into octet values that are - valid. No security issues such as string length increases or new - allowed values are introduced by the encoding process or the use of - these encoded values, apart from those introduced by the ACE encoding - itself. - - Domain names are used by users to identify and connect to Internet - servers. The security of the Internet is compromised if a user - entering a single internationalized name is connected to different - servers based on different interpretations of the internationalized - domain name. - - When systems use local character sets other than ASCII and Unicode, - this specification leaves the the problem of transcoding between the - local character set and Unicode up to the application. If different - applications (or different versions of one application) implement - different transcoding rules, they could interpret the same name - differently and contact different servers. This problem is not - solved by security protocols like TLS that do not take local - character sets into account. - - Because this document normatively refers to [NAMEPREP], [PUNYCODE], - and [STRINGPREP], it includes the security considerations from those - documents as well. - - If or when this specification is updated to use a more recent Unicode - normalization table, the new normalization table will need to be - compared with the old to spot backwards incompatible changes. If - there are such changes, they will need to be handled somehow, or - there will be security as well as operational implications. Methods - to handle the conflicts could include keeping the old normalization, - or taking care of the conflicting characters by operational means, or - some other method. - - Implementations MUST NOT use more recent normalization tables than - the one referenced from this document, even though more recent tables - may be provided by operating systems. If an application is unsure of - which version of the normalization tables are in the operating - - - -Faltstrom, et al. Standards Track [Page 19] - -RFC 3490 IDNA March 2003 - - - system, the application needs to include the normalization tables - itself. Using normalization tables other than the one referenced - from this specification could have security and operational - implications. - - To help prevent confusion between characters that are visually - similar, it is suggested that implementations provide visual - indications where a domain name contains multiple scripts. Such - mechanisms can also be used to show when a name contains a mixture of - simplified and traditional Chinese characters, or to distinguish zero - and one from O and l. DNS zone adminstrators may impose restrictions - (subject to the limitations in section 2) that try to minimize - homographs. - - Domain names (or portions of them) are sometimes compared against a - set of privileged or anti-privileged domains. In such situations it - is especially important that the comparisons be done properly, as - specified in section 3.1 requirement 4. For labels already in ASCII - form, the proper comparison reduces to the same case-insensitive - ASCII comparison that has always been used for ASCII labels. - - The introduction of IDNA means that any existing labels that start - with the ACE prefix and would be altered by ToUnicode will - automatically be ACE labels, and will be considered equivalent to - non-ASCII labels, whether or not that was the intent of the zone - adminstrator or registrant. - -11. IANA Considerations - - IANA has assigned the ACE prefix in consultation with the IESG. - - - - - - - - - - - - - - - - - - - - - -Faltstrom, et al. Standards Track [Page 20] - -RFC 3490 IDNA March 2003 - - -12. Authors' Addresses - - Patrik Faltstrom - Cisco Systems - Arstaangsvagen 31 J - S-117 43 Stockholm Sweden - - EMail: paf@cisco.com - - - Paul Hoffman - Internet Mail Consortium and VPN Consortium - 127 Segre Place - Santa Cruz, CA 95060 USA - - EMail: phoffman@imc.org - - - Adam M. Costello - University of California, Berkeley - - URL: http://www.nicemice.net/amc/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Faltstrom, et al. Standards Track [Page 21] - -RFC 3490 IDNA March 2003 - - -13. Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Faltstrom, et al. Standards Track [Page 22] - diff --git a/contrib/bind9/doc/rfc/rfc3491.txt b/contrib/bind9/doc/rfc/rfc3491.txt deleted file mode 100644 index dbc86c7fe4c0..000000000000 --- a/contrib/bind9/doc/rfc/rfc3491.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -Network Working Group P. Hoffman -Request for Comments: 3491 IMC & VPNC -Category: Standards Track M. Blanchet - Viagenie - March 2003 - - - Nameprep: A Stringprep Profile for - Internationalized Domain Names (IDN) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - This document describes how to prepare internationalized domain name - (IDN) labels in order to increase the likelihood that name input and - name comparison work in ways that make sense for typical users - throughout the world. This profile of the stringprep protocol is - used as part of a suite of on-the-wire protocols for - internationalizing the Domain Name System (DNS). - -1. Introduction - - This document specifies processing rules that will allow users to - enter internationalized domain names (IDNs) into applications and - have the highest chance of getting the content of the strings - correct. It is a profile of stringprep [STRINGPREP]. These - processing rules are only intended for internationalized domain - names, not for arbitrary text. - - This profile defines the following, as required by [STRINGPREP]. - - - The intended applicability of the profile: internationalized - domain names processed by IDNA. - - - The character repertoire that is the input and output to - stringprep: Unicode 3.2, specified in section 2. - - - - -Hoffman & Blanchet Standards Track [Page 1] - -RFC 3491 IDN Nameprep March 2003 - - - - The mappings used: specified in section 3. - - - The Unicode normalization used: specified in section 4. - - - The characters that are prohibited as output: specified in section - 5. - - - Bidirectional character handling: specified in section 6. - -1.1 Interaction of protocol parts - - Nameprep is used by the IDNA [IDNA] protocol for preparing domain - names; it is not designed for any other purpose. It is explicitly - not designed for processing arbitrary free text and SHOULD NOT be - used for that purpose. Nameprep is a profile of Stringprep - [STRINGPREP]. Implementations of Nameprep MUST fully implement - Stringprep. - - Nameprep is used to process domain name labels, not domain names. - IDNA calls nameprep for each label in a domain name, not for the - whole domain name. - -1.2 Terminology - - The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" - in this document are to be interpreted as described in BCP 14, RFC - 2119 [RFC2119]. - -2. Character Repertoire - - This profile uses Unicode 3.2, as defined in [STRINGPREP] Appendix A. - -3. Mapping - - This profile specifies mapping using the following tables from - [STRINGPREP]: - - Table B.1 - Table B.2 - -4. Normalization - - This profile specifies using Unicode normalization form KC, as - described in [STRINGPREP]. - - - - - - - -Hoffman & Blanchet Standards Track [Page 2] - -RFC 3491 IDN Nameprep March 2003 - - -5. Prohibited Output - - This profile specifies prohibiting using the following tables from - [STRINGPREP]: - - Table C.1.2 - Table C.2.2 - Table C.3 - Table C.4 - Table C.5 - Table C.6 - Table C.7 - Table C.8 - Table C.9 - - IMPORTANT NOTE: This profile MUST be used with the IDNA protocol. - The IDNA protocol has additional prohibitions that are checked - outside of this profile. - -6. Bidirectional characters - - This profile specifies checking bidirectional strings as described in - [STRINGPREP] section 6. - -7. Unassigned Code Points in Internationalized Domain Names - - If the processing in [IDNA] specifies that a list of unassigned code - points be used, the system uses table A.1 from [STRINGPREP] as its - list of unassigned code points. - -8. References - -8.1 Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of - Internationalized Strings ("stringprep")", RFC 3454, - December 2002. - - [IDNA] Faltstrom, P., Hoffman, P. and A. Costello, - "Internationalizing Domain Names in Applications - (IDNA)", RFC 3490, March 2003. - - - - - - - -Hoffman & Blanchet Standards Track [Page 3] - -RFC 3491 IDN Nameprep March 2003 - - -8.2 Informative references - - [STD13] Mockapetris, P., "Domain names - concepts and - facilities", STD 13, RFC 1034, and "Domain names - - implementation and specification", STD 13, RFC 1035, - November 1987. - -9. Security Considerations - - The Unicode and ISO/IEC 10646 repertoires have many characters that - look similar. In many cases, users of security protocols might do - visual matching, such as when comparing the names of trusted third - parties. Because it is impossible to map similar-looking characters - without a great deal of context such as knowing the fonts used, - stringprep does nothing to map similar-looking characters together - nor to prohibit some characters because they look like others. - - Security on the Internet partly relies on the DNS. Thus, any change - to the characteristics of the DNS can change the security of much of - the Internet. - - Domain names are used by users to connect to Internet servers. The - security of the Internet would be compromised if a user entering a - single internationalized name could be connected to different servers - based on different interpretations of the internationalized domain - name. - - Current applications might assume that the characters allowed in - domain names will always be the same as they are in [STD13]. This - document vastly increases the number of characters available in - domain names. Every program that uses "special" characters in - conjunction with domain names may be vulnerable to attack based on - the new characters allowed by this specification. - - - - - - - - - - - - - - - - - - -Hoffman & Blanchet Standards Track [Page 4] - -RFC 3491 IDN Nameprep March 2003 - - -10. IANA Considerations - - This is a profile of stringprep. It has been registered by the IANA - in the stringprep profile registry - (www.iana.org/assignments/stringprep-profiles). - - Name of this profile: - Nameprep - - RFC in which the profile is defined: - This document. - - Indicator whether or not this is the newest version of the - profile: - This is the first version of Nameprep. - -11. Acknowledgements - - Many people from the IETF IDN Working Group and the Unicode Technical - Committee contributed ideas that went into this document. - - The IDN Nameprep design team made many useful changes to the - document. That team and its advisors include: - - Asmus Freytag - Cathy Wissink - Francois Yergeau - James Seng - Marc Blanchet - Mark Davis - Martin Duerst - Patrik Faltstrom - Paul Hoffman - - Additional significant improvements were proposed by: - - Jonathan Rosenne - Kent Karlsson - Scott Hollenbeck - Dave Crocker - Erik Nordmark - Matitiahu Allouche - - - - - - - - - -Hoffman & Blanchet Standards Track [Page 5] - -RFC 3491 IDN Nameprep March 2003 - - -12. Authors' Addresses - - Paul Hoffman - Internet Mail Consortium and VPN Consortium - 127 Segre Place - Santa Cruz, CA 95060 USA - - EMail: paul.hoffman@imc.org and paul.hoffman@vpnc.org - - - Marc Blanchet - Viagenie inc. - 2875 boul. Laurier, bur. 300 - Ste-Foy, Quebec, Canada, G1V 2M2 - - EMail: Marc.Blanchet@viagenie.qc.ca - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hoffman & Blanchet Standards Track [Page 6] - -RFC 3491 IDN Nameprep March 2003 - - -13. Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Hoffman & Blanchet Standards Track [Page 7] - diff --git a/contrib/bind9/doc/rfc/rfc3492.txt b/contrib/bind9/doc/rfc/rfc3492.txt deleted file mode 100644 index e72ad81a2719..000000000000 --- a/contrib/bind9/doc/rfc/rfc3492.txt +++ /dev/null @@ -1,1963 +0,0 @@ - - - - - - -Network Working Group A. Costello -Request for Comments: 3492 Univ. of California, Berkeley -Category: Standards Track March 2003 - - - Punycode: A Bootstring encoding of Unicode - for Internationalized Domain Names in Applications (IDNA) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - Punycode is a simple and efficient transfer encoding syntax designed - for use with Internationalized Domain Names in Applications (IDNA). - It uniquely and reversibly transforms a Unicode string into an ASCII - string. ASCII characters in the Unicode string are represented - literally, and non-ASCII characters are represented by ASCII - characters that are allowed in host name labels (letters, digits, and - hyphens). This document defines a general algorithm called - Bootstring that allows a string of basic code points to uniquely - represent any string of code points drawn from a larger set. - Punycode is an instance of Bootstring that uses particular parameter - values specified by this document, appropriate for IDNA. - -Table of Contents - - 1. Introduction...............................................2 - 1.1 Features..............................................2 - 1.2 Interaction of protocol parts.........................3 - 2. Terminology................................................3 - 3. Bootstring description.....................................4 - 3.1 Basic code point segregation..........................4 - 3.2 Insertion unsort coding...............................4 - 3.3 Generalized variable-length integers..................5 - 3.4 Bias adaptation.......................................7 - 4. Bootstring parameters......................................8 - 5. Parameter values for Punycode..............................8 - 6. Bootstring algorithms......................................9 - - - -Costello Standards Track [Page 1] - -RFC 3492 IDNA Punycode March 2003 - - - 6.1 Bias adaptation function.............................10 - 6.2 Decoding procedure...................................11 - 6.3 Encoding procedure...................................12 - 6.4 Overflow handling....................................13 - 7. Punycode examples.........................................14 - 7.1 Sample strings.......................................14 - 7.2 Decoding traces......................................17 - 7.3 Encoding traces......................................19 - 8. Security Considerations...................................20 - 9. References................................................21 - 9.1 Normative References.................................21 - 9.2 Informative References...............................21 - A. Mixed-case annotation.....................................22 - B. Disclaimer and license....................................22 - C. Punycode sample implementation............................23 - Author's Address.............................................34 - Full Copyright Statement.....................................35 - -1. Introduction - - [IDNA] describes an architecture for supporting internationalized - domain names. Labels containing non-ASCII characters can be - represented by ACE labels, which begin with a special ACE prefix and - contain only ASCII characters. The remainder of the label after the - prefix is a Punycode encoding of a Unicode string satisfying certain - constraints. For the details of the prefix and constraints, see - [IDNA] and [NAMEPREP]. - - Punycode is an instance of a more general algorithm called - Bootstring, which allows strings composed from a small set of "basic" - code points to uniquely represent any string of code points drawn - from a larger set. Punycode is Bootstring with particular parameter - values appropriate for IDNA. - -1.1 Features - - Bootstring has been designed to have the following features: - - * Completeness: Every extended string (sequence of arbitrary code - points) can be represented by a basic string (sequence of basic - code points). Restrictions on what strings are allowed, and on - length, can be imposed by higher layers. - - * Uniqueness: There is at most one basic string that represents a - given extended string. - - * Reversibility: Any extended string mapped to a basic string can - be recovered from that basic string. - - - -Costello Standards Track [Page 2] - -RFC 3492 IDNA Punycode March 2003 - - - * Efficient encoding: The ratio of basic string length to extended - string length is small. This is important in the context of - domain names because RFC 1034 [RFC1034] restricts the length of a - domain label to 63 characters. - - * Simplicity: The encoding and decoding algorithms are reasonably - simple to implement. The goals of efficiency and simplicity are - at odds; Bootstring aims at a good balance between them. - - * Readability: Basic code points appearing in the extended string - are represented as themselves in the basic string (although the - main purpose is to improve efficiency, not readability). - - Punycode can also support an additional feature that is not used by - the ToASCII and ToUnicode operations of [IDNA]. When extended - strings are case-folded prior to encoding, the basic string can use - mixed case to tell how to convert the folded string into a mixed-case - string. See appendix A "Mixed-case annotation". - -1.2 Interaction of protocol parts - - Punycode is used by the IDNA protocol [IDNA] for converting domain - labels into ASCII; it is not designed for any other purpose. It is - explicitly not designed for processing arbitrary free text. - -2. Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14, RFC 2119 - [RFC2119]. - - A code point is an integral value associated with a character in a - coded character set. - - As in the Unicode Standard [UNICODE], Unicode code points are denoted - by "U+" followed by four to six hexadecimal digits, while a range of - code points is denoted by two hexadecimal numbers separated by "..", - with no prefixes. - - The operators div and mod perform integer division; (x div y) is the - quotient of x divided by y, discarding the remainder, and (x mod y) - is the remainder, so (x div y) * y + (x mod y) == x. Bootstring uses - these operators only with nonnegative operands, so the quotient and - remainder are always nonnegative. - - The break statement jumps out of the innermost loop (as in C). - - - - -Costello Standards Track [Page 3] - -RFC 3492 IDNA Punycode March 2003 - - - An overflow is an attempt to compute a value that exceeds the maximum - value of an integer variable. - -3. Bootstring description - - Bootstring represents an arbitrary sequence of code points (the - "extended string") as a sequence of basic code points (the "basic - string"). This section describes the representation. Section 6 - "Bootstring algorithms" presents the algorithms as pseudocode. - Sections 7.1 "Decoding traces" and 7.2 "Encoding traces" trace the - algorithms for sample inputs. - - The following sections describe the four techniques used in - Bootstring. "Basic code point segregation" is a very simple and - efficient encoding for basic code points occurring in the extended - string: they are simply copied all at once. "Insertion unsort - coding" encodes the non-basic code points as deltas, and processes - the code points in numerical order rather than in order of - appearance, which typically results in smaller deltas. The deltas - are represented as "generalized variable-length integers", which use - basic code points to represent nonnegative integers. The parameters - of this integer representation are dynamically adjusted using "bias - adaptation", to improve efficiency when consecutive deltas have - similar magnitudes. - -3.1 Basic code point segregation - - All basic code points appearing in the extended string are - represented literally at the beginning of the basic string, in their - original order, followed by a delimiter if (and only if) the number - of basic code points is nonzero. The delimiter is a particular basic - code point, which never appears in the remainder of the basic string. - The decoder can therefore find the end of the literal portion (if - there is one) by scanning for the last delimiter. - -3.2 Insertion unsort coding - - The remainder of the basic string (after the last delimiter if there - is one) represents a sequence of nonnegative integral deltas as - generalized variable-length integers, described in section 3.3. The - meaning of the deltas is best understood in terms of the decoder. - - The decoder builds the extended string incrementally. Initially, the - extended string is a copy of the literal portion of the basic string - (excluding the last delimiter). The decoder inserts non-basic code - points, one for each delta, into the extended string, ultimately - arriving at the final decoded string. - - - - -Costello Standards Track [Page 4] - -RFC 3492 IDNA Punycode March 2003 - - - At the heart of this process is a state machine with two state - variables: an index i and a counter n. The index i refers to a - position in the extended string; it ranges from 0 (the first - position) to the current length of the extended string (which refers - to a potential position beyond the current end). If the current - state is <n,i>, the next state is <n,i+1> if i is less than the - length of the extended string, or <n+1,0> if i equals the length of - the extended string. In other words, each state change causes i to - increment, wrapping around to zero if necessary, and n counts the - number of wrap-arounds. - - Notice that the state always advances monotonically (there is no way - for the decoder to return to an earlier state). At each state, an - insertion is either performed or not performed. At most one - insertion is performed in a given state. An insertion inserts the - value of n at position i in the extended string. The deltas are a - run-length encoding of this sequence of events: they are the lengths - of the runs of non-insertion states preceeding the insertion states. - Hence, for each delta, the decoder performs delta state changes, then - an insertion, and then one more state change. (An implementation - need not perform each state change individually, but can instead use - division and remainder calculations to compute the next insertion - state directly.) It is an error if the inserted code point is a - basic code point (because basic code points were supposed to be - segregated as described in section 3.1). - - The encoder's main task is to derive the sequence of deltas that will - cause the decoder to construct the desired string. It can do this by - repeatedly scanning the extended string for the next code point that - the decoder would need to insert, and counting the number of state - changes the decoder would need to perform, mindful of the fact that - the decoder's extended string will include only those code points - that have already been inserted. Section 6.3 "Encoding procedure" - gives a precise algorithm. - -3.3 Generalized variable-length integers - - In a conventional integer representation the base is the number of - distinct symbols for digits, whose values are 0 through base-1. Let - digit_0 denote the least significant digit, digit_1 the next least - significant, and so on. The value represented is the sum over j of - digit_j * w(j), where w(j) = base^j is the weight (scale factor) for - position j. For example, in the base 8 integer 437, the digits are - 7, 3, and 4, and the weights are 1, 8, and 64, so the value is 7 + - 3*8 + 4*64 = 287. This representation has two disadvantages: First, - there are multiple encodings of each value (because there can be - extra zeros in the most significant positions), which is inconvenient - - - - -Costello Standards Track [Page 5] - -RFC 3492 IDNA Punycode March 2003 - - - when unique encodings are needed. Second, the integer is not self- - delimiting, so if multiple integers are concatenated the boundaries - between them are lost. - - The generalized variable-length representation solves these two - problems. The digit values are still 0 through base-1, but now the - integer is self-delimiting by means of thresholds t(j), each of which - is in the range 0 through base-1. Exactly one digit, the most - significant, satisfies digit_j < t(j). Therefore, if several - integers are concatenated, it is easy to separate them, starting with - the first if they are little-endian (least significant digit first), - or starting with the last if they are big-endian (most significant - digit first). As before, the value is the sum over j of digit_j * - w(j), but the weights are different: - - w(0) = 1 - w(j) = w(j-1) * (base - t(j-1)) for j > 0 - - For example, consider the little-endian sequence of base 8 digits - 734251... Suppose the thresholds are 2, 3, 5, 5, 5, 5... This - implies that the weights are 1, 1*(8-2) = 6, 6*(8-3) = 30, 30*(8-5) = - 90, 90*(8-5) = 270, and so on. 7 is not less than 2, and 3 is not - less than 3, but 4 is less than 5, so 4 is the last digit. The value - of 734 is 7*1 + 3*6 + 4*30 = 145. The next integer is 251, with - value 2*1 + 5*6 + 1*30 = 62. Decoding this representation is very - similar to decoding a conventional integer: Start with a current - value of N = 0 and a weight w = 1. Fetch the next digit d and - increase N by d * w. If d is less than the current threshold (t) - then stop, otherwise increase w by a factor of (base - t), update t - for the next position, and repeat. - - Encoding this representation is similar to encoding a conventional - integer: If N < t then output one digit for N and stop, otherwise - output the digit for t + ((N - t) mod (base - t)), then replace N - with (N - t) div (base - t), update t for the next position, and - repeat. - - For any particular set of values of t(j), there is exactly one - generalized variable-length representation of each nonnegative - integral value. - - Bootstring uses little-endian ordering so that the deltas can be - separated starting with the first. The t(j) values are defined in - terms of the constants base, tmin, and tmax, and a state variable - called bias: - - t(j) = base * (j + 1) - bias, - clamped to the range tmin through tmax - - - -Costello Standards Track [Page 6] - -RFC 3492 IDNA Punycode March 2003 - - - The clamping means that if the formula yields a value less than tmin - or greater than tmax, then t(j) = tmin or tmax, respectively. (In - the pseudocode in section 6 "Bootstring algorithms", the expression - base * (j + 1) is denoted by k for performance reasons.) These t(j) - values cause the representation to favor integers within a particular - range determined by the bias. - -3.4 Bias adaptation - - After each delta is encoded or decoded, bias is set for the next - delta as follows: - - 1. Delta is scaled in order to avoid overflow in the next step: - - let delta = delta div 2 - - But when this is the very first delta, the divisor is not 2, but - instead a constant called damp. This compensates for the fact - that the second delta is usually much smaller than the first. - - 2. Delta is increased to compensate for the fact that the next delta - will be inserting into a longer string: - - let delta = delta + (delta div numpoints) - - numpoints is the total number of code points encoded/decoded so - far (including the one corresponding to this delta itself, and - including the basic code points). - - 3. Delta is repeatedly divided until it falls within a threshold, to - predict the minimum number of digits needed to represent the next - delta: - - while delta > ((base - tmin) * tmax) div 2 - do let delta = delta div (base - tmin) - - 4. The bias is set: - - let bias = - (base * the number of divisions performed in step 3) + - (((base - tmin + 1) * delta) div (delta + skew)) - - The motivation for this procedure is that the current delta - provides a hint about the likely size of the next delta, and so - t(j) is set to tmax for the more significant digits starting with - the one expected to be last, tmin for the less significant digits - up through the one expected to be third-last, and somewhere - between tmin and tmax for the digit expected to be second-last - - - -Costello Standards Track [Page 7] - -RFC 3492 IDNA Punycode March 2003 - - - (balancing the hope of the expected-last digit being unnecessary - against the danger of it being insufficient). - -4. Bootstring parameters - - Given a set of basic code points, one needs to be designated as the - delimiter. The base cannot be greater than the number of - distinguishable basic code points remaining. The digit-values in the - range 0 through base-1 need to be associated with distinct non- - delimiter basic code points. In some cases multiple code points need - to have the same digit-value; for example, uppercase and lowercase - versions of the same letter need to be equivalent if basic strings - are case-insensitive. - - The initial value of n cannot be greater than the minimum non-basic - code point that could appear in extended strings. - - The remaining five parameters (tmin, tmax, skew, damp, and the - initial value of bias) need to satisfy the following constraints: - - 0 <= tmin <= tmax <= base-1 - skew >= 1 - damp >= 2 - initial_bias mod base <= base - tmin - - Provided the constraints are satisfied, these five parameters affect - efficiency but not correctness. They are best chosen empirically. - - If support for mixed-case annotation is desired (see appendix A), - make sure that the code points corresponding to 0 through tmax-1 all - have both uppercase and lowercase forms. - -5. Parameter values for Punycode - - Punycode uses the following Bootstring parameter values: - - base = 36 - tmin = 1 - tmax = 26 - skew = 38 - damp = 700 - initial_bias = 72 - initial_n = 128 = 0x80 - - Although the only restriction Punycode imposes on the input integers - is that they be nonnegative, these parameters are especially designed - to work well with Unicode [UNICODE] code points, which are integers - in the range 0..10FFFF (but not D800..DFFF, which are reserved for - - - -Costello Standards Track [Page 8] - -RFC 3492 IDNA Punycode March 2003 - - - use by the UTF-16 encoding of Unicode). The basic code points are - the ASCII [ASCII] code points (0..7F), of which U+002D (-) is the - delimiter, and some of the others have digit-values as follows: - - code points digit-values - ------------ ---------------------- - 41..5A (A-Z) = 0 to 25, respectively - 61..7A (a-z) = 0 to 25, respectively - 30..39 (0-9) = 26 to 35, respectively - - Using hyphen-minus as the delimiter implies that the encoded string - can end with a hyphen-minus only if the Unicode string consists - entirely of basic code points, but IDNA forbids such strings from - being encoded. The encoded string can begin with a hyphen-minus, but - IDNA prepends a prefix. Therefore IDNA using Punycode conforms to - the RFC 952 rule that host name labels neither begin nor end with a - hyphen-minus [RFC952]. - - A decoder MUST recognize the letters in both uppercase and lowercase - forms (including mixtures of both forms). An encoder SHOULD output - only uppercase forms or only lowercase forms, unless it uses mixed- - case annotation (see appendix A). - - Presumably most users will not manually write or type encoded strings - (as opposed to cutting and pasting them), but those who do will need - to be alert to the potential visual ambiguity between the following - sets of characters: - - G 6 - I l 1 - O 0 - S 5 - U V - Z 2 - - Such ambiguities are usually resolved by context, but in a Punycode - encoded string there is no context apparent to humans. - -6. Bootstring algorithms - - Some parts of the pseudocode can be omitted if the parameters satisfy - certain conditions (for which Punycode qualifies). These parts are - enclosed in {braces}, and notes immediately following the pseudocode - explain the conditions under which they can be omitted. - - - - - - - -Costello Standards Track [Page 9] - -RFC 3492 IDNA Punycode March 2003 - - - Formally, code points are integers, and hence the pseudocode assumes - that arithmetic operations can be performed directly on code points. - In some programming languages, explicit conversion between code - points and integers might be necessary. - -6.1 Bias adaptation function - - function adapt(delta,numpoints,firsttime): - if firsttime then let delta = delta div damp - else let delta = delta div 2 - let delta = delta + (delta div numpoints) - let k = 0 - while delta > ((base - tmin) * tmax) div 2 do begin - let delta = delta div (base - tmin) - let k = k + base - end - return k + (((base - tmin + 1) * delta) div (delta + skew)) - - It does not matter whether the modifications to delta and k inside - adapt() affect variables of the same name inside the - encoding/decoding procedures, because after calling adapt() the - caller does not read those variables before overwriting them. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Costello Standards Track [Page 10] - -RFC 3492 IDNA Punycode March 2003 - - -6.2 Decoding procedure - - let n = initial_n - let i = 0 - let bias = initial_bias - let output = an empty string indexed from 0 - consume all code points before the last delimiter (if there is one) - and copy them to output, fail on any non-basic code point - if more than zero code points were consumed then consume one more - (which will be the last delimiter) - while the input is not exhausted do begin - let oldi = i - let w = 1 - for k = base to infinity in steps of base do begin - consume a code point, or fail if there was none to consume - let digit = the code point's digit-value, fail if it has none - let i = i + digit * w, fail on overflow - let t = tmin if k <= bias {+ tmin}, or - tmax if k >= bias + tmax, or k - bias otherwise - if digit < t then break - let w = w * (base - t), fail on overflow - end - let bias = adapt(i - oldi, length(output) + 1, test oldi is 0?) - let n = n + i div (length(output) + 1), fail on overflow - let i = i mod (length(output) + 1) - {if n is a basic code point then fail} - insert n into output at position i - increment i - end - - The full statement enclosed in braces (checking whether n is a basic - code point) can be omitted if initial_n exceeds all basic code points - (which is true for Punycode), because n is never less than initial_n. - - In the assignment of t, where t is clamped to the range tmin through - tmax, "+ tmin" can always be omitted. This makes the clamping - calculation incorrect when bias < k < bias + tmin, but that cannot - happen because of the way bias is computed and because of the - constraints on the parameters. - - Because the decoder state can only advance monotonically, and there - is only one representation of any delta, there is therefore only one - encoded string that can represent a given sequence of integers. The - only error conditions are invalid code points, unexpected end-of- - input, overflow, and basic code points encoded using deltas instead - of appearing literally. If the decoder fails on these errors as - shown above, then it cannot produce the same output for two distinct - inputs. Without this property it would have been necessary to re- - - - -Costello Standards Track [Page 11] - -RFC 3492 IDNA Punycode March 2003 - - - encode the output and verify that it matches the input in order to - guarantee the uniqueness of the encoding. - -6.3 Encoding procedure - - let n = initial_n - let delta = 0 - let bias = initial_bias - let h = b = the number of basic code points in the input - copy them to the output in order, followed by a delimiter if b > 0 - {if the input contains a non-basic code point < n then fail} - while h < length(input) do begin - let m = the minimum {non-basic} code point >= n in the input - let delta = delta + (m - n) * (h + 1), fail on overflow - let n = m - for each code point c in the input (in order) do begin - if c < n {or c is basic} then increment delta, fail on overflow - if c == n then begin - let q = delta - for k = base to infinity in steps of base do begin - let t = tmin if k <= bias {+ tmin}, or - tmax if k >= bias + tmax, or k - bias otherwise - if q < t then break - output the code point for digit t + ((q - t) mod (base - t)) - let q = (q - t) div (base - t) - end - output the code point for digit q - let bias = adapt(delta, h + 1, test h equals b?) - let delta = 0 - increment h - end - end - increment delta and n - end - - The full statement enclosed in braces (checking whether the input - contains a non-basic code point less than n) can be omitted if all - code points less than initial_n are basic code points (which is true - for Punycode if code points are unsigned). - - The brace-enclosed conditions "non-basic" and "or c is basic" can be - omitted if initial_n exceeds all basic code points (which is true for - Punycode), because the code point being tested is never less than - initial_n. - - In the assignment of t, where t is clamped to the range tmin through - tmax, "+ tmin" can always be omitted. This makes the clamping - calculation incorrect when bias < k < bias + tmin, but that cannot - - - -Costello Standards Track [Page 12] - -RFC 3492 IDNA Punycode March 2003 - - - happen because of the way bias is computed and because of the - constraints on the parameters. - - The checks for overflow are necessary to avoid producing invalid - output when the input contains very large values or is very long. - - The increment of delta at the bottom of the outer loop cannot - overflow because delta < length(input) before the increment, and - length(input) is already assumed to be representable. The increment - of n could overflow, but only if h == length(input), in which case - the procedure is finished anyway. - -6.4 Overflow handling - - For IDNA, 26-bit unsigned integers are sufficient to handle all valid - IDNA labels without overflow, because any string that needed a 27-bit - delta would have to exceed either the code point limit (0..10FFFF) or - the label length limit (63 characters). However, overflow handling - is necessary because the inputs are not necessarily valid IDNA - labels. - - If the programming language does not provide overflow detection, the - following technique can be used. Suppose A, B, and C are - representable nonnegative integers and C is nonzero. Then A + B - overflows if and only if B > maxint - A, and A + (B * C) overflows if - and only if B > (maxint - A) div C, where maxint is the greatest - integer for which maxint + 1 cannot be represented. Refer to - appendix C "Punycode sample implementation" for demonstrations of - this technique in the C language. - - The decoding and encoding algorithms shown in sections 6.2 and 6.3 - handle overflow by detecting it whenever it happens. Another - approach is to enforce limits on the inputs that prevent overflow - from happening. For example, if the encoder were to verify that no - input code points exceed M and that the input length does not exceed - L, then no delta could ever exceed (M - initial_n) * (L + 1), and - hence no overflow could occur if integer variables were capable of - representing values that large. This prevention approach would - impose more restrictions on the input than the detection approach - does, but might be considered simpler in some programming languages. - - In theory, the decoder could use an analogous approach, limiting the - number of digits in a variable-length integer (that is, limiting the - number of iterations in the innermost loop). However, the number of - digits that suffice to represent a given delta can sometimes - represent much larger deltas (because of the adaptation), and hence - this approach would probably need integers wider than 32 bits. - - - - -Costello Standards Track [Page 13] - -RFC 3492 IDNA Punycode March 2003 - - - Yet another approach for the decoder is to allow overflow to occur, - but to check the final output string by re-encoding it and comparing - to the decoder input. If and only if they do not match (using a - case-insensitive ASCII comparison) overflow has occurred. This - delayed-detection approach would not impose any more restrictions on - the input than the immediate-detection approach does, and might be - considered simpler in some programming languages. - - In fact, if the decoder is used only inside the IDNA ToUnicode - operation [IDNA], then it need not check for overflow at all, because - ToUnicode performs a higher level re-encoding and comparison, and a - mismatch has the same consequence as if the Punycode decoder had - failed. - -7. Punycode examples - -7.1 Sample strings - - In the Punycode encodings below, the ACE prefix is not shown. - Backslashes show where line breaks have been inserted in strings too - long for one line. - - The first several examples are all translations of the sentence "Why - can't they just speak in <language>?" (courtesy of Michael Kaplan's - "provincial" page [PROVINCIAL]). Word breaks and punctuation have - been removed, as is often done in domain names. - - (A) Arabic (Egyptian): - u+0644 u+064A u+0647 u+0645 u+0627 u+0628 u+062A u+0643 u+0644 - u+0645 u+0648 u+0634 u+0639 u+0631 u+0628 u+064A u+061F - Punycode: egbpdaj6bu4bxfgehfvwxn - - (B) Chinese (simplified): - u+4ED6 u+4EEC u+4E3A u+4EC0 u+4E48 u+4E0D u+8BF4 u+4E2D u+6587 - Punycode: ihqwcrb4cv8a8dqg056pqjye - - (C) Chinese (traditional): - u+4ED6 u+5011 u+7232 u+4EC0 u+9EBD u+4E0D u+8AAA u+4E2D u+6587 - Punycode: ihqwctvzc91f659drss3x8bo0yb - - (D) Czech: Pro<ccaron>prost<ecaron>nemluv<iacute><ccaron>esky - U+0050 u+0072 u+006F u+010D u+0070 u+0072 u+006F u+0073 u+0074 - u+011B u+006E u+0065 u+006D u+006C u+0075 u+0076 u+00ED u+010D - u+0065 u+0073 u+006B u+0079 - Punycode: Proprostnemluvesky-uyb24dma41a - - - - - - -Costello Standards Track [Page 14] - -RFC 3492 IDNA Punycode March 2003 - - - (E) Hebrew: - u+05DC u+05DE u+05D4 u+05D4 u+05DD u+05E4 u+05E9 u+05D5 u+05D8 - u+05DC u+05D0 u+05DE u+05D3 u+05D1 u+05E8 u+05D9 u+05DD u+05E2 - u+05D1 u+05E8 u+05D9 u+05EA - Punycode: 4dbcagdahymbxekheh6e0a7fei0b - - (F) Hindi (Devanagari): - u+092F u+0939 u+0932 u+094B u+0917 u+0939 u+093F u+0928 u+094D - u+0926 u+0940 u+0915 u+094D u+092F u+094B u+0902 u+0928 u+0939 - u+0940 u+0902 u+092C u+094B u+0932 u+0938 u+0915 u+0924 u+0947 - u+0939 u+0948 u+0902 - Punycode: i1baa7eci9glrd9b2ae1bj0hfcgg6iyaf8o0a1dig0cd - - (G) Japanese (kanji and hiragana): - u+306A u+305C u+307F u+3093 u+306A u+65E5 u+672C u+8A9E u+3092 - u+8A71 u+3057 u+3066 u+304F u+308C u+306A u+3044 u+306E u+304B - Punycode: n8jok5ay5dzabd5bym9f0cm5685rrjetr6pdxa - - (H) Korean (Hangul syllables): - u+C138 u+ACC4 u+C758 u+BAA8 u+B4E0 u+C0AC u+B78C u+B4E4 u+C774 - u+D55C u+AD6D u+C5B4 u+B97C u+C774 u+D574 u+D55C u+B2E4 u+BA74 - u+C5BC u+B9C8 u+B098 u+C88B u+C744 u+AE4C - Punycode: 989aomsvi5e83db1d2a355cv1e0vak1dwrv93d5xbh15a0dt30a5j\ - psd879ccm6fea98c - - (I) Russian (Cyrillic): - U+043F u+043E u+0447 u+0435 u+043C u+0443 u+0436 u+0435 u+043E - u+043D u+0438 u+043D u+0435 u+0433 u+043E u+0432 u+043E u+0440 - u+044F u+0442 u+043F u+043E u+0440 u+0443 u+0441 u+0441 u+043A - u+0438 - Punycode: b1abfaaepdrnnbgefbaDotcwatmq2g4l - - (J) Spanish: Porqu<eacute>nopuedensimplementehablarenEspa<ntilde>ol - U+0050 u+006F u+0072 u+0071 u+0075 u+00E9 u+006E u+006F u+0070 - u+0075 u+0065 u+0064 u+0065 u+006E u+0073 u+0069 u+006D u+0070 - u+006C u+0065 u+006D u+0065 u+006E u+0074 u+0065 u+0068 u+0061 - u+0062 u+006C u+0061 u+0072 u+0065 u+006E U+0045 u+0073 u+0070 - u+0061 u+00F1 u+006F u+006C - Punycode: PorqunopuedensimplementehablarenEspaol-fmd56a - - (K) Vietnamese: - T<adotbelow>isaoh<odotbelow>kh<ocirc>ngth<ecirchookabove>ch\ - <ihookabove>n<oacute>iti<ecircacute>ngVi<ecircdotbelow>t - U+0054 u+1EA1 u+0069 u+0073 u+0061 u+006F u+0068 u+1ECD u+006B - u+0068 u+00F4 u+006E u+0067 u+0074 u+0068 u+1EC3 u+0063 u+0068 - u+1EC9 u+006E u+00F3 u+0069 u+0074 u+0069 u+1EBF u+006E u+0067 - U+0056 u+0069 u+1EC7 u+0074 - Punycode: TisaohkhngthchnitingVit-kjcr8268qyxafd2f1b9g - - - -Costello Standards Track [Page 15] - -RFC 3492 IDNA Punycode March 2003 - - - The next several examples are all names of Japanese music artists, - song titles, and TV programs, just because the author happens to have - them handy (but Japanese is useful for providing examples of single- - row text, two-row text, ideographic text, and various mixtures - thereof). - - (L) 3<nen>B<gumi><kinpachi><sensei> - u+0033 u+5E74 U+0042 u+7D44 u+91D1 u+516B u+5148 u+751F - Punycode: 3B-ww4c5e180e575a65lsy2b - - (M) <amuro><namie>-with-SUPER-MONKEYS - u+5B89 u+5BA4 u+5948 u+7F8E u+6075 u+002D u+0077 u+0069 u+0074 - u+0068 u+002D U+0053 U+0055 U+0050 U+0045 U+0052 u+002D U+004D - U+004F U+004E U+004B U+0045 U+0059 U+0053 - Punycode: -with-SUPER-MONKEYS-pc58ag80a8qai00g7n9n - - (N) Hello-Another-Way-<sorezore><no><basho> - U+0048 u+0065 u+006C u+006C u+006F u+002D U+0041 u+006E u+006F - u+0074 u+0068 u+0065 u+0072 u+002D U+0057 u+0061 u+0079 u+002D - u+305D u+308C u+305E u+308C u+306E u+5834 u+6240 - Punycode: Hello-Another-Way--fc4qua05auwb3674vfr0b - - (O) <hitotsu><yane><no><shita>2 - u+3072 u+3068 u+3064 u+5C4B u+6839 u+306E u+4E0B u+0032 - Punycode: 2-u9tlzr9756bt3uc0v - - (P) Maji<de>Koi<suru>5<byou><mae> - U+004D u+0061 u+006A u+0069 u+3067 U+004B u+006F u+0069 u+3059 - u+308B u+0035 u+79D2 u+524D - Punycode: MajiKoi5-783gue6qz075azm5e - - (Q) <pafii>de<runba> - u+30D1 u+30D5 u+30A3 u+30FC u+0064 u+0065 u+30EB u+30F3 u+30D0 - Punycode: de-jg4avhby1noc0d - - (R) <sono><supiido><de> - u+305D u+306E u+30B9 u+30D4 u+30FC u+30C9 u+3067 - Punycode: d9juau41awczczp - - The last example is an ASCII string that breaks the existing rules - for host name labels. (It is not a realistic example for IDNA, - because IDNA never encodes pure ASCII labels.) - - (S) -> $1.00 <- - u+002D u+003E u+0020 u+0024 u+0031 u+002E u+0030 u+0030 u+0020 - u+003C u+002D - Punycode: -> $1.00 <-- - - - - -Costello Standards Track [Page 16] - -RFC 3492 IDNA Punycode March 2003 - - -7.2 Decoding traces - - In the following traces, the evolving state of the decoder is shown - as a sequence of hexadecimal values, representing the code points in - the extended string. An asterisk appears just after the most - recently inserted code point, indicating both n (the value preceeding - the asterisk) and i (the position of the value just after the - asterisk). Other numerical values are decimal. - - Decoding trace of example B from section 7.1: - - n is 128, i is 0, bias is 72 - input is "ihqwcrb4cv8a8dqg056pqjye" - there is no delimiter, so extended string starts empty - delta "ihq" decodes to 19853 - bias becomes 21 - 4E0D * - delta "wc" decodes to 64 - bias becomes 20 - 4E0D 4E2D * - delta "rb" decodes to 37 - bias becomes 13 - 4E3A * 4E0D 4E2D - delta "4c" decodes to 56 - bias becomes 17 - 4E3A 4E48 * 4E0D 4E2D - delta "v8a" decodes to 599 - bias becomes 32 - 4E3A 4EC0 * 4E48 4E0D 4E2D - delta "8d" decodes to 130 - bias becomes 23 - 4ED6 * 4E3A 4EC0 4E48 4E0D 4E2D - delta "qg" decodes to 154 - bias becomes 25 - 4ED6 4EEC * 4E3A 4EC0 4E48 4E0D 4E2D - delta "056p" decodes to 46301 - bias becomes 84 - 4ED6 4EEC 4E3A 4EC0 4E48 4E0D 4E2D 6587 * - delta "qjye" decodes to 88531 - bias becomes 90 - 4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 * 4E2D 6587 - - - - - - - - - - -Costello Standards Track [Page 17] - -RFC 3492 IDNA Punycode March 2003 - - - Decoding trace of example L from section 7.1: - - n is 128, i is 0, bias is 72 - input is "3B-ww4c5e180e575a65lsy2b" - literal portion is "3B-", so extended string starts as: - 0033 0042 - delta "ww4c" decodes to 62042 - bias becomes 27 - 0033 0042 5148 * - delta "5e" decodes to 139 - bias becomes 24 - 0033 0042 516B * 5148 - delta "180e" decodes to 16683 - bias becomes 67 - 0033 5E74 * 0042 516B 5148 - delta "575a" decodes to 34821 - bias becomes 82 - 0033 5E74 0042 516B 5148 751F * - delta "65l" decodes to 14592 - bias becomes 67 - 0033 5E74 0042 7D44 * 516B 5148 751F - delta "sy2b" decodes to 42088 - bias becomes 84 - 0033 5E74 0042 7D44 91D1 * 516B 5148 751F - - - - - - - - - - - - - - - - - - - - - - - - - - - -Costello Standards Track [Page 18] - -RFC 3492 IDNA Punycode March 2003 - - -7.3 Encoding traces - - In the following traces, code point values are hexadecimal, while - other numerical values are decimal. - - Encoding trace of example B from section 7.1: - - bias is 72 - input is: - 4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 4E2D 6587 - there are no basic code points, so no literal portion - next code point to insert is 4E0D - needed delta is 19853, encodes as "ihq" - bias becomes 21 - next code point to insert is 4E2D - needed delta is 64, encodes as "wc" - bias becomes 20 - next code point to insert is 4E3A - needed delta is 37, encodes as "rb" - bias becomes 13 - next code point to insert is 4E48 - needed delta is 56, encodes as "4c" - bias becomes 17 - next code point to insert is 4EC0 - needed delta is 599, encodes as "v8a" - bias becomes 32 - next code point to insert is 4ED6 - needed delta is 130, encodes as "8d" - bias becomes 23 - next code point to insert is 4EEC - needed delta is 154, encodes as "qg" - bias becomes 25 - next code point to insert is 6587 - needed delta is 46301, encodes as "056p" - bias becomes 84 - next code point to insert is 8BF4 - needed delta is 88531, encodes as "qjye" - bias becomes 90 - output is "ihqwcrb4cv8a8dqg056pqjye" - - - - - - - - - - - - -Costello Standards Track [Page 19] - -RFC 3492 IDNA Punycode March 2003 - - - Encoding trace of example L from section 7.1: - - bias is 72 - input is: - 0033 5E74 0042 7D44 91D1 516B 5148 751F - basic code points (0033, 0042) are copied to literal portion: "3B-" - next code point to insert is 5148 - needed delta is 62042, encodes as "ww4c" - bias becomes 27 - next code point to insert is 516B - needed delta is 139, encodes as "5e" - bias becomes 24 - next code point to insert is 5E74 - needed delta is 16683, encodes as "180e" - bias becomes 67 - next code point to insert is 751F - needed delta is 34821, encodes as "575a" - bias becomes 82 - next code point to insert is 7D44 - needed delta is 14592, encodes as "65l" - bias becomes 67 - next code point to insert is 91D1 - needed delta is 42088, encodes as "sy2b" - bias becomes 84 - output is "3B-ww4c5e180e575a65lsy2b" - -8. Security Considerations - - Users expect each domain name in DNS to be controlled by a single - authority. If a Unicode string intended for use as a domain label - could map to multiple ACE labels, then an internationalized domain - name could map to multiple ASCII domain names, each controlled by a - different authority, some of which could be spoofs that hijack - service requests intended for another. Therefore Punycode is - designed so that each Unicode string has a unique encoding. - - However, there can still be multiple Unicode representations of the - "same" text, for various definitions of "same". This problem is - addressed to some extent by the Unicode standard under the topic of - canonicalization, and this work is leveraged for domain names by - Nameprep [NAMEPREP]. - - - - - - - - - - -Costello Standards Track [Page 20] - -RFC 3492 IDNA Punycode March 2003 - - -9. References - -9.1 Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - -9.2 Informative References - - [RFC952] Harrenstien, K., Stahl, M. and E. Feinler, "DOD Internet - Host Table Specification", RFC 952, October 1985. - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and - Facilities", STD 13, RFC 1034, November 1987. - - [IDNA] Faltstrom, P., Hoffman, P. and A. Costello, - "Internationalizing Domain Names in Applications - (IDNA)", RFC 3490, March 2003. - - [NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep - Profile for Internationalized Domain Names (IDN)", RFC - 3491, March 2003. - - [ASCII] Cerf, V., "ASCII format for Network Interchange", RFC - 20, October 1969. - - [PROVINCIAL] Kaplan, M., "The 'anyone can be provincial!' page", - http://www.trigeminal.com/samples/provincial.html. - - [UNICODE] The Unicode Consortium, "The Unicode Standard", - http://www.unicode.org/unicode/standard/standard.html. - - - - - - - - - - - - - - - - - - - - -Costello Standards Track [Page 21] - -RFC 3492 IDNA Punycode March 2003 - - -A. Mixed-case annotation - - In order to use Punycode to represent case-insensitive strings, - higher layers need to case-fold the strings prior to Punycode - encoding. The encoded string can use mixed case as an annotation - telling how to convert the folded string into a mixed-case string for - display purposes. Note, however, that mixed-case annotation is not - used by the ToASCII and ToUnicode operations specified in [IDNA], and - therefore implementors of IDNA can disregard this appendix. - - Basic code points can use mixed case directly, because the decoder - copies them verbatim, leaving lowercase code points lowercase, and - leaving uppercase code points uppercase. Each non-basic code point - is represented by a delta, which is represented by a sequence of - basic code points, the last of which provides the annotation. If it - is uppercase, it is a suggestion to map the non-basic code point to - uppercase (if possible); if it is lowercase, it is a suggestion to - map the non-basic code point to lowercase (if possible). - - These annotations do not alter the code points returned by decoders; - the annotations are returned separately, for the caller to use or - ignore. Encoders can accept annotations in addition to code points, - but the annotations do not alter the output, except to influence the - uppercase/lowercase form of ASCII letters. - - Punycode encoders and decoders need not support these annotations, - and higher layers need not use them. - -B. Disclaimer and license - - Regarding this entire document or any portion of it (including the - pseudocode and C code), the author makes no guarantees and is not - responsible for any damage resulting from its use. The author grants - irrevocable permission to anyone to use, modify, and distribute it in - any way that does not diminish the rights of anyone else to use, - modify, and distribute it, provided that redistributed derivative - works do not contain misleading author or version information. - Derivative works need not be licensed under similar terms. - - - - - - - - - - - - - -Costello Standards Track [Page 22] - -RFC 3492 IDNA Punycode March 2003 - - -C. Punycode sample implementation - -/* -punycode.c from RFC 3492 -http://www.nicemice.net/idn/ -Adam M. Costello -http://www.nicemice.net/amc/ - -This is ANSI C code (C89) implementing Punycode (RFC 3492). - -*/ - - -/************************************************************/ -/* Public interface (would normally go in its own .h file): */ - -#include <limits.h> - -enum punycode_status { - punycode_success, - punycode_bad_input, /* Input is invalid. */ - punycode_big_output, /* Output would exceed the space provided. */ - punycode_overflow /* Input needs wider integers to process. */ -}; - -#if UINT_MAX >= (1 << 26) - 1 -typedef unsigned int punycode_uint; -#else -typedef unsigned long punycode_uint; -#endif - -enum punycode_status punycode_encode( - punycode_uint input_length, - const punycode_uint input[], - const unsigned char case_flags[], - punycode_uint *output_length, - char output[] ); - - /* punycode_encode() converts Unicode to Punycode. The input */ - /* is represented as an array of Unicode code points (not code */ - /* units; surrogate pairs are not allowed), and the output */ - /* will be represented as an array of ASCII code points. The */ - /* output string is *not* null-terminated; it will contain */ - /* zeros if and only if the input contains zeros. (Of course */ - /* the caller can leave room for a terminator and add one if */ - /* needed.) The input_length is the number of code points in */ - /* the input. The output_length is an in/out argument: the */ - /* caller passes in the maximum number of code points that it */ - - - -Costello Standards Track [Page 23] - -RFC 3492 IDNA Punycode March 2003 - - - /* can receive, and on successful return it will contain the */ - /* number of code points actually output. The case_flags array */ - /* holds input_length boolean values, where nonzero suggests that */ - /* the corresponding Unicode character be forced to uppercase */ - /* after being decoded (if possible), and zero suggests that */ - /* it be forced to lowercase (if possible). ASCII code points */ - /* are encoded literally, except that ASCII letters are forced */ - /* to uppercase or lowercase according to the corresponding */ - /* uppercase flags. If case_flags is a null pointer then ASCII */ - /* letters are left as they are, and other code points are */ - /* treated as if their uppercase flags were zero. The return */ - /* value can be any of the punycode_status values defined above */ - /* except punycode_bad_input; if not punycode_success, then */ - /* output_size and output might contain garbage. */ - -enum punycode_status punycode_decode( - punycode_uint input_length, - const char input[], - punycode_uint *output_length, - punycode_uint output[], - unsigned char case_flags[] ); - - /* punycode_decode() converts Punycode to Unicode. The input is */ - /* represented as an array of ASCII code points, and the output */ - /* will be represented as an array of Unicode code points. The */ - /* input_length is the number of code points in the input. The */ - /* output_length is an in/out argument: the caller passes in */ - /* the maximum number of code points that it can receive, and */ - /* on successful return it will contain the actual number of */ - /* code points output. The case_flags array needs room for at */ - /* least output_length values, or it can be a null pointer if the */ - /* case information is not needed. A nonzero flag suggests that */ - /* the corresponding Unicode character be forced to uppercase */ - /* by the caller (if possible), while zero suggests that it be */ - /* forced to lowercase (if possible). ASCII code points are */ - /* output already in the proper case, but their flags will be set */ - /* appropriately so that applying the flags would be harmless. */ - /* The return value can be any of the punycode_status values */ - /* defined above; if not punycode_success, then output_length, */ - /* output, and case_flags might contain garbage. On success, the */ - /* decoder will never need to write an output_length greater than */ - /* input_length, because of how the encoding is defined. */ - -/**********************************************************/ -/* Implementation (would normally go in its own .c file): */ - -#include <string.h> - - - - -Costello Standards Track [Page 24] - -RFC 3492 IDNA Punycode March 2003 - - -/*** Bootstring parameters for Punycode ***/ - -enum { base = 36, tmin = 1, tmax = 26, skew = 38, damp = 700, - initial_bias = 72, initial_n = 0x80, delimiter = 0x2D }; - -/* basic(cp) tests whether cp is a basic code point: */ -#define basic(cp) ((punycode_uint)(cp) < 0x80) - -/* delim(cp) tests whether cp is a delimiter: */ -#define delim(cp) ((cp) == delimiter) - -/* decode_digit(cp) returns the numeric value of a basic code */ -/* point (for use in representing integers) in the range 0 to */ -/* base-1, or base if cp is does not represent a value. */ - -static punycode_uint decode_digit(punycode_uint cp) -{ - return cp - 48 < 10 ? cp - 22 : cp - 65 < 26 ? cp - 65 : - cp - 97 < 26 ? cp - 97 : base; -} - -/* encode_digit(d,flag) returns the basic code point whose value */ -/* (when used for representing integers) is d, which needs to be in */ -/* the range 0 to base-1. The lowercase form is used unless flag is */ -/* nonzero, in which case the uppercase form is used. The behavior */ -/* is undefined if flag is nonzero and digit d has no uppercase form. */ - -static char encode_digit(punycode_uint d, int flag) -{ - return d + 22 + 75 * (d < 26) - ((flag != 0) << 5); - /* 0..25 map to ASCII a..z or A..Z */ - /* 26..35 map to ASCII 0..9 */ -} - -/* flagged(bcp) tests whether a basic code point is flagged */ -/* (uppercase). The behavior is undefined if bcp is not a */ -/* basic code point. */ - -#define flagged(bcp) ((punycode_uint)(bcp) - 65 < 26) - -/* encode_basic(bcp,flag) forces a basic code point to lowercase */ -/* if flag is zero, uppercase if flag is nonzero, and returns */ -/* the resulting code point. The code point is unchanged if it */ -/* is caseless. The behavior is undefined if bcp is not a basic */ -/* code point. */ - -static char encode_basic(punycode_uint bcp, int flag) -{ - - - -Costello Standards Track [Page 25] - -RFC 3492 IDNA Punycode March 2003 - - - bcp -= (bcp - 97 < 26) << 5; - return bcp + ((!flag && (bcp - 65 < 26)) << 5); -} - -/*** Platform-specific constants ***/ - -/* maxint is the maximum value of a punycode_uint variable: */ -static const punycode_uint maxint = -1; -/* Because maxint is unsigned, -1 becomes the maximum value. */ - -/*** Bias adaptation function ***/ - -static punycode_uint adapt( - punycode_uint delta, punycode_uint numpoints, int firsttime ) -{ - punycode_uint k; - - delta = firsttime ? delta / damp : delta >> 1; - /* delta >> 1 is a faster way of doing delta / 2 */ - delta += delta / numpoints; - - for (k = 0; delta > ((base - tmin) * tmax) / 2; k += base) { - delta /= base - tmin; - } - - return k + (base - tmin + 1) * delta / (delta + skew); -} - -/*** Main encode function ***/ - -enum punycode_status punycode_encode( - punycode_uint input_length, - const punycode_uint input[], - const unsigned char case_flags[], - punycode_uint *output_length, - char output[] ) -{ - punycode_uint n, delta, h, b, out, max_out, bias, j, m, q, k, t; - - /* Initialize the state: */ - - n = initial_n; - delta = out = 0; - max_out = *output_length; - bias = initial_bias; - - /* Handle the basic code points: */ - - - - -Costello Standards Track [Page 26] - -RFC 3492 IDNA Punycode March 2003 - - - for (j = 0; j < input_length; ++j) { - if (basic(input[j])) { - if (max_out - out < 2) return punycode_big_output; - output[out++] = - case_flags ? encode_basic(input[j], case_flags[j]) : input[j]; - } - /* else if (input[j] < n) return punycode_bad_input; */ - /* (not needed for Punycode with unsigned code points) */ - } - - h = b = out; - - /* h is the number of code points that have been handled, b is the */ - /* number of basic code points, and out is the number of characters */ - /* that have been output. */ - - if (b > 0) output[out++] = delimiter; - - /* Main encoding loop: */ - - while (h < input_length) { - /* All non-basic code points < n have been */ - /* handled already. Find the next larger one: */ - - for (m = maxint, j = 0; j < input_length; ++j) { - /* if (basic(input[j])) continue; */ - /* (not needed for Punycode) */ - if (input[j] >= n && input[j] < m) m = input[j]; - } - - /* Increase delta enough to advance the decoder's */ - /* <n,i> state to <m,0>, but guard against overflow: */ - - if (m - n > (maxint - delta) / (h + 1)) return punycode_overflow; - delta += (m - n) * (h + 1); - n = m; - - for (j = 0; j < input_length; ++j) { - /* Punycode does not need to check whether input[j] is basic: */ - if (input[j] < n /* || basic(input[j]) */ ) { - if (++delta == 0) return punycode_overflow; - } - - if (input[j] == n) { - /* Represent delta as a generalized variable-length integer: */ - - for (q = delta, k = base; ; k += base) { - if (out >= max_out) return punycode_big_output; - - - -Costello Standards Track [Page 27] - -RFC 3492 IDNA Punycode March 2003 - - - t = k <= bias /* + tmin */ ? tmin : /* +tmin not needed */ - k >= bias + tmax ? tmax : k - bias; - if (q < t) break; - output[out++] = encode_digit(t + (q - t) % (base - t), 0); - q = (q - t) / (base - t); - } - - output[out++] = encode_digit(q, case_flags && case_flags[j]); - bias = adapt(delta, h + 1, h == b); - delta = 0; - ++h; - } - } - - ++delta, ++n; - } - - *output_length = out; - return punycode_success; -} - -/*** Main decode function ***/ - -enum punycode_status punycode_decode( - punycode_uint input_length, - const char input[], - punycode_uint *output_length, - punycode_uint output[], - unsigned char case_flags[] ) -{ - punycode_uint n, out, i, max_out, bias, - b, j, in, oldi, w, k, digit, t; - - /* Initialize the state: */ - - n = initial_n; - out = i = 0; - max_out = *output_length; - bias = initial_bias; - - /* Handle the basic code points: Let b be the number of input code */ - /* points before the last delimiter, or 0 if there is none, then */ - /* copy the first b code points to the output. */ - - for (b = j = 0; j < input_length; ++j) if (delim(input[j])) b = j; - if (b > max_out) return punycode_big_output; - - for (j = 0; j < b; ++j) { - - - -Costello Standards Track [Page 28] - -RFC 3492 IDNA Punycode March 2003 - - - if (case_flags) case_flags[out] = flagged(input[j]); - if (!basic(input[j])) return punycode_bad_input; - output[out++] = input[j]; - } - - /* Main decoding loop: Start just after the last delimiter if any */ - /* basic code points were copied; start at the beginning otherwise. */ - - for (in = b > 0 ? b + 1 : 0; in < input_length; ++out) { - - /* in is the index of the next character to be consumed, and */ - /* out is the number of code points in the output array. */ - - /* Decode a generalized variable-length integer into delta, */ - /* which gets added to i. The overflow checking is easier */ - /* if we increase i as we go, then subtract off its starting */ - /* value at the end to obtain delta. */ - - for (oldi = i, w = 1, k = base; ; k += base) { - if (in >= input_length) return punycode_bad_input; - digit = decode_digit(input[in++]); - if (digit >= base) return punycode_bad_input; - if (digit > (maxint - i) / w) return punycode_overflow; - i += digit * w; - t = k <= bias /* + tmin */ ? tmin : /* +tmin not needed */ - k >= bias + tmax ? tmax : k - bias; - if (digit < t) break; - if (w > maxint / (base - t)) return punycode_overflow; - w *= (base - t); - } - - bias = adapt(i - oldi, out + 1, oldi == 0); - - /* i was supposed to wrap around from out+1 to 0, */ - /* incrementing n each time, so we'll fix that now: */ - - if (i / (out + 1) > maxint - n) return punycode_overflow; - n += i / (out + 1); - i %= (out + 1); - - /* Insert n at position i of the output: */ - - /* not needed for Punycode: */ - /* if (decode_digit(n) <= base) return punycode_invalid_input; */ - if (out >= max_out) return punycode_big_output; - - if (case_flags) { - memmove(case_flags + i + 1, case_flags + i, out - i); - - - -Costello Standards Track [Page 29] - -RFC 3492 IDNA Punycode March 2003 - - - /* Case of last character determines uppercase flag: */ - case_flags[i] = flagged(input[in - 1]); - } - - memmove(output + i + 1, output + i, (out - i) * sizeof *output); - output[i++] = n; - } - - *output_length = out; - return punycode_success; -} - -/******************************************************************/ -/* Wrapper for testing (would normally go in a separate .c file): */ - -#include <assert.h> -#include <stdio.h> -#include <stdlib.h> -#include <string.h> - -/* For testing, we'll just set some compile-time limits rather than */ -/* use malloc(), and set a compile-time option rather than using a */ -/* command-line option. */ - -enum { - unicode_max_length = 256, - ace_max_length = 256 -}; - -static void usage(char **argv) -{ - fprintf(stderr, - "\n" - "%s -e reads code points and writes a Punycode string.\n" - "%s -d reads a Punycode string and writes code points.\n" - "\n" - "Input and output are plain text in the native character set.\n" - "Code points are in the form u+hex separated by whitespace.\n" - "Although the specification allows Punycode strings to contain\n" - "any characters from the ASCII repertoire, this test code\n" - "supports only the printable characters, and needs the Punycode\n" - "string to be followed by a newline.\n" - "The case of the u in u+hex is the force-to-uppercase flag.\n" - , argv[0], argv[0]); - exit(EXIT_FAILURE); -} - -static void fail(const char *msg) - - - -Costello Standards Track [Page 30] - -RFC 3492 IDNA Punycode March 2003 - - -{ - fputs(msg,stderr); - exit(EXIT_FAILURE); -} - -static const char too_big[] = - "input or output is too large, recompile with larger limits\n"; -static const char invalid_input[] = "invalid input\n"; -static const char overflow[] = "arithmetic overflow\n"; -static const char io_error[] = "I/O error\n"; - -/* The following string is used to convert printable */ -/* characters between ASCII and the native charset: */ - -static const char print_ascii[] = - "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n" - "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n" - " !\"#$%&'()*+,-./" - "0123456789:;<=>?" - "@ABCDEFGHIJKLMNO" - "PQRSTUVWXYZ[\\]^_" - "`abcdefghijklmno" - "pqrstuvwxyz{|}~\n"; - -int main(int argc, char **argv) -{ - enum punycode_status status; - int r; - unsigned int input_length, output_length, j; - unsigned char case_flags[unicode_max_length]; - - if (argc != 2) usage(argv); - if (argv[1][0] != '-') usage(argv); - if (argv[1][2] != 0) usage(argv); - - if (argv[1][1] == 'e') { - punycode_uint input[unicode_max_length]; - unsigned long codept; - char output[ace_max_length+1], uplus[3]; - int c; - - /* Read the input code points: */ - - input_length = 0; - - for (;;) { - r = scanf("%2s%lx", uplus, &codept); - if (ferror(stdin)) fail(io_error); - - - -Costello Standards Track [Page 31] - -RFC 3492 IDNA Punycode March 2003 - - - if (r == EOF || r == 0) break; - - if (r != 2 || uplus[1] != '+' || codept > (punycode_uint)-1) { - fail(invalid_input); - } - - if (input_length == unicode_max_length) fail(too_big); - - if (uplus[0] == 'u') case_flags[input_length] = 0; - else if (uplus[0] == 'U') case_flags[input_length] = 1; - else fail(invalid_input); - - input[input_length++] = codept; - } - - /* Encode: */ - - output_length = ace_max_length; - status = punycode_encode(input_length, input, case_flags, - &output_length, output); - if (status == punycode_bad_input) fail(invalid_input); - if (status == punycode_big_output) fail(too_big); - if (status == punycode_overflow) fail(overflow); - assert(status == punycode_success); - - /* Convert to native charset and output: */ - - for (j = 0; j < output_length; ++j) { - c = output[j]; - assert(c >= 0 && c <= 127); - if (print_ascii[c] == 0) fail(invalid_input); - output[j] = print_ascii[c]; - } - - output[j] = 0; - r = puts(output); - if (r == EOF) fail(io_error); - return EXIT_SUCCESS; - } - - if (argv[1][1] == 'd') { - char input[ace_max_length+2], *p, *pp; - punycode_uint output[unicode_max_length]; - - /* Read the Punycode input string and convert to ASCII: */ - - fgets(input, ace_max_length+2, stdin); - if (ferror(stdin)) fail(io_error); - - - -Costello Standards Track [Page 32] - -RFC 3492 IDNA Punycode March 2003 - - - if (feof(stdin)) fail(invalid_input); - input_length = strlen(input) - 1; - if (input[input_length] != '\n') fail(too_big); - input[input_length] = 0; - - for (p = input; *p != 0; ++p) { - pp = strchr(print_ascii, *p); - if (pp == 0) fail(invalid_input); - *p = pp - print_ascii; - } - - /* Decode: */ - - output_length = unicode_max_length; - status = punycode_decode(input_length, input, &output_length, - output, case_flags); - if (status == punycode_bad_input) fail(invalid_input); - if (status == punycode_big_output) fail(too_big); - if (status == punycode_overflow) fail(overflow); - assert(status == punycode_success); - - /* Output the result: */ - - for (j = 0; j < output_length; ++j) { - r = printf("%s+%04lX\n", - case_flags[j] ? "U" : "u", - (unsigned long) output[j] ); - if (r < 0) fail(io_error); - } - - return EXIT_SUCCESS; - } - - usage(argv); - return EXIT_SUCCESS; /* not reached, but quiets compiler warning */ -} - - - - - - - - - - - - - - - -Costello Standards Track [Page 33] - -RFC 3492 IDNA Punycode March 2003 - - -Author's Address - - Adam M. Costello - University of California, Berkeley - http://www.nicemice.net/amc/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Costello Standards Track [Page 34] - -RFC 3492 IDNA Punycode March 2003 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Costello Standards Track [Page 35] - diff --git a/contrib/bind9/doc/rfc/rfc3493.txt b/contrib/bind9/doc/rfc/rfc3493.txt deleted file mode 100644 index 5fea6c19ecb8..000000000000 --- a/contrib/bind9/doc/rfc/rfc3493.txt +++ /dev/null @@ -1,2187 +0,0 @@ - - - - - - -Network Working Group R. Gilligan -Request for Comments: 3493 Intransa, Inc. -Obsoletes: 2553 S. Thomson -Category: Informational Cisco - J. Bound - J. McCann - Hewlett-Packard - W. Stevens - February 2003 - - - Basic Socket Interface Extensions for IPv6 - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - The de facto standard Application Program Interface (API) for TCP/IP - applications is the "sockets" interface. Although this API was - developed for Unix in the early 1980s it has also been implemented on - a wide variety of non-Unix systems. TCP/IP applications written - using the sockets API have in the past enjoyed a high degree of - portability and we would like the same portability with IPv6 - applications. But changes are required to the sockets API to support - IPv6 and this memo describes these changes. These include a new - socket address structure to carry IPv6 addresses, new address - conversion functions, and some new socket options. These extensions - are designed to provide access to the basic IPv6 features required by - TCP and UDP applications, including multicasting, while introducing a - minimum of change into the system and providing complete - compatibility for existing IPv4 applications. Additional extensions - for advanced IPv6 features (raw sockets and access to the IPv6 - extension headers) are defined in another document. - - - - - - - - - - -Gilligan, et al. Informational [Page 1] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - -Table of Contents - - 1. Introduction................................................3 - 2. Design Considerations.......................................4 - 2.1 What Needs to be Changed...............................4 - 2.2 Data Types.............................................6 - 2.3 Headers................................................6 - 2.4 Structures.............................................6 - 3. Socket Interface............................................6 - 3.1 IPv6 Address Family and Protocol Family................6 - 3.2 IPv6 Address Structure.................................7 - 3.3 Socket Address Structure for 4.3BSD-Based Systems......7 - 3.4 Socket Address Structure for 4.4BSD-Based Systems......9 - 3.5 The Socket Functions...................................9 - 3.6 Compatibility with IPv4 Applications..................10 - 3.7 Compatibility with IPv4 Nodes.........................11 - 3.8 IPv6 Wildcard Address.................................11 - 3.9 IPv6 Loopback Address.................................13 - 3.10 Portability Additions.................................14 - 4. Interface Identification...................................16 - 4.1 Name-to-Index.........................................17 - 4.2 Index-to-Name.........................................17 - 4.3 Return All Interface Names and Indexes................18 - 4.4 Free Memory...........................................18 - 5. Socket Options.............................................18 - 5.1 Unicast Hop Limit.....................................19 - 5.2 Sending and Receiving Multicast Packets...............19 - 5.3 IPV6_V6ONLY option for AF_INET6 Sockets...............22 - 6. Library Functions..........................................22 - 6.1 Protocol-Independent Nodename and - Service Name Translation..............................23 - 6.2 Socket Address Structure to Node Name - and Service Name......................................28 - 6.3 Address Conversion Functions..........................31 - 6.4 Address Testing Macros................................33 - 7. Summary of New Definitions.................................33 - 8. Security Considerations....................................35 - 9. Changes from RFC 2553......................................35 - 10. Acknowledgments............................................36 - 11. References.................................................37 - 12. Authors' Addresses.........................................38 - 13. Full Copyright Statement...................................39 - - - - - - - - - -Gilligan, et al. Informational [Page 2] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - -1. Introduction - - While IPv4 addresses are 32 bits long, IPv6 addresses are 128 bits - long. The socket interface makes the size of an IP address quite - visible to an application; virtually all TCP/IP applications for - BSD-based systems have knowledge of the size of an IP address. Those - parts of the API that expose the addresses must be changed to - accommodate the larger IPv6 address size. IPv6 also introduces new - features, some of which must be made visible to applications via the - API. This memo defines a set of extensions to the socket interface - to support the larger address size and new features of IPv6. It - defines "basic" extensions that are of use to a broad range of - applications. A companion document, the "advanced" API [4], covers - extensions that are of use to more specialized applications, examples - of which include routing daemons, and the "ping" and "traceroute" - utilities. - - The development of this API was started in 1994 in the IETF IPng - working group. The API has evolved over the years, published first - in RFC 2133, then again in RFC 2553, and reaching its final form in - this document. - - As the API matured and stabilized, it was incorporated into the Open - Group's Networking Services (XNS) specification, issue 5.2, which was - subsequently incorporated into a joint Open Group/IEEE/ISO standard - [3]. - - Effort has been made to ensure that this document and [3] contain the - same information with regard to the API definitions. However, the - reader should note that this document is for informational purposes - only, and that the official standard specification of the sockets API - is [3]. - - It is expected that any future standardization work on this API would - be done by the Open Group Base Working Group [6]. - - It should also be noted that this document describes only those - portions of the API needed for IPv4 and IPv6 communications. Other - potential uses of the API, for example the use of getaddrinfo() and - getnameinfo() with the AF_UNIX address family, are beyond the scope - of this document. - - - - - - - - - - -Gilligan, et al. Informational [Page 3] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - -2. Design Considerations - - There are a number of important considerations in designing changes - to this well-worn API: - - - The API changes should provide both source and binary - compatibility for programs written to the original API. That is, - existing program binaries should continue to operate when run on a - system supporting the new API. In addition, existing applications - that are re-compiled and run on a system supporting the new API - should continue to operate. Simply put, the API changes for IPv6 - should not break existing programs. An additional mechanism for - implementations to verify this is to verify the new symbols are - protected by Feature Test Macros as described in [3]. (Such - Feature Test Macros are not defined by this RFC.) - - - The changes to the API should be as small as possible in order to - simplify the task of converting existing IPv4 applications to - IPv6. - - - Where possible, applications should be able to use this API to - interoperate with both IPv6 and IPv4 hosts. Applications should - not need to know which type of host they are communicating with. - - - IPv6 addresses carried in data structures should be 64-bit - aligned. This is necessary in order to obtain optimum performance - on 64-bit machine architectures. - - Because of the importance of providing IPv4 compatibility in the API, - these extensions are explicitly designed to operate on machines that - provide complete support for both IPv4 and IPv6. A subset of this - API could probably be designed for operation on systems that support - only IPv6. However, this is not addressed in this memo. - -2.1 What Needs to be Changed - - The socket interface API consists of a few distinct components: - - - Core socket functions. - - - Address data structures. - - - Name-to-address translation functions. - - - Address conversion functions. - - - - - - -Gilligan, et al. Informational [Page 4] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - - The core socket functions -- those functions that deal with such - things as setting up and tearing down TCP connections, and sending - and receiving UDP packets -- were designed to be transport - independent. Where protocol addresses are passed as function - arguments, they are carried via opaque pointers. A protocol-specific - address data structure is defined for each protocol that the socket - functions support. Applications must cast pointers to these - protocol-specific address structures into pointers to the generic - "sockaddr" address structure when using the socket functions. These - functions need not change for IPv6, but a new IPv6-specific address - data structure is needed. - - The "sockaddr_in" structure is the protocol-specific data structure - for IPv4. This data structure actually includes 8-octets of unused - space, and it is tempting to try to use this space to adapt the - sockaddr_in structure to IPv6. Unfortunately, the sockaddr_in - structure is not large enough to hold the 16-octet IPv6 address as - well as the other information (address family and port number) that - is needed. So a new address data structure must be defined for IPv6. - - IPv6 addresses are scoped [2] so they could be link-local, site, - organization, global, or other scopes at this time undefined. To - support applications that want to be able to identify a set of - interfaces for a specific scope, the IPv6 sockaddr_in structure must - support a field that can be used by an implementation to identify a - set of interfaces identifying the scope for an IPv6 address. - - The IPv4 name-to-address translation functions in the socket - interface are gethostbyname() and gethostbyaddr(). These are left as - is, and new functions are defined which support both IPv4 and IPv6. - - The IPv4 address conversion functions -- inet_ntoa() and inet_addr() - -- convert IPv4 addresses between binary and printable form. These - functions are quite specific to 32-bit IPv4 addresses. We have - designed two analogous functions that convert both IPv4 and IPv6 - addresses, and carry an address type parameter so that they can be - extended to other protocol families as well. - - Finally, a few miscellaneous features are needed to support IPv6. A - new interface is needed to support the IPv6 hop limit header field. - New socket options are needed to control the sending and receiving of - IPv6 multicast packets. - - The socket interface will be enhanced in the future to provide access - to other IPv6 features. Some of these extensions are described in - [4]. - - - - - -Gilligan, et al. Informational [Page 5] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - -2.2 Data Types - - The data types of the structure elements given in this memo are - intended to track the relevant standards. uintN_t means an unsigned - integer of exactly N bits (e.g., uint16_t). The sa_family_t and - in_port_t types are defined in [3]. - -2.3 Headers - - When function prototypes and structures are shown we show the headers - that must be #included to cause that item to be defined. - -2.4 Structures - - When structures are described the members shown are the ones that - must appear in an implementation. Additional, nonstandard members - may also be defined by an implementation. As an additional - precaution nonstandard members could be verified by Feature Test - Macros as described in [3]. (Such Feature Test Macros are not - defined by this RFC.) - - The ordering shown for the members of a structure is the recommended - ordering, given alignment considerations of multibyte members, but an - implementation may order the members differently. - -3. Socket Interface - - This section specifies the socket interface changes for IPv6. - -3.1 IPv6 Address Family and Protocol Family - - A new address family name, AF_INET6, is defined in <sys/socket.h>. - The AF_INET6 definition distinguishes between the original - sockaddr_in address data structure, and the new sockaddr_in6 data - structure. - - A new protocol family name, PF_INET6, is defined in <sys/socket.h>. - Like most of the other protocol family names, this will usually be - defined to have the same value as the corresponding address family - name: - - #define PF_INET6 AF_INET6 - - The AF_INET6 is used in the first argument to the socket() function - to indicate that an IPv6 socket is being created. - - - - - - -Gilligan, et al. Informational [Page 6] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - -3.2 IPv6 Address Structure - - A new in6_addr structure holds a single IPv6 address and is defined - as a result of including <netinet/in.h>: - - struct in6_addr { - uint8_t s6_addr[16]; /* IPv6 address */ - }; - - This data structure contains an array of sixteen 8-bit elements, - which make up one 128-bit IPv6 address. The IPv6 address is stored - in network byte order. - - The structure in6_addr above is usually implemented with an embedded - union with extra fields that force the desired alignment level in a - manner similar to BSD implementations of "struct in_addr". Those - additional implementation details are omitted here for simplicity. - - An example is as follows: - - struct in6_addr { - union { - uint8_t _S6_u8[16]; - uint32_t _S6_u32[4]; - uint64_t _S6_u64[2]; - } _S6_un; - }; - #define s6_addr _S6_un._S6_u8 - -3.3 Socket Address Structure for 4.3BSD-Based Systems - - In the socket interface, a different protocol-specific data structure - is defined to carry the addresses for each protocol suite. Each - protocol-specific data structure is designed so it can be cast into a - protocol-independent data structure -- the "sockaddr" structure. - Each has a "family" field that overlays the "sa_family" of the - sockaddr data structure. This field identifies the type of the data - structure. - - The sockaddr_in structure is the protocol-specific address data - structure for IPv4. It is used to pass addresses between - applications and the system in the socket functions. The following - sockaddr_in6 structure holds IPv6 addresses and is defined as a - result of including the <netinet/in.h> header: - - - - - - - -Gilligan, et al. Informational [Page 7] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - -struct sockaddr_in6 { - sa_family_t sin6_family; /* AF_INET6 */ - in_port_t sin6_port; /* transport layer port # */ - uint32_t sin6_flowinfo; /* IPv6 flow information */ - struct in6_addr sin6_addr; /* IPv6 address */ - uint32_t sin6_scope_id; /* set of interfaces for a scope */ -}; - - This structure is designed to be compatible with the sockaddr data - structure used in the 4.3BSD release. - - The sin6_family field identifies this as a sockaddr_in6 structure. - This field overlays the sa_family field when the buffer is cast to a - sockaddr data structure. The value of this field must be AF_INET6. - - The sin6_port field contains the 16-bit UDP or TCP port number. This - field is used in the same way as the sin_port field of the - sockaddr_in structure. The port number is stored in network byte - order. - - The sin6_flowinfo field is a 32-bit field intended to contain flow- - related information. The exact way this field is mapped to or from a - packet is not currently specified. Until such time as its use is - specified, applications should set this field to zero when - constructing a sockaddr_in6, and ignore this field in a sockaddr_in6 - structure constructed by the system. - - The sin6_addr field is a single in6_addr structure (defined in the - previous section). This field holds one 128-bit IPv6 address. The - address is stored in network byte order. - - The ordering of elements in this structure is specifically designed - so that when sin6_addr field is aligned on a 64-bit boundary, the - start of the structure will also be aligned on a 64-bit boundary. - This is done for optimum performance on 64-bit architectures. - - The sin6_scope_id field is a 32-bit integer that identifies a set of - interfaces as appropriate for the scope [2] of the address carried in - the sin6_addr field. The mapping of sin6_scope_id to an interface or - set of interfaces is left to implementation and future specifications - on the subject of scoped addresses. - - Notice that the sockaddr_in6 structure will normally be larger than - the generic sockaddr structure. On many existing implementations the - sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both - being 16 bytes. Any existing code that makes this assumption needs - to be examined carefully when converting to IPv6. - - - - -Gilligan, et al. Informational [Page 8] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - -3.4 Socket Address Structure for 4.4BSD-Based Systems - - The 4.4BSD release includes a small, but incompatible change to the - socket interface. The "sa_family" field of the sockaddr data - structure was changed from a 16-bit value to an 8-bit value, and the - space saved used to hold a length field, named "sa_len". The - sockaddr_in6 data structure given in the previous section cannot be - correctly cast into the newer sockaddr data structure. For this - reason, the following alternative IPv6 address data structure is - provided to be used on systems based on 4.4BSD. It is defined as a - result of including the <netinet/in.h> header. - -struct sockaddr_in6 { - uint8_t sin6_len; /* length of this struct */ - sa_family_t sin6_family; /* AF_INET6 */ - in_port_t sin6_port; /* transport layer port # */ - uint32_t sin6_flowinfo; /* IPv6 flow information */ - struct in6_addr sin6_addr; /* IPv6 address */ - uint32_t sin6_scope_id; /* set of interfaces for a scope */ -}; - - The only differences between this data structure and the 4.3BSD - variant are the inclusion of the length field, and the change of the - family field to a 8-bit data type. The definitions of all the other - fields are identical to the structure defined in the previous - section. - - Systems that provide this version of the sockaddr_in6 data structure - must also declare SIN6_LEN as a result of including the - <netinet/in.h> header. This macro allows applications to determine - whether they are being built on a system that supports the 4.3BSD or - 4.4BSD variants of the data structure. - -3.5 The Socket Functions - - Applications call the socket() function to create a socket descriptor - that represents a communication endpoint. The arguments to the - socket() function tell the system which protocol to use, and what - format address structure will be used in subsequent functions. For - example, to create an IPv4/TCP socket, applications make the call: - - s = socket(AF_INET, SOCK_STREAM, 0); - - To create an IPv4/UDP socket, applications make the call: - - s = socket(AF_INET, SOCK_DGRAM, 0); - - - - - -Gilligan, et al. Informational [Page 9] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - - Applications may create IPv6/TCP and IPv6/UDP sockets (which may also - handle IPv4 communication as described in section 3.7) by simply - using the constant AF_INET6 instead of AF_INET in the first argument. - For example, to create an IPv6/TCP socket, applications make the - call: - - s = socket(AF_INET6, SOCK_STREAM, 0); - - To create an IPv6/UDP socket, applications make the call: - - s = socket(AF_INET6, SOCK_DGRAM, 0); - - Once the application has created a AF_INET6 socket, it must use the - sockaddr_in6 address structure when passing addresses in to the - system. The functions that the application uses to pass addresses - into the system are: - - bind() - connect() - sendmsg() - sendto() - - The system will use the sockaddr_in6 address structure to return - addresses to applications that are using AF_INET6 sockets. The - functions that return an address from the system to an application - are: - - accept() - recvfrom() - recvmsg() - getpeername() - getsockname() - - No changes to the syntax of the socket functions are needed to - support IPv6, since all of the "address carrying" functions use an - opaque address pointer, and carry an address length as a function - argument. - -3.6 Compatibility with IPv4 Applications - - In order to support the large base of applications using the original - API, system implementations must provide complete source and binary - compatibility with the original API. This means that systems must - continue to support AF_INET sockets and the sockaddr_in address - structure. Applications must be able to create IPv4/TCP and IPv4/UDP - sockets using the AF_INET constant in the socket() function, as - - - - - -Gilligan, et al. Informational [Page 10] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - - described in the previous section. Applications should be able to - hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP - sockets simultaneously within the same process. - - Applications using the original API should continue to operate as - they did on systems supporting only IPv4. That is, they should - continue to interoperate with IPv4 nodes. - -3.7 Compatibility with IPv4 Nodes - - The API also provides a different type of compatibility: the ability - for IPv6 applications to interoperate with IPv4 applications. This - feature uses the IPv4-mapped IPv6 address format defined in the IPv6 - addressing architecture specification [2]. This address format - allows the IPv4 address of an IPv4 node to be represented as an IPv6 - address. The IPv4 address is encoded into the low-order 32 bits of - the IPv6 address, and the high-order 96 bits hold the fixed prefix - 0:0:0:0:0:FFFF. IPv4-mapped addresses are written as follows: - - ::FFFF:<IPv4-address> - - These addresses can be generated automatically by the getaddrinfo() - function, as described in Section 6.1. - - Applications may use AF_INET6 sockets to open TCP connections to IPv4 - nodes, or send UDP packets to IPv4 nodes, by simply encoding the - destination's IPv4 address as an IPv4-mapped IPv6 address, and - passing that address, within a sockaddr_in6 structure, in the - connect() or sendto() call. When applications use AF_INET6 sockets - to accept TCP connections from IPv4 nodes, or receive UDP packets - from IPv4 nodes, the system returns the peer's address to the - application in the accept(), recvfrom(), or getpeername() call using - a sockaddr_in6 structure encoded this way. - - Few applications will likely need to know which type of node they are - interoperating with. However, for those applications that do need to - know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.4, is - provided. - -3.8 IPv6 Wildcard Address - - While the bind() function allows applications to select the source IP - address of UDP packets and TCP connections, applications often want - the system to select the source address for them. With IPv4, one - specifies the address as the symbolic constant INADDR_ANY (called the - "wildcard" address) in the bind() call, or simply omits the bind() - entirely. - - - - -Gilligan, et al. Informational [Page 11] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - - Since the IPv6 address type is a structure (struct in6_addr), a - symbolic constant can be used to initialize an IPv6 address variable, - but cannot be used in an assignment. Therefore systems provide the - IPv6 wildcard address in two forms. - - The first version is a global variable named "in6addr_any" that is an - in6_addr structure. The extern declaration for this variable is - defined in <netinet/in.h>: - - extern const struct in6_addr in6addr_any; - - Applications use in6addr_any similarly to the way they use INADDR_ANY - in IPv4. For example, to bind a socket to port number 23, but let - the system select the source address, an application could use the - following code: - - struct sockaddr_in6 sin6; - . . . - sin6.sin6_family = AF_INET6; - sin6.sin6_flowinfo = 0; - sin6.sin6_port = htons(23); - sin6.sin6_addr = in6addr_any; /* structure assignment */ - . . . - if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1) - . . . - - The other version is a symbolic constant named IN6ADDR_ANY_INIT and - is defined in <netinet/in.h>. This constant can be used to - initialize an in6_addr structure: - - struct in6_addr anyaddr = IN6ADDR_ANY_INIT; - - Note that this constant can be used ONLY at declaration time. It can - not be used to assign a previously declared in6_addr structure. For - example, the following code will not work: - - /* This is the WRONG way to assign an unspecified address */ - struct sockaddr_in6 sin6; - . . . - sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */ - - Be aware that the IPv4 INADDR_xxx constants are all defined in host - byte order but the IPv6 IN6ADDR_xxx constants and the IPv6 - in6addr_xxx externals are defined in network byte order. - - - - - - - -Gilligan, et al. Informational [Page 12] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - -3.9 IPv6 Loopback Address - - Applications may need to send UDP packets to, or originate TCP - connections to, services residing on the local node. In IPv4, they - can do this by using the constant IPv4 address INADDR_LOOPBACK in - their connect(), sendto(), or sendmsg() call. - - IPv6 also provides a loopback address to contact local TCP and UDP - services. Like the unspecified address, the IPv6 loopback address is - provided in two forms -- a global variable and a symbolic constant. - - The global variable is an in6_addr structure named - "in6addr_loopback." The extern declaration for this variable is - defined in <netinet/in.h>: - - extern const struct in6_addr in6addr_loopback; - - Applications use in6addr_loopback as they would use INADDR_LOOPBACK - in IPv4 applications (but beware of the byte ordering difference - mentioned at the end of the previous section). For example, to open - a TCP connection to the local telnet server, an application could use - the following code: - - struct sockaddr_in6 sin6; - . . . - sin6.sin6_family = AF_INET6; - sin6.sin6_flowinfo = 0; - sin6.sin6_port = htons(23); - sin6.sin6_addr = in6addr_loopback; /* structure assignment */ - . . . - if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1) - . . . - - The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined - in <netinet/in.h>. It can be used at declaration time ONLY; for - example: - - struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT; - - Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment - to a previously declared IPv6 address variable. - - - - - - - - - - -Gilligan, et al. Informational [Page 13] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - -3.10 Portability Additions - - One simple addition to the sockets API that can help application - writers is the "struct sockaddr_storage". This data structure can - simplify writing code that is portable across multiple address - families and platforms. This data structure is designed with the - following goals. - - - Large enough to accommodate all supported protocol-specific address - structures. - - - Aligned at an appropriate boundary so that pointers to it can be - cast as pointers to protocol specific address structures and used - to access the fields of those structures without alignment - problems. - - The sockaddr_storage structure contains field ss_family which is of - type sa_family_t. When a sockaddr_storage structure is cast to a - sockaddr structure, the ss_family field of the sockaddr_storage - structure maps onto the sa_family field of the sockaddr structure. - When a sockaddr_storage structure is cast as a protocol specific - address structure, the ss_family field maps onto a field of that - structure that is of type sa_family_t and that identifies the - protocol's address family. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gilligan, et al. Informational [Page 14] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - - An example implementation design of such a data structure would be as - follows. - -/* - * Desired design of maximum size and alignment - */ -#define _SS_MAXSIZE 128 /* Implementation specific max size */ -#define _SS_ALIGNSIZE (sizeof (int64_t)) - /* Implementation specific desired alignment */ -/* - * Definitions used for sockaddr_storage structure paddings design. - */ -#define _SS_PAD1SIZE (_SS_ALIGNSIZE - sizeof (sa_family_t)) -#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t) + - _SS_PAD1SIZE + _SS_ALIGNSIZE)) -struct sockaddr_storage { - sa_family_t ss_family; /* address family */ - /* Following fields are implementation specific */ - char __ss_pad1[_SS_PAD1SIZE]; - /* 6 byte pad, this is to make implementation - /* specific pad up to alignment field that */ - /* follows explicit in the data structure */ - int64_t __ss_align; /* field to force desired structure */ - /* storage alignment */ - char __ss_pad2[_SS_PAD2SIZE]; - /* 112 byte pad to achieve desired size, */ - /* _SS_MAXSIZE value minus size of ss_family */ - /* __ss_pad1, __ss_align fields is 112 */ -}; - - The above example implementation illustrates a data structure which - will align on a 64-bit boundary. An implementation-specific field - "__ss_align" along with "__ss_pad1" is used to force a 64-bit - alignment which covers proper alignment good enough for the needs of - sockaddr_in6 (IPv6), sockaddr_in (IPv4) address data structures. The - size of padding field __ss_pad1 depends on the chosen alignment - boundary. The size of padding field __ss_pad2 depends on the value - of overall size chosen for the total size of the structure. This - size and alignment are represented in the above example by - implementation specific (not required) constants _SS_MAXSIZE (chosen - value 128) and _SS_ALIGNSIZE (with chosen value 8). Constants - _SS_PAD1SIZE (derived value 6) and _SS_PAD2SIZE (derived value 112) - are also for illustration and not required. The derived values - assume sa_family_t is 2 bytes. The implementation specific - definitions and structure field names above start with an underscore - to denote implementation private namespace. Portable code is not - expected to access or reference those fields or constants. - - - - -Gilligan, et al. Informational [Page 15] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - - On implementations where the sockaddr data structure includes a - "sa_len" field this data structure would look like this: - -/* - * Definitions used for sockaddr_storage structure paddings design. - */ -#define _SS_PAD1SIZE (_SS_ALIGNSIZE - - (sizeof (uint8_t) + sizeof (sa_family_t)) -#define _SS_PAD2SIZE (_SS_MAXSIZE - - (sizeof (uint8_t) + sizeof (sa_family_t) + - _SS_PAD1SIZE + _SS_ALIGNSIZE)) -struct sockaddr_storage { - uint8_t ss_len; /* address length */ - sa_family_t ss_family; /* address family */ - /* Following fields are implementation specific */ - char __ss_pad1[_SS_PAD1SIZE]; - /* 6 byte pad, this is to make implementation - /* specific pad up to alignment field that */ - /* follows explicit in the data structure */ - int64_t __ss_align; /* field to force desired structure */ - /* storage alignment */ - char __ss_pad2[_SS_PAD2SIZE]; - /* 112 byte pad to achieve desired size, */ - /* _SS_MAXSIZE value minus size of ss_len, */ - /* __ss_family, __ss_pad1, __ss_align fields is 112 */ -}; - -4. Interface Identification - - This API uses an interface index (a small positive integer) to - identify the local interface on which a multicast group is joined - (Section 5.2). Additionally, the advanced API [4] uses these same - interface indexes to identify the interface on which a datagram is - received, or to specify the interface on which a datagram is to be - sent. - - Interfaces are normally known by names such as "le0", "sl1", "ppp2", - and the like. On Berkeley-derived implementations, when an interface - is made known to the system, the kernel assigns a unique positive - integer value (called the interface index) to that interface. These - are small positive integers that start at 1. (Note that 0 is never - used for an interface index.) There may be gaps so that there is no - current interface for a particular positive interface index. - - This API defines two functions that map between an interface name and - index, a third function that returns all the interface names and - indexes, and a fourth function to return the dynamic memory allocated - by the previous function. How these functions are implemented is - - - -Gilligan, et al. Informational [Page 16] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - - left up to the implementation. 4.4BSD implementations can implement - these functions using the existing sysctl() function with the - NET_RT_IFLIST command. Other implementations may wish to use ioctl() - for this purpose. - -4.1 Name-to-Index - - The first function maps an interface name into its corresponding - index. - - #include <net/if.h> - - unsigned int if_nametoindex(const char *ifname); - - If ifname is the name of an interface, the if_nametoindex() function - shall return the interface index corresponding to name ifname; - otherwise, it shall return zero. No errors are defined. - -4.2 Index-to-Name - - The second function maps an interface index into its corresponding - name. - - #include <net/if.h> - - char *if_indextoname(unsigned int ifindex, char *ifname); - - When this function is called, the ifname argument shall point to a - buffer of at least IF_NAMESIZE bytes. The function shall place in - this buffer the name of the interface with index ifindex. - (IF_NAMESIZE is also defined in <net/if.h> and its value includes a - terminating null byte at the end of the interface name.) If ifindex - is an interface index, then the function shall return the value - supplied in ifname, which points to a buffer now containing the - interface name. Otherwise, the function shall return a NULL pointer - and set errno to indicate the error. If there is no interface - corresponding to the specified index, errno is set to ENXIO. If - there was a system error (such as running out of memory), errno would - be set to the proper value (e.g., ENOMEM). - - - - - - - - - - - - -Gilligan, et al. Informational [Page 17] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - -4.3 Return All Interface Names and Indexes - - The if_nameindex structure holds the information about a single - interface and is defined as a result of including the <net/if.h> - header. - - struct if_nameindex { - unsigned int if_index; /* 1, 2, ... */ - char *if_name; /* null terminated name: "le0", ... */ - }; - - The final function returns an array of if_nameindex structures, one - structure per interface. - - #include <net/if.h> - - struct if_nameindex *if_nameindex(void); - - The end of the array of structures is indicated by a structure with - an if_index of 0 and an if_name of NULL. The function returns a NULL - pointer upon an error, and would set errno to the appropriate value. - - The memory used for this array of structures along with the interface - names pointed to by the if_name members is obtained dynamically. - This memory is freed by the next function. - -4.4 Free Memory - - The following function frees the dynamic memory that was allocated by - if_nameindex(). - - #include <net/if.h> - - void if_freenameindex(struct if_nameindex *ptr); - - The ptr argument shall be a pointer that was returned by - if_nameindex(). After if_freenameindex() has been called, the - application shall not use the array of which ptr is the address. - -5. Socket Options - - A number of new socket options are defined for IPv6. All of these - new options are at the IPPROTO_IPV6 level. That is, the "level" - parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6 - when using these options. The constant name prefix IPV6_ is used in - all of the new socket options. This serves to clearly identify these - options as applying to IPv6. - - - - -Gilligan, et al. Informational [Page 18] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - - The declaration for IPPROTO_IPV6, the new IPv6 socket options, and - related constants defined in this section are obtained by including - the header <netinet/in.h>. - -5.1 Unicast Hop Limit - - A new setsockopt() option controls the hop limit used in outgoing - unicast IPv6 packets. The name of this option is IPV6_UNICAST_HOPS, - and it is used at the IPPROTO_IPV6 layer. The following example - illustrates how it is used: - - int hoplimit = 10; - - if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, - (char *) &hoplimit, sizeof(hoplimit)) == -1) - perror("setsockopt IPV6_UNICAST_HOPS"); - - When the IPV6_UNICAST_HOPS option is set with setsockopt(), the - option value given is used as the hop limit for all subsequent - unicast packets sent via that socket. If the option is not set, the - system selects a default value. The integer hop limit value (called - x) is interpreted as follows: - - x < -1: return an error of EINVAL - x == -1: use kernel default - 0 <= x <= 255: use x - x >= 256: return an error of EINVAL - - The IPV6_UNICAST_HOPS option may be used with getsockopt() to - determine the hop limit value that the system will use for subsequent - unicast packets sent via that socket. For example: - - int hoplimit; - socklen_t len = sizeof(hoplimit); - - if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, - (char *) &hoplimit, &len) == -1) - perror("getsockopt IPV6_UNICAST_HOPS"); - else - printf("Using %d for hop limit.\n", hoplimit); - -5.2 Sending and Receiving Multicast Packets - - IPv6 applications may send multicast packets by simply specifying an - IPv6 multicast address as the destination address, for example in the - destination address argument of the sendto() function. - - - - - -Gilligan, et al. Informational [Page 19] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - - Three socket options at the IPPROTO_IPV6 layer control some of the - parameters for sending multicast packets. Setting these options is - not required: applications may send multicast packets without using - these options. The setsockopt() options for controlling the sending - of multicast packets are summarized below. These three options can - also be used with getsockopt(). - - IPV6_MULTICAST_IF - - Set the interface to use for outgoing multicast packets. The - argument is the index of the interface to use. If the - interface index is specified as zero, the system selects the - interface (for example, by looking up the address in a routing - table and using the resulting interface). - - Argument type: unsigned int - - IPV6_MULTICAST_HOPS - - Set the hop limit to use for outgoing multicast packets. (Note - a separate option - IPV6_UNICAST_HOPS - is provided to set the - hop limit to use for outgoing unicast packets.) - - The interpretation of the argument is the same as for the - IPV6_UNICAST_HOPS option: - - x < -1: return an error of EINVAL - x == -1: use kernel default - 0 <= x <= 255: use x - x >= 256: return an error of EINVAL - - If IPV6_MULTICAST_HOPS is not set, the default is 1 - (same as IPv4 today) - - Argument type: int - - IPV6_MULTICAST_LOOP - - If a multicast datagram is sent to a group to which the sending - host itself belongs (on the outgoing interface), a copy of the - datagram is looped back by the IP layer for local delivery if - this option is set to 1. If this option is set to 0 a copy is - not looped back. Other option values return an error of - EINVAL. - - - - - - - -Gilligan, et al. Informational [Page 20] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - - If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback; - same as IPv4 today). - - Argument type: unsigned int - - The reception of multicast packets is controlled by the two - setsockopt() options summarized below. An error of EOPNOTSUPP is - returned if these two options are used with getsockopt(). - - IPV6_JOIN_GROUP - - Join a multicast group on a specified local interface. - If the interface index is specified as 0, - the kernel chooses the local interface. - For example, some kernels look up the multicast group - in the normal IPv6 routing table and use the resulting - interface. - - Argument type: struct ipv6_mreq - - IPV6_LEAVE_GROUP - - Leave a multicast group on a specified interface. - If the interface index is specified as 0, the system - may choose a multicast group membership to drop by - matching the multicast address only. - - Argument type: struct ipv6_mreq - - The argument type of both of these options is the ipv6_mreq - structure, defined as a result of including the <netinet/in.h> - header; - - struct ipv6_mreq { - struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */ - unsigned int ipv6mr_interface; /* interface index */ - }; - - Note that to receive multicast datagrams a process must join the - multicast group to which datagrams will be sent. UDP applications - must also bind the UDP port to which datagrams will be sent. Some - processes also bind the multicast group address to the socket, in - addition to the port, to prevent other datagrams destined to that - same port from being delivered to the socket. - - - - - - - -Gilligan, et al. Informational [Page 21] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - -5.3 IPV6_V6ONLY option for AF_INET6 Sockets - - This socket option restricts AF_INET6 sockets to IPv6 communications - only. As stated in section <3.7 Compatibility with IPv4 Nodes>, - AF_INET6 sockets may be used for both IPv4 and IPv6 communications. - Some applications may want to restrict their use of an AF_INET6 - socket to IPv6 communications only. For these applications the - IPV6_V6ONLY socket option is defined. When this option is turned on, - the socket can be used to send and receive IPv6 packets only. This - is an IPPROTO_IPV6 level option. This option takes an int value. - This is a boolean option. By default this option is turned off. - - Here is an example of setting this option: - - int on = 1; - - if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, - (char *)&on, sizeof(on)) == -1) - perror("setsockopt IPV6_V6ONLY"); - else - printf("IPV6_V6ONLY set\n"); - - Note - This option has no effect on the use of IPv4 Mapped addresses - which enter a node as a valid IPv6 addresses for IPv6 communications - as defined by Stateless IP/ICMP Translation Algorithm (SIIT) [5]. - - An example use of this option is to allow two versions of the same - server process to run on the same port, one providing service over - IPv6, the other providing the same service over IPv4. - -6. Library Functions - - New library functions are needed to perform a variety of operations - with IPv6 addresses. Functions are needed to lookup IPv6 addresses - in the Domain Name System (DNS). Both forward lookup (nodename-to- - address translation) and reverse lookup (address-to-nodename - translation) need to be supported. Functions are also needed to - convert IPv6 addresses between their binary and textual form. - - We note that the two existing functions, gethostbyname() and - gethostbyaddr(), are left as-is. New functions are defined to handle - both IPv4 and IPv6 addresses. - - The commonly used function gethostbyname() is inadequate for many - applications, first because it provides no way for the caller to - specify anything about the types of addresses desired (IPv4 only, - IPv6 only, IPv4-mapped IPv6 are OK, etc.), and second because many - implementations of this function are not thread safe. RFC 2133 - - - -Gilligan, et al. Informational [Page 22] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - - defined a function named gethostbyname2() but this function was also - inadequate, first because its use required setting a global option - (RES_USE_INET6) when IPv6 addresses were required, and second because - a flag argument is needed to provide the caller with additional - control over the types of addresses required. The gethostbyname2() - function was deprecated in RFC 2553 and is no longer part of the - basic API. - -6.1 Protocol-Independent Nodename and Service Name Translation - - Nodename-to-address translation is done in a protocol-independent - fashion using the getaddrinfo() function. - -#include <sys/socket.h> -#include <netdb.h> - - -int getaddrinfo(const char *nodename, const char *servname, - const struct addrinfo *hints, struct addrinfo **res); - -void freeaddrinfo(struct addrinfo *ai); - -struct addrinfo { - int ai_flags; /* AI_PASSIVE, AI_CANONNAME, - AI_NUMERICHOST, .. */ - int ai_family; /* AF_xxx */ - int ai_socktype; /* SOCK_xxx */ - int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */ - socklen_t ai_addrlen; /* length of ai_addr */ - char *ai_canonname; /* canonical name for nodename */ - struct sockaddr *ai_addr; /* binary address */ - struct addrinfo *ai_next; /* next structure in linked list */ -}; - - The getaddrinfo() function translates the name of a service location - (for example, a host name) and/or a service name and returns a set of - socket addresses and associated information to be used in creating a - socket with which to address the specified service. - - The nodename and servname arguments are either null pointers or - pointers to null-terminated strings. One or both of these two - arguments must be a non-null pointer. - - The format of a valid name depends on the address family or families. - If a specific family is not given and the name could be interpreted - as valid within multiple supported families, the implementation will - attempt to resolve the name in all supported families and, in absence - of errors, one or more results shall be returned. - - - -Gilligan, et al. Informational [Page 23] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - - If the nodename argument is not null, it can be a descriptive name or - can be an address string. If the specified address family is - AF_INET, AF_INET6, or AF_UNSPEC, valid descriptive names include host - names. If the specified address family is AF_INET or AF_UNSPEC, - address strings using Internet standard dot notation as specified in - inet_addr() are valid. If the specified address family is AF_INET6 - or AF_UNSPEC, standard IPv6 text forms described in inet_pton() are - valid. - - If nodename is not null, the requested service location is named by - nodename; otherwise, the requested service location is local to the - caller. - - If servname is null, the call shall return network-level addresses - for the specified nodename. If servname is not null, it is a null- - terminated character string identifying the requested service. This - can be either a descriptive name or a numeric representation suitable - for use with the address family or families. If the specified - address family is AF_INET, AF_INET6 or AF_UNSPEC, the service can be - specified as a string specifying a decimal port number. - - If the argument hints is not null, it refers to a structure - containing input values that may direct the operation by providing - options and by limiting the returned information to a specific socket - type, address family and/or protocol. In this hints structure every - member other than ai_flags, ai_family, ai_socktype and ai_protocol - shall be set to zero or a null pointer. A value of AF_UNSPEC for - ai_family means that the caller shall accept any address family. A - value of zero for ai_socktype means that the caller shall accept any - socket type. A value of zero for ai_protocol means that the caller - shall accept any protocol. If hints is a null pointer, the behavior - shall be as if it referred to a structure containing the value zero - for the ai_flags, ai_socktype and ai_protocol fields, and AF_UNSPEC - for the ai_family field. - - Note: - - 1. If the caller handles only TCP and not UDP, for example, then the - ai_protocol member of the hints structure should be set to - IPPROTO_TCP when getaddrinfo() is called. - - 2. If the caller handles only IPv4 and not IPv6, then the ai_family - member of the hints structure should be set to AF_INET when - getaddrinfo() is called. - - - - - - - -Gilligan, et al. Informational [Page 24] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - - The ai_flags field to which hints parameter points shall be set to - zero or be the bitwise-inclusive OR of one or more of the values - AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV, - AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG. - - If the AI_PASSIVE flag is specified, the returned address information - shall be suitable for use in binding a socket for accepting incoming - connections for the specified service (i.e., a call to bind()). In - this case, if the nodename argument is null, then the IP address - portion of the socket address structure shall be set to INADDR_ANY - for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address. If the - AI_PASSIVE flag is not specified, the returned address information - shall be suitable for a call to connect() (for a connection-mode - protocol) or for a call to connect(), sendto() or sendmsg() (for a - connectionless protocol). In this case, if the nodename argument is - null, then the IP address portion of the socket address structure - shall be set to the loopback address. This flag is ignored if the - nodename argument is not null. - - If the AI_CANONNAME flag is specified and the nodename argument is - not null, the function shall attempt to determine the canonical name - corresponding to nodename (for example, if nodename is an alias or - shorthand notation for a complete name). - - If the AI_NUMERICHOST flag is specified, then a non-null nodename - string supplied shall be a numeric host address string. Otherwise, - an [EAI_NONAME] error is returned. This flag shall prevent any type - of name resolution service (for example, the DNS) from being invoked. - - If the AI_NUMERICSERV flag is specified, then a non-null servname - string supplied shall be a numeric port string. Otherwise, an - [EAI_NONAME] error shall be returned. This flag shall prevent any - type of name resolution service (for example, NIS+) from being - invoked. - - If the AI_V4MAPPED flag is specified along with an ai_family of - AF_INET6, then getaddrinfo() shall return IPv4-mapped IPv6 addresses - on finding no matching IPv6 addresses (ai_addrlen shall be 16). - - For example, when using the DNS, if no AAAA records are found then - a query is made for A records and any found are returned as IPv4- - mapped IPv6 addresses. - - The AI_V4MAPPED flag shall be ignored unless ai_family equals - AF_INET6. - - If the AI_ALL flag is used with the AI_V4MAPPED flag, then - getaddrinfo() shall return all matching IPv6 and IPv4 addresses. - - - -Gilligan, et al. Informational [Page 25] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - - For example, when using the DNS, queries are made for both AAAA - records and A records, and getaddrinfo() returns the combined - results of both queries. Any IPv4 addresses found are returned as - IPv4-mapped IPv6 addresses. - - The AI_ALL flag without the AI_V4MAPPED flag is ignored. - - Note: - - When ai_family is not specified (AF_UNSPEC), AI_V4MAPPED and - AI_ALL flags will only be used if AF_INET6 is supported. - - If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be - returned only if an IPv4 address is configured on the local system, - and IPv6 addresses shall be returned only if an IPv6 address is - configured on the local system. The loopback address is not - considered for this case as valid as a configured address. - - For example, when using the DNS, a query for AAAA records should - occur only if the node has at least one IPv6 address configured - (other than IPv6 loopback) and a query for A records should occur - only if the node has at least one IPv4 address configured (other - than the IPv4 loopback). - - The ai_socktype field to which argument hints points specifies the - socket type for the service, as defined for socket(). If a specific - socket type is not given (for example, a value of zero) and the - service name could be interpreted as valid with multiple supported - socket types, the implementation shall attempt to resolve the service - name for all supported socket types and, in the absence of errors, - all possible results shall be returned. A non-zero socket type value - shall limit the returned information to values with the specified - socket type. - - If the ai_family field to which hints points has the value AF_UNSPEC, - addresses shall be returned for use with any address family that can - be used with the specified nodename and/or servname. Otherwise, - addresses shall be returned for use only with the specified address - family. If ai_family is not AF_UNSPEC and ai_protocol is not zero, - then addresses are returned for use only with the specified address - family and protocol; the value of ai_protocol shall be interpreted as - in a call to the socket() function with the corresponding values of - ai_family and ai_protocol. - - The freeaddrinfo() function frees one or more addrinfo structures - returned by getaddrinfo(), along with any additional storage - associated with those structures (for example, storage pointed to by - the ai_canonname and ai_addr fields; an application must not - - - -Gilligan, et al. Informational [Page 26] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - - reference this storage after the associated addrinfo structure has - been freed). If the ai_next field of the structure is not null, the - entire list of structures is freed. The freeaddrinfo() function must - support the freeing of arbitrary sublists of an addrinfo list - originally returned by getaddrinfo(). - - Functions getaddrinfo() and freeaddrinfo() must be thread-safe. - - A zero return value for getaddrinfo() indicates successful - completion; a non-zero return value indicates failure. The possible - values for the failures are listed below under Error Return Values. - - Upon successful return of getaddrinfo(), the location to which res - points shall refer to a linked list of addrinfo structures, each of - which shall specify a socket address and information for use in - creating a socket with which to use that socket address. The list - shall include at least one addrinfo structure. The ai_next field of - each structure contains a pointer to the next structure on the list, - or a null pointer if it is the last structure on the list. Each - structure on the list shall include values for use with a call to the - socket() function, and a socket address for use with the connect() - function or, if the AI_PASSIVE flag was specified, for use with the - bind() function. The fields ai_family, ai_socktype, and ai_protocol - shall be usable as the arguments to the socket() function to create a - socket suitable for use with the returned address. The fields - ai_addr and ai_addrlen are usable as the arguments to the connect() - or bind() functions with such a socket, according to the AI_PASSIVE - flag. - - If nodename is not null, and if requested by the AI_CANONNAME flag, - the ai_canonname field of the first returned addrinfo structure shall - point to a null-terminated string containing the canonical name - corresponding to the input nodename; if the canonical name is not - available, then ai_canonname shall refer to the nodename argument or - a string with the same contents. The contents of the ai_flags field - of the returned structures are undefined. - - All fields in socket address structures returned by getaddrinfo() - that are not filled in through an explicit argument (for example, - sin6_flowinfo) shall be set to zero. - - Note: This makes it easier to compare socket address structures. - - - - - - - - - -Gilligan, et al. Informational [Page 27] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - - Error Return Values: - - The getaddrinfo() function shall fail and return the corresponding - value if: - - [EAI_AGAIN] The name could not be resolved at this time. Future - attempts may succeed. - - [EAI_BADFLAGS] The flags parameter had an invalid value. - - [EAI_FAIL] A non-recoverable error occurred when attempting to - resolve the name. - - [EAI_FAMILY] The address family was not recognized. - - [EAI_MEMORY] There was a memory allocation failure when trying to - allocate storage for the return value. - - [EAI_NONAME] The name does not resolve for the supplied - parameters. Neither nodename nor servname were - supplied. At least one of these must be supplied. - - [EAI_SERVICE] The service passed was not recognized for the - specified socket type. - - [EAI_SOCKTYPE] The intended socket type was not recognized. - - [EAI_SYSTEM] A system error occurred; the error code can be found - in errno. - - The gai_strerror() function provides a descriptive text string - corresponding to an EAI_xxx error value. - - #include <netdb.h> - - const char *gai_strerror(int ecode); - - The argument is one of the EAI_xxx values defined for the - getaddrinfo() and getnameinfo() functions. The return value points - to a string describing the error. If the argument is not one of the - EAI_xxx values, the function still returns a pointer to a string - whose contents indicate an unknown error. - -6.2 Socket Address Structure to Node Name and Service Name - - The getnameinfo() function is used to translate the contents of a - socket address structure to a node name and/or service name. - - - - -Gilligan, et al. Informational [Page 28] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - - #include <sys/socket.h> - #include <netdb.h> - - int getnameinfo(const struct sockaddr *sa, socklen_t salen, - char *node, socklen_t nodelen, - char *service, socklen_t servicelen, - int flags); - - The getnameinfo() function shall translate a socket address to a node - name and service location, all of which are defined as in - getaddrinfo(). - - The sa argument points to a socket address structure to be - translated. - - The salen argument holds the size of the socket address structure - pointed to by sa. - - If the socket address structure contains an IPv4-mapped IPv6 address - or an IPv4-compatible IPv6 address, the implementation shall extract - the embedded IPv4 address and lookup the node name for that IPv4 - address. - - Note: The IPv6 unspecified address ("::") and the IPv6 loopback - address ("::1") are not IPv4-compatible addresses. If the address - is the IPv6 unspecified address ("::"), a lookup is not performed, - and the [EAI_NONAME] error is returned. - - If the node argument is non-NULL and the nodelen argument is nonzero, - then the node argument points to a buffer able to contain up to - nodelen characters that receives the node name as a null-terminated - string. If the node argument is NULL or the nodelen argument is - zero, the node name shall not be returned. If the node's name cannot - be located, the numeric form of the node's address is returned - instead of its name. - - If the service argument is non-NULL and the servicelen argument is - non-zero, then the service argument points to a buffer able to - contain up to servicelen bytes that receives the service name as a - null-terminated string. If the service argument is NULL or the - servicelen argument is zero, the service name shall not be returned. - If the service's name cannot be located, the numeric form of the - service address (for example, its port number) shall be returned - instead of its name. - - The arguments node and service cannot both be NULL. - - - - - -Gilligan, et al. Informational [Page 29] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - - The flags argument is a flag that changes the default actions of the - function. By default the fully-qualified domain name (FQDN) for the - host shall be returned, but: - - - If the flag bit NI_NOFQDN is set, only the node name portion of - the FQDN shall be returned for local hosts. - - - If the flag bit NI_NUMERICHOST is set, the numeric form of the - host's address shall be returned instead of its name, under all - circumstances. - - - If the flag bit NI_NAMEREQD is set, an error shall be returned if - the host's name cannot be located. - - - If the flag bit NI_NUMERICSERV is set, the numeric form of the - service address shall be returned (for example, its port number) - instead of its name, under all circumstances. - - - If the flag bit NI_DGRAM is set, this indicates that the service - is a datagram service (SOCK_DGRAM). The default behavior shall - assume that the service is a stream service (SOCK_STREAM). - - Note: - - 1. The NI_NUMERICxxx flags are required to support the "-n" flags - that many commands provide. - - 2. The NI_DGRAM flag is required for the few AF_INET and AF_INET6 - port numbers (for example, [512,514]) that represent different - services for UDP and TCP. - - The getnameinfo() function shall be thread safe. - - A zero return value for getnameinfo() indicates successful - completion; a non-zero return value indicates failure. - - Upon successful completion, getnameinfo() shall return the node and - service names, if requested, in the buffers provided. The returned - names are always null-terminated strings. - - - - - - - - - - - - -Gilligan, et al. Informational [Page 30] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - - Error Return Values: - - The getnameinfo() function shall fail and return the corresponding - value if: - - [EAI_AGAIN] The name could not be resolved at this time. - Future attempts may succeed. - - [EAI_BADFLAGS] The flags had an invalid value. - - [EAI_FAIL] A non-recoverable error occurred. - - [EAI_FAMILY] The address family was not recognized or the address - length was invalid for the specified family. - - [EAI_MEMORY] There was a memory allocation failure. - - [EAI_NONAME] The name does not resolve for the supplied parameters. - NI_NAMEREQD is set and the host's name cannot be - located, or both nodename and servname were null. - - [EAI_OVERFLOW] An argument buffer overflowed. - - [EAI_SYSTEM] A system error occurred. The error code can be found - in errno. - -6.3 Address Conversion Functions - - The two IPv4 functions inet_addr() and inet_ntoa() convert an IPv4 - address between binary and text form. IPv6 applications need similar - functions. The following two functions convert both IPv6 and IPv4 - addresses: - - #include <arpa/inet.h> - - int inet_pton(int af, const char *src, void *dst); - - const char *inet_ntop(int af, const void *src, - char *dst, socklen_t size); - - The inet_pton() function shall convert an address in its standard - text presentation form into its numeric binary form. The af argument - shall specify the family of the address. The AF_INET and AF_INET6 - address families shall be supported. The src argument points to the - string being passed in. The dst argument points to a buffer into - which the function stores the numeric address; this shall be large - enough to hold the numeric address (32 bits for AF_INET, 128 bits for - AF_INET6). The inet_pton() function shall return 1 if the conversion - - - -Gilligan, et al. Informational [Page 31] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - - succeeds, with the address pointed to by dst in network byte order. - It shall return 0 if the input is not a valid IPv4 dotted-decimal - string or a valid IPv6 address string, or -1 with errno set to - EAFNOSUPPORT if the af argument is unknown. - - If the af argument of inet_pton() is AF_INET, the src string shall be - in the standard IPv4 dotted-decimal form: - - ddd.ddd.ddd.ddd - - where "ddd" is a one to three digit decimal number between 0 and 255. - The inet_pton() function does not accept other formats (such as the - octal numbers, hexadecimal numbers, and fewer than four numbers that - inet_addr() accepts). - - If the af argument of inet_pton() is AF_INET6, the src string shall - be in one of the standard IPv6 text forms defined in Section 2.2 of - the addressing architecture specification [2]. - - The inet_ntop() function shall convert a numeric address into a text - string suitable for presentation. The af argument shall specify the - family of the address. This can be AF_INET or AF_INET6. The src - argument points to a buffer holding an IPv4 address if the af - argument is AF_INET, or an IPv6 address if the af argument is - AF_INET6; the address must be in network byte order. The dst - argument points to a buffer where the function stores the resulting - text string; it shall not be NULL. The size argument specifies the - size of this buffer, which shall be large enough to hold the text - string (INET_ADDRSTRLEN characters for IPv4, INET6_ADDRSTRLEN - characters for IPv6). - - In order to allow applications to easily declare buffers of the - proper size to store IPv4 and IPv6 addresses in string form, the - following two constants are defined in <netinet/in.h>: - - #define INET_ADDRSTRLEN 16 - #define INET6_ADDRSTRLEN 46 - - The inet_ntop() function shall return a pointer to the buffer - containing the text string if the conversion succeeds, and NULL - otherwise. Upon failure, errno is set to EAFNOSUPPORT if the af - argument is invalid or ENOSPC if the size of the result buffer is - inadequate. - - - - - - - - -Gilligan, et al. Informational [Page 32] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - -6.4 Address Testing Macros - - The following macros can be used to test for special IPv6 addresses. - - #include <netinet/in.h> - - int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *); - int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *); - int IN6_IS_ADDR_MULTICAST (const struct in6_addr *); - int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *); - int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *); - int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *); - int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *); - - int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); - int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); - int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); - int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *); - int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *); - - The first seven macros return true if the address is of the specified - type, or false otherwise. The last five test the scope of a - multicast address and return true if the address is a multicast - address of the specified scope or false if the address is either not - a multicast address or not of the specified scope. - - Note that IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true - only for the two types of local-use IPv6 unicast addresses (Link- - Local and Site-Local) defined in [2], and that by this definition, - the IN6_IS_ADDR_LINKLOCAL macro returns false for the IPv6 loopback - address (::1). These two macros do not return true for IPv6 - multicast addresses of either link-local scope or site-local scope. - -7. Summary of New Definitions - - The following list summarizes the constants, structure, and extern - definitions discussed in this memo, sorted by header. - -<net/if.h> IF_NAMESIZE -<net/if.h> struct if_nameindex{}; - -<netdb.h> AI_ADDRCONFIG -<netdb.h> AI_ALL -<netdb.h> AI_CANONNAME -<netdb.h> AI_NUMERICHOST -<netdb.h> AI_NUMERICSERV -<netdb.h> AI_PASSIVE -<netdb.h> AI_V4MAPPED - - - -Gilligan, et al. Informational [Page 33] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - -<netdb.h> EAI_AGAIN -<netdb.h> EAI_BADFLAGS -<netdb.h> EAI_FAIL -<netdb.h> EAI_FAMILY -<netdb.h> EAI_MEMORY -<netdb.h> EAI_NONAME -<netdb.h> EAI_OVERFLOW -<netdb.h> EAI_SERVICE -<netdb.h> EAI_SOCKTYPE -<netdb.h> EAI_SYSTEM -<netdb.h> NI_DGRAM -<netdb.h> NI_NAMEREQD -<netdb.h> NI_NOFQDN -<netdb.h> NI_NUMERICHOST -<netdb.h> NI_NUMERICSERV -<netdb.h> struct addrinfo{}; - -<netinet/in.h> IN6ADDR_ANY_INIT -<netinet/in.h> IN6ADDR_LOOPBACK_INIT -<netinet/in.h> INET6_ADDRSTRLEN -<netinet/in.h> INET_ADDRSTRLEN -<netinet/in.h> IPPROTO_IPV6 -<netinet/in.h> IPV6_JOIN_GROUP -<netinet/in.h> IPV6_LEAVE_GROUP -<netinet/in.h> IPV6_MULTICAST_HOPS -<netinet/in.h> IPV6_MULTICAST_IF -<netinet/in.h> IPV6_MULTICAST_LOOP -<netinet/in.h> IPV6_UNICAST_HOPS -<netinet/in.h> IPV6_V6ONLY -<netinet/in.h> SIN6_LEN -<netinet/in.h> extern const struct in6_addr in6addr_any; -<netinet/in.h> extern const struct in6_addr in6addr_loopback; -<netinet/in.h> struct in6_addr{}; -<netinet/in.h> struct ipv6_mreq{}; -<netinet/in.h> struct sockaddr_in6{}; - -<sys/socket.h> AF_INET6 -<sys/socket.h> PF_INET6 -<sys/socket.h> struct sockaddr_storage; - - The following list summarizes the function and macro prototypes - discussed in this memo, sorted by header. - -<arpa/inet.h> int inet_pton(int, const char *, void *); -<arpa/inet.h> const char *inet_ntop(int, const void *, - char *, socklen_t); - - - - - -Gilligan, et al. Informational [Page 34] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - -<net/if.h> char *if_indextoname(unsigned int, char *); -<net/if.h> unsigned int if_nametoindex(const char *); -<net/if.h> void if_freenameindex(struct if_nameindex *); -<net/if.h> struct if_nameindex *if_nameindex(void); - -<netdb.h> int getaddrinfo(const char *, const char *, - const struct addrinfo *, - struct addrinfo **); -<netdb.h> int getnameinfo(const struct sockaddr *, socklen_t, - char *, socklen_t, char *, socklen_t, int); -<netdb.h> void freeaddrinfo(struct addrinfo *); -<netdb.h> const char *gai_strerror(int); - -<netinet/in.h> int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_MULTICAST(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *); -<netinet/in.h> int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *); - -8. Security Considerations - - IPv6 provides a number of new security mechanisms, many of which need - to be accessible to applications. Companion memos detailing the - extensions to the socket interfaces to support IPv6 security are - being written. - -9. Changes from RFC 2553 - - 1. Add brief description of the history of this API and its relation - to the Open Group/IEEE/ISO standards. - - 2. Alignments with [3]. - - 3. Removed all references to getipnodebyname() and getipnodebyaddr(), - which are deprecated in favor of getaddrinfo() and getnameinfo(). - - 4. Added IPV6_V6ONLY IP level socket option to permit nodes to not - process IPv4 packets as IPv4 Mapped addresses in implementations. - - 5. Added SIIT to references and added new contributors. - - - - -Gilligan, et al. Informational [Page 35] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - - 6. In previous versions of this specification, the sin6_flowinfo - field was associated with the IPv6 traffic class and flow label, - but its usage was not completely specified. The complete - definition of the sin6_flowinfo field, including its association - with the traffic class or flow label, is now deferred to a future - specification. - -10. Acknowledgments - - This specification's evolution and completeness were significantly - influenced by the efforts of Richard Stevens, who has passed on. - Richard's wisdom and talent made the specification what it is today. - The co-authors will long think of Richard with great respect. - - Thanks to the many people who made suggestions and provided feedback - to this document, including: - - Werner Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew - Cherenson, Alex Conta, Alan Cox, Steve Deering, Richard Draves, - Francis Dupont, Robert Elz, Brian Haberman, Jun-ichiro itojun Hagino, - Marc Hasson, Tom Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema, - Koji Imada, Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan - McDonald, Dave Mitton, Finnbarr Murphy, Thomas Narten, Josh Osborne, - Craig Partridge, Jean-Luc Richier, Bill Sommerfield, Erik Scoredos, - Keith Sklower, JINMEI Tatuya, Dave Thaler, Matt Thomas, Harvey - Thompson, Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, - David Waitzman, Carl Williams, Kazu Yamamoto, Vlad Yasevich, Stig - Venaas, and Brian Zill. - - The getaddrinfo() and getnameinfo() functions are taken from an - earlier document by Keith Sklower. As noted in that document, - William Durst, Steven Wise, Michael Karels, and Eric Allman provided - many useful discussions on the subject of protocol-independent name- - to-address translation, and reviewed early versions of Keith - Sklower's original proposal. Eric Allman implemented the first - prototype of getaddrinfo(). The observation that specifying the pair - of name and service would suffice for connecting to a service - independent of protocol details was made by Marshall Rose in a - proposal to X/Open for a "Uniform Network Interface". - - Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh - Kacker made many contributions to this document. Ramesh Govindan - made a number of contributions and co-authored an earlier version of - this memo. - - - - - - - -Gilligan, et al. Informational [Page 36] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - -11. References - - [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) - Specification", RFC 2460, December 1998. - - [2] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 2373, July 1998. - - [3] IEEE Std. 1003.1-2001 Standard for Information Technology -- - Portable Operating System Interface (POSIX). Open Group - Technical Standard: Base Specifications, Issue 6, December 2001. - ISO/IEC 9945:2002. http://www.opengroup.org/austin - - [4] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC - 2292, February 1998. - - [5] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", - RFC 2765, February 2000. - - [6] The Open Group Base Working Group - http://www.opengroup.org/platform/base.html - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gilligan, et al. Informational [Page 37] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - -12. Authors' Addresses - - Bob Gilligan - Intransa, Inc. - 2870 Zanker Rd. - San Jose, CA 95134 - - Phone: 408-678-8647 - EMail: gilligan@intransa.com - - - Susan Thomson - Cisco Systems - 499 Thornall Street, 8th floor - Edison, NJ 08837 - - Phone: 732-635-3086 - EMail: sethomso@cisco.com - - - Jim Bound - Hewlett-Packard Company - 110 Spitbrook Road ZKO3-3/W20 - Nashua, NH 03062 - - Phone: 603-884-0062 - EMail: Jim.Bound@hp.com - - - Jack McCann - Hewlett-Packard Company - 110 Spitbrook Road ZKO3-3/W20 - Nashua, NH 03062 - - Phone: 603-884-2608 - EMail: Jack.McCann@hp.com - - - - - - - - - - - - - - - -Gilligan, et al. Informational [Page 38] - -RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 - - -13. Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Gilligan, et al. Informational [Page 39] - diff --git a/contrib/bind9/doc/rfc/rfc3513.txt b/contrib/bind9/doc/rfc/rfc3513.txt deleted file mode 100644 index 49c0fa412477..000000000000 --- a/contrib/bind9/doc/rfc/rfc3513.txt +++ /dev/null @@ -1,1459 +0,0 @@ - - - - - - -Network Working Group R. Hinden -Request for Comments: 3513 Nokia -Obsoletes: 2373 S. Deering -Category: Standards Track Cisco Systems - April 2003 - - - Internet Protocol Version 6 (IPv6) Addressing Architecture - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - This specification defines the addressing architecture of the IP - Version 6 (IPv6) protocol. The document includes the IPv6 addressing - model, text representations of IPv6 addresses, definition of IPv6 - unicast addresses, anycast addresses, and multicast addresses, and an - IPv6 node's required addresses. - - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 1] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - -Table of Contents - - 1. Introduction.................................................3 - 2. IPv6 Addressing..............................................3 - 2.1 Addressing Model.........................................4 - 2.2 Text Representation of Addresses.........................4 - 2.3 Text Representation of Address Prefixes..................5 - 2.4 Address Type Identification..............................6 - 2.5 Unicast Addresses........................................7 - 2.5.1 Interface Identifiers..............................8 - 2.5.2 The Unspecified Address............................9 - 2.5.3 The Loopback Address...............................9 - 2.5.4 Global Unicast Addresses..........................10 - 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses.......10 - 2.5.6 Local-use IPv6 Unicast Addresses..................11 - 2.6 Anycast Addresses.......................................12 - 2.6.1 Required Anycast Address..........................13 - 2.7 Multicast Addresses.....................................13 - 2.7.1 Pre-Defined Multicast Addresses...................15 - 2.8 A Node's Required Addresses.............................17 - 3. Security Considerations.....................................17 - 4. IANA Considerations.........................................18 - 5. References..................................................19 - 5.1 Normative References....................................19 - 5.2 Informative References..................................19 - APPENDIX A: Creating Modified EUI-64 format Interface IDs......21 - APPENDIX B: Changes from RFC-2373..............................24 - Authors' Addresses.............................................25 - Full Copyright Statement.......................................26 - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 2] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - -1. Introduction - - This specification defines the addressing architecture of the IP - Version 6 (IPv6) protocol. It includes the basic formats for the - various types of IPv6 addresses (unicast, anycast, and multicast). - - The authors would like to acknowledge the contributions of Paul - Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, - Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, - Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg - Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, - Sue Thomson, Markku Savela, and Larry Masinter. - -2. IPv6 Addressing - - IPv6 addresses are 128-bit identifiers for interfaces and sets of - interfaces (where "interface" is as defined in section 2 of [IPV6]). - There are three types of addresses: - - Unicast: An identifier for a single interface. A packet sent to a - unicast address is delivered to the interface identified - by that address. - - Anycast: An identifier for a set of interfaces (typically belonging - to different nodes). A packet sent to an anycast address - is delivered to one of the interfaces identified by that - address (the "nearest" one, according to the routing - protocols' measure of distance). - - Multicast: An identifier for a set of interfaces (typically belonging - to different nodes). A packet sent to a multicast address - is delivered to all interfaces identified by that address. - - There are no broadcast addresses in IPv6, their function being - superseded by multicast addresses. - - In this document, fields in addresses are given a specific name, for - example "subnet". When this name is used with the term "ID" for - identifier after the name (e.g., "subnet ID"), it refers to the - contents of the named field. When it is used with the term "prefix" - (e.g., "subnet prefix") it refers to all of the address from the left - up to and including this field. - - In IPv6, all zeros and all ones are legal values for any field, - unless specifically excluded. Specifically, prefixes may contain, or - end with, zero-valued fields. - - - - - -Hinden & Deering Standards Track [Page 3] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - -2.1 Addressing Model - - IPv6 addresses of all types are assigned to interfaces, not nodes. - An IPv6 unicast address refers to a single interface. Since each - interface belongs to a single node, any of that node's interfaces' - unicast addresses may be used as an identifier for the node. - - All interfaces are required to have at least one link-local unicast - address (see section 2.8 for additional required addresses). A - single interface may also have multiple IPv6 addresses of any type - (unicast, anycast, and multicast) or scope. Unicast addresses with - scope greater than link-scope are not needed for interfaces that are - not used as the origin or destination of any IPv6 packets to or from - non-neighbors. This is sometimes convenient for point-to-point - interfaces. There is one exception to this addressing model: - - A unicast address or a set of unicast addresses may be assigned to - multiple physical interfaces if the implementation treats the - multiple physical interfaces as one interface when presenting it - to the internet layer. This is useful for load-sharing over - multiple physical interfaces. - - Currently IPv6 continues the IPv4 model that a subnet prefix is - associated with one link. Multiple subnet prefixes may be assigned - to the same link. - -2.2 Text Representation of Addresses - - There are three conventional forms for representing IPv6 addresses as - text strings: - - 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the - hexadecimal values of the eight 16-bit pieces of the address. - - Examples: - - FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 - - 1080:0:0:0:8:800:200C:417A - - Note that it is not necessary to write the leading zeros in an - individual field, but there must be at least one numeral in every - field (except for the case described in 2.). - - 2. Due to some methods of allocating certain styles of IPv6 - addresses, it will be common for addresses to contain long strings - of zero bits. In order to make writing addresses containing zero - bits easier a special syntax is available to compress the zeros. - - - -Hinden & Deering Standards Track [Page 4] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - The use of "::" indicates one or more groups of 16 bits of zeros. - The "::" can only appear once in an address. The "::" can also be - used to compress leading or trailing zeros in an address. - - For example, the following addresses: - - 1080:0:0:0:8:800:200C:417A a unicast address - FF01:0:0:0:0:0:0:101 a multicast address - 0:0:0:0:0:0:0:1 the loopback address - 0:0:0:0:0:0:0:0 the unspecified addresses - - may be represented as: - - 1080::8:800:200C:417A a unicast address - FF01::101 a multicast address - ::1 the loopback address - :: the unspecified addresses - - 3. An alternative form that is sometimes more convenient when dealing - with a mixed environment of IPv4 and IPv6 nodes is - x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of - the six high-order 16-bit pieces of the address, and the 'd's are - the decimal values of the four low-order 8-bit pieces of the - address (standard IPv4 representation). Examples: - - 0:0:0:0:0:0:13.1.68.3 - - 0:0:0:0:0:FFFF:129.144.52.38 - - or in compressed form: - - ::13.1.68.3 - - ::FFFF:129.144.52.38 - -2.3 Text Representation of Address Prefixes - - The text representation of IPv6 address prefixes is similar to the - way IPv4 addresses prefixes are written in CIDR notation [CIDR]. An - IPv6 address prefix is represented by the notation: - - ipv6-address/prefix-length - - where - - ipv6-address is an IPv6 address in any of the notations listed - in section 2.2. - - - - -Hinden & Deering Standards Track [Page 5] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - prefix-length is a decimal value specifying how many of the - leftmost contiguous bits of the address comprise - the prefix. - - For example, the following are legal representations of the 60-bit - prefix 12AB00000000CD3 (hexadecimal): - - 12AB:0000:0000:CD30:0000:0000:0000:0000/60 - 12AB::CD30:0:0:0:0/60 - 12AB:0:0:CD30::/60 - - The following are NOT legal representations of the above prefix: - - 12AB:0:0:CD3/60 may drop leading zeros, but not trailing zeros, - within any 16-bit chunk of the address - - 12AB::CD30/60 address to left of "/" expands to - 12AB:0000:0000:0000:0000:000:0000:CD30 - - 12AB::CD3/60 address to left of "/" expands to - 12AB:0000:0000:0000:0000:000:0000:0CD3 - - When writing both a node address and a prefix of that node address - (e.g., the node's subnet prefix), the two can combined as follows: - - the node address 12AB:0:0:CD30:123:4567:89AB:CDEF - and its subnet number 12AB:0:0:CD30::/60 - - can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60 - -2.4 Address Type Identification - - The type of an IPv6 address is identified by the high-order bits of - the address, as follows: - - Address type Binary prefix IPv6 notation Section - ------------ ------------- ------------- ------- - Unspecified 00...0 (128 bits) ::/128 2.5.2 - Loopback 00...1 (128 bits) ::1/128 2.5.3 - Multicast 11111111 FF00::/8 2.7 - Link-local unicast 1111111010 FE80::/10 2.5.6 - Site-local unicast 1111111011 FEC0::/10 2.5.6 - Global unicast (everything else) - - Anycast addresses are taken from the unicast address spaces (of any - scope) and are not syntactically distinguishable from unicast - addresses. - - - - -Hinden & Deering Standards Track [Page 6] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - The general format of global unicast addresses is described in - section 2.5.4. Some special-purpose subtypes of global unicast - addresses which contain embedded IPv4 addresses (for the purposes of - IPv4-IPv6 interoperation) are described in section 2.5.5. - - Future specifications may redefine one or more sub-ranges of the - global unicast space for other purposes, but unless and until that - happens, implementations must treat all addresses that do not start - with any of the above-listed prefixes as global unicast addresses. - -2.5 Unicast Addresses - - IPv6 unicast addresses are aggregable with prefixes of arbitrary - bit-length similar to IPv4 addresses under Classless Interdomain - Routing. - - There are several types of unicast addresses in IPv6, in particular - global unicast, site-local unicast, and link-local unicast. There - are also some special-purpose subtypes of global unicast, such as - IPv6 addresses with embedded IPv4 addresses or encoded NSAP - addresses. Additional address types or subtypes can be defined in - the future. - - IPv6 nodes may have considerable or little knowledge of the internal - structure of the IPv6 address, depending on the role the node plays - (for instance, host versus router). At a minimum, a node may - consider that unicast addresses (including its own) have no internal - structure: - - | 128 bits | - +-----------------------------------------------------------------+ - | node address | - +-----------------------------------------------------------------+ - - A slightly sophisticated host (but still rather simple) may - additionally be aware of subnet prefix(es) for the link(s) it is - attached to, where different addresses may have different values for - n: - - | n bits | 128-n bits | - +------------------------------------------------+----------------+ - | subnet prefix | interface ID | - +------------------------------------------------+----------------+ - - Though a very simple router may have no knowledge of the internal - structure of IPv6 unicast addresses, routers will more generally have - knowledge of one or more of the hierarchical boundaries for the - operation of routing protocols. The known boundaries will differ - - - -Hinden & Deering Standards Track [Page 7] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - from router to router, depending on what positions the router holds - in the routing hierarchy. - -2.5.1 Interface Identifiers - - Interface identifiers in IPv6 unicast addresses are used to identify - interfaces on a link. They are required to be unique within a subnet - prefix. It is recommended that the same interface identifier not be - assigned to different nodes on a link. They may also be unique over - a broader scope. In some cases an interface's identifier will be - derived directly from that interface's link-layer address. The same - interface identifier may be used on multiple interfaces on a single - node, as long as they are attached to different subnets. - - Note that the uniqueness of interface identifiers is independent of - the uniqueness of IPv6 addresses. For example, a global unicast - address may be created with a non-global scope interface identifier - and a site-local address may be created with a global scope interface - identifier. - - For all unicast addresses, except those that start with binary value - 000, Interface IDs are required to be 64 bits long and to be - constructed in Modified EUI-64 format. - - Modified EUI-64 format based Interface identifiers may have global - scope when derived from a global token (e.g., IEEE 802 48-bit MAC or - IEEE EUI-64 identifiers [EUI64]) or may have local scope where a - global token is not available (e.g., serial links, tunnel end-points, - etc.) or where global tokens are undesirable (e.g., temporary tokens - for privacy [PRIV]). - - Modified EUI-64 format interface identifiers are formed by inverting - the "u" bit (universal/local bit in IEEE EUI-64 terminology) when - forming the interface identifier from IEEE EUI-64 identifiers. In - the resulting Modified EUI-64 format the "u" bit is set to one (1) to - indicate global scope, and it is set to zero (0) to indicate local - scope. The first three octets in binary of an IEEE EUI-64 identifier - are as follows: - - 0 0 0 1 1 2 - |0 7 8 5 6 3| - +----+----+----+----+----+----+ - |cccc|ccug|cccc|cccc|cccc|cccc| - +----+----+----+----+----+----+ - - written in Internet standard bit-order , where "u" is the - universal/local bit, "g" is the individual/group bit, and "c" are the - bits of the company_id. Appendix A: "Creating Modified EUI-64 format - - - -Hinden & Deering Standards Track [Page 8] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - Interface Identifiers" provides examples on the creation of Modified - EUI-64 format based interface identifiers. - - The motivation for inverting the "u" bit when forming an interface - identifier is to make it easy for system administrators to hand - configure non-global identifiers when hardware tokens are not - available. This is expected to be case for serial links, tunnel end- - points, etc. The alternative would have been for these to be of the - form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler 1, 2, - etc. - - The use of the universal/local bit in the Modified EUI-64 format - identifier is to allow development of future technology that can take - advantage of interface identifiers with global scope. - - The details of forming interface identifiers are defined in the - appropriate "IPv6 over <link>" specification such as "IPv6 over - Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc. - -2.5.2 The Unspecified Address - - The address 0:0:0:0:0:0:0:0 is called the unspecified address. It - must never be assigned to any node. It indicates the absence of an - address. One example of its use is in the Source Address field of - any IPv6 packets sent by an initializing host before it has learned - its own address. - - The unspecified address must not be used as the destination address - of IPv6 packets or in IPv6 Routing Headers. An IPv6 packet with a - source address of unspecified must never be forwarded by an IPv6 - router. - -2.5.3 The Loopback Address - - The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. - It may be used by a node to send an IPv6 packet to itself. It may - never be assigned to any physical interface. It is treated as - having link-local scope, and may be thought of as the link-local - unicast address of a virtual interface (typically called "the - loopback interface") to an imaginary link that goes nowhere. - - The loopback address must not be used as the source address in IPv6 - packets that are sent outside of a single node. An IPv6 packet with - a destination address of loopback must never be sent outside of a - single node and must never be forwarded by an IPv6 router. A packet - received on an interface with destination address of loopback must be - dropped. - - - - -Hinden & Deering Standards Track [Page 9] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - -2.5.4 Global Unicast Addresses - - The general format for IPv6 global unicast addresses is as follows: - - | n bits | m bits | 128-n-m bits | - +------------------------+-----------+----------------------------+ - | global routing prefix | subnet ID | interface ID | - +------------------------+-----------+----------------------------+ - - where the global routing prefix is a (typically hierarchically- - structured) value assigned to a site (a cluster of subnets/links), - the subnet ID is an identifier of a link within the site, and the - interface ID is as defined in section 2.5.1. - - All global unicast addresses other than those that start with binary - 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as - described in section 2.5.1. Global unicast addresses that start with - binary 000 have no such constraint on the size or structure of the - interface ID field. - - Examples of global unicast addresses that start with binary 000 are - the IPv6 address with embedded IPv4 addresses described in section - 2.5.5 and the IPv6 address containing encoded NSAP addresses - specified in [NSAP]. An example of global addresses starting with a - binary value other than 000 (and therefore having a 64-bit interface - ID field) can be found in [AGGR]. - -2.5.5 IPv6 Addresses with Embedded IPv4 Addresses - - The IPv6 transition mechanisms [TRAN] include a technique for hosts - and routers to dynamically tunnel IPv6 packets over IPv4 routing - infrastructure. IPv6 nodes that use this technique are assigned - special IPv6 unicast addresses that carry a global IPv4 address in - the low-order 32 bits. This type of address is termed an "IPv4- - compatible IPv6 address" and has the format: - - | 80 bits | 16 | 32 bits | - +--------------------------------------+--------------------------+ - |0000..............................0000|0000| IPv4 address | - +--------------------------------------+----+---------------------+ - - Note: The IPv4 address used in the "IPv4-compatible IPv6 address" - must be a globally-unique IPv4 unicast address. - - A second type of IPv6 address which holds an embedded IPv4 address is - also defined. This address type is used to represent the addresses - of IPv4 nodes as IPv6 addresses. This type of address is termed an - "IPv4-mapped IPv6 address" and has the format: - - - -Hinden & Deering Standards Track [Page 10] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - | 80 bits | 16 | 32 bits | - +--------------------------------------+--------------------------+ - |0000..............................0000|FFFF| IPv4 address | - +--------------------------------------+----+---------------------+ - -2.5.6 Local-Use IPv6 Unicast Addresses - - There are two types of local-use unicast addresses defined. These - are Link-Local and Site-Local. The Link-Local is for use on a single - link and the Site-Local is for use in a single site. Link-Local - addresses have the following format: - - | 10 | - | bits | 54 bits | 64 bits | - +----------+-------------------------+----------------------------+ - |1111111010| 0 | interface ID | - +----------+-------------------------+----------------------------+ - - Link-Local addresses are designed to be used for addressing on a - single link for purposes such as automatic address configuration, - neighbor discovery, or when no routers are present. - - Routers must not forward any packets with link-local source or - destination addresses to other links. - - Site-Local addresses have the following format: - - | 10 | - | bits | 54 bits | 64 bits | - +----------+-------------------------+----------------------------+ - |1111111011| subnet ID | interface ID | - +----------+-------------------------+----------------------------+ - - Site-local addresses are designed to be used for addressing inside of - a site without the need for a global prefix. Although a subnet ID - may be up to 54-bits long, it is expected that globally-connected - sites will use the same subnet IDs for site-local and global - prefixes. - - Routers must not forward any packets with site-local source or - destination addresses outside of the site. - - - - - - - - - - -Hinden & Deering Standards Track [Page 11] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - -2.6 Anycast Addresses - - An IPv6 anycast address is an address that is assigned to more than - one interface (typically belonging to different nodes), with the - property that a packet sent to an anycast address is routed to the - "nearest" interface having that address, according to the routing - protocols' measure of distance. - - Anycast addresses are allocated from the unicast address space, using - any of the defined unicast address formats. Thus, anycast addresses - are syntactically indistinguishable from unicast addresses. When a - unicast address is assigned to more than one interface, thus turning - it into an anycast address, the nodes to which the address is - assigned must be explicitly configured to know that it is an anycast - address. - - For any assigned anycast address, there is a longest prefix P of that - address that identifies the topological region in which all - interfaces belonging to that anycast address reside. Within the - region identified by P, the anycast address must be maintained as a - separate entry in the routing system (commonly referred to as a "host - route"); outside the region identified by P, the anycast address may - be aggregated into the routing entry for prefix P. - - Note that in the worst case, the prefix P of an anycast set may be - the null prefix, i.e., the members of the set may have no topological - locality. In that case, the anycast address must be maintained as a - separate routing entry throughout the entire internet, which presents - a severe scaling limit on how many such "global" anycast sets may be - supported. Therefore, it is expected that support for global anycast - sets may be unavailable or very restricted. - - One expected use of anycast addresses is to identify the set of - routers belonging to an organization providing internet service. - Such addresses could be used as intermediate addresses in an IPv6 - Routing header, to cause a packet to be delivered via a particular - service provider or sequence of service providers. - - Some other possible uses are to identify the set of routers attached - to a particular subnet, or the set of routers providing entry into a - particular routing domain. - - There is little experience with widespread, arbitrary use of internet - anycast addresses, and some known complications and hazards when - using them in their full generality [ANYCST]. Until more experience - has been gained and solutions are specified, the following - restrictions are imposed on IPv6 anycast addresses: - - - - -Hinden & Deering Standards Track [Page 12] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - o An anycast address must not be used as the source address of an - IPv6 packet. - - o An anycast address must not be assigned to an IPv6 host, that is, - it may be assigned to an IPv6 router only. - -2.6.1 Required Anycast Address - - The Subnet-Router anycast address is predefined. Its format is as - follows: - - | n bits | 128-n bits | - +------------------------------------------------+----------------+ - | subnet prefix | 00000000000000 | - +------------------------------------------------+----------------+ - - The "subnet prefix" in an anycast address is the prefix which - identifies a specific link. This anycast address is syntactically - the same as a unicast address for an interface on the link with the - interface identifier set to zero. - - Packets sent to the Subnet-Router anycast address will be delivered - to one router on the subnet. All routers are required to support the - Subnet-Router anycast addresses for the subnets to which they have - interfaces. - - The subnet-router anycast address is intended to be used for - applications where a node needs to communicate with any one of the - set of routers. - -2.7 Multicast Addresses - - An IPv6 multicast address is an identifier for a group of interfaces - (typically on different nodes). An interface may belong to any - number of multicast groups. Multicast addresses have the following - format: - - | 8 | 4 | 4 | 112 bits | - +------ -+----+----+---------------------------------------------+ - |11111111|flgs|scop| group ID | - +--------+----+----+---------------------------------------------+ - - binary 11111111 at the start of the address identifies the - address as being a multicast address. - - +-+-+-+-+ - flgs is a set of 4 flags: |0|0|0|T| - +-+-+-+-+ - - - -Hinden & Deering Standards Track [Page 13] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - The high-order 3 flags are reserved, and must be initialized - to 0. - - T = 0 indicates a permanently-assigned ("well-known") - multicast address, assigned by the Internet Assigned Number - Authority (IANA). - - T = 1 indicates a non-permanently-assigned ("transient") - multicast address. - - scop is a 4-bit multicast scope value used to limit the scope - of the multicast group. The values are: - - 0 reserved - 1 interface-local scope - 2 link-local scope - 3 reserved - 4 admin-local scope - 5 site-local scope - 6 (unassigned) - 7 (unassigned) - 8 organization-local scope - 9 (unassigned) - A (unassigned) - B (unassigned) - C (unassigned) - D (unassigned) - E global scope - F reserved - - interface-local scope spans only a single interface on a - node, and is useful only for loopback transmission of - multicast. - - link-local and site-local multicast scopes span the same - topological regions as the corresponding unicast scopes. - - admin-local scope is the smallest scope that must be - administratively configured, i.e., not automatically derived - from physical connectivity or other, non- multicast-related - configuration. - - organization-local scope is intended to span multiple sites - belonging to a single organization. - - scopes labeled "(unassigned)" are available for - administrators to define additional multicast regions. - - - - -Hinden & Deering Standards Track [Page 14] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - group ID identifies the multicast group, either permanent or - transient, within the given scope. - - The "meaning" of a permanently-assigned multicast address is - independent of the scope value. For example, if the "NTP servers - group" is assigned a permanent multicast address with a group ID of - 101 (hex), then: - - FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface - (i.e., the same node) as the sender. - - FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the - sender. - - FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as the - sender. - - FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet. - - Non-permanently-assigned multicast addresses are meaningful only - within a given scope. For example, a group identified by the non- - permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one - site bears no relationship to a group using the same address at a - different site, nor to a non-permanent group using the same group ID - with different scope, nor to a permanent group with the same group - ID. - - Multicast addresses must not be used as source addresses in IPv6 - packets or appear in any Routing header. - - Routers must not forward any multicast packets beyond of the scope - indicated by the scop field in the destination multicast address. - - Nodes must not originate a packet to a multicast address whose scop - field contains the reserved value 0; if such a packet is received, it - must be silently dropped. Nodes should not originate a packet to a - multicast address whose scop field contains the reserved value F; if - such a packet is sent or received, it must be treated the same as - packets destined to a global (scop E) multicast address. - -2.7.1 Pre-Defined Multicast Addresses - - The following well-known multicast addresses are pre-defined. The - group ID's defined in this section are defined for explicit scope - values. - - Use of these group IDs for any other scope values, with the T flag - equal to 0, is not allowed. - - - -Hinden & Deering Standards Track [Page 15] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 - FF01:0:0:0:0:0:0:0 - FF02:0:0:0:0:0:0:0 - FF03:0:0:0:0:0:0:0 - FF04:0:0:0:0:0:0:0 - FF05:0:0:0:0:0:0:0 - FF06:0:0:0:0:0:0:0 - FF07:0:0:0:0:0:0:0 - FF08:0:0:0:0:0:0:0 - FF09:0:0:0:0:0:0:0 - FF0A:0:0:0:0:0:0:0 - FF0B:0:0:0:0:0:0:0 - FF0C:0:0:0:0:0:0:0 - FF0D:0:0:0:0:0:0:0 - FF0E:0:0:0:0:0:0:0 - FF0F:0:0:0:0:0:0:0 - - The above multicast addresses are reserved and shall never be - assigned to any multicast group. - - All Nodes Addresses: FF01:0:0:0:0:0:0:1 - FF02:0:0:0:0:0:0:1 - - The above multicast addresses identify the group of all IPv6 nodes, - within scope 1 (interface-local) or 2 (link-local). - - All Routers Addresses: FF01:0:0:0:0:0:0:2 - FF02:0:0:0:0:0:0:2 - FF05:0:0:0:0:0:0:2 - - The above multicast addresses identify the group of all IPv6 routers, - within scope 1 (interface-local), 2 (link-local), or 5 (site-local). - - Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX - - Solicited-node multicast address are computed as a function of a - node's unicast and anycast addresses. A solicited-node multicast - address is formed by taking the low-order 24 bits of an address - (unicast or anycast) and appending those bits to the prefix - FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the - range - - FF02:0:0:0:0:1:FF00:0000 - - to - - FF02:0:0:0:0:1:FFFF:FFFF - - - - -Hinden & Deering Standards Track [Page 16] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - For example, the solicited node multicast address corresponding to - the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6 - addresses that differ only in the high-order bits, e.g., due to - multiple high-order prefixes associated with different aggregations, - will map to the same solicited-node address thereby, reducing the - number of multicast addresses a node must join. - - A node is required to compute and join (on the appropriate interface) - the associated Solicited-Node multicast addresses for every unicast - and anycast address it is assigned. - -2.8 A Node's Required Addresses - - A host is required to recognize the following addresses as - identifying itself: - - o Its required Link-Local Address for each interface. - o Any additional Unicast and Anycast Addresses that have been - configured for the node's interfaces (manually or - automatically). - o The loopback address. - o The All-Nodes Multicast Addresses defined in section 2.7.1. - o The Solicited-Node Multicast Address for each of its unicast - and anycast addresses. - o Multicast Addresses of all other groups to which the node - belongs. - - A router is required to recognize all addresses that a host is - required to recognize, plus the following addresses as identifying - itself: - - o The Subnet-Router Anycast Addresses for all interfaces for - which it is configured to act as a router. - o All other Anycast Addresses with which the router has been - configured. - o The All-Routers Multicast Addresses defined in section 2.7.1. - -3. Security Considerations - - IPv6 addressing documents do not have any direct impact on Internet - infrastructure security. Authentication of IPv6 packets is defined - in [AUTH]. - - - - - - - - - -Hinden & Deering Standards Track [Page 17] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - -4. IANA Considerations - - The table and notes at http://www.isi.edu/in- - notes/iana/assignments/ipv6-address-space.txt should be replaced with - the following: - - INTERNET PROTOCOL VERSION 6 ADDRESS SPACE - - The initial assignment of IPv6 address space is as follows: - - Allocation Prefix Fraction of - (binary) Address Space - ----------------------------------- -------- ------------- - Unassigned (see Note 1 below) 0000 0000 1/256 - Unassigned 0000 0001 1/256 - Reserved for NSAP Allocation 0000 001 1/128 [RFC1888] - Unassigned 0000 01 1/64 - Unassigned 0000 1 1/32 - Unassigned 0001 1/16 - Global Unicast 001 1/8 [RFC2374] - Unassigned 010 1/8 - Unassigned 011 1/8 - Unassigned 100 1/8 - Unassigned 101 1/8 - Unassigned 110 1/8 - Unassigned 1110 1/16 - Unassigned 1111 0 1/32 - Unassigned 1111 10 1/64 - Unassigned 1111 110 1/128 - Unassigned 1111 1110 0 1/512 - Link-Local Unicast Addresses 1111 1110 10 1/1024 - Site-Local Unicast Addresses 1111 1110 11 1/1024 - Multicast Addresses 1111 1111 1/256 - - Notes: - - 1. The "unspecified address", the "loopback address", and the IPv6 - Addresses with Embedded IPv4 Addresses are assigned out of the - 0000 0000 binary prefix space. - - 2. For now, IANA should limit its allocation of IPv6 unicast address - space to the range of addresses that start with binary value 001. - The rest of the global unicast address space (approximately 85% of - the IPv6 address space) is reserved for future definition and use, - and is not to be assigned by IANA at this time. - - - - - - -Hinden & Deering Standards Track [Page 18] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - -5. References - -5.1 Normative References - - [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 - (IPv6) Specification", RFC 2460, December 1998. - - [RFC2026] Bradner, S., "The Internet Standards Process -- Revision - 3", BCP 9 , RFC 2026, October 1996. - -5.2 Informative References - - [ANYCST] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting - Service", RFC 1546, November 1993. - - [AUTH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC - 2402, November 1998. - - [AGGR] Hinden, R., O'Dell, M. and S. Deering, "An Aggregatable - Global Unicast Address Format", RFC 2374, July 1998. - - [CIDR] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless - Inter-Domain Routing (CIDR): An Address Assignment and - Aggregation Strategy", RFC 1519, September 1993. - - [ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet - Networks", RFC 2464, December 1998. - - [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) - Registration Authority", - http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, - March 1997. - - [FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI - Networks", RFC 2467, December 1998. - - [MASGN] Hinden, R. and S. Deering, "IPv6 Multicast Address - Assignments", RFC 2375, July 1998. - - [NSAP] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J. - and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996. - - [PRIV] Narten, T. and R. Draves, "Privacy Extensions for Stateless - Address Autoconfiguration in IPv6", RFC 3041, January 2001. - - [TOKEN] Crawford, M., Narten, T. and S. Thomas, "Transmission of - IPv6 Packets over Token Ring Networks", RFC 2470, December - 1998. - - - -Hinden & Deering Standards Track [Page 19] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - [TRAN] Gilligan, R. and E. Nordmark, "Transition Mechanisms for - IPv6 Hosts and Routers", RFC 2893, August 2000. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 20] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - -APPENDIX A: Creating Modified EUI-64 format Interface Identifiers - - Depending on the characteristics of a specific link or node there are - a number of approaches for creating Modified EUI-64 format interface - identifiers. This appendix describes some of these approaches. - -Links or Nodes with IEEE EUI-64 Identifiers - - The only change needed to transform an IEEE EUI-64 identifier to an - interface identifier is to invert the "u" (universal/local) bit. For - example, a globally unique IEEE EUI-64 identifier of the form: - - |0 1|1 3|3 4|4 6| - |0 5|6 1|2 7|8 3| - +----------------+----------------+----------------+----------------+ - |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| - +----------------+----------------+----------------+----------------+ - - where "c" are the bits of the assigned company_id, "0" is the value - of the universal/local bit to indicate global scope, "g" is - individual/group bit, and "m" are the bits of the manufacturer- - selected extension identifier. The IPv6 interface identifier would - be of the form: - - |0 1|1 3|3 4|4 6| - |0 5|6 1|2 7|8 3| - +----------------+----------------+----------------+----------------+ - |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| - +----------------+----------------+----------------+----------------+ - - The only change is inverting the value of the universal/local bit. - -Links or Nodes with IEEE 802 48 bit MAC's - - [EUI64] defines a method to create a IEEE EUI-64 identifier from an - IEEE 48bit MAC identifier. This is to insert two octets, with - hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC - (between the company_id and vendor supplied id). For example, the 48 - bit IEEE MAC with global scope: - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 21] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - |0 1|1 3|3 4| - |0 5|6 1|2 7| - +----------------+----------------+----------------+ - |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| - +----------------+----------------+----------------+ - - where "c" are the bits of the assigned company_id, "0" is the value - of the universal/local bit to indicate global scope, "g" is - individual/group bit, and "m" are the bits of the manufacturer- - selected extension identifier. The interface identifier would be of - the form: - - |0 1|1 3|3 4|4 6| - |0 5|6 1|2 7|8 3| - +----------------+----------------+----------------+----------------+ - |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| - +----------------+----------------+----------------+----------------+ - - When IEEE 802 48bit MAC addresses are available (on an interface or a - node), an implementation may use them to create interface identifiers - due to their availability and uniqueness properties. - -Links with Other Kinds of Identifiers - - There are a number of types of links that have link-layer interface - identifiers other than IEEE EIU-64 or IEEE 802 48-bit MACs. Examples - include LocalTalk and Arcnet. The method to create an Modified EUI- - 64 format identifier is to take the link identifier (e.g., the - LocalTalk 8 bit node identifier) and zero fill it to the left. For - example, a LocalTalk 8 bit node identifier of hexadecimal value 0x4F - results in the following interface identifier: - - |0 1|1 3|3 4|4 6| - |0 5|6 1|2 7|8 3| - +----------------+----------------+----------------+----------------+ - |0000000000000000|0000000000000000|0000000000000000|0000000001001111| - +----------------+----------------+----------------+----------------+ - - Note that this results in the universal/local bit set to "0" to - indicate local scope. - -Links without Identifiers - - There are a number of links that do not have any type of built-in - identifier. The most common of these are serial links and configured - tunnels. Interface identifiers must be chosen that are unique within - a subnet-prefix. - - - - -Hinden & Deering Standards Track [Page 22] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - When no built-in identifier is available on a link the preferred - approach is to use a global interface identifier from another - interface or one which is assigned to the node itself. When using - this approach no other interface connecting the same node to the same - subnet-prefix may use the same identifier. - - If there is no global interface identifier available for use on the - link the implementation needs to create a local-scope interface - identifier. The only requirement is that it be unique within a - subnet prefix. There are many possible approaches to select a - subnet-prefix-unique interface identifier. These include: - - Manual Configuration - Node Serial Number - Other node-specific token - - The subnet-prefix-unique interface identifier should be generated in - a manner that it does not change after a reboot of a node or if - interfaces are added or deleted from the node. - - The selection of the appropriate algorithm is link and implementation - dependent. The details on forming interface identifiers are defined - in the appropriate "IPv6 over <link>" specification. It is strongly - recommended that a collision detection algorithm be implemented as - part of any automatic algorithm. - - - - - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 23] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - -APPENDIX B: Changes from RFC-2373 - - The following changes were made from RFC-2373 "IP Version 6 - Addressing Architecture": - - - Clarified text in section 2.2 to allow "::" to represent one or - more groups of 16 bits of zeros. - - Changed uniqueness requirement of Interface Identifiers from - unique on a link to unique within a subnet prefix. Also added a - recommendation that the same interface identifier not be assigned - to different machines on a link. - - Change site-local format to make the subnet ID field 54-bit long - and remove the 38-bit zero's field. - - Added description of multicast scop values and rules to handle the - reserved scop value 0. - - Revised sections 2.4 and 2.5.6 to simplify and clarify how - different address types are identified. This was done to insure - that implementations do not build in any knowledge about global - unicast format prefixes. Changes include: - o Removed Format Prefix (FP) terminology - o Revised list of address types to only include exceptions to - global unicast and a singe entry that identifies everything - else as Global Unicast. - o Removed list of defined prefix exceptions from section 2.5.6 - as it is now the main part of section 2.4. - - Clarified text relating to EUI-64 identifiers to distinguish - between IPv6's "Modified EUI-64 format" identifiers and IEEE EUI- - 64 identifiers. - - Combined the sections on the Global Unicast Addresses and NSAP - Addresses into a single section on Global Unicast Addresses, - generalized the Global Unicast format, and cited [AGGR] and [NSAP] - as examples. - - Reordered sections 2.5.4 and 2.5.5. - - Removed section 2.7.2 Assignment of New IPv6 Multicast Addresses - because this is being redefined elsewhere. - - Added an IANA considerations section that updates the IANA IPv6 - address allocations and documents the NSAP and AGGR allocations. - - Added clarification that the "IPv4-compatible IPv6 address" must - use global IPv4 unicast addresses. - - Divided references in to normative and non-normative sections. - - Added reference to [PRIV] in section 2.5.1 - - Added clarification that routers must not forward multicast - packets outside of the scope indicated in the multicast address. - - Added clarification that routers must not forward packets with - source address of the unspecified address. - - Added clarification that routers must drop packets received on an - interface with destination address of loopback. - - Clarified the definition of IPv4-mapped addresses. - - - -Hinden & Deering Standards Track [Page 24] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - - - Removed the ABNF Description of Text Representations Appendix. - - Removed the address block reserved for IPX addresses. - - Multicast scope changes: - o Changed name of scope value 1 from "node-local" to - "interface-local" - o Defined scope value 4 as "admin-local" - - Corrected reference to RFC1933 and updated references. - - Many small changes to clarify and make the text more consistent. - -Authors' Addresses - - Robert M. Hinden - Nokia - 313 Fairchild Drive - Mountain View, CA 94043 - USA - - Phone: +1 650 625-2004 - EMail: hinden@iprg.nokia.com - - - Stephen E. Deering - Cisco Systems, Inc. - 170 West Tasman Drive - San Jose, CA 95134-1706 - USA - - Phone: +1 408 527-8213 - EMail: deering@cisco.com - - - - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 25] - -RFC 3513 IPv6 Addressing Architecture April 2003 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Hinden & Deering Standards Track [Page 26] - diff --git a/contrib/bind9/doc/rfc/rfc3596.txt b/contrib/bind9/doc/rfc/rfc3596.txt deleted file mode 100644 index f65690c8875a..000000000000 --- a/contrib/bind9/doc/rfc/rfc3596.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -Network Working Group S. Thomson -Request for Comments: 3596 Cisco -Obsoletes: 3152, 1886 C. Huitema -Category: Standards Track Microsoft - V. Ksinant - 6WIND - M. Souissi - AFNIC - October 2003 - - - DNS Extensions to Support IP Version 6 - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - This document defines the changes that need to be made to the Domain - Name System (DNS) to support hosts running IP version 6 (IPv6). The - changes include a resource record type to store an IPv6 address, a - domain to support lookups based on an IPv6 address, and updated - definitions of existing query types that return Internet addresses as - part of additional section processing. The extensions are designed - to be compatible with existing applications and, in particular, DNS - implementations themselves. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. New resource record definition and domain. . . . . . . . . . . 2 - 2.1. AAAA record type . . . . . . . . . . . . . . . . . . . . 3 - 2.2. AAAA data format . . . . . . . . . . . . . . . . . . . . 3 - 2.3. AAAA query . . . . . . . . . . . . . . . . . . . . . . . 3 - 2.4. Textual format of AAAA records . . . . . . . . . . . . . 3 - 2.5. IP6.ARPA domain. . . . . . . . . . . . . . . . . . . . . 3 - 3. Modifications to existing query types. . . . . . . . . . . . . 4 - 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 4 - 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 4 - - - -Thomson, et al. Standards Track [Page 1] - -RFC 3596 DNS Extensions to Support IPv6 October 2003 - - - 6. Intellectual Property Statement. . . . . . . . . . . . . . . . 4 - Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 5 - Appendix A: Changes from RFC 1886. . . . . . . . . . . . . . . . . 6 - Normative References . . . . . . . . . . . . . . . . . . . . . . . 6 - Informative References . . . . . . . . . . . . . . . . . . . . . . 6 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8 - -1. Introduction - - Current support for the storage of Internet addresses in the Domain - Name System (DNS) [1,2] cannot easily be extended to support IPv6 - addresses [3] since applications assume that address queries return - 32-bit IPv4 addresses only. - - To support the storage of IPv6 addresses in the DNS, this document - defines the following extensions: - - o A resource record type is defined to map a domain name to an - IPv6 address. - - o A domain is defined to support lookups based on address. - - o Existing queries that perform additional section processing to - locate IPv4 addresses are redefined to perform additional - section processing on both IPv4 and IPv6 addresses. - - The changes are designed to be compatible with existing software. - The existing support for IPv4 addresses is retained. Transition - issues related to the co-existence of both IPv4 and IPv6 addresses in - the DNS are discussed in [4]. - - The IP protocol version used for querying resource records is - independent of the protocol version of the resource records; e.g., - IPv4 transport can be used to query IPv6 records and vice versa. - - This document combines RFC 1886 [5] and changes to RFC 1886 made by - RFC 3152 [6], obsoleting both. Changes mainly consist in replacing - the IP6.INT domain by IP6.ARPA as defined in RFC 3152. - -2. New resource record definition and domain - - A record type is defined to store a host's IPv6 address. A host that - has more than one IPv6 address must have more than one such record. - - - - - - - -Thomson, et al. Standards Track [Page 2] - -RFC 3596 DNS Extensions to Support IPv6 October 2003 - - -2.1 AAAA record type - - The AAAA resource record type is a record specific to the Internet - class that stores a single IPv6 address. - - The IANA assigned value of the type is 28 (decimal). - -2.2 AAAA data format - - A 128 bit IPv6 address is encoded in the data portion of an AAAA - resource record in network byte order (high-order byte first). - -2.3 AAAA query - - An AAAA query for a specified domain name in the Internet class - returns all associated AAAA resource records in the answer section of - a response. - - A type AAAA query does not trigger additional section processing. - -2.4 Textual format of AAAA records - - The textual representation of the data portion of the AAAA resource - record used in a master database file is the textual representation - of an IPv6 address as defined in [3]. - -2.5 IP6.ARPA Domain - - A special domain is defined to look up a record given an IPv6 - address. The intent of this domain is to provide a way of mapping an - IPv6 address to a host name, although it may be used for other - purposes as well. The domain is rooted at IP6.ARPA. - - An IPv6 address is represented as a name in the IP6.ARPA domain by a - sequence of nibbles separated by dots with the suffix ".IP6.ARPA". - The sequence of nibbles is encoded in reverse order, i.e., the - low-order nibble is encoded first, followed by the next low-order - nibble and so on. Each nibble is represented by a hexadecimal digit. - For example, the reverse lookup domain name corresponding to the - address - - 4321:0:1:2:3:4:567:89ab - - would be - - b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6. - ARPA. - - - - -Thomson, et al. Standards Track [Page 3] - -RFC 3596 DNS Extensions to Support IPv6 October 2003 - - -3. Modifications to existing query types - - All existing query types that perform type A additional section - processing, i.e., name server (NS), location of services (SRV) and - mail exchange (MX) query types, must be redefined to perform both - type A and type AAAA additional section processing. These - definitions mean that a name server must add any relevant IPv4 - addresses and any relevant IPv6 addresses available locally to the - additional section of a response when processing any one of the above - queries. - -4. Security Considerations - - Any information obtained from the DNS must be regarded as unsafe - unless techniques specified in [7] or [8] are used. The definitions - of the AAAA record type and of the IP6.ARPA domain do not change the - model for use of these techniques. - - So, this specification is not believed to cause any new security - problems, nor to solve any existing ones. - -5. IANA Considerations - - There are no IANA assignments to be performed. - -6. Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - - - - -Thomson, et al. Standards Track [Page 4] - -RFC 3596 DNS Extensions to Support IPv6 October 2003 - - -Acknowledgments - - Vladimir Ksinant and Mohsen Souissi would like to thank Sebastien - Barbin (IRISA), Luc Beloeil (France Telecom R&D), Jean-Mickael Guerin - (6WIND), Vincent Levigneron (AFNIC), Alain Ritoux (6WIND), Frederic - Roudaut (IRISA) and G6 group for their help during the RFC 1886 - Interop tests sessions. - - Many thanks to Alain Durand and Olafur Gudmundsson for their support. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Thomson, et al. Standards Track [Page 5] - -RFC 3596 DNS Extensions to Support IPv6 October 2003 - - -Appendix A: Changes from RFC 1886 - - The following changes were made from RFC 1886 "DNS Extensions to - support IP version 6": - - - Replaced the "IP6.INT" domain by "IP6.ARPA". - - Mentioned SRV query types in section 3 "MODIFICATIONS TO - EXISTING QUERY TYPES" - - Added security considerations. - - Updated references : - * From RFC 1884 to RFC 3513 (IP Version 6 Addressing - Architecture). - * From "work in progress" to RFC 2893 (Transition Mechanisms for - IPv6 Hosts and Routers). - * Added reference to RFC 1886, RFC 3152, RFC 2535 and RFC 2845. - - Updated document abstract - - Added table of contents - - Added full copyright statement - - Added IANA considerations section - - Added Intellectual Property Statement - -Normative References - - [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD - 13, RFC 1034, November 1987. - - [2] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) - Addressing Architecture", RFC 3513, April 2003. - -Informative References - - [4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 - Hosts and Routers", RFC 2893, August 2000. - - [5] Thomson, S. and C. Huitema, "DNS Extensions to support IP - version 6", RFC 1886, December 1995. - - [6] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August - 2001. - - [7] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999 - - - - - - -Thomson, et al. Standards Track [Page 6] - -RFC 3596 DNS Extensions to Support IPv6 October 2003 - - - [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC - 2845, May 2000. - -Authors' Addresses - - Susan Thomson - Cisco Systems - 499 Thornall Street, 8th floor - Edison, NJ 08837 - - Phone: +1 732-635-3086 - EMail: sethomso@cisco.com - - - Christian Huitema - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052-6399 - - EMail: huitema@microsoft.com - - - Vladimir Ksinant - 6WIND S.A. - Immeuble Central Gare - Bat.C - 1, place Charles de Gaulle - 78180, Montigny-Le-Bretonneux - France - - Phone: +33 1 39 30 92 36 - EMail: vladimir.ksinant@6wind.com - - - Mohsen Souissi - AFNIC - Immeuble International - 2, rue Stephenson, - 78181, Saint-Quentin en Yvelines Cedex - France - - Phone: +33 1 39 30 83 40 - EMail: Mohsen.Souissi@nic.fr - - - - - - - - - - -Thomson, et al. Standards Track [Page 7] - -RFC 3596 DNS Extensions to Support IPv6 October 2003 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Thomson, et al. Standards Track [Page 8] - diff --git a/contrib/bind9/doc/rfc/rfc3597.txt b/contrib/bind9/doc/rfc/rfc3597.txt deleted file mode 100644 index 19e9a55053d1..000000000000 --- a/contrib/bind9/doc/rfc/rfc3597.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -Network Working Group A. Gustafsson -Request for Comments: 3597 Nominum Inc. -Category: Standards Track September 2003 - - - Handling of Unknown DNS Resource Record (RR) Types - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - Extending the Domain Name System (DNS) with new Resource Record (RR) - types currently requires changes to name server software. This - document specifies the changes necessary to allow future DNS - implementations to handle new RR types transparently. - -1. Introduction - - The DNS is designed to be extensible to support new services through - the introduction of new resource record (RR) types. In practice, - deploying a new RR type currently requires changes to the name server - software not only at the authoritative DNS server that is providing - the new information and the client making use of it, but also at all - slave servers for the zone containing it, and in some cases also at - caching name servers and forwarders used by the client. - - Because the deployment of new server software is slow and expensive, - the potential of the DNS in supporting new services has never been - fully realized. This memo proposes changes to name servers and to - procedures for defining new RR types aimed at simplifying the future - deployment of new RR types. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC 2119]. - - - - - - -Gustafsson Standards Track [Page 1] - -RFC 3597 Handling of Unknown DNS RR Types September 2003 - - -2. Definition - - An "RR of unknown type" is an RR whose RDATA format is not known to - the DNS implementation at hand, and whose type is not an assigned - QTYPE or Meta-TYPE as specified in [RFC 2929] (section 3.1) nor - within the range reserved in that section for assignment only to - QTYPEs and Meta-TYPEs. Such an RR cannot be converted to a type- - specific text format, compressed, or otherwise handled in a type- - specific way. - - In the case of a type whose RDATA format is class specific, an RR is - considered to be of unknown type when the RDATA format for that - combination of type and class is not known. - -3. Transparency - - To enable new RR types to be deployed without server changes, name - servers and resolvers MUST handle RRs of unknown type transparently. - That is, they must treat the RDATA section of such RRs as - unstructured binary data, storing and transmitting it without change - [RFC1123]. - - To ensure the correct operation of equality comparison (section 6) - and of the DNSSEC canonical form (section 7) when an RR type is known - to some but not all of the servers involved, servers MUST also - exactly preserve the RDATA of RRs of known type, except for changes - due to compression or decompression where allowed by section 4 of - this memo. In particular, the character case of domain names that - are not subject to compression MUST be preserved. - -4. Domain Name Compression - - RRs containing compression pointers in the RDATA part cannot be - treated transparently, as the compression pointers are only - meaningful within the context of a DNS message. Transparently - copying the RDATA into a new DNS message would cause the compression - pointers to point at the corresponding location in the new message, - which now contains unrelated data. This would cause the compressed - name to be corrupted. - - To avoid such corruption, servers MUST NOT compress domain names - embedded in the RDATA of types that are class-specific or not well- - known. This requirement was stated in [RFC1123] without defining the - term "well-known"; it is hereby specified that only the RR types - defined in [RFC1035] are to be considered "well-known". - - - - - - -Gustafsson Standards Track [Page 2] - -RFC 3597 Handling of Unknown DNS RR Types September 2003 - - - The specifications of a few existing RR types have explicitly allowed - compression contrary to this specification: [RFC2163] specified that - compression applies to the PX RR, and [RFC2535] allowed compression - in SIG RRs and NXT RRs records. Since this specification disallows - compression in these cases, it is an update to [RFC2163] (section 4) - and [RFC2535] (sections 4.1.7 and 5.2). - - Receiving servers MUST decompress domain names in RRs of well-known - type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX, - NXT, NAPTR, and SRV (although the current specification of the SRV RR - in [RFC2782] prohibits compression, [RFC2052] mandated it, and some - servers following that earlier specification are still in use). - - Future specifications for new RR types that contain domain names - within their RDATA MUST NOT allow the use of name compression for - those names, and SHOULD explicitly state that the embedded domain - names MUST NOT be compressed. - - As noted in [RFC1123], the owner name of an RR is always eligible for - compression. - -5. Text Representation - - In the "type" field of a master file line, an unknown RR type is - represented by the word "TYPE" immediately followed by the decimal RR - type number, with no intervening whitespace. In the "class" field, - an unknown class is similarly represented as the word "CLASS" - immediately followed by the decimal class number. - - This convention allows types and classes to be distinguished from - each other and from TTL values, allowing the "[<TTL>] [<class>] - <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of - [RFC1035] to both be unambiguously parsed. - - The RDATA section of an RR of unknown type is represented as a - sequence of white space separated words as follows: - - The special token \# (a backslash immediately followed by a hash - sign), which identifies the RDATA as having the generic encoding - defined herein rather than a traditional type-specific encoding. - - An unsigned decimal integer specifying the RDATA length in octets. - - Zero or more words of hexadecimal data encoding the actual RDATA - field, each containing an even number of hexadecimal digits. - - If the RDATA is of zero length, the text representation contains only - the \# token and the single zero representing the length. - - - -Gustafsson Standards Track [Page 3] - -RFC 3597 Handling of Unknown DNS RR Types September 2003 - - - An implementation MAY also choose to represent some RRs of known type - using the above generic representations for the type, class and/or - RDATA, which carries the benefit of making the resulting master file - portable to servers where these types are unknown. Using the generic - representation for the RDATA of an RR of known type can also be - useful in the case of an RR type where the text format varies - depending on a version, protocol, or similar field (or several) - embedded in the RDATA when such a field has a value for which no text - format is known, e.g., a LOC RR [RFC1876] with a VERSION other than - 0. - - Even though an RR of known type represented in the \# format is - effectively treated as an unknown type for the purpose of parsing the - RDATA text representation, all further processing by the server MUST - treat it as a known type and take into account any applicable type- - specific rules regarding compression, canonicalization, etc. - - The following are examples of RRs represented in this manner, - illustrating various combinations of generic and type-specific - encodings for the different fields of the master file format: - - a.example. CLASS32 TYPE731 \# 6 abcd ( - ef 01 23 45 ) - b.example. HS TYPE62347 \# 0 - e.example. IN A \# 4 0A000001 - e.example. CLASS1 TYPE1 10.0.0.2 - -6. Equality Comparison - - Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs - to be compared for equality. Two RRs of the same unknown type are - considered equal when their RDATA is bitwise equal. To ensure that - the outcome of the comparison is identical whether the RR is known to - the server or not, specifications for new RR types MUST NOT specify - type-specific comparison rules. - - This implies that embedded domain names, being included in the - overall bitwise comparison, are compared in a case-sensitive manner. - - As a result, when a new RR type contains one or more embedded domain - names, it is possible to have multiple RRs owned by the same name - that differ only in the character case of the embedded domain - name(s). This is similar to the existing possibility of multiple TXT - records differing only in character case, and not expected to cause - any problems in practice. - - - - - - -Gustafsson Standards Track [Page 4] - -RFC 3597 Handling of Unknown DNS RR Types September 2003 - - -7. DNSSEC Canonical Form and Ordering - - DNSSEC defines a canonical form and ordering for RRs [RFC2535] - (section 8.1). In that canonical form, domain names embedded in the - RDATA are converted to lower case. - - The downcasing is necessary to ensure the correctness of DNSSEC - signatures when case distinctions in domain names are lost due to - compression, but since it requires knowledge of the presence and - position of embedded domain names, it cannot be applied to unknown - types. - - To ensure continued consistency of the canonical form of RR types - where compression is allowed, and for continued interoperability with - existing implementations that already implement the [RFC2535] - canonical form and apply it to their known RR types, the canonical - form remains unchanged for all RR types whose whose initial - publication as an RFC was prior to the initial publication of this - specification as an RFC (RFC 3597). - - As a courtesy to implementors, it is hereby noted that the complete - set of such previously published RR types that contain embedded - domain names, and whose DNSSEC canonical form therefore involves - downcasing according to the DNS rules for character comparisons, - consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, - HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, - DNAME, and A6. - - This document specifies that for all other RR types (whether treated - as unknown types or treated as known types according to an RR type - definition RFC more recent than RFC 3597), the canonical form is such - that no downcasing of embedded domain names takes place, and - otherwise identical to the canonical form specified in [RFC2535] - section 8.1. - - Note that the owner name is always set to lower case according to the - DNS rules for character comparisons, regardless of the RR type. - - The DNSSEC canonical RR ordering is as specified in [RFC2535] section - 8.3, where the octet sequence is the canonical form as revised by - this specification. - -8. Additional Section Processing - - Unknown RR types cause no additional section processing. Future RR - type specifications MAY specify type-specific additional section - processing rules, but any such processing MUST be optional as it can - only be performed by servers for which the RR type in case is known. - - - -Gustafsson Standards Track [Page 5] - -RFC 3597 Handling of Unknown DNS RR Types September 2003 - - -9. IANA Considerations - - This document does not require any IANA actions. - -10. Security Considerations - - This specification is not believed to cause any new security - problems, nor to solve any existing ones. - -11. Normative References - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and - Facilities", STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specifications", STD 13, RFC 1035, November 1987. - - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -- - Application and Support", STD 3, RFC 1123, October 1989. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2163] Allocchio, C., "Using the Internet DNS to Distribute - MIXER Conformant Global Address Mapping (MCGAM)", RFC - 2163, January 1998. - - [RFC2929] Eastlake, D., Brunner-Williams, E. and B. Manning, - "Domain Name System (DNS) IANA Considerations", BCP 42, - RFC 2929, September 2000. - -12. Informative References - - [RFC1876] Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A - Means for Expressing Location Information in the Domain - Name System", RFC 1876, January 1996. - - [RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying - the location of services (DNS SRV)", RFC 2052, October - 1996. - - [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - - - -Gustafsson Standards Track [Page 6] - -RFC 3597 Handling of Unknown DNS RR Types September 2003 - - - [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for - specifying the location of services (DNS SRV)", RFC 2782, - February 2000. - -13. Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - -14. Author's Address - - Andreas Gustafsson - Nominum, Inc. - 2385 Bay Rd - Redwood City, CA 94063 - USA - - Phone: +1 650 381 6004 - EMail: gson@nominum.com - - - - - - - - - - - - - - - -Gustafsson Standards Track [Page 7] - -RFC 3597 Handling of Unknown DNS RR Types September 2003 - - -15. Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Gustafsson Standards Track [Page 8] - diff --git a/contrib/bind9/doc/rfc/rfc3645.txt b/contrib/bind9/doc/rfc/rfc3645.txt deleted file mode 100644 index 61266786a547..000000000000 --- a/contrib/bind9/doc/rfc/rfc3645.txt +++ /dev/null @@ -1,1459 +0,0 @@ - - - - - - -Network Working Group S. Kwan -Request for Comments: 3645 P. Garg -Updates: 2845 J. Gilroy -Category: Standards Track L. Esibov - J. Westhead - Microsoft Corp. - R. Hall - Lucent Technologies - October 2003 - - - Generic Security Service Algorithm for - Secret Key Transaction Authentication for DNS (GSS-TSIG) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - The Secret Key Transaction Authentication for DNS (TSIG) protocol - provides transaction level authentication for DNS. TSIG is - extensible through the definition of new algorithms. This document - specifies an algorithm based on the Generic Security Service - Application Program Interface (GSS-API) (RFC2743). This document - updates RFC 2845. - - - - - - - - - - - - - - - - - -Kwan, et al. Standards Track [Page 1] - -RFC 3645 GSS-TSIG October 2003 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Algorithm Overview . . . . . . . . . . . . . . . . . . . . . . 3 - 2.1. GSS Details. . . . . . . . . . . . . . . . . . . . . . . 4 - 2.2. Modifications to the TSIG protocol (RFC 2845). . . . . . 4 - 3. Client Protocol Details. . . . . . . . . . . . . . . . . . . . 5 - 3.1. Negotiating Context. . . . . . . . . . . . . . . . . . . 5 - 3.1.1. Call GSS_Init_sec_context. . . . . . . . . . . . . 6 - 3.1.2. Send TKEY Query to Server. . . . . . . . . . . . . 8 - 3.1.3. Receive TKEY Query-Response from Server. . . . . . 8 - 3.2. Context Established. . . . . . . . . . . . . . . . . . . 11 - 3.2.1. Terminating a Context. . . . . . . . . . . . . . . 11 - 4. Server Protocol Details. . . . . . . . . . . . . . . . . . . . 12 - 4.1. Negotiating Context. . . . . . . . . . . . . . . . . . . 12 - 4.1.1. Receive TKEY Query from Client . . . . . . . . . . 12 - 4.1.2. Call GSS_Accept_sec_context. . . . . . . . . . . . 12 - 4.1.3. Send TKEY Query-Response to Client . . . . . . . . 13 - 4.2. Context Established. . . . . . . . . . . . . . . . . . . 15 - 4.2.1. Terminating a Context. . . . . . . . . . . . . . . 15 - 5. Sending and Verifying Signed Messages. . . . . . . . . . . . . 15 - 5.1. Sending a Signed Message - Call GSS_GetMIC . . . . . . . 15 - 5.2. Verifying a Signed Message - Call GSS_VerifyMIC. . . . . 16 - 6. Example usage of GSS-TSIG algorithm. . . . . . . . . . . . . . 18 - 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 22 - 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22 - 9. Conformance. . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 10. Intellectual Property Statement. . . . . . . . . . . . . . . . 23 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 12.1. Normative References. . . . . . . . . . . . . . . . . . 24 - 12.2. Informative References. . . . . . . . . . . . . . . . . 24 - 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 - 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26 - -1. Introduction - - The Secret Key Transaction Authentication for DNS (TSIG) [RFC2845] - protocol was developed to provide a lightweight authentication and - integrity of messages between two DNS entities, such as client and - server or server and server. TSIG can be used to protect dynamic - update messages, authenticate regular message or to off-load - complicated DNSSEC [RFC2535] processing from a client to a server and - still allow the client to be assured of the integrity of the answers. - - - - - - - -Kwan, et al. Standards Track [Page 2] - -RFC 3645 GSS-TSIG October 2003 - - - The TSIG protocol [RFC2845] is extensible through the definition of - new algorithms. This document specifies an algorithm based on the - Generic Security Service Application Program Interface (GSS-API) - [RFC2743]. GSS-API is a framework that provides an abstraction of - security to the application protocol developer. The security - services offered can include authentication, integrity, and - confidentiality. - - The GSS-API framework has several benefits: - - * Mechanism and protocol independence. The underlying mechanisms - that realize the security services can be negotiated on the fly - and varied over time. For example, a client and server MAY use - Kerberos [RFC1964] for one transaction, whereas that same server - MAY use SPKM [RFC2025] with a different client. - - * The protocol developer is removed from the responsibility of - creating and managing a security infrastructure. For example, the - developer does not need to create new key distribution or key - management systems. Instead the developer relies on the security - service mechanism to manage this on its behalf. - - The scope of this document is limited to the description of an - authentication mechanism only. It does not discuss and/or propose an - authorization mechanism. Readers that are unfamiliar with GSS-API - concepts are encouraged to read the characteristics and concepts - section of [RFC2743] before examining this protocol in detail. It is - also assumed that the reader is familiar with [RFC2845], [RFC2930], - [RFC1034] and [RFC1035]. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", - "RECOMMENDED", and "MAY" in this document are to be interpreted as - described in BCP 14, RFC 2119 [RFC2119]. - -2. Algorithm Overview - - In GSS, client and server interact to create a "security context". - The security context can be used to create and verify transaction - signatures on messages between the two parties. A unique security - context is required for each unique connection between client and - server. - - Creating a security context involves a negotiation between client and - server. Once a context has been established, it has a finite - lifetime for which it can be used to secure messages. Thus there are - three states of a context associated with a connection: - - - - - -Kwan, et al. Standards Track [Page 3] - -RFC 3645 GSS-TSIG October 2003 - - - +----------+ - | | - V | - +---------------+ | - | Uninitialized | | - | | | - +---------------+ | - | | - V | - +---------------+ | - | Negotiating | | - | Context | | - +---------------+ | - | | - V | - +---------------+ | - | Context | | - | Established | | - +---------------+ | - | | - +----------+ - - Every connection begins in the uninitialized state. - -2.1. GSS Details - - Client and server MUST be locally authenticated and have acquired - default credentials before using this protocol as specified in - Section 1.1.1 "Credentials" in RFC 2743 [RFC2743]. - - The GSS-TSIG algorithm consists of two stages: - - I. Establish security context. The Client and Server use the - GSS_Init_sec_context and GSS_Accept_sec_context APIs to generate - the tokens that they pass to each other using [RFC2930] as a - transport mechanism. - - II. Once the security context is established it is used to generate - and verify signatures using GSS_GetMIC and GSS_VerifyMIC APIs. - These signatures are exchanged by the Client and Server as a part - of the TSIG records exchanged in DNS messages sent between the - Client and Server, as described in [RFC2845]. - -2.2. Modifications to the TSIG protocol (RFC 2845) - - Modification to RFC 2845 allows use of TSIG through signing server's - response in an explicitly specified place in multi message exchange - between two DNS entities even if client's request wasn't signed. - - - -Kwan, et al. Standards Track [Page 4] - -RFC 3645 GSS-TSIG October 2003 - - - Specifically, Section 4.2 of RFC 2845 MUST be modified as follows: - - Replace: - "The server MUST not generate a signed response to an unsigned - request." - - With: - "The server MUST not generate a signed response to an unsigned - request, except in case of response to client's unsigned TKEY - query if secret key is established on server side after server - processed client's query. Signing responses to unsigned TKEY - queries MUST be explicitly specified in the description of an - individual secret key establishment algorithm." - -3. Client Protocol Details - - A unique context is required for each server to which the client - sends secure messages. A context is identified by a context handle. - A client maintains a mapping of servers to handles: - - (target_name, key_name, context_handle) - - The value key_name also identifies a context handle. The key_name is - the owner name of the TKEY and TSIG records sent between a client and - a server to indicate to each other which context MUST be used to - process the current request. - - DNS client and server MAY use various underlying security mechanisms - to establish security context as described in sections 3 and 4. At - the same time, in order to guarantee interoperability between DNS - clients and servers that support GSS-TSIG it is REQUIRED that - security mechanism used by client enables use of Kerberos v5 (see - Section 9 for more information). - -3.1. Negotiating Context - - In GSS, establishing a security context involves the passing of - opaque tokens between the client and the server. The client - generates the initial token and sends it to the server. The server - processes the token and if necessary, returns a subsequent token to - the client. The client processes this token, and so on, until the - negotiation is complete. The number of times the client and server - exchange tokens depends on the underlying security mechanism. A - completed negotiation results in a context handle. - - - - - - - -Kwan, et al. Standards Track [Page 5] - -RFC 3645 GSS-TSIG October 2003 - - - The TKEY resource record [RFC2930] is used as the vehicle to transfer - tokens between client and server. The TKEY record is a general - mechanism for establishing secret keys for use with TSIG. For more - information, see [RFC2930]. - -3.1.1. Call GSS_Init_sec_context - - To obtain the first token to be sent to a server, a client MUST call - GSS_Init_sec_context API. - - The following input parameters MUST be used. The outcome of the call - is indicated with the output values below. Consult Sections 2.2.1, - "GSS_Init_sec_context call", of [RFC2743] for syntax definitions. - - INPUTS - CREDENTIAL HANDLE claimant_cred_handle = NULL (NULL specifies "use - default"). Client MAY instead specify some other valid - handle to its credentials. - CONTEXT HANDLE input_context_handle = 0 - INTERNAL NAME targ_name = "DNS@<target_server_name>" - OBJECT IDENTIFIER mech_type = Underlying security - mechanism chosen by implementers. To guarantee - interoperability of the implementations of the GSS-TSIG - mechanism client MUST specify a valid underlying security - mechanism that enables use of Kerberos v5 (see Section 9 for - more information). - OCTET STRING input_token = NULL - BOOLEAN replay_det_req_flag = TRUE - BOOLEAN mutual_req_flag = TRUE - BOOLEAN deleg_req_flag = TRUE - BOOLEAN sequence_req_flag = TRUE - BOOLEAN anon_req_flag = FALSE - BOOLEAN integ_req_flag = TRUE - INTEGER lifetime_req = 0 (0 requests a default - value). Client MAY instead specify another upper bound for the - lifetime of the context to be established in seconds. - OCTET STRING chan_bindings = Any valid channel bindings - as specified in Section 1.1.6 "Channel Bindings" in [RFC2743] - - OUTPUTS - INTEGER major_status - CONTEXT HANDLE output_context_handle - OCTET STRING output_token - BOOLEAN replay_det_state - BOOLEAN mutual_state - INTEGER minor_status - OBJECT IDENTIFIER mech_type - BOOLEAN deleg_state - - - -Kwan, et al. Standards Track [Page 6] - -RFC 3645 GSS-TSIG October 2003 - - - BOOLEAN sequence_state - BOOLEAN anon_state - BOOLEAN trans_state - BOOLEAN prot_ready_state - BOOLEAN conf_avail - BOOLEAN integ_avail - INTEGER lifetime_rec - - If returned major_status is set to one of the following errors: - - GSS_S_DEFECTIVE_TOKEN - GSS_S_DEFECTIVE_CREDENTIAL - GSS_S_BAD_SIG (GSS_S_BAD_MIC) - GSS_S_NO_CRED - GSS_S_CREDENTIALS_EXPIRED - GSS_S_BAD_BINDINGS - GSS_S_OLD_TOKEN - GSS_S_DUPLICATE_TOKEN - GSS_S_NO_CONTEXT - GSS_S_BAD_NAMETYPE - GSS_S_BAD_NAME - GSS_S_BAD_MECH - GSS_S_FAILURE - - then the client MUST abandon the algorithm and MUST NOT use the GSS- - TSIG algorithm to establish this security context. This document - does not prescribe which other mechanism could be used to establish a - security context. Next time when this client needs to establish - security context, the client MAY use GSS-TSIG algorithm. - - Success values of major_status are GSS_S_CONTINUE_NEEDED and - GSS_S_COMPLETE. The exact success code is important during later - processing. - - The values of replay_det_state and mutual_state indicate if the - security package provides replay detection and mutual authentication, - respectively. If returned major_status is GSS_S_COMPLETE AND one or - both of these values are FALSE, the client MUST abandon this - algorithm. - - Client's behavior MAY depend on other OUTPUT parameters according to - the policy local to the client. - - The handle output_context_handle is unique to this negotiation and is - stored in the client's mapping table as the context_handle that maps - to target_name. - - - - - -Kwan, et al. Standards Track [Page 7] - -RFC 3645 GSS-TSIG October 2003 - - -3.1.2. Send TKEY Query to Server - - An opaque output_token returned by GSS_Init_sec_context is - transmitted to the server in a query request with QTYPE=TKEY. The - token itself will be placed in a Key Data field of the RDATA field in - the TKEY resource record in the additional records section of the - query. The owner name of the TKEY resource record set queried for - and the owner name of the supplied TKEY resource record in the - additional records section MUST be the same. This name uniquely - identifies the security context to both the client and server, and - thus the client SHOULD use a value which is globally unique as - described in [RFC2930]. To achieve global uniqueness, the name MAY - contain a UUID/GUID [ISO11578]. - - TKEY Record - NAME = client-generated globally unique domain name string - (as described in [RFC2930]) - RDATA - Algorithm Name = gss-tsig - Mode = 3 (GSS-API negotiation - per [RFC2930]) - Key Size = size of output_token in octets - Key Data = output_token - - The remaining fields in the TKEY RDATA, i.e., Inception, Expiration, - Error, Other Size and Data Fields, MUST be set according to - [RFC2930]. - - The query is transmitted to the server. - - Note: if the original client call to GSS_Init_sec_context returned - any major_status other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE, - then the client MUST NOT send TKEY query. Client's behavior in this - case is described above in Section 3.1.1. - -3.1.3. Receive TKEY Query-Response from Server - - Upon the reception of the TKEY query the DNS server MUST respond - according to the description in Section 4. This section specifies - the behavior of the client after it receives the matching response to - its query. - - The next processing step depends on the value of major_status from - the most recent call that client performed to GSS_Init_sec_context: - either GSS_S_COMPLETE or GSS_S_CONTINUE. - - - - - - - -Kwan, et al. Standards Track [Page 8] - -RFC 3645 GSS-TSIG October 2003 - - -3.1.3.1. Value of major_status == GSS_S_COMPLETE - - If the last call to GSS_Init_sec_context yielded a major_status value - of GSS_S_COMPLETE and a non-NULL output_token was sent to the server, - then the client side component of the negotiation is complete and the - client is awaiting confirmation from the server. - - Confirmation is in the form of a query response with RCODE=NOERROR - and with the last client supplied TKEY record in the answer section - of the query. The response MUST be signed with a TSIG record. Note - that the server is allowed to sign a response to unsigned client's - query due to modification to the RFC 2845 specified in Section 2.2 - above. The signature in the TSIG record MUST be verified using the - procedure detailed in section 5, Sending and Verifying Signed - Messages. If the response is not signed, OR if the response is - signed but the signature is invalid, then an attacker has tampered - with the message in transit or has attempted to send the client a - false response. In this case, the client MAY continue waiting for a - response to its last TKEY query until the time period since the - client sent last TKEY query expires. Such a time period is specified - by the policy local to the client. This is a new option that allows - the DNS client to accept multiple answers for one query ID and select - one (not necessarily the first one) based on some criteria. - - If the signature is verified, the context state is advanced to - Context Established. Proceed to section 3.2 for usage of the - security context. - -3.1.3.2. Value of major_status == GSS_S_CONTINUE_NEEDED - - If the last call to GSS_Init_sec_context yielded a major_status value - of GSS_S_CONTINUE_NEEDED, then the negotiation is not yet complete. - The server will return to the client a query response with a TKEY - record in the Answer section. If the DNS message error is not - NO_ERROR or error field in the TKEY record is not 0 (i.e., no error), - then the client MUST abandon this negotiation sequence. The client - MUST delete an active context by calling GSS_Delete_sec_context - providing the associated context_handle. The client MAY repeat the - negotiation sequence starting with the uninitialized state as - described in section 3.1. To prevent infinite looping the number of - attempts to establish a security context MUST be limited to ten or - less. - - If the DNS message error is NO_ERROR and the error field in the TKEY - record is 0 (i.e., no error), then the client MUST pass a token - specified in the Key Data field in the TKEY resource record to - - - - - -Kwan, et al. Standards Track [Page 9] - -RFC 3645 GSS-TSIG October 2003 - - - GSS_Init_sec_context using the same parameters values as in previous - call except values for CONTEXT HANDLE input_context_handle and OCTET - STRING input_token as described below: - - INPUTS - CONTEXT HANDLE input_context_handle = context_handle (this is the - context_handle corresponding to the key_name which is the - owner name of the TKEY record in the answer section in the - TKEY query response) - - OCTET STRING input_token = token from Key field of - TKEY record - - Depending on the following OUTPUT values of GSS_Init_sec_context - - INTEGER major_status - OCTET STRING output_token - - the client MUST take one of the following actions: - - If OUTPUT major_status is set to one of the following values: - - GSS_S_DEFECTIVE_TOKEN - GSS_S_DEFECTIVE_CREDENTIAL - GSS_S_BAD_SIG (GSS_S_BAD_MIC) - GSS_S_NO_CRED - GSS_S_CREDENTIALS_EXPIRED - GSS_S_BAD_BINDINGS - GSS_S_OLD_TOKEN - GSS_S_DUPLICATE_TOKEN - GSS_S_NO_CONTEXT - GSS_S_BAD_NAMETYPE - GSS_S_BAD_NAME - GSS_S_BAD_MECH - GSS_S_FAILURE - - the client MUST abandon this negotiation sequence. This means that - the client MUST delete an active context by calling - GSS_Delete_sec_context providing the associated context_handle. The - client MAY repeat the negotiation sequence starting with the - uninitialized state as described in section 3.1. To prevent infinite - looping the number of attempts to establish a security context MUST - be limited to ten or less. - - If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE - then client MUST act as described below. - - - - - -Kwan, et al. Standards Track [Page 10] - -RFC 3645 GSS-TSIG October 2003 - - - If the response from the server was signed, and the OUTPUT - major_status is GSS_S_COMPLETE,then the signature in the TSIG record - MUST be verified using the procedure detailed in section 5, Sending - and Verifying Signed Messages. If the signature is invalid, then the - client MUST abandon this negotiation sequence. This means that the - client MUST delete an active context by calling - GSS_Delete_sec_context providing the associated context_handle. The - client MAY repeat the negotiation sequence starting with the - uninitialized state as described in section 3.1. To prevent infinite - looping the number of attempts to establish a security context MUST - be limited to ten or less. - - If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet - finished. The token output_token MUST be passed to the server in a - TKEY record by repeating the negotiation sequence beginning with - section 3.1.2. The client MUST place a limit on the number of - continuations in a context negotiation to prevent endless looping. - Such limit SHOULD NOT exceed value of 10. - - If major_status is GSS_S_COMPLETE and output_token is non-NULL, the - client-side component of the negotiation is complete but the token - output_token MUST be passed to the server by repeating the - negotiation sequence beginning with section 3.1.2. - - If major_status is GSS_S_COMPLETE and output_token is NULL, context - negotiation is complete. The context state is advanced to Context - Established. Proceed to section 3.2 for usage of the security - context. - -3.2. Context Established - - When context negotiation is complete, the handle context_handle MUST - be used for the generation and verification of transaction - signatures. - - The procedures for sending and receiving signed messages are - described in section 5, Sending and Verifying Signed Messages. - -3.2.1. Terminating a Context - - When the client is not intended to continue using the established - security context, the client SHOULD delete an active context by - calling GSS_Delete_sec_context providing the associated - context_handle, AND client SHOULD delete the established context on - the DNS server by using TKEY RR with the Mode field set to 5, i.e., - "key deletion" [RFC2930]. - - - - - -Kwan, et al. Standards Track [Page 11] - -RFC 3645 GSS-TSIG October 2003 - - -4. Server Protocol Details - - As on the client-side, the result of a successful context negotiation - is a context handle used in future generation and verification of the - transaction signatures. - - A server MAY be managing several contexts with several clients. - Clients identify their contexts by providing a key name in their - request. The server maintains a mapping of key names to handles: - - (key_name, context_handle) - -4.1. Negotiating Context - - A server MUST recognize TKEY queries as security context negotiation - messages. - -4.1.1. Receive TKEY Query from Client - - Upon receiving a query with QTYPE = TKEY, the server MUST examine - whether the Mode and Algorithm Name fields of the TKEY record in the - additional records section of the message contain values of 3 and - gss-tsig, respectively. If they do, then the (key_name, - context_handle) mapping table is searched for the key_name matching - the owner name of the TKEY record in the additional records section - of the query. If the name is found in the table and the security - context for this name is established and not expired, then the server - MUST respond to the query with BADNAME error in the TKEY error field. - If the name is found in the table and the security context is not - established, the corresponding context_handle is used in subsequent - GSS operations. If the name is found but the security context is - expired, then the server deletes this security context, as described - in Section 4.2.1, and interprets this query as a start of new - security context negotiation and performs operations described in - Section 4.1.2 and 4.1.3. If the name is not found, then the server - interprets this query as a start of new security context negotiation - and performs operations described in Section 4.1.2 and 4.1.3. - -4.1.2. Call GSS_Accept_sec_context - - The server performs its side of a context negotiation by calling - GSS_Accept_sec_context. The following input parameters MUST be used. - The outcome of the call is indicated with the output values below. - Consult Sections 2.2.2 "GSS_Accept_sec_context call" of the RFC 2743 - [RFC2743] for syntax definitions. - - - - - - -Kwan, et al. Standards Track [Page 12] - -RFC 3645 GSS-TSIG October 2003 - - - INPUTS - CONTEXT HANDLE input_context_handle = 0 if new negotiation, - context_handle matching - key_name if ongoing negotiation - OCTET STRING input_token = token specified in the Key - field from TKEY RR (from Additional records Section of - the client's query) - - CREDENTIAL HANDLE acceptor_cred_handle = NULL (NULL specifies "use - default"). Server MAY instead specify some other valid - handle to its credentials. - OCTET STRING chan_bindings = Any valid channel bindings - as specified in Section 1.1.6 "Channel Bindings" in [RFC2743] - - OUTPUTS - INTEGER major_status - CONTEXT_HANDLE output_context_handle - OCTET STRING output_token - INTEGER minor_status - INTERNAL NAME src_name - OBJECT IDENTIFIER mech_type - BOOLEAN deleg_state - BOOLEAN mutual_state - BOOLEAN replay_det_state - BOOLEAN sequence_state - BOOLEAN anon_state - BOOLEAN trans_state - BOOLEAN prot_ready_state - BOOLEAN conf_avail - BOOLEAN integ_avail - INTEGER lifetime_rec - CONTEXT_HANDLE delegated_cred_handle - - If this is the first call to GSS_Accept_sec_context in a new - negotiation, then output_context_handle is stored in the server's - key-mapping table as the context_handle that maps to the name of the - TKEY record. - -4.1.3. Send TKEY Query-Response to Client - - The server MUST respond to the client with a TKEY query response with - RCODE = NOERROR, that contains a TKEY record in the answer section. - - If OUTPUT major_status is one of the following errors the error field - in the TKEY record set to BADKEY. - - - - - - -Kwan, et al. Standards Track [Page 13] - -RFC 3645 GSS-TSIG October 2003 - - - GSS_S_DEFECTIVE_TOKEN - GSS_S_DEFECTIVE_CREDENTIAL - GSS_S_BAD_SIG (GSS_S_BAD_MIC) - GSS_S_DUPLICATE_TOKEN - GSS_S_OLD_TOKEN - GSS_S_NO_CRED - GSS_S_CREDENTIALS_EXPIRED - GSS_S_BAD_BINDINGS - GSS_S_NO_CONTEXT - GSS_S_BAD_MECH - GSS_S_FAILURE - - If OUTPUT major_status is set to GSS_S_COMPLETE or - GSS_S_CONTINUE_NEEDED then server MUST act as described below. - - If major_status is GSS_S_COMPLETE the server component of the - negotiation is finished. If output_token is non-NULL, then it MUST - be returned to the client in a Key Data field of the RDATA in TKEY. - The error field in the TKEY record is set to NOERROR. The message - MUST be signed with a TSIG record as described in section 5, Sending - and Verifying Signed Messages. Note that server is allowed to sign a - response to unsigned client's query due to modification to the RFC - 2845 specified in Section 2.2 above. The context state is advanced - to Context Established. Section 4.2 discusses the usage of the - security context. - - If major_status is GSS_S_COMPLETE and output_token is NULL, then the - TKEY record received from the client MUST be returned in the Answer - section of the response. The message MUST be signed with a TSIG - record as described in section 5, Sending and Verifying Signed - Messages. Note that server is allowed to sign a response to unsigned - client's query due to modification to the RFC 2845 specified in - section 2.2 above. The context state is advanced to Context - Established. Section 4.2 discusses the usage of the security - context. - - If major_status is GSS_S_CONTINUE_NEEDED, the server component of the - negotiation is not yet finished. The server responds to the TKEY - query with a standard query response, placing in the answer section a - TKEY record containing output_token in the Key Data RDATA field. The - error field in the TKEY record is set to NOERROR. The server MUST - limit the number of times that a given context is allowed to repeat, - to prevent endless looping. Such limit SHOULD NOT exceed value of - 10. - - - - - - - -Kwan, et al. Standards Track [Page 14] - -RFC 3645 GSS-TSIG October 2003 - - - In all cases, except if major_status is GSS_S_COMPLETE and - output_token is NULL, other TKEY record fields MUST contain the - following values: - - NAME = key_name - RDATA - Algorithm Name = gss-tsig - Mode = 3 (GSS-API negotiation - per [RFC2930]) - Key Size = size of output_token in octets - - The remaining fields in the TKEY RDATA, i.e., Inception, Expiration, - Error, Other Size and Data Fields, MUST be set according to - [RFC2930]. - -4.2. Context Established - - When context negotiation is complete, the handle context_handle is - used for the generation and verification of transaction signatures. - The handle is valid for a finite amount of time determined by the - underlying security mechanism. A server MAY unilaterally terminate a - context at any time (see section 4.2.1). - - Server SHOULD limit the amount of memory used to cache established - contexts. - - The procedures for sending and receiving signed messages are given in - section 5, Sending and Verifying Signed Messages. - -4.2.1. Terminating a Context - - A server can terminate any established context at any time. The - server MAY hint to the client that the context is being deleted by - including a TKEY RR in a response with the Mode field set to 5, i.e., - "key deletion" [RFC2930]. An active context is deleted by calling - GSS_Delete_sec_context providing the associated context_handle. - -5. Sending and Verifying Signed Messages - -5.1. Sending a Signed Message - Call GSS_GetMIC - - The procedure for sending a signature-protected message is specified - in [RFC2845]. The data to be passed to the signature routine - includes the whole DNS message with specific TSIG variables appended. - For the exact format, see [RFC2845]. For this protocol, use the - following TSIG variable values: - - - - - - -Kwan, et al. Standards Track [Page 15] - -RFC 3645 GSS-TSIG October 2003 - - - TSIG Record - NAME = key_name that identifies this context - RDATA - Algorithm Name = gss-tsig - - Assign the remaining fields in the TSIG RDATA appropriate values as - described in [RFC2845]. - - The signature is generated by calling GSS_GetMIC. The following - input parameters MUST be used. The outcome of the call is indicated - with the output values specified below. Consult Sections 2.3.1 - "GSS_GetMIC call" of the RFC 2743[RFC2743] for syntax definitions. - - INPUTS - CONTEXT HANDLE context_handle = context_handle for key_name - OCTET STRING message = outgoing message plus TSIG - variables (per [RFC2845]) - INTEGER qop_req = 0 (0 requests a default - value). Caller MAY instead specify other valid value (for - details see Section 1.2.4 in [RFC2743]) - - OUTPUTS - INTEGER major_status - INTEGER minor_status - OCTET STRING per_msg_token - - If major_status is GSS_S_COMPLETE, then signature generation - succeeded. The signature in per_msg_token is inserted into the - Signature field of the TSIG RR and the message is transmitted. - - If major_status is GSS_S_CONTEXT_EXPIRED, GSS_S_CREDENTIALS_EXPIRED - or GSS_S_FAILURE the caller MUST delete the security context, return - to the uninitialized state and SHOULD negotiate a new security - context, as described above in Section 3.1 - - If major_status is GSS_S_NO_CONTEXT, the caller MUST remove the entry - for key_name from the (target_ name, key_name, context_handle) - mapping table, return to the uninitialized state and SHOULD negotiate - a new security context, as described above in Section 3.1 - - If major_status is GSS_S_BAD_QOP, the caller SHOULD repeat the - GSS_GetMIC call with allowed QOP value. The number of such - repetitions MUST be limited to prevent infinite loops. - -5.2. Verifying a Signed Message - Call GSS_VerifyMIC - - The procedure for verifying a signature-protected message is - specified in [RFC2845]. - - - -Kwan, et al. Standards Track [Page 16] - -RFC 3645 GSS-TSIG October 2003 - - - The NAME of the TSIG record determines which context_handle maps to - the context that MUST be used to verify the signature. If the NAME - does not map to an established context, the server MUST send a - standard TSIG error response to the client indicating BADKEY in the - TSIG error field (as described in [RFC2845]). - - For the GSS algorithm, a signature is verified by using - GSS_VerifyMIC: - - INPUTS - CONTEXT HANDLE context_handle = context_handle for key_name - OCTET STRING message = incoming message plus TSIG - variables (per [RFC2845]) - OCTET STRING per_msg_token = Signature field from TSIG RR - - OUTPUTS - INTEGER major_status - INTEGER minor_status - INTEGER qop_state - - If major_status is GSS_S_COMPLETE, the signature is authentic and the - message was delivered intact. Per [RFC2845], the timer values of the - TSIG record MUST also be valid before considering the message to be - authentic. The caller MUST not act on the request or response in the - message until these checks are verified. - - When a server is processing a client request, the server MUST send a - standard TSIG error response to the client indicating BADKEY in the - TSIG error field as described in [RFC2845], if major_status is set to - one of the following values - - GSS_S_DEFECTIVE_TOKEN - GSS_S_BAD_SIG (GSS_S_BAD_MIC) - GSS_S_DUPLICATE_TOKEN - GSS_S_OLD_TOKEN - GSS_S_UNSEQ_TOKEN - GSS_S_GAP_TOKEN - GSS_S_CONTEXT_EXPIRED - GSS_S_NO_CONTEXT - GSS_S_FAILURE - - If the timer values of the TSIG record are invalid, the message MUST - NOT be considered authentic. If this error checking fails when a - server is processing a client request, the appropriate error response - MUST be sent to the client according to [RFC2845]. - - - - - - -Kwan, et al. Standards Track [Page 17] - -RFC 3645 GSS-TSIG October 2003 - - -6. Example usage of GSS-TSIG algorithm - - This Section describes an example where a Client, client.example.com, - and a Server, server.example.com, establish a security context - according to the algorithm described above. - - I. Client initializes security context negotiation - - To establish a security context with a server, server.example.com, the - Client calls GSS_Init_sec_context with the following parameters. - (Note that some INPUT and OUTPUT parameters not critical for this - algorithm are not described in this example.) - - CONTEXT HANDLE input_context_handle = 0 - INTERNAL NAME targ_name = "DNS@server.example.com" - OCTET STRING input_token = NULL - BOOLEAN replay_det_req_flag = TRUE - BOOLEAN mutual_req_flag = TRUE - - The OUTPUTS parameters returned by GSS_Init_sec_context include - INTEGER major_status = GSS_S_CONTINUE_NEEDED - CONTEXT HANDLE output_context_handle context_handle - OCTET STRING output_token output_token - BOOLEAN replay_det_state = TRUE - BOOLEAN mutual_state = TRUE - - Client verifies that replay_det_state and mutual_state values are - TRUE. Since the major_status is GSS_S_CONTINUE_NEEDED, which is a - success OUTPUT major_status value, client stores context_handle that - maps to "DNS@server.example.com" and proceeds to the next step. - - II. Client sends a query with QTYPE = TKEY to server - - Client sends a query with QTYPE = TKEY for a client-generated globally - unique domain name string, 789.client.example.com.server.example.com. - Query contains a TKEY record in its Additional records section with - the following fields. (Note that some fields not specific to this - algorithm are not specified.) - - NAME = 789.client.example.com.server.example.com. - RDATA - Algorithm Name = gss-tsig - Mode = 3 (GSS-API negotiation - per [RFC2930]) - Key Size = size of output_token in octets - Key Data = output_token - - - - - - -Kwan, et al. Standards Track [Page 18] - -RFC 3645 GSS-TSIG October 2003 - - - After the key_name 789.client.example.com.server.example.com. - is generated it is stored in the client's (target_name, key_name, - context_handle) mapping table. - - III. Server receives a query with QTYPE = TKEY - - When server receives a query with QTYPE = TKEY, the server verifies - that Mode and Algorithm fields in the TKEY record in the Additional - records section of the query are set to 3 and "gss-tsig" respectively. - It finds that the key_name 789.client.example.com.server.example.com. - is not listed in its (key_name, context_handle) mapping table. - - IV. Server calls GSS_Accept_sec_context - - To continue security context negotiation server calls - GSS_Accept_sec_context with the following parameters. (Note that - some INPUT and OUTPUT parameters not critical for this algorithm - are not described in this example.) - - INPUTS - CONTEXT HANDLE input_context_handle = 0 - OCTET STRING input_token = token specified in the Key - field from TKEY RR (from Additional - records section of the client's query) - - The OUTPUTS parameters returned by GSS_Accept_sec_context include - INTEGER major_status = GSS_S_CONTINUE_NEEDED - CONTEXT_HANDLE output_context_handle context_handle - OCTET STRING output_token output_token - - Server stores the mapping of the - 789.client.example.com.server.example.com. to OUTPUT context_handle - in its (key_name, context_handle) mapping table. - - V. Server responds to the TKEY query - - Since the major_status = GSS_S_CONTINUE_NEEDED in the last server's - call to GSS_Accept_sec_context, the server responds to the TKEY query - placing in the answer section a TKEY record containing output_token in - the Key Data RDATA field. The error field in the TKEY record is set - to 0. The RCODE in the query response is set to NOERROR. - - VI. Client processes token returned by server - - When the client receives the TKEY query response from the server, the - client calls GSS_Init_sec_context with the following parameters. - (Note that some INPUT and OUTPUT parameters not critical for this - algorithm are not described in this example.) - - - -Kwan, et al. Standards Track [Page 19] - -RFC 3645 GSS-TSIG October 2003 - - - CONTEXT HANDLE input_context_handle = the context_handle stored - in the client's mapping table entry (DNS@server.example.com., - 789.client.example.com.server.example.com., context_handle) - INTERNAL NAME targ_name = "DNS@server.example.com" - OCTET STRING input_token = token from Key field of TKEY - record from the Answer section of the server's response - BOOLEAN replay_det_req_flag = TRUE - BOOLEAN mutual_req_flag = TRUE - - The OUTPUTS parameters returned by GSS_Init_sec_context include - INTEGER major_status = GSS_S_COMPLETE - CONTEXT HANDLE output_context_handle = context_handle - OCTET STRING output_token = output_token - BOOLEAN replay_det_state = TRUE - BOOLEAN mutual_state = TRUE - - Since the major_status is set to GSS_S_COMPLETE the client side - security context is established, but since the output_token is not - NULL client MUST send a TKEY query to the server as described below. - - VII. Client sends a query with QTYPE = TKEY to server - - Client sends to the server a TKEY query for the - 789.client.example.com.server.example.com. name. Query contains a - TKEY record in its Additional records section with the following - fields. (Note that some INPUT and OUTPUT parameters not critical to - this algorithm are not described in this example.) - - NAME = 789.client.example.com.server.example.com. - RDATA - Algorithm Name = gss-tsig - Mode = 3 (GSS-API negotiation - per [RFC2930]) - Key Size = size of output_token in octets - Key Data = output_token - - VIII. Server receives a TKEY query - - When the server receives a TKEY query, the server verifies that Mode - and Algorithm fields in the TKEY record in the Additional records - section of the query are set to 3 and gss-tsig, respectively. It - finds that the key_name 789.client.example.com.server.example.com. is - listed in its (key_name, context_handle) mapping table. - - - - - - - - - -Kwan, et al. Standards Track [Page 20] - -RFC 3645 GSS-TSIG October 2003 - - - IX. Server calls GSS_Accept_sec_context - - To continue security context negotiation server calls - GSS_Accept_sec_context with the following parameters (Note that some - INPUT and OUTPUT parameters not critical for this algorithm are not - described in this example) - - INPUTS - CONTEXT HANDLE input_context_handle = context_handle from the - (789.client.example.com.server.example.com., context_handle) - entry in the server's mapping table - OCTET STRING input_token = token specified in the Key - field of TKEY RR (from Additional records Section of - the client's query) - - The OUTPUTS parameters returned by GSS_Accept_sec_context include - INTEGER major_status = GSS_S_COMPLETE - CONTEXT_HANDLE output_context_handle = context_handle - OCTET STRING output_token = NULL - - Since major_status = GSS_S_COMPLETE, the security context on the - server side is established, but the server still needs to respond to - the client's TKEY query, as described below. The security context - state is advanced to Context Established. - - X. Server responds to the TKEY query - - Since the major_status = GSS_S_COMPLETE in the last server's call to - GSS_Accept_sec_context and the output_token is NULL, the server - responds to the TKEY query placing in the answer section a TKEY record - that was sent by the client in the Additional records section of the - client's latest TKEY query. In addition, this server places a - TSIG record in additional records section of its response. Server - calls GSS_GetMIC to generate a signature to include it in the TSIG - record. The server specifies the following GSS_GetMIC INPUT - parameters: - - CONTEXT HANDLE context_handle = context_handle from the - (789.client.example.com.server.example.com., context_handle) - entry in the server's mapping table - OCTET STRING message = outgoing message plus TSIG - variables (as described in [RFC2845]) - - The OUTPUTS parameters returned by GSS_GetMIC include - INTEGER major_status = GSS_S_COMPLETE - OCTET STRING per_msg_token - - Signature field in the TSIG record is set to per_msg_token. - - - -Kwan, et al. Standards Track [Page 21] - -RFC 3645 GSS-TSIG October 2003 - - - XI. Client processes token returned by server - - Client receives the TKEY query response from the server. Since the - major_status was GSS_S_COMPLETE in the last client's call to - GSS_Init_sec_context, the client verifies that the server's response - is signed. To validate the signature, the client calls - GSS_VerifyMIC with the following parameters: - - INPUTS - CONTEXT HANDLE context_handle = context_handle for - 789.client.example.com.server.example.com. key_name - OCTET STRING message = incoming message plus TSIG - variables (as described in [RFC2845]) - OCTET STRING per_msg_token = Signature field from TSIG RR - included in the server's query response - - Since the OUTPUTS parameter major_status = GSS_S_COMPLETE, the - signature is validated, security negotiation is complete and the - security context state is advanced to Context Established. These - client and server will use the established security context to sign - and validate the signatures when they exchange packets with each - other until the context expires. - -7. Security Considerations - - This document describes a protocol for DNS security using GSS-API. - The security provided by this protocol is only as effective as the - security provided by the underlying GSS mechanisms. - - All the security considerations from RFC 2845, RFC 2930 and RFC 2743 - apply to the protocol described in this document. - -8. IANA Considerations - - The IANA has reserved the TSIG Algorithm name gss-tsig for the use in - the Algorithm fields of TKEY and TSIG resource records. This - Algorithm name refers to the algorithm described in this document. - The requirement to have this name registered with IANA is specified - in RFC 2845. - -9. Conformance - - The GSS API using SPNEGO [RFC2478] provides maximum flexibility to - choose the underlying security mechanisms that enables security - context negotiation. GSS API using SPNEGO [RFC2478] enables client - and server to negotiate and choose such underlying security - mechanisms on the fly. To support such flexibility, DNS clients and - servers SHOULD specify SPNEGO mech_type in their GSS API calls. At - - - -Kwan, et al. Standards Track [Page 22] - -RFC 3645 GSS-TSIG October 2003 - - - the same time, in order to guarantee interoperability between DNS - clients and servers that support GSS-TSIG it is required that - - - DNS servers specify SPNEGO mech_type - - GSS APIs called by DNS client support Kerberos v5 - - GSS APIs called by DNS server support SPNEGO [RFC2478] and - Kerberos v5. - - In addition to these, GSS APIs used by DNS client and server MAY also - support other underlying security mechanisms. - -10. Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - -11. Acknowledgements - - The authors of this document would like to thank the following people - for their contribution to this specification: Chuck Chan, Mike - Swift, Ram Viswanathan, Olafur Gudmundsson, Donald E. Eastlake, 3rd - and Erik Nordmark. - - - - - - - - - - - - -Kwan, et al. Standards Track [Page 23] - -RFC 3645 GSS-TSIG October 2003 - - -12. References - -12.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API - Negotiation Mechanism", RFC 2478, December 1998. - - [RFC2743] Linn, J., "Generic Security Service Application Program - Interface, Version 2 , Update 1", RFC 2743, January 2000. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - -12.2. Informative References - - - [ISO11578] "Information technology", "Open Systems Interconnection", - "Remote Procedure Call", ISO/IEC 11578:1996, - http://www.iso.ch/cate/d2229.html. - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1034, November 1987. - - [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC - 1964, June 1996. - - [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism - (SPKM)", RFC 2025, October 1996. - - [RFC2137] Eastlake 3rd, D., "Secure Domain Name System Dynamic - Update", RFC 2137, April 1997. - - [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - - - - - - -Kwan, et al. Standards Track [Page 24] - -RFC 3645 GSS-TSIG October 2003 - - -13. Authors' Addresses - - Stuart Kwan - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - USA - EMail: skwan@microsoft.com - - Praerit Garg - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - USA - EMail: praeritg@microsoft.com - - James Gilroy - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - USA - EMail: jamesg@microsoft.com - - Levon Esibov - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - USA - EMail: levone@microsoft.com - - Randy Hall - Lucent Technologies - 400 Lapp Road - Malvern PA 19355 - USA - EMail: randyhall@lucent.com - - Jeff Westhead - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - USA - EMail: jwesth@microsoft.com - - - - - - - - -Kwan, et al. Standards Track [Page 25] - -RFC 3645 GSS-TSIG October 2003 - - -14. Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Kwan, et al. Standards Track [Page 26] - diff --git a/contrib/bind9/doc/rfc/rfc3655.txt b/contrib/bind9/doc/rfc/rfc3655.txt deleted file mode 100644 index 13e586bad0d7..000000000000 --- a/contrib/bind9/doc/rfc/rfc3655.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -Network Working Group B. Wellington -Request for Comments: 3655 O. Gudmundsson -Updates: 2535 November 2003 -Category: Standards Track - - - Redefinition of DNS Authenticated Data (AD) bit - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - This document alters the specification defined in RFC 2535. Based on - implementation experience, the Authenticated Data (AD) bit in the DNS - header is not useful. This document redefines the AD bit such that - it is only set if all answers or records proving that no answers - exist in the response has been cryptographically verified or - otherwise meets the server's local security policy. - -1. Introduction - - Familiarity with the DNS system [RFC1035] and DNS security extensions - [RFC2535] is helpful but not necessary. - - As specified in RFC 2535 (section 6.1), the AD (Authenticated Data) - bit indicates in a response that all data included in the answer and - authority sections of the response have been authenticated by the - server according to the policies of that server. This is not - especially useful in practice, since a conformant server SHOULD never - reply with data that failed its security policy. - - This document redefines the AD bit such that it is only set if all - data in the response has been cryptographically verified or otherwise - meets the server's local security policy. Thus, neither a response - containing properly delegated insecure data, nor a server configured - without DNSSEC keys, will have the AD set. As before, data that - failed to verify will not be returned. An application running on a - host that has a trust relationship with the server performing the - - - -Wellington & Gudmundsson Standards Track [Page 1] - -RFC 3655 Redefinition of DNS AD bit November 2003 - - - recursive query can now use the value of the AD bit to determine - whether the data is secure. - -1.1. Motivation - - A full DNSSEC capable resolver called directly from an application - can return to the application the security status of the RRsets in - the answer. However, most applications use a limited stub resolver - that relies on an external recursive name server which incorporates a - full resolver. The recursive nameserver can use the AD bit in a - response to indicate the security status of the data in the answer, - and the local resolver can pass this information to the application. - The application in this context can be either a human using a DNS - tool or a software application. - - The AD bit SHOULD be used by the local resolver if and only if it has - been explicitly configured to trust the remote resolver. The AD bit - SHOULD be ignored when the recursive name server is not trusted. - - An alternate solution would be to embed a full DNSSEC resolver into - every application, but this has several disadvantages. - - - DNSSEC validation is both CPU and network intensive, and caching - SHOULD be used whenever possible. - - - DNSSEC requires non-trivial configuration - the root key must be - configured, as well as keys for any "islands of security" that - will exist until DNSSEC is fully deployed. The number of - configuration points should be minimized. - -1.2. Requirements - - The key words "MAY", "MAY NOT" "MUST", "MUST NOT", "SHOULD", "SHOULD - NOT", "RECOMMENDED", in this document are to be interpreted as - described in BCP 14, RFC 2119 [RFC2119]. - -1.3. Updated documents and sections - - The definition of the AD bit in RFC 2535, Section 6.1, is changed. - -2. Setting of AD bit - - The presence of the CD (Checking Disabled) bit in a query does not - affect the setting of the AD bit in the response. If the CD bit is - set, the server will not perform checking, but SHOULD still set the - AD bit if the data has already been cryptographically verified or - - - - - -Wellington & Gudmundsson Standards Track [Page 2] - -RFC 3655 Redefinition of DNS AD bit November 2003 - - - complies with local policy. The AD bit MUST only be set if DNSSEC - records have been requested via the DO bit [RFC3225] and relevant SIG - records are returned. - -2.1. Setting of AD bit by recursive servers - - Section 6.1 of RFC 2535 says: - - "The AD bit MUST NOT be set on a response unless all of the RRs in - the answer and authority sections of the response are either - Authenticated or Insecure." - - The replacement text reads: - - "The AD bit MUST NOT be set on a response unless all of the RRsets in - the answer and authority sections of the response are Authenticated." - - "The AD bit SHOULD be set if and only if all RRs in the answer - section and any relevant negative response RRs in the authority - section are Authenticated." - - A recursive DNS server following this modified specification will - only set the AD bit when it has cryptographically verified the data - in the answer. - -2.2. Setting of AD bit by authoritative servers - - A primary server for a secure zone MAY have the policy of treating - authoritative secure zones as Authenticated. Secondary servers MAY - have the same policy, but SHOULD NOT consider zone data Authenticated - unless the zone was transferred securely and/or the data was - verified. An authoritative server MUST only set the AD bit for - authoritative answers from a secure zone if it has been explicitly - configured to do so. The default for this behavior SHOULD be off. - - Note that having the AD bit clear on an authoritative answer is - normal and expected behavior. - -2.2.1. Justification for setting AD bit w/o verifying data - - The setting of the AD bit by authoritative servers affects only the - small set of resolvers that are configured to directly query and - trust authoritative servers. This only affects servers that function - as both recursive and authoritative. Iterative resolvers SHOULD - ignore the AD bit. - - The cost of verifying all signatures on load by an authoritative - server can be high and increases the delay before it can begin - - - -Wellington & Gudmundsson Standards Track [Page 3] - -RFC 3655 Redefinition of DNS AD bit November 2003 - - - answering queries. Verifying signatures at query time is also - expensive and could lead to resolvers timing out on many queries - after the server reloads zones. - - Organizations requiring that all DNS responses contain - cryptographically verified data will need to separate the - authoritative name server and signature verification functions, since - name servers are not required to validate signatures of data for - which they are authoritative. - -3. Interpretation of the AD bit - - A response containing data marked Insecure in the answer or authority - section MUST never have the AD bit set. In this case, the resolver - SHOULD treat the data as Insecure whether or not SIG records are - present. - - A resolver MUST NOT blindly trust the AD bit unless it communicates - with a recursive nameserver over a secure transport mechanism or - using a message authentication such as TSIG [RFC2845] or SIG(0) - [RFC2931] and is explicitly configured to trust this recursive name - server. - -4. Applicability statement - - The AD bit is intended to allow the transmission of the indication - that a resolver has verified the DNSSEC signatures accompanying the - records in the Answer and Authority section. The AD bit MUST only be - trusted when the end consumer of the DNS data has confidence that the - intermediary resolver setting the AD bit is trustworthy. This can - only be accomplished via an out of band mechanism such as: - - - Fiat: An organization that can dictate whether it is OK to trust - certain DNS servers. - - - Personal: Because of a personal relationship or the reputation of - a recursive nameserver operator, a DNS consumer can decide to - trust that recursive nameserver. - - - Knowledge: If a recursive nameserver operator posts the configured - policy of a recursive nameserver, a consumer can decide that - recursive nameserver is trustworthy. - - In the absence of one or more of these factors AD bit from a - recursive name server SHOULD NOT be trusted. For example, home users - frequently depend on their ISP to provide recursive DNS service; it - - - - - -Wellington & Gudmundsson Standards Track [Page 4] - -RFC 3655 Redefinition of DNS AD bit November 2003 - - - is not advisable to trust these recursive nameservers. A - roaming/traveling host SHOULD not use recursive DNS servers offered - by DHCP when looking up information where security status matters. - - In the latter two cases, the end consumer must also completely trust - the path to the trusted recursive name servers, or a secure transport - must be employed to protect the traffic. - - When faced with a situation where there are no satisfactory recursive - nameservers available, running one locally is RECOMMENDED. This has - the advantage that it can be trusted, and the AD bit can still be - used to allow applications to use stub resolvers. - -5. Security Considerations - - This document redefines a bit in the DNS header. If a resolver - trusts the value of the AD bit, it must be sure that the responder is - using the updated definition, which is any DNS server/resolver - supporting the DO bit [RFC3225]. - - Authoritative servers can be explicitly configured to set the AD bit - on answers without doing cryptographic checks. This behavior MUST be - off by default. The only affected resolvers are those that directly - query and trust the authoritative server, and this functionality - SHOULD only be used on servers that act both as authoritative and - recursive name servers. - - Resolvers (full or stub) that blindly trust the AD bit without - knowing the security policy of the server generating the answer can - not be considered security aware. - - A resolver MUST NOT blindly trust the AD bit unless it communicates - such as IPsec, or using message authentication such as TSIG [RFC2845] - or SIG(0) [RFC2931]. In addition, the resolver must have been - explicitly configured to trust this recursive name server. - -6. IANA Considerations - - None. - -7. Internationalization Considerations - - None. This document does not change any textual data in any - protocol. - - - - - - - -Wellington & Gudmundsson Standards Track [Page 5] - -RFC 3655 Redefinition of DNS AD bit November 2003 - - -8. Intellectual Property Rights Notice - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - -9. Acknowledgments - - The following people have provided input on this document: Robert - Elz, Andreas Gustafsson, Bob Halley, Steven Jacob, Erik Nordmark, - Edward Lewis, Jakob Schlyter, Roy Arends, Ted Lindgreen. - -10. Normative References - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures - (SIG(0))", RFC 2931, September 2000. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC - 3225, December 2001. - - - -Wellington & Gudmundsson Standards Track [Page 6] - -RFC 3655 Redefinition of DNS AD bit November 2003 - - -11. Authors' Addresses - - Brian Wellington - Nominum Inc. - 2385 Bay Road - Redwood City, CA, 94063 - USA - - EMail: Brian.Wellington@nominum.com - - - Olafur Gudmundsson - 3821 Village Park Drive - Chevy Chase, MD, 20815 - USA - - EMail: ogud@ogud.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Wellington & Gudmundsson Standards Track [Page 7] - -RFC 3655 Redefinition of DNS AD bit November 2003 - - -12. Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Wellington & Gudmundsson Standards Track [Page 8] - diff --git a/contrib/bind9/doc/rfc/rfc3658.txt b/contrib/bind9/doc/rfc/rfc3658.txt deleted file mode 100644 index 88cfb5af2425..000000000000 --- a/contrib/bind9/doc/rfc/rfc3658.txt +++ /dev/null @@ -1,1067 +0,0 @@ - - - - - - -Network Working Group O. Gudmundsson -Request for Comments: 3658 December 2003 -Updates: 3090, 3008, 2535, 1035 -Category: Standards Track - - - Delegation Signer (DS) Resource Record (RR) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - The delegation signer (DS) resource record (RR) is inserted at a zone - cut (i.e., a delegation point) to indicate that the delegated zone is - digitally signed and that the delegated zone recognizes the indicated - key as a valid zone key for the delegated zone. The DS RR is a - modification to the DNS Security Extensions definition, motivated by - operational considerations. The intent is to use this resource - record as an explicit statement about the delegation, rather than - relying on inference. - - This document defines the DS RR, gives examples of how it is used and - describes the implications on resolvers. This change is not - backwards compatible with RFC 2535. This document updates RFC 1035, - RFC 2535, RFC 3008 and RFC 3090. - - - - - - - - - - - - - - - - -Gudmundsson Standards Track [Page 1] - -RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 - - -Table of Contents - - 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.2. Reserved Words. . . . . . . . . . . . . . . . . . . . . 4 - 2. Specification of the Delegation key Signer. . . . . . . . . . 4 - 2.1. Delegation Signer Record Model. . . . . . . . . . . . . 4 - 2.2. Protocol Change . . . . . . . . . . . . . . . . . . . . 5 - 2.2.1. RFC 2535 2.3.4 and 3.4: Special Considerations - at Delegation Points . . . . . . . . . . . . . 6 - 2.2.1.1. Special processing for DS queries. . . 6 - 2.2.1.2. Special processing when child and an - ancestor share nameserver. . . . . . . 7 - 2.2.1.3. Modification on use of KEY RR in the - construction of Responses. . . . . . . 8 - 2.2.2. Signer's Name (replaces RFC3008 section 2.7). . 9 - 2.2.3. Changes to RFC 3090 . . . . . . . . . . . . . . 9 - 2.2.3.1. RFC 3090: Updates to section 1: - Introduction . . . . . . . . . . . . . 9 - 2.2.3.2. RFC 3090 section 2.1: Globally - Secured. . . . . . . . . . . . . . . . 10 - 2.2.3.3. RFC 3090 section 3: Experimental - Status . . . . . . . . . . . . . . . . 10 - 2.2.4. NULL KEY elimination. . . . . . . . . . . . . . 10 - 2.3. Comments on Protocol Changes. . . . . . . . . . . . . . 10 - 2.4. Wire Format of the DS record. . . . . . . . . . . . . . 11 - 2.4.1. Justifications for Fields . . . . . . . . . . . 12 - 2.5. Presentation Format of the DS Record. . . . . . . . . . 12 - 2.6. Transition Issues for Installed Base. . . . . . . . . . 12 - 2.6.1. Backwards compatibility with RFC 2535 and - RFC 1035. . . . . . . . . . . . . . . . . . . . 12 - 2.7. KEY and corresponding DS record example . . . . . . . . 13 - 3. Resolver. . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 3.1. DS Example" . . . . . . . . . . . . . . . . . . . . . . 14 - 3.2. Resolver Cost Estimates for DS Records" . . . . . . . . 15 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 6. Intellectual Property Statement . . . . . . . . . . . . . . . 16 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 - 8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 8.1. Normative References. . . . . . . . . . . . . . . . . . 17 - 8.2. Informational References. . . . . . . . . . . . . . . . 17 - 9. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 18 - 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19 - - - - - - - - -Gudmundsson Standards Track [Page 2] - -RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 - - -1. Introduction - - Familiarity with the DNS system [RFC1035], DNS security extensions - [RFC2535], and DNSSEC terminology [RFC3090] is important. - - Experience shows that when the same data can reside in two - administratively different DNS zones, the data frequently gets out of - sync. The presence of an NS RRset in a zone anywhere other than at - the apex indicates a zone cut or delegation. The RDATA of the NS - RRset specifies the authoritative nameservers for the delegated or - "child" zone. Based on actual measurements, 10-30% of all - delegations on the Internet have differing NS RRsets at parent and - child. There are a number of reasons for this, including a lack of - communication between parent and child and bogus name servers being - listed to meet registry requirements. - - DNSSEC [RFC2535, RFC3008, RFC3090] specifies that a child zone needs - to have its KEY RRset signed by its parent to create a verifiable - chain of KEYs. There has been some debate on where the signed KEY - RRset should reside, whether at the child [RFC2535] or at the parent. - If the KEY RRset resides at the child, maintaining the signed KEY - RRset in the child requires frequent two-way communication between - the two parties. First, the child transmits the KEY RRset to the - parent and then the parent sends the signature(s) to the child. - Storing the KEY RRset at the parent was thought to simplify the - communication. - - DNSSEC [RFC2535] requires that the parent store a NULL KEY record for - an unsecure child zone to indicate that the child is unsecure. A - NULL KEY record is a waste: an entire signed RRset is used to - communicate effectively one bit of information - that the child is - unsecure. Chasing down NULL KEY RRsets complicates the resolution - process in many cases, because nameservers for both parent and child - need to be queried for the KEY RRset if the child nameserver does not - return it. Storing the KEY RRset only in the parent zone simplifies - this and would allow the elimination of the NULL KEY RRsets entirely. - For large delegation zones, the cost of NULL keys is a significant - barrier to deployment. - - Prior to the restrictions imposed by RFC 3445 [RFC3445], another - implication of the DNSSEC key model is that the KEY record could be - used to store public keys for other protocols in addition to DNSSEC - keys. There are a number of potential problems with this, including: - - 1. The KEY RRset can become quite large if many applications and - protocols store their keys at the zone apex. Possible protocols - are IPSEC, HTTP, SMTP, SSH and others that use public key - cryptography. - - - -Gudmundsson Standards Track [Page 3] - -RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 - - - 2. The KEY RRset may require frequent updates. - - 3. The probability of compromised or lost keys, which trigger - emergency key roll-over procedures, increases. - - 4. The parent may refuse to sign KEY RRsets with non-DNSSEC zone - keys. - - 5. The parent may not meet the child's expectations of turnaround - time for resigning the KEY RRset. - - Given these reasons, SIG@parent isn't any better than SIG/KEY@Child. - -1.2. Reserved Words - - The key words "MAY", "MAY NOT", "MUST", "MUST NOT", "REQUIRED", - "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be - interpreted as described in BCP 14, RFC 2119 [RFC2119]. - -2. Specification of the Delegation key Signer - - This section defines the Delegation Signer (DS) RR type (type code - 43) and the changes to DNS to accommodate it. - -2.1. Delegation Signer Record Model - - This document presents a replacement for the DNSSEC KEY record chain - of trust [RFC2535] that uses a new RR that resides only at the - parent. This record identifies the key(s) that the child uses to - self-sign its own KEY RRset. - - Even though DS identifies two roles for KEYs, Key Signing Key (KSK) - and Zone Signing Key (ZSK), there is no requirement that zone uses - two different keys for these roles. It is expected that many small - zones will only use one key, while larger zones will be more likely - to use multiple keys. - - The chain of trust is now established by verifying the parent KEY - RRset, the DS RRset from the parent and the KEY RRset at the child. - This is cryptographically equivalent to using just KEY records. - - Communication between the parent and child is greatly reduced, since - the child only needs to notify the parent about changes in keys that - sign its apex KEY RRset. The parent is ignorant of all other keys in - the child's apex KEY RRset. Furthermore, the child maintains full - control over the apex KEY RRset and its content. The child can - maintain any policies regarding its KEY usage for DNSSEC with minimal - impact on the parent. Thus, if the child wants to have frequent key - - - -Gudmundsson Standards Track [Page 4] - -RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 - - - roll-over for its DNS zone keys, the parent does not need to be aware - of it. The child can use one key to sign only its apex KEY RRset and - a different key to sign the other RRsets in the zone. - - This model fits well with a slow roll out of DNSSEC and the islands - of security model. In this model, someone who trusts "good.example." - can preconfigure a key from "good.example." as a trusted key, and - from then on trusts any data signed by that key or that has a chain - of trust to that key. If "example." starts advertising DS records, - "good.example." does not have to change operations by suspending - self-signing. DS records can be used in configuration files to - identify trusted keys instead of KEY records. Another significant - advantage is that the amount of information stored in large - delegation zones is reduced: rather than the NULL KEY record at every - unsecure delegation demanded by RFC 2535, only secure delegations - require additional information in the form of a signed DS RRset. - - The main disadvantage of this approach is that verifying a zone's KEY - RRset requires two signature verification operations instead of the - one in RFC 2535 chain of trust. There is no impact on the number of - signatures verified for other types of RRsets. - -2.2. Protocol Change - - All DNS servers and resolvers that support DS MUST support the OK bit - [RFC3225] and a larger message size [RFC3226]. In order for a - delegation to be considered secure the delegation MUST contain a DS - RRset. If a query contains the OK bit, a nameserver returning a - referral for the delegation MUST include the following RRsets in the - authority section in this order: - - If DS RRset is present: - parent's copy of child's NS RRset - DS and SIG(DS) - - If no DS RRset is present: - parent's copy of child's NS RRset - parent's zone NXT and SIG(NXT) - - This increases the size of referral messages, possibly causing some - or all glue to be omitted. If the DS or NXT RRsets with signatures - do not fit in the DNS message, the TC bit MUST be set. Additional - section processing is not changed. - - A DS RRset accompanying a NS RRset indicates that the child zone is - secure. If a NS RRset exists without a DS RRset, the child zone is - unsecure (from the parents point of view). DS RRsets MUST NOT appear - at non-delegation points or at a zone's apex. - - - -Gudmundsson Standards Track [Page 5] - -RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 - - - Section 2.2.1 defines special considerations related to authoritative - nameservers responding to DS queries and replaces RFC 2535 sections - 2.3.4 and 3.4. Section 2.2.2 replaces RFC 3008 section 2.7, and - section 2.2.3 updates RFC 3090. - -2.2.1. RFC 2535 2.3.4 and 3.4: Special Considerations at Delegation - Points - - DNS security views each zone as a unit of data completely under the - control of the zone owner with each entry (RRset) signed by a special - private key held by the zone manager. But the DNS protocol views the - leaf nodes in a zone that are also the apex nodes of a child zone - (i.e., delegation points) as "really" belonging to the child zone. - The corresponding domain names appear in two master files and might - have RRsets signed by both the parent and child zones' keys. A - retrieval could get a mixture of these RRsets and SIGs, especially - since one nameserver could be serving both the zone above and below a - delegation point [RFC2181]. - - Each DS RRset stored in the parent zone MUST be signed by at least - one of the parent zone's private keys. The parent zone MUST NOT - contain a KEY RRset at any delegation point. Delegations in the - parent MAY contain only the following RR types: NS, DS, NXT and SIG. - The NS RRset MUST NOT be signed. The NXT RRset is the exceptional - case: it will always appear differently and authoritatively in both - the parent and child zones, if both are secure. - - A secure zone MUST contain a self-signed KEY RRset at its apex. Upon - verifying the DS RRset from the parent, a resolver MAY trust any KEY - identified in the DS RRset as a valid signer of the child's apex KEY - RRset. Resolvers configured to trust one of the keys signing the KEY - RRset MAY now treat any data signed by the zone keys in the KEY RRset - as secure. In all other cases, resolvers MUST consider the zone - unsecure. - - An authoritative nameserver queried for type DS MUST return the DS - RRset in the answer section. - -2.2.1.1. Special processing for DS queries - - When a nameserver is authoritative for the parent zone at a - delegation point and receives a query for the DS record at that name, - it MUST answer based on data in the parent zone, return DS or - negative answer. This is true whether or not it is also - authoritative for the child zone. - - - - - - -Gudmundsson Standards Track [Page 6] - -RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 - - - When the nameserver is authoritative for the child zone at a - delegation point but not the parent zone, there is no natural - response, since the child zone is not authoritative for the DS record - at the zone's apex. As these queries are only expected to originate - from recursive nameservers which are not DS-aware, the authoritative - nameserver MUST answer with: - - RCODE: NOERROR - AA bit: set - Answer Section: Empty - Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)] - - That is, it answers as if it is authoritative and the DS record does - not exist. DS-aware recursive nameservers will query the parent zone - at delegation points, so will not be affected by this. - - A nameserver authoritative for only the child zone, that is also a - caching server MAY (if the RD bit is set in the query) perform - recursion to find the DS record at the delegation point, or MAY - return the DS record from its cache. In this case, the AA bit MUST - NOT be set in the response. - -2.2.1.2. Special processing when child and an ancestor share - nameserver - - Special rules are needed to permit DS RR aware nameservers to - gracefully interact with older caches which otherwise might falsely - label a nameserver as lame because of the placement of the DS RR set. - - Such a situation might arise when a nameserver is authoritative for - both a zone and it's grandparent, but not the parent. This sounds - like an obscure example, but it is very real. The root zone is - currently served on 13 machines, and "root-servers.net." is served on - 4 of the 13, but "net." is severed on different nameservers. - - When a nameserver receives a query for (<QNAME>, DS, <QCLASS>), the - response MUST be determined from reading these rules in order: - - 1) If the nameserver is authoritative for the zone that holds the DS - RR set (i.e., the zone that delegates <QNAME>, a.k.a. the "parent" - zone), the response contains the DS RR set as an authoritative - answer. - - 2) If the nameserver is offering recursive service and the RD bit is - set in the query, the nameserver performs the query itself - (according to the rules for resolvers described below) and returns - its findings. - - - - -Gudmundsson Standards Track [Page 7] - -RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 - - - 3) If the nameserver is authoritative for the zone that holds the - <QNAME>'s SOA RR set, the response is an authoritative negative - answer as described in 2.2.1.1. - - 4) If the nameserver is authoritative for a zone or zones above the - QNAME, a referral to the most enclosing (deepest match) zone's - servers is made. - - 5) If the nameserver is not authoritative for any part of the QNAME, - a response indicating a lame nameserver for QNAME is given. - - Using these rules will require some special processing on the part of - a DS RR aware resolver. To illustrate this, an example is used. - - Assuming a nameserver is authoritative for roots.example.net. and for - the root zone but not the intervening two zones (or the intervening - two label deep zone). Assume that QNAME=roots.example.net., - QTYPE=DS, and QCLASS=IN. - - The resolver will issue this request (assuming no cached data) - expecting a referral to a nameserver for .net. Instead, rule number - 3 above applies and a negative answer is returned by the nameserver. - The reaction by the resolver is not to accept this answer as final, - as it can determine from the SOA RR in the negative answer the - context within which the nameserver has answered. - - A solution would be to instruct the resolver to hunt for the - authoritative zone of the data in a brute force manner. - - This can be accomplished by taking the owner name of the returned SOA - RR and striping off enough left-hand labels until a successful NS - response is obtained. A successful response here means that the - answer has NS records in it. (Entertaining the possibility that a - cut point can be two labels down in a zone.) - - Returning to the example, the response will include a negative answer - with either the SOA RR for "roots.example.net." or "example.net." - depending on whether roots.example.net is a delegated domain. In - either case, removing the left most label of the SOA owner name will - lead to the location of the desired data. - -2.2.1.3. Modification on use of KEY RR in the construction of Responses - - This section updates RFC 2535 section 3.5 by replacing it with the - following: - - - - - - -Gudmundsson Standards Track [Page 8] - -RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 - - - A query for KEY RR MUST NOT trigger any additional section - processing. Security aware resolvers will include corresponding SIG - records in the answer section. - - KEY records SHOULD NOT be added to the additional records section in - response to any query. - - RFC 2535 specified that KEY records be added to the additional - section when SOA or NS records were included in an answer. This was - done to reduce round trips (in the case of SOA) and to force out NULL - KEYs (in the NS case). As this document obsoletes NULL keys, there - is no need for the inclusion of KEYs with NSs. Furthermore, as SOAs - are included in the authority section of negative answers, including - the KEYs each time will cause redundant transfers of KEYs. - - RFC 2535 section 3.5 also included a rule for adding the KEY RRset to - the response for a query for A and AAAA types. As Restrict KEY - [RFC3445] eliminated use of KEY RR by all applications, this rule is - no longer needed. - -2.2.2. Signer's Name (replaces RFC 3008 section 2.7) - - The signer's name field of a SIG RR MUST contain the name of the zone - to which the data and signature belong. The combination of signer's - name, key tag, and algorithm MUST identify a zone key if the SIG is - to be considered material. This document defines a standard policy - for DNSSEC validation; local policy MAY override the standard policy. - - There are no restrictions on the signer field of a SIG(0) record. The - combination of signer's name, key tag, and algorithm MUST identify a - key if this SIG(0) is to be processed. - -2.2.3. Changes to RFC 3090 - - A number of sections in RFC 3090 need to be updated to reflect the DS - record. - -2.2.3.1. RFC 3090: Updates to section 1: Introduction - - Most of the text is still relevant but the words "NULL key" are to be - replaced with "missing DS RRset". In section 1.3, the last three - paragraphs discuss the confusion in sections of RFC 2535 that are - replaced in section 2.2.1 above. Therefore, these paragraphs are now - obsolete. - - - - - - - -Gudmundsson Standards Track [Page 9] - -RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 - - -2.2.3.2. RFC 3090 section 2.1: Globally Secured - - Rule 2.1.b is replaced by the following rule: - - 2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a - private key whose public counterpart MUST appear in a zone signing - KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to- - implement algorithm. This KEY RR MUST be identified by a DS RR in a - signed DS RRset in the parent zone. - - If a zone cannot get its parent to advertise a DS record for it, the - child zone cannot be considered globally secured. The only exception - to this is the root zone, for which there is no parent zone. - -2.2.3.3. RFC 3090 section 3: Experimental Status. - - The only difference between experimental status and globally secured - is the missing DS RRset in the parent zone. All locally secured - zones are experimental. - -2.2.4. NULL KEY elimination - - RFC 3445 section 3 eliminates the top two bits in the flags field of - KEY RR. These two bits were used to indicate NULL KEY or NO KEY. RFC - 3090 defines that zone as either secure or not and these rules - eliminate the need to put NULL keys in the zone apex to indicate that - the zone is not secured for a algorithm. Along with this document, - these other two eliminate all uses for the NULL KEY. This document - obsoletes NULL KEY. - -2.3. Comments on Protocol Changes - - Over the years, there have been various discussions surrounding the - DNS delegation model, declaring it to be broken because there is no - good way to assert if a delegation exists. In the RFC 2535 version - of DNSSEC, the presence of the NS bit in the NXT bit map proves there - is a delegation at this name. Something more explicit is required - and the DS record addresses this need for secure delegations. - - The DS record is a major change to DNS: it is the first resource - record that can appear only on the upper side of a delegation. - Adding it will cause interoperability problems and requires a flag - day for DNSSEC. Many old nameservers and resolvers MUST be upgraded - to take advantage of DS. Some old nameservers will be able to be - authoritative for zones with DS records but will not add the NXT or - DS records to the authority section. The same is true for caching - nameservers; in fact, some might even refuse to pass on the DS or NXT - records. - - - -Gudmundsson Standards Track [Page 10] - -RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 - - -2.4. Wire Format of the DS record - - The DS (type=43) record contains these fields: key tag, algorithm, - digest type, and the digest of a public key KEY record that is - allowed and/or used to sign the child's apex KEY RRset. Other keys - MAY sign the child's apex KEY RRset. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | key tag | algorithm | Digest type | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | digest (length depends on type) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | (SHA-1 digest is 20 bytes) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The key tag is calculated as specified in RFC 2535. Algorithm MUST - be allowed to sign DNS data. The digest type is an identifier for - the digest algorithm used. The digest is calculated over the - canonical name of the delegated domain name followed by the whole - RDATA of the KEY record (all four fields). - - digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata) - - KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key - - Digest type value 0 is reserved, value 1 is SHA-1, and reserving - other types requires IETF standards action. For interoperability - reasons, keeping number of digest algorithms low is strongly - RECOMMENDED. The only reason to reserve additional digest types is - to increase security. - - DS records MUST point to zone KEY records that are allowed to - authenticate DNS data. The indicated KEY records protocol field MUST - be set to 3; flag field bit 7 MUST be set to 1. The value of other - flag bits is not significant for the purposes of this document. - - The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless - of key size. New digest types probably will have larger digests. - - - - - -Gudmundsson Standards Track [Page 11] - -RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 - - -2.4.1. Justifications for Fields - - The algorithm and key tag fields are present to allow resolvers to - quickly identify the candidate KEY records to examine. SHA-1 is a - strong cryptographic checksum: it is computationally infeasible for - an attacker to generate a KEY record that has the same SHA-1 digest. - Combining the name of the key and the key rdata as input to the - digest provides stronger assurance of the binding. Having the key - tag in the DS record adds greater assurance than the SHA-1 digest - alone, as there are now two different mapping functions. - - This format allows concise representation of the keys that the child - will use, thus keeping down the size of the answer for the - delegation, reducing the probability of DNS message overflow. The - SHA-1 hash is strong enough to uniquely identify the key and is - similar to the PGP key footprint. The digest type field is present - for possible future expansion. - - The DS record is well suited to listing trusted keys for islands of - security in configuration files. - -2.5. Presentation Format of the DS Record - - The presentation format of the DS record consists of three numbers - (key tag, algorithm, and digest type) followed by the digest itself - presented in hex: - - example. DS 12345 3 1 123456789abcdef67890123456789abcdef67890 - -2.6. Transition Issues for Installed Base - - No backwards compatibility with RFC 2535 is provided. - - RFC 2535-compliant resolvers will assume that all DS-secured - delegations are locally secure. This is bad, but the DNSEXT Working - Group has determined that rather than dealing with both RFC 2535- - secured zones and DS-secured zones, a rapid adoption of DS is - preferable. Thus, the only option for early adopters is to upgrade - to DS as soon as possible. - -2.6.1. Backwards compatibility with RFC 2535 and RFC 1035 - - This section documents how a resolver determines the type of - delegation. - - - - - - - -Gudmundsson Standards Track [Page 12] - -RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 - - - RFC 1035 delegation (in parent) has: - - RFC 1035 NS - - RFC 2535 adds the following two cases: - - Secure RFC 2535: NS + NXT + SIG(NXT) - NXT bit map contains: NS SIG NXT - Unsecure RFC 2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT) - NXT bit map contains: NS SIG KEY NXT - KEY must be a NULL key. - - DNSSEC with DS has the following two states: - - Secure DS: NS + DS + SIG(DS) - NXT bit map contains: NS SIG NXT DS - Unsecure DS: NS + NXT + SIG(NXT) - NXT bit map contains: NS SIG NXT - - It is difficult for a resolver to determine if a delegation is secure - RFC 2535 or unsecure DS. This could be overcome by adding a flag to - the NXT bit map, but only upgraded resolvers would understand this - flag, anyway. Having both parent and child signatures for a KEY - RRset might allow old resolvers to accept a zone as secure, but the - cost of doing this for a long time is much higher than just - prohibiting RFC 2535-style signatures at child zone apexes and - forcing rapid deployment of DS-enabled nameservers and resolvers. - - RFC 2535 and DS can, in theory, be deployed in parallel, but this - would require resolvers to deal with RFC 2535 configurations forever. - This document obsoletes the NULL KEY in parent zones, which is a - difficult enough change that to cause a flag day. - -2.7. KEY and corresponding DS record example - - This is an example of a KEY record and the corresponding DS record. - - dskey.example. KEY 256 3 1 ( - AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj - 4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt - ) ; key id = 28668 - DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE - - - - - - - - - -Gudmundsson Standards Track [Page 13] - -RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 - - -3. Resolver - -3.1. DS Example - - To create a chain of trust, a resolver goes from trusted KEY to DS to - KEY. - - Assume the key for domain "example." is trusted. Zone "example." - contains at least the following records: - example. SOA <soa stuff> - example. NS ns.example. - example. KEY <stuff> - example. NXT secure.example. NS SOA KEY SIG NXT - example. SIG(SOA) - example. SIG(NS) - example. SIG(NXT) - example. SIG(KEY) - secure.example. NS ns1.secure.example. - secure.example. DS tag=12345 alg=3 digest_type=1 <foofoo> - secure.example. NXT unsecure.example. NS SIG NXT DS - secure.example. SIG(NXT) - secure.example. SIG(DS) - unsecure.example NS ns1.unsecure.example. - unsecure.example. NXT example. NS SIG NXT - unsecure.example. SIG(NXT) - - In zone "secure.example." following records exist: - secure.example. SOA <soa stuff> - secure.example. NS ns1.secure.example. - secure.example. KEY <tag=12345 alg=3> - secure.example. KEY <tag=54321 alg=5> - secure.example. NXT <nxt stuff> - secure.example. SIG(KEY) <key-tag=12345 alg=3> - secure.example. SIG(SOA) <key-tag=54321 alg=5> - secure.example. SIG(NS) <key-tag=54321 alg=5> - secure.example. SIG(NXT) <key-tag=54321 alg=5> - - In this example, the private key for "example." signs the DS record - for "secure.example.", making that a secure delegation. The DS - record states which key is expected to sign the KEY RRset at - "secure.example.". Here "secure.example." signs its KEY RRset with - the KEY identified in the DS RRset, thus the KEY RRset is validated - and trusted. - - This example has only one DS record for the child, but parents MUST - allow multiple DS records to facilitate key roll-over and multiple - KEY algorithms. - - - - -Gudmundsson Standards Track [Page 14] - -RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 - - - The resolver determines the security status of "unsecure.example." by - examining the parent zone's NXT record for this name. The absence of - the DS bit indicates an unsecure delegation. Note the NXT record - SHOULD only be examined after verifying the corresponding signature. - -3.2. Resolver Cost Estimates for DS Records - - From a RFC 2535 recursive resolver point of view, for each delegation - followed to chase down an answer, one KEY RRset has to be verified. - Additional RRsets might also need to be verified based on local - policy (e.g., the contents of the NS RRset). Once the resolver gets - to the appropriate delegation, validating the answer might require - verifying one or more signatures. A simple A record lookup requires - at least N delegations to be verified and one RRset. For a DS- - enabled recursive resolver, the cost is 2N+1. For an MX record, - where the target of the MX record is in the same zone as the MX - record, the costs are N+2 and 2N+2, for RFC 2535 and DS, - respectively. In the case of a negative answer, the same ratios hold - true. - - The recursive resolver has to do an extra query to get the DS record, - which will increase the overall cost of resolving this question, but - it will never be worse than chasing down NULL KEY records from the - parent in RFC 2535 DNSSEC. - - DS adds processing overhead on resolvers and increases the size of - delegation answers, but much less than storing signatures in the - parent zone. - -4. Security Considerations - - This document proposes a change to the validation chain of KEY - records in DNSSEC. The change is not believed to reduce security in - the overall system. In RFC 2535 DNSSEC, the child zone has to - communicate keys to its parent and prudent parents will require some - authentication with that transaction. The modified protocol will - require the same authentication, but allows the child to exert more - local control over its own KEY RRset. - - There is a remote possibility that an attacker could generate a valid - KEY that matches all the DS fields, of a specific DS set, and thus - forge data from the child. This possibility is considered - impractical, as on average more than - - 2 ^ (160 - <Number of keys in DS set>) - - keys would have to be generated before a match would be found. - - - - -Gudmundsson Standards Track [Page 15] - -RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 - - - An attacker that wants to match any DS record will have to generate - on average at least 2^80 keys. - - The DS record represents a change to the DNSSEC protocol and there is - an installed base of implementations, as well as textbooks on how to - set up secure delegations. Implementations that do not understand - the DS record will not be able to follow the KEY to DS to KEY chain - and will consider all zones secured that way as unsecure. - -5. IANA Considerations - - IANA has allocated an RR type code for DS from the standard RR type - space (type 43). - - IANA has established a new registry for the DS RR type for digest - algorithms. Defined types are: - - 0 is Reserved, - 1 is SHA-1. - - Adding new reservations requires IETF standards action. - -6. Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - - - - - - - -Gudmundsson Standards Track [Page 16] - -RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 - - -7. Acknowledgments - - Over the last few years a number of people have contributed ideas - that are captured in this document. The core idea of using one key - to sign only the KEY RRset comes from discussions with Bill Manning - and Perry Metzger on how to put in a single root key in all - resolvers. Alexis Yushin, Brian Wellington, Sam Weiler, Paul Vixie, - Jakob Schlyter, Scott Rose, Edward Lewis, Lars-Johan Liman, Matt - Larson, Mark Kosters, Dan Massey, Olaf Kolman, Phillip Hallam-Baker, - Miek Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David - Blacka, Steve Bellovin, Rob Austein, Derek Atkins, Roy Arends, Mark - Andrews, Harald Alvestrand, and others have provided useful comments. - -8. References - -8.1. Normative References - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) - Signing Authority", RFC 3008, November 2000. - - [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone - Status", RFC 3090, March 2001. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC - 3225, December 2001. - - [RFC3445] Massey, D. and S. Rose, "Limiting the scope of the KEY - Resource Record (RR)", RFC 3445, December 2002. - -8.2. Informational References - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver - message size requirements", RFC 3226, December 2001. - - - - - - -Gudmundsson Standards Track [Page 17] - -RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 - - -9. Author's Address - - Olafur Gudmundsson - 3821 Village Park Drive - Chevy Chase, MD, 20815 - - EMail: ds-rfc@ogud.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gudmundsson Standards Track [Page 18] - -RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 - - -10. Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Gudmundsson Standards Track [Page 19] - diff --git a/contrib/bind9/doc/rfc/rfc3757.txt b/contrib/bind9/doc/rfc/rfc3757.txt deleted file mode 100644 index 31890a4bcbeb..000000000000 --- a/contrib/bind9/doc/rfc/rfc3757.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -Network Working Group O. Kolkman -Request for Comments: 3757 RIPE NCC -Updates: 3755, 2535 J. Schlyter -Category: Standards Track NIC-SE - E. Lewis - ARIN - April 2004 - - - Domain Name System KEY (DNSKEY) Resource Record (RR) - Secure Entry Point (SEP) Flag - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - With the Delegation Signer (DS) resource record (RR), the concept of - a public key acting as a secure entry point (SEP) has been - introduced. During exchanges of public keys with the parent there is - a need to differentiate SEP keys from other public keys in the Domain - Name System KEY (DNSKEY) resource record set. A flag bit in the - DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP. - The flag bit is intended to assist in operational procedures to - correctly generate DS resource records, or to indicate what DNSKEYs - are intended for static configuration. The flag bit is not to be - used in the DNS verification protocol. This document updates RFC - 2535 and RFC 3755. - - - - - - - - - - - - - - -Kolkman, et al. Standard Track [Page 1] - -RFC 3757 DNSKEY RR SEP Flag April 2004 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. The Secure Entry Point (SEP) Flag. . . . . . . . . . . . . . . 4 - 3. DNSSEC Protocol Changes. . . . . . . . . . . . . . . . . . . . 4 - 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4 - 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 5 - 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6 - 7. Internationalization Considerations. . . . . . . . . . . . . . 6 - 8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 6 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 - 9.2. Informative References . . . . . . . . . . . . . . . . . 6 - 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 - 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8 - -1. Introduction - - "All keys are equal but some keys are more equal than others" [6]. - - With the definition of the Delegation Signer Resource Record (DS RR) - [5], it has become important to differentiate between the keys in the - DNSKEY RR set that are (to be) pointed to by parental DS RRs and the - other keys in the DNSKEY RR set. We refer to these public keys as - Secure Entry Point (SEP) keys. A SEP key either used to generate a - DS RR or is distributed to resolvers that use the key as the root of - a trusted subtree [3]. - - In early deployment tests, the use of two (kinds of) key pairs for - each zone has been prevalent. For one kind of key pair the private - key is used to sign just the zone's DNSKEY resource record (RR) set. - Its public key is intended to be referenced by a DS RR at the parent - or configured statically in a resolver. The private key of the other - kind of key pair is used to sign the rest of the zone's data sets. - The former key pair is called a key-signing key (KSK) and the latter - is called a zone-signing key (ZSK). In practice there have been - usually one of each kind of key pair, but there will be multiples of - each at times. - - It should be noted that division of keys pairs into KSK's and ZSK's - is not mandatory in any definition of DNSSEC, not even with the - introduction of the DS RR. But, in testing, this distinction has - been helpful when designing key roll over (key super-cession) - schemes. Given that the distinction has proven helpful, the labels - KSK and ZSK have begun to stick. - - - - - - -Kolkman, et al. Standard Track [Page 2] - -RFC 3757 DNSKEY RR SEP Flag April 2004 - - - There is a need to differentiate the public keys for the key pairs - that are used for key signing from keys that are not used key signing - (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to - be sent for generating DS RRs, which DNSKEYs are to be distributed to - resolvers, and which keys are fed to the signer application at the - appropriate time. - - In other words, the SEP bit provides an in-band method to communicate - a DNSKEY RR's intended use to third parties. As an example we - present 3 use cases in which the bit is useful: - - The parent is a registry, the parent and the child use secured DNS - queries and responses, with a preexisting trust-relation, or plain - DNS over a secured channel to exchange the child's DNSKEY RR sets. - Since a DNSKEY RR set will contain a complete DNSKEY RRset the SEP - bit can be used to isolate the DNSKEYs for which a DS RR needs to - be created. - - An administrator has configured a DNSKEY as root for a trusted - subtree into security aware resolver. Using a special purpose - tool that queries for the KEY RRs from that domain's apex, the - administrator will be able to notice the roll over of the trusted - anchor by a change of the subset of KEY RRs with the DS flag set. - - A signer might use the SEP bit on the public key to determine - which private key to use to exclusively sign the DNSKEY RRset and - which private key to use to sign the other RRsets in the zone. - - As demonstrated in the above examples it is important to be able to - differentiate the SEP keys from the other keys in a DNSKEY RR set in - the flow between signer and (parental) key-collector and in the flow - between the signer and the resolver configuration. The SEP flag is - to be of no interest to the flow between the verifier and the - authoritative data store. - - The reason for the term "SEP" is a result of the observation that the - distinction between KSK and ZSK key pairs is made by the signer, a - key pair could be used as both a KSK and a ZSK at the same time. To - be clear, the term SEP was coined to lessen the confusion caused by - the overlap. (Once this label was applied, it had the side effect of - removing the temptation to have both a KSK flag bit and a ZSK flag - bit.) - - The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", - "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be - interpreted as described in BCP 14, RFC 2119 [1]. - - - - - -Kolkman, et al. Standard Track [Page 3] - -RFC 3757 DNSKEY RR SEP Flag April 2004 - - -2. The Secure Entry Point (SEP) Flag - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | flags |S| protocol | algorithm | - | |E| | | - | |P| | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | / - / public key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - DNSKEY RR Format - This document assigns the 15th bit in the flags field as the secure - entry point (SEP) bit. If the bit is set to 1 the key is intended to - be used as secure entry point key. One SHOULD NOT assign special - meaning to the key if the bit is set to 0. Operators can recognize - the secure entry point key by the even or odd-ness of the decimal - representation of the flag field. - -3. DNSSEC Protocol Changes - - The bit MUST NOT be used during the resolving and verification - process. The SEP flag is only used to provide a hint about the - different administrative properties of the key and therefore the use - of the SEP flag does not change the DNS resolution protocol or the - resolution process. - -4. Operational Guidelines - - The SEP bit is set by the key-pair-generator and MAY be used by the - zone signer to decide whether the public part of the key pair is to - be prepared for input to a DS RR generation function. The SEP bit is - recommended to be set (to 1) whenever the public key of the key pair - will be distributed to the parent zone to build the authentication - chain or if the public key is to be distributed for static - configuration in verifiers. - - When a key pair is created, the operator needs to indicate whether - the SEP bit is to be set in the DNSKEY RR. As the SEP bit is within - the data that is used to compute the 'key tag field' in the SIG RR, - changing the SEP bit will change the identity of the key within DNS. - In other words, once a key is used to generate signatures, the - setting of the SEP bit is to remain constant. If not, a verifier - will not be able to find the relevant KEY RR. - - - - -Kolkman, et al. Standard Track [Page 4] - -RFC 3757 DNSKEY RR SEP Flag April 2004 - - - When signing a zone, it is intended that the key(s) with the SEP bit - set (if such keys exist) are used to sign the KEY RR set of the zone. - The same key can be used to sign the rest of the zone data too. It - is conceivable that not all keys with a SEP bit set will sign the - DNSKEY RR set, such keys might be pending retirement or not yet in - use. - - When verifying a RR set, the SEP bit is not intended to play a role. - How the key is used by the verifier is not intended to be a - consideration at key creation time. - - Although the SEP flag provides a hint on which public key is to be - used as trusted root, administrators can choose to ignore the fact - that a DNSKEY has its SEP bit set or not when configuring a trusted - root for their resolvers. - - Using the SEP flag a key roll over can be automated. The parent can - use an existing trust relation to verify DNSKEY RR sets in which a - new DNSKEY RR with the SEP flag appears. - -5. Security Considerations - - As stated in Section 3 the flag is not to be used in the resolution - protocol or to determine the security status of a key. The flag is - to be used for administrative purposes only. - - No trust in a key should be inferred from this flag - trust MUST be - inferred from an existing chain of trust or an out-of-band exchange. - - Since this flag might be used for automating public key exchanges, we - think the following consideration is in place. - - Automated mechanisms for roll over of the DS RR might be vulnerable - to a class of replay attacks. This might happen after a public key - exchange where a DNSKEY RR set, containing two DNSKEY RRs with the - SEP flag set, is sent to the parent. The parent verifies the DNSKEY - RR set with the existing trust relation and creates the new DS RR - from the DNSKEY RR that the current DS RR is not pointing to. This - key exchange might be replayed. Parents are encouraged to implement - a replay defense. A simple defense can be based on a registry of - keys that have been used to generate DS RRs during the most recent - roll over. These same considerations apply to entities that - configure keys in resolvers. - - - - - - - - -Kolkman, et al. Standard Track [Page 5] - -RFC 3757 DNSKEY RR SEP Flag April 2004 - - -6. IANA Considerations - - IANA has assigned the 15th bit in the DNSKEY Flags Registry (see - Section 4.3 of [4]) as the Secure Entry Point (SEP) bit. - -7. Internationalization Considerations - - Although SEP is a popular acronym in many different languages, there - are no internationalization considerations. - -8. Acknowledgments - - The ideas documented in this document are inspired by communications - we had with numerous people and ideas published by other folk. Among - others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson, - Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler - have contributed ideas and provided feedback. - - This document saw the light during a workshop on DNSSEC operations - hosted by USC/ISI in August 2002. - -9. References - -9.1. Normative References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [2] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [3] Lewis, E., "DNS Security Extension Clarification on Zone - Status", RFC 3090, March 2001. - - [4] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer - (DS)", RFC 3755, April 2004. - -9.2. Informative References - - [5] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", - RFC 3658, December 2003. - - [6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy - Story", ISBN 0151002177 (50th anniversary edition), April 1996. - - - - - - - -Kolkman, et al. Standard Track [Page 6] - -RFC 3757 DNSKEY RR SEP Flag April 2004 - - -10. Authors' Addresses - - Olaf M. Kolkman - RIPE NCC - Singel 256 - Amsterdam 1016 AB - NL - - Phone: +31 20 535 4444 - EMail: olaf@ripe.net - URI: http://www.ripe.net/ - - - Jakob Schlyter - NIC-SE - Box 5774 - SE-114 87 Stockholm - Sweden - - EMail: jakob@nic.se - URI: http://www.nic.se/ - - - Edward P. Lewis - ARIN - 3635 Concorde Parkway Suite 200 - Chantilly, VA 20151 - US - - Phone: +1 703 227 9854 - EMail: edlewis@arin.net - URI: http://www.arin.net/ - - - - - - - - - - - - - - - - - - - -Kolkman, et al. Standard Track [Page 7] - -RFC 3757 DNSKEY RR SEP Flag April 2004 - - -11. Full Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78 and - except as set forth therein, the authors retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE - REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE - INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR - IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed - to pertain to the implementation or use of the technology - described in this document or the extent to which any license - under such rights might or might not be available; nor does it - represent that it has made any independent effort to identify any - such rights. Information on the procedures with respect to - rights in RFC documents can be found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use - of such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository - at http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention - any copyrights, patents or patent applications, or other - proprietary rights that may cover technology that may be required - to implement this standard. Please address the information to the - IETF at ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - -Kolkman, et al. Standard Track [Page 8] - diff --git a/contrib/bind9/doc/rfc/rfc3833.txt b/contrib/bind9/doc/rfc/rfc3833.txt deleted file mode 100644 index 8ce4d34e3419..000000000000 --- a/contrib/bind9/doc/rfc/rfc3833.txt +++ /dev/null @@ -1,899 +0,0 @@ - - - - - - -Network Working Group D. Atkins -Request for Comments: 3833 IHTFP Consulting -Category: Informational R. Austein - ISC - August 2004 - - - Threat Analysis of the Domain Name System (DNS) - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2004). - -Abstract - - Although the DNS Security Extensions (DNSSEC) have been under - development for most of the last decade, the IETF has never written - down the specific set of threats against which DNSSEC is designed to - protect. Among other drawbacks, this cart-before-the-horse situation - has made it difficult to determine whether DNSSEC meets its design - goals, since its design goals are not well specified. This note - attempts to document some of the known threats to the DNS, and, in - doing so, attempts to measure to what extent (if any) DNSSEC is a - useful tool in defending against these threats. - -1. Introduction - - The earliest organized work on DNSSEC within the IETF was an open - design team meeting organized by members of the DNS working group in - November 1993 at the 28th IETF meeting in Houston. The broad - outlines of DNSSEC as we know it today are already clear in Jim - Galvin's summary of the results of that meeting [Galvin93]: - - - While some participants in the meeting were interested in - protecting against disclosure of DNS data to unauthorized parties, - the design team made an explicit decision that "DNS data is - `public'", and ruled all threats of data disclosure explicitly out - of scope for DNSSEC. - - - While some participants in the meeting were interested in - authentication of DNS clients and servers as a basis for access - control, this work was also ruled out of scope for DNSSEC per se. - - - -Atkins & Austein Informational [Page 1] - -RFC 3833 DNS Threat Analysis August 2004 - - - - Backwards compatibility and co-existence with "insecure DNS" was - listed as an explicit requirement. - - - The resulting list of desired security services was - 1) data integrity, and - 2) data origin authentication. - - - The design team noted that a digital signature mechanism would - support the desired services. - - While a number of detail decisions were yet to be made (and in some - cases remade after implementation experience) over the subsequent - decade, the basic model and design goals have remained fixed. - - Nowhere, however, does any of the DNSSEC work attempt to specify in - any detail the sorts of attacks against which DNSSEC is intended to - protect, or the reasons behind the list of desired security services - that came out of the Houston meeting. For that, we have to go back - to a paper originally written by Steve Bellovin in 1990 but not - published until 1995, for reasons that Bellovin explained in the - paper's epilogue [Bellovin95]. - - While it may seem a bit strange to publish the threat analysis a - decade after starting work on the protocol designed to defend against - it, that is, nevertheless, what this note attempts to do. Better - late than never. - - This note assumes that the reader is familiar with both the DNS and - with DNSSEC, and does not attempt to provide a tutorial on either. - The DNS documents most relevant to the subject of this note are: - [RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308], - [RFC2671], [RFC2845], [RFC2930], [RFC3007], and [RFC2535]. - - For purposes of discussion, this note uses the term "DNSSEC" to refer - to the core hierarchical public key and signature mechanism specified - in the DNSSEC documents, and refers to TKEY and TSIG as separate - mechanisms, even though channel security mechanisms such as TKEY and - TSIG are also part of the larger problem of "securing DNS" and thus - are often considered part of the overall set of "DNS security - extensions". This is an arbitrary distinction that in part reflects - the way in which the protocol has evolved (introduction of a - putatively simpler channel security model for certain operations such - as zone transfers and dynamic update requests), and perhaps should be - changed in a future revision of this note. - - - - - - - -Atkins & Austein Informational [Page 2] - -RFC 3833 DNS Threat Analysis August 2004 - - -2. Known Threats - - There are several distinct classes of threats to the DNS, most of - which are DNS-related instances of more general problems, but a few - of which are specific to peculiarities of the DNS protocol. - -2.1. Packet Interception - - Some of the simplest threats against DNS are various forms of packet - interception: monkey-in-the-middle attacks, eavesdropping on requests - combined with spoofed responses that beat the real response back to - the resolver, and so forth. In any of these scenarios, the attacker - can simply tell either party (usually the resolver) whatever it wants - that party to believe. While packet interception attacks are far - from unique to DNS, DNS's usual behavior of sending an entire query - or response in a single unsigned, unencrypted UDP packet makes these - attacks particularly easy for any bad guy with the ability to - intercept packets on a shared or transit network. - - To further complicate things, the DNS query the attacker intercepts - may just be a means to an end for the attacker: the attacker might - even choose to return the correct result in the answer section of a - reply message while using other parts of the message to set the stage - for something more complicated, for example, a name chaining attack - (see section 2.3). - - While it certainly would be possible to sign DNS messages using a - channel security mechanism such as TSIG or IPsec, or even to encrypt - them using IPsec, this would not be a very good solution for - interception attacks. First, this approach would impose a fairly - high processing cost per DNS message, as well as a very high cost - associated with establishing and maintaining bilateral trust - relationships between all the parties that might be involved in - resolving any particular query. For heavily used name servers (such - as the servers for the root zone), this cost would almost certainly - be prohibitively high. Even more important, however, is that the - underlying trust model in such a design would be wrong, since at best - it would only provide a hop-by-hop integrity check on DNS messages - and would not provide any sort of end-to-end integrity check between - the producer of DNS data (the zone administrator) and the consumer of - DNS data (the application that triggered the query). - - By contrast, DNSSEC (when used properly) does provide an end-to-end - data integrity check, and is thus a much better solution for this - class of problems during basic DNS lookup operations. - - - - - - -Atkins & Austein Informational [Page 3] - -RFC 3833 DNS Threat Analysis August 2004 - - - TSIG does have its place in corners of the DNS protocol where there's - a specific trust relationship between a particular client and a - particular server, such as zone transfer, dynamic update, or a - resolver (stub or otherwise) that is not going to check all the - DNSSEC signatures itself. - - Note that DNSSEC does not provide any protection against modification - of the DNS message header, so any properly paranoid resolver must: - - - Perform all of the DNSSEC signature checking on its own, - - - Use TSIG (or some equivalent mechanism) to ensure the integrity of - its communication with whatever name servers it chooses to trust, - or - - - Resign itself to the possibility of being attacked via packet - interception (and via other techniques discussed below). - -2.2. ID Guessing and Query Prediction - - Since DNS is for the most part used over UDP/IP, it is relatively - easy for an attacker to generate packets which will match the - transport protocol parameters. The ID field in the DNS header is - only a 16-bit field and the server UDP port associated with DNS is a - well-known value, so there are only 2**32 possible combinations of ID - and client UDP port for a given client and server. This is not a - particularly large range, and is not sufficient to protect against a - brute force search; furthermore, in practice both the client UDP port - and the ID can often be predicted from previous traffic, and it is - not uncommon for the client port to be a known fixed value as well - (due to firewalls or other restrictions), thus frequently reducing - the search space to a range smaller than 2**16. - - By itself, ID guessing is not enough to allow an attacker to inject - bogus data, but combined with knowledge (or guesses) about QNAMEs and - QTYPEs for which a resolver might be querying, this leaves the - resolver only weakly defended against injection of bogus responses. - - Since this attack relies on predicting a resolver's behavior, it's - most likely to be successful when the victim is in a known state, - whether because the victim rebooted recently, or because the victim's - behavior has been influenced by some other action by the attacker, or - because the victim is responding (in a predictable way) to some third - party action known to the attacker. - - - - - - - -Atkins & Austein Informational [Page 4] - -RFC 3833 DNS Threat Analysis August 2004 - - - This attack is both more and less difficult for the attacker than the - simple interception attack described above: more difficult, because - the attack only works when the attacker guesses correctly; less - difficult, because the attacker doesn't need to be on a transit or - shared network. - - In most other respects, this attack is similar to a packet - interception attack. A resolver that checks DNSSEC signatures will - be able to detect the forged response; resolvers that do not perform - DNSSEC signature checking themselves should use TSIG or some - equivalent mechanism to ensure the integrity of their communication - with a recursive name server that does perform DNSSEC signature - checking. - -2.3. Name Chaining - - Perhaps the most interesting class of DNS-specific threats are the - name chaining attacks. These are a subset of a larger class of - name-based attacks, sometimes called "cache poisoning" attacks. Most - name-based attacks can be partially mitigated by the long-standing - defense of checking RRs in response messages for relevance to the - original query, but such defenses do not catch name chaining attacks. - There are several variations on the basic attack, but what they all - have in common is that they all involve DNS RRs whose RDATA portion - (right hand side) includes a DNS name (or, in a few cases, something - that is not a DNS name but which directly maps to a DNS name). Any - such RR is, at least in principle, a hook that lets an attacker feed - bad data into a victim's cache, thus potentially subverting - subsequent decisions based on DNS names. - - The worst examples in this class of RRs are CNAME, NS, and DNAME RRs - because they can redirect a victim's query to a location of the - attacker's choosing. RRs like MX and SRV are somewhat less - dangerous, but in principle they can also be used to trigger further - lookups at a location of the attacker's choosing. Address RR types - such as A or AAAA don't have DNS names in their RDATA, but since the - IN-ADDR.ARPA and IP6.ARPA trees are indexed using a DNS encoding of - IPv4 and IPv6 addresses, these record types can also be used in a - name chaining attack. - - The general form of a name chaining attack is something like this: - - - Victim issues a query, perhaps at the instigation of the attacker - or some third party; in some cases the query itself may be - unrelated to the name under attack (that is, the attacker is just - using this query as a means to inject false information about some - other name). - - - - -Atkins & Austein Informational [Page 5] - -RFC 3833 DNS Threat Analysis August 2004 - - - - Attacker injects response, whether via packet interception, query - guessing, or by being a legitimate name server that's involved at - some point in the process of answering the query that the victim - issued. - - - Attacker's response includes one or more RRs with DNS names in - their RDATA; depending on which particular form this attack takes, - the object may be to inject false data associated with those names - into the victim's cache via the Additional section of this - response, or may be to redirect the next stage of the query to a - server of the attacker's choosing (in order to inject more complex - lies into the victim's cache than will fit easily into a single - response, or in order to place the lies in the Authority or Answer - section of a response where they will have a better chance of - sneaking past a resolver's defenses). - - Any attacker who can insert resource records into a victim's cache - can almost certainly do some kind of damage, so there are cache - poisoning attacks which are not name chaining attacks in the sense - discussed here. However, in the case of name chaining attacks, the - cause and effect relationship between the initial attack and the - eventual result may be significantly more complex than in the other - forms of cache poisoning, so name chaining attacks merit special - attention. - - The common thread in all of the name chaining attacks is that - response messages allow the attacker to introduce arbitrary DNS names - of the attacker's choosing and provide further information that the - attacker claims is associated with those names; unless the victim has - better knowledge of the data associated with those names, the victim - is going to have a hard time defending against this class of attacks. - - This class of attack is particularly insidious given that it's quite - easy for an attacker to provoke a victim into querying for a - particular name of the attacker's choosing, for example, by embedding - a link to a 1x1-pixel "web bug" graphic in a piece of Text/HTML mail - to the victim. If the victim's mail reading program attempts to - follow such a link, the result will be a DNS query for a name chosen - by the attacker. - - DNSSEC should provide a good defense against most (all?) variations - on this class of attack. By checking signatures, a resolver can - determine whether the data associated with a name really was inserted - by the delegated authority for that portion of the DNS name space. - More precisely, a resolver can determine whether the entity that - injected the data had access to an allegedly secret key whose - - - - - -Atkins & Austein Informational [Page 6] - -RFC 3833 DNS Threat Analysis August 2004 - - - corresponding public key appears at an expected location in the DNS - name space with an expected chain of parental signatures that start - with a public key of which the resolver has prior knowledge. - - DNSSEC signatures do not cover glue records, so there's still a - possibility of a name chaining attack involving glue, but with DNSSEC - it is possible to detect the attack by temporarily accepting the glue - in order to fetch the signed authoritative version of the same data, - then checking the signatures on the authoritative version. - -2.4. Betrayal By Trusted Server - - Another variation on the packet interception attack is the trusted - server that turns out not to be so trustworthy, whether by accident - or by intent. Many client machines are only configured with stub - resolvers, and use trusted servers to perform all of their DNS - queries on their behalf. In many cases the trusted server is - furnished by the user's ISP and advertised to the client via DHCP or - PPP options. Besides accidental betrayal of this trust relationship - (via server bugs, successful server break-ins, etc), the server - itself may be configured to give back answers that are not what the - user would expect, whether in an honest attempt to help the user or - to promote some other goal such as furthering a business partnership - between the ISP and some third party. - - This problem is particularly acute for frequent travelers who carry - their own equipment and expect it to work in much the same way - wherever they go. Such travelers need trustworthy DNS service - without regard to who operates the network into which their equipment - is currently plugged or what brand of middle boxes the local - infrastructure might use. - - While the obvious solution to this problem would be for the client to - choose a more trustworthy server, in practice this may not be an - option for the client. In many network environments a client machine - has only a limited set of recursive name servers from which to - choose, and none of them may be particularly trustworthy. In extreme - cases, port filtering or other forms of packet interception may - prevent the client host from being able to run an iterative resolver - even if the owner of the client machine is willing and able to do so. - Thus, while the initial source of this problem is not a DNS protocol - attack per se, this sort of betrayal is a threat to DNS clients, and - simply switching to a different recursive name server is not an - adequate defense. - - Viewed strictly from the DNS protocol standpoint, the only difference - between this sort of betrayal and a packet interception attack is - that in this case the client has voluntarily sent its request to the - - - -Atkins & Austein Informational [Page 7] - -RFC 3833 DNS Threat Analysis August 2004 - - - attacker. The defense against this is the same as with a packet - interception attack: the resolver must either check DNSSEC signatures - itself or use TSIG (or equivalent) to authenticate the server that it - has chosen to trust. Note that use of TSIG does not by itself - guarantee that a name server is at all trustworthy: all TSIG can do - is help a resolver protect its communication with a name server that - it has already decided to trust for other reasons. Protecting a - resolver's communication with a server that's giving out bogus - answers is not particularly useful. - - Also note that if the stub resolver does not trust the name server - that is doing work on its behalf and wants to check the DNSSEC - signatures itself, the resolver really does need to have independent - knowledge of the DNSSEC public key(s) it needs in order to perform - the check. Usually the public key for the root zone is enough, but - in some cases knowledge of additional keys may also be appropriate. - - It is difficult to escape the conclusion that a properly paranoid - resolver must always perform its own signature checking, and that - this rule even applies to stub resolvers. - -2.5. Denial of Service - - As with any network service (or, indeed, almost any service of any - kind in any domain of discourse), DNS is vulnerable to denial of - service attacks. DNSSEC does not help this, and may in fact make the - problem worse for resolvers that check signatures, since checking - signatures both increases the processing cost per DNS message and in - some cases can also increase the number of messages needed to answer - a query. TSIG (and similar mechanisms) have equivalent problems. - - DNS servers are also at risk of being used as denial of service - amplifiers, since DNS response packets tend to be significantly - longer than DNS query packets. Unsurprisingly, DNSSEC doesn't help - here either. - -2.6. Authenticated Denial of Domain Names - - Much discussion has taken place over the question of authenticated - denial of domain names. The particular question is whether there is - a requirement for authenticating the non-existence of a name. The - issue is whether the resolver should be able to detect when an - attacker removes RRs from a response. - - General paranoia aside, the existence of RR types whose absence - causes an action other than immediate failure (such as missing MX and - SRV RRs, which fail over to A RRs) constitutes a real threat. - Arguably, in some cases, even the absence of an RR might be - - - -Atkins & Austein Informational [Page 8] - -RFC 3833 DNS Threat Analysis August 2004 - - - considered a problem. The question remains: how serious is this - threat? Clearly the threat does exist; general paranoia says that - some day it'll be on the front page of some major newspaper, even if - we cannot conceive of a plausible scenario involving this attack - today. This implies that some mitigation of this risk is required. - - Note that it's necessary to prove the non-existence of applicable - wildcard RRs as part of the authenticated denial mechanism, and that, - in a zone that is more than one label deep, such a proof may require - proving the non-existence of multiple discrete sets of wildcard RRs. - - DNSSEC does include mechanisms which make it possible to determine - which authoritative names exist in a zone, and which authoritative - resource record types exist at those names. The DNSSEC protections - do not cover non-authoritative data such as glue records. - -2.7. Wildcards - - Much discussion has taken place over whether and how to provide data - integrity and data origin authentication for "wildcard" DNS names. - Conceptually, RRs with wildcard names are patterns for synthesizing - RRs on the fly according to the matching rules described in section - 4.3.2 of RFC 1034. While the rules that control the behavior of - wildcard names have a few quirks that can make them a trap for the - unwary zone administrator, it's clear that a number of sites make - heavy use of wildcard RRs, particularly wildcard MX RRs. - - In order to provide the desired services for wildcard RRs, we need to - do two things: - - - We need a way to attest to the existence of the wildcard RR itself - (that is, we need to show that the synthesis rule exists), and - - - We need a way to attest to the non-existence of any RRs which, if - they existed, would make the wildcard RR irrelevant according to - the synthesis rules that govern the way in which wildcard RRs are - used (that is, we need to show that the synthesis rule is - applicable). - - Note that this makes the wildcard mechanisms dependent upon the - authenticated denial mechanism described in the previous section. - - DNSSEC includes mechanisms along the lines described above, which - make it possible for a resolver to verify that a name server applied - the wildcard expansion rules correctly when generating an answer. - - - - - - -Atkins & Austein Informational [Page 9] - -RFC 3833 DNS Threat Analysis August 2004 - - -3. Weaknesses of DNSSEC - - DNSSEC has some problems of its own: - - - DNSSEC is complex to implement and includes some nasty edge cases - at the zone cuts that require very careful coding. Testbed - experience to date suggests that trivial zone configuration errors - or expired keys can cause serious problems for a DNSSEC-aware - resolver, and that the current protocol's error reporting - capabilities may leave something to be desired. - - - DNSSEC significantly increases the size of DNS response packets; - among other issues, this makes DNSSEC-aware DNS servers even more - effective as denial of service amplifiers. - - - DNSSEC answer validation increases the resolver's work load, since - a DNSSEC-aware resolver will need to perform signature validation - and in some cases will also need to issue further queries. This - increased workload will also increase the time it takes to get an - answer back to the original DNS client, which is likely to trigger - both timeouts and re-queries in some cases. Arguably, many current - DNS clients are already too impatient even before taking the - further delays that DNSSEC will impose into account, but that topic - is beyond the scope of this note. - - - Like DNS itself, DNSSEC's trust model is almost totally - hierarchical. While DNSSEC does allow resolvers to have special - additional knowledge of public keys beyond those for the root, in - the general case the root key is the one that matters. Thus any - compromise in any of the zones between the root and a particular - target name can damage DNSSEC's ability to protect the integrity of - data owned by that target name. This is not a change, since - insecure DNS has the same model. - - - Key rollover at the root is really hard. Work to date has not even - come close to adequately specifying how the root key rolls over, or - even how it's configured in the first place. - - - DNSSEC creates a requirement of loose time synchronization between - the validating resolver and the entity creating the DNSSEC - signatures. Prior to DNSSEC, all time-related actions in DNS could - be performed by a machine that only knew about "elapsed" or - "relative" time. Because the validity period of a DNSSEC signature - is based on "absolute" time, a validating resolver must have the - same concept of absolute time as the zone signer in order to - determine whether the signature is within its validity period or - has expired. An attacker that can change a resolver's opinion of - the current absolute time can fool the resolver using expired - - - -Atkins & Austein Informational [Page 10] - -RFC 3833 DNS Threat Analysis August 2004 - - - signatures. An attacker that can change the zone signer's opinion - of the current absolute time can fool the zone signer into - generating signatures whose validity period does not match what the - signer intended. - - - The possible existence of wildcard RRs in a zone complicates the - authenticated denial mechanism considerably. For most of the - decade that DNSSEC has been under development these issues were - poorly understood. At various times there have been questions as - to whether the authenticated denial mechanism is completely - airtight and whether it would be worthwhile to optimize the - authenticated denial mechanism for the common case in which - wildcards are not present in a zone. However, the main problem is - just the inherent complexity of the wildcard mechanism itself. - This complexity probably makes the code for generating and checking - authenticated denial attestations somewhat fragile, but since the - alternative of giving up wildcards entirely is not practical due to - widespread use, we are going to have to live with wildcards. The - question just becomes one of whether or not the proposed - optimizations would make DNSSEC's mechanisms more or less fragile. - - - Even with DNSSEC, the class of attacks discussed in section 2.4 is - not easy to defeat. In order for DNSSEC to be effective in this - case, it must be possible to configure the resolver to expect - certain categories of DNS records to be signed. This may require - manual configuration of the resolver, especially during the initial - DNSSEC rollout period when the resolver cannot reasonably expect - the root and TLD zones to be signed. - -4. Topics for Future Work - - This section lists a few subjects not covered above which probably - need additional study, additional mechanisms, or both. - -4.1. Interactions With Other Protocols - - The above discussion has concentrated exclusively on attacks within - the boundaries of the DNS protocol itself, since those are (some of) - the problems against which DNSSEC was intended to protect. There - are, however, other potential problems at the boundaries where DNS - interacts with other protocols. - -4.2. Securing DNS Dynamic Update - - DNS dynamic update opens a number of potential problems when combined - with DNSSEC. Dynamic update of a non-secure zone can use TSIG to - authenticate the updating client to the server. While TSIG does not - scale very well (it requires manual configuration of shared keys - - - -Atkins & Austein Informational [Page 11] - -RFC 3833 DNS Threat Analysis August 2004 - - - between the DNS name server and each TSIG client), it works well in a - limited or closed environment such as a DHCP server updating a local - DNS name server. - - Major issues arise when trying to use dynamic update on a secure - zone. TSIG can similarly be used in a limited fashion to - authenticate the client to the server, but TSIG only protects DNS - transactions, not the actual data, and the TSIG is not inserted into - the DNS zone, so resolvers cannot use the TSIG as a way of verifying - the changes to the zone. This means that either: - - a) The updating client must have access to a zone-signing key in - order to sign the update before sending it to the server, or - - b) The DNS name server must have access to an online zone-signing key - in order to sign the update. - - In either case, a zone-signing key must be available to create signed - RRsets to place in the updated zone. The fact that this key must be - online (or at least available) is a potential security risk. - - Dynamic update also requires an update to the SERIAL field of the - zone's SOA RR. In theory, this could also be handled via either of - the above options, but in practice (a) would almost certainly be - extremely fragile, so (b) is the only workable mechanism. - - There are other threats in terms of describing the policy of who can - make what changes to which RRsets in the zone. The current access - control scheme in Secure Dynamic Update is fairly limited. There is - no way to give fine-grained access to updating DNS zone information - to multiple entities, each of whom may require different kinds of - access. For example, Alice may need to be able to add new nodes to - the zone or change existing nodes, but not remove them; Bob may need - to be able to remove zones but not add them; Carol may need to be - able to add, remove, or modify nodes, but only A records. - - Scaling properties of the key management problem here are a - particular concern that needs more study. - -4.3. Securing DNS Zone Replication - - As discussed in previous sections, DNSSEC per se attempts to provide - data integrity and data origin authentication services on top of the - normal DNS query protocol. Using the terminology discussed in - [RFC3552], DNSSEC provides "object security" for the normal DNS query - protocol. For purposes of replicating entire DNS zones, however, - DNSSEC does not provide object security, because zones include - unsigned NS RRs and glue at delegation points. Use of TSIG to - - - -Atkins & Austein Informational [Page 12] - -RFC 3833 DNS Threat Analysis August 2004 - - - protect zone transfer (AXFR or IXFR) operations provides "channel - security", but still does not provide object security for complete - zones. The trust relationships involved in zone transfer are still - very much a hop-by-hop matter of name server operators trusting other - name server operators rather than an end-to-end matter of name server - operators trusting zone administrators. - - Zone object security was not an explicit design goal of DNSSEC, so - failure to provide this service should not be a surprise. - Nevertheless, there are some zone replication scenarios for which - this would be a very useful additional service, so this seems like a - useful area for future work. In theory it should not be difficult to - add zone object security as a backwards compatible enhancement to the - existing DNSSEC model, but the DNSEXT WG has not yet discussed either - the desirability of or the requirements for such an enhancement. - -5. Conclusion - - Based on the above analysis, the DNSSEC extensions do appear to solve - a set of problems that do need to be solved, and are worth deploying. - -Security Considerations - - This entire document is about security considerations of the DNS. - The authors believe that deploying DNSSEC will help to address some, - but not all, of the known threats to the DNS. - -Acknowledgments - - This note is based both on previous published works by others and on - a number of discussions both public and private over a period of many - years, but particular thanks go to - - Jaap Akkerhuis, - Steve Bellovin, - Dan Bernstein, - Randy Bush, - Steve Crocker, - Olafur Gudmundsson, - Russ Housley, - Rip Loomis, - Allison Mankin, - Paul Mockapetris, - Thomas Narten - Mans Nilsson, - Pekka Savola, - Paul Vixie, - Xunhua Wang, - - - -Atkins & Austein Informational [Page 13] - -RFC 3833 DNS Threat Analysis August 2004 - - - and any other members of the DNS, DNSSEC, DNSIND, and DNSEXT working - groups whose names and contributions the authors have forgotten, none - of whom are responsible for what the authors did with their ideas. - - As with any work of this nature, the authors of this note acknowledge - that we are standing on the toes of those who have gone before us. - Readers interested in this subject may also wish to read - [Bellovin95], [Schuba93], and [Vixie95]. - -Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and - facilities", STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1123] Braden, R., "Requirements for Internet Hosts - - Application and Support", STD 3, RFC 1123, October 1989. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. - Wellington, "Secret Key Transaction Authentication for - DNS (TSIG)", RFC 2845, May 2000. - - [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS - (TKEY RR)", RFC 2930, September 2000. - - [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - [RFC2535] Eastlake 3rd, D., "Domain Name System Security - Extensions", RFC 2535, March 1999. - - - - - - - - - - -Atkins & Austein Informational [Page 14] - -RFC 3833 DNS Threat Analysis August 2004 - - -Informative References - - [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC - Text on Security Considerations", BCP 72, RFC 3552, July - 2003. - - [Bellovin95] Bellovin, S., "Using the Domain Name System for System - Break-Ins", Proceedings of the Fifth Usenix Unix - Security Symposium, June 1995. - - [Galvin93] Design team meeting summary message posted to dns- - security@tis.com mailing list by Jim Galvin on 19 - November 1993. - - [Schuba93] Schuba, C., "Addressing Weaknesses in the Domain Name - System Protocol", Master's thesis, Purdue University - Department of Computer Sciences, August 1993. - - [Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of - the Fifth Usenix Unix Security Symposium, June 1995. - -Authors' Addresses - - Derek Atkins - IHTFP Consulting, Inc. - 6 Farragut Ave - Somerville, MA 02144 - USA - - EMail: derek@ihtfp.com - - - Rob Austein - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - - - - - - - - - - -Atkins & Austein Informational [Page 15] - -RFC 3833 DNS Threat Analysis August 2004 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - -Atkins & Austein Informational [Page 16] - diff --git a/contrib/bind9/doc/rfc/rfc3845.txt b/contrib/bind9/doc/rfc/rfc3845.txt deleted file mode 100644 index 9887a20af0b5..000000000000 --- a/contrib/bind9/doc/rfc/rfc3845.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -Network Working Group J. Schlyter, Ed. -Request for Comments: 3845 August 2004 -Updates: 3755, 2535 -Category: Standards Track - - - DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2004). - -Abstract - - This document redefines the wire format of the "Type Bit Map" field - in the DNS NextSECure (NSEC) resource record RDATA format to cover - the full resource record (RR) type space. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 2 - 2.1. NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . 3 - 2.1.1. The Next Domain Name Field . . . . . . . . . . . 3 - 2.1.2. The List of Type Bit Map(s) Field . . . . . . . 3 - 2.1.3. Inclusion of Wildcard Names in NSEC RDATA . . . 4 - 2.2. The NSEC RR Presentation Format . . . . . . . . . . . . 4 - 2.3. NSEC RR Example . . . . . . . . . . . . . . . . . . . . 5 - 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 - 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 - 5.2. Informative References . . . . . . . . . . . . . . . . . 6 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 - 7. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 - 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7 - - - - - - - -Schlyter, Ed. Standards Track [Page 1] - -RFC 3845 DNSSEC NSEC RDATA Format August 2004 - - -1. Introduction - - The DNS [6][7] NSEC [5] Resource Record (RR) is used for - authenticated proof of the non-existence of DNS owner names and - types. The NSEC RR is based on the NXT RR as described in RFC 2535 - [2], and is similar except for the name and typecode. The RDATA - format for the NXT RR has the limitation in that the RDATA could only - carry information about the existence of the first 127 types. RFC - 2535 did reserve a bit to specify an extension mechanism, but the - mechanism was never actually defined. - - In order to avoid needing to develop an extension mechanism into a - deployed base of DNSSEC aware servers and resolvers once the first - 127 type codes are allocated, this document redefines the wire format - of the "Type Bit Map" field in the NSEC RDATA to cover the full RR - type space. - - This document introduces a new format for the type bit map. The - properties of the type bit map format are that it can cover the full - possible range of typecodes, that it is relatively economical in the - amount of space it uses for the common case of a few types with an - owner name, that it can represent owner names with all possible types - present in packets of approximately 8.5 kilobytes, and that the - representation is simple to implement. Efficient searching of the - type bitmap for the presence of certain types is not a requirement. - - For convenience and completeness, this document presents the syntax - and semantics for the NSEC RR based on the specification in RFC 2535 - [2] and as updated by RFC 3755 [5], thereby not introducing changes - except for the syntax of the type bit map. - - This document updates RFC 2535 [2] and RFC 3755 [5]. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14, RFC 2119 [1]. - -2. The NSEC Resource Record - - The NSEC resource record lists two separate things: the owner name of - the next RRset in the canonical ordering of the zone, and the set of - RR types present at the NSEC RR's owner name. The complete set of - NSEC RRs in a zone indicate which RRsets exist in a zone, and form a - chain of owner names in the zone. This information is used to - provide authenticated denial of existence for DNS data, as described - in RFC 2535 [2]. - - The type value for the NSEC RR is 47. - - - -Schlyter, Ed. Standards Track [Page 2] - -RFC 3845 DNSSEC NSEC RDATA Format August 2004 - - - The NSEC RR RDATA format is class independent and defined for all - classes. - - The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL - field. This is in the spirit of negative caching [8]. - -2.1. NSEC RDATA Wire Format - - The RDATA of the NSEC RR is as shown below: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Next Domain Name / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / List of Type Bit Map(s) / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -2.1.1. The Next Domain Name Field - - The Next Domain Name field contains the owner name of the next RR in - the canonical ordering of the zone. The value of the Next Domain - Name field in the last NSEC record in the zone is the name of the - zone apex (the owner name of the zone's SOA RR). - - A sender MUST NOT use DNS name compression on the Next Domain Name - field when transmitting an NSEC RR. - - Owner names of RRsets that are not authoritative for the given zone - (such as glue records) MUST NOT be listed in the Next Domain Name - unless at least one authoritative RRset exists at the same owner - name. - -2.1.2. The List of Type Bit Map(s) Field - - The RR type space is split into 256 window blocks, each representing - the low-order 8 bits of the 16-bit RR type space. Each block that - has at least one active RR type is encoded using a single octet - window number (from 0 to 255), a single octet bitmap length (from 1 - to 32) indicating the number of octets used for the window block's - bitmap, and up to 32 octets (256 bits) of bitmap. - - Window blocks are present in the NSEC RR RDATA in increasing - numerical order. - - "|" denotes concatenation - - Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + - - - -Schlyter, Ed. Standards Track [Page 3] - -RFC 3845 DNSSEC NSEC RDATA Format August 2004 - - - Each bitmap encodes the low-order 8 bits of RR types within the - window block, in network bit order. The first bit is bit 0. For - window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds - to RR type 2 (NS), and so forth. For window block 1, bit 1 - corresponds to RR type 257, and bit 2 to RR type 258. If a bit is - set to 1, it indicates that an RRset of that type is present for the - NSEC RR's owner name. If a bit is set to 0, it indicates that no - RRset of that type is present for the NSEC RR's owner name. - - Since bit 0 in window block 0 refers to the non-existing RR type 0, - it MUST be set to 0. After verification, the validator MUST ignore - the value of bit 0 in window block 0. - - Bits representing Meta-TYPEs or QTYPEs, as specified in RFC 2929 [3] - (section 3.1), or within the range reserved for assignment only to - QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in - zone data. If encountered, they must be ignored upon reading. - - Blocks with no types present MUST NOT be included. Trailing zero - octets in the bitmap MUST be omitted. The length of each block's - bitmap is determined by the type code with the largest numerical - value within that block, among the set of RR types present at the - NSEC RR's owner name. Trailing zero octets not specified MUST be - interpreted as zero octets. - -2.1.3. Inclusion of Wildcard Names in NSEC RDATA - - If a wildcard owner name appears in a zone, the wildcard label ("*") - is treated as a literal symbol and is treated the same as any other - owner name for purposes of generating NSEC RRs. Wildcard owner names - appear in the Next Domain Name field without any wildcard expansion. - RFC 2535 [2] describes the impact of wildcards on authenticated - denial of existence. - -2.2. The NSEC RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Next Domain Name field is represented as a domain name. - - The List of Type Bit Map(s) Field is represented as a sequence of RR - type mnemonics. When the mnemonic is not known, the TYPE - representation as described in RFC 3597 [4] (section 5) MUST be used. - - - - - - - - -Schlyter, Ed. Standards Track [Page 4] - -RFC 3845 DNSSEC NSEC RDATA Format August 2004 - - -2.3. NSEC RR Example - - The following NSEC RR identifies the RRsets associated with - alfa.example.com. and the next authoritative name after - alfa.example.com. - - alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC - TYPE1234 - - The first four text fields specify the name, TTL, Class, and RR type - (NSEC). The entry host.example.com. is the next authoritative name - after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, - and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and - TYPE1234 RRsets associated with the name alfa.example.com. - - The RDATA section of the NSEC RR above would be encoded as: - - 0x04 'h' 'o' 's' 't' - 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' - 0x03 'c' 'o' 'm' 0x00 - 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 - 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x20 - - Assuming that the resolver can authenticate this NSEC record, it - could be used to prove that beta.example.com does not exist, or could - be used to prove that there is no AAAA record associated with - alfa.example.com. Authenticated denial of existence is discussed in - RFC 2535 [2]. - -3. IANA Considerations - - This document introduces no new IANA considerations, because all of - the protocol parameters used in this document have already been - assigned by RFC 3755 [5]. - -4. Security Considerations - - The update of the RDATA format and encoding does not affect the - security of the use of NSEC RRs. - - - - - - - - - -Schlyter, Ed. Standards Track [Page 5] - -RFC 3845 DNSSEC NSEC RDATA Format August 2004 - - -5. References - -5.1. Normative References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [2] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [3] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, "Domain - Name System (DNS) IANA Considerations", BCP 42, RFC 2929, - September 2000. - - [4] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) - Types", RFC 3597, September 2003. - - [5] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer - (DS)", RFC 3755, May 2004. - -5.2. Informative References - - [6] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [7] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [8] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC - 2308, March 1998. - -6. Acknowledgements - - The encoding described in this document was initially proposed by - Mark Andrews. Other encodings where proposed by David Blacka and - Michael Graff. - -7. Author's Address - - Jakob Schlyter (editor) - NIC-SE - Box 5774 - Stockholm SE-114 87 - Sweden - - EMail: jakob@nic.se - URI: http://www.nic.se/ - - - - -Schlyter, Ed. Standards Track [Page 6] - -RFC 3845 DNSSEC NSEC RDATA Format August 2004 - - -8. Full Copyright Statement - - Copyright (C) The Internet Society (2004). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE - REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE - INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR - IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the IETF's procedures with respect to rights in IETF Documents can - be found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Schlyter, Ed. Standards Track [Page 7] - diff --git a/contrib/bind9/doc/rfc/rfc3901.txt b/contrib/bind9/doc/rfc/rfc3901.txt deleted file mode 100644 index 43b7356e6adf..000000000000 --- a/contrib/bind9/doc/rfc/rfc3901.txt +++ /dev/null @@ -1,283 +0,0 @@ - - - - - - -Network Working Group A. Durand -Request for Comments: 3901 SUN Microsystems, Inc. -BCP: 91 J. Ihren -Category: Best Current Practice Autonomica - September 2004 - - - DNS IPv6 Transport Operational Guidelines - -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. - -Copyright Notice - - Copyright (C) The Internet Society (2004). - -Abstract - - This memo provides guidelines and Best Current Practice for operating - DNS in a world where queries and responses are carried in a mixed - environment of IPv4 and IPv6 networks. - -1. Introduction to the Problem of Name Space Fragmentation: - following the referral chain - - A resolver that tries to look up a name starts out at the root, and - follows referrals until it is referred to a name server that is - authoritative for the name. If somewhere down the chain of referrals - it is referred to a name server that is only accessible over a - transport which the resolver cannot use, the resolver is unable to - finish the task. - - When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is - only a matter of time until this starts to happen. The complete DNS - hierarchy then starts to fragment into a graph where authoritative - name servers for certain nodes are only accessible over a certain - transport. The concern is that a resolver using only a particular - version of IP and querying information about another node using the - same version of IP can not do it because somewhere in the chain of - servers accessed during the resolution process, one or more of them - will only be accessible with the other version of IP. - - With all DNS data only available over IPv4 transport everything is - simple. IPv4 resolvers can use the intended mechanism of following - referrals from the root and down while IPv6 resolvers have to work - - - -Durand & Ihren Best Current Practice [Page 1] - -RFC 3901 DNS IPv6 Transport Guidelines September 2004 - - - through a "translator", i.e., they have to use a recursive name - server on a so-called "dual stack" host as a "forwarder" since they - cannot access the DNS data directly. - - With all DNS data only available over IPv6 transport everything would - be equally simple, with the exception of IPv4 recursive name servers - having to switch to a forwarding configuration. - - However, the second situation will not arise in the foreseeable - future. Instead, the transition will be from IPv4 only to a mixture - of IPv4 and IPv6, with three categories of DNS data depending on - whether the information is available only over IPv4 transport, only - over IPv6 or both. - - Having DNS data available on both transports is the best situation. - The major question is how to ensure that it becomes the norm as - quickly as possible. However, while it is obvious that some DNS data - will only be available over v4 transport for a long time it is also - obvious that it is important to avoid fragmenting the name space - available to IPv4 only hosts. For example, during transition it is - not acceptable to break the name space that we presently have - available for IPv4-only hosts. - -2. Terminology - - The phrase "IPv4 name server" indicates a name server available over - IPv4 transport. It does not imply anything about what DNS [1,2] data - is served. Likewise, "IPv6 [4,5,6] name server" indicates a name - server available over IPv6 transport. The phrase "dual-stack name - server" indicates a name server that is actually configured to run - both protocols, IPv4 and IPv6, and not merely a server running on a - system capable of running both but actually configured to run only - one. - -3. Policy Based Avoidance of Name Space Fragmentation - - Today there are only a few DNS "zones" on the public Internet that - are available over IPv6 transport, and most of them can be regarded - as "experimental". However, as soon as the root and top level - domains are available over IPv6 transport, it is reasonable to expect - that it will become more common to have zones served by IPv6 servers. - - Having those zones served only by IPv6-only name server would not be - a good development, since this will fragment the previously - unfragmented IPv4 name space and there are strong reasons to find a - mechanism to avoid it. - - - - - -Durand & Ihren Best Current Practice [Page 2] - -RFC 3901 DNS IPv6 Transport Guidelines September 2004 - - - The recommended approach to maintain name space continuity is to use - administrative policies, as described in the next section. - -4. DNS IPv6 Transport recommended Guidelines - - In order to preserve name space continuity, the following - administrative policies are recommended: - - - every recursive name server SHOULD be either IPv4-only or dual - stack, - - This rules out IPv6-only recursive servers. However, one might - design configurations where a chain of IPv6-only name server - forward queries to a set of dual stack recursive name server - actually performing those recursive queries. - - - every DNS zone SHOULD be served by at least one IPv4-reachable - authoritative name server. - - This rules out DNS zones served only by IPv6-only authoritative - name servers. - - Note: zone validation processes SHOULD ensure that there is at least - one IPv4 address record available for the name servers of any child - delegations within the zone. - -5. Security Considerations - - The guidelines described in this memo introduce no new security - considerations into the DNS protocol or associated operational - scenarios. - -6. Acknowledgment - - This document is the result of many conversations that happened in - the DNS community at IETF and elsewhere since 2001. During that - period of time, a number of Internet drafts have been published to - clarify various aspects of the issues at stake. This document - focuses on the conclusion of those discussions. - - The authors would like to acknowledge the role of Pekka Savola in his - thorough review of the document. - - - - - - - - - -Durand & Ihren Best Current Practice [Page 3] - -RFC 3901 DNS IPv6 Transport Guidelines September 2004 - - -7. Normative References - - [1] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [2] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP - 9, RFC 2026, October 1996. - - [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) - Specification", RFC 2460, December 1998. - - [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) - Addressing Architecture", RFC 3513, April 2003. - - [6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS - Extensions to Support IP Version 6", RFC 3596, October 2003. - -8. Authors' Addresses - - Alain Durand - SUN Microsystems, Inc - 17 Network circle UMPK17-202 - Menlo Park, CA, 94025 - USA - - EMail: Alain.Durand@sun.com - - - Johan Ihren - Autonomica - Bellmansgatan 30 - SE-118 47 Stockholm - Sweden - - EMail: johani@autonomica.se - - - - - - - - - - - - - -Durand & Ihren Best Current Practice [Page 4] - -RFC 3901 DNS IPv6 Transport Guidelines September 2004 - - -9. Full Copyright Statement - - Copyright (C) The Internet Society (2004). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE - REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE - INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR - IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the IETF's procedures with respect to rights in IETF Documents can - be found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Durand & Ihren Best Current Practice [Page 5] - diff --git a/contrib/bind9/doc/rfc/rfc4025.txt b/contrib/bind9/doc/rfc/rfc4025.txt deleted file mode 100644 index 92e7f4007956..000000000000 --- a/contrib/bind9/doc/rfc/rfc4025.txt +++ /dev/null @@ -1,675 +0,0 @@ - - - - - - -Network Working Group M. Richardson -Request for Comments: 4025 SSW -Category: Standards Track February 2005 - - - A Method for Storing IPsec Keying Material in DNS - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This document describes a new resource record for the Domain Name - System (DNS). This record may be used to store public keys for use - in IP security (IPsec) systems. The record also includes provisions - for indicating what system should be contacted when an IPsec tunnel - is established with the entity in question. - - This record replaces the functionality of the sub-type #4 of the KEY - Resource Record, which has been obsoleted by RFC 3445. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2 - 1.2. Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and - IP6.ARPA) . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.3. Usage Criteria . . . . . . . . . . . . . . . . . . . . . 3 - 2. Storage Formats . . . . . . . . . . . . . . . . . . . . . . . 3 - 2.1. IPSECKEY RDATA Format . . . . . . . . . . . . . . . . . 3 - 2.2. RDATA Format - Precedence . . . . . . . . . . . . . . . 4 - 2.3. RDATA Format - Gateway Type . . . . . . . . . . . . . . 4 - 2.4. RDATA Format - Algorithm Type . . . . . . . . . . . . . 4 - 2.5. RDATA Format - Gateway . . . . . . . . . . . . . . . . . 5 - 2.6. RDATA Format - Public Keys . . . . . . . . . . . . . . . 5 - 3. Presentation Formats . . . . . . . . . . . . . . . . . . . . . 6 - 3.1. Representation of IPSECKEY RRs . . . . . . . . . . . . . 6 - 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 - - - -Richardson Standards Track [Page 1] - -RFC 4025 Storing IPsec Keying Material in DNS February 2005 - - - 4.1. Active Attacks Against Unsecured IPSECKEY Resource - Records . . . . . . . . . . . . . . . . . . . . . . . . 8 - 4.1.1. Active Attacks Against IPSECKEY Keying - Materials. . . . . . . . . . . . . . . . . . . . 8 - 4.1.2. Active Attacks Against IPSECKEY Gateway - Material. . . . . . . . . . . . . . . . . . . . 8 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 - 7.2. Informative References . . . . . . . . . . . . . . . . . 10 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 12 - -1. Introduction - - Suppose a host wishes (or is required by policy) to establish an - IPsec tunnel with some remote entity on the network prior to allowing - normal communication to take place. In many cases, this end system - will be able to determine the DNS name for the remote entity (either - by having the DNS name given explicitly, by performing a DNS PTR - query for a particular IP address, or through some other means, e.g., - by extracting the DNS portion of a "user@FQDN" name for a remote - entity). In these cases, the host will need to obtain a public key - to authenticate the remote entity, and may also need some guidance - about whether it should contact the entity directly or use another - node as a gateway to the target entity. The IPSECKEY RR provides a - mechanism for storing such information. - - The type number for the IPSECKEY RR is 45. - - This record replaces the functionality of the sub-type #4 of the KEY - Resource Record, which has been obsoleted by RFC 3445 [11]. - -1.1. Overview - - The IPSECKEY resource record (RR) is used to publish a public key - that is to be associated with a Domain Name System (DNS) [1] name for - use with the IPsec protocol suite. This can be the public key of a - host, network, or application (in the case of per-port keying). - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [3]. - - - - - - - -Richardson Standards Track [Page 2] - -RFC 4025 Storing IPsec Keying Material in DNS February 2005 - - -1.2. Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and IP6.ARPA) - - Often a security gateway will only have access to the IP address of - the node with which communication is desired and will not know any - other name for the target node. Because of this, frequently the best - way of looking up IPSECKEY RRs will be by using the IP address as an - index into one of the reverse mapping trees (IN-ADDR.ARPA for IPv4 or - IP6.ARPA for IPv6). - - The lookup is done in the fashion usual for PTR records. The IP - address' octets (IPv4) or nibbles (IPv6) are reversed and looked up - with the appropriate suffix. Any CNAMEs or DNAMEs found MUST be - followed. - - Note: even when the IPsec function is contained in the end-host, - often only the application will know the forward name used. Although - the case where the application knows the forward name is common, the - user could easily have typed in a literal IP address. This storage - mechanism does not preclude using the forward name when it is - available but does not require it. - -1.3. Usage Criteria - - An IPSECKEY resource record SHOULD be used in combination with DNSSEC - [8] unless some other means of authenticating the IPSECKEY resource - record is available. - - It is expected that there will often be multiple IPSECKEY resource - records at the same name. This will be due to the presence of - multiple gateways and a need to roll over keys. - - This resource record is class independent. - -2. Storage Formats - -2.1. IPSECKEY RDATA Format - - The RDATA for an IPSECKEY RR consists of a precedence value, a - gateway type, a public key, algorithm type, and an optional gateway - address. - - - - - - - - - - - -Richardson Standards Track [Page 3] - -RFC 4025 Storing IPsec Keying Material in DNS February 2005 - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | precedence | gateway type | algorithm | gateway | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ + - ~ gateway ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | / - / public key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - -2.2. RDATA Format - Precedence - - This is an 8-bit precedence for this record. It is interpreted in - the same way as the PREFERENCE field described in section 3.3.9 of - RFC 1035 [2]. - - Gateways listed in IPSECKEY records with lower precedence are to be - attempted first. Where there is a tie in precedence, the order - should be non-deterministic. - -2.3. RDATA Format - Gateway Type - - The gateway type field indicates the format of the information that - is stored in the gateway field. - - The following values are defined: - 0 No gateway is present. - 1 A 4-byte IPv4 address is present. - 2 A 16-byte IPv6 address is present. - 3 A wire-encoded domain name is present. The wire-encoded format is - self-describing, so the length is implicit. The domain name MUST - NOT be compressed. (See Section 3.3 of RFC 1035 [2].) - -2.4. RDATA Format - Algorithm Type - - The algorithm type field identifies the public key's cryptographic - algorithm and determines the format of the public key field. - - A value of 0 indicates that no key is present. - - The following values are defined: - 1 A DSA key is present, in the format defined in RFC 2536 [9]. - 2 A RSA key is present, in the format defined in RFC 3110 [10]. - - - - - - -Richardson Standards Track [Page 4] - -RFC 4025 Storing IPsec Keying Material in DNS February 2005 - - -2.5. RDATA Format - Gateway - - The gateway field indicates a gateway to which an IPsec tunnel may be - created in order to reach the entity named by this resource record. - - There are three formats: - - A 32-bit IPv4 address is present in the gateway field. The data - portion is an IPv4 address as described in section 3.4.1 of RFC 1035 - [2]. This is a 32-bit number in network byte order. - - A 128-bit IPv6 address is present in the gateway field. The data - portion is an IPv6 address as described in section 2.2 of RFC 3596 - [12]. This is a 128-bit number in network byte order. - - The gateway field is a normal wire-encoded domain name, as described - in section 3.3 of RFC 1035 [2]. Compression MUST NOT be used. - -2.6. RDATA Format - Public Keys - - Both the public key types defined in this document (RSA and DSA) - inherit their public key formats from the corresponding KEY RR - formats. Specifically, the public key field contains the - algorithm-specific portion of the KEY RR RDATA, which is all the KEY - RR DATA after the first four octets. This is the same portion of the - KEY RR that must be specified by documents that define a DNSSEC - algorithm. Those documents also specify a message digest to be used - for generation of SIG RRs; that specification is not relevant for - IPSECKEY RRs. - - Future algorithms, if they are to be used by both DNSSEC (in the KEY - RR) and IPSECKEY, are likely to use the same public key encodings in - both records. Unless otherwise specified, the IPSECKEY public key - field will contain the algorithm-specific portion of the KEY RR RDATA - for the corresponding algorithm. The algorithm must still be - designated for use by IPSECKEY, and an IPSECKEY algorithm type number - (which might be different from the DNSSEC algorithm number) must be - assigned to it. - - The DSA key format is defined in RFC 2536 [9] - - The RSA key format is defined in RFC 3110 [10], with the following - changes: - - The earlier definition of RSA/MD5 in RFC 2065 [4] limited the - exponent and modulus to 2552 bits in length. RFC 3110 extended that - limit to 4096 bits for RSA/SHA1 keys. The IPSECKEY RR imposes no - length limit on RSA public keys, other than the 65535 octet limit - - - -Richardson Standards Track [Page 5] - -RFC 4025 Storing IPsec Keying Material in DNS February 2005 - - - imposed by the two-octet length encoding. This length extension is - applicable only to IPSECKEY; it is not applicable to KEY RRs. - -3. Presentation Formats - -3.1. Representation of IPSECKEY RRs - - IPSECKEY RRs may appear in a zone data master file. The precedence, - gateway type, algorithm, and gateway fields are REQUIRED. The base64 - encoded public key block is OPTIONAL; if it is not present, the - public key field of the resource record MUST be construed to be zero - octets in length. - - The algorithm field is an unsigned integer. No mnemonics are - defined. - - If no gateway is to be indicated, then the gateway type field MUST be - zero, and the gateway field MUST be "." - - The Public Key field is represented as a Base64 encoding of the - Public Key. Whitespace is allowed within the Base64 text. For a - definition of Base64 encoding, see RFC 3548 [6], Section 5.2. - - The general presentation for the record is as follows: - - IN IPSECKEY ( precedence gateway-type algorithm - gateway base64-encoded-public-key ) - -3.2. Examples - - An example of a node, 192.0.2.38, that will accept IPsec tunnels on - its own behalf. - - 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 - 192.0.2.38 - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - An example of a node, 192.0.2.38, that has published its key only. - - 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2 - . - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - - - - - - - - -Richardson Standards Track [Page 6] - -RFC 4025 Storing IPsec Keying Material in DNS February 2005 - - - An example of a node, 192.0.2.38, that has delegated authority to the - node 192.0.2.3. - - 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 - 192.0.2.3 - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - An example of a node, 192.0.1.38 that has delegated authority to the - node with the identity "mygateway.example.com". - - 38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2 - mygateway.example.com. - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0, that has - delegated authority to the node 2001:0DB8:c000:0200:2::1 - - $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa. - 0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2 - 2001:0DB8:0:8002::2000:1 - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - -4. Security Considerations - - This entire memo pertains to the provision of public keying material - for use by key management protocols such as ISAKMP/IKE (RFC 2407) - [7]. - - The IPSECKEY resource record contains information that SHOULD be - communicated to the end client in an integral fashion; i.e., free - from modification. The form of this channel is up to the consumer of - the data; there must be a trust relationship between the end consumer - of this resource record and the server. This relationship may be - end-to-end DNSSEC validation, a TSIG or SIG(0) channel to another - secure source, a secure local channel on the host, or some - combination of the above. - - The keying material provided by the IPSECKEY resource record is not - sensitive to passive attacks. The keying material may be freely - disclosed to any party without any impact on the security properties - of the resulting IPsec session. IPsec and IKE provide defense - against both active and passive attacks. - - Any derivative specification that makes use of this resource record - MUST carefully document its trust model and why the trust model of - DNSSEC is appropriate, if that is the secure channel used. - - - - - -Richardson Standards Track [Page 7] - -RFC 4025 Storing IPsec Keying Material in DNS February 2005 - - - An active attack on the DNS that caused the wrong IP address to be - retrieved (via forged address), and therefore the wrong QNAME to be - queried, would also result in a man-in-the-middle attack. This - situation is independent of whether the IPSECKEY RR is used. - -4.1. Active Attacks Against Unsecured IPSECKEY Resource Records - - This section deals with active attacks against the DNS. These - attacks require that DNS requests and responses be intercepted and - changed. DNSSEC is designed to defend against attacks of this kind. - This section deals with the situation in which DNSSEC is not - available. This is not the recommended deployment scenario. - -4.1.1. Active Attacks Against IPSECKEY Keying Materials - - The first kind of active attack is when the attacker replaces the - keying material with either a key under its control or with garbage. - - The gateway field is either untouched or is null. The IKE - negotiation will therefore occur with the original end-system. For - this attack to succeed, the attacker must perform a man-in-the-middle - attack on the IKE negotiation. This attack requires that the - attacker be able to intercept and modify packets on the forwarding - path for the IKE and data packets. - - If the attacker is not able to perform this man-in-the-middle attack - on the IKE negotiation, then a denial of service will result, as the - IKE negotiation will fail. - - If the attacker is not only able to mount active attacks against DNS - but also in a position to perform a man-in-the-middle attack on IKE - and IPsec negotiations, then the attacker will be able to compromise - the resulting IPsec channel. Note that an attacker must be able to - perform active DNS attacks on both sides of the IKE negotiation for - this to succeed. - -4.1.2. Active Attacks Against IPSECKEY Gateway Material - - The second kind of active attack is one in which the attacker - replaces the gateway address to point to a node under the attacker's - control. The attacker then either replaces the public key or removes - it. If the public key were removed, then the attacker could provide - an accurate public key of its own in a second record. - - This second form creates a simple man-in-the-middle attacks since the - attacker can then create a second tunnel to the real destination. - Note that, as before, this requires that the attacker also mount an - active attack against the responder. - - - -Richardson Standards Track [Page 8] - -RFC 4025 Storing IPsec Keying Material in DNS February 2005 - - - Note that the man-in-the-middle cannot just forward cleartext packets - to the original destination. While the destination may be willing to - speak in the clear, replying to the original sender, the sender will - already have created a policy expecting ciphertext. Thus, the - attacker will need to intercept traffic in both directions. In some - cases, the attacker may be able to accomplish the full intercept by - use of Network Address/Port Translation (NAT/NAPT) technology. - - This attack is easier than the first one because the attacker does - NOT need to be on the end-to-end forwarding path. The attacker need - only be able to modify DNS replies. This can be done by packet - modification, by various kinds of race attacks, or through methods - that pollute DNS caches. - - If the end-to-end integrity of the IPSECKEY RR is suspect, the end - client MUST restrict its use of the IPSECKEY RR to cases where the RR - owner name matches the content of the gateway field. As the RR owner - name is assumed when the gateway field is null, a null gateway field - is considered a match. - - Thus, any records obtained under unverified conditions (e.g., no - DNSSEC or trusted path to source) that have a non-null gateway field - MUST be ignored. - - This restriction eliminates attacks against the gateway field, which - are considered much easier, as the attack does not need to be on the - forwarding path. - - In the case of an IPSECKEY RR with a value of three in its gateway - type field, the gateway field contains a domain name. The subsequent - query required to translate that name into an IP address or IPSECKEY - RR will also be subject to man-in-the-middle attacks. If the - end-to-end integrity of this second query is suspect, then the - provisions above also apply. The IPSECKEY RR MUST be ignored - whenever the resulting gateway does not match the QNAME of the - original IPSECKEY RR query. - -5. IANA Considerations - - This document updates the IANA Registry for DNS Resource Record Types - by assigning type 45 to the IPSECKEY record. - - This document creates two new IANA registries, both specific to the - IPSECKEY Resource Record: - - This document creates an IANA registry for the algorithm type field. - - - - - -Richardson Standards Track [Page 9] - -RFC 4025 Storing IPsec Keying Material in DNS February 2005 - - - Values 0, 1, and 2 are defined in Section 2.4. Algorithm numbers 3 - through 255 can be assigned by IETF Consensus (see RFC 2434 [5]). - - This document creates an IANA registry for the gateway type field. - - Values 0, 1, 2, and 3 are defined in Section 2.3. Gateway type - numbers 4 through 255 can be assigned by Standards Action (see RFC - 2434 [5]). - -6. Acknowledgements - - My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob - Austein, and Olafur Gudmundsson, who reviewed this document - carefully. Additional thanks to Olafur Gurmundsson for a reference - implementation. - -7. References - -7.1. Normative References - - [1] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [2] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [4] Eastlake 3rd, D. and C. Kaufman, "Domain Name System Security - Extensions", RFC 2065, January 1997. - - [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - - [6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", - RFC 3548, July 2003. - -7.2. Informative References - - [7] Piper, D., "The Internet IP Security Domain of Interpretation - for ISAKMP", RFC 2407, November 1998. - - [8] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [9] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System - (DNS)", RFC 2536, March 1999. - - - -Richardson Standards Track [Page 10] - -RFC 4025 Storing IPsec Keying Material in DNS February 2005 - - - [10] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain - Name System (DNS)", RFC 3110, May 2001. - - [11] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource - Record (RR)", RFC 3445, December 2002. - - [12] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS - Extensions to Support IP Version 6", RFC 3596, October 2003. - -Author's Address - - Michael C. Richardson - Sandelman Software Works - 470 Dawson Avenue - Ottawa, ON K1Z 5V7 - CA - - EMail: mcr@sandelman.ottawa.on.ca - URI: http://www.sandelman.ottawa.on.ca/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Richardson Standards Track [Page 11] - -RFC 4025 Storing IPsec Keying Material in DNS February 2005 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2005). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the IETF's procedures with respect to rights in IETF Documents can - be found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Richardson Standards Track [Page 12] - diff --git a/contrib/bind9/doc/rfc/rfc4033.txt b/contrib/bind9/doc/rfc/rfc4033.txt deleted file mode 100644 index 7f0a46477319..000000000000 --- a/contrib/bind9/doc/rfc/rfc4033.txt +++ /dev/null @@ -1,1179 +0,0 @@ - - - - - - -Network Working Group R. Arends -Request for Comments: 4033 Telematica Instituut -Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein - 3755, 3757, 3845 ISC -Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson - 3007, 3597, 3226 VeriSign -Category: Standards Track D. Massey - Colorado State University - S. Rose - NIST - March 2005 - - - DNS Security Introduction and Requirements - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - The Domain Name System Security Extensions (DNSSEC) add data origin - authentication and data integrity to the Domain Name System. This - document introduces these extensions and describes their capabilities - and limitations. This document also discusses the services that the - DNS security extensions do and do not provide. Last, this document - describes the interrelationships between the documents that - collectively describe DNSSEC. - - - - - - - - - - - - - - - -Arends, et al. Standards Track [Page 1] - -RFC 4033 DNS Security Introduction and Requirements March 2005 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . 3 - 3. Services Provided by DNS Security . . . . . . . . . . . . . 7 - 3.1. Data Origin Authentication and Data Integrity . . . . 7 - 3.2. Authenticating Name and Type Non-Existence . . . . . . 9 - 4. Services Not Provided by DNS Security . . . . . . . . . . . 9 - 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . 9 - 6. Resolver Considerations . . . . . . . . . . . . . . . . . . 10 - 7. Stub Resolver Considerations . . . . . . . . . . . . . . . . 11 - 8. Zone Considerations . . . . . . . . . . . . . . . . . . . . 12 - 8.1. TTL Values vs. RRSIG Validity Period . . . . . . . . . 13 - 8.2. New Temporal Dependency Issues for Zones . . . . . . . 13 - 9. Name Server Considerations . . . . . . . . . . . . . . . . . 13 - 10. DNS Security Document Family . . . . . . . . . . . . . . . . 14 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 - 12. Security Considerations . . . . . . . . . . . . . . . . . . 15 - 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 - 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 14.1. Normative References . . . . . . . . . . . . . . . . . 17 - 14.2. Informative References . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 21 - -1. Introduction - - This document introduces the Domain Name System Security Extensions - (DNSSEC). This document and its two companion documents ([RFC4034] - and [RFC4035]) update, clarify, and refine the security extensions - defined in [RFC2535] and its predecessors. These security extensions - consist of a set of new resource record types and modifications to - the existing DNS protocol ([RFC1035]). The new records and protocol - modifications are not fully described in this document, but are - described in a family of documents outlined in Section 10. Sections - 3 and 4 describe the capabilities and limitations of the security - extensions in greater detail. Section 5 discusses the scope of the - document set. Sections 6, 7, 8, and 9 discuss the effect that these - security extensions will have on resolvers, stub resolvers, zones, - and name servers. - - This document and its two companions obsolete [RFC2535], [RFC3008], - [RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and - [RFC3845]. This document set also updates but does not obsolete - [RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225], - [RFC3007], [RFC3597], and the portions of [RFC3226] that deal with - DNSSEC. - - - - -Arends, et al. Standards Track [Page 2] - -RFC 4033 DNS Security Introduction and Requirements March 2005 - - - The DNS security extensions provide origin authentication and - integrity protection for DNS data, as well as a means of public key - distribution. These extensions do not provide confidentiality. - -2. Definitions of Important DNSSEC Terms - - This section defines a number of terms used in this document set. - Because this is intended to be useful as a reference while reading - the rest of the document set, first-time readers may wish to skim - this section quickly, read the rest of this document, and then come - back to this section. - - Authentication Chain: An alternating sequence of DNS public key - (DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of - signed data, with each link in the chain vouching for the next. A - DNSKEY RR is used to verify the signature covering a DS RR and - allows the DS RR to be authenticated. The DS RR contains a hash - of another DNSKEY RR and this new DNSKEY RR is authenticated by - matching the hash in the DS RR. This new DNSKEY RR in turn - authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in - this set may be used to authenticate another DS RR, and so forth - until the chain finally ends with a DNSKEY RR whose corresponding - private key signs the desired DNS data. For example, the root - DNSKEY RRset can be used to authenticate the DS RRset for - "example." The "example." DS RRset contains a hash that matches - some "example." DNSKEY, and this DNSKEY's corresponding private - key signs the "example." DNSKEY RRset. Private key counterparts - of the "example." DNSKEY RRset sign data records such as - "www.example." and DS RRs for delegations such as - "subzone.example." - - Authentication Key: A public key that a security-aware resolver has - verified and can therefore use to authenticate data. A - security-aware resolver can obtain authentication keys in three - ways. First, the resolver is generally configured to know about - at least one public key; this configured data is usually either - the public key itself or a hash of the public key as found in the - DS RR (see "trust anchor"). Second, the resolver may use an - authenticated public key to verify a DS RR and the DNSKEY RR to - which the DS RR refers. Third, the resolver may be able to - determine that a new public key has been signed by the private key - corresponding to another public key that the resolver has - verified. Note that the resolver must always be guided by local - policy when deciding whether to authenticate a new public key, - even if the local policy is simply to authenticate any new public - key for which the resolver is able verify the signature. - - - - - -Arends, et al. Standards Track [Page 3] - -RFC 4033 DNS Security Introduction and Requirements March 2005 - - - Authoritative RRset: Within the context of a particular zone, an - RRset is "authoritative" if and only if the owner name of the - RRset lies within the subset of the name space that is at or below - the zone apex and at or above the cuts that separate the zone from - its children, if any. All RRsets at the zone apex are - authoritative, except for certain RRsets at this domain name that, - if present, belong to this zone's parent. These RRset could - include a DS RRset, the NSEC RRset referencing this DS RRset (the - "parental NSEC"), and RRSIG RRs associated with these RRsets, all - of which are authoritative in the parent zone. Similarly, if this - zone contains any delegation points, only the parental NSEC RRset, - DS RRsets, and any RRSIG RRs associated with these RRsets are - authoritative for this zone. - - Delegation Point: Term used to describe the name at the parental side - of a zone cut. That is, the delegation point for "foo.example" - would be the foo.example node in the "example" zone (as opposed to - the zone apex of the "foo.example" zone). See also zone apex. - - Island of Security: Term used to describe a signed, delegated zone - that does not have an authentication chain from its delegating - parent. That is, there is no DS RR containing a hash of a DNSKEY - RR for the island in its delegating parent zone (see [RFC4034]). - An island of security is served by security-aware name servers and - may provide authentication chains to any delegated child zones. - Responses from an island of security or its descendents can only - be authenticated if its authentication keys can be authenticated - by some trusted means out of band from the DNS protocol. - - Key Signing Key (KSK): An authentication key that corresponds to a - private key used to sign one or more other authentication keys for - a given zone. Typically, the private key corresponding to a key - signing key will sign a zone signing key, which in turn has a - corresponding private key that will sign other zone data. Local - policy may require that the zone signing key be changed - frequently, while the key signing key may have a longer validity - period in order to provide a more stable secure entry point into - the zone. Designating an authentication key as a key signing key - is purely an operational issue: DNSSEC validation does not - distinguish between key signing keys and other DNSSEC - authentication keys, and it is possible to use a single key as - both a key signing key and a zone signing key. Key signing keys - are discussed in more detail in [RFC3757]. Also see zone signing - key. - - - - - - - -Arends, et al. Standards Track [Page 4] - -RFC 4033 DNS Security Introduction and Requirements March 2005 - - - Non-Validating Security-Aware Stub Resolver: A security-aware stub - resolver that trusts one or more security-aware recursive name - servers to perform most of the tasks discussed in this document - set on its behalf. In particular, a non-validating security-aware - stub resolver is an entity that sends DNS queries, receives DNS - responses, and is capable of establishing an appropriately secured - channel to a security-aware recursive name server that will - provide these services on behalf of the security-aware stub - resolver. See also security-aware stub resolver, validating - security-aware stub resolver. - - Non-Validating Stub Resolver: A less tedious term for a - non-validating security-aware stub resolver. - - Security-Aware Name Server: An entity acting in the role of a name - server (defined in section 2.4 of [RFC1034]) that understands the - DNS security extensions defined in this document set. In - particular, a security-aware name server is an entity that - receives DNS queries, sends DNS responses, supports the EDNS0 - ([RFC2671]) message size extension and the DO bit ([RFC3225]), and - supports the RR types and message header bits defined in this - document set. - - Security-Aware Recursive Name Server: An entity that acts in both the - security-aware name server and security-aware resolver roles. A - more cumbersome but equivalent phrase would be "a security-aware - name server that offers recursive service". - - Security-Aware Resolver: An entity acting in the role of a resolver - (defined in section 2.4 of [RFC1034]) that understands the DNS - security extensions defined in this document set. In particular, - a security-aware resolver is an entity that sends DNS queries, - receives DNS responses, supports the EDNS0 ([RFC2671]) message - size extension and the DO bit ([RFC3225]), and is capable of using - the RR types and message header bits defined in this document set - to provide DNSSEC services. - - Security-Aware Stub Resolver: An entity acting in the role of a stub - resolver (defined in section 5.3.1 of [RFC1034]) that has enough - of an understanding the DNS security extensions defined in this - document set to provide additional services not available from a - security-oblivious stub resolver. Security-aware stub resolvers - may be either "validating" or "non-validating", depending on - whether the stub resolver attempts to verify DNSSEC signatures on - its own or trusts a friendly security-aware name server to do so. - See also validating stub resolver, non-validating stub resolver. - - - - - -Arends, et al. Standards Track [Page 5] - -RFC 4033 DNS Security Introduction and Requirements March 2005 - - - Security-Oblivious <anything>: An <anything> that is not - "security-aware". - - Signed Zone: A zone whose RRsets are signed and that contains - properly constructed DNSKEY, Resource Record Signature (RRSIG), - Next Secure (NSEC), and (optionally) DS records. - - Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A - validating security-aware resolver uses this public key or hash as - a starting point for building the authentication chain to a signed - DNS response. In general, a validating resolver will have to - obtain the initial values of its trust anchors via some secure or - trusted means outside the DNS protocol. Presence of a trust - anchor also implies that the resolver should expect the zone to - which the trust anchor points to be signed. - - Unsigned Zone: A zone that is not signed. - - Validating Security-Aware Stub Resolver: A security-aware resolver - that sends queries in recursive mode but that performs signature - validation on its own rather than just blindly trusting an - upstream security-aware recursive name server. See also - security-aware stub resolver, non-validating security-aware stub - resolver. - - Validating Stub Resolver: A less tedious term for a validating - security-aware stub resolver. - - Zone Apex: Term used to describe the name at the child's side of a - zone cut. See also delegation point. - - Zone Signing Key (ZSK): An authentication key that corresponds to a - private key used to sign a zone. Typically, a zone signing key - will be part of the same DNSKEY RRset as the key signing key whose - corresponding private key signs this DNSKEY RRset, but the zone - signing key is used for a slightly different purpose and may - differ from the key signing key in other ways, such as validity - lifetime. Designating an authentication key as a zone signing key - is purely an operational issue; DNSSEC validation does not - distinguish between zone signing keys and other DNSSEC - authentication keys, and it is possible to use a single key as - both a key signing key and a zone signing key. See also key - signing key. - - - - - - - - -Arends, et al. Standards Track [Page 6] - -RFC 4033 DNS Security Introduction and Requirements March 2005 - - -3. Services Provided by DNS Security - - The Domain Name System (DNS) security extensions provide origin - authentication and integrity assurance services for DNS data, - including mechanisms for authenticated denial of existence of DNS - data. These mechanisms are described below. - - These mechanisms require changes to the DNS protocol. DNSSEC adds - four new resource record types: Resource Record Signature (RRSIG), - DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure - (NSEC). It also adds two new message header bits: Checking Disabled - (CD) and Authenticated Data (AD). In order to support the larger DNS - message sizes that result from adding the DNSSEC RRs, DNSSEC also - requires EDNS0 support ([RFC2671]). Finally, DNSSEC requires support - for the DNSSEC OK (DO) EDNS header bit ([RFC3225]) so that a - security-aware resolver can indicate in its queries that it wishes to - receive DNSSEC RRs in response messages. - - These services protect against most of the threats to the Domain Name - System described in [RFC3833]. Please see Section 12 for a - discussion of the limitations of these extensions. - -3.1. Data Origin Authentication and Data Integrity - - DNSSEC provides authentication by associating cryptographically - generated digital signatures with DNS RRsets. These digital - signatures are stored in a new resource record, the RRSIG record. - Typically, there will be a single private key that signs a zone's - data, but multiple keys are possible. For example, there may be keys - for each of several different digital signature algorithms. If a - security-aware resolver reliably learns a zone's public key, it can - authenticate that zone's signed data. An important DNSSEC concept is - that the key that signs a zone's data is associated with the zone - itself and not with the zone's authoritative name servers. (Public - keys for DNS transaction authentication mechanisms may also appear in - zones, as described in [RFC2931], but DNSSEC itself is concerned with - object security of DNS data, not channel security of DNS - transactions. The keys associated with transaction security may be - stored in different RR types. See [RFC3755] for details.) - - A security-aware resolver can learn a zone's public key either by - having a trust anchor configured into the resolver or by normal DNS - resolution. To allow the latter, public keys are stored in a new - type of resource record, the DNSKEY RR. Note that the private keys - used to sign zone data must be kept secure and should be stored - offline when practical. To discover a public key reliably via DNS - resolution, the target key itself has to be signed by either a - configured authentication key or another key that has been - - - -Arends, et al. Standards Track [Page 7] - -RFC 4033 DNS Security Introduction and Requirements March 2005 - - - authenticated previously. Security-aware resolvers authenticate zone - information by forming an authentication chain from a newly learned - public key back to a previously known authentication public key, - which in turn either has been configured into the resolver or must - have been learned and verified previously. Therefore, the resolver - must be configured with at least one trust anchor. - - If the configured trust anchor is a zone signing key, then it will - authenticate the associated zone; if the configured key is a key - signing key, it will authenticate a zone signing key. If the - configured trust anchor is the hash of a key rather than the key - itself, the resolver may have to obtain the key via a DNS query. To - help security-aware resolvers establish this authentication chain, - security-aware name servers attempt to send the signature(s) needed - to authenticate a zone's public key(s) in the DNS reply message along - with the public key itself, provided that there is space available in - the message. - - The Delegation Signer (DS) RR type simplifies some of the - administrative tasks involved in signing delegations across - organizational boundaries. The DS RRset resides at a delegation - point in a parent zone and indicates the public key(s) corresponding - to the private key(s) used to self-sign the DNSKEY RRset at the - delegated child zone's apex. The administrator of the child zone, in - turn, uses the private key(s) corresponding to one or more of the - public keys in this DNSKEY RRset to sign the child zone's data. The - typical authentication chain is therefore - DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more - DS->DNSKEY subchains. DNSSEC permits more complex authentication - chains, such as additional layers of DNSKEY RRs signing other DNSKEY - RRs within a zone. - - A security-aware resolver normally constructs this authentication - chain from the root of the DNS hierarchy down to the leaf zones based - on configured knowledge of the public key for the root. Local - policy, however, may also allow a security-aware resolver to use one - or more configured public keys (or hashes of public keys) other than - the root public key, may not provide configured knowledge of the root - public key, or may prevent the resolver from using particular public - keys for arbitrary reasons, even if those public keys are properly - signed with verifiable signatures. DNSSEC provides mechanisms by - which a security-aware resolver can determine whether an RRset's - signature is "valid" within the meaning of DNSSEC. In the final - analysis, however, authenticating both DNS keys and data is a matter - of local policy, which may extend or even override the protocol - extensions defined in this document set. See Section 5 for further - discussion. - - - - -Arends, et al. Standards Track [Page 8] - -RFC 4033 DNS Security Introduction and Requirements March 2005 - - -3.2. Authenticating Name and Type Non-Existence - - The security mechanism described in Section 3.1 only provides a way - to sign existing RRsets in a zone. The problem of providing negative - responses with the same level of authentication and integrity - requires the use of another new resource record type, the NSEC - record. The NSEC record allows a security-aware resolver to - authenticate a negative reply for either name or type non-existence - with the same mechanisms used to authenticate other DNS replies. Use - of NSEC records requires a canonical representation and ordering for - domain names in zones. Chains of NSEC records explicitly describe - the gaps, or "empty space", between domain names in a zone and list - the types of RRsets present at existing names. Each NSEC record is - signed and authenticated using the mechanisms described in Section - 3.1. - -4. Services Not Provided by DNS Security - - DNS was originally designed with the assumptions that the DNS will - return the same answer to any given query regardless of who may have - issued the query, and that all data in the DNS is thus visible. - Accordingly, DNSSEC is not designed to provide confidentiality, - access control lists, or other means of differentiating between - inquirers. - - DNSSEC provides no protection against denial of service attacks. - Security-aware resolvers and security-aware name servers are - vulnerable to an additional class of denial of service attacks based - on cryptographic operations. Please see Section 12 for details. - - The DNS security extensions provide data and origin authentication - for DNS data. The mechanisms outlined above are not designed to - protect operations such as zone transfers and dynamic update - ([RFC2136], [RFC3007]). Message authentication schemes described in - [RFC2845] and [RFC2931] address security operations that pertain to - these transactions. - -5. Scope of the DNSSEC Document Set and Last Hop Issues - - The specification in this document set defines the behavior for zone - signers and security-aware name servers and resolvers in such a way - that the validating entities can unambiguously determine the state of - the data. - - A validating resolver can determine the following 4 states: - - Secure: The validating resolver has a trust anchor, has a chain of - trust, and is able to verify all the signatures in the response. - - - -Arends, et al. Standards Track [Page 9] - -RFC 4033 DNS Security Introduction and Requirements March 2005 - - - Insecure: The validating resolver has a trust anchor, a chain of - trust, and, at some delegation point, signed proof of the - non-existence of a DS record. This indicates that subsequent - branches in the tree are provably insecure. A validating resolver - may have a local policy to mark parts of the domain space as - insecure. - - Bogus: The validating resolver has a trust anchor and a secure - delegation indicating that subsidiary data is signed, but the - response fails to validate for some reason: missing signatures, - expired signatures, signatures with unsupported algorithms, data - missing that the relevant NSEC RR says should be present, and so - forth. - - Indeterminate: There is no trust anchor that would indicate that a - specific portion of the tree is secure. This is the default - operation mode. - - This specification only defines how security-aware name servers can - signal non-validating stub resolvers that data was found to be bogus - (using RCODE=2, "Server Failure"; see [RFC4035]). - - There is a mechanism for security-aware name servers to signal - security-aware stub resolvers that data was found to be secure (using - the AD bit; see [RFC4035]). - - This specification does not define a format for communicating why - responses were found to be bogus or marked as insecure. The current - signaling mechanism does not distinguish between indeterminate and - insecure states. - - A method for signaling advanced error codes and policy between a - security-aware stub resolver and security-aware recursive nameservers - is a topic for future work, as is the interface between a security- - aware resolver and the applications that use it. Note, however, that - the lack of the specification of such communication does not prohibit - deployment of signed zones or the deployment of security aware - recursive name servers that prohibit propagation of bogus data to the - applications. - -6. Resolver Considerations - - A security-aware resolver has to be able to perform cryptographic - functions necessary to verify digital signatures using at least the - mandatory-to-implement algorithm(s). Security-aware resolvers must - also be capable of forming an authentication chain from a newly - learned zone back to an authentication key, as described above. This - process might require additional queries to intermediate DNS zones to - - - -Arends, et al. Standards Track [Page 10] - -RFC 4033 DNS Security Introduction and Requirements March 2005 - - - obtain necessary DNSKEY, DS, and RRSIG records. A security-aware - resolver should be configured with at least one trust anchor as the - starting point from which it will attempt to establish authentication - chains. - - If a security-aware resolver is separated from the relevant - authoritative name servers by a recursive name server or by any sort - of intermediary device that acts as a proxy for DNS, and if the - recursive name server or intermediary device is not security-aware, - the security-aware resolver may not be capable of operating in a - secure mode. For example, if a security-aware resolver's packets are - routed through a network address translation (NAT) device that - includes a DNS proxy that is not security-aware, the security-aware - resolver may find it difficult or impossible to obtain or validate - signed DNS data. The security-aware resolver may have a particularly - difficult time obtaining DS RRs in such a case, as DS RRs do not - follow the usual DNS rules for ownership of RRs at zone cuts. Note - that this problem is not specific to NATs: any security-oblivious DNS - software of any kind between the security-aware resolver and the - authoritative name servers will interfere with DNSSEC. - - If a security-aware resolver must rely on an unsigned zone or a name - server that is not security aware, the resolver may not be able to - validate DNS responses and will need a local policy on whether to - accept unverified responses. - - A security-aware resolver should take a signature's validation period - into consideration when determining the TTL of data in its cache, to - avoid caching signed data beyond the validity period of the - signature. However, it should also allow for the possibility that - the security-aware resolver's own clock is wrong. Thus, a - security-aware resolver that is part of a security-aware recursive - name server will have to pay careful attention to the DNSSEC - "checking disabled" (CD) bit ([RFC4034]). This is in order to avoid - blocking valid signatures from getting through to other - security-aware resolvers that are clients of this recursive name - server. See [RFC4035] for how a secure recursive server handles - queries with the CD bit set. - -7. Stub Resolver Considerations - - Although not strictly required to do so by the protocol, most DNS - queries originate from stub resolvers. Stub resolvers, by - definition, are minimal DNS resolvers that use recursive query mode - to offload most of the work of DNS resolution to a recursive name - server. Given the widespread use of stub resolvers, the DNSSEC - - - - - -Arends, et al. Standards Track [Page 11] - -RFC 4033 DNS Security Introduction and Requirements March 2005 - - - architecture has to take stub resolvers into account, but the - security features needed in a stub resolver differ in some respects - from those needed in a security-aware iterative resolver. - - Even a security-oblivious stub resolver may benefit from DNSSEC if - the recursive name servers it uses are security-aware, but for the - stub resolver to place any real reliance on DNSSEC services, the stub - resolver must trust both the recursive name servers in question and - the communication channels between itself and those name servers. - The first of these issues is a local policy issue: in essence, a - security-oblivious stub resolver has no choice but to place itself at - the mercy of the recursive name servers that it uses, as it does not - perform DNSSEC validity checks on its own. The second issue requires - some kind of channel security mechanism; proper use of DNS - transaction authentication mechanisms such as SIG(0) ([RFC2931]) or - TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec. - Particular implementations may have other choices available, such as - operating system specific interprocess communication mechanisms. - Confidentiality is not needed for this channel, but data integrity - and message authentication are. - - A security-aware stub resolver that does trust both its recursive - name servers and its communication channel to them may choose to - examine the setting of the Authenticated Data (AD) bit in the message - header of the response messages it receives. The stub resolver can - use this flag bit as a hint to find out whether the recursive name - server was able to validate signatures for all of the data in the - Answer and Authority sections of the response. - - There is one more step that a security-aware stub resolver can take - if, for whatever reason, it is not able to establish a useful trust - relationship with the recursive name servers that it uses: it can - perform its own signature validation by setting the Checking Disabled - (CD) bit in its query messages. A validating stub resolver is thus - able to treat the DNSSEC signatures as trust relationships between - the zone administrators and the stub resolver itself. - -8. Zone Considerations - - There are several differences between signed and unsigned zones. A - signed zone will contain additional security-related records (RRSIG, - DNSKEY, DS, and NSEC records). RRSIG and NSEC records may be - generated by a signing process prior to serving the zone. The RRSIG - records that accompany zone data have defined inception and - expiration times that establish a validity period for the signatures - and the zone data the signatures cover. - - - - - -Arends, et al. Standards Track [Page 12] - -RFC 4033 DNS Security Introduction and Requirements March 2005 - - -8.1. TTL Values vs. RRSIG Validity Period - - It is important to note the distinction between a RRset's TTL value - and the signature validity period specified by the RRSIG RR covering - that RRset. DNSSEC does not change the definition or function of the - TTL value, which is intended to maintain database coherency in - caches. A caching resolver purges RRsets from its cache no later - than the end of the time period specified by the TTL fields of those - RRsets, regardless of whether the resolver is security-aware. - - The inception and expiration fields in the RRSIG RR ([RFC4034]), on - the other hand, specify the time period during which the signature - can be used to validate the covered RRset. The signatures associated - with signed zone data are only valid for the time period specified by - these fields in the RRSIG RRs in question. TTL values cannot extend - the validity period of signed RRsets in a resolver's cache, but the - resolver may use the time remaining before expiration of the - signature validity period of a signed RRset as an upper bound for the - TTL of the signed RRset and its associated RRSIG RR in the resolver's - cache. - -8.2. New Temporal Dependency Issues for Zones - - Information in a signed zone has a temporal dependency that did not - exist in the original DNS protocol. A signed zone requires regular - maintenance to ensure that each RRset in the zone has a current valid - RRSIG RR. The signature validity period of an RRSIG RR is an - interval during which the signature for one particular signed RRset - can be considered valid, and the signatures of different RRsets in a - zone may expire at different times. Re-signing one or more RRsets in - a zone will change one or more RRSIG RRs, which will in turn require - incrementing the zone's SOA serial number to indicate that a zone - change has occurred and re-signing the SOA RRset itself. Thus, - re-signing any RRset in a zone may also trigger DNS NOTIFY messages - and zone transfer operations. - -9. Name Server Considerations - - A security-aware name server should include the appropriate DNSSEC - records (RRSIG, DNSKEY, DS, and NSEC) in all responses to queries - from resolvers that have signaled their willingness to receive such - records via use of the DO bit in the EDNS header, subject to message - size limitations. Because inclusion of these DNSSEC RRs could easily - cause UDP message truncation and fallback to TCP, a security-aware - name server must also support the EDNS "sender's UDP payload" - mechanism. - - - - - -Arends, et al. Standards Track [Page 13] - -RFC 4033 DNS Security Introduction and Requirements March 2005 - - - If possible, the private half of each DNSSEC key pair should be kept - offline, but this will not be possible for a zone for which DNS - dynamic update has been enabled. In the dynamic update case, the - primary master server for the zone will have to re-sign the zone when - it is updated, so the private key corresponding to the zone signing - key will have to be kept online. This is an example of a situation - in which the ability to separate the zone's DNSKEY RRset into zone - signing key(s) and key signing key(s) may be useful, as the key - signing key(s) in such a case can still be kept offline and may have - a longer useful lifetime than the zone signing key(s). - - By itself, DNSSEC is not enough to protect the integrity of an entire - zone during zone transfer operations, as even a signed zone contains - some unsigned, nonauthoritative data if the zone has any children. - Therefore, zone maintenance operations will require some additional - mechanisms (most likely some form of channel security, such as TSIG, - SIG(0), or IPsec). - -10. DNS Security Document Family - - The DNSSEC document set can be partitioned into several main groups, - under the larger umbrella of the DNS base protocol documents. - - The "DNSSEC protocol document set" refers to the three documents that - form the core of the DNS security extensions: - - 1. DNS Security Introduction and Requirements (this document) - - 2. Resource Records for DNS Security Extensions [RFC4034] - - 3. Protocol Modifications for the DNS Security Extensions [RFC4035] - - Additionally, any document that would add to or change the core DNS - Security extensions would fall into this category. This includes any - future work on the communication between security-aware stub - resolvers and upstream security-aware recursive name servers. - - The "Digital Signature Algorithm Specification" document set refers - to the group of documents that describe how specific digital - signature algorithms should be implemented to fit the DNSSEC resource - record format. Each document in this set deals with a specific - digital signature algorithm. Please see the appendix on "DNSSEC - Algorithm and Digest Types" in [RFC4034] for a list of the algorithms - that were defined when this core specification was written. - - The "Transaction Authentication Protocol" document set refers to the - group of documents that deal with DNS message authentication, - including secret key establishment and verification. Although not - - - -Arends, et al. Standards Track [Page 14] - -RFC 4033 DNS Security Introduction and Requirements March 2005 - - - strictly part of the DNSSEC specification as defined in this set of - documents, this group is noted because of its relationship to DNSSEC. - - The final document set, "New Security Uses", refers to documents that - seek to use proposed DNS Security extensions for other security - related purposes. DNSSEC does not provide any direct security for - these new uses but may be used to support them. Documents that fall - in this category include those describing the use of DNS in the - storage and distribution of certificates ([RFC2538]). - -11. IANA Considerations - - This overview document introduces no new IANA considerations. Please - see [RFC4034] for a complete review of the IANA considerations - introduced by DNSSEC. - -12. Security Considerations - - This document introduces DNS security extensions and describes the - document set that contains the new security records and DNS protocol - modifications. The extensions provide data origin authentication and - data integrity using digital signatures over resource record sets. - This section discusses the limitations of these extensions. - - In order for a security-aware resolver to validate a DNS response, - all zones along the path from the trusted starting point to the zone - containing the response zones must be signed, and all name servers - and resolvers involved in the resolution process must be - security-aware, as defined in this document set. A security-aware - resolver cannot verify responses originating from an unsigned zone, - from a zone not served by a security-aware name server, or for any - DNS data that the resolver is only able to obtain through a recursive - name server that is not security-aware. If there is a break in the - authentication chain such that a security-aware resolver cannot - obtain and validate the authentication keys it needs, then the - security-aware resolver cannot validate the affected DNS data. - - This document briefly discusses other methods of adding security to a - DNS query, such as using a channel secured by IPsec or using a DNS - transaction authentication mechanism such as TSIG ([RFC2845]) or - SIG(0) ([RFC2931]), but transaction security is not part of DNSSEC - per se. - - A non-validating security-aware stub resolver, by definition, does - not perform DNSSEC signature validation on its own and thus is - vulnerable both to attacks on (and by) the security-aware recursive - name servers that perform these checks on its behalf and to attacks - on its communication with those security-aware recursive name - - - -Arends, et al. Standards Track [Page 15] - -RFC 4033 DNS Security Introduction and Requirements March 2005 - - - servers. Non-validating security-aware stub resolvers should use - some form of channel security to defend against the latter threat. - The only known defense against the former threat would be for the - security-aware stub resolver to perform its own signature validation, - at which point, again by definition, it would no longer be a - non-validating security-aware stub resolver. - - DNSSEC does not protect against denial of service attacks. DNSSEC - makes DNS vulnerable to a new class of denial of service attacks - based on cryptographic operations against security-aware resolvers - and security-aware name servers, as an attacker can attempt to use - DNSSEC mechanisms to consume a victim's resources. This class of - attacks takes at least two forms. An attacker may be able to consume - resources in a security-aware resolver's signature validation code by - tampering with RRSIG RRs in response messages or by constructing - needlessly complex signature chains. An attacker may also be able to - consume resources in a security-aware name server that supports DNS - dynamic update, by sending a stream of update messages that force the - security-aware name server to re-sign some RRsets in the zone more - frequently than would otherwise be necessary. - - Due to a deliberate design choice, DNSSEC does not provide - confidentiality. - - DNSSEC introduces the ability for a hostile party to enumerate all - the names in a zone by following the NSEC chain. NSEC RRs assert - which names do not exist in a zone by linking from existing name to - existing name along a canonical ordering of all the names within a - zone. Thus, an attacker can query these NSEC RRs in sequence to - obtain all the names in a zone. Although this is not an attack on - the DNS itself, it could allow an attacker to map network hosts or - other resources by enumerating the contents of a zone. - - DNSSEC introduces significant additional complexity to the DNS and - thus introduces many new opportunities for implementation bugs and - misconfigured zones. In particular, enabling DNSSEC signature - validation in a resolver may cause entire legitimate zones to become - effectively unreachable due to DNSSEC configuration errors or bugs. - - DNSSEC does not protect against tampering with unsigned zone data. - Non-authoritative data at zone cuts (glue and NS RRs in the parent - zone) are not signed. This does not pose a problem when validating - the authentication chain, but it does mean that the non-authoritative - data itself is vulnerable to tampering during zone transfer - operations. Thus, while DNSSEC can provide data origin - authentication and data integrity for RRsets, it cannot do so for - zones, and other mechanisms (such as TSIG, SIG(0), or IPsec) must be - used to protect zone transfer operations. - - - -Arends, et al. Standards Track [Page 16] - -RFC 4033 DNS Security Introduction and Requirements March 2005 - - - Please see [RFC4034] and [RFC4035] for additional security - considerations. - -13. Acknowledgements - - This document was created from the input and ideas of the members of - the DNS Extensions Working Group. Although explicitly listing - everyone who has contributed during the decade in which DNSSEC has - been under development would be impossible, the editors would - particularly like to thank the following people for their - contributions to and comments on this document set: Jaap Akkerhuis, - Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein, - David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald - Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson, - Gilles Guette, Andreas Gustafsson, Jun-ichiro Itojun Hagino, Phillip - Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson, - Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon - Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters, - Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis, - Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ - Mundy, Thomas Narten, Mans Nilsson, Masataka Ohta, Mike Patton, Rob - Payne, Jim Reid, Michael Richardson, Erik Rozendaal, Marcos Sanz, - Pekka Savola, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, - Brian Wellington, and Suzanne Woolf. - - No doubt the above list is incomplete. We apologize to anyone we - left out. - -14. References - -14.1. Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2535] Eastlake 3rd, D., "Domain Name System Security - Extensions", RFC 2535, March 1999. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC - 3225, December 2001. - - - - - -Arends, et al. Standards Track [Page 17] - -RFC 4033 DNS Security Introduction and Requirements March 2005 - - - [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver - message size requirements", RFC 3226, December 2001. - - [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY - Resource Record (RR)", RFC 3445, December 2002. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for DNS Security Extensions", RFC - 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - -14.2. Informative References - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2538] Eastlake 3rd, D. and O. Gudmundsson, "Storing Certificates - in the Domain Name System (DNS)", RFC 2538, March 1999. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures - ( SIG(0)s )", RFC 2931, September 2000. - - [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) - Signing Authority", RFC 3008, November 2000. - - [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone - Status", RFC 3090, March 2001. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - - - -Arends, et al. Standards Track [Page 18] - -RFC 4033 DNS Security Introduction and Requirements March 2005 - - - [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS - Authenticated Data (AD) bit", RFC 3655, November 2003. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer (DS)", RFC 3755, May 2004. - - [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name - System KEY (DNSKEY) Resource Record (RR) Secure Entry - Point (SEP) Flag", RFC 3757, April 2004. - - [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain - Name System (DNS)", RFC 3833, August 2004. - - [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) - RDATA Format", RFC 3845, August 2004. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Standards Track [Page 19] - -RFC 4033 DNS Security Introduction and Requirements March 2005 - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Brouwerijstraat 1 - 7523 XC Enschede - NL - - EMail: roy.arends@telin.nl - - - Rob Austein - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Dan Massey - Colorado State University - Department of Computer Science - Fort Collins, CO 80523-1873 - - EMail: massey@cs.colostate.edu - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - - -Arends, et al. Standards Track [Page 20] - -RFC 4033 DNS Security Introduction and Requirements March 2005 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2005). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Arends, et al. Standards Track [Page 21] - diff --git a/contrib/bind9/doc/rfc/rfc4034.txt b/contrib/bind9/doc/rfc/rfc4034.txt deleted file mode 100644 index 6a12c6b8efc5..000000000000 --- a/contrib/bind9/doc/rfc/rfc4034.txt +++ /dev/null @@ -1,1627 +0,0 @@ - - - - - - -Network Working Group R. Arends -Request for Comments: 4034 Telematica Instituut -Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein - 3755, 3757, 3845 ISC -Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson - 3007, 3597, 3226 VeriSign -Category: Standards Track D. Massey - Colorado State University - S. Rose - NIST - March 2005 - - - Resource Records for the DNS Security Extensions - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This document is part of a family of documents that describe the DNS - Security Extensions (DNSSEC). The DNS Security Extensions are a - collection of resource records and protocol modifications that - provide source authentication for the DNS. This document defines the - public key (DNSKEY), delegation signer (DS), resource record digital - signature (RRSIG), and authenticated denial of existence (NSEC) - resource records. The purpose and format of each resource record is - described in detail, and an example of each resource record is given. - - This document obsoletes RFC 2535 and incorporates changes from all - updates to RFC 2535. - - - - - - - - - - - -Arends, et al. Standards Track [Page 1] - -RFC 4034 DNSSEC Resource Records March 2005 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Background and Related Documents . . . . . . . . . . . 3 - 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . 3 - 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . 4 - 2.1. DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . 4 - 2.1.1. The Flags Field. . . . . . . . . . . . . . . . 4 - 2.1.2. The Protocol Field . . . . . . . . . . . . . . 5 - 2.1.3. The Algorithm Field. . . . . . . . . . . . . . 5 - 2.1.4. The Public Key Field . . . . . . . . . . . . . 5 - 2.1.5. Notes on DNSKEY RDATA Design . . . . . . . . . 5 - 2.2. The DNSKEY RR Presentation Format. . . . . . . . . . . 5 - 2.3. DNSKEY RR Example . . . . . . . . . . . . . . . . . . 6 - 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 6 - 3.1. RRSIG RDATA Wire Format. . . . . . . . . . . . . . . . 7 - 3.1.1. The Type Covered Field . . . . . . . . . . . . 7 - 3.1.2. The Algorithm Number Field . . . . . . . . . . 8 - 3.1.3. The Labels Field . . . . . . . . . . . . . . . 8 - 3.1.4. Original TTL Field . . . . . . . . . . . . . . 8 - 3.1.5. Signature Expiration and Inception Fields. . . 9 - 3.1.6. The Key Tag Field. . . . . . . . . . . . . . . 9 - 3.1.7. The Signer's Name Field. . . . . . . . . . . . 9 - 3.1.8. The Signature Field. . . . . . . . . . . . . . 9 - 3.2. The RRSIG RR Presentation Format . . . . . . . . . . . 10 - 3.3. RRSIG RR Example . . . . . . . . . . . . . . . . . . . 11 - 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 12 - 4.1. NSEC RDATA Wire Format . . . . . . . . . . . . . . . . 13 - 4.1.1. The Next Domain Name Field . . . . . . . . . . 13 - 4.1.2. The Type Bit Maps Field. . . . . . . . . . . . 13 - 4.1.3. Inclusion of Wildcard Names in NSEC RDATA. . . 14 - 4.2. The NSEC RR Presentation Format. . . . . . . . . . . . 14 - 4.3. NSEC RR Example. . . . . . . . . . . . . . . . . . . . 15 - 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 15 - 5.1. DS RDATA Wire Format . . . . . . . . . . . . . . . . . 16 - 5.1.1. The Key Tag Field. . . . . . . . . . . . . . . 16 - 5.1.2. The Algorithm Field. . . . . . . . . . . . . . 16 - 5.1.3. The Digest Type Field. . . . . . . . . . . . . 17 - 5.1.4. The Digest Field . . . . . . . . . . . . . . . 17 - 5.2. Processing of DS RRs When Validating Responses . . . . 17 - 5.3. The DS RR Presentation Format. . . . . . . . . . . . . 17 - 5.4. DS RR Example. . . . . . . . . . . . . . . . . . . . . 18 - 6. Canonical Form and Order of Resource Records . . . . . . . . 18 - 6.1. Canonical DNS Name Order . . . . . . . . . . . . . . . 18 - 6.2. Canonical RR Form. . . . . . . . . . . . . . . . . . . 19 - 6.3. Canonical RR Ordering within an RRset. . . . . . . . . 20 - 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 20 - 8. Security Considerations. . . . . . . . . . . . . . . . . . . 21 - - - -Arends, et al. Standards Track [Page 2] - -RFC 4034 DNSSEC Resource Records March 2005 - - - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 10.1. Normative References . . . . . . . . . . . . . . . . . 22 - 10.2. Informative References . . . . . . . . . . . . . . . . 23 - A. DNSSEC Algorithm and Digest Types. . . . . . . . . . . . . . 24 - A.1. DNSSEC Algorithm Types . . . . . . . . . . . . . . . . 24 - A.1.1. Private Algorithm Types. . . . . . . . . . . . 25 - A.2. DNSSEC Digest Types. . . . . . . . . . . . . . . . . . 25 - B. Key Tag Calculation. . . . . . . . . . . . . . . . . . . . . 25 - B.1. Key Tag for Algorithm 1 (RSA/MD5). . . . . . . . . . . 27 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 29 - -1. Introduction - - The DNS Security Extensions (DNSSEC) introduce four new DNS resource - record types: DNS Public Key (DNSKEY), Resource Record Signature - (RRSIG), Next Secure (NSEC), and Delegation Signer (DS). This - document defines the purpose of each resource record (RR), the RR's - RDATA format, and its presentation format (ASCII representation). - -1.1. Background and Related Documents - - This document is part of a family of documents defining DNSSEC, which - should be read together as a set. - - [RFC4033] contains an introduction to DNSSEC and definition of common - terms; the reader is assumed to be familiar with this document. - [RFC4033] also contains a list of other documents updated by and - obsoleted by this document set. - - [RFC4035] defines the DNSSEC protocol operations. - - The reader is also assumed to be familiar with the basic DNS concepts - described in [RFC1034], [RFC1035], and the subsequent documents that - update them, particularly [RFC2181] and [RFC2308]. - - This document defines the DNSSEC resource records. All numeric DNS - type codes given in this document are decimal integers. - -1.2. Reserved Words - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - - - - - -Arends, et al. Standards Track [Page 3] - -RFC 4034 DNSSEC Resource Records March 2005 - - -2. The DNSKEY Resource Record - - DNSSEC uses public key cryptography to sign and authenticate DNS - resource record sets (RRsets). The public keys are stored in DNSKEY - resource records and are used in the DNSSEC authentication process - described in [RFC4035]: A zone signs its authoritative RRsets by - using a private key and stores the corresponding public key in a - DNSKEY RR. A resolver can then use the public key to validate - signatures covering the RRsets in the zone, and thus to authenticate - them. - - The DNSKEY RR is not intended as a record for storing arbitrary - public keys and MUST NOT be used to store certificates or public keys - that do not directly relate to the DNS infrastructure. - - The Type value for the DNSKEY RR type is 48. - - The DNSKEY RR is class independent. - - The DNSKEY RR has no special TTL requirements. - -2.1. DNSKEY RDATA Wire Format - - The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1 - octet Protocol Field, a 1 octet Algorithm Field, and the Public Key - Field. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Flags | Protocol | Algorithm | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Public Key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -2.1.1. The Flags Field - - Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, - then the DNSKEY record holds a DNS zone key, and the DNSKEY RR's - owner name MUST be the name of a zone. If bit 7 has value 0, then - the DNSKEY record holds some other type of DNS public key and MUST - NOT be used to verify RRSIGs that cover RRsets. - - Bit 15 of the Flags field is the Secure Entry Point flag, described - in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a - key intended for use as a secure entry point. This flag is only - - - -Arends, et al. Standards Track [Page 4] - -RFC 4034 DNSSEC Resource Records March 2005 - - - intended to be a hint to zone signing or debugging software as to the - intended use of this DNSKEY record; validators MUST NOT alter their - behavior during the signature validation process in any way based on - the setting of this bit. This also means that a DNSKEY RR with the - SEP bit set would also need the Zone Key flag set in order to be able - to generate signatures legally. A DNSKEY RR with the SEP set and the - Zone Key flag not set MUST NOT be used to verify RRSIGs that cover - RRsets. - - Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon - creation of the DNSKEY RR and MUST be ignored upon receipt. - -2.1.2. The Protocol Field - - The Protocol Field MUST have value 3, and the DNSKEY RR MUST be - treated as invalid during signature verification if it is found to be - some value other than 3. - -2.1.3. The Algorithm Field - - The Algorithm field identifies the public key's cryptographic - algorithm and determines the format of the Public Key field. A list - of DNSSEC algorithm types can be found in Appendix A.1 - -2.1.4. The Public Key Field - - The Public Key Field holds the public key material. The format - depends on the algorithm of the key being stored and is described in - separate documents. - -2.1.5. Notes on DNSKEY RDATA Design - - Although the Protocol Field always has value 3, it is retained for - backward compatibility with early versions of the KEY record. - -2.2. The DNSKEY RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Flag field MUST be represented as an unsigned decimal integer. - Given the currently defined flags, the possible values are: 0, 256, - and 257. - - The Protocol Field MUST be represented as an unsigned decimal integer - with a value of 3. - - The Algorithm field MUST be represented either as an unsigned decimal - integer or as an algorithm mnemonic as specified in Appendix A.1. - - - -Arends, et al. Standards Track [Page 5] - -RFC 4034 DNSSEC Resource Records March 2005 - - - The Public Key field MUST be represented as a Base64 encoding of the - Public Key. Whitespace is allowed within the Base64 text. For a - definition of Base64 encoding, see [RFC3548]. - -2.3. DNSKEY RR Example - - The following DNSKEY RR stores a DNS zone key for example.com. - - example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 - Cbl+BBZH4b/0PY1kxkmvHjcZc8no - kfzj31GajIQKY+5CptLr3buXA10h - WqTkF7H6RfoRqXQeogmMHfpftf6z - Mv1LyBUgia7za6ZEzOJBOztyvhjL - 742iU/TpPSEDhm2SNKLijfUppn1U - aNvv4w== ) - - The first four text fields specify the owner name, TTL, Class, and RR - type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in - the Flags field has value 1. Value 3 is the fixed Protocol value. - Value 5 indicates the public key algorithm. Appendix A.1 identifies - algorithm type 5 as RSA/SHA1 and indicates that the format of the - RSA/SHA1 public key field is defined in [RFC3110]. The remaining - text is a Base64 encoding of the public key. - -3. The RRSIG Resource Record - - DNSSEC uses public key cryptography to sign and authenticate DNS - resource record sets (RRsets). Digital signatures are stored in - RRSIG resource records and are used in the DNSSEC authentication - process described in [RFC4035]. A validator can use these RRSIG RRs - to authenticate RRsets from the zone. The RRSIG RR MUST only be used - to carry verification material (digital signatures) used to secure - DNS operations. - - An RRSIG record contains the signature for an RRset with a particular - name, class, and type. The RRSIG RR specifies a validity interval - for the signature and uses the Algorithm, the Signer's Name, and the - Key Tag to identify the DNSKEY RR containing the public key that a - validator can use to verify the signature. - - Because every authoritative RRset in a zone must be protected by a - digital signature, RRSIG RRs must be present for names containing a - CNAME RR. This is a change to the traditional DNS specification - [RFC1034], which stated that if a CNAME is present for a name, it is - the only type allowed at that name. A RRSIG and NSEC (see Section 4) - MUST exist for the same name as a CNAME resource record in a signed - zone. - - - - -Arends, et al. Standards Track [Page 6] - -RFC 4034 DNSSEC Resource Records March 2005 - - - The Type value for the RRSIG RR type is 46. - - The RRSIG RR is class independent. - - An RRSIG RR MUST have the same class as the RRset it covers. - - The TTL value of an RRSIG RR MUST match the TTL value of the RRset it - covers. This is an exception to the [RFC2181] rules for TTL values - of individual RRs within a RRset: individual RRSIG RRs with the same - owner name will have different TTL values if the RRsets they cover - have different TTL values. - -3.1. RRSIG RDATA Wire Format - - The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a - 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original - TTL field, a 4 octet Signature Expiration field, a 4 octet Signature - Inception field, a 2 octet Key tag, the Signer's Name field, and the - Signature field. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type Covered | Algorithm | Labels | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Original TTL | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Signature Expiration | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Signature Inception | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Key Tag | / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Signature / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -3.1.1. The Type Covered Field - - The Type Covered field identifies the type of the RRset that is - covered by this RRSIG record. - - - - - - - -Arends, et al. Standards Track [Page 7] - -RFC 4034 DNSSEC Resource Records March 2005 - - -3.1.2. The Algorithm Number Field - - The Algorithm Number field identifies the cryptographic algorithm - used to create the signature. A list of DNSSEC algorithm types can - be found in Appendix A.1 - -3.1.3. The Labels Field - - The Labels field specifies the number of labels in the original RRSIG - RR owner name. The significance of this field is that a validator - uses it to determine whether the answer was synthesized from a - wildcard. If so, it can be used to determine what owner name was - used in generating the signature. - - To validate a signature, the validator needs the original owner name - that was used to create the signature. If the original owner name - contains a wildcard label ("*"), the owner name may have been - expanded by the server during the response process, in which case the - validator will have to reconstruct the original owner name in order - to validate the signature. [RFC4035] describes how to use the Labels - field to reconstruct the original owner name. - - The value of the Labels field MUST NOT count either the null (root) - label that terminates the owner name or the wildcard label (if - present). The value of the Labels field MUST be less than or equal - to the number of labels in the RRSIG owner name. For example, - "www.example.com." has a Labels field value of 3, and - "*.example.com." has a Labels field value of 2. Root (".") has a - Labels field value of 0. - - Although the wildcard label is not included in the count stored in - the Labels field of the RRSIG RR, the wildcard label is part of the - RRset's owner name when the signature is generated or verified. - -3.1.4. Original TTL Field - - The Original TTL field specifies the TTL of the covered RRset as it - appears in the authoritative zone. - - The Original TTL field is necessary because a caching resolver - decrements the TTL value of a cached RRset. In order to validate a - signature, a validator requires the original TTL. [RFC4035] - describes how to use the Original TTL field value to reconstruct the - original TTL. - - - - - - - -Arends, et al. Standards Track [Page 8] - -RFC 4034 DNSSEC Resource Records March 2005 - - -3.1.5. Signature Expiration and Inception Fields - - The Signature Expiration and Inception fields specify a validity - period for the signature. The RRSIG record MUST NOT be used for - authentication prior to the inception date and MUST NOT be used for - authentication after the expiration date. - - The Signature Expiration and Inception field values specify a date - and time in the form of a 32-bit unsigned number of seconds elapsed - since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network - byte order. The longest interval that can be expressed by this - format without wrapping is approximately 136 years. An RRSIG RR can - have an Expiration field value that is numerically smaller than the - Inception field value if the expiration field value is near the - 32-bit wrap-around point or if the signature is long lived. Because - of this, all comparisons involving these fields MUST use "Serial - number arithmetic", as defined in [RFC1982]. As a direct - consequence, the values contained in these fields cannot refer to - dates more than 68 years in either the past or the future. - -3.1.6. The Key Tag Field - - The Key Tag field contains the key tag value of the DNSKEY RR that - validates this signature, in network byte order. Appendix B explains - how to calculate Key Tag values. - -3.1.7. The Signer's Name Field - - The Signer's Name field value identifies the owner name of the DNSKEY - RR that a validator is supposed to use to validate this signature. - The Signer's Name field MUST contain the name of the zone of the - covered RRset. A sender MUST NOT use DNS name compression on the - Signer's Name field when transmitting a RRSIG RR. - -3.1.8. The Signature Field - - The Signature field contains the cryptographic signature that covers - the RRSIG RDATA (excluding the Signature field) and the RRset - specified by the RRSIG owner name, RRSIG class, and RRSIG Type - Covered field. The format of this field depends on the algorithm in - use, and these formats are described in separate companion documents. - -3.1.8.1. Signature Calculation - - A signature covers the RRSIG RDATA (excluding the Signature Field) - and covers the data RRset specified by the RRSIG owner name, RRSIG - class, and RRSIG Type Covered fields. The RRset is in canonical form - (see Section 6), and the set RR(1),...RR(n) is signed as follows: - - - -Arends, et al. Standards Track [Page 9] - -RFC 4034 DNSSEC Resource Records March 2005 - - - signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where - - "|" denotes concatenation; - - RRSIG_RDATA is the wire format of the RRSIG RDATA fields - with the Signer's Name field in canonical form and - the Signature field excluded; - - RR(i) = owner | type | class | TTL | RDATA length | RDATA - - "owner" is the fully qualified owner name of the RRset in - canonical form (for RRs with wildcard owner names, the - wildcard label is included in the owner name); - - Each RR MUST have the same owner name as the RRSIG RR; - - Each RR MUST have the same class as the RRSIG RR; - - Each RR in the RRset MUST have the RR type listed in the - RRSIG RR's Type Covered field; - - Each RR in the RRset MUST have the TTL listed in the - RRSIG Original TTL Field; - - Any DNS names in the RDATA field of each RR MUST be in - canonical form; and - - The RRset MUST be sorted in canonical order. - - See Sections 6.2 and 6.3 for details on canonical form and ordering - of RRsets. - -3.2. The RRSIG RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Type Covered field is represented as an RR type mnemonic. When - the mnemonic is not known, the TYPE representation as described in - [RFC3597], Section 5, MUST be used. - - The Algorithm field value MUST be represented either as an unsigned - decimal integer or as an algorithm mnemonic, as specified in Appendix - A.1. - - The Labels field value MUST be represented as an unsigned decimal - integer. - - - - - -Arends, et al. Standards Track [Page 10] - -RFC 4034 DNSSEC Resource Records March 2005 - - - The Original TTL field value MUST be represented as an unsigned - decimal integer. - - The Signature Expiration Time and Inception Time field values MUST be - represented either as an unsigned decimal integer indicating seconds - since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in - UTC, where: - - YYYY is the year (0001-9999, but see Section 3.1.5); - MM is the month number (01-12); - DD is the day of the month (01-31); - HH is the hour, in 24 hour notation (00-23); - mm is the minute (00-59); and - SS is the second (00-59). - - Note that it is always possible to distinguish between these two - formats because the YYYYMMDDHHmmSS format will always be exactly 14 - digits, while the decimal representation of a 32-bit unsigned integer - can never be longer than 10 digits. - - The Key Tag field MUST be represented as an unsigned decimal integer. - - The Signer's Name field value MUST be represented as a domain name. - - The Signature field is represented as a Base64 encoding of the - signature. Whitespace is allowed within the Base64 text. See - Section 2.2. - -3.3. RRSIG RR Example - - The following RRSIG RR stores the signature for the A RRset of - host.example.com: - - host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( - 20030220173103 2642 example.com. - oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr - PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o - B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t - GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG - J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) - - The first four fields specify the owner name, TTL, Class, and RR type - (RRSIG). The "A" represents the Type Covered field. The value 5 - identifies the algorithm used (RSA/SHA1) to create the signature. - The value 3 is the number of Labels in the original owner name. The - value 86400 in the RRSIG RDATA is the Original TTL for the covered A - RRset. 20030322173103 and 20030220173103 are the expiration and - - - - -Arends, et al. Standards Track [Page 11] - -RFC 4034 DNSSEC Resource Records March 2005 - - - inception dates, respectively. 2642 is the Key Tag, and example.com. - is the Signer's Name. The remaining text is a Base64 encoding of the - signature. - - Note that combination of RRSIG RR owner name, class, and Type Covered - indicates that this RRSIG covers the "host.example.com" A RRset. The - Label value of 3 indicates that no wildcard expansion was used. The - Algorithm, Signer's Name, and Key Tag indicate that this signature - can be authenticated using an example.com zone DNSKEY RR whose - algorithm is 5 and whose key tag is 2642. - -4. The NSEC Resource Record - - The NSEC resource record lists two separate things: the next owner - name (in the canonical ordering of the zone) that contains - authoritative data or a delegation point NS RRset, and the set of RR - types present at the NSEC RR's owner name [RFC3845]. The complete - set of NSEC RRs in a zone indicates which authoritative RRsets exist - in a zone and also form a chain of authoritative owner names in the - zone. This information is used to provide authenticated denial of - existence for DNS data, as described in [RFC4035]. - - Because every authoritative name in a zone must be part of the NSEC - chain, NSEC RRs must be present for names containing a CNAME RR. - This is a change to the traditional DNS specification [RFC1034], - which stated that if a CNAME is present for a name, it is the only - type allowed at that name. An RRSIG (see Section 3) and NSEC MUST - exist for the same name as does a CNAME resource record in a signed - zone. - - See [RFC4035] for discussion of how a zone signer determines - precisely which NSEC RRs it has to include in a zone. - - The type value for the NSEC RR is 47. - - The NSEC RR is class independent. - - The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL - field. This is in the spirit of negative caching ([RFC2308]). - - - - - - - - - - - - -Arends, et al. Standards Track [Page 12] - -RFC 4034 DNSSEC Resource Records March 2005 - - -4.1. NSEC RDATA Wire Format - - The RDATA of the NSEC RR is as shown below: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Next Domain Name / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Type Bit Maps / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -4.1.1. The Next Domain Name Field - - The Next Domain field contains the next owner name (in the canonical - ordering of the zone) that has authoritative data or contains a - delegation point NS RRset; see Section 6.1 for an explanation of - canonical ordering. The value of the Next Domain Name field in the - last NSEC record in the zone is the name of the zone apex (the owner - name of the zone's SOA RR). This indicates that the owner name of - the NSEC RR is the last name in the canonical ordering of the zone. - - A sender MUST NOT use DNS name compression on the Next Domain Name - field when transmitting an NSEC RR. - - Owner names of RRsets for which the given zone is not authoritative - (such as glue records) MUST NOT be listed in the Next Domain Name - unless at least one authoritative RRset exists at the same owner - name. - -4.1.2. The Type Bit Maps Field - - The Type Bit Maps field identifies the RRset types that exist at the - NSEC RR's owner name. - - The RR type space is split into 256 window blocks, each representing - the low-order 8 bits of the 16-bit RR type space. Each block that - has at least one active RR type is encoded using a single octet - window number (from 0 to 255), a single octet bitmap length (from 1 - to 32) indicating the number of octets used for the window block's - bitmap, and up to 32 octets (256 bits) of bitmap. - - Blocks are present in the NSEC RR RDATA in increasing numerical - order. - - Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ - - where "|" denotes concatenation. - - - -Arends, et al. Standards Track [Page 13] - -RFC 4034 DNSSEC Resource Records March 2005 - - - Each bitmap encodes the low-order 8 bits of RR types within the - window block, in network bit order. The first bit is bit 0. For - window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds - to RR type 2 (NS), and so forth. For window block 1, bit 1 - corresponds to RR type 257, and bit 2 to RR type 258. If a bit is - set, it indicates that an RRset of that type is present for the NSEC - RR's owner name. If a bit is clear, it indicates that no RRset of - that type is present for the NSEC RR's owner name. - - Bits representing pseudo-types MUST be clear, as they do not appear - in zone data. If encountered, they MUST be ignored upon being read. - - Blocks with no types present MUST NOT be included. Trailing zero - octets in the bitmap MUST be omitted. The length of each block's - bitmap is determined by the type code with the largest numerical - value, within that block, among the set of RR types present at the - NSEC RR's owner name. Trailing zero octets not specified MUST be - interpreted as zero octets. - - The bitmap for the NSEC RR at a delegation point requires special - attention. Bits corresponding to the delegation NS RRset and the RR - types for which the parent zone has authoritative data MUST be set; - bits corresponding to any non-NS RRset for which the parent is not - authoritative MUST be clear. - - A zone MUST NOT include an NSEC RR for any domain name that only - holds glue records. - -4.1.3. Inclusion of Wildcard Names in NSEC RDATA - - If a wildcard owner name appears in a zone, the wildcard label ("*") - is treated as a literal symbol and is treated the same as any other - owner name for the purposes of generating NSEC RRs. Wildcard owner - names appear in the Next Domain Name field without any wildcard - expansion. [RFC4035] describes the impact of wildcards on - authenticated denial of existence. - -4.2. The NSEC RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Next Domain Name field is represented as a domain name. - - The Type Bit Maps field is represented as a sequence of RR type - mnemonics. When the mnemonic is not known, the TYPE representation - described in [RFC3597], Section 5, MUST be used. - - - - - -Arends, et al. Standards Track [Page 14] - -RFC 4034 DNSSEC Resource Records March 2005 - - -4.3. NSEC RR Example - - The following NSEC RR identifies the RRsets associated with - alfa.example.com. and identifies the next authoritative name after - alfa.example.com. - - alfa.example.com. 86400 IN NSEC host.example.com. ( - A MX RRSIG NSEC TYPE1234 ) - - The first four text fields specify the name, TTL, Class, and RR type - (NSEC). The entry host.example.com. is the next authoritative name - after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, - and TYPE1234 mnemonics indicate that there are A, MX, RRSIG, NSEC, - and TYPE1234 RRsets associated with the name alfa.example.com. - - The RDATA section of the NSEC RR above would be encoded as: - - 0x04 'h' 'o' 's' 't' - 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' - 0x03 'c' 'o' 'm' 0x00 - 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 - 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x20 - - Assuming that the validator can authenticate this NSEC record, it - could be used to prove that beta.example.com does not exist, or to - prove that there is no AAAA record associated with alfa.example.com. - Authenticated denial of existence is discussed in [RFC4035]. - -5. The DS Resource Record - - The DS Resource Record refers to a DNSKEY RR and is used in the DNS - DNSKEY authentication process. A DS RR refers to a DNSKEY RR by - storing the key tag, algorithm number, and a digest of the DNSKEY RR. - Note that while the digest should be sufficient to identify the - public key, storing the key tag and key algorithm helps make the - identification process more efficient. By authenticating the DS - record, a resolver can authenticate the DNSKEY RR to which the DS - record points. The key authentication process is described in - [RFC4035]. - - The DS RR and its corresponding DNSKEY RR have the same owner name, - but they are stored in different locations. The DS RR appears only - on the upper (parental) side of a delegation, and is authoritative - data in the parent zone. For example, the DS RR for "example.com" is - stored in the "com" zone (the parent zone) rather than in the - - - -Arends, et al. Standards Track [Page 15] - -RFC 4034 DNSSEC Resource Records March 2005 - - - "example.com" zone (the child zone). The corresponding DNSKEY RR is - stored in the "example.com" zone (the child zone). This simplifies - DNS zone management and zone signing but introduces special response - processing requirements for the DS RR; these are described in - [RFC4035]. - - The type number for the DS record is 43. - - The DS resource record is class independent. - - The DS RR has no special TTL requirements. - -5.1. DS RDATA Wire Format - - The RDATA for a DS RR consists of a 2 octet Key Tag field, a 1 octet - Algorithm field, a 1 octet Digest Type field, and a Digest field. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Key Tag | Algorithm | Digest Type | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Digest / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -5.1.1. The Key Tag Field - - The Key Tag field lists the key tag of the DNSKEY RR referred to by - the DS record, in network byte order. - - The Key Tag used by the DS RR is identical to the Key Tag used by - RRSIG RRs. Appendix B describes how to compute a Key Tag. - -5.1.2. The Algorithm Field - - The Algorithm field lists the algorithm number of the DNSKEY RR - referred to by the DS record. - - The algorithm number used by the DS RR is identical to the algorithm - number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the - algorithm number types. - - - - - - - - -Arends, et al. Standards Track [Page 16] - -RFC 4034 DNSSEC Resource Records March 2005 - - -5.1.3. The Digest Type Field - - The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY - RR. The Digest Type field identifies the algorithm used to construct - the digest. Appendix A.2 lists the possible digest algorithm types. - -5.1.4. The Digest Field - - The DS record refers to a DNSKEY RR by including a digest of that - DNSKEY RR. - - The digest is calculated by concatenating the canonical form of the - fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, - and then applying the digest algorithm. - - digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); - - "|" denotes concatenation - - DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. - - The size of the digest may vary depending on the digest algorithm and - DNSKEY RR size. As of the time of this writing, the only defined - digest algorithm is SHA-1, which produces a 20 octet digest. - -5.2. Processing of DS RRs When Validating Responses - - The DS RR links the authentication chain across zone boundaries, so - the DS RR requires extra care in processing. The DNSKEY RR referred - to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST - have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC - zone key, the DS RR (and the DNSKEY RR it references) MUST NOT be - used in the validation process. - -5.3. The DS RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Key Tag field MUST be represented as an unsigned decimal integer. - - The Algorithm field MUST be represented either as an unsigned decimal - integer or as an algorithm mnemonic specified in Appendix A.1. - - The Digest Type field MUST be represented as an unsigned decimal - integer. - - - - - - -Arends, et al. Standards Track [Page 17] - -RFC 4034 DNSSEC Resource Records March 2005 - - - The Digest MUST be represented as a sequence of case-insensitive - hexadecimal digits. Whitespace is allowed within the hexadecimal - text. - -5.4. DS RR Example - - The following example shows a DNSKEY RR and its corresponding DS RR. - - dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz - fwJr1AYtsmx3TGkJaNXVbfi/ - 2pHm822aJ5iI9BMzNXxeYCmZ - DRD99WYwYqUSdjMmmAphXdvx - egXd/M5+X7OrzKBaMbCVdFLU - Uh6DhweJBjEVv5f2wwjM9Xzc - nOf+EPbtG9DMBmADjFDc2w/r - ljwvFw== - ) ; key id = 60485 - - dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A - 98631FAD1A292118 ) - - The first four text fields specify the name, TTL, Class, and RR type - (DS). Value 60485 is the key tag for the corresponding - "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm - used by this "dskey.example.com." DNSKEY RR. The value 1 is the - algorithm used to construct the digest, and the rest of the RDATA - text is the digest in hexadecimal. - -6. Canonical Form and Order of Resource Records - - This section defines a canonical form for resource records, a - canonical ordering of DNS names, and a canonical ordering of resource - records within an RRset. A canonical name order is required to - construct the NSEC name chain. A canonical RR form and ordering - within an RRset are required in order to construct and verify RRSIG - RRs. - -6.1. Canonical DNS Name Order - - For the purposes of DNS security, owner names are ordered by treating - individual labels as unsigned left-justified octet strings. The - absence of a octet sorts before a zero value octet, and uppercase - US-ASCII letters are treated as if they were lowercase US-ASCII - letters. - - - - - - - -Arends, et al. Standards Track [Page 18] - -RFC 4034 DNSSEC Resource Records March 2005 - - - To compute the canonical ordering of a set of DNS names, start by - sorting the names according to their most significant (rightmost) - labels. For names in which the most significant label is identical, - continue sorting according to their next most significant label, and - so forth. - - For example, the following names are sorted in canonical DNS name - order. The most significant label is "example". At this level, - "example" sorts first, followed by names ending in "a.example", then - by names ending "z.example". The names within each level are sorted - in the same way. - - example - a.example - yljkjljk.a.example - Z.a.example - zABC.a.EXAMPLE - z.example - \001.z.example - *.z.example - \200.z.example - -6.2. Canonical RR Form - - For the purposes of DNS security, the canonical form of an RR is the - wire format of the RR where: - - 1. every domain name in the RR is fully expanded (no DNS name - compression) and fully qualified; - - 2. all uppercase US-ASCII letters in the owner name of the RR are - replaced by the corresponding lowercase US-ASCII letters; - - 3. if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, - HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, - SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in - the DNS names contained within the RDATA are replaced by the - corresponding lowercase US-ASCII letters; - - 4. if the owner name of the RR is a wildcard name, the owner name is - in its original unexpanded form, including the "*" label (no - wildcard substitution); and - - 5. the RR's TTL is set to its original value as it appears in the - originating authoritative zone or the Original TTL field of the - covering RRSIG RR. - - - - - -Arends, et al. Standards Track [Page 19] - -RFC 4034 DNSSEC Resource Records March 2005 - - -6.3. Canonical RR Ordering within an RRset - - For the purposes of DNS security, RRs with the same owner name, - class, and type are sorted by treating the RDATA portion of the - canonical form of each RR as a left-justified unsigned octet sequence - in which the absence of an octet sorts before a zero octet. - - [RFC2181] specifies that an RRset is not allowed to contain duplicate - records (multiple RRs with the same owner name, class, type, and - RDATA). Therefore, if an implementation detects duplicate RRs when - putting the RRset in canonical form, it MUST treat this as a protocol - error. If the implementation chooses to handle this protocol error - in the spirit of the robustness principle (being liberal in what it - accepts), it MUST remove all but one of the duplicate RR(s) for the - purposes of calculating the canonical form of the RRset. - -7. IANA Considerations - - This document introduces no new IANA considerations, as all of the - protocol parameters used in this document have already been assigned - by previous specifications. However, since the evolution of DNSSEC - has been long and somewhat convoluted, this section attempts to - describe the current state of the IANA registries and other protocol - parameters that are (or once were) related to DNSSEC. - - Please refer to [RFC4035] for additional IANA considerations. - - DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to - the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS - Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47, - and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. - [RFC3755] also marked type 30 (NXT) as Obsolete and restricted use - of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction - security protocol described in [RFC2931] and to the transaction - KEY Resource Record described in [RFC2930]. - - DNS Security Algorithm Numbers: [RFC2535] created an IANA registry - for DNSSEC Resource Record Algorithm field numbers and assigned - values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755] - altered this registry to include flags for each entry regarding - its use with the DNS security extensions. Each algorithm entry - could refer to an algorithm that can be used for zone signing, - transaction security (see [RFC2931]), or both. Values 6-251 are - available for assignment by IETF standards action ([RFC3755]). - See Appendix A for a full listing of the DNS Security Algorithm - Numbers entries at the time of this writing and their status for - use in DNSSEC. - - - - -Arends, et al. Standards Track [Page 20] - -RFC 4034 DNSSEC Resource Records March 2005 - - - [RFC3658] created an IANA registry for DNSSEC DS Digest Types and - assigned value 0 to reserved and value 1 to SHA-1. - - KEY Protocol Values: [RFC2535] created an IANA Registry for KEY - Protocol Values, but [RFC3445] reassigned all values other than 3 - to reserved and closed this IANA registry. The registry remains - closed, and all KEY and DNSKEY records are required to have a - Protocol Octet value of 3. - - Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA - registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, - this registry only contains assignments for bit 7 (the ZONE bit) - and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757]). - As stated in [RFC3755], bits 0-6 and 8-14 are available for - assignment by IETF Standards Action. - -8. Security Considerations - - This document describes the format of four DNS resource records used - by the DNS security extensions and presents an algorithm for - calculating a key tag for a public key. Other than the items - described below, the resource records themselves introduce no - security considerations. Please see [RFC4033] and [RFC4035] for - additional security considerations related to the use of these - records. - - The DS record points to a DNSKEY RR by using a cryptographic digest, - the key algorithm type, and a key tag. The DS record is intended to - identify an existing DNSKEY RR, but it is theoretically possible for - an attacker to generate a DNSKEY that matches all the DS fields. The - probability of constructing a matching DNSKEY depends on the type of - digest algorithm in use. The only currently defined digest algorithm - is SHA-1, and the working group believes that constructing a public - key that would match the algorithm, key tag, and SHA-1 digest given - in a DS record would be a sufficiently difficult problem that such an - attack is not a serious threat at this time. - - The key tag is used to help select DNSKEY resource records - efficiently, but it does not uniquely identify a single DNSKEY - resource record. It is possible for two distinct DNSKEY RRs to have - the same owner name, the same algorithm type, and the same key tag. - An implementation that uses only the key tag to select a DNSKEY RR - might select the wrong public key in some circumstances. Please see - Appendix B for further details. - - - - - - - -Arends, et al. Standards Track [Page 21] - -RFC 4034 DNSSEC Resource Records March 2005 - - - The table of algorithms in Appendix A and the key tag calculation - algorithms in Appendix B include the RSA/MD5 algorithm for - completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as - explained in [RFC3110]. - -9. Acknowledgements - - This document was created from the input and ideas of the members of - the DNS Extensions Working Group and working group mailing list. The - editors would like to express their thanks for the comments and - suggestions received during the revision of these security extension - specifications. Although explicitly listing everyone who has - contributed during the decade in which DNSSEC has been under - development would be impossible, [RFC4033] includes a list of some of - the participants who were kind enough to comment on these documents. - -10. References - -10.1. Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, - August 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name - System (DNS)", RFC 2536, March 1999. - - [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures - ( SIG(0)s )", RFC 2931, September 2000. - - [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the - Domain Name System (DNS)", RFC 3110, May 2001. - - - - - -Arends, et al. Standards Track [Page 22] - -RFC 4034 DNSSEC Resource Records March 2005 - - - [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY - Resource Record (RR)", RFC 3445, December 2002. - - [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data - Encodings", RFC 3548, July 2003. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer (DS)", RFC 3755, May 2004. - - [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name - System KEY (DNSKEY) Resource Record (RR) Secure Entry - Point (SEP) Flag", RFC 3757, April 2004. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", RFC - 4033, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - -10.2. Informative References - - [RFC2535] Eastlake 3rd, D., "Domain Name System Security - Extensions", RFC 2535, March 1999. - - [RFC2537] Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain - Name System (DNS)", RFC 2537, March 1999. - - [RFC2539] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the - Domain Name System (DNS)", RFC 2539, March 1999. - - [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - [RFC3845] Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC) - RDATA Format", RFC 3845, August 2004. - - - - - - - - -Arends, et al. Standards Track [Page 23] - -RFC 4034 DNSSEC Resource Records March 2005 - - -Appendix A. DNSSEC Algorithm and Digest Types - - The DNS security extensions are designed to be independent of the - underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS - resource records all use a DNSSEC Algorithm Number to identify the - cryptographic algorithm in use by the resource record. The DS - resource record also specifies a Digest Algorithm Number to identify - the digest algorithm used to construct the DS record. The currently - defined Algorithm and Digest Types are listed below. Additional - Algorithm or Digest Types could be added as advances in cryptography - warrant them. - - A DNSSEC aware resolver or name server MUST implement all MANDATORY - algorithms. - -A.1. DNSSEC Algorithm Types - - The DNSKEY, RRSIG, and DS RRs use an 8-bit number to identify the - security algorithm being used. These values are stored in the - "Algorithm number" field in the resource record RDATA. - - Some algorithms are usable only for zone signing (DNSSEC), some only - for transaction security mechanisms (SIG(0) and TSIG), and some for - both. Those usable for zone signing may appear in DNSKEY, RRSIG, and - DS RRs. Those usable for transaction security would be present in - SIG(0) and KEY RRs, as described in [RFC2931]. - - Zone - Value Algorithm [Mnemonic] Signing References Status - ----- -------------------- --------- ---------- --------- - 0 reserved - 1 RSA/MD5 [RSAMD5] n [RFC2537] NOT RECOMMENDED - 2 Diffie-Hellman [DH] n [RFC2539] - - 3 DSA/SHA-1 [DSA] y [RFC2536] OPTIONAL - 4 Elliptic Curve [ECC] TBA - - 5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY - 252 Indirect [INDIRECT] n - - 253 Private [PRIVATEDNS] y see below OPTIONAL - 254 Private [PRIVATEOID] y see below OPTIONAL - 255 reserved - - 6 - 251 Available for assignment by IETF Standards Action. - - - - - - - - - -Arends, et al. Standards Track [Page 24] - -RFC 4034 DNSSEC Resource Records March 2005 - - -A.1.1. Private Algorithm Types - - Algorithm number 253 is reserved for private use and will never be - assigned to a specific algorithm. The public key area in the DNSKEY - RR and the signature area in the RRSIG RR begin with a wire encoded - domain name, which MUST NOT be compressed. The domain name indicates - the private algorithm to use, and the remainder of the public key - area is determined by that algorithm. Entities should only use - domain names they control to designate their private algorithms. - - Algorithm number 254 is reserved for private use and will never be - assigned to a specific algorithm. The public key area in the DNSKEY - RR and the signature area in the RRSIG RR begin with an unsigned - length byte followed by a BER encoded Object Identifier (ISO OID) of - that length. The OID indicates the private algorithm in use, and the - remainder of the area is whatever is required by that algorithm. - Entities should only use OIDs they control to designate their private - algorithms. - -A.2. DNSSEC Digest Types - - A "Digest Type" field in the DS resource record types identifies the - cryptographic digest algorithm used by the resource record. The - following table lists the currently defined digest algorithm types. - - VALUE Algorithm STATUS - 0 Reserved - - 1 SHA-1 MANDATORY - 2-255 Unassigned - - -Appendix B. Key Tag Calculation - - The Key Tag field in the RRSIG and DS resource record types provides - a mechanism for selecting a public key efficiently. In most cases, a - combination of owner name, algorithm, and key tag can efficiently - identify a DNSKEY record. Both the RRSIG and DS resource records - have corresponding DNSKEY records. The Key Tag field in the RRSIG - and DS records can be used to help select the corresponding DNSKEY RR - efficiently when more than one candidate DNSKEY RR is available. - - However, it is essential to note that the key tag is not a unique - identifier. It is theoretically possible for two distinct DNSKEY RRs - to have the same owner name, the same algorithm, and the same key - tag. The key tag is used to limit the possible candidate keys, but - it does not uniquely identify a DNSKEY record. Implementations MUST - NOT assume that the key tag uniquely identifies a DNSKEY RR. - - - - - -Arends, et al. Standards Track [Page 25] - -RFC 4034 DNSSEC Resource Records March 2005 - - - The key tag is the same for all DNSKEY algorithm types except - algorithm 1 (please see Appendix B.1 for the definition of the key - tag for algorithm 1). The key tag algorithm is the sum of the wire - format of the DNSKEY RDATA broken into 2 octet groups. First, the - RDATA (in wire format) is treated as a series of 2 octet groups. - These groups are then added together, ignoring any carry bits. - - A reference implementation of the key tag algorithm is as an ANSI C - function is given below, with the RDATA portion of the DNSKEY RR is - used as input. It is not necessary to use the following reference - code verbatim, but the numerical value of the Key Tag MUST be - identical to what the reference implementation would generate for the - same input. - - Please note that the algorithm for calculating the Key Tag is almost - but not completely identical to the familiar ones-complement checksum - used in many other Internet protocols. Key Tags MUST be calculated - using the algorithm described here rather than the ones complement - checksum. - - The following ANSI C reference implementation calculates the value of - a Key Tag. This reference implementation applies to all algorithm - types except algorithm 1 (see Appendix B.1). The input is the wire - format of the RDATA portion of the DNSKEY RR. The code is written - for clarity, not efficiency. - - /* - * Assumes that int is at least 16 bits. - * First octet of the key tag is the most significant 8 bits of the - * return value; - * Second octet of the key tag is the least significant 8 bits of the - * return value. - */ - - unsigned int - keytag ( - unsigned char key[], /* the RDATA part of the DNSKEY RR */ - unsigned int keysize /* the RDLENGTH */ - ) - { - unsigned long ac; /* assumed to be 32 bits or larger */ - int i; /* loop index */ - - for ( ac = 0, i = 0; i < keysize; ++i ) - ac += (i & 1) ? key[i] : key[i] << 8; - ac += (ac >> 16) & 0xFFFF; - return ac & 0xFFFF; - } - - - -Arends, et al. Standards Track [Page 26] - -RFC 4034 DNSSEC Resource Records March 2005 - - -B.1. Key Tag for Algorithm 1 (RSA/MD5) - - The key tag for algorithm 1 (RSA/MD5) is defined differently from the - key tag for all other algorithms, for historical reasons. For a - DNSKEY RR with algorithm 1, the key tag is defined to be the most - significant 16 bits of the least significant 24 bits in the public - key modulus (in other words, the 4th to last and 3rd to last octets - of the public key modulus). - - Please note that Algorithm 1 is NOT RECOMMENDED. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Standards Track [Page 27] - -RFC 4034 DNSSEC Resource Records March 2005 - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Brouwerijstraat 1 - 7523 XC Enschede - NL - - EMail: roy.arends@telin.nl - - - Rob Austein - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Dan Massey - Colorado State University - Department of Computer Science - Fort Collins, CO 80523-1873 - - EMail: massey@cs.colostate.edu - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - - -Arends, et al. Standards Track [Page 28] - -RFC 4034 DNSSEC Resource Records March 2005 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2005). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Arends, et al. Standards Track [Page 29] - diff --git a/contrib/bind9/doc/rfc/rfc4035.txt b/contrib/bind9/doc/rfc/rfc4035.txt deleted file mode 100644 index b701cd2f235b..000000000000 --- a/contrib/bind9/doc/rfc/rfc4035.txt +++ /dev/null @@ -1,2971 +0,0 @@ - - - - - - -Network Working Group R. Arends -Request for Comments: 4035 Telematica Instituut -Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein - 3755, 3757, 3845 ISC -Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson - 3007, 3597, 3226 VeriSign -Category: Standards Track D. Massey - Colorado State University - S. Rose - NIST - March 2005 - - - Protocol Modifications for the DNS Security Extensions - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This document is part of a family of documents that describe the DNS - Security Extensions (DNSSEC). The DNS Security Extensions are a - collection of new resource records and protocol modifications that - add data origin authentication and data integrity to the DNS. This - document describes the DNSSEC protocol modifications. This document - defines the concept of a signed zone, along with the requirements for - serving and resolving by using DNSSEC. These techniques allow a - security-aware resolver to authenticate both DNS resource records and - authoritative DNS error indications. - - This document obsoletes RFC 2535 and incorporates changes from all - updates to RFC 2535. - - - - - - - - - - -Arends, et al. Standards Track [Page 1] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Background and Related Documents . . . . . . . . . . . . 4 - 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . 4 - 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. Including DNSKEY RRs in a Zone . . . . . . . . . . . . . 5 - 2.2. Including RRSIG RRs in a Zone . . . . . . . . . . . . . 5 - 2.3. Including NSEC RRs in a Zone . . . . . . . . . . . . . . 6 - 2.4. Including DS RRs in a Zone . . . . . . . . . . . . . . . 7 - 2.5. Changes to the CNAME Resource Record. . . . . . . . . . 7 - 2.6. DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . 8 - 2.7. Example of a Secure Zone . . . . . . . . . . . . . . . . 8 - 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.1. Authoritative Name Servers . . . . . . . . . . . . . . . 9 - 3.1.1. Including RRSIG RRs in a Response . . . . . . . 10 - 3.1.2. Including DNSKEY RRs in a Response . . . . . . . 11 - 3.1.3. Including NSEC RRs in a Response . . . . . . . . 11 - 3.1.4. Including DS RRs in a Response . . . . . . . . . 14 - 3.1.5. Responding to Queries for Type AXFR or IXFR . . 15 - 3.1.6. The AD and CD Bits in an Authoritative Response. 16 - 3.2. Recursive Name Servers . . . . . . . . . . . . . . . . . 17 - 3.2.1. The DO Bit . . . . . . . . . . . . . . . . . . . 17 - 3.2.2. The CD Bit . . . . . . . . . . . . . . . . . . . 17 - 3.2.3. The AD Bit . . . . . . . . . . . . . . . . . . . 18 - 3.3. Example DNSSEC Responses . . . . . . . . . . . . . . . . 19 - 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 4.1. EDNS Support . . . . . . . . . . . . . . . . . . . . . . 19 - 4.2. Signature Verification Support . . . . . . . . . . . . . 19 - 4.3. Determining Security Status of Data . . . . . . . . . . 20 - 4.4. Configured Trust Anchors . . . . . . . . . . . . . . . . 21 - 4.5. Response Caching . . . . . . . . . . . . . . . . . . . . 21 - 4.6. Handling of the CD and AD Bits . . . . . . . . . . . . . 22 - 4.7. Caching BAD Data . . . . . . . . . . . . . . . . . . . . 22 - 4.8. Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . 23 - 4.9. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . 23 - 4.9.1. Handling of the DO Bit . . . . . . . . . . . . . 24 - 4.9.2. Handling of the CD Bit . . . . . . . . . . . . . 24 - 4.9.3. Handling of the AD Bit . . . . . . . . . . . . . 24 - 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25 - 5.1. Special Considerations for Islands of Security . . . . . 26 - 5.2. Authenticating Referrals . . . . . . . . . . . . . . . . 26 - 5.3. Authenticating an RRset with an RRSIG RR . . . . . . . . 28 - 5.3.1. Checking the RRSIG RR Validity . . . . . . . . . 28 - 5.3.2. Reconstructing the Signed Data . . . . . . . . . 29 - 5.3.3. Checking the Signature . . . . . . . . . . . . . 31 - 5.3.4. Authenticating a Wildcard Expanded RRset - Positive Response. . . . . . . . . . . . . . . . 32 - - - -Arends, et al. Standards Track [Page 2] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - 5.4. Authenticated Denial of Existence . . . . . . . . . . . 32 - 5.5. Resolver Behavior When Signatures Do Not Validate . . . 33 - 5.6. Authentication Example . . . . . . . . . . . . . . . . . 33 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 34 - 9.2. Informative References . . . . . . . . . . . . . . . . . 35 - A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 36 - B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 41 - B.1. Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41 - B.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 43 - B.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 44 - B.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 44 - B.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 45 - B.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46 - B.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 47 - B.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 48 - C. Authentication Examples . . . . . . . . . . . . . . . . . . . 49 - C.1. Authenticating an Answer . . . . . . . . . . . . . . . . 49 - C.1.1. Authenticating the Example DNSKEY RR . . . . . . 49 - C.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 50 - C.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 50 - C.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 50 - C.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 51 - C.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51 - C.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 51 - C.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 51 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53 - -1. Introduction - - The DNS Security Extensions (DNSSEC) are a collection of new resource - records and protocol modifications that add data origin - authentication and data integrity to the DNS. This document defines - the DNSSEC protocol modifications. Section 2 of this document - defines the concept of a signed zone and lists the requirements for - zone signing. Section 3 describes the modifications to authoritative - name server behavior necessary for handling signed zones. Section 4 - describes the behavior of entities that include security-aware - resolver functions. Finally, Section 5 defines how to use DNSSEC RRs - to authenticate a response. - - - - - - - -Arends, et al. Standards Track [Page 3] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - -1.1. Background and Related Documents - - This document is part of a family of documents defining DNSSEC that - should be read together as a set. - - [RFC4033] contains an introduction to DNSSEC and definitions of - common terms; the reader is assumed to be familiar with this - document. [RFC4033] also contains a list of other documents updated - by and obsoleted by this document set. - - [RFC4034] defines the DNSSEC resource records. - - The reader is also assumed to be familiar with the basic DNS concepts - described in [RFC1034], [RFC1035], and the subsequent documents that - update them; particularly, [RFC2181] and [RFC2308]. - - This document defines the DNSSEC protocol operations. - -1.2. Reserved Words - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - -2. Zone Signing - - DNSSEC introduces the concept of signed zones. A signed zone - includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG), - Next Secure (NSEC), and (optionally) Delegation Signer (DS) records - according to the rules specified in Sections 2.1, 2.2, 2.3, and 2.4, - respectively. A zone that does not include these records according - to the rules in this section is an unsigned zone. - - DNSSEC requires a change to the definition of the CNAME resource - record ([RFC1035]). Section 2.5 changes the CNAME RR to allow RRSIG - and NSEC RRs to appear at the same owner name as does a CNAME RR. - - DNSSEC specifies the placement of two new RR types, NSEC and DS, - which can be placed at the parental side of a zone cut (that is, at a - delegation point). This is an exception to the general prohibition - against putting data in the parent zone at a zone cut. Section 2.6 - describes this change. - - - - - - - - - -Arends, et al. Standards Track [Page 4] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - -2.1. Including DNSKEY RRs in a Zone - - To sign a zone, the zone's administrator generates one or more - public/private key pairs and uses the private key(s) to sign - authoritative RRsets in the zone. For each private key used to - create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR - containing the corresponding public key. A zone key DNSKEY RR MUST - have the Zone Key bit of the flags RDATA field set (see Section 2.1.1 - of [RFC4034]). Public keys associated with other DNS operations MAY - be stored in DNSKEY RRs that are not marked as zone keys but MUST NOT - be used to verify RRSIGs. - - If the zone administrator intends a signed zone to be usable other - than as an island of security, the zone apex MUST contain at least - one DNSKEY RR to act as a secure entry point into the zone. This - secure entry point could then be used as the target of a secure - delegation via a corresponding DS RR in the parent zone (see - [RFC4034]). - -2.2. Including RRSIG RRs in a Zone - - For each authoritative RRset in a signed zone, there MUST be at least - one RRSIG record that meets the following requirements: - - o The RRSIG owner name is equal to the RRset owner name. - - o The RRSIG class is equal to the RRset class. - - o The RRSIG Type Covered field is equal to the RRset type. - - o The RRSIG Original TTL field is equal to the TTL of the RRset. - - o The RRSIG RR's TTL is equal to the TTL of the RRset. - - o The RRSIG Labels field is equal to the number of labels in the - RRset owner name, not counting the null root label and not - counting the leftmost label if it is a wildcard. - - o The RRSIG Signer's Name field is equal to the name of the zone - containing the RRset. - - o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a - zone key DNSKEY record at the zone apex. - - The process for constructing the RRSIG RR for a given RRset is - described in [RFC4034]. An RRset MAY have multiple RRSIG RRs - associated with it. Note that as RRSIG RRs are closely tied to the - RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS - - - -Arends, et al. Standards Track [Page 5] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - RR types, do not form RRsets. In particular, the TTL values among - RRSIG RRs with a common owner name do not follow the RRset rules - described in [RFC2181]. - - An RRSIG RR itself MUST NOT be signed, as signing an RRSIG RR would - add no value and would create an infinite loop in the signing - process. - - The NS RRset that appears at the zone apex name MUST be signed, but - the NS RRsets that appear at delegation points (that is, the NS - RRsets in the parent zone that delegate the name to the child zone's - name servers) MUST NOT be signed. Glue address RRsets associated - with delegations MUST NOT be signed. - - There MUST be an RRSIG for each RRset using at least one DNSKEY of - each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset - itself MUST be signed by each algorithm appearing in the DS RRset - located at the delegating parent (if any). - -2.3. Including NSEC RRs in a Zone - - Each owner name in the zone that has authoritative data or a - delegation point NS RRset MUST have an NSEC resource record. The - format of NSEC RRs and the process for constructing the NSEC RR for a - given name is described in [RFC4034]. - - The TTL value for any NSEC RR SHOULD be the same as the minimum TTL - value field in the zone SOA RR. - - An NSEC record (and its associated RRSIG RRset) MUST NOT be the only - RRset at any particular owner name. That is, the signing process - MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not - the owner name of any RRset before the zone was signed. The main - reasons for this are a desire for namespace consistency between - signed and unsigned versions of the same zone and a desire to reduce - the risk of response inconsistency in security oblivious recursive - name servers. - - The type bitmap of every NSEC resource record in a signed zone MUST - indicate the presence of both the NSEC record itself and its - corresponding RRSIG record. - - The difference between the set of owner names that require RRSIG - records and the set of owner names that require NSEC records is - subtle and worth highlighting. RRSIG records are present at the - owner names of all authoritative RRsets. NSEC records are present at - the owner names of all names for which the signed zone is - authoritative and also at the owner names of delegations from the - - - -Arends, et al. Standards Track [Page 6] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - signed zone to its children. Neither NSEC nor RRSIG records are - present (in the parent zone) at the owner names of glue address - RRsets. Note, however, that this distinction is for the most part - visible only during the zone signing process, as NSEC RRsets are - authoritative data and are therefore signed. Thus, any owner name - that has an NSEC RRset will have RRSIG RRs as well in the signed - zone. - - The bitmap for the NSEC RR at a delegation point requires special - attention. Bits corresponding to the delegation NS RRset and any - RRsets for which the parent zone has authoritative data MUST be set; - bits corresponding to any non-NS RRset for which the parent is not - authoritative MUST be clear. - -2.4. Including DS RRs in a Zone - - The DS resource record establishes authentication chains between DNS - zones. A DS RRset SHOULD be present at a delegation point when the - child zone is signed. The DS RRset MAY contain multiple records, - each referencing a public key in the child zone used to verify the - RRSIGs in that zone. All DS RRsets in a zone MUST be signed, and DS - RRsets MUST NOT appear at a zone's apex. - - A DS RR SHOULD point to a DNSKEY RR that is present in the child's - apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed - by the corresponding private key. DS RRs that fail to meet these - conditions are not useful for validation, but because the DS RR and - its corresponding DNSKEY RR are in different zones, and because the - DNS is only loosely consistent, temporary mismatches can occur. - - The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset - (that is, the NS RRset from the same zone containing the DS RRset). - - Construction of a DS RR requires knowledge of the corresponding - DNSKEY RR in the child zone, which implies communication between the - child and parent zones. This communication is an operational matter - not covered by this document. - -2.5. Changes to the CNAME Resource Record - - If a CNAME RRset is present at a name in a signed zone, appropriate - RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that - name for secure dynamic update purposes is also allowed ([RFC3007]). - Other types MUST NOT be present at that name. - - This is a modification to the original CNAME definition given in - [RFC1034]. The original definition of the CNAME RR did not allow any - other types to coexist with a CNAME record, but a signed zone - - - -Arends, et al. Standards Track [Page 7] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - requires NSEC and RRSIG RRs for every authoritative name. To resolve - this conflict, this specification modifies the definition of the - CNAME resource record to allow it to coexist with NSEC and RRSIG RRs. - -2.6. DNSSEC RR Types Appearing at Zone Cuts - - DNSSEC introduced two new RR types that are unusual in that they can - appear at the parental side of a zone cut. At the parental side of a - zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at - the owner name. A DS RR could also be present if the zone being - delegated is signed and seeks to have a chain of authentication to - the parent zone. This is an exception to the original DNS - specification ([RFC1034]), which states that only NS RRsets could - appear at the parental side of a zone cut. - - This specification updates the original DNS specification to allow - NSEC and DS RR types at the parent side of a zone cut. These RRsets - are authoritative for the parent when they appear at the parent side - of a zone cut. - -2.7. Example of a Secure Zone - - Appendix A shows a complete example of a small signed zone. - -3. Serving - - This section describes the behavior of entities that include - security-aware name server functions. In many cases such functions - will be part of a security-aware recursive name server, but a - security-aware authoritative name server has some of the same - requirements. Functions specific to security-aware recursive name - servers are described in Section 3.2; functions specific to - authoritative servers are described in Section 3.1. - - In the following discussion, the terms "SNAME", "SCLASS", and "STYPE" - are as used in [RFC1034]. - - A security-aware name server MUST support the EDNS0 ([RFC2671]) - message size extension, MUST support a message size of at least 1220 - octets, and SHOULD support a message size of 4000 octets. As IPv6 - packets can only be fragmented by the source host, a security aware - name server SHOULD take steps to ensure that UDP datagrams it - transmits over IPv6 are fragmented, if necessary, at the minimum IPv6 - MTU, unless the path MTU is known. Please see [RFC1122], [RFC2460], - and [RFC3226] for further discussion of packet size and fragmentation - issues. - - - - - -Arends, et al. Standards Track [Page 8] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - A security-aware name server that receives a DNS query that does not - include the EDNS OPT pseudo-RR or that has the DO bit clear MUST - treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and - MUST NOT perform any of the additional processing described below. - Because the DS RR type has the peculiar property of only existing in - the parent zone at delegation points, DS RRs always require some - special processing, as described in Section 3.1.4.1. - - Security aware name servers that receive explicit queries for - security RR types that match the content of more than one zone that - it serves (for example, NSEC and RRSIG RRs above and below a - delegation point where the server is authoritative for both zones) - should behave self-consistently. As long as the response is always - consistent for each query to the name server, the name server MAY - return one of the following: - - o The above-delegation RRsets. - o The below-delegation RRsets. - o Both above and below-delegation RRsets. - o Empty answer section (no records). - o Some other response. - o An error. - - DNSSEC allocates two new bits in the DNS message header: the CD - (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit - is controlled by resolvers; a security-aware name server MUST copy - the CD bit from a query into the corresponding response. The AD bit - is controlled by name servers; a security-aware name server MUST - ignore the setting of the AD bit in queries. See Sections 3.1.6, - 3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits. - - A security aware name server that synthesizes CNAME RRs from DNAME - RRs as described in [RFC2672] SHOULD NOT generate signatures for the - synthesized CNAME RRs. - -3.1. Authoritative Name Servers - - Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT - pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name - server for a signed zone MUST include additional RRSIG, NSEC, and DS - RRs, according to the following rules: - - o RRSIG RRs that can be used to authenticate a response MUST be - included in the response according to the rules in Section 3.1.1. - - - - - - - -Arends, et al. Standards Track [Page 9] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - o NSEC RRs that can be used to provide authenticated denial of - existence MUST be included in the response automatically according - to the rules in Section 3.1.3. - - o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST - be included in referrals automatically according to the rules in - Section 3.1.4. - - These rules only apply to responses where the semantics convey - information about the presence or absence of resource records. That - is, these rules are not intended to rule out responses such as RCODE - 4 ("Not Implemented") or RCODE 5 ("Refused"). - - DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 - discusses zone transfer requirements. - -3.1.1. Including RRSIG RRs in a Response - - When responding to a query that has the DO bit set, a security-aware - authoritative name server SHOULD attempt to send RRSIG RRs that a - security-aware resolver can use to authenticate the RRsets in the - response. A name server SHOULD make every attempt to keep the RRset - and its associated RRSIG(s) together in a response. Inclusion of - RRSIG RRs in a response is subject to the following rules: - - o When placing a signed RRset in the Answer section, the name server - MUST also place its RRSIG RRs in the Answer section. The RRSIG - RRs have a higher priority for inclusion than any other RRsets - that may have to be included. If space does not permit inclusion - of these RRSIG RRs, the name server MUST set the TC bit. - - o When placing a signed RRset in the Authority section, the name - server MUST also place its RRSIG RRs in the Authority section. - The RRSIG RRs have a higher priority for inclusion than any other - RRsets that may have to be included. If space does not permit - inclusion of these RRSIG RRs, the name server MUST set the TC bit. - - o When placing a signed RRset in the Additional section, the name - server MUST also place its RRSIG RRs in the Additional section. - If space does not permit inclusion of both the RRset and its - associated RRSIG RRs, the name server MAY retain the RRset while - dropping the RRSIG RRs. If this happens, the name server MUST NOT - set the TC bit solely because these RRSIG RRs didn't fit. - - - - - - - - -Arends, et al. Standards Track [Page 10] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - -3.1.2. Including DNSKEY RRs in a Response - - When responding to a query that has the DO bit set and that requests - the SOA or NS RRs at the apex of a signed zone, a security-aware - authoritative name server for that zone MAY return the zone apex - DNSKEY RRset in the Additional section. In this situation, the - DNSKEY RRset and associated RRSIG RRs have lower priority than does - any other information that would be placed in the additional section. - The name server SHOULD NOT include the DNSKEY RRset unless there is - enough space in the response message for both the DNSKEY RRset and - its associated RRSIG RR(s). If there is not enough space to include - these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST - NOT set the TC bit solely because these RRs didn't fit (see Section - 3.1.1). - -3.1.3. Including NSEC RRs in a Response - - When responding to a query that has the DO bit set, a security-aware - authoritative name server for a signed zone MUST include NSEC RRs in - each of the following cases: - - No Data: The zone contains RRsets that exactly match <SNAME, SCLASS> - but does not contain any RRsets that exactly match <SNAME, SCLASS, - STYPE>. - - Name Error: The zone does not contain any RRsets that match <SNAME, - SCLASS> either exactly or via wildcard name expansion. - - Wildcard Answer: The zone does not contain any RRsets that exactly - match <SNAME, SCLASS> but does contain an RRset that matches - <SNAME, SCLASS, STYPE> via wildcard name expansion. - - Wildcard No Data: The zone does not contain any RRsets that exactly - match <SNAME, SCLASS> and does contain one or more RRsets that - match <SNAME, SCLASS> via wildcard name expansion, but does not - contain any RRsets that match <SNAME, SCLASS, STYPE> via wildcard - name expansion. - - In each of these cases, the name server includes NSEC RRs in the - response to prove that an exact match for <SNAME, SCLASS, STYPE> was - not present in the zone and that the response that the name server is - returning is correct given the data in the zone. - - - - - - - - - -Arends, et al. Standards Track [Page 11] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - -3.1.3.1. Including NSEC RRs: No Data Response - - If the zone contains RRsets matching <SNAME, SCLASS> but contains no - RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST - include the NSEC RR for <SNAME, SCLASS> along with its associated - RRSIG RR(s) in the Authority section of the response (see Section - 3.1.1). If space does not permit inclusion of the NSEC RR or its - associated RRSIG RR(s), the name server MUST set the TC bit (see - Section 3.1.1). - - Since the search name exists, wildcard name expansion does not apply - to this query, and a single signed NSEC RR suffices to prove that the - requested RR type does not exist. - -3.1.3.2. Including NSEC RRs: Name Error Response - - If the zone does not contain any RRsets matching <SNAME, SCLASS> - either exactly or via wildcard name expansion, then the name server - MUST include the following NSEC RRs in the Authority section, along - with their associated RRSIG RRs: - - o An NSEC RR proving that there is no exact match for <SNAME, - SCLASS>. - - o An NSEC RR proving that the zone contains no RRsets that would - match <SNAME, SCLASS> via wildcard name expansion. - - In some cases, a single NSEC RR may prove both of these points. If - it does, the name server SHOULD only include the NSEC RR and its - RRSIG RR(s) once in the Authority section. - - If space does not permit inclusion of these NSEC and RRSIG RRs, the - name server MUST set the TC bit (see Section 3.1.1). - - The owner names of these NSEC and RRSIG RRs are not subject to - wildcard name expansion when these RRs are included in the Authority - section of the response. - - Note that this form of response includes cases in which SNAME - corresponds to an empty non-terminal name within the zone (a name - that is not the owner name for any RRset but that is the parent name - of one or more RRsets). - -3.1.3.3. Including NSEC RRs: Wildcard Answer Response - - If the zone does not contain any RRsets that exactly match <SNAME, - SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE> - via wildcard name expansion, the name server MUST include the - - - -Arends, et al. Standards Track [Page 12] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - wildcard-expanded answer and the corresponding wildcard-expanded - RRSIG RRs in the Answer section and MUST include in the Authority - section an NSEC RR and associated RRSIG RR(s) proving that the zone - does not contain a closer match for <SNAME, SCLASS>. If space does - not permit inclusion of the answer, NSEC and RRSIG RRs, the name - server MUST set the TC bit (see Section 3.1.1). - -3.1.3.4. Including NSEC RRs: Wildcard No Data Response - - This case is a combination of the previous cases. The zone does not - contain an exact match for <SNAME, SCLASS>, and although the zone - does contain RRsets that match <SNAME, SCLASS> via wildcard - expansion, none of those RRsets matches STYPE. The name server MUST - include the following NSEC RRs in the Authority section, along with - their associated RRSIG RRs: - - o An NSEC RR proving that there are no RRsets matching STYPE at the - wildcard owner name that matched <SNAME, SCLASS> via wildcard - expansion. - - o An NSEC RR proving that there are no RRsets in the zone that would - have been a closer match for <SNAME, SCLASS>. - - In some cases, a single NSEC RR may prove both of these points. If - it does, the name server SHOULD only include the NSEC RR and its - RRSIG RR(s) once in the Authority section. - - The owner names of these NSEC and RRSIG RRs are not subject to - wildcard name expansion when these RRs are included in the Authority - section of the response. - - If space does not permit inclusion of these NSEC and RRSIG RRs, the - name server MUST set the TC bit (see Section 3.1.1). - -3.1.3.5. Finding the Right NSEC RRs - - As explained above, there are several situations in which a - security-aware authoritative name server has to locate an NSEC RR - that proves that no RRsets matching a particular SNAME exist. - Locating such an NSEC RR within an authoritative zone is relatively - simple, at least in concept. The following discussion assumes that - the name server is authoritative for the zone that would have held - the non-existent RRsets matching SNAME. The algorithm below is - written for clarity, not for efficiency. - - To find the NSEC that proves that no RRsets matching name N exist in - the zone Z that would have held them, construct a sequence, S, - consisting of the owner names of every RRset in Z, sorted into - - - -Arends, et al. Standards Track [Page 13] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - canonical order ([RFC4034]), with no duplicate names. Find the name - M that would have immediately preceded N in S if any RRsets with - owner name N had existed. M is the owner name of the NSEC RR that - proves that no RRsets exist with owner name N. - - The algorithm for finding the NSEC RR that proves that a given name - is not covered by any applicable wildcard is similar but requires an - extra step. More precisely, the algorithm for finding the NSEC - proving that no RRsets exist with the applicable wildcard name is - precisely the same as the algorithm for finding the NSEC RR that - proves that RRsets with any other owner name do not exist. The part - that's missing is a method of determining the name of the non- - existent applicable wildcard. In practice, this is easy, because the - authoritative name server has already checked for the presence of - precisely this wildcard name as part of step (1)(c) of the normal - lookup algorithm described in Section 4.3.2 of [RFC1034]. - -3.1.4. Including DS RRs in a Response - - When responding to a query that has the DO bit set, a security-aware - authoritative name server returning a referral includes DNSSEC data - along with the NS RRset. - - If a DS RRset is present at the delegation point, the name server - MUST return both the DS RRset and its associated RRSIG RR(s) in the - Authority section along with the NS RRset. - - If no DS RRset is present at the delegation point, the name server - MUST return both the NSEC RR that proves that the DS RRset is not - present and the NSEC RR's associated RRSIG RR(s) along with the NS - RRset. The name server MUST place the NS RRset before the NSEC RRset - and its associated RRSIG RR(s). - - Including these DS, NSEC, and RRSIG RRs increases the size of - referral messages and may cause some or all glue RRs to be omitted. - If space does not permit inclusion of the DS or NSEC RRset and - associated RRSIG RRs, the name server MUST set the TC bit (see - Section 3.1.1). - -3.1.4.1. Responding to Queries for DS RRs - - The DS resource record type is unusual in that it appears only on the - parent zone's side of a zone cut. For example, the DS RRset for the - delegation of "foo.example" is stored in the "example" zone rather - than in the "foo.example" zone. This requires special processing - rules for both name servers and resolvers, as the name server for the - child zone is authoritative for the name at the zone cut by the - normal DNS rules but the child zone does not contain the DS RRset. - - - -Arends, et al. Standards Track [Page 14] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - A security-aware resolver sends queries to the parent zone when - looking for a needed DS RR at a delegation point (see Section 4.2). - However, special rules are necessary to avoid confusing - security-oblivious resolvers which might become involved in - processing such a query (for example, in a network configuration that - forces a security-aware resolver to channel its queries through a - security-oblivious recursive name server). The rest of this section - describes how a security-aware name server processes DS queries in - order to avoid this problem. - - The need for special processing by a security-aware name server only - arises when all the following conditions are met: - - o The name server has received a query for the DS RRset at a zone - cut. - - o The name server is authoritative for the child zone. - - o The name server is not authoritative for the parent zone. - - o The name server does not offer recursion. - - In all other cases, the name server either has some way of obtaining - the DS RRset or could not have been expected to have the DS RRset - even by the pre-DNSSEC processing rules, so the name server can - return either the DS RRset or an error response according to the - normal processing rules. - - If all the above conditions are met, however, the name server is - authoritative for SNAME but cannot supply the requested RRset. In - this case, the name server MUST return an authoritative "no data" - response showing that the DS RRset does not exist in the child zone's - apex. See Appendix B.8 for an example of such a response. - -3.1.5. Responding to Queries for Type AXFR or IXFR - - DNSSEC does not change the DNS zone transfer process. A signed zone - will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these - records have no special meaning with respect to a zone transfer - operation. - - An authoritative name server is not required to verify that a zone is - properly signed before sending or accepting a zone transfer. - However, an authoritative name server MAY choose to reject the entire - zone transfer if the zone fails to meet any of the signing - requirements described in Section 2. The primary objective of a zone - transfer is to ensure that all authoritative name servers have - identical copies of the zone. An authoritative name server that - - - -Arends, et al. Standards Track [Page 15] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - chooses to perform its own zone validation MUST NOT selectively - reject some RRs and accept others. - - DS RRsets appear only on the parental side of a zone cut and are - authoritative data in the parent zone. As with any other - authoritative RRset, the DS RRset MUST be included in zone transfers - of the zone in which the RRset is authoritative data. In the case of - the DS RRset, this is the parent zone. - - NSEC RRs appear in both the parent and child zones at a zone cut and - are authoritative data in both the parent and child zones. The - parental and child NSEC RRs at a zone cut are never identical to each - other, as the NSEC RR in the child zone's apex will always indicate - the presence of the child zone's SOA RR whereas the parental NSEC RR - at the zone cut will never indicate the presence of an SOA RR. As - with any other authoritative RRs, NSEC RRs MUST be included in zone - transfers of the zone in which they are authoritative data. The - parental NSEC RR at a zone cut MUST be included in zone transfers of - the parent zone, and the NSEC at the zone apex of the child zone MUST - be included in zone transfers of the child zone. - - RRSIG RRs appear in both the parent and child zones at a zone cut and - are authoritative in whichever zone contains the authoritative RRset - for which the RRSIG RR provides the signature. That is, the RRSIG RR - for a DS RRset or a parental NSEC RR at a zone cut will be - authoritative in the parent zone, and the RRSIG for any RRset in the - child zone's apex will be authoritative in the child zone. Parental - and child RRSIG RRs at a zone cut will never be identical to each - other, as the Signer's Name field of an RRSIG RR in the child zone's - apex will indicate a DNSKEY RR in the child zone's apex whereas the - same field of a parental RRSIG RR at the zone cut will indicate a - DNSKEY RR in the parent zone's apex. As with any other authoritative - RRs, RRSIG RRs MUST be included in zone transfers of the zone in - which they are authoritative data. - -3.1.6. The AD and CD Bits in an Authoritative Response - - The CD and AD bits are designed for use in communication between - security-aware resolvers and security-aware recursive name servers. - These bits are for the most part not relevant to query processing by - security-aware authoritative name servers. - - A security-aware name server does not perform signature validation - for authoritative data during query processing, even when the CD bit - is clear. A security-aware name server SHOULD clear the CD bit when - composing an authoritative response. - - - - - -Arends, et al. Standards Track [Page 16] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - A security-aware name server MUST NOT set the AD bit in a response - unless the name server considers all RRsets in the Answer and - Authority sections of the response to be authentic. A security-aware - name server's local policy MAY consider data from an authoritative - zone to be authentic without further validation. However, the name - server MUST NOT do so unless the name server obtained the - authoritative zone via secure means (such as a secure zone transfer - mechanism) and MUST NOT do so unless this behavior has been - configured explicitly. - - A security-aware name server that supports recursion MUST follow the - rules for the CD and AD bits given in Section 3.2 when generating a - response that involves data obtained via recursion. - -3.2. Recursive Name Servers - - As explained in [RFC4033], a security-aware recursive name server is - an entity that acts in both the security-aware name server and - security-aware resolver roles. This section uses the terms "name - server side" and "resolver side" to refer to the code within a - security-aware recursive name server that implements the - security-aware name server role and the code that implements the - security-aware resolver role, respectively. - - The resolver side follows the usual rules for caching and negative - caching that would apply to any security-aware resolver. - -3.2.1. The DO Bit - - The resolver side of a security-aware recursive name server MUST set - the DO bit when sending requests, regardless of the state of the DO - bit in the initiating request received by the name server side. If - the DO bit in an initiating query is not set, the name server side - MUST strip any authenticating DNSSEC RRs from the response but MUST - NOT strip any DNSSEC RR types that the initiating query explicitly - requested. - -3.2.2. The CD Bit - - The CD bit exists in order to allow a security-aware resolver to - disable signature validation in a security-aware name server's - processing of a particular query. - - The name server side MUST copy the setting of the CD bit from a query - to the corresponding response. - - The name server side of a security-aware recursive name server MUST - pass the state of the CD bit to the resolver side along with the rest - - - -Arends, et al. Standards Track [Page 17] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - of an initiating query, so that the resolver side will know whether - it is required to verify the response data it returns to the name - server side. If the CD bit is set, it indicates that the originating - resolver is willing to perform whatever authentication its local - policy requires. Thus, the resolver side of the recursive name - server need not perform authentication on the RRsets in the response. - When the CD bit is set, the recursive name server SHOULD, if - possible, return the requested data to the originating resolver, even - if the recursive name server's local authentication policy would - reject the records in question. That is, by setting the CD bit, the - originating resolver has indicated that it takes responsibility for - performing its own authentication, and the recursive name server - should not interfere. - - If the resolver side implements a BAD cache (see Section 4.7) and the - name server side receives a query that matches an entry in the - resolver side's BAD cache, the name server side's response depends on - the state of the CD bit in the original query. If the CD bit is set, - the name server side SHOULD return the data from the BAD cache; if - the CD bit is not set, the name server side MUST return RCODE 2 - (server failure). - - The intent of the above rule is to provide the raw data to clients - that are capable of performing their own signature verification - checks while protecting clients that depend on the resolver side of a - security-aware recursive name server to perform such checks. Several - of the possible reasons why signature validation might fail involve - conditions that may not apply equally to the recursive name server - and the client that invoked it. For example, the recursive name - server's clock may be set incorrectly, or the client may have - knowledge of a relevant island of security that the recursive name - server does not share. In such cases, "protecting" a client that is - capable of performing its own signature validation from ever seeing - the "bad" data does not help the client. - -3.2.3. The AD Bit - - The name server side of a security-aware recursive name server MUST - NOT set the AD bit in a response unless the name server considers all - RRsets in the Answer and Authority sections of the response to be - authentic. The name server side SHOULD set the AD bit if and only if - the resolver side considers all RRsets in the Answer section and any - relevant negative response RRs in the Authority section to be - authentic. The resolver side MUST follow the procedure described in - Section 5 to determine whether the RRs in question are authentic. - However, for backward compatibility, a recursive name server MAY set - the AD bit when a response includes unsigned CNAME RRs if those CNAME - - - - -Arends, et al. Standards Track [Page 18] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - RRs demonstrably could have been synthesized from an authentic DNAME - RR that is also included in the response according to the synthesis - rules described in [RFC2672]. - -3.3. Example DNSSEC Responses - - See Appendix B for example response packets. - -4. Resolving - - This section describes the behavior of entities that include - security-aware resolver functions. In many cases such functions will - be part of a security-aware recursive name server, but a stand-alone - security-aware resolver has many of the same requirements. Functions - specific to security-aware recursive name servers are described in - Section 3.2. - -4.1. EDNS Support - - A security-aware resolver MUST include an EDNS ([RFC2671]) OPT - pseudo-RR with the DO ([RFC3225]) bit set when sending queries. - - A security-aware resolver MUST support a message size of at least - 1220 octets, SHOULD support a message size of 4000 octets, and MUST - use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR - to advertise the message size that it is willing to accept. A - security-aware resolver's IP layer MUST handle fragmented UDP packets - correctly regardless of whether any such fragmented packets were - received via IPv4 or IPv6. Please see [RFC1122], [RFC2460], and - [RFC3226] for discussion of these requirements. - -4.2. Signature Verification Support - - A security-aware resolver MUST support the signature verification - mechanisms described in Section 5 and SHOULD apply them to every - received response, except when: - - o the security-aware resolver is part of a security-aware recursive - name server, and the response is the result of recursion on behalf - of a query received with the CD bit set; - - o the response is the result of a query generated directly via some - form of application interface that instructed the security-aware - resolver not to perform validation for this query; or - - o validation for this query has been disabled by local policy. - - - - - -Arends, et al. Standards Track [Page 19] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - A security-aware resolver's support for signature verification MUST - include support for verification of wildcard owner names. - - Security-aware resolvers MAY query for missing security RRs in an - attempt to perform validation; implementations that choose to do so - must be aware that the answers received may not be sufficient to - validate the original response. For example, a zone update may have - changed (or deleted) the desired information between the original and - follow-up queries. - - When attempting to retrieve missing NSEC RRs that reside on the - parental side at a zone cut, a security-aware iterative-mode resolver - MUST query the name servers for the parent zone, not the child zone. - - When attempting to retrieve a missing DS, a security-aware - iterative-mode resolver MUST query the name servers for the parent - zone, not the child zone. As explained in Section 3.1.4.1, - security-aware name servers need to apply special processing rules to - handle the DS RR, and in some situations the resolver may also need - to apply special rules to locate the name servers for the parent zone - if the resolver does not already have the parent's NS RRset. To - locate the parent NS RRset, the resolver can start with the - delegation name, strip off the leftmost label, and query for an NS - RRset by that name. If no NS RRset is present at that name, the - resolver then strips off the leftmost remaining label and retries the - query for that name, repeating this process of walking up the tree - until it either finds the NS RRset or runs out of labels. - -4.3. Determining Security Status of Data - - A security-aware resolver MUST be able to determine whether it should - expect a particular RRset to be signed. More precisely, a - security-aware resolver must be able to distinguish between four - cases: - - Secure: An RRset for which the resolver is able to build a chain of - signed DNSKEY and DS RRs from a trusted security anchor to the - RRset. In this case, the RRset should be signed and is subject to - signature validation, as described above. - - Insecure: An RRset for which the resolver knows that it has no chain - of signed DNSKEY and DS RRs from any trusted starting point to the - RRset. This can occur when the target RRset lies in an unsigned - zone or in a descendent of an unsigned zone. In this case, the - RRset may or may not be signed, but the resolver will not be able - to verify the signature. - - - - - -Arends, et al. Standards Track [Page 20] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - Bogus: An RRset for which the resolver believes that it ought to be - able to establish a chain of trust but for which it is unable to - do so, either due to signatures that for some reason fail to - validate or due to missing data that the relevant DNSSEC RRs - indicate should be present. This case may indicate an attack but - may also indicate a configuration error or some form of data - corruption. - - Indeterminate: An RRset for which the resolver is not able to - determine whether the RRset should be signed, as the resolver is - not able to obtain the necessary DNSSEC RRs. This can occur when - the security-aware resolver is not able to contact security-aware - name servers for the relevant zones. - -4.4. Configured Trust Anchors - - A security-aware resolver MUST be capable of being configured with at - least one trusted public key or DS RR and SHOULD be capable of being - configured with multiple trusted public keys or DS RRs. Since a - security-aware resolver will not be able to validate signatures - without such a configured trust anchor, the resolver SHOULD have some - reasonably robust mechanism for obtaining such keys when it boots; - examples of such a mechanism would be some form of non-volatile - storage (such as a disk drive) or some form of trusted local network - configuration mechanism. - - Note that trust anchors also cover key material that is updated in a - secure manner. This secure manner could be through physical media, a - key exchange protocol, or some other out-of-band means. - -4.5. Response Caching - - A security-aware resolver SHOULD cache each response as a single - atomic entry containing the entire answer, including the named RRset - and any associated DNSSEC RRs. The resolver SHOULD discard the - entire atomic entry when any of the RRs contained in it expire. In - most cases the appropriate cache index for the atomic entry will be - the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response - form described in Section 3.1.3.2 the appropriate cache index will be - the double <QNAME,QCLASS>. - - The reason for these recommendations is that, between the initial - query and the expiration of the data from the cache, the - authoritative data might have been changed (for example, via dynamic - update). - - - - - - -Arends, et al. Standards Track [Page 21] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - There are two situations for which this is relevant: - - 1. By using the RRSIG record, it is possible to deduce that an - answer was synthesized from a wildcard. A security-aware - recursive name server could store this wildcard data and use it - to generate positive responses to queries other than the name for - which the original answer was first received. - - 2. NSEC RRs received to prove the non-existence of a name could be - reused by a security-aware resolver to prove the non-existence of - any name in the name range it spans. - - In theory, a resolver could use wildcards or NSEC RRs to generate - positive and negative responses (respectively) until the TTL or - signatures on the records in question expire. However, it seems - prudent for resolvers to avoid blocking new authoritative data or - synthesizing new data on their own. Resolvers that follow this - recommendation will have a more consistent view of the namespace. - -4.6. Handling of the CD and AD Bits - - A security-aware resolver MAY set a query's CD bit in order to - indicate that the resolver takes responsibility for performing - whatever authentication its local policy requires on the RRsets in - the response. See Section 3.2 for the effect this bit has on the - behavior of security-aware recursive name servers. - - A security-aware resolver MUST clear the AD bit when composing query - messages to protect against buggy name servers that blindly copy - header bits that they do not understand from the query message to the - response message. - - A resolver MUST disregard the meaning of the CD and AD bits in a - response unless the response was obtained by using a secure channel - or the resolver was specifically configured to regard the message - header bits without using a secure channel. - -4.7. Caching BAD Data - - While many validation errors will be transient, some are likely to be - more persistent, such as those caused by administrative error - (failure to re-sign a zone, clock skew, and so forth). Since - requerying will not help in these cases, validating resolvers might - generate a significant amount of unnecessary DNS traffic as a result - of repeated queries for RRsets with persistent validation failures. - - To prevent such unnecessary DNS traffic, security-aware resolvers MAY - cache data with invalid signatures, with some restrictions. - - - -Arends, et al. Standards Track [Page 22] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - Conceptually, caching such data is similar to negative caching - ([RFC2308]), except that instead of caching a valid negative - response, the resolver is caching the fact that a particular answer - failed to validate. This document refers to a cache of data with - invalid signatures as a "BAD cache". - - Resolvers that implement a BAD cache MUST take steps to prevent the - cache from being useful as a denial-of-service attack amplifier, - particularly the following: - - o Since RRsets that fail to validate do not have trustworthy TTLs, - the implementation MUST assign a TTL. This TTL SHOULD be small, - in order to mitigate the effect of caching the results of an - attack. - - o In order to prevent caching of a transient validation failure - (which might be the result of an attack), resolvers SHOULD track - queries that result in validation failures and SHOULD only answer - from the BAD cache after the number of times that responses to - queries for that particular <QNAME, QTYPE, QCLASS> have failed to - validate exceeds a threshold value. - - Resolvers MUST NOT return RRsets from the BAD cache unless the - resolver is not required to validate the signatures of the RRsets in - question under the rules given in Section 4.2 of this document. See - Section 3.2.2 for discussion of how the responses returned by a - security-aware recursive name server interact with a BAD cache. - -4.8. Synthesized CNAMEs - - A validating security-aware resolver MUST treat the signature of a - valid signed DNAME RR as also covering unsigned CNAME RRs that could - have been synthesized from the DNAME RR, as described in [RFC2672], - at least to the extent of not rejecting a response message solely - because it contains such CNAME RRs. The resolver MAY retain such - CNAME RRs in its cache or in the answers it hands back, but is not - required to do so. - -4.9. Stub Resolvers - - A security-aware stub resolver MUST support the DNSSEC RR types, at - least to the extent of not mishandling responses just because they - contain DNSSEC RRs. - - - - - - - - -Arends, et al. Standards Track [Page 23] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - -4.9.1. Handling of the DO Bit - - A non-validating security-aware stub resolver MAY include the DNSSEC - RRs returned by a security-aware recursive name server as part of the - data that the stub resolver hands back to the application that - invoked it, but is not required to do so. A non-validating stub - resolver that seeks to do this will need to set the DO bit in order - to receive DNSSEC RRs from the recursive name server. - - A validating security-aware stub resolver MUST set the DO bit, - because otherwise it will not receive the DNSSEC RRs it needs to - perform signature validation. - -4.9.2. Handling of the CD Bit - - A non-validating security-aware stub resolver SHOULD NOT set the CD - bit when sending queries unless it is requested by the application - layer, as by definition, a non-validating stub resolver depends on - the security-aware recursive name server to perform validation on its - behalf. - - A validating security-aware stub resolver SHOULD set the CD bit, - because otherwise the security-aware recursive name server will - answer the query using the name server's local policy, which may - prevent the stub resolver from receiving data that would be - acceptable to the stub resolver's local policy. - -4.9.3. Handling of the AD Bit - - A non-validating security-aware stub resolver MAY chose to examine - the setting of the AD bit in response messages that it receives in - order to determine whether the security-aware recursive name server - that sent the response claims to have cryptographically verified the - data in the Answer and Authority sections of the response message. - Note, however, that the responses received by a security-aware stub - resolver are heavily dependent on the local policy of the - security-aware recursive name server. Therefore, there may be little - practical value in checking the status of the AD bit, except perhaps - as a debugging aid. In any case, a security-aware stub resolver MUST - NOT place any reliance on signature validation allegedly performed on - its behalf, except when the security-aware stub resolver obtained the - data in question from a trusted security-aware recursive name server - via a secure channel. - - A validating security-aware stub resolver SHOULD NOT examine the - setting of the AD bit in response messages, as, by definition, the - stub resolver performs its own signature validation regardless of the - setting of the AD bit. - - - -Arends, et al. Standards Track [Page 24] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - -5. Authenticating DNS Responses - - To use DNSSEC RRs for authentication, a security-aware resolver - requires configured knowledge of at least one authenticated DNSKEY or - DS RR. The process for obtaining and authenticating this initial - trust anchor is achieved via some external mechanism. For example, a - resolver could use some off-line authenticated exchange to obtain a - zone's DNSKEY RR or to obtain a DS RR that identifies and - authenticates a zone's DNSKEY RR. The remainder of this section - assumes that the resolver has somehow obtained an initial set of - trust anchors. - - An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY - RRset. To authenticate an apex DNSKEY RRset by using an initial key, - the resolver MUST: - - 1. verify that the initial DNSKEY RR appears in the apex DNSKEY - RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA - bit 7) set; and - - 2. verify that there is some RRSIG RR that covers the apex DNSKEY - RRset, and that the combination of the RRSIG RR and the initial - DNSKEY RR authenticates the DNSKEY RRset. The process for using - an RRSIG RR to authenticate an RRset is described in Section 5.3. - - Once the resolver has authenticated the apex DNSKEY RRset by using an - initial DNSKEY RR, delegations from that zone can be authenticated by - using DS RRs. This allows a resolver to start from an initial key - and use DS RRsets to proceed recursively down the DNS tree, obtaining - other apex DNSKEY RRsets. If the resolver were configured with a - root DNSKEY RR, and if every delegation had a DS RR associated with - it, then the resolver could obtain and validate any apex DNSKEY - RRset. The process of using DS RRs to authenticate referrals is - described in Section 5.2. - - Section 5.3 shows how the resolver can use DNSKEY RRs in the apex - DNSKEY RRset and RRSIG RRs from the zone to authenticate any other - RRsets in the zone once the resolver has authenticated a zone's apex - DNSKEY RRset. Section 5.4 shows how the resolver can use - authenticated NSEC RRsets from the zone to prove that an RRset is not - present in the zone. - - When a resolver indicates support for DNSSEC (by setting the DO bit), - a security-aware name server should attempt to provide the necessary - DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). - However, a security-aware resolver may still receive a response that - lacks the appropriate DNSSEC RRs, whether due to configuration issues - such as an upstream security-oblivious recursive name server that - - - -Arends, et al. Standards Track [Page 25] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - accidentally interferes with DNSSEC RRs or due to a deliberate attack - in which an adversary forges a response, strips DNSSEC RRs from a - response, or modifies a query so that DNSSEC RRs appear not to be - requested. The absence of DNSSEC data in a response MUST NOT by - itself be taken as an indication that no authentication information - exists. - - A resolver SHOULD expect authentication information from signed - zones. A resolver SHOULD believe that a zone is signed if the - resolver has been configured with public key information for the - zone, or if the zone's parent is signed and the delegation from the - parent contains a DS RRset. - -5.1. Special Considerations for Islands of Security - - Islands of security (see [RFC4033]) are signed zones for which it is - not possible to construct an authentication chain to the zone from - its parent. Validating signatures within an island of security - requires that the validator have some other means of obtaining an - initial authenticated zone key for the island. If a validator cannot - obtain such a key, it SHOULD switch to operating as if the zones in - the island of security are unsigned. - - All the normal processes for validating responses apply to islands of - security. The only difference between normal validation and - validation within an island of security is in how the validator - obtains a trust anchor for the authentication chain. - -5.2. Authenticating Referrals - - Once the apex DNSKEY RRset for a signed parent zone has been - authenticated, DS RRsets can be used to authenticate the delegation - to a signed child zone. A DS RR identifies a DNSKEY RR in the child - zone's apex DNSKEY RRset and contains a cryptographic digest of the - child zone's DNSKEY RR. Use of a strong cryptographic digest - algorithm ensures that it is computationally infeasible for an - adversary to generate a DNSKEY RR that matches the digest. Thus, - authenticating the digest allows a resolver to authenticate the - matching DNSKEY RR. The resolver can then use this child DNSKEY RR - to authenticate the entire child apex DNSKEY RRset. - - Given a DS RR for a delegation, the child zone's apex DNSKEY RRset - can be authenticated if all of the following hold: - - o The DS RR has been authenticated using some DNSKEY RR in the - parent's apex DNSKEY RRset (see Section 5.3). - - - - - -Arends, et al. Standards Track [Page 26] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - o The Algorithm and Key Tag in the DS RR match the Algorithm field - and the key tag of a DNSKEY RR in the child zone's apex DNSKEY - RRset, and, when the DNSKEY RR's owner name and RDATA are hashed - using the digest algorithm specified in the DS RR's Digest Type - field, the resulting digest value matches the Digest field of the - DS RR. - - o The matching DNSKEY RR in the child zone has the Zone Flag bit - set, the corresponding private key has signed the child zone's - apex DNSKEY RRset, and the resulting RRSIG RR authenticates the - child zone's apex DNSKEY RRset. - - If the referral from the parent zone did not contain a DS RRset, the - response should have included a signed NSEC RRset proving that no DS - RRset exists for the delegated name (see Section 3.1.4). A - security-aware resolver MUST query the name servers for the parent - zone for the DS RRset if the referral includes neither a DS RRset nor - a NSEC RRset proving that the DS RRset does not exist (see Section - 4). - - If the validator authenticates an NSEC RRset that proves that no DS - RRset is present for this zone, then there is no authentication path - leading from the parent to the child. If the resolver has an initial - DNSKEY or DS RR that belongs to the child zone or to any delegation - below the child zone, this initial DNSKEY or DS RR MAY be used to - re-establish an authentication path. If no such initial DNSKEY or DS - RR exists, the validator cannot authenticate RRsets in or below the - child zone. - - If the validator does not support any of the algorithms listed in an - authenticated DS RRset, then the resolver has no supported - authentication path leading from the parent to the child. The - resolver should treat this case as it would the case of an - authenticated NSEC RRset proving that no DS RRset exists, as - described above. - - Note that, for a signed delegation, there are two NSEC RRs associated - with the delegated name. One NSEC RR resides in the parent zone and - can be used to prove whether a DS RRset exists for the delegated - name. The second NSEC RR resides in the child zone and identifies - which RRsets are present at the apex of the child zone. The parent - NSEC RR and child NSEC RR can always be distinguished because the SOA - bit will be set in the child NSEC RR and clear in the parent NSEC RR. - A security-aware resolver MUST use the parent NSEC RR when attempting - to prove that a DS RRset does not exist. - - - - - - -Arends, et al. Standards Track [Page 27] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - If the resolver does not support any of the algorithms listed in an - authenticated DS RRset, then the resolver will not be able to verify - the authentication path to the child zone. In this case, the - resolver SHOULD treat the child zone as if it were unsigned. - -5.3. Authenticating an RRset with an RRSIG RR - - A validator can use an RRSIG RR and its corresponding DNSKEY RR to - attempt to authenticate RRsets. The validator first checks the RRSIG - RR to verify that it covers the RRset, has a valid time interval, and - identifies a valid DNSKEY RR. The validator then constructs the - canonical form of the signed data by appending the RRSIG RDATA - (excluding the Signature Field) with the canonical form of the - covered RRset. Finally, the validator uses the public key and - signature to authenticate the signed data. Sections 5.3.1, 5.3.2, - and 5.3.3 describe each step in detail. - -5.3.1. Checking the RRSIG RR Validity - - A security-aware resolver can use an RRSIG RR to authenticate an - RRset if all of the following conditions hold: - - o The RRSIG RR and the RRset MUST have the same owner name and the - same class. - - o The RRSIG RR's Signer's Name field MUST be the name of the zone - that contains the RRset. - - o The RRSIG RR's Type Covered field MUST equal the RRset's type. - - o The number of labels in the RRset owner name MUST be greater than - or equal to the value in the RRSIG RR's Labels field. - - o The validator's notion of the current time MUST be less than or - equal to the time listed in the RRSIG RR's Expiration field. - - o The validator's notion of the current time MUST be greater than or - equal to the time listed in the RRSIG RR's Inception field. - - o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST - match the owner name, algorithm, and key tag for some DNSKEY RR in - the zone's apex DNSKEY RRset. - - o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY - RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) - set. - - - - - -Arends, et al. Standards Track [Page 28] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - It is possible for more than one DNSKEY RR to match the conditions - above. In this case, the validator cannot predetermine which DNSKEY - RR to use to authenticate the signature, and it MUST try each - matching DNSKEY RR until either the signature is validated or the - validator has run out of matching public keys to try. - - Note that this authentication process is only meaningful if the - validator authenticates the DNSKEY RR before using it to validate - signatures. The matching DNSKEY RR is considered to be authentic if: - - o the apex DNSKEY RRset containing the DNSKEY RR is considered - authentic; or - - o the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, - and the DNSKEY RR either matches an authenticated DS RR from the - parent zone or matches a trust anchor. - -5.3.2. Reconstructing the Signed Data - - Once the RRSIG RR has met the validity requirements described in - Section 5.3.1, the validator has to reconstruct the original signed - data. The original signed data includes RRSIG RDATA (excluding the - Signature field) and the canonical form of the RRset. Aside from - being ordered, the canonical form of the RRset might also differ from - the received RRset due to DNS name compression, decremented TTLs, or - wildcard expansion. The validator should use the following to - reconstruct the original signed data: - - signed_data = RRSIG_RDATA | RR(1) | RR(2)... where - - "|" denotes concatenation - - RRSIG_RDATA is the wire format of the RRSIG RDATA fields - with the Signature field excluded and the Signer's Name - in canonical form. - - RR(i) = name | type | class | OrigTTL | RDATA length | RDATA - - name is calculated according to the function below - - class is the RRset's class - - type is the RRset type and all RRs in the class - - OrigTTL is the value from the RRSIG Original TTL field - - All names in the RDATA field are in canonical form - - - - -Arends, et al. Standards Track [Page 29] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - The set of all RR(i) is sorted into canonical order. - - To calculate the name: - let rrsig_labels = the value of the RRSIG Labels field - - let fqdn = RRset's fully qualified domain name in - canonical form - - let fqdn_labels = Label count of the fqdn above. - - if rrsig_labels = fqdn_labels, - name = fqdn - - if rrsig_labels < fqdn_labels, - name = "*." | the rightmost rrsig_label labels of the - fqdn - - if rrsig_labels > fqdn_labels - the RRSIG RR did not pass the necessary validation - checks and MUST NOT be used to authenticate this - RRset. - - The canonical forms for names and RRsets are defined in [RFC4034]. - - NSEC RRsets at a delegation boundary require special processing. - There are two distinct NSEC RRsets associated with a signed delegated - name. One NSEC RRset resides in the parent zone, and specifies which - RRsets are present at the parent zone. The second NSEC RRset resides - at the child zone and identifies which RRsets are present at the apex - in the child zone. The parent NSEC RRset and child NSEC RRset can - always be distinguished as only a child NSEC RR will indicate that an - SOA RRset exists at the name. When reconstructing the original NSEC - RRset for the delegation from the parent zone, the NSEC RRs MUST NOT - be combined with NSEC RRs from the child zone. When reconstructing - the original NSEC RRset for the apex of the child zone, the NSEC RRs - MUST NOT be combined with NSEC RRs from the parent zone. - - Note that each of the two NSEC RRsets at a delegation point has a - corresponding RRSIG RR with an owner name matching the delegated - name, and each of these RRSIG RRs is authoritative data associated - with the same zone that contains the corresponding NSEC RRset. If - necessary, a resolver can tell these RRSIG RRs apart by checking the - Signer's Name field. - - - - - - - - -Arends, et al. Standards Track [Page 30] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - -5.3.3. Checking the Signature - - Once the resolver has validated the RRSIG RR as described in Section - 5.3.1 and reconstructed the original signed data as described in - Section 5.3.2, the validator can attempt to use the cryptographic - signature to authenticate the signed data, and thus (finally!) - authenticate the RRset. - - The Algorithm field in the RRSIG RR identifies the cryptographic - algorithm used to generate the signature. The signature itself is - contained in the Signature field of the RRSIG RDATA, and the public - key used to verify the signature is contained in the Public Key field - of the matching DNSKEY RR(s) (found in Section 5.3.1). [RFC4034] - provides a list of algorithm types and provides pointers to the - documents that define each algorithm's use. - - Note that it is possible for more than one DNSKEY RR to match the - conditions in Section 5.3.1. In this case, the validator can only - determine which DNSKEY RR is correct by trying each matching public - key until the validator either succeeds in validating the signature - or runs out of keys to try. - - If the Labels field of the RRSIG RR is not equal to the number of - labels in the RRset's fully qualified owner name, then the RRset is - either invalid or the result of wildcard expansion. The resolver - MUST verify that wildcard expansion was applied properly before - considering the RRset to be authentic. Section 5.3.4 describes how - to determine whether a wildcard was applied properly. - - If other RRSIG RRs also cover this RRset, the local resolver security - policy determines whether the resolver also has to test these RRSIG - RRs and how to resolve conflicts if these RRSIG RRs lead to differing - results. - - If the resolver accepts the RRset as authentic, the validator MUST - set the TTL of the RRSIG RR and each RR in the authenticated RRset to - a value no greater than the minimum of: - - o the RRset's TTL as received in the response; - - o the RRSIG RR's TTL as received in the response; - - o the value in the RRSIG RR's Original TTL field; and - - o the difference of the RRSIG RR's Signature Expiration time and the - current time. - - - - - -Arends, et al. Standards Track [Page 31] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - -5.3.4. Authenticating a Wildcard Expanded RRset Positive Response - - If the number of labels in an RRset's owner name is greater than the - Labels field of the covering RRSIG RR, then the RRset and its - covering RRSIG RR were created as a result of wildcard expansion. - Once the validator has verified the signature, as described in - Section 5.3, it must take additional steps to verify the non- - existence of an exact match or closer wildcard match for the query. - Section 5.4 discusses these steps. - - Note that the response received by the resolver should include all - NSEC RRs needed to authenticate the response (see Section 3.1.3). - -5.4. Authenticated Denial of Existence - - A resolver can use authenticated NSEC RRs to prove that an RRset is - not present in a signed zone. Security-aware name servers should - automatically include any necessary NSEC RRs for signed zones in - their responses to security-aware resolvers. - - Denial of existence is determined by the following rules: - - o If the requested RR name matches the owner name of an - authenticated NSEC RR, then the NSEC RR's type bit map field lists - all RR types present at that owner name, and a resolver can prove - that the requested RR type does not exist by checking for the RR - type in the bit map. If the number of labels in an authenticated - NSEC RR's owner name equals the Labels field of the covering RRSIG - RR, then the existence of the NSEC RR proves that wildcard - expansion could not have been used to match the request. - - o If the requested RR name would appear after an authenticated NSEC - RR's owner name and before the name listed in that NSEC RR's Next - Domain Name field according to the canonical DNS name order - defined in [RFC4034], then no RRsets with the requested name exist - in the zone. However, it is possible that a wildcard could be - used to match the requested RR owner name and type, so proving - that the requested RRset does not exist also requires proving that - no possible wildcard RRset exists that could have been used to - generate a positive response. - - In addition, security-aware resolvers MUST authenticate the NSEC - RRsets that comprise the non-existence proof as described in Section - 5.3. - - To prove the non-existence of an RRset, the resolver must be able to - verify both that the queried RRset does not exist and that no - relevant wildcard RRset exists. Proving this may require more than - - - -Arends, et al. Standards Track [Page 32] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - one NSEC RRset from the zone. If the complete set of necessary NSEC - RRsets is not present in a response (perhaps due to message - truncation), then a security-aware resolver MUST resend the query in - order to attempt to obtain the full collection of NSEC RRs necessary - to verify the non-existence of the requested RRset. As with all DNS - operations, however, the resolver MUST bound the work it puts into - answering any particular query. - - Since a validated NSEC RR proves the existence of both itself and its - corresponding RRSIG RR, a validator MUST ignore the settings of the - NSEC and RRSIG bits in an NSEC RR. - -5.5. Resolver Behavior When Signatures Do Not Validate - - If for whatever reason none of the RRSIGs can be validated, the - response SHOULD be considered BAD. If the validation was being done - to service a recursive query, the name server MUST return RCODE 2 to - the originating client. However, it MUST return the full response if - and only if the original query had the CD bit set. Also see Section - 4.7 on caching responses that do not validate. - -5.6. Authentication Example - - Appendix C shows an example of the authentication process. - -6. IANA Considerations - - [RFC4034] contains a review of the IANA considerations introduced by - DNSSEC. The following are additional IANA considerations discussed - in this document: - - [RFC2535] reserved the CD and AD bits in the message header. The - meaning of the AD bit was redefined in [RFC3655], and the meaning of - both the CD and AD bit are restated in this document. No new bits in - the DNS message header are defined in this document. - - [RFC2671] introduced EDNS, and [RFC3225] reserved the DNSSEC OK bit - and defined its use. The use is restated but not altered in this - document. - -7. Security Considerations - - This document describes how the DNS security extensions use public - key cryptography to sign and authenticate DNS resource record sets. - Please see [RFC4033] for terminology and general security - considerations related to DNSSEC; see [RFC4034] for considerations - specific to the DNSSEC resource record types. - - - - -Arends, et al. Standards Track [Page 33] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - An active attacker who can set the CD bit in a DNS query message or - the AD bit in a DNS response message can use these bits to defeat the - protection that DNSSEC attempts to provide to security-oblivious - recursive-mode resolvers. For this reason, use of these control bits - by a security-aware recursive-mode resolver requires a secure - channel. See Sections 3.2.2 and 4.9 for further discussion. - - The protocol described in this document attempts to extend the - benefits of DNSSEC to security-oblivious stub resolvers. However, as - recovery from validation failures is likely to be specific to - particular applications, the facilities that DNSSEC provides for stub - resolvers may prove inadequate. Operators of security-aware - recursive name servers will have to pay close attention to the - behavior of the applications that use their services when choosing a - local validation policy; failure to do so could easily result in the - recursive name server accidentally denying service to the clients it - is intended to support. - -8. Acknowledgements - - This document was created from the input and ideas of the members of - the DNS Extensions Working Group and working group mailing list. The - editors would like to express their thanks for the comments and - suggestions received during the revision of these security extension - specifications. Although explicitly listing everyone who has - contributed during the decade in which DNSSEC has been under - development would be impossible, [RFC4033] includes a list of some of - the participants who were kind enough to comment on these documents. - -9. References - -9.1. Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1122] Braden, R., "Requirements for Internet Hosts - - Communication Layers", STD 3, RFC 1122, October 1989. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - - - -Arends, et al. Standards Track [Page 34] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 - (IPv6) Specification", RFC 2460, December 1998. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC - 2672, August 1999. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC - 3225, December 2001. - - [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver - message size requirements", RFC 3226, December 2001. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", RFC - 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for DNS Security Extensions", RFC - 4034, March 2005. - -9.2. Informative References - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2535] Eastlake 3rd, D., "Domain Name System Security - Extensions", RFC 2535, March 1999. - - [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS - Authenticated Data (AD) bit", RFC 3655, November 2003. - - - - - - - - - - - - - - - -Arends, et al. Standards Track [Page 35] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - -Appendix A. Signed Zone Example - - The following example shows a (small) complete signed zone. - - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1081539377 - 3600 - 300 - 3600000 - 3600 - ) - 3600 RRSIG SOA 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h - 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF - vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW - DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB - jV7j86HyQgM5e7+miRAz8V01b0I= ) - 3600 NS ns1.example. - 3600 NS ns2.example. - 3600 RRSIG NS 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd - EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf - 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 - RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 - 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) - 3600 MX 1 xx.example. - 3600 RRSIG MX 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB - 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE - VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO - 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM - W6OISukd1EQt7a0kygkg+PEDxdI= ) - 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY - 3600 RRSIG NSEC 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm - FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V - Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW - SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm - jfFJ5arXf4nPxp/kEowGgBRzY/U= ) - 3600 DNSKEY 256 3 5 ( - AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV - rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e - k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo - vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI - - - -Arends, et al. Standards Track [Page 36] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - ySFNsgEYvh0z2542lzMKR4Dh8uZffQ== - ) - 3600 DNSKEY 257 3 5 ( - AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl - LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ - syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP - RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT - Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q== - ) - 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( - 20040409183619 9465 example. - ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ - xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ - XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9 - hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY - NC3AHfvCV1Tp4VKDqxqG7R5tTVM= ) - 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z - DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri - bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp - eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk - 7z5OXogYVaFzHKillDt3HRxHIZM= ) - a.example. 3600 IN NS ns1.a.example. - 3600 IN NS ns2.a.example. - 3600 DS 57855 5 1 ( - B6DCD485719ADCA18E5F3D48A2331627FDD3 - 636B ) - 3600 RRSIG DS 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ - oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH - kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD - EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ - Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) - 3600 NSEC ai.example. NS DS RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba - U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2 - 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I - BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g - sdkOW6Zyqtz3Zos8N0BBkEx+2G4= ) - ns1.a.example. 3600 IN A 192.0.2.5 - ns2.a.example. 3600 IN A 192.0.2.6 - ai.example. 3600 IN A 192.0.2.9 - 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - - - -Arends, et al. Standards Track [Page 37] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B - ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd - hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u - ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy - 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) - 3600 HINFO "KLH-10" "ITS" - 3600 RRSIG HINFO 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l - e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh - ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7 - AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw - FvL8sqlS5QS6FY/ijFEDnI4RkZA= ) - 3600 AAAA 2001:db8::f00:baa9 - 3600 RRSIG AAAA 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK - kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh - 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T - cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 - sZM6QjBBLmukH30+w1z3h8PUP2o= ) - 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG - CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p - P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN - 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL - AhS+JOVfDI/79QtyTI0SaDWcg8U= ) - b.example. 3600 IN NS ns1.b.example. - 3600 IN NS ns2.b.example. - 3600 NSEC ns1.example. NS RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx - 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS - xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs - 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ - vhRXgWT7OuFXldoCG6TfVFMs9xE= ) - ns1.b.example. 3600 IN A 192.0.2.7 - ns2.b.example. 3600 IN A 192.0.2.8 - ns1.example. 3600 IN A 192.0.2.1 - 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet - 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 - im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ - +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK - - - -Arends, et al. Standards Track [Page 38] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - v/iVXSYC0b7mPSU+EOlknFpVECs= ) - 3600 NSEC ns2.example. A RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 - 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB - jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq - ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 - IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) - ns2.example. 3600 IN A 192.0.2.2 - 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq - Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu - yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO - 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq - rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) - 3600 NSEC *.w.example. A RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE - VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb - 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH - l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw - Ymx28EtgIpo9A0qmP08rMBqs1Jw= ) - *.w.example. 3600 IN MX 1 ai.example. - 3600 RRSIG MX 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 - f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc - tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X - TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw - 4kX18MMR34i8lC36SR5xBni8vHI= ) - 3600 NSEC x.w.example. MX RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 - HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU - 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx - 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 - s1InQ2UoIv6tJEaaKkP701j8OLA= ) - x.w.example. 3600 IN MX 1 xx.example. - 3600 RRSIG MX 5 3 3600 20040509183619 ( - 20040409183619 38519 example. - Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 - XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP - H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I - kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 - - - -Arends, et al. Standards Track [Page 39] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) - 3600 NSEC x.y.w.example. MX RRSIG NSEC - 3600 RRSIG NSEC 5 3 3600 20040509183619 ( - 20040409183619 38519 example. - aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK - vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E - mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI - NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e - IjgiM8PXkBQtxPq37wDKALkyn7Q= ) - x.y.w.example. 3600 IN MX 1 xx.example. - 3600 RRSIG MX 5 4 3600 20040509183619 ( - 20040409183619 38519 example. - k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia - t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj - q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq - GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb - +gLcMZBnHJ326nb/TOOmrqNmQQE= ) - 3600 NSEC xx.example. MX RRSIG NSEC - 3600 RRSIG NSEC 5 4 3600 20040509183619 ( - 20040409183619 38519 example. - OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp - ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg - xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX - a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr - QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) - xx.example. 3600 IN A 192.0.2.10 - 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP - 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa - 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y - VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx - kbIDV6GPPSZVusnZU6OMgdgzHV4= ) - 3600 HINFO "KLH-10" "TOPS-20" - 3600 RRSIG HINFO 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0 - t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq - BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8 - 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+ - RgNvuwbioFSEuv2pNlkq0goYxNY= ) - 3600 AAAA 2001:db8::f00:baaa - 3600 RRSIG AAAA 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C - aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z - ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr - U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ - - - -Arends, et al. Standards Track [Page 40] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - xS9cL2QgW7FChw16mzlkH6/vsfs= ) - 3600 NSEC example. A HINFO AAAA RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY - 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k - mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi - asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W - GghLahumFIpg4MO3LS/prgzVVWo= ) - - The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA - Flags indicate that each of these DNSKEY RRs is a zone key. One of - these DNSKEY RRs also has the SEP flag set and has been used to sign - the apex DNSKEY RRset; this is the key that should be hashed to - generate a DS record to be inserted into the parent zone. The other - DNSKEY is used to sign all the other RRsets in the zone. - - The zone includes a wildcard entry, "*.w.example". Note that the - name "*.w.example" is used in constructing NSEC chains, and that the - RRSIG covering the "*.w.example" MX RRset has a label count of 2. - - The zone also includes two delegations. The delegation to - "b.example" includes an NS RRset, glue address records, and an NSEC - RR; note that only the NSEC RRset is signed. The delegation to - "a.example" provides a DS RR; note that only the NSEC and DS RRsets - are signed. - -Appendix B. Example Responses - - The examples in this section show response messages using the signed - zone example in Appendix A. - -B.1. Answer - - A successful query to an authoritative server. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - x.w.example. IN MX - - ;; Answer - x.w.example. 3600 IN MX 1 xx.example. - x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 ( - 20040409183619 38519 example. - Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 - XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP - H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I - - - -Arends, et al. Standards Track [Page 41] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 - jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) - - ;; Authority - example. 3600 NS ns1.example. - example. 3600 NS ns2.example. - example. 3600 RRSIG NS 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd - EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf - 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 - RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 - 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) - - ;; Additional - xx.example. 3600 IN A 192.0.2.10 - xx.example. 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP - 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa - 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y - VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx - kbIDV6GPPSZVusnZU6OMgdgzHV4= ) - xx.example. 3600 AAAA 2001:db8::f00:baaa - xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C - aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z - ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr - U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ - xS9cL2QgW7FChw16mzlkH6/vsfs= ) - ns1.example. 3600 IN A 192.0.2.1 - ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet - 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 - im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ - +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK - v/iVXSYC0b7mPSU+EOlknFpVECs= ) - ns2.example. 3600 IN A 192.0.2.2 - ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq - Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu - yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO - 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq - rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) - - - - -Arends, et al. Standards Track [Page 42] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - -B.2. Name Error - - An authoritative name error. The NSEC RRs prove that the name does - not exist and that no covering wildcard exists. - - ;; Header: QR AA DO RCODE=3 - ;; - ;; Question - ml.example. IN A - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1081539377 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h - 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF - vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW - DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB - jV7j86HyQgM5e7+miRAz8V01b0I= ) - b.example. 3600 NSEC ns1.example. NS RRSIG NSEC - b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx - 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS - xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs - 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ - vhRXgWT7OuFXldoCG6TfVFMs9xE= ) - example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY - example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm - FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V - Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW - SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm - jfFJ5arXf4nPxp/kEowGgBRzY/U= ) - - ;; Additional - ;; (empty) - - - - -Arends, et al. Standards Track [Page 43] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - -B.3. No Data Error - - A "no data" response. The NSEC RR proves that the name exists and - that the requested RR type does not. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - ns1.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1081539377 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h - 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF - vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW - DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB - jV7j86HyQgM5e7+miRAz8V01b0I= ) - ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC - ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 - 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB - jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq - ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 - IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) - - ;; Additional - ;; (empty) - -B.4. Referral to Signed Zone - - Referral to a signed zone. The DS RR contains the data which the - resolver will need to validate the corresponding DNSKEY RR in the - child zone's apex. - - ;; Header: QR DO RCODE=0 - ;; - - - -Arends, et al. Standards Track [Page 44] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - ;; Question - mc.a.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - a.example. 3600 IN NS ns1.a.example. - a.example. 3600 IN NS ns2.a.example. - a.example. 3600 DS 57855 5 1 ( - B6DCD485719ADCA18E5F3D48A2331627FDD3 - 636B ) - a.example. 3600 RRSIG DS 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ - oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH - kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD - EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ - Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) - - ;; Additional - ns1.a.example. 3600 IN A 192.0.2.5 - ns2.a.example. 3600 IN A 192.0.2.6 - -B.5. Referral to Unsigned Zone - - Referral to an unsigned zone. The NSEC RR proves that no DS RR for - this delegation exists in the parent zone. - - ;; Header: QR DO RCODE=0 - ;; - ;; Question - mc.b.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - b.example. 3600 IN NS ns1.b.example. - b.example. 3600 IN NS ns2.b.example. - b.example. 3600 NSEC ns1.example. NS RRSIG NSEC - b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx - 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS - xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs - 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ - vhRXgWT7OuFXldoCG6TfVFMs9xE= ) - - - -Arends, et al. Standards Track [Page 45] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - ;; Additional - ns1.b.example. 3600 IN A 192.0.2.7 - ns2.b.example. 3600 IN A 192.0.2.8 - -B.6. Wildcard Expansion - - A successful query that was answered via wildcard expansion. The - label count in the answer's RRSIG RR indicates that a wildcard RRset - was expanded to produce this response, and the NSEC RR proves that no - closer match exists in the zone. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - a.z.w.example. IN MX - - ;; Answer - a.z.w.example. 3600 IN MX 1 ai.example. - a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 - f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc - tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X - TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw - 4kX18MMR34i8lC36SR5xBni8vHI= ) - - ;; Authority - example. 3600 NS ns1.example. - example. 3600 NS ns2.example. - example. 3600 RRSIG NS 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd - EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf - 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 - RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 - 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) - x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC - x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( - 20040409183619 38519 example. - OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp - ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg - xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX - a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr - QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) - - ;; Additional - ai.example. 3600 IN A 192.0.2.9 - ai.example. 3600 RRSIG A 5 2 3600 20040509183619 ( - - - -Arends, et al. Standards Track [Page 46] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - 20040409183619 38519 example. - pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B - ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd - hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u - ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy - 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) - ai.example. 3600 AAAA 2001:db8::f00:baa9 - ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK - kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh - 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T - cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 - sZM6QjBBLmukH30+w1z3h8PUP2o= ) - -B.7. Wildcard No Data Error - - A "no data" response for a name covered by a wildcard. The NSEC RRs - prove that the matching wildcard name does not have any RRs of the - requested type and that no closer match exists in the zone. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - a.z.w.example. IN AAAA - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1081539377 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h - 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF - vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW - DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB - jV7j86HyQgM5e7+miRAz8V01b0I= ) - x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC - x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( - 20040409183619 38519 example. - OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp - - - -Arends, et al. Standards Track [Page 47] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg - xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX - a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr - QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) - *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC - *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 - HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU - 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx - 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 - s1InQ2UoIv6tJEaaKkP701j8OLA= ) - - ;; Additional - ;; (empty) - -B.8. DS Child Zone No Data Error - - A "no data" response for a QTYPE=DS query that was mistakenly sent to - a name server for the child zone. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - example. IN DS - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1081539377 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h - 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF - vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW - DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB - jV7j86HyQgM5e7+miRAz8V01b0I= ) - example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY - example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm - - - -Arends, et al. Standards Track [Page 48] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V - Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW - SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm - jfFJ5arXf4nPxp/kEowGgBRzY/U= ) - - ;; Additional - ;; (empty) - -Appendix C. Authentication Examples - - The examples in this section show how the response messages in - Appendix B are authenticated. - -C.1. Authenticating an Answer - - The query in Appendix B.1 returned an MX RRset for "x.w.example.com". - The corresponding RRSIG indicates that the MX RRset was signed by an - "example" DNSKEY with algorithm 5 and key tag 38519. The resolver - needs the corresponding DNSKEY RR in order to authenticate this - answer. The discussion below describes how a resolver might obtain - this DNSKEY RR. - - The RRSIG indicates the original TTL of the MX RRset was 3600, and, - for the purpose of authentication, the current TTL is replaced by - 3600. The RRSIG labels field value of 3 indicates that the answer - was not the result of wildcard expansion. The "x.w.example.com" MX - RRset is placed in canonical form, and, assuming the current time - falls between the signature inception and expiration dates, the - signature is authenticated. - -C.1.1. Authenticating the Example DNSKEY RR - - This example shows the logical authentication process that starts - from the a configured root DNSKEY (or DS RR) and moves down the tree - to authenticate the desired "example" DNSKEY RR. Note that the - logical order is presented for clarity. An implementation may choose - to construct the authentication as referrals are received or to - construct the authentication chain only after all RRsets have been - obtained, or in any other combination it sees fit. The example here - demonstrates only the logical process and does not dictate any - implementation rules. - - We assume the resolver starts with a configured DNSKEY RR for the - root zone (or a configured DS RR for the root zone). The resolver - checks whether this configured DNSKEY RR is present in the root - DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root - DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY - RRset, and whether the signature lifetime is valid. If all these - - - -Arends, et al. Standards Track [Page 49] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - conditions are met, all keys in the DNSKEY RRset are considered - authenticated. The resolver then uses one (or more) of the root - DNSKEY RRs to authenticate the "example" DS RRset. Note that the - resolver may have to query the root zone to obtain the root DNSKEY - RRset or "example" DS RRset. - - Once the DS RRset has been authenticated using the root DNSKEY, the - resolver checks the "example" DNSKEY RRset for some "example" DNSKEY - RR that matches one of the authenticated "example" DS RRs. If such a - matching "example" DNSKEY is found, the resolver checks whether this - DNSKEY RR has signed the "example" DNSKEY RRset and the signature - lifetime is valid. If these conditions are met, all keys in the - "example" DNSKEY RRset are considered authenticated. - - Finally, the resolver checks that some DNSKEY RR in the "example" - DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This - DNSKEY is used to authenticate the RRSIG included in the response. - If multiple "example" DNSKEY RRs match this algorithm and key tag, - then each DNSKEY RR is tried, and the answer is authenticated if any - of the matching DNSKEY RRs validate the signature as described above. - -C.2. Name Error - - The query in Appendix B.2 returned NSEC RRs that prove that the - requested data does not exist and no wildcard applies. The negative - reply is authenticated by verifying both NSEC RRs. The NSEC RRs are - authenticated in a manner identical to that of the MX RRset discussed - above. - -C.3. No Data Error - - The query in Appendix B.3 returned an NSEC RR that proves that the - requested name exists, but the requested RR type does not exist. The - negative reply is authenticated by verifying the NSEC RR. The NSEC - RR is authenticated in a manner identical to that of the MX RRset - discussed above. - -C.4. Referral to Signed Zone - - The query in Appendix B.4 returned a referral to the signed - "a.example." zone. The DS RR is authenticated in a manner identical - to that of the MX RRset discussed above. This DS RR is used to - authenticate the "a.example" DNSKEY RRset. - - Once the "a.example" DS RRset has been authenticated using the - "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset - for some "a.example" DNSKEY RR that matches the DS RR. If such a - matching "a.example" DNSKEY is found, the resolver checks whether - - - -Arends, et al. Standards Track [Page 50] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - - this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether - the signature lifetime is valid. If all these conditions are met, - all keys in the "a.example" DNSKEY RRset are considered - authenticated. - -C.5. Referral to Unsigned Zone - - The query in Appendix B.5 returned a referral to an unsigned - "b.example." zone. The NSEC proves that no authentication leads from - "example" to "b.example", and the NSEC RR is authenticated in a - manner identical to that of the MX RRset discussed above. - -C.6. Wildcard Expansion - - The query in Appendix B.6 returned an answer that was produced as a - result of wildcard expansion. The answer section contains a wildcard - RRset expanded as it would be in a traditional DNS response, and the - corresponding RRSIG indicates that the expanded wildcard MX RRset was - signed by an "example" DNSKEY with algorithm 5 and key tag 38519. - The RRSIG indicates that the original TTL of the MX RRset was 3600, - and, for the purpose of authentication, the current TTL is replaced - by 3600. The RRSIG labels field value of 2 indicates that the answer - is the result of wildcard expansion, as the "a.z.w.example" name - contains 4 labels. The name "a.z.w.w.example" is replaced by - "*.w.example", the MX RRset is placed in canonical form, and, - assuming that the current time falls between the signature inception - and expiration dates, the signature is authenticated. - - The NSEC proves that no closer match (exact or closer wildcard) could - have been used to answer this query, and the NSEC RR must also be - authenticated before the answer is considered valid. - -C.7. Wildcard No Data Error - - The query in Appendix B.7 returned NSEC RRs that prove that the - requested data does not exist and no wildcard applies. The negative - reply is authenticated by verifying both NSEC RRs. - -C.8. DS Child Zone No Data Error - - The query in Appendix B.8 returned NSEC RRs that shows the requested - was answered by a child server ("example" server). The NSEC RR - indicates the presence of an SOA RR, showing that the answer is from - the child . Queries for the "example" DS RRset should be sent to the - parent servers ("root" servers). - - - - - - -Arends, et al. Standards Track [Page 51] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Brouwerijstraat 1 - 7523 XC Enschede - NL - - EMail: roy.arends@telin.nl - - - Rob Austein - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Dan Massey - Colorado State University - Department of Computer Science - Fort Collins, CO 80523-1873 - - EMail: massey@cs.colostate.edu - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - - -Arends, et al. Standards Track [Page 52] - -RFC 4035 DNSSEC Protocol Modifications March 2005 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2005). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Arends, et al. Standards Track [Page 53] - diff --git a/contrib/bind9/doc/rfc/rfc4074.txt b/contrib/bind9/doc/rfc/rfc4074.txt deleted file mode 100644 index d9252b39eb59..000000000000 --- a/contrib/bind9/doc/rfc/rfc4074.txt +++ /dev/null @@ -1,339 +0,0 @@ - - - - - - -Network Working Group Y. Morishita -Request for Comments: 4074 JPRS -Category: Informational T. Jinmei - Toshiba - May 2005 - - - Common Misbehavior Against DNS Queries for IPv6 Addresses - -Status of This Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - There is some known misbehavior of DNS authoritative servers when - they are queried for AAAA resource records. Such behavior can block - IPv4 communication that should actually be available, cause a - significant delay in name resolution, or even make a denial of - service attack. This memo describes details of known cases and - discusses their effects. - -1. Introduction - - Many existing DNS clients (resolvers) that support IPv6 first search - for AAAA Resource Records (RRs) of a target host name, and then for A - RRs of the same name. This fallback mechanism is based on the DNS - specifications, which if not obeyed by authoritative servers, can - produce unpleasant results. In some cases, for example, a web - browser fails to connect to a web server it could otherwise reach. - In the following sections, this memo describes some typical cases of - such misbehavior and its (bad) effects. - - Note that the misbehavior is not specific to AAAA RRs. In fact, all - known examples also apply to the cases of queries for MX, NS, and SOA - RRs. The authors believe this can be generalized for all types of - queries other than those for A RRs. In this memo, however, we - concentrate on the case for AAAA queries, since the problem is - particularly severe for resolvers that support IPv6, which thus - affects many end users. Resolvers at end users normally send A - and/or AAAA queries only, so the problem for the other cases is - relatively minor. - - - -Morishita & Jinmei Informational [Page 1] - -RFC 4074 Common Misbehavior Against DNS Queries May 2005 - - -2. Network Model - - In this memo, we assume a typical network model of name resolution - environment using DNS. It consists of three components: stub - resolvers, caching servers, and authoritative servers. A stub - resolver issues a recursive query to a caching server, which then - handles the entire name resolution procedure recursively. The - caching server caches the result of the query and sends the result to - the stub resolver. The authoritative servers respond to queries for - names for which they have the authority, normally in a non-recursive - manner. - -3. Expected Behavior - - Suppose that an authoritative server has an A RR but has no AAAA RR - for a host name. Then, the server should return a response to a - query for an AAAA RR of the name with the response code (RCODE) being - 0 (indicating no error) and with an empty answer section (see - Sections 4.3.2 and 6.2.4 of [1]). Such a response indicates that - there is at least one RR of a different type than AAAA for the - queried name, and the stub resolver can then look for A RRs. - - This way, the caching server can cache the fact that the queried name - has no AAAA RR (but may have other types of RRs), and thus improve - the response time to further queries for an AAAA RR of the name. - -4. Problematic Behaviors - - There are some known cases at authoritative servers that do not - conform to the expected behavior. This section describes those - problematic cases. - -4.1. Ignore Queries for AAAA - - Some authoritative servers seem to ignore queries for an AAAA RR, - causing a delay at the stub resolver to fall back to a query for an A - RR. This behavior may cause a fatal timeout at the resolver or at - the application that calls the resolver. Even if the resolver - eventually falls back, the result can be an unacceptable delay for - the application user, especially with interactive applications like - web browsing. - -4.2. Return "Name Error" - - This type of server returns a response with RCODE 3 ("Name Error") to - a query for an AAAA RR, indicating that it does not have any RRs of - any type for the queried name. - - - - -Morishita & Jinmei Informational [Page 2] - -RFC 4074 Common Misbehavior Against DNS Queries May 2005 - - - With this response, the stub resolver may immediately give up and - never fall back. Even if the resolver retries with a query for an A - RR, the negative response for the name has been cached in the caching - server, and the caching server will simply return the negative - response. As a result, the stub resolver considers this to be a - fatal error in name resolution. - - Several examples of this behavior are known to the authors. As of - this writing, all have been fixed. - -4.3. Return Other Erroneous Codes - - Other authoritative servers return a response with erroneous response - codes other than RCODE 3 ("Name Error"). One such RCODE is 4 ("Not - Implemented"), indicating that the servers do not support the - requested type of query. - - These cases are less harmful than the previous one; if the stub - resolver falls back to querying for an A RR, the caching server will - process the query correctly and return an appropriate response. - - However, these can still cause a serious effect. There was an - authoritative server implementation that returned RCODE 2 ("Server - failure") to queries for AAAA RRs. One widely deployed mail server - implementation with a certain type of resolver library interpreted - this result as an indication of retry and did not fall back to - queries for A RRs, causing message delivery failure. - - If the caching server receives a response with these response codes, - it does not cache the fact that the queried name has no AAAA RR, - resulting in redundant queries for AAAA RRs in the future. The - behavior will waste network bandwidth and increase the load of the - authoritative server. - - Using RCODE 1 ("Format error") would cause a similar effect, though - the authors have not seen such implementations yet. - -4.4. Return a Broken Response - - Another type of authoritative servers returns broken responses to - AAAA queries. Returning a response whose RR type is AAAA with the - length of the RDATA being 4 bytes is a known behavior of this - category. The 4-byte data looks like the IPv4 address of the queried - host name. - - - - - - - -Morishita & Jinmei Informational [Page 3] - -RFC 4074 Common Misbehavior Against DNS Queries May 2005 - - - That is, the RR in the answer section would be described as follows: - - www.bad.example. 600 IN AAAA 192.0.2.1 - - which is, of course, bogus (or at least meaningless). - - A widely deployed caching server implementation transparently returns - the broken response (and caches it) to the stub resolver. Another - known server implementation parses the response by itself, and sends - a separate response with RCODE 2 ("Server failure"). - - In either case, the broken response does not affect queries for an A - RR of the same name. If the stub resolver falls back to A queries, - it will get an appropriate response. - - The latter case, however, causes the same bad effect as that - described in the previous section: redundant queries for AAAA RRs. - -4.5. Make Lame Delegation - - Some authoritative servers respond to AAAA queries in a way that - causes lame delegation. In this case, the parent zone specifies that - the authoritative server should have the authority of a zone, but the - server should not return an authoritative response for AAAA queries - within the zone (i.e., the AA bit in the response is not set). On - the other hand, the authoritative server returns an authoritative - response for A queries. - - When a caching server asks the server for AAAA RRs in the zone, it - recognizes the delegation is lame, and returns a response with RCODE - 2 ("Server failure") to the stub resolver. - - Furthermore, some caching servers record the authoritative server as - lame for the zone and will not use it for a certain period of time. - With this type of caching server, even if the stub resolver falls - back to querying for an A RR, the caching server will simply return a - response with RCODE 2, since all the servers are known to be "lame." - - There is also an implementation that relaxes the behavior a little - bit. It tries to avoid using the lame server, but continues to try - it as a last resort. With this type of caching server, the stub - resolver will get a correct response if it falls back after Server - failure. However, this still causes redundant AAAA queries, as - explained in the previous sections. - - - - - - - -Morishita & Jinmei Informational [Page 4] - -RFC 4074 Common Misbehavior Against DNS Queries May 2005 - - -5. Security Considerations - - The CERT/CC pointed out that the response with RCODE 3 ("Name - Error"), described in Section 4.2, can be used for a denial of - service attack [2]. The same argument applies to the case of "lame - delegation", described in Section 4.5, with a certain type of caching - server. - -6. Acknowledgements - - Erik Nordmark encouraged the authors to publish this document as an - RFC. Akira Kato and Paul Vixie reviewed a preliminary version of - this document. Pekka Savola carefully reviewed a previous version - and provided detailed comments. Bill Fenner, Scott Hollenbeck, - Thomas Narten, and Alex Zinin reviewed and helped improve the - document at the last stage for publication. - -7. Informative References - - [1] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [2] The CERT Coordination Center, "Incorrect NXDOMAIN responses from - AAAA queries could cause denial-of-service conditions", - March 2003, <http://www.kb.cert.org/vuls/id/714121>. - -Authors' Addresses - - MORISHITA Orange Yasuhiro - Research and Development Department, Japan Registry Services Co.,Ltd. - Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda - Chiyoda-ku, Tokyo 101-0065 - Japan - - EMail: yasuhiro@jprs.co.jp - - - JINMEI Tatuya - Corporate Research & Development Center, Toshiba Corporation - 1 Komukai Toshiba-cho, Saiwai-ku - Kawasaki-shi, Kanagawa 212-8582 - Japan - - EMail: jinmei@isl.rdc.toshiba.co.jp - - - - - - - -Morishita & Jinmei Informational [Page 5] - -RFC 4074 Common Misbehavior Against DNS Queries May 2005 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2005). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Morishita & Jinmei Informational [Page 6] - diff --git a/contrib/bind9/doc/rfc/rfc4159.txt b/contrib/bind9/doc/rfc/rfc4159.txt deleted file mode 100644 index 1ab4bd1ae340..000000000000 --- a/contrib/bind9/doc/rfc/rfc4159.txt +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - -Network Working Group G. Huston -Request for Comments: 4159 APNIC -BCP: 109 August 2005 -Category: Best Current Practice - - - Deprecation of "ip6.int" - -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. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - This document advises of the deprecation of the use of "ip6.int" for - Standards Conformant IPv6 implementations. - -1. IPv6 Standards Action - - In August 2001 the IETF published [RFC3152], which advised that the - use of "ip6.int" as the domain for reverse-mapping of IPv6 addresses - to DNS names was deprecated. The document noted that the use of - "ip6.int" would be phased out in an orderly fashion. - - As of 1 September 2005, the IETF advises the community that the DNS - domain "ip6.int" should no longer be used to perform reverse mapping - of IPv6 addresses to domain names, and that the domain "ip6.arpa" - should be used henceforth, in accordance with the IANA Considerations - described in [RFC3596]. The domain "ip6.int" is deprecated, and its - use in IPv6 implementations that conform to the IPv6 Internet - Standards is discontinued. - - The Regional Internet Registries (RIRs) are advised that maintenance - of delegation of entries in "ip6.int" is no longer required as part - of infrastructure services in support of Internet Standards - Conformant IPv6 implementations as of 1 September 2005. The RIRs are - requested to work with their communities to adopt a schedule - regarding the cessation of support of registration services for the - "ip6.int" domain. - - - - - - -Huston Best Current Practice [Page 1] - -RFC 4159 ip6.int August 2005 - - -2. IANA Considerations - - IANA is advised that the "ip6.int" domain for reverse mapping of IPv6 - addresses to domain names is no longer part of Internet Standards - Conformant support of IPv6 as of 1 September 2005. - -3. Security Considerations - - While DNS spoofing of address to name mapping has been exploited in - IPv4, removal of the "ip6.int" zone from the standard IPv6 - specification creates no new threats to the security of the internet. - -4. Acknowledgements - - The document was prepared with the assistance of Kurt Lindqvist, - Thomas Narten, Paul Wilson, David Kessens, Bob Hinden, Brian - Haberman, and Bill Manning. - -5. Normative References - - [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, - August 2001. - - [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS - Extensions to Support IP Version 6", RFC 3596, October - 2003. - -Author's Address - - Geoff Huston - APNIC - - EMail: gih@apnic.net - - - - - - - - - - - - - - - - - - -Huston Best Current Practice [Page 2] - -RFC 4159 ip6.int August 2005 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2005). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Huston Best Current Practice [Page 3] - diff --git a/contrib/bind9/doc/rfc/rfc952.txt b/contrib/bind9/doc/rfc/rfc952.txt deleted file mode 100644 index 7df339a272e2..000000000000 --- a/contrib/bind9/doc/rfc/rfc952.txt +++ /dev/null @@ -1,340 +0,0 @@ -Network Working Group K. Harrenstien (SRI) -Request for Comments: 952 M. Stahl (SRI) - E. Feinler (SRI) -Obsoletes: RFC 810, 608 October 1985 - - DOD INTERNET HOST TABLE SPECIFICATION - - -STATUS OF THIS MEMO - - This RFC is the official specification of the format of the Internet - Host Table. This edition of the specification includes minor - revisions to RFC-810 which brings it up to date. Distribution of this - memo is unlimited. - -INTRODUCTION - - The DoD Host Table is utilized by the DoD Hostname Server maintained - by the DDN Network Information Center (NIC) on behalf of the Defense - Communications Agency (DCA) [See RFC-953]. - -LOCATION OF THE STANDARD DOD ONLINE HOST TABLE - - A machine-translatable ASCII text version of the DoD Host Table is - online in the file NETINFO:HOSTS.TXT on the SRI-NIC host. It can be - obtained via FTP from your local host by connecting to host - SRI-NIC.ARPA (26.0.0.73 or 10.0.0.51), logging in as user = - ANONYMOUS, password = GUEST, and retrieving the file - "NETINFO:HOSTS.TXT". The same table may also be obtained via the NIC - Hostname Server, as described in RFC-953. The latter method is - faster and easier, but requires a user program to make the necessary - connection to the Name Server. - -ASSUMPTIONS - - 1. A "name" (Net, Host, Gateway, or Domain name) is a text string up - to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus - sign (-), and period (.). Note that periods are only allowed when - they serve to delimit components of "domain style names". (See - RFC-921, "Domain Name System Implementation Schedule", for - background). No blank or space characters are permitted as part of a - name. No distinction is made between upper and lower case. The first - character must be an alpha character. The last character must not be - a minus sign or period. A host which serves as a GATEWAY should have - "-GATEWAY" or "-GW" as part of its name. Hosts which do not serve as - Internet gateways should not use "-GATEWAY" and "-GW" as part of - their names. A host which is a TAC should have "-TAC" as the last - part of its host name, if it is a DoD host. Single character names - or nicknames are not allowed. - - 2. Internet Addresses are 32-bit addresses [See RFC-796]. In the - - -Harrenstien & Stahl & Feinler [Page 1] - - - -RFC 952 October 1985 -DOD INTERNET HOST TABLE SPECIFICATION - - - host table described herein each address is represented by four - decimal numbers separated by a period. Each decimal number - represents 1 octet. - - 3. If the first bit of the first octet of the address is 0 (zero), - then the next 7 bits of the first octet indicate the network number - (Class A Address). If the first two bits are 1,0 (one,zero), then - the next 14 bits define the net number (Class B Address). If the - first 3 bits are 1,1,0 (one,one,zero), then the next 21 bits define - the net number (Class C Address) [See RFC-943]. - - This is depicted in the following diagram: - - +-+------------+--------------+--------------+--------------+ - |0| NET <-7-> | LOCAL ADDRESS <-24-> | - +-+------------+--------------+--------------+--------------+ - - +---+----------+--------------+--------------+--------------+ - |1 0| NET <-14-> | LOCAL ADDRESS <-16-> | - +---+----------+--------------+--------------+--------------+ - - +-----+--------+--------------+--------------+--------------+ - |1 1 0| NET <-21-> | LOCAL ADDRESS| - +-----+--------+--------------+--------------+--------------+ - - 4. The LOCAL ADDRESS portion of the internet address identifies a - host within the network specified by the NET portion of the address. - - 5. The ARPANET and MILNET are both Class A networks. The NET portion - is 10 decimal for ARPANET, 26 decimal for MILNET, and the LOCAL - ADDRESS maps as follows: the second octet identifies the physical - host, the third octet identifies the logical host, and the fourth - identifies the Packet Switching Node (PSN), formerly known as an - Interface Message Processor (IMP). - - +-+------------+--------------+--------------+--------------+ - |0| 10 or 26 | HOST | LOGICAL HOST | PSN (IMP) | - +-+------------+--------------+--------------+--------------+ - - (NOTE: RFC-796 also describes the local address mappings for - several other networks.) - - 6. It is the responsibility of the users of this host table to - translate it into whatever format is needed for their purposes. - - 7. Names and addresses for DoD hosts and gateways will be negotiated - and registered with the DDN PMO, and subsequently with the NIC, - - -Harrenstien & Stahl & Feinler [Page 2] - - - -RFC 952 October 1985 -DOD INTERNET HOST TABLE SPECIFICATION - - - before being used and before traffic is passed by a DoD host. Names - and addresses for domains and networks are to be registered with the - DDN Network Information Center (HOSTMASTER@SRI-NIC.ARPA) or - 800-235-3155. - - The NIC will attempt to keep similar information for non-DoD networks - and hosts, if this information is provided, and as long as it is - needed, i.e., until intercommunicating network name servers are in - place. - -EXAMPLE OF HOST TABLE FORMAT - - NET : 10.0.0.0 : ARPANET : - NET : 128.10.0.0 : PURDUE-CS-NET : - GATEWAY : 10.0.0.77, 18.10.0.4 : MIT-GW.ARPA,MIT-GATEWAY : PDP-11 : - MOS : IP/GW,EGP : - HOST : 26.0.0.73, 10.0.0.51 : SRI-NIC.ARPA,SRI-NIC,NIC : DEC-2060 : - TOPS20 :TCP/TELNET,TCP/SMTP,TCP/TIME,TCP/FTP,TCP/ECHO,ICMP : - HOST : 10.2.0.11 : SU-TAC.ARPA,SU-TAC : C/30 : TAC : TCP : - -SYNTAX AND CONVENTIONS - - ; (semicolon) is used to denote the beginning of a comment. - Any text on a given line following a ';' is a - comment, and not part of the host table. - - NET keyword introducing a network entry - - GATEWAY keyword introducing a gateway entry - - HOST keyword introducing a host entry - - DOMAIN keyword introducing a domain entry - - :(colon) is used as a field delimiter - - ::(2 colons) indicates a null field - - ,(comma) is used as a data element delimiter - - XXX/YYY indicates protocol information of the type - TRANSPORT/SERVICE. - - where TRANSPORT/SERVICE options are specified as - - "FOO/BAR" both transport and service known - - - -Harrenstien & Stahl & Feinler [Page 3] - - - -RFC 952 October 1985 -DOD INTERNET HOST TABLE SPECIFICATION - - - "FOO" transport known; services not known - - "BAR" service is known, transport not known - - NOTE: See "Assigned Numbers" for specific options and acronyms - for machine types, operating systems, and protocol/services. - - Each host table entry is an ASCII text string comprised of 6 fields, - where - - Field 1 KEYWORD indicating whether this entry pertains to - a NET, GATEWAY, HOST, or DOMAIN. NET entries are - assigned and cannot have alternate addresses or - nicknames. DOMAIN entries do not use fields 4, 5, - or 6. - - Field 2 Internet Address of Network, Gateway, or Host - followed by alternate addresses. Addresses for a - Domain are those where a Domain Name Server exists - for that domain. - - Field 3 Official Name of Network, Gateway, Host, or Domain - (with optional nicknames, where permitted). - - Field 4 Machine Type - - Field 5 Operating System - - Field 6 Protocol List - - Fields 4, 5 and 6 are optional. For a Domain they are not used. - - Fields 3-6, if included, pertain to the first address in Field 2. - - 'Blanks' (spaces and tabs) are ignored between data elements or - fields, but are disallowed within a data element. - - Each entry ends with a colon. - - The entries in the table are grouped by types in the order Domain, - Net, Gateway, and Host. Within each type the ordering is - unspecified. - - Note that although optional nicknames are allowed for hosts, they are - discouraged, except in the case where host names have been changed - - - - -Harrenstien & Stahl & Feinler [Page 4] - - - -RFC 952 October 1985 -DOD INTERNET HOST TABLE SPECIFICATION - - - and both the new and the old names are maintained for a suitable - period of time to effect a smooth transition. Nicknames are not - permitted for NET names. - -GRAMMATICAL HOST TABLE SPECIFICATION - - A. Parsing grammar - - <entry> ::= <keyword> ":" <addresses> ":" <names> [":" [<cputype>] - [":" [<opsys>] [":" [<protocol list>] ]]] ":" - <addresses> ::= <address> *["," <address>] - <address> ::= <octet> "." <octet> "." <octet> "." <octet> - <octet> ::= <0 to 255 decimal> - <names> ::= <netname> | <gatename> | <domainname> *["," - <nicknames>] - | <official hostname> *["," <nicknames>] - <netname> ::= <name> - <gatename> ::= <hname> - <domainname> ::= <hname> - <official hostname> ::= <hname> - <nickname> ::= <hname> - <protocol list> ::= <protocol spec> *["," <protocol spec>] - <protocol spec> ::= <transport name> "/" <service name> - | <raw protocol name> - - B. Lexical grammar - - <entry-field> ::= <entry-text> [<cr><lf> <blank> <entry-field>] - <entry-text> ::= <print-char> *<text> - <blank> ::= <space-or-tab> [<blank>] - <keyword> ::= NET | GATEWAY | HOST | DOMAIN - <hname> ::= <name>*["."<name>] - <name> ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>] - <cputype> ::= PDP-11/70 | DEC-1080 | C/30 | CDC-6400...etc. - <opsys> ::= ITS | MULTICS | TOPS20 | UNIX...etc. - <transport name> ::= TCP | NCP | UDP | IP...etc. - <service name> ::= TELNET | FTP | SMTP | MTP...etc. - <raw protocol name> ::= <name> - <comment> ::= ";" <text><cr><lf> - <text> ::= *[<print-char> | <blank>] - <print-char> ::= <any printing char (not space or tab)> - - Notes: - - 1. Zero or more 'blanks' between separators " , : " are allowed. - 'Blanks' are spaces and tabs. - - - -Harrenstien & Stahl & Feinler [Page 5] - - - -RFC 952 October 1985 -DOD INTERNET HOST TABLE SPECIFICATION - - - 2. Continuation lines are lines that begin with at least one - blank. They may be used anywhere 'blanks' are legal to split an - entry across lines. - -BIBLIOGRAPHY - - 1. Feinler, E., Harrenstien, K., Su, Z. and White, V., "Official DoD - Internet Host Table Specification", RFC-810, Network Information - Center, SRI International, March 1982. - - 2. Harrenstien, K., Stahl, M., and Feinler, E., "Hostname Server", - RFC-953, Network Information Center, SRI International, October - 1985. - - 3. Kudlick, M. "Host Names Online", RFC-608, Network Information - Center, SRI International, January 1973. - - 4. Postel, J., "Internet Protocol", RFC-791, Information Sciences - Institute, University of Southern California, Marina del Rey, - September 1981. - - 5. Postel, J., "Address Mappings", RFC-796, Information Sciences - Institute, University of Southern California, Marina del Rey, - September 1981. - - 6. Postel, J., "Domain Name System Implementation Schedule", RFC-921, - Information Sciences Institute, University of Southern California, - Marina del Rey, October 1984. - - 7. Reynolds, J. and Postel, J., "Assigned Numbers", RFC-943, - Information Sciences Institute, University of Southern California, - Marina del Rey, April 1985. - - - - - - - - - - - - - - - - - -Harrenstien & Stahl & Feinler [Page 6] - |