More about the root zone scaling, letter from the the IAB

From: IAB Chair <[log in to unmask]>
Subject: On the "Scaling the Root" study
Date: October 14, 2009 2:29:22 PM PDT
To: Rod Beckstrom <[log in to unmask]>, Peter Dengate Thrush <
[log in to unmask]>
Cc: Thomas Narten <[log in to unmask]>, IAB <[log in to unmask]>



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