While most current root zone scaling information is available in the CDAR report (
), I did some research regarding root zone scaling, and found that the most comprehensive source to understand is this ICANN report of 2012:
Besides all its interesting content, they compiled a list of previous root zone scaling studies that I reproduce here, changing only the link style and updating the links to their current publishing points:
"Appendix A — Previous Studies and Analyses
A number of studies and analyses have been compiled on the topic of scaling of the DNS Root Zone in the last three years:
• Root Zone Augmentation and Impact Analysis(
https://www.icann.org/en/system/files/files/root-zone-augementation-analysis-17sep09-en.pdf) — This study, also known as the “L-Root Study,” examined the impacts of multifaceted growth of the size of the Root Zone on the performance of “
l.root-servers.net,” the root server that is managed by ICANN. This analysis considered the implications of IPv6 addresses, DNSSEC, as well as new TLDs in a laboratory simulation. The work was conducted by the independent DNS Operations and Research Center (DNS-OARC). This study was published in September 2009, and its conclusions include that root zone servers’ requirements for memory grow linearly with the number of top-level domains, that the then-deployed software was capable of handling at least 100,000 top-level domains before there was potential degradation in response times. Other software in use had higher thresholds (i.e. over a million TLDs) before the size of the root zone became a factor.
• Summary of the Impact of Root Zone Scaling(
https://archive.icann.org/en/topics/new-gtlds/summary-of-impact-root-zone-scaling-06oct10-en.pdf) — An analysis of issues relating to the impact of Root Zone Scaling was prepared by ICANN and published the document in October 2010. This document considers the findings of the DNS-OARC and RSST reports, and the various root scaling events to date. It identifies the impacts from IPv6 deployment, TLD growth, DNSSEC deployment and other factors, and concludes the maximum growth to the Root Zone caused by the New gTLD Program is unlikely to cause any disruption.
• Report of the Security and Stability Advisory Committee on Root Scaling(
https://www.icann.org/en/system/files/files/sac-046-en.pdf) — ICANN’s Security and Stability Advisory Committee reviewed the original research questions relating to Root Zone Scaling, and provided recommendations relating to processes to handle the increase in the number of top-level domains.
• Board response to the GAC on Root Zone Scaling(
https://archive.icann.org/en/topics/new-gtlds/root-scaling-30may11-en.pdf) — ICANN published an additional response to the issues raised on dialogue between the ICANN Board and the Governmental Advisory Committee, by providing further detail on how ICANN undertakes to address the ICANN community’s and the GAC’s concerns regarding root scaling. This response was published in May 2011."
Besides those documents, the other interesting documents on this are:
In short, the anticipated delegation rate model estimated the maximum *evaluation* throughput to be near a 1000 per year, and other ACs responded that it wouldn't be a problem to be delegated. They have not said that the system had a 1000/year limit, a myth that started only when the number of applications (near 2000) exceeded the high estimate of applications (a thousand), that discussion went stray and landed at that being a limit.
Since those studies, processing power, memory sizes, DNS software design and available bandwidth all greatly increased, so even figures that were determined at that point (like the 100,000 TLDs root zone size) are outdated, although still limited by latency of the global Internet (which is mainly determined by the speed of light in optical fiber). The root zone now features DNSSEC and IPv6 to most TLDs, so something that was an unknown at that time is now a baseline, the root zone management system has been completely rewritten, and root server monitoring instrumentation greatly improved (see RSSAC 002,
https://www.icann.org/en/system/files/files/rssac-002-measurements-root-06jun16-en.pdf)
But, we didn't get an RSSAC response to our CC2 question on the CDAR report, nor they mentioned this in their comments to the CDAR report which were mostly clarifying questions. I believe we could ask them to clarify that and clear the fog in this topic.
Rubens