[council] Fwd: Root Zone Scaling Myths

Michele Neylon - Blacknight michele at blacknight.com
Mon Jun 26 10:17:14 UTC 2017


Rubens

So technically there’s no issue, but what about operationally / administratively?

Regards

Michele


--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
https://www.blacknight.com/
https://blacknight.blog/
https://ceo.hosting/
Intl. +353 (0) 59  9183072
Direct Dial: +353 (0)59 9183090
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,
Ireland  Company No.: 370845

From: <council-bounces at gnso.icann.org> on behalf of Rubens Kuhl <rubensk at nic.br>
Date: Monday 26 June 2017 at 11:53
To: "GNSO Council List (council at gnso.icann.org) (council at gnso.icann.org)" <council at gnso.icann.org>
Subject: [council] Fwd: Root Zone Scaling Myths



Just to answer a question from James Bladel during the part of the GNSO Working Session I couldn't attend due to conflicting schedule, it was determined at 2009 that the root server system could handle with the then in-use software codebase 100,000 TLDs without performance impacts. Even at that point, one of the DNS software codebases in use by root servers could go up to a million TLDs. Since then, DNS software has greatly improved, memory sizes are now much bigger, computers are much faster; there are TLD zone architectures that current handle 4 million entries and could easily scale up to 10 million without any significant architectural change, so the same evaluation done today would likely give 1 million with not that optimised software or 10+ million, all with open-source, readily-available solutions.

I've recently sent to one the Subsequent Procedures work tracks an e-mail describing some "archeology" on this theme, please see below.


Rubens




From: Rubens Kuhl <rubensk at nic.br<mailto:rubensk at nic.br>>
Subject: [Gnso-newgtld-wg-wt4] Root Zone Scaling Myths
Date: June 18, 2017 at 4:40:49 AM GMT+2
To: gnso-newgtld-wg-wt4 at icann.org<mailto:gnso-newgtld-wg-wt4 at icann.org>


While most current root zone scaling information is available in the CDAR report (https://www.icann.org/en/system/files/files/cdar-root-stability-final-08mar17-en.pdf), I did some research regarding root zone scaling, and found that the most comprehensive source to understand is this ICANN report of 2012:
http://newgtlds.icann.org/en/about/historical-documentation/root-scaling-27jun12-en.pdf

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<http://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.
• Report on the Impact on the DNS Root System of Increasing the Size and Volatility of the Root Zone(https://www.icann.org/en/system/files/files/root-scaling-study-report-31aug09-en.pdf) — This report was developed by a specially convened “Root Server Scaling Team” (RSST), comprised of experts from the RSSAC, SSAC as well as experts from outside the ICANN community.
• 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.
• Explanatory memorandum on Root Zone Scaling(https://archive.icann.org/en/topics/new-gtlds/root-zone-scaling-15apr11-en.pdf) — As part of a number of briefing papers associated with the New gTLD Program following dialogue between the ICANN Board and the Governmental Advisory Committee, ICANN published a memorandum concerning Root Scaling in April 2011.
• 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:
Anticipated delegation rate model: http://www.icann.org/en/topics/new-gtlds/anticipated-delegation-rate-model-25feb10-en.pdf
2010 RSSAC e-mail to Board regarding scaling: https://www.icann.org/en/system/files/files/murai-to-board-25nov10-en.pdf
SAC 042 (https://www.icann.org/en/system/files/files/sac-042-en.pdf) (later superseded by SAC 046)

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





_______________________________________________
Gnso-newgtld-wg-wt4 mailing list
Gnso-newgtld-wg-wt4 at icann.org<mailto:Gnso-newgtld-wg-wt4 at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt4


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/council/attachments/20170626/3c54d023/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 113 bytes
Desc: image001.png
URL: <http://mm.icann.org/pipermail/council/attachments/20170626/3c54d023/image001.png>


More information about the council mailing list