I'm a big fan of LocalRoot (and I think the name is fine), but I see a lot of unnecessary complexity here. It seems like we could accomplish everything we need with two very simple requirements:
1. Root servers SHOULD offer open AXFR over TCP* (perhaps updating RFC 7720). 2. LocalRoot resolvers SHOULD try AXFR with different root servers until they find one that works (if they don't have a proprietary source for the root zone data). No HTTP, no URI schemes, no new registries, formats, or special IPs. I assume the authors considered this option and concluded that it isn't sufficient. I'd like to know why. Then we can add the minimum complexity needed to alleviate those concerns. --Ben *And DELEG should clarify that if a nameserver offers additional transports, it MUST support all the same QTYPEs across transports, including AXFR. ________________________________ From: Michael Richardson <[email protected]> Sent: Thursday, January 22, 2026 6:24 PM To: Wes Hardaker <[email protected]>; [email protected] <[email protected]> Subject: [DNSOP] Re: DNSOP4 documents for consideration about the future of LocalRoot behavior. Wes Hardaker <[email protected]> wrote: >> I would personally like an AS112 type registration. a well known anycast IP range, >> which has letsencrypt HTTPS marking for the IP as numbers, so we go to >> https://2001:db8::53/ as an endpoint and get the closest anycast >> service. > Well that would be fine too but it can't be the only target. We need > multiple to fall back to, as if there was only a single target operated > by something like AS112 you don't have a second attempt when that one > fails to give you data because it's not answering or has corrupted data > itself or ... I agree: AS112 *AND* ... I was thinking that at the various /24s and /48s used by root-servers.net, that another IP address in that subnet could offer the transfer service. (hmm. my local copy of the db.root lacks v6 for e.root-servers.net, yet it has one now) -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
