draft-ietf-dnsext-unknown-rrs-04.txt   draft-ietf-dnsext-unknown-rrs-05.txt 
INTERNET-DRAFT Andreas Gustafsson INTERNET-DRAFT Andreas Gustafsson
draft-ietf-dnsext-unknown-rrs-04.txt Nominum Inc. draft-ietf-dnsext-unknown-rrs-05.txt Nominum Inc.
September 2002 March 2003
Handling of Unknown DNS RR Types Updates: RFC 1034, RFC 2163, RFC 2535
Handling of Unknown DNS Resource Record 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 34
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/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
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.
Abstract Abstract
Extending the Domain Name System with new Resource Record types Extending the Domain Name System with new Resource Record (RR) types
currently requires changes to name server software. This document currently requires changes to name server software. This document
specifies the changes necessary to allow future DNS implementations specifies the changes necessary to allow future DNS implementations
to handle new RR types transparently. to handle new RR types transparently.
1. Introduction 1. Introduction
The DNS is designed to be extensible to support new services through The DNS is designed to be extensible to support new services through
the introduction of new resource record (RR) types. In practice, the introduction of new resource record (RR) types. In practice,
deploying a new RR type currently requires changes to the name server deploying a new RR type currently requires changes to the name server
software not only at the authoritative DNS server that is providing software not only at the authoritative DNS server that is providing
skipping to change at page 3, line 9 skipping to change at page 3, line 11
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 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".
The specifications of a few existing RR types have explicitly allowed
compression contrary to this specification: RFC2163 specified that
compression applies to the PX RR, and RFC2535 allowed compression in
SIG RRs and NXT RRs records. Since this specification disallows
compression in these cases, it is an update to RFC2163 (section 4)
and RFC2535 (sections 4.1.7 and 5.2).
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 current specification of the SRV RR NXT, NAPTR, and SRV (although the current specification of the SRV RR
in RFC2782 prohibits compression, RFC2052 mandated it, and some in RFC2782 prohibits compression, RFC2052 mandated it, and some
servers following that earlier specification are still in use). 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.
skipping to change at page 4, line 46 skipping to change at page 5, line 4
Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs
to be compared for equality. Two RRs of the same unknown type are to be compared for equality. Two RRs of the same unknown type are
considered equal when their RDATA is bitwise equal. To ensure that 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 outcome of the comparison is identical whether the RR is known to
the server or not, specifications for new RR types MUST NOT specify the server or not, specifications for new RR types MUST NOT specify
type-specific comparison rules. type-specific comparison rules.
This implies that embedded domain names, being included in the This implies that embedded domain names, being included in the
overall bitwise comparison, are compared in a case-sensitive manner. overall bitwise comparison, are compared in a case-sensitive manner.
As a result, when a new RR type contains one or more embedded domain 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 names, it is possible to have multiple RRs owned by the same name
that differ only in the character case of the embedded domain that differ only in the character case of the embedded domain
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 defines a canonical form and ordering for RRs [RFC2535,
the canonical form, domain names embedded in the RDATA are converted section 8.1]. In that canonical form, domain names embedded in the
to lower case. RDATA are converted to lower case.
To ensure backwards compatibility, this canonical form remains The downcasing is necessary to ensure the correctness of DNSSEC
unchanged for any RR types defined in RFC2931 or earlier. That is, signatures when case distinctions in domain names are lost due to
the domain names embedded in RRs of type NS, MD, MF, CNAME, SOA, MB, compression, but since it requires knowledge of the presence and
MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, position of embedded domain names, it cannot be applied to unknown
NAPTR, KX, SRV, DNAME, and A6 are converted to lower case according types.
to the DNS rules for character comparisons.
For all other RR types, the canonical form is hereby changed such To ensure continued consistency of the canonical form of RR types
that no downcasing of embedded domain names takes place. The owner where compression is allowed, and for continued interoperability with
name is always set to lower case according to the DNS rules for existing implementations that already implement the RFC2535 canonical
character comparisons, regardless of the RR type. form and apply it to their known RR types, the canonical form remains
unchanged for all RR types whose whose initial publication as an RFC
was prior to the initial publication of this specification as an RFC
(RFC TBD).
The canonical ordering is as specified in RFC2535 section 8.3, where As a courtesy to implementors, it is hereby noted that the complete
the octet sequence is the canonical form as revised by this set of such previously published RR types that contain embedded
specification. domain names, and whose DNSSEC canonical form therefore involves
downcasing according to the DNS rules for character comparisons,
consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
DNAME, and A6.
This document specifies that for all other RR types (whether treated
as unknown types or treated as known types according to an RR type
definition RFC more recent than than RFC TBD), the canonical form is
such that no downcasing of embedded domain names takes place, and
otherwise identical to the canonical form specified in RFC2535
section 8.1.
Note that the owner name is always set to lower case according to the
DNS rules for character comparisons, regardless of the RR type.
The DNSSEC canonical RR ordering is as specified in RFC2535 section
8.3, where the octet sequence is the canonical form as revised by
this specification.
8. Additional Section Processing 8. Additional Section Processing
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 new 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 Normative 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.
[RFC1123] - Requirements for Internet Hosts -- Application and [RFC1123] - Requirements for Internet Hosts -- Application and
Support, R. Braden, Editor, October 1989. Support, R. Braden, Editor, October 1989.
[RFC2119] - Key words for use in RFCs to Indicate Requirement Levels,
S. Bradner, BCP 14, March 1997.
[RFC2535] - Domain Name System Security Extensions. D. Eastlake,
March 1999.
[RFC2613] - Using the Internet DNS to Distribute MIXER Conformant
Global Address Mapping (MCGAM), C. Allocchio, January 1998.
[RFC2929] - Domain Name System (DNS) IANA Considerations, D.
Eastlake, E. Brunner-Williams, B. Manning, September 2000.
Non-normative References
[RFC1876] - A Means for Expressing Location Information in the Domain [RFC1876] - A Means for Expressing Location Information in the Domain
Name System, C. Davis, P. Vixie, T. Goodwin, I. Dickinson, January Name System, C. Davis, P. Vixie, T. Goodwin, I. Dickinson, January
1996. 1996.
[RFC2052] - A DNS RR for specifying the location of services (DNS [RFC2052] - A DNS RR for specifying the location of services (DNS
SRV), A. Gulbrandsen, P. Vixie, October 1996. Obsoleted by RFC2782. SRV), A. Gulbrandsen, P. Vixie, October 1996. Obsoleted by RFC2782.
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate [RFC2136] - Dynamic Updates in the Domain Name System (DNS UPDATE),
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] - Dynamic Updates in the Domain Name System (DNS UPDATE).
P. 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 1999.
[RFC2782] - A DNS RR for specifying the location of services (DNS [RFC2782] - A DNS RR for specifying the location of services (DNS
SRV). A. Gulbrandsen, P. Vixie, L. Esibov, February 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. Nominum Inc.
2385 Bay Rd 2385 Bay Rd
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
Phone: +1 650 381 6004 Phone: +1 650 381 6004
skipping to change at line 305 skipping to change at page 8, line 5
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such proprietary
rights by implementors or users of this specification can be obtained
from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
 End of changes. 

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