You are here: Home > Publications > RIPE Labs > Anand Buddhdev > The Future of DNSSEC at the RIPE NCC

The Future of DNSSEC at the RIPE NCC

Anand Buddhdev — 23 Oct 2017
DNSSEC signing solutions and products have evolved greatly since we first began signing our zones. We are now exploring ways of doing it better and smarter.

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:

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.

7 Comments

Roland van Rijswijk says:
24 Oct, 2017 10:22 AM
Any plans to support CDS/CDNSKEY? I would sign SURFnet's reverse DNS zones if RIPE would support this ;-)
Anand Buddhdev says:
24 Oct, 2017 12:54 PM
Hi Roland. We don't have plans for CDS/CDNSKEY at the moment. However, if we hear otherwise from the community, and more people would like the RIPE NCC to support it, then we would certainly look at implementing it for the reverse DNS zones.
Tony Finch says:
24 Oct, 2017 01:43 PM
Yes, I would really like CDS/CDNSKEY support :-)

I wrote dnssec-cds so that I could support it for our delegated zones, and it would be really handy for them if they could also use CDS/CDNSKEY for their PI address space.

(dnssec-cds is mentioned in the BIND 9.12 release notes https://deepthought.isc.org/[…]/BIND-9.12.0b1-Release-Notes.html and the man page is at https://ftp.isc.org/[…]/man.dnssec-cds.html)
Arsen Stasic says:
24 Oct, 2017 02:59 PM
@Tony Finch: is your dnssec-cds somewhere available?
Tony Finch says:
25 Oct, 2017 12:08 PM
Yes! dnssec-cds is part of the BIND 9.12.0b1 release
Shane Kerr says:
24 Oct, 2017 03:34 PM
Note that Jaromír Talíř will be giving a presentation about CDNSKEY in Knot DNS and the FRED registry tomorrow at the DNS working group at RIPE 75.
Marc Groeneweg says:
24 Oct, 2017 03:52 PM
We are quite happy with our OpenDNSSEC implementation. We are now running an active/passive setup in combination with HSM's, which can be configured in a HA modus. That way, horizontal scaling is possible to get extra signing power. OpenDNSSEC will evolve in a more mature platform, supporting fast zone updates and out-of-the-box HA configuration. Still, our signing environment uses traditional RSA signing. Please check the specifications of HSMs in support for other algorithms like Elliptic Curve.

Cryptech for sure is an interesting development, but is still in development, and is of yet not available in a HA setup.
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.