On 30 Oct 2025, at 14:38, Joe Abley via dns-wg <dns-wg@ripe.net> wrote:

The surprising thing to me about this is that anybody thinks this is surprising. Evi Nemeth wrote about this over 20 years ago. Do people imagine that the graph of junk is going down and to the right?

More importantly Joe, does anyone imagine they'll ever go down and to the right? With ever-increasing zillions of people getting Gb/s+ connections at home, I fear there's only one direction those graphs of junk traffic are going to go.

Proprietary From: Joe Abley via dns-wg <dns-wg@ripe.net> Date: Thursday, 30 October 2025 at 14:39 To: Hank Nussbacher <hank@efes.iucc.ac.il> Cc: dns-wg@ripe.net <dns-wg@ripe.net> Subject: [dns-wg] Re: More Than 70% of DNS Root Queries Are Junk On 30 Oct 2025, at 14:49, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:

https://pulse.internetsociety.org/blog/more-than-70-of-dns-root-queries-are-...

The surprising thing to me about this is that anybody thinks this is surprising. Evi Nemeth wrote about this over 20 years ago. Do people imagine that the graph of junk is going down and to the right? https://www.caida.org/catalog/papers/2001_dnsmeasroot/dmr.pdf My recollection about this issue is there a handful of studies done thru time. Duane Wessels in 2003 https://www.caida.org/catalog/papers/2003_dnspackets/wessels-pam2003.pdf Follow-up in 2008 https://www.caida.org/catalog/papers/2008_root_internet/root_internet.pdf And I’m sure Duane did a refresher on his paper in the past 10 years. It seems to be going down, but all depends on the methodology. Cheers, Joe ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/dns-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

On 30 Oct 2025, at 3:31 pm, Randy Bush <randy@psg.com> wrote: The surprising thing to me about this is that anybody thinks this is surprising. Evi Nemeth wrote about this over 20 years ago. indeed but a question. what are one or two simple things that operators could do to have useful impact? again: one or two. simple. impact. Great question Randy. For a bind resolver adding zone "." { type mirror; }; to your local configuration will have a useful impact. simple. immediate. I'm sure other resolver code bases have similar switches, Geoff

On 2025/10/30 21:25, Randy Bush wrote:

could i convince you to put up a web page with the recipes for the half dozen prominent resolvers with this hack and one or two others?

The BIND instructions are in RFC 8806, as are those for some other resolvers that support this. There are caveats: - allowing AXFR of the root is something that some root operators do, but it is not a formal service offering. Any (or all) of them could withdraw it at any point. - you'll want to have really good monitoring in place to make sure your transfers are succeeding - without NOTIFY you might miss urgent root zone updates, e.g. in the case of an urgent TLD key roll - you might also want to use ZONEMD to check that the zone is correct. Ray

On 2025/10/30 21:51, Randy Bush wrote:

in case you did not notice, you left *simple* a few turns back. oh right, this is the dns (see my 2000 rant that dns anti-simplicity [0]).

Well yes, I was seeking to discourage people from doing this without full consideration of the implications. It wasn't me that said it was simple...

would you care to put up a web page with the recipe(s) for doing all this? oh, you say there are 42 platforms and at least three ways to do each on any given platform?

Not my problem, I'm just the messenger. Ray

Ray Bellis <ray@isc.org> wrote: >> could i convince you to put up a web page with the recipes for the half >> dozen prominent resolvers with this hack and one or two others? > The BIND instructions are in RFC 8806, as are those for some other resolvers > that support this. > There are caveats: > - allowing AXFR of the root is something that some root operators do, > but it is not a formal service offering. Any (or all) of them could > withdraw it at any point. 1. I think we should fix this in "contracts" going forward. > - you'll want to have really good monitoring in place to make sure your > transfers are succeeding > - without NOTIFY you might miss urgent root zone updates, e.g. in the > case of an urgent TLD key roll 2. I'm skeptical about this. If I were only caching, would my risk not be similiar? > - you might also want to use ZONEMD to check that the zone is correct. 3. My understanding of bind9's "type mirror" is that it runs a DNSSEC check on it. I assume other platforms do the same. The ZONEMD(RFC8976) suggests that some NS RR can not be protected by DNSSEC. (I understand how this can be the case, but not for the NS in .) I see ZONEMD in the root zone, so maybe "type mirror" can check that automatically too? If current root infrastructure is designed to withstand DDoS attacks, then anyone (any ISP/Enterprise/...) who has RFC8806 won't need that to survive the attack. Maybe 8806 should be the better resiliency against attacks. ISPs that don't do 8806 won't survive, and will have an incentive to implement it. 4. An ISP might think it a good idea, once they have 8806, so add their own (internal) anycast responder for some A/AAAA for . zone. There are probably good reasons to discourage this, the major one being routing leaks. I imagine it will happen anyway. I'd like to see a how-to-do-it-right document instead. Maybe there is already one. -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide

