rfc4343.txt

来自「非常好的dns解析软件」· 文本 代码 · 共 564 行 · 第 1/2 页


RFC 4343          DNS Case Insensitivity Clarification      January 2006


   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.

5.  Internationalized Domain Names

   A scheme has been adopted for "internationalized domain names" and
   "internationalized labels" as described in [RFC3490, RFC3454,
   RFC3491, and RFC3492].  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 [RFC3454] and [RFC3491], 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 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



Eastlake 3rd                Standards Track                     [Page 6]

RFC 4343          DNS Case Insensitivity Clarification      January 2006


   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 Section 6
   of [RFC4034].  See also [RFC3597].

   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) [RFC1183] 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.

7.  Acknowledgements

   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

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

   [RFC1995]    Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
                August 1996.

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

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

   [RFC2181]     Elz, R. and R. Bush, "Clarifications to the DNS
                Specification", RFC 2181, July 1997.

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






Eastlake 3rd                Standards Track                     [Page 7]

RFC 4343          DNS Case Insensitivity Clarification      January 2006


   [RFC3597]    Gustafsson, A., "Handling of Unknown DNS Resource Record
                (RR) Types", RFC 3597, September 2003.

   [RFC4034]    Arends, R., Austein, R., Larson, M., Massey, D., and S.
                Rose, "Resource Records for the DNS Security
                Extensions", RFC 4034, March 2005.

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

                Mockapetris, P., "Domain names - implementation and
                specification", STD 13, RFC 1035, November 1987.

Informative References

   [ISO-8859-1] International Standards Organization, Standard for
                Character Encodings, Latin-1.

   [ISO-8859-2] International Standards Organization, Standard for
                Character Encodings, Latin-2.

   [RFC1183]    Everhart, C., Mamakos, L., Ullmann, R., and P.
                Mockapetris, "New DNS RR Definitions", RFC 1183, October
                1990.

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

   [RFC2606]    Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
                Names", BCP 32, RFC 2606, June 1999.

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

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

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

   [RFC3092]    Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology
                of "Foo"", RFC 3092, 1 April 2001.

   [RFC3363]    Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
                Hain, "Representing Internet Protocol version 6 (IPv6)
                Addresses in the Domain Name System (DNS)", RFC 3363,
                August 2002.



Eastlake 3rd                Standards Track                     [Page 8]

RFC 4343          DNS Case Insensitivity Clarification      January 2006


   [RFC3454]    Hoffman, P. and M. Blanchet, "Preparation of
                Internationalized Strings ("stringprep")", RFC 3454,
                December 2002.

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

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

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

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

Author's Address

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

   Phone: [phone] (w)
   EMail: [e-mail]























Eastlake 3rd                Standards Track                     [Page 9]

RFC 4343          DNS Case Insensitivity Clarification      January 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, 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 BCP 78 and BCP 79.

   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
   http://www.ietf.org/ipr.

   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
   [e-mail].

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).







Eastlake 3rd                Standards Track                    [Page 10]