I mean, these are the steps that can bring it. And with Let's Encrypt as a safe fallback, it actually is feasible this time.

Long shot? Yes. But not impossible.

▲

ekr____ 8 hours ago | parent | next [-]

What's the incentive for individual sites or browsers to do this?

From the site's perspective, they're going to need to have a WebPKI certificate for the foreseeable future, basically until there is no appreciable population of WebPKI-only clients, which is years in the future. So DANE is strictly more work.

From the browser's perspective, very few sites actually support DANE, and the current situation is satisfactory, so why go to any additional effort?

In order for technologies to get wide deployment, they usually need to be valuable to individual ecosystem actors at the margin, i.e., they have to get value by deploying them today. Even stipulating that an eventual DANE-only system is better, it doesn't provide any benefit in the near term, so it's very hard to get deployment.

	▲	tptacek 7 hours ago \| parent [-]
		A fun note: I vibecoded a dumb thingy that monitors the top 1000 zones on the Tranco research list of popular zones for DNSSEC status: https://dnssecmenot.fly.dev/ Obviously, the headline is that just 2% of the top 100 zones are signed (thanks to Cloudflare). But the funnier thing is: in 5+ months of letting this thing run, it's picked up just three changes to DNSSEC status among all the zones it monitors. The third happened just an hour or so ago, when Canva disabled DNSSEC.

▲

tptacek 9 hours ago | parent | prev [-]

The first step you'd need is a reliable way to deliver DNSSEC records to browsers, which does not currently exist. So I feel like you're missing at least a step 0, if not a step -1 (of getting ~anybody to actually sign zones.)

▲

kbolino 8 hours ago | parent | next [-]

Aren't browsers generally implementing their own DNS resolution (via DoH) nowadays anyway? Not sure it helps that much, but operating systems not enforcing/delivering DNSSEC seems like a side-stepped problem now.

	▲	tptacek 8 hours ago \| parent [-]
		No, not as a general rule they aren't. And remember, the DNSSEC record delivery problem isn't an issue for the majority of all browser sessions, just a small minority that are on paths that won't pass DNSSEC records reliably. Since you can't just write those paths off, and you can't really reliably detect them, you end up needing a resolution fallback --- at which point you might as well not be using DANE. This was a big enough issue that there was a whole standards push to staple DNSSEC records to the TLS handshake (which then fell apart).

▲

cyberax 3 hours ago | parent | prev [-]

I sign my zones :)

The reliable way is DoH/DoT that are rapidly going to become the standard. They don't suffer from fragmentation issues, so they can reliably get the DNSSEC chain.

Or maybe the next step is putting the stapled response into the certificate. Perhaps it can even be used by Let's Encrypt as a part of the challenge, providing the incentive to get it right.

The original stapled DNSSEC experiment was suffering from misaligned incentives. CAs didn't care at all about it.