It's not that people don't "like" DNSSEC.

The author themselves states in a different post on their blog that DNSSEC is avoided like the plague because it is a royal pain in the ass to set up and outages at major corporations (coughSlackcough) that clearly have talented, knowledgeable, experienced ops people show that the standard was not designed with practical implementation in mind.

"Security that is difficult to implement and can cause catastrophic-level outages not used by majority of internet; film at 11."

Instead of lecturing everyone on how they should be using DNSSEC, what we should be doing is working on "DNSSEC 2.0", from lessons learned in the 2-3 decades people have been trying to use DNSSEC.

Exactly this. DNSSEC is needlessly complicated in large part because its service model was fixed in the mid-late 1990s, when the conventional wisdom was that DNS servers would never be powerful enough to actually perform cryptographic operations. A true DNSSEC 2.0 could simply forego the concept of offline signers (which has largely been foregone already, because online signing is necessary to serve secure NXDOMAINs without revealing all your hostnames) and sign/encrypt on demand.

But DNSSEC 2.0 is unlikely to happen, because DoH solves most of the real-world on-the-wire problems with DNS security. There have always been two visions for how to secure the DNS: the top-down way, with signatures rolling down from the roots, a la DNSSEC, and the bottom-up way, where leaf servers allow individual clients to make secure queries, and we gradually converge on a secure DNS as more and more leafs make secure queries available. Top-down won at the IETF, but bottom-up is going to win the market.

aka DNSCurve.

It may turn out that DNSSEC is useful, for exactly one thing: downloading the root zone securely. This circumvents any refusal to do signing-on-the-server by the root zone server operators.

Here are the instructions: https://localroot.isi.edu/

also: https://datatracker.ietf.org/doc/html/rfc8806

See also: IPv6 instead of RFC 1710.

https://datatracker.ietf.org/doc/html/draft-ietf-sipp-ipae-t...

Twenty-six years later, we're still waiting for IPv6 to be considered "the Internet".

comcast.net is DNSSEC signed and Comcast was one of the first major ISPs to implement DNSSEC validation. Comcast's MX records are DNSSEC signed.

> dig +dnssec comcast.net MX

This has nothing to do with DNSSEC.

It has nothing to do with Comcast not liking DNSSEC.

But if the ecosystem as a whole was happy about DNSSEC and DANE, it's somewhat doubtful we'd have both specs and the involvement of https.

We would not. There'd be no reason to have MTA-STS if there was universal DNSSEC deployment. Of course, outages like this would be vastly more common, because DNSSEC includes a large superset of the failure modes of MTA-STS.