[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/