I think that would be fairly easy to create rules for, though. Only check at the level where registrars are handing out domains (i.e. trust the most-specific SOA, not counting TLD).
In fact, with LetsEncrypt or DV in general, I'm not sure what exists already to stop the scenario you're referring to. My TLD can decide they want certs for my domain and start advertising their nameservers to any IP addresses owned by LetsEncrypt.
As it is there's plenty of manual checking that keeps CAs in check. I don't see why the same processes couldn't be applied to such a system.
You can check that a new certificate was issued for your domain through Certificate Transparency. Maybe if DANE/TLSA certs would also have be submitted to CT logs and browsers required CT that'd provide stronger security that we have now...
Another thing is DNSSEC's reliance on RSA 1024 (did that change?).
It will take a while until everyone has upgraded, but so far no fast attack on RSA 1024 has been reported...
Even elliptic curve algorithm based keys are possible now (and recommended because of their small size, which is good for one packet UDP answers, which is not possible with RSA 2048)
Other problems with DNSSEC aside, the crazy thing here is the suggestion to replace the Web PKI with a system that has taken longer to migrate towards safe key sizes than the existing solution. 1024-bit keys for end-entity certificates were deprecated in 2013 and the last 1024-bit roots were pulled in 2014-2015 (ish?). I don't feel like the CA/B Forum is a particularly fast-moving body, so this is pretty telling.
In fact, with LetsEncrypt or DV in general, I'm not sure what exists already to stop the scenario you're referring to. My TLD can decide they want certs for my domain and start advertising their nameservers to any IP addresses owned by LetsEncrypt.
As it is there's plenty of manual checking that keeps CAs in check. I don't see why the same processes couldn't be applied to such a system.