I recently deployed DNSSEC on almost all of my domains and lived to talk about it!

A little history, first. Back in July of 2010 I used ISC's DLV registry to sign one of my domains since the com. and net. TLDs weren't signed at the time.  The DLV registry provided a list of trust anchors so individuals could sign their domains and DNSSEC validating caches could easily look them up.  I signed tengigabitethernet.com. with no ZSK rollover and it worked!  I also configured all of my internal caches to perform DNSSEC validation (dnssec-validation yes; along with making sure the "." keys are fresh).

Since com., net., org., and most other TLDs are now signed, a few months ago I decided it was time for me to sign the remainder of my domains and figure out how to perform automatic ZSK rollover.

I first started reading a few documents about the right way to sign zones and get together a sane configuration with BIND (9.7.3 at the time).  This howto probably contained the most information, so I used it primarily.  Creating the keys and signing domains was familiar to me at this point, so that was mostly review.  I then started to research the best way of performing automatic ZSK rollover, which turned out to be the difficult part.

For security reasons, it's recommended to roll over the ZSKs (zone signing key, as opposed to a key signing key which isn't published) periodically.  I decided that it would be good to roll my ZSKs every over month (the odd-numbered months, specified as 1,3,5,7,9,11 via cron).  After searching the Internet for some suggestions on best practices for ZSK rollover, it seemed that most folks were using a new directive in BIND that took the throught out of this: dnssec-auto.

The dnssec-auto configuration directive was introduced starting with BIND 9.7.0 and includes the ability to automatically re-sign zones and perform routine key maintenance, including key rollovers.  Apparently this feature was introduced prematurely and creating new keys with dnssec-auto automatically wasn't possible until 9.8.0.  This sounded exactly what I wanted, however.. a bit of a rub, this requires that all zones be converted to dynamic zones.  This is required because BIND needs to constantly re-write the zone files (it actually uses a journal) and mainatin them by keeping serial numbers updated.

Dynamic zones didn't seem to be a big deal at first, but I decided I didn't want to go this route right now for a number of reasons.  First, moving from a static zone to a dynamic zone removes the ability for me to edit the zone file by hand, which I've gotten used to doing.  Maybe I'm the only one who does this, but I use zone files in lieu of an official IP address management system and include all sorts of comments in them.  To maintain dynamic zones, one must use the nsupdate(1) utility that ships with BIND.  It's not a difficult tool to use, and very easily to script.  The second reason is somewhat related: I was unable to find the equivalent of $GENERATE macros to use with nsupdate.  This may be by design, but it's annoying.

A few workarounds for the above might be to move comments to TXT records and write scripts to emulate $GENERATE functionality that prepare a batch of nsupdate commands.  I suspect down the line I will eventually have to cave and move to a dynamic style of DNS zone maintenance, but it's not going to be today.

So, after deciding I was going to keep things manual, I created some scripts from scratch to handle ZSK rollover.  They run dnssec-keygen, dnssec-signzone, and reload BIND as needed.  I automated serial number generaton and initial DNSSEC key generation at the same time.  Long story short, this allows me to still edit the original zone files in my external view and have the signed copies be served up by BIND.  The copies of each zone are appended by the characters ".signed" and these zones are included in named.conf.local (yes, I'm using Debian GNU/Linux).  It's a little wasteful, because I have a shared SOA for all of my domains and my scripts re-sign all of my zones for any DNS change.  Although for my setup, it's not a big deal.

If you're curious what these scripts look like, check them out here.  Please keep in mind that these are very specific to my setup and if you decide to use them you'll essentially have to figure them out yourself and obviously change update-soa.sh to reflect what you want your SOA to look like.

Anyway, to get my DNSSEC setup live, I took the DS records (dsset-*) and had my registrars add them to the parents.  This is required so caches that have DNSSEC validation enabled will go ahead and actually perform validation.  The DS record authenticates the chain of trust from the parent down to the child zone.  So, com. has a DS record for prolixium.com. and uses it to validate that the DNSKEY for prolixium.com. is valid and can be used to check the RRSIG RRs for each record queried.  Here's how it looks:

% dig +short @a.gtld-servers.net. prolixium.com. DS
57876 7 1 5B9D902C4E4B15833369B7EED602370B3A525334

Now, this is sometimes when it gets hairy.  Since adding the DS key to the parent is the registrar's responsibility, they may or may not support it, or may only support it for a subset of their zones.  Even worse, some registrars may advertise support for DNSSEC but in actuality only support it when you use their nameservers as opposed to your own.  Because of this, make absolutely sure your registrar has an option in their interface for adding DS records beforehand.

As an aside, Go Daddy has excellent DNSSEC support, but unfortunately supports the evil that is SOPA (their latest flip-flopping should not distract you from the fact that they potentially helped write it and also got an exception from the shutdown clause).  I had most of my domains with Go Daddy but moved all but one to name.com and Joker.  name.com irrirated me because they only officially support DNSSEC for org., have no mention of DNSSEC in any of their knowledge base, and initially filed my support inquiry as spam.  Fortunately the DS records in the parents ended up staying put even after the transfer from Go Daddy, so I guess I'm set for now.  Joker supports DNSSEC for all of their domains that are signed.

After signing my zones, I used two web-based DNSSEC checking utilities to validate my configuration: DNSViz and the Verisign DNSSEC Debugger.

In conclusion, although signing zones the manual way ends up taking much longer and causes much more pain, it's a great way to learn DNSSEC!

New comments are currently disabled for this entry.