draft-ietf-dnsext-insensitive-03.txt

bind-3.2.

INTERNET-DRAFT                                    DNS Case Insensitivity


   The ASCII case insensitivity conventions, or case folding, only apply
   to ASCII labels, that is to say, label type 0x0, whether appearing
   directly or invoked by indirect labels.



4. Case on Input and Output

   While ASCII label comparisons are case insensitive, case MUST be
   preserved on output, except when output is optimized by the use of
   indirect labels, and preserved when convenient on input.



4.1 DNS Output Case Preservation

   [STD 13] views the DNS namespace as a node tree. ASCII output is as
   if a name was marshalled 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 inserted. No "case conversion" or "case folding" is done
   during such output operations.  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 is the "same" as the
   remainder of the name being optimized, the case insensitive
   comparison specified above is done. Thus such optimization MAY
   destroy the output preservation of case. This type of optimization is
   commonly called "name compression".



4.2 DNS Input Case Preservation

   Originally, DNS input came from an ASCII Master File as defined in
   [STD 13]. DNS Dynamic update has been added as a source of DNS data
   [RFC 2136, 3007]. When a node in the DNS name tree is created by such
   input, no case conversion is done and 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 exist in DNS data being
   augmented or updated, the situation is more complex. Implemenations
   may retain the case first input for such a label or allow new input
   to override the old case or maintain separate copies preserving the
   input case.

   For example, if data with owner name "foo.bar.example" is input 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" or the actual input case could be preserved.


D. Eastlake 3rd                                                 [Page 6]


INTERNET-DRAFT                                    DNS Case Insensitivity


   Thus later retrieval of data stored under "xyz.bar.example" in this
   case can easily result is obtaining data with "xyz.BAR.example".  The
   same considerations apply when inputting multiple data records with
   owner names differing only in case. From the example above, if an "A"
   record is stored under owner name "xyz.BAR.example" and then a second
   "A" record under "XYZ.BAR.example", the second MAY be stored with the
   first (lower case initial label) name.

   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
   unpredicatable output capitalization.



4.3 Wildcard Matching

   There is one additional instance of note, which reflects the general
   rules that output case reflects input case unless there is
   conflicting capitalization in the DNS database or the output case is
   hidden by name compression. This is when a query matches a wildcard
   in the DNS database at a server. In that case, the answer SHOULD
   reflect the input case of the label or labels that matched the
   wildcard unless they are replaced by an indirect label which MAY
   point to a name with different capitalization.



5. Internationalized Domain Names

   A scheme has been adopted for "internationalized domain names" and
   "internationalized labels" as described in [RFC 3490, 3454, 3491, and
   3492]. It makes most of [UNICODE] 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 [RFC 3454] and
   [RFC 3491] which should be seen for further details.  This is not a
   part of the DNS as standardized in STD 13.



6. Security Considerations

   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 two domain names
   differing only in case were actually different names.



D. Eastlake 3rd                                                 [Page 7]


INTERNET-DRAFT                                    DNS Case Insensitivity


   Furthermore, a domain name may be used in contexts other than the
   DNS.  It could be used as a case sensitive index into some data base
   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 ASCII type
   labels, that is, always map the ASCII letter value octets in ASCII
   labels to some specific pre-chosen case, either upper case or lower
   case. An example of a canonical form for domain names (and also a
   canonical ordering for them) appears in Section 8 of [RFC 2535]. See
   also [UNKRR].

   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 "RP" 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.
































D. Eastlake 3rd                                                 [Page 8]


INTERNET-DRAFT                                    DNS Case Insensitivity


Normative References

   [ASCII] - ANSI, "USA Standard Code for Information Interchange",
   X3.4, American National Standards Institute: New York, 1968.

   [RFC 1034, 1035] - See [STD 13].

   [RFC 2119] - "Key words for use in RFCs to Indicate Requirement
   Levels", S.  Bradner, March 1997.

   [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
   "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997.

   [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
   March 1999.

   [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic
   Update", November 2000.

   [STD 13]
       - P. Mockapetris, "Domain names - concepts and facilities", RFC
   1034, November 1987.
       - P. Mockapetris, "Domain names - implementation and
   specification", RFC 1035, November 1987.

   [UNKRR] - Andreas Gustafsson, "Handling of Unknown DNS RR Types",
   draft-ietf-dnsext-unknown-rrs-05.txt, March 2003.



Informative References

   [RFC 1591] - J. Postel, "Domain Name System Structure and
   Delegation", March 1994.

   [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
   June 1999.

   [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain
   Name System (DNS) IANA Considerations", September 2000.

   [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
   1999.

   [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
   August 1999.

   [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of
   Internationalized String ("stringprep")", December 2002.



D. Eastlake 3rd                                                 [Page 9]


INTERNET-DRAFT                                    DNS Case Insensitivity


   [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,
   "Internationalizing Domain Names in Applications (IDNA)", March 2003.

   [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
   for Internationalized Domain Names (IDN)", March 2003.

   [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode
   for Internationalized Domain Names in Applications (IDNA)", March
   2003.

   [UNICODE] - The Unicode Consortium, "The Unicode Standard",
   <http://www.unicode.org/unicode/standard/standard.html>.



-02 to -03 Changes

   The following changes were made between draft version -02 and -03:

   1. Add internationalized domain name section and references.

   2. Change to indicate that later input of a label for an existing DNS
   name tree node may or may not be normalized to the earlier input or
   override it or both may be preserved.

   3. Numerous minor wording changes.



Author's Address

   Donald E. Eastlake 3rd
   Motorola Laboratories
   155 Beaver Street
   Milford, MA 01757 USA

   Telephone:   [phone] (w)
                [phone] (h)
   EMail:       [e-mail]



Expiration and File Name

   This draft expires September 2003.

   Its file name is draft-ietf-dnsext-insensitive-03.txt.





D. Eastlake 3rd                                                [Page 10]