Edit File: draft-ietf-dnsext-rfc3597-bis-02.txt
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 "[<TTL>] [<class>] <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" 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]
Back to File Manager