1. Revisiting the Root
David Huberman
ICANN’s Office of the CTO

2. Overview A Brief History of the Root Server System
Root Server Instances in the RIPE NCC Service Region
Root Server System Governance
Distribution of the Root Zone

3. A Brief History of the Root Server System

4. 1983
DNS defined
The DNS specification was first published in November 1983 when Paul Mockapetris published RFC882

5. 1984 First root server established at
University of Southern California’s
Information Sciences Institute
(USC ISI)
The hierarchy Paul envisioned required a server to function as the root of the tree.  In 1984, Paul setup the first root server at the University of Southern California’s Information Sciences Institute, which for the rest of this presentation will be referred to as “USC ISI” or just “ISI”.

6. 1985 Four root servers: two on each U.S. coast
In 1985, we expanded from one root server to four. There were two root servers at ISI in California, and two more root servers on the U.S. east coast: one at SRI in suburban Washington DC, and one at the Army’s Ballistic Research Laboratory in Aberdeen, Maryland.

7. 1987 Seven root servers: SRI – ISI – RPI – U. of Maryland –
U.S. Air Force – NASA – U.S. Army
By 1987, we were up to 7 root servers. But all of these organizations, and all of the servers, were still located only in the continental United States.

8. NORDU.NET replaces U.S. Air Force
1991
NORDU.NET replaces U.S. Air Force
On 28 July 1991, we finally got some geographic diversity, as the first root node was established outside the United States, at the Nordic University Network in Sweden. NORDUnet was the first international wide-area multiprotocol network in the world, supporting TCP/IP, X.25, NJE, and DECnet protocols. The staff operating NORDUnet had quite a lot of DNS operator experience stemming from their work operating the national TLD for Sweden, .SE

9. InterNIC and ISC are added
1993
Nine root servers:
InterNIC and ISC are added
From September 1991 until the beginning of 1993, everything was housed in the U.S. DoDNIC. In the beginning of 1993, Jon Postel and Mark Kosters transferred all non-military data out of DODNIC and into the InterNIC. InterNIC took over the running of what is now A root. Later in the summer of 1993, Vixie approached Jon Postel and expressed his interest in running a root server given all his work on BIND. Postel said yes, and ISC was assigned the 9th root server.

10. 1995 Labels changed to [X].ROOT-SERVERS.NET
to allow more root servers in a 512-byte priming response
When a DNS resolver boots up, it initializes its cache with a priming query. The priming response the resolver receives includes both a current NS Resource Record Set for the root zone and the IP address information for reaching the root servers. The root server names were not standardized, and in their state in 1995, the response to the priming query was maxed out. So to fix this, Bill Manning, Paul Vixie, and Mark Kosters applied “label compression” to the root server system. Kosters came up with the root-servers.net domain name, registered it, and then he actually assigned out the letters to each of the root server operators. With label compression applied, there was now room in the priming response for four more root servers.

11. 1997
13 Root Servers
In 1997 we reached 13 root zone servers, labeled A root through M root, and 22 years later here in 2019, we’re still there.

12. Root Server System Today

13. The Root Server System Today
13 labels: A through M
26 IP addresses (13 IPv4, 13 IPv6)
Operated by 12 Root Server Operators
Assigned to 1,100+ instances thanks to “anycast” routing
On 1 December 2018 there were 77.7 billion queries received by the root zone servers (*excludes G-root)
Today we have 13 root server labels, A through M, each having an IPv4 address and an IPv6 address. These 13 root server labels are operated by 12 root server operators. The root servers are configured on over 1,100 instances thanks to anycasting. But it’s not 1,100 machines. In each instance, there could one machine, or there could literally be dozens of machines. I wanted to see how much traffic root servers were getting these days, so on 1 December 2018, I took a look. I was able to do this because of the work done by the ICANN RSSAC - the Root Server System Advisory Committee of ICANN. RSSAC is comprised of representatives of the 12 root server operators. Back in 2014, they published an advisory document called RSSAC02, “Measurements of the Root Server System” which was an initial set of parameters that would be useful to monitor and establish a baseline trend of the root server system. As a result, the RSOs maintain FTP pages where you can download daily stats files. I did so on 1 December 2018, and found 77.7 billion queries received via TCP, UDP, IPv4, and IPv6 to each of the root servers with the exception of G-root, which is not currently producing stats.

