August 21, 2006; 04:06 AM
The Internet Assigned Numbers Authority (IANA), a function performed by
ICANN in accordance with its obligations under contract with the U.S.
Government, is responsible for the delegation of top-level domains in the
IANA is seeking to review its practices associated with the technical
checks it performs on data provided by top-level domain operators for
inclusion in the root zone. These checks are designed to ensure the
authoritative name servers meet certain minimum standards required to
ensure the stability of the DNS is maintained.
The aim of this review is to ensure IANA's tests align with the recommended
practices of the technical community, as well as being clear and
implemented in an objective and reasonable manner.
Presently, when a top-level domain (TLD) operator requests a change to its
authoritative name servers listed in the root zone, IANA undertakes
verification checks to ensure the correct parties consent to the request.
At this initial stage, the name servers supplied are also tested for a
variety of characteristics.
Once the IANA process of verifying and evaluating the request is complete,
IANA repeats the name server tests to ensure they are still correctly
configured and available. This second test is to ensure that any
substantial delays in obtaining consent, or time spent evaluating the
request (in the case of reassigning the operator of a TLD), haven't
resulted in a change in the status of the name servers.
In line with IANA's operating conditions, the request is then sent to the
US Department of Commerce for review, and ultimately to VeriSign for
implementation in the root server network. At this stage, VeriSign
additionally performs its own checks before implementation in the root
The tests can be broadly grouped in to two categories — mandatory
requirements, which are properties the name servers must exhibit or else a
request will be refused; and recommendations, which will result in a
dialogue between IANA and the requestor to verify if they are sure about
their request. Mandatory requirements are checks for the essential
characteristics of an authoritative name server set, whilst recommendations
refer to signs that the request might be in some way deficient.
The tests that IANA conducts today are:
Minimum number of name servers.
There must be at least two name servers supplied, and they must not share
the same IP address.
Maximum number of name servers.
There must be no more than 13 name servers supplied.
The supplied hostnames for the authoritative name servers must be fully
qualified domain names, with labels no longer than 63 octets.
Name server reachability.
The supplied authoritative name servers should be verifiably reachable
over the public Internet. IANA sends a DNS query over UDP for the SOA
record of the top-level domain, and looks for a DNS answer in response.
IANA sends the query from its American facilities, and should that fail,
tests it from sites in Europe and the Asia-Pacific. If IANA is unable to
receive DNS answer packets in response to those queries from any location,
or if it has limited connectivity that appears unreliable, it clarifies
the situation with the requestor.
Name server authority.
In response to a query for the SOA record for the top-level domain, each
of the supplied authoritative name servers must respond with a DNS answer
with the "AA" bit set. (see RFC 1035, Section 4.1.1)
Name server coherency.
IANA checks that the requested name servers match the "NS" Resource Record
set in the children. IANA queries the NS RR-set returned by the
authoritative name servers, and compare them to the supplied NS records
for the root zone. These should match.
Glue coherency with hostname.
IANA checks the A and AAAA records of the authoritative name servers, and
compares them to the supplied glue records for inclusion in the root zone.
These should match.
Glue coherency with existing glue.
IANA checks if other top-level domains use the supplied glue if the
request represents an alteration to the name server's IP address. If the
name server hostname is shared, it is not a technical failure per se, but
IANA advises the applicant that it requires consensus from all affected
parties, and starts a dialogue to check whether or not to proceed. (Note:
this particular practice is the subject of a separate forthcoming IANA
Serial number coherency.
IANA checks the serial numbers in the SOA records supplied by the
authoritative name servers. These should match.
Minimum network diversity.
IANA asks that the name servers be on geographically and network
topologically separated networks. IANA currently loosely tests this by
querying with the applicant on their network setup should all name servers
be in the same "/24" IPv4 range.
Name server continuity.
Should the request involve completely changing every NS record in the
root, IANA asks the requestor to consider staggering the request in two
passes such that any unexpected faults might be mitigated.
VeriSign, in its role as implementor of IANA-approved changes to the
primary root name server, additionally tests for the following
characteristics which are NOT tested by IANA during its processing:
Whether the name servers have matching PTR records (both IPv4 and IPv6)
Whether the name servers have RFC 1918 addresses. (Note: supplying such an
address would ordinarily fail IANA's tests due to unreachability.)
Whether the IP addresses are on the list of reserved IP addresses.
Whether the last octet of the name server IP address is 0 or 255.
Whether the overall length of the name server hostname is less than 128
IANA's tests err on the side of caution by clarifying potential problems
with the requestor. After this discussion, IANA generally allows the
administrator to insist that it implement the changes as requested unless
it will cause a demonstrable problem. In practice, however, in almost every
case it has been a configuration error that the requestor has been happy to
fix. In some cases, the requestor has advised it is an issue they are aware
of, but are not in a position to fix until the request has been implemented
(such as in the case of a full reassignment of the operator of a TLD, or a
change of technical operator).
Some of the relevant issues to consider:
As part of an effort to automate components of the IANA root zone
management process that would otherwise need to be conducted manually,
IANA seeks to have technical tests which are automatable. The ability for
operators to perform automated tests for compliance, as well as
independently test their request against objective criteria, is highly
There may be additional technical checks that should be added — such
as calculating response sizes and ensuring they are within a certain size
(i.e. 512 bytes), and testing whether authoritative name servers have
If it is retained, IANA would like to find a more appropriate mechanism
for the network diversity test — possibly involving the testing of
network AS paths.
IANA would ideally like to harmonise its technical requirements with
those of other parties such as VeriSign, in order to not unnecessarily
delay a request due to a disparity between differing requirements.
IANA only conducts testing in conjunction with a change request. There is
presently no ongoing compliance testing.
Under the present procedure, a change to one name server can be held up by
a defect in another name server — even if the defective name server
is already listed in the root zone, and not being altered by the request.
With these issues in mind, IANA is seeking community input on which
technical standards should be required for entering data into the root
zone, and how to test for matches to those standards.
Which technical requirements should be mandatory for TLD operators to
comply with in order for changes to be accepted in the DNS root?
Which issues should be highlighted as warnings by the technical review
Under which circumstances should these warnings be allowed to advance if
the TLD operator wishes to still proceed?
How should these technical requirements be implemented in an automated
What role, if any, should IANA play in the ongoing verification of
compliance by TLD operators to minimum technical standards?
Comments can be submitted by sending email to
Comments will be viewable at
The comment period will be open until 30 September 2006.