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 2025/10/30 17:23, Michael Richardson wrote:

A good reason for more people to do RFC8806 :-) Of course, as people do that, the precentage of junk will go *up* as legitimate traffic stays local. But, OTH, we could scale back the root nameserver infrastructure.

The root nameserver infrastructure is scaled as it is for DDoS defence, not because of current typical traffic levels (junk queries or otherwise). 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. Ray