1. Hyperlocal Root Service
Decentralizing for resilience and performance
David Conrad
Eastern Europe DNS Forum
4-5 December 2018

2. Introduction
Root name service is almost identical to name service for any other zone
Primary difference: where name servers are obtained from
Root hints and “priming query” vs. referral response from parent
Once cache is primed, the root operates like any other zone
Primarily referrals to child zones
Unique organization structure
Resiliency needs are a bit higher
However, if root servers are unavailable…
Entire DNS namespace will (eventually) be unreachable
Internet mostly stops
% dig . ns +dnssec
[…]
;; ANSWER SECTION:
IN NS h.root-servers.net.
IN NS f.root-servers.net.
IN NS m.root-servers.net.
IN NS g.root-servers.net.
IN NS k.root-servers.net.
IN NS d.root-servers.net.
IN NS c.root-servers.net.
IN NS b.root-servers.net.
IN NS i.root-servers.net.
IN NS l.root-servers.net.
IN NS e.root-servers.net.
IN NS j.root-servers.net.
IN NS a.root-servers.net.
IN RRSIG NS
1WZd/yui+9a/fSd2I9mnjetZN1T76hymtOaj1EHOU+8SefdN75a86rO1
DhTghuZpAC0gY7WhsE1Uwdn19JvVjsATQpgvLp1+A4VA9H7T8bRXUoUW GoEHm+2j2vG/eYUj05sMAwKLiN0ejEGJKJEFTuAFiRrJp6Hx6uQszfGZ mGQcb45C6VeQmMdmDiOZpr55nbDRf8wjaEVUKF1Ll1pj35LQppL8n528 JlfV4o44u8u+DDubHmuLDfZoXdtfB7wDFyCVZbWlHHOVxwMiaryU9Myq 6opjErhdrmG1qx1BQhafdzXW9nxgkgLFHFd1fJPRoL3XscyHFeW0TkfR 8Y72fg==
;; ADDITIONAL SECTION:
a.root-servers.net IN A
a.root-servers.net IN AAAA :503:ba3e::2:30
b.root-servers.net IN A
b.root-servers.net IN AAAA :500:200::b
c.root-servers.net IN A
c.root-servers.net IN AAAA :500:2::c
e.root-servers.net IN A
e.root-servers.net IN AAAA :500:a8::e
f.root-servers.net IN A
f.root-servers.net IN AAAA :500:2f::f
g.root-servers.net IN A
g.root-servers.net IN AAAA :500:12::d0d
h.root-servers.net IN A
h.root-servers.net IN AAAA :500:1::53
i.root-servers.net IN A
i.root-servers.net IN AAAA :7fe::53
j.root-servers.net IN A
j.root-servers.net IN AAAA :503:c27::2:30
k.root-servers.net IN A
k.root-servers.net IN AAAA :7fd::1
l.root-servers.net IN A
l.root-servers.net IN AAAA :500:9f::42
m.root-servers.net IN A
m.root-servers.net IN AAAA :dc3::35

3. Growing Risk
Historically and currently, the root server system has worked essentially flawlessly
However, attack capacity is growing fast: root system at risk of failing under a sustained DDoS attack.
Risk Mitigation Options
Limit/reduce attack capacity
Expand root server capacity
Decentralize root service

4. Limiting/Reducing Attack Traffic
Ideal solution, but…
Lots of attacks and vectors: reflection attacks, amplification attacks, volumetric attacks, compromised hosts, botnets, etc.
“The ’S’ in IOT stands for security”
Source address filtering insufficiently implemented

5. Expanding Root Server Capacity
There are 13 server addresses run by 12 operators, almost 1000 servers
Resolvers automatically pick the one(s) with the quickest round-trip times to the resolver.
There are usually more than one that are so close that they can be considered equivalently fast.
If a path to the quickest resolver is blocked (such as because there is a DDoS on some other host that is along the path), resolvers figure this out quickly and adjust.
Under normal circumstances, this all works just fine for all resolvers.

