Demonstrating string eligibility
To delegate or transfer a ccTLD, it must be shown that the string is eligible to be delegated.
The primary method of eligibility for country-code top-level domains is its listing as an “alpha-2” (two-letter ASCII) code listed in the ISO 3166-1 standard. Another method of eligibility is the string may have been deemed eligible as a country-code through the IDN Fast Track process.
Complete details on which country-codes are considered eligible are available in
Qualifying top-level domain strings.
Demonstrating technical and administrative competency
The delegation request must include documentation that demonstrates the technical and administrative ability of the proposed manager to operate the domain competently and that they will not jeopardize nor compromise the stability and security of the DNS.
The proposed manager decides whom to list as the administrative and technical contacts. Both the administrative contact and the technical contact must cross-verify all root zone changes and be responsive to communications about root zone changes.
For more information on preparing documentation to demonstrate technical and administrative ability, please go to
Preparing an Operational and Technical Plan.
Providing information on the Proposed Manager
It is a requirement that the requestor provides the legal name of the organisation (as officially registered in its principal place of business), along with its physical address, telephone and fax numbers. In support of this, the requestor must provide a certified copy or extract of the business registration, certification, or law that demonstrates the organisation’s legal status.
Providing geographical location
As country-codes represent specific countries or territories, the proposed manager will be resident or incorporated in, the territory and/or jurisdiction of the relevant government or public authority of the country associated with the ccTLD, unless formally decided otherwise by the relevant government or public authority.
It is a requirement that the requestor indicate the geographic locations of the proposed manager, the administrative contact person for the domain, and the location(s) where the principal operations will be conducted.
Demonstrating consent
It is a requirement that the requestor provides documentation that shows that directly involved parties consent to the request to delegate or transfer. For a new delegation, this includes the proposed new organisation and contact persons. For an existing delegation, this also includes documented consent from the existing management of the domain.
Demonstrating that the request serves the local Internet community’s interest
The delegation or transfer request must demonstrate that the proposed manager recognises its responsibility to fairly and equitably serve the local Internet community’s interests with respect to management of the domain. In support of this, it is a requirement that the requestor document the mechanisms that will be utilised to inform and seek input from the local community on ccTLD management issues.
It is a requirement that the requestor provide documentation indicating local Internet community support for the proposed manager in operating the ccTLD, such as letters of support from interested and/or impacted parties, and the results of public consultations that led to the request.
Demonstrating government review and consideration
It is a requirement that the requestor provide documentation indicating the relevant governments have been informed about the request. It is a requirement that the documentation includes a statement of support or non-objection from an authorised representative of the government.
Demonstrating a stable transfer plan
For the transfer of an existing operational ccTLD, it is a requirement that the requestor provide information on how existing operations will be transferred to the proposed new manager in a safe manner. It must explain how the stability of the domain will be preserved and how existing registrants will be impacted by the change. If the request is in relation to a transfer from a retired ccTLD to another ccTLD, it must also describe the decommissioning process for the retired domain.
Submitting the request
Once the request has been prepared, submit it to our Root Zone Management staff to commence processing.
Initial email submission
To start the request, send an email with the delegation/transfer form attached to
[email protected].
Supporting documentation must be provided with the Delegation Request Form. Files should be in PDF format where possible.
Once the email is sent to
[email protected], our ticketing system will reply automatically with a confirmation of receipt and a unique reference number within 1 day. This number will be used to track progress and correspondence relating to the request. Please ensure the number, just as it appears in the confirmation receipt, is included in the subject of all future communications related to the request.
Original documentation
In addition to the electronic submissions, it is a requirement that the requester submit originals, or certified copies, of all official documents and testimony used in the request for which its authenticity is material to the evaluation. This includes the following:
- Registration certifications
- Letters of support or consent
- Legal documents that are a basis of the application
The documents should be couriered or posted to ICANN’s Root Zone Management staff at the following address. It is important that the documents cite the reference number that appeared in the email confirmation receipt.
Root Zone Management
12025 Waterfront Drive
#300
Los Angeles CA 90094
USA
Please submit all requests, templates, and documentation in English. Where accuracy is essential, English documentation and/or English translations of key documents (such as governmental decrees relating to the request) must be notarised or certified official translations.
After the request is received
Once we receive the request and issue a confirmation receipt, a process of analysis and verification begins. The amount of time this process takes varies depending upon the information provided in the supporting documentation, and the complexity of the individual case.
In the event that further documentation or clarification is needed, we will contact the requestor. The delegation or transfer request will not proceed until we have received satisfactory documentation and information.
If we are unable to process the request due to significant lack of detail, the inability to confirm information, and/or unresponsiveness by the requestor, we will administratively close the request. In such cases, the requestor is welcome to resubmit the request at a later date to restart the review process once the additional material is available.
Requesting confirmation from contacts
In addition to verification and analysis of the material supplied in the request, for transfer requests, we will ask the current administrative and technical contacts, and the current ccTLD manager, whether they agree to the request.
In the case of a delegation, we confirm with the proposed contacts as listed in the request, to ensure they consent to the responsibilities of being listed as a contact for the domain.
In those cases where confirmation is not received from one or more parties, further consultation will be necessary. This may delay processing of the request. Please see
Obtaining consent for a root zone change.
Posting the status of the pending request
We will publicly post requests for delegations and transfers. This public disclosure will at a minimum include the domain name being requested, the party that will manage the domain, and the current status of the request.
If there are specific stability or security reasons why information should not be disclosed, the requestor should explain that in the Delegation Request Form.
Analysing the request
After all materials are received, and the positions of the contacts have been ascertained, our staff performs an analysis of the request. If the result of the analysis is the request accords with all appropriate policies and procedures, it will be approved for implementation. If there are defects in the request, it will be referred back to the requester for further work or clarification.
Implementing the request
Upon referral for implementation, the Root Zone Maintainer will implement the changes to the DNS root zone. We will implement the data changes in the WHOIS database.
After the request has been implemented, we will notify the requestor, and the requestor will verify that the changes were made correctly. In the event any problems arise, immediately notify us at
[email protected] and include the reference number of the change request.
https://www.iana.org/help/cctld-delegation
Running a new gtld costs a lot more than $185,000 that's just the fee to ICANN to play the game, if someone else wants the same string there is an auction and the costs can go way up in price.
