Abstract

This document is a response to IANA's request for review of the procedures related to root zone management issued on 18 August 2006.

Table of Contents

1.  Overview
2.  Executive Summary
3.  Suggested Test Regime
4.  Regular, Scheduled Testing
5.  Roles of the IANA and Verisign
6.  Treatment of WARNING Conditions by the IANA
7.  Renumbering Nameservers
8.  Documentation
9.  References
§  Authors' Addresses

1. Overview

This document is a response to the IANA's request for public review of the procedures related to root zone management issued on 18 August 2006.

2. Executive Summary

Afilias is very much in favour of the general practice of performing technical validation of change requests before they are implemented. Such checks ought to provide little or no inconvenience to established, experienced TLD operators, and play a useful role in knowledge transfer to those TLD operators who are less experienced, to the benefit of registrants and users of the Internet in general.

Afilias believes that while failures of some checks ought prevent the corresponding changes from being implemented, other checks ought at most to generate warnings, and should not prevent changes from being implemented.

Afilias believes that the IANA should perform the same set of automated checks against every TLD on a regular schedule, and communicate any issues that become apparent to zone operators in a proactive manner. This will increase contact between the IANA and zone operators who have technical challenges to overcome, and should help avoid the problem of urgent change requests being held up because of pre-existing technical problems.

Afilias believes that the IANA should direct VeriSign Global Registry Services in the checks that VeriSign performs as part of its management role for the root zone, and the circumstances in which Verisign should properly refuse to implement a change should be clearly defined.

Afilias believes that the IANA should maintain technical point of contact information for nameservers, as well as zones. In the event that a change request relating to the renumbering of a nameserver is received from a zone operator, the nameserver operator should be contacted for confirmation, but the operators of other zones delegated to that nameserver should receive a courtesy notification of the change only; they should not be required to confirm acceptance of the change. It should be possible for a nameserver operator to request changes to the root zone in the event that the nameserver must be renumbered.

Afilias suggests that the IANA should publish the complete procedure for requesting and processing changes in the root zone through the IETF as one or more Informational RFCs.

3. Suggested Test Regime

The following tests are numbered according identically to those in the IANA's request for comments where they already exist, for ease of reference. Tests are annotated as follows:

MANDATORY

A failure of this test should result in the change request being denied.

WARNING

A failure of this test should result in a warning message being sent to the requestor by a human operator. The operator should confirm through dialogue with the requestor that the issues encapsulated in the warnings are well-understood. The requestor may opt to proceed with the change as submitted.

DELETE

This check should be removed.

MODIFY

This check should be modified.

ADD

This new check should be added.

(1)

Minimum Number of Nameservers. MANDATORY, MODIFY. The requirement that the nameservers should not share the same IP address is unnecessary; topological diversity is ensured through test (10).

(2)

Maximum Number of Nameservers. DELETE. This requirement is encapsulated more appropriately within proposed new test (a).

(3)

Hostname Validity. MANDATORY, MODIFY. The requirement should be changed to match exactly what is specified in [RFC1034] (Mockapetris, P., “Domain names - concepts and facilities,” November 1987.) section 3.5.

(4)

Nameserver Reachability. MANDATORY.

(5)

Nameserver Authority. MANDATORY.

(6)

Nameserver Coherency. WARNING. The delegation NS set in the root zone may legitimately differ from the apex NS set in the delegated TLD zone, e.g. as part of a transition plan from one set of authority servers to another.

(7)

Glue Coherency with Hostname. MANDATORY.

(8)

Glue Coherency with Existing Glue. DELETE. A request to change a glue record in the root zone in order to renumber a nameserver should be processed as such, and should not trigger warnings. See also Section 7 (Renumbering Nameservers).

(9)

Serial Number Consistency. WARNING. For some zones, a difference in SOA serial between authority servers is a natural consequence of the rapid turnaround of changes submitted to a registry.

(10)

Minimum Network Diversity. MANDATORY, MODIFY. Network diversity cannot be judged accurately by simply calculating the arithmetic distance between IP addresses, nor by comparing observed AS_PATH attributes in covering routes. A combination of checks should be used to allow the IANA to gauge whether an NS set has appropriate topological diversity. The requirement should be that not all nameservers are colocated, not that no two nameservers are colocated.

