Deploy360 7 November 2015

DNSSEC Algorithm Roll-over

By Kevin MeynellFormer Senior Manager, Technical and Operational Engagement

ripelabs_128RIPE Labs have just published an interesting article about their experiences of rolling over the algorithm used to sign a DNSSEC zone. The RIPE NCC was one of the first organisations to sign its zones with DNSSEC which meant using RSA/SHA1 as this was the only defined algorithm at the time.

In recent years it’s been demonstrated that SHA1 has certain vulnerabilities which is why RFC 5072 standardised the use of SHA2, even though many validators did not support it at the time. Since then, SHA2 has has become better supported by validators, and this combined with the fact that the root zone is now signed with SHA2, was the reason for the RIPE NCC to roll over the ‘’ domain to the stronger algorithm.

This proved less than straightforward as firstly their original signer software could only sign the zone with either SHA1 or SHA2 but not both. A new version of the signer was therefore required, but after setting up a test system and introducing SHA2, it became apparent that BIND and Google DNS were able to validate the zone, whereas Unbound and Verisign DNS did not.

Further investigation traced this to the use of separate Zone Signing Keys (ZSKs) and Key Signing Keys (KSKs) and expectation of some validators that the algorithm signalled by the Delegation Signer (DS) record is used to sign all records in the zone. This is a more strict interpretation of RFC 6840, and whilst the latest version Unbound does now have an option to relax this validation requirement, implementors should be aware of this issue.

The recommendation of RIPE Labs is that the KSK and ZSK should be rolled at the same time, and the old ZSK should not be withdrawn until the KSK roll-over is complete. NLnet Labs have also published an article on rolling DNSSEC algorithms on OpenDNSSEC as the current version of OpenDNSSEC does not directly support this.


Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Improving Technical Security 15 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...

Improving Technical Security 14 March 2019

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...

Improving Technical Security 13 March 2019

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...