Introduction

When we introduced DNSSEC to all our zones back in 2005, we did this using some home-grown perl scripts. In 2009, we switched from these perl scripts to a signer product developed by a company called Secure64. This is a dedicated signer solution that runs on Secure64's SourceT operating system, on HP servers with Itanium processors. We chose this solution because at that time, there were very few options. About the only other solution was OpenDNSSEC, but it was in its infancy, and needed a lot of work to deploy it properly. The Secure64 product offered us a relatively simple solution while providing quite a reasonable level of security.

Our signer servers are old and no longer have hardware support, so we needed to replace them. This also meant that we would need additional licences for the signer product. We got quotes for new server hardware and additional licences, and found it to be quite expensive. This got us thinking about alternatives. Since 2009, the DNSSEC signer scene has improved a lot. There are several solutions available, so we thought it was a good time to look at them.

Requirements

We wrote down our requirements, as well as a list of nice-to-haves:

Musts

• Support bump-in-the-wire signing: the signer should be able to XFR zones in (from our provisioning server), sign them, and XFR the signed zones out (to our distribution servers)
• Support for modern algorithms and ease of algorithm rollover
• Automated ZSK and KSK rollovers
• Safety during KSK rollovers (the signer should not make any assumptions about when it is safe to complete a KSK roll-over)
• Clear and verbose logging
• Import foreign ZSKs: the signer must be able to import and publish ZSKs from another signer, to allow for a seamless migration.

Nice-to-have

• Options for key roll timing and policy management
• Key storage options: support for HSMs for key storage, as well as offline KSK storage
• Ease of automation
• Ease of monitoring
• Ease of migration to another signer: would it be possible to migrate to another signer in future?
• Possibility of having a redundant setup: The old setup consisted of 2 signers for redundancy purposes, so it would be good to have the same, or a similar setup
• Good quality documentation
• Simple configuration file format
• Import foreign KSKs: this would allow switching to a new signer without having to do a KSK roll-over.

Evaluation and selection

We evaluated 5 different solutions, testing them against the above criteria. They all met our requirements, so in theory, they could all be used as a replacement for the current signers, but they are considerably different when it comes to the "nice-to-haves".

BIND (9.12.2)

BIND has an excellent documentation dedicated to DNSSEC and it has tools for key and policy management. The main downside of BIND is key creation. The keys have to be created manually, when a new zone is created or when rolling keys. The other downside is logging. The logs show a zone has been signed and also shows the changes in SOA serial numbers, but no details about keys and their states is logged.

PowerDNS authority (4.1.4)

The signer configuration involves editing the config file, updating databases and running command-line tools. PowerDNS doesn't roll any keys by itself; the operator has to run commands to roll keys. Its DNSSEC-related logging is also a bit terse.

OpenDNSSEC (2.1.3)

It is a powerful signer with extensive key and policy management capabilities. However, its documentation is outdated and incomplete. Its configuration has to be maintained in XML, which isn't very human-friendly. OpenDNSSEC also requires an HSM of some kind, so at the very least, one has to also install SoftHSM along with it, if one wants to keep keys on disk.

Knot DNS (2.7.2) 

We like Knot DNS for its simple and readable configuration, the helpful key management tool, and last but not least, for being a good fit for automation. Unlike the other signers we tested, the entire configuration can go to the config file, without needing to run command-line tools. However, for tasks like KSK rollover, which we prefer to be performed by hand, manual configuration is a possibility.

New Secure64 signer (based on Knot DNS)

Secure64 has developed a new signer solution, which is basically Knot DNS running on a modified CentOS 7 distribution. It works the same way as the stock Knot DNS running on regular CentOS 7.

Our choice of signer

We settled on standard Knot DNS for our signing solution, to replace the old Secure64 signers. We already use Knot DNS in the K-root anycast cluster, as well as our reverse DNS cluster. We are quite familiar with its configuration, logging and capabilities, and we have found the support from CZ.NIC to be really good. It meets all the requirements, as well as all the nice-to-haves. Its documentation is superb and up-to-date. It's easy to configure and run, and has very clear and good logging. Its pace of development is also rapid, such that soon it will also have features such as offline KSK support.

Key storage

The private keys for DNSSEC signing must be stored safely. It is common to use a hardware security module (HSM) for this. However, this is not the only way to store keys safely. Keys can be generated and stored on encrypted disks, and if access to a server is restricted and limited to only certain functions, then it is acceptable to use such a setup. Last year, when we blogged about migrating our signers, we asked our community about this, and many in our community came forward to tell us that use of an HSM might actually be overkill. We have therefore decided to keep our setup simple, by adopting a design that uses a regular Linux server running Knot DNS, with keys on an encrypted disk partition. This will be coupled with stringent access and security policies to keep the keys safe.

Migration plan

Two new servers

We are going to deploy two new signers, running on dedicated hardware, and running Linux. Access to these signers will be highly restricted, and limited to authorised staff. These servers will run Knot DNS, and will be configured with all our zones as slave zones, getting their zone data from our provisioning server. Knot DNS will generate KSKs and ZSKs for all the zones as needed. The key signing key (KSK) and zone signing key (ZSK) sizes will be the same as on the current Secure64 signers. The zones will be signed with the same algorithm (RSA/SHA256) as on our current signers.

KSK roll-over

Our old Secure64 signers do not export their private keys. This means that in order to migrate to the new signers, we will have to perform a KSK roll-over. Therefore, we will pre-publish DS records of KSKs from our new signers.

ZSK roll-over

ZSKs are easier to deal with. We don't need access to the private components of the ZSKs. Instead, we just need to import the ZSKs from the new signer into the old one, and from the old one into the new one. This allows both old and new signers to sign the DNSKEY RRset with their own KSKs. Once this is done, we can switch from the old signer to the new one at any time. Validating resolvers will see signatures in the zone made using either the old ZSK or the new ZSK, and they trust either ZSK because they will have been signed by the old KSK or the new KSK, for which there are matching DS records in the parent zone.

We can switch between the old signer and new signer at any time, and even go back to the old signer in case we face any issues during the migration. This setup will allow us a safe and dependable migration path, with no need to rush anything. We can also switch zones individually from the old signer to the new one, so there is also no need to have a flag day for it. The migration can happen seamlessly and without anyone noticing, as it should.