RFC 3490 (rfc3490) - Page 2 of 22
Internationalizing Domain Names in Applications (IDNA)
Alternative Format: Original Text Document
RFC 3490 IDNA March 2003
3.2.2. Non-domain-name data types stored in domain names... 9
4. Conversion operations......................................... 9
4.1 ToASCII................................................... 10
4.2 ToUnicode................................................. 11
5. ACE prefix.................................................... 12
6. Implications for typical applications using DNS............... 13
6.1 Entry and display in applications......................... 14
6.2 Applications and resolver libraries....................... 15
6.3 DNS servers............................................... 15
6.4 Avoiding exposing users to the raw ACE encoding........... 16
6.5 DNSSEC authentication of IDN domain names................ 16
7. Name server considerations.................................... 17
8. Root server considerations.................................... 17
9. References.................................................... 18
9.1 Normative References...................................... 18
9.2 Informative References.................................... 18
10. Security Considerations...................................... 19
11. IANA Considerations.......................................... 20
12. Authors' Addresses........................................... 21
13. Full Copyright Statement..................................... 22
1. Introduction
IDNA works by allowing applications to use certain ASCII name labels
(beginning with a special prefix) to represent non-ASCII name labels.
Lower-layer protocols need not be aware of this; therefore IDNA does
not depend on changes to any infrastructure. In particular, IDNA
does not depend on any changes to DNS servers, resolvers, or protocol
elements, because the ASCII name service provided by the existing DNS
is entirely sufficient for IDNA.
This document does not require any applications to conform to IDNA,
but applications can elect to use IDNA in order to support IDN while
maintaining interoperability with existing infrastructure. If an
application wants to use non-ASCII characters in domain names, IDNA
is the only currently-defined option. Adding IDNA support to an
existing application entails changes to the application only, and
leaves room for flexibility in the user interface.
A great deal of the discussion of IDN solutions has focused on
transition issues and how IDN will work in a world where not all of
the components have been updated. Proposals that were not chosen by
the IDN Working Group would depend on user applications, resolvers,
and DNS servers being updated in order for a user to use an
internationalized domain name. Rather than rely on widespread
updating of all components, IDNA depends on updates to user
applications only; no changes are needed to the DNS protocol or any
DNS servers or the resolvers on user's computers.
Faltstrom, et al. Standards Track