The sad fact is that hardly anybody actually relies on DNSSEC right now. The use case for things like internal and home.arpa just relies on they're not being a secure denial of existence. Arguably, and this is certainly what I would argue, if you actually want DNSSEC on, for example, a home network, then you need a secure delegation. I think this is a much more interesting problem to solve the problem of installing trust anchors for locally served domains.
The obvious reason why trust anchors for locally served domains don't work is that if everybody's house uses home.arpa as its locally served domain, then whenever I visit anybody and use their home Wi-Fi, I'm going to get a validation error. I think fixing this is way harder than just figuring out a way to make it easier for people to get delegations for their home routers. After all, we somehow figured out how to do the equivalent with ACME. (I use the term "we" loosely, since my only involvement with this was rejoicing at the success that Let's Encrypt had doing it.) > On 9 May 2025, at 22:15, John Levine <jo...@taugh.com> wrote: > > It appears that Andrew Sullivan <a...@crankycanuck.ca> said: >> In the absence >> of an automatic local trust-anchor installation mechanism that happens at >> network auto configuration (the very idea of which >> strikes me as creating way more problems than it is likely to fix), I don't >> see how DNSSEC is compatible with this degenerate use >> of a global namespace with an overloaded private use space. > > I agree with your point that trying to make DNSSEC work in a private > namespace is a losing battle. But since we clearly > have people who think it should work, maybe they could try something along > the lines of what I suggested yesterday, a > TOFU way to publish local trust anchors on the theory that whatever network > is the first one a device connects to is > the one it trusts. > > I have my doubts about whether it would make things better, but I'd rather > give it a try than rerun the arguments about > which flavor of DNSSEC breakage is the right one. > > R's, > John > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
