Skip to main content

Update about Synchronized IDN ccTLDs

This blog post is primarily intended to update the many people in the technical community and ccTLD community about activities related to Synchronized IDN ccTLDs.

As you may know, one of the ICANN Board resolutions from the recent ICANN meeting in Nairobi directed staff to develop an extension to the Fast Track Process: a mechanism to introduce Synchronized IDN ccTLDs. A Proposed Implementation Plan was subsequently published for public comments.

The Proposed Implementation Plan can be found here:

Since Synchronized IDN ccTLDs in the Fast Track context is a new concept, naturally this has raised some concerns and confusion. The best place to record comments and questions is in the public forum: Still, we thought it would be helpful to point to some resources, and answer questions we have seen in mail lists and elsewhere.

If you haven’t read it yet, we encourage you to read the recently published Q&A. The Q&A addresses concerns raised by the technical community due to the usage of certain terminology in the Board resolution and the Proposed Implementation Plan. In particular the Q&A explains that “synchronized” relates solely to policy and procedural requirements. The Q&A further clarifies that there is no (DNS) technical mechanism by which domains under Synchronized IDN ccTLDs will be made to resolve identically (same address/value etc) at the DNS protocol level. As a result, from a purely technical/DNS protocol perspective, two synchronized IDN ccTLDs are simply two separate delegations from the root zone.

If you have further questions, we encourage you to attend one or both of two upcoming webinars. These webinars will be recorded and the recordings will be published at the public comment forum for review by all interested parties. The webinars are scheduled for 14 April at 01:00 and 14:00 UTC. Registration and access information can be found at: or directly at the e-learning site at:

In addition it is important to note that the plan for synchronized IDN ccTLDs is not a general statement from ICANN about how all variant TLD introductions can or should be made. Quite the contrary, the requirements in the Proposed Implementation Plan for Synchronized IDN ccTLDs assures that it is limited. As one example of these limitations it is required that Synchronized IDN ccTLDs request first must complete the String Evaluation step in the Fast Track Process. Again, the Synchronized IDN ccTLD Process is an extension of the Fast Track Process and all Fast Track rules apply.

Given these designed-in requirements/limitations, the volume of Synchronized IDN ccTLDs will not really increase the total volume of new TLDs already contemplated within the Fast Track Process. Also, confusingly similar IDN ccTLDs will not be allowed for delegation regardless of whether they are considered synchronized or not (this type of variant TLDs needs additional work, see below). And, there are no current activities ongoing towards a notion of “Synchronized IDN gTLDs”.

As mentioned, more work is required to create a general mechanism by which all variant IDN TLDs (not just the very limited set of Synchronized IDN ccTLDs) can be introduced. The term variant has been used loosely; other related terminology used is aliasing, sameness, and so forth. A clarification of the terminology and what is meant by it is needed before the ongoing work can be initiated. A more general solution depends on (at least!):

• Definition of what exactly it is that is being sought by a “variant solution”. What is the desired behavior of variants in all cases?

• Definition of the different types of variants – which may inform the answers to 1).

• Review and test of DNAME as a technical solution, and its adequacy to achieve variant TLD management.

• Review/test of BNAME as a technical solution, and its adequacy to achieve variant TLD management. It is noted that the BNAME proposal is rather new and currently exist as an Internet Draft in the IETF.

• Review/test of variant management via procedures and registration policies. This based on the experience with the Synchronized IDN ccTLDs.

Along with the technical community, ICANN wants to contribute to finding the answers to these questions, and is launching a project to address them. Part of this work will be looking to use the community experience on this subject. In particular ICANN is seeking advice from the technical community, such as for example the work currently ongoing in the IETF/DNSEXT on the subject of sameness and variants in context of the DNS.

Meanwhile we look forward to your comments in the public forum, and your participation in the upcoming webinars!


    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."