...

could i convince you to put up a web page with the recipes for the half dozen prominent resolvers with this hack and one or two others?

The BIND instructions are in RFC 8806, as are those for some other resolvers that support this.

Funny you should mention that. I recently read that RFC, and came off with a feeling that "the authors do not really want you to do this". Why? 1) It is an Informational RFC, but it uses the upper-case keywords from RFC 2119 even though that notation is supposedly only appropriate for standards-track documents. 2) What's worse, the justification for the stated requirements are not spelled out in the RFC, and some of the requirements are not exactly immediately obvious at least to me, even though I would dare to call myself "experienced". So it comes across as an "edict from above". As a source for *information* I would like to give it an "F" for "fail" for this reason alone. 3) The various MUST requirements give rise to significant complication in the configurations. An example for #2 and #3 is Specifically, the root service on the local system MUST be configured to only answer queries from resolvers on the same host and MUST NOT answer queries from any other resolver. Why? The document is silent on that matter. I sense a strong unwillingness to simplify as much as possible. What would go wrong on this front if you simply dropped a root mirror zone in each view you are currently serving? This paragraph in the RFC gives rise to the monstrostity of a configuration presented for BIND 9.12 which is also incomplete because of: * No mention of where 127.12.12.12 needs to be configured. * No mention of whether listen-on needs to be modified. * No mention of whether the "MUST validate the zone DNSSEC-wise" requirement (OK, not an actual quote) is fulfilled by this configuration (it probably isn't?) Granted, the "mirror zone" feature of BIND 9.14+ makes that configuration sample much simpler, and it supposedly DNSSEC-validates the zone before serving it, but, again, the assumed (by me) conflict with the customary "hints" root zone is not mentioned, and here the use of a specially cordoned off view is also not mentioned. So it's no longer needed in this case? Why not? (...and both BIND 9.12 and 9.14 are by now both "ancient history", for those of us who follow along with the maintenance versions of BIND.)

There are caveats:

- allowing AXFR of the root is something that some root operators do, but it is not a formal service offering. Any (or all) of them could withdraw it at any point.

What would happen at that point with BIND 9.14+? The mirror zone would expire, and the local recursor would then revert back to the built-in root hints on startup instead? What's the actual damage to the service the local recursor provides in that case? Granted, in the 7 days from the last successful AXFR until the Expire timer triggers, the recursor would serve up the information from the root zone at the start of that period. How bad would that be? How often does a TLD fully replace all its NS records? Or urgently need to update its DS record? I would posit that changing the delegation of a TLD is typically done more slowly and over a period longer than 7 days. (Emergency KSK rollovers are another matter. Anyone have any history on how frequent such events have been? This can be used to calculate the risk of serving an inaccurate DS record for a TLD for a number of days within that expiry period.) As has been mentioned, the continuity of AXFR service seems to be something which is fixable in a contract if there is any will...

- you'll want to have really good monitoring in place to make sure your transfers are succeeding

What? One-time success is no guarantee for future success? :) And ... what to do if your zone transfers of the root zone are failing? Especially if you haven't touched the "local" or "adjacent" network config?

- without NOTIFY you might miss urgent root zone updates, e.g. in the case of an urgent TLD key roll

How is this significantly different from the propagation of that information without serving the root zone locally? It seems that all the DS records in the root zone have 86000 as TTL, so takes a full day to time out before the root zone is re-consulted for an updated copy. And with the current timers in the SOA (30m refresh 15m retry), and a good success rate for SOA queries and root zone transfers, I fail to see how this would in reality present a practical problem.

- you might also want to use ZONEMD to check that the zone is correct.

Ehm, isn't that for ISC to implement for zone-type "mirror" and for us to use that way (and similar for other DNS server software maintainers), instead of forcing us as administrators to jump through even more complication hoops? I thought the whole point of publishing RFC 8806 was to spur adoption of this configuration method. Was I wrong on this point? It certainly comes off that way. Regards, - Håvard

Hi, On Thu, Oct 30, 2025 at 08:46:41PM +0000, Geoff Huston wrote:

Great question Randy. For a bind resolver adding

zone "." { type mirror; };

to your local configuration will have a useful impact. simple. immediate.

I'm sure other resolver code bases have similar switches,

That assumes a sane resolver, which shouldn't be contributing to all the garbage hitting the roots in the first place. No? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

...

again: one or two. simple. impact.

Great question Randy. For a bind resolver adding

zone "." { type mirror; };

to your local configuration will have a useful impact. simple. immediate.

