2
INTERNET-DRAFT Donald E. Eastlake 3rd
3
Updates RFC 1034, 1035 Motorola Laboratories
4
Expires January 2006 July 2005
8
Domain Name System (DNS) Case Insensitivity Clarification
9
------ ---- ------ ----- ---- ------------- -------------
10
<draft-ietf-dnsext-insensitive-06.txt>
12
Donald E. Eastlake 3rd
16
Status of This Document
18
By submitting this Internet-Draft, each author represents that any
19
applicable patent or other IPR claims of which he or she is aware
20
have been or will be disclosed, and any of which he or she becomes
21
aware will be disclosed, in accordance with Section 6 of BCP 79.
23
Distribution of this document is unlimited. Comments should be sent
24
to the DNSEXT working group at namedroppers@ops.ietf.org.
26
Internet-Drafts are working documents of the Internet Engineering
27
Task Force (IETF), its areas, and its working groups. Note that
28
other groups may also distribute working documents as Internet-
31
Internet-Drafts are draft documents valid for a maximum of six months
32
and may be updated, replaced, or obsoleted by other documents at any
33
time. It is inappropriate to use Internet-Drafts as reference
34
material or to cite them other than a "work in progress."
36
The list of current Internet-Drafts can be accessed at
37
http://www.ietf.org/1id-abstracts.html
39
The list of Internet-Draft Shadow Directories can be accessed at
40
http://www.ietf.org/shadow.html
46
Copyright (C) The Internet Society (2005). All Rights Reserved.
52
Domain Name System (DNS) names are "case insensitive". This document
53
explains exactly what that means and provides a clear specification
54
of the rules. This clarification updates RFCs 1034 and 1035.
57
D. Eastlake 3rd [Page 1]
60
INTERNET-DRAFT DNS Case Insensitivity
65
The contributions to this document of Rob Austein, Olafur
66
Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
67
Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman
68
are gratefully acknowledged.
74
Status of This Document....................................1
75
Copyright Notice...........................................1
76
Abstract...................................................1
78
Acknowledgements...........................................2
79
Table of Contents..........................................2
81
1. Introduction............................................3
82
2. Case Insensitivity of DNS Labels........................3
83
2.1 Escaping Unusual DNS Label Octets......................3
84
2.2 Example Labels with Escapes............................4
85
3. Name Lookup, Label Types, and CLASS.....................4
86
3.1 Original DNS Label Types...............................5
87
3.2 Extended Label Type Case Insensitivity Considerations..5
88
3.3 CLASS Case Insensitivity Considerations................5
89
4. Case on Input and Output................................6
90
4.1 DNS Output Case Preservation...........................6
91
4.2 DNS Input Case Preservation............................6
92
5. Internationalized Domain Names..........................7
93
6. Security Considerations.................................8
95
Copyright and Disclaimer...................................9
96
Normative References.......................................9
97
Informative References....................................10
99
Changes Between Draft Version.............................11
100
-02 to -03 Changes........................................11
101
-03 to -04 Changes........................................11
102
-04 to -05 Changes........................................11
103
-05 to -06 Changes........................................12
105
Author's Address..........................................13
106
Expiration and File Name..................................13
115
D. Eastlake 3rd [Page 2]
118
INTERNET-DRAFT DNS Case Insensitivity
123
The Domain Name System (DNS) is the global hierarchical replicated
124
distributed database system for Internet addressing, mail proxy, and
125
other information. Each node in the DNS tree has a name consisting of
126
zero or more labels [STD 13][RFC 1591, 2606] that are treated in a
127
case insensitive fashion. This document clarifies the meaning of
128
"case insensitive" for the DNS. This clarification updates RFCs 1034
131
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
132
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
133
document are to be interpreted as described in [RFC 2119].
137
2. Case Insensitivity of DNS Labels
139
DNS was specified in the era of [ASCII]. DNS names were expected to
140
look like most host names or Internet email address right halves (the
141
part after the at-sign, "@") or be numeric as in the in-addr.arpa
142
part of the DNS name space. For example,
147
or 69.2.0.192.in-addr.arpa.
149
Case varied alternatives to the above would be DNS names like
154
or 69.2.0.192.in-ADDR.ARPA.
156
However, the individual octets of which DNS names consist are not
157
limited to valid ASCII character codes. They are 8-bit bytes and all
158
values are allowed. Many applications, however, interpret them as
163
2.1 Escaping Unusual DNS Label Octets
165
In Master Files [STD 13] and other human readable and writable ASCII
166
contexts, an escape is needed for the byte value for period (0x2E,
167
".") and all octet values outside of the inclusive range of 0x21
168
("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in
169
the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF.
173
D. Eastlake 3rd [Page 3]
176
INTERNET-DRAFT DNS Case Insensitivity
179
One typographic convention for octets that do not correspond to an
180
ASCII printing graphic is to use a back-slash followed by the value
181
of the octet as an unsigned integer represented by exactly three
184
The same convention can be used for printing ASCII characters so that
185
they will be treated as a normal label character. This includes the
186
back-slash character used in this convention itself which can be
187
expressed as \092 or \\ and the special label separator period (".")
188
which can be expressed as and \046 or \. respectively. It is
189
advisable to avoid using a backslash to quote an immediately
190
following non-printing ASCII character code to avoid implementation
193
A back-slash followed by only one or two decimal digits is undefined.
194
A back-slash followed by four decimal digits produces two octets, the
195
first octet having the value of the first three digits considered as
196
a decimal number and the second octet being the character code for
197
the fourth decimal digit.
201
2.2 Example Labels with Escapes
203
The first example below shows embedded spaces and a period (".")
204
within a label. The second one show a 5-octet label where the second
205
octet has all bits zero, the third is a backslash, and the fourth
206
octet has all bits one.
208
Donald\032E\.\032Eastlake\0323rd.example.
209
and a\000\\\255z.example.
213
3. Name Lookup, Label Types, and CLASS
215
The original DNS design decision was made that comparisons on name
216
lookup for DNS queries should be case insensitive [STD 13]. That is
217
to say, a lookup string octet with a value in the inclusive range of
218
0x41 to 0x5A, the upper case ASCII letters, MUST match the identical
219
value and also match the corresponding value in the inclusive range
220
0x61 to 0x7A, the lower case ASCII letters. And a lookup string octet
221
with a lower case ASCII letter value MUST similarly match the
222
identical value and also match the corresponding value in the upper
223
case ASCII letter range.
225
(Historical Note: the terms "upper case" and "lower case" were
226
invented after movable type. The terms originally referred to the
227
two font trays for storing, in partitioned areas, the different
228
physical type elements. Before movable type, the nearest equivalent
231
D. Eastlake 3rd [Page 4]
234
INTERNET-DRAFT DNS Case Insensitivity
237
terms were "majuscule" and "minuscule".)
239
One way to implement this rule would be, when comparing octets, to
240
subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A
241
before the comparison. Such an operation is commonly known as "case
242
folding" but implementation via case folding is not required. Note
243
that the DNS case insensitivity does NOT correspond to the case
244
folding specified in [iso-8859-1] or [iso-8859-2]. For example, the
245
octets 0xDD (\221) and 0xFD (\253) do NOT match although in other
246
contexts, where they are interpreted as the upper and lower case
247
version of "Y" with an acute accent, they might.
251
3.1 Original DNS Label Types
253
DNS labels in wire-encoded names have a type associated with them.
254
The original DNS standard [RFC 1035] had only two types. ASCII
255
labels, with a length of from zero to 63 octets, and indirect (or
256
compression) labels which consist of an offset pointer to a name
257
location elsewhere in the wire encoding on a DNS message. (The ASCII
258
label of length zero is reserved for use as the name of the root node
259
of the name tree.) ASCII labels follow the ASCII case conventions
260
described herein and, as stated above, can actually contain arbitrary
261
byte values. Indirect labels are, in effect, replaced by the name to
262
which they point which is then treated with the case insensitivity
263
rules in this document.
267
3.2 Extended Label Type Case Insensitivity Considerations
269
DNS was extended by [RFC 2671] to have additional label type numbers
270
available. (The only such type defined so far is the BINARY type [RFC
271
2673] which is now Experimental [RFC 3363].)
273
The ASCII case insensitivity conventions only apply to ASCII labels,
274
that is to say, label type 0x0, whether appearing directly or invoked
279
3.3 CLASS Case Insensitivity Considerations
281
As described in [STD 13] and [RFC 2929], DNS has an additional axis
282
for data location called CLASS. The only CLASS in global use at this
283
time is the "IN" or Internet CLASS.
285
The handling of DNS label case is not CLASS dependent. With the
286
original design of DNS, it was intended that a recursive DNS resolver
289
D. Eastlake 3rd [Page 5]
292
INTERNET-DRAFT DNS Case Insensitivity
295
be able to handle new CLASSes that were unknown at the time of its
296
implementation. This requires uniform handling of label case
297
insensitivity. Should it become desireable, for example, to allocate
298
a CLASS with "case sensitive ASCII labels" for example, it would be
299
necessary to allocate a new label type for these labels.
303
4. Case on Input and Output
305
While ASCII label comparisons are case insensitive, [STD 13] says
306
case MUST be preserved on output, and preserved when convenient on
307
input. However, this means less than it would appear since the
308
preservation of case on output is NOT required when output is
309
optimized by the use of indirect labels, as explained below.
313
4.1 DNS Output Case Preservation
315
[STD 13] views the DNS namespace as a node tree. ASCII output is as
316
if a name was marshaled by taking the label on the node whose name is
317
to be output, converting it to a typographically encoded ASCII
318
string, walking up the tree outputting each label encountered, and
319
preceding all labels but the first with a period ("."). Wire output
320
follows the same sequence but each label is wire encoded and no
321
periods inserted. No "case conversion" or "case folding" is done
322
during such output operations, thus "preserving" case. However, to
323
optimize output, indirect labels may be used to point to names
324
elsewhere in the DNS answer. In determining whether the name to be
325
pointed to, for example the QNAME, is the "same" as the remainder of
326
the name being optimized, the case insensitive comparison specified
327
above is done. Thus such optimization may easily destroy the output
328
preservation of case. This type of optimization is commonly called
333
4.2 DNS Input Case Preservation
335
Originally, DNS data came from an ASCII Master File as defined in
336
[STD 13] or a zone transfer. DNS Dynamic update and incremental zone
337
transfers [RFC 1995] have been added as a source of DNS data [RFC
338
2136, 3007]. When a node in the DNS name tree is created by any of
339
such inputs, no case conversion is done. Thus the case of ASCII
340
labels is preserved if they are for nodes being created. However,
341
when a name label is input for a node that already exist in DNS data
342
being held, the situation is more complex. Implementations are free
343
to retain the case first loaded for such a label or allow new input
344
to override the old case or even maintain separate copies preserving
347
D. Eastlake 3rd [Page 6]
350
INTERNET-DRAFT DNS Case Insensitivity
355
For example, if data with owner name "foo.bar.example" is loaded and
356
then later data with owner name "xyz.BAR.example" is input, the name
357
of the label on the "bar.example" node, i.e. "bar", might or might
358
not be changed to "BAR" in the DNS stored data or the actual input
359
case could be preserved. Thus later retrieval of data stored under
360
"xyz.bar.example" in this case can return all data with
361
"xyz.BAR.example" or all data with "xyz.bar.example" or even, when
362
more than one RR is being returned, a mixture of these two cases.
363
This last case is unlikely because optimization of answer length
364
through indirect labels tends to cause only copy of the name tail
365
("bar.example" or "BAR.example") to be used for all returned RRs.
366
Note that none of this has any effect on the number of completeness
367
of the RR set returned, only on the case of the names in the RR set
370
The same considerations apply when inputting multiple data records
371
with owner names differing only in case. For example, if an "A"
372
record is the first resourced record stored under owner name
373
"xyz.BAR.example" and then a second "A" record is stored under
374
"XYZ.BAR.example", the second MAY be stored with the first (lower
375
case initial label) name or the second MAY override the first so that
376
only an upper case initial label is retained or both capitalizations
377
MAY be kept in the DNS stored data. In any case, a retrieval with
378
either capitalization will retrieve all RRs with either
381
Note that the order of insertion into a server database of the DNS
382
name tree nodes that appear in a Master File is not defined so that
383
the results of inconsistent capitalization in a Master File are
384
unpredictable output capitalization.
388
5. Internationalized Domain Names
390
A scheme has been adopted for "internationalized domain names" and
391
"internationalized labels" as described in [RFC 3490, 3454, 3491, and
392
3492]. It makes most of [UNICODE] available through a separate
393
application level transformation from internationalized domain name
394
to DNS domain name and from DNS domain name to internationalized
395
domain name. Any case insensitivity that internationalized domain
396
names and labels have varies depending on the script and is handled
397
entirely as part of the transformation described in [RFC 3454] and
398
[RFC 3491] which should be seen for further details. This is not a
399
part of the DNS as standardized in STD 13.
405
D. Eastlake 3rd [Page 7]
408
INTERNET-DRAFT DNS Case Insensitivity
411
6. Security Considerations
413
The equivalence of certain DNS label types with case differences, as
414
clarified in this document, can lead to security problems. For
415
example, a user could be confused by believing two domain names
416
differing only in case were actually different names.
418
Furthermore, a domain name may be used in contexts other than the
419
DNS. It could be used as a case sensitive index into some data base
420
or file system. Or it could be interpreted as binary data by some
421
integrity or authentication code system. These problems can usually
422
be handled by using a standardized or "canonical" form of the DNS
423
ASCII type labels, that is, always mapping the ASCII letter value
424
octets in ASCII labels to some specific pre-chosen case, either upper
425
case or lower case. An example of a canonical form for domain names
426
(and also a canonical ordering for them) appears in Section 6 of [RFC
427
4034]. See also [RFC 3597].
429
Finally, a non-DNS name may be stored into DNS with the false
430
expectation that case will always be preserved. For example, although
431
this would be quite rare, on a system with case sensitive email
432
address local parts, an attempt to store two "RP" records that
433
differed only in case would probably produce unexpected results that
434
might have security implications. That is because the entire email
435
address, including the possibly case sensitive local or left hand
436
part, is encoded into a DNS name in a readable fashion where the case
437
of some letters might be changed on output as described above.
463
D. Eastlake 3rd [Page 8]
466
INTERNET-DRAFT DNS Case Insensitivity
469
Copyright and Disclaimer
471
Copyright (C) The Internet Society (2005). This document is subject
472
to the rights, licenses and restrictions contained in BCP 78, and
473
except as set forth therein, the authors retain all their rights.
476
This document and the information contained herein are provided on an
477
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
478
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
479
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
480
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
481
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
482
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
488
[ASCII] - ANSI, "USA Standard Code for Information Interchange",
489
X3.4, American National Standards Institute: New York, 1968.
491
[RFC 1034, 1035] - See [STD 13].
493
[RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August
496
[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
497
Requirement Levels", March 1997.
499
[RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
500
"Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997.
502
[RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic
503
Update", November 2000.
505
[RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types",
506
draft-ietf-dnsext-unknown-rrs-05.txt, March 2003.
508
[RFC 4034} - Arends, R., Austein, R., Larson, M., Massey, D., and S.
509
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
513
- P. Mockapetris, "Domain names - concepts and facilities", RFC
515
- P. Mockapetris, "Domain names - implementation and
516
specification", RFC 1035, November 1987.
521
D. Eastlake 3rd [Page 9]
524
INTERNET-DRAFT DNS Case Insensitivity
527
Informative References
529
[ISO 8859-1] - International Standards Organization, Standard for
530
Character Encodings, Latin-1.
532
[ISO 8859-2] - International Standards Organization, Standard for
533
Character Encodings, Latin-2.
535
[RFC 1591] - J. Postel, "Domain Name System Structure and
536
Delegation", March 1994.
538
[RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
541
[RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain
542
Name System (DNS) IANA Considerations", September 2000.
544
[RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
547
[RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
550
[RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of
553
[RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
554
Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
555
the Domain Name System (DNS)", RFC 3363, August 2002.
557
[RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of
558
Internationalized String ("stringprep")", December 2002.
560
[RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,
561
"Internationalizing Domain Names in Applications (IDNA)", March 2003.
563
[RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
564
for Internationalized Domain Names (IDN)", March 2003.
566
[RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode
567
for Internationalized Domain Names in Applications (IDNA)", March
570
[UNICODE] - The Unicode Consortium, "The Unicode Standard",
571
<http://www.unicode.org/unicode/standard/standard.html>.
579
D. Eastlake 3rd [Page 10]
582
INTERNET-DRAFT DNS Case Insensitivity
585
Changes Between Draft Version
587
RFC Editor: The following summaries of changes between draft versions
588
are to be removed before publication.
594
The following changes were made between draft version -02 and -03:
596
1. Add internationalized domain name section and references.
598
2. Change to indicate that later input of a label for an existing DNS
599
name tree node may or may not be normalized to the earlier input or
600
override it or both may be preserved.
602
3. Numerous minor wording changes.
608
The following changes were made between draft versions -03 and -04:
610
1. Change to conform to the new IPR, Copyright, etc., notice
613
2. Change in some section headers for clarity.
615
3. Drop section on wildcards.
617
4. Add emphasis on loss of case preservation due to name compression.
619
5. Add references to RFCs 1995 and 3092.
625
The following changes were made between draft versions -04 and -05:
627
1. More clearly state that this draft updates RFCs 1034, 1035 [STD
630
2. Add informative references to ISO 8859-1 and ISO 8859-2.
632
3. Fix hyphenation and capitalization nits.
637
D. Eastlake 3rd [Page 11]
640
INTERNET-DRAFT DNS Case Insensitivity
645
The following changes were made between draft version -05 and -06.
647
1. Add notation to the RFC Editor that the draft version change
648
summaries are to be removed before RFC publication.
650
2. Additional text explaining why labe case insensitivity is CLASS
653
3. Changes and additional text clarifying that the fact that
654
inconsistent case in data loaded into DNS may result in
655
unpredicatable or inconsistent case in DNS storage but has no effect
656
on the completeness of RR sets retrieved.
658
4. Add reference to [RFC 3363] and update reference to [RFC 2535] to
695
D. Eastlake 3rd [Page 12]
698
INTERNET-DRAFT DNS Case Insensitivity
703
Donald E. Eastlake 3rd
704
Motorola Laboratories
706
Milford, MA 01757 USA
708
Telephone: +1 508-786-7554 (w)
710
EMail: Donald.Eastlake@motorola.com
714
Expiration and File Name
716
This draft expires January 2006.
718
Its file name is draft-ietf-dnsext-insensitive-06.txt.
753
D. Eastlake 3rd [Page 13]
added
removed
doc/draft/draft-ietf-dnsext-insensitive-06.txt
