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 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 will be made available on the IANA web site.
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 will 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. As of the date of publication of this document, 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. 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. Other errors will be the lack of necessary
glue, differences between name server IP address and their respective
glue records, and differences 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 the
anticipated schedule (i.e. zone serial number) on which the change will
be propagated to the root servers. The IANA will track the receipt or
non-receipt of this notice and, upon receiving it, will verify that
it has been properly propagated by issuing queries to the root servers.
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.