DNSSec in the real world: my experience with DNSSec

December 25, 2014

In the abstract, I like the idea of secure DNS, because really who wouldn't. I've read enough criticism of DNSSec the protocol to think that it's not great and maybe should be replaced by something more less ungainly, and I've been convinced that it is not the right way to get TLS certificate information, but those are relatively moderate issues (from some jaundiced perspectives).

That's in theory. In practice, things are rather different. In practice the only thing DNSSec has ever done for me is prevent me from seeing websites, generally US government websites (I seem to especially trip over the NIH and NASA's APOD). My normal caching resolver is Unbound, which does some amount of DNSSec checking and enforcing. When I set it up initially, these checks kept keeping me from resolving IP addresses so I kept turning them down and turning them down, to the point where I've now done my best to turn them off entirely. But apparently my best isn't good enough and so periodically Unbound refuses to resolve an IP address, I kill it and start my old dnscache instance, and the IP address immediately resolves.

At one level this is not particularly surprising. DNSSec creates a whole new collection of ways to have DNS resolution screw up, either because people fumble their DNSSec implementation (even temporarily) or because your local resolver can't get a DNSSec reply that it requires to be secure. It's not surprising that this happens every so often.

At another level this is utterly fatal to DNSSec, because of the security false positives problem. For many people, actual DNS interception is vanishingly rare and they perform a very large number of DNS lookups. If the actual signal is very rare, even a very low noise rate will totally swamp it. In other words, every or almost every DNSSec failure people get will be a false positive, and people simply will not tolerate this. As has happened with me, DNSSec will become one of those things that you turn off because it's stopping you from doing things on the Internet that you want to do.

(And in turn this means that vendors cannot make DNSSec something that end users can't turn off. Forcing something that in practice screws your users is an extremely bad idea and it gets you extremely bad reactions.)


Comments on this page:

By Pete at 2014-12-26 01:23:21:

Meanwhile I'm just using BIND and everything works fine. Are you sure you're not laying the problems of Unbound at the feet of DNSSEC? Could be that Unbound is junk software and your suffering is your decision alone.

By cks at 2014-12-26 02:35:18:

One issue I was having was definitely solved by turning yet another bit of DNSSec checking off, so I'm pretty confident it's Unbound's DNSSec stuff that's at fault. It could be that Unbound's implementation is bad, but then Fedora picked Unbound as their default DNS caching server and left its DNSSec stuff turned on by default, so I have to believe that they've looked into the situation.

Could be that Unbound is junk software and your suffering is your decision alone.

The FreeBSD folks moved from BIND in the base system to Unbound as the local DNS resolver (along with LDNS):

Personally I don't think they would have made such a change lightly given that BIND has been part of FreeBSD for its entire history. I don't think the problem is Unbound, but that one can't be as sloppy with DNSSEC as you can with unauthenticated DNS.

Just like with crypto in most other situations, one has to sweat the details, otherwise, as we've learned with SSL/TLS in 2014, you open yourself to holes and attacks.

I have to believe that they've looked into the situation.

You forgot the debacle of the thousands of texlive packages?

Written on 25 December 2014.
« The security effects of tearing down my GRE tunnel on IPSec failure
My experience with ZFS on Linux: it's worked pretty well for me »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Dec 25 02:02:54 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.