From: Automatic Updater Date: Thu, 25 Feb 2010 01:45:07 +0000 (+0000) Subject: sync X-Git-Tag: v9.6.3~527 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=ff50f1db55e771d47da37c4ee83eeba1da9f8c93;p=thirdparty%2Fbind9.git sync --- diff --git a/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt b/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt deleted file mode 100644 index ee35cb91af8..00000000000 --- a/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -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] -