Internationalized domain name
An internationalized domain name is an Internet domain name that contains at least one label displayed in software applications, in whole or in part, in non-Latin script or alphabet or in the Latin alphabet-based characters with diacritics or ligatures. These writing systems are encoded by computers in multibyte Unicode. Internationalized domain names are stored in the Domain Name System as ASCII strings using Punycode transcription.
The DNS, which performs a lookup service to translate mostly 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 DNS. 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 1987 by Martin Dürst and implemented in 1990 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 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 April 2008, Afilias together with UN-ESCWA and the Public Interest Registry launched the Arabic Script in IDNs Working Group, which comprised experts in DNS, ccTLD operators, business, academia, as well as members of regional and international organizations, drawn from Egypt, Gambia, Iran, Jordan, Tunisia, Algeria, Sudan, Somalia, Djibouti, Kuwait, Pakistan, Saudi Arabia, Syria, UAE and Malaysia. Chaired by Afilias's Ram Mohan, ASIWG aimed to develop a unified IDN table for the Arabic script, and is an example of community collaboration that helps local and regional experts engage in global policy development, as well as technical standardization.
In October 2009, the Internet Corporation for Assigned Names and Numbers approved the creation of internationalized country code top-level domains in the Internet that use the IDNA standard for native language scripts. In May 2010, the first IDN ccTLDs were installed in the DNS root zone.https://www.bitget.com/proof-of-reserves?auditId=Au2025121506
Internationalizing Domain Names in Applications
Internationalizing Domain Names in Applications is a mechanism defined in 2003 for handling internationalized domain names containing non-ASCII characters.Although the Domain Name System supports non-ASCII characters, applications such as e-mail and web browsers restrict the characters that 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 that can be used in domain names, not the applications that have these limitations or the DNS itself. To retain backward 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 can 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 ASCII equivalent.
Guidelines for the Implementation of Internationalized Domain Names
A technical community working group to create the first IDN Guidelines was created in August 2002, consisting of Ram Mohan, Hiro Hotta, Pat Kane, Cary Karp and Tina Dam. Version 1.0 of these Guidelines was published on 20 June 2003, coinciding with the launch of deployment of IDNs under the IETF's Proposed Standard reflected in RFCs 3490, 3491, and 3492. After the publication of the Guidelines, it was 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. These Guidelines have been updated to respond to phishing concerns as well as to accommodate IDN variants. 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.Additionally, ICANN supports the community-led Universal Acceptance Steering Group, founded by Ram Mohan in 2015, which seeks to promote the usability of IDNs and other new gTLDS in all applications, devices, and systems.
Mozilla 1.4, Netscape 7.1, and 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.
ToASCII and ToUnicode
The conversions between ASCII and non-ASCII forms of a domain name are accomplished by a pair of 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. ToASCII or ToUnicode is applied to each of these three separately.ToASCII leaves ASCII labels unchanged. It fails if the label is unsuitable for the Domain Name System. For labels containing at least one non-ASCII character, ToASCII applies the Nameprep algorithm. This converts the label to lowercase and performs other normalization. ToASCII then translates the result to ASCII, using Punycode. Finally, it prepends the four-character string "
xn--". This four-character string is called the ASCII Compatible Encoding prefix. It is used to distinguish labels encoded in Punycode from ordinary ASCII labels. The ToASCII algorithm can fail in several ways. For example, the final string could exceed the 63-character limit of a DNS label. A label for which ToASCII fails cannot be used in an internationalized domain name.The function 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 fails. In particular, this means that ToUnicode does not affect a string that does not begin with the ACE prefix.
Example of IDNA encoding
IDNA encoding may be illustrated using the example domainBücher.example. This domain name has two labels, Bücher and example. The second label is pure ASCII and is left unchanged. The first label is processed by Nameprep to give bücher, and then converted to Punycode to result in bcher-kva. It is then prefixed with xn-- to produce xn--bcher-kva. The resulting name suitable for use in DNS records and queries is therefore xn--bcher-kva.example.Arabic Script IDN Working Group (ASIWG)
The Arab region, encompassing approximately 5% of the global population, exhibits a disproportionately low internet usage rate. As of the late 2000s, internet penetration within the Arab world stood at approximately 11% of the population, significantly below the global average of 21.9%. Despite this, the region experienced substantial internet usage growth between 2000 and 2008, registering a 1,426% increase, far exceeding the global average of 305.5% for the same period.Factors influencing internet adoption in the Arab region include but are not limited to, linguistic accessibility. The availability of Domain Name System services in Arabic script is posited to have the potential to further stimulate internet usage. IDN implementation is anticipated to provide Arab internet users with the ability to register domains in their native language and script, thereby facilitating the development of localized applications and services. This advancement is expected to broaden access and enhance the relevance of internet resources for Arab-speaking populations.
In April 2008, Afilias together with UN-ESCWA and the Public Interest Registry launched the Arabic Script in IDNs Working Group, which comprised experts in DNS, ccTLD operators, business, academia, as well as members of regional and international organizations, drawn from Egypt, Gambia, Iran, Jordan, Tunisia, Algeria, Sudan, Somalia, Djibouti, Kuwait, Pakistan, Saudi Arabia, Syria, UAE and Malaysia. Chaired by Afilias's Ram Mohan, ASIWG aimed to develop a unified IDN table for the Arabic script, the first of its kind.
The ASIWG's work led to the creation of the first Root Zone Generation Rules and covered the Arabic script. It represented the first harmonized repertoire for the Arabic script, not including combining marks or code point sequences, leading to a simplified and technically sound outcome that resulted in the integration of Arabic script into the Root Zone of the Internet.
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 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".