(11)

Nameserver Continuity. WARNING. There are legitimate reasons for changes to be processed in a single atomic operation, without staging changes in the NS set as described.

(12)

Whether Nameservers have Matching PTR Records. WARNING. Although the management of PTR records is to be encouraged, their absence does not impact the performance of the DNS.

(13)

Whether Nameservers have RFC 1918 Addresses. MANDATORY. Due to lax operational attention to the uses of these address ranges on the Internet, it is possible to conceive of circumstances in which nameservers so-numbered might pass other tests, and so this ought to be checked explicitly.

(14)

Whether Nameservers are on the List of Reserved IP Addresses. MANDATORY, MODIFY. Reference should be made to [RFC3330] (IANA, “Special-Use IPv4 Addresses,” September 2002.), to IPv4 multicast addresses and to the Unspecified, Loopback, Link-Local, Site-Local and Multicast IPv6 addresses specified in [RFC4291] (Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” February 2006.).

(15)

Whether the Last Octet of the Nameserver IP Address is 0 or 255. DELETE. This requirement is obsoleted by [RFC4632] (Fuller, V. and T. Li, “Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan,” August 2006.).

(16)

Whether the Overall Length of the Nameserver Hostname is less than 128 Characters. DELETE. This requirement is encapsulated more succinctly in proposed new test (a).

(a)

Size of Referral NS RRset and Glue. MANDATORY, ADD. The size of the AUTHORITY and ADDITIONAL sections in a referral response from a root server should be sufficiently small that reasonable questions can be answered with a useful set of courtesy glue over UDP Transport without requiring EDNS0. The functional details of the corresponding test for this requirement should be specified with the assistance of root server operators.

(b)

EDNS0 Support. WARNING, ADD. Every nameserver should support [RFC2671] (Vixie, P., “Extension Mechanisms for DNS (EDNS0),” August 1999.).

(c)

TCP Transport Support. WARNING, ADD. Every nameserver should support queries on both UDP and TCP transport.

4. Regular, Scheduled Testing

Afilias believes that the IANA should carry out regular, scheduled, automated testing of TLD zones and should make proactive contact with zone operators in the event that problems are detected.

Early warning of test failure gives zone operators more opportunity to resolve problems, compared with the current process in which an urgent change request can be denied due to pre-existing problems unrelated to the requested change.

5. Roles of the IANA and Verisign

The IANA should carry out all tests, and should reject or clarify requests in the event that failures are evident in MANDATORY or WARNING checks, as appropriate.

Verisign should carry out MANDATORY tests only.

Afilias believes that there is benefit in having both the IANA and Verisign carry out the same set of MANDATORY tests, since this provides codebase diversity and helps to guard against systematic false negative responses from tests.

6. Treatment of WARNING Conditions by the IANA

In the event that a request is received which pre-acknowledges the results of one or more WARNING tests, the request should proceed without requiring further acknowledgement of the WARNING test results by the requestor.

For example, a zone operator may be well aware that SOA serial numbers may differ between authority servers due to the architecture in place for zone changes to propagate between authority servers. If acknowledged in the original request, processing of the request should not be held up by the results of the corresponding WARNING test carried out by the IANA.

7. Renumbering Nameservers

Afilias suggests that the IANA should maintain point of contact details for nameservers for which glue exists in the root zone, as well as for zone operators.

A request to renumber a nameserver should be accepted from the operator of any zone delegated to that nameserver, but confirmation from the nameserver operator for the change should be sought before the change is allowed to proceed. Requests to renumber a nameserver should also be accepted by the nameserver operator.

When a nameserver is to be renumbered, notification of the change should be sent to the operators of all zones delegated to that nameserver. An additional delay should be instituted to give zone operators the opportunity to request changes to their zones' nameservers in response to the proposed nameserver change.

8. Documentation

Afilias believes that the IANA should publish the procedures and functional specification of the tests carried out in the IETF, as an informational RFC. Future changes to procedures or to the tests should be published as additional RFCs in the usual manner of the IETF.

9. References

Authors' Addresses