It's possible that for .local it's not needed. The other RFCs are actually for DNS-protocol uses that are locally-served and hence can't have secure delegations. That means that the secure delegation mechanism you propose here won't work for those domains, but that's okay. I also don't see any urgency to this, since AS112 works, but if this is better than AS112, maybe we should switch.
> On 17 Jun 2025, at 18:51, Joe Abley <[email protected]> wrote: > > Hi Ted, > > On 17 Jun 2025, at 18:45, Ted Lemon <[email protected]> wrote: > >> This looks good. > > Glad you like it! > >> we'll do some A/AAAA queries to root, but presumably these will be negative >> cached so it won't be a huge load? > > Both certainly seem possible. This is the Wes-science placeholder that I > alluded to, earlier. I don't actually know what he has found, yet, since I > had to get on a plane. > >> If this really is better, then we should consider also updating RFC6303, >> RFC8375 and RFC9665, and also adding a similar delegation for .local. >> RFC6762 doesn't address this at all. > > As currently written, this would not be applicable to .LOCAL or .ALT or > .ONION or anything that acts as an anchor for non-DNS resolution protocols. > > The thinking here was that (a) the resolution switch in those examples > happens in or very close to the application, so there are other ways for > applications to know those names exist and (b) those names really shouldn't > exist in the DNS as well as those other name resolution protocols, kind of by > definition, and introducing that kind of ambiguity would be a bit of a > regression. > > Quite possibly we have missed some potential benefit, though. > > > Joe > _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