This is getting into the weeds with BIND config, but won't an administrator also have to comment out any "type hint" root zone configuration at the same time? I would not have expected to be able to have both zone "." { type mirror; file "root.zone"; }; and zone "." { type hint; file "root.cache"; }; configured simultaneously, and the latter i beleive to be rather customary. So what does BIND fall back on if validation of the mirror root zone should fail or some other problem causes the mirror zone to be dis-regarded? Built-in root hints, perhaps? I'm just trying to map out all of the potential failure scenarios, and convince myself that this is "just as safe as before"... Regards, - Håvard

David, On 31/10/2025 11.38, David Malone wrote:

...

I'm just trying to map out all of the potential failure scenarios, and convince myself that this is "just as safe as before"...

Just one data point - I wrote a paper about the local root configuration that I presented at IMC in 2004.

https://conferences.sigcomm.org/imc/2004/papers/p15-malone.pdf

The results seemd to show a reasonable improvement in weird queries leaking out of my name server, so I've been using the local root configuration ever since, and I don't remember it causing any trouble in the last ~20 years. (Plus, the configuration is now easier.)

I've also been doing the same thing for "arpa", "in-addr.arpa", and "ip6.arpa" for a shorter period of time, with no problems.

I was wondering where you got in-addr.arpa and ip6.arpa around, and found out that ICANN provides those and a few more zones at servers set up for XFR: https://www.dns.icann.org/services/axfr/ Most of these are DNSSEC-signed (I think all of them except for root-servers.net). I wonder if we could convince ICANN to add ZONEMD to those zones as well... Cheers, -- Shane

Hi David, On 2 Nov 2025, at 16:09, David Malone <dwmalone@maths.tcd.ie> wrote:

Ah! Very neat - I guess they are intended for writing into config files?

Years ago, when I worked for ICANN doing DNS things, we created the xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org services in order to provide AXFR access to zones that we served on L-Root. I assume those are the ancestors of the similarly-named services described at https://www.dns.icann.org/services/axfr/ The operational idea was to be able not to provide AXFR on L-Root itself so that L could concentrate on being a root server and not have the additional job of providing zone transfer responses. The public transparency idea was to make all the public zones we served available, not just the root zone, because why wouldn't we, somebody might find them useful. To be clear I haven't worked for ICANN for a long time and I'm very sure that the current ICANN DNS people are much more competent than I ever was, but in case it's useful that's my memory of the history. Joe

On 30. 10. 25 16:46, Geoff Huston wrote:

...

On 30 Oct 2025, at 3:31 pm, Randy Bush <randy@psg.com> wrote:

...

The surprising thing to me about this is that anybody thinks this is surprising. Evi Nemeth wrote about this over 20 years ago.

indeed

but a question.  what are one or two simple things that operators could do to have useful impact?

again: one or two.  simple.  impact.

Great question Randy. For a bind resolver adding

     zone "." { type mirror; };

to your local configuration will have a useful impact. simple. immediate.

Geoff, do you have data which compare properties of these two BIND configs? a) zone "." { type mirror; }; b) // empty config file I'm very eager to see data! Personally I would think RFC8198 and DNSSEC validation, both of which are on by default in current BIND versions, should result in behavior closer to optimal than plain mirror zone enabled in all configs. 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. Personally I postulate vast majority of traffic at root is NOT from caching recursive resolvers but in fact from some other sources of junk, and so changing behavior of caching recursive resolvers will not have useful impact on root zone traffic. But I don't have data. Do you have some? -- Petr Špaček Internet Systems Consortium

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

Op 30-10-2025 om 15:38 schreef Joe Abley via dns-wg:

On 30 Oct 2025, at 14:49, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:

...

https://pulse.internetsociety.org/blog/more-than-70-of-dns-root-queries-are-...

The surprising thing to me about this is that anybody thinks this is surprising. Evi Nemeth wrote about this over 20 years ago. Do people imagine that the graph of junk is going down and to the right?

There is a very nice ICANN project, managed by Alain Durand and Christian Huitema, measuring this metric over the last 7 years with I root: https://ithi.research.icann.org/graph-m3.html At least for I root, the long term trend for No Such Domain queries appears to go down sort of. Also, from the graph in the ISOC article, it looks like their measurement is from 2023. I also don't see mentioning of cacheable queries in the article, so I'm assuming it is only about No Such Domain queries. -- Willem

Moin! On 30 Oct 2025, at 20:54, Ray Bellis wrote:

There is also no formal infrastructure in place to support RFC 8806 at scale, nor to generate the signalling to tell any RFC 8806 mirror that a new zone is available. If there was, it would also need signficant DDoS protection.

For a zone that has 2 day TTL referrals and changes twice a day I honestly don’t think signalling is needed. The current refresh/retry timer is fully sufficient for that. I think the current root server would be more than capable of doing two zone transfers per day for all the IPs they serve. I unfortunately don’t have the numbers for that, but maybe someone with access to root server data could crunch this. So long -Ralf ——- Ralf Weber