15. D: University of Maryland E: NASA - AMES F: ISC G: U.S. DoD
Root Server Operators
A: Verisign
B: USC ISI
C: Cogent
D: University of Maryland
E: NASA - AMES
F: ISC
G: U.S. DoD
H: U.S. Army Research Lab
I: Netnod
J: Verisign
K: RIPE NCC
L: ICANN
M: WIDE
We have 13 root server labels operated by 12 root server operators. Verisign operates A root, and it also operates J root. <recite each label and RSO, then change page after I: NETNOD>

16. D: University of Maryland E: NASA - AMES F: ISC G: U.S. DoD
Root Server Operators
A: Verisign
B: USC ISI
C: Cogent
D: University of Maryland
E: NASA - AMES
F: ISC
G: U.S. DoD
H: U.S. Army Research Lab
I: Netnod
J: Verisign
K: RIPE NCC
L: ICANN
M: WIDE
After label compression was applied to the root server system in 1995, four more labels (numbers 10, 11, 12, and 13) were available be to be added. Mark Kosters and Jon Postel sat down and discussed it. Classifying it to the other root server operators as “an experiment”, John and Mark added the four new labels J, K, L, and M. Two labels were setup experimentally at Network Solutions (J & K). Two more labels were setup experimentally at USC ISI (L & M). The plan was when a new RSO was ready to start operating a root server, the new labels would be divvied up. The first new RSO was RIPE and RIPE was given K. When it was time for WIDE to get one, Jon Postel said to Kosters, "How about J goes to Japan? J for Japan, get it?" Kosters replied, "No, it’s meant for Asia, not Japan, so J is a bad idea. Also, that would be two of ours gone and none of yours. How about you send one." So M went to WIDE. J stayed with NSI until it became Verisign, and it resides at Verisign today. L stayed with ISI until John Crain and ICANN came along. Officially, moving L to ICANN was part of ISI’s support of ICANN. More importantly, L was in the same ISI LAN as B, and L wasn’t racked. People felt it was good to separate B and L topologically, and it would be good if an important root server was properly racked, so John Crain took the server and moved it to ICANN’s cabinet in a datacenter and renumbered it into ICANN’s address space.

17. Root Server Instances in the RIPE NCC Service Region

18. Root Servers in the RIPE NCC Service Region
As of 20 April 2019:
The region has 340 root server instances (out of 1,120 total instances worldwide)
55 economies (out of 75) have at least one root server instance
104 metropolitan areas

19. Reykjavik, Iceland

20. Northernmost Root Server Instance Globally
Lulea, Sweden was northernmost, just beating out Oulu, Finland.
Lulea, SE: ° N
Oulu, FI: ° N

21. Frankfurt, DE
Frankfurt has the most number of root server instances for any city in the RIPE NCC service region

22. Nuuk, Greenland
But Nuuk, the capital of Greenland, has the most root server instances per capita, with one root server instance serving the 56,480 residents of Greenland (per the United Nations)

23. Root Server System Governance

24. We have had no process to add or replace root server operators since Jon Postel died in 1998
Earlier we discussed the story behind J, K, L, and M. Jon Postel died shortly after M was assigned to WIDE. And with Jon’s death, we were left with no process to add or replace root server operators. So J stayed with Verisign and L stayed with ICANN even though Jon had wanted to identify other root server operators to assign those labels to.

25. A Path Forward RSSAC Advisory 037: “A Proposed Governance Model for
the DNS Root Server System”
It’s now more than 20 years since Jon Postel’s death, and for the first time, we have a potential path forward. ICANN’s RSSAC has published the advisory RSSAC 037, which has been a multi-year project by RSSAC. They have worked hard to get it right. RSSAC037 is “A Proposed Governance Model for the DNS Root Server System”. It’s the RSSAC’s attempt to model who should govern the root server system, and how it should evolve in times of need in the future.

