Almost whenever a security event involving Windows is featured on Slashdot or Heise, some Linux fanboys will invariably post their cocky “that would not have happened with Linux” messages.
I start to see the same thing with DNS incidents and DNSSEC.
This is just as childish and stupid, especially as the voices writing such notes are often enough established engineers and not your average adolescent geek.
In reality most of the recent DNS hacks were not perpetrated by crafting forged DNS responses to poison caches but were successful attacks against the Registrar/Registrant interfaces. No, DNSSEC would not have helped in such a case.
The same is true for DNSSEC and the domain-based censorship which was just passed by the German government. DNSSEC will not help here. It is no panacea against meddling with DNS answers. It depends on who is doing the validation and whether the offending domains are actually signed or not (not likely these days):
- DNSSEC validation is done at the ISP resolver:
DNSSEC doesn’t help the end-user here at all.
- DNSSEC validation in the client, ISP recursor is used:
If the domain is signed, then the user will get a NXDOMAIN (or maybe a better error-reporting) instead of the IP address of the STOP-sign website.
So the censuring still works, just the alerting of the user (and the logging of the STOP-sign access) does not.
- DNSSEC validation in the client, full recursion at the client
Censorship is ineffective. Just the same as when the local recursor does no DNSSEC checking.
Remember: DNSSEC is not about the availability part of security, it’s only about the integrity. Censorship does not really need to attack the integrity, it’s all about availability.