IANA Administrative Procedure for Root Zone Name Server Delegation and Glue Data
12 July 2004
Introduction
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- If specific NS, glue, or other records are clearly the cause of the
operational problem, those records will be removed from the root zone.
- 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.
- 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.
- 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.
References
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. |