idnits 2.17.1 draft-ietf-dnsext-insensitive-00.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 114 has weird spacing: '... or a\000\3...' -- 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 2003) is 7772 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 66, but not defined == Missing Reference: 'RFC 1035' is mentioned on line 136, but not defined == Missing Reference: '3007' is mentioned on line 191, but not defined == Unused Reference: 'RFC 1034' is defined on line 240, but no explicit reference was found in the text == Unused Reference: '1035' is defined on line 240, but no explicit reference was found in the text == Unused Reference: 'RFC 3007' is defined on line 251, but no explicit reference was found in the text == Unused Reference: 'RFC 2606' is defined on line 268, but no explicit reference was found in the text == Unused Reference: 'RFC 2673' is defined on line 277, 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 July 2003 January 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 Table of Contents 42 Status of This Document....................................1 43 Abstract...................................................1 45 Table of Contents..........................................2 47 1. Introduction............................................3 48 2. Case Insensitivity of DNS Labels........................3 49 3. Additional DNS Case Insensitivity Considerations........4 50 3.1 CLASS Case Insensitivity Considerations................4 51 3.2 Label Type Case Insensitivity Considerations...........5 52 4. Case on Input and Output................................5 53 5. Security Considerations.................................6 55 Normative References.......................................7 56 Informative References.....................................7 58 Author's Address...........................................8 59 Expiration and File Name...................................8 61 1. Introduction 63 The Domain Name System (DNS) is the global hierarchical replicated 64 distributed database system for Internet addressing, mail proxy, and 65 other information. Each node in the DNS tree has a name consisting of 66 zero or more labels [STD 13][RFC 1591, 2606] which have always been 67 specified as being treated in a case insensitive fashion. This 68 document clarifies the meaning of "case insensitive" for this 69 application. 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC 2119]. 75 2. Case Insensitivity of DNS Labels 77 DNS was specified in the era of [ASCII]. DNS names were expected to 78 look like most host names or Internet email address right halves (the 79 part after the at-sign ("@")) or be numeric as in the in-addr.arpa 80 part of the DNS name space. For example, 82 foo.example.net. 83 aol.com. 84 www.gnu.ai.mit.edu. 85 or 69.2.0.192.in-addr.arpa. 87 Case varied alternatives to the above would be DNS names like 89 Foo.ExamplE.net. 90 AOL.COM. 91 WWW.gnu.AI.mit.EDU. 92 or 69.2.0.192.in-ADDR.ARPA. 94 The individual bytes of which DNS names consist are not limited to 95 valid ASCII character codes. They are defined as 8-bit bytes and all 96 values are allowed. It is just that they are traditionally interpreted 97 as ASCII characters. 99 The typographic convention for bytes that do not correspond to an 100 ASCII printing graphic is to show them as a back-slash followed by 101 three hex digits for the value of the byte as an unsigned 102 integer. This includes all byte values outside of the inclusive range 103 of 0x21 ("!") to 0x7E ("~"). That is to say, all byte values in the 104 two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF. The same 105 convention can be used for the back-slash character and the special 106 label separator period ("."). A period can also be protected from 107 recognition as a separator, so that it will be treated as a normal 108 label character, by preceeding it with a back-slash. The first example 109 below shows embedded spaces and a period (".") within a label. The 110 second one show a 4 byte label where the second byte has all bits zero 111 and the third byte has all bits one. 113 Donald\040E\.\040Eastlake\0403rd.example. 114 or a\000\377z.example. 116 The design decision was made that comparisons on name lookup for DNS 117 queries should be case insensitive [STD 13]. That is to say, a lookup 118 string byte with a value in the inclusive range of 0x41 to 0x5A, the 119 upper case ASCII letters, MUST match the identical value and also 120 match the corresponding value in the inclusive range 0x61 to 0x7A, 121 the lower case ASCII letters. And a lookup string byte with a lower 122 case ASCII letter value MUST similarly match the identical value and 123 also match the corresponding value in the upper case ASCII letter 124 range. One way to implement this rule would be, when comparing bytes, 125 to subtract 0x20 from all bytes in the inclusive range 0x61 to 0x7A 126 before the comparison. Such an operation is commonly known as "case 127 folding". 129 (Historic Note: the terms "upper case" and "lower case" were invented 130 after movable type became wide spread for printing. The terms 131 originally refered to the two font trays for storing, in partitioned 132 areas, the different physical type elements. Before movable type, 133 the nearest equivalent terms were "majuscule" and "minuscule".) 135 DNS labels in wire encoded names have a type associated with them. 136 The original DNS standard [RFC 1035] had only two types. ASCII 137 labels, with a length of from zero to 63 bytes and indirect labels 138 which consist of an offset pointer to a name location elsewhere in 139 the wire encoding. (The ASCII label of length zero is reserved for 140 use as the name of the root node of the name tree.) ASCII labels 141 follow the ASCII case conventions described above. Indirect labels 142 are, in effect, replaced by the name to which they point which is 143 then treated with the case insensitivity rules in this document. 145 3. Additional DNS Case Insensitivity Considerations 147 This section clarifies the effect of DNS CLASS and extended Label 148 Type on case insensitivity. 150 3.1 CLASS Case Insensitivity Considerations 152 As described in [STD 13] and [RFC 2929], DNS has an additional axis 153 for data location called CLASS. The only CLASS in global use at this 154 time is the "IN" or Internet CLASS. 156 The handling of DNS label case is not CLASS dependent. 158 3.2 Label Type Case Insensitivity Considerations 160 DNS was extended by [RFC 2671] to have additional label type numbers 161 available. (The only such type defined so far it the BINARY type [RFC 162 2673].) 164 The ASCII case insensitivity conventions, or case folding, only apply 165 to ASCII labels, that is to say, label type 0x0, whether appearing 166 directly or invoked by indirect labels. 168 4. Case on Input and Output 170 While ASCII label comparisons are case insensitive, case MUST be 171 preserved on output, except when output is optimized by the use of 172 indirect labels, and preserved when possible on input. 174 [STD 13] views the DNS namespace as a node tree. ASCII output is as 175 if a name was marshalled by taking the label on the node whose name 176 is to be output, converting it to a typographicly encoded ASCII 177 string, walking up the tree outputting each label encountered, and 178 preceeding all labels but the first with a period ("."). Wire output 179 follows the same sequence but each label is wire encoded and no 180 periods inserted. No "case conversion" or "case folding" is done 181 during such output operations. However, to optimize output, indirect 182 labels may be used to point to names elsewhere in the DNS answer. In 183 determining whether the name to be pointed to is the "same" as the 184 remainder of the name being optimized, the case insensitive 185 comparison specified above is done. Thus such optimization MAY 186 destroy the output preservation of case. This type of optimization is 187 commonly called "name compression". 189 Originally, DNS input came from an ASCII Master File as defined in 190 [STD 13]. DNS Dynamic update has been added as a source of DNS data 191 [RFC 2136, 3007]. When a node in the DNS name tree is created by such 192 input, no case conversion is done and the case of ASCII labels is 193 preserved if they are for nodes being creted. However, no change is 194 made in the name label on nodes that already exist is the DNS data 195 being augmented or updated. It is quite common for higher level nodes 196 to already exist. For example, if data with owner name 197 "foo.bar.example" is input and then later data with owner name 198 "xyz.BAR.example" is input, the name of the label on the 199 "bar.example" node, i.e. "bar", is not changed to "BAR". Thus later 200 retrieval of data stored under "xyz.bar.example" in this case can 201 easily result is obtaining data with "xyz.BAR.example". 203 Note that the order of insertion into a server database of the DNS 204 name tree nodes that appear in a Master File is not defined so that 205 the results of inconsistent capitalization in a Master File are 206 unpredicatable output capitalization. 208 There is one additional instance of note, which reflects the general 209 rules that output case reflects input case unless there is 210 conflicting capitalization in the DNS database or the output case is 211 hidden by name compression. This is when a query matches a wild card 212 in the DNS database at a server. In that case, the answer SHOULD 213 reflect the input case of the label or labels that matched the 214 wildcard unless they are replaced by an indirect label which MAY 215 point to a name with different captialization. 217 5. Security Considerations 219 The equivalence of certain DNS label types with case differences, as 220 clarified in this document, can lead to security problems. For 221 example, a user could be confused by believing two domain names 222 differing only in case were actually different names. 224 Furthermore, a domain name may be used in contexts other than the 225 DNS. It could be used as an index into some case sensitive data base 226 system. Or it could be interpreted as binary data by some integrity 227 or authentication code system. These problems can usually be handled 228 by using a standardized or "canonical" form of the DNS ASCII type 229 labels, that is, always map the ASCII letter value octets in ASCII 230 labels to some specific pre-chosen case, either upper case or lower 231 case. An example of a canonical form for domain names (and also a 232 canonical ordering for them) appears in Section 8 of [RFC 2535]. See 233 also [UNKRR]. 235 Normative References 237 [ASCII] - ANSI, "USA Standard Code for Information Interchange", 238 X3.4, American National Standards Institute: New York, 1968. 240 [RFC 1034, 1035] - See [STD 13]. 242 [RFC 2119] - "Key words for use in RFCs to Indicate Requirement 243 Levels", S. Bradner, March 1997. 245 [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, 246 "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997. 248 [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", 249 March 1999. 251 [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic 252 Update", November 2000. 254 [STD 13] 255 - P. Mockapetris, "Domain names - concepts and facilities", RFC 256 1034, November 1987. 257 - P. Mockapetris, "Domain names - implementation and 258 specification", RFC 1035, November 1987. 260 [UNKRR] - Andreas Gustafsson, "Handling of Unknown DNS RR Types", 261 draft-ietf-dnsext-unknown-rrs-04.txt, September 2002. 263 Informative References 265 [RFC 1591] - J. Postel, "Domain Name System Structure and 266 Delegation", March 1994. 268 [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", 269 June 1999. 271 [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain 272 Name System (DNS) IANA Considerations", September 2000. 274 [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August 275 1999. 277 [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System", 278 August 1999. 280 Author's Address 282 Donald E. Eastlake 3rd 283 Motorola Laboratories 284 155 Beaver Street 285 Milford, MA 01757 USA 287 Telephone: +1 508-851-8280 (w) 288 +1 508-634-2066 (h) 289 EMail: Donald.Eastlake@motorola.com 291 Expiration and File Name 293 This draft expires July 2003. 295 Its file name is draft-ietf-dnsext-insensitive-00.txt.