[dns-operations] root? we don't need no stinkin' root!

[Mukund Sivaraman]

On Tue, Nov 26, 2019 at 08:41:51AM -0500, Mark Allman wrote:
> 
> Let me try to get away from what is or is not "big" and ask two
> questions.  (These are legit questions to me.  I have studied the
> DNS a whole bunch, but I do not operate any non-trivial part of the
> DNS and so that viewpoint is valuable to me.)
> 
> (1) Setting aside history and how things have been done and why
>     (which I am happy to stipulate is rational)... At this point,
>     are there tangible benefits for getting information about the
>     TLD nameservers to resolvers as needed via a network service?
> 
> (2) Are there fundamental problems that would arise in recursive
>     resolvers if the information about TLD nameservers was no longer
>     available via a network service, but instead had to come from a
>     file that was snarfed periodically?

Probably not many. There are some Twitter feeds about what kinds of
changes occur to the root zone and how frequently, e.g.:

https://twitter.com/diffroot

I like how you've posed your questions, at a high-level view.

In the past few years, I've heard of several proposals for improving
root zone resilience, and how it can be made available to resolvers more
readily and robustly.

* RFC 7706 (root zone on loopback)
* Paul Vixie's idea about making one of the root letters have AS112
  style IP addresses
* Root zone mirroring with zone transfer over HTTPS
* Root zone distribution via bittorrent (IIRC I heard it from NLnet Labs
  staff)
* Root zone distribution as a blockchain
* DNS as a blockchain
* Combining zones into a look-aside megazone that is well provisioned

The root zone is another zone. Due to real-world traffic patterns, it is
perhaps more resilient to authoritative service degradation than
top-level zones such as "com." because once a TLD delegation (e.g.,
com.) is cached in a resolver, it is not going to look in the root zone,
when names in the TLD (e.g., com.) are queried, for a very long time.

DNS will always have an under-provisioning problem until there is some
policy about traffic. It will be so as long as a network-connected IP
camera is able to generate packets that saturate its 1Gbps link, and as
long as manufacturers are not liable for how their devices behave
(quality of firmware, updates, etc.).

Resilience applies to _any_ zone, not just the root zone. If an
Alexa-top-10 example.com company's authoritative DNS nameservers are
attacked by an equivalent of the Mirai botnet, or worse, a government
sponsored packet flood / DNS QUERY flood, overprovisioning to handle
such attacks increases its running costs by orders of magnitude. CDNs
with their global anycast DNS service are popular these days, but their
resiliency would depend on the specific attack circumstances. Not a year
goes by where we don't hear of a significant DNS outage due to a
DDoS. Use of such CDNs have also made DNS more centralized, which not
everybody thinks is wise for the general health of the internet.
Availability of a service doesn't depend just on resilience to DDoS
attacks.

If we use response/query percentage (response rate) as a metric for
service quality of a zone, a popular TLD zone would be more vulnerable
than the root when there is similar degradation of response rate.  The
same can be said for CDN-style global anycast authoritiative
DNS too. What would be more noticed and make the popular news - if
root-servers were to drop to 50% of their reply rate, or if Cloudflare
DNS were to drop to 50% of its reply rate?

It does not appear taking over-provisioning for granted would work
well. Borrowing a sibling reply's nomenclature, "large" will not work
robustly now or in the long term. "Clever" has to be better than root on
loopback - it has to work for other parts of DNS too (what if the root
works, but we can't resolve any new queries in the "com." TLDs?)
"Clever" has to be also about regulating, about limits imposed in
equipment by laws, and responsibility for maintaining connected
devices. The average human who installs a security camera knows nothing
about what happens on the wire and cannot realistically be expected to
be responsible.

		Mukund