draft-ietf-dnsext-rfc3597-bis-00.txt   draft-ietf-dnsext-rfc3597-bis-01.txt 
INTERNET-DRAFT A. Gustafsson INTERNET-DRAFT A. Gustafsson
Araneus Information Systems Oy Araneus Information Systems Oy
September 23, 2009 January 26, 2010
Intended status: Draft Standard Intended status: Draft Standard
Obsoletes: RFC3597 Obsoletes: RFC3597
Handling of Unknown DNS Resource Record (RR) Types Handling of Unknown DNS Resource Record (RR) Types
draft-ietf-dnsext-rfc3597-bis-00.txt draft-ietf-dnsext-rfc3597-bis-01.txt
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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 42
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Extending the Domain Name System (DNS) with new Resource Record (RR) described in the Simplified BSD License.
types should not requires changes to name server software. This
document specifies how new RR types are transparently handled by DNS
software.
1. Introduction 1. Introduction
The DNS [RFC1034] is designed to be extensible to support new The DNS [RFC1034] is designed to be extensible to support new
services through the introduction of new resource record (RR) types. services through the introduction of new resource record (RR) types.
Nevertheless, DNS implementations have historically required software Nevertheless, DNS implementations have historically required software
changes to support new RR types, not only at the authoritative DNS changes to support new RR types, not only at the authoritative DNS
server providing the new information and the client making use of it, 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 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. cases also at caching name servers and forwarders used by the client.
Because the deployment of new DNS software is slow and expensive, Because the deployment of new DNS software is slow and expensive,
this has been a significant impediment to supporting new services in this has been a significant impediment to supporting new services in
the DNS. the DNS.
[RFC3597] defined DNS implementation behavior and procedures for [RFC3597] defined DNS implementation behavior and procedures for
defining new RR types aimed at simplifying the deployment of new RR defining new RR types aimed at simplifying the deployment of new RR
types by allowing them to be treated transparently by existing types by allowing them to be treated transparently by existing
implementations. Thanks to the widespread adoption of that implementations. Thanks to the widespread adoption of that
specification, much of the DNS is now capable of handling new record specification, much of the DNS is now capable of handling new record
types without software changes. types without software changes. Another development that has
simplified the introduction of new DNS RR types is the adoption of a
simpler IANA allocation procedure for RR types [RFC5395].
This document is a self-contained revised specification supplanting This document is a self-contained revised specification supplanting
and obsoleting [RFC3597]. and obsoleting RFC 3597, with the aim of allowing the specification
to advance on the Standards Track.
2. Definitions 2. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
An "RR of unknown type" is an RR whose RDATA format is not known to 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 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 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 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 Meta-TYPEs. Such an RR cannot be converted to a type-specific text
format, compressed, or otherwise handled in a type-specific way. 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 In the case of a type whose RDATA format is known to be class
considered to be of unknown type when the RDATA format for that specific, an RR is considered to be of unknown type when the RDATA
combination of type and class is not known. format for that combination of type and class is not known.
3. Transparency 3. Transparency
To enable new RR types to be deployed without server changes, name To enable new RR types to be deployed without server changes, name
servers and resolvers MUST handle RRs of unknown type transparently. servers and resolvers MUST handle RRs of unknown type transparently.
That is, they must treat the RDATA section of such RRs as The RDATA section of RRs of unknown type must be treated as
unstructured binary data, storing and transmitting it without change unstructured binary data, and must be stored and transmitted without
[RFC1123]. change ([RFC1123], section 6.1.3.5).
To ensure the correct operation of equality comparison (section 6) To ensure the correct operation of equality comparison (section 6)
and of the DNSSEC canonical form (section 7) when an RR type is known 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 to some but not all of the servers involved, servers MUST also
exactly preserve the RDATA of RRs of known type, except for changes exactly preserve the RDATA of RRs of known type, except for changes
due to compression or decompression where allowed by section 4 of due to compression or decompression where allowed by section 4 of
this document. In particular, the character case of domain names this document. In particular, the character case of domain names
that are not subject to compression MUST be preserved. that are not subject to compression MUST be preserved.
4. Domain Name Compression 4. Domain Name Compression
skipping to change at page 3, line 31 skipping to change at page 3, line 36
name to be corrupted. name to be corrupted.
To avoid such corruption, servers MUST NOT compress domain names To avoid such corruption, servers MUST NOT compress domain names
embedded in the RDATA of types that are class-specific or not well- embedded in the RDATA of types that are class-specific or not well-
known. This requirement was stated in [RFC1123] without defining the known. This requirement was stated in [RFC1123] without defining the
term "well-known"; it is hereby specified that only the RR types term "well-known"; it is hereby specified that only the RR types
defined in [RFC1035] are to be considered "well-known". defined in [RFC1035] are to be considered "well-known".
Receiving servers MUST decompress domain names in RRs of 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, type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
NXT, NAPTR, and SRV to ensure interoperability with implementations NXT, SRV, and NAPTR to ensure interoperability with implementations
predating [RFC3597]. predating [RFC3597].
Specifications for new RR types that contain domain names within Specifications for new RR types that contain domain names within
their RDATA MUST NOT allow the use of name compression for those their RDATA MUST NOT allow the use of name compression for those
names, and SHOULD explicitly state that the embedded domain names names, and SHOULD explicitly state that the embedded domain names
MUST NOT be compressed. MUST NOT be compressed.
As noted in [RFC1123], the owner name of an RR is always eligible for As noted in [RFC1123], the owner name of an RR is always eligible for
compression. compression.
skipping to change at page 4, line 4 skipping to change at page 4, line 10
In the "type" field of a master file line, an unknown RR type is 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 represented by the word "TYPE" immediately followed by the decimal RR
type number, with no intervening whitespace. In the "class" field, type number, with no intervening whitespace. In the "class" field,
an unknown class is similarly represented as the word "CLASS" an unknown class is similarly represented as the word "CLASS"
immediately followed by the decimal class number. immediately followed by the decimal class number.
This convention allows types and classes to be distinguished from This convention allows types and classes to be distinguished from
each other and from TTL values, allowing the "[<TTL>] [<class>] each other and from TTL values, allowing the "[<TTL>] [<class>]
<type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
[RFC1035] section 5.1 to both be unambiguously parsed.
[RFC1035] to both be unambiguously parsed.
The RDATA section of an RR of unknown type is represented as a The RDATA section of an RR of unknown type is represented as a
sequence of white space separated words as follows: sequence of white space separated words as follows:
The special token \# (a backslash immediately followed by a hash The special token \# (a backslash immediately followed by a hash
sign), which identifies the RDATA as having the generic encoding sign), which identifies the RDATA as having the generic encoding
defined herein rather than a traditional type-specific encoding. defined herein rather than a traditional type-specific encoding.
An unsigned decimal integer specifying the RDATA length in octets. An unsigned decimal integer specifying the RDATA length in octets.
skipping to change at line 279 skipping to change at page 6, line 47
14. Author's Address 14. Author's Address
Andreas Gustafsson Andreas Gustafsson
Araneus Information Systems Oy Araneus Information Systems Oy
PL 110 PL 110
02321 Espoo 02321 Espoo
Finland Finland
Phone: +358 40 547 2099 Phone: +358 40 547 2099
EMail: gson@araneus.fi EMail: gson@araneus.fi
Appendix A. Change History
[NOTE TO RFC EDITOR: PLEASE REMOVE THIS APPENDIX ON PUBLICATION.]
A.1. Changes between RFC3597 and -00
The reference to the DNS IANA Considerations BCP (BCP42) has been
changed from RFC2929 to the current version, RFC5395
Downward references have been eliminated; specifically, the document
no longer refers to RFC2163 or RFC2535.
IP addresses in examples have been changed to the 192.0.2.0/24 range
per RFC3330
The draft no longer specifies changes to the DNSSEC canonical form
and ordering, as those changes have now been incorporated into the
base DNSSEC specification.
There has also been a number of editorial changes, such as updates to
the text in the Abstract and Introduction to better reflect the
current state of implementation.
A.2. Changes between -00 and -01
Moved the Abstract to immediately following the document title.
Updated boilerplate to the current version.
In the Introduction, the text "Another development that has
simplified the introduction of new DNS RR types is the adoption of a
simpler IANA allocation procedure for RR types" and a reference to
[RFC5395] were added.
In the Introduction, the text "with the aim of allowing the
specification to advance on the Standards Track" was added to explain
the motivation for the draft.
In section 2, the text "is class specific" was replaced by "is known
to be class specific".
In section 3, the words "That is" were removed so as not to imply
that the transparent treatment of RRs of unknown type is only a
matter of how the RDATA field is handled. The remainder of the
sentence was rephrased.
In section 4, the entries for SRV and NAPTR in the list of RR types
to decompress were swapped to make the list consistently ordered by
ascending numerical RR type.
References to RFC 1035 and RFC 1123 now include the specific section
numbers being referenced.
A Change History was added as Appendix A.
 End of changes. 12 change blocks. 
27 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.37c. The latest version is available from http://tools.ietf.org/tools/rfcdiff/