That's the problem: it was designed to deal with the IETF namedroppers favorite attack (server-server cache poisoning, a la Eugene Kashpureff) and not any part of the real-world threat model for DNS.

In fact, at this point, DNSSEC has very little to do with securing the DNS (as it is used by the rest of the Internet) at all; rather, it's a self-justifying self-rationalizing mechanism for building random new things nobody uses on top of the DNS. So it won't protect your DNS records, but it will try its hardest to make sure the security of your SSH sessions somehow depend on the security of those records.

An actual good solution wouldn't really be that complex to implement. You basically just need to sign a record or set of complimentary records (for example, all of your NS records), and make it reasonably simple to select and return those signatures from a recursive resolver, and then build a certificate hierarchy the exact shape of the DNS itself. You install the public key for the super seekret ICANN cert, and the client either trusts the recursive resolver or caches the tld certs and recursively resolves those, or some combination of the two.

Beyond that, it's all a clerical matter of being better or worse at verifying identity at the level of the registrar and the NIC.

Maybe a third party could start implementing something like this (maybe just a directory of domains validated in the way we do that for TLS), and it could be grafted to a NIC's infrastructure (maybe I'll talk to CIRA about it), and then maybe ICANN would pay attention after that.

I'd be up for it, if a handful of other people would try as well.

There are an awful lot of people who are unaware that DNSSEC is basically useless, unfortunately.