It seems pretty clear to me that the industry, and particularly the slice of the industry that operates large, important sites and staffs big security teams, doesn't believe this is a meaningful problem at all.

I agree with them.

▲ thenewnewguy 9 hours ago | parent | next [-]

Would this article not be evidence the part of the industry that makes up the CA/B Forum (i.e. CAs and Browsers) disagree?

▲ throwway120385 9 hours ago | parent | next [-]

Yeah but CAs want to sell you certificates, and browsers compete on their support for those certificates.

▲

ekr____ 6 hours ago | parent [-]

Huh? They really don't. It's actually kind of unfortunate that browsers don't have uniform policies about what certificates they accept, but for obvious reasons each browser wants to make their own decision.

	▲	kbolino 2 hours ago \| parent [-]
		They do have uniform policies, those policies come from the aforementioned CA/Browser Forum, which has been issuing its Baseline Requirements for over a decade.

▲ tptacek 8 hours ago | parent | prev [-]

The fact that it's 2026 and the CAs are only now getting around to requiring any CA to take DNSSEC, which has in its current form been operational for well over a decade, makes you take DNSSEC more seriously?

▲ alwillis 3 hours ago | parent | next [-]

LetsEncrypt has been checking for DNSSEC since they launched 10+ years ago.

       The ACME standard recommends ACME-based CAs use DNSSEC for validation, section 11.2 [1]:
       An ACME-based CA will often need to make DNS queries, e.g., to
       validate control of DNS names.  Because the security of such
       validations ultimately depends on the authenticity of DNS data, every
       possible precaution should be taken to secure DNS queries done by the
       CA.  Therefore, it is RECOMMENDED that ACME-based CAs make all DNS
       queries via DNSSEC-validating stub or recursive resolvers.  This
       provides additional protection to domains that choose to make use of
       DNSSEC.

       An ACME-based CA must only use a resolver if it trusts the resolver
       and every component of the network route by which it is accessed.
       Therefore, it is RECOMMENDED that ACME-based CAs operate their own
       DNSSEC-validating resolvers within their trusted network and use
       these resolvers both for CAA record lookups and all record lookups in
       furtherance of a challenge scheme (A, AAAA, TXT, etc.).

[1]: https://datatracker.ietf.org/doc/html/rfc8555/#section-11.2

	▲	tptacek 2 hours ago \| parent [-]
		Yes, that's my understanding as well. You'll notice my top-level comment from a few hours ago says that as well. (You edited your comment to include more detail about when LE started validating DNSSEC; all I know is that it's been many years that they've been doing it.)

▲ thenewnewguy 8 hours ago | parent | prev [-]

Why dodge the question? Clearly they care today, and I live in today.

If we're doing to defer to industry, does only the opinion of website operators matter, or do browsers and CAs matter too? Browsers and CAs tend to be pretty important and staff big security teams too.

▲

rstupek 8 hours ago | parent [-]

Are they requiring DNSSEC in order to acquire the certificate? That would be a better indicator to me that it's not security theater=security

▲

Bender 8 hours ago | parent | next [-]

Barely 5% of the internet have DNSSEC signed zones and a big chunk of that are handled by CDN's that do the signing automagically for the domain owner as they also host SOA DNS. Mandating DNSSEC would require years of planning and warning those that have not yet set it up and in my opinion DNSSEC tooling should become a better first class citizen in all of the authoritative DNS daemons. as in there should be so many levels of error handling and validation that it would be next to impossible for anyone to break their zones.

So do we wait for all the stragglers? Wait for the top 500 or top 2500 to make it mandatory? Who takes financial responsibility for those that fell through the cracks?

▲

tptacek 8 hours ago | parent | prev [-]

No CA requires DNSSEC. Obviously they can't: almost nothing is signed. The only change "today" is that technically CAs are now required to honor DNSSEC, where they weren't before.

▲

rstupek 7 hours ago | parent | next [-]

I think the fact they don't require it shows it's moribund. If cert providers (or google with their big stick of chrome) specified it is required to have DNSSEC to get a certificate, everyone would jump in line and set it up because there'd be no other choice.

	▲	tptacek 7 hours ago \| parent [-]
		I agree that not checking it all is an even worse signal. I'm just saying the fact that this is officially enforced only in 2026 is itself a bad signal. At any rate, the CAs you'd have worked with were enforcing DNSSEC this whole time.

▲

indolering 8 hours ago | parent | prev [-]

Which is really unfortunate, since it's pretty easy to do.

	▲	tptacek 8 hours ago \| parent [-]
		I agree that it's relatively easy for CAs to validate DNSSEC. I think the fact that they weren't technically required to, despite the sole remaining use case for DNSSEC being to protect against misissuance, is a pretty strong indicator of how cooked DNSSEC is.

▲ mindslight 6 hours ago | parent | prev [-]

Big sites don't have the same concerns as individual end users, in this case specifically about centralized servers surveilling DNS queries.

DNSSEC zone signing lets one resolve records without having to directly go through trusted (ie centralizing) nameservers. (If you run your own recursive resolver this just changes the set of trusted servers to the zones' servers).

I've made this argument in the context of your poo-pooing DNSSEC before, and I don't expect you to be receptive to it this time. Rather I just really wish I could get around to writing code to demonstrate what I mean.