Regarding DNSSEC:

• Blog post: <https://blog.technitium.com/2023/05/for-dnssec-and-why-dane-...>

• As a podcast episode: <https://blog.apnic.net/2023/03/16/podcast-dnssec-the-case-fo...>

I don't think the analysis upthread should make you rethink DNSSEC, since it, too, is a centralized system; rather than being controlled by Avery Pennarun (you could do worse), it's controlled by an unholy alliance of world governments and companies like Verisign.

If we could find a credible DNSSEC advocate (for our audience; that is: a cryptography engineer, vulnerability researcher, or an engineering leader at a major firm), we would absolutely invite them on.

'teddyh below gave you links to two pro-DNSSEC resources; fun note: the latter source (Geoff Huston, one of the world's more respected networking researchers) has since then written this:

https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/.

thanks much appreciated to you and teddyh for these links. really needed this opposite views.

The title of that article which you link to is “Calling time on DNSSEC?”, and Betteridge's law of headlines applies to it. Here’s the final paragraphs from that article:

“I guess the question we should be asking is — if we want a secured namespace what aspects should we change about the way DNSSEC is used to make it simpler, faster, and more robust?”

I'm happy just to see more people reading it. People can make their own call about it.

I may be in favour of DNSSEC, but I admit that it's time for a v2 of the RFC that removes the stupid "encryption can't be done at the endpoint" restriction. In practice you can just turn on validation on many computers and gain its benefits, especially if used in the manner as described here where you can just block connections to unprotected hostnames to work around the most glaring issue, but the whole spec is written for a world we've moved beyond.

IPv6 doesn't have that problem, though.

thanks!