contrib/bind9/doc/rfc/rfc4343.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                    D. Eastlake 3rd
   8 Request for Comments: 4343                         Motorola Laboratories
   9 Updates: 1034, 1035, 2181                                   January 2006
  10 Category: Standards Track
  11
  12
  13        Domain Name System (DNS) Case Insensitivity Clarification
  14
  15 Status of This Memo
  16
  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.
  22
  23 Copyright Notice
  24
  25    Copyright (C) The Internet Society (2006).
  26
  27 Abstract
  28
  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.
  32
  33 Table of Contents
  34
  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
  51
  52
  53
  54
  55
  56
  57
  58 Eastlake 3rd                Standards Track                     [Page 1]
  59 \f
  60 RFC 4343          DNS Case Insensitivity Clarification      January 2006
  61
  62
  63 1.  Introduction
  64
  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].
  72
  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].
  76
  77 2.  Case Insensitivity of DNS Labels
  78
  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,
  83
  84        foo.example.net.
  85        aol.com.
  86        www.gnu.ai.mit.edu.
  87    or  69.2.0.192.in-addr.arpa.
  88
  89    Case-varied alternatives to the above [RFC3092] would be DNS names
  90    like
  91
  92        Foo.ExamplE.net.
  93        AOL.COM.
  94        WWW.gnu.AI.mit.EDU.
  95    or  69.2.0.192.in-ADDR.ARPA.
  96
  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
 100    as ASCII characters.
 101
 102 2.1.  Escaping Unusual DNS Label Octets
 103
 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.
 109
 110
 111
 112
 113
 114 Eastlake 3rd                Standards Track                     [Page 2]
 115 \f
 116 RFC 4343          DNS Case Insensitivity Clarification      January 2006
 117
 118
 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
 122    decimal digits.
 123
 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.
 131
 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.
 137
 138 2.2.  Example Labels with Escapes
 139
 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.
 144
 145          Donald\032E\.\032Eastlake\0323rd.example.
 146    and   a\000\\\255z.example.
 147
 148 3.  Name Lookup, Label Types, and CLASS
 149
 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.
 159
 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".)
 165
 166
 167
 168
 169
 170 Eastlake 3rd                Standards Track                     [Page 3]
 171 \f
 172 RFC 4343          DNS Case Insensitivity Clarification      January 2006
 173
 174
 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.
 184
 185 3.1.  Original DNS Label Types
 186
 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.
 198
 199 3.2.  Extended Label Type Case Insensitivity Considerations
 200
 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].)
 204
 205    The ASCII case insensitivity conventions only apply to ASCII labels;
 206    that is to say, label type 0x0, whether appearing directly or invoked
 207    by indirect labels.
 208
 209 3.3.  CLASS Case Insensitivity Considerations
 210
 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.
 214
 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.
 222
 223
 224
 225
 226 Eastlake 3rd                Standards Track                     [Page 4]
 227 \f
 228 RFC 4343          DNS Case Insensitivity Clarification      January 2006
 229
 230
 231 4.  Case on Input and Output
 232
 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.
 238
 239 4.1.  DNS Output Case Preservation
 240
 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
 255    "name compression".
 256
 257 4.2.  DNS Input Case Preservation
 258
 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
 269    the input case.
 270
 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
 279
 280
 281
 282 Eastlake 3rd                Standards Track                     [Page 5]
 283 \f
 284 RFC 4343          DNS Case Insensitivity Clarification      January 2006
 285
 286
 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.
 292
 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
 302    capitalization.
 303
 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.
 308
 309 5.  Internationalized Domain Names
 310
 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
 321    STD 13.
 322
 323 6.  Security Considerations
 324
 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.
 329
 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
 335
 336
 337
 338 Eastlake 3rd                Standards Track                     [Page 6]
 339 \f
 340 RFC 4343          DNS Case Insensitivity Clarification      January 2006
 341
 342
 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].
 348
 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.
 359
 360 7.  Acknowledgements
 361
 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.
 366
 367 Normative References
 368
 369    [ASCII]      ANSI, "USA Standard Code for Information Interchange",
 370                 X3.4, American National Standards Institute: New York,
 371                 1968.
 372
 373    [RFC1995]    Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
 374                 August 1996.
 375
 376    [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
 377                 Requirement Levels", BCP 14, RFC 2119, March 1997.
 378
 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.
 382
 383    [RFC2181]     Elz, R. and R. Bush, "Clarifications to the DNS
 384                 Specification", RFC 2181, July 1997.
 385
 386    [RFC3007]    Wellington, B., "Secure Domain Name System (DNS) Dynamic
 387                 Update", RFC 3007, November 2000.
 388
 389
 390
 391
 392
 393
 394 Eastlake 3rd                Standards Track                     [Page 7]
 395 \f
 396 RFC 4343          DNS Case Insensitivity Clarification      January 2006
 397
 398
 399    [RFC3597]    Gustafsson, A., "Handling of Unknown DNS Resource Record
 400                 (RR) Types", RFC 3597, September 2003.
 401
 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.
 405
 406    [STD13]      Mockapetris, P., "Domain names - concepts and
 407                 facilities", STD 13, RFC 1034, November 1987.
 408
 409                 Mockapetris, P., "Domain names - implementation and
 410                 specification", STD 13, RFC 1035, November 1987.
 411
 412 Informative References
 413
 414    [ISO-8859-1] International Standards Organization, Standard for
 415                 Character Encodings, Latin-1.
 416
 417    [ISO-8859-2] International Standards Organization, Standard for
 418                 Character Encodings, Latin-2.
 419
 420    [RFC1183]    Everhart, C., Mamakos, L., Ullmann, R., and P.
 421                 Mockapetris, "New DNS RR Definitions", RFC 1183, October
 422                 1990.
 423
 424    [RFC1591]    Postel, J., "Domain Name System Structure and
 425                 Delegation", RFC 1591, March 1994.
 426
 427    [RFC2606]    Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
 428                 Names", BCP 32, RFC 2606, June 1999.
 429
 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.
 433
 434    [RFC2671]    Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
 435                 2671, August 1999.
 436
 437    [RFC2673]    Crawford, M., "Binary Labels in the Domain Name System",
 438                 RFC 2673, August 1999.
 439
 440    [RFC3092]    Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology
 441                 of "Foo"", RFC 3092, 1 April 2001.
 442
 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,
 446                 August 2002.
 447
 448
 449
 450 Eastlake 3rd                Standards Track                     [Page 8]
 451 \f
 452 RFC 4343          DNS Case Insensitivity Clarification      January 2006
 453
 454
 455    [RFC3454]    Hoffman, P. and M. Blanchet, "Preparation of
 456                 Internationalized Strings ("stringprep")", RFC 3454,
 457                 December 2002.
 458
 459    [RFC3490]    Faltstrom, P., Hoffman, P., and A. Costello,
 460                 "Internationalizing Domain Names in Applications
 461                 (IDNA)", RFC 3490, March 2003.
 462
 463    [RFC3491]    Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
 464                 Profile for Internationalized Domain Names (IDN)", RFC
 465                 3491, March 2003.
 466
 467    [RFC3492]    Costello, A., "Punycode: A Bootstring encoding of
 468                 Unicode for Internationalized Domain Names in
 469                 Applications (IDNA)", RFC 3492, March 2003.
 470
 471    [UNICODE]    The Unicode Consortium, "The Unicode Standard",
 472                 <http://www.unicode.org/unicode/standard/standard.html>.
 473
 474 Author's Address
 475
 476    Donald E. Eastlake 3rd
 477    Motorola Laboratories
 478    155 Beaver Street
 479    Milford, MA 01757 USA
 480
 481    Phone: +1 508-786-7554 (w)
 482    EMail: Donald.Eastlake@motorola.com
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506 Eastlake 3rd                Standards Track                     [Page 9]
 507 \f
 508 RFC 4343          DNS Case Insensitivity Clarification      January 2006
 509
 510
 511 Full Copyright Statement
 512
 513    Copyright (C) The Internet Society (2006).
 514
 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.
 518
 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.
 526
 527 Intellectual Property
 528
 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.
 537
 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.
 544
 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
 549    ietf-ipr@ietf.org.
 550
 551 Acknowledgement
 552
 553    Funding for the RFC Editor function is provided by the IETF
 554    Administrative Support Activity (IASA).
 555
 556
 557
 558
 559
 560
 561
 562 Eastlake 3rd                Standards Track                    [Page 10]
 563 \f