idnits 2.17.1 draft-ietf-dnsext-insensitive-05.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 334. ** 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. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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. -- The abstract seems to indicate that this document updates RFC1034, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC1035, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 161 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 (January 2005) is 7041 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 92, but not defined == Missing Reference: 'RFC 1035' is mentioned on line 194, but not defined == Unused Reference: 'RFC 1034' is defined on line 341, but no explicit reference was found in the text == Unused Reference: '1035' is defined on line 341, but no explicit reference was found in the text == Unused Reference: 'RFC 2136' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'RFC 3007' is defined on line 355, but no explicit reference was found in the text == Unused Reference: 'ISO 8859-1' is defined on line 369, but no explicit reference was found in the text == Unused Reference: 'ISO 8859-2' is defined on line 372, but no explicit reference was found in the text == Unused Reference: 'RFC 2606' is defined on line 378, but no explicit reference was found in the text == Unused Reference: 'RFC 2673' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'RFC 3092' is defined on line 390, but no explicit reference was found in the text == Unused Reference: 'RFC 3490' is defined on line 396, but no explicit reference was found in the text == Unused Reference: 'RFC 3492' is defined on line 402, 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 (~~), 19 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Donald E. Eastlake 3rd 3 Updates RFC 1034, 1035 Motorola Laboratories 4 Expires July 2005 January 2005 6 Domain Name System (DNS) Case Insensitivity Clarification 7 ------ ---- ------ ----- ---- ------------- ------------- 8 10 Donald E. Eastlake 3rd 12 Status of This Document 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 or will be disclosed, and any of which I become aware will be 17 disclosed, in accordance with RFC 3668. 19 Distribution of this document is unlimited. Comments should be sent 20 to the DNSEXT working group at namedroppers@ops.ietf.org. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 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 a "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright Notice 40 Copyright (C) The Internet Society. All Rights Reserved. 42 Abstract 44 Domain Name System (DNS) names are "case insensitive". This document 45 explains exactly what that means and provides a clear specification 46 of the rules. This clarification updates RFCs 1034 and 1035. 48 Acknowledgements 50 The contributions to this document of Rob Austein, Olafur 51 Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana, 52 Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman 53 are gratefully acknowledged. 55 Table of Contents 57 Status of This Document....................................1 58 Copyright Notice...........................................1 59 Abstract...................................................1 61 Acknowledgements...........................................2 62 Table of Contents..........................................2 64 1. Introduction............................................3 65 2. Case Insensitivity of DNS Labels........................3 66 2.1 Escaping Unusual DNS Label Octets......................3 67 2.2 Example Labels with Escapes............................4 68 3. Name Lookup, Label Types, and CLASS.....................4 69 3.1 Original DNS Label Types...............................5 70 3.2 Extended Label Type Case Insensitivity Considerations..5 71 3.3 CLASS Case Insensitivity Considerations................5 72 4. Case on Input and Output................................6 73 4.1 DNS Output Case Preservation...........................6 74 4.2 DNS Input Case Preservation............................6 75 5. Internationalized Domain Names..........................7 76 6. Security Considerations.................................7 78 Full Copyright Notice and Disclaimer.......................9 79 Normative References.......................................9 80 Informative References....................................10 81 -02 to -03 Changes........................................10 82 -03 to -04 Changes........................................11 83 -04 to -05 Changes........................................11 84 Author's Address..........................................11 85 Expiration and File Name..................................12 87 1. Introduction 89 The Domain Name System (DNS) is the global hierarchical replicated 90 distributed database system for Internet addressing, mail proxy, and 91 other information. Each node in the DNS tree has a name consisting of 92 zero or more labels [STD 13][RFC 1591, 2606] that are treated in a 93 case insensitive fashion. This document clarifies the meaning of 94 "case insensitive" for the DNS. This clarification updates RFCs 1034 95 and 1035 [STD 13]. 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC 2119]. 101 2. Case Insensitivity of DNS Labels 103 DNS was specified in the era of [ASCII]. DNS names were expected to 104 look like most host names or Internet email address right halves (the 105 part after the at-sign, "@") or be numeric as in the in-addr.arpa 106 part of the DNS name space. For example, 108 foo.example.net. 109 aol.com. 110 www.gnu.ai.mit.edu. 111 or 69.2.0.192.in-addr.arpa. 113 Case varied alternatives to the above would be DNS names like 115 Foo.ExamplE.net. 116 AOL.COM. 117 WWW.gnu.AI.mit.EDU. 118 or 69.2.0.192.in-ADDR.ARPA. 120 However, the individual octets of which DNS names consist are not 121 limited to valid ASCII character codes. They are 8-bit bytes and all 122 values are allowed. Many applications, however, interpret them as 123 ASCII characters. 125 2.1 Escaping Unusual DNS Label Octets 127 In Master Files [STD 13] and other human readable and writable ASCII 128 contexts, an escape is needed for the byte value for period (0x2E, 129 ".") and all octet values outside of the inclusive range of 0x21 130 ("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in 131 the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF. 133 One typographic convention for octets that do not correspond to an 134 ASCII printing graphic is to use a back-slash followed by the value 135 of the octet as an unsigned integer represented by exactly three 136 decimal digits. 138 The same convention can be used for printing ASCII characters so that 139 they will be treated as a normal label character. This includes the 140 back-slash character used in this convention itself which can be 141 expressed as \092 or \\ and the special label separator period (".") 142 which can be expressed as and \046 or \. respectively. It is 143 advisable to avoid using a backslash to quote an immediately 144 following non-printing ASCII character code to avoid implementation 145 difficulties. 147 A back-slash followed by only one or two decimal digits is undefined. 148 A back-slash followed by four decimal digits produces two octets, the 149 first octet having the value of the first three digits considered as 150 a decimal number and the second octet being the character code for 151 the fourth decimal digit. 153 2.2 Example Labels with Escapes 155 The first example below shows embedded spaces and a period (".") 156 within a label. The second one show a 5-octet label where the second 157 octet has all bits zero, the third is a backslash, and the fourth 158 octet has all bits one. 160 Donald\032E\.\032Eastlake\0323rd.example. 161 and a\000\\\255z.example. 163 3. Name Lookup, Label Types, and CLASS 165 The design decision was made that comparisons on name lookup for all 166 DNS queries should be case insensitive [STD 13]. That is to say, a 167 lookup string octet with a value in the inclusive range of 0x41 to 168 0x5A, the upper case ASCII letters, MUST match the identical value 169 and also match the corresponding value in the inclusive range 0x61 to 170 0x7A, the lower case ASCII letters. And a lookup string octet with a 171 lower case ASCII letter value MUST similarly match the identical 172 value and also match the corresponding value in the upper case ASCII 173 letter range. 175 (Historical Note: the terms "upper case" and "lower case" were 176 invented after movable type. The terms originally referred to the 177 two font trays for storing, in partitioned areas, the different 178 physical type elements. Before movable type, the nearest equivalent 179 terms were "majuscule" and "minuscule".) 181 One way to implement this rule would be, when comparing octets, to 182 subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A 183 before the comparison. Such an operation is commonly known as "case 184 folding" but implementation via case folding is not required. Note 185 that the DNS case insensitivity does NOT correspond to the case 186 folding specified in [iso-8859-1] or [iso-8859-2]. For example, the 187 octets 0xDD (\221) and 0xFD (\253) do NOT match although in other 188 contexts, where they are interpreted as the upper and lower case 189 version of "Y" with an acute accent, they might. 191 3.1 Original DNS Label Types 193 DNS labels in wire-encoded names have a type associated with them. 194 The original DNS standard [RFC 1035] had only two types. ASCII 195 labels, with a length of from zero to 63 octets, and indirect labels 196 which consist of an offset pointer to a name location elsewhere in 197 the wire encoding on a DNS message. (The ASCII label of length zero 198 is reserved for use as the name of the root node of the name tree.) 199 ASCII labels follow the ASCII case conventions described herein and, 200 as stated above, can actually contain arbitrary byte values. Indirect 201 labels are, in effect, replaced by the name to which they point which 202 is then treated with the case insensitivity rules in this document. 204 3.2 Extended Label Type Case Insensitivity Considerations 206 DNS was extended by [RFC 2671] to have additional label type numbers 207 available. (The only such type defined so far is the BINARY type [RFC 208 2673].) 210 The ASCII case insensitivity conventions only apply to ASCII labels, 211 that is to say, label type 0x0, whether appearing directly or invoked 212 by indirect labels. 214 3.3 CLASS Case Insensitivity Considerations 216 As described in [STD 13] and [RFC 2929], DNS has an additional axis 217 for data location called CLASS. The only CLASS in global use at this 218 time is the "IN" or Internet CLASS. 220 The handling of DNS label case is not CLASS dependent. 222 4. Case on Input and Output 224 While ASCII label comparisons are case insensitive, [STD 13] says 225 case MUST be preserved on output, and preserved when convenient on 226 input. However, this means less than it would appear since the 227 preservation of case on output is NOT required when output is 228 optimized by the use of indirect labels, as explained below. 230 4.1 DNS Output Case Preservation 232 [STD 13] views the DNS namespace as a node tree. ASCII output is as 233 if a name was marshaled by taking the label on the node whose name is 234 to be output, converting it to a typographically encoded ASCII 235 string, walking up the tree outputting each label encountered, and 236 preceding all labels but the first with a period ("."). Wire output 237 follows the same sequence but each label is wire encoded and no 238 periods inserted. No "case conversion" or "case folding" is done 239 during such output operations, thus "preserving" case. However, to 240 optimize output, indirect labels may be used to point to names 241 elsewhere in the DNS answer. In determining whether the name to be 242 pointed to, for example the QNAME, is the "same" as the remainder of 243 the name being optimized, the case insensitive comparison specified 244 above is done. Thus such optimization may easily destroy the output 245 preservation of case. This type of optimization is commonly called 246 "name compression". 248 4.2 DNS Input Case Preservation 250 Originally, DNS input came from an ASCII Master File as defined in 251 [STD 13] or a zone transfer. DNS Dynamic update and incremental zone 252 transfers [RFC 1995] have been added as a source of DNS data [RFC 253 2136, 3007]. When a node in the DNS name tree is created by any of 254 such inputs, no case conversion is done. Thus the case of ASCII 255 labels is preserved if they are for nodes being created. However, 256 when a name label is input for a node that already exist in DNS data 257 being held, the situation is more complex. Implementations may retain 258 the case first input for such a label or allow new input to override 259 the old case or even maintain separate copies preserving the input 260 case. 262 For example, if data with owner name "foo.bar.example" is input and 263 then later data with owner name "xyz.BAR.example" is input, the name 264 of the label on the "bar.example" node, i.e. "bar", might or might 265 not be changed to "BAR" or the actual input case could be preserved. 266 Thus later retrieval of data stored under "xyz.bar.example" in this 267 case can easily return data with "xyz.BAR.example". The same 268 considerations apply when inputting multiple data records with owner 269 names differing only in case. For example, if an "A" record is stored 270 as the first resourced record under owner name "xyz.BAR.example" and 271 then a second "A" record is stored under "XYZ.BAR.example", the 272 second MAY be stored with the first (lower case initial label) name 273 or the second MAY override the first so that only an upper case 274 initial label is retained or both capitalizations MAY be kept. 276 Note that the order of insertion into a server database of the DNS 277 name tree nodes that appear in a Master File is not defined so that 278 the results of inconsistent capitalization in a Master File are 279 unpredictable output capitalization. 281 5. Internationalized Domain Names 283 A scheme has been adopted for "internationalized domain names" and 284 "internationalized labels" as described in [RFC 3490, 3454, 3491, and 285 3492]. It makes most of [UNICODE] available through a separate 286 application level transformation from internationalized domain name 287 to DNS domain name and from DNS domain name to internationalized 288 domain name. Any case insensitivity that internationalized domain 289 names and labels have varies depending on the script and is handled 290 entirely as part of the transformation described in [RFC 3454] and 291 [RFC 3491] which should be seen for further details. This is not a 292 part of the DNS as standardized in STD 13. 294 6. Security Considerations 296 The equivalence of certain DNS label types with case differences, as 297 clarified in this document, can lead to security problems. For 298 example, a user could be confused by believing two domain names 299 differing only in case were actually different names. 301 Furthermore, a domain name may be used in contexts other than the 302 DNS. It could be used as a case sensitive index into some data base 303 system. Or it could be interpreted as binary data by some integrity 304 or authentication code system. These problems can usually be handled 305 by using a standardized or "canonical" form of the DNS ASCII type 306 labels, that is, always mapping the ASCII letter value octets in 307 ASCII labels to some specific pre-chosen case, either upper case or 308 lower case. An example of a canonical form for domain names (and also 309 a canonical ordering for them) appears in Section 8 of [RFC 2535]. 310 See also [RFC 3597]. 312 Finally, a non-DNS name may be stored into DNS with the false 313 expectation that case will always be preserved. For example, although 314 this would be quite rare, on a system with case sensitive email 315 address local parts, an attempt to store two "RP" records that 316 differed only in case would probably produce unexpected results that 317 might have security implications. That is because the entire email 318 address, including the possibly case sensitive local or left hand 319 part, is encoded into a DNS name in a readable fashion where the case 320 of some letters might be changed on output as described above. 322 Full Copyright Notice and Disclaimer 324 Copyright (C) The Internet Society 2005. This document is subject to 325 the rights, licenses and restrictions contained in BCP 78 and except 326 as set forth therein, the authors retain all their rights. 328 This document and the information contained herein are provided on an 329 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 330 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 331 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 332 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 333 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 334 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 336 Normative References 338 [ASCII] - ANSI, "USA Standard Code for Information Interchange", 339 X3.4, American National Standards Institute: New York, 1968. 341 [RFC 1034, 1035] - See [STD 13]. 343 [RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August 344 1996. 346 [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate 347 Requirement Levels", March 1997. 349 [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, 350 "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997. 352 [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", 353 March 1999. 355 [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic 356 Update", November 2000. 358 [RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types", 359 draft-ietf-dnsext-unknown-rrs-05.txt, March 2003. 361 [STD 13] 362 - P. Mockapetris, "Domain names - concepts and facilities", RFC 363 1034, November 1987. 364 - P. Mockapetris, "Domain names - implementation and 365 specification", RFC 1035, November 1987. 367 Informative References 369 [ISO 8859-1] - International Standards Organization, Standard for 370 Character Encodings, Latin-1. 372 [ISO 8859-2] - International Standards Organization, Standard for 373 Character Encodings, Latin-2. 375 [RFC 1591] - J. Postel, "Domain Name System Structure and 376 Delegation", March 1994. 378 [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", 379 June 1999. 381 [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain 382 Name System (DNS) IANA Considerations", September 2000. 384 [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August 385 1999. 387 [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System", 388 August 1999. 390 [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of 391 Foo", 1 April 2001. 393 [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of 394 Internationalized String ("stringprep")", December 2002. 396 [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello, 397 "Internationalizing Domain Names in Applications (IDNA)", March 2003. 399 [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile 400 for Internationalized Domain Names (IDN)", March 2003. 402 [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode 403 for Internationalized Domain Names in Applications (IDNA)", March 404 2003. 406 [UNICODE] - The Unicode Consortium, "The Unicode Standard", 407 . 409 -02 to -03 Changes 411 The following changes were made between draft version -02 and -03: 413 1. Add internationalized domain name section and references. 415 2. Change to indicate that later input of a label for an existing DNS 416 name tree node may or may not be normalized to the earlier input or 417 override it or both may be preserved. 419 3. Numerous minor wording changes. 421 -03 to -04 Changes 423 The following changes were made between draft versions -03 and -04: 425 1. Change to conform to the new IPR, Copyright, etc., notice 426 requirements. 428 2. Change in some section headers for clarity. 430 3. Drop section on wildcards. 432 4. Add emphasis on loss of case preservation due to name compression. 434 5. Add references to RFCs 1995 and 3092. 436 -04 to -05 Changes 438 The following changes were made between draft versions -04 and -05: 440 1. More clearly state that this draft updates RFCs 1034, 1035 [STD 441 13]. 443 2. Add informative references to ISO 8859-1 and ISO 8859-2. 445 3. Fix hyphenation and capitalization nits. 447 Author's Address 449 Donald E. Eastlake 3rd 450 Motorola Laboratories 451 155 Beaver Street 452 Milford, MA 01757 USA 454 Telephone: +1 508-786-7554 (w) 455 +1 508-634-2066 (h) 456 EMail: Donald.Eastlake@motorola.com 458 Expiration and File Name 460 This draft expires July 2005. 462 Its file name is draft-ietf-dnsext-insensitive-05.txt.