idnits 2.17.1 draft-ietf-dnsext-insensitive-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 326. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 154 has weird spacing: '... and a\000...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2004) is 7197 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '2606' is mentioned on line 86, but not defined == Missing Reference: 'RFC 1035' is mentioned on line 186, but not defined == Unused Reference: 'RFC 1034' is defined on line 333, but no explicit reference was found in the text == Unused Reference: '1035' is defined on line 333, but no explicit reference was found in the text == Unused Reference: 'RFC 2136' is defined on line 341, but no explicit reference was found in the text == Unused Reference: 'RFC 3007' is defined on line 347, but no explicit reference was found in the text == Unused Reference: 'RFC 2606' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'RFC 2673' is defined on line 373, but no explicit reference was found in the text == Unused Reference: 'RFC 3092' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'RFC 3490' is defined on line 382, but no explicit reference was found in the text == Unused Reference: 'RFC 3492' is defined on line 388, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' -- Duplicate reference: RFC1034, mentioned in '1035', was also mentioned in 'RFC 1034'. ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-06) exists of draft-ietf-dnsext-unknown-rrs-05 -- Obsolete informational reference (is this intentional?): RFC 2929 (Obsoleted by RFC 5395) -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 2673 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 3454 (Obsoleted by RFC 7564) -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 3491 (Obsoleted by RFC 5891) Summary: 12 errors (**), 0 flaws (~~), 17 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald E. Eastlake 3rd 2 Clarifies STD0013 Motorola Laboratories 3 Expires December 2004 July 2004 5 Domain Name System (DNS) Case Insensitivity Clarification 6 ------ ---- ------ ----- ---- ------------- ------------- 7 9 Donald E. Eastlake 3rd 11 Status of This Document 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 18 Distribution of this document is unlimited. Comments should be sent 19 to the DNSEXT working group at namedroppers@ops.ietf.org. 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC 2026. Internet-Drafts are 23 working documents of the Internet Engineering Task Force (IETF), its 24 areas, and its working groups. Note that other groups may also 25 distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 34 Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 Domain Name System (DNS) names are "case insensitive". This document 40 explains exactly what that means and provides a clear specification 41 of the rules. This clarification should not have any interoperability 42 consequences. 44 Acknowledgements 46 The contributions to this document of Rob Austein, Olafur 47 Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana, 48 Andreas Gustafsson, Andrew Main, and Scott Seligman are gratefully 49 acknowledged. 51 Table of Contents 53 Status of This Document....................................1 54 Abstract...................................................1 56 Acknowledgements...........................................2 57 Table of Contents..........................................2 59 1. Introduction............................................3 60 2. Case Insensitivity of DNS Labels........................3 61 2.1 Escaping Unusual DNS Label Octets......................3 62 2.2 Example Labels with Escapes............................4 63 3. Name Lookup, Label Types, and CLASS.....................4 64 3.1 Original DNS Label Types...............................5 65 3.2 Extended Label Type Case Insensitivity Considerations..5 66 3.3 CLASS Case Insensitivity Considerations................5 67 4. Case on Input and Output................................6 68 4.1 DNS Output Case Preservation...........................6 69 4.2 DNS Input Case Preservation............................6 70 5. Internationalized Domain Names..........................7 71 6. Security Considerations.................................7 73 Copyright and Disclaimer...................................9 74 Normative References.......................................9 75 Informative References....................................10 76 -02 to -03 Changes........................................10 77 -03 to -04 Changes........................................11 78 Author's Address..........................................11 79 Expiration and File Name..................................11 81 1. Introduction 83 The Domain Name System (DNS) is the global hierarchical replicated 84 distributed database system for Internet addressing, mail proxy, and 85 other information. Each node in the DNS tree has a name consisting of 86 zero or more labels [STD 13][RFC 1591, 2606] that are treated in a 87 case insensitive fashion. This document clarifies the meaning of 88 "case insensitive" for the DNS. 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC 2119]. 94 2. Case Insensitivity of DNS Labels 96 DNS was specified in the era of [ASCII]. DNS names were expected to 97 look like most host names or Internet email address right halves (the 98 part after the at-sign, "@") or be numeric as in the in-addr.arpa 99 part of the DNS name space. For example, 101 foo.example.net. 102 aol.com. 103 www.gnu.ai.mit.edu. 104 or 69.2.0.192.in-addr.arpa. 106 Case varied alternatives to the above would be DNS names like 108 Foo.ExamplE.net. 109 AOL.COM. 110 WWW.gnu.AI.mit.EDU. 111 or 69.2.0.192.in-ADDR.ARPA. 113 However, the individual octets of which DNS names consist are not 114 limited to valid ASCII character codes. They are 8-bit bytes and all 115 values are allowed. Many applications, however, interpret them as 116 ASCII characters. 118 2.1 Escaping Unusual DNS Label Octets 120 In Master Files [STD 13] and other human readable and writable ASCII 121 contexts, an escape is needed for the byte value for period (0x2E, 122 ".") and all octet values outside of the inclusive range of 0x21 123 ("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in 124 the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF. 126 One typographic convention for octets that do not correspond to an 127 ASCII printing graphic is to use a back-slash followed by the value 128 of the octet as an unsigned integer represented by exactly three 129 decimal digits. 131 The same convention can be used for printing ASCII characters so that 132 they will be treated as a normal label character. This includes the 133 back-slash character used in this convention itself which can be 134 expressed as \092 or \\ and the special label separator period (".") 135 which can be expressed as and \046 or \. respectively. It is 136 advisable to avoid using a backslash to quote an immediately 137 following non-printing ASCII character code to avoid implementation 138 difficulties. 140 A back-slash followed by only one or two decimal digits is undefined. 141 A back-slash followed by four decimal digits produces two octets, the 142 first octet having the value of the first three digits considered as 143 a decimal number and the second octet being the character code for 144 the fourth decimal digit. 146 2.2 Example Labels with Escapes 148 The first example below shows embedded spaces and a period (".") 149 within a label. The second one show a 5 octet label where the second 150 octet has all bits zero, the third is a backslash, and the fourth 151 octet has all bits one. 153 Donald\032E\.\032Eastlake\0323rd.example. 154 and a\000\\\255z.example. 156 3. Name Lookup, Label Types, and CLASS 158 The design decision was made that comparisons on name lookup for DNS 159 queries should be case insensitive [STD 13]. That is to say, a lookup 160 string octet with a value in the inclusive range of 0x41 to 0x5A, the 161 upper case ASCII letters, MUST match the identical value and also 162 match the corresponding value in the inclusive range 0x61 to 0x7A, 163 the lower case ASCII letters. And a lookup string octet with a lower 164 case ASCII letter value MUST similarly match the identical value and 165 also match the corresponding value in the upper case ASCII letter 166 range. 168 (Historical Note: the terms "upper case" and "lower case" were 169 invented after movable type. The terms originally referred to the 170 two font trays for storing, in partitioned areas, the different 171 physical type elements. Before movable type, the nearest equivalent 172 terms were "majuscule" and "minuscule".) 173 One way to implement this rule would be, when comparing octets, to 174 subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A 175 before the comparison. Such an operation is commonly known as "case 176 folding" but implementation via case folding is not required. Note 177 that the DNS case insensitivity does NOT correspond to the case 178 folding specified in iso-8859-1 or iso-8859-2. For example, the 179 octets 0xDD (\221) and 0xFD (\253) do NOT match although in other 180 contexts, where they are interpreted as the upper and lower case 181 version of "Y" with an acute accent, they might. 183 3.1 Original DNS Label Types 185 DNS labels in wire encoded names have a type associated with them. 186 The original DNS standard [RFC 1035] had only two types. ASCII 187 labels, with a length of from zero to 63 octets, and indirect labels 188 which consist of an offset pointer to a name location elsewhere in 189 the wire encoding on a DNS message. (The ASCII label of length zero 190 is reserved for use as the name of the root node of the name tree.) 191 ASCII labels follow the ASCII case conventions described herein and, 192 as stated above, can actually contain arbitrary byte values. Indirect 193 labels are, in effect, replaced by the name to which they point which 194 is then treated with the case insensitivity rules in this document. 196 3.2 Extended Label Type Case Insensitivity Considerations 198 DNS was extended by [RFC 2671] to have additional label type numbers 199 available. (The only such type defined so far is the BINARY type [RFC 200 2673].) 202 The ASCII case insensitivity conventions only apply to ASCII labels, 203 that is to say, label type 0x0, whether appearing directly or invoked 204 by indirect labels. 206 3.3 CLASS Case Insensitivity Considerations 208 As described in [STD 13] and [RFC 2929], DNS has an additional axis 209 for data location called CLASS. The only CLASS in global use at this 210 time is the "IN" or Internet CLASS. 212 The handling of DNS label case is not CLASS dependent. 214 4. Case on Input and Output 216 While ASCII label comparisons are case insensitive, [STD 13] says 217 case MUST be preserved on output, and preserved when convenient on 218 input. However, this means less than it would appear since the 219 preservation of case on output is NOT required when output is 220 optimized by the use of indirect labels, as explained below. 222 4.1 DNS Output Case Preservation 224 [STD 13] views the DNS namespace as a node tree. ASCII output is as 225 if a name was marshaled by taking the label on the node whose name is 226 to be output, converting it to a typographically encoded ASCII 227 string, walking up the tree outputting each label encountered, and 228 preceding all labels but the first with a period ("."). Wire output 229 follows the same sequence but each label is wire encoded and no 230 periods inserted. No "case conversion" or "case folding" is done 231 during such output operations, thus "preserving" case. However, to 232 optimize output, indirect labels may be used to point to names 233 elsewhere in the DNS answer. In determining whether the name to be 234 pointed to, for example the QNAME, is the "same" as the remainder of 235 the name being optimized, the case insensitive comparison specified 236 above is done. Thus such optimization MAY easily destroy the output 237 preservation of case. This type of optimization is commonly called 238 "name compression". 240 4.2 DNS Input Case Preservation 242 Originally, DNS input came from an ASCII Master File as defined in 243 [STD 13] or a zone transfer. DNS Dynamic update and incremental zone 244 transfers [RFC 1995] have been added as a source of DNS data [RFC 245 2136, 3007]. When a node in the DNS name tree is created by any of 246 such inputs, no case conversion is done. Thus the case of ASCII 247 labels is preserved if they are for nodes being created. However, 248 when a name label is input for a node that already exist in DNS data 249 being held, the situation is more complex. Implementations may retain 250 the case first input for such a label or allow new input to override 251 the old case or even maintain separate copies preserving the input 252 case. 254 For example, if data with owner name "foo.bar.example" is input and 255 then later data with owner name "xyz.BAR.example" is input, the name 256 of the label on the "bar.example" node, i.e. "bar", might or might 257 not be changed to "BAR" or the actual input case could be preserved. 258 Thus later retrieval of data stored under "xyz.bar.example" in this 259 case can easily return data with "xyz.BAR.example". The same 260 considerations apply when inputting multiple data records with owner 261 names differing only in case. For example, if an "A" record is stored 262 as the first resourced record under owner name "xyz.BAR.example" and 263 then a second "A" record is stored under "XYZ.BAR.example", the 264 second MAY be stored with the first (lower case initial label) name 265 or the second MAY override the first so that only an upper case 266 initial label is retained or both capitalizations MAY be kept. 268 Note that the order of insertion into a server database of the DNS 269 name tree nodes that appear in a Master File is not defined so that 270 the results of inconsistent capitalization in a Master File are 271 unpredictable output capitalization. 273 5. Internationalized Domain Names 275 A scheme has been adopted for "internationalized domain names" and 276 "internationalized labels" as described in [RFC 3490, 3454, 3491, and 277 3492]. It makes most of [UNICODE] available through a separate 278 application level transformation from internationalized domain name 279 to DNS domain name and from DNS domain name to internationalized 280 domain name. Any case insensitivity that internationalized domain 281 names and labels have varies depending on the script and is handled 282 entirely as part of the transformation described in [RFC 3454] and 283 [RFC 3491] which should be seen for further details. This is not a 284 part of the DNS as standardized in STD 13. 286 6. Security Considerations 288 The equivalence of certain DNS label types with case differences, as 289 clarified in this document, can lead to security problems. For 290 example, a user could be confused by believing two domain names 291 differing only in case were actually different names. 293 Furthermore, a domain name may be used in contexts other than the 294 DNS. It could be used as a case sensitive index into some data base 295 system. Or it could be interpreted as binary data by some integrity 296 or authentication code system. These problems can usually be handled 297 by using a standardized or "canonical" form of the DNS ASCII type 298 labels, that is, always mapping the ASCII letter value octets in 299 ASCII labels to some specific pre-chosen case, either upper case or 300 lower case. An example of a canonical form for domain names (and also 301 a canonical ordering for them) appears in Section 8 of [RFC 2535]. 302 See also [RFC 3597]. 304 Finally, a non-DNS name may be stored into DNS with the false 305 expectation that case will always be preserved. For example, although 306 this would be quite rare, on a system with case sensitive email 307 address local parts, an attempt to store two "RP" records that 308 differed only in case would probably produce unexpected results that 309 might have security implications. That is because the entire email 310 address, including the possibly case sensitive local or left hand 311 part, is encoded into a DNS name in a readable fashion where the case 312 of some letters might be changed on output as described above. 314 Copyright and Disclaimer 316 Copyright (C) The Internet Society 2004. This document is subject to 317 the rights, licenses and restrictions contained in BCP 78, and except 318 as set forth therein, the authors retain all their rights. 320 This document and the information contained herein are provided on an 321 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 322 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 323 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 324 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 325 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 326 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 328 Normative References 330 [ASCII] - ANSI, "USA Standard Code for Information Interchange", 331 X3.4, American National Standards Institute: New York, 1968. 333 [RFC 1034, 1035] - See [STD 13]. 335 [RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August 336 1996. 338 [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate 339 Requirement Levels", March 1997. 341 [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, 342 "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997. 344 [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", 345 March 1999. 347 [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic 348 Update", November 2000. 350 [RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types", 351 draft-ietf-dnsext-unknown-rrs-05.txt, March 2003. 353 [STD 13] 354 - P. Mockapetris, "Domain names - concepts and facilities", RFC 355 1034, November 1987. 356 - P. Mockapetris, "Domain names - implementation and 357 specification", RFC 1035, November 1987. 359 Informative References 361 [RFC 1591] - J. Postel, "Domain Name System Structure and 362 Delegation", March 1994. 364 [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", 365 June 1999. 367 [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain 368 Name System (DNS) IANA Considerations", September 2000. 370 [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August 371 1999. 373 [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System", 374 August 1999. 376 [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of 377 Foo", 1 April 2001. 379 [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of 380 Internationalized String ("stringprep")", December 2002. 382 [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello, 383 "Internationalizing Domain Names in Applications (IDNA)", March 2003. 385 [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile 386 for Internationalized Domain Names (IDN)", March 2003. 388 [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode 389 for Internationalized Domain Names in Applications (IDNA)", March 390 2003. 392 [UNICODE] - The Unicode Consortium, "The Unicode Standard", 393 . 395 -02 to -03 Changes 397 The following changes were made between draft version -02 and -03: 399 1. Add internationalized domain name section and references. 401 2. Change to indicate that later input of a label for an existing DNS 402 name tree node may or may not be normalized to the earlier input or 403 override it or both may be preserved. 405 3. Numerous minor wording changes. 407 -03 to -04 Changes 409 The following changes were made between draft version -03 and -04: 411 1. Change to conform to the new IPR, Copyright, etc., notice 412 requirements. 414 2. Change in some section headers for clarity. 416 3. Drop section on wildcards. 418 4. Add emphasis on loss of case preservation due to name compression. 420 5. Add references to RFCs 1995 and 3092. 422 Author's Address 424 Donald E. Eastlake 3rd 425 Motorola Laboratories 426 155 Beaver Street 427 Milford, MA 01757 USA 429 Telephone: +1 508-786-7554 (w) 430 +1 508-634-2066 (h) 431 EMail: Donald.Eastlake@motorola.com 433 Expiration and File Name 435 This draft expires December 2004. 437 Its file name is draft-ietf-dnsext-insensitive-04.txt.