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.
I like the majors, and I like them offering things like 1.1.1.1 and 8.8.8.8 but I think if we're exploring a future of the fetch of the root, I'd rather an AS112 type thing was offered by the majors, amongst themselves, than a single major said "we'll do this for community benefit" (again, this is personal opinion and nothing else) -G On Thu, Jan 22, 2026 at 1:43 PM Wes Hardaker <[email protected]> wrote: > > George Michaelson <[email protected]> writes: > > [adding gas to the fire....] > > > I'm broadly comfortable with the document separation but it does beg > > the question what is the impact of one or other of them being blocked, > > or left to rot? Because if we're in an all-or-nothing world it needs > > to be called out (I am pretty sure we aren't btw) > > Well, that's fair though to some extent some of them are independent > (eg, the URL scheme should probably be done regardless) and some of the > separation, as I said, is to separate the discussion a bit into the very > different components. We may want to merge them. Or not. But we could > fail the two IANA ones and the main LocalRoot document and the URL > scheme documents are still likely helpful on their own. > > > I am least comfortable with the last one. I think IANA would not want to be > > given the task of judging suitability to list. > > Well, that's actually part of the goal of providing guidance about what > types of providers should go in there. Some people I've talked to think > we should just trust IANA to build the list. I think "some" guidance > would be good. But it could be a more standard process too. And I > agree this is a larger component of the discussion. I do need to have a > (another actually) good heart to heart with Kim too. > > But the reality is that with ZONEMD and DNSSEC in play, it really > doesn't matter how you get the contents as long as you can. Though the > document doesn't say or suggest you can use carrier pigeons, you > certainly can (assuming a good fleet of pigeons that make regular > trips). The providers of the data need to be robust, but as long as you > can reach some you should be good. > > Yes I'm hand waving a lot, but the underlying goal should be: the IANA > root zone data provider list should be easier to fill and change than > the existing root server addresses that actually serve the root zone. > There aren't privacy trust issues. It can be longer. They only need to > be queried occasionally. They can reuse existing well established CDN > infrastructure. And if one fails, you shouldn't care as much if others > work. A complete failure to contact any due to local outages won't > matter as much Just make sure you use and trust the object protection. > IANA needs to house a default list. But operators can build their own > list if they like. Just check the data. > > -- > Wes Hardaker > Google
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
