Understanding the ccTLD Delegation and Redelegation Procedure
Country-code top-level domains (ccTLDs) are two-letter top-level domains that are derived from the ISO 3166-1 standard. IANA is responsible for receiving requests relating to the delegation and redelegation of a sponsoring organisation for these domains. The sponsoring organisation is entrusted with operating the domains in the public interest for the community the domain is designated to serve. IANA evaluates requests against both technical and public interest criteria, and provides the results of its investigation to the ICANN Board of Directors who ultimately decide whether to approve requests. IANA is also responsible for implementation of requests that have been approved by the ICANN Board.
Note well: This document is not a statement of policy, and should not be construed as such. It is simply a guide prepared by IANA staff to assist applicants better understand the process, and will be adapted over time based on feedback and questions.
Who is this document for?
This document is for anyone who needs to understand the step-by-step process involved in the delegation or redelegation of a ccTLD. While primarily intended as a guide for those organizations pursuing such a request, this document is also intended to serve as a reference for anyone interested in the IANA ccTLD delegation and redelegation process.
Who is involved in a delegation or redelegation?
The delegation or redelegation of a ccTLD, while conceptually simple, can become complex because many different organizations and individuals play a part in the process. For example:
- The proposed new operator (applicant) typically initiates the process and provides the needed information in a standard format.
- The existing operator is contacted to confirm the change is appropriate and should be implemented, in the event of a redelegation request.
- The sponsoring organization, in many cases the government associated with the ccTLD, is asked to verify that the redelegation is supported.
- Those parties served by the ccTLD are asked to show that they support the request and that it meets the interests and needs of the local Internet community.
- IANA Root Management Staff act as the coordinator and analyst for the request. This work includes investigating the details of the request, preparing a recommendation for the ICANN Board, and implementing the request if it is approved.
- The ICANN Board of Directors considers the recommendation prepared by IANA staff and then votes on whether the request should move forward.
- The US Department of Commerce evaluates a report on the request prepared by IANA staff.
Submitting the Request
The steps for delegation and redelegation involve preparation of an initial request via a Change Request Template. In addition to the Change Request Template, IANA requires supplementary information that shows that the request meets the eligibility criteria. IANA uses this information to corroborate the delegation or redelegation request. This documentation includes:
- information showing the change serves the local interest in the country;
- documentation demonstrating the technical and administrative capabilities of the organization receiving the redelegation;
- a description of the legal status of the organization;
- the names of contacts in any in-country government agencies who have a say in the delegation/redelegation;
- a detailed description of how existing ccTLD operations will be transferred to the proposed new operator, in the case of a redelegation;
- documentation showing that the new operator will operate the domain in a fair and equitable manner; and,
- the approvals of the current contacts for the TLD, in the case of a redelegation.
Each of these requirements is described in more detail below.
Once these materials are received, they are validated and examined. A report is prepared on the request by IANA, obtaining the necessary approvals from the various parties involved in the delegation and redelegation, and finally the implementation of the change if agreed upon and approved.
1. The Change Request Template
The template used for delegation and redelegation requests can be obtained from the IANA web site at:
This template is a plain text form to be filled out by the applicant and submitted via electronic mail for processing. Once an applicant has completed filling out the template, it should be sent to IANA’s Root Management team at:
The template should be submitted to IANA be in ASCII plain text format. While it is sometimes tempting for formatting or other reasons to use HTML, RTF, Portable Document Format, or other proprietary word processing formats, please use only plain text. The use of other formats will delay processing as IANA staff will need to convert them.
The applicant may attach the supplemental information along with the original template as email attachments. Another approach would be to wait for the confirmation receipt with its ticket number and then use that number in subsequent messages to send the attachments. In either case, electronic copies of relevant paper-based documentation and supporting materials should be sent as Portable Document Format (PDF) files.
The applicant should also send the original supplemental materials, or official copies, to IANA by post. To send materials by post, please submit the initial template via electronic mail to obtain a ticket number and post the supplemental documents to:
IANA Root Management
Ticket Number: ticket-number
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094
It is requested that the applicant ensures the envelope and correspondence clearly includes the reference number from the template confirmation receipt, to help expedite processing.
Delays in the delegation/redelegation process can also be avoided if the template and other documents sent to IANA are in English. IANA appreciates the fact that diverse languages are in use by ccTLD operators throughout the world. However, IANA does not currently have the resources or ability to ensure accurate and timely translations of templates and supporting documents. Where appropriate, translations of key documents (such as government decrees relating to the request, and so forth) should be notarised official translations.
The template is made up of a number of parts:
- a brief description of the purpose for the change request;
- the identification of the ccTLD itself;
- the identity of the sponsoring organization;
- the administrative contact for the redelegation;
- the technical contact for the redelegation;
- the primary nameserver for the ccTLD;
- a list of the secondary nameservers for the ccTLD;
- the URL for registration services; and,
- the address of the “WHOIS” (port 43) server associated with the ccTLD.
Once the template is sent to IANA, the applicant will receive an automated confirmation of receipt from the IANA’s ticketing system. This confirmation receipt will include a ticket number in the subject line of the message in the form:
Subject: [IANA #ticket-number] Re: subject of message
The ticket number is used to track progress and correspondence related to the request. For this reason it is very important to ensure that the ticket number is included in the subject line – just as it appears in the confirmation receipt – in all future communications related to the request. Failure to include the tag in the subject line of correspondence will delay the processing of your request.
Note that if you do not receive an automated confirmation message from IANA with the above subject line tag within a reasonable timeframe (i.e., less than a day), it is possible your message was inappropriately marked as unsolicited commercial email and deposited in a “spam box” for later review by IANA staff. If this is the case, we apologize. Due to the public nature of IANA service mail boxes, IANA receives a substantial amount of unsolicited commercial email and have been forced to take steps to reduce the load of this email on our processing of requests. Should you experience significant delays, please either call IANA staff at:
+1 310 823 9358
or send a fax to:
+1 310 823 8649
2. Documentation showing that the request serves the local interest
Crucial to the request are statements of support from the local Internet community. This documentation should provide information demonstrating that the request would be in the interests of the Internet community served by the ccTLD.
Good examples of this documentation include statements from national ISPs and ISP associations, Internet user groups, and Internet Society chapters showing support for the request. Other possibilities include statements from national consortia of electronic commerce providers or trademark and intellectual property holders. It would also be instructive to summarise the usage of Internet in the country, and an explanation on why the statements provided (and the organisations they are from) are representative of the community. If there is disagreement about how the ccTLD is run within the community, explain the circumstances and the different points of view, and why your application is the most appropriate path to serve the Internet community’s interests.
Along with the documentation for local support, this part of the application should include a summary of the intended administrative operation of the domain name including, as an example, how names will be added and in what order, removed, how disputes will be resolved.
3. Documentation showing the technical and administrative skills of the applicant
The applicant must show that they have the technical and administrative skills needed to run a ccTLD registry. Examples of documentation that may be included in this section are:
- A description of the staffing, financial and technical resources that would be put in place to serve the ccTLD.
- A description of the applicant’s technical capabilities including the technical plan for both registry and DNS operations.
- The proposed registry/registrar model, if any, along with database capabilities, zone data generation and provision of public whois services.
- Database and physical security for the operation of the ccTLD.
- An explanation of how system outages will be prevented and what system recovery procedures will be put into place for the ccTLD.
- A description of previous registry/database and Internet related experience.
- An overview of the qualifications of financial and business officers and any other relevant management employees.
The list above is not exhaustive but serves as examples of what may be used to help complete this section of the application.
4. Legal company requirements
When ccTLDs were first implemented in the mid-1980s, they were usually assigned to specific individuals to act as custodians and run the domains in the public interest. Today, however, ccTLD operations are normally delegated to organizations. As a result, the applicant needs to describe the legal authenticity, status and character of the organization applying for the redelegation.
Items that might be included in this section are:
- The legal name, principal address, telephone and fax numbers for the organization.
- The organization’s email contact address and URL of its website.
- The Dun and Bradstreet D-U-N-S Number (if any), and/or local company registration numbers, of the organization proposed to become the operator.
- Full names and titles of the directors, officers and all senior managers of the organization proposed to become the operator.
- A short description of the history of the organization that would give the IANA team the ability to assess the size, stability and history of the organization.
5. Transfer Plan
In the case of a redelegation, the applicant should provide information on how existing operations will be transferred to the proposed new operator. It should explain how the stability of the domain will be preserved, and how existing registrants will be impacted by the change. If the application is in relation to a transfer from a retired ccTLD to another ccTLD, it is strongly recommended this plan describe the transfer and decommissioning process for the retired domain.
6. Government contact
In this short section, the applicant should provide documentation indicating that any appropriate government officials have been informed about the request. A statement of support from the relevant government department or agency is effective in meeting this requirement.
7. Fair and Equitable Treatment
Applicants are asked to demonstrate that they will operate the domain in a fair and equitable manner for the local Internet community the domain is designed to serve. This can usually be demonstrated by providing IANA with a domain registration policy that allows all people to register domains on an equal basis, without unduly favouring a particular segment of the community. It is not considered unfair if a domain’s policy limits registration only to people within the country the domain is designated to serve.
After IANA receives the request
Once IANA has sent a confirmation receipt to the applicant for the request and has received the provided supplemental information, IANA begins a process of analysis and verification.
IANA confirms the accuracy of the information provided on the template and makes assessments of the additional documentation provided. In cases involving nameserver changes, IANA performs a series of tests on all nameservers to ensure they are properly configured according to the relevant technical standards.
The amount of time this step takes varies depending upon the depth and quality of information provided in the supporting documentation and the complexity of the individual redelegation case.
There are two possible results from the IANA review step. First, IANA may find that they have sufficient documentation to go forward with the request. In this case, IANA staff begins the process of requesting confirmation of the redelegation from existing contacts. In the event that IANA needs further documentation, it requests that information from the applicant and informs them that the redelegation will not proceed until the documentation and information has been received. If there is no reasonable prospect the redelegation request can succeed, IANA will inform the requestor this and may administratively close the request.
Requesting confirmation from contacts
Once IANA has completed its verification and analysis of the material supplied in the request it then requests, confirmation of the redelegation from the current administrative and technical contacts (if applicable) as well as the newly proposed administrative and technical contacts.
If confirmation is immediate from all parties, IANA proceeds with the next step in the process. In those cases where confirmation is not received from one or more parties, further consultation is necessary. IANA’s experience has been that a failure to receive confirmation from the existing or proposed contacts can significantly delay and complicate the process.
IANA’s experience also suggests that each delegation and redelegation request presents unique challenges. IANA and ICANN are able to assist countries and ccTLDs in meeting these challenges. However, if the applicant ensures all contacts are able and ready to respond to the confirmation request, processing will proceed much more quickly.
Preparing the request for the ICANN Board
ICANN’s Board of Directors votes on all redelegation requests. Based on the information IANA has received from the applicant and the subsequent analysis made by IANA Root Management staff, IANA prepares a report for the ICANN Board of Directors.
This report describes the request, the process used for its evaluation, details the results of IANA’s analysis of the request and provides a recommendation. If the Board votes in favor of the request, the application moves on to the next step. If the ICANN Board of Directors votes against a request, IANA will inform the applicant of that decision and work with the applicant to make sure the reasons for the decision are fully explained. The Board may also decide they need further information or research, in which case IANA will coordinate further work in this area and contact the requestor as needed.
Seeking authorisation for the change
As is required by the current contract under which IANA operates, once the ICANN Board has approved the request, a public report — which is a summary of the longer Board report — is prepared and submitted to the United States Department of Commerce for authorisation. Typically, the US Department of Commerce processes these reports within a business week, however IANA cannot guarantee any specific timeframes under which the application will be approved.
Implementing the change
Once the US Department of Commerce approves the IANA report, VeriSign will implement the name server changes in the root-zone as specified in the request, and IANA will make the proposed data changes needed to implement the conclude the request.
Immediately after being notified that the request has been implemented, the applicant should verify that the changes were made correctly. In the event that any problems arise, the applicant should immediately work with IANA to resolve the issues. For any issues associated with alterations to a ccTLD, the applicant should contact IANA Root Management at email@example.com and use the ticket number provided in the confirmation as a reference.
How long does a request take?
Every delegation or redelegation request is different. With many organizations participating in any particular request, the processing can be affected by delays in coordinating and communicating among the parties, obtaining the necessary approvals, and verifying the information provided. The process can be further complicated when not all parties agree to the request.
Because of this, it is not possible to predict a timetable for the process from receipt of the request through to completed implementation. Fully-formed requests that clearly meet all relevant criteria can take as little as a month or two. In some extreme and complicated cases, requests can take a number of years.
Are there circumstances where some information is not needed?
There are some special cases when less information is required to support a redelegation request.
IANA will check if a change request to a supporting organization reflects a change of administrative responsibility to a new organization that is essentially the same as the previous organization. Situations like this, called an “administrative redelegation”, include where ccTLD management has shifted as the result of an internal restructure, internal governmental restructure, or the entity is renamed or wholly acquired by another entity.
In such cases, to be considered an administrative redelegation, day-to-day operations would need to remain substantially unaltered. For example, there would normally need to be continuity of staff, policy, policy setting structure, levels of service and so on.
When a request is determined to be an administrative redelegation, IANA will allow the applicant to bypass some of the elements of a regular redelegation, such as demonstrating local Internet community support and operational competencies. IANA will also implement the change without the requirement for the ICANN Board to decide the matter.
If IANA considers an application to be eligible for this expedited treatment, it will advise the applicant.