Presentation by David Huberman at APRICOT 2019 on Tuesday, 26 February 2019.

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

2. | 2
Overview
¤ The Root Server System at a Glance
¤ Security Threats to the Root Server System
¤ Evolution: Possible Steps Forward

3. | 3| 3
The Root Server System
at a Glance

4. | 4| 4
1983DNS defined

5. | 5| 5
1984First root server established at
University of Southern California’s
Information Sciences Institute
(USC ISI)

6. | 6
1985Four root servers:
two on each U.S. coast

7. | 7
1987Seven root servers:
SRI – ISI – RPI – U. of Maryland –
U.S. Air Force – NASA – U.S. Army

8. | 8
1991NORDU.NET replaces U.S. Air Force

9. | 9
1993Nine root servers:
InterNIC and ISC are added

10. | 10
1995Labels changed to [X].ROOT-SERVERS.NET
to allow more root servers in a 512-byte priming response

11. | 11
199713 Root Servers

12. | 12
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 900+ instances thanks to “anycast” routing
¤ On 1 December 2018 there were 77.7 billion queries received by the
root zone servers (*excludes G-root)

13. | 13

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

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

16. | 16| 16
We have had
no process to
add or replace
root server
operators since
Jon Postel died
in 1998

17. | 17
A Path Forward
¤ RSSAC Advisory 037:
“A Proposed Governance Model for
the DNS Root Server System”

18. | 18
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)

19. | 19
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.
¤ The DRF will use information that the PMMF provides to recommend
whether to remove or replace any existing RSOs.

20. | 20
Making RSSAC037 a Reality
¤ Needs community approval that the model makes sense
¤ Needs an implementation plan.
¤ The implementation plans need input and support of key stakeholders
(IAB/IETF, ICANN community, RSOs, ...).
¤ Realistically looking at 2020 or 2021 before ICANN can execute on
RSSAC037.

21. | 21| 21
Security Threats to the Root Server System

22. | 22
DDoS Attacks
The root server system is currently
vulnerable to a large-scale DDoS
from a widely distributed set of
sources.
State of the Art should allow for
larger and more tailored attacks.

23. | 23
IoT: It is Going to Get Worse
Billions of devices offering
substantial bandwidth.
Poor security practices among IoT
vendors, service providers, and end
users.
Challenges to upgrading devices.

24. | 24
Routing Attacks
The Internet routing system is
currently insecure.
BCP38: filtering/cleaning impacts
router performance.
Nothing special about root server
prefixes.

25. | 25
Economic Threats
RSOs are unpaid volunteers.
What’s the ROI?
Traditional DDoS Solution is to
throw money at the problem.

26. | 26
The rate at which DDoS
capacity is increasing is
outpacing the ability of
RSOs to expand
headroom

27. | 27
DNS Software Ecosystem
Root servers typically run on
commodity (open source) software.
Long-term viability and vitality of
this software is dependent on
community involvement, donations,
and feature requests.

28. | 28
Politics
DNS root has long been politically
charged.
Some governments, IGOs, and
NGOs see the DNS root as a point
of control.
Ongoing Internet governance
discussions frequently involve
questions about “How do I get a
root server?”

29. | 29| 29
Evolution: Possible Steps Forward

30. | 30
“Money can solve this!” Who is paying?
For DDoS, an
unwinnable race.
Mitigating Threats: Money

31. | 31
“Protocols can
solve this!”
Getting people to turn
on DNSSEC is
difficult.
Getting people to
participate in RPKI is
even more difficult.
Mitigating Threats: Protocols

32. | 32
Mitigating Threats: Bring the Root to your LAN
HYPERLOCAL

33. | 33
What is Hyperlocal?
RFC 7706bis: Decreasing Access Times to Root Servers by Running One on
the Same Server.
“Some DNS recursive resolvers have longer-than-desired round-trip
times to the closest DNS root server. Some DNS recursive resolver
operators want to prevent snooping of requests sent to DNS root servers
by third parties. Such resolvers can greatly decrease the round-trip time
and prevent observation of requests by running a copy of the full root
zone ” … on the same server

34. | 34
Hyperlocal Root Service
Mirror the root zone into/near local resolver (7706bis).
DNSSEC = source of root zone data does not matter.
When local resolver has root information, no way for a query for root
information to be misrouted.
Much harder to snoop on.

35. | 35
Some Challenges
Deploying hyperlocal requires some DNS expertise.
Whence root data?

36. | 36| 36
Summary

37. | 37
¤ It’s probably time to evolve from 1997.
¤ A new governance model for root service.
¤ Hyperlocal.
¤ DNSSEC and RPKI are really important.

38. | 38
Visit us at icann.org
Thank You