draft-ietf-dnsext-unknown-rrs-00.txt   draft-ietf-dnsext-unknown-rrs-01.txt 
INTERNET-DRAFT Andreas Gustafsson INTERNET-DRAFT Andreas Gustafsson
draft-ietf-dnsext-unknown-rrs-00.txt Nominum Inc. draft-ietf-dnsext-unknown-rrs-01.txt Nominum Inc.
November 2000 July 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 17 skipping to change at page 2, line 17
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. Definitions
In this document, a "well known" RR type means one defined in In this document, a "well known" RR type means one defined in
RFC1035. RFC1035.
An "RR of unknown type" is an RR type whose RDATA format is not known An "RR of unknown type" is an RR whose RDATA format is not known to
to the DNS implementation at hand, and which therefore cannot be the DNS implementation at hand, such that it cannot be converted to a
converted to a type-specific text format, compressed, or otherwise type-specific text format, compressed, or otherwise handled in a
handled in any type-specific way. This includes the case where the type-specific way, and whose type is not an assigned QTYPE or Meta-
RR's type is recognized but its RDATA format is class specific and TYPE in RFC2929 section 3.1 nor within the range reserved in that
the RR is of a class for which the format is not known. section for assignment only to QTYPEs and Meta-TYPEs.
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 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.
4. Domain Name Compression 4. Domain Name Compression
skipping to change at page 4, line 36 skipping to change at page 4, line 40
name(s). This is similar to the existing possibility of multiple TXT name(s). This is similar to the existing possibility of multiple TXT
records differing only in character case, and not expected to cause records differing only in character case, and not expected to cause
any problems in practice. any problems in practice.
7. DNSSEC Canonical Form and Ordering 7. DNSSEC Canonical Form and Ordering
DNSSEC [RFC2535] defines a canonical form and ordering for RRs. In DNSSEC [RFC2535] defines a canonical form and ordering for RRs. In
the canonical form, domain names embedded in the RDATA are converted the canonical form, domain names embedded in the RDATA are converted
to lower case. to lower case.
To ensure backwards compatilbility, this canonical form remains To ensure backwards compatibility, this canonical form remains
unchanged for any RR types defined in RFC2931 or earlier. That is, unchanged for any RR types defined in RFC2931 or earlier. That is,
the domain names embedded in RRs of type NS, MD, MF, CNAME, SOA, MB, the domain names embedded in RRs of type NS, MD, MF, CNAME, SOA, MB,
MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT,
NAPTR, KX, SRV, DNAME, and A6 are converted to lower case. For all NAPTR, KX, SRV, DNAME, and A6 are converted to lower case. For all
other RR types, the canonical form is hereby changed such that no other RR types, the canonical form is hereby changed such that no
downcasing of embedded domain names takes place. The owner name is downcasing of embedded domain names takes place. The owner name is
still set to lower case. still set to lower case.
The canonical ordering is as specified in RFC2535 section 8.3, where The canonical ordering is as specified in RFC2535 section 8.3, where
the octet sequence is the canonical form as revised by this the octet sequence is the canonical form as revised by this
skipping to change at page 5, line 12 skipping to change at page 5, line 16
Unknown RR types cause no additional section processing. Future RR Unknown RR types cause no additional section processing. Future RR
type specifications MAY specify type-specific additional section type specifications MAY specify type-specific additional section
processing rules, but any such processing MUST be optional as it can 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. only be performed by servers for which the RR type in case is known.
9. IANA Considerations 9. IANA Considerations
The IANA is hereby requested to verify that specifications for new RR The IANA is hereby requested to verify that specifications for new RR
types requesting an RR type number comply with this specification. types requesting an RR type number comply with this specification.
In particular, the IANA MUST NOT assign numbers to RR types whose In particular, the IANA MUST NOT assign numbers to new RR types whose
specification allows embedded domain names to be compressed. specification allows embedded domain names to be compressed.
10. Security Considerations 10. Security Considerations
This specification is not believed to cause any new security This specification is not believed to cause any new security
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 [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). P.
Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997. 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, March
1999. 1999.
[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. Nominum Inc.
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
Phone: +1 650 779 6004 Phone: +1 650 381 6004
Email: Andreas.Gustafsson@nominum.com Email: Andreas.Gustafsson@nominum.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2000). 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
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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