idnits 2.17.1 draft-ietf-dnsext-insensitive-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. ** 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 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. == 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: ---------------------------------------------------------------------------- == Line 150 has weird spacing: '... or a\000\2...' -- 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 (February 2003) is 7734 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 82, but not defined == Missing Reference: 'RFC 1035' is mentioned on line 184, but not defined == Missing Reference: '3007' is mentioned on line 244, but not defined == Unused Reference: 'RFC 1034' is defined on line 311, but no explicit reference was found in the text == Unused Reference: '1035' is defined on line 311, but no explicit reference was found in the text == Unused Reference: 'RFC 3007' is defined on line 322, but no explicit reference was found in the text == Unused Reference: 'RFC 2606' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'RFC 2673' is defined on line 348, 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-04 -- 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) Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 7 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 August 2003 February 2003 5 Domain Name System (DNS) Case Insensitivity Clarification 6 ------ ---- ------ ----- ---- ------------- ------------- 7 9 Donald E. Eastlake 3rd 11 Status of This Document 13 Distribution of this document is unlimited. Comments should be sent 14 to the DNSEXT working group at namedroppers@ops.ietf.org. 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC 2026. Internet-Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 Domain Name System (DNS) names are "case insensitive". This document 36 explains exactly what that means and provides a clear specification 37 of the rules. This clarification should not have any interoperability 38 consequences. 40 Copyright (C) 2003 The Internet Society. All Rights Reserved. 42 Acknowledgements 44 The contributions to this document of Rob Austein, Olafur 45 Gudmundsson, Daniel J. Anderson, Alan Barrett, Dana, Andrew Main, and 46 Scott Seligman are gratefully acknowledged. 48 Table of Contents 50 Status of This Document....................................1 51 Abstract...................................................1 53 Acknowledgements...........................................2 54 Table of Contents..........................................2 56 1. Introduction............................................3 57 2. Case Insensitivity of DNS Labels........................3 58 2.1 Escaping Unusual DNS Label Octets......................3 59 2.2 Example Labels with Escapes............................4 60 2.3 Name Lookup Case Insensitivity.........................4 61 2.4 Original DNS Label Types...............................5 62 3. Additional DNS Case Insensitivity Considerations........5 63 3.1 CLASS Case Insensitivity Considerations................5 64 3.2 Extended Label Type Case Insensitivity Considerations..5 65 4. Case on Input and Output................................6 66 4.1 DNS Output Case Preservation...........................6 67 4.2 DNS Input Case Preservation............................6 68 4.3 Wildcard Matching......................................7 69 5. Security Considerations.................................7 71 Normative References.......................................9 72 Informative References.....................................9 74 Author's Address..........................................10 75 Expiration and File Name..................................10 77 1. Introduction 79 The Domain Name System (DNS) is the global hierarchical replicated 80 distributed database system for Internet addressing, mail proxy, and 81 other information. Each node in the DNS tree has a name consisting of 82 zero or more labels [STD 13][RFC 1591, 2606] which have been 83 specified as being treated in a case insensitive fashion. This 84 document clarifies the meaning of "case insensitive" for this 85 application. 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC 2119]. 91 2. Case Insensitivity of DNS Labels 93 DNS was specified in the era of [ASCII]. DNS names were expected to 94 look like most host names or Internet email address right halves (the 95 part after the at-sign ("@")) or be numeric as in the in-addr.arpa 96 part of the DNS name space. For example, 98 foo.example.net. 99 aol.com. 100 www.gnu.ai.mit.edu. 101 or 69.2.0.192.in-addr.arpa. 103 Case varied alternatives to the above would be DNS names like 105 Foo.ExamplE.net. 106 AOL.COM. 107 WWW.gnu.AI.mit.EDU. 108 or 69.2.0.192.in-ADDR.ARPA. 110 The individual octets of which DNS names consist are not limited to 111 valid ASCII character codes. They are defined as 8-bit bytes and all 112 values are allowed. Most applications, however, interprete them 113 as ASCII characters. 115 2.1 Escaping Unusual DNS Label Octets 117 An escape is needed for all octet values outside of the inclusive 118 range of 0x21 ("!") to 0x7E ("~"). That is to say, all octet values in 119 the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF. 121 One typographic convention for octets that do not correspond to an 122 ASCII printing graphic is to show them as a back-slash followed by the 123 value of the octet as an unsigned integer represented by exactly three 124 decimal digits. The same convention can be used for printing ASCII 125 characters. This includes the back-slash character used in this 126 convention itself and the special label separator period (".") which 127 can be expressed as \092 and \046 respectively. 129 A back-slash followed by only one or two decimal digits is 130 undefined. A back-slash followed by four decimal digits produces two 131 octets, the first octet having the value of the first three digits 132 considered as a decimal number and the second octet being the 133 character code for the fourth decimal digit. 135 Octets, other than those corresponding to the ASCII digits 0 through 136 9, can also be protected from recognition, so that they will be 137 treated as a normal label character, by a second convention: 138 preceding them with a back-slash. This is the most commonly used 139 technique for protecting back slash ("\") and period ("."). However, 140 it is advisable to avoid using this on other than printing ASCII 141 characters to avoid implementation difficulties. 143 2.2 Example Labels with Escapes 145 The first example below shows embedded spaces and a period (".") 146 within a label. The second one show a 4 octet label where the second 147 octet has all bits zero and the third octet has all bits one. 149 Donald\032E\.\032Eastlake\0323rd.example. 150 or a\000\255z.example. 152 2.3 Name Lookup Case Insensitivity 154 The design decision was made that comparisons on name lookup for DNS 155 queries should be case insensitive [STD 13]. That is to say, a lookup 156 string octet with a value in the inclusive range of 0x41 to 0x5A, the 157 upper case ASCII letters, MUST match the identical value and also 158 match the corresponding value in the inclusive range 0x61 to 0x7A, 159 the lower case ASCII letters. And a lookup string octet with a lower 160 case ASCII letter value MUST similarly match the identical value and 161 also match the corresponding value in the upper case ASCII letter 162 range. 164 (Historical Note: the terms "upper case" and "lower case" were 165 invented after movable type became wide spread for printing. The 166 terms originally referred to the two font trays for storing, in 167 partitioned areas, the different physical type elements. Before 168 movable type, the nearest equivalent terms were "majuscule" and 169 "minuscule".) 171 One way to implement this rule would be, when comparing octets, to 172 subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A 173 before the comparison. Such an operation is commonly known as "case 174 folding" but implementation via case folding is not required. Note 175 that the DNS case insensitivity does NOT correspond to the case 176 folding specified in iso-8859-1 or iso-8859-2. For example, the 177 octets 0xDD (\221) and 0xFD (\253) do NOT match although in other 178 contexts where they are interpreted as the upper and lower case 179 version of "Y" with an acute accent, they might. 181 2.4 Original DNS Label Types 183 DNS labels in wire encoded names have a type associated with them. 184 The original DNS standard [RFC 1035] had only two types. ASCII 185 labels, with a length of from zero to 63 octets and indirect labels 186 which consist of an offset pointer to a name location elsewhere in 187 the wire encoding on a DNS message. (The ASCII label of length zero 188 is reserved for use as the name of the root node of the name tree.) 189 ASCII labels follow the ASCII case conventions described above. 190 Indirect labels are, in effect, replaced by the name to which they 191 point which is then treated with the case insensitivity rules in this 192 document. 194 3. Additional DNS Case Insensitivity Considerations 196 This section clarifies the effect of DNS CLASS and extended Label 197 Type on case insensitivity. 199 3.1 CLASS Case Insensitivity Considerations 201 As described in [STD 13] and [RFC 2929], DNS has an additional axis 202 for data location called CLASS. The only CLASS in global use at this 203 time is the "IN" or Internet CLASS. 205 The handling of DNS label case is not CLASS dependent. 207 3.2 Extended Label Type Case Insensitivity Considerations 209 DNS was extended by [RFC 2671] to have additional label type numbers 210 available. (The only such type defined so far is the BINARY type [RFC 211 2673].) 213 The ASCII case insensitivity conventions, or case folding, only apply 214 to ASCII labels, that is to say, label type 0x0, whether appearing 215 directly or invoked by indirect labels. 217 4. Case on Input and Output 219 While ASCII label comparisons are case insensitive, case MUST be 220 preserved on output, except when output is optimized by the use of 221 indirect labels, and preserved when possible on input. 223 4.1 DNS Output Case Preservation 225 [STD 13] views the DNS namespace as a node tree. ASCII output is as 226 if a name was marshalled by taking the label on the node whose name 227 is to be output, converting it to a typographically encoded ASCII 228 string, walking up the tree outputting each label encountered, and 229 preceding all labels but the first with a period ("."). Wire output 230 follows the same sequence but each label is wire encoded and no 231 periods inserted. No "case conversion" or "case folding" is done 232 during such output operations. However, to optimize output, indirect 233 labels may be used to point to names elsewhere in the DNS answer. In 234 determining whether the name to be pointed to is the "same" as the 235 remainder of the name being optimized, the case insensitive 236 comparison specified above is done. Thus such optimization MAY 237 destroy the output preservation of case. This type of optimization is 238 commonly called "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]. DNS Dynamic update has been added as a source of DNS data 244 [RFC 2136, 3007]. When a node in the DNS name tree is created by such 245 input, no case conversion is done and the case of ASCII labels is 246 preserved if they are for nodes being created. However, no change is 247 made in the name label on nodes that already exist in the DNS data 248 being augmented or updated. It is quite common for higher level nodes 249 to already exist. 251 For example, if data with owner name "foo.bar.example" is input and 252 then later data with owner name "xyz.BAR.example" is input, the name 253 of the label on the "bar.example" node, i.e. "bar", is not changed to 254 "BAR". Thus later retrieval of data stored under "xyz.bar.example" in 255 this case can easily result is obtaining data with "xyz.BAR.example". 256 The same considerations apply when inputting multiple data records 257 with owner names differing only in case. From the example above, if 258 an "A" record is stored under owner name "xyz.BAR.example" and then a 259 second "A" record under "XYZ.BAR.example", the second will be stored 260 at the node with the first (lower case initial label) name. 262 Note that the order of insertion into a server database of the DNS 263 name tree nodes that appear in a Master File is not defined so that 264 the results of inconsistent capitalization in a Master File are 265 unpredicatable output capitalization. 267 4.3 Wildcard Matching 269 There is one additional instance of note, which reflects the general 270 rules that output case reflects input case unless there is 271 conflicting capitalization in the DNS database or the output case is 272 hidden by name compression. This is when a query matches a wildcard 273 in the DNS database at a server. In that case, the answer SHOULD 274 reflect the input case of the label or labels that matched the 275 wildcard unless they are replaced by an indirect label which MAY 276 point to a name with different capitalization. 278 5. Security Considerations 280 The equivalence of certain DNS label types with case differences, as 281 clarified in this document, can lead to security problems. For 282 example, a user could be confused by believing two domain names 283 differing only in case were actually different names. 285 Furthermore, a domain name may be used in contexts other than the 286 DNS. It could be used as an index into some case sensitive data base 287 system. Or it could be interpreted as binary data by some integrity 288 or authentication code system. These problems can usually be handled 289 by using a standardized or "canonical" form of the DNS ASCII type 290 labels, that is, always map the ASCII letter value octets in ASCII 291 labels to some specific pre-chosen case, either upper case or lower 292 case. An example of a canonical form for domain names (and also a 293 canonical ordering for them) appears in Section 8 of [RFC 2535]. See 294 also [UNKRR]. 296 Finally, a non-DNS name may be stored into DNS with the false 297 expectation that case will always be preserved. For example, although 298 this would be quite rare, on a system with case sensitive email 299 address local parts, an attempt to store two "RP" records that 300 differed only in case would probably produce unexpected results that 301 might have security implications. That is because the entire email 302 address, including the possibly case sensitive local or left hand 303 part, is encoded into a DNS name in a readable fashion where the case 304 of some letters might be changed on output as described above. 306 Normative References 308 [ASCII] - ANSI, "USA Standard Code for Information Interchange", 309 X3.4, American National Standards Institute: New York, 1968. 311 [RFC 1034, 1035] - See [STD 13]. 313 [RFC 2119] - "Key words for use in RFCs to Indicate Requirement 314 Levels", S. Bradner, March 1997. 316 [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, 317 "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997. 319 [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", 320 March 1999. 322 [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic 323 Update", November 2000. 325 [STD 13] 326 - P. Mockapetris, "Domain names - concepts and facilities", RFC 327 1034, November 1987. 328 - P. Mockapetris, "Domain names - implementation and 329 specification", RFC 1035, November 1987. 331 [UNKRR] - Andreas Gustafsson, "Handling of Unknown DNS RR Types", 332 draft-ietf-dnsext-unknown-rrs-04.txt, September 2002. 334 Informative References 336 [RFC 1591] - J. Postel, "Domain Name System Structure and 337 Delegation", March 1994. 339 [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", 340 June 1999. 342 [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain 343 Name System (DNS) IANA Considerations", September 2000. 345 [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August 346 1999. 348 [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System", 349 August 1999. 351 Author's Address 353 Donald E. Eastlake 3rd 354 Motorola Laboratories 355 155 Beaver Street 356 Milford, MA 01757 USA 358 Telephone: +1 508-851-8280 (w) 359 +1 508-634-2066 (h) 360 EMail: Donald.Eastlake@motorola.com 362 Expiration and File Name 364 This draft expires August 2003. 366 Its file name is draft-ietf-dnsext-insensitive-02.txt.