Delegating or redelegating a country-code top-level domain (ccTLD)
This document provides an overall guide to the country-code top-level domain (ccTLD) delegation and redelegation process, and is designed to assist requestors in determining their eligibility, and in preparing formal requests.
Background on the process
The delegation and redelegation process is designed to assign or re-assign a ccTLD to a manager, taking into account a number of technical and public interest criteria. These criteria relate to the basic principles that the manager be a responsible and technically competent trustee of the domain on behalf of the national and global Internet communities.
The process is initiated when a formal request is submitted to the IANA Root Zone Management staff at ICANN. The request and all required documentation is then reviewed and verified by these ICANN staff members. After the review and authorisations are completed, the request is implemented as a change to the Root Zone and Root Zone Database.
Upon successful completion of the process, the new country-code domain is established, or a transfer takes place in the case of redelegation of an existing ccTLD.
Who is involved?
The delegation and redelegation process involves a number of different organisations and individuals. For example:
- The requestor, usually the proposed manager, initiates the process by submitting a formal delegation or redelegation request. The requestor is the main party ICANN interacts with throughout the request, and is responsible for collecting much of the materials required to process the request.
- The proposed manager is an organisation to which delegated responsibility for the ccTLD is sought. This organisation must demonstrate it understands and can meet its obligations as a trustee for the domain on behalf of the national and global Internet communities. The term manager is synonymous with other terms, such as Sponsoring Organization and operator, which have been used in other documentation. In this document, we have standardized on manager.
- Significant stakeholders are those parties that benefit from the operation of the ccTLD, and their opinions are important in assessing the public interest aspects of a request.
- The respective government is consulted to indicate either support or non-objection for the delegation or redelegation request. As a country-code represents the name of either a country or territory, the government is an important stakeholder in how the domain should be managed.
- ICANN, as the IANA Functions Operator, is responsible for the receipt, verification and processing of the request. IANA Root Zone Management staff performs these activities.
- The U.S. Department of Commerce, as the Root Zone Administrator, is responsible for verifying that processing procedures have been followed, and authorising any related changes to the DNS root zone and root zone database.
- Verisign, as the Root Zone Maintainer, is responsible for receiving requests that have been processed by ICANN and authorised by the US Department of Commerce, implementing those changes in the root zone, and distributing the revised root zone to the root name servers.
While many parties are involved in processing a delegation or redelegation, the Root Zone Management staff at ICANN are the primary interface for those requesting a delegation or a redelegation of a ccTLD.
Preparing a request
A delegation or redelegation request involves the development and submission of documentation that describes the nature of the request, and how the proposed new manager satisfies the criteria used to assess the request.
Completing a delegation request form
The delegation request form which describes the basic details of the request, must be completed. The details include the identity of the proposed manager, the contact persons to be listed in the Root Zone Database, the technical delegation details for the domain, and a checklist relating to the assessment criteria for the delegation or redelegation request.
Please see Technical requirements for authoritative name servers for more information about the technical delegation details for the domain.
Demonstrating string eligibility
To delegate or redelegate 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.
It is a requirement that the requestor provides documentation that shows that directly involved parties consent to the request to delegate or redelegate. 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 redelegation 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 redelegation 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 ICANN’s Root Zone Management staff to commence processing.
Initial email submission
To start the request, send an email with the delegation/redelegation form attached to email@example.com.
Supporting documentation must be provided with the Delegation Request Form. Files should be in PDF format where possible.
Once the email is sent to firstname.lastname@example.org, ICANN’s 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.
In addition to the electronic submissions, it is a requirement that the requestor 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 #300Los Angeles CA 90094
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 redelegation 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 redelegation 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, ICANN confirms 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
ICANN will publicly post requests for delegations and redelegations. 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, ICANN staff performs an analysis of the request.
The result of this analysis is a report that describes how the application meets the various criteria. This report will be reviewed by the ICANN Board of Directors to confirm proper procedures were followed.
Implementing the request
After the review by the ICANN Board, ICANN, as the IANA Functions Operator will forward the completed request to the Root Zone Administrator. The Root Zone Administrator will then authorize changes to the DNS root zone and root zone database. Upon authorization, the Root Zone Maintainer will implement the changes to the DNS root zone. The IANA Functions Operator 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@example.com and include the reference number of the change request.