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/