The Domain Name System, which performs a lookup service to translate user-friendly names into network addresses for locating Internet resources, is restricted in practice to the use of ASCII characters, a practical limitation that initially set the standard for acceptable domain names. The internationalization of domain names is a technical solution to translate names written in language-native scripts into an ASCII text representation that is compatible with the Domain Name System. Internationalized domain names can only be used with applications that are specifically designed for such use; they require no changes in the infrastructure of the Internet.
IDN was originally proposed in December 1996 by Martin Dürst and implemented in 1998 by Tan Juay Kwang and Leong Kok Yong under the guidance of Tan Tin Wee. After much debate and many competing proposals, a system called Internationalizing Domain Names in Applications (IDNA) was adopted as a standard, and has been implemented in several top-level domains.
In IDNA, the term internationalized domain name means specifically any domain name consisting only of labels to which the IDNA ToASCII algorithm can be successfully applied. In March 2008, the IETF formed a new IDN working group to update the current IDNA protocol.
In October 2009, the Internet Corporation for Assigned Names and Numbers (ICANN) approved the creation of internationalized country code top-level domains (IDN ccTLDs) in the Internet that use the IDNA standard for native language scripts. In May 2010 the first IDN ccTLD were installed in the DNS root zone.
Internationalizing Domain Names in Applications
Internationalizing Domain Names in Applications (IDNA) is a mechanism defined in 2003 for handling internationalized domain names containing non-ASCII characters. These names either are Latin letters with diacritics (ñ, é) or are written in languages or scripts which do not use the Latin alphabet: Arabic, Hangul, Hiragana and Kanji for instance. Although the Domain Name System supports non-ASCII characters, applications such as e-mail and web browsers restrict the characters which can be used as domain names for purposes such as a hostname. Strictly speaking it is the network protocols these applications use that have restrictions on the characters which can be used in domain names, not the applications that have these limitations or the DNS itself. To retain backwards compatibility with the installed base the IETF IDNA Working Group decided that internationalized domain names should be converted to a suitable ASCII-based form that could be handled by web browsers and other user applications. IDNA specifies how this conversion between names written in non-ASCII characters and their ASCII-based representation is performed.
An IDNA-enabled application is able to convert between the internationalized and ASCII representations of a domain name. It uses the ASCII form for DNS lookups but can present the internationalized form to users who presumably prefer to read and write domain names in non-ASCII scripts such as Arabic or Hiragana. Applications that do not support IDNA will not be able to handle domain names with non-ASCII characters, but will still be able to access such domains if given the (usually rather cryptic) ASCII equivalent.
ICANN issued guidelines for the use of IDNA in June 2003, and it was already possible to register .jp domains using this system in July 2003 and .info domains in March 2004. Several other top-level domain registries started accepting registrations in 2004 and 2005. IDN Guidelines were first created in June 2003, and have been updated to respond to phishing concerns in November 2005. An ICANN working group focused on country code domain names at the top level was formed in November 2007 and promoted jointly by the country code supporting organization and the Governmental Advisory Committee.
Mozilla 1.4, Netscape 7.1, Opera 7.11 were among the first applications to support IDNA. A browser plugin is available for Internet Explorer 6 to provide IDN support. Internet Explorer 7.0 and Windows Vista’s URL APIs provide native support for IDN.
Top-level domain implementation
In 2009, ICANN decided to implement a new class of top-level domains, assignable to countries and independent regions, similar to the rules for country code top-level domains. However, the domain names may be any desirable string of characters, symbols, or glyphs in the language-specific, non-Latin alphabet or script of the applicant’s language, within certain guidelines to assure sufficient visual uniqueness.
The process of installing IDN country code domains began with a long period of testing in a set of subdomains in the test top-level domain. Eleven domains used language-native scripts or alphabets, such as δοκιμή, meaning test in Greek.
These efforts culminated in the creation of the first internationalized country code top-level domains (IDN ccTLDs) for production use in 2010.
In the Domain Name System, these domains use an ASCII representation consisting of the prefix xn-- followed by the Punycode translation of the Unicode representation of the language-specific alphabet or script glyphs. For example, the Cyrillic name of Russia’s IDN ccTLD is рф. In Punycode representation, this is p1ai, and its DNS name is xn--p1ai.
Top-level domains accepting IDN registration
Many top-level domains have started to accept internationalized domain name registrations at the second or lower levels.
DotAsia, the registrar for the TLD Asia, conducted a 70-day sunrise period starting May 11, 2011 for second-level domain registrations in the Chinese, Japanese and Korean scripts.