draft-ietf-dnsext-insensitive-00.txt		draft-ietf-dnsext-insensitive-01.txt
	INTERNET-DRAFT Donald E. Eastlake 3rd		INTERNET-DRAFT Donald E. Eastlake 3rd
	Clarifies STD0013 Motorola Laboratories		Clarifies STD0013 Motorola Laboratories
	Expires July 2003 January 2003		Expires August 2003 February 2003
	Domain Name System (DNS) Case Insensitivity Clarification		Domain Name System (DNS) Case Insensitivity Clarification
	------ ---- ------ ----- ---- ------------- -------------		------ ---- ------ ----- ---- ------------- -------------
	<draft-ietf-dnsext-insensitive-00.txt>		<draft-ietf-dnsext-insensitive-01.txt>
	Donald E. Eastlake 3rd		Donald E. Eastlake 3rd
	Status of This Document		Status of This Document
	Distribution of this document is unlimited. Comments should be sent		Distribution of this document is unlimited. Comments should be sent
	to the DNSEXT working group at namedroppers@ops.ietf.org.		to the DNSEXT working group at namedroppers@ops.ietf.org.
	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 RFC 2026. Internet-Drafts are		all provisions of Section 10 of RFC 2026. Internet-Drafts are
	skipping to change at page 2, line 7		skipping to change at page 2, line 7
	Abstract		Abstract
	Domain Name System (DNS) names are "case insensitive". This document		Domain Name System (DNS) names are "case insensitive". This document
	explains exactly what that means and provides a clear specification		explains exactly what that means and provides a clear specification
	of the rules. This clarification should not have any interoperability		of the rules. This clarification should not have any interoperability
	consequences.		consequences.
	INTERNET-DRAFT DNS Case Insensitivity		INTERNET-DRAFT DNS Case Insensitivity
			Acknowledgements
			The contributions to this document of Rob Austein, Olafur
			Gudmundsson, Daniel J. Anderson, Alan Barrett, and Andrew Main are
			gratefully acknowledged.
	Table of Contents		Table of Contents
	Status of This Document....................................1		Status of This Document....................................1
	Abstract...................................................1		Abstract...................................................1
			Acknowledgements...........................................2
	Table of Contents..........................................2		Table of Contents..........................................2
	1. Introduction............................................3		1. Introduction............................................3
	2. Case Insensitivity of DNS Labels........................3		2. Case Insensitivity of DNS Labels........................3
	3. Additional DNS Case Insensitivity Considerations........4		2.1 Escaping Unusual DNS Label Octets......................3
	3.1 CLASS Case Insensitivity Considerations................4		2.2 Example Labels with Escapes............................4
	3.2 Label Type Case Insensitivity Considerations...........5		2.3 Name Lookup Case Insensitivity.........................4
	4. Case on Input and Output................................5		2.4 Original DNS Label Types...............................5
	5. Security Considerations.................................6		3. Additional DNS Case Insensitivity Considerations........5
			3.1 CLASS Case Insensitivity Considerations................5
			3.2 Extended Label Type Case Insensitivity Considerations..5
			4. Case on Input and Output................................6
			4.1 DNS Output Case Preservation...........................6
			4.2 DNS Input Case Preservation............................6
			4.3 Wildcard Matching......................................7
			5. Security Considerations.................................7
	Normative References.......................................7		Normative References.......................................9
	Informative References.....................................7		Informative References.....................................9
	Author's Address...........................................8		Author's Address..........................................10
	Expiration and File Name...................................8		Expiration and File Name..................................10
	INTERNET-DRAFT DNS Case Insensitivity		INTERNET-DRAFT DNS Case Insensitivity
	1. Introduction		1. Introduction
	The Domain Name System (DNS) is the global hierarchical replicated		The Domain Name System (DNS) is the global hierarchical replicated
	distributed database system for Internet addressing, mail proxy, and		distributed database system for Internet addressing, mail proxy, and
	other information. Each node in the DNS tree has a name consisting of		other information. Each node in the DNS tree has a name consisting of
	zero or more labels [STD 13][RFC 1591, 2606] which have always been		zero or more labels [STD 13][RFC 1591, 2606] which have been
	specified as being treated in a case insensitive fashion. This		specified as being treated in a case insensitive fashion. This
	document clarifies the meaning of "case insensitive" for this		document clarifies the meaning of "case insensitive" for this
	application.		application.
	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. Case Insensitivity of DNS Labels		2. Case Insensitivity of DNS Labels
	skipping to change at page 3, line 40		skipping to change at page 3, line 40
	www.gnu.ai.mit.edu.		www.gnu.ai.mit.edu.
	or 69.2.0.192.in-addr.arpa.		or 69.2.0.192.in-addr.arpa.
	Case varied alternatives to the above would be DNS names like		Case varied alternatives to the above would be DNS names like
	Foo.ExamplE.net.		Foo.ExamplE.net.
	AOL.COM.		AOL.COM.
	WWW.gnu.AI.mit.EDU.		WWW.gnu.AI.mit.EDU.
	or 69.2.0.192.in-ADDR.ARPA.		or 69.2.0.192.in-ADDR.ARPA.
	The individual bytes of which DNS names consist are not limited to		The individual octets of which DNS names consist are not limited to
	valid ASCII character codes. They are defined as 8-bit bytes and all		valid ASCII character codes. They are defined as 8-bit bytes and all
	values are allowed. It is just that they are traditionally interpreted		values are allowed. Most applications, however, interprete them
	as ASCII characters.		as ASCII characters.
	The typographic convention for bytes that do not correspond to an		2.1 Escaping Unusual DNS Label Octets
	ASCII printing graphic is to show them as a back-slash followed by
	three hex digits for the value of the byte as an unsigned		An escape is needed for all octet values outside of the inclusive
	integer. This includes all byte values outside of the inclusive range		range of 0x21 ("!") to 0x7E ("~"). That is to say, all octet values in
	of 0x21 ("!") to 0x7E ("~"). That is to say, all byte values in the		the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF.
	two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF. The same
	convention can be used for the back-slash character and the special		One typographic convention for octets that do not correspond to an
	label separator period ("."). A period can also be protected from		ASCII printing graphic is to show them as a back-slash followed by the
	recognition as a separator, so that it will be treated as a normal
	label character, by preceeding it with a back-slash. The first example
	INTERNET-DRAFT DNS Case Insensitivity		INTERNET-DRAFT DNS Case Insensitivity
	below shows embedded spaces and a period (".") within a label. The		value of the octet as an unsigned integer represented by exactly three
	second one show a 4 byte label where the second byte has all bits zero		decimal digits. The same convention can be used for printing ASCII
	and the third byte has all bits one.		characters. This includes the back-slash character used in this
			convention itself and the special label separator period (".") which
			can be expressed as \092 and \046 respectively.
	Donald\040E\.\040Eastlake\0403rd.example.		A back-slash followed by only one or two decimal digits is
	or a\000\377z.example.		undefined. A back-slash followed by four decimal digits produces two
			octets, the first octet having the value of the first three digits
			considered as a decimal number and the second octet being the
			character code for the fourth decimal digit.
			Octets, other than those corresponding to the ASCII digits 0 through
			9, can also be protected from recognition, so that they will be
			treated as a normal label character, by a second convention:
			preceding them with a back-slash. This is the most commonly used
			technique for protecting back slash ("\") and period ("."). However,
			it is advisable to avoid using this on other than printing ASCII
			characters.
			2.2 Example Labels with Escapes
			The first example below shows embedded spaces and a period (".")
			within a label. The second one show a 4 octet label where the second
			octet has all bits zero and the third octet has all bits one.
			Donald\032E\.\032Eastlake\0323rd.example.
			or a\000\255z.example.
			2.3 Name Lookup Case Insensitivity
	The design decision was made that comparisons on name lookup for DNS		The design decision was made that comparisons on name lookup for DNS
	queries should be case insensitive [STD 13]. That is to say, a lookup		queries should be case insensitive [STD 13]. That is to say, a lookup
	string byte with a value in the inclusive range of 0x41 to 0x5A, the		string octet with a value in the inclusive range of 0x41 to 0x5A, the
	upper case ASCII letters, MUST match the identical value and also		upper case ASCII letters, MUST match the identical value and also
	match the corresponding value in the inclusive range 0x61 to 0x7A,		match the corresponding value in the inclusive range 0x61 to 0x7A,
	the lower case ASCII letters. And a lookup string byte with a lower		the lower case ASCII letters. And a lookup string octet with a lower
	case ASCII letter value MUST similarly match the identical value and		case ASCII letter value MUST similarly match the identical value and
	also match the corresponding value in the upper case ASCII letter		also match the corresponding value in the upper case ASCII letter
	range. One way to implement this rule would be, when comparing bytes,		range.
	to subtract 0x20 from all bytes in the inclusive range 0x61 to 0x7A
			(Historical Note: the terms "upper case" and "lower case" were
			invented after movable type became wide spread for printing. The
			terms originally referred to the two font trays for storing, in
			partitioned areas, the different physical type elements. Before
			movable type, the nearest equivalent terms were "majuscule" and
			INTERNET-DRAFT DNS Case Insensitivity
			"minuscule".)
			One way to implement this rule would be, when comparing octets, to
			subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A
	before the comparison. Such an operation is commonly known as "case		before the comparison. Such an operation is commonly known as "case
	folding".		folding" but implementation via case folding is not required. Note
			that the DNS case insensitivity does NOT correspond to the case
			folding specified in iso-8859-1 or iso-8859-2. For example, the
			octets 0xDD (\221) and 0xFD (\253) do NOT match although in other
			contexts where they are interpreted as the upper and lower case
			version of "Y" with an acute accent, they might.
	(Historic Note: the terms "upper case" and "lower case" were invented		2.4 Original DNS Label Types
	after movable type became wide spread for printing. The terms
	originally refered to the two font trays for storing, in partitioned
	areas, the different physical type elements. Before movable type,
	the nearest equivalent terms were "majuscule" and "minuscule".)
	DNS labels in wire encoded names have a type associated with them.		DNS labels in wire encoded names have a type associated with them.
	The original DNS standard [RFC 1035] had only two types. ASCII		The original DNS standard [RFC 1035] had only two types. ASCII
	labels, with a length of from zero to 63 bytes and indirect labels		labels, with a length of from zero to 63 octets and indirect labels
	which consist of an offset pointer to a name location elsewhere in		which consist of an offset pointer to a name location elsewhere in
	the wire encoding. (The ASCII label of length zero is reserved for		the wire encoding on a DNS message. (The ASCII label of length zero
	use as the name of the root node of the name tree.) ASCII labels		is reserved for use as the name of the root node of the name tree.)
	follow the ASCII case conventions described above. Indirect labels		ASCII labels follow the ASCII case conventions described above.
	are, in effect, replaced by the name to which they point which is		Indirect labels are, in effect, replaced by the name to which they
	then treated with the case insensitivity rules in this document.		point which is then treated with the case insensitivity rules in this
			document.
	3. Additional DNS Case Insensitivity Considerations		3. Additional DNS Case Insensitivity Considerations
	This section clarifies the effect of DNS CLASS and extended Label		This section clarifies the effect of DNS CLASS and extended Label
	Type on case insensitivity.		Type on case insensitivity.
	3.1 CLASS Case Insensitivity Considerations		3.1 CLASS Case Insensitivity Considerations
	As described in [STD 13] and [RFC 2929], DNS has an additional axis		As described in [STD 13] and [RFC 2929], DNS has an additional axis
	for data location called CLASS. The only CLASS in global use at this		for data location called CLASS. The only CLASS in global use at this
	time is the "IN" or Internet CLASS.		time is the "IN" or Internet CLASS.
	INTERNET-DRAFT DNS Case Insensitivity
	The handling of DNS label case is not CLASS dependent.		The handling of DNS label case is not CLASS dependent.
	3.2 Label Type Case Insensitivity Considerations		3.2 Extended Label Type Case Insensitivity Considerations
	DNS was extended by [RFC 2671] to have additional label type numbers		DNS was extended by [RFC 2671] to have additional label type numbers
	available. (The only such type defined so far it the BINARY type [RFC		available. (The only such type defined so far it the BINARY type [RFC
			INTERNET-DRAFT DNS Case Insensitivity
	2673].)		2673].)
	The ASCII case insensitivity conventions, or case folding, only apply		The ASCII case insensitivity conventions, or case folding, only apply
	to ASCII labels, that is to say, label type 0x0, whether appearing		to ASCII labels, that is to say, label type 0x0, whether appearing
	directly or invoked by indirect labels.		directly or invoked by indirect labels.
	4. Case on Input and Output		4. Case on Input and Output
	While ASCII label comparisons are case insensitive, case MUST be		While ASCII label comparisons are case insensitive, case MUST be
	preserved on output, except when output is optimized by the use of		preserved on output, except when output is optimized by the use of
	indirect labels, and preserved when possible on input.		indirect labels, and preserved when possible on input.
			4.1 DNS Output Case Preservation
	[STD 13] views the DNS namespace as a node tree. ASCII output is as		[STD 13] views the DNS namespace as a node tree. ASCII output is as
	if a name was marshalled by taking the label on the node whose name		if a name was marshalled by taking the label on the node whose name
	is to be output, converting it to a typographicly encoded ASCII		is to be output, converting it to a typographically encoded ASCII
	string, walking up the tree outputting each label encountered, and		string, walking up the tree outputting each label encountered, and
	preceeding all labels but the first with a period ("."). Wire output		preceding all labels but the first with a period ("."). Wire output
	follows the same sequence but each label is wire encoded and no		follows the same sequence but each label is wire encoded and no
	periods inserted. No "case conversion" or "case folding" is done		periods inserted. No "case conversion" or "case folding" is done
	during such output operations. However, to optimize output, indirect		during such output operations. However, to optimize output, indirect
	labels may be used to point to names elsewhere in the DNS answer. In		labels may be used to point to names elsewhere in the DNS answer. In
	determining whether the name to be pointed to is the "same" as the		determining whether the name to be pointed to is the "same" as the
	remainder of the name being optimized, the case insensitive		remainder of the name being optimized, the case insensitive
	comparison specified above is done. Thus such optimization MAY		comparison specified above is done. Thus such optimization MAY
	destroy the output preservation of case. This type of optimization is		destroy the output preservation of case. This type of optimization is
	commonly called "name compression".		commonly called "name compression".
			4.2 DNS Input Case Preservation
	Originally, DNS input came from an ASCII Master File as defined in		Originally, DNS input came from an ASCII Master File as defined in
	[STD 13]. DNS Dynamic update has been added as a source of DNS data		[STD 13]. DNS Dynamic update has been added as a source of DNS data
	[RFC 2136, 3007]. When a node in the DNS name tree is created by such		[RFC 2136, 3007]. When a node in the DNS name tree is created by such
	input, no case conversion is done and the case of ASCII labels is		input, no case conversion is done and the case of ASCII labels is
	preserved if they are for nodes being creted. However, no change is		preserved if they are for nodes being creted. However, no change is
	made in the name label on nodes that already exist is the DNS data		made in the name label on nodes that already exist is the DNS data
	being augmented or updated. It is quite common for higher level nodes		being augmented or updated. It is quite common for higher level nodes
	to already exist. For example, if data with owner name		to already exist.
	"foo.bar.example" is input and then later data with owner name
	"xyz.BAR.example" is input, the name of the label on the		For example, if data with owner name "foo.bar.example" is input and
	"bar.example" node, i.e. "bar", is not changed to "BAR". Thus later		then later data with owner name "xyz.BAR.example" is input, the name
	retrieval of data stored under "xyz.bar.example" in this case can		of the label on the "bar.example" node, i.e. "bar", is not changed to
	easily result is obtaining data with "xyz.BAR.example".		"BAR". Thus later retrieval of data stored under "xyz.bar.example" in
	INTERNET-DRAFT DNS Case Insensitivity		INTERNET-DRAFT DNS Case Insensitivity
			this case can easily result is obtaining data with "xyz.BAR.example".
			The same considerations apply inputting multiple data records with
			owner names differing only in case. From the example above, if an "A"
			record is stored under owner name "xyz.BAR.example" and then a second
			"A" record under "XYZ.BAR.example", the second will be stored at the
			node with the first (lower case initial label) name.
	Note that the order of insertion into a server database of the DNS		Note that the order of insertion into a server database of the DNS
	name tree nodes that appear in a Master File is not defined so that		name tree nodes that appear in a Master File is not defined so that
	the results of inconsistent capitalization in a Master File are		the results of inconsistent capitalization in a Master File are
	unpredicatable output capitalization.		unpredicatable output capitalization.
	There is one additional instance of note, which relfects the general		4.3 Wildcard Matching
			There is one additional instance of note, which reflects the general
	rules that output case reflects input case unless there is		rules that output case reflects input case unless there is
	conflicting capitalization in the DNS database or the output case is		conflicting capitalization in the DNS database or the output case is
	hidden by name compression. This is when a query matches a wild card		hidden by name compression. This is when a query matches a wild card
	in the DNS database at a server. In that case, the answer SHOULD		in the DNS database at a server. In that case, the answer SHOULD
	reflect the input case of the label or labels that matched the		reflect the input case of the label or labels that matched the
	wildcard unless they are replaced by an indirect label which MAY		wildcard unless they are replaced by an indirect label which MAY
	point to a name with different captialization.		point to a name with different capitalization.
	5. Security Considerations		5. Security Considerations
	The equivalence of certain DNS label types with case differences, as		The equivalence of certain DNS label types with case differences, as
	clarified in this document, can lead to security problems. For		clarified in this document, can lead to security problems. For
	example, a user could be confused by believing two domain names		example, a user could be confused by believing two domain names
	differing only in case were actually different names.		differing only in case were actually different names.
	Furthermore, a domain name may be used in contexts other than the		Furthermore, a domain name may be used in contexts other than the
	DNS. It could be used as an index into some case sensitive data base		DNS. It could be used as an index into some case sensitive data base
	system. Or it could be interpreted as binary data by some integrity		system. Or it could be interpreted as binary data by some integrity
	or authentication code system. These problems can usually be handled		or authentication code system. These problems can usually be handled
	by using a standardized or "canonical" form of the DNS ASCII type		by using a standardized or "canonical" form of the DNS ASCII type
	labels, that is, always map the ASCII letter value octets in ASCII		labels, that is, always map the ASCII letter value octets in ASCII
	labels to some specific pre-chosen case, either upper case or lower		labels to some specific pre-chosen case, either upper case or lower
	case. An example of a canonical form for domain names (and also a		case. An example of a canonical form for domain names (and also a
	canonical ordering for them) appears in Section 8 of [RFC 2535]. See		canonical ordering for them) appears in Section 8 of [RFC 2535]. See
	also [UNKRR].		also [UNKRR].
			Finally, a non-DNS name may be stored into DNS with the false
			expectation that case will always be preserved. For example, although
			this would be quite rare, on a system with case sensitive email
			address local parts, an attempt to store two "RP" records that
			differed only in case would probably produce unexpected results that
			INTERNET-DRAFT DNS Case Insensitivity
			might have security implications. That is because the entire email
			address, including the possibly case sensitive local or left hand
			part, is encoded into a DNS name in a readable fashion where the case
			of some letters might be changed on output as described above.
	INTERNET-DRAFT DNS Case Insensitivity		INTERNET-DRAFT DNS Case Insensitivity
	Normative References		Normative References
	[ASCII] - ANSI, "USA Standard Code for Information Interchange",		[ASCII] - ANSI, "USA Standard Code for Information Interchange",
	X3.4, American National Standards Institute: New York, 1968.		X3.4, American National Standards Institute: New York, 1968.
	[RFC 1034, 1035] - See [STD 13].		[RFC 1034, 1035] - See [STD 13].
	[RFC 2119] - "Key words for use in RFCs to Indicate Requirement		[RFC 2119] - "Key words for use in RFCs to Indicate Requirement
	skipping to change at page 8, line 20		skipping to change at page 10, line 20
	Motorola Laboratories		Motorola Laboratories
	155 Beaver Street		155 Beaver Street
	Milford, MA 01757 USA		Milford, MA 01757 USA
	Telephone: +1 508-851-8280 (w)		Telephone: +1 508-851-8280 (w)
	+1 508-634-2066 (h)		+1 508-634-2066 (h)
	EMail: Donald.Eastlake@motorola.com		EMail: Donald.Eastlake@motorola.com
	Expiration and File Name		Expiration and File Name
	This draft expires July 2003.		This draft expires August 2003.
	Its file name is draft-ietf-dnsext-insensitive-00.txt.		Its file name is draft-ietf-dnsext-insensitive-01.txt.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/