diff options
Diffstat (limited to 'doc/rfc')
107 files changed, 107094 insertions, 0 deletions
diff --git a/doc/rfc/index b/doc/rfc/index new file mode 100644 index 0000000..990d4a9 --- /dev/null +++ b/doc/rfc/index @@ -0,0 +1,114 @@ + 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" +4193: Unique Local IPv6 Unicast Addresses +4255: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints +4343: Domain Name System (DNS) Case Insensitivity Clarification +4367: What's in a Name: False Assumptions about DNS Names +4398: Storing Certificates in the Domain Name System (DNS) +4431: The DNSSEC Lookaside Validation (DLV) DNS Resource Record +4408: Sender Policy Framework (SPF) for Authorizing Use of Domains + in E-Mail, Version 1 +4470: Minimally Covering NSEC Records and DNSSEC On-line Signing +4634: US Secure Hash Algorithms (SHA and HMAC-SHA) +4641: DNSSEC Operational Practices diff --git a/doc/rfc/rfc1032.txt b/doc/rfc/rfc1032.txt new file mode 100644 index 0000000..0e82721 --- /dev/null +++ b/doc/rfc/rfc1032.txt @@ -0,0 +1,781 @@ +Network Working Group M. Stahl +Request for Comments: 1032 SRI International + November 1987 + + + DOMAIN ADMINISTRATORS GUIDE + + +STATUS OF THIS MEMO + + This memo describes procedures for registering a domain with the + Network Information Center (NIC) of Defense Data Network (DDN), and + offers guidelines on the establishment and administration of a domain + in accordance with the requirements specified in RFC-920. It is + intended for use by domain administrators. This memo should be used + in conjunction with RFC-920, which is an official policy statement of + the Internet Activities Board (IAB) and the Defense Advanced Research + Projects Agency (DARPA). Distribution of this memo is unlimited. + +BACKGROUND + + Domains are administrative entities that provide decentralized + management of host naming and addressing. The domain-naming system + is distributed and hierarchical. + + The NIC is designated by the Defense Communications Agency (DCA) to + provide registry services for the domain-naming system on the DDN and + DARPA portions of the Internet. + + As registrar of top-level and second-level domains, as well as + administrator of the root domain name servers on behalf of DARPA and + DDN, the NIC is responsible for maintaining the root server zone + files and their binary equivalents. In addition, the NIC is + responsible for administering the top-level domains of "ARPA," "COM," + "EDU," "ORG," "GOV," and "MIL" on behalf of DCA and DARPA until it + becomes feasible for other appropriate organizations to assume those + responsibilities. + + It is recommended that the guidelines described in this document be + used by domain administrators in the establishment and control of + second-level domains. + +THE DOMAIN ADMINISTRATOR + + The role of the domain administrator (DA) is that of coordinator, + manager, and technician. If his domain is established at the second + level or lower in the tree, the DA must register by interacting with + the management of the domain directly above his, making certain that + + + +Stahl [Page 1] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + his domain satisfies all the requirements of the administration under + which his domain would be situated. To find out who has authority + over the name space he wishes to join, the DA can ask the NIC + Hostmaster. Information on contacts for the top-level and second- + level domains can also be found on line in the file NETINFO:DOMAIN- + CONTACTS.TXT, which is available from the NIC via anonymous FTP. + + The DA should be technically competent; he should understand the + concepts and procedures for operating a domain server, as described + in RFC-1034, and make sure that the service provided is reliable and + uninterrupted. It is his responsibility or that of his delegate to + ensure that the data will be current at all times. As a manager, the + DA must be able to handle complaints about service provided by his + domain name server. He must be aware of the behavior of the hosts in + his domain, and take prompt action on reports of problems, such as + protocol violations or other serious misbehavior. The administrator + of a domain must be a responsible person who has the authority to + either enforce these actions himself or delegate them to someone + else. + + Name assignments within a domain are controlled by the DA, who should + verify that names are unique within his domain and that they conform + to standard naming conventions. He furnishes access to names and + name-related information to users both inside and outside his domain. + He should work closely with the personnel he has designated as the + "technical and zone" contacts for his domain, for many administrative + decisions will be made on the basis of input from these people. + +THE DOMAIN TECHNICAL AND ZONE CONTACT + + A zone consists of those contiguous parts of the domain tree for + which a domain server has complete information and over which it has + authority. A domain server may be authoritative for more than one + zone. The domain technical/zone contact is the person who tends to + the technical aspects of maintaining the domain's name server and + resolver software, and database files. He keeps the name server + running, and interacts with technical people in other domains and + zones to solve problems that affect his zone. + +POLICIES + + Domain or host name choices and the allocation of domain name space + are considered to be local matters. In the event of conflicts, it is + the policy of the NIC not to get involved in local disputes or in the + local decision-making process. The NIC will not act as referee in + disputes over such matters as who has the "right" to register a + particular top-level or second-level domain for an organization. The + NIC considers this a private local matter that must be settled among + + + +Stahl [Page 2] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + the parties involved prior to their commencing the registration + process with the NIC. Therefore, it is assumed that the responsible + person for a domain will have resolved any local conflicts among the + members of his domain before registering that domain with the NIC. + The NIC will give guidance, if requested, by answering specific + technical questions, but will not provide arbitration in disputes at + the local level. This policy is also in keeping with the distributed + hierarchical nature of the domain-naming system in that it helps to + distribute the tasks of solving problems and handling questions. + + Naming conventions for hosts should follow the rules specified in + RFC-952. From a technical standpoint, domain names can be very long. + Each segment of a domain name may contain up to 64 characters, but + the NIC strongly advises DAs to choose names that are 12 characters + or fewer, because behind every domain system there is a human being + who must keep track of the names, addresses, contacts, and other data + in a database. The longer the name, the more likely the data + maintainer is to make a mistake. Users also will appreciate shorter + names. Most people agree that short names are easier to remember and + type; most domain names registered so far are 12 characters or fewer. + + Domain name assignments are made on a first-come-first-served basis. + The NIC has chosen not to register individual hosts directly under + the top-level domains it administers. One advantage of the domain + naming system is that administration and data maintenance can be + delegated down a hierarchical tree. Registration of hosts at the + same level in the tree as a second-level domain would dilute the + usefulness of this feature. In addition, the administrator of a + domain is responsible for the actions of hosts within his domain. We + would not want to find ourselves in the awkward position of policing + the actions of individual hosts. Rather, the subdomains registered + under these top-level domains retain the responsibility for this + function. + + Countries that wish to be registered as top-level domains are + required to name themselves after the two-letter country code listed + in the international standard ISO-3166. In some cases, however, the + two-letter ISO country code is identical to a state code used by the + U.S. Postal Service. Requests made by countries to use the three- + letter form of country code specified in the ISO-3166 standard will + be considered in such cases so as to prevent possible conflicts and + confusion. + + + + + + + + + +Stahl [Page 3] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + +HOW TO REGISTER + + Obtain a domain questionnaire from the NIC hostmaster, or FTP the + file NETINFO:DOMAIN-TEMPLATE.TXT from host SRI-NIC.ARPA. + + Fill out the questionnaire completely. Return it via electronic mail + to HOSTMASTER@SRI-NIC.ARPA. + + The APPENDIX to this memo contains the application form for + registering a top-level or second-level domain with the NIC. It + supersedes the version of the questionnaire found in RFC-920. The + application should be submitted by the person administratively + responsible for the domain, and must be filled out completely before + the NIC will authorize establishment of a top-level or second-level + domain. The DA is responsible for keeping his domain's data current + with the NIC or with the registration agent with which his domain is + registered. For example, the CSNET and UUCP managements act as + domain filters, processing domain applications for their own + organizations. They pass pertinent information along periodically to + the NIC for incorporation into the domain database and root server + files. The online file NETINFO:ALTERNATE-DOMAIN-PROCEDURE.TXT + outlines this procedure. It is highly recommended that the DA review + this information periodically and provide any corrections or + additions. Corrections should be submitted via electronic mail. + +WHICH DOMAIN NAME? + + The designers of the domain-naming system initiated several general + categories of names as top-level domain names, so that each could + accommodate a variety of organizations. The current top-level + domains registered with the DDN Network Information Center are ARPA, + COM, EDU, GOV, MIL, NET, and ORG, plus a number of top-level country + domains. To join one of these, a DA needs to be aware of the purpose + for which it was intended. + + "ARPA" is a temporary domain. It is by default appended to the + names of hosts that have not yet joined a domain. When the system + was begun in 1984, the names of all hosts in the Official DoD + Internet Host Table maintained by the NIC were changed by adding + of the label ".ARPA" in order to accelerate a transition to the + domain-naming system. Another reason for the blanket name changes + was to force hosts to become accustomed to using the new style + names and to modify their network software, if necessary. This + was done on a network-wide basis and was directed by DCA in DDN + Management Bulletin No. 22. Hosts that fall into this domain will + eventually move to other branches of the domain tree. + + + + + +Stahl [Page 4] + +RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 + + + "COM" is meant to incorporate subdomains of companies and + businesses. + + "EDU" was initiated to accommodate subdomains set up by + universities and other educational institutions. + + "GOV" exists to act as parent domain for subdomains set up by + government agencies. + + "MIL" was initiated to act as parent to subdomains that are + developed by military organizations. + + "NET" was introduced as a parent domain for various network-type + organizations. Organizations that belong within this top-level + domain are generic or network-specific, such as network service + centers and consortia. "NET" also encompasses network + management-related organizations, such as information centers and + operations centers. + + "ORG" exists as a parent to subdomains that do not clearly fall + within the other top-level domains. This may include technical- + support groups, professional societies, or similar organizations. + + One of the guidelines in effect in the domain-naming system is that a + host should have only one name regardless of what networks it is + connected to. This implies, that, in general, domain names should + not include routing information or addresses. For example, a host + that has one network connection to the Internet and another to BITNET + should use the same name when talking to either network. For a + description of the syntax of domain names, please refer to Section 3 + of RFC-1034. + +VERIFICATION OF DATA + + The verification process can be accomplished in several ways. One of + these is through the NIC WHOIS server. If he has access to WHOIS, + the DA can type the command "whois domain <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/doc/rfc/rfc1033.txt b/doc/rfc/rfc1033.txt new file mode 100644 index 0000000..37029fd --- /dev/null +++ b/doc/rfc/rfc1033.txt @@ -0,0 +1,1229 @@ +Network Working Group M. Lottor +Request For Comments: 1033 SRI International + November 1987 + + + DOMAIN ADMINISTRATORS OPERATIONS GUIDE + + + +STATUS OF THIS MEMO + + This RFC provides guidelines for domain administrators in operating a + domain server and maintaining their portion of the hierarchical + database. Familiarity with the domain system is assumed. + Distribution of this memo is unlimited. + +ACKNOWLEDGMENTS + + This memo is a formatted collection of notes and excerpts from the + references listed at the end of this document. Of particular mention + are Paul Mockapetris and Kevin Dunlap. + +INTRODUCTION + + A domain server requires a few files to get started. It will + normally have some number of boot/startup files (also known as the + "safety belt" files). One section will contain a list of possible + root servers that the server will use to find the up-to-date list of + root servers. Another section will list the zone files to be loaded + into the server for your local domain information. A zone file + typically contains all the data for a particular domain. This guide + describes the data formats that can be used in zone files and + suggested parameters to use for certain fields. If you are + attempting to do anything advanced or tricky, consult the appropriate + domain RFC's for more details. + + Note: Each implementation of domain software may require different + files. Zone files are standardized but some servers may require + other startup files. See the appropriate documentation that comes + with your software. See the appendix for some specific examples. + +ZONES + + A zone defines the contents of a contiguous section of the domain + space, usually bounded by administrative boundaries. There will + typically be a separate data file for each zone. The data contained + in a zone file is composed of entries called Resource Records (RRs). + + + + +Lottor [Page 1] + +RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 + + + You may only put data in your domain server that you are + authoritative for. You must not add entries for domains other than + your own (except for the special case of "glue records"). + + A domain server will probably read a file on start-up that lists the + zones it should load into its database. The format of this file is + not standardized and is different for most domain server + implementations. For each zone it will normally contain the domain + name of the zone and the file name that contains the data to load for + the zone. + +ROOT SERVERS + + A resolver will need to find the root servers when it first starts. + When the resolver boots, it will typically read a list of possible + root servers from a file. + + The resolver will cycle through the list trying to contact each one. + When it finds a root server, it will ask it for the current list of + root servers. It will then discard the list of root servers it read + from the data file and replace it with the current list it received. + + Root servers will not change very often. You can get the names of + current root servers from the NIC. + + FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to + NIC@SRI-NIC.ARPA. + + As of this date (June 1987) they are: + + SRI-NIC.ARPA 10.0.0.51 26.0.0.73 + C.ISI.EDU 10.0.0.52 + BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2 + A.ISI.EDU 26.3.0.103 + +RESOURCE RECORDS + + Records in the zone data files are called resource records (RRs). + They are specified in RFC-883 and RFC-973. An RR has a standard + format as shown: + + <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/doc/rfc/rfc1034.txt b/doc/rfc/rfc1034.txt new file mode 100644 index 0000000..55cdb21 --- /dev/null +++ b/doc/rfc/rfc1034.txt @@ -0,0 +1,3077 @@ +Network Working Group P. Mockapetris +Request for Comments: 1034 ISI +Obsoletes: RFCs 882, 883, 973 November 1987 + + + DOMAIN NAMES - CONCEPTS AND FACILITIES + + + +1. STATUS OF THIS MEMO + +This RFC is an introduction to the Domain Name System (DNS), and omits +many details which can be found in a companion RFC, "Domain Names - +Implementation and Specification" [RFC-1035]. That RFC assumes that the +reader is familiar with the concepts discussed in this memo. + +A subset of DNS functions and data types constitute an official +protocol. The official protocol includes standard queries and their +responses and most of the Internet class data formats (e.g., host +addresses). + +However, the domain system is intentionally extensible. Researchers are +continuously proposing, implementing and experimenting with new data +types, query types, classes, functions, etc. Thus while the components +of the official protocol are expected to stay essentially unchanged and +operate as a production service, experimental behavior should always be +expected in extensions beyond the official protocol. Experimental or +obsolete features are clearly marked in these RFCs, and such information +should be used with caution. + +The reader is especially cautioned not to depend on the values which +appear in examples to be current or complete, since their purpose is +primarily pedagogical. Distribution of this memo is unlimited. + +2. INTRODUCTION + +This RFC introduces domain style names, their use for Internet mail and +host address support, and the protocols and servers used to implement +domain name facilities. + +2.1. The history of domain names + +The impetus for the development of the domain system was growth in the +Internet: + + - Host name to address mappings were maintained by the Network + Information Center (NIC) in a single file (HOSTS.TXT) which + was FTPed by all hosts [RFC-952, RFC-953]. The total network + + + +Mockapetris [Page 1] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + bandwidth consumed in distributing a new version by this + scheme is proportional to the square of the number of hosts in + the network, and even when multiple levels of FTP are used, + the outgoing FTP load on the NIC host is considerable. + Explosive growth in the number of hosts didn't bode well for + the future. + + - The network population was also changing in character. The + timeshared hosts that made up the original ARPANET were being + replaced with local networks of workstations. Local + organizations were administering their own names and + addresses, but had to wait for the NIC to change HOSTS.TXT to + make changes visible to the Internet at large. Organizations + also wanted some local structure on the name space. + + - The applications on the Internet were getting more + sophisticated and creating a need for general purpose name + service. + + +The result was several ideas about name spaces and their management +[IEN-116, RFC-799, RFC-819, RFC-830]. The proposals varied, but a +common thread was the idea of a hierarchical name space, with the +hierarchy roughly corresponding to organizational structure, and names +using "." as the character to mark the boundary between hierarchy +levels. A design using a distributed database and generalized resources +was described in [RFC-882, RFC-883]. Based on experience with several +implementations, the system evolved into the scheme described in this +memo. + +The terms "domain" or "domain name" are used in many contexts beyond the +DNS described here. Very often, the term domain name is used to refer +to a name with structure indicated by dots, but no relation to the DNS. +This is particularly true in mail addressing [Quarterman 86]. + +2.2. DNS design goals + +The design goals of the DNS influence its structure. They are: + + - The primary goal is a consistent name space which will be used + for referring to resources. In order to avoid the problems + caused by ad hoc encodings, names should not be required to + contain network identifiers, addresses, routes, or similar + information as part of the name. + + - The sheer size of the database and frequency of updates + suggest that it must be maintained in a distributed manner, + with local caching to improve performance. Approaches that + + + +Mockapetris [Page 2] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + attempt to collect a consistent copy of the entire database + will become more and more expensive and difficult, and hence + should be avoided. The same principle holds for the structure + of the name space, and in particular mechanisms for creating + and deleting names; these should also be distributed. + + - Where there tradeoffs between the cost of acquiring data, the + speed of updates, and the accuracy of caches, the source of + the data should control the tradeoff. + + - The costs of implementing such a facility dictate that it be + generally useful, and not restricted to a single application. + We should be able to use names to retrieve host addresses, + mailbox data, and other as yet undetermined information. All + data associated with a name is tagged with a type, and queries + can be limited to a single type. + + - Because we want the name space to be useful in dissimilar + networks and applications, we provide the ability to use the + same name space with different protocol families or + management. For example, host address formats differ between + protocols, though all protocols have the notion of address. + The DNS tags all data with a class as well as the type, so + that we can allow parallel use of different formats for data + of type address. + + - We want name server transactions to be independent of the + communications system that carries them. Some systems may + wish to use datagrams for queries and responses, and only + establish virtual circuits for transactions that need the + reliability (e.g., database updates, long transactions); other + systems will use virtual circuits exclusively. + + - The system should be useful across a wide spectrum of host + capabilities. Both personal computers and large timeshared + hosts should be able to use the system, though perhaps in + different ways. + +2.3. Assumptions about usage + +The organization of the domain system derives from some assumptions +about the needs and usage patterns of its user community and is designed +to avoid many of the the complicated problems found in general purpose +database systems. + +The assumptions are: + + - The size of the total database will initially be proportional + + + +Mockapetris [Page 3] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + to the number of hosts using the system, but will eventually + grow to be proportional to the number of users on those hosts + as mailboxes and other information are added to the domain + system. + + - Most of the data in the system will change very slowly (e.g., + mailbox bindings, host addresses), but that the system should + be able to deal with subsets that change more rapidly (on the + order of seconds or minutes). + + - The administrative boundaries used to distribute + responsibility for the database will usually correspond to + organizations that have one or more hosts. Each organization + that has responsibility for a particular set of domains will + provide redundant name servers, either on the organization's + own hosts or other hosts that the organization arranges to + use. + + - Clients of the domain system should be able to identify + trusted name servers they prefer to use before accepting + referrals to name servers outside of this "trusted" set. + + - Access to information is more critical than instantaneous + updates or guarantees of consistency. Hence the update + process allows updates to percolate out through the users of + the domain system rather than guaranteeing that all copies are + simultaneously updated. When updates are unavailable due to + network or host failure, the usual course is to believe old + information while continuing efforts to update it. The + general model is that copies are distributed with timeouts for + refreshing. The distributor sets the timeout value and the + recipient of the distribution is responsible for performing + the refresh. In special situations, very short intervals can + be specified, or the owner can prohibit copies. + + - In any system that has a distributed database, a particular + name server may be presented with a query that can only be + answered by some other server. The two general approaches to + dealing with this problem are "recursive", in which the first + server pursues the query for the client at another server, and + "iterative", in which the server refers the client to another + server and lets the client pursue the query. Both approaches + have advantages and disadvantages, but the iterative approach + is preferred for the datagram style of access. The domain + system requires implementation of the iterative approach, but + allows the recursive approach as an option. + + + + + +Mockapetris [Page 4] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +The domain system assumes that all data originates in master files +scattered through the hosts that use the domain system. These master +files are updated by local system administrators. Master files are text +files that are read by a local name server, and hence become available +through the name servers to users of the domain system. The user +programs access name servers through standard programs called resolvers. + +The standard format of master files allows them to be exchanged between +hosts (via FTP, mail, or some other mechanism); this facility is useful +when an organization wants a domain, but doesn't want to support a name +server. The organization can maintain the master files locally using a +text editor, transfer them to a foreign host which runs a name server, +and then arrange with the system administrator of the name server to get +the files loaded. + +Each host's name servers and resolvers are configured by a local system +administrator [RFC-1033]. For a name server, this configuration data +includes the identity of local master files and instructions on which +non-local master files are to be loaded from foreign servers. The name +server uses the master files or copies to load its zones. For +resolvers, the configuration data identifies the name servers which +should be the primary sources of information. + +The domain system defines procedures for accessing the data and for +referrals to other name servers. The domain system also defines +procedures for caching retrieved data and for periodic refreshing of +data defined by the system administrator. + +The system administrators provide: + + - The definition of zone boundaries. + + - Master files of data. + + - Updates to master files. + + - Statements of the refresh policies desired. + +The domain system provides: + + - Standard formats for resource data. + + - Standard methods for querying the database. + + - Standard methods for name servers to refresh local data from + foreign name servers. + + + + + +Mockapetris [Page 5] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +2.4. Elements of the DNS + +The DNS has three major components: + + - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are + specifications for a tree structured name space and data + associated with the names. Conceptually, each node and leaf + of the domain name space tree names a set of information, and + query operations are attempts to extract specific types of + information from a particular set. A query names the domain + name of interest and describes the type of resource + information that is desired. For example, the Internet + uses some of its domain names to identify hosts; queries for + address resources return Internet host addresses. + + - NAME SERVERS are server programs which hold information about + the domain tree's structure and set information. A name + server may cache structure or set information about any part + of the domain tree, but in general a particular name server + has complete information about a subset of the domain space, + and pointers to other name servers that can be used to lead to + information from any part of the domain tree. Name servers + know the parts of the domain tree for which they have complete + information; a name server is said to be an AUTHORITY for + these parts of the name space. Authoritative information is + organized into units called ZONEs, and these zones can be + automatically distributed to the name servers which provide + redundant service for the data in a zone. + + - RESOLVERS are programs that extract information from name + servers in response to client requests. Resolvers must be + able to access at least one name server and use that name + server's information to answer a query directly, or pursue the + query using referrals to other name servers. A resolver will + typically be a system routine that is directly accessible to + user programs; hence no protocol is necessary between the + resolver and the user program. + +These three components roughly correspond to the three layers or views +of the domain system: + + - From the user's point of view, the domain system is accessed + through a simple procedure or OS call to a local resolver. + The domain space consists of a single tree and the user can + request information from any section of the tree. + + - From the resolver's point of view, the domain system is + composed of an unknown number of name servers. Each name + + + +Mockapetris [Page 6] + +RFC 1034 Domain Concepts and Facilities November 1987 + + + server has one or more pieces of the whole domain tree's data, + but the resolver views each of these databases as essentially + static. + + - From a name server's point of view, the domain system consists + of separate sets of local information called zones. The name + server has local copies of some of the zones. The name server + must periodically refresh its zones from master copies in + local files or foreign name servers. The name server must + concurrently process queries that arrive from resolvers. + +In the interests of performance, implementations may couple these +functions. For example, a resolver on the same machine as a name server +might share a database consisting of the the zones managed by the name +server and the cache managed by the resolver. + +3. DOMAIN NAME SPACE and RESOURCE RECORDS + +3.1. Name space specifications and terminology + +The domain name space is a tree structure. Each node and leaf on the +tree corresponds to a resource set (which may be empty). The domain +system makes no distinctions between the uses of the interior nodes and +leaves, and this memo uses the term "node" to refer to both. + +Each node has a label, which is zero to 63 octets in length. Brother +nodes may not have the same label, although the same label can be used +for nodes which are not brothers. One label is reserved, and that is +the null (i.e., zero length) label used for the root. + +The domain name of a node is the list of the labels on the path from the +node to the root of the tree. By convention, the labels that compose a +domain name are printed or read left to right, from the most specific +(lowest, farthest from the root) to the least specific (highest, closest +to the root). + +Internally, programs that manipulate domain names should represent them +as sequences of labels, where each label is a length octet followed by +an octet string. Because all domain names end at the root, which has a +null string for a label, these internal representations can use a length +byte of zero to terminate a domain name. + +By convention, domain names can be stored with arbitrary case, but +domain name comparisons for all present domain functions are done in a +case-insensitive manner, assuming an ASCII character set, and a high +order zero bit. This means that you are free to create a node with +label "A" or a node with label "a", but not both as brothers; you could +refer to either using "a" or "A". When you receive a domain name or + + + +Mockapetris [Page 7] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +label, you should preserve its case. The rationale for this choice is +that we may someday need to add full binary domain names for new +services; existing services would not be changed. + +When a user needs to type a domain name, the length of each label is +omitted and the labels are separated by dots ("."). Since a complete +domain name ends with the root label, this leads to a printed form which +ends in a dot. We use this property to distinguish between: + + - a character string which represents a complete domain name + (often called "absolute"). For example, "poneria.ISI.EDU." + + - a character string that represents the starting labels of a + domain name which is incomplete, and should be completed by + local software using knowledge of the local domain (often + called "relative"). For example, "poneria" used in the + ISI.EDU domain. + +Relative names are either taken relative to a well known origin, or to a +list of domains used as a search list. Relative names appear mostly at +the user interface, where their interpretation varies from +implementation to implementation, and in master files, where they are +relative to a single origin domain name. The most common interpretation +uses the root "." as either the single origin or as one of the members +of the search list, so a multi-label relative name is often one where +the trailing dot has been omitted to save typing. + +To simplify implementations, the total number of octets that represent a +domain name (i.e., the sum of all label octets and label lengths) is +limited to 255. + +A domain is identified by a domain name, and consists of that part of +the domain name space that is at or below the domain name which +specifies the domain. A domain is a subdomain of another domain if it +is contained within that domain. This relationship can be tested by +seeing if the subdomain's name ends with the containing domain's name. +For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ". + +3.2. Administrative guidelines on use + +As a matter of policy, the DNS technical specifications do not mandate a +particular tree structure or rules for selecting labels; its goal is to +be as general as possible, so that it can be used to build arbitrary +applications. In particular, the system was designed so that the name +space did not have to be organized along the lines of network +boundaries, name servers, etc. The rationale for this is not that the +name space should have no implied semantics, but rather that the choice +of implied semantics should be left open to be used for the problem at + + + +Mockapetris [Page 8] + +RFC 1034 Domain Concepts and Facilities November 1987 + + +hand, and that different parts of the tree can have different implied +semantics. For example, the IN-ADDR.ARPA domain is organized and +distributed by network and host address because its role is to translate +from network or host numbers to names; NetBIOS domains [RFC-1001, RFC- +1002] are flat because that is appropriate for that application. + +However, there are some guidelines that apply to the "normal" parts of +the name space used for hosts, mailboxes, etc., that will make the name +space more uniform, provide for growth, and minimize problems as +software is converted from the older host table. The political +decisions about the top levels of the tree originated in RFC-920. +Current policy for the top levels is discussed in [RFC-1032]. MILNET +conversion issues are covered in [RFC-1031]. + +Lower domains which will eventually be broken into multiple zones should +provide branching at the top of the domain so that the eventual +decomposition can be done without renaming. Node labels which use +special characters, leading digits, etc., are likely to break older +software which depends on more restrictive choices. + +3.3. Technical guidelines on use + +Before the DNS can be used to hold naming information for some kind of +object, two needs must be met: + + - A convention for mapping between object names and domain + names. This describes how information about an object is + accessed. + + - RR types and data formats for describing the object. + +These rules can be quite simple or fairly complex. Very often, the +designer must take into account existing formats and plan for upward +compatibility for existing usage. Multiple mappings or levels of +mapping may be required. + +For hosts, the mapping depends on the existing syntax for host names +which is a subset of the usual text representation for domain names, +together with RR formats for describing host addresses, etc. Because we +need a reliable inverse mapping from address to host name, a special +mapping for addresses into the IN-ADDR.ARPA domain is also defined. + +For mailboxes, the mapping is slightly more complex. The usual mail +address <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/doc/rfc/rfc1035.txt b/doc/rfc/rfc1035.txt new file mode 100644 index 0000000..b1a9bf5 --- /dev/null +++ b/doc/rfc/rfc1035.txt @@ -0,0 +1,3077 @@ +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/doc/rfc/rfc1101.txt b/doc/rfc/rfc1101.txt new file mode 100644 index 0000000..66c9d8b --- /dev/null +++ b/doc/rfc/rfc1101.txt @@ -0,0 +1,787 @@ + + + + + + +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/doc/rfc/rfc1122.txt b/doc/rfc/rfc1122.txt new file mode 100644 index 0000000..c14f2e5 --- /dev/null +++ b/doc/rfc/rfc1122.txt @@ -0,0 +1,6844 @@ + + + + + + +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/doc/rfc/rfc1123.txt b/doc/rfc/rfc1123.txt new file mode 100644 index 0000000..51cdf83 --- /dev/null +++ b/doc/rfc/rfc1123.txt @@ -0,0 +1,5782 @@ + + + + + + +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/doc/rfc/rfc1183.txt b/doc/rfc/rfc1183.txt new file mode 100644 index 0000000..6f08044 --- /dev/null +++ b/doc/rfc/rfc1183.txt @@ -0,0 +1,619 @@ + + + + + + +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/doc/rfc/rfc1348.txt b/doc/rfc/rfc1348.txt new file mode 100644 index 0000000..d9e5dea --- /dev/null +++ b/doc/rfc/rfc1348.txt @@ -0,0 +1,227 @@ + + + + + + +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/doc/rfc/rfc1535.txt b/doc/rfc/rfc1535.txt new file mode 100644 index 0000000..03bddee --- /dev/null +++ b/doc/rfc/rfc1535.txt @@ -0,0 +1,283 @@ + + + + + + +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/doc/rfc/rfc1536.txt b/doc/rfc/rfc1536.txt new file mode 100644 index 0000000..5ff2b25 --- /dev/null +++ b/doc/rfc/rfc1536.txt @@ -0,0 +1,675 @@ + + + + + + +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/doc/rfc/rfc1537.txt b/doc/rfc/rfc1537.txt new file mode 100644 index 0000000..81b9768 --- /dev/null +++ b/doc/rfc/rfc1537.txt @@ -0,0 +1,507 @@ + + + + + + +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/doc/rfc/rfc1591.txt b/doc/rfc/rfc1591.txt new file mode 100644 index 0000000..89e0a25 --- /dev/null +++ b/doc/rfc/rfc1591.txt @@ -0,0 +1,395 @@ + + + + + + +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/doc/rfc/rfc1611.txt b/doc/rfc/rfc1611.txt new file mode 100644 index 0000000..ed5b93a --- /dev/null +++ b/doc/rfc/rfc1611.txt @@ -0,0 +1,1683 @@ + + + + + + +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/doc/rfc/rfc1612.txt b/doc/rfc/rfc1612.txt new file mode 100644 index 0000000..4ef23b0 --- /dev/null +++ b/doc/rfc/rfc1612.txt @@ -0,0 +1,1795 @@ + + + + + + +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/doc/rfc/rfc1706.txt b/doc/rfc/rfc1706.txt new file mode 100644 index 0000000..5b5d821 --- /dev/null +++ b/doc/rfc/rfc1706.txt @@ -0,0 +1,563 @@ + + + + + + +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/doc/rfc/rfc1712.txt b/doc/rfc/rfc1712.txt new file mode 100644 index 0000000..40d8857 --- /dev/null +++ b/doc/rfc/rfc1712.txt @@ -0,0 +1,395 @@ + + + + + + +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/doc/rfc/rfc1750.txt b/doc/rfc/rfc1750.txt new file mode 100644 index 0000000..56d478c --- /dev/null +++ b/doc/rfc/rfc1750.txt @@ -0,0 +1,1683 @@ + + + + + + +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/doc/rfc/rfc1876.txt b/doc/rfc/rfc1876.txt new file mode 100644 index 0000000..a289cff --- /dev/null +++ b/doc/rfc/rfc1876.txt @@ -0,0 +1,1011 @@ + + + + + + +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/doc/rfc/rfc1886.txt b/doc/rfc/rfc1886.txt new file mode 100644 index 0000000..9874fdd --- /dev/null +++ b/doc/rfc/rfc1886.txt @@ -0,0 +1,268 @@ + + + + + + +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/doc/rfc/rfc1982.txt b/doc/rfc/rfc1982.txt new file mode 100644 index 0000000..5a34bc4 --- /dev/null +++ b/doc/rfc/rfc1982.txt @@ -0,0 +1,394 @@ + + + + + + +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/doc/rfc/rfc1995.txt b/doc/rfc/rfc1995.txt new file mode 100644 index 0000000..b50bdc6 --- /dev/null +++ b/doc/rfc/rfc1995.txt @@ -0,0 +1,451 @@ + + + + + + +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/doc/rfc/rfc1996.txt b/doc/rfc/rfc1996.txt new file mode 100644 index 0000000..b08f200 --- /dev/null +++ b/doc/rfc/rfc1996.txt @@ -0,0 +1,395 @@ + + + + + + +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/doc/rfc/rfc2052.txt b/doc/rfc/rfc2052.txt new file mode 100644 index 0000000..46ba362 --- /dev/null +++ b/doc/rfc/rfc2052.txt @@ -0,0 +1,563 @@ + + + + + + +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/doc/rfc/rfc2104.txt b/doc/rfc/rfc2104.txt new file mode 100644 index 0000000..a205103 --- /dev/null +++ b/doc/rfc/rfc2104.txt @@ -0,0 +1,620 @@ + + + + + + +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/doc/rfc/rfc2119.txt b/doc/rfc/rfc2119.txt new file mode 100644 index 0000000..e31fae4 --- /dev/null +++ b/doc/rfc/rfc2119.txt @@ -0,0 +1,171 @@ + + + + + + +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/doc/rfc/rfc2133.txt b/doc/rfc/rfc2133.txt new file mode 100644 index 0000000..ea66cf0 --- /dev/null +++ b/doc/rfc/rfc2133.txt @@ -0,0 +1,1795 @@ + + + + + + +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/doc/rfc/rfc2136.txt b/doc/rfc/rfc2136.txt new file mode 100644 index 0000000..4d62702 --- /dev/null +++ b/doc/rfc/rfc2136.txt @@ -0,0 +1,1460 @@ + + + + + + +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/doc/rfc/rfc2137.txt b/doc/rfc/rfc2137.txt new file mode 100644 index 0000000..ceb3613 --- /dev/null +++ b/doc/rfc/rfc2137.txt @@ -0,0 +1,619 @@ + + + + + + +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/doc/rfc/rfc2163.txt b/doc/rfc/rfc2163.txt new file mode 100644 index 0000000..00fcee7 --- /dev/null +++ b/doc/rfc/rfc2163.txt @@ -0,0 +1,1459 @@ + + + + + + +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/doc/rfc/rfc2168.txt b/doc/rfc/rfc2168.txt new file mode 100644 index 0000000..3eed1bd --- /dev/null +++ b/doc/rfc/rfc2168.txt @@ -0,0 +1,1123 @@ + + + + + + +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/doc/rfc/rfc2181.txt b/doc/rfc/rfc2181.txt new file mode 100644 index 0000000..7899e1c --- /dev/null +++ b/doc/rfc/rfc2181.txt @@ -0,0 +1,842 @@ + + + + + + +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/doc/rfc/rfc2230.txt b/doc/rfc/rfc2230.txt new file mode 100644 index 0000000..03995fe --- /dev/null +++ b/doc/rfc/rfc2230.txt @@ -0,0 +1,619 @@ + + + + + + +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/doc/rfc/rfc2308.txt b/doc/rfc/rfc2308.txt new file mode 100644 index 0000000..9123a95 --- /dev/null +++ b/doc/rfc/rfc2308.txt @@ -0,0 +1,1067 @@ + + + + + + +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/doc/rfc/rfc2317.txt b/doc/rfc/rfc2317.txt new file mode 100644 index 0000000..c17bb41 --- /dev/null +++ b/doc/rfc/rfc2317.txt @@ -0,0 +1,563 @@ + + + + + + +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/doc/rfc/rfc2373.txt b/doc/rfc/rfc2373.txt new file mode 100644 index 0000000..59fcff8 --- /dev/null +++ b/doc/rfc/rfc2373.txt @@ -0,0 +1,1459 @@ + + + + + + +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/doc/rfc/rfc2374.txt b/doc/rfc/rfc2374.txt new file mode 100644 index 0000000..e3c7f0d --- /dev/null +++ b/doc/rfc/rfc2374.txt @@ -0,0 +1,675 @@ + + + + + + +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/doc/rfc/rfc2375.txt b/doc/rfc/rfc2375.txt new file mode 100644 index 0000000..a1fe8b9 --- /dev/null +++ b/doc/rfc/rfc2375.txt @@ -0,0 +1,451 @@ + + + + + + +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/doc/rfc/rfc2418.txt b/doc/rfc/rfc2418.txt new file mode 100644 index 0000000..9bdb2c5 --- /dev/null +++ b/doc/rfc/rfc2418.txt @@ -0,0 +1,1459 @@ + + + + + + +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/doc/rfc/rfc2535.txt b/doc/rfc/rfc2535.txt new file mode 100644 index 0000000..fe0b3d0 --- /dev/null +++ b/doc/rfc/rfc2535.txt @@ -0,0 +1,2635 @@ + + + + + + +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/doc/rfc/rfc2536.txt b/doc/rfc/rfc2536.txt new file mode 100644 index 0000000..88be242 --- /dev/null +++ b/doc/rfc/rfc2536.txt @@ -0,0 +1,339 @@ + + + + + + +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/doc/rfc/rfc2537.txt b/doc/rfc/rfc2537.txt new file mode 100644 index 0000000..cb75cf5 --- /dev/null +++ b/doc/rfc/rfc2537.txt @@ -0,0 +1,339 @@ + + + + + + +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/doc/rfc/rfc2538.txt b/doc/rfc/rfc2538.txt new file mode 100644 index 0000000..c53e3ef --- /dev/null +++ b/doc/rfc/rfc2538.txt @@ -0,0 +1,563 @@ + + + + + + +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/doc/rfc/rfc2539.txt b/doc/rfc/rfc2539.txt new file mode 100644 index 0000000..cf32523 --- /dev/null +++ b/doc/rfc/rfc2539.txt @@ -0,0 +1,395 @@ + + + + + + +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/doc/rfc/rfc2540.txt b/doc/rfc/rfc2540.txt new file mode 100644 index 0000000..6314806 --- /dev/null +++ b/doc/rfc/rfc2540.txt @@ -0,0 +1,339 @@ + + + + + + +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/doc/rfc/rfc2541.txt b/doc/rfc/rfc2541.txt new file mode 100644 index 0000000..a62ed2b --- /dev/null +++ b/doc/rfc/rfc2541.txt @@ -0,0 +1,395 @@ + + + + + + +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/doc/rfc/rfc2553.txt b/doc/rfc/rfc2553.txt new file mode 100644 index 0000000..6989bf3 --- /dev/null +++ b/doc/rfc/rfc2553.txt @@ -0,0 +1,2299 @@ + + + + + + +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/doc/rfc/rfc2671.txt b/doc/rfc/rfc2671.txt new file mode 100644 index 0000000..ec05f80 --- /dev/null +++ b/doc/rfc/rfc2671.txt @@ -0,0 +1,395 @@ + + + + + + +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/doc/rfc/rfc2672.txt b/doc/rfc/rfc2672.txt new file mode 100644 index 0000000..1103016 --- /dev/null +++ b/doc/rfc/rfc2672.txt @@ -0,0 +1,507 @@ + + + + + + +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/doc/rfc/rfc2673.txt b/doc/rfc/rfc2673.txt new file mode 100644 index 0000000..19d272e --- /dev/null +++ b/doc/rfc/rfc2673.txt @@ -0,0 +1,395 @@ + + + + + + +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/doc/rfc/rfc2782.txt b/doc/rfc/rfc2782.txt new file mode 100644 index 0000000..1827f10 --- /dev/null +++ b/doc/rfc/rfc2782.txt @@ -0,0 +1,675 @@ + + + + + + +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/doc/rfc/rfc2825.txt b/doc/rfc/rfc2825.txt new file mode 100644 index 0000000..fd8ef7c --- /dev/null +++ b/doc/rfc/rfc2825.txt @@ -0,0 +1,395 @@ +
+
+
+
+
+
+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/doc/rfc/rfc2826.txt b/doc/rfc/rfc2826.txt new file mode 100644 index 0000000..b4d8869 --- /dev/null +++ b/doc/rfc/rfc2826.txt @@ -0,0 +1,339 @@ +
+
+
+
+
+
+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/doc/rfc/rfc2845.txt b/doc/rfc/rfc2845.txt new file mode 100644 index 0000000..aa9f385 --- /dev/null +++ b/doc/rfc/rfc2845.txt @@ -0,0 +1,843 @@ + + + + + + +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/doc/rfc/rfc2874.txt b/doc/rfc/rfc2874.txt new file mode 100644 index 0000000..915c104 --- /dev/null +++ b/doc/rfc/rfc2874.txt @@ -0,0 +1,1123 @@ + + + + + + +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/doc/rfc/rfc2915.txt b/doc/rfc/rfc2915.txt new file mode 100644 index 0000000..2022ba1 --- /dev/null +++ b/doc/rfc/rfc2915.txt @@ -0,0 +1,1011 @@ + + + + + + +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/doc/rfc/rfc2929.txt b/doc/rfc/rfc2929.txt new file mode 100644 index 0000000..f055968 --- /dev/null +++ b/doc/rfc/rfc2929.txt @@ -0,0 +1,675 @@ + + + + + + +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/doc/rfc/rfc2930.txt b/doc/rfc/rfc2930.txt new file mode 100644 index 0000000..f99573d --- /dev/null +++ b/doc/rfc/rfc2930.txt @@ -0,0 +1,899 @@ + + + + + + +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/doc/rfc/rfc2931.txt b/doc/rfc/rfc2931.txt new file mode 100644 index 0000000..84cc97e --- /dev/null +++ b/doc/rfc/rfc2931.txt @@ -0,0 +1,563 @@ + + + + + + +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/doc/rfc/rfc3007.txt b/doc/rfc/rfc3007.txt new file mode 100644 index 0000000..1697475 --- /dev/null +++ b/doc/rfc/rfc3007.txt @@ -0,0 +1,507 @@ + + + + + + +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/doc/rfc/rfc3008.txt b/doc/rfc/rfc3008.txt new file mode 100644 index 0000000..08a4a8f --- /dev/null +++ b/doc/rfc/rfc3008.txt @@ -0,0 +1,395 @@ + + + + + + +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/doc/rfc/rfc3071.txt b/doc/rfc/rfc3071.txt new file mode 100644 index 0000000..2c4d52f --- /dev/null +++ b/doc/rfc/rfc3071.txt @@ -0,0 +1,563 @@ + + + + + + +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/doc/rfc/rfc3090.txt b/doc/rfc/rfc3090.txt new file mode 100644 index 0000000..08008f7 --- /dev/null +++ b/doc/rfc/rfc3090.txt @@ -0,0 +1,619 @@ + + + + + + +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/doc/rfc/rfc3110.txt b/doc/rfc/rfc3110.txt new file mode 100644 index 0000000..7646948 --- /dev/null +++ b/doc/rfc/rfc3110.txt @@ -0,0 +1,395 @@ + + + + + + +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/doc/rfc/rfc3123.txt b/doc/rfc/rfc3123.txt new file mode 100644 index 0000000..3b2fe00 --- /dev/null +++ b/doc/rfc/rfc3123.txt @@ -0,0 +1,451 @@ + + + + + + +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/doc/rfc/rfc3152.txt b/doc/rfc/rfc3152.txt new file mode 100644 index 0000000..b226ce6 --- /dev/null +++ b/doc/rfc/rfc3152.txt @@ -0,0 +1,227 @@ + + + + + + +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/doc/rfc/rfc3197.txt b/doc/rfc/rfc3197.txt new file mode 100644 index 0000000..94cefa4 --- /dev/null +++ b/doc/rfc/rfc3197.txt @@ -0,0 +1,283 @@ + + + + + + +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/doc/rfc/rfc3225.txt b/doc/rfc/rfc3225.txt new file mode 100644 index 0000000..13e6768 --- /dev/null +++ b/doc/rfc/rfc3225.txt @@ -0,0 +1,339 @@ + + + + + + +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/doc/rfc/rfc3226.txt b/doc/rfc/rfc3226.txt new file mode 100644 index 0000000..dac0e11 --- /dev/null +++ b/doc/rfc/rfc3226.txt @@ -0,0 +1,339 @@ + + + + + + +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/doc/rfc/rfc3258.txt b/doc/rfc/rfc3258.txt new file mode 100644 index 0000000..dcd4b34 --- /dev/null +++ b/doc/rfc/rfc3258.txt @@ -0,0 +1,619 @@ + + + + + + +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/doc/rfc/rfc3363.txt b/doc/rfc/rfc3363.txt new file mode 100644 index 0000000..9d7a39c --- /dev/null +++ b/doc/rfc/rfc3363.txt @@ -0,0 +1,339 @@ + + + + + + +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/doc/rfc/rfc3364.txt b/doc/rfc/rfc3364.txt new file mode 100644 index 0000000..189c0d2 --- /dev/null +++ b/doc/rfc/rfc3364.txt @@ -0,0 +1,619 @@ + + + + + + +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/doc/rfc/rfc3425.txt b/doc/rfc/rfc3425.txt new file mode 100644 index 0000000..707cafd --- /dev/null +++ b/doc/rfc/rfc3425.txt @@ -0,0 +1,283 @@ + + + + + + +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/doc/rfc/rfc3445.txt b/doc/rfc/rfc3445.txt new file mode 100644 index 0000000..67f9b2d --- /dev/null +++ b/doc/rfc/rfc3445.txt @@ -0,0 +1,563 @@ + + + + + + +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/doc/rfc/rfc3467.txt b/doc/rfc/rfc3467.txt new file mode 100644 index 0000000..37ac7ec --- /dev/null +++ b/doc/rfc/rfc3467.txt @@ -0,0 +1,1739 @@ + + + + + + +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/doc/rfc/rfc3490.txt b/doc/rfc/rfc3490.txt new file mode 100644 index 0000000..d2e0b3b --- /dev/null +++ b/doc/rfc/rfc3490.txt @@ -0,0 +1,1235 @@ + + + + + + +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/doc/rfc/rfc3491.txt b/doc/rfc/rfc3491.txt new file mode 100644 index 0000000..dbc86c7 --- /dev/null +++ b/doc/rfc/rfc3491.txt @@ -0,0 +1,395 @@ + + + + + + +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/doc/rfc/rfc3492.txt b/doc/rfc/rfc3492.txt new file mode 100644 index 0000000..e72ad81 --- /dev/null +++ b/doc/rfc/rfc3492.txt @@ -0,0 +1,1963 @@ + + + + + + +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/doc/rfc/rfc3493.txt b/doc/rfc/rfc3493.txt new file mode 100644 index 0000000..5fea6c1 --- /dev/null +++ b/doc/rfc/rfc3493.txt @@ -0,0 +1,2187 @@ + + + + + + +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/doc/rfc/rfc3513.txt b/doc/rfc/rfc3513.txt new file mode 100644 index 0000000..49c0fa4 --- /dev/null +++ b/doc/rfc/rfc3513.txt @@ -0,0 +1,1459 @@ + + + + + + +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/doc/rfc/rfc3596.txt b/doc/rfc/rfc3596.txt new file mode 100644 index 0000000..f65690c --- /dev/null +++ b/doc/rfc/rfc3596.txt @@ -0,0 +1,451 @@ + + + + + + +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/doc/rfc/rfc3597.txt b/doc/rfc/rfc3597.txt new file mode 100644 index 0000000..19e9a55 --- /dev/null +++ b/doc/rfc/rfc3597.txt @@ -0,0 +1,451 @@ + + + + + + +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/doc/rfc/rfc3645.txt b/doc/rfc/rfc3645.txt new file mode 100644 index 0000000..6126678 --- /dev/null +++ b/doc/rfc/rfc3645.txt @@ -0,0 +1,1459 @@ + + + + + + +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/doc/rfc/rfc3655.txt b/doc/rfc/rfc3655.txt new file mode 100644 index 0000000..13e586b --- /dev/null +++ b/doc/rfc/rfc3655.txt @@ -0,0 +1,451 @@ + + + + + + +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/doc/rfc/rfc3658.txt b/doc/rfc/rfc3658.txt new file mode 100644 index 0000000..88cfb5a --- /dev/null +++ b/doc/rfc/rfc3658.txt @@ -0,0 +1,1067 @@ + + + + + + +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/doc/rfc/rfc3757.txt b/doc/rfc/rfc3757.txt new file mode 100644 index 0000000..31890a4 --- /dev/null +++ b/doc/rfc/rfc3757.txt @@ -0,0 +1,451 @@ + + + + + + +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/doc/rfc/rfc3833.txt b/doc/rfc/rfc3833.txt new file mode 100644 index 0000000..8ce4d34 --- /dev/null +++ b/doc/rfc/rfc3833.txt @@ -0,0 +1,899 @@ + + + + + + +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/doc/rfc/rfc3845.txt b/doc/rfc/rfc3845.txt new file mode 100644 index 0000000..9887a20 --- /dev/null +++ b/doc/rfc/rfc3845.txt @@ -0,0 +1,395 @@ + + + + + + +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/doc/rfc/rfc3901.txt b/doc/rfc/rfc3901.txt new file mode 100644 index 0000000..43b7356 --- /dev/null +++ b/doc/rfc/rfc3901.txt @@ -0,0 +1,283 @@ + + + + + + +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/doc/rfc/rfc4025.txt b/doc/rfc/rfc4025.txt new file mode 100644 index 0000000..92e7f40 --- /dev/null +++ b/doc/rfc/rfc4025.txt @@ -0,0 +1,675 @@ + + + + + + +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/doc/rfc/rfc4033.txt b/doc/rfc/rfc4033.txt new file mode 100644 index 0000000..7f0a464 --- /dev/null +++ b/doc/rfc/rfc4033.txt @@ -0,0 +1,1179 @@ + + + + + + +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/doc/rfc/rfc4034.txt b/doc/rfc/rfc4034.txt new file mode 100644 index 0000000..6a12c6b --- /dev/null +++ b/doc/rfc/rfc4034.txt @@ -0,0 +1,1627 @@ + + + + + + +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/doc/rfc/rfc4035.txt b/doc/rfc/rfc4035.txt new file mode 100644 index 0000000..b701cd2 --- /dev/null +++ b/doc/rfc/rfc4035.txt @@ -0,0 +1,2971 @@ + + + + + + +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/doc/rfc/rfc4074.txt b/doc/rfc/rfc4074.txt new file mode 100644 index 0000000..d9252b3 --- /dev/null +++ b/doc/rfc/rfc4074.txt @@ -0,0 +1,339 @@ + + + + + + +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/doc/rfc/rfc4159.txt b/doc/rfc/rfc4159.txt new file mode 100644 index 0000000..1ab4bd1 --- /dev/null +++ b/doc/rfc/rfc4159.txt @@ -0,0 +1,171 @@ + + + + + + +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/doc/rfc/rfc4193.txt b/doc/rfc/rfc4193.txt new file mode 100644 index 0000000..17e2c0b --- /dev/null +++ b/doc/rfc/rfc4193.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group R. Hinden +Request for Comments: 4193 Nokia +Category: Standards Track B. Haberman + JHU-APL + October 2005 + + + Unique Local IPv6 Unicast Addresses + +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 defines an IPv6 unicast address format that is globally + unique and is intended for local communications, usually inside of a + site. These addresses are not expected to be routable on the global + Internet. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Acknowledgements ................................................3 + 3. Local IPv6 Unicast Addresses ....................................3 + 3.1. Format .....................................................3 + 3.1.1. Background ..........................................4 + 3.2. Global ID ..................................................4 + 3.2.1. Locally Assigned Global IDs .........................5 + 3.2.2. Sample Code for Pseudo-Random Global ID Algorithm ...5 + 3.2.3. Analysis of the Uniqueness of Global IDs ............6 + 3.3. Scope Definition ...........................................6 + 4. Operational Guidelines ..........................................7 + 4.1. Routing ....................................................7 + 4.2. Renumbering and Site Merging ...............................7 + 4.3. Site Border Router and Firewall Packet Filtering ...........8 + 4.4. DNS Issues .................................................8 + 4.5. Application and Higher Level Protocol Issues ...............9 + 4.6. Use of Local IPv6 Addresses for Local Communication ........9 + 4.7. Use of Local IPv6 Addresses with VPNs .....................10 + + + +Hinden & Haberman Standards Track [Page 1] + +RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 + + + 5. Global Routing Considerations ..................................11 + 5.1. From the Standpoint of the Internet .......................11 + 5.2. From the Standpoint of a Site .............................11 + 6. Advantages and Disadvantages ...................................12 + 6.1. Advantages ................................................12 + 6.2. Disadvantages .............................................13 + 7. Security Considerations ........................................13 + 8. IANA Considerations ............................................13 + 9. References .....................................................13 + 9.1. Normative References ......................................13 + 9.2. Informative References ....................................14 + +1. Introduction + + This document defines an IPv6 unicast address format that is globally + unique and is intended for local communications [IPV6]. These + addresses are called Unique Local IPv6 Unicast Addresses and are + abbreviated in this document as Local IPv6 addresses. They are not + expected to be routable on the global Internet. They are routable + inside of a more limited area such as a site. They may also be + routed between a limited set of sites. + + Local IPv6 unicast addresses have the following characteristics: + + - Globally unique prefix (with high probability of uniqueness). + + - Well-known prefix to allow for easy filtering at site + boundaries. + + - Allow sites to be combined or privately interconnected without + creating any address conflicts or requiring renumbering of + interfaces that use these prefixes. + + - Internet Service Provider independent and can be used for + communications inside of a site without having any permanent or + intermittent Internet connectivity. + + - If accidentally leaked outside of a site via routing or DNS, + there is no conflict with any other addresses. + + - In practice, applications may treat these addresses like global + scoped addresses. + + This document defines the format of Local IPv6 addresses, how to + allocate them, and usage considerations including routing, site + border routers, DNS, application support, VPN usage, and guidelines + for how to use for local communication inside a site. + + + + +Hinden & Haberman Standards Track [Page 2] + +RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 + + + 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. Acknowledgements + + The underlying idea of creating Local IPv6 addresses described in + this document has been proposed a number of times by a variety of + people. The authors of this document do not claim exclusive credit. + Credit goes to Brian Carpenter, Christian Huitema, Aidan Williams, + Andrew White, Charlie Perkins, and many others. The authors would + also like to thank Brian Carpenter, Charlie Perkins, Harald + Alvestrand, Keith Moore, Margaret Wasserman, Shannon Behrens, Alan + Beard, Hans Kruse, Geoff Huston, Pekka Savola, Christian Huitema, Tim + Chown, Steve Bellovin, Alex Zinin, Tony Hain, Bill Fenner, Sam + Hartman, and Elwyn Davies for their comments and suggestions on this + document. + +3. Local IPv6 Unicast Addresses + +3.1. Format + + The Local IPv6 addresses are created using a pseudo-randomly + allocated global ID. They have the following format: + + | 7 bits |1| 40 bits | 16 bits | 64 bits | + +--------+-+------------+-----------+----------------------------+ + | Prefix |L| Global ID | Subnet ID | Interface ID | + +--------+-+------------+-----------+----------------------------+ + + Where: + + Prefix FC00::/7 prefix to identify Local IPv6 unicast + addresses. + + L Set to 1 if the prefix is locally assigned. + Set to 0 may be defined in the future. See + Section 3.2 for additional information. + + Global ID 40-bit global identifier used to create a + globally unique prefix. See Section 3.2 for + additional information. + + Subnet ID 16-bit Subnet ID is an identifier of a subnet + within the site. + + Interface ID 64-bit Interface ID as defined in [ADDARCH]. + + + + +Hinden & Haberman Standards Track [Page 3] + +RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 + + +3.1.1. Background + + There were a range of choices available when choosing the size of the + prefix and Global ID field length. There is a direct tradeoff + between having a Global ID field large enough to support foreseeable + future growth and not using too much of the IPv6 address space + needlessly. A reasonable way of evaluating a specific field length + is to compare it to a projected 2050 world population of 9.3 billion + [POPUL] and the number of resulting /48 prefixes per person. A range + of prefix choices is shown in the following table: + + Prefix Global ID Number of Prefixes % of IPv6 + Length /48 Prefixes per Person Address Space + + /11 37 137,438,953,472 15 0.049% + /10 38 274,877,906,944 30 0.098% + /9 39 549,755,813,888 59 0.195% + /8 40 1,099,511,627,776 118 0.391% + /7 41 2,199,023,255,552 236 0.781% + /6 42 4,398,046,511,104 473 1.563% + + A very high utilization ratio of these allocations can be assumed + because the Global ID field does not require internal structure, and + there is no reason to be able to aggregate the prefixes. + + The authors believe that a /7 prefix resulting in a 41-bit Global ID + space (including the L bit) is a good choice. It provides for a + large number of assignments (i.e., 2.2 trillion) and at the same time + uses less than .8% of the total IPv6 address space. It is unlikely + that this space will be exhausted. If more than this were to be + needed, then additional IPv6 address space could be allocated for + this purpose. + +3.2. Global ID + + The allocation of Global IDs is pseudo-random [RANDOM]. They MUST + NOT be assigned sequentially or with well-known numbers. This is to + ensure that there is not any relationship between allocations and to + help clarify that these prefixes are not intended to be routed + globally. Specifically, these prefixes are not designed to + aggregate. + + This document defines a specific local method to allocate Global IDs, + indicated by setting the L bit to 1. Another method, indicated by + clearing the L bit, may be defined later. Apart from the allocation + method, all Local IPv6 addresses behave and are treated identically. + + + + + +Hinden & Haberman Standards Track [Page 4] + +RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 + + + The local assignments are self-generated and do not need any central + coordination or assignment, but have an extremely high probability of + being unique. + +3.2.1. Locally Assigned Global IDs + + Locally assigned Global IDs MUST be generated with a pseudo-random + algorithm consistent with [RANDOM]. Section 3.2.2 describes a + suggested algorithm. It is important that all sites generating + Global IDs use a functionally similar algorithm to ensure there is a + high probability of uniqueness. + + The use of a pseudo-random algorithm to generate Global IDs in the + locally assigned prefix gives an assurance that any network numbered + using such a prefix is highly unlikely to have that address space + clash with any other network that has another locally assigned prefix + allocated to it. This is a particularly useful property when + considering a number of scenarios including networks that merge, + overlapping VPN address space, or hosts mobile between such networks. + +3.2.2. Sample Code for Pseudo-Random Global ID Algorithm + + The algorithm described below is intended to be used for locally + assigned Global IDs. In each case the resulting global ID will be + used in the appropriate prefix as defined in Section 3.2. + + 1) Obtain the current time of day in 64-bit NTP format [NTP]. + + 2) Obtain an EUI-64 identifier from the system running this + algorithm. If an EUI-64 does not exist, one can be created from + a 48-bit MAC address as specified in [ADDARCH]. If an EUI-64 + cannot be obtained or created, a suitably unique identifier, + local to the node, should be used (e.g., system serial number). + + 3) Concatenate the time of day with the system-specific identifier + in order to create a key. + + 4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1]; + the resulting value is 160 bits. + + 5) Use the least significant 40 bits as the Global ID. + + 6) Concatenate FC00::/7, the L bit set to 1, and the 40-bit Global + ID to create a Local IPv6 address prefix. + + This algorithm will result in a Global ID that is reasonably unique + and can be used to create a locally assigned Local IPv6 address + prefix. + + + +Hinden & Haberman Standards Track [Page 5] + +RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 + + +3.2.3. Analysis of the Uniqueness of Global IDs + + The selection of a pseudo random Global ID is similar to the + selection of an SSRC identifier in RTP/RTCP defined in Section 8.1 of + [RTP]. This analysis is adapted from that document. + + Since Global IDs are chosen randomly (and independently), it is + possible that separate networks have chosen the same Global ID. For + any given network, with one or more random Global IDs, that has + inter-connections to other such networks, having a total of N such + IDs, the probability that two or more of these IDs will collide can + be approximated using the formula: + + P = 1 - exp(-N**2 / 2**(L+1)) + + where P is the probability of collision, N is the number of + interconnected Global IDs, and L is the length of the Global ID. + + The following table shows the probability of a collision for a range + of connections using a 40-bit Global ID field. + + Connections Probability of Collision + + 2 1.81*10^-12 + 10 4.54*10^-11 + 100 4.54*10^-09 + 1000 4.54*10^-07 + 10000 4.54*10^-05 + + Based on this analysis, the uniqueness of locally generated Global + IDs is adequate for sites planning a small to moderate amount of + inter-site communication using locally generated Global IDs. + +3.3. Scope Definition + + By default, the scope of these addresses is global. That is, they + are not limited by ambiguity like the site-local addresses defined in + [ADDARCH]. Rather, these prefixes are globally unique, and as such, + their applicability is greater than site-local addresses. Their + limitation is in the routability of the prefixes, which is limited to + a site and any explicit routing agreements with other sites to + propagate them (also see Section 4.1). Also, unlike site-locals, a + site may have more than one of these prefixes and use them at the + same time. + + + + + + + +Hinden & Haberman Standards Track [Page 6] + +RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 + + +4. Operational Guidelines + + The guidelines in this section do not require any change to the + normal routing and forwarding functionality in an IPv6 host or + router. These are configuration and operational usage guidelines. + +4.1. Routing + + Local IPv6 addresses are designed to be routed inside of a site in + the same manner as other types of unicast addresses. They can be + carried in any IPv6 routing protocol without any change. + + It is expected that they would share the same Subnet IDs with + provider-based global unicast addresses, if they were being used + concurrently [GLOBAL]. + + The default behavior of exterior routing protocol sessions between + administrative routing regions must be to ignore receipt of and not + advertise prefixes in the FC00::/7 block. A network operator may + specifically configure prefixes longer than FC00::/7 for inter-site + communication. + + If BGP is being used at the site border with an ISP, the default BGP + configuration must filter out any Local IPv6 address prefixes, both + incoming and outgoing. It must be set both to keep any Local IPv6 + address prefixes from being advertised outside of the site as well as + to keep these prefixes from being learned from another site. The + exception to this is if there are specific /48 or longer routes + created for one or more Local IPv6 prefixes. + + For link-state IGPs, it is suggested that a site utilizing IPv6 local + address prefixes be contained within one IGP domain or area. By + containing an IPv6 local address prefix to a single link-state area + or domain, the distribution of prefixes can be controlled. + +4.2. Renumbering and Site Merging + + The use of Local IPv6 addresses in a site results in making + communication that uses these addresses independent of renumbering a + site's provider-based global addresses. + + When merging multiple sites, the addresses created with these + prefixes are unlikely to need to be renumbered because all of the + addresses have a high probability of being unique. Routes for each + specific prefix would have to be configured to allow routing to work + correctly between the formerly separate sites. + + + + + +Hinden & Haberman Standards Track [Page 7] + +RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 + + +4.3. Site Border Router and Firewall Packet Filtering + + While no serious harm will be done if packets with these addresses + are sent outside of a site via a default route, it is recommended + that routers be configured by default to keep any packets with Local + IPv6 addresses from leaking outside of the site and to keep any site + prefixes from being advertised outside of their site. + + Site border routers and firewalls should be configured to not forward + any packets with Local IPv6 source or destination addresses outside + of the site, unless they have been explicitly configured with routing + information about specific /48 or longer Local IPv6 prefixes. This + will ensure that packets with Local IPv6 destination addresses will + not be forwarded outside of the site via a default route. The + default behavior of these devices should be to install a "reject" + route for these prefixes. Site border routers should respond with + the appropriate ICMPv6 Destination Unreachable message to inform the + source that the packet was not forwarded. [ICMPV6]. This feedback is + important to avoid transport protocol timeouts. + + Routers that maintain peering arrangements between Autonomous Systems + throughout the Internet should obey the recommendations for site + border routers, unless configured otherwise. + +4.4. DNS Issues + + At the present time, AAAA and PTR records for locally assigned local + IPv6 addresses are not recommended to be installed in the global DNS. + + For background on this recommendation, one of the concerns about + adding AAAA and PTR records to the global DNS for locally assigned + Local IPv6 addresses stems from the lack of complete assurance that + the prefixes are unique. There is a small possibility that the same + locally assigned IPv6 Local addresses will be used by two different + organizations both claiming to be authoritative with different + contents. In this scenario, it is likely there will be a connection + attempt to the closest host with the corresponding locally assigned + IPv6 Local address. This may result in connection timeouts, + connection failures indicated by ICMP Destination Unreachable + messages, or successful connections to the wrong host. Due to this + concern, adding AAAA records for these addresses to the global DNS is + thought to be unwise. + + Reverse (address-to-name) queries for locally assigned IPv6 Local + addresses MUST NOT be sent to name servers for the global DNS, due to + the load that such queries would create for the authoritative name + servers for the ip6.arpa zone. This form of query load is not + specific to locally assigned Local IPv6 addresses; any current form + + + +Hinden & Haberman Standards Track [Page 8] + +RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 + + + of local addressing creates additional load of this kind, due to + reverse queries leaking out of the site. However, since allowing + such queries to escape from the site serves no useful purpose, there + is no good reason to make the existing load problems worse. + + The recommended way to avoid sending such queries to nameservers for + the global DNS is for recursive name server implementations to act as + if they were authoritative for an empty d.f.ip6.arpa zone and return + RCODE 3 for any such query. Implementations that choose this + strategy should allow it to be overridden, but returning an RCODE 3 + response for such queries should be the default, both because this + will reduce the query load problem and also because, if the site + administrator has not set up the reverse tree corresponding to the + locally assigned IPv6 Local addresses in use, returning RCODE 3 is in + fact the correct answer. + +4.5. Application and Higher Level Protocol Issues + + Application and other higher level protocols can treat Local IPv6 + addresses in the same manner as other types of global unicast + addresses. No special handling is required. This type of address + may not be reachable, but that is no different from other types of + IPv6 global unicast address. Applications need to be able to handle + multiple addresses that may or may not be reachable at any point in + time. In most cases, this complexity should be hidden in APIs. + + From a host's perspective, the difference between Local IPv6 and + other types of global unicast addresses shows up as different + reachability and could be handled by default in that way. In some + cases, it is better for nodes and applications to treat them + differently from global unicast addresses. A starting point might be + to give them preference over global unicast, but fall back to global + unicast if a particular destination is found to be unreachable. Much + of this behavior can be controlled by how they are allocated to nodes + and put into the DNS. However, it is useful if a host can have both + types of addresses and use them appropriately. + + Note that the address selection mechanisms of [ADDSEL], and in + particular the policy override mechanism replacing default address + selection, are expected to be used on a site where Local IPv6 + addresses are configured. + +4.6. Use of Local IPv6 Addresses for Local Communication + + Local IPv6 addresses, like global scope unicast addresses, are only + assigned to nodes if their use has been enabled (via IPv6 address + autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually). They are + + + + +Hinden & Haberman Standards Track [Page 9] + +RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 + + + not created automatically in the way that IPv6 link-local addresses + are and will not appear or be used unless they are purposely + configured. + + In order for hosts to autoconfigure Local IPv6 addresses, routers + have to be configured to advertise Local IPv6 /64 prefixes in router + advertisements, or a DHCPv6 server must have been configured to + assign them. In order for a node to learn the Local IPv6 address of + another node, the Local IPv6 address must have been installed in a + naming system (e.g., DNS, proprietary naming system, etc.) For these + reasons, controlling their usage in a site is straightforward. + + To limit the use of Local IPv6 addresses the following guidelines + apply: + + - Nodes that are to only be reachable inside of a site: The local + DNS should be configured to only include the Local IPv6 + addresses of these nodes. Nodes with only Local IPv6 addresses + must not be installed in the global DNS. + + - Nodes that are to be limited to only communicate with other + nodes in the site: These nodes should be set to only + autoconfigure Local IPv6 addresses via [ADDAUTO] or to only + receive Local IPv6 addresses via [DHCP6]. Note: For the case + where both global and Local IPv6 prefixes are being advertised + on a subnet, this will require a switch in the devices to only + autoconfigure Local IPv6 addresses. + + - Nodes that are to be reachable from inside of the site and from + outside of the site: The DNS should be configured to include + the global addresses of these nodes. The local DNS may be + configured to also include the Local IPv6 addresses of these + nodes. + + - Nodes that can communicate with other nodes inside of the site + and outside of the site: These nodes should autoconfigure global + addresses via [ADDAUTO] or receive global address via [DHCP6]. + They may also obtain Local IPv6 addresses via the same + mechanisms. + +4.7. Use of Local IPv6 Addresses with VPNs + + Local IPv6 addresses can be used for inter-site Virtual Private + Networks (VPN) if appropriate routes are set up. Because the + addresses are unique, these VPNs will work reliably and without the + need for translation. They have the additional property that they + will continue to work if the individual sites are renumbered or + merged. + + + +Hinden & Haberman Standards Track [Page 10] + +RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 + + +5. Global Routing Considerations + + Section 4.1 provides operational guidelines that forbid default + routing of local addresses between sites. Concerns were raised to + the IPv6 working group and to the IETF as a whole that sites may + attempt to use local addresses as globally routed provider- + independent addresses. This section describes why using local + addresses as globally-routed provider-independent addresses is + unadvisable. + +5.1. From the Standpoint of the Internet + + There is a mismatch between the structure of IPv6 local addresses and + the normal IPv6 wide area routing model. The /48 prefix of an IPv6 + local addresses fits nowhere in the normal hierarchy of IPv6 unicast + addresses. Normal IPv6 unicast addresses can be routed + hierarchically down to physical subnet (link) level and only have to + be flat-routed on the physical subnet. IPv6 local addresses would + have to be flat-routed even over the wide area Internet. + + Thus, packets whose destination address is an IPv6 local address + could be routed over the wide area only if the corresponding /48 + prefix were carried by the wide area routing protocol in use, such as + BGP. This contravenes the operational assumption that long prefixes + will be aggregated into many fewer short prefixes, to limit the table + size and convergence time of the routing protocol. If a network uses + both normal IPv6 addresses [ADDARCH] and IPv6 local addresses, these + types of addresses will certainly not aggregate with each other, + since they differ from the most significant bit onwards. Neither + will IPv6 local addresses aggregate with each other, due to their + random bit patterns. This means that there would be a very + significant operational penalty for attempting to use IPv6 local + address prefixes generically with currently known wide area routing + technology. + +5.2. From the Standpoint of a Site + + There are a number of design factors in IPv6 local addresses that + reduce the likelihood that IPv6 local addresses will be used as + arbitrary global unicast addresses. These include: + + - The default rules to filter packets and routes make it very + difficult to use IPv6 local addresses for arbitrary use across + the Internet. For a site to use them as general purpose unicast + addresses, it would have to make sure that the default rules + were not being used by all other sites and intermediate ISPs + used for their current and future communication. + + + + +Hinden & Haberman Standards Track [Page 11] + +RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 + + + - They are not mathematically guaranteed to be unique and are not + registered in public databases. Collisions, while highly + unlikely, are possible and a collision can compromise the + integrity of the communications. The lack of public + registration creates operational problems. + + - The addresses are allocated randomly. If a site had multiple + prefixes that it wanted to be used globally, the cost of + advertising them would be very high because they could not be + aggregated. + + - They have a long prefix (i.e., /48) so a single local address + prefix doesn't provide enough address space to be used + exclusively by the largest organizations. + +6. Advantages and Disadvantages + +6.1. Advantages + + This approach has the following advantages: + + - Provides Local IPv6 prefixes that can be used independently of + any provider-based IPv6 unicast address allocations. This is + useful for sites not always connected to the Internet or sites + that wish to have a distinct prefix that can be used to localize + traffic inside of the site. + + - Applications can treat these addresses in an identical manner as + any other type of global IPv6 unicast addresses. + + - Sites can be merged without any renumbering of the Local IPv6 + addresses. + + - Sites can change their provider-based IPv6 unicast address + without disrupting any communication that uses Local IPv6 + addresses. + + - Well-known prefix that allows for easy filtering at site + boundary. + + - Can be used for inter-site VPNs. + + - If accidently leaked outside of a site via routing or DNS, there + is no conflict with any other addresses. + + + + + + + +Hinden & Haberman Standards Track [Page 12] + +RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 + + +6.2. Disadvantages + + This approach has the following disadvantages: + + - Not possible to route Local IPv6 prefixes on the global Internet + with current routing technology. Consequentially, it is + necessary to have the default behavior of site border routers to + filter these addresses. + + - There is a very low probability of non-unique locally assigned + Global IDs being generated by the algorithm in Section 3.2.3. + This risk can be ignored for all practical purposes, but it + leads to a theoretical risk of clashing address prefixes. + +7. Security Considerations + + Local IPv6 addresses do not provide any inherent security to the + nodes that use them. They may be used with filters at site + boundaries to keep Local IPv6 traffic inside of the site, but this is + no more or less secure than filtering any other type of global IPv6 + unicast addresses. + + Local IPv6 addresses do allow for address-based security mechanisms, + including IPsec, across end to end VPN connections. + +8. IANA Considerations + + The IANA has assigned the FC00::/7 prefix to "Unique Local Unicast". + +9. References + +9.1. Normative References + + [ADDARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6 + (IPv6) Addressing Architecture", RFC 3513, April 2003. + + [FIPS] "Federal Information Processing Standards Publication", + (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. + + [GLOBAL] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global + Unicast Address Format", RFC 3587, August 2003. + + [ICMPV6] Conta, A. and S. Deering, "Internet Control Message + Protocol (ICMPv6) for the Internet Protocol Version 6 + (IPv6) Specification", RFC 2463, December 1998. + + + + + + +Hinden & Haberman Standards Track [Page 13] + +RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 + + + [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [NTP] Mills, D., "Network Time Protocol (Version 3) + Specification, Implementation and Analysis", RFC 1305, + March 1992. + + [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, + June 2005. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [SHA1] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 + (SHA1)", RFC 3174, September 2001. + +9.2. Informative References + + [ADDAUTO] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [ADDSEL] Draves, R., "Default Address Selection for Internet + Protocol version 6 (IPv6)", RFC 3484, February 2003. + + [DHCP6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and + M. Carney, "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6)", RFC 3315, July 2003. + + [POPUL] Population Reference Bureau, "World Population Data Sheet + of the Population Reference Bureau 2002", August 2002. + + [RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, July 2003. + + + + + + + + + + + + + + + + +Hinden & Haberman Standards Track [Page 14] + +RFC 4193 Unique Local IPv6 Unicast Addresses October 2005 + + +Authors' Addresses + + Robert M. Hinden + Nokia + 313 Fairchild Drive + Mountain View, CA 94043 + USA + + Phone: +1 650 625-2004 + EMail: bob.hinden@nokia.com + + + Brian Haberman + Johns Hopkins University + Applied Physics Lab + 11100 Johns Hopkins Road + Laurel, MD 20723 + USA + + Phone: +1 443 778 1319 + EMail: brian@innovationslab.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hinden & Haberman Standards Track [Page 15] + +RFC 4193 Unique Local IPv6 Unicast Addresses October 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. + + + + + + + +Hinden & Haberman Standards Track [Page 16] + diff --git a/doc/rfc/rfc4255.txt b/doc/rfc/rfc4255.txt new file mode 100644 index 0000000..f350b7a --- /dev/null +++ b/doc/rfc/rfc4255.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group J. Schlyter +Request for Comments: 4255 OpenSSH +Category: Standards Track W. Griffin + SPARTA + January 2006 + + + Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints + +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 (2006). + +Abstract + + This document describes a method of verifying Secure Shell (SSH) host + keys using Domain Name System Security (DNSSEC). The document + defines a new DNS resource record that contains a standard SSH key + fingerprint. + +Table of Contents + + 1. Introduction ....................................................2 + 2. SSH Host Key Verification .......................................2 + 2.1. Method .....................................................2 + 2.2. Implementation Notes .......................................2 + 2.3. Fingerprint Matching .......................................3 + 2.4. Authentication .............................................3 + 3. The SSHFP Resource Record .......................................3 + 3.1. The SSHFP RDATA Format .....................................4 + 3.1.1. Algorithm Number Specification ......................4 + 3.1.2. Fingerprint Type Specification ......................4 + 3.1.3. Fingerprint .........................................5 + 3.2. Presentation Format of the SSHFP RR ........................5 + 4. Security Considerations .........................................5 + 5. IANA Considerations .............................................6 + 6. Normative References ............................................7 + 7. Informational References ........................................7 + 8. Acknowledgements ................................................8 + + + + +Schlyter & Griffin Standards Track [Page 1] + +RFC 4255 DNS and SSH Fingerprints January 2006 + + +1. Introduction + + The SSH [6] protocol provides secure remote login and other secure + network services over an insecure network. The security of the + connection relies on the server authenticating itself to the client + as well as the user authenticating itself to the server. + + If a connection is established to a server whose public key is not + already known to the client, a fingerprint of the key is presented to + the user for verification. If the user decides that the fingerprint + is correct and accepts the key, the key is saved locally and used for + verification for all following connections. While some security- + conscious users verify the fingerprint out-of-band before accepting + the key, many users blindly accept the presented key. + + The method described here can provide out-of-band verification by + looking up a fingerprint of the server public key in the DNS [1][2] + and using DNSSEC [5] to verify the lookup. + + In order to distribute the fingerprint using DNS, this document + defines a new DNS resource record, "SSHFP", to carry the fingerprint. + + Basic understanding of the DNS system [1][2] and the DNS security + extensions [5] is assumed by 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 RFC 2119 [3]. + +2. SSH Host Key Verification + +2.1. Method + + Upon connection to an SSH server, the SSH client MAY look up the + SSHFP resource record(s) for the host it is connecting to. If the + algorithm and fingerprint of the key received from the SSH server + match the algorithm and fingerprint of one of the SSHFP resource + record(s) returned from DNS, the client MAY accept the identity of + the server. + +2.2. Implementation Notes + + Client implementors SHOULD provide a configurable policy used to + select the order of methods used to verify a host key. This document + defines one method: Fingerprint storage in DNS. Another method + defined in the SSH Architecture [6] uses local files to store keys + for comparison. Other methods that could be defined in the future + might include storing fingerprints in LDAP or other databases. A + + + +Schlyter & Griffin Standards Track [Page 2] + +RFC 4255 DNS and SSH Fingerprints January 2006 + + + configurable policy will allow administrators to determine which + methods they want to use and in what order the methods should be + prioritized. This will allow administrators to determine how much + trust they want to place in the different methods. + + One specific scenario for having a configurable policy is where + clients do not use fully qualified host names to connect to servers. + In this scenario, the implementation SHOULD verify the host key + against a local database before verifying the key via the fingerprint + returned from DNS. This would help prevent an attacker from + injecting a DNS search path into the local resolver and forcing the + client to connect to a different host. + +2.3. Fingerprint Matching + + The public key and the SSHFP resource record are matched together by + comparing algorithm number and fingerprint. + + The public key algorithm and the SSHFP algorithm number MUST + match. + + A message digest of the public key, using the message digest + algorithm specified in the SSHFP fingerprint type, MUST match the + SSHFP fingerprint. + +2.4. Authentication + + A public key verified using this method MUST NOT be trusted if the + SSHFP resource record (RR) used for verification was not + authenticated by a trusted SIG RR. + + Clients that do validate the DNSSEC signatures themselves SHOULD use + standard DNSSEC validation procedures. + + Clients that do not validate the DNSSEC signatures themselves MUST + use a secure transport (e.g., TSIG [9], SIG(0) [10], or IPsec [8]) + between themselves and the entity performing the signature + validation. + +3. The SSHFP Resource Record + + The SSHFP resource record (RR) is used to store a fingerprint of an + SSH public host key that is associated with a Domain Name System + (DNS) name. + + The RR type code for the SSHFP RR is 44. + + + + + +Schlyter & Griffin Standards Track [Page 3] + +RFC 4255 DNS and SSH Fingerprints January 2006 + + +3.1. The SSHFP RDATA Format + + The RDATA for a SSHFP RR consists of an algorithm number, fingerprint + type and the fingerprint of the public host key. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | algorithm | fp type | / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / + / / + / fingerprint / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +3.1.1. Algorithm Number Specification + + This algorithm number octet describes the algorithm of the public + key. The following values are assigned: + + Value Algorithm name + ----- -------------- + 0 reserved + 1 RSA + 2 DSS + + Reserving other types requires IETF consensus [4]. + +3.1.2. Fingerprint Type Specification + + The fingerprint type octet describes the message-digest algorithm + used to calculate the fingerprint of the public key. The following + values are assigned: + + Value Fingerprint type + ----- ---------------- + 0 reserved + 1 SHA-1 + + Reserving other types requires IETF consensus [4]. + + For interoperability reasons, as few fingerprint types as possible + should be reserved. The only reason to reserve additional types is + to increase security. + + + + + + + +Schlyter & Griffin Standards Track [Page 4] + +RFC 4255 DNS and SSH Fingerprints January 2006 + + +3.1.3. Fingerprint + + The fingerprint is calculated over the public key blob as described + in [7]. + + The message-digest algorithm is presumed to produce an opaque octet + string output, which is placed as-is in the RDATA fingerprint field. + +3.2. Presentation Format of the SSHFP RR + + The RDATA of the presentation format of the SSHFP resource record + consists of two numbers (algorithm and fingerprint type) followed by + the fingerprint itself, presented in hex, e.g.: + + host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890 + + The use of mnemonics instead of numbers is not allowed. + +4. Security Considerations + + Currently, the amount of trust a user can realistically place in a + server key is proportional to the amount of attention paid to + verifying that the public key presented actually corresponds to the + private key of the server. If a user accepts a key without verifying + the fingerprint with something learned through a secured channel, the + connection is vulnerable to a man-in-the-middle attack. + + The overall security of using SSHFP for SSH host key verification is + dependent on the security policies of the SSH host administrator and + DNS zone administrator (in transferring the fingerprint), detailed + aspects of how verification is done in the SSH implementation, and in + the client's diligence in accessing the DNS in a secure manner. + + One such aspect is in which order fingerprints are looked up (e.g., + first checking local file and then SSHFP). We note that, in addition + to protecting the first-time transfer of host keys, SSHFP can + optionally be used for stronger host key protection. + + If SSHFP is checked first, new SSH host keys may be distributed by + replacing the corresponding SSHFP in DNS. + + If SSH host key verification can be configured to require SSHFP, + SSH host key revocation can be implemented by removing the + corresponding SSHFP from DNS. + + + + + + + +Schlyter & Griffin Standards Track [Page 5] + +RFC 4255 DNS and SSH Fingerprints January 2006 + + + As stated in Section 2.2, we recommend that SSH implementors provide + a policy mechanism to control the order of methods used for host key + verification. One specific scenario for having a configurable policy + is where clients use unqualified host names to connect to servers. + In this case, we recommend that SSH implementations check the host + key against a local database before verifying the key via the + fingerprint returned from DNS. This would help prevent an attacker + from injecting a DNS search path into the local resolver and forcing + the client to connect to a different host. + + A different approach to solve the DNS search path issue would be for + clients to use a trusted DNS search path, i.e., one not acquired + through DHCP or other autoconfiguration mechanisms. Since there is + no way with current DNS lookup APIs to tell whether a search path is + from a trusted source, the entire client system would need to be + configured with this trusted DNS search path. + + Another dependency is on the implementation of DNSSEC itself. As + stated in Section 2.4, we mandate the use of secure methods for + lookup and that SSHFP RRs are authenticated by trusted SIG RRs. This + is especially important if SSHFP is to be used as a basis for host + key rollover and/or revocation, as described above. + + Since DNSSEC only protects the integrity of the host key fingerprint + after it is signed by the DNS zone administrator, the fingerprint + must be transferred securely from the SSH host administrator to the + DNS zone administrator. This could be done manually between the + administrators or automatically using secure DNS dynamic update [11] + between the SSH server and the nameserver. We note that this is no + different from other key enrollment situations, e.g., a client + sending a certificate request to a certificate authority for signing. + +5. IANA Considerations + + IANA has allocated the RR type code 44 for SSHFP from the standard RR + type space. + + IANA has opened a new registry for the SSHFP RR type for public key + algorithms. The defined types are: + + 0 is reserved + 1 is RSA + 2 is DSA + + Adding new reservations requires IETF consensus [4]. + + + + + + +Schlyter & Griffin Standards Track [Page 6] + +RFC 4255 DNS and SSH Fingerprints January 2006 + + + IANA has opened a new registry for the SSHFP RR type for fingerprint + types. The defined types are: + + 0 is reserved + 1 is SHA-1 + + Adding new reservations requires IETF consensus [4]. + +6. 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] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October + 1998. + + [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, March + 2005. + + Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", RFC + 4035, March 2005. + + [6] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) + Protocol Architecture", RFC 4251, January 2006. + + [7] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) + Transport Layer Protocol", RFC 4253, January 2006. + +7. Informational References + + [8] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document + Roadmap", RFC 2411, November 1998. + + + + + + +Schlyter & Griffin Standards Track [Page 7] + +RFC 4255 DNS and SSH Fingerprints January 2006 + + + [9] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. + + [10] Eastlake 3rd, D., "DNS Request and Transaction Signatures + ( SIG(0)s )", RFC 2931, September 2000. + + [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + +8. Acknowledgements + + The authors gratefully acknowledge, in no particular order, the + contributions of the following persons: + + Martin Fredriksson + + Olafur Gudmundsson + + Edward Lewis + + Bill Sommerfeld + +Authors' Addresses + + Jakob Schlyter + OpenSSH + 812 23rd Avenue SE + Calgary, Alberta T2G 1N8 + Canada + + EMail: jakob@openssh.com + URI: http://www.openssh.com/ + + + Wesley Griffin + SPARTA + 7075 Samuel Morse Drive + Columbia, MD 21046 + USA + + EMail: wgriffin@sparta.com + URI: http://www.sparta.com/ + + + + + + + + +Schlyter & Griffin Standards Track [Page 8] + +RFC 4255 DNS and SSH Fingerprints January 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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 provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Schlyter & Griffin Standards Track [Page 9] + diff --git a/doc/rfc/rfc4343.txt b/doc/rfc/rfc4343.txt new file mode 100644 index 0000000..621420a --- /dev/null +++ b/doc/rfc/rfc4343.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group D. Eastlake 3rd +Request for Comments: 4343 Motorola Laboratories +Updates: 1034, 1035, 2181 January 2006 +Category: Standards Track + + + Domain Name System (DNS) Case Insensitivity Clarification + +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 (2006). + +Abstract + + Domain Name System (DNS) names are "case insensitive". This document + explains exactly what that means and provides a clear specification + of the rules. This clarification updates RFCs 1034, 1035, and 2181. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Case Insensitivity of DNS Labels ................................2 + 2.1. Escaping Unusual DNS Label Octets ..........................2 + 2.2. Example Labels with Escapes ................................3 + 3. Name Lookup, Label Types, and CLASS .............................3 + 3.1. Original DNS Label Types ...................................4 + 3.2. Extended Label Type Case Insensitivity Considerations ......4 + 3.3. CLASS Case Insensitivity Considerations ....................4 + 4. Case on Input and Output ........................................5 + 4.1. DNS Output Case Preservation ...............................5 + 4.2. DNS Input Case Preservation ................................5 + 5. Internationalized Domain Names ..................................6 + 6. Security Considerations .........................................6 + 7. Acknowledgements ................................................7 + Normative References................................................7 + Informative References..............................................8 + + + + + + + +Eastlake 3rd Standards Track [Page 1] + +RFC 4343 DNS Case Insensitivity Clarification January 2006 + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + other information. Each node in the DNS tree has a name consisting + of zero or more labels [STD13, RFC1591, RFC2606] that are treated in + a case insensitive fashion. This document clarifies the meaning of + "case insensitive" for the DNS. This clarification updates RFCs + 1034, 1035 [STD13], and [RFC2181]. + + 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. Case Insensitivity of DNS Labels + + DNS was specified in the era of [ASCII]. DNS names were expected to + look like most host names or Internet email address right halves (the + part after the at-sign, "@") or to be numeric, as in the in-addr.arpa + part of the DNS name space. For example, + + foo.example.net. + aol.com. + www.gnu.ai.mit.edu. + or 69.2.0.192.in-addr.arpa. + + Case-varied alternatives to the above [RFC3092] would be DNS names + like + + Foo.ExamplE.net. + AOL.COM. + WWW.gnu.AI.mit.EDU. + or 69.2.0.192.in-ADDR.ARPA. + + However, the individual octets of which DNS names consist are not + limited to valid ASCII character codes. They are 8-bit bytes, and + all values are allowed. Many applications, however, interpret them + as ASCII characters. + +2.1. Escaping Unusual DNS Label Octets + + In Master Files [STD13] and other human-readable and -writable ASCII + contexts, an escape is needed for the byte value for period (0x2E, + ".") and all octet values outside of the inclusive range from 0x21 + ("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in + the two inclusive ranges from 0x00 to 0x20 and from 0x7F to 0xFF. + + + + + +Eastlake 3rd Standards Track [Page 2] + +RFC 4343 DNS Case Insensitivity Clarification January 2006 + + + One typographic convention for octets that do not correspond to an + ASCII printing graphic is to use a back-slash followed by the value + of the octet as an unsigned integer represented by exactly three + decimal digits. + + The same convention can be used for printing ASCII characters so that + they will be treated as a normal label character. This includes the + back-slash character used in this convention itself, which can be + expressed as \092 or \\, and the special label separator period + ("."), which can be expressed as and \046 or \. It is advisable to + avoid using a backslash to quote an immediately following non- + printing ASCII character code to avoid implementation difficulties. + + A back-slash followed by only one or two decimal digits is undefined. + A back-slash followed by four decimal digits produces two octets, the + first octet having the value of the first three digits considered as + a decimal number, and the second octet being the character code for + the fourth decimal digit. + +2.2. Example Labels with Escapes + + The first example below shows embedded spaces and a period (".") + within a label. The second one shows a 5-octet label where the + second octet has all bits zero, the third is a backslash, and the + fourth octet has all bits one. + + Donald\032E\.\032Eastlake\0323rd.example. + and a\000\\\255z.example. + +3. Name Lookup, Label Types, and CLASS + + According to the original DNS design decision, comparisons on name + lookup for DNS queries should be case insensitive [STD13]. That is + to say, a lookup string octet with a value in the inclusive range + from 0x41 to 0x5A, the uppercase ASCII letters, MUST match the + identical value and also match the corresponding value in the + inclusive range from 0x61 to 0x7A, the lowercase ASCII letters. A + lookup string octet with a lowercase ASCII letter value MUST + similarly match the identical value and also match the corresponding + value in the uppercase ASCII letter range. + + (Historical note: The terms "uppercase" and "lowercase" were invented + after movable type. The terms originally referred to the two font + trays for storing, in partitioned areas, the different physical type + elements. Before movable type, the nearest equivalent terms were + "majuscule" and "minuscule".) + + + + + +Eastlake 3rd Standards Track [Page 3] + +RFC 4343 DNS Case Insensitivity Clarification January 2006 + + + One way to implement this rule would be to subtract 0x20 from all + octets in the inclusive range from 0x61 to 0x7A before comparing + octets. Such an operation is commonly known as "case folding", but + implementation via case folding is not required. Note that the DNS + case insensitivity does NOT correspond to the case folding specified + in [ISO-8859-1] or [ISO-8859-2]. For example, the octets 0xDD (\221) + and 0xFD (\253) do NOT match, although in other contexts, where they + are interpreted as the upper- and lower-case version of "Y" with an + acute accent, they might. + +3.1. Original DNS Label Types + + DNS labels in wire-encoded names have a type associated with them. + The original DNS standard [STD13] had only two types: ASCII labels, + with a length from zero to 63 octets, and indirect (or compression) + labels, which consist of an offset pointer to a name location + elsewhere in the wire encoding on a DNS message. (The ASCII label of + length zero is reserved for use as the name of the root node of the + name tree.) ASCII labels follow the ASCII case conventions described + herein and, as stated above, can actually contain arbitrary byte + values. Indirect labels are, in effect, replaced by the name to + which they point, which is then treated with the case insensitivity + rules in this document. + +3.2. Extended Label Type Case Insensitivity Considerations + + DNS was extended by [RFC2671] so that additional label type numbers + would be available. (The only such type defined so far is the BINARY + type [RFC2673], which is now Experimental [RFC3363].) + + The ASCII case insensitivity conventions only apply to ASCII labels; + that is to say, label type 0x0, whether appearing directly or invoked + by indirect labels. + +3.3. CLASS Case Insensitivity Considerations + + As described in [STD13] and [RFC2929], DNS has an additional axis for + data location called CLASS. The only CLASS in global use at this + time is the "IN" (Internet) CLASS. + + The handling of DNS label case is not CLASS dependent. With the + original design of DNS, it was intended that a recursive DNS resolver + be able to handle new CLASSes that were unknown at the time of its + implementation. This requires uniform handling of label case + insensitivity. Should it become desirable, for example, to allocate + a CLASS with "case sensitive ASCII labels", it would be necessary to + allocate a new label type for these labels. + + + + +Eastlake 3rd Standards Track [Page 4] + +RFC 4343 DNS Case Insensitivity Clarification January 2006 + + +4. Case on Input and Output + + While ASCII label comparisons are case insensitive, [STD13] says case + MUST be preserved on output and preserved when convenient on input. + However, this means less than it would appear, since the preservation + of case on output is NOT required when output is optimized by the use + of indirect labels, as explained below. + +4.1. DNS Output Case Preservation + + [STD13] views the DNS namespace as a node tree. ASCII output is as + if a name were marshaled by taking the label on the node whose name + is to be output, converting it to a typographically encoded ASCII + string, walking up the tree outputting each label encountered, and + preceding all labels but the first with a period ("."). Wire output + follows the same sequence, but each label is wire encoded, and no + periods are inserted. No "case conversion" or "case folding" is done + during such output operations, thus "preserving" case. However, to + optimize output, indirect labels may be used to point to names + elsewhere in the DNS answer. In determining whether the name to be + pointed to (for example, the QNAME) is the "same" as the remainder of + the name being optimized, the case insensitive comparison specified + above is done. Thus, such optimization may easily destroy the output + preservation of case. This type of optimization is commonly called + "name compression". + +4.2. DNS Input Case Preservation + + Originally, DNS data came from an ASCII Master File as defined in + [STD13] or a zone transfer. DNS Dynamic update and incremental zone + transfers [RFC1995] have been added as a source of DNS data [RFC2136, + RFC3007]. When a node in the DNS name tree is created by any of such + inputs, no case conversion is done. Thus, the case of ASCII labels + is preserved if they are for nodes being created. However, when a + name label is input for a node that already exists in DNS data being + held, the situation is more complex. Implementations are free to + retain the case first loaded for such a label, to allow new input to + override the old case, or even to maintain separate copies preserving + the input case. + + For example, if data with owner name "foo.bar.example" [RFC3092] is + loaded and then later data with owner name "xyz.BAR.example" is + input, the name of the label on the "bar.example" node (i.e., "bar") + might or might not be changed to "BAR" in the DNS stored data. Thus, + later retrieval of data stored under "xyz.bar.example" in this case + can use "xyz.BAR.example" in all returned data, use "xyz.bar.example" + in all returned data, or even, when more than one RR is being + returned, use a mixture of these two capitalizations. This last case + + + +Eastlake 3rd Standards Track [Page 5] + +RFC 4343 DNS Case Insensitivity Clarification January 2006 + + + is unlikely, as optimization of answer length through indirect labels + tends to cause only one copy of the name tail ("bar.example" or + "BAR.example") to be used for all returned RRs. Note that none of + this has any effect on the number or completeness of the RR set + returned, only on the case of the names in the RR set returned. + + The same considerations apply when inputting multiple data records + with owner names differing only in case. For example, if an "A" + record is the first resource record stored under owner name + "xyz.BAR.example" and then a second "A" record is stored under + "XYZ.BAR.example", the second MAY be stored with the first (lower + case initial label) name, the second MAY override the first so that + only an uppercase initial label is retained, or both capitalizations + MAY be kept in the DNS stored data. In any case, a retrieval with + either capitalization will retrieve all RRs with either + capitalization. + + Note that the order of insertion into a server database of the DNS + name tree nodes that appear in a Master File is not defined so that + the results of inconsistent capitalization in a Master File are + unpredictable output capitalization. + +5. Internationalized Domain Names + + A scheme has been adopted for "internationalized domain names" and + "internationalized labels" as described in [RFC3490, RFC3454, + RFC3491, and RFC3492]. It makes most of [UNICODE] available through + a separate application level transformation from internationalized + domain name to DNS domain name and from DNS domain name to + internationalized domain name. Any case insensitivity that + internationalized domain names and labels have varies depending on + the script and is handled entirely as part of the transformation + described in [RFC3454] and [RFC3491], which should be seen for + further details. This is not a part of the DNS as standardized in + STD 13. + +6. Security Considerations + + The equivalence of certain DNS label types with case differences, as + clarified in this document, can lead to security problems. For + example, a user could be confused by believing that two domain names + differing only in case were actually different names. + + Furthermore, a domain name may be used in contexts other than the + DNS. It could be used as a case sensitive index into some database + or file system. Or it could be interpreted as binary data by some + integrity or authentication code system. These problems can usually + be handled by using a standardized or "canonical" form of the DNS + + + +Eastlake 3rd Standards Track [Page 6] + +RFC 4343 DNS Case Insensitivity Clarification January 2006 + + + ASCII type labels; that is, always mapping the ASCII letter value + octets in ASCII labels to some specific pre-chosen case, either + uppercase or lower case. An example of a canonical form for domain + names (and also a canonical ordering for them) appears in Section 6 + of [RFC4034]. See also [RFC3597]. + + Finally, a non-DNS name may be stored into DNS with the false + expectation that case will always be preserved. For example, + although this would be quite rare, on a system with case sensitive + email address local parts, an attempt to store two Responsible Person + (RP) [RFC1183] records that differed only in case would probably + produce unexpected results that might have security implications. + That is because the entire email address, including the possibly case + sensitive local or left-hand part, is encoded into a DNS name in a + readable fashion where the case of some letters might be changed on + output as described above. + +7. Acknowledgements + + The contributions to this document by Rob Austein, Olafur + Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana, + Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman + are gratefully acknowledged. + +Normative References + + [ASCII] ANSI, "USA Standard Code for Information Interchange", + X3.4, American National Standards Institute: New York, + 1968. + + [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, + August 1996. + + [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 (DNS + UPDATE)", RFC 2136, April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + + + + + +Eastlake 3rd Standards Track [Page 7] + +RFC 4343 DNS Case Insensitivity Clarification January 2006 + + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security + Extensions", RFC 4034, March 2005. + + [STD13] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. + + Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + +Informative References + + [ISO-8859-1] International Standards Organization, Standard for + Character Encodings, Latin-1. + + [ISO-8859-2] International Standards Organization, Standard for + Character Encodings, Latin-2. + + [RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P. + Mockapetris, "New DNS RR Definitions", RFC 1183, October + 1990. + + [RFC1591] Postel, J., "Domain Name System Structure and + Delegation", RFC 1591, March 1994. + + [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS + Names", BCP 32, RFC 2606, June 1999. + + [RFC2929] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, + "Domain Name System (DNS) IANA Considerations", BCP 42, + RFC 2929, September 2000. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", + RFC 2673, August 1999. + + [RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology + of "Foo"", RFC 3092, 1 April 2001. + + [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. + Hain, "Representing Internet Protocol version 6 (IPv6) + Addresses in the Domain Name System (DNS)", RFC 3363, + August 2002. + + + +Eastlake 3rd Standards Track [Page 8] + +RFC 4343 DNS Case Insensitivity Clarification January 2006 + + + [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of + Internationalized Strings ("stringprep")", RFC 3454, + December 2002. + + [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, + "Internationalizing Domain Names in Applications + (IDNA)", RFC 3490, March 2003. + + [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep + Profile for Internationalized Domain Names (IDN)", RFC + 3491, March 2003. + + [RFC3492] Costello, A., "Punycode: A Bootstring encoding of + Unicode for Internationalized Domain Names in + Applications (IDNA)", RFC 3492, March 2003. + + [UNICODE] The Unicode Consortium, "The Unicode Standard", + <http://www.unicode.org/unicode/standard/standard.html>. + +Author's Address + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Phone: +1 508-786-7554 (w) + EMail: Donald.Eastlake@motorola.com + + + + + + + + + + + + + + + + + + + + + + + +Eastlake 3rd Standards Track [Page 9] + +RFC 4343 DNS Case Insensitivity Clarification January 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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 provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Eastlake 3rd Standards Track [Page 10] + diff --git a/doc/rfc/rfc4367.txt b/doc/rfc/rfc4367.txt new file mode 100644 index 0000000..f066b64 --- /dev/null +++ b/doc/rfc/rfc4367.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group J. Rosenberg, Ed. +Request for Comments: 4367 IAB +Category: Informational February 2006 + + + What's in a Name: False Assumptions about DNS Names + +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 (2006). + +Abstract + + The Domain Name System (DNS) provides an essential service on the + Internet, mapping structured names to a variety of data, usually IP + addresses. These names appear in email addresses, Uniform Resource + Identifiers (URIs), and other application-layer identifiers that are + often rendered to human users. Because of this, there has been a + strong demand to acquire names that have significance to people, + through equivalence to registered trademarks, company names, types of + services, and so on. There is a danger in this trend; the humans and + automata that consume and use such names will associate specific + semantics with some names and thereby make assumptions about the + services that are, or should be, provided by the hosts associated + with the names. Those assumptions can often be false, resulting in a + variety of failure conditions. This document discusses this problem + in more detail and makes recommendations on how it can be avoided. + + + + + + + + + + + + + + + + + + +Rosenberg Informational [Page 1] + +RFC 4367 Name Assumptions February 2006 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Target Audience .................................................4 + 3. Modeling Usage of the DNS .......................................4 + 4. Possible Assumptions ............................................5 + 4.1. By the User ................................................5 + 4.2. By the Client ..............................................6 + 4.3. By the Server ..............................................7 + 5. Consequences of False Assumptions ...............................8 + 6. Reasons Why the Assumptions Can Be False ........................9 + 6.1. Evolution ..................................................9 + 6.2. Leakage ...................................................10 + 6.3. Sub-Delegation ............................................10 + 6.4. Mobility ..................................................12 + 6.5. Human Error ...............................................12 + 7. Recommendations ................................................12 + 8. A Note on RFC 2219 and RFC 2782 ................................13 + 9. Security Considerations ........................................14 + 10. Acknowledgements ..............................................14 + 11. IAB Members ...................................................14 + 12. Informative References ........................................15 + +1. Introduction + + The Domain Name System (DNS) [1] provides an essential service on the + Internet, mapping structured names to a variety of different types of + data. Most often it is used to obtain the IP address of a host + associated with that name [2] [1] [3]. However, it can be used to + obtain other information, and proposals have been made for nearly + everything, including geographic information [4]. + + Domain names are most often used in identifiers used by application + protocols. The most well known include email addresses and URIs, + such as the HTTP URL [5], Real Time Streaming Protocol (RTSP) URL + [6], and SIP URI [7]. These identifiers are ubiquitous, appearing on + business cards, web pages, street signs, and so on. Because of this, + there has been a strong demand to acquire domain names that have + significance to people through equivalence to registered trademarks, + company names, types of services, and so on. Such identifiers serve + many business purposes, including extension of brand, advertising, + and so on. + + People often make assumptions about the type of service that is or + should be provided by a host associated with that name, based on + their expectations and understanding of what the name implies. This, + in turn, triggers attempts by organizations to register domain names + based on that presumed user expectation. Examples of this are the + + + +Rosenberg Informational [Page 2] + +RFC 4367 Name Assumptions February 2006 + + + various proposals for a Top-Level Domain (TLD) that could be + associated with adult content [8], the requests for creation of TLDs + associated with mobile devices and services, and even phishing + attacks. + + When these assumptions are codified into the behavior of an + automaton, such as an application client or server, as a result of + implementor choice, management directive, or domain owner policy, the + overall system can fail in various ways. This document describes a + number of typical ways in which these assumptions can be codified, + how they can be wrong, the consequences of those mistakes, and the + recommended ways in which they can be avoided. + + Section 4 describes some of the possible assumptions that clients, + servers, and people can make about a domain name. In this context, + an "assumption" is defined as any behavior that is expected when + accessing a service at a domain name, even though the behavior is not + explicitly codified in protocol specifications. Frequently, these + assumptions involve ignoring parts of a specification based on an + assumption that the client or server is deployed in an environment + that is more rigid than the specification allows. Section 5 + overviews some of the consequences of these false assumptions. + Generally speaking, these consequences can include a variety of + different interoperability failures, user experience failures, and + system failures. Section 6 discusses why these assumptions can be + false from the very beginning or become false at some point in the + future. Most commonly, they become false because the environment + changes in unexpected ways over time, and what was a valid assumption + before, no longer is. Other times, the assumptions prove wrong + because they were based on the belief that a specific community of + clients and servers was participating, and an element outside of that + community began participating. + + Section 7 then provides some recommendations. These recommendations + encapsulate some of the engineering mantras that have been at the + root of Internet protocol design for decades. These include: + + Follow the specifications. + + Use the capability negotiation techniques provided in the + protocols. + + Be liberal in what you accept, and conservative in what you send. + [18] + + Overall, automata should not change their behavior within a protocol + based on the domain name, or some component of the domain name, of + the host they are communicating with. + + + +Rosenberg Informational [Page 3] + +RFC 4367 Name Assumptions February 2006 + + +2. Target Audience + + This document has several audiences. Firstly, it is aimed at + implementors who ultimately develop the software that make the false + assumptions that are the subject of this document. The + recommendations described here are meant to reinforce the engineering + guidelines that are often understood by implementors, but frequently + forgotten as deadlines near and pressures mount. + + The document is also aimed at technology managers, who often develop + the requirements that lead to these false assumptions. For them, + this document serves as a vehicle for emphasizing the importance of + not taking shortcuts in the scope of applicability of a project. + + Finally, this document is aimed at domain name policy makers and + administrators. For them, it points out the perils in establishing + domain policies that get codified into the operation of applications + running within that domain. + +3. Modeling Usage of the DNS + + + +--------+ + | | + | | + | DNS | + |Service | + | | + +--------+ + ^ | + | | + | | + | | + /--\ | | + | | | V + | | +--------+ +--------+ + \--/ | | | | + | | | | | + ---+--- | Client |-------------------->| Server | + | | | | | + | | | | | + /\ +--------+ +--------+ + / \ + / \ + + User + Figure 1 + + + + +Rosenberg Informational [Page 4] + +RFC 4367 Name Assumptions February 2006 + + + Figure 1 shows a simple conceptual model of how the DNS is used by + applications. A user of the application obtains an identifier for + particular content or service it wishes to obtain. This identifier + is often a URL or URI that contains a domain name. The user enters + this identifier into its client application (for example, by typing + in the URL in a web browser window). The client is the automaton (a + software and/or hardware system) that contacts a server for that + application in order to provide service to the user. To do that, it + contacts a DNS server to resolve the domain name in the identifier to + an IP address. It then contacts the server at that IP address. This + simple model applies to application protocols such as HTTP [5], SIP + [7], RTSP [6], and SMTP [9]. + + >From this model, it is clear that three entities in the system can + potentially make false assumptions about the service provided by the + server. The human user may form expectations relating to the content + of the service based on a parsing of the host name from which the + content originated. The server might assume that the client + connecting to it supports protocols that it does not, can process + content that it cannot, or has capabilities that it does not. + Similarly, the client might assume that the server supports + protocols, content, or capabilities that it does not. Furthermore, + applications can potentially contain a multiplicity of humans, + clients, and servers, all of which can independently make these false + assumptions. + +4. Possible Assumptions + + For each of the three elements, there are many types of false + assumptions that can be made. + +4.1. By the User + + The set of possible assumptions here is nearly boundless. Users + might assume that an HTTP URL that looks like a company name maps to + a server run by that company. They might assume that an email from a + email address in the .gov TLD is actually from a government employee. + They might assume that the content obtained from a web server within + a TLD labeled as containing adult materials (for example, .sex) + actually contains adult content [8]. These assumptions are + unavoidable, may all be false, and are not the focus of this + document. + + + + + + + + + +Rosenberg Informational [Page 5] + +RFC 4367 Name Assumptions February 2006 + + +4.2. By the Client + + Even though the client is an automaton, it can make some of the same + assumptions that a human user might make. For example, many clients + assume that any host with a hostname that begins with "www" is a web + server, even though this assumption may be false. + + In addition, the client concerns itself with the protocols needed to + communicate with the server. As a result, it might make assumptions + about the operation of the protocols for communicating with the + server. These assumptions manifest themselves in an implementation + when a standardized protocol negotiation technique defined by the + protocol is ignored, and instead, some kind of rule is coded into the + software that comes to its own conclusion about what the negotiation + would have determined. The result is often a loss of + interoperability, degradation in reliability, and worsening of user + experience. + + Authentication Algorithm: Though a protocol might support a + multiplicity of authentication techniques, a client might assume + that a server always supports one that is only optional according + to the protocol. For example, a SIP client contacting a SIP + server in a domain that is apparently used to identify mobile + devices (for example, www.example.cellular) might assume that the + server supports the optional Authentication and Key Agreement + (AKA) digest technique [10], just because of the domain name that + was used to access the server. As another example, a web client + might assume that a server with the name https.example.com + supports HTTP over Transport Layer Security (TLS) [16]. + + Data Formats: Though a protocol might allow a multiplicity of data + formats to be sent from the server to the client, the client might + assume a specific one, rather than using the content labeling and + negotiation capabilities of the underlying protocol. For example, + an RTSP client might assume that all audio content delivered to it + from media.example.cellular uses a low-bandwidth codec. As + another example, a mail client might assume that the contents of + messages it retrieves from a mail server at mail.example.cellular + are always text, instead of checking the MIME headers [11] in the + message in order to determine the actual content type. + + Protocol Extensions: A client may attempt an operation on the server + that requires the server to support an optional protocol + extension. However, rather than implementing the necessary + fallback logic, the client may falsely assume that the extension + is supported. As an example, a SIP client that requires reliable + provisional responses to its request (RFC 3262 [17]) might assume + that this extension is supported on servers in the domain + + + +Rosenberg Informational [Page 6] + +RFC 4367 Name Assumptions February 2006 + + + sip.example.telecom. Furthermore, the client would not implement + the fallback behavior defined in RFC 3262, since it would assume + that all servers it will communicate with are in this domain and + that all therefore support this extension. However, if the + assumptions prove wrong, the client is unable to make any phone + calls. + + Languages: A client may support facilities for processing text + content differently depending on the language of the text. Rather + than determining the language from markers in the message from the + server, the client might assume a language based on the domain + name. This assumption can easily be wrong. For example, a client + might assume that any text in a web page retrieved from a server + within the .de country code TLD (ccTLD) is in German, and attempt + a translation to Finnish. This would fail dramatically if the + text was actually in French. Unfortunately, this client behavior + is sometimes exhibited because the server has not properly labeled + the language of the content in the first place, often because the + server assumed such a labeling was not needed. This is an example + of how these false assumptions can create vicious cycles. + +4.3. By the Server + + The server, like the client, is an automaton. Let us consider one + servicing a particular domain -- www.company.cellular, for example. + It might assume that all clients connecting to this domain support + particular capabilities, rather than using the underlying protocol to + make this determination. Some examples include: + + Authentication Algorithm: The server can assume that a client + supports a particular, optional, authentication technique, and it + therefore does not support the mandatory one. + + Language: The server can serve content in a particular language, + based on an assumption that clients accessing the domain speak a + particular language, or based on an assumption that clients coming + from a particular IP address speak a certain language. + + Data Formats: The server can assume that the client supports a + particular set of MIME types and is only capable of sending ones + within that set. When it generates content in a protocol + response, it ignores any content negotiation headers that were + present in the request. For example, a web server might ignore + the Accept HTTP header field and send a specific image format. + + + + + + + +Rosenberg Informational [Page 7] + +RFC 4367 Name Assumptions February 2006 + + + Protocol Extensions: The server might assume that the client supports + a particular optional protocol extension, and so it does not + support the fallback behavior necessary in the case where the + client does not. + + Client Characteristics: The server might assume certain things about + the physical characteristics of its clients, such as memory + footprint, processing power, screen sizes, screen colors, pointing + devices, and so on. Based on these assumptions, it might choose + specific behaviors when processing a request. For example, a web + server might always assume that clients connect through cell + phones, and therefore return content that lacks images and is + tuned for such devices. + +5. Consequences of False Assumptions + + There are numerous negative outcomes that can arise from the various + false assumptions that users, servers, and clients can make. These + include: + + Interoperability Failure: In these cases, the client or server + assumed some kind of protocol operation, and this assumption was + wrong. The result is that the two are unable to communicate, and + the user receives some kind of an error. This represents a total + interoperability failure, manifesting itself as a lack of service + to users of the system. Unfortunately, this kind of failure + persists. Repeated attempts over time by the client to access the + service will fail. Only a change in the server or client software + can fix this problem. + + System Failure: In these cases, the client or server misinterpreted a + protocol operation, and this misinterpretation was serious enough + to uncover a bug in the implementation. The bug causes a system + crash or some kind of outage, either transient or permanent (until + user reset). If this failure occurs in a server, not only will + the connecting client lose service, but other clients attempting + to connect will not get service. As an example, if a web server + assumes that content passed to it from a client (created, for + example, by a digital camera) is of a particular content type, and + it always passes image content to a codec for decompression prior + to storage, the codec might crash when it unexpectedly receives an + image compressed in a different format. Of course, it might crash + even if the Content-Type was correct, but the compressed bitstream + was invalid. False assumptions merely introduce additional + failure cases. + + + + + + +Rosenberg Informational [Page 8] + +RFC 4367 Name Assumptions February 2006 + + + Poor User Experience: In these cases, the client and server + communicate, but the user receives a diminished user experience. + For example, if a client on a PC connects to a web site that + provides content for mobile devices, the content may be + underwhelming when viewed on the PC. Or, a client accessing a + streaming media service may receive content of very low bitrate, + even though the client supported better codecs. Indeed, if a user + wishes to access content from both a cellular device and a PC + using a shared address book (that is, an address book shared + across multiple devices), the user would need two entries in that + address book, and would need to use the right one from the right + device. This is a poor user experience. + + Degraded Security: In these cases, a weaker security mechanism is + used than the one that ought to have been used. As an example, a + server in a domain might assume that it is only contacted by + clients with a limited set of authentication algorithms, even + though the clients have been recently upgraded to support a + stronger set. + +6. Reasons Why the Assumptions Can Be False + + Assumptions made by clients and servers about the operation of + protocols when contacting a particular domain are brittle, and can be + wrong for many reasons. On the server side, many of the assumptions + are based on the notion that a domain name will only be given to, or + used by, a restricted set of clients. If the holder of the domain + name assumes something about those clients, and can assume that only + those clients use the domain name, then it can configure or program + the server to operate specifically for those clients. Both parts of + this assumption can be wrong, as discussed in more detail below. + + On the client side, the notion is similar, being based on the + assumption that a server within a particular domain will provide a + specific type of service. Sub-delegation and evolution, both + discussed below, can make these assumptions wrong. + +6.1. Evolution + + The Internet and the devices that access it are constantly evolving, + often at a rapid pace. Unfortunately, there is a tendency to build + for the here and now, and then worry about the future at a later + time. Many of the assumptions above are predicated on + characteristics of today's clients and servers. Support for specific + protocols, authentication techniques, or content are based on today's + standards and today's devices. Even though they may, for the most + part, be true, they won't always be. An excellent example is mobile + devices. A server servicing a domain accessed by mobile devices + + + +Rosenberg Informational [Page 9] + +RFC 4367 Name Assumptions February 2006 + + + might try to make assumptions about the protocols, protocol + extensions, security mechanisms, screen sizes, or processor power of + such devices. However, all of these characteristics can and will + change over time. + + When they do change, the change is usually evolutionary. The result + is that the assumptions remain valid in some cases, but not in + others. It is difficult to fix such systems, since it requires the + server to detect what type of client is connecting, and what its + capabilities are. Unless the system is built and deployed with these + capability negotiation techniques built in to begin with, such + detection can be extremely difficult. In fact, fixing it will often + require the addition of such capability negotiation features that, if + they had been in place and used to begin with, would have avoided the + problem altogether. + +6.2. Leakage + + Servers also make assumptions because of the belief that they will + only be accessed by specific clients, and in particular, those that + are configured or provisioned to use the domain name. In essence, + there is an assumption of community -- that a specific community + knows and uses the domain name, while others outside of the community + do not. + + The problem is that this notion of community is a false one. The + Internet is global. The DNS is global. There is no technical + barrier that separates those inside of the community from those + outside. The ease with which information propagates across the + Internet makes it extremely likely that such domain names will + eventually find their way into clients outside of the presumed + community. The ubiquitous presence of domain names in various URI + formats, coupled with the ease of conveyance of URIs, makes such + leakage merely a matter of time. Furthermore, since the DNS is + global, and since it can only have one root [12], it becomes possible + for clients outside of the community to search and find and use such + "special" domain names. + + Indeed, this leakage is a strength of the Internet architecture, not + a weakness. It enables global access to services from any client + with a connection to the Internet. That, in turn, allows for rapid + growth in the number of customers for any particular service. + +6.3. Sub-Delegation + + Clients and users make assumptions about domains because of the + notion that there is some kind of centralized control that can + enforce those assumptions. However, the DNS is not centralized; it + + + +Rosenberg Informational [Page 10] + +RFC 4367 Name Assumptions February 2006 + + + is distributed. If a domain doesn't delegate its sub-domains and has + its records within a single zone, it is possible to maintain a + centralized policy about operation of its domain. However, once a + domain gets sufficiently large that the domain administrators begin + to delegate sub-domains to other authorities, it becomes increasingly + difficult to maintain any kind of central control on the nature of + the service provided in each sub-domain. + + Similarly, the usage of domain names with human semantic connotation + tends to lead to a registration of multiple domains in which a + particular service is to run. As an example, a service provider with + the name "example" might register and set up its services in + "example.com", "example.net", and generally example.foo for each foo + that is a valid TLD. This, like sub-delegation, results in a growth + in the number of domains over which it is difficult to maintain + centralized control. + + Not that it is not possible, since there are many examples of + successful administration of policies across sub-domains many levels + deep. However, it takes an increasing amount of effort to ensure + this result, as it requires human intervention and the creation of + process and procedure. Automated validation of adherence to policies + is very difficult to do, as there is no way to automatically verify + many policies that might be put into place. + + A less costly process for providing centralized management of + policies is to just hope that any centralized policies are being + followed, and then wait for complaints or perform random audits. + Those approaches have many problems. + + The invalidation of assumptions due to sub-delegation is discussed in + further detail in Section 4.1.3 of [8] and in Section 3.3 of [20]. + + As a result of the fragility of policy continuity across sub- + delegations, if a client or user assumes some kind of property + associated with a TLD (such as ".wifi"), it becomes increasingly more + likely with the number of sub-domains that this property will not + exist in a server identified by a particular name. For example, in + "store.chain.company.provider.wifi", there may be four levels of + delegation from ".wifi", making it quite likely that, unless the + holder of ".wifi" is working diligently, the properties that the + holder of ".wifi" wishes to enforce are not present. These + properties may not be present due to human error or due to a willful + decision not to adhere to them. + + + + + + + +Rosenberg Informational [Page 11] + +RFC 4367 Name Assumptions February 2006 + + +6.4. Mobility + + One of the primary value propositions of a hostname as an identifier + is its persistence. A client can change IP addresses, yet still + retain a persistent identifier used by other hosts to reach it. + Because their value derives from their persistence, hostnames tend to + move with a host not just as it changes IP addresses, but as it + changes access network providers and technologies. For this reason, + assumptions made about a host based on the presumed access network + corresponding to that hostname tend to be wrong over time. As an + example, a PC might normally be connected to its broadband provider, + and through dynamic DNS have a hostname within the domain of that + provider. However, one cannot assume that any host within that + network has access over a broadband link; the user could connect + their PC over a low-bandwidth wireless access network and still + retain its domain name. + +6.5. Human Error + + Of course, human error can be the source of errors in any system, and + the same is true here. There are many examples relevant to the + problem under discussion. + + A client implementation may make the assumption that, just because a + DNS SRV record exists for a particular protocol in a particular + domain, indicating that the service is available on some port, that + the service is, in fact, running there. This assumption could be + wrong because the SRV records haven't been updated by the system + administrators to reflect the services currently running. As another + example, a client might assume that a particular domain policy + applies to all sub-domains. However, a system administrator might + have omitted to apply the policy to servers running in one of those + sub-domains. + +7. Recommendations + + Based on these problems, the clear conclusion is that clients, + servers, and users should not make assumptions on the nature of the + service provided to, or by, a domain. More specifically, however, + the following can be said: + + Follow the specifications: When specifications define mandatory + baseline procedures and formats, those should be implemented and + supported, even if the expectation is that optional procedures + will most often be used. For example, if a specification mandates + a particular baseline authentication technique, but allows others + to be negotiated and used, implementations need to implement the + baseline authentication algorithm even if the other ones are used + + + +Rosenberg Informational [Page 12] + +RFC 4367 Name Assumptions February 2006 + + + most of the time. Put more simply, the behavior of the protocol + machinery should never change based on the domain name of the + host. + + Use capability negotiation: Many protocols are engineered with + capability negotiation mechanisms. For example, a content + negotiation framework has been defined for protocols using MIME + content [13] [14] [15]. SIP allows for clients to negotiate the + media types used in the multimedia session, as well as protocol + parameters. HTTP allows for clients to negotiate the media types + returned in requests for content. When such features are + available in a protocol, client and servers should make use of + them rather than making assumptions about supported capabilities. + A corollary is that protocol designers should include such + mechanisms when evolution is expected in the usage of the + protocol. + + "Be liberal in what you accept, and conservative in what you send" + [18]: This axiom of Internet protocol design is applicable here + as well. Implementations should be prepared for the full breadth + of what a protocol allows another entity to send, rather than be + limiting in what it is willing to receive. + + To summarize -- there is never a need to make assumptions. Rather + than doing so, utilize the specifications and the negotiation + capabilities they provide, and the overall system will be robust and + interoperable. + +8. A Note on RFC 2219 and RFC 2782 + + Based on the definition of an assumption given here, the behavior + hinted at by records in the DNS also represents an assumption. RFC + 2219 [19] defines well-known aliases that can be used to construct + domain names for reaching various well-known services in a domain. + This approach was later followed by the definition of a new resource + record, the SRV record [2], which specifies that a particular service + is running on a server in a domain. Although both of these + mechanisms are useful as a hint that a particular service is running + in a domain, both of them represent assumptions that may be false. + However, they differ in the set of reasons why those assumptions + might be false. + + A client that assumes that "ftp.example.com" is an FTP server may be + wrong because the presumed naming convention in RFC 2219 was not + known by, or not followed by, the owner of domain.com. With RFC + 2782, an SRV record for a particular service would be present only by + explicit choice of the domain administrator, and thus a client that + + + + +Rosenberg Informational [Page 13] + +RFC 4367 Name Assumptions February 2006 + + + assumes that the corresponding host provides this service would be + wrong only because of human error in configuration. In this case, + the assumption is less likely to be wrong, but it certainly can be. + + The only way to determine with certainty that a service is running on + a host is to initiate a connection to the port for that service, and + check. Implementations need to be careful not to codify any + behaviors that cause failures should the information provided in the + record actually be false. This borders on common sense for robust + implementations, but it is valuable to raise this point explicitly. + +9. Security Considerations + + One of the assumptions that can be made by clients or servers is the + availability and usage (or lack thereof) of certain security + protocols and algorithms. For example, a client accessing a service + in a particular domain might assume a specific authentication + algorithm or hash function in the application protocol. It is + possible that, over time, weaknesses are found in such a technique, + requiring usage of a different mechanism. Similarly, a system might + start with an insecure mechanism, and then decide later on to use a + secure one. In either case, assumptions made on security properties + can result in interoperability failures, or worse yet, providing + service in an insecure way, even though the client asked for, and + thought it would get, secure service. These kinds of assumptions are + fundamentally unsound even if the records themselves are secured with + DNSSEC. + +10. Acknowledgements + + The IAB would like to thank John Klensin, Keith Moore and Peter Koch + for their comments. + +11. IAB Members + + Internet Architecture Board members at the time of writing of this + document are: + + Bernard Aboba + + Loa Andersson + + Brian Carpenter + + Leslie Daigle + + Patrik Faltstrom + + + + +Rosenberg Informational [Page 14] + +RFC 4367 Name Assumptions February 2006 + + + Bob Hinden + + Kurtis Lindqvist + + David Meyer + + Pekka Nikander + + Eric Rescorla + + Pete Resnick + + Jonathan Rosenberg + +12. Informative References + + [1] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [2] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + Three: The Domain Name System (DNS) Database", RFC 3403, + October 2002. + + [4] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means + for Expressing Location Information in the Domain Name System", + RFC 1876, January 1996. + + [5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., + Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- + HTTP/1.1", RFC 2616, June 1999. + + [6] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming + Protocol (RTSP)", RFC 2326, April 1998. + + [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, June 2002. + + [8] Eastlake, D., ".sex Considered Dangerous", RFC 3675, + February 2004. + + [9] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, + April 2001. + + + + +Rosenberg Informational [Page 15] + +RFC 4367 Name Assumptions February 2006 + + + [10] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer + Protocol (HTTP) Digest Authentication Using Authentication and + Key Agreement (AKA)", RFC 3310, September 2002. + + [11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message Bodies", + RFC 2045, November 1996. + + [12] Internet Architecture Board, "IAB Technical Comment on the + Unique DNS Root", RFC 2826, May 2000. + + [13] Klyne, G., "Indicating Media Features for MIME Content", + RFC 2912, September 2000. + + [14] Klyne, G., "A Syntax for Describing Media Feature Sets", + RFC 2533, March 1999. + + [15] Klyne, G., "Protocol-independent Content Negotiation + Framework", RFC 2703, September 1999. + + [16] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. + + [17] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional + Responses in Session Initiation Protocol (SIP)", RFC 3262, + June 2002. + + [18] Braden, R., "Requirements for Internet Hosts - Communication + Layers", STD 3, RFC 1122, October 1989. + + [19] Hamilton, M. and R. Wright, "Use of DNS Aliases for Network + Services", BCP 17, RFC 2219, October 1997. + + [20] Faltstrom, P., "Design Choices When Expanding DNS", Work in + Progress, June 2005. + +Author's Address + + Jonathan Rosenberg, Editor + IAB + 600 Lanidex Plaza + Parsippany, NJ 07054 + US + + Phone: +1 973 952-5000 + EMail: jdrosen@cisco.com + URI: http://www.jdrosen.net + + + + + +Rosenberg Informational [Page 16] + +RFC 4367 Name Assumptions February 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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 provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Rosenberg Informational [Page 17] + diff --git a/doc/rfc/rfc4398.txt b/doc/rfc/rfc4398.txt new file mode 100644 index 0000000..6437436 --- /dev/null +++ b/doc/rfc/rfc4398.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group S. Josefsson +Request for Comments: 4398 March 2006 +Obsoletes: 2538 +Category: Standards Track + + + 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 (2006). + +Abstract + + Cryptographic public keys are frequently published, and their + authenticity is 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). + + This document obsoletes RFC 2538. + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Standards Track [Page 1] + +RFC 4398 Storing Certificates in the DNS February 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. The CERT Resource Record ........................................3 + 2.1. Certificate Type Values ....................................4 + 2.2. Text Representation of CERT RRs ............................6 + 2.3. X.509 OIDs .................................................6 + 3. Appropriate Owner Names for CERT RRs ............................7 + 3.1. Content-Based X.509 CERT RR Names ..........................8 + 3.2. Purpose-Based X.509 CERT RR Names ..........................9 + 3.3. Content-Based OpenPGP CERT RR Names ........................9 + 3.4. Purpose-Based OpenPGP CERT RR Names .......................10 + 3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX ...........10 + 4. Performance Considerations .....................................11 + 5. Contributors ...................................................11 + 6. Acknowledgements ...............................................11 + 7. Security Considerations ........................................12 + 8. IANA Considerations ............................................12 + 9. Changes since RFC 2538 .........................................13 + 10. References ....................................................14 + 10.1. Normative References .....................................14 + 10.2. Informative References ...................................15 + Appendix A. Copying Conditions ...................................16 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Standards Track [Page 2] + +RFC 4398 Storing Certificates in the DNS February 2006 + + +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 of 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 OpenPGP + certificates/revocations used by OpenPGP software. + + Section 2 specifies a CERT resource record (RR) for the storage of + certificates in the Domain Name System [1] [2]. + + Section 3 discusses appropriate owner names for CERT RRs. + + Sections 4, 7, and 8 cover performance, security, and IANA + considerations, respectively. + + Section 9 explains the changes in this document compared to RFC 2538. + + 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 [3]. + +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 defined in Section 2.1 + below. + + The key tag field is the 16-bit value computed for the key embedded + in the certificate, using the RRSIG Key Tag algorithm described in + Appendix B of [12]. This field is used as an efficiency measure to + + + +Josefsson Standards Track [Page 3] + +RFC 4398 Storing Certificates in the DNS February 2006 + + + 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 to be examined. Note that two different + keys can have the same key tag. However, the key MUST be transformed + to the format it would have as the public key portion of a DNSKEY RR + before the key tag is computed. This is only possible if the key is + applicable to an algorithm and complies to limits (such as key size) + defined for DNS security. If it is not, the algorithm field MUST be + zero and the tag field is meaningless and SHOULD be zero. + + The algorithm field has the same meaning as the algorithm field in + DNSKEY and RRSIG RRs [12], except that a zero algorithm field + indicates that the algorithm is unknown to a secure DNS, which may + simply be the result of the algorithm not having been standardized + for DNSSEC [11]. + +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 certificate + 3 PGP OpenPGP packet + 4 IPKIX The URL of an X.509 data object + 5 ISPKI The URL of an SPKI certificate + 6 IPGP The fingerprint and URL of an OpenPGP packet + 7 ACPKIX Attribute Certificate + 8 IACPKIX The URL of an Attribute Certificate + 9-252 Available for IANA assignment + 253 URI URI private + 254 OID OID private + 255 Reserved + 256-65279 Available for IANA assignment + 65280-65534 Experimental + 65535 Reserved + + These values represent the initial content of the IANA registry; see + Section 8. + + The PKIX type is reserved to indicate an X.509 certificate conforming + to the profile defined by the IETF PKIX working group [8]. The + certificate section will start with a one-octet unsigned OID length + and then an X.500 OID indicating the nature of the remainder of the + + + + + +Josefsson Standards Track [Page 4] + +RFC 4398 Storing Certificates in the DNS February 2006 + + + certificate section (see Section 2.3, below). (NOTE: X.509 + certificates do not include their X.500 directory-type-designating + OID as a prefix.) + + The SPKI and ISPKI types are reserved to indicate the SPKI + certificate format [15], for use when the SPKI documents are moved + from experimental status. The format for these two CERT RR types + will need to be specified later. + + The PGP type indicates an OpenPGP packet as described in [5] and its + extensions and successors. This is used to transfer public key + material and revocation signatures. The data is binary and MUST NOT + be encoded into an ASCII armor. An implementation SHOULD process + transferable public keys as described in Section 10.1 of [5], but it + MAY handle additional OpenPGP packets. + + The ACPKIX type indicates an Attribute Certificate format [9]. + + The IPKIX and IACPKIX types indicate a URL that will serve the + content that would have been in the "certificate, CRL, or URL" field + of the corresponding type (PKIX or ACPKIX, respectively). + + The IPGP type contains both an OpenPGP fingerprint for the key in + question, as well as a URL. The certificate portion of the IPGP CERT + RR is defined as a one-octet fingerprint length, followed by the + OpenPGP fingerprint, followed by the URL. The OpenPGP fingerprint is + calculated as defined in RFC 2440 [5]. A zero-length fingerprint or + a zero-length URL are legal, and indicate URL-only IPGP data or + fingerprint-only IPGP data, respectively. A zero-length fingerprint + and a zero-length URL are meaningless and invalid. + + The IPKIX, ISPKI, IPGP, and IACPKIX types are known as "indirect". + These types MUST be used when the content is too large to fit in the + CERT RR and MAY be used at the implementer's discretion. They SHOULD + NOT be used where the DNS message is 512 octets or smaller and could + thus be expected to fit a UDP packet. + + 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 [10], 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 + so that, for example, subtype or version information can also be + encoded into the URI. + + + + + +Josefsson Standards Track [Page 5] + +RFC 4398 Storing Certificates in the DNS February 2006 + + + The OID private type indicates a private format certificate specified + by an ISO OID prefix. The certificate section will start with a + one-octet 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 + decimal integer or as a mnemonic symbol as listed in Section 2.1, + above. + + The key tag field is represented as an unsigned decimal integer. + + The algorithm field is represented as an unsigned decimal integer or + a mnemonic symbol as listed in [12]. + + The certificate/CRL portion is represented in base 64 [16] and may be + divided 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. However, 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: + + + + + + + + + + + +Josefsson Standards Track [Page 6] + +RFC 4398 Storing Certificates in the DNS February 2006 + + + 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 DNS names with + characters that require DNS quoting as per Section 5.1 of RFC 1035 + [2]. + + The choice of name under which CERT RRs are stored is important to + clients that perform CERT queries. In some situations, the clients + may not know all information about the CERT RR object it wishes to + retrieve. For example, a client may not know the subject name of an + X.509 certificate, or the email address of the owner of an OpenPGP + key. Further, the client might only know the hostname of a service + that uses X.509 certificates or the Key ID of an OpenPGP key. + + Therefore, two owner name guidelines are defined: content-based owner + names and purpose-based owner names. A content-based owner name is + derived from the content of the CERT RR data; for example, the + Subject field in an X.509 certificate or the User ID field in OpenPGP + keys. A purpose-based owner name is a name that a client retrieving + CERT RRs ought to know already; for example, the host name of an + X.509 protected service or the Key ID of an OpenPGP key. The + content-based and purpose-based owner name may be the same; for + example, when a client looks up a key based on the From: address of + an incoming email. + + Implementations SHOULD use the purpose-based owner name guidelines + described in this document and MAY use CNAME RRs at content-based + owner names (or other names), pointing to the purpose-based owner + name. + + + +Josefsson Standards Track [Page 7] + +RFC 4398 Storing Certificates in the DNS February 2006 + + + Note that this section describes an application-based mapping from + the name space used in a certificate to the name space used by DNS. + The DNS does not infer any relationship amongst CERT resource records + based on similarities or differences of the DNS owner name(s) of CERT + resource records. For example, if multiple labels are used when + mapping from a CERT identifier to a domain name, then care must be + taken in understanding wildcard record synthesis. + +3.1. Content-Based X.509 CERT RR Names + + Some X.509 versions, such as the PKIX profile of X.509 [8], permit + multiple names to be associated with subjects and issuers under + "Subject Alternative Name" and "Issuer Alternative Name". For + example, the PKIX profile has such Alternate Names with an ASN.1 + specification as follows: + + GeneralName ::= CHOICE { + otherName [0] OtherName, + rfc822Name [1] IA5String, + dNSName [2] IA5String, + x400Address [3] ORAddress, + directoryName [4] 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: + + 1. If a domain name is included in the identification in the + certificate or CRL, that ought to 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 ought to be used. + 3. If neither of the above is used, but a URI containing a domain + name is present, that domain name ought to be used. + 4. If none of the above is included but a character string name is + included, then it ought to be treated as described below for + OpenPGP names. + 5. If none of the above apply, then the distinguished name (DN) + ought to be mapped into a domain name as specified in [4]. + + Example 1: 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/>. The storage locations + recommended, in priority order, would be + + + +Josefsson Standards Track [Page 8] + +RFC 4398 Storing Certificates in the DNS February 2006 + + + 1. john-doe.com, + 2. www.secure.john-doe.com, and + 3. Doe.com.xy. + + Example 2: 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>". 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. Purpose-Based X.509 CERT RR Names + + Due to the difficulty for clients that do not already possess a + certificate to reconstruct the content-based owner name, + purpose-based owner names are recommended in this section. + Recommendations for purpose-based owner names vary per scenario. The + following table summarizes the purpose-based X.509 CERT RR owner name + guidelines for use with S/MIME [17], SSL/TLS [13], and IPsec [14]: + + Scenario Owner name + ------------------ ---------------------------------------------- + S/MIME Certificate Standard translation of an RFC 2822 email + address. Example: An S/MIME certificate for + "postmaster@example.org" will use a standard + hostname translation of the owner name, + "postmaster.example.org". + + TLS Certificate Hostname of the TLS server. + + IPsec Certificate Hostname of the IPsec machine and/or, for IPv4 + or IPv6 addresses, the fully qualified domain + name in the appropriate reverse domain. + + An alternate approach for IPsec is to store raw public keys [18]. + +3.3. Content-Based OpenPGP CERT RR Names + + OpenPGP signed keys (certificates) use a general character string + User ID [5]. However, it is recommended by OpenPGP that such names + include the RFC 2822 [7] email address of the party, as in "Leslie + Example <Leslie@host.example>". If such a format is used, the CERT + ought to be under the standard translation of the email address into + + + + + +Josefsson Standards Track [Page 9] + +RFC 4398 Storing Certificates in the DNS February 2006 + + + a domain name, which would be leslie.host.example in this case. If + no RFC 2822 name can be extracted from the string name, no specific + domain name is recommended. + + If a user has more than one email address, the CNAME type can be used + to reduce the amount of data stored in the DNS. For example: + + $ORIGIN example.org. + smith IN CERT PGP 0 0 <OpenPGP binary> + john.smith IN CNAME smith + js IN CNAME smith + +3.4. Purpose-Based OpenPGP CERT RR Names + + Applications that receive an OpenPGP packet containing encrypted or + signed data but do not know the email address of the sender will have + difficulties constructing the correct owner name and cannot use the + content-based owner name guidelines. However, these clients commonly + know the key fingerprint or the Key ID. The key ID is found in + OpenPGP packets, and the key fingerprint is commonly found in + auxiliary data that may be available. In this case, use of an owner + name identical to the key fingerprint and the key ID expressed in + hexadecimal [16] is recommended. For example: + + $ORIGIN example.org. + 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ... + F835EDA21E94B565716F IN CERT PGP ... + B565716F IN CERT PGP ... + + If the same key material is stored for several owner names, the use + of CNAME may help avoid data duplication. Note that CNAME is not + always applicable, because it maps one owner name to the other for + all purposes, which may be sub-optimal when two keys with the same + Key ID are stored. + +3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX + + These types are stored under the same owner names, both purpose- and + content-based, as the PKIX, SPKI, PGP, and ACPKIX types. + + + + + + + + + + + + +Josefsson Standards Track [Page 10] + +RFC 4398 Storing Certificates in the DNS February 2006 + + +4. Performance Considerations + + The Domain Name System (DNS) protocol was designed for small + transfers, typically below 512 octets. While larger transfers will + perform correctly and work is underway to make larger transfers more + efficient, it is still advisable at this time that every reasonable + effort be made to minimize the size of certificates stored within the + DNS. Steps that can be taken may include using the fewest possible + optional or extension fields and using short field values for + necessary variable-length fields. + + The RDATA field in the DNS protocol may only hold data of size 65535 + octets (64kb) or less. This means that each CERT RR MUST NOT contain + more than 64kb of payload, even if the corresponding certificate or + certificate revocation list is larger. This document addresses this + by defining "indirect" data types for each normal type. + + Deploying CERT RRs to support digitally signed email changes the + access patterns of DNS lookups from per-domain to per-user. If + digitally signed email and a key/certificate lookup based on CERT RRs + are deployed on a wide scale, this may lead to an increased DNS load, + with potential performance and cache effectiveness consequences. + Whether or not this load increase will be noticeable is not known. + +5. Contributors + + The majority of this document is copied verbatim from RFC 2538, by + Donald Eastlake 3rd and Olafur Gudmundsson. + +6. Acknowledgements + + Thanks to David Shaw and Michael Graff for their contributions to + earlier works that motivated, and served as inspiration for, this + document. + + This document was improved by suggestions and comments from Olivier + Dubuisson, Scott Hollenbeck, Russ Housley, Peter Koch, Olaf M. + Kolkman, Ben Laurie, Edward Lewis, John Loughney, Allison Mankin, + Douglas Otis, Marcos Sanz, Pekka Savola, Jason Sloderbeck, Samuel + Weiler, and Florian Weimer. No doubt the list is incomplete. We + apologize to anyone we left out. + + + + + + + + + + +Josefsson Standards Track [Page 11] + +RFC 4398 Storing Certificates in the DNS February 2006 + + +7. Security Considerations + + By definition, certificates contain their own authenticating + signatures. 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. + + If an organization chooses to issue certificates for its employees, + placing CERT RRs in the DNS by owner name, and if DNSSEC (with NSEC) + is in use, it is possible for someone to enumerate all employees of + the organization. This is usually not considered desirable, for the + same reason that enterprise phone listings are not often publicly + published and are even marked confidential. + + Using the URI type introduces another level of indirection that may + open a new vulnerability. One method of securing that indirection is + to include a hash of the certificate in the URI itself. + + If DNSSEC is used, then the non-existence of a CERT RR and, + consequently, certificates or revocation lists can be securely + asserted. Without DNSSEC, this is not possible. + +8. IANA Considerations + + The IANA has created a new registry for CERT RR: certificate types. + The initial contents of this registry is: + + Decimal Type Meaning Reference + ------- ---- ------- --------- + 0 Reserved RFC 4398 + 1 PKIX X.509 as per PKIX RFC 4398 + 2 SPKI SPKI certificate RFC 4398 + 3 PGP OpenPGP packet RFC 4398 + 4 IPKIX The URL of an X.509 data object RFC 4398 + 5 ISPKI The URL of an SPKI certificate RFC 4398 + 6 IPGP The fingerprint and URL RFC 4398 + of an OpenPGP packet + 7 ACPKIX Attribute Certificate RFC 4398 + 8 IACPKIX The URL of an Attribute RFC 4398 + Certificate + + + +Josefsson Standards Track [Page 12] + +RFC 4398 Storing Certificates in the DNS February 2006 + + + 9-252 Available for IANA assignment + by IETF Standards action + 253 URI URI private RFC 4398 + 254 OID OID private RFC 4398 + 255 Reserved RFC 4398 + 256-65279 Available for IANA assignment + by IETF Consensus + 65280-65534 Experimental RFC 4398 + 65535 Reserved RFC 4398 + + Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can + only be assigned by an IETF standards action [6]. This document + assigns 0x0001 through 0x0008 and 0x00FD and 0x00FE. Certificate + types 0x0100 through 0xFEFF are assigned through IETF Consensus [6] + based on RFC documentation of the certificate type. The availability + of private types under 0x00FD and 0x00FE ought to satisfy most + requirements for proprietary or private types. + + The CERT RR reuses the DNS Security Algorithm Numbers registry. In + particular, the CERT RR requires that algorithm number 0 remain + reserved, as described in Section 2. The IANA will reference the + CERT RR as a user of this registry and value 0, in particular. + +9. Changes since RFC 2538 + + 1. Editorial changes to conform with new document requirements, + including splitting reference section into two parts and + updating the references to point at latest versions, and to add + some additional references. + 2. Improve terminology. For example replace "PGP" with "OpenPGP", + to align with RFC 2440. + 3. In Section 2.1, clarify that OpenPGP public key data are binary, + not the ASCII armored format, and reference 10.1 in RFC 2440 on + how to deal with OpenPGP keys, and acknowledge that + implementations may handle additional packet types. + 4. Clarify that integers in the representation format are decimal. + 5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis + terminology. Improve reference for Key Tag Algorithm + calculations. + 6. Add examples that suggest use of CNAME to reduce bandwidth. + 7. In Section 3, appended the last paragraphs that discuss + "content-based" vs "purpose-based" owner names. Add Section 3.2 + for purpose-based X.509 CERT owner names, and Section 3.4 for + purpose-based OpenPGP CERT owner names. + 8. Added size considerations. + 9. The SPKI types has been reserved, until RFC 2692/2693 is moved + from the experimental status. + 10. Added indirect types IPKIX, ISPKI, IPGP, and IACPKIX. + + + +Josefsson Standards Track [Page 13] + +RFC 4398 Storing Certificates in the DNS February 2006 + + + 11. An IANA registry of CERT type values was created. + +10. References + +10.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] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri, + "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, + January 1998. + + [5] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, + "OpenPGP Message Format", RFC 2440, November 1998. + + [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [7] Resnick, P., "Internet Message Format", RFC 2822, April 2001. + + [8] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 + Public Key Infrastructure Certificate and Certificate + Revocation List (CRL) Profile", RFC 3280, April 2002. + + [9] Farrell, S. and R. Housley, "An Internet Attribute Certificate + Profile for Authorization", RFC 3281, April 2002. + + [10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, + January 2005. + + [11] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [12] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + + + + +Josefsson Standards Track [Page 14] + +RFC 4398 Storing Certificates in the DNS February 2006 + + +10.2. Informative References + + [13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + [14] Kent, S. and K. Seo, "Security Architecture for the Internet + Protocol", RFC 4301, December 2005. + + [15] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., + and T. Ylonen, "SPKI Certificate Theory", RFC 2693, + September 1999. + + [16] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", + RFC 3548, July 2003. + + [17] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions + (S/MIME) Version 3.1 Message Specification", RFC 3851, + July 2004. + + [18] Richardson, M., "A Method for Storing IPsec Keying Material in + DNS", RFC 4025, March 2005. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Standards Track [Page 15] + +RFC 4398 Storing Certificates in the DNS February 2006 + + +Appendix A. Copying Conditions + + Regarding the portion of this document that was written by Simon + Josefsson ("the author", for the remainder of this section), 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. + +Author's Address + + Simon Josefsson + + EMail: simon@josefsson.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Standards Track [Page 16] + +RFC 4398 Storing Certificates in the DNS February 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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 provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Josefsson Standards Track [Page 17] + diff --git a/doc/rfc/rfc4408.txt b/doc/rfc/rfc4408.txt new file mode 100644 index 0000000..bc1b3f5 --- /dev/null +++ b/doc/rfc/rfc4408.txt @@ -0,0 +1,2691 @@ + + + + + + +Network Working Group M. Wong +Request for Comments: 4408 W. Schlitt +Category: Experimental April 2006 + + + Sender Policy Framework (SPF) for + Authorizing Use of Domains in E-Mail, Version 1 + +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 (2006). + +IESG Note + + The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) + are published simultaneously as Experimental RFCs, although there is + no general technical consensus and efforts to reconcile the two + approaches have failed. As such, these documents have not received + full IETF review and are published "AS-IS" to document the different + approaches as they were considered in the MARID working group. + + The IESG takes no position about which approach is to be preferred + and cautions the reader that there are serious open issues for each + approach and concerns about using them in tandem. The IESG believes + that documenting the different approaches does less harm than not + documenting them. + + Note that the Sender ID experiment may use DNS records that may have + been created for the current SPF experiment or earlier versions in + this set of experiments. Depending on the content of the record, + this may mean that Sender-ID heuristics would be applied incorrectly + to a message. Depending on the actions associated by the recipient + with those heuristics, the message may not be delivered or may be + discarded on receipt. + + Participants relying on Sender ID experiment DNS records are warned + that they may lose valid messages in this set of circumstances. + aParticipants publishing SPF experiment DNS records should consider + the advice given in section 3.4 of RFC 4406 and may wish to publish + both v=spf1 and spf2.0 records to avoid the conflict. + + + + +Wong & Schlitt Experimental [Page 1] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + Participants in the Sender-ID experiment need to be aware that the + way Resent-* header fields are used will result in failure to receive + legitimate email when interacting with standards-compliant systems + (specifically automatic forwarders which comply with the standards by + not adding Resent-* headers, and systems which comply with RFC 822 + but have not yet implemented RFC 2822 Resent-* semantics). It would + be inappropriate to advance Sender-ID on the standards track without + resolving this interoperability problem. + + The community is invited to observe the success or failure of the two + approaches during the two years following publication, in order that + a community consensus can be reached in the future. + +Abstract + + E-mail on the Internet can be forged in a number of ways. In + particular, existing protocols place no restriction on what a sending + host can use as the reverse-path of a message or the domain given on + the SMTP HELO/EHLO commands. This document describes version 1 of + the Sender Policy Framework (SPF) protocol, whereby a domain may + explicitly authorize the hosts that are allowed to use its domain + name, and a receiving host may check such authorization. + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Protocol Status ............................................4 + 1.2. Terminology ................................................5 + 2. Operation .......................................................5 + 2.1. The HELO Identity ..........................................5 + 2.2. The MAIL FROM Identity .....................................5 + 2.3. Publishing Authorization ...................................6 + 2.4. Checking Authorization .....................................6 + 2.5. Interpreting the Result ....................................7 + 2.5.1. None ................................................8 + 2.5.2. Neutral .............................................8 + 2.5.3. Pass ................................................8 + 2.5.4. Fail ................................................8 + 2.5.5. SoftFail ............................................9 + 2.5.6. TempError ...........................................9 + 2.5.7. PermError ...........................................9 + 3. SPF Records .....................................................9 + 3.1. Publishing ................................................10 + 3.1.1. DNS Resource Record Types ..........................10 + 3.1.2. Multiple DNS Records ...............................11 + 3.1.3. Multiple Strings in a Single DNS record ............11 + 3.1.4. Record Size ........................................11 + 3.1.5. Wildcard Records ...................................11 + + + +Wong & Schlitt Experimental [Page 2] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + 4. The check_host() Function ......................................12 + 4.1. Arguments .................................................12 + 4.2. Results ...................................................13 + 4.3. Initial Processing ........................................13 + 4.4. Record Lookup .............................................13 + 4.5. Selecting Records .........................................13 + 4.6. Record Evaluation .........................................14 + 4.6.1. Term Evaluation ....................................14 + 4.6.2. Mechanisms .........................................15 + 4.6.3. Modifiers ..........................................15 + 4.7. Default Result ............................................16 + 4.8. Domain Specification ......................................16 + 5. Mechanism Definitions ..........................................16 + 5.1. "all" .....................................................17 + 5.2. "include" .................................................18 + 5.3. "a" .......................................................19 + 5.4. "mx" ......................................................20 + 5.5. "ptr" .....................................................20 + 5.6. "ip4" and "ip6" ...........................................21 + 5.7. "exists" ..................................................22 + 6. Modifier Definitions ...........................................22 + 6.1. redirect: Redirected Query ................................23 + 6.2. exp: Explanation ..........................................23 + 7. The Received-SPF Header Field ..................................25 + 8. Macros .........................................................27 + 8.1. Macro Definitions .........................................27 + 8.2. Expansion Examples ........................................30 + 9. Implications ...................................................31 + 9.1. Sending Domains ...........................................31 + 9.2. Mailing Lists .............................................32 + 9.3. Forwarding Services and Aliases ...........................32 + 9.4. Mail Services .............................................34 + 9.5. MTA Relays ................................................34 + 10. Security Considerations .......................................35 + 10.1. Processing Limits ........................................35 + 10.2. SPF-Authorized E-Mail May Contain Other False + Identities ...............................................37 + 10.3. Spoofed DNS and IP Data ..................................37 + 10.4. Cross-User Forgery .......................................37 + 10.5. Untrusted Information Sources ............................38 + 10.6. Privacy Exposure .........................................38 + 11. Contributors and Acknowledgements .............................38 + 12. IANA Considerations ...........................................39 + 12.1. The SPF DNS Record Type ..................................39 + 12.2. The Received-SPF Mail Header Field .......................39 + 13. References ....................................................39 + 13.1. Normative References .....................................39 + 13.2. Informative References ...................................40 + + + +Wong & Schlitt Experimental [Page 3] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + Appendix A. Collected ABNF .......................................42 + Appendix B. Extended Examples ....................................44 + B.1. Simple Examples ..........................................44 + B.2. Multiple Domain Example ..................................45 + B.3. DNSBL Style Example ......................................46 + B.4. Multiple Requirements Example ............................46 + +1. Introduction + + The current E-Mail infrastructure has the property that any host + injecting mail into the mail system can identify itself as any domain + name it wants. Hosts can do this at a variety of levels: in + particular, the session, the envelope, and the mail headers. + Although this feature is desirable in some circumstances, it is a + major obstacle to reducing Unsolicited Bulk E-Mail (UBE, aka spam). + Furthermore, many domain name holders are understandably concerned + about the ease with which other entities may make use of their domain + names, often with malicious intent. + + This document defines a protocol by which domain owners may authorize + hosts to use their domain name in the "MAIL FROM" or "HELO" identity. + Compliant domain holders publish Sender Policy Framework (SPF) + records specifying which hosts are permitted to use their names, and + compliant mail receivers use the published SPF records to test the + authorization of sending Mail Transfer Agents (MTAs) using a given + "HELO" or "MAIL FROM" identity during a mail transaction. + + An additional benefit to mail receivers is that after the use of an + identity is verified, local policy decisions about the mail can be + made based on the sender's domain, rather than the host's IP address. + This is advantageous because reputation of domain names is likely to + be more accurate than reputation of host IP addresses. Furthermore, + if a claimed identity fails verification, local policy can take + stronger action against such E-Mail, such as rejecting it. + +1.1. Protocol Status + + SPF has been in development since the summer of 2003 and has seen + deployment beyond the developers beginning in December 2003. The + design of SPF slowly evolved until the spring of 2004 and has since + stabilized. There have been quite a number of forms of SPF, some + written up as documents, some submitted as Internet Drafts, and many + discussed and debated in development forums. + + The goal of this document is to clearly document the protocol defined + by earlier draft specifications of SPF as used in existing + implementations. This conception of SPF is sometimes called "SPF + Classic". It is understood that particular implementations and + + + +Wong & Schlitt Experimental [Page 4] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + deployments may differ from, and build upon, this work. It is hoped + that we have nonetheless captured the common understanding of SPF + version 1. + +1.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 [RFC2119]. + + This document is concerned with the portion of a mail message + commonly called "envelope sender", "return path", "reverse path", + "bounce address", "2821 FROM", or "MAIL FROM". Since these terms are + either not well defined or often used casually, this document defines + the "MAIL FROM" identity in Section 2.2. Note that other terms that + may superficially look like the common terms, such as "reverse-path", + are used only with the defined meanings from normative documents. + +2. Operation + +2.1. The HELO Identity + + The "HELO" identity derives from either the SMTP HELO or EHLO command + (see [RFC2821]). These commands supply the SMTP client (sending + host) for the SMTP session. Note that requirements for the domain + presented in the EHLO or HELO command are not always clear to the + sending party, and SPF clients must be prepared for the "HELO" + identity to be malformed or an IP address literal. At the time of + this writing, many legitimate E-Mails are delivered with invalid HELO + domains. + + It is RECOMMENDED that SPF clients not only check the "MAIL FROM" + identity, but also separately check the "HELO" identity by applying + the check_host() function (Section 4) to the "HELO" identity as the + <sender>. + +2.2. The MAIL FROM Identity + + The "MAIL FROM" identity derives from the SMTP MAIL command (see + [RFC2821]). This command supplies the "reverse-path" for a message, + which generally consists of the sender mailbox, and is the mailbox to + which notification messages are to be sent if there are problems + delivering the message. + + [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in + RFC 2821). In this case, there is no explicit sender mailbox, and + such a message can be assumed to be a notification message from the + mail system itself. When the reverse-path is null, this document + + + +Wong & Schlitt Experimental [Page 5] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + defines the "MAIL FROM" identity to be the mailbox composed of the + localpart "postmaster" and the "HELO" identity (which may or may not + have been checked separately before). + + SPF clients MUST check the "MAIL FROM" identity. SPF clients check + the "MAIL FROM" identity by applying the check_host() function to the + "MAIL FROM" identity as the <sender>. + +2.3. Publishing Authorization + + An SPF-compliant domain MUST publish a valid SPF record as described + in Section 3. This record authorizes the use of the domain name in + the "HELO" and "MAIL FROM" identities by the MTAs it specifies. + + If domain owners choose to publish SPF records, it is RECOMMENDED + that they end in "-all", or redirect to other records that do, so + that a definitive determination of authorization can be made. + + Domain holders may publish SPF records that explicitly authorize no + hosts if mail should never originate using that domain. + + When changing SPF records, care must be taken to ensure that there is + a transition period so that the old policy remains valid until all + legitimate E-Mail has been checked. + +2.4. Checking Authorization + + A mail receiver can perform a set of SPF checks for each mail message + it receives. An SPF check tests the authorization of a client host + to emit mail with a given identity. Typically, such checks are done + by a receiving MTA, but can be performed elsewhere in the mail + processing chain so long as the required information is available and + reliable. At least the "MAIL FROM" identity MUST be checked, but it + is RECOMMENDED that the "HELO" identity also be checked beforehand. + + Without explicit approval of the domain owner, checking other + identities against SPF version 1 records is NOT RECOMMENDED because + there are cases that are known to give incorrect results. For + example, almost all mailing lists rewrite the "MAIL FROM" identity + (see Section 9.2), but some do not change any other identities in the + message. The scenario described in Section 9.3, sub-section 1.2, is + another example. Documents that define other identities should + define the method for explicit approval. + + It is possible that mail receivers will use the SPF check as part of + a larger set of tests on incoming mail. The results of other tests + may influence whether or not a particular SPF check is performed. + For example, finding the sending host's IP address on a local white + + + +Wong & Schlitt Experimental [Page 6] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + list may cause all other tests to be skipped and all mail from that + host to be accepted. + + When a mail receiver decides to perform an SPF check, it MUST use a + correctly-implemented check_host() function (Section 4) evaluated + with the correct parameters. Although the test as a whole is + optional, once it has been decided to perform a test it must be + performed as specified so that the correct semantics are preserved + between publisher and receiver. + + To make the test, the mail receiver MUST evaluate the check_host() + function with the arguments set as follows: + + <ip> - the IP address of the SMTP client that is emitting the + mail, either IPv4 or IPv6. + + <domain> - the domain portion of the "MAIL FROM" or "HELO" identity. + + <sender> - the "MAIL FROM" or "HELO" identity. + + Note that the <domain> argument may not be a well-formed domain name. + For example, if the reverse-path was null, then the EHLO/HELO domain + is used, with its associated problems (see Section 2.1). In these + cases, check_host() is defined in Section 4.3 to return a "None" + result. + + Although invalid, malformed, or non-existent domains cause SPF checks + to return "None" because no SPF record can be found, it has long been + the policy of many MTAs to reject E-Mail from such domains, + especially in the case of invalid "MAIL FROM". In order to prevent + the circumvention of SPF records, rejecting E-Mail from invalid + domains should be considered. + + Implementations must take care to correctly extract the <domain> from + the data given with the SMTP MAIL FROM command as many MTAs will + still accept such things as source routes (see [RFC2821], Appendix + C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). + These archaic features have been maliciously used to bypass security + systems. + +2.5. Interpreting the Result + + This section describes how software that performs the authorization + should interpret the results of the check_host() function. The + authorization check SHOULD be performed during the processing of the + SMTP transaction that sends the mail. This allows errors to be + returned directly to the sending MTA by way of SMTP replies. + + + + +Wong & Schlitt Experimental [Page 7] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + Performing the authorization after the SMTP transaction has finished + may cause problems, such as the following: (1) It may be difficult to + accurately extract the required information from potentially + deceptive headers; (2) legitimate E-Mail may fail because the + sender's policy may have since changed. + + Generating non-delivery notifications to forged identities that have + failed the authorization check is generally abusive and against the + explicit wishes of the identity owner. + +2.5.1. None + + A result of "None" means that no records were published by the domain + or that no checkable sender domain could be determined from the given + identity. The checking software cannot ascertain whether or not the + client host is authorized. + +2.5.2. Neutral + + The domain owner has explicitly stated that he cannot or does not + want to assert whether or not the IP address is authorized. A + "Neutral" result MUST be treated exactly like the "None" result; the + distinction exists only for informational purposes. Treating + "Neutral" more harshly than "None" would discourage domain owners + from testing the use of SPF records (see Section 9.1). + +2.5.3. Pass + + A "Pass" result means that the client is authorized to inject mail + with the given identity. The domain can now, in the sense of + reputation, be considered responsible for sending the message. + Further policy checks can now proceed with confidence in the + legitimate use of the identity. + +2.5.4. Fail + + A "Fail" result is an explicit statement that the client is not + authorized to use the domain in the given identity. The checking + software can choose to mark the mail based on this or to reject the + mail outright. + + If the checking software chooses to reject the mail during the SMTP + transaction, then it SHOULD use an SMTP reply code of 550 (see + [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification + (DSN) code (see [RFC3464]), in addition to an appropriate reply text. + The check_host() function may return either a default explanation + string or one from the domain that published the SPF records (see + Section 6.2). If the information does not originate with the + + + +Wong & Schlitt Experimental [Page 8] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + checking software, it should be made clear that the text is provided + by the sender's domain. For example: + + 550-5.7.1 SPF MAIL FROM check failed: + 550-5.7.1 The domain example.com explains: + 550 5.7.1 Please see http://www.example.com/mailpolicy.html + +2.5.5. SoftFail + + A "SoftFail" result should be treated as somewhere between a "Fail" + and a "Neutral". The domain believes the host is not authorized but + is not willing to make that strong of a statement. Receiving + software SHOULD NOT reject the message based solely on this result, + but MAY subject the message to closer scrutiny than normal. + + The domain owner wants to discourage the use of this host and thus + desires limited feedback when a "SoftFail" result occurs. For + example, the recipient's Mail User Agent (MUA) could highlight the + "SoftFail" status, or the receiving MTA could give the sender a + message using a technique called "greylisting" whereby the MTA can + issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the + first time the message is received, but accept it the second time. + +2.5.6. TempError + + A "TempError" result means that the SPF client encountered a + transient error while performing the check. Checking software can + choose to accept or temporarily reject the message. If the message + is rejected during the SMTP transaction for this reason, the software + SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN + code. + +2.5.7. PermError + + A "PermError" result means that the domain's published records could + not be correctly interpreted. This signals an error condition that + requires manual intervention to be resolved, as opposed to the + TempError result. Be aware that if the domain owner uses macros + (Section 8), it is possible that this result is due to the checked + identities having an unexpected format. + +3. SPF Records + + An SPF record is a DNS Resource Record (RR) that declares which hosts + are, and are not, authorized to use a domain name for the "HELO" and + "MAIL FROM" identities. Loosely, the record partitions all hosts + into permitted and not-permitted sets (though some hosts might fall + into neither category). + + + +Wong & Schlitt Experimental [Page 9] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + The SPF record is a single string of text. An example record is the + following: + + v=spf1 +mx a:colo.example.com/28 -all + + This record has a version of "spf1" and three directives: "+mx", + "a:colo.example.com/28" (the + is implied), and "-all". + +3.1. Publishing + + Domain owners wishing to be SPF compliant must publish SPF records + for the hosts that are used in the "MAIL FROM" and "HELO" identities. + The SPF records are placed in the DNS tree at the host name it + pertains to, not a subdomain under it, such as is done with SRV + records. This is the same whether the TXT or SPF RR type (see + Section 3.1.1) is used. + + The example above in Section 3 might be published via these lines in + a domain zone file: + + example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" + smtp-out.example.com. TXT "v=spf1 a -all" + + When publishing via TXT records, beware of other TXT records + published there for other purposes. They may cause problems with + size limits (see Section 3.1.4). + +3.1.1. DNS Resource Record Types + + This document defines a new DNS RR of type SPF, code 99. The format + of this type is identical to the TXT RR [RFC1035]. For either type, + the character content of the record is encoded as [US-ASCII]. + + It is recognized that the current practice (using a TXT record) is + not optimal, but it is necessary because there are a number of DNS + server and resolver implementations in common use that cannot handle + the new RR type. The two-record-type scheme provides a forward path + to the better solution of using an RR type reserved for this purpose. + + An SPF-compliant domain name SHOULD have SPF records of both RR + types. A compliant domain name MUST have a record of at least one + type. If a domain has records of both types, they MUST have + identical content. For example, instead of publishing just one + record as in Section 3.1 above, it is better to publish: + + example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all" + example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all" + + + + +Wong & Schlitt Experimental [Page 10] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + Example RRs in this document are shown with the TXT record type; + however, they could be published with the SPF type or with both + types. + +3.1.2. Multiple DNS Records + + A domain name MUST NOT have multiple records that would cause an + authorization check to select more than one record. See Section 4.5 + for the selection rules. + +3.1.3. Multiple Strings in a Single DNS record + + As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS + record (either TXT or SPF RR types) can be composed of more than one + string. If a published record contains multiple strings, then the + record MUST be treated as if those strings are concatenated together + without adding spaces. For example: + + IN TXT "v=spf1 .... first" "second string..." + + MUST be treated as equivalent to + + IN TXT "v=spf1 .... firstsecond string..." + + SPF or TXT records containing multiple strings are useful in + constructing records that would exceed the 255-byte maximum length of + a string within a single TXT or SPF RR record. + +3.1.4. Record Size + + The published SPF record for a given domain name SHOULD remain small + enough that the results of a query for it will fit within 512 octets. + This will keep even older DNS implementations from falling over to + TCP. Since the answer size is dependent on many things outside the + scope of this document, it is only possible to give this guideline: + If the combined length of the DNS name and the text of all the + records of a given type (TXT or SPF) is under 450 characters, then + DNS answers should fit in UDP packets. Note that when computing the + sizes for queries of the TXT format, one must take into account any + other TXT records published at the domain name. Records that are too + long to fit in a single UDP packet MAY be silently ignored by SPF + clients. + +3.1.5. Wildcard Records + + Use of wildcard records for publishing is not recommended. Care must + be taken if wildcard records are used. If a domain publishes + wildcard MX records, it may want to publish wildcard declarations, + + + +Wong & Schlitt Experimental [Page 11] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + subject to the same requirements and problems. In particular, the + declaration must be repeated for any host that has any RR records at + all, and for subdomains thereof. For example, the example given in + [RFC1034], Section 4.3.3, could be extended with the following: + + X.COM. MX 10 A.X.COM + X.COM. TXT "v=spf1 a:A.X.COM -all" + + *.X.COM. MX 10 A.X.COM + *.X.COM. TXT "v=spf1 a:A.X.COM -all" + + A.X.COM. A 1.2.3.4 + A.X.COM. MX 10 A.X.COM + A.X.COM. TXT "v=spf1 a:A.X.COM -all" + + *.A.X.COM. MX 10 A.X.COM + *.A.X.COM. TXT "v=spf1 a:A.X.COM -all" + + Notice that SPF records must be repeated twice for every name within + the domain: once for the name, and once with a wildcard to cover the + tree under the name. + + Use of wildcards is discouraged in general as they cause every name + under the domain to exist and queries against arbitrary names will + never return RCODE 3 (Name Error). + +4. The check_host() Function + + The check_host() function fetches SPF records, parses them, and + interprets them to determine whether a particular host is or is not + permitted to send mail with a given identity. Mail receivers that + perform this check MUST correctly evaluate the check_host() function + as described here. + + Implementations MAY use a different algorithm than the canonical + algorithm defined here, so long as the results are the same in all + cases. + +4.1. Arguments + + The check_host() function takes these arguments: + + <ip> - the IP address of the SMTP client that is emitting the + mail, either IPv4 or IPv6. + + <domain> - the domain that provides the sought-after authorization + information; initially, the domain portion of the "MAIL + FROM" or "HELO" identity. + + + +Wong & Schlitt Experimental [Page 12] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + <sender> - the "MAIL FROM" or "HELO" identity. + + The domain portion of <sender> will usually be the same as the + <domain> argument when check_host() is initially evaluated. However, + this will generally not be true for recursive evaluations (see + Section 5.2 below). + + Actual implementations of the check_host() function may need + additional arguments. + +4.2. Results + + The function check_host() can return one of several results described + in Section 2.5. Based on the result, the action to be taken is + determined by the local policies of the receiver. + +4.3. Initial Processing + + If the <domain> is malformed (label longer than 63 characters, zero- + length label not at the end, etc.) or is not a fully qualified domain + name, or if the DNS lookup returns "domain does not exist" (RCODE 3), + check_host() immediately returns the result "None". + + If the <sender> has no localpart, substitute the string "postmaster" + for the localpart. + +4.4. Record Lookup + + In accordance with how the records are published (see Section 3.1 + above), a DNS query needs to be made for the <domain> name, querying + for either RR type TXT, SPF, or both. If both SPF and TXT RRs are + looked up, the queries MAY be done in parallel. + + If all DNS lookups that are made return a server failure (RCODE 2), + or other error (RCODE other than 0 or 3), or time out, then + check_host() exits immediately with the result "TempError". + +4.5. Selecting Records + + Records begin with a version section: + + record = version terms *SP + version = "v=spf1" + + Starting with the set of records that were returned by the lookup, + record selection proceeds in two steps: + + + + + +Wong & Schlitt Experimental [Page 13] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + 1. Records that do not begin with a version section of exactly + "v=spf1" are discarded. Note that the version section is + terminated either by an SP character or the end of the record. A + record with a version section of "v=spf10" does not match and must + be discarded. + + 2. If any records of type SPF are in the set, then all records of + type TXT are discarded. + + After the above steps, there should be exactly one record remaining + and evaluation can proceed. If there are two or more records + remaining, then check_host() exits immediately with the result of + "PermError". + + If no matching records are returned, an SPF client MUST assume that + the domain makes no SPF declarations. SPF processing MUST stop and + return "None". + +4.6. Record Evaluation + + After one SPF record has been selected, the check_host() function + parses and interprets it to find a result for the current test. If + there are any syntax errors, check_host() returns immediately with + the result "PermError". + + Implementations MAY choose to parse the entire record first and + return "PermError" if the record is not syntactically well formed. + However, in all cases, any syntax errors anywhere in the record MUST + be detected. + +4.6.1. Term Evaluation + + There are two types of terms: mechanisms and modifiers. A record + contains an ordered list of these as specified in the following + Augmented Backus-Naur Form (ABNF). + + terms = *( 1*SP ( directive / modifier ) ) + + directive = [ qualifier ] mechanism + qualifier = "+" / "-" / "?" / "~" + mechanism = ( all / include + / A / MX / PTR / IP4 / IP6 / exists ) + modifier = redirect / explanation / unknown-modifier + unknown-modifier = name "=" macro-string + + name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) + + Most mechanisms allow a ":" or "/" character after the name. + + + +Wong & Schlitt Experimental [Page 14] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + Modifiers always contain an equals ('=') character immediately after + the name, and before any ":" or "/" characters that may be part of + the macro-string. + + Terms that do not contain any of "=", ":", or "/" are mechanisms, as + defined in Section 5. + + As per the definition of the ABNF notation in [RFC4234], mechanism + and modifier names are case-insensitive. + +4.6.2. Mechanisms + + Each mechanism is considered in turn from left to right. If there + are no more mechanisms, the result is specified in Section 4.7. + + When a mechanism is evaluated, one of three things can happen: it can + match, not match, or throw an exception. + + If it matches, processing ends and the qualifier value is returned as + the result of that record. If it does not match, processing + continues with the next mechanism. If it throws an exception, + mechanism processing ends and the exception value is returned. + + The possible qualifiers, and the results they return are as follows: + + "+" Pass + "-" Fail + "~" SoftFail + "?" Neutral + + The qualifier is optional and defaults to "+". + + When a mechanism matches and the qualifier is "-", then a "Fail" + result is returned and the explanation string is computed as + described in Section 6.2. + + The specific mechanisms are described in Section 5. + +4.6.3. Modifiers + + Modifiers are not mechanisms: they do not return match or not-match. + Instead they provide additional information. Although modifiers do + not directly affect the evaluation of the record, the "redirect" + modifier has an effect after all the mechanisms have been evaluated. + + + + + + + +Wong & Schlitt Experimental [Page 15] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +4.7. Default Result + + If none of the mechanisms match and there is no "redirect" modifier, + then the check_host() returns a result of "Neutral", just as if + "?all" were specified as the last directive. If there is a + "redirect" modifier, check_host() proceeds as defined in Section 6.1. + + Note that records SHOULD always use either a "redirect" modifier or + an "all" mechanism to explicitly terminate processing. + + For example: + + v=spf1 +mx -all + or + v=spf1 +mx redirect=_spf.example.com + +4.8. Domain Specification + + Several of these mechanisms and modifiers have a <domain-spec> + section. The <domain-spec> string is macro expanded (see Section 8). + The resulting string is the common presentation form of a fully- + qualified DNS name: a series of labels separated by periods. This + domain is called the <target-name> in the rest of this document. + + Note: The result of the macro expansion is not subject to any further + escaping. Hence, this facility cannot produce all characters that + are legal in a DNS label (e.g., the control characters). However, + this facility is powerful enough to express legal host names and + common utility labels (such as "_spf") that are used in DNS. + + For several mechanisms, the <domain-spec> is optional. If it is not + provided, the <domain> is used as the <target-name>. + +5. Mechanism Definitions + + This section defines two types of mechanisms. + + Basic mechanisms contribute to the language framework. They do not + specify a particular type of authorization scheme. + + all + include + + Designated sender mechanisms are used to designate a set of <ip> + addresses as being permitted or not permitted to use the <domain> for + sending mail. + + + + + +Wong & Schlitt Experimental [Page 16] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + a + mx + ptr + ip4 + ip6 + exists + + The following conventions apply to all mechanisms that perform a + comparison between <ip> and an IP address at any point: + + If no CIDR-length is given in the directive, then <ip> and the IP + address are compared for equality. (Here, CIDR is Classless Inter- + Domain Routing.) + + If a CIDR-length is specified, then only the specified number of + high-order bits of <ip> and the IP address are compared for equality. + + When any mechanism fetches host addresses to compare with <ip>, when + <ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6 + address, AAAA records are fetched. Even if the SMTP connection is + via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section + 2.5.5) MUST still be considered an IPv4 address. + + Several mechanisms rely on information fetched from DNS. For these + DNS queries, except where noted, if the DNS server returns an error + (RCODE other than 0 or 3) or the query times out, the mechanism + throws the exception "TempError". If the server returns "domain does + not exist" (RCODE 3), then evaluation of the mechanism continues as + if the server returned no error (RCODE 0) and zero answer records. + +5.1. "all" + + all = "all" + + The "all" mechanism is a test that always matches. It is used as the + rightmost mechanism in a record to provide an explicit default. + + For example: + + v=spf1 a mx -all + + Mechanisms after "all" will never be tested. Any "redirect" modifier + (Section 6.1) has no effect when there is an "all" mechanism. + + + + + + + + +Wong & Schlitt Experimental [Page 17] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +5.2. "include" + + include = "include" ":" domain-spec + + The "include" mechanism triggers a recursive evaluation of + check_host(). The domain-spec is expanded as per Section 8. Then + check_host() is evaluated with the resulting string as the <domain>. + The <ip> and <sender> arguments remain the same as in the current + evaluation of check_host(). + + In hindsight, the name "include" was poorly chosen. Only the + evaluated result of the referenced SPF record is used, rather than + acting as if the referenced SPF record was literally included in the + first. For example, evaluating a "-all" directive in the referenced + record does not terminate the overall processing and does not + necessarily result in an overall "Fail". (Better names for this + mechanism would have been "if-pass", "on-pass", etc.) + + The "include" mechanism makes it possible for one domain to designate + multiple administratively-independent domains. For example, a vanity + domain "example.net" might send mail using the servers of + administratively-independent domains example.com and example.org. + + Example.net could say + + IN TXT "v=spf1 include:example.com include:example.org -all" + + This would direct check_host() to, in effect, check the records of + example.com and example.org for a "Pass" result. Only if the host + were not permitted for either of those domains would the result be + "Fail". + + + + + + + + + + + + + + + + + + + + +Wong & Schlitt Experimental [Page 18] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + Whether this mechanism matches, does not match, or throws an + exception depends on the result of the recursive evaluation of + check_host(): + + +---------------------------------+---------------------------------+ + | A recursive check_host() result | Causes the "include" mechanism | + | of: | to: | + +---------------------------------+---------------------------------+ + | Pass | match | + | | | + | Fail | not match | + | | | + | SoftFail | not match | + | | | + | Neutral | not match | + | | | + | TempError | throw TempError | + | | | + | PermError | throw PermError | + | | | + | None | throw PermError | + +---------------------------------+---------------------------------+ + + The "include" mechanism is intended for crossing administrative + boundaries. Although it is possible to use includes to consolidate + multiple domains that share the same set of designated hosts, domains + are encouraged to use redirects where possible, and to minimize the + number of includes within a single administrative domain. For + example, if example.com and example.org were managed by the same + entity, and if the permitted set of hosts for both domains was + "mx:example.com", it would be possible for example.org to specify + "include:example.com", but it would be preferable to specify + "redirect=example.com" or even "mx:example.com". + +5.3. "a" + + This mechanism matches if <ip> is one of the <target-name>'s IP + addresses. + + A = "a" [ ":" domain-spec ] [ dual-cidr-length ] + + An address lookup is done on the <target-name>. The <ip> is compared + to the returned address(es). If any address matches, the mechanism + matches. + + + + + + + +Wong & Schlitt Experimental [Page 19] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +5.4. "mx" + + This mechanism matches if <ip> is one of the MX hosts for a domain + name. + + MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] + + check_host() first performs an MX lookup on the <target-name>. Then + it performs an address lookup on each MX name returned. The <ip> is + compared to each returned IP address. To prevent Denial of Service + (DoS) attacks, more than 10 MX names MUST NOT be looked up during the + evaluation of an "mx" mechanism (see Section 10). If any address + matches, the mechanism matches. + + Note regarding implicit MXs: If the <target-name> has no MX records, + check_host() MUST NOT pretend the target is its single MX, and MUST + NOT default to an A lookup on the <target-name> directly. This + behavior breaks with the legacy "implicit MX" rule. See [RFC2821], + Section 5. If such behavior is desired, the publisher should specify + an "a" directive. + +5.5. "ptr" + + This mechanism tests whether the DNS reverse-mapping for <ip> exists + and correctly points to a domain name within a particular domain. + + PTR = "ptr" [ ":" domain-spec ] + + First, the <ip>'s name is looked up using this procedure: perform a + DNS reverse-mapping for <ip>, looking up the corresponding PTR record + in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa." + if it is an IPv6 address. For each record returned, validate the + domain name by looking up its IP address. To prevent DoS attacks, + more than 10 PTR names MUST NOT be looked up during the evaluation of + a "ptr" mechanism (see Section 10). If <ip> is among the returned IP + addresses, then that domain name is validated. In pseudocode: + + sending-domain_names := ptr_lookup(sending-host_IP); if more than 10 + sending-domain_names are found, use at most 10. for each name in + (sending-domain_names) { + IP_addresses := a_lookup(name); + if the sending-domain_IP is one of the IP_addresses { + validated-sending-domain_names += name; + } } + + Check all validated domain names to see if they end in the + <target-name> domain. If any do, this mechanism matches. If no + validated domain name can be found, or if none of the validated + + + +Wong & Schlitt Experimental [Page 20] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + domain names end in the <target-name>, this mechanism fails to match. + If a DNS error occurs while doing the PTR RR lookup, then this + mechanism fails to match. If a DNS error occurs while doing an A RR + lookup, then that domain name is skipped and the search continues. + + Pseudocode: + + for each name in (validated-sending-domain_names) { + if name ends in <domain-spec>, return match. + if name is <domain-spec>, return match. + } + return no-match. + + This mechanism matches if the <target-name> is either an ancestor of + a validated domain name or if the <target-name> and a validated + domain name are the same. For example: "mail.example.com" is within + the domain "example.com", but "mail.bad-example.com" is not. + + Note: Use of this mechanism is discouraged because it is slow, it is + not as reliable as other mechanisms in cases of DNS errors, and it + places a large burden on the arpa name servers. If used, proper PTR + records must be in place for the domain's hosts and the "ptr" + mechanism should be one of the last mechanisms checked. + +5.6. "ip4" and "ip6" + + These mechanisms test whether <ip> is contained within a given IP + network. + + IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] + IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] + + ip4-cidr-length = "/" 1*DIGIT + ip6-cidr-length = "/" 1*DIGIT + dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] + + ip4-network = qnum "." qnum "." qnum "." qnum + qnum = DIGIT ; 0-9 + / %x31-39 DIGIT ; 10-99 + / "1" 2DIGIT ; 100-199 + / "2" %x30-34 DIGIT ; 200-249 + / "25" %x30-35 ; 250-255 + ; as per conventional dotted quad notation. e.g., 192.0.2.0 + ip6-network = <as per [RFC 3513], section 2.2> + ; e.g., 2001:DB8::CD30 + + The <ip> is compared to the given network. If CIDR-length high-order + bits match, the mechanism matches. + + + +Wong & Schlitt Experimental [Page 21] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + If ip4-cidr-length is omitted, it is taken to be "/32". If + ip6-cidr-length is omitted, it is taken to be "/128". It is not + permitted to omit parts of the IP address instead of using CIDR + notations. That is, use 192.0.2.0/24 instead of 192.0.2. + +5.7. "exists" + + This mechanism is used to construct an arbitrary domain name that is + used for a DNS A record query. It allows for complicated schemes + involving arbitrary parts of the mail envelope to determine what is + permitted. + + exists = "exists" ":" domain-spec + + The domain-spec is expanded as per Section 8. The resulting domain + name is used for a DNS A RR lookup. If any A record is returned, + this mechanism matches. The lookup type is A even when the + connection type is IPv6. + + Domains can use this mechanism to specify arbitrarily complex + queries. For example, suppose example.com publishes the record: + + v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all + + The <target-name> might expand to + "1.2.0.192.someuser._spf.example.com". This makes fine-grained + decisions possible at the level of the user and client IP address. + + This mechanism enables queries that mimic the style of tests that + existing anti-spam DNS blacklists (DNSBL) use. + +6. Modifier Definitions + + Modifiers are name/value pairs that provide additional information. + Modifiers always have an "=" separating the name and the value. + + The modifiers defined in this document ("redirect" and "exp") MAY + appear anywhere in the record, but SHOULD appear at the end, after + all mechanisms. Ordering of these two modifiers does not matter. + These two modifiers MUST NOT appear in a record more than once each. + If they do, then check_host() exits with a result of "PermError". + + Unrecognized modifiers MUST be ignored no matter where in a record, + or how often. This allows implementations of this document to + gracefully handle records with modifiers that are defined in other + specifications. + + + + + +Wong & Schlitt Experimental [Page 22] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +6.1. redirect: Redirected Query + + If all mechanisms fail to match, and a "redirect" modifier is + present, then processing proceeds as follows: + + redirect = "redirect" "=" domain-spec + + The domain-spec portion of the redirect section is expanded as per + the macro rules in Section 8. Then check_host() is evaluated with + the resulting string as the <domain>. The <ip> and <sender> + arguments remain the same as current evaluation of check_host(). + + The result of this new evaluation of check_host() is then considered + the result of the current evaluation with the exception that if no + SPF record is found, or if the target-name is malformed, the result + is a "PermError" rather than "None". + + Note that the newly-queried domain may itself specify redirect + processing. + + This facility is intended for use by organizations that wish to apply + the same record to multiple domains. For example: + + la.example.com. TXT "v=spf1 redirect=_spf.example.com" + ny.example.com. TXT "v=spf1 redirect=_spf.example.com" + sf.example.com. TXT "v=spf1 redirect=_spf.example.com" + _spf.example.com. TXT "v=spf1 mx:example.com -all" + + In this example, mail from any of the three domains is described by + the same record. This can be an administrative advantage. + + Note: In general, the domain "A" cannot reliably use a redirect to + another domain "B" not under the same administrative control. Since + the <sender> stays the same, there is no guarantee that the record at + domain "B" will correctly work for mailboxes in domain "A", + especially if domain "B" uses mechanisms involving localparts. An + "include" directive may be more appropriate. + + For clarity, it is RECOMMENDED that any "redirect" modifier appear as + the very last term in a record. + +6.2. exp: Explanation + + explanation = "exp" "=" domain-spec + + If check_host() results in a "Fail" due to a mechanism match (such as + "-all"), and the "exp" modifier is present, then the explanation + string returned is computed as described below. If no "exp" modifier + + + +Wong & Schlitt Experimental [Page 23] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + is present, then either a default explanation string or an empty + explanation string may be returned. + + The <domain-spec> is macro expanded (see Section 8) and becomes the + <target-name>. The DNS TXT record for the <target-name> is fetched. + + If <domain-spec> is empty, or there are any DNS processing errors + (any RCODE other than 0), or if no records are returned, or if more + than one record is returned, or if there are syntax errors in the + explanation string, then proceed as if no exp modifier was given. + + The fetched TXT record's strings are concatenated with no spaces, and + then treated as an <explain-string>, which is macro-expanded. This + final result is the explanation string. Implementations MAY limit + the length of the resulting explanation string to allow for other + protocol constraints and/or reasonable processing limits. Since the + explanation string is intended for an SMTP response and [RFC2821] + Section 2.4 says that responses are in [US-ASCII], the explanation + string is also limited to US-ASCII. + + Software evaluating check_host() can use this string to communicate + information from the publishing domain in the form of a short message + or URL. Software SHOULD make it clear that the explanation string + comes from a third party. For example, it can prepend the macro + string "%{o} explains: " to the explanation, such as shown in Section + 2.5.4. + + Suppose example.com has this record: + + v=spf1 mx -all exp=explain._spf.%{d} + + Here are some examples of possible explanation TXT records at + explain._spf.example.com: + + "Mail from example.com should only be sent by its own servers." + -- a simple, constant message + + "%{i} is not one of %{d}'s designated mail servers." + -- a message with a little more information, including the IP + address that failed the check + + "See http://%{d}/why.html?s=%{S}&i=%{I}" + -- a complicated example that constructs a URL with the + arguments to check_host() so that a web page can be + generated with detailed, custom instructions + + Note: During recursion into an "include" mechanism, an exp= modifier + from the <target-name> MUST NOT be used. In contrast, when executing + + + +Wong & Schlitt Experimental [Page 24] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + a "redirect" modifier, an exp= modifier from the original domain MUST + NOT be used. + +7. The Received-SPF Header Field + + It is RECOMMENDED that SMTP receivers record the result of SPF + processing in the message header. If an SMTP receiver chooses to do + so, it SHOULD use the "Received-SPF" header field defined here for + each identity that was checked. This information is intended for the + recipient. (Information intended for the sender is described in + Section 6.2, Explanation.) + + The Received-SPF header field is a trace field (see [RFC2822] Section + 3.6.7) and SHOULD be prepended to the existing header, above the + Received: field that is generated by the SMTP receiver. It MUST + appear above all other Received-SPF fields in the message. The + header field has the following format: + + header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] + [ key-value-list ] CRLF + + result = "Pass" / "Fail" / "SoftFail" / "Neutral" / + "None" / "TempError" / "PermError" + + key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) + [";"] + + key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) + + key = "client-ip" / "envelope-from" / "helo" / + "problem" / "receiver" / "identity" / + mechanism / "x-" name / name + + identity = "mailfrom" ; for the "MAIL FROM" identity + / "helo" ; for the "HELO" identity + / name ; other identities + + dot-atom = <unquoted word as per [RFC2822]> + quoted-string = <quoted string as per [RFC2822]> + comment = <comment string as per [RFC2822]> + CFWS = <comment or folding white space as per [RFC2822]> + FWS = <folding white space as per [RFC2822]> + CRLF = <standard end-of-line token as per [RFC2822]> + + The header field SHOULD include a "(...)" style <comment> after the + result, conveying supporting information for the result, such as + <ip>, <sender>, and <domain>. + + + + +Wong & Schlitt Experimental [Page 25] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + The following key-value pairs are designed for later machine parsing. + SPF clients SHOULD give enough information so that the SPF results + can be verified. That is, at least "client-ip", "helo", and, if the + "MAIL FROM" identity was checked, "envelope-from". + + client-ip the IP address of the SMTP client + + envelope-from the envelope sender mailbox + + helo the host name given in the HELO or EHLO command + + mechanism the mechanism that matched (if no mechanisms matched, + substitute the word "default") + + problem if an error was returned, details about the error + + receiver the host name of the SPF client + + identity the identity that was checked; see the <identity> ABNF + rule + + Other keys may be defined by SPF clients. Until a new key name + becomes widely accepted, new key names should start with "x-". + + SPF clients MUST make sure that the Received-SPF header field does + not contain invalid characters, is not excessively long, and does not + contain malicious data that has been provided by the sender. + + Examples of various header styles that could be generated are the + following: + + Received-SPF: Pass (mybox.example.org: domain of + myname@example.com designates 192.0.2.1 as permitted sender) + receiver=mybox.example.org; client-ip=192.0.2.1; + envelope-from=<myname@example.com>; helo=foo.example.com; + + Received-SPF: Fail (mybox.example.org: domain of + myname@example.com does not designate + 192.0.2.1 as permitted sender) + identity=mailfrom; client-ip=192.0.2.1; + envelope-from=<myname@example.com>; + + + + + + + + + + +Wong & Schlitt Experimental [Page 26] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +8. Macros + +8.1. Macro Definitions + + Many mechanisms and modifiers perform macro expansion on part of the + term. + + domain-spec = macro-string domain-end + domain-end = ( "." toplabel [ "." ] ) / macro-expand + + toplabel = ( *alphanum ALPHA *alphanum ) / + ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) + ; LDH rule plus additional TLD restrictions + ; (see [RFC3696], Section 2) + alphanum = ALPHA / DIGIT + + explain-string = *( macro-string / SP ) + + macro-string = *( macro-expand / macro-literal ) + macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) + / "%%" / "%_" / "%-" + macro-literal = %x21-24 / %x26-7E + ; visible characters except "%" + macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / + "c" / "r" / "t" + transformers = *DIGIT [ "r" ] + delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" + + A literal "%" is expressed by "%%". + + "%_" expands to a single " " space. + "%-" expands to a URL-encoded space, viz., "%20". + + The following macro letters are expanded in term arguments: + + s = <sender> + l = local-part of <sender> + o = domain of <sender> + d = <domain> + i = <ip> + p = the validated domain name of <ip> + v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6 + h = HELO/EHLO domain + + + + + + + + +Wong & Schlitt Experimental [Page 27] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + The following macro letters are allowed only in "exp" text: + + c = SMTP client IP (easily readable format) + r = domain name of host performing the check + t = current timestamp + + A '%' character not followed by a '{', '%', '-', or '_' character is + a syntax error. So + + -exists:%(ir).sbl.spamhaus.example.org + + is incorrect and will cause check_host() to return a "PermError". + Instead, say + + -exists:%{ir}.sbl.spamhaus.example.org + + Optional transformers are the following: + + *DIGIT = zero or more digits + 'r' = reverse value, splitting on dots by default + + If transformers or delimiters are provided, the replacement value for + a macro letter is split into parts. After performing any reversal + operation and/or removal of left-hand parts, the parts are rejoined + using "." and not the original splitting characters. + + By default, strings are split on "." (dots). Note that no special + treatment is given to leading, trailing, or consecutive delimiters, + and so the list of parts may contain empty strings. Older + implementations of SPF prohibit trailing dots in domain names, so + trailing dots should not be published by domain owners, although they + must be accepted by implementations conforming to this document. + Macros may specify delimiter characters that are used instead of ".". + + The 'r' transformer indicates a reversal operation: if the client IP + address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1" + and the macro %{ir} would expand to "1.2.0.192". + + The DIGIT transformer indicates the number of right-hand parts to + use, after optional reversal. If a DIGIT is specified, the value + MUST be nonzero. If no DIGITs are specified, or if the value + specifies more parts than are available, all the available parts are + used. If the DIGIT was 5, and only 3 parts were available, the macro + interpreter would pretend the DIGIT was 3. Implementations MUST + support at least a value of 128, as that is the maximum number of + labels in a domain name. + + + + + +Wong & Schlitt Experimental [Page 28] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + The "s" macro expands to the <sender> argument. It is an E-Mail + address with a localpart, an "@" character, and a domain. The "l" + macro expands to just the localpart. The "o" macro expands to just + the domain part. Note that these values remain the same during + recursive and chained evaluations due to "include" and/or "redirect". + Note also that if the original <sender> had no localpart, the + localpart was set to "postmaster" in initial processing (see Section + 4.3). + + For IPv4 addresses, both the "i" and "c" macros expand to the + standard dotted-quad format. + + For IPv6 addresses, the "i" macro expands to a dot-format address; it + is intended for use in %{ir}. The "c" macro may expand to any of the + hexadecimal colon-format addresses specified in [RFC3513], Section + 2.2. It is intended for humans to read. + + The "p" macro expands to the validated domain name of <ip>. The + procedure for finding the validated domain name is defined in Section + 5.5. If the <domain> is present in the list of validated domains, it + SHOULD be used. Otherwise, if a subdomain of the <domain> is + present, it SHOULD be used. Otherwise, any name from the list may be + used. If there are no validated domain names or if a DNS error + occurs, the string "unknown" is used. + + The "r" macro expands to the name of the receiving MTA. This SHOULD + be a fully qualified domain name, but if one does not exist (as when + the checking is done by a MUA) or if policy restrictions dictate + otherwise, the word "unknown" SHOULD be substituted. The domain name + may be different from the name found in the MX record that the client + MTA used to locate the receiving MTA. + + The "t" macro expands to the decimal representation of the + approximate number of seconds since the Epoch (Midnight, January 1, + 1970, UTC). This is the same value as is returned by the POSIX + time() function in most standards-compliant libraries. + + When the result of macro expansion is used in a domain name query, if + the expanded domain name exceeds 253 characters (the maximum length + of a domain name), the left side is truncated to fit, by removing + successive domain labels until the total length does not exceed 253 + characters. + + Uppercased macros expand exactly as their lowercased equivalents, and + are then URL escaped. URL escaping must be performed for characters + not in the "uric" set, which is defined in [RFC3986]. + + + + + +Wong & Schlitt Experimental [Page 29] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + Note: Care must be taken so that macro expansion for legitimate + E-Mail does not exceed the 63-character limit on DNS labels. The + localpart of E-Mail addresses, in particular, can have more than 63 + characters between dots. + + Note: Domains should avoid using the "s", "l", "o", or "h" macros in + conjunction with any mechanism directive. Although these macros are + powerful and allow per-user records to be published, they severely + limit the ability of implementations to cache results of check_host() + and they reduce the effectiveness of DNS caches. + + Implementations should be aware that if no directive processed during + the evaluation of check_host() contains an "s", "l", "o", or "h" + macro, then the results of the evaluation can be cached on the basis + of <domain> and <ip> alone for as long as the shortest Time To Live + (TTL) of all the DNS records involved. + +8.2. Expansion Examples + + The <sender> is strong-bad@email.example.com. + The IPv4 SMTP client IP is 192.0.2.3. + The IPv6 SMTP client IP is 2001:DB8::CB01. + The PTR domain name of the client IP is mx.example.org. + + macro expansion + ------- ---------------------------- + %{s} strong-bad@email.example.com + %{o} email.example.com + %{d} email.example.com + %{d4} email.example.com + %{d3} email.example.com + %{d2} example.com + %{d1} com + %{dr} com.example.email + %{d2r} example.email + %{l} strong-bad + %{l-} strong.bad + %{lr} strong-bad + %{lr-} bad.strong + %{l1r-} strong + + + + + + + + + + + +Wong & Schlitt Experimental [Page 30] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + macro-string expansion + -------------------------------------------------------------------- + %{ir}.%{v}._spf.%{d2} 3.2.0.192.in-addr._spf.example.com + %{lr-}.lp._spf.%{d2} bad.strong.lp._spf.example.com + + %{lr-}.lp.%{ir}.%{v}._spf.%{d2} + bad.strong.lp.3.2.0.192.in-addr._spf.example.com + + %{ir}.%{v}.%{l1r-}.lp._spf.%{d2} + 3.2.0.192.in-addr.strong.lp._spf.example.com + + %{d2}.trusted-domains.example.net + example.com.trusted-domains.example.net + + IPv6: + %{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0. + 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com + +9. Implications + + This section outlines the major implications that adoption of this + document will have on various entities involved in Internet E-Mail. + It is intended to make clear to the reader where this document + knowingly affects the operation of such entities. This section is + not a "how-to" manual, or a "best practices" document, and it is not + a comprehensive list of what such entities should do in light of this + document. + + This section is non-normative. + +9.1. Sending Domains + + Domains that wish to be compliant with this specification will need + to determine the list of hosts that they allow to use their domain + name in the "HELO" and "MAIL FROM" identities. It is recognized that + forming such a list is not just a simple technical exercise, but + involves policy decisions with both technical and administrative + considerations. + + It can be helpful to publish records that include a "tracking + exists:" mechanism. By looking at the name server logs, a rough list + may then be generated. For example: + + v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all + + + + + + + +Wong & Schlitt Experimental [Page 31] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +9.2. Mailing Lists + + Mailing lists must be aware of how they re-inject mail that is sent + to the list. Mailing lists MUST comply with the requirements in + [RFC2821], Section 3.10, and [RFC1123], Section 5.3.6, that say that + the reverse-path MUST be changed to be the mailbox of a person or + other entity who administers the list. Whereas the reasons for + changing the reverse-path are many and long-standing, SPF adds + enforcement to this requirement. + + In practice, almost all mailing list software in use already complies + with this requirement. Mailing lists that do not comply may or may + not encounter problems depending on how access to the list is + restricted. Such lists that are entirely internal to a domain (only + people in the domain can send to or receive from the list) are not + affected. + +9.3. Forwarding Services and Aliases + + Forwarding services take mail that is received at a mailbox and + direct it to some external mailbox. At the time of this writing, the + near-universal practice of such services is to use the original "MAIL + FROM" of a message when re-injecting it for delivery to the external + mailbox. [RFC1123] and [RFC2821] describe this action as an "alias" + rather than a "mail list". This means that the external mailbox's + MTA sees all such mail in a connection from a host of the forwarding + service, and so the "MAIL FROM" identity will not, in general, pass + authorization. + + There are three places that techniques can be used to ameliorate this + problem. + + 1. The beginning, when E-Mail is first sent. + + 1. "Neutral" results could be given for IP addresses that may be + forwarders, instead of "Fail" results. For example: + + "v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all" + + This would cause a lookup on an anti-spam DNS blacklist + (DNSBL) and cause a result of "Fail" only for E-Mail coming + from listed sources. All other E-Mail, including E-Mail sent + through forwarders, would receive a "Neutral" result. By + checking the DNSBL after the known good sources, problems with + incorrect listing on the DNSBL are greatly reduced. + + + + + + +Wong & Schlitt Experimental [Page 32] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + 2. The "MAIL FROM" identity could have additional information in + the localpart that cryptographically identifies the mail as + coming from an authorized source. In this case, such an SPF + record could be used: + + "v=spf1 mx exists:%{l}._spf_verify.%{d} -all" + + Then, a specialized DNS server can be set up to serve the + _spf_verify subdomain that validates the localpart. Although + this requires an extra DNS lookup, this happens only when the + E-Mail would otherwise be rejected as not coming from a known + good source. + + Note that due to the 63-character limit for domain labels, + this approach only works reliably if the localpart signature + scheme is guaranteed either to only produce localparts with a + maximum of 63 characters or to gracefully handle truncated + localparts. + + 3. Similarly, a specialized DNS server could be set up that will + rate-limit the E-Mail coming from unexpected IP addresses. + + "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all" + + 4. SPF allows the creation of per-user policies for special + cases. For example, the following SPF record and appropriate + wildcard DNS records can be used: + + "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}" + + 2. The middle, when E-Mail is forwarded. + + 1. Forwarding services can solve the problem by rewriting the + "MAIL FROM" to be in their own domain. This means that mail + bounced from the external mailbox will have to be re-bounced + by the forwarding service. Various schemes to do this exist + though they vary widely in complexity and resource + requirements on the part of the forwarding service. + + 2. Several popular MTAs can be forced from "alias" semantics to + "mailing list" semantics by configuring an additional alias + with "owner-" prepended to the original alias name (e.g., an + alias of "friends: george@example.com, fred@example.org" would + need another alias of the form "owner-friends: localowner"). + + + + + + + +Wong & Schlitt Experimental [Page 33] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + 3. The end, when E-Mail is received. + + 1. If the owner of the external mailbox wishes to trust the + forwarding service, he can direct the external mailbox's MTA + to skip SPF tests when the client host belongs to the + forwarding service. + + 2. Tests against other identities, such as the "HELO" identity, + may be used to override a failed test against the "MAIL FROM" + identity. + + 3. For larger domains, it may not be possible to have a complete + or accurate list of forwarding services used by the owners of + the domain's mailboxes. In such cases, whitelists of + generally-recognized forwarding services could be employed. + +9.4. Mail Services + + Service providers that offer mail services to third-party domains, + such as sending of bulk mail, may want to adjust their setup in light + of the authorization check described in this document. If the "MAIL + FROM" identity used for such E-Mail uses the domain of the service + provider, then the provider needs only to ensure that its sending + host is authorized by its own SPF record, if any. + + If the "MAIL FROM" identity does not use the mail service provider's + domain, then extra care must be taken. The SPF record format has + several options for the third-party domain to authorize the service + provider's MTAs to send mail on its behalf. For mail service + providers, such as ISPs, that have a wide variety of customers using + the same MTA, steps should be taken to prevent cross-customer forgery + (see Section 10.4). + +9.5. MTA Relays + + The authorization check generally precludes the use of arbitrary MTA + relays between sender and receiver of an E-Mail message. + + Within an organization, MTA relays can be effectively deployed. + However, for purposes of this document, such relays are effectively + transparent. The SPF authorization check is a check between border + MTAs of different domains. + + For mail senders, this means that published SPF records must + authorize any MTAs that actually send across the Internet. Usually, + these are just the border MTAs as internal MTAs simply forward mail + to these MTAs for delivery. + + + + +Wong & Schlitt Experimental [Page 34] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + Mail receivers will generally want to perform the authorization check + at the border MTAs, specifically including all secondary MXs. This + allows mail that fails to be rejected during the SMTP session rather + than bounced. Internal MTAs then do not perform the authorization + test. To perform the authorization test other than at the border, + the host that first transferred the message to the organization must + be determined, which can be difficult to extract from the message + header. Testing other than at the border is not recommended. + +10. Security Considerations + +10.1. Processing Limits + + As with most aspects of E-Mail, there are a number of ways that + malicious parties could use the protocol as an avenue for a + Denial-of-Service (DoS) attack. The processing limits outlined here + are designed to prevent attacks such as the following: + + o A malicious party could create an SPF record with many references + to a victim's domain and send many E-Mails to different SPF + clients; those SPF clients would then create a DoS attack. In + effect, the SPF clients are being used to amplify the attacker's + bandwidth by using fewer bytes in the SMTP session than are used + by the DNS queries. Using SPF clients also allows the attacker to + hide the true source of the attack. + + o Whereas implementations of check_host() are supposed to limit the + number of DNS lookups, malicious domains could publish records + that exceed these limits in an attempt to waste computation effort + at their targets when they send them mail. Malicious domains + could also design SPF records that cause particular + implementations to use excessive memory or CPU usage, or to + trigger bugs. + + o Malicious parties could send a large volume of mail purporting to + come from the intended target to a wide variety of legitimate mail + hosts. These legitimate machines would then present a DNS load on + the target as they fetched the relevant records. + + Of these, the case of a third party referenced in the SPF record is + the easiest for a DoS attack to effectively exploit. As a result, + limits that may seem reasonable for an individual mail server can + still allow an unreasonable amount of bandwidth amplification. + Therefore, the processing limits need to be quite low. + + SPF implementations MUST limit the number of mechanisms and modifiers + that do DNS lookups to at most 10 per SPF check, including any + lookups caused by the use of the "include" mechanism or the + + + +Wong & Schlitt Experimental [Page 35] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + "redirect" modifier. If this number is exceeded during a check, a + PermError MUST be returned. The "include", "a", "mx", "ptr", and + "exists" mechanisms as well as the "redirect" modifier do count + against this limit. The "all", "ip4", and "ip6" mechanisms do not + require DNS lookups and therefore do not count against this limit. + The "exp" modifier does not count against this limit because the DNS + lookup to fetch the explanation string occurs after the SPF record + has been evaluated. + + When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, + there MUST be a limit of no more than 10 MX or PTR RRs looked up and + checked. + + SPF implementations SHOULD limit the total amount of data obtained + from the DNS queries. For example, when DNS over TCP or EDNS0 are + available, there may need to be an explicit limit to how much data + will be accepted to prevent excessive bandwidth usage or memory usage + and DoS attacks. + + MTAs or other processors MAY also impose a limit on the maximum + amount of elapsed time to evaluate check_host(). Such a limit SHOULD + allow at least 20 seconds. If such a limit is exceeded, the result + of authorization SHOULD be "TempError". + + Domains publishing records SHOULD try to keep the number of "include" + mechanisms and chained "redirect" modifiers to a minimum. Domains + SHOULD also try to minimize the amount of other DNS information + needed to evaluate a record. This can be done by choosing directives + that require less DNS information and placing lower-cost mechanisms + earlier in the SPF record. + + For example, consider a domain set up as follows: + + example.com. IN MX 10 mx.example.com. + mx.example.com. IN A 192.0.2.1 + a.example.com. IN TXT "v=spf1 mx:example.com -all" + b.example.com. IN TXT "v=spf1 a:mx.example.com -all" + c.example.com. IN TXT "v=spf1 ip4:192.0.2.1 -all" + + Evaluating check_host() for the domain "a.example.com" requires the + MX records for "example.com", and then the A records for the listed + hosts. Evaluating for "b.example.com" requires only the A records. + Evaluating for "c.example.com" requires none. + + However, there may be administrative considerations: using "a" over + "ip4" allows hosts to be renumbered easily. Using "mx" over "a" + allows the set of mail hosts to be changed easily. + + + + +Wong & Schlitt Experimental [Page 36] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +10.2. SPF-Authorized E-Mail May Contain Other False Identities + + The "MAIL FROM" and "HELO" identity authorizations must not be + construed to provide more assurance than they do. It is entirely + possible for a malicious sender to inject a message using his own + domain in the identities used by SPF, to have that domain's SPF + record authorize the sending host, and yet the message can easily + list other identities in its header. Unless the user or the MUA + takes care to note that the authorized identity does not match the + other more commonly-presented identities (such as the From: header + field), the user may be lulled into a false sense of security. + +10.3. Spoofed DNS and IP Data + + There are two aspects of this protocol that malicious parties could + exploit to undermine the validity of the check_host() function: + + o The evaluation of check_host() relies heavily on DNS. A malicious + attacker could attack the DNS infrastructure and cause + check_host() to see spoofed DNS data, and then return incorrect + results. This could include returning "Pass" for an <ip> value + where the actual domain's record would evaluate to "Fail". See + [RFC3833] for a description of DNS weaknesses. + + o The client IP address, <ip>, is assumed to be correct. A + malicious attacker could spoof TCP sequence numbers to make mail + appear to come from a permitted host for a domain that the + attacker is impersonating. + +10.4. Cross-User Forgery + + By definition, SPF policies just map domain names to sets of + authorized MTAs, not whole E-Mail addresses to sets of authorized + users. Although the "l" macro (Section 8) provides a limited way to + define individual sets of authorized MTAs for specific E-Mail + addresses, it is generally impossible to verify, through SPF, the use + of specific E-Mail addresses by individual users of the same MTA. + + It is up to mail services and their MTAs to directly prevent + cross-user forgery: based on SMTP AUTH ([RFC2554]), users should be + restricted to using only those E-Mail addresses that are actually + under their control (see [RFC4409], Section 6.1). Another means to + verify the identity of individual users is message cryptography such + as PGP ([RFC2440]) or S/MIME ([RFC3851]). + + + + + + + +Wong & Schlitt Experimental [Page 37] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +10.5. Untrusted Information Sources + + SPF uses information supplied by third parties, such as the "HELO" + domain name, the "MAIL FROM" address, and SPF records. This + information is then passed to the receiver in the Received-SPF: trace + fields and possibly returned to the client MTA in the form of an SMTP + rejection message. This information must be checked for invalid + characters and excessively long lines. + + When the authorization check fails, an explanation string may be + included in the reject response. Both the sender and the rejecting + receiver need to be aware that the explanation was determined by the + publisher of the SPF record checked and, in general, not the + receiver. The explanation may contain malicious URLs, or it may be + offensive or misleading. + + This is probably less of a concern than it may initially seem since + such messages are returned to the sender, and the explanation strings + come from the sender policy published by the domain in the identity + claimed by that very sender. As long as the DSN is not redirected to + someone other than the actual sender, the only people who see + malicious explanation strings are people whose messages claim to be + from domains that publish such strings in their SPF records. In + practice, DSNs can be misdirected, such as when an MTA accepts an + E-Mail and then later generates a DSN to a forged address, or when an + E-Mail forwarder does not direct the DSN back to the original sender. + +10.6. Privacy Exposure + + Checking SPF records causes DNS queries to be sent to the domain + owner. These DNS queries, especially if they are caused by the + "exists" mechanism, can contain information about who is sending + E-Mail and likely to which MTA the E-Mail is being sent. This can + introduce some privacy concerns, which may be more or less of an + issue depending on local laws and the relationship between the domain + owner and the person sending the E-Mail. + +11. Contributors and Acknowledgements + + This document is largely based on the work of Meng Weng Wong and Mark + Lentczner. Although, as this section acknowledges, many people have + contributed to this document, a very large portion of the writing and + editing are due to Meng and Mark. + + This design owes a debt of parentage to [RMX] by Hadmut Danisch and + to [DMP] by Gordon Fecyk. The idea of using a DNS record to check + the legitimacy of an E-Mail address traces its ancestry further back + through messages on the namedroppers mailing list by Paul Vixie + + + +Wong & Schlitt Experimental [Page 38] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + [Vixie] (based on suggestion by Jim Miller) and by David Green + [Green]. + + Philip Gladstone contributed the concept of macros to the + specification, multiplying the expressiveness of the language and + making per-user and per-IP lookups possible. + + The authors would also like to thank the literally hundreds of + individuals who have participated in the development of this design. + They are far too numerous to name, but they include the following: + + The folks on the spf-discuss mailing list. + The folks on the SPAM-L mailing list. + The folks on the IRTF ASRG mailing list. + The folks on the IETF MARID mailing list. + The folks on #perl. + +12. IANA Considerations + +12.1. The SPF DNS Record Type + + The IANA has assigned a new Resource Record Type and Qtype from the + DNS Parameters Registry for the SPF RR type with code 99. + +12.2. The Received-SPF Mail Header Field + + Per [RFC3864], the "Received-SPF:" header field is added to the IANA + Permanent Message Header Field Registry. The following is the + registration template: + + Header field name: Received-SPF + Applicable protocol: mail ([RFC2822]) + Status: Experimental + Author/Change controller: IETF + Specification document(s): RFC 4408 + Related information: + Requesting SPF Council review of any proposed changes and + additions to this field are recommended. For information about + the SPF Council see http://www.openspf.org/Council + +13. References + +13.1. Normative References + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + + + + +Wong & Schlitt Experimental [Page 39] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + [RFC1123] Braden, R., "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. + + [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, + April 2001. + + [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April + 2001. + + [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format + for Delivery Status Notifications", RFC 3464, January + 2003. + + [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 + (IPv6) Addressing Architecture", RFC 3513, April 2003. + + [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, RFC 3864, + September 2004. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, RFC + 3986, January 2005. + + [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [US-ASCII] American National Standards Institute (formerly United + States of America Standards Institute), "USA Code for + Information Interchange, X3.4", 1968. + + ANSI X3.4-1968 has been replaced by newer versions with slight + modifications, but the 1968 version remains definitive for + the Internet. + +13.2 Informative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, August + 1996. + + [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, + "OpenPGP Message Format", RFC 2440, November 1998. + + + +Wong & Schlitt Experimental [Page 40] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + [RFC2554] Myers, J., "SMTP Service Extension for Authentication", + RFC 2554, March 1999. + + [RFC3696] Klensin, J., "Application Techniques for Checking and + Transformation of Names", RFC 3696, February 2004. + + [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain + Name System (DNS)", RFC 3833, August 2004. + + [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail + Extensions (S/MIME) Version 3.1 Message Specification", + RFC 3851, July 2004. + + [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", + RFC 4409, April 2006. + + [RMX] Danish, H., "The RMX DNS RR Type for light weight sender + authentication", Work In Progress + + [DMP] Fecyk, G., "Designated Mailers Protocol", Work In Progress + + [Vixie] Vixie, P., "Repudiating MAIL FROM", 2002. + + [Green] Green, D., "Domain-Authorized SMTP Mail", 2002. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wong & Schlitt Experimental [Page 41] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +Appendix A. Collected ABNF + + This section is normative and any discrepancies with the ABNF + fragments in the preceding text are to be resolved in favor of this + grammar. + + See [RFC4234] for ABNF notation. Please note that as per this ABNF + definition, literal text strings (those in quotes) are case- + insensitive. Hence, "mx" matches "mx", "MX", "mX", and "Mx". + + record = version terms *SP + version = "v=spf1" + + terms = *( 1*SP ( directive / modifier ) ) + + directive = [ qualifier ] mechanism + qualifier = "+" / "-" / "?" / "~" + mechanism = ( all / include + / A / MX / PTR / IP4 / IP6 / exists ) + + all = "all" + include = "include" ":" domain-spec + A = "a" [ ":" domain-spec ] [ dual-cidr-length ] + MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] + PTR = "ptr" [ ":" domain-spec ] + IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] + IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] + exists = "exists" ":" domain-spec + + modifier = redirect / explanation / unknown-modifier + redirect = "redirect" "=" domain-spec + explanation = "exp" "=" domain-spec + unknown-modifier = name "=" macro-string + + ip4-cidr-length = "/" 1*DIGIT + ip6-cidr-length = "/" 1*DIGIT + dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] + + ip4-network = qnum "." qnum "." qnum "." qnum + qnum = DIGIT ; 0-9 + / %x31-39 DIGIT ; 10-99 + / "1" 2DIGIT ; 100-199 + / "2" %x30-34 DIGIT ; 200-249 + / "25" %x30-35 ; 250-255 + ; conventional dotted quad notation. e.g., 192.0.2.0 + ip6-network = <as per [RFC 3513], section 2.2> + ; e.g., 2001:DB8::CD30 + + + + +Wong & Schlitt Experimental [Page 42] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + domain-spec = macro-string domain-end + domain-end = ( "." toplabel [ "." ] ) / macro-expand + toplabel = ( *alphanum ALPHA *alphanum ) / + ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) + ; LDH rule plus additional TLD restrictions + ; (see [RFC3696], Section 2) + + alphanum = ALPHA / DIGIT + + explain-string = *( macro-string / SP ) + + macro-string = *( macro-expand / macro-literal ) + macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) + / "%%" / "%_" / "%-" + macro-literal = %x21-24 / %x26-7E + ; visible characters except "%" + macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / + "c" / "r" / "t" + transformers = *DIGIT [ "r" ] + delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" + + name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) + + header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] + [ key-value-list ] CRLF + + result = "Pass" / "Fail" / "SoftFail" / "Neutral" / + "None" / "TempError" / "PermError" + + key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) + [";"] + + key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) + + key = "client-ip" / "envelope-from" / "helo" / + "problem" / "receiver" / "identity" / + mechanism / "x-" name / name + + identity = "mailfrom" ; for the "MAIL FROM" identity + / "helo" ; for the "HELO" identity + / name ; other identities + + dot-atom = <unquoted word as per [RFC2822]> + quoted-string = <quoted string as per [RFC2822]> + comment = <comment string as per [RFC2822]> + CFWS = <comment or folding white space as per [RFC2822]> + FWS = <folding white space as per [RFC2822]> + CRLF = <standard end-of-line token as per [RFC2822]> + + + +Wong & Schlitt Experimental [Page 43] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +Appendix B. Extended Examples + + These examples are based on the following DNS setup: + + ; A domain with two mail servers, two hosts + ; and two servers at the domain name + $ORIGIN example.com. + @ MX 10 mail-a + MX 20 mail-b + A 192.0.2.10 + A 192.0.2.11 + amy A 192.0.2.65 + bob A 192.0.2.66 + mail-a A 192.0.2.129 + mail-b A 192.0.2.130 + www CNAME example.com. + + ; A related domain + $ORIGIN example.org. + @ MX 10 mail-c + mail-c A 192.0.2.140 + + ; The reverse IP for those addresses + $ORIGIN 2.0.192.in-addr.arpa. + 10 PTR example.com. + 11 PTR example.com. + 65 PTR amy.example.com. + 66 PTR bob.example.com. + 129 PTR mail-a.example.com. + 130 PTR mail-b.example.com. + 140 PTR mail-c.example.org. + + ; A rogue reverse IP domain that claims to be + ; something it's not + $ORIGIN 0.0.10.in-addr.arpa. + 4 PTR bob.example.com. + +B.1. Simple Examples + + These examples show various possible published records for + example.com and which values if <ip> would cause check_host() to + return "Pass". Note that <domain> is "example.com". + + v=spf1 +all + -- any <ip> passes + + v=spf1 a -all + -- hosts 192.0.2.10 and 192.0.2.11 pass + + + +Wong & Schlitt Experimental [Page 44] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + + v=spf1 a:example.org -all + -- no sending hosts pass since example.org has no A records + + v=spf1 mx -all + -- sending hosts 192.0.2.129 and 192.0.2.130 pass + + v=spf1 mx:example.org -all + -- sending host 192.0.2.140 passes + + v=spf1 mx mx:example.org -all + -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass + + v=spf1 mx/30 mx:example.org/30 -all + -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes + + v=spf1 ptr -all + -- sending host 192.0.2.65 passes (reverse DNS is valid and is in + example.com) + -- sending host 192.0.2.140 fails (reverse DNS is valid, but not + in example.com) + -- sending host 10.0.0.4 fails (reverse IP is not valid) + + v=spf1 ip4:192.0.2.128/28 -all + -- sending host 192.0.2.65 fails + -- sending host 192.0.2.129 passes + +B.2. Multiple Domain Example + + These examples show the effect of related records: + + example.org: "v=spf1 include:example.com include:example.net -all" + + This record would be used if mail from example.org actually came + through servers at example.com and example.net. Example.org's + designated servers are the union of example.com's and example.net's + designated servers. + + la.example.org: "v=spf1 redirect=example.org" + ny.example.org: "v=spf1 redirect=example.org" + sf.example.org: "v=spf1 redirect=example.org" + + These records allow a set of domains that all use the same mail + system to make use of that mail system's record. In this way, only + the mail system's record needs to be updated when the mail setup + changes. These domains' records never have to change. + + + + + + +Wong & Schlitt Experimental [Page 45] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +B.3. DNSBL Style Example + + Imagine that, in addition to the domain records listed above, there + are these: + + $ORIGIN _spf.example.com. mary.mobile-users A + 127.0.0.2 fred.mobile-users A 127.0.0.2 + 15.15.168.192.joel.remote-users A 127.0.0.2 + 16.15.168.192.joel.remote-users A 127.0.0.2 + + The following records describe users at example.com who mail from + arbitrary servers, or who mail from personal servers. + + example.com: + + v=spf1 mx + include:mobile-users._spf.%{d} + include:remote-users._spf.%{d} + -all + + mobile-users._spf.example.com: + + v=spf1 exists:%{l1r+}.%{d} + + remote-users._spf.example.com: + + v=spf1 exists:%{ir}.%{l1r+}.%{d} + +B.4. Multiple Requirements Example + + Say that your sender policy requires both that the IP address is + within a certain range and that the reverse DNS for the IP matches. + This can be done several ways, including the following: + + example.com. SPF ( "v=spf1 " + "-include:ip4._spf.%{d} " + "-include:ptr._spf.%{d} " + "+all" ) + ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all" + ptr._spf.example.com. SPF "v=spf1 -ptr +all" + + This example shows how the "-include" mechanism can be useful, how an + SPF record that ends in "+all" can be very restrictive, and the use + of De Morgan's Law. + + + + + + + +Wong & Schlitt Experimental [Page 46] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +Authors' Addresses + + Meng Weng Wong + Singapore + + EMail: mengwong+spf@pobox.com + + + Wayne Schlitt + 4615 Meredeth #9 + Lincoln Nebraska, NE 68506 + United States of America + + EMail: wayne@schlitt.net + URI: http://www.schlitt.net/spf/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wong & Schlitt Experimental [Page 47] + +RFC 4408 Sender Policy Framework (SPF) April 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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 provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Wong & Schlitt Experimental [Page 48] + diff --git a/doc/rfc/rfc4431.txt b/doc/rfc/rfc4431.txt new file mode 100644 index 0000000..8b38872 --- /dev/null +++ b/doc/rfc/rfc4431.txt @@ -0,0 +1,227 @@ + + + + + + +Network Working Group M. Andrews +Request for Comments: 4431 Internet Systems Consortium +Category: Informational S. Weiler + SPARTA, Inc. + February 2006 + + + The DNSSEC Lookaside Validation (DLV) DNS Resource Record + +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 (2006). + +Abstract + + This document defines a new DNS resource record, called the DNSSEC + Lookaside Validation (DLV) RR, for publishing DNSSEC trust anchors + outside of the DNS delegation chain. + +1. Introduction + + DNSSEC [1] [2] [3] authenticates DNS data by building public-key + signature chains along the DNS delegation chain from a trust anchor, + ideally a trust anchor for the DNS root. + + This document defines a new resource record for publishing such trust + anchors outside of the DNS's normal delegation chain. Use of these + records by DNSSEC validators is outside the scope of this document, + but it is expected that these records will help resolvers validate + DNSSEC-signed data from zones whose ancestors either aren't signed or + refuse to publish delegation signer (DS) records for their children. + +2. DLV Resource Record + + The DLV resource record has exactly the same wire and presentation + formats as the DS resource record, defined in RFC 4034, Section 5. + It uses the same IANA-assigned values in the algorithm and digest + type fields as the DS record. (Those IANA registries are known as + the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm + Numbers" registries.) + + + + + +Andrews & Weiler Informational [Page 1] + +RFC 4431 DLV Resource Record February 2006 + + + The DLV record is a normal DNS record type without any special + processing requirements. In particular, the DLV record does not + inherit any of the special processing or handling requirements of the + DS record type (described in Section 3.1.4.1 of RFC 4035). Unlike + the DS record, the DLV record may not appear on the parent's side of + a zone cut. A DLV record may, however, appear at the apex of a zone. + +3. Security Considerations + + For authoritative servers and resolvers that do not attempt to use + DLV RRs as part of DNSSEC validation, there are no particular + security concerns -- DLV RRs are just like any other DNS data. + + Software using DLV RRs as part of DNSSEC validation will almost + certainly want to impose constraints on their use, but those + constraints are best left to be described by the documents that more + fully describe the particulars of how the records are used. At a + minimum, it would be unwise to use the records without some sort of + cryptographic authentication. More likely than not, DNSSEC itself + will be used to authenticate the DLV RRs. Depending on how a DLV RR + is used, failure to properly authenticate it could lead to + significant additional security problems including failure to detect + spoofed DNS data. + + RFC 4034, Section 8, describes security considerations specific to + the DS RR. Those considerations are equally applicable to DLV RRs. + Of particular note, the key tag field is used to help select DNSKEY + RRs efficiently, but it does not uniquely identify a single DNSKEY + RR. 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. + + For further discussion of the security implications of DNSSEC, see + RFC 4033, RFC 4034, and RFC 4035. + +4. IANA Considerations + + IANA has assigned DNS type code 32769 to the DLV resource record from + the Specification Required portion of the DNS Resource Record Type + registry, as defined in [4]. + + The DLV resource record reuses the same algorithm and digest type + registries already used for the DS resource record, currently known + as the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm + Numbers" registries. + + + + + +Andrews & Weiler Informational [Page 2] + +RFC 4431 DLV Resource Record February 2006 + + +5. Normative References + + [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + RFC 4035, March 2005. + + [4] Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain Name + System (DNS) IANA Considerations", BCP 42, RFC 2929, + September 2000. + +Authors' Addresses + + Mark Andrews + Internet Systems Consortium + 950 Charter St. + Redwood City, CA 94063 + US + + EMail: Mark_Andrews@isc.org + + + Samuel Weiler + SPARTA, Inc. + 7075 Samuel Morse Drive + Columbia, Maryland 21046 + US + + EMail: weiler@tislabs.com + + + + + + + + + + + + + + + +Andrews & Weiler Informational [Page 3] + +RFC 4431 DLV Resource Record February 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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 provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Andrews & Weiler Informational [Page 4] + diff --git a/doc/rfc/rfc4470.txt b/doc/rfc/rfc4470.txt new file mode 100644 index 0000000..ac12d65 --- /dev/null +++ b/doc/rfc/rfc4470.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group S. Weiler +Request for Comments: 4470 SPARTA, Inc. +Updates: 4035, 4034 J. Ihren +Category: Standards Track Autonomica AB + April 2006 + + + Minimally Covering NSEC Records and DNSSEC On-line Signing + + +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 (2006). + +Abstract + + This document describes how to construct DNSSEC NSEC resource records + that cover a smaller range of names than called for by RFC 4034. By + generating and signing these records on demand, authoritative name + servers can effectively stop the disclosure of zone contents + otherwise made possible by walking the chain of NSEC records in a + signed zone. + +Table of Contents + + 1. Introduction ....................................................1 + 2. Applicability of This Technique .................................2 + 3. Minimally Covering NSEC Records .................................2 + 4. Better Epsilon Functions ........................................4 + 5. Security Considerations .........................................5 + 6. Acknowledgements ................................................6 + 7. Normative References ............................................6 + +1. Introduction + + With DNSSEC [1], an NSEC record lists the next instantiated name in + its zone, proving that no names exist in the "span" between the + NSEC's owner name and the name in the "next name" field. In this + document, an NSEC record is said to "cover" the names between its + owner name and next name. + + + +Weiler & Ihren Standards Track [Page 1] + +RFC 4470 NSEC Epsilon April 2006 + + + Through repeated queries that return NSEC records, it is possible to + retrieve all of the names in the zone, a process commonly called + "walking" the zone. Some zone owners have policies forbidding zone + transfers by arbitrary clients; this side effect of the NSEC + architecture subverts those policies. + + This document presents a way to prevent zone walking by constructing + NSEC records that cover fewer names. These records can make zone + walking take approximately as many queries as simply asking for all + possible names in a zone, making zone walking impractical. Some of + these records must be created and signed on demand, which requires + on-line private keys. Anyone contemplating use of this technique is + strongly encouraged to review the discussion of the risks of on-line + signing in Section 5. + +1.2. Keywords + + The keywords "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 [4]. + +2. Applicability of This Technique + + The technique presented here may be useful to a zone owner that wants + to use DNSSEC, is concerned about exposure of its zone contents via + zone walking, and is willing to bear the costs of on-line signing. + + As discussed in Section 5, on-line signing has several security + risks, including an increased likelihood of private keys being + disclosed and an increased risk of denial of service attack. Anyone + contemplating use of this technique is strongly encouraged to review + the discussion of the risks of on-line signing in Section 5. + + Furthermore, at the time this document was published, the DNSEXT + working group was actively working on a mechanism to prevent zone + walking that does not require on-line signing (tentatively called + NSEC3). The new mechanism is likely to expose slightly more + information about the zone than this technique (e.g., the number of + instantiated names), but it may be preferable to this technique. + +3. Minimally Covering NSEC Records + + This mechanism involves changes to NSEC records for instantiated + names, which can still be generated and signed in advance, as well as + the on-demand generation and signing of new NSEC records whenever a + name must be proven not to exist. + + + + + +Weiler & Ihren Standards Track [Page 2] + +RFC 4470 NSEC Epsilon April 2006 + + + In the "next name" field of instantiated names' NSEC records, rather + than list the next instantiated name in the zone, list any name that + falls lexically after the NSEC's owner name and before the next + instantiated name in the zone, according to the ordering function in + RFC 4034 [2] Section 6.1. This relaxes the requirement in Section + 4.1.1 of RFC 4034 that the "next name" field contains the next owner + name in the zone. This change is expected to be fully compatible + with all existing DNSSEC validators. These NSEC records are returned + whenever proving something specifically about the owner name (e.g., + that no resource records of a given type appear at that name). + + Whenever an NSEC record is needed to prove the non-existence of a + name, a new NSEC record is dynamically produced and signed. The new + NSEC record has an owner name lexically before the QNAME but + lexically following any existing name and a "next name" lexically + following the QNAME but before any existing name. + + The generated NSEC record's type bitmap MUST have the RRSIG and NSEC + bits set and SHOULD NOT have any other bits set. This relaxes the + requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at + names that did not exist before the zone was signed. + + The functions to generate the lexically following and proceeding + names need not be perfect or consistent, but the generated NSEC + records must not cover any existing names. Furthermore, this + technique works best when the generated NSEC records cover as few + names as possible. In this document, the functions that generate the + nearby names are called "epsilon" functions, a reference to the + mathematical convention of using the greek letter epsilon to + represent small deviations. + + An NSEC record denying the existence of a wildcard may be generated + in the same way. Since the NSEC record covering a non-existent + wildcard is likely to be used in response to many queries, + authoritative name servers using the techniques described here may + want to pregenerate or cache that record and its corresponding RRSIG. + + For example, a query for an A record at the non-instantiated name + example.com might produce the following two NSEC records, the first + denying the existence of the name example.com and the second denying + the existence of a wildcard: + + exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC ) + + \).com 3600 IN NSEC +.com ( RRSIG NSEC ) + + + + + + +Weiler & Ihren Standards Track [Page 3] + +RFC 4470 NSEC Epsilon April 2006 + + + Before answering a query with these records, an authoritative server + must test for the existence of names between these endpoints. If the + generated NSEC would cover existing names (e.g., exampldd.com or + *bizarre.example.com), a better epsilon function may be used or the + covered name closest to the QNAME could be used as the NSEC owner + name or next name, as appropriate. If an existing name is used as + the NSEC owner name, that name's real NSEC record MUST be returned. + Using the same example, assuming an exampldd.com delegation exists, + this record might be returned from the parent: + + exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC ) + + Like every authoritative record in the zone, each generated NSEC + record MUST have corresponding RRSIGs generated using each algorithm + (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as + described in RFC 4035 [3] Section 2.2. To minimize the number of + signatures that must be generated, a zone may wish to limit the + number of algorithms in its DNSKEY RRset. + +4. Better Epsilon Functions + + Section 6.1 of RFC 4034 defines a strict ordering of DNS names. + Working backward from that definition, it should be possible to + define epsilon functions that generate the immediately following and + preceding names, respectively. This document does not define such + functions. Instead, this section presents functions that come + reasonably close to the perfect ones. As described above, an + authoritative server should still ensure than no generated NSEC + covers any existing name. + + To increment a name, add a leading label with a single null (zero- + value) octet. + + To decrement a name, decrement the last character of the leftmost + label, then fill that label to a length of 63 octets with octets of + value 255. To decrement a null (zero-value) octet, remove the octet + -- if an empty label is left, remove the label. Defining this + function numerically: fill the leftmost label to its maximum length + with zeros (numeric, not ASCII zeros) and subtract one. + + In response to a query for the non-existent name foo.example.com, + these functions produce NSEC records of the following: + + + + + + + + + +Weiler & Ihren Standards Track [Page 4] + +RFC 4470 NSEC Epsilon April 2006 + + + fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG ) + + \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG ) + + The first of these NSEC RRs proves that no exact match for + foo.example.com exists, and the second proves that there is no + wildcard in example.com. + + Both of these functions are imperfect: they do not take into account + constraints on number of labels in a name nor total length of a name. + As noted in the previous section, though, this technique does not + depend on the use of perfect epsilon functions: it is sufficient to + test whether any instantiated names fall into the span covered by the + generated NSEC and, if so, substitute those instantiated owner names + for the NSEC owner name or next name, as appropriate. + +5. Security Considerations + + This approach requires on-demand generation of RRSIG records. This + creates several new vulnerabilities. + + First, on-demand signing requires that a zone's authoritative servers + have access to its private keys. Storing private keys on well-known + Internet-accessible servers may make them more vulnerable to + unintended disclosure. + + Second, since generation of digital signatures tends to be + computationally demanding, the requirement for on-demand signing + makes authoritative servers vulnerable to a denial of service attack. + + Last, if the epsilon functions are predictable, on-demand signing may + enable a chosen-plaintext attack on a zone's private keys. Zones + using this approach should attempt to use cryptographic algorithms + that are resistant to chosen-plaintext attacks. It is worth noting + that although DNSSEC has a "mandatory to implement" algorithm, that + is a requirement on resolvers and validators -- there is no + requirement that a zone be signed with any given algorithm. + + The success of using minimally covering NSEC records to prevent zone + walking depends greatly on the quality of the epsilon functions + + + +Weiler & Ihren Standards Track [Page 5] + +RFC 4470 NSEC Epsilon April 2006 + + + chosen. An increment function that chooses a name obviously derived + from the next instantiated name may be easily reverse engineered, + destroying the value of this technique. An increment function that + always returns a name close to the next instantiated name is likewise + a poor choice. Good choices of epsilon functions are the ones that + produce the immediately following and preceding names, respectively, + though zone administrators may wish to use less perfect functions + that return more human-friendly names than the functions described in + Section 4 above. + + Another obvious but misguided concern is the danger from synthesized + NSEC records being replayed. It is possible for an attacker to + replay an old but still validly signed NSEC record after a new name + has been added in the span covered by that NSEC, incorrectly proving + that there is no record at that name. This danger exists with DNSSEC + as defined in [3]. The techniques described here actually decrease + the danger, since the span covered by any NSEC record is smaller than + before. Choosing better epsilon functions will further reduce this + danger. + +6. Acknowledgements + + Many individuals contributed to this design. They include, in + addition to the authors of this document, Olaf Kolkman, Ed Lewis, + Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis, + Jakob Schlyter, Bill Manning, and Joao Damas. + + In addition, the editors would like to thank Ed Lewis, Scott Rose, + and David Blacka for their careful review of the document. + +7. Normative References + + [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, March + 2005. + + [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", RFC + 4035, March 2005. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + + + +Weiler & Ihren Standards Track [Page 6] + +RFC 4470 NSEC Epsilon April 2006 + + +Authors' Addresses + + Samuel Weiler + SPARTA, Inc. + 7075 Samuel Morse Drive + Columbia, Maryland 21046 + US + + EMail: weiler@tislabs.com + + + Johan Ihren + Autonomica AB + Bellmansgatan 30 + Stockholm SE-118 47 + Sweden + + EMail: johani@autonomica.se + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Weiler & Ihren Standards Track [Page 7] + +RFC 4470 NSEC Epsilon April 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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 provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Weiler & Ihren Standards Track [Page 8] + diff --git a/doc/rfc/rfc4634.txt b/doc/rfc/rfc4634.txt new file mode 100644 index 0000000..b672df8 --- /dev/null +++ b/doc/rfc/rfc4634.txt @@ -0,0 +1,6051 @@ + + + + + + +Network Working Group D. Eastlake 3rd +Request for Comments: 4634 Motorola Labs +Updates: 3174 T. Hansen +Category: Informational AT&T Labs + July 2006 + + + US Secure Hash Algorithms (SHA and HMAC-SHA) + +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 (2006). + +Abstract + + The United States of America has adopted a suite of Secure Hash + Algorithms (SHAs), including four beyond SHA-1, as part of a Federal + Information Processing Standard (FIPS), specifically SHA-224 (RFC + 3874), SHA-256, SHA-384, and SHA-512. The purpose of this document + is to make source code performing these hash functions conveniently + available to the Internet community. The sample code supports input + strings of arbitrary bit length. SHA-1's sample code from RFC 3174 + has also been updated to handle input strings of arbitrary bit + length. Most of the text herein was adapted by the authors from FIPS + 180-2. + + Code to perform SHA-based HMACs, with arbitrary bit length text, is + also included. + + + + + + + + + + + + + + + + + +Eastlake 3rd & Hansen Informational [Page 1] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +Table of Contents + + 1. Overview of Contents ............................................3 + 1.1. License ....................................................4 + 2. Notation for Bit Strings and Integers ...........................4 + 3. Operations on Words .............................................5 + 4. Message Padding and Parsing .....................................6 + 4.1. SHA-224 and SHA-256 ........................................7 + 4.2. SHA-384 and SHA-512 ........................................8 + 5. Functions and Constants Used ....................................9 + 5.1. SHA-224 and SHA-256 ........................................9 + 5.2. SHA-384 and SHA-512 .......................................10 + 6. Computing the Message Digest ...................................11 + 6.1. SHA-224 and SHA-256 Initialization ........................11 + 6.2. SHA-224 and SHA-256 Processing ............................11 + 6.3. SHA-384 and SHA-512 Initialization ........................13 + 6.4. SHA-384 and SHA-512 Processing ............................14 + 7. SHA-Based HMACs ................................................15 + 8. C Code for SHAs ................................................15 + 8.1. The .h File ...............................................18 + 8.2. The SHA Code ..............................................24 + 8.2.1. sha1.c .............................................24 + 8.2.2. sha224-256.c .......................................33 + 8.2.3. sha384-512.c .......................................45 + 8.2.4. usha.c .............................................67 + 8.2.5. sha-private.h ......................................72 + 8.3. The HMAC Code .............................................73 + 8.4. The Test Driver ...........................................78 + 9. Security Considerations .......................................106 + 10. Normative References .........................................106 + 11. Informative References .......................................106 + + + + + + + + + + + + + + + + + + + + +Eastlake 3rd & Hansen Informational [Page 2] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +1. Overview of Contents + + NOTE: Much of the text below is taken from [FIPS180-2] and assertions + therein of the security of the algorithms described are made by the + US Government, the author of [FIPS180-2], and not by the authors of + this document. + + The text below specifies Secure Hash Algorithms, SHA-224 [RFC3874], + SHA-256, SHA-384, and SHA-512, for computing a condensed + representation of a message or a data file. (SHA-1 is specified in + [RFC3174].) When a message of any length < 2^64 bits (for SHA-224 + and SHA-256) or < 2^128 bits (for SHA-384 and SHA-512) is input to + one of these algorithms, the result is an output called a message + digest. The message digests range in length from 224 to 512 bits, + depending on the algorithm. Secure hash algorithms are typically + used with other cryptographic algorithms, such as digital signature + algorithms and keyed hash authentication codes, or in the generation + of random numbers [RFC4086]. + + The four algorithms specified in this document are called secure + because it is computationally infeasible to (1) find a message that + corresponds to a given message digest, or (2) find two different + messages that produce the same message digest. Any change to a + message in transit will, with very high probability, result in a + different message digest. This will result in a verification failure + when the secure hash algorithm is used with a digital signature + algorithm or a keyed-hash message authentication algorithm. + + The code provided herein supports input strings of arbitrary bit + length. SHA-1's sample code from [RFC3174] has also been updated to + handle input strings of arbitrary bit length. See Section 1.1 for + license information for this code. + + Section 2 below defines the terminology and functions used as + building blocks to form these algorithms. Section 3 describes the + fundamental operations on words from which these algorithms are + built. Section 4 describes how messages are padded up to an integral + multiple of the required block size and then parsed into blocks. + Section 5 defines the constants and the composite functions used to + specify these algorithms. Section 6 gives the actual specification + for the SHA-224, SHA-256, SHA-384, and SHA-512 functions. Section 7 + provides pointers to the specification of HMAC keyed message + authentication codes based on the SHA algorithms. Section 8 gives + sample code for the SHA algorithms and Section 9 code for SHA-based + HMACs. The SHA-based HMACs will accept arbitrary bit length text. + + + + + + +Eastlake 3rd & Hansen Informational [Page 3] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +1.1. License + + Permission is granted for all uses, commercial and non-commercial, of + the sample code found in Section 8. Royalty free license to use, + copy, modify and distribute the software found in Section 8 is + granted, provided that this document is identified in all material + mentioning or referencing this software, and provided that + redistributed derivative works do not contain misleading author or + version information. + + The authors make no representations concerning either the + merchantability of this software or the suitability of this software + for any particular purpose. It is provided "as is" without express + or implied warranty of any kind. + +2. Notation for Bit Strings and Integers + + The following terminology related to bit strings and integers will be + used: + + a. A hex digit is an element of the set {0, 1, ... , 9, A, ... , + F}. A hex digit is the representation of a 4-bit string. + Examples: 7 = 0111, A = 1010. + + b. A word equals a 32-bit or 64-bit string, which may be + represented as a sequence of 8 or 16 hex digits, respectively. + To convert a word to hex digits, each 4-bit string is converted + to its hex equivalent as described in (a) above. Example: + + 1010 0001 0000 0011 1111 1110 0010 0011 = A103FE23. + + Throughout this document, the "big-endian" convention is used + when expressing both 32-bit and 64-bit words, so that within + each word the most significant bit is shown in the left-most bit + position. + + c. An integer may be represented as a word or pair of words. + + An integer between 0 and 2^32 - 1 inclusive may be represented + as a 32-bit word. The least significant four bits of the + integer are represented by the right-most hex digit of the word + representation. Example: the integer 291 = 2^8+2^5+2^1+2^0 = + 256+32+2+1 is represented by the hex word 00000123. + + The same holds true for an integer between 0 and 2^64-1 + inclusive, which may be represented as a 64-bit word. + + + + + +Eastlake 3rd & Hansen Informational [Page 4] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + If Z is an integer, 0 <= z < 2^64, then z = (2^32)x + y where 0 + <= x < 2^32 and 0 <= y < 2^32. Since x and y can be represented + as words X and Y, respectively, z can be represented as the pair + of words (X,Y). + + d. block = 512-bit or 1024-bit string. A block (e.g., B) may be + represented as a sequence of 32-bit or 64-bit words. + +3. Operations on Words + + The following logical operators will be applied to words in all four + hash operations specified herein. SHA-224 and SHA-256 operate on + 32-bit words, while SHA-384 and SHA-512 operate on 64-bit words. + + In the operations below, x<<n is obtained as follows: discard the + left-most n bits of x and then pad the result with n zeroed bits on + the right (the result will still be the same number of bits). + + a. Bitwise logical word operations + + X AND Y = bitwise logical "and" of X and Y. + + X OR Y = bitwise logical "inclusive-or" of X and Y. + + X XOR Y = bitwise logical "exclusive-or" of X and Y. + + NOT X = bitwise logical "complement" of X. + + Example: + 01101100101110011101001001111011 + XOR 01100101110000010110100110110111 + -------------------------------- + = 00001001011110001011101111001100 + + b. The operation X + Y is defined as follows: words X and Y + represent w-bit integers x and y, where 0 <= x < 2^w and + 0 <= y < 2^w. For positive integers n and m, let + + n mod m + + be the remainder upon dividing n by m. Compute + + z = (x + y) mod 2^w. + + Then 0 <= z < 2^w. Convert z to a word, Z, and define Z = X + + Y. + + + + + +Eastlake 3rd & Hansen Informational [Page 5] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + c. The right shift operation SHR^n(x), where x is a w-bit word and + n is an integer with 0 <= n < w, is defined by + + SHR^n(x) = x>>n + + d. The rotate right (circular right shift) operation ROTR^n(x), + where x is a w-bit word and n is an integer with 0 <= n < w, is + defined by + + ROTR^n(x) = (x>>n) OR (x<<(w-n)) + + e. The rotate left (circular left shift) operation ROTL^n(x), where + x is a w-bit word and n is an integer with 0 <= n < w, is + defined by + + ROTL^n(X) = (x<<n) OR (x>>w-n) + + Note the following equivalence relationships, where w is fixed + in each relationship: + + ROTL^n(x) = ROTR^(w-x)(x) + + ROTR^n(x) = ROTL^(w-n)(x) + +4. Message Padding and Parsing + + The hash functions specified herein are used to compute a message + digest for a message or data file that is provided as input. The + message or data file should be considered to be a bit string. The + length of the message is the number of bits in the message (the empty + message has length 0). If the number of bits in a message is a + multiple of 8, for compactness we can represent the message in hex. + The purpose of message padding is to make the total length of a + padded message a multiple of 512 for SHA-224 and SHA-256 or a + multiple of 1024 for SHA-384 and SHA-512. + + The following specifies how this padding shall be performed. As a + summary, a "1" followed by a number of "0"s followed by a 64-bit or + 128-bit integer are appended to the end of the message to produce a + padded message of length 512*n or 1024*n. The minimum number of "0"s + necessary to meet this criterion is used. The appended integer is + the length of the original message. The padded message is then + processed by the hash function as n 512-bit or 1024-bit blocks. + + + + + + + + +Eastlake 3rd & Hansen Informational [Page 6] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +4.1. SHA-224 and SHA-256 + + Suppose a message has length L < 2^64. Before it is input to the + hash function, the message is padded on the right as follows: + + a. "1" is appended. Example: if the original message is + "01010000", this is padded to "010100001". + + b. K "0"s are appended where K is the smallest, non-negative + solution to the equation + + L + 1 + K = 448 (mod 512) + + c. Then append the 64-bit block that is L in binary representation. + After appending this block, the length of the message will be a + multiple of 512 bits. + + Example: Suppose the original message is the bit string + + 01100001 01100010 01100011 01100100 01100101 + + After step (a), this gives + + 01100001 01100010 01100011 01100100 01100101 1 + + Since L = 40, the number of bits in the above is 41 and K = 407 + "0"s are appended, making the total now 448. This gives the + following in hex: + + 61626364 65800000 00000000 00000000 + 00000000 00000000 00000000 00000000 + 00000000 00000000 00000000 00000000 + 00000000 00000000 + + The 64-bit representation of L = 40 is hex 00000000 00000028. + Hence the final padded message is the following hex: + + 61626364 65800000 00000000 00000000 + 00000000 00000000 00000000 00000000 + 00000000 00000000 00000000 00000000 + 00000000 00000000 00000000 00000028 + + + + + + + + + + +Eastlake 3rd & Hansen Informational [Page 7] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +4.2. SHA-384 and SHA-512 + + Suppose a message has length L < 2^128. Before it is input to the + hash function, the message is padded on the right as follows: + + a. "1" is appended. Example: if the original message is + "01010000", this is padded to "010100001". + + b. K "0"s are appended where K is the smallest, non-negative + solution to the equation + + L + 1 + K = 896 (mod 1024) + + c. Then append the 128-bit block that is L in binary + representation. After appending this block, the length of the + message will be a multiple of 1024 bits. + + Example: Suppose the original message is the bit string + + 01100001 01100010 01100011 01100100 01100101 + + After step (a) this gives + + 01100001 01100010 01100011 01100100 01100101 1 + + Since L = 40, the number of bits in the above is 41 and K = 855 + "0"s are appended, making the total now 896. This gives the + following in hex: + + 61626364 65800000 00000000 00000000 + 00000000 00000000 00000000 00000000 + 00000000 00000000 00000000 00000000 + 00000000 00000000 00000000 00000000 + 00000000 00000000 00000000 00000000 + 00000000 00000000 00000000 00000000 + 00000000 00000000 00000000 00000000 + + The 128-bit representation of L = 40 is hex 00000000 00000000 + 00000000 00000028. Hence the final padded message is the + following hex: + + 61626364 65800000 00000000 00000000 + 00000000 00000000 00000000 00000000 + 00000000 00000000 00000000 00000000 + 00000000 00000000 00000000 00000000 + 00000000 00000000 00000000 00000000 + + + + + +Eastlake 3rd & Hansen Informational [Page 8] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + 00000000 00000000 00000000 00000000 + 00000000 00000000 00000000 00000000 + 00000000 00000000 00000000 00000028 + +5. Functions and Constants Used + + The following subsections give the six logical functions and the + table of constants used in each of the hash functions. + +5.1. SHA-224 and SHA-256 + + SHA-224 and SHA-256 use six logical functions, where each function + operates on 32-bit words, which are represented as x, y, and z. The + result of each function is a new 32-bit word. + + CH( x, y, z) = (x AND y) XOR ( (NOT x) AND z) + + MAJ( x, y, z) = (x AND y) XOR (x AND z) XOR (y AND z) + + BSIG0(x) = ROTR^2(x) XOR ROTR^13(x) XOR ROTR^22(x) + + BSIG1(x) = ROTR^6(x) XOR ROTR^11(x) XOR ROTR^25(x) + + SSIG0(x) = ROTR^7(x) XOR ROTR^18(x) XOR SHR^3(x) + + SSIG1(x) = ROTR^17(x) XOR ROTR^19(x) XOR SHR^10(x) + + SHA-224 and SHA-256 use the same sequence of sixty-four constant + 32-bit words, K0, K1, ..., K63. These words represent the first + thirty-two bits of the fractional parts of the cube roots of the + first sixty-four prime numbers. In hex, these constant words are as + follows (from left to right): + + 428a2f98 71374491 b5c0fbcf e9b5dba5 + 3956c25b 59f111f1 923f82a4 ab1c5ed5 + d807aa98 12835b01 243185be 550c7dc3 + 72be5d74 80deb1fe 9bdc06a7 c19bf174 + e49b69c1 efbe4786 0fc19dc6 240ca1cc + 2de92c6f 4a7484aa 5cb0a9dc 76f988da + 983e5152 a831c66d b00327c8 bf597fc7 + c6e00bf3 d5a79147 06ca6351 14292967 + 27b70a85 2e1b2138 4d2c6dfc 53380d13 + 650a7354 766a0abb 81c2c92e 92722c85 + a2bfe8a1 a81a664b c24b8b70 c76c51a3 + d192e819 d6990624 f40e3585 106aa070 + 19a4c116 1e376c08 2748774c 34b0bcb5 + + + + + +Eastlake 3rd & Hansen Informational [Page 9] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + 391c0cb3 4ed8aa4a 5b9cca4f 682e6ff3 + 748f82ee 78a5636f 84c87814 8cc70208 + 90befffa a4506ceb bef9a3f7 c67178f2 + +5.2. SHA-384 and SHA-512 + + SHA-384 and SHA-512 each use six logical functions, where each + function operates on 64-bit words, which are represented as x, y, and + z. The result of each function is a new 64-bit word. + + CH( x, y, z) = (x AND y) XOR ( (NOT x) AND z) + + MAJ( x, y, z) = (x AND y) XOR (x AND z) XOR (y AND z) + + BSIG0(x) = ROTR^28(x) XOR ROTR^34(x) XOR ROTR^39(x) + + BSIG1(x) = ROTR^14(x) XOR ROTR^18(x) XOR ROTR^41(x) + + SSIG0(x) = ROTR^1(x) XOR ROTR^8(x) XOR SHR^7(x) + + SSIG1(x) = ROTR^19(x) XOR ROTR^61(x) XOR SHR^6(x) + + SHA-384 and SHA-512 use the same sequence of eighty constant 64-bit + words, K0, K1, ... K79. These words represent the first sixty-four + bits of the fractional parts of the cube roots of the first eighty + prime numbers. In hex, these constant words are as follows (from + left to right): + + 428a2f98d728ae22 7137449123ef65cd b5c0fbcfec4d3b2f e9b5dba58189dbbc + 3956c25bf348b538 59f111f1b605d019 923f82a4af194f9b ab1c5ed5da6d8118 + d807aa98a3030242 12835b0145706fbe 243185be4ee4b28c 550c7dc3d5ffb4e2 + 72be5d74f27b896f 80deb1fe3b1696b1 9bdc06a725c71235 c19bf174cf692694 + e49b69c19ef14ad2 efbe4786384f25e3 0fc19dc68b8cd5b5 240ca1cc77ac9c65 + 2de92c6f592b0275 4a7484aa6ea6e483 5cb0a9dcbd41fbd4 76f988da831153b5 + 983e5152ee66dfab a831c66d2db43210 b00327c898fb213f bf597fc7beef0ee4 + c6e00bf33da88fc2 d5a79147930aa725 06ca6351e003826f 142929670a0e6e70 + 27b70a8546d22ffc 2e1b21385c26c926 4d2c6dfc5ac42aed 53380d139d95b3df + 650a73548baf63de 766a0abb3c77b2a8 81c2c92e47edaee6 92722c851482353b + a2bfe8a14cf10364 a81a664bbc423001 c24b8b70d0f89791 c76c51a30654be30 + d192e819d6ef5218 d69906245565a910 f40e35855771202a 106aa07032bbd1b8 + 19a4c116b8d2d0c8 1e376c085141ab53 2748774cdf8eeb99 34b0bcb5e19b48a8 + 391c0cb3c5c95a63 4ed8aa4ae3418acb 5b9cca4f7763e373 682e6ff3d6b2b8a3 + 748f82ee5defb2fc 78a5636f43172f60 84c87814a1f0ab72 8cc702081a6439ec + 90befffa23631e28 a4506cebde82bde9 bef9a3f7b2c67915 c67178f2e372532b + ca273eceea26619c d186b8c721c0c207 eada7dd6cde0eb1e f57d4f7fee6ed178 + 06f067aa72176fba 0a637dc5a2c898a6 113f9804bef90dae 1b710b35131c471b + 28db77f523047d84 32caab7b40c72493 3c9ebe0a15c9bebc 431d67c49c100d4c + 4cc5d4becb3e42b6 597f299cfc657e2a 5fcb6fab3ad6faec 6c44198c4a475817 + + + +Eastlake 3rd & Hansen Informational [Page 10] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +6. Computing the Message Digest + + The output of each of the secure hash functions, after being applied + to a message of N blocks, is the hash quantity H(N). For SHA-224 and + SHA-256, H(i) can be considered to be eight 32-bit words, H(i)0, + H(i)1, ... H(i)7. For SHA-384 and SHA-512, it can be considered to + be eight 64-bit words, H(i)0, H(i)1, ..., H(i)7. + + As described below, the hash words are initialized, modified as each + message block is processed, and finally concatenated after processing + the last block to yield the output. For SHA-256 and SHA-512, all of + the H(N) variables are concatenated while the SHA-224 and SHA-384 + hashes are produced by omitting some from the final concatenation. + +6.1. SHA-224 and SHA-256 Initialization + + For SHA-224, the initial hash value, H(0), consists of the following + 32-bit words in hex: + + H(0)0 = c1059ed8 + H(0)1 = 367cd507 + H(0)2 = 3070dd17 + H(0)3 = f70e5939 + H(0)4 = ffc00b31 + H(0)5 = 68581511 + H(0)6 = 64f98fa7 + H(0)7 = befa4fa4 + + For SHA-256, the initial hash value, H(0), consists of the following + eight 32-bit words, in hex. These words were obtained by taking the + first thirty-two bits of the fractional parts of the square roots of + the first eight prime numbers. + + H(0)0 = 6a09e667 + H(0)1 = bb67ae85 + H(0)2 = 3c6ef372 + H(0)3 = a54ff53a + H(0)4 = 510e527f + H(0)5 = 9b05688c + H(0)6 = 1f83d9ab + H(0)7 = 5be0cd19 + +6.2. SHA-224 and SHA-256 Processing + + SHA-224 and SHA-256 perform identical processing on messages blocks + and differ only in how H(0) is initialized and how they produce their + final output. They may be used to hash a message, M, having a length + of L bits, where 0 <= L < 2^64. The algorithm uses (1) a message + + + +Eastlake 3rd & Hansen Informational [Page 11] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + schedule of sixty-four 32-bit words, (2) eight working variables of + 32 bits each, and (3) a hash value of eight 32-bit words. + + The words of the message schedule are labeled W0, W1, ..., W63. The + eight working variables are labeled a, b, c, d, e, f, g, and h. The + words of the hash value are labeled H(i)0, H(i)1, ..., H(i)7, which + will hold the initial hash value, H(0), replaced by each successive + intermediate hash value (after each message block is processed), + H(i), and ending with the final hash value, H(N), after all N blocks + are processed. They also use two temporary words, T1 and T2. + + The input message is padded as described in Section 4.1 above then + parsed into 512-bit blocks, which are considered to be composed of 16 + 32-bit words M(i)0, M(i)1, ..., M(i)15. The following computations + are then performed for each of the N message blocks. All addition is + performed modulo 2^32. + + For i = 1 to N + + 1. Prepare the message schedule W: + For t = 0 to 15 + Wt = M(i)t + For t = 16 to 63 + Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(t-15) + W(t-16) + + 2. Initialize the working variables: + a = H(i-1)0 + b = H(i-1)1 + c = H(i-1)2 + d = H(i-1)3 + e = H(i-1)4 + f = H(i-1)5 + g = H(i-1)6 + h = H(i-1)7 + + 3. Perform the main hash computation: + For t = 0 to 63 + T1 = h + BSIG1(e) + CH(e,f,g) + Kt + Wt + T2 = BSIG0(a) + MAJ(a,b,c) + h = g + g = f + f = e + e = d + T1 + d = c + c = b + b = a + a = T1 + T2 + + + + +Eastlake 3rd & Hansen Informational [Page 12] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + 4. Compute the intermediate hash value H(i): + H(i)0 = a + H(i-1)0 + H(i)1 = b + H(i-1)1 + H(i)2 = c + H(i-1)2 + H(i)3 = d + H(i-1)3 + H(i)4 = e + H(i-1)4 + H(i)5 = f + H(i-1)5 + H(i)6 = g + H(i-1)6 + H(i)7 = h + H(i-1)7 + + After the above computations have been sequentially performed for all + of the blocks in the message, the final output is calculated. For + SHA-256, this is the concatenation of all of H(N)0, H(N)1, through + H(N)7. For SHA-224, this is the concatenation of H(N)0, H(N)1, + through H(N)6. + +6.3. SHA-384 and SHA-512 Initialization + + For SHA-384, the initial hash value, H(0), consists of the following + eight 64-bit words, in hex. These words were obtained by taking the + first sixty-four bits of the fractional parts of the square roots of + the ninth through sixteenth prime numbers. + + H(0)0 = cbbb9d5dc1059ed8 + H(0)1 = 629a292a367cd507 + H(0)2 = 9159015a3070dd17 + H(0)3 = 152fecd8f70e5939 + H(0)4 = 67332667ffc00b31 + H(0)5 = 8eb44a8768581511 + H(0)6 = db0c2e0d64f98fa7 + H(0)7 = 47b5481dbefa4fa4 + + For SHA-512, the initial hash value, H(0), consists of the following + eight 64-bit words, in hex. These words were obtained by taking the + first sixty-four bits of the fractional parts of the square roots of + the first eight prime numbers. + + H(0)0 = 6a09e667f3bcc908 + H(0)1 = bb67ae8584caa73b + H(0)2 = 3c6ef372fe94f82b + H(0)3 = a54ff53a5f1d36f1 + H(0)4 = 510e527fade682d1 + H(0)5 = 9b05688c2b3e6c1f + H(0)6 = 1f83d9abfb41bd6b + H(0)7 = 5be0cd19137e2179 + + + + + + +Eastlake 3rd & Hansen Informational [Page 13] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +6.4. SHA-384 and SHA-512 Processing + + SHA-384 and SHA-512 perform identical processing on message blocks + and differ only in how H(0) is initialized and how they produce their + final output. They may be used to hash a message, M, having a length + of L bits, where 0 <= L < 2^128. The algorithm uses (1) a message + schedule of eighty 64-bit words, (2) eight working variables of 64 + bits each, and (3) a hash value of eight 64-bit words. + + The words of the message schedule are labeled W0, W1, ..., W79. The + eight working variables are labeled a, b, c, d, e, f, g, and h. The + words of the hash value are labeled H(i)0, H(i)1, ..., H(i)7, which + will hold the initial hash value, H(0), replaced by each successive + intermediate hash value (after each message block is processed), + H(i), and ending with the final hash value, H(N) after all N blocks + are processed. + + The input message is padded as described in Section 4.2 above, then + parsed into 1024-bit blocks, which are considered to be composed of + 16 64-bit words M(i)0, M(i)1, ..., M(i)15. The following + computations are then performed for each of the N message blocks. + All addition is performed modulo 2^64. + + For i = 1 to N + + 1. Prepare the message schedule W: + For t = 0 to 15 + Wt = M(i)t + For t = 16 to 79 + Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(t-15) + W(t-16) + + 2. Initialize the working variables: + a = H(i-1)0 + b = H(i-1)1 + c = H(i-1)2 + d = H(i-1)3 + e = H(i-1)4 + f = H(i-1)5 + g = H(i-1)6 + h = H(i-1)7 + + 3. Perform the main hash computation: + For t = 0 to 79 + T1 = h + BSIG1(e) + CH(e,f,g) + Kt + Wt + T2 = BSIG0(a) + MAJ(a,b,c) + h = g + g = f + f = e + + + +Eastlake 3rd & Hansen Informational [Page 14] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + e = d + T1 + d = c + c = b + b = a + a = T1 + T2 + + 4. Compute the intermediate hash value H(i): + H(i)0 = a + H(i-1)0 + H(i)1 = b + H(i-1)1 + H(i)2 = c + H(i-1)2 + H(i)3 = d + H(i-1)3 + H(i)4 = e + H(i-1)4 + H(i)5 = f + H(i-1)5 + H(i)6 = g + H(i-1)6 + H(i)7 = h + H(i-1)7 + + After the above computations have been sequentially performed for all + of the blocks in the message, the final output is calculated. For + SHA-512, this is the concatenation of all of H(N)0, H(N)1, through + H(N)7. For SHA-384, this is the concatenation of H(N)0, H(N)1, + through H(N)5. + +7. SHA-Based HMACs + + HMAC is a method for computing a keyed MAC (message authentication + code) using a hash function as described in [RFC2104]. It uses a key + to mix in with the input text to produce the final hash. + + Sample code is also provided, in Section 8.3 below, to perform HMAC + based on any of the SHA algorithms described herein. The sample code + found in [RFC2104] was written in terms of a specified text size. + Since SHA is defined in terms of an arbitrary number of bits, the + sample HMAC code has been written to allow the text input to HMAC to + have an arbitrary number of octets and bits. A fixed-length + interface is also provided. + +8. C Code for SHAs + + Below is a demonstration implementation of these secure hash + functions in C. Section 8.1 contains the header file sha.h, which + declares all constants, structures, and functions used by the sha and + hmac functions. Section 8.2 contains the C code for sha1.c, + sha224-256.c, sha384-512.c, and usha.c along with sha-private.h, + which provides some declarations common to all the sha functions. + Section 8.3 contains the C code for the hmac functions. Section 8.4 + contains a test driver to exercise the code. + + + + + +Eastlake 3rd & Hansen Informational [Page 15] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + For each of the digest length $$$, there is the following set of + constants, a structure, and functions: + + Constants: + SHA$$$HashSize number of octets in the hash + SHA$$$HashSizeBits number of bits in the hash + SHA$$$_Message_Block_Size + number of octets used in the intermediate + message blocks + shaSuccess = 0 constant returned by each function on success + shaNull = 1 constant returned by each function when + presented with a null pointer parameter + shaInputTooLong = 2 constant returned by each function when the + input data is too long + shaStateError constant returned by each function when + SHA$$$Input is called after SHA$$$FinalBits or + SHA$$$Result. + + Structure: + typedef SHA$$$Context + an opaque structure holding the complete state + for producing the hash + + Functions: + int SHA$$$Reset(SHA$$$Context *); + Reset the hash context state + int SHA$$$Input(SHA$$$Context *, const uint8_t *octets, + unsigned int bytecount); + Incorporate bytecount octets into the hash. + int SHA$$$FinalBits(SHA$$$Context *, const uint8_t octet, + unsigned int bitcount); + Incorporate bitcount bits into the hash. The bits are in + the upper portion of the octet. SHA$$$Input() cannot be + called after this. + int SHA$$$Result(SHA$$$Context *, + uint8_t Message_Digest[SHA$$$HashSize]); + Do the final calculations on the hash and copy the value + into Message_Digest. + + In addition, functions with the prefix USHA are provided that take a + SHAversion value (SHA$$$) to select the SHA function suite. They add + the following constants, structure, and functions: + + Constants: + shaBadParam constant returned by USHA functions when + presented with a bad SHAversion (SHA$$$) + parameter + + + + +Eastlake 3rd & Hansen Informational [Page 16] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + SHA$$$ SHAversion enumeration values, used by usha + and hmac functions to select the SHA function + suite + + Structure: + typedef USHAContext + an opaque structure holding the complete state + for producing the hash + + Functions: + int USHAReset(USHAContext *, SHAversion whichSha); + Reset the hash context state. + int USHAInput(USHAContext *, + const uint8_t *bytes, unsigned int bytecount); + Incorporate bytecount octets into the hash. + int USHAFinalBits(USHAContext *, + const uint8_t bits, unsigned int bitcount); + Incorporate bitcount bits into the hash. + int USHAResult(USHAContext *, + uint8_t Message_Digest[USHAMaxHashSize]); + Do the final calculations on the hash and copy the value + into Message_Digest. Octets in Message_Digest beyond + USHAHashSize(whichSha) are left untouched. + int USHAHashSize(enum SHAversion whichSha); + The number of octets in the given hash. + int USHAHashSizeBits(enum SHAversion whichSha); + The number of bits in the given hash. + int USHABlockSize(enum SHAversion whichSha); + The internal block size for the given hash. + + The hmac functions follow the same pattern to allow any length of + text input to be used. + + Structure: + typedef HMACContext an opaque structure holding the complete state + for producing the hash + + Functions: + int hmacReset(HMACContext *ctx, enum SHAversion whichSha, + const unsigned char *key, int key_len); + Reset the hash context state. + int hmacInput(HMACContext *ctx, const unsigned char *text, + int text_len); + Incorporate text_len octets into the hash. + int hmacFinalBits(HMACContext *ctx, const uint8_t bits, + unsigned int bitcount); + Incorporate bitcount bits into the hash. + + + + +Eastlake 3rd & Hansen Informational [Page 17] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + int hmacResult(HMACContext *ctx, + uint8_t Message_Digest[USHAMaxHashSize]); + Do the final calculations on the hash and copy the value + into Message_Digest. Octets in Message_Digest beyond + USHAHashSize(whichSha) are left untouched. + + In addition, a combined interface is provided, similar to that shown + in RFC 2104, that allows a fixed-length text input to be used. + + int hmac(SHAversion whichSha, + const unsigned char *text, int text_len, + const unsigned char *key, int key_len, + uint8_t Message_Digest[USHAMaxHashSize]); + Calculate the given digest for the given text and key, and + return the resulting hash. Octets in Message_Digest beyond + USHAHashSize(whichSha) are left untouched. + +8.1. The .h File + +/**************************** sha.h ****************************/ +/******************* See RFC 4634 for details ******************/ +#ifndef _SHA_H_ +#define _SHA_H_ + +/* + * Description: + * This file implements the Secure Hash Signature Standard + * algorithms as defined in the National Institute of Standards + * and Technology Federal Information Processing Standards + * Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2 + * published on August 1, 2002, and the FIPS PUB 180-2 Change + * Notice published on February 28, 2004. + * + * A combined document showing all algorithms is available at + * http://csrc.nist.gov/publications/fips/ + * fips180-2/fips180-2withchangenotice.pdf + * + * The five hashes are defined in these sizes: + * SHA-1 20 byte / 160 bit + * SHA-224 28 byte / 224 bit + * SHA-256 32 byte / 256 bit + * SHA-384 48 byte / 384 bit + * SHA-512 64 byte / 512 bit + */ + +#include <stdint.h> +/* + * If you do not have the ISO standard stdint.h header file, then you + + + +Eastlake 3rd & Hansen Informational [Page 18] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * must typedef the following: + * name meaning + * uint64_t unsigned 64 bit integer + * uint32_t unsigned 32 bit integer + * uint8_t unsigned 8 bit integer (i.e., unsigned char) + * int_least16_t integer of >= 16 bits + * + */ + +#ifndef _SHA_enum_ +#define _SHA_enum_ +/* + * All SHA functions return one of these values. + */ +enum { + shaSuccess = 0, + shaNull, /* Null pointer parameter */ + shaInputTooLong, /* input data too long */ + shaStateError, /* called Input after FinalBits or Result */ + shaBadParam /* passed a bad parameter */ +}; +#endif /* _SHA_enum_ */ + +/* + * These constants hold size information for each of the SHA + * hashing operations + */ +enum { + SHA1_Message_Block_Size = 64, SHA224_Message_Block_Size = 64, + SHA256_Message_Block_Size = 64, SHA384_Message_Block_Size = 128, + SHA512_Message_Block_Size = 128, + USHA_Max_Message_Block_Size = SHA512_Message_Block_Size, + + SHA1HashSize = 20, SHA224HashSize = 28, SHA256HashSize = 32, + SHA384HashSize = 48, SHA512HashSize = 64, + USHAMaxHashSize = SHA512HashSize, + + SHA1HashSizeBits = 160, SHA224HashSizeBits = 224, + SHA256HashSizeBits = 256, SHA384HashSizeBits = 384, + SHA512HashSizeBits = 512, USHAMaxHashSizeBits = SHA512HashSizeBits +}; + +/* + * These constants are used in the USHA (unified sha) functions. + */ +typedef enum SHAversion { + SHA1, SHA224, SHA256, SHA384, SHA512 +} SHAversion; + + + +Eastlake 3rd & Hansen Informational [Page 19] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +/* + * This structure will hold context information for the SHA-1 + * hashing operation. + */ +typedef struct SHA1Context { + uint32_t Intermediate_Hash[SHA1HashSize/4]; /* Message Digest */ + + uint32_t Length_Low; /* Message length in bits */ + uint32_t Length_High; /* Message length in bits */ + + int_least16_t Message_Block_Index; /* Message_Block array index */ + /* 512-bit message blocks */ + uint8_t Message_Block[SHA1_Message_Block_Size]; + + int Computed; /* Is the digest computed? */ + int Corrupted; /* Is the digest corrupted? */ +} SHA1Context; + +/* + * This structure will hold context information for the SHA-256 + * hashing operation. + */ +typedef struct SHA256Context { + uint32_t Intermediate_Hash[SHA256HashSize/4]; /* Message Digest */ + + uint32_t Length_Low; /* Message length in bits */ + uint32_t Length_High; /* Message length in bits */ + + int_least16_t Message_Block_Index; /* Message_Block array index */ + /* 512-bit message blocks */ + uint8_t Message_Block[SHA256_Message_Block_Size]; + + int Computed; /* Is the digest computed? */ + int Corrupted; /* Is the digest corrupted? */ +} SHA256Context; + +/* + * This structure will hold context information for the SHA-512 + * hashing operation. + */ +typedef struct SHA512Context { +#ifdef USE_32BIT_ONLY + uint32_t Intermediate_Hash[SHA512HashSize/4]; /* Message Digest */ + uint32_t Length[4]; /* Message length in bits */ +#else /* !USE_32BIT_ONLY */ + uint64_t Intermediate_Hash[SHA512HashSize/8]; /* Message Digest */ + uint64_t Length_Low, Length_High; /* Message length in bits */ +#endif /* USE_32BIT_ONLY */ + + + +Eastlake 3rd & Hansen Informational [Page 20] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + int_least16_t Message_Block_Index; /* Message_Block array index */ + /* 1024-bit message blocks */ + uint8_t Message_Block[SHA512_Message_Block_Size]; + + int Computed; /* Is the digest computed?*/ + int Corrupted; /* Is the digest corrupted? */ +} SHA512Context; + +/* + * This structure will hold context information for the SHA-224 + * hashing operation. It uses the SHA-256 structure for computation. + */ +typedef struct SHA256Context SHA224Context; + +/* + * This structure will hold context information for the SHA-384 + * hashing operation. It uses the SHA-512 structure for computation. + */ +typedef struct SHA512Context SHA384Context; + +/* + * This structure holds context information for all SHA + * hashing operations. + */ +typedef struct USHAContext { + int whichSha; /* which SHA is being used */ + union { + SHA1Context sha1Context; + SHA224Context sha224Context; SHA256Context sha256Context; + SHA384Context sha384Context; SHA512Context sha512Context; + } ctx; +} USHAContext; + +/* + * This structure will hold context information for the HMAC + * keyed hashing operation. + */ +typedef struct HMACContext { + int whichSha; /* which SHA is being used */ + int hashSize; /* hash size of SHA being used */ + int blockSize; /* block size of SHA being used */ + USHAContext shaContext; /* SHA context */ + unsigned char k_opad[USHA_Max_Message_Block_Size]; + /* outer padding - key XORd with opad */ +} HMACContext; + + + + + + +Eastlake 3rd & Hansen Informational [Page 21] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +/* + * Function Prototypes + */ + +/* SHA-1 */ +extern int SHA1Reset(SHA1Context *); +extern int SHA1Input(SHA1Context *, const uint8_t *bytes, + unsigned int bytecount); +extern int SHA1FinalBits(SHA1Context *, const uint8_t bits, + unsigned int bitcount); +extern int SHA1Result(SHA1Context *, + uint8_t Message_Digest[SHA1HashSize]); + +/* SHA-224 */ +extern int SHA224Reset(SHA224Context *); +extern int SHA224Input(SHA224Context *, const uint8_t *bytes, + unsigned int bytecount); +extern int SHA224FinalBits(SHA224Context *, const uint8_t bits, + unsigned int bitcount); +extern int SHA224Result(SHA224Context *, + uint8_t Message_Digest[SHA224HashSize]); + +/* SHA-256 */ +extern int SHA256Reset(SHA256Context *); +extern int SHA256Input(SHA256Context *, const uint8_t *bytes, + unsigned int bytecount); +extern int SHA256FinalBits(SHA256Context *, const uint8_t bits, + unsigned int bitcount); +extern int SHA256Result(SHA256Context *, + uint8_t Message_Digest[SHA256HashSize]); + +/* SHA-384 */ +extern int SHA384Reset(SHA384Context *); +extern int SHA384Input(SHA384Context *, const uint8_t *bytes, + unsigned int bytecount); +extern int SHA384FinalBits(SHA384Context *, const uint8_t bits, + unsigned int bitcount); +extern int SHA384Result(SHA384Context *, + uint8_t Message_Digest[SHA384HashSize]); + +/* SHA-512 */ +extern int SHA512Reset(SHA512Context *); +extern int SHA512Input(SHA512Context *, const uint8_t *bytes, + unsigned int bytecount); +extern int SHA512FinalBits(SHA512Context *, const uint8_t bits, + unsigned int bitcount); +extern int SHA512Result(SHA512Context *, + uint8_t Message_Digest[SHA512HashSize]); + + + +Eastlake 3rd & Hansen Informational [Page 22] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +/* Unified SHA functions, chosen by whichSha */ +extern int USHAReset(USHAContext *, SHAversion whichSha); +extern int USHAInput(USHAContext *, + const uint8_t *bytes, unsigned int bytecount); +extern int USHAFinalBits(USHAContext *, + const uint8_t bits, unsigned int bitcount); +extern int USHAResult(USHAContext *, + uint8_t Message_Digest[USHAMaxHashSize]); +extern int USHABlockSize(enum SHAversion whichSha); +extern int USHAHashSize(enum SHAversion whichSha); +extern int USHAHashSizeBits(enum SHAversion whichSha); + +/* + * HMAC Keyed-Hashing for Message Authentication, RFC2104, + * for all SHAs. + * This interface allows a fixed-length text input to be used. + */ +extern int hmac(SHAversion whichSha, /* which SHA algorithm to use */ + const unsigned char *text, /* pointer to data stream */ + int text_len, /* length of data stream */ + const unsigned char *key, /* pointer to authentication key */ + int key_len, /* length of authentication key */ + uint8_t digest[USHAMaxHashSize]); /* caller digest to fill in */ + +/* + * HMAC Keyed-Hashing for Message Authentication, RFC2104, + * for all SHAs. + * This interface allows any length of text input to be used. + */ +extern int hmacReset(HMACContext *ctx, enum SHAversion whichSha, + const unsigned char *key, int key_len); +extern int hmacInput(HMACContext *ctx, const unsigned char *text, + int text_len); + +extern int hmacFinalBits(HMACContext *ctx, const uint8_t bits, + unsigned int bitcount); +extern int hmacResult(HMACContext *ctx, + uint8_t digest[USHAMaxHashSize]); + +#endif /* _SHA_H_ */ + + + + + + + + + + + +Eastlake 3rd & Hansen Informational [Page 23] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +8.2. The SHA Code + + This code is primarily intended as expository and could be optimized + further. For example, the assignment rotations through the variables + a, b, ..., h could be treated as a cycle and the loop unrolled, + rather than doing the explicit copying. + + Note that there are alternative representations of the Ch() and Maj() + functions controlled by an ifdef. + +8.2.1. sha1.c + +/**************************** sha1.c ****************************/ +/******************** See RFC 4634 for details ******************/ +/* + * Description: + * This file implements the Secure Hash Signature Standard + * algorithms as defined in the National Institute of Standards + * and Technology Federal Information Processing Standards + * Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2 + * published on August 1, 2002, and the FIPS PUB 180-2 Change + * Notice published on February 28, 2004. + * + * A combined document showing all algorithms is available at + * http://csrc.nist.gov/publications/fips/ + * fips180-2/fips180-2withchangenotice.pdf + * + * The SHA-1 algorithm produces a 160-bit message digest for a + * given data stream. It should take about 2**n steps to find a + * message with the same digest as a given message and + * 2**(n/2) to find any two messages with the same digest, + * when n is the digest size in bits. Therefore, this + * algorithm can serve as a means of providing a + * "fingerprint" for a message. + * + * Portability Issues: + * SHA-1 is defined in terms of 32-bit "words". This code + * uses <stdint.h> (included via "sha.h") to define 32 and 8 + * bit unsigned integer types. If your C compiler does not + * support 32 bit unsigned integers, this code is not + * appropriate. + * + * Caveats: + * SHA-1 is designed to work with messages less than 2^64 bits + * long. This implementation uses SHA1Input() to hash the bits + * that are a multiple of the size of an 8-bit character, and then + * uses SHA1FinalBits() to hash the final few bits of the input. + */ + + + +Eastlake 3rd & Hansen Informational [Page 24] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +#include "sha.h" +#include "sha-private.h" + +/* + * Define the SHA1 circular left shift macro + */ +#define SHA1_ROTL(bits,word) \ + (((word) << (bits)) | ((word) >> (32-(bits)))) + +/* + * add "length" to the length + */ +static uint32_t addTemp; +#define SHA1AddLength(context, length) \ + (addTemp = (context)->Length_Low, \ + (context)->Corrupted = \ + (((context)->Length_Low += (length)) < addTemp) && \ + (++(context)->Length_High == 0) ? 1 : 0) + +/* Local Function Prototypes */ +static void SHA1Finalize(SHA1Context *context, uint8_t Pad_Byte); +static void SHA1PadMessage(SHA1Context *, uint8_t Pad_Byte); +static void SHA1ProcessMessageBlock(SHA1Context *); + +/* + * SHA1Reset + * + * Description: + * This function will initialize the SHA1Context in preparation + * for computing a new SHA1 message digest. + * + * Parameters: + * context: [in/out] + * The context to reset. + * + * Returns: + * sha Error Code. + * + */ +int SHA1Reset(SHA1Context *context) +{ + if (!context) + return shaNull; + + context->Length_Low = 0; + context->Length_High = 0; + context->Message_Block_Index = 0; + + + + +Eastlake 3rd & Hansen Informational [Page 25] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + /* Initial Hash Values: FIPS-180-2 section 5.3.1 */ + context->Intermediate_Hash[0] = 0x67452301; + context->Intermediate_Hash[1] = 0xEFCDAB89; + context->Intermediate_Hash[2] = 0x98BADCFE; + context->Intermediate_Hash[3] = 0x10325476; + context->Intermediate_Hash[4] = 0xC3D2E1F0; + + context->Computed = 0; + context->Corrupted = 0; + + return shaSuccess; +} + +/* + * SHA1Input + * + * Description: + * This function accepts an array of octets as the next portion + * of the message. + * + * Parameters: + * context: [in/out] + * The SHA context to update + * message_array: [in] + * An array of characters representing the next portion of + * the message. + * length: [in] + * The length of the message in message_array + * + * Returns: + * sha Error Code. + * + */ +int SHA1Input(SHA1Context *context, + const uint8_t *message_array, unsigned length) +{ + if (!length) + return shaSuccess; + + if (!context || !message_array) + return shaNull; + + if (context->Computed) { + context->Corrupted = shaStateError; + return shaStateError; + } + + if (context->Corrupted) + + + +Eastlake 3rd & Hansen Informational [Page 26] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + return context->Corrupted; + + while (length-- && !context->Corrupted) { + context->Message_Block[context->Message_Block_Index++] = + (*message_array & 0xFF); + + if (!SHA1AddLength(context, 8) && + (context->Message_Block_Index == SHA1_Message_Block_Size)) + SHA1ProcessMessageBlock(context); + + message_array++; + } + + return shaSuccess; +} + +/* + * SHA1FinalBits + * + * Description: + * This function will add in any final bits of the message. + * + * Parameters: + * context: [in/out] + * The SHA context to update + * message_bits: [in] + * The final bits of the message, in the upper portion of the + * byte. (Use 0b###00000 instead of 0b00000### to input the + * three bits ###.) + * length: [in] + * The number of bits in message_bits, between 1 and 7. + * + * Returns: + * sha Error Code. + */ +int SHA1FinalBits(SHA1Context *context, const uint8_t message_bits, + unsigned int length) +{ + uint8_t masks[8] = { + /* 0 0b00000000 */ 0x00, /* 1 0b10000000 */ 0x80, + /* 2 0b11000000 */ 0xC0, /* 3 0b11100000 */ 0xE0, + /* 4 0b11110000 */ 0xF0, /* 5 0b11111000 */ 0xF8, + /* 6 0b11111100 */ 0xFC, /* 7 0b11111110 */ 0xFE + }; + uint8_t markbit[8] = { + /* 0 0b10000000 */ 0x80, /* 1 0b01000000 */ 0x40, + /* 2 0b00100000 */ 0x20, /* 3 0b00010000 */ 0x10, + /* 4 0b00001000 */ 0x08, /* 5 0b00000100 */ 0x04, + + + +Eastlake 3rd & Hansen Informational [Page 27] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + /* 6 0b00000010 */ 0x02, /* 7 0b00000001 */ 0x01 + }; + + if (!length) + return shaSuccess; + + if (!context) + return shaNull; + + if (context->Computed || (length >= 8) || (length == 0)) { + context->Corrupted = shaStateError; + return shaStateError; + } + + if (context->Corrupted) + return context->Corrupted; + + SHA1AddLength(context, length); + SHA1Finalize(context, + (uint8_t) ((message_bits & masks[length]) | markbit[length])); + + return shaSuccess; +} + +/* + * SHA1Result + * + * Description: + * This function will return the 160-bit message digest into the + * Message_Digest array provided by the caller. + * NOTE: The first octet of hash is stored in the 0th element, + * the last octet of hash in the 19th element. + * + * Parameters: + * context: [in/out] + * The context to use to calculate the SHA-1 hash. + * Message_Digest: [out] + * Where the digest is returned. + * + * Returns: + * sha Error Code. + * + */ +int SHA1Result(SHA1Context *context, + uint8_t Message_Digest[SHA1HashSize]) +{ + int i; + + + + +Eastlake 3rd & Hansen Informational [Page 28] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + if (!context || !Message_Digest) + return shaNull; + + if (context->Corrupted) + return context->Corrupted; + + if (!context->Computed) + SHA1Finalize(context, 0x80); + + for (i = 0; i < SHA1HashSize; ++i) + Message_Digest[i] = (uint8_t) (context->Intermediate_Hash[i>>2] + >> 8 * ( 3 - ( i & 0x03 ) )); + + return shaSuccess; +} + +/* + * SHA1Finalize + * + * Description: + * This helper function finishes off the digest calculations. + * + * Parameters: + * context: [in/out] + * The SHA context to update + * Pad_Byte: [in] + * The last byte to add to the digest before the 0-padding + * and length. This will contain the last bits of the message + * followed by another single bit. If the message was an + * exact multiple of 8-bits long, Pad_Byte will be 0x80. + * + * Returns: + * sha Error Code. + * + */ +static void SHA1Finalize(SHA1Context *context, uint8_t Pad_Byte) +{ + int i; + SHA1PadMessage(context, Pad_Byte); + /* message may be sensitive, clear it out */ + for (i = 0; i < SHA1_Message_Block_Size; ++i) + context->Message_Block[i] = 0; + context->Length_Low = 0; /* and clear length */ + context->Length_High = 0; + context->Computed = 1; +} + +/* + + + +Eastlake 3rd & Hansen Informational [Page 29] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * SHA1PadMessage + * + * Description: + * According to the standard, the message must be padded to an + * even 512 bits. The first padding bit must be a '1'. The last + * 64 bits represent the length of the original message. All bits + * in between should be 0. This helper function will pad the + * message according to those rules by filling the Message_Block + * array accordingly. When it returns, it can be assumed that the + * message digest has been computed. + * + * Parameters: + * context: [in/out] + * The context to pad + * Pad_Byte: [in] + * The last byte to add to the digest before the 0-padding + * and length. This will contain the last bits of the message + * followed by another single bit. If the message was an + * exact multiple of 8-bits long, Pad_Byte will be 0x80. + * + * Returns: + * Nothing. + */ +static void SHA1PadMessage(SHA1Context *context, uint8_t Pad_Byte) +{ + /* + * Check to see if the current message block is too small to hold + * the initial padding bits and length. If so, we will pad the + * block, process it, and then continue padding into a second + * block. + */ + if (context->Message_Block_Index >= (SHA1_Message_Block_Size - 8)) { + context->Message_Block[context->Message_Block_Index++] = Pad_Byte; + while (context->Message_Block_Index < SHA1_Message_Block_Size) + context->Message_Block[context->Message_Block_Index++] = 0; + + SHA1ProcessMessageBlock(context); + } else + context->Message_Block[context->Message_Block_Index++] = Pad_Byte; + + while (context->Message_Block_Index < (SHA1_Message_Block_Size - 8)) + context->Message_Block[context->Message_Block_Index++] = 0; + + /* + * Store the message length as the last 8 octets + */ + context->Message_Block[56] = (uint8_t) (context->Length_High >> 24); + context->Message_Block[57] = (uint8_t) (context->Length_High >> 16); + + + +Eastlake 3rd & Hansen Informational [Page 30] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + context->Message_Block[58] = (uint8_t) (context->Length_High >> 8); + context->Message_Block[59] = (uint8_t) (context->Length_High); + context->Message_Block[60] = (uint8_t) (context->Length_Low >> 24); + context->Message_Block[61] = (uint8_t) (context->Length_Low >> 16); + context->Message_Block[62] = (uint8_t) (context->Length_Low >> 8); + context->Message_Block[63] = (uint8_t) (context->Length_Low); + + SHA1ProcessMessageBlock(context); +} + +/* + * SHA1ProcessMessageBlock + * + * Description: + * This helper function will process the next 512 bits of the + * message stored in the Message_Block array. + * + * Parameters: + * None. + * + * Returns: + * Nothing. + * + * Comments: + * Many of the variable names in this code, especially the + * single character names, were used because those were the + * names used in the publication. + */ +static void SHA1ProcessMessageBlock(SHA1Context *context) +{ + /* Constants defined in FIPS-180-2, section 4.2.1 */ + const uint32_t K[4] = { + 0x5A827999, 0x6ED9EBA1, 0x8F1BBCDC, 0xCA62C1D6 + }; + int t; /* Loop counter */ + uint32_t temp; /* Temporary word value */ + uint32_t W[80]; /* Word sequence */ + uint32_t A, B, C, D, E; /* Word buffers */ + + /* + * Initialize the first 16 words in the array W + */ + for (t = 0; t < 16; t++) { + W[t] = ((uint32_t)context->Message_Block[t * 4]) << 24; + W[t] |= ((uint32_t)context->Message_Block[t * 4 + 1]) << 16; + W[t] |= ((uint32_t)context->Message_Block[t * 4 + 2]) << 8; + W[t] |= ((uint32_t)context->Message_Block[t * 4 + 3]); + } + + + +Eastlake 3rd & Hansen Informational [Page 31] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + for (t = 16; t < 80; t++) + W[t] = SHA1_ROTL(1, W[t-3] ^ W[t-8] ^ W[t-14] ^ W[t-16]); + + A = context->Intermediate_Hash[0]; + B = context->Intermediate_Hash[1]; + C = context->Intermediate_Hash[2]; + D = context->Intermediate_Hash[3]; + E = context->Intermediate_Hash[4]; + + for (t = 0; t < 20; t++) { + temp = SHA1_ROTL(5,A) + SHA_Ch(B, C, D) + E + W[t] + K[0]; + E = D; + D = C; + C = SHA1_ROTL(30,B); + B = A; + A = temp; + } + + for (t = 20; t < 40; t++) { + temp = SHA1_ROTL(5,A) + SHA_Parity(B, C, D) + E + W[t] + K[1]; + E = D; + D = C; + C = SHA1_ROTL(30,B); + B = A; + A = temp; + } + + for (t = 40; t < 60; t++) { + temp = SHA1_ROTL(5,A) + SHA_Maj(B, C, D) + E + W[t] + K[2]; + E = D; + D = C; + C = SHA1_ROTL(30,B); + B = A; + A = temp; + } + + for (t = 60; t < 80; t++) { + temp = SHA1_ROTL(5,A) + SHA_Parity(B, C, D) + E + W[t] + K[3]; + E = D; + D = C; + C = SHA1_ROTL(30,B); + B = A; + A = temp; + } + + context->Intermediate_Hash[0] += A; + context->Intermediate_Hash[1] += B; + context->Intermediate_Hash[2] += C; + + + +Eastlake 3rd & Hansen Informational [Page 32] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + context->Intermediate_Hash[3] += D; + context->Intermediate_Hash[4] += E; + + context->Message_Block_Index = 0; +} + +8.2.2. sha224-256.c + +/*************************** sha224-256.c ***************************/ +/********************* See RFC 4634 for details *********************/ +/* + * Description: + * This file implements the Secure Hash Signature Standard + * algorithms as defined in the National Institute of Standards + * and Technology Federal Information Processing Standards + * Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2 + * published on August 1, 2002, and the FIPS PUB 180-2 Change + * Notice published on February 28, 2004. + * + * A combined document showing all algorithms is available at + * http://csrc.nist.gov/publications/fips/ + * fips180-2/fips180-2withchangenotice.pdf + * + * The SHA-224 and SHA-256 algorithms produce 224-bit and 256-bit + * message digests for a given data stream. It should take about + * 2**n steps to find a message with the same digest as a given + * message and 2**(n/2) to find any two messages with the same + * digest, when n is the digest size in bits. Therefore, this + * algorithm can serve as a means of providing a + * "fingerprint" for a message. + * + * Portability Issues: + * SHA-224 and SHA-256 are defined in terms of 32-bit "words". + * This code uses <stdint.h> (included via "sha.h") to define 32 + * and 8 bit unsigned integer types. If your C compiler does not + * support 32 bit unsigned integers, this code is not + * appropriate. + * + * Caveats: + * SHA-224 and SHA-256 are designed to work with messages less + * than 2^64 bits long. This implementation uses SHA224/256Input() + * to hash the bits that are a multiple of the size of an 8-bit + * character, and then uses SHA224/256FinalBits() to hash the + * final few bits of the input. + */ + +#include "sha.h" +#include "sha-private.h" + + + +Eastlake 3rd & Hansen Informational [Page 33] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +/* Define the SHA shift, rotate left and rotate right macro */ +#define SHA256_SHR(bits,word) ((word) >> (bits)) +#define SHA256_ROTL(bits,word) \ + (((word) << (bits)) | ((word) >> (32-(bits)))) +#define SHA256_ROTR(bits,word) \ + (((word) >> (bits)) | ((word) << (32-(bits)))) + +/* Define the SHA SIGMA and sigma macros */ +#define SHA256_SIGMA0(word) \ + (SHA256_ROTR( 2,word) ^ SHA256_ROTR(13,word) ^ SHA256_ROTR(22,word)) +#define SHA256_SIGMA1(word) \ + (SHA256_ROTR( 6,word) ^ SHA256_ROTR(11,word) ^ SHA256_ROTR(25,word)) +#define SHA256_sigma0(word) \ + (SHA256_ROTR( 7,word) ^ SHA256_ROTR(18,word) ^ SHA256_SHR( 3,word)) +#define SHA256_sigma1(word) \ + (SHA256_ROTR(17,word) ^ SHA256_ROTR(19,word) ^ SHA256_SHR(10,word)) + +/* + * add "length" to the length + */ +static uint32_t addTemp; +#define SHA224_256AddLength(context, length) \ + (addTemp = (context)->Length_Low, (context)->Corrupted = \ + (((context)->Length_Low += (length)) < addTemp) && \ + (++(context)->Length_High == 0) ? 1 : 0) + +/* Local Function Prototypes */ +static void SHA224_256Finalize(SHA256Context *context, + uint8_t Pad_Byte); +static void SHA224_256PadMessage(SHA256Context *context, + uint8_t Pad_Byte); +static void SHA224_256ProcessMessageBlock(SHA256Context *context); +static int SHA224_256Reset(SHA256Context *context, uint32_t *H0); +static int SHA224_256ResultN(SHA256Context *context, + uint8_t Message_Digest[], int HashSize); + +/* Initial Hash Values: FIPS-180-2 Change Notice 1 */ +static uint32_t SHA224_H0[SHA256HashSize/4] = { + 0xC1059ED8, 0x367CD507, 0x3070DD17, 0xF70E5939, + 0xFFC00B31, 0x68581511, 0x64F98FA7, 0xBEFA4FA4 +}; + +/* Initial Hash Values: FIPS-180-2 section 5.3.2 */ +static uint32_t SHA256_H0[SHA256HashSize/4] = { + 0x6A09E667, 0xBB67AE85, 0x3C6EF372, 0xA54FF53A, + 0x510E527F, 0x9B05688C, 0x1F83D9AB, 0x5BE0CD19 +}; + + + + +Eastlake 3rd & Hansen Informational [Page 34] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +/* + * SHA224Reset + * + * Description: + * This function will initialize the SHA384Context in preparation + * for computing a new SHA224 message digest. + * + * Parameters: + * context: [in/out] + * The context to reset. + * + * Returns: + * sha Error Code. + */ +int SHA224Reset(SHA224Context *context) +{ + return SHA224_256Reset(context, SHA224_H0); +} + +/* + * SHA224Input + * + * Description: + * This function accepts an array of octets as the next portion + * of the message. + * + * Parameters: + * context: [in/out] + * The SHA context to update + * message_array: [in] + * An array of characters representing the next portion of + * the message. + * length: [in] + * The length of the message in message_array + * + * Returns: + * sha Error Code. + * + */ +int SHA224Input(SHA224Context *context, const uint8_t *message_array, + unsigned int length) +{ + return SHA256Input(context, message_array, length); +} + +/* + * SHA224FinalBits + * + + + +Eastlake 3rd & Hansen Informational [Page 35] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * Description: + * This function will add in any final bits of the message. + * + * Parameters: + * context: [in/out] + * The SHA context to update + * message_bits: [in] + * The final bits of the message, in the upper portion of the + * byte. (Use 0b###00000 instead of 0b00000### to input the + * three bits ###.) + * length: [in] + * The number of bits in message_bits, between 1 and 7. + * + * Returns: + * sha Error Code. + */ +int SHA224FinalBits( SHA224Context *context, + const uint8_t message_bits, unsigned int length) +{ + return SHA256FinalBits(context, message_bits, length); +} + +/* + * SHA224Result + * + * Description: + * This function will return the 224-bit message + * digest into the Message_Digest array provided by the caller. + * NOTE: The first octet of hash is stored in the 0th element, + * the last octet of hash in the 28th element. + * + * Parameters: + * context: [in/out] + * The context to use to calculate the SHA hash. + * Message_Digest: [out] + * Where the digest is returned. + * + * Returns: + * sha Error Code. + */ +int SHA224Result(SHA224Context *context, + uint8_t Message_Digest[SHA224HashSize]) +{ + return SHA224_256ResultN(context, Message_Digest, SHA224HashSize); +} + +/* + * SHA256Reset + + + +Eastlake 3rd & Hansen Informational [Page 36] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * + * Description: + * This function will initialize the SHA256Context in preparation + * for computing a new SHA256 message digest. + * + * Parameters: + * context: [in/out] + * The context to reset. + * + * Returns: + * sha Error Code. + */ +int SHA256Reset(SHA256Context *context) +{ + return SHA224_256Reset(context, SHA256_H0); +} + +/* + * SHA256Input + * + * Description: + * This function accepts an array of octets as the next portion + * of the message. + * + * Parameters: + * context: [in/out] + * The SHA context to update + * message_array: [in] + * An array of characters representing the next portion of + * the message. + * length: [in] + * The length of the message in message_array + * + * Returns: + * sha Error Code. + */ +int SHA256Input(SHA256Context *context, const uint8_t *message_array, + unsigned int length) +{ + if (!length) + return shaSuccess; + + if (!context || !message_array) + return shaNull; + + if (context->Computed) { + context->Corrupted = shaStateError; + return shaStateError; + + + +Eastlake 3rd & Hansen Informational [Page 37] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + } + + if (context->Corrupted) + return context->Corrupted; + + while (length-- && !context->Corrupted) { + context->Message_Block[context->Message_Block_Index++] = + (*message_array & 0xFF); + + if (!SHA224_256AddLength(context, 8) && + (context->Message_Block_Index == SHA256_Message_Block_Size)) + SHA224_256ProcessMessageBlock(context); + + message_array++; + } + + return shaSuccess; + +} + +/* + * SHA256FinalBits + * + * Description: + * This function will add in any final bits of the message. + * + * Parameters: + * context: [in/out] + * The SHA context to update + * message_bits: [in] + * The final bits of the message, in the upper portion of the + * byte. (Use 0b###00000 instead of 0b00000### to input the + * three bits ###.) + * length: [in] + * The number of bits in message_bits, between 1 and 7. + * + * Returns: + * sha Error Code. + */ +int SHA256FinalBits(SHA256Context *context, + const uint8_t message_bits, unsigned int length) +{ + uint8_t masks[8] = { + /* 0 0b00000000 */ 0x00, /* 1 0b10000000 */ 0x80, + /* 2 0b11000000 */ 0xC0, /* 3 0b11100000 */ 0xE0, + /* 4 0b11110000 */ 0xF0, /* 5 0b11111000 */ 0xF8, + /* 6 0b11111100 */ 0xFC, /* 7 0b11111110 */ 0xFE + }; + + + +Eastlake 3rd & Hansen Informational [Page 38] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + uint8_t markbit[8] = { + /* 0 0b10000000 */ 0x80, /* 1 0b01000000 */ 0x40, + /* 2 0b00100000 */ 0x20, /* 3 0b00010000 */ 0x10, + /* 4 0b00001000 */ 0x08, /* 5 0b00000100 */ 0x04, + /* 6 0b00000010 */ 0x02, /* 7 0b00000001 */ 0x01 + }; + + if (!length) + return shaSuccess; + + if (!context) + return shaNull; + + if ((context->Computed) || (length >= 8) || (length == 0)) { + context->Corrupted = shaStateError; + return shaStateError; + } + + if (context->Corrupted) + return context->Corrupted; + + SHA224_256AddLength(context, length); + SHA224_256Finalize(context, (uint8_t) + ((message_bits & masks[length]) | markbit[length])); + + return shaSuccess; +} + +/* + * SHA256Result + * + * Description: + * This function will return the 256-bit message + * digest into the Message_Digest array provided by the caller. + * NOTE: The first octet of hash is stored in the 0th element, + * the last octet of hash in the 32nd element. + * + * Parameters: + * context: [in/out] + * The context to use to calculate the SHA hash. + * Message_Digest: [out] + * Where the digest is returned. + * + * Returns: + * sha Error Code. + */ +int SHA256Result(SHA256Context *context, uint8_t Message_Digest[]) +{ + + + +Eastlake 3rd & Hansen Informational [Page 39] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + return SHA224_256ResultN(context, Message_Digest, SHA256HashSize); +} + +/* + * SHA224_256Finalize + * + * Description: + * This helper function finishes off the digest calculations. + * + * Parameters: + * context: [in/out] + * The SHA context to update + * Pad_Byte: [in] + * The last byte to add to the digest before the 0-padding + * and length. This will contain the last bits of the message + * followed by another single bit. If the message was an + * exact multiple of 8-bits long, Pad_Byte will be 0x80. + * + * Returns: + * sha Error Code. + */ +static void SHA224_256Finalize(SHA256Context *context, + uint8_t Pad_Byte) +{ + int i; + SHA224_256PadMessage(context, Pad_Byte); + /* message may be sensitive, so clear it out */ + for (i = 0; i < SHA256_Message_Block_Size; ++i) + context->Message_Block[i] = 0; + context->Length_Low = 0; /* and clear length */ + context->Length_High = 0; + context->Computed = 1; +} + +/* + * SHA224_256PadMessage + * + * Description: + * According to the standard, the message must be padded to an + * even 512 bits. The first padding bit must be a '1'. The + * last 64 bits represent the length of the original message. + * All bits in between should be 0. This helper function will pad + * the message according to those rules by filling the + * Message_Block array accordingly. When it returns, it can be + * assumed that the message digest has been computed. + * + * Parameters: + * context: [in/out] + + + +Eastlake 3rd & Hansen Informational [Page 40] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * The context to pad + * Pad_Byte: [in] + * The last byte to add to the digest before the 0-padding + * and length. This will contain the last bits of the message + * followed by another single bit. If the message was an + * exact multiple of 8-bits long, Pad_Byte will be 0x80. + * + * Returns: + * Nothing. + */ +static void SHA224_256PadMessage(SHA256Context *context, + uint8_t Pad_Byte) +{ + /* + * Check to see if the current message block is too small to hold + * the initial padding bits and length. If so, we will pad the + * block, process it, and then continue padding into a second + * block. + */ + if (context->Message_Block_Index >= (SHA256_Message_Block_Size-8)) { + context->Message_Block[context->Message_Block_Index++] = Pad_Byte; + while (context->Message_Block_Index < SHA256_Message_Block_Size) + context->Message_Block[context->Message_Block_Index++] = 0; + SHA224_256ProcessMessageBlock(context); + } else + context->Message_Block[context->Message_Block_Index++] = Pad_Byte; + + while (context->Message_Block_Index < (SHA256_Message_Block_Size-8)) + context->Message_Block[context->Message_Block_Index++] = 0; + + /* + * Store the message length as the last 8 octets + */ + context->Message_Block[56] = (uint8_t)(context->Length_High >> 24); + context->Message_Block[57] = (uint8_t)(context->Length_High >> 16); + context->Message_Block[58] = (uint8_t)(context->Length_High >> 8); + context->Message_Block[59] = (uint8_t)(context->Length_High); + context->Message_Block[60] = (uint8_t)(context->Length_Low >> 24); + context->Message_Block[61] = (uint8_t)(context->Length_Low >> 16); + context->Message_Block[62] = (uint8_t)(context->Length_Low >> 8); + context->Message_Block[63] = (uint8_t)(context->Length_Low); + + SHA224_256ProcessMessageBlock(context); +} + +/* + * SHA224_256ProcessMessageBlock + * + + + +Eastlake 3rd & Hansen Informational [Page 41] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * Description: + * This function will process the next 512 bits of the message + * stored in the Message_Block array. + * + * Parameters: + * context: [in/out] + * The SHA context to update + * + * Returns: + * Nothing. + * + * Comments: + * Many of the variable names in this code, especially the + * single character names, were used because those were the + * names used in the publication. + */ +static void SHA224_256ProcessMessageBlock(SHA256Context *context) +{ + /* Constants defined in FIPS-180-2, section 4.2.2 */ + static const uint32_t K[64] = { + 0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5, 0x3956c25b, + 0x59f111f1, 0x923f82a4, 0xab1c5ed5, 0xd807aa98, 0x12835b01, + 0x243185be, 0x550c7dc3, 0x72be5d74, 0x80deb1fe, 0x9bdc06a7, + 0xc19bf174, 0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc, + 0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da, 0x983e5152, + 0xa831c66d, 0xb00327c8, 0xbf597fc7, 0xc6e00bf3, 0xd5a79147, + 0x06ca6351, 0x14292967, 0x27b70a85, 0x2e1b2138, 0x4d2c6dfc, + 0x53380d13, 0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85, + 0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3, 0xd192e819, + 0xd6990624, 0xf40e3585, 0x106aa070, 0x19a4c116, 0x1e376c08, + 0x2748774c, 0x34b0bcb5, 0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f, + 0x682e6ff3, 0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208, + 0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2 + }; + int t, t4; /* Loop counter */ + uint32_t temp1, temp2; /* Temporary word value */ + uint32_t W[64]; /* Word sequence */ + uint32_t A, B, C, D, E, F, G, H; /* Word buffers */ + + /* + * Initialize the first 16 words in the array W + */ + for (t = t4 = 0; t < 16; t++, t4 += 4) + W[t] = (((uint32_t)context->Message_Block[t4]) << 24) | + (((uint32_t)context->Message_Block[t4 + 1]) << 16) | + (((uint32_t)context->Message_Block[t4 + 2]) << 8) | + (((uint32_t)context->Message_Block[t4 + 3])); + + + + +Eastlake 3rd & Hansen Informational [Page 42] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + for (t = 16; t < 64; t++) + W[t] = SHA256_sigma1(W[t-2]) + W[t-7] + + SHA256_sigma0(W[t-15]) + W[t-16]; + + A = context->Intermediate_Hash[0]; + B = context->Intermediate_Hash[1]; + C = context->Intermediate_Hash[2]; + D = context->Intermediate_Hash[3]; + E = context->Intermediate_Hash[4]; + F = context->Intermediate_Hash[5]; + G = context->Intermediate_Hash[6]; + H = context->Intermediate_Hash[7]; + + for (t = 0; t < 64; t++) { + temp1 = H + SHA256_SIGMA1(E) + SHA_Ch(E,F,G) + K[t] + W[t]; + temp2 = SHA256_SIGMA0(A) + SHA_Maj(A,B,C); + H = G; + G = F; + F = E; + E = D + temp1; + D = C; + C = B; + B = A; + A = temp1 + temp2; + } + + context->Intermediate_Hash[0] += A; + context->Intermediate_Hash[1] += B; + context->Intermediate_Hash[2] += C; + context->Intermediate_Hash[3] += D; + context->Intermediate_Hash[4] += E; + context->Intermediate_Hash[5] += F; + context->Intermediate_Hash[6] += G; + context->Intermediate_Hash[7] += H; + + context->Message_Block_Index = 0; +} + +/* + * SHA224_256Reset + * + * Description: + * This helper function will initialize the SHA256Context in + * preparation for computing a new SHA256 message digest. + * + * Parameters: + * context: [in/out] + * The context to reset. + + + +Eastlake 3rd & Hansen Informational [Page 43] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * H0 + * The initial hash value to use. + * + * Returns: + * sha Error Code. + */ +static int SHA224_256Reset(SHA256Context *context, uint32_t *H0) +{ + if (!context) + return shaNull; + + context->Length_Low = 0; + context->Length_High = 0; + context->Message_Block_Index = 0; + + context->Intermediate_Hash[0] = H0[0]; + context->Intermediate_Hash[1] = H0[1]; + context->Intermediate_Hash[2] = H0[2]; + context->Intermediate_Hash[3] = H0[3]; + context->Intermediate_Hash[4] = H0[4]; + context->Intermediate_Hash[5] = H0[5]; + context->Intermediate_Hash[6] = H0[6]; + context->Intermediate_Hash[7] = H0[7]; + + context->Computed = 0; + context->Corrupted = 0; + + return shaSuccess; +} + +/* + * SHA224_256ResultN + * + * Description: + * This helper function will return the 224-bit or 256-bit message + * digest into the Message_Digest array provided by the caller. + * NOTE: The first octet of hash is stored in the 0th element, + * the last octet of hash in the 28th/32nd element. + * + * Parameters: + * context: [in/out] + * The context to use to calculate the SHA hash. + * Message_Digest: [out] + * Where the digest is returned. + * HashSize: [in] + * The size of the hash, either 28 or 32. + * + * Returns: + + + +Eastlake 3rd & Hansen Informational [Page 44] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * sha Error Code. + */ +static int SHA224_256ResultN(SHA256Context *context, + uint8_t Message_Digest[], int HashSize) +{ + int i; + + if (!context || !Message_Digest) + return shaNull; + + if (context->Corrupted) + return context->Corrupted; + + if (!context->Computed) + SHA224_256Finalize(context, 0x80); + + for (i = 0; i < HashSize; ++i) + Message_Digest[i] = (uint8_t) + (context->Intermediate_Hash[i>>2] >> 8 * ( 3 - ( i & 0x03 ) )); + + return shaSuccess; +} + +8.2.3. sha384-512.c + +/*************************** sha384-512.c ***************************/ +/********************* See RFC 4634 for details *********************/ +/* + * Description: + * This file implements the Secure Hash Signature Standard + * algorithms as defined in the National Institute of Standards + * and Technology Federal Information Processing Standards + * Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2 + * published on August 1, 2002, and the FIPS PUB 180-2 Change + * Notice published on February 28, 2004. + * + * A combined document showing all algorithms is available at + * http://csrc.nist.gov/publications/fips/ + * fips180-2/fips180-2withchangenotice.pdf + * + * The SHA-384 and SHA-512 algorithms produce 384-bit and 512-bit + * message digests for a given data stream. It should take about + * 2**n steps to find a message with the same digest as a given + * message and 2**(n/2) to find any two messages with the same + * digest, when n is the digest size in bits. Therefore, this + * algorithm can serve as a means of providing a + * "fingerprint" for a message. + * + + + +Eastlake 3rd & Hansen Informational [Page 45] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * Portability Issues: + * SHA-384 and SHA-512 are defined in terms of 64-bit "words", + * but if USE_32BIT_ONLY is #defined, this code is implemented in + * terms of 32-bit "words". This code uses <stdint.h> (included + * via "sha.h") to define the 64, 32 and 8 bit unsigned integer + * types. If your C compiler does not support 64 bit unsigned + * integers, and you do not #define USE_32BIT_ONLY, this code is + * not appropriate. + * + * Caveats: + * SHA-384 and SHA-512 are designed to work with messages less + * than 2^128 bits long. This implementation uses + * SHA384/512Input() to hash the bits that are a multiple of the + * size of an 8-bit character, and then uses SHA384/256FinalBits() + * to hash the final few bits of the input. + * + */ + +#include "sha.h" +#include "sha-private.h" + +#ifdef USE_32BIT_ONLY +/* + * Define 64-bit arithmetic in terms of 32-bit arithmetic. + * Each 64-bit number is represented in a 2-word array. + * All macros are defined such that the result is the last parameter. + */ + +/* + * Define shift, rotate left and rotate right functions + */ +#define SHA512_SHR(bits, word, ret) ( \ + /* (((uint64_t)((word))) >> (bits)) */ \ + (ret)[0] = (((bits) < 32) && ((bits) >= 0)) ? \ + ((word)[0] >> (bits)) : 0, \ + (ret)[1] = ((bits) > 32) ? ((word)[0] >> ((bits) - 32)) : \ + ((bits) == 32) ? (word)[0] : \ + ((bits) >= 0) ? \ + (((word)[0] << (32 - (bits))) | \ + ((word)[1] >> (bits))) : 0 ) + +#define SHA512_SHL(bits, word, ret) ( \ + /* (((uint64_t)(word)) << (bits)) */ \ + (ret)[0] = ((bits) > 32) ? ((word)[1] << ((bits) - 32)) : \ + ((bits) == 32) ? (word)[1] : \ + ((bits) >= 0) ? \ + (((word)[0] << (bits)) | \ + ((word)[1] >> (32 - (bits)))) : \ + + + +Eastlake 3rd & Hansen Informational [Page 46] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + 0, \ + (ret)[1] = (((bits) < 32) && ((bits) >= 0)) ? \ + ((word)[1] << (bits)) : 0 ) + +/* + * Define 64-bit OR + */ +#define SHA512_OR(word1, word2, ret) ( \ + (ret)[0] = (word1)[0] | (word2)[0], \ + (ret)[1] = (word1)[1] | (word2)[1] ) + +/* + * Define 64-bit XOR + */ +#define SHA512_XOR(word1, word2, ret) ( \ + (ret)[0] = (word1)[0] ^ (word2)[0], \ + (ret)[1] = (word1)[1] ^ (word2)[1] ) + +/* + * Define 64-bit AND + */ +#define SHA512_AND(word1, word2, ret) ( \ + (ret)[0] = (word1)[0] & (word2)[0], \ + (ret)[1] = (word1)[1] & (word2)[1] ) + +/* + * Define 64-bit TILDA + */ +#define SHA512_TILDA(word, ret) \ + ( (ret)[0] = ~(word)[0], (ret)[1] = ~(word)[1] ) + +/* + * Define 64-bit ADD + */ +#define SHA512_ADD(word1, word2, ret) ( \ + (ret)[1] = (word1)[1], (ret)[1] += (word2)[1], \ + (ret)[0] = (word1)[0] + (word2)[0] + ((ret)[1] < (word1)[1]) ) + +/* + * Add the 4word value in word2 to word1. + */ +static uint32_t ADDTO4_temp, ADDTO4_temp2; +#define SHA512_ADDTO4(word1, word2) ( \ + ADDTO4_temp = (word1)[3], \ + (word1)[3] += (word2)[3], \ + ADDTO4_temp2 = (word1)[2], \ + (word1)[2] += (word2)[2] + ((word1)[3] < ADDTO4_temp), \ + ADDTO4_temp = (word1)[1], \ + + + +Eastlake 3rd & Hansen Informational [Page 47] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + (word1)[1] += (word2)[1] + ((word1)[2] < ADDTO4_temp2), \ + (word1)[0] += (word2)[0] + ((word1)[1] < ADDTO4_temp) ) + +/* + * Add the 2word value in word2 to word1. + */ +static uint32_t ADDTO2_temp; +#define SHA512_ADDTO2(word1, word2) ( \ + ADDTO2_temp = (word1)[1], \ + (word1)[1] += (word2)[1], \ + (word1)[0] += (word2)[0] + ((word1)[1] < ADDTO2_temp) ) + +/* + * SHA rotate ((word >> bits) | (word << (64-bits))) + */ +static uint32_t ROTR_temp1[2], ROTR_temp2[2]; +#define SHA512_ROTR(bits, word, ret) ( \ + SHA512_SHR((bits), (word), ROTR_temp1), \ + SHA512_SHL(64-(bits), (word), ROTR_temp2), \ + SHA512_OR(ROTR_temp1, ROTR_temp2, (ret)) ) + +/* + * Define the SHA SIGMA and sigma macros + * SHA512_ROTR(28,word) ^ SHA512_ROTR(34,word) ^ SHA512_ROTR(39,word) + */ +static uint32_t SIGMA0_temp1[2], SIGMA0_temp2[2], + SIGMA0_temp3[2], SIGMA0_temp4[2]; +#define SHA512_SIGMA0(word, ret) ( \ + SHA512_ROTR(28, (word), SIGMA0_temp1), \ + SHA512_ROTR(34, (word), SIGMA0_temp2), \ + SHA512_ROTR(39, (word), SIGMA0_temp3), \ + SHA512_XOR(SIGMA0_temp2, SIGMA0_temp3, SIGMA0_temp4), \ + SHA512_XOR(SIGMA0_temp1, SIGMA0_temp4, (ret)) ) + +/* + * SHA512_ROTR(14,word) ^ SHA512_ROTR(18,word) ^ SHA512_ROTR(41,word) + */ +static uint32_t SIGMA1_temp1[2], SIGMA1_temp2[2], + SIGMA1_temp3[2], SIGMA1_temp4[2]; +#define SHA512_SIGMA1(word, ret) ( \ + SHA512_ROTR(14, (word), SIGMA1_temp1), \ + SHA512_ROTR(18, (word), SIGMA1_temp2), \ + SHA512_ROTR(41, (word), SIGMA1_temp3), \ + SHA512_XOR(SIGMA1_temp2, SIGMA1_temp3, SIGMA1_temp4), \ + SHA512_XOR(SIGMA1_temp1, SIGMA1_temp4, (ret)) ) + +/* + * (SHA512_ROTR( 1,word) ^ SHA512_ROTR( 8,word) ^ SHA512_SHR( 7,word)) + + + +Eastlake 3rd & Hansen Informational [Page 48] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + */ +static uint32_t sigma0_temp1[2], sigma0_temp2[2], + sigma0_temp3[2], sigma0_temp4[2]; +#define SHA512_sigma0(word, ret) ( \ + SHA512_ROTR( 1, (word), sigma0_temp1), \ + SHA512_ROTR( 8, (word), sigma0_temp2), \ + SHA512_SHR( 7, (word), sigma0_temp3), \ + SHA512_XOR(sigma0_temp2, sigma0_temp3, sigma0_temp4), \ + SHA512_XOR(sigma0_temp1, sigma0_temp4, (ret)) ) + +/* + * (SHA512_ROTR(19,word) ^ SHA512_ROTR(61,word) ^ SHA512_SHR( 6,word)) + */ +static uint32_t sigma1_temp1[2], sigma1_temp2[2], + sigma1_temp3[2], sigma1_temp4[2]; +#define SHA512_sigma1(word, ret) ( \ + SHA512_ROTR(19, (word), sigma1_temp1), \ + SHA512_ROTR(61, (word), sigma1_temp2), \ + SHA512_SHR( 6, (word), sigma1_temp3), \ + SHA512_XOR(sigma1_temp2, sigma1_temp3, sigma1_temp4), \ + SHA512_XOR(sigma1_temp1, sigma1_temp4, (ret)) ) + +#undef SHA_Ch +#undef SHA_Maj + +#ifndef USE_MODIFIED_MACROS +/* + * These definitions are the ones used in FIPS-180-2, section 4.1.3 + * Ch(x,y,z) ((x & y) ^ (~x & z)) + */ +static uint32_t Ch_temp1[2], Ch_temp2[2], Ch_temp3[2]; +#define SHA_Ch(x, y, z, ret) ( \ + SHA512_AND(x, y, Ch_temp1), \ + SHA512_TILDA(x, Ch_temp2), \ + SHA512_AND(Ch_temp2, z, Ch_temp3), \ + SHA512_XOR(Ch_temp1, Ch_temp3, (ret)) ) +/* + * Maj(x,y,z) (((x)&(y)) ^ ((x)&(z)) ^ ((y)&(z))) + */ +static uint32_t Maj_temp1[2], Maj_temp2[2], + Maj_temp3[2], Maj_temp4[2]; +#define SHA_Maj(x, y, z, ret) ( \ + SHA512_AND(x, y, Maj_temp1), \ + SHA512_AND(x, z, Maj_temp2), \ + SHA512_AND(y, z, Maj_temp3), \ + SHA512_XOR(Maj_temp2, Maj_temp3, Maj_temp4), \ + SHA512_XOR(Maj_temp1, Maj_temp4, (ret)) ) + + + + +Eastlake 3rd & Hansen Informational [Page 49] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +#else /* !USE_32BIT_ONLY */ +/* + * These definitions are potentially faster equivalents for the ones + * used in FIPS-180-2, section 4.1.3. + * ((x & y) ^ (~x & z)) becomes + * ((x & (y ^ z)) ^ z) + */ +#define SHA_Ch(x, y, z, ret) ( \ + (ret)[0] = (((x)[0] & ((y)[0] ^ (z)[0])) ^ (z)[0]), \ + (ret)[1] = (((x)[1] & ((y)[1] ^ (z)[1])) ^ (z)[1]) ) + +/* + * ((x & y) ^ (x & z) ^ (y & z)) becomes + * ((x & (y | z)) | (y & z)) + */ +#define SHA_Maj(x, y, z, ret) ( \ + ret[0] = (((x)[0] & ((y)[0] | (z)[0])) | ((y)[0] & (z)[0])), \ + ret[1] = (((x)[1] & ((y)[1] | (z)[1])) | ((y)[1] & (z)[1])) ) +#endif /* USE_MODIFIED_MACROS */ + +/* + * add "length" to the length + */ +static uint32_t addTemp[4] = { 0, 0, 0, 0 }; +#define SHA384_512AddLength(context, length) ( \ + addTemp[3] = (length), SHA512_ADDTO4((context)->Length, addTemp), \ + (context)->Corrupted = (((context)->Length[3] == 0) && \ + ((context)->Length[2] == 0) && ((context)->Length[1] == 0) && \ + ((context)->Length[0] < 8)) ? 1 : 0 ) + +/* Local Function Prototypes */ +static void SHA384_512Finalize(SHA512Context *context, + uint8_t Pad_Byte); +static void SHA384_512PadMessage(SHA512Context *context, + uint8_t Pad_Byte); +static void SHA384_512ProcessMessageBlock(SHA512Context *context); +static int SHA384_512Reset(SHA512Context *context, uint32_t H0[]); +static int SHA384_512ResultN( SHA512Context *context, + uint8_t Message_Digest[], int HashSize); + +/* Initial Hash Values: FIPS-180-2 sections 5.3.3 and 5.3.4 */ +static uint32_t SHA384_H0[SHA512HashSize/4] = { + 0xCBBB9D5D, 0xC1059ED8, 0x629A292A, 0x367CD507, 0x9159015A, + 0x3070DD17, 0x152FECD8, 0xF70E5939, 0x67332667, 0xFFC00B31, + 0x8EB44A87, 0x68581511, 0xDB0C2E0D, 0x64F98FA7, 0x47B5481D, + 0xBEFA4FA4 +}; + + + + +Eastlake 3rd & Hansen Informational [Page 50] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +static uint32_t SHA512_H0[SHA512HashSize/4] = { + 0x6A09E667, 0xF3BCC908, 0xBB67AE85, 0x84CAA73B, 0x3C6EF372, + 0xFE94F82B, 0xA54FF53A, 0x5F1D36F1, 0x510E527F, 0xADE682D1, + 0x9B05688C, 0x2B3E6C1F, 0x1F83D9AB, 0xFB41BD6B, 0x5BE0CD19, + 0x137E2179 +}; + +#else /* !USE_32BIT_ONLY */ + +/* Define the SHA shift, rotate left and rotate right macro */ +#define SHA512_SHR(bits,word) (((uint64_t)(word)) >> (bits)) +#define SHA512_ROTR(bits,word) ((((uint64_t)(word)) >> (bits)) | \ + (((uint64_t)(word)) << (64-(bits)))) + +/* Define the SHA SIGMA and sigma macros */ +#define SHA512_SIGMA0(word) \ + (SHA512_ROTR(28,word) ^ SHA512_ROTR(34,word) ^ SHA512_ROTR(39,word)) +#define SHA512_SIGMA1(word) \ + (SHA512_ROTR(14,word) ^ SHA512_ROTR(18,word) ^ SHA512_ROTR(41,word)) +#define SHA512_sigma0(word) \ + (SHA512_ROTR( 1,word) ^ SHA512_ROTR( 8,word) ^ SHA512_SHR( 7,word)) +#define SHA512_sigma1(word) \ + (SHA512_ROTR(19,word) ^ SHA512_ROTR(61,word) ^ SHA512_SHR( 6,word)) + +/* + * add "length" to the length + */ +static uint64_t addTemp; +#define SHA384_512AddLength(context, length) \ + (addTemp = context->Length_Low, context->Corrupted = \ + ((context->Length_Low += length) < addTemp) && \ + (++context->Length_High == 0) ? 1 : 0) + +/* Local Function Prototypes */ +static void SHA384_512Finalize(SHA512Context *context, + uint8_t Pad_Byte); +static void SHA384_512PadMessage(SHA512Context *context, + uint8_t Pad_Byte); +static void SHA384_512ProcessMessageBlock(SHA512Context *context); +static int SHA384_512Reset(SHA512Context *context, uint64_t H0[]); +static int SHA384_512ResultN(SHA512Context *context, + uint8_t Message_Digest[], int HashSize); + +/* Initial Hash Values: FIPS-180-2 sections 5.3.3 and 5.3.4 */ +static uint64_t SHA384_H0[] = { + 0xCBBB9D5DC1059ED8ll, 0x629A292A367CD507ll, 0x9159015A3070DD17ll, + 0x152FECD8F70E5939ll, 0x67332667FFC00B31ll, 0x8EB44A8768581511ll, + 0xDB0C2E0D64F98FA7ll, 0x47B5481DBEFA4FA4ll + + + +Eastlake 3rd & Hansen Informational [Page 51] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +}; +static uint64_t SHA512_H0[] = { + 0x6A09E667F3BCC908ll, 0xBB67AE8584CAA73Bll, 0x3C6EF372FE94F82Bll, + 0xA54FF53A5F1D36F1ll, 0x510E527FADE682D1ll, 0x9B05688C2B3E6C1Fll, + 0x1F83D9ABFB41BD6Bll, 0x5BE0CD19137E2179ll +}; + +#endif /* USE_32BIT_ONLY */ + +/* + * SHA384Reset + * + * Description: + * This function will initialize the SHA384Context in preparation + * for computing a new SHA384 message digest. + * + * Parameters: + * context: [in/out] + * The context to reset. + * + * Returns: + * sha Error Code. + * + */ +int SHA384Reset(SHA384Context *context) +{ + return SHA384_512Reset(context, SHA384_H0); +} + +/* + * SHA384Input + * + * Description: + * This function accepts an array of octets as the next portion + * of the message. + * + * Parameters: + * context: [in/out] + * The SHA context to update + * message_array: [in] + * An array of characters representing the next portion of + * the message. + * length: [in] + * The length of the message in message_array + * + * Returns: + * sha Error Code. + * + + + +Eastlake 3rd & Hansen Informational [Page 52] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + */ +int SHA384Input(SHA384Context *context, + const uint8_t *message_array, unsigned int length) +{ + return SHA512Input(context, message_array, length); +} + +/* + * SHA384FinalBits + * + * Description: + * This function will add in any final bits of the message. + * + * Parameters: + * context: [in/out] + * The SHA context to update + * message_bits: [in] + * The final bits of the message, in the upper portion of the + * byte. (Use 0b###00000 instead of 0b00000### to input the + * three bits ###.) + * length: [in] + * The number of bits in message_bits, between 1 and 7. + * + * Returns: + * sha Error Code. + * + */ +int SHA384FinalBits(SHA384Context *context, + const uint8_t message_bits, unsigned int length) +{ + return SHA512FinalBits(context, message_bits, length); +} + +/* + * SHA384Result + * + * Description: + * This function will return the 384-bit message + * digest into the Message_Digest array provided by the caller. + * NOTE: The first octet of hash is stored in the 0th element, + * the last octet of hash in the 48th element. + * + * Parameters: + * context: [in/out] + * The context to use to calculate the SHA hash. + * Message_Digest: [out] + * Where the digest is returned. + * + + + +Eastlake 3rd & Hansen Informational [Page 53] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * Returns: + * sha Error Code. + * + */ +int SHA384Result(SHA384Context *context, + uint8_t Message_Digest[SHA384HashSize]) +{ + return SHA384_512ResultN(context, Message_Digest, SHA384HashSize); +} + +/* + * SHA512Reset + * + * Description: + * This function will initialize the SHA512Context in preparation + * for computing a new SHA512 message digest. + * + * Parameters: + * context: [in/out] + * The context to reset. + * + * Returns: + * sha Error Code. + * + */ +int SHA512Reset(SHA512Context *context) +{ + return SHA384_512Reset(context, SHA512_H0); +} + +/* + * SHA512Input + * + * Description: + * This function accepts an array of octets as the next portion + * of the message. + * + * Parameters: + * context: [in/out] + * The SHA context to update + * message_array: [in] + * An array of characters representing the next portion of + * the message. + * length: [in] + * The length of the message in message_array + * + * Returns: + * sha Error Code. + + + +Eastlake 3rd & Hansen Informational [Page 54] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * + */ +int SHA512Input(SHA512Context *context, + const uint8_t *message_array, + unsigned int length) +{ + if (!length) + return shaSuccess; + + if (!context || !message_array) + return shaNull; + + if (context->Computed) { + context->Corrupted = shaStateError; + return shaStateError; + } + + if (context->Corrupted) + return context->Corrupted; + + while (length-- && !context->Corrupted) { + context->Message_Block[context->Message_Block_Index++] = + (*message_array & 0xFF); + + if (!SHA384_512AddLength(context, 8) && + (context->Message_Block_Index == SHA512_Message_Block_Size)) + SHA384_512ProcessMessageBlock(context); + + message_array++; + } + + return shaSuccess; +} + +/* + * SHA512FinalBits + * + * Description: + * This function will add in any final bits of the message. + * + * Parameters: + * context: [in/out] + * The SHA context to update + * message_bits: [in] + * The final bits of the message, in the upper portion of the + * byte. (Use 0b###00000 instead of 0b00000### to input the + * three bits ###.) + * length: [in] + + + +Eastlake 3rd & Hansen Informational [Page 55] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * The number of bits in message_bits, between 1 and 7. + * + * Returns: + * sha Error Code. + * + */ +int SHA512FinalBits(SHA512Context *context, + const uint8_t message_bits, unsigned int length) +{ + uint8_t masks[8] = { + /* 0 0b00000000 */ 0x00, /* 1 0b10000000 */ 0x80, + /* 2 0b11000000 */ 0xC0, /* 3 0b11100000 */ 0xE0, + /* 4 0b11110000 */ 0xF0, /* 5 0b11111000 */ 0xF8, + /* 6 0b11111100 */ 0xFC, /* 7 0b11111110 */ 0xFE + }; + uint8_t markbit[8] = { + /* 0 0b10000000 */ 0x80, /* 1 0b01000000 */ 0x40, + /* 2 0b00100000 */ 0x20, /* 3 0b00010000 */ 0x10, + /* 4 0b00001000 */ 0x08, /* 5 0b00000100 */ 0x04, + /* 6 0b00000010 */ 0x02, /* 7 0b00000001 */ 0x01 + }; + + if (!length) + return shaSuccess; + + if (!context) + return shaNull; + + if ((context->Computed) || (length >= 8) || (length == 0)) { + context->Corrupted = shaStateError; + return shaStateError; + } + + if (context->Corrupted) + return context->Corrupted; + + SHA384_512AddLength(context, length); + SHA384_512Finalize(context, (uint8_t) + ((message_bits & masks[length]) | markbit[length])); + + return shaSuccess; +} + +/* + * SHA384_512Finalize + * + * Description: + * This helper function finishes off the digest calculations. + + + +Eastlake 3rd & Hansen Informational [Page 56] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * + * Parameters: + * context: [in/out] + * The SHA context to update + * Pad_Byte: [in] + * The last byte to add to the digest before the 0-padding + * and length. This will contain the last bits of the message + * followed by another single bit. If the message was an + * exact multiple of 8-bits long, Pad_Byte will be 0x80. + * + * Returns: + * sha Error Code. + * + */ +static void SHA384_512Finalize(SHA512Context *context, + uint8_t Pad_Byte) +{ + int_least16_t i; + SHA384_512PadMessage(context, Pad_Byte); + /* message may be sensitive, clear it out */ + for (i = 0; i < SHA512_Message_Block_Size; ++i) + context->Message_Block[i] = 0; +#ifdef USE_32BIT_ONLY /* and clear length */ + context->Length[0] = context->Length[1] = 0; + context->Length[2] = context->Length[3] = 0; +#else /* !USE_32BIT_ONLY */ + context->Length_Low = 0; + context->Length_High = 0; +#endif /* USE_32BIT_ONLY */ + context->Computed = 1; +} + +/* + * SHA512Result + * + * Description: + * This function will return the 512-bit message + * digest into the Message_Digest array provided by the caller. + * NOTE: The first octet of hash is stored in the 0th element, + * the last octet of hash in the 64th element. + * + * Parameters: + * context: [in/out] + * The context to use to calculate the SHA hash. + * Message_Digest: [out] + * Where the digest is returned. + * + * Returns: + + + +Eastlake 3rd & Hansen Informational [Page 57] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * sha Error Code. + * + */ +int SHA512Result(SHA512Context *context, + uint8_t Message_Digest[SHA512HashSize]) +{ + return SHA384_512ResultN(context, Message_Digest, SHA512HashSize); +} + +/* + * SHA384_512PadMessage + * + * Description: + * According to the standard, the message must be padded to an + * even 1024 bits. The first padding bit must be a '1'. The + * last 128 bits represent the length of the original message. + * All bits in between should be 0. This helper function will + * pad the message according to those rules by filling the + * Message_Block array accordingly. When it returns, it can be + * assumed that the message digest has been computed. + * + * Parameters: + * context: [in/out] + * The context to pad + * Pad_Byte: [in] + * The last byte to add to the digest before the 0-padding + * and length. This will contain the last bits of the message + * followed by another single bit. If the message was an + * exact multiple of 8-bits long, Pad_Byte will be 0x80. + * + * Returns: + * Nothing. + * + */ +static void SHA384_512PadMessage(SHA512Context *context, + uint8_t Pad_Byte) +{ + /* + * Check to see if the current message block is too small to hold + * the initial padding bits and length. If so, we will pad the + * block, process it, and then continue padding into a second + * block. + */ + if (context->Message_Block_Index >= (SHA512_Message_Block_Size-16)) { + context->Message_Block[context->Message_Block_Index++] = Pad_Byte; + while (context->Message_Block_Index < SHA512_Message_Block_Size) + context->Message_Block[context->Message_Block_Index++] = 0; + + + + +Eastlake 3rd & Hansen Informational [Page 58] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + SHA384_512ProcessMessageBlock(context); + } else + context->Message_Block[context->Message_Block_Index++] = Pad_Byte; + + while (context->Message_Block_Index < (SHA512_Message_Block_Size-16)) + context->Message_Block[context->Message_Block_Index++] = 0; + + /* + * Store the message length as the last 16 octets + */ +#ifdef USE_32BIT_ONLY + context->Message_Block[112] = (uint8_t)(context->Length[0] >> 24); + context->Message_Block[113] = (uint8_t)(context->Length[0] >> 16); + context->Message_Block[114] = (uint8_t)(context->Length[0] >> 8); + context->Message_Block[115] = (uint8_t)(context->Length[0]); + context->Message_Block[116] = (uint8_t)(context->Length[1] >> 24); + context->Message_Block[117] = (uint8_t)(context->Length[1] >> 16); + context->Message_Block[118] = (uint8_t)(context->Length[1] >> 8); + context->Message_Block[119] = (uint8_t)(context->Length[1]); + + context->Message_Block[120] = (uint8_t)(context->Length[2] >> 24); + context->Message_Block[121] = (uint8_t)(context->Length[2] >> 16); + context->Message_Block[122] = (uint8_t)(context->Length[2] >> 8); + context->Message_Block[123] = (uint8_t)(context->Length[2]); + context->Message_Block[124] = (uint8_t)(context->Length[3] >> 24); + context->Message_Block[125] = (uint8_t)(context->Length[3] >> 16); + context->Message_Block[126] = (uint8_t)(context->Length[3] >> 8); + context->Message_Block[127] = (uint8_t)(context->Length[3]); +#else /* !USE_32BIT_ONLY */ + context->Message_Block[112] = (uint8_t)(context->Length_High >> 56); + context->Message_Block[113] = (uint8_t)(context->Length_High >> 48); + context->Message_Block[114] = (uint8_t)(context->Length_High >> 40); + context->Message_Block[115] = (uint8_t)(context->Length_High >> 32); + context->Message_Block[116] = (uint8_t)(context->Length_High >> 24); + context->Message_Block[117] = (uint8_t)(context->Length_High >> 16); + context->Message_Block[118] = (uint8_t)(context->Length_High >> 8); + context->Message_Block[119] = (uint8_t)(context->Length_High); + + context->Message_Block[120] = (uint8_t)(context->Length_Low >> 56); + context->Message_Block[121] = (uint8_t)(context->Length_Low >> 48); + context->Message_Block[122] = (uint8_t)(context->Length_Low >> 40); + context->Message_Block[123] = (uint8_t)(context->Length_Low >> 32); + context->Message_Block[124] = (uint8_t)(context->Length_Low >> 24); + context->Message_Block[125] = (uint8_t)(context->Length_Low >> 16); + context->Message_Block[126] = (uint8_t)(context->Length_Low >> 8); + context->Message_Block[127] = (uint8_t)(context->Length_Low); +#endif /* USE_32BIT_ONLY */ + + + + +Eastlake 3rd & Hansen Informational [Page 59] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + SHA384_512ProcessMessageBlock(context); +} + +/* + * SHA384_512ProcessMessageBlock + * + * Description: + * This helper function will process the next 1024 bits of the + * message stored in the Message_Block array. + * + * Parameters: + * context: [in/out] + * The SHA context to update + * + * Returns: + * Nothing. + * + * Comments: + * Many of the variable names in this code, especially the + * single character names, were used because those were the + * names used in the publication. + * + * + */ +static void SHA384_512ProcessMessageBlock(SHA512Context *context) +{ + /* Constants defined in FIPS-180-2, section 4.2.3 */ +#ifdef USE_32BIT_ONLY + static const uint32_t K[80*2] = { + 0x428A2F98, 0xD728AE22, 0x71374491, 0x23EF65CD, 0xB5C0FBCF, + 0xEC4D3B2F, 0xE9B5DBA5, 0x8189DBBC, 0x3956C25B, 0xF348B538, + 0x59F111F1, 0xB605D019, 0x923F82A4, 0xAF194F9B, 0xAB1C5ED5, + 0xDA6D8118, 0xD807AA98, 0xA3030242, 0x12835B01, 0x45706FBE, + 0x243185BE, 0x4EE4B28C, 0x550C7DC3, 0xD5FFB4E2, 0x72BE5D74, + 0xF27B896F, 0x80DEB1FE, 0x3B1696B1, 0x9BDC06A7, 0x25C71235, + 0xC19BF174, 0xCF692694, 0xE49B69C1, 0x9EF14AD2, 0xEFBE4786, + 0x384F25E3, 0x0FC19DC6, 0x8B8CD5B5, 0x240CA1CC, 0x77AC9C65, + 0x2DE92C6F, 0x592B0275, 0x4A7484AA, 0x6EA6E483, 0x5CB0A9DC, + 0xBD41FBD4, 0x76F988DA, 0x831153B5, 0x983E5152, 0xEE66DFAB, + 0xA831C66D, 0x2DB43210, 0xB00327C8, 0x98FB213F, 0xBF597FC7, + 0xBEEF0EE4, 0xC6E00BF3, 0x3DA88FC2, 0xD5A79147, 0x930AA725, + 0x06CA6351, 0xE003826F, 0x14292967, 0x0A0E6E70, 0x27B70A85, + 0x46D22FFC, 0x2E1B2138, 0x5C26C926, 0x4D2C6DFC, 0x5AC42AED, + 0x53380D13, 0x9D95B3DF, 0x650A7354, 0x8BAF63DE, 0x766A0ABB, + 0x3C77B2A8, 0x81C2C92E, 0x47EDAEE6, 0x92722C85, 0x1482353B, + 0xA2BFE8A1, 0x4CF10364, 0xA81A664B, 0xBC423001, 0xC24B8B70, + 0xD0F89791, 0xC76C51A3, 0x0654BE30, 0xD192E819, 0xD6EF5218, + 0xD6990624, 0x5565A910, 0xF40E3585, 0x5771202A, 0x106AA070, + + + +Eastlake 3rd & Hansen Informational [Page 60] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + 0x32BBD1B8, 0x19A4C116, 0xB8D2D0C8, 0x1E376C08, 0x5141AB53, + 0x2748774C, 0xDF8EEB99, 0x34B0BCB5, 0xE19B48A8, 0x391C0CB3, + 0xC5C95A63, 0x4ED8AA4A, 0xE3418ACB, 0x5B9CCA4F, 0x7763E373, + 0x682E6FF3, 0xD6B2B8A3, 0x748F82EE, 0x5DEFB2FC, 0x78A5636F, + 0x43172F60, 0x84C87814, 0xA1F0AB72, 0x8CC70208, 0x1A6439EC, + 0x90BEFFFA, 0x23631E28, 0xA4506CEB, 0xDE82BDE9, 0xBEF9A3F7, + 0xB2C67915, 0xC67178F2, 0xE372532B, 0xCA273ECE, 0xEA26619C, + 0xD186B8C7, 0x21C0C207, 0xEADA7DD6, 0xCDE0EB1E, 0xF57D4F7F, + 0xEE6ED178, 0x06F067AA, 0x72176FBA, 0x0A637DC5, 0xA2C898A6, + 0x113F9804, 0xBEF90DAE, 0x1B710B35, 0x131C471B, 0x28DB77F5, + 0x23047D84, 0x32CAAB7B, 0x40C72493, 0x3C9EBE0A, 0x15C9BEBC, + 0x431D67C4, 0x9C100D4C, 0x4CC5D4BE, 0xCB3E42B6, 0x597F299C, + 0xFC657E2A, 0x5FCB6FAB, 0x3AD6FAEC, 0x6C44198C, 0x4A475817 + }; + int t, t2, t8; /* Loop counter */ + uint32_t temp1[2], temp2[2], /* Temporary word values */ + temp3[2], temp4[2], temp5[2]; + uint32_t W[2*80]; /* Word sequence */ + uint32_t A[2], B[2], C[2], D[2], /* Word buffers */ + E[2], F[2], G[2], H[2]; + + /* Initialize the first 16 words in the array W */ + for (t = t2 = t8 = 0; t < 16; t++, t8 += 8) { + W[t2++] = ((((uint32_t)context->Message_Block[t8 ])) << 24) | + ((((uint32_t)context->Message_Block[t8 + 1])) << 16) | + ((((uint32_t)context->Message_Block[t8 + 2])) << 8) | + ((((uint32_t)context->Message_Block[t8 + 3]))); + W[t2++] = ((((uint32_t)context->Message_Block[t8 + 4])) << 24) | + ((((uint32_t)context->Message_Block[t8 + 5])) << 16) | + ((((uint32_t)context->Message_Block[t8 + 6])) << 8) | + ((((uint32_t)context->Message_Block[t8 + 7]))); + } + + for (t = 16; t < 80; t++, t2 += 2) { + /* W[t] = SHA512_sigma1(W[t-2]) + W[t-7] + + SHA512_sigma0(W[t-15]) + W[t-16]; */ + uint32_t *Wt2 = &W[t2-2*2]; + uint32_t *Wt7 = &W[t2-7*2]; + uint32_t *Wt15 = &W[t2-15*2]; + uint32_t *Wt16 = &W[t2-16*2]; + SHA512_sigma1(Wt2, temp1); + SHA512_ADD(temp1, Wt7, temp2); + SHA512_sigma0(Wt15, temp1); + SHA512_ADD(temp1, Wt16, temp3); + SHA512_ADD(temp2, temp3, &W[t2]); + } + + A[0] = context->Intermediate_Hash[0]; + + + +Eastlake 3rd & Hansen Informational [Page 61] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + A[1] = context->Intermediate_Hash[1]; + B[0] = context->Intermediate_Hash[2]; + B[1] = context->Intermediate_Hash[3]; + C[0] = context->Intermediate_Hash[4]; + C[1] = context->Intermediate_Hash[5]; + D[0] = context->Intermediate_Hash[6]; + D[1] = context->Intermediate_Hash[7]; + E[0] = context->Intermediate_Hash[8]; + E[1] = context->Intermediate_Hash[9]; + F[0] = context->Intermediate_Hash[10]; + F[1] = context->Intermediate_Hash[11]; + G[0] = context->Intermediate_Hash[12]; + G[1] = context->Intermediate_Hash[13]; + H[0] = context->Intermediate_Hash[14]; + H[1] = context->Intermediate_Hash[15]; + + for (t = t2 = 0; t < 80; t++, t2 += 2) { + /* + * temp1 = H + SHA512_SIGMA1(E) + SHA_Ch(E,F,G) + K[t] + W[t]; + */ + SHA512_SIGMA1(E,temp1); + SHA512_ADD(H, temp1, temp2); + SHA_Ch(E,F,G,temp3); + SHA512_ADD(temp2, temp3, temp4); + SHA512_ADD(&K[t2], &W[t2], temp5); + SHA512_ADD(temp4, temp5, temp1); + /* + * temp2 = SHA512_SIGMA0(A) + SHA_Maj(A,B,C); + */ + SHA512_SIGMA0(A,temp3); + SHA_Maj(A,B,C,temp4); + SHA512_ADD(temp3, temp4, temp2); + H[0] = G[0]; H[1] = G[1]; + G[0] = F[0]; G[1] = F[1]; + F[0] = E[0]; F[1] = E[1]; + SHA512_ADD(D, temp1, E); + D[0] = C[0]; D[1] = C[1]; + C[0] = B[0]; C[1] = B[1]; + B[0] = A[0]; B[1] = A[1]; + SHA512_ADD(temp1, temp2, A); + } + + SHA512_ADDTO2(&context->Intermediate_Hash[0], A); + SHA512_ADDTO2(&context->Intermediate_Hash[2], B); + SHA512_ADDTO2(&context->Intermediate_Hash[4], C); + SHA512_ADDTO2(&context->Intermediate_Hash[6], D); + SHA512_ADDTO2(&context->Intermediate_Hash[8], E); + SHA512_ADDTO2(&context->Intermediate_Hash[10], F); + + + +Eastlake 3rd & Hansen Informational [Page 62] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + SHA512_ADDTO2(&context->Intermediate_Hash[12], G); + SHA512_ADDTO2(&context->Intermediate_Hash[14], H); + +#else /* !USE_32BIT_ONLY */ + static const uint64_t K[80] = { + 0x428A2F98D728AE22ll, 0x7137449123EF65CDll, 0xB5C0FBCFEC4D3B2Fll, + 0xE9B5DBA58189DBBCll, 0x3956C25BF348B538ll, 0x59F111F1B605D019ll, + 0x923F82A4AF194F9Bll, 0xAB1C5ED5DA6D8118ll, 0xD807AA98A3030242ll, + 0x12835B0145706FBEll, 0x243185BE4EE4B28Cll, 0x550C7DC3D5FFB4E2ll, + 0x72BE5D74F27B896Fll, 0x80DEB1FE3B1696B1ll, 0x9BDC06A725C71235ll, + 0xC19BF174CF692694ll, 0xE49B69C19EF14AD2ll, 0xEFBE4786384F25E3ll, + 0x0FC19DC68B8CD5B5ll, 0x240CA1CC77AC9C65ll, 0x2DE92C6F592B0275ll, + 0x4A7484AA6EA6E483ll, 0x5CB0A9DCBD41FBD4ll, 0x76F988DA831153B5ll, + 0x983E5152EE66DFABll, 0xA831C66D2DB43210ll, 0xB00327C898FB213Fll, + 0xBF597FC7BEEF0EE4ll, 0xC6E00BF33DA88FC2ll, 0xD5A79147930AA725ll, + 0x06CA6351E003826Fll, 0x142929670A0E6E70ll, 0x27B70A8546D22FFCll, + 0x2E1B21385C26C926ll, 0x4D2C6DFC5AC42AEDll, 0x53380D139D95B3DFll, + 0x650A73548BAF63DEll, 0x766A0ABB3C77B2A8ll, 0x81C2C92E47EDAEE6ll, + 0x92722C851482353Bll, 0xA2BFE8A14CF10364ll, 0xA81A664BBC423001ll, + 0xC24B8B70D0F89791ll, 0xC76C51A30654BE30ll, 0xD192E819D6EF5218ll, + 0xD69906245565A910ll, 0xF40E35855771202All, 0x106AA07032BBD1B8ll, + 0x19A4C116B8D2D0C8ll, 0x1E376C085141AB53ll, 0x2748774CDF8EEB99ll, + 0x34B0BCB5E19B48A8ll, 0x391C0CB3C5C95A63ll, 0x4ED8AA4AE3418ACBll, + 0x5B9CCA4F7763E373ll, 0x682E6FF3D6B2B8A3ll, 0x748F82EE5DEFB2FCll, + 0x78A5636F43172F60ll, 0x84C87814A1F0AB72ll, 0x8CC702081A6439ECll, + 0x90BEFFFA23631E28ll, 0xA4506CEBDE82BDE9ll, 0xBEF9A3F7B2C67915ll, + 0xC67178F2E372532Bll, 0xCA273ECEEA26619Cll, 0xD186B8C721C0C207ll, + 0xEADA7DD6CDE0EB1Ell, 0xF57D4F7FEE6ED178ll, 0x06F067AA72176FBAll, + 0x0A637DC5A2C898A6ll, 0x113F9804BEF90DAEll, 0x1B710B35131C471Bll, + 0x28DB77F523047D84ll, 0x32CAAB7B40C72493ll, 0x3C9EBE0A15C9BEBCll, + 0x431D67C49C100D4Cll, 0x4CC5D4BECB3E42B6ll, 0x597F299CFC657E2All, + 0x5FCB6FAB3AD6FAECll, 0x6C44198C4A475817ll + }; + int t, t8; /* Loop counter */ + uint64_t temp1, temp2; /* Temporary word value */ + uint64_t W[80]; /* Word sequence */ + uint64_t A, B, C, D, E, F, G, H; /* Word buffers */ + + /* + * Initialize the first 16 words in the array W + */ + for (t = t8 = 0; t < 16; t++, t8 += 8) + W[t] = ((uint64_t)(context->Message_Block[t8 ]) << 56) | + ((uint64_t)(context->Message_Block[t8 + 1]) << 48) | + ((uint64_t)(context->Message_Block[t8 + 2]) << 40) | + ((uint64_t)(context->Message_Block[t8 + 3]) << 32) | + ((uint64_t)(context->Message_Block[t8 + 4]) << 24) | + ((uint64_t)(context->Message_Block[t8 + 5]) << 16) | + + + +Eastlake 3rd & Hansen Informational [Page 63] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + ((uint64_t)(context->Message_Block[t8 + 6]) << 8) | + ((uint64_t)(context->Message_Block[t8 + 7])); + + for (t = 16; t < 80; t++) + W[t] = SHA512_sigma1(W[t-2]) + W[t-7] + + SHA512_sigma0(W[t-15]) + W[t-16]; + + A = context->Intermediate_Hash[0]; + B = context->Intermediate_Hash[1]; + C = context->Intermediate_Hash[2]; + D = context->Intermediate_Hash[3]; + E = context->Intermediate_Hash[4]; + F = context->Intermediate_Hash[5]; + G = context->Intermediate_Hash[6]; + H = context->Intermediate_Hash[7]; + + for (t = 0; t < 80; t++) { + temp1 = H + SHA512_SIGMA1(E) + SHA_Ch(E,F,G) + K[t] + W[t]; + temp2 = SHA512_SIGMA0(A) + SHA_Maj(A,B,C); + H = G; + G = F; + F = E; + E = D + temp1; + D = C; + C = B; + B = A; + A = temp1 + temp2; + } + + context->Intermediate_Hash[0] += A; + context->Intermediate_Hash[1] += B; + context->Intermediate_Hash[2] += C; + context->Intermediate_Hash[3] += D; + context->Intermediate_Hash[4] += E; + context->Intermediate_Hash[5] += F; + context->Intermediate_Hash[6] += G; + context->Intermediate_Hash[7] += H; +#endif /* USE_32BIT_ONLY */ + + context->Message_Block_Index = 0; +} + +/* + * SHA384_512Reset + * + * Description: + * This helper function will initialize the SHA512Context in + * preparation for computing a new SHA384 or SHA512 message + + + +Eastlake 3rd & Hansen Informational [Page 64] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * digest. + * + * Parameters: + * context: [in/out] + * The context to reset. + * H0 + * The initial hash value to use. + * + * Returns: + * sha Error Code. + * + */ +#ifdef USE_32BIT_ONLY +static int SHA384_512Reset(SHA512Context *context, uint32_t H0[]) +#else /* !USE_32BIT_ONLY */ +static int SHA384_512Reset(SHA512Context *context, uint64_t H0[]) +#endif /* USE_32BIT_ONLY */ +{ + int i; + if (!context) + return shaNull; + + context->Message_Block_Index = 0; + +#ifdef USE_32BIT_ONLY + context->Length[0] = context->Length[1] = 0; + context->Length[2] = context->Length[3] = 0; + + for (i = 0; i < SHA512HashSize/4; i++) + context->Intermediate_Hash[i] = H0[i]; +#else /* !USE_32BIT_ONLY */ + context->Length_High = context->Length_Low = 0; + + for (i = 0; i < SHA512HashSize/8; i++) + context->Intermediate_Hash[i] = H0[i]; +#endif /* USE_32BIT_ONLY */ + + context->Computed = 0; + context->Corrupted = 0; + + return shaSuccess; +} + +/* + * SHA384_512ResultN + * + * Description: + * This helper function will return the 384-bit or 512-bit message + + + +Eastlake 3rd & Hansen Informational [Page 65] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * digest into the Message_Digest array provided by the caller. + * NOTE: The first octet of hash is stored in the 0th element, + * the last octet of hash in the 48th/64th element. + * + * Parameters: + * context: [in/out] + * The context to use to calculate the SHA hash. + * Message_Digest: [out] + * Where the digest is returned. + * HashSize: [in] + * The size of the hash, either 48 or 64. + * + * Returns: + * sha Error Code. + * + */ +static int SHA384_512ResultN(SHA512Context *context, + uint8_t Message_Digest[], int HashSize) +{ + int i; + +#ifdef USE_32BIT_ONLY + int i2; +#endif /* USE_32BIT_ONLY */ + + if (!context || !Message_Digest) + return shaNull; + + if (context->Corrupted) + return context->Corrupted; + + if (!context->Computed) + SHA384_512Finalize(context, 0x80); + +#ifdef USE_32BIT_ONLY + for (i = i2 = 0; i < HashSize; ) { + Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>24); + Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>16); + Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>8); + Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2++]); + Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>24); + Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>16); + Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>8); + Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2++]); + } +#else /* !USE_32BIT_ONLY */ + for (i = 0; i < HashSize; ++i) + Message_Digest[i] = (uint8_t) + + + +Eastlake 3rd & Hansen Informational [Page 66] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + (context->Intermediate_Hash[i>>3] >> 8 * ( 7 - ( i % 8 ) )); +#endif /* USE_32BIT_ONLY */ + + return shaSuccess; +} + +8.2.4. usha.c + +/**************************** usha.c ****************************/ +/******************** See RFC 4634 for details ******************/ +/* + * Description: + * This file implements a unified interface to the SHA algorithms. + */ + +#include "sha.h" + +/* + * USHAReset + * + * Description: + * This function will initialize the SHA Context in preparation + * for computing a new SHA message digest. + * + * Parameters: + * context: [in/out] + * The context to reset. + * whichSha: [in] + * Selects which SHA reset to call + * + * Returns: + * sha Error Code. + * + */ +int USHAReset(USHAContext *ctx, enum SHAversion whichSha) +{ + if (ctx) { + ctx->whichSha = whichSha; + switch (whichSha) { + case SHA1: return SHA1Reset((SHA1Context*)&ctx->ctx); + case SHA224: return SHA224Reset((SHA224Context*)&ctx->ctx); + case SHA256: return SHA256Reset((SHA256Context*)&ctx->ctx); + case SHA384: return SHA384Reset((SHA384Context*)&ctx->ctx); + case SHA512: return SHA512Reset((SHA512Context*)&ctx->ctx); + default: return shaBadParam; + } + } else { + return shaNull; + + + +Eastlake 3rd & Hansen Informational [Page 67] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + } +} + +/* + * USHAInput + * + * Description: + * This function accepts an array of octets as the next portion + * of the message. + * + * Parameters: + * context: [in/out] + * The SHA context to update + * message_array: [in] + * An array of characters representing the next portion of + * the message. + * length: [in] + * The length of the message in message_array + * + * Returns: + * sha Error Code. + * + */ +int USHAInput(USHAContext *ctx, + const uint8_t *bytes, unsigned int bytecount) +{ + if (ctx) { + switch (ctx->whichSha) { + case SHA1: + return SHA1Input((SHA1Context*)&ctx->ctx, bytes, bytecount); + case SHA224: + return SHA224Input((SHA224Context*)&ctx->ctx, bytes, + bytecount); + case SHA256: + return SHA256Input((SHA256Context*)&ctx->ctx, bytes, + bytecount); + case SHA384: + return SHA384Input((SHA384Context*)&ctx->ctx, bytes, + bytecount); + case SHA512: + return SHA512Input((SHA512Context*)&ctx->ctx, bytes, + bytecount); + default: return shaBadParam; + } + } else { + return shaNull; + } +} + + + +Eastlake 3rd & Hansen Informational [Page 68] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +/* + * USHAFinalBits + * + * Description: + * This function will add in any final bits of the message. + * + * Parameters: + * context: [in/out] + * The SHA context to update + * message_bits: [in] + * The final bits of the message, in the upper portion of the + * byte. (Use 0b###00000 instead of 0b00000### to input the + * three bits ###.) + * length: [in] + * The number of bits in message_bits, between 1 and 7. + * + * Returns: + * sha Error Code. + */ +int USHAFinalBits(USHAContext *ctx, + const uint8_t bits, unsigned int bitcount) +{ + if (ctx) { + switch (ctx->whichSha) { + case SHA1: + return SHA1FinalBits((SHA1Context*)&ctx->ctx, bits, bitcount); + case SHA224: + return SHA224FinalBits((SHA224Context*)&ctx->ctx, bits, + bitcount); + case SHA256: + return SHA256FinalBits((SHA256Context*)&ctx->ctx, bits, + bitcount); + case SHA384: + return SHA384FinalBits((SHA384Context*)&ctx->ctx, bits, + bitcount); + case SHA512: + return SHA512FinalBits((SHA512Context*)&ctx->ctx, bits, + bitcount); + default: return shaBadParam; + } + } else { + return shaNull; + } +} + +/* + * USHAResult + * + + + +Eastlake 3rd & Hansen Informational [Page 69] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * Description: + * This function will return the 160-bit message digest into the + * Message_Digest array provided by the caller. + * NOTE: The first octet of hash is stored in the 0th element, + * the last octet of hash in the 19th element. + * + * Parameters: + * context: [in/out] + * The context to use to calculate the SHA-1 hash. + * Message_Digest: [out] + * Where the digest is returned. + * + * Returns: + * sha Error Code. + * + */ +int USHAResult(USHAContext *ctx, + uint8_t Message_Digest[USHAMaxHashSize]) +{ + if (ctx) { + switch (ctx->whichSha) { + case SHA1: + return SHA1Result((SHA1Context*)&ctx->ctx, Message_Digest); + case SHA224: + return SHA224Result((SHA224Context*)&ctx->ctx, Message_Digest); + case SHA256: + return SHA256Result((SHA256Context*)&ctx->ctx, Message_Digest); + case SHA384: + return SHA384Result((SHA384Context*)&ctx->ctx, Message_Digest); + case SHA512: + return SHA512Result((SHA512Context*)&ctx->ctx, Message_Digest); + default: return shaBadParam; + } + } else { + return shaNull; + } +} + +/* + * USHABlockSize + * + * Description: + * This function will return the blocksize for the given SHA + * algorithm. + * + * Parameters: + * whichSha: + * which SHA algorithm to query + + + +Eastlake 3rd & Hansen Informational [Page 70] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * + * Returns: + * block size + * + */ +int USHABlockSize(enum SHAversion whichSha) +{ + switch (whichSha) { + case SHA1: return SHA1_Message_Block_Size; + case SHA224: return SHA224_Message_Block_Size; + case SHA256: return SHA256_Message_Block_Size; + case SHA384: return SHA384_Message_Block_Size; + default: + case SHA512: return SHA512_Message_Block_Size; + } +} + +/* + * USHAHashSize + * + * Description: + * This function will return the hashsize for the given SHA + * algorithm. + * + * Parameters: + * whichSha: + * which SHA algorithm to query + * + * Returns: + * hash size + * + */ +int USHAHashSize(enum SHAversion whichSha) +{ + switch (whichSha) { + case SHA1: return SHA1HashSize; + case SHA224: return SHA224HashSize; + case SHA256: return SHA256HashSize; + case SHA384: return SHA384HashSize; + default: + case SHA512: return SHA512HashSize; + } +} + +/* + * USHAHashSizeBits + * + * Description: + + + +Eastlake 3rd & Hansen Informational [Page 71] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * This function will return the hashsize for the given SHA + * algorithm, expressed in bits. + * + * Parameters: + * whichSha: + * which SHA algorithm to query + * + * Returns: + * hash size in bits + * + */ +int USHAHashSizeBits(enum SHAversion whichSha) +{ + switch (whichSha) { + case SHA1: return SHA1HashSizeBits; + case SHA224: return SHA224HashSizeBits; + case SHA256: return SHA256HashSizeBits; + case SHA384: return SHA384HashSizeBits; + default: + case SHA512: return SHA512HashSizeBits; + } +} + +8.2.5. sha-private.h + +/*************************** sha-private.h ***************************/ +/********************** See RFC 4634 for details *********************/ +#ifndef _SHA_PRIVATE__H +#define _SHA_PRIVATE__H +/* + * These definitions are defined in FIPS-180-2, section 4.1. + * Ch() and Maj() are defined identically in sections 4.1.1, + * 4.1.2 and 4.1.3. + * + * The definitions used in FIPS-180-2 are as follows: + */ + +#ifndef USE_MODIFIED_MACROS +#define SHA_Ch(x,y,z) (((x) & (y)) ^ ((~(x)) & (z))) +#define SHA_Maj(x,y,z) (((x) & (y)) ^ ((x) & (z)) ^ ((y) & (z))) + +#else /* USE_MODIFIED_MACROS */ +/* + * The following definitions are equivalent and potentially faster. + */ + +#define SHA_Ch(x, y, z) (((x) & ((y) ^ (z))) ^ (z)) +#define SHA_Maj(x, y, z) (((x) & ((y) | (z))) | ((y) & (z))) + + + +Eastlake 3rd & Hansen Informational [Page 72] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +#endif /* USE_MODIFIED_MACROS */ + +#define SHA_Parity(x, y, z) ((x) ^ (y) ^ (z)) + +#endif /* _SHA_PRIVATE__H */ + +8.3 The HMAC Code + +/**************************** hmac.c ****************************/ +/******************** See RFC 4634 for details ******************/ +/* + * Description: + * This file implements the HMAC algorithm (Keyed-Hashing for + * Message Authentication, RFC2104), expressed in terms of the + * various SHA algorithms. + */ + +#include "sha.h" + +/* + * hmac + * + * Description: + * This function will compute an HMAC message digest. + * + * Parameters: + * whichSha: [in] + * One of SHA1, SHA224, SHA256, SHA384, SHA512 + * key: [in] + * The secret shared key. + * key_len: [in] + * The length of the secret shared key. + * message_array: [in] + * An array of characters representing the message. + * length: [in] + * The length of the message in message_array + * digest: [out] + * Where the digest is returned. + * NOTE: The length of the digest is determined by + * the value of whichSha. + * + * Returns: + * sha Error Code. + * + */ +int hmac(SHAversion whichSha, const unsigned char *text, int text_len, + const unsigned char *key, int key_len, + uint8_t digest[USHAMaxHashSize]) + + + +Eastlake 3rd & Hansen Informational [Page 73] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +{ + HMACContext ctx; + return hmacReset(&ctx, whichSha, key, key_len) || + hmacInput(&ctx, text, text_len) || + hmacResult(&ctx, digest); +} + +/* + * hmacReset + * + * Description: + * This function will initialize the hmacContext in preparation + * for computing a new HMAC message digest. + * + * Parameters: + * context: [in/out] + * The context to reset. + * whichSha: [in] + * One of SHA1, SHA224, SHA256, SHA384, SHA512 + * key: [in] + * The secret shared key. + * key_len: [in] + * The length of the secret shared key. + * + * Returns: + * sha Error Code. + * + */ +int hmacReset(HMACContext *ctx, enum SHAversion whichSha, + const unsigned char *key, int key_len) +{ + int i, blocksize, hashsize; + + /* inner padding - key XORd with ipad */ + unsigned char k_ipad[USHA_Max_Message_Block_Size]; + + /* temporary buffer when keylen > blocksize */ + unsigned char tempkey[USHAMaxHashSize]; + + if (!ctx) return shaNull; + + blocksize = ctx->blockSize = USHABlockSize(whichSha); + hashsize = ctx->hashSize = USHAHashSize(whichSha); + + ctx->whichSha = whichSha; + + /* + * If key is longer than the hash blocksize, + + + +Eastlake 3rd & Hansen Informational [Page 74] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * reset it to key = HASH(key). + */ + if (key_len > blocksize) { + USHAContext tctx; + int err = USHAReset(&tctx, whichSha) || + USHAInput(&tctx, key, key_len) || + USHAResult(&tctx, tempkey); + if (err != shaSuccess) return err; + + key = tempkey; + key_len = hashsize; + } + + /* + * The HMAC transform looks like: + * + * SHA(K XOR opad, SHA(K XOR ipad, text)) + * + * where K is an n byte key. + * ipad is the byte 0x36 repeated blocksize times + * opad is the byte 0x5c repeated blocksize times + * and text is the data being protected. + */ + + /* store key into the pads, XOR'd with ipad and opad values */ + for (i = 0; i < key_len; i++) { + k_ipad[i] = key[i] ^ 0x36; + ctx->k_opad[i] = key[i] ^ 0x5c; + } + /* remaining pad bytes are '\0' XOR'd with ipad and opad values */ + for ( ; i < blocksize; i++) { + k_ipad[i] = 0x36; + ctx->k_opad[i] = 0x5c; + } + + /* perform inner hash */ + /* init context for 1st pass */ + return USHAReset(&ctx->shaContext, whichSha) || + /* and start with inner pad */ + USHAInput(&ctx->shaContext, k_ipad, blocksize); +} + +/* + * hmacInput + * + * Description: + * This function accepts an array of octets as the next portion + * of the message. + + + +Eastlake 3rd & Hansen Informational [Page 75] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * + * Parameters: + * context: [in/out] + * The HMAC context to update + * message_array: [in] + * An array of characters representing the next portion of + * the message. + * length: [in] + * The length of the message in message_array + * + * Returns: + * sha Error Code. + * + */ +int hmacInput(HMACContext *ctx, const unsigned char *text, + int text_len) +{ + if (!ctx) return shaNull; + /* then text of datagram */ + return USHAInput(&ctx->shaContext, text, text_len); +} + +/* + * HMACFinalBits + * + * Description: + * This function will add in any final bits of the message. + * + * Parameters: + * context: [in/out] + * The HMAC context to update + * message_bits: [in] + * The final bits of the message, in the upper portion of the + * byte. (Use 0b###00000 instead of 0b00000### to input the + * three bits ###.) + * length: [in] + * The number of bits in message_bits, between 1 and 7. + * + * Returns: + * sha Error Code. + */ +int hmacFinalBits(HMACContext *ctx, + const uint8_t bits, + unsigned int bitcount) +{ + if (!ctx) return shaNull; + /* then final bits of datagram */ + return USHAFinalBits(&ctx->shaContext, bits, bitcount); + + + +Eastlake 3rd & Hansen Informational [Page 76] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +} + +/* + * HMACResult + * + * Description: + * This function will return the N-byte message digest into the + * Message_Digest array provided by the caller. + * NOTE: The first octet of hash is stored in the 0th element, + * the last octet of hash in the Nth element. + * + * Parameters: + * context: [in/out] + * The context to use to calculate the HMAC hash. + * digest: [out] + * Where the digest is returned. + * NOTE 2: The length of the hash is determined by the value of + * whichSha that was passed to hmacReset(). + * + * Returns: + * sha Error Code. + * + */ +int hmacResult(HMACContext *ctx, uint8_t *digest) +{ + if (!ctx) return shaNull; + + /* finish up 1st pass */ + /* (Use digest here as a temporary buffer.) */ + return USHAResult(&ctx->shaContext, digest) || + + /* perform outer SHA */ + /* init context for 2nd pass */ + USHAReset(&ctx->shaContext, ctx->whichSha) || + + /* start with outer pad */ + USHAInput(&ctx->shaContext, ctx->k_opad, ctx->blockSize) || + + /* then results of 1st hash */ + USHAInput(&ctx->shaContext, digest, ctx->hashSize) || + + /* finish up 2nd pass */ + USHAResult(&ctx->shaContext, digest); +} + + + + + + + +Eastlake 3rd & Hansen Informational [Page 77] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +8.4. The Test Driver + + The following code is a main program test driver to exercise the code + in sha1.c, sha224-256.c, and sha384-512.c. The test driver can also + be used as a stand-alone program for generating the hashes. + + See also [RFC2202], [RFC4231], and [SHAVS]. + +/**************************** shatest.c ****************************/ +/********************* See RFC 4634 for details ********************/ +/* + * Description: + * This file will exercise the SHA code performing + * the three tests documented in FIPS PUB 180-2 + * (http://csrc.nist.gov/publications/fips/ + * fips180-2/fips180-2withchangenotice.pdf) + * one that calls SHAInput with an exact multiple of 512 bits + * the seven tests documented for each algorithm in + * "The Secure Hash Algorithm Validation System (SHAVS)", + * three of which are bit-level tests + * (http://csrc.nist.gov/cryptval/shs/SHAVS.pdf) + * + * This file will exercise the HMAC SHA1 code performing + * the seven tests documented in RFCs 2202 and 4231. + * + * To run the tests and just see PASSED/FAILED, use the -p option. + * + * Other options exercise: + * hashing an arbitrary string + * hashing a file's contents + * a few error test checks + * printing the results in raw format + * + * Portability Issues: + * None. + * + */ + +#include <stdint.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <ctype.h> +#include "sha.h" + +static int xgetopt(int argc, char **argv, const char *optstring); +extern char *xoptarg; +static int scasecmp(const char *s1, const char *s2); + + + +Eastlake 3rd & Hansen Informational [Page 78] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +/* + * Define patterns for testing + */ +#define TEST1 "abc" +#define TEST2_1 \ + "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq" +#define TEST2_2a \ + "abcdefghbcdefghicdefghijdefghijkefghijklfghijklmghijklmn" +#define TEST2_2b \ + "hijklmnoijklmnopjklmnopqklmnopqrlmnopqrsmnopqrstnopqrstu" +#define TEST2_2 TEST2_2a TEST2_2b +#define TEST3 "a" /* times 1000000 */ +#define TEST4a "01234567012345670123456701234567" +#define TEST4b "01234567012345670123456701234567" + /* an exact multiple of 512 bits */ +#define TEST4 TEST4a TEST4b /* times 10 */ + +#define TEST7_1 \ + "\x49\xb2\xae\xc2\x59\x4b\xbe\x3a\x3b\x11\x75\x42\xd9\x4a\xc8" +#define TEST8_1 \ + "\x9a\x7d\xfd\xf1\xec\xea\xd0\x6e\xd6\x46\xaa\x55\xfe\x75\x71\x46" +#define TEST9_1 \ + "\x65\xf9\x32\x99\x5b\xa4\xce\x2c\xb1\xb4\xa2\xe7\x1a\xe7\x02\x20" \ + "\xaa\xce\xc8\x96\x2d\xd4\x49\x9c\xbd\x7c\x88\x7a\x94\xea\xaa\x10" \ + "\x1e\xa5\xaa\xbc\x52\x9b\x4e\x7e\x43\x66\x5a\x5a\xf2\xcd\x03\xfe" \ + "\x67\x8e\xa6\xa5\x00\x5b\xba\x3b\x08\x22\x04\xc2\x8b\x91\x09\xf4" \ + "\x69\xda\xc9\x2a\xaa\xb3\xaa\x7c\x11\xa1\xb3\x2a" +#define TEST10_1 \ + "\xf7\x8f\x92\x14\x1b\xcd\x17\x0a\xe8\x9b\x4f\xba\x15\xa1\xd5\x9f" \ + "\x3f\xd8\x4d\x22\x3c\x92\x51\xbd\xac\xbb\xae\x61\xd0\x5e\xd1\x15" \ + "\xa0\x6a\x7c\xe1\x17\xb7\xbe\xea\xd2\x44\x21\xde\xd9\xc3\x25\x92" \ + "\xbd\x57\xed\xea\xe3\x9c\x39\xfa\x1f\xe8\x94\x6a\x84\xd0\xcf\x1f" \ + "\x7b\xee\xad\x17\x13\xe2\xe0\x95\x98\x97\x34\x7f\x67\xc8\x0b\x04" \ + "\x00\xc2\x09\x81\x5d\x6b\x10\xa6\x83\x83\x6f\xd5\x56\x2a\x56\xca" \ + "\xb1\xa2\x8e\x81\xb6\x57\x66\x54\x63\x1c\xf1\x65\x66\xb8\x6e\x3b" \ + "\x33\xa1\x08\xb0\x53\x07\xc0\x0a\xff\x14\xa7\x68\xed\x73\x50\x60" \ + "\x6a\x0f\x85\xe6\xa9\x1d\x39\x6f\x5b\x5c\xbe\x57\x7f\x9b\x38\x80" \ + "\x7c\x7d\x52\x3d\x6d\x79\x2f\x6e\xbc\x24\xa4\xec\xf2\xb3\xa4\x27" \ + "\xcd\xbb\xfb" +#define TEST7_224 \ + "\xf0\x70\x06\xf2\x5a\x0b\xea\x68\xcd\x76\xa2\x95\x87\xc2\x8d" +#define TEST8_224 \ + "\x18\x80\x40\x05\xdd\x4f\xbd\x15\x56\x29\x9d\x6f\x9d\x93\xdf\x62" +#define TEST9_224 \ + "\xa2\xbe\x6e\x46\x32\x81\x09\x02\x94\xd9\xce\x94\x82\x65\x69\x42" \ + "\x3a\x3a\x30\x5e\xd5\xe2\x11\x6c\xd4\xa4\xc9\x87\xfc\x06\x57\x00" \ + "\x64\x91\xb1\x49\xcc\xd4\xb5\x11\x30\xac\x62\xb1\x9d\xc2\x48\xc7" \ + "\x44\x54\x3d\x20\xcd\x39\x52\xdc\xed\x1f\x06\xcc\x3b\x18\xb9\x1f" \ + + + +Eastlake 3rd & Hansen Informational [Page 79] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + "\x3f\x55\x63\x3e\xcc\x30\x85\xf4\x90\x70\x60\xd2" +#define TEST10_224 \ + "\x55\xb2\x10\x07\x9c\x61\xb5\x3a\xdd\x52\x06\x22\xd1\xac\x97\xd5" \ + "\xcd\xbe\x8c\xb3\x3a\xa0\xae\x34\x45\x17\xbe\xe4\xd7\xba\x09\xab" \ + "\xc8\x53\x3c\x52\x50\x88\x7a\x43\xbe\xbb\xac\x90\x6c\x2e\x18\x37" \ + "\xf2\x6b\x36\xa5\x9a\xe3\xbe\x78\x14\xd5\x06\x89\x6b\x71\x8b\x2a" \ + "\x38\x3e\xcd\xac\x16\xb9\x61\x25\x55\x3f\x41\x6f\xf3\x2c\x66\x74" \ + "\xc7\x45\x99\xa9\x00\x53\x86\xd9\xce\x11\x12\x24\x5f\x48\xee\x47" \ + "\x0d\x39\x6c\x1e\xd6\x3b\x92\x67\x0c\xa5\x6e\xc8\x4d\xee\xa8\x14" \ + "\xb6\x13\x5e\xca\x54\x39\x2b\xde\xdb\x94\x89\xbc\x9b\x87\x5a\x8b" \ + "\xaf\x0d\xc1\xae\x78\x57\x36\x91\x4a\xb7\xda\xa2\x64\xbc\x07\x9d" \ + "\x26\x9f\x2c\x0d\x7e\xdd\xd8\x10\xa4\x26\x14\x5a\x07\x76\xf6\x7c" \ + "\x87\x82\x73" +#define TEST7_256 \ + "\xbe\x27\x46\xc6\xdb\x52\x76\x5f\xdb\x2f\x88\x70\x0f\x9a\x73" +#define TEST8_256 \ + "\xe3\xd7\x25\x70\xdc\xdd\x78\x7c\xe3\x88\x7a\xb2\xcd\x68\x46\x52" +#define TEST9_256 \ + "\x3e\x74\x03\x71\xc8\x10\xc2\xb9\x9f\xc0\x4e\x80\x49\x07\xef\x7c" \ + "\xf2\x6b\xe2\x8b\x57\xcb\x58\xa3\xe2\xf3\xc0\x07\x16\x6e\x49\xc1" \ + "\x2e\x9b\xa3\x4c\x01\x04\x06\x91\x29\xea\x76\x15\x64\x25\x45\x70" \ + "\x3a\x2b\xd9\x01\xe1\x6e\xb0\xe0\x5d\xeb\xa0\x14\xeb\xff\x64\x06" \ + "\xa0\x7d\x54\x36\x4e\xff\x74\x2d\xa7\x79\xb0\xb3" +#define TEST10_256 \ + "\x83\x26\x75\x4e\x22\x77\x37\x2f\x4f\xc1\x2b\x20\x52\x7a\xfe\xf0" \ + "\x4d\x8a\x05\x69\x71\xb1\x1a\xd5\x71\x23\xa7\xc1\x37\x76\x00\x00" \ + "\xd7\xbe\xf6\xf3\xc1\xf7\xa9\x08\x3a\xa3\x9d\x81\x0d\xb3\x10\x77" \ + "\x7d\xab\x8b\x1e\x7f\x02\xb8\x4a\x26\xc7\x73\x32\x5f\x8b\x23\x74" \ + "\xde\x7a\x4b\x5a\x58\xcb\x5c\x5c\xf3\x5b\xce\xe6\xfb\x94\x6e\x5b" \ + "\xd6\x94\xfa\x59\x3a\x8b\xeb\x3f\x9d\x65\x92\xec\xed\xaa\x66\xca" \ + "\x82\xa2\x9d\x0c\x51\xbc\xf9\x33\x62\x30\xe5\xd7\x84\xe4\xc0\xa4" \ + "\x3f\x8d\x79\xa3\x0a\x16\x5c\xba\xbe\x45\x2b\x77\x4b\x9c\x71\x09" \ + "\xa9\x7d\x13\x8f\x12\x92\x28\x96\x6f\x6c\x0a\xdc\x10\x6a\xad\x5a" \ + "\x9f\xdd\x30\x82\x57\x69\xb2\xc6\x71\xaf\x67\x59\xdf\x28\xeb\x39" \ + "\x3d\x54\xd6" +#define TEST7_384 \ + "\x8b\xc5\x00\xc7\x7c\xee\xd9\x87\x9d\xa9\x89\x10\x7c\xe0\xaa" +#define TEST8_384 \ + "\xa4\x1c\x49\x77\x79\xc0\x37\x5f\xf1\x0a\x7f\x4e\x08\x59\x17\x39" +#define TEST9_384 \ + "\x68\xf5\x01\x79\x2d\xea\x97\x96\x76\x70\x22\xd9\x3d\xa7\x16\x79" \ + "\x30\x99\x20\xfa\x10\x12\xae\xa3\x57\xb2\xb1\x33\x1d\x40\xa1\xd0" \ + "\x3c\x41\xc2\x40\xb3\xc9\xa7\x5b\x48\x92\xf4\xc0\x72\x4b\x68\xc8" \ + "\x75\x32\x1a\xb8\xcf\xe5\x02\x3b\xd3\x75\xbc\x0f\x94\xbd\x89\xfe" \ + "\x04\xf2\x97\x10\x5d\x7b\x82\xff\xc0\x02\x1a\xeb\x1c\xcb\x67\x4f" \ + "\x52\x44\xea\x34\x97\xde\x26\xa4\x19\x1c\x5f\x62\xe5\xe9\xa2\xd8" \ + "\x08\x2f\x05\x51\xf4\xa5\x30\x68\x26\xe9\x1c\xc0\x06\xce\x1b\xf6" \ + "\x0f\xf7\x19\xd4\x2f\xa5\x21\xc8\x71\xcd\x23\x94\xd9\x6e\xf4\x46" \ + + + +Eastlake 3rd & Hansen Informational [Page 80] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + "\x8f\x21\x96\x6b\x41\xf2\xba\x80\xc2\x6e\x83\xa9" +#define TEST10_384 \ + "\x39\x96\x69\xe2\x8f\x6b\x9c\x6d\xbc\xbb\x69\x12\xec\x10\xff\xcf" \ + "\x74\x79\x03\x49\xb7\xdc\x8f\xbe\x4a\x8e\x7b\x3b\x56\x21\xdb\x0f" \ + "\x3e\x7d\xc8\x7f\x82\x32\x64\xbb\xe4\x0d\x18\x11\xc9\xea\x20\x61" \ + "\xe1\xc8\x4a\xd1\x0a\x23\xfa\xc1\x72\x7e\x72\x02\xfc\x3f\x50\x42" \ + "\xe6\xbf\x58\xcb\xa8\xa2\x74\x6e\x1f\x64\xf9\xb9\xea\x35\x2c\x71" \ + "\x15\x07\x05\x3c\xf4\xe5\x33\x9d\x52\x86\x5f\x25\xcc\x22\xb5\xe8" \ + "\x77\x84\xa1\x2f\xc9\x61\xd6\x6c\xb6\xe8\x95\x73\x19\x9a\x2c\xe6" \ + "\x56\x5c\xbd\xf1\x3d\xca\x40\x38\x32\xcf\xcb\x0e\x8b\x72\x11\xe8" \ + "\x3a\xf3\x2a\x11\xac\x17\x92\x9f\xf1\xc0\x73\xa5\x1c\xc0\x27\xaa" \ + "\xed\xef\xf8\x5a\xad\x7c\x2b\x7c\x5a\x80\x3e\x24\x04\xd9\x6d\x2a" \ + "\x77\x35\x7b\xda\x1a\x6d\xae\xed\x17\x15\x1c\xb9\xbc\x51\x25\xa4" \ + "\x22\xe9\x41\xde\x0c\xa0\xfc\x50\x11\xc2\x3e\xcf\xfe\xfd\xd0\x96" \ + "\x76\x71\x1c\xf3\xdb\x0a\x34\x40\x72\x0e\x16\x15\xc1\xf2\x2f\xbc" \ + "\x3c\x72\x1d\xe5\x21\xe1\xb9\x9b\xa1\xbd\x55\x77\x40\x86\x42\x14" \ + "\x7e\xd0\x96" +#define TEST7_512 \ + "\x08\xec\xb5\x2e\xba\xe1\xf7\x42\x2d\xb6\x2b\xcd\x54\x26\x70" +#define TEST8_512 \ + "\x8d\x4e\x3c\x0e\x38\x89\x19\x14\x91\x81\x6e\x9d\x98\xbf\xf0\xa0" +#define TEST9_512 \ + "\x3a\xdd\xec\x85\x59\x32\x16\xd1\x61\x9a\xa0\x2d\x97\x56\x97\x0b" \ + "\xfc\x70\xac\xe2\x74\x4f\x7c\x6b\x27\x88\x15\x10\x28\xf7\xb6\xa2" \ + "\x55\x0f\xd7\x4a\x7e\x6e\x69\xc2\xc9\xb4\x5f\xc4\x54\x96\x6d\xc3" \ + "\x1d\x2e\x10\xda\x1f\x95\xce\x02\xbe\xb4\xbf\x87\x65\x57\x4c\xbd" \ + "\x6e\x83\x37\xef\x42\x0a\xdc\x98\xc1\x5c\xb6\xd5\xe4\xa0\x24\x1b" \ + "\xa0\x04\x6d\x25\x0e\x51\x02\x31\xca\xc2\x04\x6c\x99\x16\x06\xab" \ + "\x4e\xe4\x14\x5b\xee\x2f\xf4\xbb\x12\x3a\xab\x49\x8d\x9d\x44\x79" \ + "\x4f\x99\xcc\xad\x89\xa9\xa1\x62\x12\x59\xed\xa7\x0a\x5b\x6d\xd4" \ + "\xbd\xd8\x77\x78\xc9\x04\x3b\x93\x84\xf5\x49\x06" +#define TEST10_512 \ + "\xa5\x5f\x20\xc4\x11\xaa\xd1\x32\x80\x7a\x50\x2d\x65\x82\x4e\x31" \ + "\xa2\x30\x54\x32\xaa\x3d\x06\xd3\xe2\x82\xa8\xd8\x4e\x0d\xe1\xde" \ + "\x69\x74\xbf\x49\x54\x69\xfc\x7f\x33\x8f\x80\x54\xd5\x8c\x26\xc4" \ + "\x93\x60\xc3\xe8\x7a\xf5\x65\x23\xac\xf6\xd8\x9d\x03\xe5\x6f\xf2" \ + "\xf8\x68\x00\x2b\xc3\xe4\x31\xed\xc4\x4d\xf2\xf0\x22\x3d\x4b\xb3" \ + "\xb2\x43\x58\x6e\x1a\x7d\x92\x49\x36\x69\x4f\xcb\xba\xf8\x8d\x95" \ + "\x19\xe4\xeb\x50\xa6\x44\xf8\xe4\xf9\x5e\xb0\xea\x95\xbc\x44\x65" \ + "\xc8\x82\x1a\xac\xd2\xfe\x15\xab\x49\x81\x16\x4b\xbb\x6d\xc3\x2f" \ + "\x96\x90\x87\xa1\x45\xb0\xd9\xcc\x9c\x67\xc2\x2b\x76\x32\x99\x41" \ + "\x9c\xc4\x12\x8b\xe9\xa0\x77\xb3\xac\xe6\x34\x06\x4e\x6d\x99\x28" \ + "\x35\x13\xdc\x06\xe7\x51\x5d\x0d\x73\x13\x2e\x9a\x0d\xc6\xd3\xb1" \ + "\xf8\xb2\x46\xf1\xa9\x8a\x3f\xc7\x29\x41\xb1\xe3\xbb\x20\x98\xe8" \ + "\xbf\x16\xf2\x68\xd6\x4f\x0b\x0f\x47\x07\xfe\x1e\xa1\xa1\x79\x1b" \ + "\xa2\xf3\xc0\xc7\x58\xe5\xf5\x51\x86\x3a\x96\xc9\x49\xad\x47\xd7" \ + "\xfb\x40\xd2" +#define SHA1_SEED "\xd0\x56\x9c\xb3\x66\x5a\x8a\x43\xeb\x6e\xa2\x3d" \ + + + +Eastlake 3rd & Hansen Informational [Page 81] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + "\x75\xa3\xc4\xd2\x05\x4a\x0d\x7d" +#define SHA224_SEED "\xd0\x56\x9c\xb3\x66\x5a\x8a\x43\xeb\x6e\xa2" \ + "\x3d\x75\xa3\xc4\xd2\x05\x4a\x0d\x7d\x66\xa9\xca\x99\xc9\xce\xb0" \ + "\x27" +#define SHA256_SEED "\xf4\x1e\xce\x26\x13\xe4\x57\x39\x15\x69\x6b" \ + "\x5a\xdc\xd5\x1c\xa3\x28\xbe\x3b\xf5\x66\xa9\xca\x99\xc9\xce\xb0" \ + "\x27\x9c\x1c\xb0\xa7" +#define SHA384_SEED "\x82\x40\xbc\x51\xe4\xec\x7e\xf7\x6d\x18\xe3" \ + "\x52\x04\xa1\x9f\x51\xa5\x21\x3a\x73\xa8\x1d\x6f\x94\x46\x80\xd3" \ + "\x07\x59\x48\xb7\xe4\x63\x80\x4e\xa3\xd2\x6e\x13\xea\x82\x0d\x65" \ + "\xa4\x84\xbe\x74\x53" +#define SHA512_SEED "\x47\x3f\xf1\xb9\xb3\xff\xdf\xa1\x26\x69\x9a" \ + "\xc7\xef\x9e\x8e\x78\x77\x73\x09\x58\x24\xc6\x42\x55\x7c\x13\x99" \ + "\xd9\x8e\x42\x20\x44\x8d\xc3\x5b\x99\xbf\xdd\x44\x77\x95\x43\x92" \ + "\x4c\x1c\xe9\x3b\xc5\x94\x15\x38\x89\x5d\xb9\x88\x26\x1b\x00\x77" \ + "\x4b\x12\x27\x20\x39" + +#define TESTCOUNT 10 +#define HASHCOUNT 5 +#define RANDOMCOUNT 4 +#define HMACTESTCOUNT 7 + +#define PRINTNONE 0 +#define PRINTTEXT 1 +#define PRINTRAW 2 +#define PRINTHEX 3 +#define PRINTBASE64 4 + +#define PRINTPASSFAIL 1 +#define PRINTFAIL 2 + +#define length(x) (sizeof(x)-1) + +/* Test arrays for hashes. */ +struct hash { + const char *name; + SHAversion whichSha; + int hashsize; + struct { + const char *testarray; + int length; + long repeatcount; + int extrabits; + int numberExtrabits; + const char *resultarray; + } tests[TESTCOUNT]; + const char *randomtest; + const char *randomresults[RANDOMCOUNT]; + + + +Eastlake 3rd & Hansen Informational [Page 82] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +} hashes[HASHCOUNT] = { + { "SHA1", SHA1, SHA1HashSize, + { + /* 1 */ { TEST1, length(TEST1), 1, 0, 0, + "A9993E364706816ABA3E25717850C26C9CD0D89D" }, + /* 2 */ { TEST2_1, length(TEST2_1), 1, 0, 0, + "84983E441C3BD26EBAAE4AA1F95129E5E54670F1" }, + /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0, + "34AA973CD4C4DAA4F61EEB2BDBAD27316534016F" }, + /* 4 */ { TEST4, length(TEST4), 10, 0, 0, + "DEA356A2CDDD90C7A7ECEDC5EBB563934F460452" }, + /* 5 */ { "", 0, 0, 0x98, 5, + "29826B003B906E660EFF4027CE98AF3531AC75BA" }, + /* 6 */ { "\x5e", 1, 1, 0, 0, + "5E6F80A34A9798CAFC6A5DB96CC57BA4C4DB59C2" }, + /* 7 */ { TEST7_1, length(TEST7_1), 1, 0x80, 3, + "6239781E03729919C01955B3FFA8ACB60B988340" }, + /* 8 */ { TEST8_1, length(TEST8_1), 1, 0, 0, + "82ABFF6605DBE1C17DEF12A394FA22A82B544A35" }, + /* 9 */ { TEST9_1, length(TEST9_1), 1, 0xE0, 3, + "8C5B2A5DDAE5A97FC7F9D85661C672ADBF7933D4" }, + /* 10 */ { TEST10_1, length(TEST10_1), 1, 0, 0, + "CB0082C8F197D260991BA6A460E76E202BAD27B3" } + }, SHA1_SEED, { "E216836819477C7F78E0D843FE4FF1B6D6C14CD4", + "A2DBC7A5B1C6C0A8BCB7AAA41252A6A7D0690DBC", + "DB1F9050BB863DFEF4CE37186044E2EEB17EE013", + "127FDEDF43D372A51D5747C48FBFFE38EF6CDF7B" + } }, + { "SHA224", SHA224, SHA224HashSize, + { + /* 1 */ { TEST1, length(TEST1), 1, 0, 0, + "23097D223405D8228642A477BDA255B32AADBCE4BDA0B3F7E36C9DA7" }, + /* 2 */ { TEST2_1, length(TEST2_1), 1, 0, 0, + "75388B16512776CC5DBA5DA1FD890150B0C6455CB4F58B1952522525" }, + /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0, + "20794655980C91D8BBB4C1EA97618A4BF03F42581948B2EE4EE7AD67" }, + /* 4 */ { TEST4, length(TEST4), 10, 0, 0, + "567F69F168CD7844E65259CE658FE7AADFA25216E68ECA0EB7AB8262" }, + /* 5 */ { "", 0, 0, 0x68, 5, + "E3B048552C3C387BCAB37F6EB06BB79B96A4AEE5FF27F51531A9551C" }, + /* 6 */ { "\x07", 1, 1, 0, 0, + "00ECD5F138422B8AD74C9799FD826C531BAD2FCABC7450BEE2AA8C2A" }, + /* 7 */ { TEST7_224, length(TEST7_224), 1, 0xA0, 3, + "1B01DB6CB4A9E43DED1516BEB3DB0B87B6D1EA43187462C608137150" }, + /* 8 */ { TEST8_224, length(TEST8_224), 1, 0, 0, + "DF90D78AA78821C99B40BA4C966921ACCD8FFB1E98AC388E56191DB1" }, + /* 9 */ { TEST9_224, length(TEST9_224), 1, 0xE0, 3, + "54BEA6EAB8195A2EB0A7906A4B4A876666300EEFBD1F3B8474F9CD57" }, + + + +Eastlake 3rd & Hansen Informational [Page 83] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + /* 10 */ { TEST10_224, length(TEST10_224), 1, 0, 0, + "0B31894EC8937AD9B91BDFBCBA294D9ADEFAA18E09305E9F20D5C3A4" } + }, SHA224_SEED, { "100966A5B4FDE0B42E2A6C5953D4D7F41BA7CF79FD" + "2DF431416734BE", "1DCA396B0C417715DEFAAE9641E10A2E99D55A" + "BCB8A00061EB3BE8BD", "1864E627BDB2319973CD5ED7D68DA71D8B" + "F0F983D8D9AB32C34ADB34", "A2406481FC1BCAF24DD08E6752E844" + "709563FB916227FED598EB621F" + } }, + { "SHA256", SHA256, SHA256HashSize, + { + /* 1 */ { TEST1, length(TEST1), 1, 0, 0, "BA7816BF8F01CFEA4141" + "40DE5DAE2223B00361A396177A9CB410FF61F20015AD" }, + /* 2 */ { TEST2_1, length(TEST2_1), 1, 0, 0, "248D6A61D20638B8" + "E5C026930C3E6039A33CE45964FF2167F6ECEDD419DB06C1" }, + /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0, "CDC76E5C9914FB92" + "81A1C7E284D73E67F1809A48A497200E046D39CCC7112CD0" }, + /* 4 */ { TEST4, length(TEST4), 10, 0, 0, "594847328451BDFA" + "85056225462CC1D867D877FB388DF0CE35F25AB5562BFBB5" }, + /* 5 */ { "", 0, 0, 0x68, 5, "D6D3E02A31A84A8CAA9718ED6C2057BE" + "09DB45E7823EB5079CE7A573A3760F95" }, + /* 6 */ { "\x19", 1, 1, 0, 0, "68AA2E2EE5DFF96E3355E6C7EE373E3D" + "6A4E17F75F9518D843709C0C9BC3E3D4" }, + /* 7 */ { TEST7_256, length(TEST7_256), 1, 0x60, 3, "77EC1DC8" + "9C821FF2A1279089FA091B35B8CD960BCAF7DE01C6A7680756BEB972" }, + /* 8 */ { TEST8_256, length(TEST8_256), 1, 0, 0, "175EE69B02BA" + "9B58E2B0A5FD13819CEA573F3940A94F825128CF4209BEABB4E8" }, + /* 9 */ { TEST9_256, length(TEST9_256), 1, 0xA0, 3, "3E9AD646" + "8BBBAD2AC3C2CDC292E018BA5FD70B960CF1679777FCE708FDB066E9" }, + /* 10 */ { TEST10_256, length(TEST10_256), 1, 0, 0, "97DBCA7D" + "F46D62C8A422C941DD7E835B8AD3361763F7E9B2D95F4F0DA6E1CCBC" }, + }, SHA256_SEED, { "83D28614D49C3ADC1D6FC05DB5F48037C056F8D2A4CE44" + "EC6457DEA5DD797CD1", "99DBE3127EF2E93DD9322D6A07909EB33B6399" + "5E529B3F954B8581621BB74D39", "8D4BE295BB64661CA3C7EFD129A2F7" + "25B33072DBDDE32385B9A87B9AF88EA76F", "40AF5D3F9716B040DF9408" + "E31536B70FF906EC51B00447CA97D7DD97C12411F4" + } }, + { "SHA384", SHA384, SHA384HashSize, + { + /* 1 */ { TEST1, length(TEST1), 1, 0, 0, + "CB00753F45A35E8BB5A03D699AC65007272C32AB0EDED163" + "1A8B605A43FF5BED8086072BA1E7CC2358BAECA134C825A7" }, + /* 2 */ { TEST2_2, length(TEST2_2), 1, 0, 0, + "09330C33F71147E83D192FC782CD1B4753111B173B3B05D2" + "2FA08086E3B0F712FCC7C71A557E2DB966C3E9FA91746039" }, + /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0, + "9D0E1809716474CB086E834E310A4A1CED149E9C00F24852" + "7972CEC5704C2A5B07B8B3DC38ECC4EBAE97DDD87F3D8985" }, + /* 4 */ { TEST4, length(TEST4), 10, 0, 0, + + + +Eastlake 3rd & Hansen Informational [Page 84] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + "2FC64A4F500DDB6828F6A3430B8DD72A368EB7F3A8322A70" + "BC84275B9C0B3AB00D27A5CC3C2D224AA6B61A0D79FB4596" }, + /* 5 */ { "", 0, 0, 0x10, 5, + "8D17BE79E32B6718E07D8A603EB84BA0478F7FCFD1BB9399" + "5F7D1149E09143AC1FFCFC56820E469F3878D957A15A3FE4" }, + /* 6 */ { "\xb9", 1, 1, 0, 0, + "BC8089A19007C0B14195F4ECC74094FEC64F01F90929282C" + "2FB392881578208AD466828B1C6C283D2722CF0AD1AB6938" }, + /* 7 */ { TEST7_384, length(TEST7_384), 1, 0xA0, 3, + "D8C43B38E12E7C42A7C9B810299FD6A770BEF30920F17532" + "A898DE62C7A07E4293449C0B5FA70109F0783211CFC4BCE3" }, + /* 8 */ { TEST8_384, length(TEST8_384), 1, 0, 0, + "C9A68443A005812256B8EC76B00516F0DBB74FAB26D66591" + "3F194B6FFB0E91EA9967566B58109CBC675CC208E4C823F7" }, + /* 9 */ { TEST9_384, length(TEST9_384), 1, 0xE0, 3, + "5860E8DE91C21578BB4174D227898A98E0B45C4C760F0095" + "49495614DAEDC0775D92D11D9F8CE9B064EEAC8DAFC3A297" }, + /* 10 */ { TEST10_384, length(TEST10_384), 1, 0, 0, + "4F440DB1E6EDD2899FA335F09515AA025EE177A79F4B4AAF" + "38E42B5C4DE660F5DE8FB2A5B2FBD2A3CBFFD20CFF1288C0" } + }, SHA384_SEED, { "CE44D7D63AE0C91482998CF662A51EC80BF6FC68661A3C" + "57F87566112BD635A743EA904DEB7D7A42AC808CABE697F38F", "F9C6D2" + "61881FEE41ACD39E67AA8D0BAD507C7363EB67E2B81F45759F9C0FD7B503" + "DF1A0B9E80BDE7BC333D75B804197D", "D96512D8C9F4A7A4967A366C01" + "C6FD97384225B58343A88264847C18E4EF8AB7AEE4765FFBC3E30BD485D3" + "638A01418F", "0CA76BD0813AF1509E170907A96005938BC985628290B2" + "5FEF73CF6FAD68DDBA0AC8920C94E0541607B0915A7B4457F7" + } }, + { "SHA512", SHA512, SHA512HashSize, + { + /* 1 */ { TEST1, length(TEST1), 1, 0, 0, + "DDAF35A193617ABACC417349AE20413112E6FA4E89A97EA2" + "0A9EEEE64B55D39A2192992A274FC1A836BA3C23A3FEEBBD" + "454D4423643CE80E2A9AC94FA54CA49F" }, + /* 2 */ { TEST2_2, length(TEST2_2), 1, 0, 0, + "8E959B75DAE313DA8CF4F72814FC143F8F7779C6EB9F7FA1" + "7299AEADB6889018501D289E4900F7E4331B99DEC4B5433A" + "C7D329EEB6DD26545E96E55B874BE909" }, + /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0, + "E718483D0CE769644E2E42C7BC15B4638E1F98B13B204428" + "5632A803AFA973EBDE0FF244877EA60A4CB0432CE577C31B" + "EB009C5C2C49AA2E4EADB217AD8CC09B" }, + /* 4 */ { TEST4, length(TEST4), 10, 0, 0, + "89D05BA632C699C31231DED4FFC127D5A894DAD412C0E024" + "DB872D1ABD2BA8141A0F85072A9BE1E2AA04CF33C765CB51" + "0813A39CD5A84C4ACAA64D3F3FB7BAE9" }, + /* 5 */ { "", 0, 0, 0xB0, 5, + "D4EE29A9E90985446B913CF1D1376C836F4BE2C1CF3CADA0" + + + +Eastlake 3rd & Hansen Informational [Page 85] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + "720A6BF4857D886A7ECB3C4E4C0FA8C7F95214E41DC1B0D2" + "1B22A84CC03BF8CE4845F34DD5BDBAD4" }, + /* 6 */ { "\xD0", 1, 1, 0, 0, + "9992202938E882E73E20F6B69E68A0A7149090423D93C81B" + "AB3F21678D4ACEEEE50E4E8CAFADA4C85A54EA8306826C4A" + "D6E74CECE9631BFA8A549B4AB3FBBA15" }, + /* 7 */ { TEST7_512, length(TEST7_512), 1, 0x80, 3, + "ED8DC78E8B01B69750053DBB7A0A9EDA0FB9E9D292B1ED71" + "5E80A7FE290A4E16664FD913E85854400C5AF05E6DAD316B" + "7359B43E64F8BEC3C1F237119986BBB6" }, + /* 8 */ { TEST8_512, length(TEST8_512), 1, 0, 0, + "CB0B67A4B8712CD73C9AABC0B199E9269B20844AFB75ACBD" + "D1C153C9828924C3DDEDAAFE669C5FDD0BC66F630F677398" + "8213EB1B16F517AD0DE4B2F0C95C90F8" }, + /* 9 */ { TEST9_512, length(TEST9_512), 1, 0x80, 3, + "32BA76FC30EAA0208AEB50FFB5AF1864FDBF17902A4DC0A6" + "82C61FCEA6D92B783267B21080301837F59DE79C6B337DB2" + "526F8A0A510E5E53CAFED4355FE7C2F1" }, + /* 10 */ { TEST10_512, length(TEST10_512), 1, 0, 0, + "C665BEFB36DA189D78822D10528CBF3B12B3EEF726039909" + "C1A16A270D48719377966B957A878E720584779A62825C18" + "DA26415E49A7176A894E7510FD1451F5" } + }, SHA512_SEED, { "2FBB1E7E00F746BA514FBC8C421F36792EC0E11FF5EFC3" + "78E1AB0C079AA5F0F66A1E3EDBAEB4F9984BE14437123038A452004A5576" + "8C1FD8EED49E4A21BEDCD0", "25CBE5A4F2C7B1D7EF07011705D50C62C5" + "000594243EAFD1241FC9F3D22B58184AE2FEE38E171CF8129E29459C9BC2" + "EF461AF5708887315F15419D8D17FE7949", "5B8B1F2687555CE2D7182B" + "92E5C3F6C36547DA1C13DBB9EA4F73EA4CBBAF89411527906D35B1B06C1B" + "6A8007D05EC66DF0A406066829EAB618BDE3976515AAFC", "46E36B007D" + "19876CDB0B29AD074FE3C08CDD174D42169D6ABE5A1414B6E79707DF5877" + "6A98091CF431854147BB6D3C66D43BFBC108FD715BDE6AA127C2B0E79F" + } + } +}; + +/* Test arrays for HMAC. */ +struct hmachash { + const char *keyarray[5]; + int keylength[5]; + const char *dataarray[5]; + int datalength[5]; + const char *resultarray[5]; + int resultlength[5]; +} hmachashes[HMACTESTCOUNT] = { + { /* 1 */ { + "\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b" + "\x0b\x0b\x0b\x0b\x0b" + }, { 20 }, { + + + +Eastlake 3rd & Hansen Informational [Page 86] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + "\x48\x69\x20\x54\x68\x65\x72\x65" /* "Hi There" */ + }, { 8 }, { + /* HMAC-SHA-1 */ + "B617318655057264E28BC0B6FB378C8EF146BE00", + /* HMAC-SHA-224 */ + "896FB1128ABBDF196832107CD49DF33F47B4B1169912BA4F53684B22", + /* HMAC-SHA-256 */ + "B0344C61D8DB38535CA8AFCEAF0BF12B881DC200C9833DA726E9376C2E32" + "CFF7", + /* HMAC-SHA-384 */ + "AFD03944D84895626B0825F4AB46907F15F9DADBE4101EC682AA034C7CEB" + "C59CFAEA9EA9076EDE7F4AF152E8B2FA9CB6", + /* HMAC-SHA-512 */ + "87AA7CDEA5EF619D4FF0B4241A1D6CB02379F4E2CE4EC2787AD0B30545E1" + "7CDEDAA833B7D6B8A702038B274EAEA3F4E4BE9D914EEB61F1702E696C20" + "3A126854" + }, { SHA1HashSize, SHA224HashSize, SHA256HashSize, + SHA384HashSize, SHA512HashSize } + }, + { /* 2 */ { + "\x4a\x65\x66\x65" /* "Jefe" */ + }, { 4 }, { + "\x77\x68\x61\x74\x20\x64\x6f\x20\x79\x61\x20\x77\x61\x6e\x74" + "\x20\x66\x6f\x72\x20\x6e\x6f\x74\x68\x69\x6e\x67\x3f" + /* "what do ya want for nothing?" */ + }, { 28 }, { + /* HMAC-SHA-1 */ + "EFFCDF6AE5EB2FA2D27416D5F184DF9C259A7C79", + /* HMAC-SHA-224 */ + "A30E01098BC6DBBF45690F3A7E9E6D0F8BBEA2A39E6148008FD05E44", + /* HMAC-SHA-256 */ + "5BDCC146BF60754E6A042426089575C75A003F089D2739839DEC58B964EC" + "3843", + /* HMAC-SHA-384 */ + "AF45D2E376484031617F78D2B58A6B1B9C7EF464F5A01B47E42EC3736322" + "445E8E2240CA5E69E2C78B3239ECFAB21649", + /* HMAC-SHA-512 */ + "164B7A7BFCF819E2E395FBE73B56E0A387BD64222E831FD610270CD7EA25" + "05549758BF75C05A994A6D034F65F8F0E6FDCAEAB1A34D4A6B4B636E070A" + "38BCE737" + }, { SHA1HashSize, SHA224HashSize, SHA256HashSize, + SHA384HashSize, SHA512HashSize } + }, + { /* 3 */ + { + "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa" + "\xaa\xaa\xaa\xaa\xaa" + }, { 20 }, { + + + +Eastlake 3rd & Hansen Informational [Page 87] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + "\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd" + "\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd" + "\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd" + "\xdd\xdd\xdd\xdd\xdd" + }, { 50 }, { + /* HMAC-SHA-1 */ + "125D7342B9AC11CD91A39AF48AA17B4F63F175D3", + /* HMAC-SHA-224 */ + "7FB3CB3588C6C1F6FFA9694D7D6AD2649365B0C1F65D69D1EC8333EA", + /* HMAC-SHA-256 */ + "773EA91E36800E46854DB8EBD09181A72959098B3EF8C122D9635514CED5" + "65FE", + /* HMAC-SHA-384 */ + "88062608D3E6AD8A0AA2ACE014C8A86F0AA635D947AC9FEBE83EF4E55966" + "144B2A5AB39DC13814B94E3AB6E101A34F27", + /* HMAC-SHA-512 */ + "FA73B0089D56A284EFB0F0756C890BE9B1B5DBDD8EE81A3655F83E33B227" + "9D39BF3E848279A722C806B485A47E67C807B946A337BEE8942674278859" + "E13292FB" + }, { SHA1HashSize, SHA224HashSize, SHA256HashSize, + SHA384HashSize, SHA512HashSize } + }, + { /* 4 */ { + "\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f" + "\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19" + }, { 25 }, { + "\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd" + "\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd" + "\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd" + "\xcd\xcd\xcd\xcd\xcd" + }, { 50 }, { + /* HMAC-SHA-1 */ + "4C9007F4026250C6BC8414F9BF50C86C2D7235DA", + /* HMAC-SHA-224 */ + "6C11506874013CAC6A2ABC1BB382627CEC6A90D86EFC012DE7AFEC5A", + /* HMAC-SHA-256 */ + "82558A389A443C0EA4CC819899F2083A85F0FAA3E578F8077A2E3FF46729" + "665B", + /* HMAC-SHA-384 */ + "3E8A69B7783C25851933AB6290AF6CA77A9981480850009CC5577C6E1F57" + "3B4E6801DD23C4A7D679CCF8A386C674CFFB", + /* HMAC-SHA-512 */ + "B0BA465637458C6990E5A8C5F61D4AF7E576D97FF94B872DE76F8050361E" + "E3DBA91CA5C11AA25EB4D679275CC5788063A5F19741120C4F2DE2ADEBEB" + "10A298DD" + }, { SHA1HashSize, SHA224HashSize, SHA256HashSize, + SHA384HashSize, SHA512HashSize } + }, + + + +Eastlake 3rd & Hansen Informational [Page 88] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + { /* 5 */ { + "\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c" + "\x0c\x0c\x0c\x0c\x0c" + }, { 20 }, { + "Test With Truncation" + }, { 20 }, { + /* HMAC-SHA-1 */ + "4C1A03424B55E07FE7F27BE1", + /* HMAC-SHA-224 */ + "0E2AEA68A90C8D37C988BCDB9FCA6FA8", + /* HMAC-SHA-256 */ + "A3B6167473100EE06E0C796C2955552B", + /* HMAC-SHA-384 */ + "3ABF34C3503B2A23A46EFC619BAEF897", + /* HMAC-SHA-512 */ + "415FAD6271580A531D4179BC891D87A6" + }, { 12, 16, 16, 16, 16 } + }, + { /* 6 */ { + "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa" + "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa" + "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa" + "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa" + "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa" + "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa" + "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa" + "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa" + "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa" + }, { 80, 131 }, { + "Test Using Larger Than Block-Size Key - Hash Key First" + }, { 54 }, { + /* HMAC-SHA-1 */ + "AA4AE5E15272D00E95705637CE8A3B55ED402112", + /* HMAC-SHA-224 */ + "95E9A0DB962095ADAEBE9B2D6F0DBCE2D499F112F2D2B7273FA6870E", + /* HMAC-SHA-256 */ + "60E431591EE0B67F0D8A26AACBF5B77F8E0BC6213728C5140546040F0EE3" + "7F54", + /* HMAC-SHA-384 */ + "4ECE084485813E9088D2C63A041BC5B44F9EF1012A2B588F3CD11F05033A" + "C4C60C2EF6AB4030FE8296248DF163F44952", + /* HMAC-SHA-512 */ + "80B24263C7C1A3EBB71493C1DD7BE8B49B46D1F41B4AEEC1121B013783F8" + "F3526B56D037E05F2598BD0FD2215D6A1E5295E64F73F63F0AEC8B915A98" + "5D786598" + }, { SHA1HashSize, SHA224HashSize, SHA256HashSize, + SHA384HashSize, SHA512HashSize } + }, + + + +Eastlake 3rd & Hansen Informational [Page 89] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + { /* 7 */ { + "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa" + "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa" + "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa" + "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa" + "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa" + "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa" + "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa" + "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa" + "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa" + }, { 80, 131 }, { + "Test Using Larger Than Block-Size Key and " + "Larger Than One Block-Size Data", + "\x54\x68\x69\x73\x20\x69\x73\x20\x61\x20\x74\x65\x73\x74\x20" + "\x75\x73\x69\x6e\x67\x20\x61\x20\x6c\x61\x72\x67\x65\x72\x20" + "\x74\x68\x61\x6e\x20\x62\x6c\x6f\x63\x6b\x2d\x73\x69\x7a\x65" + "\x20\x6b\x65\x79\x20\x61\x6e\x64\x20\x61\x20\x6c\x61\x72\x67" + "\x65\x72\x20\x74\x68\x61\x6e\x20\x62\x6c\x6f\x63\x6b\x2d\x73" + "\x69\x7a\x65\x20\x64\x61\x74\x61\x2e\x20\x54\x68\x65\x20\x6b" + "\x65\x79\x20\x6e\x65\x65\x64\x73\x20\x74\x6f\x20\x62\x65\x20" + "\x68\x61\x73\x68\x65\x64\x20\x62\x65\x66\x6f\x72\x65\x20\x62" + "\x65\x69\x6e\x67\x20\x75\x73\x65\x64\x20\x62\x79\x20\x74\x68" + "\x65\x20\x48\x4d\x41\x43\x20\x61\x6c\x67\x6f\x72\x69\x74\x68" + "\x6d\x2e" + /* "This is a test using a larger than block-size key and a " + "larger than block-size data. The key needs to be hashed " + "before being used by the HMAC algorithm." */ + }, { 73, 152 }, { + /* HMAC-SHA-1 */ + "E8E99D0F45237D786D6BBAA7965C7808BBFF1A91", + /* HMAC-SHA-224 */ + "3A854166AC5D9F023F54D517D0B39DBD946770DB9C2B95C9F6F565D1", + /* HMAC-SHA-256 */ + "9B09FFA71B942FCB27635FBCD5B0E944BFDC63644F0713938A7F51535C3A" + "35E2", + /* HMAC-SHA-384 */ + "6617178E941F020D351E2F254E8FD32C602420FEB0B8FB9ADCCEBB82461E" + "99C5A678CC31E799176D3860E6110C46523E", + /* HMAC-SHA-512 */ + "E37B6A775DC87DBAA4DFA9F96E5E3FFDDEBD71F8867289865DF5A32D20CD" + "C944B6022CAC3C4982B10D5EEB55C3E4DE15134676FB6DE0446065C97440" + "FA8C6A58" + }, { SHA1HashSize, SHA224HashSize, SHA256HashSize, + SHA384HashSize, SHA512HashSize } + } +}; + +/* + + + +Eastlake 3rd & Hansen Informational [Page 90] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * Check the hash value against the expected string, expressed in hex + */ +static const char hexdigits[] = "0123456789ABCDEF"; +int checkmatch(const unsigned char *hashvalue, + const char *hexstr, int hashsize) +{ + int i; + for (i = 0; i < hashsize; ++i) { + if (*hexstr++ != hexdigits[(hashvalue[i] >> 4) & 0xF]) + return 0; + if (*hexstr++ != hexdigits[hashvalue[i] & 0xF]) return 0; + } + return 1; +} + +/* + * Print the string, converting non-printable characters to "." + */ +void printstr(const char *str, int len) +{ + for ( ; len-- > 0; str++) + putchar(isprint((unsigned char)*str) ? *str : '.'); +} + +/* + * Print the string, converting non-printable characters to hex "## ". + */ +void printxstr(const char *str, int len) +{ + for ( ; len-- > 0; str++) + printf("%c%c ", hexdigits[(*str >> 4) & 0xF], + hexdigits[*str & 0xF]); +} + +/* + * Print a usage message. + */ +void usage(const char *argv0) +{ + fprintf(stderr, + "Usage:\n" + "Common options: [-h hash] [-w|-x] [-H]\n" + "Standard tests:\n" + "\t%s [-m] [-l loopcount] [-t test#] [-e]\n" + "\t\t[-r randomseed] [-R randomloop-count] " + "[-p] [-P|-X]\n" + "Hash a string:\n" + "\t%s [-S expectedresult] -s hashstr [-k key]\n" + + + +Eastlake 3rd & Hansen Informational [Page 91] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + "Hash a file:\n" + "\t%s [-S expectedresult] -f file [-k key]\n" + "Hash a file, ignoring whitespace:\n" + "\t%s [-S expectedresult] -F file [-k key]\n" + "Additional bits to add in: [-B bitcount -b bits]\n" + "-h\thash to test: " + "0|SHA1, 1|SHA224, 2|SHA256, 3|SHA384, 4|SHA512\n" + "-m\tperform hmac test\n" + "-k\tkey for hmac test\n" + "-t\ttest case to run, 1-10\n" + "-l\thow many times to run the test\n" + "-e\ttest error returns\n" + "-p\tdo not print results\n" + "-P\tdo not print PASSED/FAILED\n" + "-X\tprint FAILED, but not PASSED\n" + "-r\tseed for random test\n" + "-R\thow many times to run random test\n" + "-s\tstring to hash\n" + "-S\texpected result of hashed string, in hex\n" + "-w\toutput hash in raw format\n" + "-x\toutput hash in hex format\n" + "-B\t# extra bits to add in after string or file input\n" + "-b\textra bits to add (high order bits of #, 0# or 0x#)\n" + "-H\tinput hashstr or randomseed is in hex\n" + , argv0, argv0, argv0, argv0); + exit(1); +} + +/* + * Print the results and PASS/FAIL. + */ +void printResult(uint8_t *Message_Digest, int hashsize, + const char *hashname, const char *testtype, const char *testname, + const char *resultarray, int printResults, int printPassFail) +{ + int i, k; + if (printResults == PRINTTEXT) { + putchar('\t'); + for (i = 0; i < hashsize ; ++i) { + putchar(hexdigits[(Message_Digest[i] >> 4) & 0xF]); + putchar(hexdigits[Message_Digest[i] & 0xF]); + putchar(' '); + } + putchar('\n'); + } else if (printResults == PRINTRAW) { + fwrite(Message_Digest, 1, hashsize, stdout); + } else if (printResults == PRINTHEX) { + for (i = 0; i < hashsize ; ++i) { + + + +Eastlake 3rd & Hansen Informational [Page 92] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + putchar(hexdigits[(Message_Digest[i] >> 4) & 0xF]); + putchar(hexdigits[Message_Digest[i] & 0xF]); + } + putchar('\n'); + } + + if (printResults && resultarray) { + printf(" Should match:\n\t"); + for (i = 0, k = 0; i < hashsize; i++, k += 2) { + putchar(resultarray[k]); + putchar(resultarray[k+1]); + putchar(' '); + } + putchar('\n'); + } + + if (printPassFail && resultarray) { + int ret = checkmatch(Message_Digest, resultarray, hashsize); + if ((printPassFail == PRINTPASSFAIL) || !ret) + printf("%s %s %s: %s\n", hashname, testtype, testname, + ret ? "PASSED" : "FAILED"); + } +} + +/* + * Exercise a hash series of functions. The input is the testarray, + * repeated repeatcount times, followed by the extrabits. If the + * result is known, it is in resultarray in uppercase hex. + */ +int hash(int testno, int loopno, int hashno, + const char *testarray, int length, long repeatcount, + int numberExtrabits, int extrabits, const unsigned char *keyarray, + int keylen, const char *resultarray, int hashsize, int printResults, + int printPassFail) +{ + USHAContext sha; + HMACContext hmac; + int err, i; + uint8_t Message_Digest[USHAMaxHashSize]; + char buf[20]; + + if (printResults == PRINTTEXT) { + printf("\nTest %d: Iteration %d, Repeat %ld\n\t'", testno+1, + loopno, repeatcount); + printstr(testarray, length); + printf("'\n\t'"); + printxstr(testarray, length); + printf("'\n"); + + + +Eastlake 3rd & Hansen Informational [Page 93] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + printf(" Length=%d bytes (%d bits), ", length, length * 8); + printf("ExtraBits %d: %2.2x\n", numberExtrabits, extrabits); + } + + memset(&sha, '\343', sizeof(sha)); /* force bad data into struct */ + memset(&hmac, '\343', sizeof(hmac)); + err = keyarray ? hmacReset(&hmac, hashes[hashno].whichSha, + keyarray, keylen) : + USHAReset(&sha, hashes[hashno].whichSha); + if (err != shaSuccess) { + fprintf(stderr, "hash(): %sReset Error %d.\n", + keyarray ? "hmac" : "sha", err); + return err; + } + + for (i = 0; i < repeatcount; ++i) { + err = keyarray ? hmacInput(&hmac, (const uint8_t *) testarray, + length) : + USHAInput(&sha, (const uint8_t *) testarray, + length); + if (err != shaSuccess) { + fprintf(stderr, "hash(): %sInput Error %d.\n", + keyarray ? "hmac" : "sha", err); + return err; + } + } + + if (numberExtrabits > 0) { + err = keyarray ? hmacFinalBits(&hmac, (uint8_t) extrabits, + numberExtrabits) : + USHAFinalBits(&sha, (uint8_t) extrabits, + numberExtrabits); + if (err != shaSuccess) { + fprintf(stderr, "hash(): %sFinalBits Error %d.\n", + keyarray ? "hmac" : "sha", err); + return err; + } + } + + err = keyarray ? hmacResult(&hmac, Message_Digest) : + USHAResult(&sha, Message_Digest); + if (err != shaSuccess) { + fprintf(stderr, "hash(): %s Result Error %d, could not " + "compute message digest.\n", keyarray ? "hmac" : "sha", err); + return err; + } + + sprintf(buf, "%d", testno+1); + + + +Eastlake 3rd & Hansen Informational [Page 94] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + printResult(Message_Digest, hashsize, hashes[hashno].name, + keyarray ? "hmac standard test" : "sha standard test", buf, + resultarray, printResults, printPassFail); + + return err; +} + +/* + * Exercise a hash series of functions. The input is a filename. + * If the result is known, it is in resultarray in uppercase hex. + */ +int hashfile(int hashno, const char *hashfilename, int bits, + int bitcount, int skipSpaces, const unsigned char *keyarray, + int keylen, const char *resultarray, int hashsize, + int printResults, int printPassFail) +{ + USHAContext sha; + HMACContext hmac; + int err, nread, c; + unsigned char buf[4096]; + uint8_t Message_Digest[USHAMaxHashSize]; + unsigned char cc; + FILE *hashfp = (strcmp(hashfilename, "-") == 0) ? stdin : + fopen(hashfilename, "r"); + + if (!hashfp) { + fprintf(stderr, "cannot open file '%s'\n", hashfilename); + return shaStateError; + } + + memset(&sha, '\343', sizeof(sha)); /* force bad data into struct */ + memset(&hmac, '\343', sizeof(hmac)); + err = keyarray ? hmacReset(&hmac, hashes[hashno].whichSha, + keyarray, keylen) : + USHAReset(&sha, hashes[hashno].whichSha); + + if (err != shaSuccess) { + fprintf(stderr, "hashfile(): %sReset Error %d.\n", + keyarray ? "hmac" : "sha", err); + return err; + } + + if (skipSpaces) + while ((c = getc(hashfp)) != EOF) { + if (!isspace(c)) { + cc = (unsigned char)c; + err = keyarray ? hmacInput(&hmac, &cc, 1) : + USHAInput(&sha, &cc, 1); + + + +Eastlake 3rd & Hansen Informational [Page 95] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + if (err != shaSuccess) { + fprintf(stderr, "hashfile(): %sInput Error %d.\n", + keyarray ? "hmac" : "sha", err); + if (hashfp != stdin) fclose(hashfp); + return err; + } + } + } + else + while ((nread = fread(buf, 1, sizeof(buf), hashfp)) > 0) { + err = keyarray ? hmacInput(&hmac, buf, nread) : + USHAInput(&sha, buf, nread); + if (err != shaSuccess) { + fprintf(stderr, "hashfile(): %s Error %d.\n", + keyarray ? "hmacInput" : "shaInput", err); + if (hashfp != stdin) fclose(hashfp); + return err; + } + } + + if (bitcount > 0) + err = keyarray ? hmacFinalBits(&hmac, bits, bitcount) : + USHAFinalBits(&sha, bits, bitcount); + if (err != shaSuccess) { + fprintf(stderr, "hashfile(): %s Error %d.\n", + keyarray ? "hmacResult" : "shaResult", err); + if (hashfp != stdin) fclose(hashfp); + return err; + } + + err = keyarray ? hmacResult(&hmac, Message_Digest) : + USHAResult(&sha, Message_Digest); + if (err != shaSuccess) { + fprintf(stderr, "hashfile(): %s Error %d.\n", + keyarray ? "hmacResult" : "shaResult", err); + if (hashfp != stdin) fclose(hashfp); + return err; + } + + printResult(Message_Digest, hashsize, hashes[hashno].name, "file", + hashfilename, resultarray, printResults, printPassFail); + + if (hashfp != stdin) fclose(hashfp); + return err; +} + +/* + * Exercise a hash series of functions through multiple permutations. + + + +Eastlake 3rd & Hansen Informational [Page 96] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * The input is an initial seed. That seed is replicated 3 times. + * For 1000 rounds, the previous three results are used as the input. + * This result is then checked, and used to seed the next cycle. + * If the result is known, it is in resultarrays in uppercase hex. + */ +void randomtest(int hashno, const char *seed, int hashsize, + const char **resultarrays, int randomcount, + int printResults, int printPassFail) +{ + int i, j; char buf[20]; + unsigned char SEED[USHAMaxHashSize], MD[1003][USHAMaxHashSize]; + + /* INPUT: Seed - A random seed n bits long */ + memcpy(SEED, seed, hashsize); + if (printResults == PRINTTEXT) { + printf("%s random test seed= '", hashes[hashno].name); + printxstr(seed, hashsize); + printf("'\n"); + } + + for (j = 0; j < randomcount; j++) { + /* MD0 = MD1 = MD2 = Seed; */ + memcpy(MD[0], SEED, hashsize); + memcpy(MD[1], SEED, hashsize); + memcpy(MD[2], SEED, hashsize); + for (i=3; i<1003; i++) { + /* Mi = MDi-3 || MDi-2 || MDi-1; */ + USHAContext Mi; + memset(&Mi, '\343', sizeof(Mi)); /* force bad data into struct */ + USHAReset(&Mi, hashes[hashno].whichSha); + USHAInput(&Mi, MD[i-3], hashsize); + USHAInput(&Mi, MD[i-2], hashsize); + USHAInput(&Mi, MD[i-1], hashsize); + /* MDi = SHA(Mi); */ + USHAResult(&Mi, MD[i]); + } + + /* MDj = Seed = MDi; */ + memcpy(SEED, MD[i-1], hashsize); + + /* OUTPUT: MDj */ + sprintf(buf, "%d", j); + printResult(SEED, hashsize, hashes[hashno].name, "random test", + buf, resultarrays ? resultarrays[j] : 0, printResults, + (j < RANDOMCOUNT) ? printPassFail : 0); + } +} + + + + +Eastlake 3rd & Hansen Informational [Page 97] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +/* + * Look up a hash name. + */ +int findhash(const char *argv0, const char *opt) +{ + int i; + const char *names[HASHCOUNT][2] = { + { "0", "sha1" }, { "1", "sha224" }, { "2", "sha256" }, + { "3", "sha384" }, { "4", "sha512" } + }; + + for (i = 0; i < HASHCOUNT; i++) + if ((strcmp(opt, names[i][0]) == 0) || + (scasecmp(opt, names[i][1]) == 0)) + return i; + + fprintf(stderr, "%s: Unknown hash name: '%s'\n", argv0, opt); + usage(argv0); + return 0; +} + +/* + * Run some tests that should invoke errors. + */ +void testErrors(int hashnolow, int hashnohigh, int printResults, + int printPassFail) +{ + USHAContext usha; + uint8_t Message_Digest[USHAMaxHashSize]; + int hashno, err; + + for (hashno = hashnolow; hashno <= hashnohigh; hashno++) { + memset(&usha, '\343', sizeof(usha)); /* force bad data */ + USHAReset(&usha, hashno); + USHAResult(&usha, Message_Digest); + err = USHAInput(&usha, (const unsigned char *)"foo", 3); + if (printResults == PRINTTEXT) + printf ("\nError %d. Should be %d.\n", err, shaStateError); + if ((printPassFail == PRINTPASSFAIL) || + ((printPassFail == PRINTFAIL) && (err != shaStateError))) + printf("%s se: %s\n", hashes[hashno].name, + (err == shaStateError) ? "PASSED" : "FAILED"); + + err = USHAFinalBits(&usha, 0x80, 3); + if (printResults == PRINTTEXT) + printf ("\nError %d. Should be %d.\n", err, shaStateError); + if ((printPassFail == PRINTPASSFAIL) || + ((printPassFail == PRINTFAIL) && (err != shaStateError))) + + + +Eastlake 3rd & Hansen Informational [Page 98] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + printf("%s se: %s\n", hashes[hashno].name, + (err == shaStateError) ? "PASSED" : "FAILED"); + + err = USHAReset(0, hashes[hashno].whichSha); + if (printResults == PRINTTEXT) + printf("\nError %d. Should be %d.\n", err, shaNull); + if ((printPassFail == PRINTPASSFAIL) || + ((printPassFail == PRINTFAIL) && (err != shaNull))) + printf("%s usha null: %s\n", hashes[hashno].name, + (err == shaNull) ? "PASSED" : "FAILED"); + + switch (hashno) { + case SHA1: err = SHA1Reset(0); break; + case SHA224: err = SHA224Reset(0); break; + case SHA256: err = SHA256Reset(0); break; + case SHA384: err = SHA384Reset(0); break; + case SHA512: err = SHA512Reset(0); break; + } + if (printResults == PRINTTEXT) + printf("\nError %d. Should be %d.\n", err, shaNull); + if ((printPassFail == PRINTPASSFAIL) || + ((printPassFail == PRINTFAIL) && (err != shaNull))) + printf("%s sha null: %s\n", hashes[hashno].name, + (err == shaNull) ? "PASSED" : "FAILED"); + } +} + +/* replace a hex string in place with its value */ +int unhexStr(char *hexstr) +{ + char *o = hexstr; + int len = 0, nibble1 = 0, nibble2 = 0; + if (!hexstr) return 0; + for ( ; *hexstr; hexstr++) { + if (isalpha((int)(unsigned char)(*hexstr))) { + nibble1 = tolower(*hexstr) - 'a' + 10; + } else if (isdigit((int)(unsigned char)(*hexstr))) { + nibble1 = *hexstr - '0'; + } else { + printf("\nError: bad hex character '%c'\n", *hexstr); + } + if (!*++hexstr) break; + if (isalpha((int)(unsigned char)(*hexstr))) { + nibble2 = tolower(*hexstr) - 'a' + 10; + } else if (isdigit((int)(unsigned char)(*hexstr))) { + nibble2 = *hexstr - '0'; + } else { + printf("\nError: bad hex character '%c'\n", *hexstr); + + + +Eastlake 3rd & Hansen Informational [Page 99] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + } + *o++ = (char)((nibble1 << 4) | nibble2); + len++; + } + return len; +} + +int main(int argc, char **argv) +{ + int i, err; + int loopno, loopnohigh = 1; + int hashno, hashnolow = 0, hashnohigh = HASHCOUNT - 1; + int testno, testnolow = 0, testnohigh; + int ntestnohigh = 0; + int printResults = PRINTTEXT; + int printPassFail = 1; + int checkErrors = 0; + char *hashstr = 0; + int hashlen = 0; + const char *resultstr = 0; + char *randomseedstr = 0; + int runHmacTests = 0; + char *hmacKey = 0; + int hmaclen = 0; + int randomcount = RANDOMCOUNT; + const char *hashfilename = 0; + const char *hashFilename = 0; + int extrabits = 0, numberExtrabits = 0; + int strIsHex = 0; + + while ((i = xgetopt(argc, argv, "b:B:ef:F:h:Hk:l:mpPr:R:s:S:t:wxX")) + != -1) + switch (i) { + case 'b': extrabits = strtol(xoptarg, 0, 0); break; + case 'B': numberExtrabits = atoi(xoptarg); break; + case 'e': checkErrors = 1; break; + case 'f': hashfilename = xoptarg; break; + case 'F': hashFilename = xoptarg; break; + case 'h': hashnolow = hashnohigh = findhash(argv[0], xoptarg); + break; + case 'H': strIsHex = 1; break; + case 'k': hmacKey = xoptarg; hmaclen = strlen(xoptarg); break; + case 'l': loopnohigh = atoi(xoptarg); break; + case 'm': runHmacTests = 1; break; + case 'P': printPassFail = 0; break; + case 'p': printResults = PRINTNONE; break; + case 'R': randomcount = atoi(xoptarg); break; + case 'r': randomseedstr = xoptarg; break; + + + +Eastlake 3rd & Hansen Informational [Page 100] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + case 's': hashstr = xoptarg; hashlen = strlen(hashstr); break; + case 'S': resultstr = xoptarg; break; + case 't': testnolow = ntestnohigh = atoi(xoptarg) - 1; break; + case 'w': printResults = PRINTRAW; break; + case 'x': printResults = PRINTHEX; break; + case 'X': printPassFail = 2; break; + default: usage(argv[0]); + } + + if (strIsHex) { + hashlen = unhexStr(hashstr); + unhexStr(randomseedstr); + hmaclen = unhexStr(hmacKey); + } + testnohigh = (ntestnohigh != 0) ? ntestnohigh: + runHmacTests ? (HMACTESTCOUNT-1) : (TESTCOUNT-1); + if ((testnolow < 0) || + (testnohigh >= (runHmacTests ? HMACTESTCOUNT : TESTCOUNT)) || + (hashnolow < 0) || (hashnohigh >= HASHCOUNT) || + (hashstr && (testnolow == testnohigh)) || + (randomcount < 0) || + (resultstr && (!hashstr && !hashfilename && !hashFilename)) || + ((runHmacTests || hmacKey) && randomseedstr) || + (hashfilename && hashFilename)) + usage(argv[0]); + + /* + * Perform SHA/HMAC tests + */ + for (hashno = hashnolow; hashno <= hashnohigh; ++hashno) { + if (printResults == PRINTTEXT) + printf("Hash %s\n", hashes[hashno].name); + err = shaSuccess; + + for (loopno = 1; (loopno <= loopnohigh) && (err == shaSuccess); + ++loopno) { + if (hashstr) + err = hash(0, loopno, hashno, hashstr, hashlen, 1, + numberExtrabits, extrabits, (const unsigned char *)hmacKey, + hmaclen, resultstr, hashes[hashno].hashsize, printResults, + printPassFail); + + else if (randomseedstr) + randomtest(hashno, randomseedstr, hashes[hashno].hashsize, 0, + randomcount, printResults, printPassFail); + + else if (hashfilename) + err = hashfile(hashno, hashfilename, extrabits, + + + +Eastlake 3rd & Hansen Informational [Page 101] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + numberExtrabits, 0, + (const unsigned char *)hmacKey, hmaclen, + resultstr, hashes[hashno].hashsize, + printResults, printPassFail); + + else if (hashFilename) + err = hashfile(hashno, hashFilename, extrabits, + numberExtrabits, 1, + (const unsigned char *)hmacKey, hmaclen, + resultstr, hashes[hashno].hashsize, + printResults, printPassFail); + + else /* standard tests */ { + for (testno = testnolow; + (testno <= testnohigh) && (err == shaSuccess); ++testno) { + if (runHmacTests) { + err = hash(testno, loopno, hashno, + hmachashes[testno].dataarray[hashno] ? + hmachashes[testno].dataarray[hashno] : + hmachashes[testno].dataarray[1] ? + hmachashes[testno].dataarray[1] : + hmachashes[testno].dataarray[0], + hmachashes[testno].datalength[hashno] ? + hmachashes[testno].datalength[hashno] : + hmachashes[testno].datalength[1] ? + hmachashes[testno].datalength[1] : + hmachashes[testno].datalength[0], + 1, 0, 0, + (const unsigned char *)( + hmachashes[testno].keyarray[hashno] ? + hmachashes[testno].keyarray[hashno] : + hmachashes[testno].keyarray[1] ? + hmachashes[testno].keyarray[1] : + hmachashes[testno].keyarray[0]), + hmachashes[testno].keylength[hashno] ? + hmachashes[testno].keylength[hashno] : + hmachashes[testno].keylength[1] ? + hmachashes[testno].keylength[1] : + hmachashes[testno].keylength[0], + hmachashes[testno].resultarray[hashno], + hmachashes[testno].resultlength[hashno], + printResults, printPassFail); + } else { + err = hash(testno, loopno, hashno, + hashes[hashno].tests[testno].testarray, + hashes[hashno].tests[testno].length, + hashes[hashno].tests[testno].repeatcount, + hashes[hashno].tests[testno].numberExtrabits, + + + +Eastlake 3rd & Hansen Informational [Page 102] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + hashes[hashno].tests[testno].extrabits, 0, 0, + hashes[hashno].tests[testno].resultarray, + hashes[hashno].hashsize, + printResults, printPassFail); + } + } + + if (!runHmacTests) { + randomtest(hashno, hashes[hashno].randomtest, + hashes[hashno].hashsize, hashes[hashno].randomresults, + RANDOMCOUNT, printResults, printPassFail); + } + } + } + } + + /* Test some error returns */ + if (checkErrors) { + testErrors(hashnolow, hashnohigh, printResults, printPassFail); + } + + return 0; +} + +/* + * Compare two strings, case independently. + * Equivalent to strcasecmp() found on some systems. + */ +int scasecmp(const char *s1, const char *s2) +{ + for (;;) { + char u1 = tolower(*s1++); + char u2 = tolower(*s2++); + if (u1 != u2) + return u1 - u2; + if (u1 == '\0') + return 0; + } +} + +/* + * This is a copy of getopt provided for those systems that do not + * have it. The name was changed to xgetopt to not conflict on those + * systems that do have it. Similarly, optarg, optind and opterr + * were renamed to xoptarg, xoptind and xopterr. + * + * Copyright 1990, 1991, 1992 by the Massachusetts Institute of + * Technology and UniSoft Group Limited. + + + +Eastlake 3rd & Hansen Informational [Page 103] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + * + * Permission to use, copy, modify, distribute, and sell this software + * and its documentation for any purpose is hereby granted without fee, + * provided that the above copyright notice appear in all copies and + * that both that copyright notice and this permission notice appear in + * supporting documentation, and that the names of MIT and UniSoft not + * be used in advertising or publicity pertaining to distribution of + * the software without specific, written prior permission. MIT and + * UniSoft make no representations about the suitability of this + * software for any purpose. It is provided "as is" without express + * or implied warranty. + * + * $XConsortium: getopt.c,v 1.2 92/07/01 11:59:04 rws Exp $ + * NB: Reformatted to match above style. + */ + +char *xoptarg; +int xoptind = 1; +int xopterr = 1; + +static int xgetopt(int argc, char **argv, const char *optstring) +{ + static int avplace; + char *ap; + char *cp; + int c; + + if (xoptind >= argc) + return EOF; + + ap = argv[xoptind] + avplace; + + /* At beginning of arg but not an option */ + if (avplace == 0) { + if (ap[0] != '-') + return EOF; + else if (ap[1] == '-') { + /* Special end of options option */ + xoptind++; + return EOF; + } else if (ap[1] == '\0') + return EOF; /* single '-' is not allowed */ + } + + /* Get next letter */ + avplace++; + c = *++ap; + + + + +Eastlake 3rd & Hansen Informational [Page 104] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + + cp = strchr(optstring, c); + if (cp == NULL || c == ':') { + if (xopterr) + fprintf(stderr, "Unrecognised option -- %c\n", c); + return '?'; + } + + if (cp[1] == ':') { + /* There should be an option arg */ + avplace = 0; + if (ap[1] == '\0') { + /* It is a separate arg */ + if (++xoptind >= argc) { + if (xopterr) + fprintf(stderr, "Option requires an argument\n"); + return '?'; + } + xoptarg = argv[xoptind++]; + } else { + /* is attached to option letter */ + xoptarg = ap + 1; + ++xoptind; + } + } else { + /* If we are out of letters then go to next arg */ + if (ap[1] == '\0') { + ++xoptind; + avplace = 0; + } + + xoptarg = NULL; + } + return c; +} + + + + + + + + + + + + + + + + + +Eastlake 3rd & Hansen Informational [Page 105] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +9. Security Considerations + + This document is intended to provides the Internet community + convenient access to source code that implements the United States of + America Federal Information Processing Standard Secure Hash + Algorithms (SHAs) [FIPS180-2] and HMACs based upon these one-way hash + functions. See license in Section 1.1. No independent assertion of + the security of this hash function by the authors for any particular + use is intended. + +10. Normative References + + [FIPS180-2] "Secure Hash Standard", United States of America, + National Institute of Standards and Technology, Federal + Information Processing Standard (FIPS) 180-2, + http://csrc.nist.gov/publications/fips/fips180-2/ + fips180-2withchangenotice.pdf. + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, February + 1997. + +11. Informative References + + [RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and + HMAC-SHA-1", RFC 2202, September 1997. + + [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm + 1 (SHA1)", RFC 3174, September 2001. + + [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", + RFC 3874, September 2004. + + [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC + 4086, June 2005. + + [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- + 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC + 4231, December 2005. + + [SHAVS] "The Secure Hash Algorithm Validation System (SHAVS)", + http://csrc.nist.gov/cryptval/shs/SHAVS.pdf. + + + + + + + + +Eastlake 3rd & Hansen Informational [Page 106] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +Authors' Addresses + + Donald E. Eastlake, 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Phone: +1-508-786-7554 (w) + EMail: donald.eastlake@motorola.com + + + Tony Hansen + AT&T Laboratories + 200 Laurel Ave. + Middletown, NJ 07748 USA + + Phone: +1-732-420-8934 (w) + EMail: tony+shs@maillennium.att.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake 3rd & Hansen Informational [Page 107] + +RFC 4634 SHAs and HMAC-SHAs July 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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 provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Eastlake 3rd & Hansen Informational [Page 108] + diff --git a/doc/rfc/rfc4641.txt b/doc/rfc/rfc4641.txt new file mode 100644 index 0000000..0a013bc --- /dev/null +++ b/doc/rfc/rfc4641.txt @@ -0,0 +1,1963 @@ + + + + + + +Network Working Group O. Kolkman +Request for Comments: 4641 R. Gieben +Obsoletes: 2541 NLnet Labs +Category: Informational September 2006 + + + DNSSEC Operational Practices + +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 (2006). + +Abstract + + This document describes a set of practices for operating the DNS with + security extensions (DNSSEC). The target audience is zone + administrators deploying DNSSEC. + + The document discusses operational aspects of using keys and + signatures in the DNS. It discusses issues of key generation, key + storage, signature generation, key rollover, and related policies. + + This document obsoletes RFC 2541, as it covers more operational + ground and gives more up-to-date requirements with respect to key + sizes and the new DNSSEC specification. + + + + + + + + + + + + + + + + + + + + +Kolkman & Gieben Informational [Page 1] + +RFC 4641 DNSSEC Operational Practices September 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. The Use of the Term 'key' ..................................4 + 1.2. Time Definitions ...........................................4 + 2. Keeping the Chain of Trust Intact ...............................5 + 3. Keys Generation and Storage .....................................6 + 3.1. Zone and Key Signing Keys ..................................6 + 3.1.1. Motivations for the KSK and ZSK Separation ..........6 + 3.1.2. KSKs for High-Level Zones ...........................7 + 3.2. Key Generation .............................................8 + 3.3. Key Effectivity Period .....................................8 + 3.4. Key Algorithm ..............................................9 + 3.5. Key Sizes ..................................................9 + 3.6. Private Key Storage .......................................11 + 4. Signature Generation, Key Rollover, and Related Policies .......12 + 4.1. Time in DNSSEC ............................................12 + 4.1.1. Time Considerations ................................12 + 4.2. Key Rollovers .............................................14 + 4.2.1. Zone Signing Key Rollovers .........................14 + 4.2.1.1. Pre-Publish Key Rollover ..................15 + 4.2.1.2. Double Signature Zone Signing Key + Rollover ..................................17 + 4.2.1.3. Pros and Cons of the Schemes ..............18 + 4.2.2. Key Signing Key Rollovers ..........................18 + 4.2.3. Difference Between ZSK and KSK Rollovers ...........20 + 4.2.4. Automated Key Rollovers ............................21 + 4.3. Planning for Emergency Key Rollover .......................21 + 4.3.1. KSK Compromise .....................................22 + 4.3.1.1. Keeping the Chain of Trust Intact .........22 + 4.3.1.2. Breaking the Chain of Trust ...............23 + 4.3.2. ZSK Compromise .....................................23 + 4.3.3. Compromises of Keys Anchored in Resolvers ..........24 + 4.4. Parental Policies .........................................24 + 4.4.1. Initial Key Exchanges and Parental Policies + Considerations .....................................24 + 4.4.2. Storing Keys or Hashes? ............................25 + 4.4.3. Security Lameness ..................................25 + 4.4.4. DS Signature Validity Period .......................26 + 5. Security Considerations ........................................26 + 6. Acknowledgments ................................................26 + 7. References .....................................................27 + 7.1. Normative References ......................................27 + 7.2. Informative References ....................................28 + Appendix A. Terminology ...........................................30 + Appendix B. Zone Signing Key Rollover How-To ......................31 + Appendix C. Typographic Conventions ...............................32 + + + + +Kolkman & Gieben Informational [Page 2] + +RFC 4641 DNSSEC Operational Practices September 2006 + + +1. Introduction + + This document describes how to run a DNS Security (DNSSEC)-enabled + environment. It is intended for operators who have knowledge of the + DNS (see RFC 1034 [1] and RFC 1035 [2]) and want to deploy DNSSEC. + See RFC 4033 [4] for an introduction to DNSSEC, RFC 4034 [5] for the + newly introduced Resource Records (RRs), and RFC 4035 [6] for the + protocol changes. + + During workshops and early operational deployment tests, operators + and system administrators have gained experience about operating the + DNS with security extensions (DNSSEC). This document translates + these experiences into a set of practices for zone administrators. + At the time of writing, there exists very little experience with + DNSSEC in production environments; this document should therefore + explicitly not be seen as representing 'Best Current Practices'. + + The procedures herein are focused on the maintenance of signed zones + (i.e., signing and publishing zones on authoritative servers). It is + intended that maintenance of zones such as re-signing or key + rollovers be transparent to any verifying clients on the Internet. + + The structure of this document is as follows. In Section 2, we + discuss the importance of keeping the "chain of trust" intact. + Aspects of key generation and storage of private keys are discussed + in Section 3; the focus in this section is mainly on the private part + of the key(s). Section 4 describes considerations concerning the + public part of the keys. Since these public keys appear in the DNS + one has to take into account all kinds of timing issues, which are + discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the + rollover, or supercession, of keys. Finally, Section 4.4 discusses + considerations on how parents deal with their children's public keys + in order to maintain chains of trust. + + The typographic conventions used in this document are explained in + Appendix C. + + Since this is a document with operational suggestions and there are + no protocol specifications, the RFC 2119 [7] language does not apply. + + This document obsoletes RFC 2541 [12] to reflect the evolution of the + underlying DNSSEC protocol since then. Changes in the choice of + cryptographic algorithms, DNS record types and type names, and the + parent-child key and signature exchange demanded a major rewrite and + additional information and explanation. + + + + + + +Kolkman & Gieben Informational [Page 3] + +RFC 4641 DNSSEC Operational Practices September 2006 + + +1.1. The Use of the Term 'key' + + It is assumed that the reader is familiar with the concept of + asymmetric keys on which DNSSEC is based (public key cryptography + [17]). Therefore, this document will use the term 'key' rather + loosely. Where it is written that 'a key is used to sign data' it is + assumed that the reader understands that it is the private part of + the key pair that is used for signing. It is also assumed that the + reader understands that the public part of the key pair is published + in the DNSKEY Resource Record and that it is the public part that is + used in key exchanges. + +1.2. Time Definitions + + In this document, we will be using a number of time-related terms. + The following definitions apply: + + o "Signature validity period" The period that a signature is valid. + It starts at the time specified in the signature inception field + of the RRSIG RR and ends at the time specified in the expiration + field of the RRSIG RR. + + o "Signature publication period" Time after which a signature (made + with a specific key) is replaced with a new signature (made with + the same key). This replacement takes place by publishing the + relevant RRSIG in the master zone file. After one stops + publishing an RRSIG in a zone, it may take a while before the + RRSIG has expired from caches and has actually been removed from + the DNS. + + o "Key effectivity period" The period during which a key pair is + expected to be effective. This period is defined as the time + between the first inception time stamp and the last expiration + date of any signature made with this key, regardless of any + discontinuity in the use of the key. The key effectivity period + can span multiple signature validity periods. + + o "Maximum/Minimum Zone Time to Live (TTL)" The maximum or minimum + value of the TTLs from the complete set of RRs in a zone. Note + that the minimum TTL is not the same as the MINIMUM field in the + SOA RR. See [11] for more information. + + + + + + + + + + +Kolkman & Gieben Informational [Page 4] + +RFC 4641 DNSSEC Operational Practices September 2006 + + +2. Keeping the Chain of Trust Intact + + Maintaining a valid chain of trust is important because broken chains + of trust will result in data being marked as Bogus (as defined in [4] + Section 5), which may cause entire (sub)domains to become invisible + to verifying clients. The administrators of secured zones have to + realize that their zone is, to verifying clients, part of a chain of + trust. + + As mentioned in the introduction, the procedures herein are intended + to ensure that maintenance of zones, such as re-signing or key + rollovers, will be transparent to the verifying clients on the + Internet. + + Administrators of secured zones will have to keep in mind that data + published on an authoritative primary server will not be immediately + seen by verifying clients; it may take some time for the data to be + transferred to other secondary authoritative nameservers and clients + may be fetching data from caching non-authoritative servers. In this + light, note that the time for a zone transfer from master to slave is + negligible when using NOTIFY [9] and incremental transfer (IXFR) [8]. + It increases when full zone transfers (AXFR) are used in combination + with NOTIFY. It increases even more if you rely on full zone + transfers based on only the SOA timing parameters for refresh. + + For the verifying clients, it is important that data from secured + zones can be used to build chains of trust regardless of whether the + data came directly from an authoritative server, a caching + nameserver, or some middle box. Only by carefully using the + available timing parameters can a zone administrator ensure that the + data necessary for verification can be obtained. + + The responsibility for maintaining the chain of trust is shared by + administrators of secured zones in the chain of trust. This is most + obvious in the case of a 'key compromise' when a trade-off between + maintaining a valid chain of trust and replacing the compromised keys + as soon as possible must be made. Then zone administrators will have + to make a trade-off, between keeping the chain of trust intact -- + thereby allowing for attacks with the compromised key -- or + deliberately breaking the chain of trust and making secured + subdomains invisible to security-aware resolvers. Also see Section + 4.3. + + + + + + + + + +Kolkman & Gieben Informational [Page 5] + +RFC 4641 DNSSEC Operational Practices September 2006 + + +3. Keys Generation and Storage + + This section describes a number of considerations with respect to the + security of keys. It deals with the generation, effectivity period, + size, and storage of private keys. + +3.1. Zone and Key Signing Keys + + The DNSSEC validation protocol does not distinguish between different + types of DNSKEYs. All DNSKEYs can be used during the validation. In + practice, operators use Key Signing and Zone Signing Keys and use the + so-called Secure Entry Point (SEP) [3] flag to distinguish between + them during operations. The dynamics and considerations are + discussed below. + + To make zone re-signing and key rollover procedures easier to + implement, it is possible to use one or more keys as Key Signing Keys + (KSKs). These keys will only sign the apex DNSKEY RRSet in a zone. + Other keys can be used to sign all the RRSets in a zone and are + referred to as Zone Signing Keys (ZSKs). In this document, we assume + that KSKs are the subset of keys that are used for key exchanges with + the parent and potentially for configuration as trusted anchors -- + the SEP keys. In this document, we assume a one-to-one mapping + between KSK and SEP keys and we assume the SEP flag to be set on all + KSKs. + +3.1.1. Motivations for the KSK and ZSK Separation + + Differentiating between the KSK and ZSK functions has several + advantages: + + o No parent/child interaction is required when ZSKs are updated. + + o The KSK can be made stronger (i.e., using more bits in the key + material). This has little operational impact since it is only + used to sign a small fraction of the zone data. Also, the KSK is + only used to verify the zone's key set, not for other RRSets in + the zone. + + o As the KSK is only used to sign a key set, which is most probably + updated less frequently than other data in the zone, it can be + stored separately from and in a safer location than the ZSK. + + o A KSK can have a longer key effectivity period. + + For almost any method of key management and zone signing, the KSK is + used less frequently than the ZSK. Once a key set is signed with the + KSK, all the keys in the key set can be used as ZSKs. If a ZSK is + + + +Kolkman & Gieben Informational [Page 6] + +RFC 4641 DNSSEC Operational Practices September 2006 + + + compromised, it can be simply dropped from the key set. The new key + set is then re-signed with the KSK. + + Given the assumption that for KSKs the SEP flag is set, the KSK can + be distinguished from a ZSK by examining the flag field in the DNSKEY + RR. If the flag field is an odd number it is a KSK. If it is an + even number it is a ZSK. + + The Zone Signing Key can be used to sign all the data in a zone on a + regular basis. When a Zone Signing Key is to be rolled, no + interaction with the parent is needed. This allows for signature + validity periods on the order of days. + + The Key Signing Key is only to be used to sign the DNSKEY RRs in a + zone. If a Key Signing Key is to be rolled over, there will be + interactions with parties other than the zone administrator. These + can include the registry of the parent zone or administrators of + verifying resolvers that have the particular key configured as secure + entry points. Hence, the key effectivity period of these keys can + and should be made much longer. Although, given a long enough key, + the key effectivity period can be on the order of years, we suggest + planning for a key effectivity on the order of a few months so that a + key rollover remains an operational routine. + +3.1.2. KSKs for High-Level Zones + + 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, + in which case this, and only this, subdomain wouldn't be affected by + the compromise of the parent zone). Therefore, extra care should be + taken with high-level zones, and strong keys should be 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 namespace 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 the trust anchors in + an enormous population of resolvers around the world will be + extremely difficult. + + + + +Kolkman & Gieben Informational [Page 7] + +RFC 4641 DNSSEC Operational Practices September 2006 + + +3.2. 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 + 4086 [14]. One should carefully assess if the random number + generator used during key generation adheres to these suggestions. + + Keys with a long effectivity period 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.3. Key Effectivity Period + + For various reasons, keys in DNSSEC need to be changed once in a + while. The longer a key is in use, the greater the probability that + it will have been compromised through carelessness, accident, + espionage, or cryptanalysis. Furthermore, when key rollovers are too + rare an event, they will not become part of the operational habit and + there is risk that nobody on-site will remember the procedure for + rollover when the need is there. + + From a purely operational perspective, a reasonable key effectivity + period for Key Signing Keys is 13 months, with the intent to replace + them after 12 months. An intended key effectivity period of a month + is reasonable for Zone Signing Keys. + + For key sizes that match these effectivity periods, see Section 3.5. + + As argued in Section 3.1.2, securely updating trust anchors will be + extremely difficult. On the other hand, the "operational habit" + argument does also apply to trust anchor reconfiguration. If a short + key effectivity period is used and the trust anchor configuration has + to be revisited on a regular basis, the odds that the configuration + tends to be forgotten is smaller. The trade-off is against a system + that is so dynamic that administrators of the validating clients will + not be able to follow the modifications. + + Key effectivity periods can be made very short, as in a few minutes. + But when replacing keys one has to take the considerations from + Section 4.1 and Section 4.2 into account. + + + + +Kolkman & Gieben Informational [Page 8] + +RFC 4641 DNSSEC Operational Practices September 2006 + + +3.4. Key Algorithm + + There are currently three different types of algorithms that can be + used in DNSSEC: RSA, DSA, and elliptic curve cryptography. The + latter is fairly new and has yet to be standardized for usage in + DNSSEC. + + RSA has been developed in an open and transparent manner. As the + patent on RSA expired in 2000, its use is now also free. + + DSA has been developed by the National Institute of Standards and + Technology (NIST). The creation of signatures takes roughly the same + time as with RSA, but is 10 to 40 times as slow for verification + [17]. + + We suggest the use of RSA/SHA-1 as the preferred algorithm for the + key. The current known attacks on RSA can be defeated by making your + key longer. As the MD5 hashing algorithm is showing cracks, we + recommend the usage of SHA-1. + + At the time of publication, it is known that the SHA-1 hash has + cryptanalysis issues. There is work in progress on addressing these + issues. We recommend the use of public key algorithms based on + hashes stronger than SHA-1 (e.g., SHA-256), as soon as these + algorithms are available in protocol specifications (see [19] and + [20]) and implementations. + +3.5. Key Sizes + + When choosing key sizes, zone administrators will need to take into + account how long a key will be used, how much data will be signed + during the key publication period (see Section 8.10 of [17]), and, + optionally, how large the key size of the parent is. As the chain of + trust really is "a chain", there is not much sense in making one of + the keys in the chain several times larger then the others. As + always, it's the weakest link that defines the strength of the entire + chain. Also see Section 3.1.1 for a discussion of how keys serving + different roles (ZSK vs. KSK) may need different key sizes. + + Generating a key of the correct size is a difficult problem; RFC 3766 + [13] tries to deal with that problem. The first part of the + selection procedure in Section 1 of the RFC states: + + 1. Determine the attack resistance necessary to satisfy the + security requirements of the application. Do this by + estimating the minimum number of computer operations that the + attacker will be forced to do in order to compromise the + + + + +Kolkman & Gieben Informational [Page 9] + +RFC 4641 DNSSEC Operational Practices September 2006 + + + security of the system and then take the logarithm base two of + that number. Call that logarithm value "n". + + A 1996 report recommended 90 bits as a good all-around choice + for system security. The 90 bit number should be increased by + about 2/3 bit/year, or about 96 bits in 2005. + + [13] goes on to explain how this number "n" can be used to calculate + the key sizes in public key cryptography. This culminated in the + table given below (slightly modified for our purpose): + + +-------------+-----------+--------------+ + | System | | | + | requirement | Symmetric | RSA or DSA | + | for attack | key size | modulus size | + | resistance | (bits) | (bits) | + | (bits) | | | + +-------------+-----------+--------------+ + | 70 | 70 | 947 | + | 80 | 80 | 1228 | + | 90 | 90 | 1553 | + | 100 | 100 | 1926 | + | 150 | 150 | 4575 | + | 200 | 200 | 8719 | + | 250 | 250 | 14596 | + +-------------+-----------+--------------+ + + The key sizes given are rather large. This is because these keys are + resilient against a trillionaire attacker. Assuming this rich + attacker will not attack your key and that the key is rolled over + once a year, we come to the following recommendations about KSK + sizes: 1024 bits for low-value domains, 1300 bits for medium-value + domains, and 2048 bits for high-value domains. + + Whether a domain is of low, medium, or high value depends solely on + the views of the zone owner. One could, for instance, view leaf + nodes in the DNS as of low value, and top-level domains (TLDs) or the + root zone of high value. The suggested key sizes should be safe for + the next 5 years. + + As ZSKs can be rolled over more easily (and thus more often), the key + sizes can be made smaller. But as said in the introduction of this + paragraph, making the ZSKs' key sizes too small (in relation to the + KSKs' sizes) doesn't make much sense. Try to limit the difference in + size to about 100 bits. + + + + + + +Kolkman & Gieben Informational [Page 10] + +RFC 4641 DNSSEC Operational Practices September 2006 + + + Note that nobody can see into the future and that these key sizes are + only provided here as a guide. Further information can be found in + [16] and Section 7.5 of [17]. It should be noted though that [16] is + already considered overly optimistic about what key sizes are + considered safe. + + One final note concerning key sizes. Larger keys will increase the + sizes of the RRSIG and DNSKEY records and will therefore increase the + chance of DNS UDP packet overflow. Also, the time it takes to + validate and create RRSIGs increases with larger keys, so don't + needlessly double your key sizes. + +3.6. Private Key Storage + + It is recommended that, where possible, zone private keys and the + zone file master copy that is to be signed 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 RRSIG and NSEC RRs. Then the augmented file can be + transferred. + + When relying on dynamic update to manage a signed zone [10], be aware + that at least one private key of the zone will have to reside on the + master server. This key is only as secure as the amount of exposure + the server receives to unknown clients and the security of the host. + Although not mandatory, one could administer the DNS in the following + way. The master that processes the dynamic updates is unavailable + from generic hosts on the Internet, it is not listed in the NS RR + set, although its name appears in the SOA RRs MNAME field. The + nameservers in the NS RRSet are able to receive zone updates through + NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism. This + approach is known as the "hidden master" setup. + + The ideal situation 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. + + In general, keeping a zone file off-line will not be practical and + the machines on which zone files are maintained will be connected to + a network. Operators are advised to take security measures to shield + unauthorized access to the master copy. + + + + + +Kolkman & Gieben Informational [Page 11] + +RFC 4641 DNSSEC Operational Practices September 2006 + + + For dynamically updated secured zones [10], both the master copy and + the private key that is used to update signatures on updated RRs will + need to be on-line. + +4. Signature Generation, Key Rollover, and Related Policies + +4.1. Time in DNSSEC + + Without DNSSEC, all times in the DNS are relative. The SOA fields + REFRESH, RETRY, and EXPIRATION are timers used to determine the time + elapsed after a slave server synchronized with a master server. The + Time to Live (TTL) value and the SOA RR minimum TTL parameter [11] + are used to determine how long a forwarder should cache data after it + has been fetched from an authoritative server. By using a signature + validity period, DNSSEC introduces the notion of an absolute time in + the DNS. Signatures in DNSSEC have an expiration date after which + the signature is marked as invalid and the signed data is to be + considered Bogus. + +4.1.1. Time Considerations + + Because of the expiration of signatures, one should consider the + following: + + o We suggest the Maximum Zone TTL of your zone data to be a fraction + of your signature validity period. + + If the TTL would be of similar order as the signature validity + period, then all RRSets fetched during the validity period + would be cached until the signature expiration time. Section + 7.1 of [4] suggests that "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". As a result, + query load on authoritative servers would peak at signature + expiration time, as this is also the time at which records + simultaneously expire from caches. + + To avoid query load peaks, we suggest the TTL on all the RRs in + your zone to be at least a few times smaller than your + signature validity period. + + o We suggest the signature publication period to end at least one + Maximum Zone TTL duration before the end of the signature validity + period. + + + + + + + +Kolkman & Gieben Informational [Page 12] + +RFC 4641 DNSSEC Operational Practices September 2006 + + + Re-signing a zone shortly before the end of the signature + validity period may cause simultaneous expiration of data from + caches. This in turn may lead to peaks in the load on + authoritative servers. + + o We suggest the Minimum Zone TTL to be long enough to both fetch + and verify all the RRs in the trust chain. In workshop + environments, it has been demonstrated [18] that a low TTL (under + 5 to 10 minutes) caused disruptions because of the following two + problems: + + 1. During validation, some data may expire before the + validation is complete. The validator should be able to + keep all data until it is completed. This applies to all + RRs needed to complete the chain of trust: DSes, DNSKEYs, + RRSIGs, and the final answers, i.e., the RRSet that is + returned for the initial query. + + 2. Frequent verification causes load on recursive nameservers. + Data at delegation points, DSes, DNSKEYs, and RRSIGs + benefit from caching. The TTL on those should be + relatively long. + + o Slave servers will need to be able to fetch newly signed zones + well before the RRSIGs in the zone served by the slave server pass + their signature expiration time. + + When a slave server is out of sync with its master and data in + a zone is signed by expired signatures, it may be better for + the slave server not to give out any answer. + + Normally, a slave server that is not able to contact a master + server for an extended period will expire a zone. When that + happens, the server will respond differently to queries for + that zone. Some servers issue SERVFAIL, whereas others turn + off the 'AA' bit in the answers. The time of expiration is set + in the SOA record and is relative to the last successful + refresh between the master and the slave servers. There exists + no coupling between the signature expiration of RRSIGs in the + zone and the expire parameter in the SOA. + + If the server serves a DNSSEC zone, then it may well happen + that the signatures expire well before the SOA expiration timer + counts down to zero. It is not possible to completely prevent + this from happening by tweaking the SOA parameters. However, + the effects can be minimized where the SOA expiration time is + equal to or shorter than the signature validity period. The + consequence of an authoritative server not being able to update + + + +Kolkman & Gieben Informational [Page 13] + +RFC 4641 DNSSEC Operational Practices September 2006 + + + a zone, whilst that zone includes expired signatures, is that + non-secure resolvers will continue to be able to resolve data + served by the particular slave servers while security-aware + resolvers will experience problems because of answers being + marked as Bogus. + + We suggest the SOA expiration timer being approximately one + third or one fourth of the signature validity period. It will + allow problems with transfers from the master server to be + noticed before the actual signature times out. We also suggest + that operators of nameservers that supply secondary services + develop 'watch dogs' to spot upcoming signature expirations in + zones they slave, and take appropriate action. + + When determining the value for the expiration parameter one has + to take the following into account: What are the chances that + all my secondaries expire the zone? How quickly can I reach an + administrator of secondary servers to load a valid zone? These + questions are not DNSSEC specific but may influence the choice + of your signature validity intervals. + +4.2. Key Rollovers + + A DNSSEC key cannot be used forever (see Section 3.3). So key + rollovers -- or supercessions, as they are sometimes called -- are a + fact of life when using DNSSEC. Zone administrators who are in the + process of rolling their keys have to take into account that data + published in previous versions of their zone still lives in caches. + When deploying DNSSEC, this becomes an important consideration; + ignoring data that may be in caches may lead to loss of service for + clients. + + The most pressing example of this occurs when zone material signed + with an old key is being validated by a resolver that does not have + the old zone key cached. If the old key is no longer present in the + current zone, this validation fails, marking the data "Bogus". + Alternatively, an attempt could be made to validate data that is + signed with a new key against an old key that lives in a local cache, + also resulting in data being marked "Bogus". + +4.2.1. Zone Signing Key Rollovers + + For "Zone Signing Key rollovers", there are two ways to make sure + that during the rollover data still cached can be verified with the + new key sets or newly generated signatures can be verified with the + keys still in caches. One schema, described in Section 4.2.1.2, uses + + + + + +Kolkman & Gieben Informational [Page 14] + +RFC 4641 DNSSEC Operational Practices September 2006 + + + double signatures; the other uses key pre-publication (Section + 4.2.1.1). The pros, cons, and recommendations are described in + Section 4.2.1.3. + +4.2.1.1. Pre-Publish Key Rollover + + This section shows how to perform a ZSK rollover without the need to + sign all the data in a zone twice -- the "pre-publish key rollover". + This method has advantages in the case of a key compromise. If the + old key is compromised, the new key has already been distributed in + the DNS. The zone administrator is then able to quickly switch to + the new key and remove the compromised key from the zone. Another + major advantage is that the zone size does not double, as is the case + with the double signature ZSK rollover. A small "how-to" for this + kind of rollover can be found in Appendix B. + + Pre-publish key rollover involves four stages as follows: + + ---------------------------------------------------------------- + initial new DNSKEY new RRSIGs DNSKEY removal + ---------------------------------------------------------------- + SOA0 SOA1 SOA2 SOA3 + RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) + + DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 + DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 + DNSKEY11 DNSKEY11 + RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) + RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) + ---------------------------------------------------------------- + + Pre-Publish Key Rollover + + initial: Initial version of the zone: DNSKEY 1 is the Key Signing + Key. DNSKEY 10 is used to sign all the data of the zone, the Zone + Signing Key. + + new DNSKEY: DNSKEY 11 is introduced into the key set. Note that no + signatures are generated with this key yet, but this does not + secure against brute force attacks on the public key. The minimum + duration of this pre-roll phase is the time it takes for the data + to propagate to the authoritative servers plus TTL value of the + key set. + + new RRSIGs: At the "new RRSIGs" stage (SOA serial 2), DNSKEY 11 is + used to sign the data in the zone exclusively (i.e., all the + signatures from DNSKEY 10 are removed from the zone). DNSKEY 10 + remains published in the key set. This way data that was loaded + + + +Kolkman & Gieben Informational [Page 15] + +RFC 4641 DNSSEC Operational Practices September 2006 + + + into caches from version 1 of the zone can still be verified with + key sets fetched from version 2 of the zone. The minimum time + that the key set including DNSKEY 10 is to be published is the + time that it takes for zone data from the previous version of the + zone to expire from old caches, i.e., the time it takes for this + zone to propagate to all authoritative servers plus the Maximum + Zone TTL value of any of the data in the previous version of the + zone. + + DNSKEY removal: DNSKEY 10 is removed from the zone. The key set, now + only containing DNSKEY 1 and DNSKEY 11, is re-signed with the + DNSKEY 1. + + The above scheme can be simplified by always publishing the "future" + key immediately after the rollover. The scheme would look as follows + (we show two rollovers); the future key is introduced in "new DNSKEY" + as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY + (II)": + + ---------------------------------------------------------------- + initial new RRSIGs new DNSKEY + ---------------------------------------------------------------- + SOA0 SOA1 SOA2 + RRSIG10(SOA0) RRSIG11(SOA1) RRSIG11(SOA2) + + DNSKEY1 DNSKEY1 DNSKEY1 + DNSKEY10 DNSKEY10 DNSKEY11 + DNSKEY11 DNSKEY11 DNSKEY12 + RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) + RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) + ---------------------------------------------------------------- + + ---------------------------------------------------------------- + new RRSIGs (II) new DNSKEY (II) + ---------------------------------------------------------------- + SOA3 SOA4 + RRSIG12(SOA3) RRSIG12(SOA4) + + DNSKEY1 DNSKEY1 + DNSKEY11 DNSKEY12 + DNSKEY12 DNSKEY13 + RRSIG1(DNSKEY) RRSIG1(DNSKEY) + RRSIG12(DNSKEY) RRSIG12(DNSKEY) + ---------------------------------------------------------------- + + Pre-Publish Key Rollover, Showing Two Rollovers + + + + + +Kolkman & Gieben Informational [Page 16] + +RFC 4641 DNSSEC Operational Practices September 2006 + + + Note that the key introduced in the "new DNSKEY" phase is not used + for production yet; the private key can thus be stored in a + physically secure manner and does not need to be 'fetched' every time + a zone needs to be signed. + +4.2.1.2. Double Signature Zone Signing Key Rollover + + This section shows how to perform a ZSK key rollover using the double + zone data signature scheme, aptly named "double signature rollover". + + During the "new DNSKEY" stage the new version of the zone file will + need to propagate to all authoritative servers and the data that + exists in (distant) caches will need to expire, requiring at least + the Maximum Zone TTL. + + Double signature ZSK rollover involves three stages as follows: + + ---------------------------------------------------------------- + initial new DNSKEY DNSKEY removal + ---------------------------------------------------------------- + SOA0 SOA1 SOA2 + RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) + RRSIG11(SOA1) + + DNSKEY1 DNSKEY1 DNSKEY1 + DNSKEY10 DNSKEY10 DNSKEY11 + DNSKEY11 + RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) + RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) + RRSIG11(DNSKEY) + ---------------------------------------------------------------- + + Double Signature Zone Signing Key Rollover + + initial: Initial Version of the zone: DNSKEY 1 is the Key Signing + Key. DNSKEY 10 is used to sign all the data of the zone, the Zone + Signing Key. + + new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is + introduced into the key set and all the data in the zone is signed + with DNSKEY 10 and DNSKEY 11. The rollover period will need to + continue until all data from version 0 of the zone has expired + from remote caches. This will take at least the Maximum Zone TTL + of version 0 of the zone. + + DNSKEY removal: DNSKEY 10 is removed from the zone. All the + signatures from DNSKEY 10 are removed from the zone. The key set, + now only containing DNSKEY 11, is re-signed with DNSKEY 1. + + + +Kolkman & Gieben Informational [Page 17] + +RFC 4641 DNSSEC Operational Practices September 2006 + + + At every instance, RRSIGs from the previous version of the zone can + be verified with the DNSKEY RRSet from the current version and the + other way around. The data from the current version can be verified + with the data from the previous version of the zone. The duration of + the "new DNSKEY" phase and the period between rollovers should be at + least the Maximum Zone TTL. + + Making sure that the "new DNSKEY" phase lasts until the signature + expiration time of the data in initial version of the zone is + recommended. This way all caches are cleared of the old signatures. + However, this duration could be considerably longer than the Maximum + Zone TTL, making the rollover a lengthy procedure. + + Note that in this example we assumed that the zone was not modified + during the rollover. New data can be introduced in the zone as long + as it is signed with both keys. + +4.2.1.3. Pros and Cons of the Schemes + + Pre-publish key rollover: This rollover does not involve signing the + zone data twice. Instead, before the actual rollover, the new key + is published in the key set and thus is available for + cryptanalysis attacks. A small disadvantage is that this process + requires four steps. Also the pre-publish scheme involves more + parental work when used for KSK rollovers as explained in Section + 4.2.3. + + Double signature ZSK rollover: The drawback of this signing scheme is + that during the rollover the number of signatures in your zone + doubles; this may be prohibitive if you have very big zones. An + advantage is that it only requires three steps. + +4.2.2. Key Signing Key Rollovers + + For the rollover of a Key Signing Key, the same considerations as for + the rollover of a Zone Signing Key apply. However, we can use a + double signature scheme to guarantee that old data (only the apex key + set) in caches can be verified with a new key set and vice versa. + Since only the key set is signed with a KSK, zone size considerations + do not apply. + + + + + + + + + + + +Kolkman & Gieben Informational [Page 18] + +RFC 4641 DNSSEC Operational Practices September 2006 + + + -------------------------------------------------------------------- + initial new DNSKEY DS change DNSKEY removal + -------------------------------------------------------------------- + Parent: + SOA0 --------> SOA1 --------> + RRSIGpar(SOA0) --------> RRSIGpar(SOA1) --------> + DS1 --------> DS2 --------> + RRSIGpar(DS) --------> RRSIGpar(DS) --------> + + + Child: + SOA0 SOA1 --------> SOA2 + RRSIG10(SOA0) RRSIG10(SOA1) --------> RRSIG10(SOA2) + --------> + DNSKEY1 DNSKEY1 --------> DNSKEY2 + DNSKEY2 --------> + DNSKEY10 DNSKEY10 --------> DNSKEY10 + RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) --------> RRSIG2 (DNSKEY) + RRSIG2 (DNSKEY) --------> + RRSIG10(DNSKEY) RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) + -------------------------------------------------------------------- + + Stages of Deployment for a Double Signature Key Signing Key Rollover + + initial: Initial version of the zone. The parental DS points to + DNSKEY1. Before the rollover starts, the child will have to + verify what the TTL is of the DS RR that points to DNSKEY1 -- it + is needed during the rollover and we refer to the value as TTL_DS. + + new DNSKEY: During the "new DNSKEY" phase, the zone administrator + generates a second KSK, DNSKEY2. The key is provided to the + parent, and the child will have to wait until a new DS RR has been + generated that points to DNSKEY2. After that DS RR has been + published on all servers authoritative for the parent's zone, the + zone administrator has to wait at least TTL_DS to make sure that + the old DS RR has expired from caches. + + DS change: The parent replaces DS1 with DS2. + + DNSKEY removal: DNSKEY1 has been removed. + + The scenario above puts the responsibility for maintaining a valid + chain of trust with the child. It also is based on the premise that + the parent only has one DS RR (per algorithm) per zone. An + alternative mechanism has been considered. Using an established + trust relation, the interaction can be performed in-band, and the + removal of the keys by the child can possibly be signaled by the + parent. In this mechanism, there are periods where there are two DS + + + +Kolkman & Gieben Informational [Page 19] + +RFC 4641 DNSSEC Operational Practices September 2006 + + + RRs at the parent. Since at the moment of writing the protocol for + this interaction has not been developed, further discussion is out of + scope for this document. + +4.2.3. Difference Between ZSK and KSK Rollovers + + Note that KSK rollovers and ZSK rollovers are different in the sense + that a KSK rollover requires interaction with the parent (and + possibly replacing of trust anchors) and the ensuing delay while + waiting for it. + + A zone key rollover can be handled in two different ways: pre-publish + (Section 4.2.1.1) and double signature (Section 4.2.1.2). + + As the KSK is used to validate the key set and because the KSK is not + changed during a ZSK rollover, a cache is able to validate the new + key set of the zone. The pre-publish method would also work for a + KSK rollover. The records that are to be pre-published are the + parental DS RRs. The pre-publish method has some drawbacks for KSKs. + We first describe the rollover scheme and then indicate these + drawbacks. + + -------------------------------------------------------------------- + initial new DS new DNSKEY DS/DNSKEY removal + -------------------------------------------------------------------- + Parent: + SOA0 SOA1 --------> SOA2 + RRSIGpar(SOA0) RRSIGpar(SOA1) --------> RRSIGpar(SOA2) + DS1 DS1 --------> DS2 + DS2 --------> + RRSIGpar(DS) RRSIGpar(DS) --------> RRSIGpar(DS) + + + Child: + SOA0 --------> SOA1 SOA1 + RRSIG10(SOA0) --------> RRSIG10(SOA1) RRSIG10(SOA1) + --------> + DNSKEY1 --------> DNSKEY2 DNSKEY2 + --------> + DNSKEY10 --------> DNSKEY10 DNSKEY10 + RRSIG1 (DNSKEY) --------> RRSIG2(DNSKEY) RRSIG2 (DNSKEY) + RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) RRSIG10(DNSKEY) + -------------------------------------------------------------------- + + Stages of Deployment for a Pre-Publish Key Signing Key Rollover + + + + + + +Kolkman & Gieben Informational [Page 20] + +RFC 4641 DNSSEC Operational Practices September 2006 + + + When the child zone wants to roll, it notifies the parent during the + "new DS" phase and submits the new key (or the corresponding DS) to + the parent. The parent publishes DS1 and DS2, pointing to DNSKEY1 + and DNSKEY2, respectively. During the rollover ("new DNSKEY" phase), + which can take place as soon as the new DS set propagated through the + DNS, the child replaces DNSKEY1 with DNSKEY2. Immediately after that + ("DS/DNSKEY removal" phase), it can notify the parent that the old DS + record can be deleted. + + The drawbacks of this scheme are that during the "new DS" phase the + parent cannot verify the match between the DS2 RR and DNSKEY2 using + the DNS -- as DNSKEY2 is not yet published. Besides, we introduce a + "security lame" key (see Section 4.4.3). Finally, the child-parent + interaction consists of two steps. The "double signature" method + only needs one interaction. + +4.2.4. Automated Key Rollovers + + As keys must be renewed periodically, there is some motivation to + automate the rollover process. Consider the following: + + o ZSK rollovers are easy to automate as only the child zone is + involved. + + o A KSK rollover needs interaction between parent and child. Data + exchange is needed to provide the new keys to the parent; + consequently, this data must be authenticated and integrity must + be guaranteed in order to avoid attacks on the rollover. + +4.3. Planning for Emergency Key Rollover + + This section deals with preparation for a possible key compromise. + Our advice is to have a documented procedure ready for when a key + compromise is suspected or confirmed. + + When the private material of one of your keys is compromised it can + be used for as long as a valid trust chain exists. A trust chain + remains intact for + + o as long as a signature over the compromised key in the trust chain + is valid, + + o as long as a parental DS RR (and signature) points to the + compromised key, + + o as long as the key is anchored in a resolver and is used as a + starting point for validation (this is generally the hardest to + update). + + + +Kolkman & Gieben Informational [Page 21] + +RFC 4641 DNSSEC Operational Practices September 2006 + + + While a trust chain to your compromised key exists, your namespace is + vulnerable to abuse by anyone who has obtained illegitimate + possession of the key. Zone operators have to make a trade-off if + the abuse of the compromised key is worse than having data in caches + that cannot be validated. If the zone operator chooses to break the + trust chain to the compromised key, data in caches signed with this + key cannot be validated. However, if the zone administrator chooses + to take the path of a regular rollover, the malicious key holder can + spoof data so that it appears to be valid. + +4.3.1. KSK Compromise + + A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable + as long as the compromised KSK is configured as trust anchor or a + parental DS points to it. + + A compromised KSK can be used to sign the key set of an attacker's + zone. That zone could be used to poison the DNS. + + Therefore, when the KSK has been compromised, the trust anchor or the + parental DS should be replaced as soon as possible. It is local + policy whether to break the trust chain during the emergency + rollover. The trust chain would be broken when the compromised KSK + is removed from the child's zone while the parent still has a DS + pointing to the compromised KSK (the assumption is that there is only + one DS at the parent. If there are multiple DSes this does not apply + -- however the chain of trust of this particular key is broken). + + Note that an attacker's zone still uses the compromised KSK and the + presence of a parental DS would cause the data in this zone to appear + as valid. Removing the compromised key would cause the attacker's + zone to appear as valid and the child's zone as Bogus. Therefore, we + advise not to remove the KSK before the parent has a DS to a new KSK + in place. + +4.3.1.1. Keeping the Chain of Trust Intact + + If we follow this advice, the timing of the replacement of the KSK is + somewhat critical. The goal is to remove the compromised KSK as soon + as the new DS RR is available at the parent. And also make sure that + the signature made with a new KSK over the key set with the + compromised KSK in it expires just after the new DS appears at the + parent, thus removing the old cruft in one swoop. + + The procedure is as follows: + + 1. Introduce a new KSK into the key set, keep the compromised KSK in + the key set. + + + +Kolkman & Gieben Informational [Page 22] + +RFC 4641 DNSSEC Operational Practices September 2006 + + + 2. Sign the key set, with a short validity period. The validity + period should expire shortly after the DS is expected to appear + in the parent and the old DSes have expired from caches. + + 3. Upload the DS for this new key to the parent. + + 4. Follow the procedure of the regular KSK rollover: Wait for the DS + to appear in the authoritative servers and then wait as long as + the TTL of the old DS RRs. If necessary re-sign the DNSKEY RRSet + and modify/extend the expiration time. + + 5. Remove the compromised DNSKEY RR from the zone and re-sign the + key set using your "normal" validity interval. + + An additional danger of a key compromise is that the compromised key + could be used to facilitate a legitimate DNSKEY/DS rollover and/or + nameserver changes at the parent. When that happens, the domain may + be in dispute. An authenticated out-of-band and secure notify + mechanism to contact a parent is needed in this case. + + Note that this is only a problem when the DNSKEY and or DS records + are used for authentication at the parent. + +4.3.1.2. Breaking the Chain of Trust + + There are two methods to break the chain of trust. The first method + causes the child zone to appear 'Bogus' to validating resolvers. The + other causes the child zone to appear 'insecure'. These are + described below. + + In the method that causes the child zone to appear 'Bogus' to + validating resolvers, the child zone replaces the current KSK with a + new one and re-signs the key set. Next it sends the DS of the new + key to the parent. Only after the parent has placed the new DS in + the zone is the child's chain of trust repaired. + + An alternative method of breaking the chain of trust is by removing + the DS RRs from the parent zone altogether. As a result, the child + zone would become insecure. + +4.3.2. ZSK Compromise + + Primarily because there is no parental interaction required when a + ZSK is compromised, the situation is less severe than with a KSK + compromise. The zone must still be re-signed with a new ZSK as soon + as possible. As this is a local operation and requires no + communication between the parent and child, this can be achieved + fairly quickly. However, one has to take into account that just as + + + +Kolkman & Gieben Informational [Page 23] + +RFC 4641 DNSSEC Operational Practices September 2006 + + + with a normal rollover the immediate disappearance of the old + compromised key may lead to verification problems. Also note that as + long as the RRSIG over the compromised ZSK is not expired the zone + may be still at risk. + +4.3.3. Compromises of Keys Anchored in Resolvers + + A key can also be pre-configured in resolvers. For instance, if + DNSSEC is successfully deployed the root key may be pre-configured in + most security aware resolvers. + + If trust-anchor keys are compromised, the resolvers using these keys + should be notified of this fact. Zone administrators may consider + setting up a mailing list to communicate the fact that a SEP key is + about to be rolled over. This communication will of course need to + be authenticated, e.g., by using digital signatures. + + End-users faced with the task of updating an anchored key should + always validate the new key. New keys should be authenticated out- + of-band, for example, through the use of an announcement website that + is secured using secure sockets (TLS) [21]. + +4.4. Parental Policies + +4.4.1. Initial Key Exchanges and Parental Policies Considerations + + The initial key exchange is always subject to the policies set by the + parent. When designing a key exchange policy one should take into + account that the authentication and authorization mechanisms used + during a key exchange should be as strong as the authentication and + authorization mechanisms used for the exchange of delegation + information between parent and child. That is, there is no implicit + need in DNSSEC to make the authentication process stronger than it + was in DNS. + + Using the DNS itself as the source for the actual DNSKEY material, + with an out-of-band check on the validity of the DNSKEY, has the + benefit that it reduces the chances of user error. A DNSKEY query + tool can make use of the SEP bit [3] to select the proper key from a + DNSSEC key set, thereby reducing the chance that the wrong DNSKEY is + sent. It can validate the self-signature over a key; thereby + verifying the ownership of the private key material. Fetching the + DNSKEY from the DNS ensures that the chain of trust remains intact + once the parent publishes the DS RR indicating the child is secure. + + Note: the out-of-band verification is still needed when the key + material is fetched via the DNS. The parent can never be sure + whether or not the DNSKEY RRs have been spoofed. + + + +Kolkman & Gieben Informational [Page 24] + +RFC 4641 DNSSEC Operational Practices September 2006 + + +4.4.2. Storing Keys or Hashes? + + When designing a registry system one should consider which of the + DNSKEYs and/or the corresponding DSes to store. Since a child zone + might wish to have a DS published using a message digest algorithm + not yet understood by the registry, the registry can't count on being + able to generate the DS record from a raw DNSKEY. Thus, we recommend + that registry systems at least support storing DS records. + + It may also be useful to store DNSKEYs, since having them may help + during troubleshooting and, as long as the child's chosen message + digest is supported, the overhead of generating DS records from them + is minimal. Having an out-of-band mechanism, such as a registry + directory (e.g., Whois), to find out which keys are used to generate + DS Resource Records for specific owners and/or zones may also help + with troubleshooting. + + The storage considerations also relate to the design of the customer + interface and the method by which data is transferred between + registrant and registry; Will the child zone administrator be able to + upload DS RRs with unknown hash algorithms or does the interface only + allow DNSKEYs? In the registry-registrar model, one can use the + DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [15], + which allows transfer of DS RRs and optionally DNSKEY RRs. + +4.4.3. Security Lameness + + Security lameness is defined as what happens when a parent has a DS + RR pointing to a non-existing DNSKEY RR. When this happens, the + child's zone may be marked "Bogus" by verifying DNS clients. + + As part of a comprehensive delegation check, the parent could, at key + exchange time, verify that the child's key is actually configured in + the DNS. However, if a parent does not understand the hashing + algorithm used by child, the parental checks are limited to only + comparing the key id. + + Child zones should be very careful in removing DNSKEY material, + specifically SEP keys, for which a DS RR exists. + + Once a zone is "security lame", a fix (e.g., removing a DS RR) will + take time to propagate through the DNS. + + + + + + + + + +Kolkman & Gieben Informational [Page 25] + +RFC 4641 DNSSEC Operational Practices September 2006 + + +4.4.4. DS Signature Validity Period + + Since the DS can be replayed as long as it has a valid signature, a + short signature validity period over the DS minimizes the time a + child is vulnerable in the case of a compromise of the child's + KSK(s). A signature validity period that is too short introduces the + possibility that a zone is marked "Bogus" in case of a configuration + error in the signer. There may not be enough time to fix the + problems before signatures expire. Something as mundane as operator + unavailability during weekends shows the need for DS signature + validity periods longer than 2 days. We recommend an absolute + minimum for a DS signature validity period of a few days. + + The maximum signature validity period of the DS record depends on how + long child zones are willing to be vulnerable after a key compromise. + On the other hand, shortening the DS signature validity interval + increases the operational risk for the parent. Therefore, the parent + may have policy to use a signature validity interval that is + considerably longer than the child would hope for. + + A compromise between the operational constraints of the parent and + minimizing damage for the child may result in a DS signature validity + period somewhere between a week and months. + + In addition to the signature validity period, which sets a lower + bound on the number of times the zone owner will need to sign the + zone data and which sets an upper bound to the time a child is + vulnerable after key compromise, there is the TTL value on the DS + RRs. Shortening the TTL means that the authoritative servers will + see more queries. But on the other hand, a short TTL lowers the + persistence of DS RRSets in caches thereby increasing the speed with + which updated DS RRSets propagate through the DNS. + +5. Security Considerations + + DNSSEC adds data integrity to the DNS. This document tries to assess + the operational considerations to maintain a stable and secure DNSSEC + service. Not taking into account the 'data propagation' properties + in the DNS will cause validation failures and may make secured zones + unavailable to security-aware resolvers. + +6. Acknowledgments + + Most of the ideas in this document were the result of collective + efforts during workshops, discussions, and tryouts. + + At the risk of forgetting individuals who were the original + contributors of the ideas, we would like to acknowledge people who + + + +Kolkman & Gieben Informational [Page 26] + +RFC 4641 DNSSEC Operational Practices September 2006 + + + were actively involved in the compilation of this document. In + random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael + Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette + Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger + Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz, and Peter Koch. + + Some material in this document has been copied from RFC 2541 [12]. + + Mike StJohns designed the key exchange between parent and child + mentioned in the last paragraph of Section 4.2.2 + + Section 4.2.4 was supplied by G. Guette and O. Courtay. + + Emma Bretherick, Adrian Bedford, and Lindy Foster corrected many of + the spelling and style issues. + + Kolkman and Gieben take the blame for introducing all miscakes (sic). + + While working on this document, Kolkman was employed by the RIPE NCC + and Gieben was employed by NLnet Labs. + +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] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System + KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) + Flag", RFC 3757, May 2004. + + [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, March + 2005. + + [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", RFC + 4035, March 2005. + + + + + +Kolkman & Gieben Informational [Page 27] + +RFC 4641 DNSSEC Operational Practices September 2006 + + +7.2. Informative References + + [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [8] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August + 1996. + + [9] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes + (DNS NOTIFY)", RFC 1996, August 1996. + + [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [11] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", + RFC 2308, March 1998. + + [12] Eastlake, D., "DNS Security Operational Considerations", RFC + 2541, March 1999. + + [13] Orman, H. and P. Hoffman, "Determining Strengths For Public + Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, + April 2004. + + [14] Eastlake, D., Schiller, J., and S. Crocker, "Randomness + Requirements for Security", BCP 106, RFC 4086, June 2005. + + [15] Hollenbeck, S., "Domain Name System (DNS) Security Extensions + Mapping for the Extensible Provisioning Protocol (EPP)", RFC + 4310, December 2005. + + [16] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key + Sizes", The Journal of Cryptology 14 (255-293), 2001. + + [17] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and + Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN + (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc., + 1996. + + [18] Rose, S., "NIST DNSSEC workshop notes", June 2001. + + [19] Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource + Records in DNSSEC", Work in Progress, January 2006. + + [20] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) + Resource Records (RRs)", RFC 4509, May 2006. + + + + + +Kolkman & Gieben Informational [Page 28] + +RFC 4641 DNSSEC Operational Practices September 2006 + + + [21] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and + T. Wright, "Transport Layer Security (TLS) Extensions", RFC + 4366, April 2006. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman & Gieben Informational [Page 29] + +RFC 4641 DNSSEC Operational Practices September 2006 + + +Appendix A. Terminology + + In this document, there is some jargon used that is defined in other + documents. In most cases, we have not copied the text from the + documents defining the terms but have given a more elaborate + explanation of the meaning. Note that these explanations should not + be seen as authoritative. + + Anchored key: A DNSKEY configured in resolvers around the globe. + This key is hard to update, hence the term anchored. + + Bogus: Also see Section 5 of [4]. An RRSet in DNSSEC is marked + "Bogus" when a signature of an RRSet does not validate against a + DNSKEY. + + Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used + exclusively for signing the apex key set. The fact that a key is + a KSK is only relevant to the signing tool. + + Key size: The term 'key size' can be substituted by 'modulus size' + throughout the document. It is mathematically more correct to use + modulus size, but as this is a document directed at operators we + feel more at ease with the term key size. + + Private and public keys: DNSSEC secures the DNS through the use of + public key cryptography. Public key cryptography is based on the + existence of two (mathematically related) keys, a public key and a + private key. The public keys are published in the DNS by use of + the DNSKEY Resource Record (DNSKEY RR). Private keys should + remain private. + + Key rollover: A key rollover (also called key supercession in some + environments) is the act of replacing one key pair with another at + the end of a key effectivity period. + + Secure Entry Point (SEP) key: A KSK that has a parental DS record + pointing to it or is configured as a trust anchor. Although not + required by the protocol, we recommend that the SEP flag [3] is + set on these keys. + + Self-signature: This only applies to signatures over DNSKEYs; a + signature made with DNSKEY x, over DNSKEY x is called a self- + signature. Note: without further information, self-signatures + convey no trust. They are useful to check the authenticity of the + DNSKEY, i.e., they can be used as a hash. + + + + + + +Kolkman & Gieben Informational [Page 30] + +RFC 4641 DNSSEC Operational Practices September 2006 + + + Singing the zone file: The term used for the event where an + administrator joyfully signs its zone file while producing melodic + sound patterns. + + Signer: The system that has access to the private key material and + signs the Resource Record sets in a zone. A signer may be + configured to sign only parts of the zone, e.g., only those RRSets + for which existing signatures are about to expire. + + Zone Signing Key (ZSK): A key that is used for signing all data in a + zone. The fact that a key is a ZSK is only relevant to the + signing tool. + + Zone administrator: The 'role' that is responsible for signing a zone + and publishing it on the primary authoritative server. + +Appendix B. Zone Signing Key Rollover How-To + + Using the pre-published signature scheme and the most conservative + method to assure oneself that data does not live in caches, here + follows the "how-to". + + Step 0: The preparation: Create two keys and publish both in your key + set. Mark one of the keys "active" and the other "published". + Use the "active" key for signing your zone data. Store the + private part of the "published" key, preferably off-line. The + protocol does not provide for attributes to mark a key as active + or published. This is something you have to do on your own, + through the use of a notebook or key management tool. + + Step 1: Determine expiration: At the beginning of the rollover make a + note of the highest expiration time of signatures in your zone + file created with the current key marked as active. Wait until + the expiration time marked in Step 1 has passed. + + Step 2: Then start using the key that was marked "published" to sign + your data (i.e., mark it "active"). Stop using the key that was + marked "active"; mark it "rolled". + + Step 3: It is safe to engage in a new rollover (Step 1) after at + least one signature validity period. + + + + + + + + + + +Kolkman & Gieben Informational [Page 31] + +RFC 4641 DNSSEC Operational Practices September 2006 + + +Appendix C. Typographic Conventions + + The following typographic conventions are used in this document: + + Key notation: A key is denoted by DNSKEYx, where x is a number or an + identifier, x could be thought of as the key id. + + RRSet notations: RRs are only denoted by the type. All other + information -- owner, class, rdata, and TTL--is left out. Thus: + "example.com 3600 IN A 192.0.2.1" is reduced to "A". RRSets are a + list of RRs. A example of this would be "A1, A2", specifying the + RRSet containing two "A" records. This could again be abbreviated to + just "A". + + Signature notation: Signatures are denoted as RRSIGx(RRSet), which + means that RRSet is signed with DNSKEYx. + + Zone representation: Using the above notation we have simplified the + representation of a signed zone by leaving out all unnecessary + details such as the names and by representing all data by "SOAx" + + SOA representation: SOAs are represented as SOAx, where x is the + serial number. + + Using this notation the following signed zone: + + example.net. 86400 IN SOA ns.example.net. bert.example.net. ( + 2006022100 ; serial + 86400 ; refresh ( 24 hours) + 7200 ; retry ( 2 hours) + 3600000 ; expire (1000 hours) + 28800 ) ; minimum ( 8 hours) + 86400 RRSIG SOA 5 2 86400 20130522213204 ( + 20130422213204 14 example.net. + cmL62SI6iAX46xGNQAdQ... ) + 86400 NS a.iana-servers.net. + 86400 NS b.iana-servers.net. + 86400 RRSIG NS 5 2 86400 20130507213204 ( + 20130407213204 14 example.net. + SO5epiJei19AjXoUpFnQ ... ) + 86400 DNSKEY 256 3 5 ( + EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14 + 86400 DNSKEY 257 3 5 ( + gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15 + 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( + 20130422213204 14 example.net. + J4zCe8QX4tXVGjV4e1r9... ) + + + + +Kolkman & Gieben Informational [Page 32] + +RFC 4641 DNSSEC Operational Practices September 2006 + + + 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( + 20130422213204 15 example.net. + keVDCOpsSeDReyV6O... ) + 86400 RRSIG NSEC 5 2 86400 20130507213204 ( + 20130407213204 14 example.net. + obj3HEp1GjnmhRjX... ) + a.example.net. 86400 IN TXT "A label" + 86400 RRSIG TXT 5 3 86400 20130507213204 ( + 20130407213204 14 example.net. + IkDMlRdYLmXH7QJnuF3v... ) + 86400 NSEC b.example.com. TXT RRSIG NSEC + 86400 RRSIG NSEC 5 3 86400 20130507213204 ( + 20130407213204 14 example.net. + bZMjoZ3bHjnEz0nIsPMM... ) + ... + + is reduced to the following representation: + + SOA2006022100 + RRSIG14(SOA2006022100) + DNSKEY14 + DNSKEY15 + + RRSIG14(KEY) + RRSIG15(KEY) + + The rest of the zone data has the same signature as the SOA record, + i.e., an RRSIG created with DNSKEY 14. + + + + + + + + + + + + + + + + + + + + + + + +Kolkman & Gieben Informational [Page 33] + +RFC 4641 DNSSEC Operational Practices September 2006 + + +Authors' Addresses + + Olaf M. Kolkman + NLnet Labs + Kruislaan 419 + Amsterdam 1098 VA + The Netherlands + + EMail: olaf@nlnetlabs.nl + URI: http://www.nlnetlabs.nl + + + R. (Miek) Gieben + + EMail: miek@miek.nl + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman & Gieben Informational [Page 34] + +RFC 4641 DNSSEC Operational Practices September 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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 provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Kolkman & Gieben Informational [Page 35] + diff --git a/doc/rfc/rfc952.txt b/doc/rfc/rfc952.txt new file mode 100644 index 0000000..7df339a --- /dev/null +++ b/doc/rfc/rfc952.txt @@ -0,0 +1,340 @@ +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] + |
