Before attempting an algorithm rollover, please read RFC 6781 “DNSSEC Operational Practices, Version 2”, section 4 carefully to understand the terminology, actions and timelines (TTL and RRSIG expiry) involved in changing DNSKEY algorithms.
This How To describes the “conservative” approach from the above mentioned RFC, as specified in section 4.1.4. Phases are named after the steps in the diagram in that section. The following instruction assume a KSK+ZSK setup; if you only have a CSK, ignore the ZSK steps.
After every change, use your favourite DNSSEC checker (DNSViz, VeriSign DNSSEC Analyzer, a validating resolver) to make sure no mistakes have crept in.
During this process, response sizes will be larger than usual, due to double sets of signatures, and double the amount of DNSKEYs. Please check that these bigger packets can make it out of your network without trouble, and verify that you and your secondaries can serve queries over TCP as well.
Warning
For every mutation to your zone (so, every step except updating DS in the parent), make sure that your serial is bumped, so your secondaries pick up the changes too.
If you are using AXFR replication, this usually is as simple as pdnsutil increase-serial example.com
In the initial situation, we have a KSK+ZSK with our old algorithm, and the parent zone contains a DS matching that KSK.
Assuming this situation has existed for a few days, or perhaps way longer, we can move on to the new RRSIGs phase without delay.
To create signatures with the new algorithm, without publishing keys, run something like:
pdnsutil add-zone-key example.com KSK active unpublished ecdsa384
pdnsutil add-zone-key example.com ZSK active unpublished ecdsa384
Note the key IDs that add-zone-key reports.
You can also retrieve these later with pdnsutil show-zone example.com.
After this, PowerDNS will sign all records in the zone with both the old and new ZSKs, and the DNSKEY set will be signed by both KSKs.
Please check that your secondaries also show the new signatures.
In the next step, we will publish the new keys. Once we do that, some validators will demand that those new keys also sign all records in the zone. However, those validators may still have records signed with only the old ZSK in cache. So, we need to wait for those records to expire.
In your zone, check for the highest TTL you can find. This includes the SOA TTL and the SOA MINIMUM, which affect negative caching, including NSEC/NSEC3 records. The DNSKEY TTL is also taken from the SOA MINIMUM.
Now, wait for that long. Depending on your setup, this will usually be between a few hours and a few days.
In the previous step, we generated two new keys, and signed our zone with them, without actually exposing validators to the new keys. After waiting for all records in our zone to expire from caches, we can publish the DNSKEYs:
pdnsutil publish-zone-key example.com 3
pdnsutil publish-zone-key example.com 4
Replace 3 and 4 with the key IDs gathered in the previous step, or find them in pdnsutil show-zone example.com.
PowerDNS will now publish the new DNSKEYs that have already been used for signing for a while.
The old DNSKEYs remain published, and active for signing, for now.
Please check that your secondaries now show both the old and new DNSKEYs when queried for them with dig DNSKEY example.com @....
Now that the new DNSKEYs are published, we again need to wait for caches to pick them up, before we switch DS records in the parent.
Check the DNSKEY TTL - then wait that long.
Our zone is currently fully signed with two algorithms, and keys for both algorithms are published. This means that a DS for either the old or new algorithm is sufficient for validation. We can now switch the DS - there is no need to have DSes for both algorithms in the parent zone.
Using pdnsutil show-zone example.com or pdnsutil export-zone-ds example.com, extract the new DNSKEYs or new DSes, depending on what the parent zone operator takes as input.
Note that these commands print DNSKEYs and/or DSes for both the old and the new algorithm.
Check the DS TTL at the parent, for example: dig DS example.com @c.gtld-servers.net for a delegation from .com.
Submit the new algorithm DNSKEY/DSes to the parent, and make sure to delete those for the old algorithm.
Check again with the parent to see whether the new DS is published.
Then, wait for as long as the TTL on the old DS was.
We are signing with two algorithms. The parent DS is pointing at the KSK for the new algorithm, and the old DS has expired from all caches. However, both sets of DNSKEYs are still in caches. It is time to remove the old DNSKEYs, while keeping their signature:
pdnsutil unpublish-zone-key example.com 1
pdnsutil unpublish-zone-key example.com 2
Replace 1 and 2 with the IDs of the old keys.
Please check that your secondaries now only show the new set of keys when queried with dig DNSKEY example.com @....
Over the next DNSKEY TTL seconds, validators can still have both sets of keys in cache. So, we leave our signatures in until that time passes.
After waiting DNSKEY TTL seconds, caches should only have a copy of our new set of keys. This means we can now safely stop signing with the old keys:
pdnsutil deactivate-zone-key example.com 1
pdnsutil deactivate-zone-key example.com 2
Alternatively, you can use remove-zone-key to remove all traces of the old keys.
In another hours-to-a-few-days, the old signatures will expire from caches.
Your algorithm roll is complete.