Internationalized domain name

An internationalized domain name (IDN) is an Internet domain name that (potentially) contains non-ASCII characters. Such domain names could contain letters with diacritics, as required by many European languages, or characters from non-Latin scripts such as Arabic or Chinese. However, the standard for domain names does not allow such characters, and much work has gone into finding a way around this, either by changing the standard, or by agreeing on a way to convert internationalized domain names into standard ASCII domain names while preserving the stability of the domain name system.

IDN has, by the standards of the Internet, a long history; it was originally proposed in 1998. After much debate and many competing proposals, a system called Internationalizing Domain Names in Applications (IDNA) was adopted as the chosen standard, and is currently, as of 2005, in the process of being rolled out.

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. ToASCII is based on the Punycode ASCII encoding of normalized (Nameprep) Unicode strings.

Contents

1 Internationalizing Domain Names in Applications 2 ToASCII and ToUnicode 3 Example of IDNA encoding 4 Spoofing concerns 5 History of IDN 6 DNS registries known to have adopted IDNA 7 External links

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. Such domain names could not be handled by the existing DNS and name resolver infrastructure. Rather than redesigning the existing DNS infrastructure, it was decided that non-ASCII domain names should be converted to a suitable ASCII-based form by web browsers and other user applications; IDNA specifies how this conversion is to be done.

IDNA was designed for maximum backward compatibility with the existing DNS system, which was designed for use with names using only a subset of the ASCII character set.

An IDNA-enabled application is able to convert between the restricted-ASCII and non-ASCII representations of a domain, using the ASCII form in cases where it is needed (such as for DNS lookup), but being able to present the more readable non-ASCII form to users. 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. Several other top-level domain registries started accepting registrations in March 2004.

Mozilla 1.4, Netscape 7.1 and Opera 7.11 are among the first applications to support IDNA.

ToASCII and ToUnicode

The conversions between ASCII and non-ASCII forms of a domain name are accomplished by algorithms called ToASCII and ToUnicode. These algorithms are not applied to the domain name as a whole, but rather to individual labels. For example, if the domain name is www.example.com, then the labels are www, example and com, and ToASCII or ToUnicode would be applied to each of these three separately.

The details of these two algorithms are complex, and are specified in the RFCs linked at the end of this article. The following gives an overview of their behaviour.

ToASCII leaves unchanged any ASCII label, but will fail if the label is unsuitable for DNS. If given a label containing at least one non-ASCII character, ToASCII will apply the Nameprep algorithm (which converts the label to lowercase and performs other normalization) and will then translate the result to ASCII using Punycode before prepending the 4-character string "xn--". This 4-character string is called the ACE prefix, where ACE means ASCII Compatible Encoding, and is used to distinguish Punycode-encoded labels from ordinary ASCII labels. Note that the ToASCII algorithm can fail in a number of ways; for example, the final string could exceed the 63-character limit for the DNS. A label on which ToASCII fails cannot be used in an internationalized domain name.

ToUnicode reverses the action of ToASCII, stripping off the ACE prefix and applying the Punycode decode algorithm. It does not reverse the Nameprep processing, since that is merely a normalization and is by nature irreversible. Unlike ToASCII, ToUnicode always succeeds, because it simply returns the original string if decoding would fail. In particular, this means that ToUnicode has no effect on a string that does not begin with the ACE prefix.

Example of IDNA encoding

As an example of how IDNA works, suppose the domain to be encoded is Bücher.ch. This has two labels, Bücher and ch. The second label is pure ASCII, and so is left unchanged. The first label is processed by Nameprep to give bücher, and then by Punycode to give bcher-kva, and then has xn-- prepended to give xn--bcher-kva. The final domain suitable for use with the DNS is therefore xn--bcher-kva.ch.

Spoofing concerns

Because IDN allows websites to use full Unicode names, it also makes it much easier to create a spoofed web site that looks exactly like another, including domain name and security certificate, but in fact is controlled by someone attempting to steal private information. These spoofing attacks potentially open users up to phishing attacks.

These attacks are not due to technical deficiencies in either the Unicode or IDNA specifications, but due to the fact that different characters in different languages can look the same, depending on the font used. For example, Unicode character U+0430, Cyrillic small letter a ("а"), can look identical to Unicode character U+0061, Latin small letter a, ("a") which is the lowercase "a" used in English. Technically, characters that look alike in this way are known as homographs.

Although a computer may display visually identical or very similar glyphs for two different characters, these differences are still significant (to the computer, but not the user) when locating the web sites or validating certificates. Thus, the user's assumption of a one-to-one correspondence between the visual appearance of a name, and the named entity, breaks down.

For example, someone could register a domain name that appears identical to an existing domain but goes somewhere else. For example, the spoofed domain "pаypal.com" contains a Cyrillic a, not a Latin a. In many ways, this is not a new thing. Even staying within the old character set of A-Z, 0-9 and hyphen, G00GLE.COM is easily confused with GOOGLE.COM, for example. What was new was that the expansion of the character repertoire from a few dozen characters in a single alphabet to many thousands of characters in many scripts greatly increased the scope for homograph attacks. In general, this kind of attack is known as a homograph spoofing attack.

