This is a list of top-level domains (TLDs) for which software from the Mozilla project displays Internationalized Domain Names (IDNs).
In the absence of an entry in the list, a domain will still work, but it is rendered in its punicode form instead of in native form.
In order for us to display IDNs in a particular TLD, that registry concerned must have and keep a published policy stating which characters are permitted. If the set of characters contains pairs of homographic characters, the policy must specify a method (of the registry's choice) to prevent two homographic domains being registered to different entities.
This helps to keep confusingly similar domains from being displayed when rendered for the user.
To Add/Update a TLD
Any registry which wishes the Foundation to update their information or enable IDN display for their TLD should submit a bug, providing the following:
- the TLD(s) being submitted for addition or modification, and
- a link to their registry home page, and
- a link to their policy page, pointing out which sections clearly state the permitted character set and the homograph avoidance method, if required, and
- a link to the character set(s) used for review, and
- Their name, and role within the TLD Registry, with contact information for further correspondance or clarifications
Anyone who has evidence that a registry is not following their published policies, or that the policy has changed to permit the situation prohibited above should contact the Mozilla security group.
ASCII Country Code or Generic/Sponsored Top Level Domains
IDN Country Code or Generic/Sponsored Top Level Domains
| .الاردن | .xn--mgbayh7gpa | .<al-Ordon> | Registry | Policy | |
| .السعودية | .xn--mgberp4a5d4ar and variants | .<al-Saudiah> | Registry | Policy | Character List |
| .中國 .中国 | .xn--fiqz9s .xn--fiqs8s |
.<China> | Registry | Policy | (JET Guidelines) |
| .امارات | .xn--mgbaam7a8h | .<Emarat> | Registry | Policy | Character List |
| .香港 | .xn--j6w193g | .<Hong Kong> | Registry | Policy | (JET Guidelines) |
| .ایران | .xn--mgba3a4f16a .xn--mgba3a4fra |
.<Iran> | Registry | Policy | |
| .ලංකා .இலங்கை |
.xn--fzc2c9e2c .xn--xkc2al3hye2a |
.<Lanka> .<llangai> |
Registry | Policy | |
| .مصر | .xn--wgbh1c | .<Masr> | Registry | Policy | Character List |
| .قطر | .xn--wgbl6a | .<Qatar> | Registry | Policy | (characters in Appendix A of Policy) |
| .РФ | .xn--p1ai | .<RF> | Registry | Policy | |
| .سورية | .xn--ogbpf8fl | .<Souria> | Registry | Policy | (JET Guidelines) |
| .台灣 .台湾 |
.xn--kpry57d .xn--kprw13d |
.<Taiwan> | Registry | Policy | (JET Guidelines) |
Testing
To enable IDN for a particular TLD for testing purposes, go to the URL about:config in Firefox 1.1 or above and add a boolean pref called "network.IDN.whitelist.tld", where "tld" is the TLD, and set it to "true". This procedure is not recommended for users as it may expose them to security risk.
Rationale
The following excellent summary of why we are doing this was written by Neil Harris for the NANOG mailing list.
"The Moz/Opera anti-spoofing mechanism is the result of widespread public analysis and discussion, and has the following advantages:
- It deals with the actual problem: the visual representation of characters to the user -- the problem is, quite literally, in the eye of the beholder.
- It is simple to code and deploy: about ten lines of code for the Mozilla implementation.
- It is based on simple and non-political principles.
- It requires only a minimal amount of data to be distributed with the software.
- It is the sole survivor of a large number of alternative proposals that were considered and rejected. Unlike most of the other rejected proposals, it does not need any modifications to the DNS protocol, or distribution of "language" codes for labels, nor does it require multiple DNS lookups, large character tables in the browser, or real-time access to WHOIS information.
- It is based on a much more thorough analysis of the problem than the earlier ICANN proposals, and builds on the experience of the Unicode community, and the earlier analysis of the spoofing problem for the CJK languages performed for RFC 3743. For example, simple script restrictions alone, as per ICANN, do not solve the problem -- there are plenty of subtle homographs in the Latin alphabet.
- It does not treat IDNs as second-class citizens.
- It is language- and script-agnostic.
- It is scalable on a per-registry basis, so there's no need for a "flag day", and requires no action on behalf of the registry beyond that which might be expected as a service to their customers, who have a reasonable expectation that their domains not be easily spoofed.
- And, most of all, it uses human, and not technical, means to provide a chain of trust from the registry to the application to the user.
I must say that, from a user's perspective, I find it hard to understand why any registry would not want to put their anti-spoofing policy -- assuming they have one -- on public display, thus encouraging software vendors to regard their IDN labels as safe to display within their software.
In the long run, of course, it makes sense for best common registry anti-spoofing practices to be codified, probably in an RFC, or through the Unicode consortium. However, until then, the maintenance of an ad-hoc list by software vendors seems to be a powerful incentive in the short term for registries to implement and publish anti-spoofing policies which encourage trust."
