|
An internationalized domain name (IDN) is an Internet domain name that contains one or more non-ASCII characters. Such domain names could contain letters with diacritics, as required by many non-English languages, or characters from non-Latin scripts such as Arabic, Hebrew, Chinese or Hindi. However, the standard for domain names does not allow such characters, and much work has gone into finding a way to internationalize domain names into a standard ASCII format, thereby preserving the stability of the domain name system. IDN has, by the standards of the Internet, a long history; it was originally proposed in 1996 (by M. Dürst) and implemented in 1998 (by James Seng under the guidance of T.W.Tan). After much debate and many competing proposals, a system called Internationalizing Domain Names in Applications (IDNA [1]) was adopted as the chosen standard, and has been rolled out 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. (For the meaning of 'label' and 'ToASCII', see the section ToASCII and ToUnicode below.) In March 2008, the IETF formed a new IDN Working Group to update[2] the current IDNA protocol. Internationalizing domain names in applicationsInternationalizing Domain Names in Applications (IDNA) is a mechanism defined in 2003 for handling internationalized domain names containing non-ASCII characters. While much of the Domain Name System can technically support non-ASCII characters, applications such as e-mail and web browsers restrict domain names to what can be used as a hostname. 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 and .info[3] domains in March 2004. Several other top-level domain registries started accepting registrations in 2004 and 2005. IDN Guidelines were first created[4] in June 2003, and have been updated[5] 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[6] and promoted jointly by the country code supporting organization and the Governmental Advisory Committee. Mozilla 1.4, Netscape 7.1, Opera 7.11 and Safari are among the first applications to support IDNA. A browser plugin is available for Internet Explorer 6 to provide IDN support. Internet Explorer 7.0[7] and Windows Vista's URL APIs provide native support for IDN. ToASCII and ToUnicodeThe 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 encodingAs an example of how IDNA works, suppose the domain to be encoded is Bücher.ch (“Bücher” is German for “books”, and .ch is the country domain for Switzerland). 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. ASCII Spoofing and squatting concernsBecause 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 because 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. Characters that look alike in this way may be termed homonyms, homographs, or (less ambiguously) homoglyphs. Although a computer may display visually identical or very similar glyphs for two different characters, these differences are still significant to the computer when locating web sites or validating certificates. The user assumes a one-to-one correspondence between the visual appearance of a name and the named entity, but when two names appear identical, this correspondence breaks down. By contrast, with the old set of a to z, 0 to 9, and the hyphen, there is little in the way of homographs. l and 1 and 0 and o are the closest, and the combination "rn" looks similar to "m" in some fonts; however, most fonts make a noticeable visible distinction between them. Still, this means even in the worst case a site like Google would still only need to register 8 names to protect against the homograph attacks. On December 2001, two Israeli researchers, Evgeniy Gabrilovich and Alex Gontmakher, published a paper titled "The Homograph Attack",[8] an attack that used Unicode URLs to spoof a website URL. To prove the feasibility of this kind of attack, the researchers successfully registered a variant of the domain name "Microsoft.com" which incorporated Russian language characters. In general, this kind of attack is known as a homograph spoofing attack. This problem was anticipated before IDN was introduced, and guidelines were issued to registries to try and avoid or reduce the problem – for example, recommending that registries only accept the Latin alphabet and that of their own country, not all of Unicode. Unfortunately this advice was not followed by those in control of a number of major TLDs. On February 7, 2005, Slashdot reported that this exploit was disclosed at the hacker conference Shmoocon with an example available at http://www.shmoo.com/idn/. On browsers supporting IDNA, the URL "http://www.pаypal.com/" (where the first a is replaced by a Cyrillic а) appears to lead to paypal.com but instead led to a spoofed PayPal web site that said "Meeow." Internet Explorer 7 imposes restrictions on displaying non-ASCII domain names based on a user-defined list of allowed languages and provide an anti-phishing filter that checks suspicious Web sites against a remote database of known phishing sites. Since Internet Explorer prior to version 7 does not support IDNs, it is not vulnerable to this kind of attack. However, older versions of Internet Explorer can be made IDN-compatible by browser plug-ins some of which are vulnerable to the spoofing attacks. On July 9, 2005, the IDN-enabling plug-in Quero Toolbar 2.1.0 was released that implemented several anti-spoofing techniques like mixed-script detection and highlighting of characters belonging to different scripts.[citation needed] 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 exploiting similarities between ASCII and non-ASCII letters (but not necessarily, for example, between Cyrillic and Greek letters, unless the user knows which Punycode URL corresponds to their chosen IDN URL) 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] 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[2]. (See the article on homograph spoofing attacks for more details). As of September 9, 2005, the most recent version of Mozilla Firefox as well as the most recent Internet Explorer displays the spoofed Paypal URL as "http://www.xn--pypal-4ve.com/", unsightly but clearly different from the actual paypal.com. By contrast, the (non-existent) "http://www.xn--pypal-4ve.org" will display in the Firefox address bar as http://www.pаypal.org, as this form of domain is prohibited from registration at the Afilias registry level and therefore does not pose the same risk. Safari's approach is to render problematic character sets as punycode. This can be changed by altering the settings in Mac OS X's system files[9]. History of IDN
Top-Level Domains known to accept IDN registration
Non-IDNA or non-ICANN registries that support non-ASCII domain namesThere are other registries that support non-ASCII domain names. The company ThaiURL.com in Thailand supports .com registrations via its own modified DNS, ThaiURL. Because these companies, and other organizations that offer modified DNS systems, do not subject themselves to ICANN's control, they must be regarded as alternate DNS roots. Domains registered with them will therefore not be supported by most Internet Service Providers, and as a result most users will not be able to look up such domains without manually configuring their computers to use the alternate DNS. See alsoReferences
External links
|
This article is from Wikipedia. All text is available under the terms of the GNU Free Documentation License.
Mercedes Car
This site monitored by SitePinger.net