Internationalized domain names (IDNs) have been available to Internet users for many years, but this year the first fully non-Latin IDN domains have become enabled by ICANN and country-code top-level domain registries. The recent success of the launch of Russia's .рф (.rf) ccTLD shows that there is an enormous demand for domain names in Internet users' native languages.
.ASIA top-level domain is one of the pioneer domain registries in Asia to enable the secure DNS standard
| Attachment | Date | Size |
|---|---|---|
![[file]](http://www.afilias.info/sites/all/modules/webfm/image/icon/pdf.gif "Download Mohan LK ICANNComments June2010.pdf"){kind=icon} Mohan LK ICANNComments June2010.pdf | 07/01/10 11:03 am | 144.39 KB |
"The importance of the Chinese domain name market cannot be understated," said Mr.
Düsseldorf, GERMANY - 17 March 2004 - Afilias, a global provider of Internet domain name registry services, announced Wednesday that it has opened registration for .INFO German script internationalized domain names (IDNs), which now enables Internet users to register Web addresses containing the German characters ä, ö, and ü. Afilias opened registration yesterday evening. As of 13:00 UTC (08:00 a.m. EST) on 17 March, over 13,000 German script IDNs were registered, the first of which was kinderbücher.info.
Düsseldorf, GERMANY - 27 January 2004 - Afilias, a global provider of Internet domain name registry services, announced Tuesday that it will launch the first standards-based registrations of German script internationalized domain names (IDNs) under the .INFO generic top-level domain (gTLD) on 26 February 2004. Registrations will be processed on a first-come, first-served basis and will enable the registration of Internet domain names that contain the widely used German script umlaut characters: "ä", "ö" and "ü".
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
On November 11, 2010 Afilias secured the .ASIA TLD with DNSSEC. You can find media, presentations, and comments from the event here.
Â
简体中文
繁體中文
Deutsch
