diff --git a/doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt b/doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt new file mode 100644 index 0000000000..b5877705eb --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc3597-bis-02.txt @@ -0,0 +1,451 @@ + + + + + + +INTERNET-DRAFT A. Gustafsson + Araneus Information Systems Oy + February 24, 2010 + +Intended status: Draft Standard +Obsoletes: RFC3597 + + Handling of Unknown DNS Resource Record (RR) Types + draft-ietf-dnsext-rfc3597-bis-02.txt + +Abstract + + Extending the Domain Name System (DNS) with new Resource Record (RR) + types should not requires changes to name server software. This + document specifies how new RR types are transparently handled by DNS + software. + +Status of this Memo + + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + + + +Expires August 2010 Standards Track [Page 1] + +draft-ietf-dnsext-rfc3597-bis-02.txt February 2010 + + + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +1. Introduction + + The DNS [RFC1034] is designed to be extensible to support new + services through the introduction of new resource record (RR) types. + Nevertheless, DNS implementations have historically required software + changes to support new RR types, not only at the authoritative DNS + server 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 DNS software is slow and expensive, + this has been a significant impediment to supporting new services in + the DNS. + + [RFC3597] defined DNS implementation behavior and procedures for + defining new RR types aimed at simplifying the deployment of new RR + types by allowing them to be treated transparently by existing + implementations. Thanks to the widespread adoption of that + specification, much of the DNS is now capable of handling new record + types without software changes. Another development that has + simplified the introduction of new DNS RR types is the adoption of a + simpler IANA allocation procedure for RR types [RFC5395]. + + This document is a self-contained revised specification supplanting + and obsoleting RFC 3597, with the aim of allowing the specification + to advance on the Standards Track. + +2. Definitions + + 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]. + + 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 [RFC5395] (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 known to be 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 + + + +Expires August 2010 Standards Track [Page 2] + +draft-ietf-dnsext-rfc3597-bis-02.txt February 2010 + + + To enable new RR types to be deployed without server changes, name + servers and resolvers MUST handle RRs of unknown type transparently. + The RDATA section of RRs of unknown type must be treated as + unstructured binary data, and must be stored and transmitted without + change ([RFC1123], section 6.1.3.5). + + 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 document. 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". + + 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, SRV, and NAPTR to ensure interoperability with implementations + predating [RFC3597]. + + 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, + + + +Expires August 2010 Standards Track [Page 3] + +draft-ietf-dnsext-rfc3597-bis-02.txt February 2010 + + + 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 "[] [] + " and "[] [] " forms of + [RFC1035] section 5.1 to both be unambiguously parsed. + + The RDATA section of an RR of unknown type is represented as a + sequence of items separated by any combination of tabs and spaces, 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 items of hexadecimal data encoding the actual RDATA + field, each item 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. + + 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 ) + + + +Expires August 2010 Standards Track [Page 4] + +draft-ietf-dnsext-rfc3597-bis-02.txt February 2010 + + + b.example. HS TYPE62347 \# 0 + e.example. IN A \# 4 C0000201 + e.example. CLASS1 TYPE1 192.0.2.1 + +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. + +7. DNSSEC Considerations + + The rules for the DNSSEC canonical form and ordering were updated to + support transparent treatment of unknown types in [RFC3597]. Those + updates have subsequently been integrated into the base DNSSEC + specification, such that the DNSSEC canonical form and ordering are + now specified in [RFC4034] or its successors rather than in this + document. + +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. + +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. + + + + +Expires August 2010 Standards Track [Page 5] + +draft-ietf-dnsext-rfc3597-bis-02.txt February 2010 + + +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. + + [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA + Considerations", BCP 42, RFC 5395, November 2008. + +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. + + [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, April 1997. + + [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. + +14. Author's Address + + Andreas Gustafsson + Araneus Information Systems Oy + PL 110 + 02321 Espoo + Finland + + Phone: +358 40 547 2099 + EMail: gson@araneus.fi + +Appendix A. Summary of Changes Since RFC3597 + + This section summarizes the major changes between RFC3597 and this + + + +Expires August 2010 Standards Track [Page 6] + +draft-ietf-dnsext-rfc3597-bis-02.txt February 2010 + + + document. In addition to the changes listed below, there has also + been a number of editorial changes, such as updates to the text in + the Abstract and Introduction to better reflect the current state of + implementation, updates to boilerplate text, and minor + clarifications. + + The reference to the DNS IANA Considerations BCP (BCP42) has been + changed from RFC2929 to the current version, RFC5395. + + Downward references have been eliminated; specifically, the document + no longer refers to RFC2163 or RFC2535. + + IP addresses in examples have been changed to use the 192.0.2.0/24 + range per RFC3330. + + The document no longer specifies changes to the DNSSEC canonical form + and ordering, as those changes have now been incorporated into the + base DNSSEC specification. + +Appendix B. Detailed Change Log + + [NOTE TO RFC EDITOR: PLEASE REMOVE THIS APPENDIX ON PUBLICATION.] + +B.1. Changes between RFC3597 and -00 + + The reference to the DNS IANA Considerations BCP (BCP42) has been + changed from RFC2929 to the current version, RFC5395. + + Downward references have been eliminated; specifically, the document + no longer refers to RFC2163 or RFC2535. + + IP addresses in examples have been changed to use the 192.0.2.0/24 + range per RFC3330. + + The document no longer specifies changes to the DNSSEC canonical form + and ordering, as those changes have now been incorporated into the + base DNSSEC specification. + + There has also been a number of editorial changes, such as updates to + the text in the Abstract and Introduction to better reflect the + current state of implementation. + +B.2. Changes between -00 and -01 + + Moved the Abstract to immediately following the document title. + + Updated boilerplate to the current version. + + + + +Expires August 2010 Standards Track [Page 7] + +draft-ietf-dnsext-rfc3597-bis-02.txt February 2010 + + + In the Introduction, the text "Another development that has + simplified the introduction of new DNS RR types is the adoption of a + simpler IANA allocation procedure for RR types" and a reference to + [RFC5395] were added. + + In the Introduction, the text "with the aim of allowing the + specification to advance on the Standards Track" was added to explain + the motivation for the draft. + + In section 2, the text "is class specific" was replaced by "is known + to be class specific". + + In section 3, the words "That is" were removed so as not to imply + that the transparent treatment of RRs of unknown type is only a + matter of how the RDATA field is handled. The remainder of the + sentence was rephrased. + + In section 4, the entries for SRV and NAPTR in the list of RR types + to decompress were swapped to make the list consistently ordered by + ascending numerical RR type. + + References to RFC 1035 and RFC 1123 now include the specific section + numbers being referenced. + + A Change History was added as Appendix A. + +B.3. Changes between -01 and -02 + + In section 5, the term "white space" was replaced by "any combination + of tabs and spaces", and the term "word" was replaced by "item", for + consistency with RFC1035 terminology. + + In section 5, hyphens were added to mark the beginning of each item + in the the list of items comprising the RDATA text representation. + + The Change History was split into a Summary of Changes Since RFC3597 + (Appendix A) intended to remain in the document when published as an + RFC, and a Detailed Change Log (Appendix B) to be deleted on + publication. + + + + + + + + + + + + +Expires August 2010 Standards Track [Page 8] +