<<<
Chronological Index
>>> <<<
Thread Index
>>>
root scaling study report comments
- To: rsst-report@xxxxxxxxx
- Subject: root scaling study report comments
- From: Elaine Pruis <elaine@xxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 29 Nov 2009 23:17:43 -0800
Writing in my personal capacity.
Dear ICANN,
Thank you for the opportunity to comment on the root scaling report
and the root scaling model.
The hard work of the Root Scaling Study Team and TNO to address the
call for analysis of root scaling capabilities is recognized. However
the report has serious problems that must be addressed.
The study is contradictory and several of the recommendations are
unsubstantiated by the qualitative and quantitative evidence.
Furthermore alternate studies such as the "Root Zone Augmentation and
Impact Analysis" present incompatible findings. ICANN should not
employ the recommendations from the report without an internal review
of the report, further development of the model, and affirmation of
the findings from the root server operators.
The conclusions of the report are not substantiated by the
quantitative results. The root scaling model is: incomplete; only
establishes today's baseline; is not predictive; and merely factors in
today's known variables (it does not account for process changes in
provisioning for DNSSEC and assumes that RZ-WAS is deployed although
according to some parts of the report it is not). The report notes the
complexity of combinations proves the model used for simulation needs
improvement. Therefore the model cannot be relied upon to make a
definitive judgement about the capacity for the root to scale. Since
"the model was constructed from incomplete information over a
relatively short period of time" it should not be the basis of
qualitative decision making. Finally, the report warns the reader "no
conclusions should be based on the current results of the model, as
doing so would be premature."
In fact, the report notes that the root operators strive for diversity
in hardware and procedures, making it "very difficult to predict the
capacity of the entire system in any way"!!
The report states: "if the rate of change becomes too steep, the root
server operators will not be able to follow without changing their
established normal state OAM&P. " This implies the root can't handle
scaling without a change in the current system. What exactly are the
barriers to change: adding more staff, servers, and upgrading
hardware? If it is the voluntary nature of the system or the lack of
funds, a grant system could be created (with funds collected from the
$25k tax on new TLDs) to alleviate those costs.
The root server operators ultimately have the opportunity to add
hardware, staff and other resources to deal with the increase in zone
file size. Historically the root server operators have been able to
meet scaling of the root, i.e. 250 new ccTLDs added, and IPv6
additions (now at 15%). The report gives historical example of the
system meeting capacity... "because of anycast deployment, load
balancing and multiprocessing...the number of computers at each root-
server address is effectively unlimited... it is plausible to expect
continued improvements in computing and communications performances."
It seems that the strong recommendation to add DNSSEC to the root zone
directly contradicts the stated goal of the report where "ICANN must
ensure that potential changes in the technical management of the root
zone and scope of activity at the TLD level within the DNS will not
pose significant risks to the security and stability of the system."
The report states "with aggressive re-planning the system is capable
of managing the risks associated with adding either (a)DNNSEC or (b)
new TLDs, IDNs, and IPv6 addresses over a 12-24 months - but not both."
There is no evidence in the root scaling model conclusions nor the
qualitative analysis that this is true. Rather the report states that
IPv6 are already present in the root zone, are being added at a steady
pace. The root operators have managed this growth successfully. It
also states that new TLDs and IDNs are not considered to be overly
taxing as they do not increase the zone file size significantly.
The qualitative statements imply that the bottlenecks are actually
humans and not hardware. "On the provisioning side the ability to
scale the root is completely dominated by the steps that involve human
intervention". If there are not enough people involved in the
verification process to support an increase in the number of TLDs or
change orders, increasing staff levels solves this issue. Even if
"the NITA does not plan to change the way in which it exercises its
oversight role", it might have to reconsider that position in order to
accommodate the recommendations of the community to allow for
security, stability and innovation.
The stated problems of a misconfigured firewall not being able to
process the larger DNSSEC request can be solved by configuring the
firewall correctly. An education campaign will solve this problem.
DNSSEC solves the DNS cache poisoning problem, but it seems the "cost"
of a required deployment may outweigh the benefits. DNSSEC has been
around for more than a decade, yet the uptake has been very limited.
DNSSEC only solves one security problem, it does not make the Internet
as a whole secure. Consumers do not demand DNSSEC. Registrars must
hire a specialist and re-engineer their systems to implement the key
signature system. TLD operators must develop a keystore that is
complicated and requires substantial programming.
The report states "If a choice must be made, DNSSEC should come
first," and "deploying DNSSEC before the other changes have increased
the size of the root would significantly lower the risk it presents to
DNS stability." DNSSEC actually exacerbated the time to solve the
problem of an errant root zone file update as evidenced by the
disappearance of .se from the Internet.
DNSSEC has the greatest effect, causes the greatest risk to stability,
and isolates and disenfranchises areas with low bandwidth. "Adding
DNSSEC, either to the root zone as presently constituted or in
combination with the other changes... would immediately push the root
server operators in to a re-planning discontinuity."
Do the benefits of mandatory DNSSEC implementation override the
benefits of adding IPV6, IDNs and new TLDs? How does the report
justify the disenfranchisement of poorly connected internet locations?
Remote anycast servers could fall off the list of possible sites that
can be served today. If the entire root is DNSSEC signed, these
regions will be broadly affected. This is certainly not part of
ICANN's mandate. "The widespread distribution of anycast satellites
of the root servers has improved the level of service provided to many
perviously less well served locations" and "the rapidly increasing use
of anycast addressing has enabled the root name server system to
respond to both the technical and institutional requirements through
the addition of multiple geographically distributed anycast root
server satellites."
These factors need to be considered before any decisions are made
based on the recommendations of the root scaling report.
If ICANN takes up the Expressions of Interest proposal where the
number and type of new TLDs are made known, several of these questions
could be factored into further analysis.
Elaine Pruis
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|