upvote
> DNSSEC only protects the name lookup for a host, and TLS/HTTPS protects the entire session.

It only provides privacy, it doesn't verify that the resolver didn't tamper with the record.

>to the point where the root keys for DNSSEC could be posted on Pastebin tonight and almost nobody would have to be paged.

This would very much be a major issue and lots of people would immediately scramble to address it. The root servers are very highly audited and there is an absurd amount of protocol and oversight of the process.

reply
Who? Outside of DNS providers, which organizations would need an emergency response to the collapse of DNSSEC security? Be specific; name one. If TLS security collapsed, I could pick a company from the Fortune 1000 at random, and they'd have an emergency response going.
reply
DNSSEC can be trivially used with DANE to protect the entire session. The browser vendors quite consciously decided to NOT do that.

> 2. People actually rely on TLS/HTTPS, and nobody relies on DNSSEC

Sure. But I treat it as a failing of the overall ecosystem rather than just the technical failure of DNSSEC. It's not the _best_ technology, but it's also no worse than many others.

This is the outcome of browser vendors not caring at all about privacy and security. Step back and look at the current TLS infrastructure from the viewpoint of somebody in the 90-s:

You're saying that to provide service for anything over the Web, you have to publish all your DNS names in a globally distributed immutable log that will be preserved for all eternity? And that you can't even have a purely static website anymore because you need to update the TLS cert every 7 days? This is just some crazy talk!

(yes, you technically can get a wildcard cert, but it requires ...drumroll... messing with the DNS)

The amount of just plain brokenness and centralization in TLS is mind-boggling, but we somehow just deal with it without even noticing it anymore. Because browser vendors were able to apply sufficient thrust to that pig.

reply