Hi Gert, On 9 Nov 2025, at 18:16, Gert Doering <gert@space.net> wrote:
On Tue, Nov 04, 2025 at 10:23:50AM -0500, Petr ??pa??ek wrote: My thinking it - most resolvers will not query _all_ of NSEC ranges and DS RRs in the root zone during single day, thus most of the AXFR content would be wasted on most of the resolvers.
I'm trying to say - for well behaved resolver implementation, I don't think mirror zone vs. RFC8198 is absolutely clear winner as you propose above.
I seem to hear that there is much garbage (= non-existing TLDs) that is hitting the roots. For those, it's more a question of negative caching, and depending on how much "random" the queries are (yet-uncached), an AXFR could easily win regarding traffic/load.
Well-behaved, modern resolvers that use aggressive negative caching can already be expected to send small numbers of junk queries to root servers. Resolvers that are configured to localroot should not send any at all, and we know at least some resolvers (including one big public resolver service) are configured this way. Despite these measures, the volume of junk queries continues to be high. Perhaps most of the sources of junk queries are not well-behaved, modern resolvers; perhaps the junk is coming from other places. If that is true, localrooting the well-behaved, modern resolvers might well be useful for other reasons but will not help much in reducing the amount of junk. If we want to reduce the amount of junk, we will first need to spend some time working out where it is coming from. I quite like this idea. The answers might be interesting. Alternatively, given that the amount of routine junk landing is tiny compared to the capacity requirements of the root server system to absorb attack traffic, we could just not worry about it. This approach seems to have been working out just fine so far. We collectively spend a lot of time thinking about the root server system, which is odd when you think about it since it's arguably not very interesting. The system as a whole has a lot of capacity; a lot of administrative, network and code-path diversity; it's said to have had 100% overall service availability continuously for decades and resolvers don't need responses from it very often. The failures in the DNS system that would probably make the helpdesk phone ring hot are not failures of root servers. Individual root servers in the past have been down for days and the only people who noticed were DNS engineers. People who are in the business of keeping end-users happy should probably be more concerned about the availability of domain names that keep the apps on customers' phones working than about root servers, I would say. Joe