The fix in either case is key rollover; if it's the KSK it needs to go to the root which will be annoying but doable. The TLD needs to do this, and it'll be complete, for everyone, regardless of updates or shitty devices, after the relevant TTL has passed. The TTL on the root zone's DS records seems to be 1 day.
If the TLD fails to do the key rollover for whatever reason (incompetence, maliciousness, …) - DNSsec is now broken on the entire TLD. So, security of DNS fails down to classic DNS with all spoofing problems and randomization/uniqueness countermeasures we've accumulated over 35 years. Their DNSsec signatures are still valid, DANE is still green. It really depends on your stance on this; personally speaking I'd consider the TLD unusable now and end the post here, but I assume you don't share that view.
Can you spoof/break DANE now? Yes, if you can break DNS. But in that case, you're in a whole lot of trouble already; if you can really break DNS (poison arbitrary resolvers) you can now get a 'classic' (non-DANE) TLS certificate from your favorite ACME provider. If you can't fully break DNS, that essentially leaves MITM situations, i.e. specific individual situations. Part of that is getting improved with DoT, DoH and DoQ (which, yes, have their own issues.) Realistically, browsers would be marking the entire TLD DANE-untrustworthy now.
On Earth-666, you could presumably roll out DLV [DNSsec Lookaside Validation] now — that's the "side root" mechanism that was used before DNSsec became ubiquitous at the TLD level. Most DNS people absolutely hate it. Ignoring that, the one TLD is now screwed and it's a layer 9 fix. Is that better or worse than a compromised CA resulting in every single TLS service being screwed? Neither, just different, I'd argue.
(As batshit crazy as it is, maybe DLV is the answer to the kind of compromise you have in mind. You seem to be happy with browser vendors having a lot of authority and control over trust. A browser could unilaterally decide to roll out DLV on a given TLD, or any level of domain really. Somebody has to run that as a service, though. Unless they ship the records with the browser… but that's getting really extreme now.)
For the sake of useful discussion, another case to consider is a malicious TLD that specifically hates you. (Or was given reason to hate you by legal means.) They can publish completely bogus data for your domain, including DANE records. But they can also get ACME certs… so I'd call that a wash. (Sure, they wouldn't be able to get OV certs. But a situation with OV certs is IMHO also a situation where you wouldn't use DANE exclusively, rather you'd require both DANE & classic PKI.)
That's because I don't understand what point you're trying to make. Something here is probably blatantly obvious to you and entirely opaque to me.
> Nothing like that will ever happen in the DNSSEC PKI.
This is a nonsensical statement to me. What is "like that" in DNSSEC? A TLD operator fucking up badly? That's not even the same class of event since the blast radius is at least limited to their TLD(s). For most TLDs (though not gTLDs), the layer 9 "owner" isn't the operator, it'd result in that contract getting cancelled and someone else running the TLD instead. Do you mean, the root keys getting screwed up? That's akin to (and less likely than) a browser shipping a compromised CA store. https://www.iana.org/dnssec/tcrs these people can screw up the DNS PKI for the entire planet, I guess.
The roles between Web PKI and DNSSEC plainly do not line up for simple analogy statements to work. Again: what role in the DNSSEC PKI is getting compromised in your argument?
Constrained names aren't a solution for this problem. eMudhra had a thriving business selling certificates to US organizations. Unless you're really coming from a place of "we can't trust companies in India", the only coherent thing you can be arguing is that only one company should issue certificates from North America.
We tried that before. It was called Verisign. In a DANE-first world, it would again be Verisign. Immutably, and without accountability. There would be no transparency logs and no dis-trusting of them when they inevitably misissued at the behest of the United States Government.
The WebPKI's answer to this problem is to gradually ratchet requirements so that fewer and fewer companies can run CAs, and to build and coercively require transparency mechanisms like CT (something people on this thread inexplicably object to as "bullying") so those requirements can be enforced.
What Verisign can do in all of this is change the NS and DS for a given domain, and Mallory can run different DNS servers for that domain then, giving out different data, including TLSA records. If they do this, they can also get ACME certs, except that will result in a permanent CT entry. Great feature! We should build a clone for DNSsec.
Will the owner of the domain notice either of these things? Hard to say. In both cases, you need to query something (CT logs or DNS caches) for your own domain, and check if things pop up you didn't put there. You can't query specific ISP's caches, that sucks. And it's only visible in DNS while under attack. Still, my gut feeling is more people will actually notice their NS getting messed with, because it happens by accident when they screw up their DNS. "credit card expired" and stuff like that. DS records are automatically monitored by any self-respecting DNSsec implementation for propagation & state triggering, but only for a given list of servers & caches. The attack could probably stay under the radar by keeping 1.1.1.1 and 8.8.8.8 intact, or at least some instances of it.
And then there's that tiny problem that only browsers really care about CT. Anything else is, at best, protected only if it can't be distinguished by fingerprint on TLS connect. DNS can only be subverted on a per-resolver/cache basis. Not really better, not worse, but different.
I have two takeaways from this. First, I should poke some people at IETF about inventing "DT", DNSsec Transparency. I expect it could probably be implemented in the DNS caches [in addition to end resolvers]. That'd be an interesting way of rolling things out: you can cover shitty client devices without changing them at all. If they use a DNS cache doing "DT", they'd be covered, even if not perfectly. The best time to do any of this would've been 2013, when CT came along. The second best time is now.
The other takeaway is, I should probably prod ENISA people to see if the EU bureaucracy can force some things. We've recently started working with them (mostly because the US apparatus is underfunded to hell and can't answer an e-mail with less than 6 months of delay), though we're only a tiny cog. And if the thought of the EU requiring some level of DNSsec or "DANE-and" gives somebody a heart attack: good!
And let's at least not lie about one thing: if "DANE-and" is being validated for a given target, that does prevent exploiting the eMudhra compromise.
P.S.: before we get in another pile of miscommunication: DNSsec/DANE validation goes on the end application or end host DNS component and the cache. The AD bit is a misdesign and scourge on DNSsec, should be ignored on any network packet, and is not what you build trust on. (AFAIK this is consensus in the DNS world, and one of the things getting ratcheted on their side.)