I agree that this is not a technical issue of scaling the root; that quantity of queries per day and second is not a big problem. Rather, as you note, it is a layer-9 issue. But I don't think we should constrain our requirements development & protocol design because of this. Ultimately root operators and others will need to make independent assessments of cost/benefit and it's not unheard of for communities in ICANN to initiate the different policy development processes in order to change pricing/margin/contract stuff to accommodate new requirements.
On 10/29/19, 11:30 PM, "dns-privacy on behalf of Jim Reid" <[email protected] on behalf of [email protected]> wrote: On 30 Oct 2019, at 01:32, Eric Rescorla <[email protected]> wrote: > >> Yes, it's hard, but I think it's worthwhile, because the prospect of getting the root to offer ADoT seems very distant to me. >> > Why? Do we have estimates of the load level here as compared to (say) Quad9 or 1.1.1.1? The root server operators publish statistics on the traffic they get. Links for some of their data can be found at https://protect2.fireeye.com/url?k=2afc0159bfd08024.2afc26ed-cd00c20c720e6f6a&u=https://root-servers.org. The anycast cluster for a.root-servers.net alone currently handles upwards of 8B queries/day - roughly 100,000 queries/second. That’s steady state. The numbers would go *far* higher than that during a Mirai-style DDoS attack. It’s going to be a challenge to get authoritative servers handling those sorts of query levels to support DoT (over TCP?). FWIW solving the non-trivial operational and engineering issues will be the easy bit. Solving the layer-9 issues will be harder. I expect that also holds for DoT support at authoritative servers for important TLDs or the DNS hosting platforms from the likes of Akamai, Dyn, UltraDNS, etc that handle very high query rates. I suppose someone could ask RSSAC* for their opinion on deploying DoT at the root. And having lit the blue touchpaper, I will now run away at great speed to watch the ensuing firework display. :-) * Other ICANN advisory committees are available. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
