1 files changed, 395 insertions, 0 deletions
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 000000000000..ee35cb91af8e
--- /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 "[<TTL>] [<class>]
+   <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" 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]
+