Skip to main content

IDN ccTLD Fast Track String Evaluation Request System

1Start1Step 11Step 21Step 2.11Step 2.21Step 2.31Step 2.41Step 2.51Step 31Complete

The IDN ccTLD Fast Track Process is a mechanism to delegate a limited number of non-contentious internationalized country-code top-level domain names (IDN ccTLDs). There are several requirements for submitting a request in the process, all of which are defined in the Final Implementation Plan for the IDN ccTLD Fast Track Process

A request for an IDN ccTLD using the Fast Track Process is comprised of two separate processes:

  1. String Evaluation - the process to request and get evaluated IDN ccTLD string(s) as representation(s) of the eligible country or territory; and
  2. String Delegation - the process whereby an eligible sponsoring organization applies to operate an approved string, and the string is added to the DNS root zone.

This online system allows eligible participants to provide all the information required for the String Evaluation process, and submit the request to ICANN. Please note that the String Delegation process has a different set of requirements, and is managed separately to this system. After a successful String Evaluation, a String Delegation request must be conducted with IANA Root Zone Management as described in

A detailed manual describing the use of the online system can be found here. If you have any problems using this system, please contact ICANN at:

By signing and submitting this request we (the "Requestor") acknowledge and understand that:

The Internet Corporation for Assigned Names and Numbers (ICANN), as the steward of the global, interoperable Internet, is accepting submissions for requests for string evaluation of IDN ccTLD strings.

Usability Warning: The usability of IDNs may be limited, as not all application software is capable of working with IDNs. It is up to each application developer to decide whether or not they wish to support IDNs. This can include, for example, browsers, email clients, and sites where you sign up for a service or purchase a product and in that process need to enter an email address. Such usability problems currently exist today with the ASCII TLDs in some situations.

Further acceptability and usability issues may occur as the IDNA protocol standard is revised and as the IDN protocol for email management is finalized in the Internet Engineering Task Force (IETF). The result of the IDNA protocol revision will be that some characters previously not permitted within IDNs will become valid. ICANN will accept requests for strings with these newly valid characters, but until the new, revised standard is implemented and broadly adopted by relevant application developers, users may experience problems with using the IDN. This may have different results in different applications, and in some instances a user may experience no functionality at all. It would be appropriate for all IDN TLD managers to provide their users with information about the limitations of use of IDNs and at the same time promote the use of IDNs to achieve global IDN implementation across applications. ICANN supports such efforts but is not able to enforce or require them.

String Evaluation Stage: The submission of this request initiates the "Request Submission for String Evaluation" stage as set forth in the Implementation Plan for the IDN ccTLD Process.

Payment of the fee (USD $26,000) for the processing of a request in the String Evaluation Stage is expected. ICANN will submit a notice of this amount to you. If you are unable to pay this fee you can contact ICANN stating the reason for the inability to pay the fee.

Payment of an annual contribution to ICANN's cost of operations in the amount 1-3% of the revenue from the registrations of domain names within the selected TLD is expected. ICANN will submit a notice of the structure of this amount to you on an annual basis.

String Delegation Stage: The "Request Submission for String Evaluation" stage must be successfully completed before a separate request for the delegation of the IDN ccTLD can be submitted. A request for the delegation of the IDN ccTLD will be processed in accordance with ICANN's standard IANA process for the delegation for ASCII country-code top-level domains. The request may be withdrawn by the organization submitting the request (the "Requestor") or terminated by ICANN as set forth at Section 5.4 of the Implementation Plan for the IDN ccTLD Process. See the latest version of the Final Implementation Plan of the IDN ccTLD Fast Track Process at

ICANN's commitment to accountability and transparency will be followed. This means that certain information relating to the "Request Submission for String Evaluation" stage will be publicly available, either on ICANN's website or subject to disclosure under ICANN's Documentary Information Disclosure Policy. See more details at:

By signing and submitting this request the Requestor commits to TLD operations that will secure and enhance the stability and interoperability of the Internet's Domain Name System (DNS) for the benefit of the local and global Internet community, and to working in good faith together with ICANN towards a stable and secure Internet DNS. The Requestor understands that ICANN reserves the right to take actions necessary to protect the security, stability and interoperability of the global DNS.

ICANN expects that IDN ccTLDs will be established and operated in the manner described below:

  1. The IDN ccTLD manager shall establish, operate and maintain the authoritative name servers for the requested string in a stable and secure manner, adequate to resolve names within the requested string by users throughout the Internet and in compliance with Relevant Applicable Standards subject to and within the limits of relevant national law and national public policy. Relevant Applicable Standards are standards-track or best current practice RFCs sponsored by the Internet Engineering Task Force;
  2. IDN domain names are to be registered in accordance with a publicly available registration policy that shall comply on an ongoing basis with relevant applicable standards to IDNs, such as the IDNA Protocol, and with the IDN guidelines as updated and published from time to time on the ICANN website, all subject to and within the limits of relevant applicable national law and public policy. This includes, but is not limited to, adherence to RFCs 3490, 3491, 3492, 3454 and their successors;
  3. The IDN ccTLD manager should not use DNS redirection and synthesized DNS responses within any level of the registry; and
  4. The Requestor agrees that the IDN ccTLD manager will cooperatively engage with ICANN in the event of an activity or lack of activity that generates a serious concern regarding the stability, security or interoperability of the Internet's Domain Name System (DNS) from a global perspective. Briefly, the cooperative engagement process involves the designation of an official representative from ICANN and the IDN ccTLD manager, who shall meet with each other telephonically and/or in person to address the concerns in good faith and attempt to reach a resolution.

If the Requestor seeks to enter into a Documentation of Responsibilities, an Exchange of Letters, or a general TLD Agreement with ICANN after delegation, please check relevant boxes below. For reference, templates are available in the Final Implementation Plan at

Requestor warrants that the statements and representations contained in the request (including any documents submitted and oral statements made in connection with the request) are true and accurate and complete in all material respects, and that ICANN may rely on those statements and representations fully in evaluating this application.

Requestor acknowledges that any material misstatement or misrepresentation (or omission of material information) will reflect negatively on this request and may cause ICANN to terminate the request.

By submitting this request, I represent that I am authorized to act as a representative of Requestor and to enter into the commitments undertaken in this request.

By submitting my personal data, I agree that my personal data will be processed in accordance with the ICANN Privacy Policy, and agree to abide by the website Terms of Service.
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."