6. Expand Root Server Capacity
No significant attacks on the root server system in years
Doesn’t mean that one won’t happen in the future
The cost of mounting DDoS attacks keeps going down, but the ability to defend against these attacks goes up.
Unlike pretty much any other zone, there is no single administrator of root name service
No service level agreements or contractual requirements
No service-wide funding model
RSSAC 37/38 is intended to address the governance model
Will allow for greater accountability
May provide for a funding model to facilitate capacity growth
Unsustainable in the face of exponential increase in attack capacity

7. A Different Approach: Focus on Resolvers
Resolver operators care a great deal about having a stable name service
They mitigate DDoS attacks within their infrastructure and/or fund capacity increase as necessary
RFC 7706 from 2015 described a technique that some resolver operators had adopted to get “better” service for root queries.
Faster responses (particularly for NXDOMAIN), lower latency, improved privacy, etc.
RFC 7706 is being updated to include lessons learned from the past few years.
Let’s call this new system “hyperlocal” to make a clear distinction from the limitations of RFC 7706.

8. Extreme Decentralization: Hyperlocal
Hyperlocal is a set of techniques resolvers can use to mirror the entire root zone and use it locally
In short: the resolver also acts as an authoritative server for the root, but does so on a way that only it can access that root service.
Mirroring the root zone means the root namespace is available from potentially any resolver
Decentralizing access to the root namespace to millions of servers
Attacks against the root name servers would go unnoticed in a hyperlocal resolver
For security, hyperlocal requires that the resolver be validating using DNSSEC
Resolver operators can’t modify root zone contents without those changes being detectable

9. Making hyperlocal stable and trustable
Root zone availability becomes an issue
Existing root zone distribution system assumes few clients
Hyperlocal-supporting zone availability service would need to handle potentially hundreds of thousands/millions of clients
ICANN is investigating a service for providing the root zone to hyperlocal resolvers
This service is quite different than a root server instance in that for hyperlocal, you get the whole root zone all at once.
Availability requirements for this service are orders of magnitude less time sensitive than root service
Resolver operators opting in to this service could choose among dozens or hundreds of locations, and could use either DNS transport (with AXFR) or HTTPS
Perhaps with notification of zone changes

10. Getting the root zone from other places
ICANN’s service is not required for hyperlocal
Many resolver operators are already getting service from other places.
Six root server operators (USC-ISI, Cogent, ISC, DDN- NIC, RIPE, and ICANN) already serve the root zone over AXFR
ICANN’s is available at lax.xfr.dns.icann.org & iad.xfr.dns.icann.org.
Other provisioning services are appearing. For example, LocalRoot from ISI ( is in beta test now.

11. Making hyperlocal reliable
The hyperlocal technique must be at least as resilient as the current system or else it isn’t worth doing.
A common concern about deploying hyperlocal has been “what if this doesn’t work?”.
If the hyperlocal service fails (such as it cannot get the new root zone), it has to have failsafe fallbacks, such as continuing to serve the old root zone until a new zone can be retrieved.
The update to RFC 7706 will make these fallbacks explicit, and software vendors will have to show that their software is reliable in the face of attacks.
Hyperlocal failure would impact those dependent on the resolver
”Self-correcting problem” since resolver operator’s customer would create direct incentives for the resolver operator not to break things

12. Supporting software vendors with hyperlocal
ICANN has seeded some of the popular open source resolver vendors with small amounts of capital to include hyperlocal features in their software
The results have been a variety of software with different approaches and interfaces for managing their hyperlocal feature.
When ICANN delivers its provisioning service, we assume that the vendors will update to allow it as one of the ways to get the root zone

13. Is this really needed?
Possibly not, but it would be terrible to find that out too late.
Choosing hyperlocal over “plain old root service” is up to the resolver operator: it is an option in the resolver’s configuration.
Hyperlocal will be of most value to resolvers with the most tenuous connections to the root server operators, such as ISPs with just one uplink.
If, in the future, the root server system comes under regular attack, hyperlocal with a good provisioning service will help resolvers keep serving reliable DNS data to users.

14. Engage with ICANN Thank You and Questions Visit us at icann.org
@icann
facebook.com/icannorg
youtube.com/icannnews
flickr.com/icann
linkedin/company/icann
slideshare/icannpresentations
soundcloud/icann