Delegating or transferring a country-code top-level domain (ccTLD)

This document provides an overall guide to the country-code top-level domain (ccTLD) delegation and transfer (redelegation) process, and is designed to assist requestors in determining their eligibility, and in preparing formal requests.

Background on the process

The delegation and transfer 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 our Root Zone Management staff. The request and all required documentation is then reviewed and verified by our team. 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 transfer of an existing ccTLD.

Who is involved?

The delegation and transfer 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 transfer request. The requestor is the main party we interact 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 transfer 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.
• We, Public Technical Identifiers, as the IANA naming functions operator, are responsible for the receipt, verification and processing of the request. Our Root Zone Management staff performs these activities.
• Verisign, as the Root Zone Maintainer, is responsible for receiving requests that we have processed and 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 transfer, our staff are the primary interface for those requesting a delegation or a transfer of a ccTLD.

Preparing a request

A delegation or transfer 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 transfer 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 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 root-mgmt@iana.org.

Supporting documentation must be provided with the Delegation Request Form. Files should be in PDF format where possible.

Once the email is sent to root-mgmt@iana.org, 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 root-mgmt@iana.org and include the reference number of the change request.