Categories
Deploy360 Domain Name System Security Extensions (DNSSEC)

DNSSEC Algorithm Roll-over

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 ‘ripe.net’ 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.

References