Comments Sought on Technical Checks Used for DNS Root Zone Changes
18 August 2006
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 DNS root.
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.
Background
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 zone.
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. -
Hostname validity.
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 the IP address under test has limited connectivity that appears unreliable, IANA 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 discussion paper) -
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 characters.
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 valued.
- 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 recursion disabled.
- 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.
Guiding questions:
- 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 process?
- 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 environment?
- 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 techcheck-comments@icann.org. Comments will be viewable at http://forum.icann.org/lists/techcheck-comments.
The comment period will be open until 30 September 2006.