1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc3597.txt b/doc/rfc/rfc3597.txt
new file mode 100644
index 0000000..19e9a55
--- /dev/null
+++ b/doc/rfc/rfc3597.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                      A. Gustafsson
+Request for Comments: 3597                                  Nominum Inc.
+Category: Standards Track                                 September 2003
+
+
+           Handling of Unknown DNS Resource Record (RR) Types
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   Extending the Domain Name System (DNS) with new Resource Record (RR)
+   types currently requires changes to name server software.  This
+   document specifies the changes necessary to allow future DNS
+   implementations to handle new RR types transparently.
+
+1.  Introduction
+
+   The DNS is designed to be extensible to support new services through
+   the introduction of new resource record (RR) types.  In practice,
+   deploying a new RR type currently requires changes to the name server
+   software not only at the authoritative DNS server that is 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 server software is slow and expensive,
+   the potential of the DNS in supporting new services has never been
+   fully realized.  This memo proposes changes to name servers and to
+   procedures for defining new RR types aimed at simplifying the future
+   deployment of new RR types.
+
+   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 [RFC 2119].
+
+
+
+
+
+
+Gustafsson                  Standards Track                     [Page 1]
+
+RFC 3597            Handling of Unknown DNS RR Types      September 2003
+
+
+2.  Definition
+
+   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 [RFC 2929] (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].
+
+   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 memo.  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".
+
+
+
+
+
+
+Gustafsson                  Standards Track                     [Page 2]
+
+RFC 3597            Handling of Unknown DNS RR Types      September 2003
+
+
+   The specifications of a few existing RR types have explicitly allowed
+   compression contrary to this specification: [RFC2163] specified that
+   compression applies to the PX RR, and [RFC2535] allowed compression
+   in SIG RRs and NXT RRs records.  Since this specification disallows
+   compression in these cases, it is an update to [RFC2163] (section 4)
+   and [RFC2535] (sections 4.1.7 and 5.2).
+
+   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 (although the current specification of the SRV RR
+   in [RFC2782] prohibits compression, [RFC2052] mandated it, and some
+   servers following that earlier specification are still in use).
+
+   Future 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
+   [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.
+
+
+
+Gustafsson                  Standards Track                     [Page 3]
+
+RFC 3597            Handling of Unknown DNS RR Types      September 2003
+
+
+   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 0A000001
+      e.example.   CLASS1      TYPE1           10.0.0.2
+
+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.
+
+
+
+
+
+
+Gustafsson                  Standards Track                     [Page 4]
+
+RFC 3597            Handling of Unknown DNS RR Types      September 2003
+
+
+7.  DNSSEC Canonical Form and Ordering
+
+   DNSSEC defines a canonical form and ordering for RRs [RFC2535]
+   (section 8.1).  In that canonical form, domain names embedded in the
+   RDATA are converted to lower case.
+
+   The downcasing is necessary to ensure the correctness of DNSSEC
+   signatures when case distinctions in domain names are lost due to
+   compression, but since it requires knowledge of the presence and
+   position of embedded domain names, it cannot be applied to unknown
+   types.
+
+   To ensure continued consistency of the canonical form of RR types
+   where compression is allowed, and for continued interoperability with
+   existing implementations that already implement the [RFC2535]
+   canonical form and apply it to their known RR types, the canonical
+   form remains unchanged for all RR types whose whose initial
+   publication as an RFC was prior to the initial publication of this
+   specification as an RFC (RFC 3597).
+
+   As a courtesy to implementors, it is hereby noted that the complete
+   set of such previously published RR types that contain embedded
+   domain names, and whose DNSSEC canonical form therefore involves
+   downcasing according to the DNS rules for character comparisons,
+   consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
+   HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
+   DNAME, and A6.
+
+   This document specifies that for all other RR types (whether treated
+   as unknown types or treated as known types according to an RR type
+   definition RFC more recent than RFC 3597), the canonical form is such
+   that no downcasing of embedded domain names takes place, and
+   otherwise identical to the canonical form specified in [RFC2535]
+   section 8.1.
+
+   Note that the owner name is always set to lower case according to the
+   DNS rules for character comparisons, regardless of the RR type.
+
+   The DNSSEC canonical RR ordering is as specified in [RFC2535] section
+   8.3, where the octet sequence is the canonical form as revised by
+   this specification.
+
+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.
+
+
+
+Gustafsson                  Standards Track                     [Page 5]
+
+RFC 3597            Handling of Unknown DNS RR Types      September 2003
+
+
+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.
+
+   [RFC2535]   Eastlake, D., "Domain Name System Security Extensions",
+               RFC 2535, March 1999.
+
+   [RFC2163]   Allocchio, C., "Using the Internet DNS to Distribute
+               MIXER Conformant Global Address Mapping (MCGAM)", RFC
+               2163, January 1998.
+
+   [RFC2929]   Eastlake, D., Brunner-Williams, E. and B. Manning,
+               "Domain Name System (DNS) IANA Considerations", BCP 42,
+               RFC 2929, September 2000.
+
+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.
+
+   [RFC2052]   Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying
+               the location of services (DNS SRV)", RFC 2052, October
+               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.
+
+
+
+
+Gustafsson                  Standards Track                     [Page 6]
+
+RFC 3597            Handling of Unknown DNS RR Types      September 2003
+
+
+   [RFC2782]   Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+               specifying the location of services (DNS SRV)", RFC 2782,
+               February 2000.
+
+13.  Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+14.  Author's Address
+
+   Andreas Gustafsson
+   Nominum, Inc.
+   2385 Bay Rd
+   Redwood City, CA 94063
+   USA
+
+   Phone: +1 650 381 6004
+   EMail: gson@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gustafsson                  Standards Track                     [Page 7]
+
+RFC 3597            Handling of Unknown DNS RR Types      September 2003
+
+
+15.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gustafsson                  Standards Track                     [Page 8]
+