Dedicated to preserving the central coordinating functions of the global
Internet for the public good.

Procedures for Handling Requests by ccTLD Managers to Change Nameservers
(effective 30 May 2003)

Preamble: This document modifies the procedures followed by the IANA as of 19 March 2003. This document has been coordinated between the IANA and a group of ccTLD managers and members of the ICANN Security and Stability Advisory Committee. The intent of these changes is to streamline the procedures for ordinary changes without compromising the minimally necessary checks for the integrity of the top level of the domain name system.Preamble: This document modifies the procedures followed by the IANA as of 19 March 2003. This document has been coordinated between the IANA and a group of ccTLD managers and members of the ICANN Security and Stability Advisory Committee. The intent of these changes is to streamline the procedures for ordinary changes without compromising the minimally necessary checks for the integrity of the top level of the domain name system. This document is created by agreement between the ccTLD community and the IANA and is to be updated and modified as experience warrants. In this respect, this document has roughly the same status an IETF Proposed Standard, viz it represents consensus after best effort to define the process and will be reviewed after there is implementation experience.

This document specifically focuses on the procedure for handling requests for changes in nameserver information in the root zone relating to ccTLDs. gTLD changes have various minor differences based upon contractual relationships.

1. Receive request from TLD operator.

The ccTLD manager should fill in and send a complete a "Modification Template" to <root-mgmt@iana.org>. The template is available on the IANA web site. <http://www.iana.org/tld/cctld-template.txt>

2. Acknowledge request

Upon receipt of the request the IANA will reply to the person sending the request plus the administrative and technical contacts of the ccTLD (if different).

At this time the IANA will issue a ticket number in the format of:

ROOT-MGMT#YYYYMMDDNNN

The ticket will be initially be flagged OPEN-IANA.

OPEN refers to the unresolved status of the ticket. IANA refers to the person who should take action.

Other status possibilities include. OPEN-TLD, OPEN-DOC and OPEN-IMPLEMENT-CHANGES and CLOSED.

3. Initial template review

The IANA staff will review the template and, as necessary, revise it to ensure that it precisely defines the change to the root zone being requested and, ordinarily, to separate requests for other types of changes to avoid delays in making the nameserver changes.

4. Verify request

The IANA staff will verify authorization/authenticity of the request and obtain confirmation from the listed TLD administrative and technical contacts that those contacts are aware of and in agreement with the requested changes. A minimum authentication of an exchange of e-mails with the e-mail addresses registered with the IANA is required. If the address does not match or the IANA has reason to believe the person using the e-mail address does not have current authority for the domain, the IANA will investigate further.

The ticket status will change between OPEN-IANA and OPEN-TLD as e-mail exchanges take place. In the event that an authentication fails, an explanation of the failure will be sent to all involved in authentication process and the ticket will be closed; at this point the ticket status is set to CLOSED. If the requester believes that this is incorrect, sending an e-mail with the ticket number will re-open the ticket. Refer to the ticketing system information for exact details.[NOTE: Information page being prepared.] In the event that the requested change affects other TLDs, such as an IP address change of a common nameserver, IANA will confirm with the machine owner that the change is indeed correct. The IANA will inform all other affected TLDs before updating the glue record in the root-zone.

5. Assess name server transition sequence to ensure that it provides continuous name service for the TLD

In the event of a complete change of all servers the IANA may request that some form of staggering of changes take place if it becomes apparent that not doing so may cause the TLD to become temporarily unavailable for portions of the network.

6. Verify new name server operational status/standards compliance, using DNS queries and other tools such as ping and traceroute

The initial test will be in the form of a query to each server requesting the SOA and NS resource records for the affected ccTLD. The expected result would be that all machines give authoritative answers with the same serial number and that they list an identical set of authoritative servers. Differences will be considered as an error. If an error occurs the IANA staff will attempt the tests at a later time and from a topologically diverse machine to minimize the chance that the issue is one caused by connectivity problems. The IANA will also check for necessary glue, consistency between name server IP address and their respective glue records, and consistency between NS records at parent and child.

Apparent lack of topological diversity, invalid e-mail addresses in the SOA, and other items non-critical to the functioning of the zone or the root servers and their ability to return answers will result in a "Warning" or "Alert" being sent to the listed technical and administrative contacts. Errors will result in the IANA staff waiting for correction before implementing the zone changes. "Warnings" or "Alerts" will result in a request for confirmation that the ccTLD administrative and technical contacts are aware of and understand the issues. With the exception of lack of topological diversity, improvements in response to these "Warnings" generally do not require IANA staff involvement as they take place outside the root zone. The IANA staff will work with the technical and administrative contacts to assist in addressing any technical issues.

7. Submit request for root-zone change to U.S. Department of Commerce for approval

The IANA staff will submit the request for change to the DoC and the root-zone editor. Any special instructions, such as special timing needs, will be included with the request. At this point the status of the ticket will be changed to "OPEN-DOC" and the requesters will be informed of the status change.

8. The Department of Commerce approval will be sent to the IANA and the root-zone editor

Once the IANA receives notification of the approval, the ticket status is changed to OPEN-IMPLEMENT-CHANGES. The root-zone editor will implement the approved changes according to any timing or other requirements in the submitted request.

9. Monitor making of change to root zone

Upon making the necessary change in its registry database, the root-zone editor will notify the IANA that the change has been made and say when the change (i.e. zone serial number) is expected be propagated to the root servers. The IANA will track the receipt or non-receipt of this notice. Upon receiving it, the IANA will query the root servers to verify that it has been properly propagated. Upon this verification, the ticket will closed and the ccTLD technical and administrative contacts will be sent a final e-mail ticket noting these facts and listing the current status of the ccTLD. At this point the ticket status is CLOSED.

(19 March 2003; updated 13 May 2003)