Chris's Wiki :: blog/tech/DNSSECFailureDrivesDisablement

The news of the time interval is that the people in charge of the New Zealand country zones (things directly under .nz) fumbled a DNSSEC key (KSK) rollover in such a way as to break DNSSEC resolution for those domains (see DNSSEC chain validation issue for .nz domains, this news article, and more). The suggested resolution to return these domains to working DNSSEC was for all of the people running DNSSEC validating resolvers to flush the zone information for everything under .nz. Or you could wait for things to time out in a day or two.

You know what else you could do in your DNSSEC validating resolver to fix this and other future DNSSEC 'we shot ourselves in the foot' moments? That's right: you could disable DNSSEC validation entirely. The corollary is that every prominent DNSSEC failure is another push for people operating resolvers to give up on the whole set of complexity and hassles.

Some people are required to operating DNSSEC validating resolvers, and others are strongly committed to it (and are so far willing to pay the costs of doing so in staff time, people's complaints, and so on). But other people are not so committed and so the more big DNSSEC failures there are, the more of them are going to solve the problem once and for all by dropping out. And then DNSSEC becomes that much harder to adopt widely even if you think it's a good idea.

(As for whether DNSSEC is a useful idea, see for example this RIPE86 slide deck by Geoff Huston, via, also.)

An additional contributing factor to this dynamic is that attacks that are (or would be) stopped by DNSSEC seem relatively uncommon these days. In practice, for almost all people and almost all of the time, it seems to be that a DNSSEC validation failure happens because a zone operator screwed up. This gives us the security alert problem, where the typical person's experience is dominated by false positives that just get in their way.

PS: At this point it's probably too late to fix the core problem, since DNSSEC is already designed and deployed, and my impression is that it has low protocol agility (the ability to readily change). Exhorting people to not screw up things like DNSSEC KSK rollover clearly hasn't worked, so the only real solution would be better ways to automatically recover from it. Maybe there are practical changes to resolving DNS servers that can be done to work around the issue, so for example they have heuristics to trigger automatically flushing and re-fetching zones.