With RFC 9102, you don't need DNSSEC to work on all network paths. But it was smothered in the crib by browser vendors. Sad.
This is like, what you're up against when trying to discuss DNSSEC realistically: people who think DANE stapling was a viable path forward. An entire new generation of SSL-strippable connections; the last one took us 15 years to get rid of. Let's try that again!
An attacker with a compromised certificate MITMs the site, terminates and proxies TLS using the bad certificate, and the TLS UA never sees that it's supposed to enforce DANE too?
That's what ExtSupportLifetime is for. Other pinning approaches, e.g. HSTS-like preload lists, work too. Union them. You need only one of N mechanisms to say "my domain promises to staple DNSSEC" to make the browser expect it and fail hard if it's not there. But stapling is just a transitional measure anyway.
The better solution, of course, is to just fix DNSSEC so the problem doesn't occur in the first place. There's no need to staple and no opportunity to strip if you can verify the DNS resolution end to end.
So, in this "doesn't work" scenario, it just so happens that the very first client contact endpoint is via this MITM, and the certificate is compromised at this moment, and HSTS or something prevents stripping TLS entirely, and the endpoint isn't on a DANE preload list (although it is on the HSTS one!) and DNSSEC isn't working in the client's environment? All at once?
Yeah, right.
Who's going to use HSTS, and DANE, but not set the "I'm using DANE" bit in the HSTS config? And if you're not using HSTS, an attacker can just strip TLS anyway and you lose regardless.
So yeah, it does work, and the "doesn't work" failure mode is server misconfiguration.
And, of course, this is just to get you to the point where you can count on DANE stapling for sites you've already been introduced to!
You're not worried that you're kind of making my case for me? You're definitely kind of making my case for me.