-\r
-INTERNET-DRAFT Donald E. Eastlake 3rd\r
-Updates RFC 1034, 1035 Motorola Laboratories\r
-Expires July 2005 January 2005\r
-\r
-\r
-\r
- Domain Name System (DNS) Case Insensitivity Clarification\r
- ------ ---- ------ ----- ---- ------------- -------------\r
- <draft-ietf-dnsext-insensitive-05.txt>\r
-\r
- Donald E. Eastlake 3rd\r
-\r
-\r
-\r
-Status of This Document\r
-\r
- By submitting this Internet-Draft, I certify that any applicable\r
- patent or other IPR claims of which I am aware have been disclosed,\r
- or will be disclosed, and any of which I become aware will be\r
- disclosed, in accordance with RFC 3668.\r
-\r
- Distribution of this document is unlimited. Comments should be sent\r
- to the DNSEXT working group at namedroppers@ops.ietf.org.\r
-\r
- Internet-Drafts are working documents of the Internet Engineering\r
- Task Force (IETF), its areas, and its working groups. Note that\r
- other groups may also distribute working documents as Internet-\r
- Drafts.\r
-\r
- Internet-Drafts are draft documents valid for a maximum of six months\r
- and may be updated, replaced, or obsoleted by other documents at any\r
- time. It is inappropriate to use Internet-Drafts as reference\r
- material or to cite them other than a "work in progress."\r
-\r
- The list of current Internet-Drafts can be accessed at\r
- http://www.ietf.org/1id-abstracts.html\r
-\r
- The list of Internet-Draft Shadow Directories can be accessed at\r
- http://www.ietf.org/shadow.html\r
-\r
-\r
-\r
-Copyright Notice\r
-\r
- Copyright (C) The Internet Society. All Rights Reserved.\r
-\r
-\r
-\r
-Abstract\r
-\r
- Domain Name System (DNS) names are "case insensitive". This document\r
- explains exactly what that means and provides a clear specification\r
- of the rules. This clarification updates RFCs 1034 and 1035.\r
-\r
-\r
-D. Eastlake 3rd [Page 1]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
-Acknowledgements\r
-\r
- The contributions to this document of Rob Austein, Olafur\r
- Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,\r
- Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman\r
- are gratefully acknowledged.\r
-\r
-\r
-\r
-Table of Contents\r
-\r
- Status of This Document....................................1\r
- Copyright Notice...........................................1\r
- Abstract...................................................1\r
-\r
- Acknowledgements...........................................2\r
- Table of Contents..........................................2\r
-\r
- 1. Introduction............................................3\r
- 2. Case Insensitivity of DNS Labels........................3\r
- 2.1 Escaping Unusual DNS Label Octets......................3\r
- 2.2 Example Labels with Escapes............................4\r
- 3. Name Lookup, Label Types, and CLASS.....................4\r
- 3.1 Original DNS Label Types...............................5\r
- 3.2 Extended Label Type Case Insensitivity Considerations..5\r
- 3.3 CLASS Case Insensitivity Considerations................5\r
- 4. Case on Input and Output................................6\r
- 4.1 DNS Output Case Preservation...........................6\r
- 4.2 DNS Input Case Preservation............................6\r
- 5. Internationalized Domain Names..........................7\r
- 6. Security Considerations.................................7\r
-\r
- Full Copyright Notice and Disclaimer.......................9\r
- Normative References.......................................9\r
- Informative References....................................10\r
- -02 to -03 Changes........................................10\r
- -03 to -04 Changes........................................11\r
- -04 to -05 Changes........................................11\r
- Author's Address..........................................11\r
- Expiration and File Name..................................12\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-D. Eastlake 3rd [Page 2]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
-1. Introduction\r
-\r
- The Domain Name System (DNS) is the global hierarchical replicated\r
- distributed database system for Internet addressing, mail proxy, and\r
- other information. Each node in the DNS tree has a name consisting of\r
- zero or more labels [STD 13][RFC 1591, 2606] that are treated in a\r
- case insensitive fashion. This document clarifies the meaning of\r
- "case insensitive" for the DNS. This clarification updates RFCs 1034\r
- and 1035 [STD 13].\r
-\r
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",\r
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this\r
- document are to be interpreted as described in [RFC 2119].\r
-\r
-\r
-\r
-2. Case Insensitivity of DNS Labels\r
-\r
- DNS was specified in the era of [ASCII]. DNS names were expected to\r
- look like most host names or Internet email address right halves (the\r
- part after the at-sign, "@") or be numeric as in the in-addr.arpa\r
- part of the DNS name space. For example,\r
-\r
- foo.example.net.\r
- aol.com.\r
- www.gnu.ai.mit.edu.\r
- or 69.2.0.192.in-addr.arpa.\r
-\r
- Case varied alternatives to the above would be DNS names like\r
-\r
- Foo.ExamplE.net.\r
- AOL.COM.\r
- WWW.gnu.AI.mit.EDU.\r
- or 69.2.0.192.in-ADDR.ARPA.\r
-\r
- However, the individual octets of which DNS names consist are not\r
- limited to valid ASCII character codes. They are 8-bit bytes and all\r
- values are allowed. Many applications, however, interpret them as\r
- ASCII characters.\r
-\r
-\r
-\r
-2.1 Escaping Unusual DNS Label Octets\r
-\r
- In Master Files [STD 13] and other human readable and writable ASCII\r
- contexts, an escape is needed for the byte value for period (0x2E,\r
- ".") and all octet values outside of the inclusive range of 0x21\r
- ("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in\r
- the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF.\r
-\r
-\r
-\r
-D. Eastlake 3rd [Page 3]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
- One typographic convention for octets that do not correspond to an\r
- ASCII printing graphic is to use a back-slash followed by the value\r
- of the octet as an unsigned integer represented by exactly three\r
- decimal digits.\r
-\r
- The same convention can be used for printing ASCII characters so that\r
- they will be treated as a normal label character. This includes the\r
- back-slash character used in this convention itself which can be\r
- expressed as \092 or \\ and the special label separator period (".")\r
- which can be expressed as and \046 or \. respectively. It is\r
- advisable to avoid using a backslash to quote an immediately\r
- following non-printing ASCII character code to avoid implementation\r
- difficulties.\r
-\r
- A back-slash followed by only one or two decimal digits is undefined.\r
- A back-slash followed by four decimal digits produces two octets, the\r
- first octet having the value of the first three digits considered as\r
- a decimal number and the second octet being the character code for\r
- the fourth decimal digit.\r
-\r
-\r
-\r
-2.2 Example Labels with Escapes\r
-\r
- The first example below shows embedded spaces and a period (".")\r
- within a label. The second one show a 5-octet label where the second\r
- octet has all bits zero, the third is a backslash, and the fourth\r
- octet has all bits one.\r
-\r
- Donald\032E\.\032Eastlake\0323rd.example.\r
- and a\000\\\255z.example.\r
-\r
-\r
-\r
-3. Name Lookup, Label Types, and CLASS\r
-\r
- The design decision was made that comparisons on name lookup for all\r
- DNS queries should be case insensitive [STD 13]. That is to say, a\r
- lookup string octet with a value in the inclusive range of 0x41 to\r
- 0x5A, the upper case ASCII letters, MUST match the identical value\r
- and also match the corresponding value in the inclusive range 0x61 to\r
- 0x7A, the lower case ASCII letters. And a lookup string octet with a\r
- lower case ASCII letter value MUST similarly match the identical\r
- value and also match the corresponding value in the upper case ASCII\r
- letter range.\r
-\r
- (Historical Note: the terms "upper case" and "lower case" were\r
- invented after movable type. The terms originally referred to the\r
- two font trays for storing, in partitioned areas, the different\r
- physical type elements. Before movable type, the nearest equivalent\r
-\r
-\r
-D. Eastlake 3rd [Page 4]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
- terms were "majuscule" and "minuscule".)\r
-\r
- One way to implement this rule would be, when comparing octets, to\r
- subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A\r
- before the comparison. Such an operation is commonly known as "case\r
- folding" but implementation via case folding is not required. Note\r
- that the DNS case insensitivity does NOT correspond to the case\r
- folding specified in [iso-8859-1] or [iso-8859-2]. For example, the\r
- octets 0xDD (\221) and 0xFD (\253) do NOT match although in other\r
- contexts, where they are interpreted as the upper and lower case\r
- version of "Y" with an acute accent, they might.\r
-\r
-\r
-\r
-3.1 Original DNS Label Types\r
-\r
- DNS labels in wire-encoded names have a type associated with them.\r
- The original DNS standard [RFC 1035] had only two types. ASCII\r
- labels, with a length of from zero to 63 octets, and indirect labels\r
- which consist of an offset pointer to a name location elsewhere in\r
- the wire encoding on a DNS message. (The ASCII label of length zero\r
- is reserved for use as the name of the root node of the name tree.)\r
- ASCII labels follow the ASCII case conventions described herein and,\r
- as stated above, can actually contain arbitrary byte values. Indirect\r
- labels are, in effect, replaced by the name to which they point which\r
- is then treated with the case insensitivity rules in this document.\r
-\r
-\r
-\r
-3.2 Extended Label Type Case Insensitivity Considerations\r
-\r
- DNS was extended by [RFC 2671] to have additional label type numbers\r
- available. (The only such type defined so far is the BINARY type [RFC\r
- 2673].)\r
-\r
- The ASCII case insensitivity conventions only apply to ASCII labels,\r
- that is to say, label type 0x0, whether appearing directly or invoked\r
- by indirect labels.\r
-\r
-\r
-\r
-3.3 CLASS Case Insensitivity Considerations\r
-\r
- As described in [STD 13] and [RFC 2929], DNS has an additional axis\r
- for data location called CLASS. The only CLASS in global use at this\r
- time is the "IN" or Internet CLASS.\r
-\r
- The handling of DNS label case is not CLASS dependent.\r
-\r
-\r
-\r
-\r
-D. Eastlake 3rd [Page 5]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
-4. Case on Input and Output\r
-\r
- While ASCII label comparisons are case insensitive, [STD 13] says\r
- case MUST be preserved on output, and preserved when convenient on\r
- input. However, this means less than it would appear since the\r
- preservation of case on output is NOT required when output is\r
- optimized by the use of indirect labels, as explained below.\r
-\r
-\r
-\r
-4.1 DNS Output Case Preservation\r
-\r
- [STD 13] views the DNS namespace as a node tree. ASCII output is as\r
- if a name was marshaled by taking the label on the node whose name is\r
- to be output, converting it to a typographically encoded ASCII\r
- string, walking up the tree outputting each label encountered, and\r
- preceding all labels but the first with a period ("."). Wire output\r
- follows the same sequence but each label is wire encoded and no\r
- periods inserted. No "case conversion" or "case folding" is done\r
- during such output operations, thus "preserving" case. However, to\r
- optimize output, indirect labels may be used to point to names\r
- elsewhere in the DNS answer. In determining whether the name to be\r
- pointed to, for example the QNAME, is the "same" as the remainder of\r
- the name being optimized, the case insensitive comparison specified\r
- above is done. Thus such optimization may easily destroy the output\r
- preservation of case. This type of optimization is commonly called\r
- "name compression".\r
-\r
-\r
-\r
-4.2 DNS Input Case Preservation\r
-\r
- Originally, DNS input came from an ASCII Master File as defined in\r
- [STD 13] or a zone transfer. DNS Dynamic update and incremental zone\r
- transfers [RFC 1995] have been added as a source of DNS data [RFC\r
- 2136, 3007]. When a node in the DNS name tree is created by any of\r
- such inputs, no case conversion is done. Thus the case of ASCII\r
- labels is preserved if they are for nodes being created. However,\r
- when a name label is input for a node that already exist in DNS data\r
- being held, the situation is more complex. Implementations may retain\r
- the case first input for such a label or allow new input to override\r
- the old case or even maintain separate copies preserving the input\r
- case.\r
-\r
- For example, if data with owner name "foo.bar.example" is input and\r
- then later data with owner name "xyz.BAR.example" is input, the name\r
- of the label on the "bar.example" node, i.e. "bar", might or might\r
- not be changed to "BAR" or the actual input case could be preserved.\r
- Thus later retrieval of data stored under "xyz.bar.example" in this\r
- case can easily return data with "xyz.BAR.example". The same\r
-\r
-\r
-D. Eastlake 3rd [Page 6]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
- considerations apply when inputting multiple data records with owner\r
- names differing only in case. For example, if an "A" record is stored\r
- as the first resourced record under owner name "xyz.BAR.example" and\r
- then a second "A" record is stored under "XYZ.BAR.example", the\r
- second MAY be stored with the first (lower case initial label) name\r
- or the second MAY override the first so that only an upper case\r
- initial label is retained or both capitalizations MAY be kept.\r
-\r
- Note that the order of insertion into a server database of the DNS\r
- name tree nodes that appear in a Master File is not defined so that\r
- the results of inconsistent capitalization in a Master File are\r
- unpredictable output capitalization.\r
-\r
-\r
-\r
-5. Internationalized Domain Names\r
-\r
- A scheme has been adopted for "internationalized domain names" and\r
- "internationalized labels" as described in [RFC 3490, 3454, 3491, and\r
- 3492]. It makes most of [UNICODE] available through a separate\r
- application level transformation from internationalized domain name\r
- to DNS domain name and from DNS domain name to internationalized\r
- domain name. Any case insensitivity that internationalized domain\r
- names and labels have varies depending on the script and is handled\r
- entirely as part of the transformation described in [RFC 3454] and\r
- [RFC 3491] which should be seen for further details. This is not a\r
- part of the DNS as standardized in STD 13.\r
-\r
-\r
-\r
-6. Security Considerations\r
-\r
- The equivalence of certain DNS label types with case differences, as\r
- clarified in this document, can lead to security problems. For\r
- example, a user could be confused by believing two domain names\r
- differing only in case were actually different names.\r
-\r
- Furthermore, a domain name may be used in contexts other than the\r
- DNS. It could be used as a case sensitive index into some data base\r
- system. Or it could be interpreted as binary data by some integrity\r
- or authentication code system. These problems can usually be handled\r
- by using a standardized or "canonical" form of the DNS ASCII type\r
- labels, that is, always mapping the ASCII letter value octets in\r
- ASCII labels to some specific pre-chosen case, either upper case or\r
- lower case. An example of a canonical form for domain names (and also\r
- a canonical ordering for them) appears in Section 8 of [RFC 2535].\r
- See also [RFC 3597].\r
-\r
- Finally, a non-DNS name may be stored into DNS with the false\r
- expectation that case will always be preserved. For example, although\r
-\r
-\r
-D. Eastlake 3rd [Page 7]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
- this would be quite rare, on a system with case sensitive email\r
- address local parts, an attempt to store two "RP" records that\r
- differed only in case would probably produce unexpected results that\r
- might have security implications. That is because the entire email\r
- address, including the possibly case sensitive local or left hand\r
- part, is encoded into a DNS name in a readable fashion where the case\r
- of some letters might be changed on output as described above.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-D. Eastlake 3rd [Page 8]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
-Full Copyright Notice and Disclaimer\r
-\r
- Copyright (C) The Internet Society 2005. This document is subject to\r
- the rights, licenses and restrictions contained in BCP 78 and except\r
- as set forth therein, the authors retain all their rights.\r
-\r
-\r
- This document and the information contained herein are provided on an\r
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS\r
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET\r
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,\r
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE\r
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED\r
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
-\r
-\r
-\r
-Normative References\r
-\r
- [ASCII] - ANSI, "USA Standard Code for Information Interchange",\r
- X3.4, American National Standards Institute: New York, 1968.\r
-\r
- [RFC 1034, 1035] - See [STD 13].\r
-\r
- [RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August\r
- 1996.\r
-\r
- [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate\r
- Requirement Levels", March 1997.\r
-\r
- [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,\r
- "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997.\r
-\r
- [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",\r
- March 1999.\r
-\r
- [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic\r
- Update", November 2000.\r
-\r
- [RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types",\r
- draft-ietf-dnsext-unknown-rrs-05.txt, March 2003.\r
-\r
- [STD 13]\r
- - P. Mockapetris, "Domain names - concepts and facilities", RFC\r
- 1034, November 1987.\r
- - P. Mockapetris, "Domain names - implementation and\r
- specification", RFC 1035, November 1987.\r
-\r
-\r
-\r
-\r
-\r
-D. Eastlake 3rd [Page 9]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
-Informative References\r
-\r
- [ISO 8859-1] - International Standards Organization, Standard for\r
- Character Encodings, Latin-1.\r
-\r
- [ISO 8859-2] - International Standards Organization, Standard for\r
- Character Encodings, Latin-2.\r
-\r
- [RFC 1591] - J. Postel, "Domain Name System Structure and\r
- Delegation", March 1994.\r
-\r
- [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",\r
- June 1999.\r
-\r
- [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain\r
- Name System (DNS) IANA Considerations", September 2000.\r
-\r
- [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August\r
- 1999.\r
-\r
- [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",\r
- August 1999.\r
-\r
- [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of\r
- Foo", 1 April 2001.\r
-\r
- [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of\r
- Internationalized String ("stringprep")", December 2002.\r
-\r
- [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,\r
- "Internationalizing Domain Names in Applications (IDNA)", March 2003.\r
-\r
- [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile\r
- for Internationalized Domain Names (IDN)", March 2003.\r
-\r
- [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode\r
- for Internationalized Domain Names in Applications (IDNA)", March\r
- 2003.\r
-\r
- [UNICODE] - The Unicode Consortium, "The Unicode Standard",\r
- <http://www.unicode.org/unicode/standard/standard.html>.\r
-\r
-\r
-\r
--02 to -03 Changes\r
-\r
- The following changes were made between draft version -02 and -03:\r
-\r
- 1. Add internationalized domain name section and references.\r
-\r
-\r
-\r
-D. Eastlake 3rd [Page 10]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
- 2. Change to indicate that later input of a label for an existing DNS\r
- name tree node may or may not be normalized to the earlier input or\r
- override it or both may be preserved.\r
-\r
- 3. Numerous minor wording changes.\r
-\r
-\r
-\r
--03 to -04 Changes\r
-\r
- The following changes were made between draft versions -03 and -04:\r
-\r
- 1. Change to conform to the new IPR, Copyright, etc., notice\r
- requirements.\r
-\r
- 2. Change in some section headers for clarity.\r
-\r
- 3. Drop section on wildcards.\r
-\r
- 4. Add emphasis on loss of case preservation due to name compression.\r
-\r
- 5. Add references to RFCs 1995 and 3092.\r
-\r
-\r
-\r
--04 to -05 Changes\r
-\r
- The following changes were made between draft versions -04 and -05:\r
-\r
- 1. More clearly state that this draft updates RFCs 1034, 1035 [STD\r
- 13].\r
-\r
- 2. Add informative references to ISO 8859-1 and ISO 8859-2.\r
-\r
- 3. Fix hyphenation and capitalization nits.\r
-\r
-\r
-\r
-Author's Address\r
-\r
- Donald E. Eastlake 3rd\r
- Motorola Laboratories\r
- 155 Beaver Street\r
- Milford, MA 01757 USA\r
-\r
- Telephone: +1 508-786-7554 (w)\r
- +1 508-634-2066 (h)\r
- EMail: Donald.Eastlake@motorola.com\r
-\r
-\r
-\r
-\r
-D. Eastlake 3rd [Page 11]\r
-\f\r
-\r
-INTERNET-DRAFT DNS Case Insensitivity\r
-\r
-\r
-Expiration and File Name\r
-\r
- This draft expires July 2005.\r
-\r
- Its file name is draft-ietf-dnsext-insensitive-05.txt.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-D. Eastlake 3rd [Page 12]\r
-\f\r
-\r
+
+INTERNET-DRAFT Donald E. Eastlake 3rd
+Updates RFC 1034, 1035 Motorola Laboratories
+Expires January 2006 July 2005
+
+
+
+ Domain Name System (DNS) Case Insensitivity Clarification
+ ------ ---- ------ ----- ---- ------------- -------------
+ <draft-ietf-dnsext-insensitive-06.txt>
+
+ Donald E. Eastlake 3rd
+
+
+
+Status of This Document
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Distribution of this document is unlimited. Comments should be sent
+ to the DNSEXT working group at namedroppers@ops.ietf.org.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than a "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+
+
+Abstract
+
+ Domain Name System (DNS) names are "case insensitive". This document
+ explains exactly what that means and provides a clear specification
+ of the rules. This clarification updates RFCs 1034 and 1035.
+
+
+D. Eastlake 3rd [Page 1]
+\f
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+Acknowledgements
+
+ The contributions to this document of Rob Austein, Olafur
+ Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
+ Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman
+ are gratefully acknowledged.
+
+
+
+Table of Contents
+
+ Status of This Document....................................1
+ Copyright Notice...........................................1
+ Abstract...................................................1
+
+ Acknowledgements...........................................2
+ Table of Contents..........................................2
+
+ 1. Introduction............................................3
+ 2. Case Insensitivity of DNS Labels........................3
+ 2.1 Escaping Unusual DNS Label Octets......................3
+ 2.2 Example Labels with Escapes............................4
+ 3. Name Lookup, Label Types, and CLASS.....................4
+ 3.1 Original DNS Label Types...............................5
+ 3.2 Extended Label Type Case Insensitivity Considerations..5
+ 3.3 CLASS 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
+ 5. Internationalized Domain Names..........................7
+ 6. Security Considerations.................................8
+
+ Copyright and Disclaimer...................................9
+ Normative References.......................................9
+ Informative References....................................10
+
+ Changes Between Draft Version.............................11
+ -02 to -03 Changes........................................11
+ -03 to -04 Changes........................................11
+ -04 to -05 Changes........................................11
+ -05 to -06 Changes........................................12
+
+ Author's Address..........................................13
+ Expiration and File Name..................................13
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 2]
+\f
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+1. Introduction
+
+ 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] that are treated in a
+ case insensitive fashion. This document clarifies the meaning of
+ "case insensitive" for the DNS. This clarification updates RFCs 1034
+ and 1035 [STD 13].
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC 2119].
+
+
+
+2. Case Insensitivity of DNS Labels
+
+ 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 of the DNS name space. For example,
+
+ foo.example.net.
+ aol.com.
+ www.gnu.ai.mit.edu.
+ or 69.2.0.192.in-addr.arpa.
+
+ Case varied alternatives to the above would be DNS names like
+
+ Foo.ExamplE.net.
+ AOL.COM.
+ WWW.gnu.AI.mit.EDU.
+ or 69.2.0.192.in-ADDR.ARPA.
+
+ However, the individual octets of which DNS names consist are not
+ limited to valid ASCII character codes. They are 8-bit bytes and all
+ values are allowed. Many applications, however, interpret them as
+ ASCII characters.
+
+
+
+2.1 Escaping Unusual DNS Label Octets
+
+ 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.
+
+
+
+D. Eastlake 3rd [Page 3]
+\f
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+ One typographic convention for octets that do not correspond to an
+ 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 which can be
+ expressed as \092 or \\ and the special label separator period (".")
+ which can be expressed as and \046 or \. 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 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.
+
+
+
+2.2 Example Labels with Escapes
+
+ The first example below shows embedded spaces and a period (".")
+ within a label. The second one show a 5-octet label where the second
+ octet has all bits zero, the third is a backslash, and the fourth
+ octet has all bits one.
+
+ Donald\032E\.\032Eastlake\0323rd.example.
+ and a\000\\\255z.example.
+
+
+
+3. Name Lookup, Label Types, and CLASS
+
+ The original DNS design decision was made that comparisons on name
+ lookup for DNS queries should be case insensitive [STD 13]. That is
+ to say, a lookup 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 match the corresponding value in the inclusive range
+ 0x61 to 0x7A, the lower case ASCII letters. And a lookup string octet
+ with a lower case ASCII letter value MUST similarly match the
+ identical value and also match the corresponding value in the upper
+ case ASCII letter range.
+
+ (Historical Note: the terms "upper case" and "lower case" were
+ 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
+
+
+D. Eastlake 3rd [Page 4]
+\f
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+ terms were "majuscule" and "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
+ 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.
+
+
+
+3.1 Original DNS Label Types
+
+ DNS labels in wire-encoded names have a type associated with them.
+ The original DNS standard [RFC 1035] had only two types. ASCII
+ labels, with a length of from zero to 63 octets, and indirect (or
+ compression) labels which consist of an offset pointer to a name
+ location elsewhere in the wire encoding on a DNS message. (The ASCII
+ label of length zero is reserved for use as the name of the root node
+ of the name tree.) ASCII labels follow the ASCII case conventions
+ described herein and, as stated above, can actually contain arbitrary
+ byte values. Indirect labels are, in effect, replaced by the name to
+ which they point which is then treated with the case insensitivity
+ rules in this document.
+
+
+
+3.2 Extended Label Type Case Insensitivity Considerations
+
+ 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] which is now Experimental [RFC 3363].)
+
+ The ASCII case insensitivity conventions only apply to ASCII labels,
+ that is to say, label type 0x0, whether appearing directly or invoked
+ by indirect labels.
+
+
+
+3.3 CLASS Case Insensitivity Considerations
+
+ 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
+ time is the "IN" or Internet CLASS.
+
+ The handling of DNS label case is not CLASS dependent. With the
+ original design of DNS, it was intended that a recursive DNS resolver
+
+
+D. Eastlake 3rd [Page 5]
+\f
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+ be able to handle new CLASSes that were unknown at the time of its
+ implementation. This requires uniform handling of label case
+ insensitivity. Should it become desireable, for example, to allocate
+ a CLASS with "case sensitive ASCII labels" for example, it would be
+ necessary to allocate a new label type for these labels.
+
+
+
+4. Case on Input and Output
+
+ While ASCII label comparisons are case insensitive, [STD 13] says
+ case MUST be preserved on output, and preserved when convenient on
+ input. However, this means less than it would appear since the
+ preservation of case on output is NOT required when output is
+ optimized by the use of indirect labels, as explained below.
+
+
+
+4.1 DNS Output Case Preservation
+
+ [STD 13] views the DNS namespace as a node tree. ASCII output is as
+ if a name was marshaled by taking the label on the node whose name is
+ to be output, converting it to a typographically encoded ASCII
+ string, walking up the tree outputting each label encountered, and
+ preceding all labels but the first with a period ("."). Wire output
+ follows the same sequence but each label is wire encoded and no
+ periods inserted. No "case conversion" or "case folding" is done
+ during such output operations, thus "preserving" case. However, to
+ optimize output, indirect labels may be used to point to names
+ elsewhere in the DNS answer. In determining whether the name to be
+ pointed to, for example the QNAME, is the "same" as the remainder of
+ the name being optimized, the case insensitive comparison specified
+ above is done. Thus such optimization may easily destroy the output
+ preservation of case. This type of optimization is commonly called
+ "name compression".
+
+
+
+4.2 DNS Input Case Preservation
+
+ Originally, DNS data came from an ASCII Master File as defined in
+ [STD 13] or a zone transfer. DNS Dynamic update and incremental zone
+ transfers [RFC 1995] have been added as a source of DNS data [RFC
+ 2136, 3007]. When a node in the DNS name tree is created by any of
+ such inputs, no case conversion is done. Thus the case of ASCII
+ labels is 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 held, the situation is more complex. Implementations are free
+ to retain the case first loaded for such a label or allow new input
+ to override the old case or even maintain separate copies preserving
+
+
+D. Eastlake 3rd [Page 6]
+\f
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+ the input case.
+
+ For example, if data with owner name "foo.bar.example" is loaded 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", might or might
+ not be changed to "BAR" in the DNS stored data or the actual input
+ case could be preserved. Thus later retrieval of data stored under
+ "xyz.bar.example" in this case can return all data with
+ "xyz.BAR.example" or all data with "xyz.bar.example" or even, when
+ more than one RR is being returned, a mixture of these two cases.
+ This last case is unlikely because optimization of answer length
+ through indirect labels tends to cause only copy of the name tail
+ ("bar.example" or "BAR.example") to be used for all returned RRs.
+ Note that none of this has any effect on the number of completeness
+ of the RR set returned, only on the case of the names in the RR set
+ returned.
+
+ The same considerations apply when inputting multiple data records
+ with owner names differing only in case. For example, if an "A"
+ record is the first resourced record stored under owner name
+ "xyz.BAR.example" and then a second "A" record is stored under
+ "XYZ.BAR.example", the second MAY be stored with the first (lower
+ case initial label) name or the second MAY override the first so that
+ only an upper case initial label is retained or both capitalizations
+ MAY be kept in the DNS stored data. In any case, a retrieval with
+ either capitalization will retrieve all RRs with either
+ capitalization.
+
+ 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
+ the results of inconsistent capitalization in a Master File are
+ unpredictable output capitalization.
+
+
+
+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.
+
+
+
+
+
+D. Eastlake 3rd [Page 7]
+\f
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+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.
+
+ Furthermore, a domain name may be used in contexts other than the
+ DNS. It could be used as a case sensitive index into some data base
+ or file 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 labels, that is, always mapping the ASCII letter value
+ octets in ASCII 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 canonical ordering for them) appears in Section 6 of [RFC
+ 4034]. See also [RFC 3597].
+
+ 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
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 8]
+\f
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+Copyright and Disclaimer
+
+ Copyright (C) The Internet Society (2005). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+Normative References
+
+ [ASCII] - ANSI, "USA Standard Code for Information Interchange",
+ X3.4, American National Standards Institute: New York, 1968.
+
+ [RFC 1034, 1035] - See [STD 13].
+
+ [RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August
+ 1996.
+
+ [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
+ Requirement Levels", March 1997.
+
+ [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
+ "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997.
+
+ [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic
+ Update", November 2000.
+
+ [RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types",
+ draft-ietf-dnsext-unknown-rrs-05.txt, March 2003.
+
+ [RFC 4034} - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
+ March 2005.
+
+ [STD 13]
+ - P. Mockapetris, "Domain names - concepts and facilities", RFC
+ 1034, November 1987.
+ - P. Mockapetris, "Domain names - implementation and
+ specification", RFC 1035, November 1987.
+
+
+
+
+D. Eastlake 3rd [Page 9]
+\f
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+Informative References
+
+ [ISO 8859-1] - International Standards Organization, Standard for
+ Character Encodings, Latin-1.
+
+ [ISO 8859-2] - International Standards Organization, Standard for
+ Character Encodings, Latin-2.
+
+ [RFC 1591] - J. Postel, "Domain Name System Structure and
+ Delegation", March 1994.
+
+ [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
+ June 1999.
+
+ [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain
+ Name System (DNS) IANA Considerations", September 2000.
+
+ [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
+ 1999.
+
+ [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
+ August 1999.
+
+ [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of
+ Foo", 1 April 2001.
+
+ [RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
+ Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
+ the Domain Name System (DNS)", RFC 3363, August 2002.
+
+ [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of
+ Internationalized String ("stringprep")", December 2002.
+
+ [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>.
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 10]
+\f
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+Changes Between Draft Version
+
+ RFC Editor: The following summaries of changes between draft versions
+ are to be removed before publication.
+
+
+
+-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.
+
+
+
+-03 to -04 Changes
+
+ The following changes were made between draft versions -03 and -04:
+
+ 1. Change to conform to the new IPR, Copyright, etc., notice
+ requirements.
+
+ 2. Change in some section headers for clarity.
+
+ 3. Drop section on wildcards.
+
+ 4. Add emphasis on loss of case preservation due to name compression.
+
+ 5. Add references to RFCs 1995 and 3092.
+
+
+
+-04 to -05 Changes
+
+ The following changes were made between draft versions -04 and -05:
+
+ 1. More clearly state that this draft updates RFCs 1034, 1035 [STD
+ 13].
+
+ 2. Add informative references to ISO 8859-1 and ISO 8859-2.
+
+ 3. Fix hyphenation and capitalization nits.
+
+
+
+
+D. Eastlake 3rd [Page 11]
+\f
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+-05 to -06 Changes
+
+ The following changes were made between draft version -05 and -06.
+
+ 1. Add notation to the RFC Editor that the draft version change
+ summaries are to be removed before RFC publication.
+
+ 2. Additional text explaining why labe case insensitivity is CLASS
+ independent.
+
+ 3. Changes and additional text clarifying that the fact that
+ inconsistent case in data loaded into DNS may result in
+ unpredicatable or inconsistent case in DNS storage but has no effect
+ on the completeness of RR sets retrieved.
+
+ 4. Add reference to [RFC 3363] and update reference to [RFC 2535] to
+ be to [RFC 4034].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 12]
+\f
+
+INTERNET-DRAFT DNS Case Insensitivity
+
+
+Author's Address
+
+ Donald E. Eastlake 3rd
+ Motorola Laboratories
+ 155 Beaver Street
+ Milford, MA 01757 USA
+
+ Telephone: +1 508-786-7554 (w)
+
+ EMail: Donald.Eastlake@motorola.com
+
+
+
+Expiration and File Name
+
+ This draft expires January 2006.
+
+ Its file name is draft-ietf-dnsext-insensitive-06.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 13]
+\f
projects / thirdparty / bind9.git / commitdiff
