Internet Architecture Board

RFC2850

IAB correspondence with ICANN on their “Scaling the Root” study., 14 October 2009

Home»Documents»IAB Correspondence, Reports, and Selected Documents»2009»IAB correspondence with ICANN on their "Scaling the Root" study., 14 October 2009

From: IAB Chair <iab-chair@ietf.org>
Subject: On the “Scaling the Root” study
Date: October 14, 2009 2:29:22 PM PDT
To: Rod Beckstrom <rod.beckstrom@icann.org>, Peter Dengate Thrush < barrister@chambers.gen.nz>
Cc: Thomas Narten <narten@us.ibm.com>, IAB <iab@iab.org>

Dear ICANN CEO and Board of Directors,

The IAB has taken notice of the “Scaling the Root” report about the impact on the DNS Root System of Increasing the Size and Volatility of the Root Zone [1] and has reviewed its high level recommendations.

The report has made a qualitative and, through the referenced TNO report, a quantitative analysis of the provisioning and the publication functions.

The IAB notes with interest that the recommendations of the report, while updated and differing in detail, are essentially consistent with the recommendations on similar topics contained in the [US] National Research Council 2005 report titled “Signposts in Cyberspace”[2]. Because the two reports were prepared from different perspectives and in different organizational arrangements, the similarity of the recommendations should strengthen the conclusion that the recommendations of the present report are not just an artifact of the composition of the committee and the charge to it.

- Provisioning

In general, instabilities in DNS provisioning can lead to errors in root-zone content, and subsequently, problems in global DNS resolution due to inconsitencies in the delegation hierarchy or, inconsistencies in the “chains of trust” needed by DNSSEC. We welcome the attempt of the study team to approach the provisioning from an operational research (OR) perspective and although the IAB does not, as a body, claim expertise in OR, we observe that the report takes a novel approach for ICANN-sponsored studies.

An important take-away is that the OR model seems to suggest that operational changes such as redelegations and possibly changes in DNSSEC information (the report is not specific on what verification will be performed with respect to DNSSEC information) may take on the order of several tens of days, even if the number of zones contained in the root zone is well below 10000. The report suggests that human validation has a role in preventing errors to be introduced in the root zone. On the other hand, such validation implies delays which in turn themselves cause instabilities — such as security lameness because operators of TLDs have moved their nameservers or rolled DNS keys. Further, the TNO model assumes that no errors are being made, while the quality of validation performed by human inspection might decrease with increased stress, more frequent updates, or with other changes that encourage treating validity-checking as a routine task.

- Publication

With respect to the publication of the root zone DNS data the IAB observes that the report has made an attempt to parameterize the throughput of replication from the distribution (database) master to all the authoritative nameservers that serve the root. In the qualitative analysis the point is made that the root server operators, the distribution master producer, and the provisioning entity are all independently functioning actors. We believe that the property of loose coordination between the root server operators brings a number of strengths to the system as a whole; these properties reduce the chances that a failure due to operational, hardware or software problems, or perhaps human error, would have negative consequences for the overall root publication mechanism.

On the other hand, this design introduces a long feedback loop and makes this system slow in responding to significant changes. While the DNS as a whole has the property of being loosely coherent — i.e., most differences in data obtained from the DNS from different places in the infrastructure at the same time can be explained in terms of propagation delays and caching properties — there are certain limits to what inconsistencies the system can absorb, and if parts of the system lag far behind problems might occur (e.g., see RFC 4641, Section 5). To our current knowledge there is no good understanding of the circumstances that can lead to such inconsistencies and the overall consequences of such inconsistencies, especially at the root level.

- Other considerations

The numeric data in the report seems to suggest that, if difficulties occur, they are likely to appear first as provisioning problems rather than publication problems – but the report does not include any investigation into how problems in the provisioning would exacerbate problems in the publication system or the other way around.

The report suggests that the ‘root-server requirements’ (RFC2870, IETF BCP40, an IETF consensus document) needs review. The IAB has traditionally had a role in developing structures to review various technical issues that relate to the Internet. In this case, we believe that an update to such document is most appropriately prepared by the root-zone operators and reviewed for BCP status in the IETF. Were ICANN and/or the root operators to conclude that a standing open and collaborative forum, or some other arrangement, were needed to address issues such as root scaling or (as currently organized in parallel) review of technical DNSSEC design, the IAB would be willing to collaborate in organizing such body.

The report also suggests that the root can grow if that growth is carefully managed and not too sudden. We observe that the introduction of IPv6 glue for existing TLDs is an ongoing and evolutionary process, necessary and well underway already.

The IAB also believes that the current estimates for new TLDs under the so called “fast track” program (estimated to be 50-60 [2]) suggest relatively small changes to the root-zone. However, while this provides a way to estimate the number of Internationalized ccTLDs, it is not clear whether the upper bound of those estimates (which depend on policies relating to assignment per language and/or per variant) will reach or exceed a number for which the root scaling report suggest that problems may start to occur. A slow and careful start of introducing Internationalized ccTLDs is therefore suggested.

We addressed the introduction of Internationalized ccTLDs and the introduction of IPv6 glue. The report discussed two other major changes: deployment of DNSSEC and the introduction of generic TLDs.

The introduction of DNSSEC will modify the dynamics of the system in a significant way. It has an amplifying effect to both the provisioning and the production mechanisms: there will be more changes in the data to be published due to key rollovers at TLD registries and there will be more data that needs to be published. Although the introduction of DNSSEC will modify the dynamics of the system, we do not anticipate it causing more than one disruptive, step-function, occurrence. The IAB supports the recommendation that the introduction of DNSSEC to the root has the highest priority. Note that this does not imply that we think that the introduction of IPv6 glue should be slowed down or delayed in any way; that process is, as discussed above, evolutionary.

Finally there is the introduction of new generic TLDs. Here it is not clear whether there will be an upper bound to the demand. Obviously the growth will occur from market demand as limited by ICANN policy. The IAB believes that security, stability and resiliency are the most important properties of the system and that those should be safeguarded and monitored at all times, even if market forces, combined with threat of legislation, provide considerable pressure for growth.

We believe that no new generic names should be added to the root zone unless stable and robust policies can be established to manage growth with names of given type, and to deal with any problems that arise should demand for new names exceed a rate that can safely be absorbed by the system. Such policies should include the ability to freeze or halt root zone delegations for new names and possibly revoke existing delegations — both may be necessary and depending on the seriousness of the situation it may even be necessary to revoke registration. We note with particular concern that permitting name delegations of certain classes of names will effectively set a precedent that implies additional names of that type will be allowed in the future, making it extremely difficult in practice to deny requests for other names of that type once an initial delegation has been made. For example, one difficult case would concern Brand A acquiring a TLD while Brand B is denied a name (for general stability reasons rather than on merit) leading to complaints of unfairness and possibly legal action. If such policies cannot be established by general and stable consensus, the presumed commercial advantages of adding more names are likely to be given more weight than the risks to the stable and predictable operation of the DNS.

For the IAB,

–Olaf Kolkman, Chair.



[1] http://www.icann.org/en/committees/dns-root/root-scaling-study-report-31aug09-en.pdf (Version 1.0 dd 7 September 2009).
[2] http://www.nap.edu/catalog.php?record_id=11258
[3] http://www.ripe.net/ripe/meetings/ripe59/presentations/uploads/presentations/Tuesday/RIR%20NRO%20Reports/Vegoda-IANA_Update.SAxR.pdf

(Webmaster note: The link to reference [3] has changed since the original correspondence was sent. It is now located here: http://www.ripe.net/ripe/meetings/ripe-59/presentations/vegoda-iana-update.pdf