[DNSOP] Re: DNSOP4 documents for consideration about the future of LocalRoot behavior.

[Libor Peltan <[e-mail]>]

Hi,

As a DNS nerd, I also favor AXFR/IXFR for local root updates. However, 
the public AXFR service needs to be provided by *different* nameservers 
than normal root zone answering, because AXFR is easy to DoS and often 
can suffer even with high load of legitimate traffic. So we need to care 
that it doesn't disrupt the normal root DNS (even TCP) answering.

And yes, the root zone signing process should be modernized to be able 
to sign incrementally, in any case. But that's not critical.

As an alternative, I have also thought that as root zone is signed with 
NSECs, the resolvers actually can fill their cache by simply iterating 
the zone with normal queries :) But then I thought, that simply enabling 
aggresive negative caching is more efficient.

Anyway, what are the main benefits of local root against negative caching?

I concur to the caution that transferring zone files over HTTP(S) looks 
weird and care must be taken not to fall to some circular dependency 
(HTTPS TLS certificate requiring working DNS?). But one argment for this 
is that it is already implemented and running.

Libor


On 26. 01. 26 17:57, Ben Schwartz wrote:
> Standardizing protocol elements for public distribution of zone files 
> over HTTP (e.g. defining content-types, providing guidance on cache 
> header usage) seems like a grand idea.  Let's make it easy to mirror 
> the root zone over HTTP, sure.
>
> Suggesting that LocalRoot resolvers use HTTP, on the other hand, seems 
> like a dangerous shortcut.  HTTP is enormously complicated, and 
> normally relies on DNS in many different ways. Incorporating it as a 
> formal dependency of DNS, even optionally, adds a lot of complexity, 
> probably including the need for a non-HTTP fallback path to break the 
> cyclic dependency.
>
> LocalRoot resolvers are welcome to fetch the zone using HTTP, 
> BitTorrent, or however else they like.  But when setting requirements 
> for LocalRoot resolvers, or standardizing publication points, we 
> should focus on making DNS a self-contained system that bootstraps 
> from TCP/IP in the simplest achievable way.
>
> If there are real concerns about the efficiency of zone distribution 
> in DNS, I would prefer to invest in correcting them within the DNS 
> protocol.  (IXFR seems well-suited to LocalRoot, but we could pretty 
> easily layer on ZSTD or something if needed.)
>
> I do see the appeal of taking this opportunity to break out of the 
> 13-letters paradigm.  However, I think caution is also warranted 
> there.  The proposed "root zone publication points" system effectively 
> introduces a hard dependency on HTTP, to accomplish the equivalent of 
> what DNS Priming does in-band.  I would prefer some form of in-band 
> priming, perhaps encoding the list of "AXFR root servers" into the 
> root zone.
>
> --Ben
> ------------------------------------------------------------------------
> *From:* George Michaelson <[e-mail]>
> *Sent:* Saturday, January 24, 2026 3:53 AM
> *To:* dnsop WG <[e-mail]>
> *Subject:* [DNSOP] Re: DNSOP4 documents for consideration about the 
> future of LocalRoot behavior.
> One of the principal advantages of http to a file is that the world 
> has built out CDN to be efficient at back and front end delivery of 
> this content. I can name many many entities who could do this with 
> zero code simply by running cron job on
> One of the principal advantages of http to a file is that the world 
> has built out CDN to be efficient at back and front end delivery of 
> this content. I can name many many entities who could do this with 
> zero code simply by running cron job on a frequency chosen to fit 
> timely update, and then content placement in their normal distribution 
> method.
>
> This is very attractive to me. It means I can say to people who want 
> to help distribute the root, it's next to zero public facing code 
> change to be able to do it.
>
> Please do not misunderstand this as disrespecting in band in protocol 
> AXFR. My point is this increases the surface of participation in 
> broadcasting the root, as a public good, in ways which demanding 
> competency and literacy in DNS do not.
>
> G
>
> On Sat, 24 Jan 2026, 1:56 pm Wes Hardaker, <[e-mail]> wrote:
>
>     "John Levine" <[e-mail]> writes:
>
>     > ICANN has two public AXFR servers at xfr.cjr.dns.icann.org
>     <https://urldefense.com/v3/__http://xfr.cjr.dns.icann.org__;!!Bt8RZUm9aw!4we9Qu0B3pricHKBRb6NS5ac3Z6zsJrLFxv8AO9QXPgRBl_G8EFpK3k9NM6khoLuM1SmHpMF$>
>     and
>     > xfr.lax.dns.icann.org
>     <https://urldefense.com/v3/__http://xfr.lax.dns.icann.org__;!!Bt8RZUm9aw!4we9Qu0B3pricHKBRb6NS5ac3Z6zsJrLFxv8AO9QXPgRBl_G8EFpK3k9NM6khoLuM6z3Pt0z$>.
>     How about asking them what their experience has
>     > been, how's the load, how hard is it to manage, how have they dealt
>     > with the sorts of attacks that people make on public servers.
>
>     If they have that information, of course it would be helpful.
>
>     I can tell you from the perspective of b.root-servers.net
>     <https://urldefense.com/v3/__http://b.root-servers.net__;!!Bt8RZUm9aw!4we9Qu0B3pricHKBRb6NS5ac3Z6zsJrLFxv8AO9QXPgRBl_G8EFpK3k9NM6khoLuMxpk6WBm$>
>     what our load
>     has been like: it's been growing since 2022 or so (and we haven't
>     really
>     noticed any issues):
>
>     https://ant.isi.edu/~hardaker/tmp/xfr-counts-by-date.png
>     <https://urldefense.com/v3/__https://ant.isi.edu/*hardaker/tmp/xfr-counts-by-date.png__;fg!!Bt8RZUm9aw!4we9Qu0B3pricHKBRb6NS5ac3Z6zsJrLFxv8AO9QXPgRBl_G8EFpK3k9NM6khoLuMyyxF0Cv$>
>
>     https://ant.isi.edu/~hardaker/tmp/xfr-counts-uniq-srcs.png
>     <https://urldefense.com/v3/__https://ant.isi.edu/*hardaker/tmp/xfr-counts-uniq-srcs.png__;fg!!Bt8RZUm9aw!4we9Qu0B3pricHKBRb6NS5ac3Z6zsJrLFxv8AO9QXPgRBl_G8EFpK3k9NM6khoLuM62JmF7u$>
>
>     https://ant.isi.edu/~hardaker/tmp/xfr-counts-by-ASN.png
>     <https://urldefense.com/v3/__https://ant.isi.edu/*hardaker/tmp/xfr-counts-by-ASN.png__;fg!!Bt8RZUm9aw!4we9Qu0B3pricHKBRb6NS5ac3Z6zsJrLFxv8AO9QXPgRBl_G8EFpK3k9NM6khoLuM7ktvRGH$>
>
>     (the horizontal data points is 1 sample day every 3 months since
>     late 2016)
>
>     I'll mention again that the current documents state we should have
>     multiple protocol transfer options available for implementations and
>     operators to choose from.  This is sort of already case in existing
>     implementations and we should support those.  IMHO, AXFR should
>     definitely be one choice.  But a zonefile-over-HTTPS makes sense
>     to me too.
>
>     -- 
>     Wes Hardaker
>     Google
>
>     _______________________________________________
>     DNSOP mailing list -- [e-mail]
>     To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> DNSOP mailing list [e-mail]
> To unsubscribe send an email [e-mail]