diff --git a/doc/draft/draft-ietf-dnsext-insensitive-06.txt b/doc/draft/draft-ietf-dnsext-insensitive-06.txt deleted file mode 100644 index 1c4c3f635e..0000000000 --- a/doc/draft/draft-ietf-dnsext-insensitive-06.txt +++ /dev/null @@ -1,754 +0,0 @@ - -INTERNET-DRAFT Donald E. Eastlake 3rd -Updates RFC 1034, 1035 Motorola Laboratories -Expires January 2006 July 2005 - - - - Domain Name System (DNS) Case Insensitivity Clarification - ------ ---- ------ ----- ---- ------------- ------------- - - - 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] - - -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] - - -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] - - -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] - - -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] - - -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] - - -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] - - -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] - - -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] - - -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", - . - - - - - - - -D. Eastlake 3rd [Page 10] - - -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] - - -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] - - -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] - diff --git a/doc/rfc/index b/doc/rfc/index index c12bc81c95..4eb3530338 100644 --- a/doc/rfc/index +++ b/doc/rfc/index @@ -103,3 +103,4 @@ 4159: Deprecation of "ip6.int" 4193: Unique Local IPv6 Unicast Addresses 4255: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints +4343: Domain Name System (DNS) Case Insensitivity Clarification diff --git a/doc/rfc/rfc4343.txt b/doc/rfc/rfc4343.txt new file mode 100644 index 0000000000..621420a45f --- /dev/null +++ b/doc/rfc/rfc4343.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group D. Eastlake 3rd +Request for Comments: 4343 Motorola Laboratories +Updates: 1034, 1035, 2181 January 2006 +Category: Standards Track + + + Domain Name System (DNS) Case Insensitivity Clarification + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +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, 1035, and 2181. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Case Insensitivity of DNS Labels ................................2 + 2.1. Escaping Unusual DNS Label Octets ..........................2 + 2.2. Example Labels with Escapes ................................3 + 3. Name Lookup, Label Types, and CLASS .............................3 + 3.1. Original DNS Label Types ...................................4 + 3.2. Extended Label Type Case Insensitivity Considerations ......4 + 3.3. CLASS Case Insensitivity Considerations ....................4 + 4. Case on Input and Output ........................................5 + 4.1. DNS Output Case Preservation ...............................5 + 4.2. DNS Input Case Preservation ................................5 + 5. Internationalized Domain Names ..................................6 + 6. Security Considerations .........................................6 + 7. Acknowledgements ................................................7 + Normative References................................................7 + Informative References..............................................8 + + + + + + + +Eastlake 3rd Standards Track [Page 1] + +RFC 4343 DNS Case Insensitivity Clarification January 2006 + + +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 [STD13, RFC1591, RFC2606] that are treated in + a case insensitive fashion. This document clarifies the meaning of + "case insensitive" for the DNS. This clarification updates RFCs + 1034, 1035 [STD13], and [RFC2181]. + + 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 [RFC2119]. + +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 to 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 [RFC3092] 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 [STD13] 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 from 0x21 + ("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in + the two inclusive ranges from 0x00 to 0x20 and from 0x7F to 0xFF. + + + + + +Eastlake 3rd Standards Track [Page 2] + +RFC 4343 DNS Case Insensitivity Clarification January 2006 + + + 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 \. 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 shows 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 + + According to the original DNS design decision, comparisons on name + lookup for DNS queries should be case insensitive [STD13]. That is + to say, a lookup string octet with a value in the inclusive range + from 0x41 to 0x5A, the uppercase ASCII letters, MUST match the + identical value and also match the corresponding value in the + inclusive range from 0x61 to 0x7A, the lowercase ASCII letters. A + lookup string octet with a lowercase ASCII letter value MUST + similarly match the identical value and also match the corresponding + value in the uppercase ASCII letter range. + + (Historical note: The terms "uppercase" and "lowercase" 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".) + + + + + +Eastlake 3rd Standards Track [Page 3] + +RFC 4343 DNS Case Insensitivity Clarification January 2006 + + + One way to implement this rule would be to subtract 0x20 from all + octets in the inclusive range from 0x61 to 0x7A before comparing + octets. 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 [STD13] had only two types: ASCII labels, + with a length 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 [RFC2671] so that additional label type numbers + would be available. (The only such type defined so far is the BINARY + type [RFC2673], which is now Experimental [RFC3363].) + + 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 [STD13] and [RFC2929], DNS has an additional axis for + data location called CLASS. The only CLASS in global use at this + time is the "IN" (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 + 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 desirable, for example, to allocate + a CLASS with "case sensitive ASCII labels", it would be necessary to + allocate a new label type for these labels. + + + + +Eastlake 3rd Standards Track [Page 4] + +RFC 4343 DNS Case Insensitivity Clarification January 2006 + + +4. Case on Input and Output + + While ASCII label comparisons are case insensitive, [STD13] 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 + + [STD13] views the DNS namespace as a node tree. ASCII output is as + if a name were 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 are 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 + [STD13] or a zone transfer. DNS Dynamic update and incremental zone + transfers [RFC1995] have been added as a source of DNS data [RFC2136, + RFC3007]. 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 exists in DNS data being + held, the situation is more complex. Implementations are free to + retain the case first loaded for such a label, to allow new input to + override the old case, or even to maintain separate copies preserving + the input case. + + For example, if data with owner name "foo.bar.example" [RFC3092] 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. Thus, + later retrieval of data stored under "xyz.bar.example" in this case + can use "xyz.BAR.example" in all returned data, use "xyz.bar.example" + in all returned data, or even, when more than one RR is being + returned, use a mixture of these two capitalizations. This last case + + + +Eastlake 3rd Standards Track [Page 5] + +RFC 4343 DNS Case Insensitivity Clarification January 2006 + + + is unlikely, as optimization of answer length through indirect labels + tends to cause only one 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 or 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 resource 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, the second MAY override the first so that + only an uppercase 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 [RFC3490, RFC3454, + RFC3491, and RFC3492]. 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 [RFC3454] and [RFC3491], 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 that 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 database + 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 + + + +Eastlake 3rd Standards Track [Page 6] + +RFC 4343 DNS Case Insensitivity Clarification January 2006 + + + ASCII type labels; that is, always mapping the ASCII letter value + octets in ASCII labels to some specific pre-chosen case, either + uppercase or lower case. An example of a canonical form for domain + names (and also a canonical ordering for them) appears in Section 6 + of [RFC4034]. See also [RFC3597]. + + 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 Responsible Person + (RP) [RFC1183] 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. + +7. Acknowledgements + + The contributions to this document by Rob Austein, Olafur + Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana, + Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman + are gratefully acknowledged. + +Normative References + + [ASCII] ANSI, "USA Standard Code for Information Interchange", + X3.4, American National Standards Institute: New York, + 1968. + + [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, + August 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS + UPDATE)", RFC 2136, April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + + + + + +Eastlake 3rd Standards Track [Page 7] + +RFC 4343 DNS Case Insensitivity Clarification January 2006 + + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security + Extensions", RFC 4034, March 2005. + + [STD13] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. + + Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + +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. + + [RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P. + Mockapetris, "New DNS RR Definitions", RFC 1183, October + 1990. + + [RFC1591] Postel, J., "Domain Name System Structure and + Delegation", RFC 1591, March 1994. + + [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS + Names", BCP 32, RFC 2606, June 1999. + + [RFC2929] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, + "Domain Name System (DNS) IANA Considerations", BCP 42, + RFC 2929, September 2000. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", + RFC 2673, August 1999. + + [RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology + of "Foo"", RFC 3092, 1 April 2001. + + [RFC3363] 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. + + + +Eastlake 3rd Standards Track [Page 8] + +RFC 4343 DNS Case Insensitivity Clarification January 2006 + + + [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of + Internationalized Strings ("stringprep")", RFC 3454, + December 2002. + + [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, + "Internationalizing Domain Names in Applications + (IDNA)", RFC 3490, March 2003. + + [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep + Profile for Internationalized Domain Names (IDN)", RFC + 3491, March 2003. + + [RFC3492] Costello, A., "Punycode: A Bootstring encoding of + Unicode for Internationalized Domain Names in + Applications (IDNA)", RFC 3492, March 2003. + + [UNICODE] The Unicode Consortium, "The Unicode Standard", + . + +Author's Address + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Phone: +1 508-786-7554 (w) + EMail: Donald.Eastlake@motorola.com + + + + + + + + + + + + + + + + + + + + + + + +Eastlake 3rd Standards Track [Page 9] + +RFC 4343 DNS Case Insensitivity Clarification January 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Eastlake 3rd Standards Track [Page 10] +