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 _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
