DNSSEC Key Rollover Calculator
Plan DNSSEC KSK, ZSK, and combined key rollovers with DNSKEY TTL, DS TTL, parent publication delay, prepublish time, signature validity, resign interval, zone count, and resolver cache buffer.
Wait for new DS publication, DS TTL, DNSKEY TTL, and resolver cache buffer before retiring the old KSK.
Prepublish the new ZSK, sign with it, then keep the old ZSK until DNSKEY caches and old signatures age out.
Short signature validity can make a rollover urgent; long validity can leave old signatures visible longer.
Zone count, batch size, and gap estimate the final zone retirement date for staged home lab or hosted DNS fleets.
| Phase | KSK double-DS timing | ZSK prepublish timing | Retire condition |
|---|---|---|---|
| Publish new key | Add new KSK DNSKEY while old DS remains valid. | Add new ZSK DNSKEY before signing with it. | Authoritative servers must all serve the new DNSKEY. |
| Parent or cache wait | Wait parent publish delay plus parent DS TTL. | Wait at least DNSKEY TTL plus resolver buffer. | Validators can build a valid chain using cached or fresh data. |
| Activate signing | Move DS trust to the new KSK once visible. | Generate RRSIGs with the new ZSK. | New signatures validate across multiple resolvers. |
| Retire old key | Remove old DS first, then old KSK after DS and DNSKEY caches expire. | Remove old ZSK after old signatures and DNSKEY RRsets are no longer needed. | Old key is absent from validation paths and caches are exhausted. |
| Input | Conservative use | Typical range | Failure if underestimated |
|---|---|---|---|
| DNSKEY TTL | Minimum cache wait for key RRset changes. | 1 hour to 2 days | Resolvers may miss the key needed for validation. |
| DS TTL | Parent-side wait after DS changes. | 1 day to 3 days | Validators may follow an old DS to a removed KSK. |
| Parent publish delay | Registrar, registry, and CDS processing delay. | Minutes to 7 days | New DS may not exist when the old trust path is removed. |
| Resolver buffer | Extra hold time for stale caches and monitoring lag. | 6 hours to 3 days | Edge resolvers can serve old trust data longer than expected. |
| Scenario | Suggested overlap | Risk driver | Operational note |
|---|---|---|---|
| Single ZSK rollover | 2 to 7 days | DNSKEY TTL and old RRSIGs | Check all authoritative nodes before activation. |
| KSK registrar rollover | 7 to 21 days | Parent DS delay and DS TTL | Confirm parent DS from outside your network. |
| Algorithm rollover | 14 to 45 days | Dual algorithm validation | Keep both algorithms until validators accept the new one. |
| Multi-signer migration | 14 to 30 days | Shared DNSKEY and provider sync | Both signers must publish compatible DNSKEY RRsets. |
Small DNSKEY and RRSIG records reduce UDP fragmentation risk during overlap.
Very small signatures, but confirm registrar, parent, and validator support before switching.
Compatible and familiar, but larger DNSKEY RRsets make overlap responses heavier.
Longer keys increase DNSKEY answer size and may justify extra resolver buffer.
| Rollover type | New key state | Old key state | Important check |
|---|---|---|---|
| ZSK prepublish | Published, then active for new RRSIGs. | Kept until old signatures and DNSKEY caches age out. | Validate signed RRsets with public recursive resolvers. |
| KSK double-DS | Published and matched by new parent DS. | Kept until old DS and DNSKEY caches age out. | Query parent zone for both DS states during transition. |
| Double-RRset KSK | New DNSKEY signs DNSKEY RRset before DS switch. | Old DNSKEY signs until trust path moves. | Confirm DNSKEY RRset validates through both KSKs. |
| Algorithm rollover | New algorithm signs required RRsets. | Old algorithm remains until new chain is trusted. | Do not remove old algorithm before all DS and DNSKEY caches clear. |
| Multi-signer | Both providers publish synchronized key material. | Old signer remains authoritative through migration. | Check every nameserver returns consistent DNSKEY and RRSIG data. |
DNSSEC destroys trust on ‘net when you turn over a new key. You need to do it; rotating keys is a necessary evil for security. But it means breaking the chain of validation for everyone trying to reach your site while you turn the key. If you misjudge it too much, nobody can see your site again for a while. They won’t be able to until caches time out and all the validating server finally give up looking for signatures that don’t exist anymore.
It’s not really about crypto, so much as it is about patience. Once you type in your parent delay and TTLs the calculator will figure out the math for you so you know for sure: yes, two days should of be enough time for my slow-ass registrar to propogate the change. We all think we’re waiting on our own servers to update, but really we’re waiting for everyone else’s updates to propagate around Internet.
Why You Must Be Patient When Changing Keys
Rolling over a Zone Signing Key seems like it should be easy enough. It happens completely inside your zone. Publish new key and start using it to sign things. Then, just wait until old signatures has expired. Except you can’t instantly remove the old key once the new one has been published.
DNSKEY records gets cached aggressively by resolvers. Maybe yours has a TTL of twelve hours. But recursive server in Tokyo could have cached your record for days afterward. If you remove the old key before the caches clear, there will be a validation gap. The validator looks at a response signed by Key A while its cache contains only Key B, which was removed long ago. An insecure response follows.
It is a small point but worth noting. A third party is typically involved: your TLD registry. There’s nothing you can do about the delay between when you upload new DS record and when parent zone publishes it. Registrars range from instant (using CDS protocols) to three business days. The parent delay is included in the safe retirement window in the calculator, so you don’t pull down the old KSK before everyone sees the new trust anchor everywhere.
That’s the critical path. The DS record must be published to your ISP’s recursive resolvers and root hints first. If that hasn’t happened, your locally cached dnskey ttl doesn’t matter. Wait for slowest link in the chain.
In addition, running two parallel validation chains on the road to algorithm changeover are even slower, since you need to wait until each validator has signed off on the new method. This is like changing lanes while driving, until you’re completely over the line, you’re straddling both. When you have thousands of zones, this isn’t just a crypto problem but also a logistics one. You can’t simply roll them all at once or else you’ll get slammed with huge numbers of failed resolutions. By staggering it into batches, you spread out the workload and can identify errors early. And tool helps account for those batch gaps so you can plan out exactly when your final zone will be safe to retire its old keys.
None of this leaves you free to assume that if your resolver doesn’t say it’s broken then nothing’s wrong. Half the planet could be seeing insecure responses while yours thinks its local cache is fine. Keep an eye out using external probes and other public validation tools; make sure the chain of trust isn’t broken at any step in the process. Be aware also that introducing a new key during overlap will cause the answer set to grow larger, so watch out for response sizes. Adding large RSA keys may bloat payloads until they fall back to TCP. That’ll slow down resolution even more, with risk of timeout errors as well. It’s a small friction but it adds up fast.
You don’t rush it because that’s not the point. You’re removing friction. You respect the hidden clocks ticking away on every server around the world. You livig in your own zone, but you aren’t the internet. By accounting for that overlap exactly, when you ultimately drop the old key everyone has their hand on something they can verify. The trust isn’t broken. The site isn’t compromised. Not a single user even knows the switch occur.