26. RSSAC 037: A Proposed Governance Model for the DNS Root Server System
1. Secretariat Function (SF) 2. Strategy, Architecture, and Policy Function (SAPF) 3. Designation and Removal Function (DRF) 4. Performance Monitoring and Measurement Function (PMMF) 5. Financial Function (FF)
The proposed model has 5 functions. In addition to a Secretariat function and a Strategy, Architecture, and Policy function, I wanted to highlight a bit about the Designation and Removal Function of new and existing RSOs. There is also a Performance Monitoring and Measurement Function, and importantly, a Financial function which is designed to provide a sustainable funding model, for both ongoing RSO operations and in emergent situations. But it is the designation and removal function which underpins the governance model and really allows us to move forward out of 1997.

27. Designation and Removal Function (DRF)
Establishes whenever there is a need for a new Root Server Operator (RSO).
Only when there is a need, obtain applications from organizations willing to be designated as RSOs.
RSO candidates are evaluated by PMMF.
Recommending the designation of an RSO from a pool of candidates based on the evaluations.
Handling removal cases where an RSO should no longer operate the root service.
Participating in accountability efforts by evaluating existing operators for compliance with policies and metrics.
It’s worth noting here that right now we don’t see any technical need for additional root server letters. There are thousands of root servers anycasted across 6 continents. With such broad coverage it has been difficult to justify creating new letters strictly on a technical basis.

28. RSSAC037: Current Status
The ICANN Board is overseeing the development of a Concept Paper as part of its consideration of RSSAC037
The Concept Paper
Incorporates the 11 guiding principles of the Root Server System (RSS) identified by the RSSAC in RSSAC037 and acknowledges the important role and continued commitment of the Root Server Operators to the overall security, stability, and resiliency of the RSS
Envisions a new cooperation and governance model for the RSS based on RSSAC037; and 
Outlines three phases of a community-driven process to finalize a new cooperation and governance model for the RSS
After RSSAC and the ICANN Board approve the Concept Paper, the ICANN org will publish it and open RSSAC037 for public comment. 
The proposed governance model is now under consideration by the ICANN Board. The Board has commissioned the ICANN Org to develop a concept paper as part of its consideration of RSSAC037. This concept paper is currently under review. The Paper should be published, and the Public Comment period should open, shortly after ICANN65 this June.

29. Distribution of the Root Zone

30. Root Zone Distribution
In the traditional model, the Root Zone Maintainer distributes the root zone to the root server operators:
RZM is a contracted function. Verisign is the operator today, but it could easily be someone else tomorrow. Verisign’s root zone distribution facility is highly redundant and has stood the test of time.

31. The Root Zone Can Also be Run from a Local Resolver
Over the last 20+ years, a small number of very large recursive resolver operators have sometimes chosen to run a local copy of the root zone
Steve Crocker named this concept, “hyperlocal”
Hyperlocal is meant to complement the root server system
RFC 7706 was published so that resolver operators who want to implement this have an informational base of reference
The current I-D (RFC 7706bis, revised March 2019) gives examples of how to set-up modern resolvers to use hyperlocal functionality

32. Hyperlocal Root Service
Benefits:
It is local, so it is faster (shorter RTT)
It is local, so queries for root information cannot be misrouted
It is local, so queries between the recursive resolver and the root zone cannot be snooped on by an external actor
But …
It is more fragile than the normal way to access root zone data because it adds a series of steps and fallbacks

33. Conclusion

34. Conclusion
The Root Server System enjoys a strong, robust, and highly redundant infrastructure that has stood the test of time since its origins in 1985.
The Internet continues to evolve both in terms of technologies and usage. As the Internet evolves, hopefully so too will root service.
The implementation of a new governance model should be a valuable and significant contribution to the evolution of the Root Server System.

35. Thank You
Thank you very much