7Network Working Group D. Eastlake 3rd
8Request for Comments: 4343 Motorola Laboratories
9Updates: 1034, 1035, 2181 January 2006
10Category: Standards Track
13 Domain Name System (DNS) Case Insensitivity Clarification
17 This document specifies an Internet standards track protocol for the
18 Internet community, and requests discussion and suggestions for
19 improvements. Please refer to the current edition of the "Internet
20 Official Protocol Standards" (STD 1) for the standardization state
21 and status of this protocol. Distribution of this memo is unlimited.
25 Copyright (C) The Internet Society (2006).
29 Domain Name System (DNS) names are "case insensitive". This document
30 explains exactly what that means and provides a clear specification
31 of the rules. This clarification updates RFCs 1034, 1035, and 2181.
35 1. Introduction ....................................................2
36 2. Case Insensitivity of DNS Labels ................................2
37 2.1. Escaping Unusual DNS Label Octets ..........................2
38 2.2. Example Labels with Escapes ................................3
39 3. Name Lookup, Label Types, and CLASS .............................3
40 3.1. Original DNS Label Types ...................................4
41 3.2. Extended Label Type Case Insensitivity Considerations ......4
42 3.3. CLASS Case Insensitivity Considerations ....................4
43 4. Case on Input and Output ........................................5
44 4.1. DNS Output Case Preservation ...............................5
45 4.2. DNS Input Case Preservation ................................5
46 5. Internationalized Domain Names ..................................6
47 6. Security Considerations .........................................6
48 7. Acknowledgements ................................................7
49 Normative References................................................7
50 Informative References..............................................8
58Eastlake 3rd Standards Track [Page 1]
60RFC 4343 DNS Case Insensitivity Clarification January 2006
65 The Domain Name System (DNS) is the global hierarchical replicated
66 distributed database system for Internet addressing, mail proxy, and
67 other information. Each node in the DNS tree has a name consisting
68 of zero or more labels [STD13, RFC1591, RFC2606] that are treated in
69 a case insensitive fashion. This document clarifies the meaning of
70 "case insensitive" for the DNS. This clarification updates RFCs
71 1034, 1035 [STD13], and [RFC2181].
73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
75 document are to be interpreted as described in [RFC2119].
772. Case Insensitivity of DNS Labels
79 DNS was specified in the era of [ASCII]. DNS names were expected to
80 look like most host names or Internet email address right halves (the
81 part after the at-sign, "@") or to be numeric, as in the in-addr.arpa
82 part of the DNS name space. For example,
87 or 69.2.0.192.in-addr.arpa.
89 Case-varied alternatives to the above [RFC3092] would be DNS names
95 or 69.2.0.192.in-ADDR.ARPA.
97 However, the individual octets of which DNS names consist are not
98 limited to valid ASCII character codes. They are 8-bit bytes, and
99 all values are allowed. Many applications, however, interpret them
1022.1. Escaping Unusual DNS Label Octets
104 In Master Files [STD13] and other human-readable and -writable ASCII
105 contexts, an escape is needed for the byte value for period (0x2E,
106 ".") and all octet values outside of the inclusive range from 0x21
107 ("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in
108 the two inclusive ranges from 0x00 to 0x20 and from 0x7F to 0xFF.
114Eastlake 3rd Standards Track [Page 2]
116RFC 4343 DNS Case Insensitivity Clarification January 2006
119 One typographic convention for octets that do not correspond to an
120 ASCII printing graphic is to use a back-slash followed by the value
121 of the octet as an unsigned integer represented by exactly three
124 The same convention can be used for printing ASCII characters so that
125 they will be treated as a normal label character. This includes the
126 back-slash character used in this convention itself, which can be
127 expressed as \092 or \\, and the special label separator period
128 ("."), which can be expressed as and \046 or \. It is advisable to
129 avoid using a backslash to quote an immediately following non-
130 printing ASCII character code to avoid implementation difficulties.
132 A back-slash followed by only one or two decimal digits is undefined.
133 A back-slash followed by four decimal digits produces two octets, the
134 first octet having the value of the first three digits considered as
135 a decimal number, and the second octet being the character code for
136 the fourth decimal digit.
1382.2. Example Labels with Escapes
140 The first example below shows embedded spaces and a period (".")
141 within a label. The second one shows a 5-octet label where the
142 second octet has all bits zero, the third is a backslash, and the
143 fourth octet has all bits one.
145 Donald\032E\.\032Eastlake\0323rd.example.
146 and a\000\\\255z.example.
1483. Name Lookup, Label Types, and CLASS
150 According to the original DNS design decision, comparisons on name
151 lookup for DNS queries should be case insensitive [STD13]. That is
152 to say, a lookup string octet with a value in the inclusive range
153 from 0x41 to 0x5A, the uppercase ASCII letters, MUST match the
154 identical value and also match the corresponding value in the
155 inclusive range from 0x61 to 0x7A, the lowercase ASCII letters. A
156 lookup string octet with a lowercase ASCII letter value MUST
157 similarly match the identical value and also match the corresponding
158 value in the uppercase ASCII letter range.
160 (Historical note: The terms "uppercase" and "lowercase" were invented
161 after movable type. The terms originally referred to the two font
162 trays for storing, in partitioned areas, the different physical type
163 elements. Before movable type, the nearest equivalent terms were
164 "majuscule" and "minuscule".)
170Eastlake 3rd Standards Track [Page 3]
172RFC 4343 DNS Case Insensitivity Clarification January 2006
175 One way to implement this rule would be to subtract 0x20 from all
176 octets in the inclusive range from 0x61 to 0x7A before comparing
177 octets. Such an operation is commonly known as "case folding", but
178 implementation via case folding is not required. Note that the DNS
179 case insensitivity does NOT correspond to the case folding specified
180 in [ISO-8859-1] or [ISO-8859-2]. For example, the octets 0xDD (\221)
181 and 0xFD (\253) do NOT match, although in other contexts, where they
182 are interpreted as the upper- and lower-case version of "Y" with an
183 acute accent, they might.
1853.1. Original DNS Label Types
187 DNS labels in wire-encoded names have a type associated with them.
188 The original DNS standard [STD13] had only two types: ASCII labels,
189 with a length from zero to 63 octets, and indirect (or compression)
190 labels, which consist of an offset pointer to a name location
191 elsewhere in the wire encoding on a DNS message. (The ASCII label of
192 length zero is reserved for use as the name of the root node of the
193 name tree.) ASCII labels follow the ASCII case conventions described
194 herein and, as stated above, can actually contain arbitrary byte
195 values. Indirect labels are, in effect, replaced by the name to
196 which they point, which is then treated with the case insensitivity
197 rules in this document.
1993.2. Extended Label Type Case Insensitivity Considerations
201 DNS was extended by [RFC2671] so that additional label type numbers
202 would be available. (The only such type defined so far is the BINARY
203 type [RFC2673], which is now Experimental [RFC3363].)
205 The ASCII case insensitivity conventions only apply to ASCII labels;
206 that is to say, label type 0x0, whether appearing directly or invoked
2093.3. CLASS Case Insensitivity Considerations
211 As described in [STD13] and [RFC2929], DNS has an additional axis for
212 data location called CLASS. The only CLASS in global use at this
213 time is the "IN" (Internet) CLASS.
215 The handling of DNS label case is not CLASS dependent. With the
216 original design of DNS, it was intended that a recursive DNS resolver
217 be able to handle new CLASSes that were unknown at the time of its
218 implementation. This requires uniform handling of label case
219 insensitivity. Should it become desirable, for example, to allocate
220 a CLASS with "case sensitive ASCII labels", it would be necessary to
221 allocate a new label type for these labels.
226Eastlake 3rd Standards Track [Page 4]
228RFC 4343 DNS Case Insensitivity Clarification January 2006
2314. Case on Input and Output
233 While ASCII label comparisons are case insensitive, [STD13] says case
234 MUST be preserved on output and preserved when convenient on input.
235 However, this means less than it would appear, since the preservation
236 of case on output is NOT required when output is optimized by the use
237 of indirect labels, as explained below.
2394.1. DNS Output Case Preservation
241 [STD13] views the DNS namespace as a node tree. ASCII output is as
242 if a name were marshaled by taking the label on the node whose name
243 is to be output, converting it to a typographically encoded ASCII
244 string, walking up the tree outputting each label encountered, and
245 preceding all labels but the first with a period ("."). Wire output
246 follows the same sequence, but each label is wire encoded, and no
247 periods are inserted. No "case conversion" or "case folding" is done
248 during such output operations, thus "preserving" case. However, to
249 optimize output, indirect labels may be used to point to names
250 elsewhere in the DNS answer. In determining whether the name to be
251 pointed to (for example, the QNAME) is the "same" as the remainder of
252 the name being optimized, the case insensitive comparison specified
253 above is done. Thus, such optimization may easily destroy the output
254 preservation of case. This type of optimization is commonly called
2574.2. DNS Input Case Preservation
259 Originally, DNS data came from an ASCII Master File as defined in
260 [STD13] or a zone transfer. DNS Dynamic update and incremental zone
261 transfers [RFC1995] have been added as a source of DNS data [RFC2136,
262 RFC3007]. When a node in the DNS name tree is created by any of such
263 inputs, no case conversion is done. Thus, the case of ASCII labels
264 is preserved if they are for nodes being created. However, when a
265 name label is input for a node that already exists in DNS data being
266 held, the situation is more complex. Implementations are free to
267 retain the case first loaded for such a label, to allow new input to
268 override the old case, or even to maintain separate copies preserving
271 For example, if data with owner name "foo.bar.example" [RFC3092] is
272 loaded and then later data with owner name "xyz.BAR.example" is
273 input, the name of the label on the "bar.example" node (i.e., "bar")
274 might or might not be changed to "BAR" in the DNS stored data. Thus,
275 later retrieval of data stored under "xyz.bar.example" in this case
276 can use "xyz.BAR.example" in all returned data, use "xyz.bar.example"
277 in all returned data, or even, when more than one RR is being
278 returned, use a mixture of these two capitalizations. This last case
282Eastlake 3rd Standards Track [Page 5]
284RFC 4343 DNS Case Insensitivity Clarification January 2006
287 is unlikely, as optimization of answer length through indirect labels
288 tends to cause only one copy of the name tail ("bar.example" or
289 "BAR.example") to be used for all returned RRs. Note that none of
290 this has any effect on the number or completeness of the RR set
291 returned, only on the case of the names in the RR set returned.
293 The same considerations apply when inputting multiple data records
294 with owner names differing only in case. For example, if an "A"
295 record is the first resource record stored under owner name
296 "xyz.BAR.example" and then a second "A" record is stored under
297 "XYZ.BAR.example", the second MAY be stored with the first (lower
298 case initial label) name, the second MAY override the first so that
299 only an uppercase initial label is retained, or both capitalizations
300 MAY be kept in the DNS stored data. In any case, a retrieval with
301 either capitalization will retrieve all RRs with either
304 Note that the order of insertion into a server database of the DNS
305 name tree nodes that appear in a Master File is not defined so that
306 the results of inconsistent capitalization in a Master File are
307 unpredictable output capitalization.
3095. Internationalized Domain Names
311 A scheme has been adopted for "internationalized domain names" and
312 "internationalized labels" as described in [RFC3490, RFC3454,
313 RFC3491, and RFC3492]. It makes most of [UNICODE] available through
314 a separate application level transformation from internationalized
315 domain name to DNS domain name and from DNS domain name to
316 internationalized domain name. Any case insensitivity that
317 internationalized domain names and labels have varies depending on
318 the script and is handled entirely as part of the transformation
319 described in [RFC3454] and [RFC3491], which should be seen for
320 further details. This is not a part of the DNS as standardized in
3236. Security Considerations
325 The equivalence of certain DNS label types with case differences, as
326 clarified in this document, can lead to security problems. For
327 example, a user could be confused by believing that two domain names
328 differing only in case were actually different names.
330 Furthermore, a domain name may be used in contexts other than the
331 DNS. It could be used as a case sensitive index into some database
332 or file system. Or it could be interpreted as binary data by some
333 integrity or authentication code system. These problems can usually
334 be handled by using a standardized or "canonical" form of the DNS
338Eastlake 3rd Standards Track [Page 6]
340RFC 4343 DNS Case Insensitivity Clarification January 2006
343 ASCII type labels; that is, always mapping the ASCII letter value
344 octets in ASCII labels to some specific pre-chosen case, either
345 uppercase or lower case. An example of a canonical form for domain
346 names (and also a canonical ordering for them) appears in Section 6
347 of [RFC4034]. See also [RFC3597].
349 Finally, a non-DNS name may be stored into DNS with the false
350 expectation that case will always be preserved. For example,
351 although this would be quite rare, on a system with case sensitive
352 email address local parts, an attempt to store two Responsible Person
353 (RP) [RFC1183] records that differed only in case would probably
354 produce unexpected results that might have security implications.
355 That is because the entire email address, including the possibly case
356 sensitive local or left-hand part, is encoded into a DNS name in a
357 readable fashion where the case of some letters might be changed on
358 output as described above.
362 The contributions to this document by Rob Austein, Olafur
363 Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
364 Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman
365 are gratefully acknowledged.
369 [ASCII] ANSI, "USA Standard Code for Information Interchange",
370 X3.4, American National Standards Institute: New York,
373 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
377 Requirement Levels", BCP 14, RFC 2119, March 1997.
379 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
380 "Dynamic Updates in the Domain Name System (DNS
381 UPDATE)", RFC 2136, April 1997.
383 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
384 Specification", RFC 2181, July 1997.
386 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
387 Update", RFC 3007, November 2000.
394Eastlake 3rd Standards Track [Page 7]
396RFC 4343 DNS Case Insensitivity Clarification January 2006
399 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
400 (RR) Types", RFC 3597, September 2003.
402 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
403 Rose, "Resource Records for the DNS Security
404 Extensions", RFC 4034, March 2005.
406 [STD13] Mockapetris, P., "Domain names - concepts and
407 facilities", STD 13, RFC 1034, November 1987.
409 Mockapetris, P., "Domain names - implementation and
410 specification", STD 13, RFC 1035, November 1987.
412Informative References
414 [ISO-8859-1] International Standards Organization, Standard for
415 Character Encodings, Latin-1.
417 [ISO-8859-2] International Standards Organization, Standard for
418 Character Encodings, Latin-2.
420 [RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P.
421 Mockapetris, "New DNS RR Definitions", RFC 1183, October
424 [RFC1591] Postel, J., "Domain Name System Structure and
425 Delegation", RFC 1591, March 1994.
427 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
428 Names", BCP 32, RFC 2606, June 1999.
430 [RFC2929] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
431 "Domain Name System (DNS) IANA Considerations", BCP 42,
432 RFC 2929, September 2000.
434 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
437 [RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
438 RFC 2673, August 1999.
440 [RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology
441 of "Foo"", RFC 3092, 1 April 2001.
443 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
444 Hain, "Representing Internet Protocol version 6 (IPv6)
445 Addresses in the Domain Name System (DNS)", RFC 3363,
450Eastlake 3rd Standards Track [Page 8]
452RFC 4343 DNS Case Insensitivity Clarification January 2006
455 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
456 Internationalized Strings ("stringprep")", RFC 3454,
459 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
460 "Internationalizing Domain Names in Applications
461 (IDNA)", RFC 3490, March 2003.
463 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
464 Profile for Internationalized Domain Names (IDN)", RFC
467 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of
468 Unicode for Internationalized Domain Names in
469 Applications (IDNA)", RFC 3492, March 2003.
471 [UNICODE] The Unicode Consortium, "The Unicode Standard",
472 <http://www.unicode.org/unicode/standard/standard.html>.
476 Donald E. Eastlake 3rd
477 Motorola Laboratories
479 Milford, MA 01757 USA
481 Phone: +1 508-786-7554 (w)
482 EMail: Donald.Eastlake@motorola.com
506Eastlake 3rd Standards Track [Page 9]
508RFC 4343 DNS Case Insensitivity Clarification January 2006
511Full Copyright Statement
513 Copyright (C) The Internet Society (2006).
515 This document is subject to the rights, licenses and restrictions
516 contained in BCP 78, and except as set forth therein, the authors
517 retain all their rights.
519 This document and the information contained herein are provided on an
520 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
521 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
522 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
523 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
524 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
525 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
529 The IETF takes no position regarding the validity or scope of any
530 Intellectual Property Rights or other rights that might be claimed to
531 pertain to the implementation or use of the technology described in
532 this document or the extent to which any license under such rights
533 might or might not be available; nor does it represent that it has
534 made any independent effort to identify any such rights. Information
535 on the procedures with respect to rights in RFC documents can be
536 found in BCP 78 and BCP 79.
538 Copies of IPR disclosures made to the IETF Secretariat and any
539 assurances of licenses to be made available, or the result of an
540 attempt made to obtain a general license or permission for the use of
541 such proprietary rights by implementers or users of this
542 specification can be obtained from the IETF on-line IPR repository at
543 http://www.ietf.org/ipr.
545 The IETF invites any interested party to bring to its attention any
546 copyrights, patents or patent applications, or other proprietary
547 rights that may cover technology that may be required to implement
548 this standard. Please address the information to the IETF at
553 Funding for the RFC Editor function is provided by the IETF
554 Administrative Support Activity (IASA).
562Eastlake 3rd Standards Track [Page 10]