On February 7 2005, Slashdot reported that this exploit was disclosed at the hacker conference Schmoocon with an example available at http://www.shmoo.com/idn/. On browsers supporting IDNA, the URL "https://www.pаypal.com/" appears to lead to paypal.com but instead leads to a spoofed PayPal web site that says "Meeow." Mozilla Firefox, which supports IDNA, shows the page as being at the paypal.com and with a verified security certificate. Firefox displays no warnings of any sort.

It is possible to work around this problem in Firefox, Mozilla and other Gecko-based browsers by turning off IDN support entirely. To do this, type "about:config" into the address bar, bringing up the list of browser settings. Then find the "network.enableIDN" setting, and change the value to "false". The browser will then report IDN URLs as nonexistent. Note that on some versions (particularly, Firefox 1.0), this work-around only works for the first session only. Closing the browser and restarting leaves the user vulnerable again (though the option remains disabled). This can be corrected by clearing the browser's cache.

On February 17, 2005, Mozilla developers announced that they would ship their next versions of their software with IDN support still enabled, but showing the punycode URLs instead, thus thwarting any attacks while still allowing people to access websites on an IDN domain. This is a change from the earlier plans to disable IDN entirely for the time being. [1] (https://bugzilla.mozilla.org/show_bug.cgi?id=279099#c135)

Since then, both Mozilla and Opera have now announced that they will be using per-domain whitelists to selectively switch on IDN display for domain run by registries which are taking appropriate anti-spoofing precautions. (See the article on homograph spoofing attacks for more details).

History of IDN

• 07/98: Asia Pacific Networking Group (now known as APSTAR) iDNS Working Group formed - chaired by James Seng
• 1999: Early Research in IDN at National University of Singapore, Center for Internet Research
• 02/99: iDNS Testbed launched with participation from CNNIC, JPNIC, KRNIC, TWNIC, THNIC, HKNIC and SGNIC
• 11/99: IETF IDN Birds-of-Feather in Washington
• 01/00: IETF IDN Working Group formed chaired by James Seng and Marc Blanchet
• 03/01: ICANN Board IDN Working Group formed
• 11/01: ICANN IDN Committee formed
• 03/03: Publication of RFC 3454, RFC 3490, RFC 3491 and RFC 3492
• 06/03: Publication of ICANN IDN Guidelines for registries (http://www.icann.org/general/idn-guidelines-20jun03.htm)
• 05/04: Publication of RFC 3743, Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean

DNS registries known to have adopted IDNA

• .jp (July 2003)
• .kr (August 2003)
• .pl (September 11 2003), see details (http://www.dns.pl/IDN/draft-bartosiewicz-idn-pl.txt)
• .se (October 2003)
• .dk (January 2 2004), see details (http://www.dk-hostmaster.dk/dkhostcms/bs?pageid=302&action=cmsview&language=da&)
• .museum (January 20 2004), see details (http://about.museum/idn/)
• .no (February 9 2004), see details (http://www.norid.no/nytt/pressemelding20031202.en.html)
• .de (March 1 2004)
• .at (March 1 2004)
• .ch (March 1 2004)
• .lv (2004), see details (http://www.nic.lv/DNS/lvdomain.php)
• .at (2004), see details (http://nic.at/de/news/news/nw_news.asp?Key=751&Typ=100)
• .info (March 19 2004 for German names, see details (http://www.afilias.info/register/idn/))
• .org (January 18 2005 for German names, see details (http://www.pir.org/news/press_releases/pr_articles/2005-01-18-01))
• .br (May 9 2005) for Portuguese names, see details (http://registro.br/anuncios/20050504.html)

External links

• RFC 3454 (Stringprep)
• RFC 3490 (IDNA)
• RFC 3491 (Nameprep)
• RFC 3492 (Punycode)
• ICANN Guidelines for the Implementation of Internationalized Domain Names (http://www.icann.org/general/idn-guidelines-20jun03.htm)
• Internet Mail Consortium IDNA test tool (http://www.imc.org/idna/) (includes Perl source code)
• IANA e-mails explaining the final choice of ACE prefix (http://www.atm.tut.fi/list-archive/ietf-announce/msg13572.html)
• GNU Libidn (http://www.gnu.org/software/libidn/) is an implementation of IDNA
• List of all applications which have implemented IDNA along with a list of open source SDKs (http://www.verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/page_002201.html)
• Unicode Technical Report #36 - Security Considerations for the Implementation of Unicode and Related Technology (http://www.unicode.org/reports/tr36/)
• Online Punycode/IDN Decoder/Encoder (http://www.motobit.com/util/punycode-decoder-encoder.asp)
• ICANN Internationalized Domain Names (http://www.icann.org/topics/idn.html)
• ISC IDN-OSS project (http://idn.isc.org/)
• IDN Language Table Registry (http://www.iana.org/assignments/idn/)
• The Shmoo Group: IDN (http://www.shmoo.com/idn/)fr:Nom de domaine internationalisé

is:IDN-lén ja:国際化ドメイン名 de:IDNA