Reviving RFC 9102 would help. It staples DNSSEC chains to TLS handshakes so clients don't need to use a working DNSSEC resolver to use DANE. In effect, RFC 9102 presents DANE in a form that a WebPKI-centric client can digest, treating DNS root delegations as a kind of certificate authority. Browser vendors vetoed it on complexity grounds. They were wrong to do so. If the security community is serious about preventing future "return 4" attacks, it needs to solve the universal issuance problem one way or another, and the best way is reviving RFC 9102 so we can gradually onboard DNSSEC. DNSSEC opponents in "security community" are partly to blame. They cast aspersions over DNSSEC, then use the resulting spotty adoption to justify their aspersions. It's rotten. DNSSEC just isn't that hard to actually get working. I'd also suggest we can adopt a dual-stack approach incrementally. Let, say, contoso.com register a regular certificate (perhaps via ACME or whatever) *and* publish DANE TLSA records pinning the certificates. A DANE-ignorant, CA-only client would get the same level of protection provided today. A DANE-aware client could validate *both* the DANE record _and_ the CA chain and reject connections if either failed. Doing so prevents "return 4" attacks while enabling incremental adoption. Such a client could even check DANE TLSA records on *non*-DNSSEC-validated zones under the theory that they'd still provide useful signal. Doing so would in-effect revive HPKP, which I believe was also smothered in the crib, but in a way that provides a gradual onramp to a DANE-over-DNSSEC-only world. You could start by 1) publishing regular unauthenticated TLSA records, then 2) add from-root DNSSEC validation to your zone, then 3) start stapling via RFC 9102 (still serving the CA chain), then, when the ecosystem is ready, 4) stop sending the CA chain. You'd use an HSTS-like mechanism to ratchet progress through these stages to resist downgrade attacks. More ambitious than RFC 9102 ExtSupportLifetime because the ratches goes all the way to "I do not use CAs and any CA attestation for this domain is a lie". Additionally, the ratchet wouldn't be a pure client-side cache, but part of the authoritative TLD response. That is, the .com TLD would, when asked about contoso.com, report not only its NS records and glue, but also "is forever at stage >= 2". My hope would be that major TLDs would start mandating DNSSEC for new delegations (like .bank) and publish records commanding resolving to reject any non-signed subdomains. If we really tried, we could do, say, .edu and .gov by 2030, with grandfathering. This way, domains in these TLDs would come pre-ratcheted without some stupid preload list. We don't need a flag day to fix WebPKI, no matter what people tell you.

More seriously, we need to get out from under WebPKI, which allows *any* one compromised CA to compromise *all* TLS traffic. What is to be done? DANE is to be done. Secure DNS for authorization is the obvious answer. It is a "fix everything button". People were proposing the concept as far back as 1996, in vain, because the web went in a different and riskier direction. Yada yada yada, "you trust the TLD authorities with DANE", WebPKI defenders yap. I don't want to hear it. Just stop. My brother in malware, WebPKI lets any bleach-drinking "derp my secret key is 4" CA break the internet, yet you're sitting there, presumably huffing the fumes yourself, opining as a serious person that we can't have browsers use DANE to authenticate connections because the DNS roots might be evil one day? Meanwhile, because WebPKI has functionally become Let's Encrypt, and LE will give me a certificate if I demonstrate domain control, WebPKI has exactly the same vulnerability a DANE world would, but without any of the safeguards or benefits. "Oh, but in WebPKI we can eject the bad actors". Yeah? Well, in DANE, I don't have to care, because the wtf.lol TLD doing something stupid can't hurt me. "We can just push a revocation!" Okay, and we're supposed to rely on a tiny handful of CRL aggregators to do that? And reach all the people embedding random CA bundles in long-lived systems? No, the security of the internet shouldn't rely on some guy's pager going off, especially not when the people who run these things have convinced us all that CRLs and OCSP are somehow bad and that only they, collectively, are allowed to publish global lists of who's been cryptographically naughty or nice? No: name constraints, CA/B tut-tutting, and CAA aren't the answer. DANE is, always has been, and always will be because having two partly overlapping principal languages and a false separation of concerns is a ridiculous footgun for the internet.