Adventures with DNSSEC Part 1: Checking signatures

A confession: “Deploy DNSSEC” has been on my to-do list for at least a couple of years. During that time, I have been pinging my domain registrar to allow registration of DS records so that my domain’s DNS can be authenticated properly. I have used their delay in making this possible as an excuse to push that to-do list item down to the bottom.

I recently attended TrustyCon, an alternative security conference held during the RSA Conference a month or so ago. At TrustyCon, Jeff Moss, organizer of DefCon and other security conferences, gave a talk entitled “Community Immunity” that addressed security from a public health point of view: we need to be secure both to protect ourselves and the community. A video of Jeff’s talk is on YouTube, starting at 6:06:00.

Using a caching name server that checks DNSSEC response signatures was one of his examples of protecting oneself. Signing your domain with DNSSEC protects others who use it. Understanding this distinction started me thinking about DNSSEC as not one big thing to do, but two or more. And since I run my own caching name server and checking signatures is supposed to be easy, so why not?

According to Jeff’s talk, turning on DNSSEC verification is as simple as putting the following in your named.conf file (assuming you’re running BIND, of course):

options {
        dnssec-enable yes;
        dnssec-validation yes;
        };

So I thought I’d give it a try, but I did a little homework first.  I found lots of confusing information, including the fact that since BIND 9.5 (I’m running 9.7), dnssec-enable and dnssec-validation both default to yes. This must not be the reason that I’m not checking signatures.

After looking around a while, I found a tutorial on HowToForge that describes the DNSSEC deployment process on Debian Linux in some detail. It doesn’t clearly separate the validation from signing steps clearly, but step 2 told me what was missing: my configuration didn’t specify the root keys that should be trusted by my name server. To fix this problem, I added the line:

include "/etc/bind/bind.keys";

at the bottom of my configuration, and restarted the name server.  It immediately crashed with a segmentation fault!

After a bit of hunting around, I found Debian bug #630733, that describes a segmentation fault under some circumstances when starting BIND. The circumstances didn’t quite match mine, but it gave me the clue I needed: my system had an empty file, /var/cache/bind/managed-keys.bind that was confusing BIND. After removing that empty file, the name server worked fine.

To test, I tried resolving the intentionally mis-signed domain dnssec-failed.org on a machine that uses this name server:

fenton@kernel:~$ dig dnssec-failed.org soa

If the name server is checking signatures, the status returned will be SERVFAIL. If it is not checking signatures, the status will be NOERROR.

Like me, you might be wondering if this is a good idea to do. Might DNS resolution for some domains be broken by inadvertent bad signatures? Using the above dnssec-failed test, I found that both Google (8.8.8.8) and Comcast (75.75.75.75) are checking DNSSEC signatures. If it doesn’t cause a problem for them, it won’t for me.

I’m still struggling with deploying DNSSEC on the signing side, so I’ll leave that for a subsequent article.