DNSSEC Signing Revisited

A couple of years ago, I signed the DNS records of my personal domain with DNSSEC, and wrote a blog post on the experience. Since then, life has been generally good, although there have been a couple of hiccups where the signatures expired and my domain became briefly unavailable to resolvers that verify DNSSEC. I figured out how to make the re-signing of the domain happen automatically, and those problems for the most part went away.

I recently upgraded my DNS server from the Debian “squeeze” release to the “jessie” release to ensure that I continue to get security updates. A month or so later, I got a notification that my DNS was broken again. I figured that the process that re-signed and published my DNS records had failed to start; quite a few things like that broke in the upgrade.

But it was worse than that: the dnssec-tools package that I have been using for signing (described in that blog post) is no longer available from Debian for jessie, apparently because of some unresolved bugs. I needed to quickly find another way to sign my domain.

BIND to the rescue

Looking around for alternatives, I found out that BIND 9.9, which is available as a jessie package, supports inline signing. I have always used BIND as my DNS server, and I welcome the prospect of signing without a lot of external dependencies. ISC provides a good (but incomplete – see below) how-to guide on turning on DNSSEC signing, so I followed those instructions.

My first problem was the keys themselves. Dnssec-tools seems to have used a different format for the public/private keypairs used by DNSSEC than BIND, so I needed to generate new keys. I started to do this, but it was taking forever! It turns out that dnssec-keygen needs a fair amount of cryptographic entropy to generate a keypair, and I was running it on a virtual private server that doesn’t get much entropy. So, despite my aversion to transferring private keys, I generated keys on my home Linux (Ubuntu) machine. This took long enough, even with me banging on keys and doing every other random thing I could think of.

Having transferred the keys (two keypairs, a Zone Signing Key and a Key Signing Key) back to the name server, I went ahead and signed the zone. But I realized something was missing: the ISC how-to guide doesn’t talk about publishing the DS records at the parent domain that are necessary to link my keys to the global DNS trust chain.

Fortunately, I found the instructions for this in a different ISC how-to guide. The dnssec-dsfromkey utility converts the public keys into the necessary format for the DS records. I then logged into my domain registrar’s website and added the necessary DS records.

Everything looked pretty good, and I was able to look up my records using my verifying resolver. But I also checked an online utility to see if it saw any errors. It said my DNSSEC was still broken. I thought maybe there were some old records in a cache somewhere so I waited a day or two.

Time didn’t help here, and I couldn’t figure out why it was still reporting an error. So I consulted a very knowledgeable friend – thank you Patrik! – who introduced me to a different tool, DNSViz, that showed that my slave DNS server, running on a different host, was returning different data. Specifically, it was showing several DNSKEY records from my old configuration that shouldn’t have been there.

I looked at the primary zone file, both the unsigned one I maintain and the one signed by BIND (using the named-checkzone utility, since the file is in a binary format). Everything looked fine; the extra DNSKEY records weren’t there. I re-transferred the zone to the secondary, but the extra records remained.

Finally, somewhat in desperation, I deleted the zone file and the associated .jnl file (not sure where the latter came from). Restarted BIND and everything was fine. I’m guessing that the .jnl (journal) file was telling BIND to make only incremental changes to the zone, and therefore the old DNSKEY records were untouched.

I will, of course, need to continue to watch to make sure that the signatures don’t expire since I don’t understand the key rollover methodology yet. But module a couple of problems getting started here, I’m optimistic that inline signing with BIND will be much easier than what I had been doing.