Comment Sought on DNS Root Zone Glue Policy

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 how it maintains IP address information in the root zone, commonly known as “glue”.

Background

In administering alterations to the DNS root zone, each top-level domain operator supplies IANA with a list of authoritative name servers, along with IP addresses so that they may be inserted as glue records into the root zone. The purpose of glue is defined in RFC 1034, from section 4.2.1.

The representation of an authoritative name server’s IP address (or set of IP addresses) in the DNS should be congruent between the IP address specified in the authoritative zone for that host, and that listed as glue. Inconsistencies in glue data can result in technical instability of the DNS.

IANA relies on the top-level domain operator to submit the correct glue data in conjunction with a change request. As part of its technical testing, IANA will ensure the new proposed IP addresses pass the appropriate technical tests. Once this testing is complete, the administrative and technical contacts for the domain must approve the change, and once approved IANA will insert or amend the glue data in the root zone.

In some circumstances, an authoritative name server is shared by more than one top-level domain. In these situations, if there is a move to alter the glue data, IANA takes a conservative approach by requiring that ALL affected top-level domain operators actively consent to the alteration.

In practice, this procedure has resulted in a severe hindrance to some changes to root zone data. Some authoritative name servers are shared by over 30 different top-level domains. Changes to their glue data would require the active consent of the administrative and technical contact of each of those domains, possibly up to 60 persons. A single unresponsive top-level domain administrator from that group could derail changes, and in practice this has occurred on a number of occasions. IANA staff does their best to resolve these situations and this usually results in months of research and substantial intervention.

Duty-of-care to TLD operators

The current active confirmation seeks to ensure the TLD operator is fully aware of the renumbering of one of their authoritative name servers. This gives them the opportunity to identify possible configurations changes they need to make to ensure continuity of service. Changes to this role may need to consider the impact on TLD operators, and what IANA’s duty of care is to inform TLDs of impending changes that impact them.

Possible Approaches

Some of the possible approaches that have been raised include:

Retain same approach. IANA does not consider this desirable, but the community may feel the current approach is appropriate to maintain.

Reduce acceptance threshold. Instead of requiring every administrative and technical contact to approve, the threshold could be at a minimum the requesting administrative and technical contact, or be a lower figure than 100%. For illustration, a hypothetical criteria may be “The changes must be approved by the administrative and technical contacts of either two affected TLD operators, or 20% of affected TLD operators – whichever is higher.”

Allow changes with a mandatory advisement and wait period. Once the acceptance criteria is met, if it has not been accepted by 100% of affected parties, IANA can notify all administrative and technical contacts of the nature of the change and give them a fixed time (e.g. 30 days) to make necessary alterations before changes are made to the root zone.

Introduce name server operators as participants in the process. Changes are requested and coordinated with the administrative and technical contacts of a domain. These are not necessarily the same parties that operate the authoritative name servers for a domain. These operators may authorize changes instead, although such an approach would be a radical departure from current operations and would require a new procedure that dealt with the roles and responsibilities of these operators, as well as IANA procedures to authenticate these parties.

This list is not exhaustive, and IANA welcomes contributions on any feasible solution. Particular regard would be paid to solutions that are automatable, in line with IANA activity that seeks to automate the processes associated with routine changes to the DNS root zone.

Guiding questions

1. How should IANA accept requests to alter root zone glue? (either in general, or specifically for shared glue)

2. What criteria should be used to approve shared root zone changes?

3. In the event that an affected party contests a change, how should this conflict resolved and on what grounds can a change proceed regardless?

4. Are there any other unintended consequences of renumbering a shared name server that have not been considered?

Comments either to the questions posed, or the issue in general, can be submitted by sending email to root-glue-comments@icann.org. Comments will be viewable at http://forum.icann.org/lists/root-glue-comments.

The comment period will be open until 31 January 2007. At the conclusion of this comment period, a staff report on the comments and a recommended operating procedure will be developed.

Reference

• A document seeking to clarify glue technical issues is currently being developed within the IETF. It is currently in draft but may prove useful in this discussion. The present draft is available at http://www.ietf.org/internet-drafts/draft-koch-dns-glue-clarifications-02.txt.