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