It's worth keeping in mind that the Turkish government hi-jacked DNS resolvers; as-deployed DNSSEC would in no way have helped.
The 2008 attack was not novel and was described by DJB about 7 years prior to Kaminsky, and DJB's utilities included a mitigation: randomized source ports. At present there is an equivalent vulnerability: UDP/IP fragments can be spoofed in such a way that poison records can be injected to resolvers. It is possible to mitigate this, but many DNSSEC proponents - including the Bind maintainers - refuse to consider mitigations because they feel that people should be moving to DNSSEC instead. It bears repeating that as-deployed; DNSSEC doesn't help protect against cache poisoning towards stubs - only towards caching resolvers.
DNSSEC was also the reason why source ports weren't randomized, and thus the reason that Kaminsky's attack was briefly so viable. Somewhere there's a NANOG post with the BIND maintainers talking about the "scoreboarding resolver" they'd implemented but wouldn't release, because (even back in 1997) the real answer was DNSSEC.
I'm not sure I agree about the novelty of Kaminsky's attack. Ruefully: I remember arguing with him about that on Twitter, him getting me on the phone to explain how his attack refined the older cache poisoning attacks, me conceding it, and then bad stuff happening a few months later.
My facts are right. As-deployed, clients don't validate DNSSEC; so the resolvers can pass on any response and the stubs/browsers will accept it. The signatures aren't being checked.
Edit to update: The Turkish Government forged DNS to block twitter. Even if clients did start validating DNSSEC - if the failure mode is that it still be blocked, but for a different reason, is that really useful? A Government could simply drop all queries for twitter.com too. How does DNSSEC meaningfully help?
The signatures should be checked client-side. As I pointed out in another comment on this page (https://news.ycombinator.com/item?id=8896318), recent studies find that more and more resolvers send the RRSIGs to the clients, who then should check them.
In the case of the Turkish hijacking, of course hijacked resolvers would not send RRSIGs. This should prompt the client to request another resolver.
It depends on what you mean by clients. The most popular Firefox plugin to validate DNSSEC does in fact validate responses properly, and would have caught the Turkish MITM.
The 2008 attack was not novel and was described by DJB about 7 years prior to Kaminsky, and DJB's utilities included a mitigation: randomized source ports. At present there is an equivalent vulnerability: UDP/IP fragments can be spoofed in such a way that poison records can be injected to resolvers. It is possible to mitigate this, but many DNSSEC proponents - including the Bind maintainers - refuse to consider mitigations because they feel that people should be moving to DNSSEC instead. It bears repeating that as-deployed; DNSSEC doesn't help protect against cache poisoning towards stubs - only towards caching resolvers.