--- 1/draft-ietf-dnsext-insensitive-04.txt 2006-02-04 23:10:47.000000000 +0100 +++ 2/draft-ietf-dnsext-insensitive-05.txt 2006-02-04 23:10:47.000000000 +0100 @@ -1,103 +1,109 @@ INTERNET-DRAFT Donald E. Eastlake 3rd -Clarifies STD0013 Motorola Laboratories -Expires December 2004 July 2004 +Updates RFC 1034, 1035 Motorola Laboratories +Expires July 2005 January 2005 Domain Name System (DNS) Case Insensitivity Clarification ------ ---- ------ ----- ---- ------------- ------------- - + Donald E. Eastlake 3rd Status of This Document By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. + or will be disclosed, and any of which I become aware will be + disclosed, in accordance with RFC 3668. Distribution of this document is unlimited. Comments should be sent to the DNSEXT working group at namedroppers@ops.ietf.org. - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC 2026. 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 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 as "work in progress." + 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/ietf/1id-abstracts.txt. The list of Internet- - Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. + 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. 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 should not have any interoperability - consequences. + of the rules. This clarification updates RFCs 1034 and 1035. 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, and Scott Seligman are gratefully - acknowledged. + 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.................................7 - Copyright and Disclaimer...................................9 + Full Copyright Notice and Disclaimer.......................9 Normative References.......................................9 Informative References....................................10 -02 to -03 Changes........................................10 -03 to -04 Changes........................................11 + -04 to -05 Changes........................................11 Author's Address..........................................11 - Expiration and File Name..................................11 + Expiration and File Name..................................12 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. + "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 @@ -121,24 +127,23 @@ 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. - One typographic convention for octets that do not correspond to an - 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 @@ -147,60 +152,61 @@ 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 + 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 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. + The design decision was made that comparisons on name lookup for all + 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 - terms were "majuscule" and "minuscule".) 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 + 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. + 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 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. @@ -239,21 +245,21 @@ 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 + 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 input 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 @@ -325,24 +331,24 @@ 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. INTERNET-DRAFT DNS Case Insensitivity -Copyright and Disclaimer +Full Copyright Notice and Disclaimer - Copyright (C) The Internet Society 2004. This document is subject to - the rights, licenses and restrictions contained in BCP 78, and except + 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. @@ -374,20 +380,26 @@ [STD 13] - P. Mockapetris, "Domain names - concepts and facilities", RFC 1034, November 1987. - P. Mockapetris, "Domain names - implementation and specification", RFC 1035, November 1987. 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 @@ -414,49 +426,62 @@ [UNICODE] - The Unicode Consortium, "The Unicode Standard", . -02 to -03 Changes The following changes were made between draft version -02 and -03: 1. Add internationalized domain name section and references. +INTERNET-DRAFT DNS Case Insensitivity + 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. -INTERNET-DRAFT DNS Case Insensitivity - -03 to -04 Changes - The following changes were made between draft version -03 and -04: + 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. + Author's Address Donald E. Eastlake 3rd Motorola Laboratories 155 Beaver Street Milford, MA 01757 USA Telephone: +1 508-786-7554 (w) +1 508-634-2066 (h) EMail: Donald.Eastlake@motorola.com +INTERNET-DRAFT DNS Case Insensitivity + Expiration and File Name - This draft expires December 2004. + This draft expires July 2005. - Its file name is draft-ietf-dnsext-insensitive-04.txt. + Its file name is draft-ietf-dnsext-insensitive-05.txt.