IANA Logo IANA Administrative Procedure
for Root Zone Name Server Delegation and Glue Data

IANA Administrative Procedure for Root Zone Name Server Delegation and Glue Data
12 July 2004


The Internet Assigned Numbers Authority (IANA) is a function performed by ICANN. A crucial aspect of the IANA function is publication of the Top Level Domain (TLD) information, including Whois and name server data. More information about the services IANA provides in this area can be found on the domain name services page (http://www.iana.org/domain-names.htm) of IANA’s web site. Collectively this part of the IANA function is referred to as root zone management.

ICANN and the IANA staff are responsible for certain operational factors that must be taken into consideration in regards to name server (NS) records and their corresponding IP address records (often referred to as “glue”) submitted by the TLD managers for publication in the root zone. These records form the delegation data for the domain. In this case, “delegation data” is a DNS technical term, and does not deal with the management issues related to what is commonly referred to as redelegation of a TLD.

This document is intended for an audience that has a base of knowledge about DNS terminology and operations. It sets out the administrative procedures used by IANA for processing name server change requests submitted by TLD managers, steps taken by IANA in response to requests regarding delegation records that cause significant operational problems for the DNS, and in particular the root servers; and the reasons for each of these procedures. The procedures described apply equally to all NS, glue (A/AAAA), or other records published in the root zone.

For a more thorough understanding of the matters at hand, TLD managers are encouraged to read the documents listed in the references below.

IANA Procedures for Processing Name Server Change Requests

Because changes to the root zone can have global as well as local effects, and because even under the best of circumstances these changes can take several days to reverse because of caching and other factors, it is critical that all changes be carefully examined before they are implemented.

To test name server change requests the IANA staff uses the following procedure. The order of execution of individual steps varies according to the circumstances of the request.

  1. A cross check is performed to determine if the changing resource record(s) affects other TLDs. If so, managers of the affected TLDs are notified. Except in extreme circumstances, no changes will be performed until confirmation is received from each affected TLD.
  2. Each name server listed in the request that is intended to become or remain part of the delegation is checked from several points on the Internet to make sure that it answers standard name server requests for the domain. If not, the TLD manager is contacted with the results.
  3. The complete list of intended name servers for the domain’s delegation is compared against the list of NS (Name Server) records reported by the existing and proposed authoritative servers for the domain to be sure that the two lists match. DNS best practices, as well as significant operational experience demonstrate that this is a crucial aspect of good zone management at all levels of the delegation tree. In the event that there is a discrepancy, and the request does not contain the requisite changes to bring the delegation and the NS records in the zone into alignment, the TLD manager is contacted with this information and asked to clarify the request.
  4. Each of the servers in the request that is intended to become or remain part of the delegation is checked to be sure that the serial numbers and other information in the SOA (Start Of Authority) record match what is returned by the master (also known as primary) server for the domain. Experience shows that when these records do not match it is likely that there are other operational problems with the name server(s) that are not properly synchronized, especially when the unsynchronized server is intended to be added to the delegation.
  5. If the number of name servers or IP addresses in the delegation exceeds eight (8), the size of responses to reasonable queries with the intended delegation will be checked to ensure that such responses fit into a 512 byte UDP packet. This is the standard size limitation for UDP response packets for most resolving name server software on the Internet today.

    In one year the IANA staff will undertake a re-evaluation of the 512 byte limit.

At the insistence of the TLD manager, a name server may be added to a domain’s delegation record that does not meet all the criteria listed in 2 and 3 above. Such exceptions are rare, and made only as a result of careful examination of the circumstances and consultation with the TLD manager.

IANA Procedures for Removing Problematic Delegation Data

In the unlikely event of an extreme operational problem for the DNS, such as unexpected rise in load of the root servers, steps will be taken to restore operational stability. In all such cases the TLD managers affected by the changes will be notified before they are made. Whenever possible IANA will wait for a response before proceeding. In all cases, stability of the DNS must be the primary concern.

  1. If specific NS, glue, or other records are clearly the cause of the operational problem, those records will be removed from the root zone.
  2. If the operational problem is related to the size of the DNS response packet for the delegation, and the TLD manager has specified an order in which to remove such records (see below), that specification will be honoured whenever possible.
  3. In the event that no such specification has been recorded, or in the event that removing records in the order and/or quantity specified does not restore operational stability to the root zone, the delegation will be rolled back to the last known good version. If any name servers from that last known good delegation have subsequently been taken off line, they will not become part of the restored delegation.
  4. In the event that a TLD name server stops responding to DNS queries for an extended period of time IANA shall contact the affected TLD managers using all means available. This includes, but is not limited to, e-mail, fax, telephone, and postal mail. Such notification shall be sent no less than three (3) times at seven (7) day intervals.

If after 25 days the name server is still not responding to DNS queries for the TLD(s), and the affected managers have not specifically objected, IANA may initiate the process to have the name server removed from the delegation(s). Such removal shall not be cause to prevent the name server from being returned to the delegation should the TLD manager submit a change request to the IANA.

Once operational stability has been restored, the underlying cause of the problem shall be investigated, and IANA will work with the TLD manager, root server operators, and other interested parties to achieve the desired result without negative operational consequences.

IANA Procedures for Removal Order of Delegation Data

At the request of the TLD manager, IANA shall record the order in which the TLD manager prefers the delegation data be removed, should the need arise.


Bush, R., et al, “Root Name Server Operational Requirements” (http://www.rfc-editor.org/rfc/rfc2870.txt), RFC 2870, BCP 40, June 2000.

Crocker, S. et al, “DNS Infrastructure Recommendation Of the Security and Stability Advisory Committee” (http://www.icann.org/committees/security/dns-recommendation-01nov03.htm), November 2003.

Souissi, Mohsen, “DNS Response Size and Name Compression” (http://w6.nic.fr/dnsv6/resp-size.html), March 2004

van der Pol, R., et al, “Adding IPv6 glue to the root zone” (http://www.nlnetlabs.nl/ipv6/publications/v6rootglue.pdf), October 2003.

Comments concerning the layout, construction and functionality of this site
should be sent to webmaster@iana.org.

Page Updated 12-Jul-2004
Copyright © 2004 The Internet Corporation for Assigned Names and Numbers, All rights reserved.