IDN TLDs: pre-registrations, declined requests, etc.

by Tina Dam on February 5, 2010

IDN TLDs: pre-registrations, declined requests, and other misconceptions
Recent statements and speculations have been made concerning the IDN ccTLD Fast Track Process and related issues. People seem to be most concerned about:

• ICANN denying some countries/territories access to the Fast Track Process
• ICANN approving IDN ccTLDs
• The notion of pre-registrations in new TLDs

This blog post is intended to set the record straight on these matters.

Is ICANN denying access to the Fast Track Process?
Let me be very clear: The Fast Track Process for submitting requests for IDN ccTLD strings is available to all eligible countries and territories. Statements like ICANN has refused IDN ccTLDs to some countries are incorrect. ICANN encourages eligible countries and territories to participate in the process and submit their IDN ccTLD requests.

This is an exciting new opportunity for Internet users around the world, and we would like to see as many users being served by these new initiatives as possible and as are deemed useful.

ICANN also has a support function in place at for interested parties.

So far, ICANN has received 17 requests encompassing 10 languages. These numbers will be updated from time to time at

To comply with the confidentiality requirements of the process, ICANN cannot disclose any additional information. We cannot state whether a particular request has been received, or how far along the process a request is. We understand that the public has a great deal of interest in potential future IDN ccTLDs, and therefore some requesting entities have elected to publicly disclose information about their requests.

However, the only time ICANN can make information available about a request is after it successfully passes the String Evaluation step.

What strings are ‘approved’ and what does it mean?
Four IDN ccTLD strings were recently announced as successfully completing the String Evaluation step of the Fast Track Process. These requests are associated with Egypt, the Russian Federation, Saudi Arabia, and the United Arab Emirates. The full announcement is here:

However, passing the String Evaluation step is not the same as saying that ICANN approved these TLDs. These four entities must go through the final step in the Fast Track Process – String Delegation. The String Delegation step must be initiated by the respective country or territory, and that can only be done with requests that have successfully met the String Evaluation criteria. String Delegation follows the same ICANN IANA process that is used for ASCII-based ccTLDs, and thus String Delegation requests are submitted to IANA root zone management.

Only after String Delegation takes place will these TLDs be in the DNS root zone, and only then can resolutions requests against them be performed. In other words, this is when domains can be registered and used.

Has ICANN authorized pre-registration of TLD domain names?
ICANN has not authorized pre-registration of domain names in any potential future TLDs.

The reason is simple: There is no way to be sure that a certain string will become a TLD and hence available for domain name registration until all steps in the associated evaluation and delegation processes are successfully completed.

ICANN has previously posted warnings concerning speculative pre-registrations, and those warnings are still informative. You can review them at

{ 15 comments… read them below or add one }

РФ 02.05.10 at 6:04 pm

No wonder Russia and China want to split the root. Russia is already selling .рф. They say it’ll go live at the end of March.

You’ve had a decade to get IDN down. It’s still not working. This is no one else’s fault but your own.

Icann has failed horribly at this. It’s time you admit this.

Nila 02.08.10 at 11:09 am

ICANN has not authorized pre-registration of domain names in any potential future TLDs.

Francisco 02.10.10 at 6:31 am

Thanks for you sharing.

Tina Dam 02.10.10 at 1:48 pm

@РФ – thanks for the comment. based on the fact that the ICANN model works through bottom-up processes, where many people participate (and perhaps you do as well…) in various constituencies I assume that your comment about us failing goes to all of us…

I agree that it would have been really good to have IDNs implemented some time ago…even back in the 70’ies when the initial system was build. However, it has simply not been possible and I think we should look forward positively and be excited about the reality of IDNs at second level have worked well for many since intorductions in early 2000 and that many more will be able to use them now that we move to the top level….


E. Blanconil 02.11.10 at 3:42 am

\”everyone eligible\”, only means \”not those ICANN decided ineligible\”. Since Fast Track is supposed to be a technical feasibility test, filtering out any kind of possible project and reserving it to IDNccTLDs only reduces the credibility of the test. Fast Track should be reserved to the most technically demanding IDNgTLD projects. In particular those calling for IDNA exceptions and Zone Manager restrictions. Anyway, ICANN is only responsible of the \”IN\” class – nothing prevents the use of a private reserved class as an IDNA class (as suggested by ICP-3). There are 65.000 classes on the internet. May be worth reading ICANN\’s ICP-3 again – in particular part 5 about experimentation processes.

РФ 02.11.10 at 7:01 am

@Tina Dam

Make no mistake. I am happy for the future of IDN. Icann only seems to be a road block.

China has used their IDN .中国 for years and it has resolved within China for that time. They only want it to go global. Who is standing in the way?

Actually, IDN haven’t worked well. There are many things that still aren’t working for IDN. E-mail being the biggest and largest set back for full adoption. Not to mention you are not treating IDN cctlds and IDN gtlds the same.

You have held back IDN gtlds while given a green light on cctlds. Thus saying all IDN are not equal.

Four days into the fast track program, by your own account, you had 10 requests in 4 languages. Yet you’ve only allowed 2 languages and 4 requests through to the final step. How is that possible? It’s been 3 weeks since you’ve announced this. Where are the others? Fast-Track? Really?

Yes, you are very clearly standing in the way. So no, the failing is only on you.

Tina Dam 02.11.10 at 8:06 am

@ E. Blanconil, you said:

“Since Fast Track is supposed to be a technical feasibility test….”

This is incorrect. There are a number of requirement other than those in the technical evaulation step. For example, government support, community support for the string, resemblance of the countryname etc. Please see the Implementation Plan at:


Tina Dam 02.11.10 at 8:18 am

you clearly need to understand the way ICANN functions better. The processes are build by the community and there are numerous ways for anyone to participate. ICANN staff provides services by ways of supporting the development and implementation of these processes.
I am happy to go over this with you in details, so feel free to contact me.

To your specific comments:

1. China: yes this has worked well at the _second_level_ with a plugin and/or re-direct inside China. That is however not the same as inserting IDN TLds in the rootzone. One thing is the technical feasibility, another is the policy aspects. (not re the above, the policy aspects are dealth with in the ICANN community. For gTLDs this is via the GNSO and for ccTLDs this is via the ccNSO. Othen various advisory committes provide input as well).

2. Email: you are right, getting emails out in IDNs would be great. The protocol is under development in the IETF. A LOT of people are spending their free time making this happen and again, the IETF is open for participation for anyone interested and able to do so. Once the protocol is completed I am sure it will be implemented by various email software providers – some already have. This however does not lie inside the mandate of ICANN and any application developers decides if they want to implement that fucntionality or not.

3. gtlds vs cctlds: they follow two different processes. One thing that was agreed upon between the various groups in the ICANN community was that if either of the two processes was ready before the other, then none should be slowed down. There is nothign else to it than that….

4. # in Fast Track: yes, the remaining are in evaulation. This means that we are still processing them and/or that the requestors are working on aspects of their request. The total is 17 (including the four that passed String Evaulation).

It almost sounds to your comments like anybody should be allowed to get any string they want in the root zone, with no processes or check/rules etc in place. Well, that is not how things work and if they did we would not have the Internet we have today.

At least I know that I (just like many others on ICANN staff) are putting in a lot of extra hours (and no we do not get paid overtime) to make things work well and as quickly as possible. What do you do? Posting negative comments on the blog, you are off course welcome to do so, but it does not seem very productive to me….

Genuha 02.11.10 at 11:16 am

That is however not the same as inserting IDN TLds in the rootzone.

Sean Kerner 02.11.10 at 11:34 am

In my experience, you’ve always been super-open and forthcoming on IDN related information – esp on this FastTrack process.

I for one appreciate and respect your efforts.

Tina Dam 02.11.10 at 12:11 pm

@Sean, thanks appreciated….and just to be clear: I dont mind at all critical comments and requests for making changes etc – as long as they are productive and something we can work on.

E. Blanconil 02.11.10 at 1:29 pm

actually the problem is far simpler than ICANN makes it. And this where it becomes complex.

China supports its IDNccTLD for a long through stubs. Actually they are in the root zone, but not in the ICANN root file. The problem is that IDNA was documented in 2003 in continuation of i-DNs existing IDNs and related to Unicode version 3-2. While Unicode had reached version 5. There was a need to make IDNA independent from Unicode version, to correct some imperfections, etc. This has been stabilized for the Internet by the recently published IDNA2008 version.

It only describes the way the Internet DNS wants to receive IDNs to restore them at the proper destination. This is neat and clean on the Internet side. The problem is that ICANN has not understood yet that the work is not completed: nothing has been specified for the user side, just a list of still not approved suggestions.

The reason why is that IDNA2008 unleashes the Internet capacity to support multiplicity, what is named the “presentation” layer and this way makes common the use of classes. This is an enormous change for users (ICANN only takes care of class “IN” domain names). At the same time, since there is no more “stringprep” there is a lot more flexibility for character mapping (preventing look alike characters to be confused, on a cultural basis). Yet, that mapping is just “up in the air”. There is no documentation, not configuration file and format, etc. in order to introduce some globally understood/used procedure.

As a result you can have several IDNA enabled applications on your PC that may resolve differently the _same_ IDN. IETF has no solution yet for that. Because this is on the user side, not on the network side. But this is not in the scope of anyone, because no one is in charge of something universal to the user.

So, the solution is for the Internet Users themselves to specify their own architecture. This is not complex. This works very simply, there is not a single line of code to change: just to load and run named on your computer and use your own copy of the root to make your computer non recursive and to get build a copy of Bind that supports punycode.

Problem is that when you have that on board your PC you are not tied to ICANN something anymore. You can decide to support any TLD which has a name server. Choosing among millions of TLDs of your liking if people started supporting them for free. In addition you can do that in other classes than “IN” and this means no pollution, no interference with ICANN. You can even run your own “.com” in an other of the 65.000 classes.

This is chaos. Actually, this is the unique virtual root and exactly what ICANN has asked to experiment in its ICP-3 document, but never did. This is why Fast Track with only a few selected IDNccTLDs is technically meaningless and an incitation to all the others to start their own MYCANN class.

ICANN played sorcerer apprentice. They followed the IETF work. But did not grasp the implication. The implication is that most of the DNS may become chaos except in the Google Class run be a unique centralised Google Public DNS. Just remember that the Chair of the IDNA2008 IETF WG is the boss of the the Google Public DNS and that they have the Google IETF internationalization specialist as an ICANN BoD Member.

This is obvioulsy something that China, Russia, India probably Europe cannot accept easily. The day they understand (or actually the day they want to use it) they will object and build their own DNS version (everyone can do that and share its config files). Bye Bye ICANN. What is astonishing is that ICANN does not even care …

Meli 03.05.10 at 1:05 pm

@E. Blanconil
That does not sound simple to me.

Telefon Dinleme 05.04.10 at 11:07 am

Thanks Good Site

Kong 07.09.10 at 11:26 pm

When we can register IDN?

Leave a Comment

You can use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

To prove you're a person (not a spam script), type the security word shown in the picture. Click on the picture to hear an audio file of the word.
Anti-spam image