IDN-enabled TLDs
This is a list of top-level domains (TLDs) for which software from the Mozilla project displays Internationalized Domain Names (IDNs).
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 to prevent two homographic domains being registered to different entities.
Any registry which wishes the Foundation to enable IDN for their TLD should email Gerv, giving a link to their registry home page and their policy, which clearly states the permitted character set and the homograph avoidance method, if required. 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.
| .ac | Registry | Policy |
| .at | Registry | Policy (character list) |
| .biz | Registry | Policy |
| .br | Registry | Policy |
| .ch | Registry | Policy |
| .cl | Registry | Policy |
| .cn | Registry | Policy (JET Guidelines) |
| .de | Registry | Policy |
| .dk | Registry | Policy |
| .es | Registry | Policy (character list) |
| .fi | Registry | Policy |
| .gr | Registry | Policy |
| .hu | Registry | Policy (section 2.1.2) |
| .info | Registry | Policy |
| .io | Registry | Policy |
| .ir | Registry | Policy |
| .is | Registry | Policy |
| .jp | Registry | Policy |
| .kr | Registry | Policy (JET Guidelines) |
| .li | Registry | Policy (managed by .ch registry) |
| .lt | Registry | Policy |
| .museum | Registry | Policy |
| .no | Registry | Policy (section 4) |
| .org | Registry | Policy (character list) |
| .pl | Registry | Policy |
| .se | Registry | Policy (character list) |
| .sh | Registry | Policy |
| .th | Registry | Policy |
| .tm | Registry | Policy |
| .tw | Registry | Policy (JET Guidelines) |
| .vn | Registry | Policy (character list) |
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."