draft-ietf-dnsext-unknown-rrs-01.txt   draft-ietf-dnsext-unknown-rrs-02.txt 
INTERNET-DRAFT Andreas Gustafsson INTERNET-DRAFT Andreas Gustafsson
draft-ietf-dnsext-unknown-rrs-01.txt Nominum Inc. draft-ietf-dnsext-unknown-rrs-02.txt ISC
July 2001 November 2001
Handling of Unknown DNS RR Types Handling of Unknown DNS RR Types
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 12 skipping to change at page 2, line 12
Because the deployment of new server software is slow and expensive, Because the deployment of new server software is slow and expensive,
the potential of the DNS in supporting new services has never been the potential of the DNS in supporting new services has never been
fully realized. This memo proposes changes to name servers and to fully realized. This memo proposes changes to name servers and to
procedures for defining new RR types aimed at simplifying the future procedures for defining new RR types aimed at simplifying the future
deployment of new RR types. deployment of new RR types.
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 [RFC 2119]. document are to be interpreted as described in [RFC 2119].
2. Definitions 2. Definition
In this document, a "well known" RR type means one defined in
RFC1035.
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, such that it cannot be converted to a the DNS implementation at hand, such that it cannot be converted to a
type-specific text format, compressed, or otherwise handled in a type-specific text format, compressed, or otherwise handled in a
type-specific way, and whose type is not an assigned QTYPE or Meta- type-specific way, and whose type is not an assigned QTYPE or Meta-
TYPE in RFC2929 section 3.1 nor within the range reserved in that TYPE in RFC2929 section 3.1 nor within the range reserved in that
section for assignment only to QTYPEs and Meta-TYPEs. section for assignment only to QTYPEs and Meta-TYPEs.
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 class specific, an RR is
considered to be of unknown type when the RDATA format for that considered to be of unknown type when the RDATA format for that
combination of type and class is not known. 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 That is, they must treat the RDATA section of such RRs as
unstructured binary data, storing and transmitting it without change. unstructured binary data, storing and transmitting it without change
[RFC1123].
4. Domain Name Compression 4. Domain Name Compression
RRs containing compression pointers in the RDATA part cannot be RRs containing compression pointers in the RDATA part cannot be
treated transparently, as the compression pointers are only treated transparently, as the compression pointers are only
meaningful within the context of a DNS message. Transparently meaningful within the context of a DNS message. Transparently
copying the RDATA into a new DNS message would cause the compression copying the RDATA into a new DNS message would cause the compression
pointers to point at the corresponding location in the new message, pointers to point at the corresponding location in the new message,
which now contains unrelated data. This would cause the compressed which now contains unrelated data. This would cause the compressed
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 not well known. 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 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 (although the SRV RR is clearly defined to not NXT, NAPTR, and SRV (although the current specification of the SRV RR
allow compression of the target field, some existing name servers in RFC2782 prohibits compression, RFC2052 mandated it, and some
compress it anyway). servers following that earlier specification are still in use).
Future specifications for new RR types that contain domain names Future specifications for new RR types that contain domain names
within their RDATA MUST NOT allow the use of name compression for within their RDATA MUST NOT allow the use of name compression for
those names, and SHOULD explicitly state that the embedded domain those names, and SHOULD explicitly state that the embedded domain
names MUST NOT be compressed. names MUST NOT be compressed.
As noted in RFC1123, the owner name of an RR is always eligible for
compression.
5. Text Representation 5. Text Representation
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>]
skipping to change at page 5, line 32 skipping to change at page 5, line 36
problems, nor to solve any existing ones. problems, nor to solve any existing ones.
References References
[RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
November 1987. November 1987.
[RFC1035] - Domain Names - Implementation and Specifications, P. [RFC1035] - Domain Names - Implementation and Specifications, P.
Mockapetris, November 1987. Mockapetris, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC1123] - Requirements for Internet Hosts -- Application and
Support, R. Braden, Editor, October 1989.
[RFC2052] - A DNS RR for specifying the location of services (DNS
SRV), A. Gulbrandsen, P. Vixie, October 1996. Obsoleted by RFC2782.
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE). P. [RFC2136] - Dynamic Updates in the Domain Name System (DNS UPDATE).
Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997. P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997.
[RFC2535] Domain Name System Security Extensions. D. Eastlake, March [RFC2535] - Domain Name System Security Extensions. D. Eastlake,
1999. March 1999.
[RFC2929] Domain Name System (DNS) IANA Considerations. D. Eastlake, [RFC2782] - A DNS RR for specifying the location of services (DNS
E. Brunner-Williams, B. Manning, September 2000. SRV). A. Gulbrandsen, P. Vixie, L. Esibov, February 2000.
[RFC2929] - Domain Name System (DNS) IANA Considerations. D.
Eastlake, E. Brunner-Williams, B. Manning, September 2000.
Author's Address Author's Address
Andreas Gustafsson Andreas Gustafsson
Nominum Inc. ISC
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
Phone: +1 650 381 6004 Phone: +1 650 779 7004
Email: Andreas.Gustafsson@nominum.com
Email: Andreas_Gustafsson@isc.org
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/