ICANN ICANN Email List Archives

[rsst-report]


<<< 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 >>>

Privacy Policy | Terms of Service | Cookies Policy