History

The RIPE NCC has been involved in DNSSEC for a long time. We had enabled validation back in 2005, and we were the second organisation to publish signed zones that same year. We began signing zones using some perl scripts, written by Olaf Kolkman, that wrapped BIND's dnssec-signzone tool. The key material was all stored on disk, on a regular Linux server. While access to the server was limited to very few staff, there was no strong security to keep the private key material safe.

The ZSK roll-overs were handled automatically with cron jobs, but the KSK roll-overs were done by hand every 6 months.

Manual work like that inevitably leads to human error, no matter how good the scripts are. Therefore in 2009, we decided to replace this collection of scripts and cron jobs with a solution that would automate most of the work, and provide more security for the key material. At that time, DNSSEC solutions were still immature. None of the well-known servers (such as BIND) had in-line signing capabilities, and we still needed dnssec-signzone. OpenDNSSEC was available, but integrating it with HSMs wasn't straightforward. So we chose Secure64's signing appliance. This is a hybrid solution that performs all operations in software, but the software runs on Secure64's hardened operating system, which in turn runs on hardware that has both an Itanium processor and a Trusted Platform Module (TPM) chip. The combination of these things provides a DNSSEC signer solution which can keep key material safe, and provide the kind of automation for signing and key roll-over that we were looking for.

Current Status

Our journey with the Secure64 signers has not been plain sailing. We had to deal with several bugs in the software, but this is inevitable with any software. Over the years we have added to and improved our monitoring. Secure64 has also patched many of the bugs, and the operational problems have mostly gone away. However, the hardware they're running on is quite old. If there's a failure, it's difficult to replace some of the components. We have also run into memory issues, whereby the memory gets fragmented to the point that the signer can't sign large zones, and the only solution is to reboot the signer.

This issue is even more serious because the signer doesn't emit any error messages about this. It fails silently, and we had to add even more monitoring to ensure that we would catch this problem before it caused operational issues.

We contacted our vendor to get quotes for replacement hardware and software licences. The cost for replacing our current signers is quite significant.

The Future

We feel that this is a good moment to think about our DNSSEC signing infrastructure. This is because signing software has come a long way since 2009, and there are several mature products available:

• OpenDNSSEC
• BIND
• PowerDNS
• Knot DNS

All of these products are well-supported and have strong communities around them. Additionally, they all support the PKCS#11 library, which interfaces with a number of hardware security modules (HSMs). All of these products can work as a bump-in-the-wire signer, by taking in an unsigned zone, signing it, and providing the signed zone via DNS XFR.

Safeguarding keys

In any cryptographic system, including DNSSEC, it is essential to safeguard private portions of keys. The security depends on the key remaining safe and only accessible to authorised entities for the purpose of generating signatures and hashes.

A common way to do this is to use HSMs. HSMs are designed to store keys and keep them safe from tampering or unauthorised access. They can also take plain text data, either encrypt it, or produce signatures or hashes.

Another way to do this is to generate and store keys on an encrypted disk on a regular Linux server. This allows building a simpler solution, without HSMs and the associated complexity. It's easy to backup keys, and move them between signers. It also has downsides, in that breach of the security of the server would also expose the private keys on it. A solution like this requires careful consideration of the pros and cons, and weighing them against our needs, as well as those of our community.

Signer infrastructure project

Over the coming months, we will be examining the various options available, to see whether we will continue with our current setup but with new hardware, or switch to a setup based on one of the open source products listed above, combined with either HSMs or keys on disk on a server.

Cryptech

A recent development in the HSM world is Cryptech. This is meant to be a fully open-source HSM design, so that anyone can build their own HSM from publicly available designs and open-source firmware. A first prototype has already been built and tested, and has been shown to work with OpenDNSSEC to generate keys and sign zones. This work is still at a very early stage, but we are keeping an eye on the project to see if we may be able to make use of this technology for our DNSSEC signing needs in the future.

This will be presented at the DNS WG session at RIPE 75. We'd love to get your feedback there. Or you can also leave a comment below.