Making DNSSEC More Accessible

I have previously written about DNSSECs “failure”. I tried to draw attention to the absence of simple documentation for implementing DNSSEC properly using simple tools. The steps to implement it are not that difficult, but without proper tools and documentation, nobody is going to find out. My previous post became subject of heated debates, and I have also been invited by NLNetLabs to discuss how we can improve the situation. The post below is meant to shed some light on the matter.

First of all, I’m going to follow the best practices as outlined in RFC6781, where they recommend using a Key Signing Key and a Zone Signing Key (unless you are in a very specific situation and you don’t need this tutorial). The tutorial below describes the steps needed to start using a DNSSEC enabled zone, which can all be done using the ldns toolchain.

_Caveat emptor: _This is not a complete tutorial, since I have not completely figured out yet how to do key rollovers using this toolchain. This is also why I have not implemented DNSSEC for this zone.

Step 1: Generating Keys

The first step is to generate the two keys for your zone. This is not too difficult:

Above I am using the RSASHA256 algorithm with 1024 bits for each key, which according to the RFC should be secure enough. The first commands generates a regular key which is used as the Zone Signing Key (ZSK), the second command uses the -k tag to generate a Key Signing Key (KSK).

The DS file of the KSK is the information that you give to your registrar to create the secure entry point for your domain. So make sure you note the ID of that key so that you do not get confused.

Step 2: Signing and activating the zone

To manage everything properly, it is best to keep separate zone files in separate directories. This also makes it easiest to secure access. So we copy the zone file into the same directory and issue the magic command to sign the zone.

Then we end up with a signed copy of the zone, this has the same information as the original zone, but also includes the DNSKEY, RRSIG and NSEC records. To activate this zone, configure your DNS server software to use the signed version of the zone file (1sand0s.nl.zone.signed) and reload it (make sure it uses the new zone file).

Step 3: Resign the zone every month

By default these RRSIG records have a limited lifetime which by default is 28 days. Once this period is over, these results are no longer considered valid. To prevent this you have to resign the zone (this can be done using the same keys). So you preferably resign your zone every three weeks. You do have to update the serial to tell other servers about the update (this is a planned feature of ldns-signzone). So, you could create a short script that did something like the following.

To check the exact deadline for your RRSIG records you can use the ldns-rrsig utility.

To be continued

The above are some simple steps to get started with a secure zone using the ldns toolchain. The keys are valid forever by default. You should however plan for the eventuality when keys are compromised. A roll-over process in DNS is difficult because of all the distributed caches. The RFC has several different methods with which to do this, and I have yet to figure out exactly how that can be done using the ldns tools.