INTERNET-DRAFT Donald E. Eastlake 3rd
Clarifies STD0013 Motorola Laboratories
-Expires August 2003 February 2003
+Expires September 2003 April 2003
Domain Name System (DNS) Case Insensitivity Clarification
------ ---- ------ ----- ---- ------------- -------------
- <draft-ietf-dnsext-insensitive-02.txt>
+ <draft-ietf-dnsext-insensitive-03.txt>
Donald E. Eastlake 3rd
-Copyright (C) 2003 The Internet Society. All Rights Reserved.
+
Acknowledgements
The contributions to this document of Rob Austein, Olafur
- Gudmundsson, Daniel J. Anderson, Alan Barrett, Dana, Andrew Main, and
- Scott Seligman are gratefully acknowledged.
+ Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
+ Andreas Gustafsson, Andrew Main, and Scott Seligman are gratefully
+ acknowledged.
4.1 DNS Output Case Preservation...........................6
4.2 DNS Input Case Preservation............................6
4.3 Wildcard Matching......................................7
- 5. Security Considerations.................................7
+ 5. Internationalized Domain Names..........................7
+ 6. Security Considerations.................................7
Normative References.......................................9
Informative References.....................................9
-
+ -02 to -03 Changes........................................10
Author's Address..........................................10
Expiration and File Name..................................10
-
-
D. Eastlake 3rd [Page 2]
\f
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
other information. Each node in the DNS tree has a name consisting of
- zero or more labels [STD 13][RFC 1591, 2606] which have been
- specified as being treated in a case insensitive fashion. This
- document clarifies the meaning of "case insensitive" for this
- application.
+ zero or more labels [STD 13][RFC 1591, 2606] that are treated in a
+ case insensitive fashion. This document clarifies the meaning of
+ "case insensitive" for the DNS.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
DNS was specified in the era of [ASCII]. DNS names were expected to
look like most host names or Internet email address right halves (the
- part after the at-sign ("@")) or be numeric as in the in-addr.arpa
+ part after the at-sign, "@") or be numeric as in the in-addr.arpa
part of the DNS name space. For example,
foo.example.net.
or 69.2.0.192.in-ADDR.ARPA.
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
- values are allowed. Most applications, however, interprete them
- as ASCII characters.
+ valid ASCII character codes. They are as 8-bit bytes and all values
+ are allowed. Many applications, however, interprete them as ASCII
+ characters.
2.1 Escaping Unusual DNS Label Octets
- An escape is needed for all octet values outside of the inclusive
- range of 0x21 ("!") to 0x7E ("~"). That is to say, all octet values in
- the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF.
+ In Master Files [STD 13] and other human readable and writable ASCII
+ contexts, an escape is needed for the byte value for period (0x2E,
+ ".") and all octet values outside of the inclusive range of 0x21 ("!")
+ to 0x7E ("~"). That is to say, 0x2E and all octet values in the two
+ inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF.
One typographic convention for octets that do not correspond to an
- ASCII printing graphic is to show them as a back-slash followed by the
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT DNS Case Insensitivity
- value of the octet as an unsigned integer represented by exactly three
- decimal digits. The same convention can be used for printing ASCII
- 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.
+ ASCII printing graphic is to use a back-slash followed by the value of
+ the octet as an unsigned integer represented by exactly three decimal
+ digits.
+
+ The same convention can be used for printing ASCII characters so that
+ they will be treated as a normal label character. 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. It is advisable to avoid using a backslash to quote an
+ immediately following non-printing ASCII character code to avoid
+ implementation difficulties.
A back-slash followed by only one or two decimal digits is
undefined. A back-slash followed by four decimal digits produces two
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 to avoid implementation difficulties.
-
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.
+ within a label. The second one show a 5 octet label where the second
+ octet has all bits zero, the third is a backslahs,
+ and the fourth octet has all bits one.
- Donald\032E\.\032Eastlake\0323rd.example.
- or a\000\255z.example.
+ Donald\032E\.\032Eastlake\0323rd.example.
+ and a\000\\\255z.example.
range.
(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
+ invented after movable type. 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 "minuscule".)
+
D. Eastlake 3rd [Page 4]
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
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
+ contexts, where they are interpreted as the upper and lower case
version of "Y" with an acute accent, they might.
DNS was extended by [RFC 2671] to have additional label type numbers
available. (The only such type defined so far is the BINARY type [RFC
+ 2673].)
+
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT DNS Case Insensitivity
- 2673].)
-
The ASCII case insensitivity conventions, or case folding, only apply
to ASCII labels, that is to say, label type 0x0, whether appearing
directly or invoked by indirect labels.
While ASCII label comparisons are case insensitive, case MUST be
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 convenient on input.
[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
input, no case conversion is done and the case of ASCII labels is
- preserved if they are for nodes being created. However, no change is
- made in the name label on nodes that already exist in the DNS data
- being augmented or updated. It is quite common for higher level nodes
- to already exist.
+ preserved if they are for nodes being created. However, when a name
+ label is input for a node that already exist in DNS data being
+ augmented or updated, the situation is more complex. Implemenations
+ may retain the case first input for such a label or allow new input
+ to override the old case or maintain separate copies preserving the
+ input case.
For example, if data with owner name "foo.bar.example" is input and
then later data with owner name "xyz.BAR.example" is input, the name
- of the label on the "bar.example" node, i.e. "bar", is not changed to
- "BAR". Thus later retrieval of data stored under "xyz.bar.example" in
+ of the label on the "bar.example" node, i.e. "bar", might or might
+ not be changed to "BAR" or the actual input case could be preserved.
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT DNS Case Insensitivity
- this case can easily result is obtaining data with "xyz.BAR.example".
- The same considerations apply when 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.
+ Thus later retrieval of data stored under "xyz.bar.example" in this
+ case can easily result is obtaining data with "xyz.BAR.example". The
+ same considerations apply when 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 MAY be stored with the
+ first (lower case initial label) name.
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
-5. Security Considerations
+5. Internationalized Domain Names
+
+ A scheme has been adopted for "internationalized domain names" and
+ "internationalized labels" as described in [RFC 3490, 3454, 3491, and
+ 3492]. It makes most of [UNICODE] available through a separate
+ application level transformation from internationalized domain name
+ to DNS domain name and from DNS domain name to internationalized
+ domain name. Any case insensitivity that internationalized domain
+ names and labels have varies depending on the script and is handled
+ entirely as part of the transformation described in [RFC 3454] and
+ [RFC 3491] which should be seen for further details. This is not a
+ part of the DNS as standardized in STD 13.
+
+
+
+6. Security Considerations
The equivalence of certain DNS label types with case differences, as
clarified in this document, can lead to security problems. For
example, a user could be confused by believing two domain names
differing only in case were actually different names.
+
+
+D. Eastlake 3rd [Page 7]
+\f
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
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 a case sensitive index into some data base
system. Or it could be interpreted as binary data by some integrity
or authentication code system. These problems can usually be handled
by using a standardized or "canonical" form of the DNS ASCII type
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
-
-
-D. Eastlake 3rd [Page 7]
-\f
-
-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
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
specification", RFC 1035, November 1987.
[UNKRR] - Andreas Gustafsson, "Handling of Unknown DNS RR Types",
- draft-ietf-dnsext-unknown-rrs-04.txt, September 2002.
+ draft-ietf-dnsext-unknown-rrs-05.txt, March 2003.
[RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
August 1999.
-
-
+ [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of
+ Internationalized String ("stringprep")", December 2002.
INTERNET-DRAFT DNS Case Insensitivity
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1 508-851-8280 (w)
- +1 508-634-2066 (h)
- EMail: Donald.Eastlake@motorola.com
-
-
-
-
-Expiration and File Name
-
- This draft expires August 2003.
-
- Its file name is draft-ietf-dnsext-insensitive-02.txt.
-
-
-
-
-
-
-
-
+ [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,
+ "Internationalizing Domain Names in Applications (IDNA)", March 2003.
+ [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
+ for Internationalized Domain Names (IDN)", March 2003.
+ [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode
+ for Internationalized Domain Names in Applications (IDNA)", March
+ 2003.
+ [UNICODE] - The Unicode Consortium, "The Unicode Standard",
+ <http://www.unicode.org/unicode/standard/standard.html>.
+-02 to -03 Changes
+ The following changes were made between draft version -02 and -03:
+ 1. Add internationalized domain name section and references.
+ 2. Change to indicate that later input of a label for an existing DNS
+ name tree node may or may not be normalized to the earlier input or
+ override it or both may be preserved.
+ 3. Numerous minor wording changes.
+Author's Address
+ Donald E. Eastlake 3rd
+ Motorola Laboratories
+ 155 Beaver Street
+ Milford, MA 01757 USA
+ Telephone: +1 508-851-8280 (w)
+ +1 508-634-2066 (h)
+ EMail: Donald.Eastlake@motorola.com
+Expiration and File Name
+ This draft expires September 2003.
+ Its file name is draft-ietf-dnsext-insensitive-03.txt.
projects / thirdparty / bind9.git / commitdiff
