draft-skwan-utf8-dns-06.txt

bind-3.2.

As pointed in the previous section, there is no need to upgrade DNS
servers, except possibly those that are authoritative for the zones
containing internationalized hostnames.

The following interoperability issues should be taken into account

- A legacy application may not be able to process the hostnames
containing non-ASCII characters returned by DNS resolvers. Effect of
failure to process a name containing 7-bit needs to be separately
investigated. 
- If other protocols decide to use the nameprep-UTF-8-encoding to
represent internationalized hostnames in their wire packets, then a
legacy application supporting such protocol that receives UTF-8
encoded hostname from another application (for example, such as mail
server or client) may fail to process such hostname. Effect of failure
to process a name containing 7-bit needs to be separately investigate.


Expires November 2001                                         [Page 4]

INTERNET-DRAFT                  UTF-8 DNS                     May 2001


Thus hostnames that are intended to be globally usable [RFC1958] on
legacy applications should still contain ASCII-only characters per
[RFC1123].

- If an updated application runs on legacy resolver that rejects name
resolution of the names containing any character not allowed by
[RFC1123], then such resolvers will require an upgrade to enable name
resolution of the internationalized hostnames.

- As specified above, DNS servers authoritative for the DNS records
containing the internationalized hostnames must be able to save and
load the hostnames containing napepreped-UTF-8-converted characters.
If the DNS server doesn't satisfy this requirement, but needs to host
such resource records, then it needs to be upgraded.

- Any DNS server involved in a name resolution process of the DNS
records containing an internationalized hostname must not reject name
resolution only because the hostname contains characters not allowed
by [RFC1123]. This requirement does not mean that every DNS server in
the name resolution path between the client and authoritative server
must be able to store and load the DNS records containing the
internationalized hostnames, but only means that the DNS server
performing recursive resolution needs to be able to query for and
cache such records, and that the DNS servers authoritative for the DNS
names higher in the DNS name hierarchy than the internationalized
names in query, need to be able to respond to such queries.
Overwhelming majority of the DNS servers currently deployed on the
Internet already satisfy this requirement. Authors are not aware of
any implementation of the DNS server widely deployed on the Internet
that doesn't satisfy this requirement.

Although most of the DNS servers may be capable of accepting a zone
transfer of a zone containing UTF-8 encoded hostnames, some of them
may not be able to store those names in a zone file or load those
names from a zone file. Administrators should exercise caution when
transferring a zone containing UTF-8 encoded hostnames to such DNS
servers.



4. Security Considerations

Support for internationalized hostnames introduces a possibility of a
new type of spoofing attacks that could be based on attacker's
knowledge of misbehaving applications or resolvers that modifies the
internationalized hostname that needs to be resolved. For example, if
there is an application that modifies any character containing 7-bit
in some predictable manner (for example by simply dropping the 7-bit),





Expires November 2001                                         [Page 5]

INTERNET-DRAFT                  UTF-8 DNS                     May 2001


then an attacker may register a DNS record mapping the derivative
(i.e. modified by the misbehaving application or resolver) name to the
data desired by attacker. In this scenario any user using such
misbehaving application may receive as a result of name resolution the
data (for example an IP address in A resource record) specified by the
attacker without noticing that they are subjected to an attack even if
the DNSSEC is used to verify the authenticity of the response.

Because this protocol depends on the procedures described in
[NAMEPREP] and [RFC2044], the security issues identified in these
document are also applicable to this protocol.


5. Acknowledgements

The authors of this document would like to thank the following people
for their contribution to this specification:  John McConnell,
Cliff Van Dyke and Bjorn Rettig.


6. References

[RFC1035]     P.V. Mockapetris, "Domain Names - Implementation and
              Specification," RFC 1035, ISI, Nov 1987.

[RFC2044]     F. Yergeau, "UTF-8, a transformation format of Unicode 
              and ISO 10646," RFC 2044, Alis Technologies, Oct 1996.

[RFC1958]     B. Carpenter, "Architectural Principles of the
              Internet," RFC 1958, IAB, June 1996.

[RFC1123]     R. Braden, "Requirements for Internet Hosts -
              Application and Support," STD 3, RFC 1123, January 1989.

[RFC2130]     C. Weider et. al., "The Report of the IAB Character 
              Set Workshop held 29 July - 1 March 1996",
              RFC 2130, Apr 1997.

[RFC2181]     R. Elz and R. Bush, "Clarifications to the DNS 
              Specification," RFC 2181, University of Melbourne and
              RGnet Inc, July 1997.

[UNICODE 2.0] The Unicode Consortium, "The Unicode Standard, Version
              2.0," Addison-Wesley, 1996. ISBN 0-201-48345-9.

[NAMEPREP]    Paul Hoffman and Marc Blanchet, "Preparation of
              Internationalized Host Names",
              draft-ietf-idn-nameprep-*.txt.





Expires November 2001                                         [Page 6]

INTERNET-DRAFT                  UTF-8 DNS                     May 2001


7. Author's Addresses

Stuart Kwan                         James Gilroy
Microsoft Corporation               Microsoft Corporation
One Microsoft Way                   One Microsoft Way
Redmond, WA  98052                  Redmond, WA  98052
USA                                 USA
[e-mail]                 [e-mail]

Levon Esibov
Microsoft Corporation
One Microsoft Way
Redmond, WA  98052
USA
[e-mail]


11.  Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it has made any
effort to identify any such rights.  Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11.  Copies of claims of
rights made available for publication 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
implementors or users of this specification can be obtained from the
IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard.  Please address the information to the IETF Executive
Director.


12.  Full Copyright Statement

Copyright (C) The Internet Society (2001).  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

Expires November 2001                                         [Page 7]

INTERNET-DRAFT                  UTF-8 DNS                     May 2001


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

Expires November 2001                                         [Page 8]