+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
projects / thirdparty / bind9.git / commitdiff
