Hello World.

Setting up OpenDNSSEC on Debian sid

As the previous post described how to do fancy DNS setups with BIND and OpenDNSSEC, this post will cover the missing part: setting up OpenDNSSEC. I’ll describe how to install OpenDNSSEC (1: in combination with SoftHSM2 (2.0.0-2) on Debian sid (as of today, 2016-01-03). It’s more like a reference for my future self, but I think it’s worth sharing.

First we have to install the necessary packages of course. In our case these are (replace mysql with sqlite3 if you want to use SQLite instead of MySQL/MariaDB):

apt install opendnssec opendnssec-enforcer-mysql softhsm2

Next we take a look at the new configuration files in /etc/opendnssec and /etc/softhsm and customize them as needed.

/etc/opendnssec/conf.xml is the general configuration file for OpenDNSSEC which needs quite some changes. For details, check the OpenDNSSEC documentation on conf.xml.

  • <Repository name="SoftHSM">: Uncomment this section and change the path in <Module> to /usr/lib/x86_64-linux-gnu/softhsm/libsofthsm2.so. 1234 is fine as PIN, you can change it, but remember to use the same PIN when initializing SoftHSM later.

  • <Enforcer>:

    • Uncomment the <Privileges> section so that it properly drops privileges. Using the opendnssec user and group is fine.

    • <Datastore>: If you want to use SQLite, keep it as is, for MySQL change it like this:

  • <Signer>:

    • Same thing as for <Enforcer>: uncomment the <Privileges> section.
    • <WorkerThreads> and <SignerThreads>: The default value of 4 should be fine if you run OpenDNSSEC on any decent hardware, if you run it in a small VM, you can reduce it, if you have more cores and have to sign lots of zones with many records, you can increase it.

/etc/opendnssec/kasp.xml defines the Key and Signature Policy, actually it defines multiple KASPs. By default you will find the two policies default and lab in there. default is mostly fine for normal use, lab can be used for playing in non-production zones as it has pretty short signature lifetimes and fast key rollovers. There are some parameters you might want to take a look at, for everything else check the OpenDNSSEC documentation on kasp.xml:

  • <Refresh>P3D</Refresh>: This is the remaining time for which all signatures will be valid. It’s also the amount of time you have to fix your DNSSEC in case anything breaks. So you might want to increase it.
  • <KSK> (Key Signing Key): The default parameters of a 2048 bit RSA key with SHA256 hashes and a rollover period of one year are good. You can change the algorithm to 10 (RSA-SHA512) if you like. That doesn’t increase the signature size, but also doesn’t improve security.
  • <ZSK> (Zone Signing Key): This is where the weak part of DNSSEC comes in. 1024 bit RSA keys are pretty often used as ZSK as it keeps the signature sizes small (many zones including the root ., de, eu and others use 1024 bit RSA as ZSK). On the other hand, that key size isn’t considered really secure any more. It’s not completely broken yet, but that may change soon. So you may either want to increase the key size to 2048 bits or decrease the rollover period to something like one month. Sadly OpenDNSSEC does not support any Elliptic Curve Cryptography, so using these algorithms is not an option at the moment. Support is planned for some future 2.x release.

/etc/opendnssec/zonelist.xml will be automatically updated when adding/removing zones with ods-ksmutil so there’s no need to touch that file.

/etc/opendnssec/addns.xml Is only used for doing zone transfers and is not needed for basic operation. If you want to see it in action, take a look at the previous post where it is used for tranfers from and to BIND.

/etc/softhsm/softhsm2.conf is the configuration file for SoftHSM2 and basically defines where your private keys are stored. The default value of /var/lib/softhsm/tokens/ should be fine for most cases. That directory does not exist by default and I like to create it using permissions similar to /tmp (+t), but making it only group-writable for the group softhsm. The following two commands add the user opendnssec to the group softhsm and create the directory /var/lib/softhsm/tokens with the appropriate permissions:

adduser opendnssec softhsm
install -d -m 3770 -g softhsm /var/lib/softhsm/tokens

Next we can initialize the SoftHSM. We run this command as the user opendnssec as this is the user that will use it later (when promted for the PINs, enter 1234 or the value you defined in conf.xml):

sudo -u opendnssec softhsm2-util --init-token --slot 0 --label OpenDNSSEC

Now we are ready to initialize the database of OpenDNSSEC and start it all up:

ods-ksmutil setup
systemctl start opendnssec-signer
systemctl start opendnssec-enforcer

And finally we can add a zone to OpenDNSSEC using the follwing command:

ods-ksmutil zone add --zone dnssec.example

This will expect an unsigned zone file in /var/lib/opendnssec/unsigned/dnssec.example. You can use the following minimal zone for testing:

$TTL 3600

@       IN    SOA    ns hostmaster 1 10800 1800 3600000 3600
        NS    ns

Now we can force OpenDNSSEC to immediately sign our new zone using this command (sometimes it’s necessary to run ods-ksmutil update zonelist before):

ods-signer sign dnssec.example

This will create a signed zone in /var/lib/opendnssec/unsigned/dnssec.example which you can load into your nameserver.

You can export the public key to send it to your registrar so that it gets published in the parent zone using the following command:

ods-ksmutil key export -z dnssec.example

In case you need a DS record, you can append the parameter --ds. If you run the command shortly after creating the zone, you won’t see any key as OpenDNSSEC does some magic to only show the key when it’s safe to publish it. If you run ods-ksmutil key list, you’ll see that the key is in the publish state and when it will transition to the ready state. This is important for KSK rollovers, but not that much if you just created the zone. To override this behavior, append the parameter --keystate publish.

But before you deploy this in production, it might be a good idea to read a bit more of the OpenDNSSEC documentation and think about stuff like backing up your keys.