[DNSOP] Re: on the more general problem of delegating to other namespaces in the DNS

[Ted Lemon <[e-mail]>]

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 <[e-mail]> wrote:
> 
> Hi Ted,
> 
> On 17 Jun 2025, at 18:45, Ted Lemon <[e-mail]> 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
>