root scaling model

[Elaine Pruis <elaine.pruis@xxxxxxxxxxxxxxxxx>]

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