rfc3490.txt

bind 9.3结合mysql数据库

   encodings of the same domain name.

   [RFC2181] explicitly allows domain labels to contain octets beyond
   the ASCII range (0..7F), and this document does not change that.
   Note, however, that there is no defined interpretation of octets
   80..FF as characters.  If labels containing these octets are returned
   to applications, unpredictable behavior could result.  The ASCII form
   defined by ToASCII is the only standard representation for
   internationalized labels in the current DNS protocol.

8. Root server considerations

   IDNs are likely to be somewhat longer than current domain names, so
   the bandwidth needed by the root servers is likely to go up by a
   small amount.  Also, queries and responses for IDNs will probably be
   somewhat longer than typical queries today, so more queries and
   responses may be forced to go to TCP instead of UDP.









Faltstrom, et al.           Standards Track                    [Page 17]

RFC 3490                          IDNA                        March 2003


9. References

9.1 Normative References

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

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

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

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

   [STD3]       Braden, R., "Requirements for Internet Hosts --
                Communication Layers", STD 3, RFC 1122, and
                "Requirements for Internet Hosts -- Application and
                Support", STD 3, RFC 1123, October 1989.

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

9.2 Informative References

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

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

   [UAX9]       Unicode Standard Annex #9, The Bidirectional Algorithm,
                <http://www.unicode.org/unicode/reports/tr9/>.

   [UNICODE]    The Unicode Consortium. The Unicode Standard, Version
                3.2.0 is defined by The Unicode Standard, Version 3.0
                (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
                as amended by the Unicode Standard Annex #27: Unicode
                3.1 (http://www.unicode.org/reports/tr27/) and by the
                Unicode Standard Annex #28: Unicode 3.2
                (http://www.unicode.org/reports/tr28/).




Faltstrom, et al.           Standards Track                    [Page 18]

RFC 3490                          IDNA                        March 2003


   [USASCII]    Cerf, V., "ASCII format for Network Interchange", RFC
                20, October 1969.

10. Security Considerations

   Security on the Internet partly relies on the DNS.  Thus, any change
   to the characteristics of the DNS can change the security of much of
   the Internet.

   This memo describes an algorithm which encodes characters that are
   not valid according to STD3 and STD13 into octet values that are
   valid.  No security issues such as string length increases or new
   allowed values are introduced by the encoding process or the use of
   these encoded values, apart from those introduced by the ACE encoding
   itself.

   Domain names are used by users to identify and connect to Internet
   servers.  The security of the Internet is compromised if a user
   entering a single internationalized name is connected to different
   servers based on different interpretations of the internationalized
   domain name.

   When systems use local character sets other than ASCII and Unicode,
   this specification leaves the the problem of transcoding between the
   local character set and Unicode up to the application.  If different
   applications (or different versions of one application) implement
   different transcoding rules, they could interpret the same name
   differently and contact different servers.  This problem is not
   solved by security protocols like TLS that do not take local
   character sets into account.

   Because this document normatively refers to [NAMEPREP], [PUNYCODE],
   and [STRINGPREP], it includes the security considerations from those
   documents as well.

   If or when this specification is updated to use a more recent Unicode
   normalization table, the new normalization table will need to be
   compared with the old to spot backwards incompatible changes.  If
   there are such changes, they will need to be handled somehow, or
   there will be security as well as operational implications.  Methods
   to handle the conflicts could include keeping the old normalization,
   or taking care of the conflicting characters by operational means, or
   some other method.

   Implementations MUST NOT use more recent normalization tables than
   the one referenced from this document, even though more recent tables
   may be provided by operating systems.  If an application is unsure of
   which version of the normalization tables are in the operating



Faltstrom, et al.           Standards Track                    [Page 19]

RFC 3490                          IDNA                        March 2003


   system, the application needs to include the normalization tables
   itself.  Using normalization tables other than the one referenced
   from this specification could have security and operational
   implications.

   To help prevent confusion between characters that are visually
   similar, it is suggested that implementations provide visual
   indications where a domain name contains multiple scripts.  Such
   mechanisms can also be used to show when a name contains a mixture of
   simplified and traditional Chinese characters, or to distinguish zero
   and one from O and l.  DNS zone adminstrators may impose restrictions
   (subject to the limitations in section 2) that try to minimize
   homographs.

   Domain names (or portions of them) are sometimes compared against a
   set of privileged or anti-privileged domains.  In such situations it
   is especially important that the comparisons be done properly, as
   specified in section 3.1 requirement 4.  For labels already in ASCII
   form, the proper comparison reduces to the same case-insensitive
   ASCII comparison that has always been used for ASCII labels.

   The introduction of IDNA means that any existing labels that start
   with the ACE prefix and would be altered by ToUnicode will
   automatically be ACE labels, and will be considered equivalent to
   non-ASCII labels, whether or not that was the intent of the zone
   adminstrator or registrant.

11. IANA Considerations

   IANA has assigned the ACE prefix in consultation with the IESG.





















Faltstrom, et al.           Standards Track                    [Page 20]

RFC 3490                          IDNA                        March 2003


12. Authors' Addresses

   Patrik Faltstrom
   Cisco Systems
   Arstaangsvagen 31 J
   S-117 43 Stockholm  Sweden

   EMail: [e-mail]


   Paul Hoffman
   Internet Mail Consortium and VPN Consortium
   127 Segre Place
   Santa Cruz, CA  95060  USA

   EMail: [e-mail]


   Adam M. Costello
   University of California, Berkeley

   URL: http://www.nicemice.net/amc/





























Faltstrom, et al.           Standards Track                    [Page 21]

RFC 3490                          IDNA                        March 2003


13. Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Faltstrom, et al.           Standards Track                    [Page 22]