About Us

Afilias' specialized technology makes Internet addresses more accessible and useful through a wide range of applications, including Internet domain registry services, Managed DNS and award-winning mobile Web services.

IDN Backgrounder

Internationalized Domain Names (IDNs) were first launched in 2004 called IDNA, and now based on IETF standard RFC5890 published in 2010, which use the Punycode encoding algorithm to represent non-ASCII characters found in Arabic, Chinese, Cyrillic, Hindi and other languages, into ASCII (plain text characters and numbers) domain names that the DNS system can resolve. This allows Internet users to type a domain name in their local script using their native language, instead of an English translation.

What is Punycode and how does it work with the DNS?

The Punycode algorithm was adopted as part of international standards for converting non-English characters into ASCII.

To convert IDNs to ASCII, the international characters must first be mapped to a corresponding ASCII string of characters, e.g.: the ü in probestück.info is converted to the ASCII string "w9a." Then a specific prefix (as specified by the standard) "xn--" is added to the beginning of the entire domain name. So the resulting ASCII name for the IDN probestück.info is xn--probestck-w9a.info.

How does this process work with domain name registration?

To register a domain name using IDN characters, registrars use the Nameprep and Stringprep specifications from the IETF to translate the Internationalized name into its punycode equivalent, and submit that domain name to Afilias (or another registry operator) for registration within a TLD that supports IDN domains. The registry actually reserves the ‘punycode' representation of the domain, and will display that ASCII domain in the WHOIS system.

In order to be registered, each language must be converted into a script "table" that dictates each letter's translation. Typically these language tables are developed and adopted by leading researchers at sovereign governments whose citizens represent a dominant or sole majority of a language.

Domain name registries adopt these "language tables" when they allow a new IDN script to be registered.

What is the difference between an IDN domain name and an IDN TLD?

For years, Internet users have been able to register domain names with International characters in the second level domain string - the part to the left of the last "dot" in the address. In our example above (probestück.info), info is the top-level domain and probestück is the second level.

Only recently has ICANN begun to allow IDN characters to be represented to the right of the last "dot," or at the top-level domain level. Currently, this process is only underway for country code top-level domains (ccTLDs).

For example, The Jordanian registry officially launched the Arabic version of its ccTLD as .alordon which translates to xn--mgbayh7gpa using the Punycode algorithm and is visible in Arabic as الاردن.

A list of ccTLD that have requested their IDN string to ICANN, and their status is available here http://www.icann.org/en/topics/idn/fast-track/string-evaluation-completion-en.htm

User accessibility of IDN names through browsers

When a user types an IDN into a browser, the application must know how to convert the name into ‘punycode' for it to be handled properly by the registry. Most current versions of commercial browsers are compliant with the international ‘punycode' standard.

In these browsers, when a user types in an IDN name, e.g.: probestück.info, the browser uses the Nameprep and Stringprep specifications to translate the name into the ‘punycode' string xn--probestck-w9a.info. The browser then sends this ‘punycode' string to Afilias' .INFO TLD nameserver, where the name is looked up in the zone file like ASCII domains are today.

As in normal DNS queries to resolve ASCII domains, the TLD nameserver will respond with one of two answers: either "YES" this name exists, or "NO" this name does not exist (i.e.: NX domain record). If the name exists, the TLD nameserver will return the nameserver for the domain. The DNS resolver will then query that nameserver for the hostname. If the hostname exists, the IP address will be returned and the browser will be able to use it to connect to the web server and website for probestück.info. If the answer is NO, then the user will get a NX domain response or the error "this domain does not exist." Many browsers will return a 404 error, or may provide a redirected search page.


Technical References:

The following are the new set of RFC for IDN 2008.

RFC 5890 http://www.rfc-editor.org/info/rfc5890

RFC 5891 http://www.rfc-editor.org/info/rfc5891

RFC 5892 http://www.rfc-editor.org/info/rfc5892

RFC 5893 http://www.rfc-editor.org/info/rfc5893

RFC 5894 http://www.rfc-editor.org/info/rfc5894

RFC 5895 http://www.rfc-editor.org/info/rfc5895