I don't agree with this pessimistic take. I think properly configured by vendors, this will work fine. Obviously it will need refinement, but I think to find a problem and then default to "turn it off, never turn it on again" would be bad.
I have run local root. I don't see any problems with my service, running local root. I don't see the relevance of fetch mechanisms to success or failure here, or the rate of churn in the root as a significant issue for a local root copy mechanism. I can't see the difference between this, and the push for query minimisation. I do accept that there are a cohort of people who have downside consequences of reduced traffic to the roots. It does not help people taking root feeds of query load to measure things like DGA and other attack paths. Those measurements would probably have to move into the quad9, 8.8.8.8 and 1.1.1.1 space to get economy of scale. -G On Thu, Mar 5, 2026 at 9:41 AM Paul Vixie <[email protected]> wrote: > i think Local Root fails basic engineering economics. the law of large > numbers tells us how many things will appear to be locally broken based > only on the number of configuration variables and the number of subscribers. > > "root hints" scaled well because if it's out of date, only one variable > within (one root name server name+address) need overlap with current > reality in order for an rdns server to be online and operational. > > if encryption from an rdns to "the root" is vital, there are better ways > to achieve it. > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
