Your point was already addressed: http://news.ycombinator.com/item?id=2960504.
The resolver software that ultimately makes the trust decision --- examining the RRSIG records in the response and deciding what to display or do as a result --- is running on computers under end-user control. If the end-user, or whoever maintains your browser or other software for them, decides that a particular key has probably been compromised and should not be trusted, no RFC can force their software to treat that key as valid simply because it has a valid DS from its parent zone. You can have a DNSSEC blacklist just as we have openssl-blacklist and openssh-blacklist. You can make your resolver do whatever you want.
Now, this is considerably more work than clicking around your browser's Preferences UI to delete DigiNotar's keys, but it's not as if every user has to do it themself.
However, I appreciate the information about what the DNSSEC quasi-standards say you should program your resolver to do.
In one corner, we have PKI protocol whose trust roots are configurable, so much so that every mainstream browser has point-and-click UI to change them. It so happens that this protocol is also the de facto standard with 15+ years of deployment history.
In the other corner, we have a PKI protocol that, instead of providing configurable trust, hardcodes trust into DNS names. Instead making point-and-click configuration changes, to alter the PKI roots in this scheme you'd have to "violate" the standards of one of the core Internet protocols by building and deploying a noncompliant DNS resolver.
Kragen, why on earth do you prefer the second solution to the first?
First, the existing PKI already hardcodes trust into DNS names. If Libya's registry decides vb.ly is immoral and should be redirected to a server serving up a placeholder page, Violet Blue can't make her site continue working. And they can almost certainly even obtain an X.509 certificate proving that they really do own vb.ly, so that you still get the placeholder page instead of a TLS error page even if you visit the site over https.
Second, the existing PKI grants every CA power over the entire namespace, instead of merely over the names it was established to verify. That means I can't get my intranet site to authenticate properly without granting my company the authority to MITM every site in the world.
As a result of this idiocy, recovering from trust root compromises seems to have gone from being a once-in-a-lifetime catastrophe to a yearly, even monthly catastrophe, to the point that intelligent people think it's important to have a point-and-click UI to recover from it.
The current configuration of the SSL PKI grants every CA power over the entire namespace. But that's not intrinsic to the SSL trust model.
We are zero lines of code away from a key-continuity trust model where no CA's are required for vigilant and technically qualified users. Some people call this "TOFU".
We are zero lines of code away from a cert-pinning model that uses installed based of millions of people to detect bogus certs, regardless of whether Verisign has complied with some government order to sign them.
We are tens --- literally tens --- of lines of code away from a model that cordons off parts of the CN space to specific CAs or notary servers. Don't want Thawte to have a say in whether a cert belongs to EFF.ORG? Don't want to have to depend on key continuity or cert pinning to enforce that? This level of sophistication is almost but not quite a UI feature away from completion.
None of these ideas are trivially implemented with DNSSEC. The entire design of DNSSEC militates against some of them.
Meanwhile: DNSSEC does not exist. Applications are not ready for DNSSEC. Many of them will require new revisions to function properly in a post-DNSSEC world. DNSSEC the way people-who-hate-CA's conceive of DNSSEC requires every user to run a full caching resolver on their desktop. How many people in Iran do that today? Having never been deployed "in the large", nobody knows whether DNSSEC even works.
By any reckoning, we are far more lines of code away from a working DNSSEC trust model than we are from any reasonable improvement to the HTTPS/TLS trust model, which is far more adaptable than DNSSEC (the SSL/TLS PKI has no other dependencies other than SSL/TLS trust, unlike DNSSEC, which also has to make the whole Internet work).
So I'm asking you again: why would you rather deploy DNSSEC than fix HTTPS/TLS?
Please don't say "because I don't trust all the CAs in my browser configuration" again.