From 3a2a2463f2ec42666dd225e7bcfb26c41bcac38e Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 23 Sep 2009 22:15:24 +0000 Subject: [PATCH] new draft --- .../draft-ietf-dnsext-rfc3597-bis-00.txt | 395 ++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt diff --git a/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt b/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt new file mode 100644 index 0000000000..ee35cb91af --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt @@ -0,0 +1,395 @@ + + + + + + +INTERNET-DRAFT A. Gustafsson + Araneus Information Systems Oy + September 23, 2009 + +Intended status: Draft Standard +Obsoletes: RFC3597 + + Handling of Unknown DNS Resource Record (RR) Types + draft-ietf-dnsext-rfc3597-bis-00.txt + +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) 2009 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 in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + +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. + + + + +Expires March 2010 Standards Track [Page 1] + +draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 + + +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. + + This document is a self-contained revised specification supplanting + and obsoleting [RFC3597]. + +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 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]. + + + + +Expires March 2010 Standards Track [Page 2] + +draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 + + + 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, NAPTR, and SRV 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, + 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 + + + +Expires March 2010 Standards Track [Page 3] + +draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 + + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Expires March 2010 Standards Track [Page 4] + +draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 + + + 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 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. + + + + + + +Expires March 2010 Standards Track [Page 5] + +draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 + + +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. + +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. + + + + +Expires March 2010 Standards Track [Page 6] + +draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 + + + [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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Expires March 2010 Standards Track [Page 7] +