2013/04/05

DNSSEC with BIND 9.9

I've been pleasantly surprised by this; BIND 9.9 has made enabling DNSSEC for a zone really easy. The only problem I hit along the way is that the defaults for dnssec-keygen aren't as secure as I'd like.

Create the key directory - in my case /var/named/dnssec/farnz.org.uk, and make it accessible to named. You will put keys in here, which will cause BIND to take your existing unsigned zone and maintain a signed copy for you.

Create your key signing keys (KSKs). I created two - one currently in use with dnssec-keygen -a 8 -b 2048 -fk -K /var/named/dnssec/farnz.org.uk farnz.org.uk, and one that's published but not in use created with dnssec-keygen -a 8 -b 2048 -fk -K -A none /var/named/dnssec/farnz.org.uk farnz.org.uk. The idea here is that the one that's published but not in use is signed with the KSK that's in use; when I roll over my KSK, anyone who's cached the old KSK will be able to verify the new KSK. There's thus no need to delay when rolling over the KSK - cached old versions are not a problem.

If you get this far, you should have BIND automatically signing your zone. You now need to obtain a DS record for your active KSK dnssec-dsfromkey -2 Kfarnz.org.uk.+008+52165.key changing the key name accordingly. Send this DS record to your parent zone - in my case, as the domain is hosted by AAISP, I added the DS record to their DNS management interface, and had them send it to Nominet.

At this point, your domain is signed and traceable to the root key - you can test it via DNSViz and DNSSEC Analyzer.

Rolling over the ZSK

Rolling over the ZSK should be a quick and simple process, as you don't need to communicate with other server operators. There are three steps:

Mark the old ZSK for inactivation and deletion in the future: dnssec-settime -I+1d -D+7d Kfarnz.org.uk.+008+12156.key

Tell BIND to catch up: rndc sign farnz.org.uk

The marks on the old ZSK do not tell BIND to delete it from disk; instead, when the old ZSK becomes inactive, it will no longer be used to sign RRSETs being returned to clients (so the time to inactivation should be longer than the ZSK's TTL), and when it's deleted, it will no longer be published in DNS at all.

Rolling over the KSK

This is more involved, because it needs co-operation with your parent zone: