Understand what must remain valid
DNSSEC helps resolvers verify that DNS answers come from the expected zone and have not been altered. A rollover replaces a DNSSEC signing key without interrupting that verification. The main risk is a mismatch: a resolver may have cached an older key or signature while the authoritative zone or its parent has already moved to newer records. A validating resolver can then reject answers even though the domain’s web or mail servers are working.
Most signed zones use a zone-signing key (ZSK) to sign ordinary DNS records and a key-signing key (KSK) to sign the DNSKEY set. The parent zone publishes a DS record that links to the child zone’s KSK. Some providers use a simpler key arrangement, so check your provider’s documentation rather than assuming you can manage two separate keys. In every arrangement, the goal is the same: preserve a verifiable path from the parent’s DS record through the child’s DNSKEY records to the signed answers.
Prepare a cache-aware rollover plan
Before changing anything, identify who controls each part of the chain. Your DNS host may generate keys and signatures, while your registrar may submit DS records to the parent zone. Record the currently published DNSKEY and DS values, the relevant DNSKEY and DS time-to-live (TTL) values, and how long your provider keeps old signatures available. Save public record values for comparison, but do not copy private signing keys into tickets, screenshots, or shared notes.
Plan separate stages for adding the new key, confirming that resolvers can see it, switching signing or parent references, and removing the old key. Allow time between stages for cached data to age out; the applicable TTLs and your provider’s signing schedule matter more than a fixed number of hours. If your provider automates rollovers, learn which stages it handles and which, if any, require a registrar change. Avoid combining a key rollover with a DNS provider migration or an algorithm change unless you have a specific plan for that added complexity.
Stage ZSK and KSK changes differently
For a ZSK rollover, a common approach is to publish the new ZSK in the DNSKEY set before relying on signatures made with it. Keep the old key and the signatures needed to validate cached answers during the transition. Once the new key is widely available and answers signed with it validate, wait for old cached signatures and DNSKEY sets to expire before removing the old ZSK. Your DNS software may use pre-publication, double-signing, or another supported method; follow its sequence rather than mixing steps from different methods.
A KSK rollover also involves the parent zone’s DS record. Publish the new KSK in the child zone and ensure the DNSKEY set is signed as required by your rollover method. Coordinate the new DS submission with the registrar, then verify what the parent actually publishes. Do not remove the old KSK or old DS merely because the registrar accepted an update: validating resolvers may still have cached the old DS or DNSKEY set. Maintain a working path for both old and new cached data until the relevant caches have had time to clear.
Validate each stage, not just the final state
After each change, check the authoritative records and test the domain through more than one validating resolver. Compare the DNSKEY records served by the child with the DS records served by the parent, and confirm that ordinary records validate as well. Check names used for the website and email, such as the apex domain, www, and mail-related hostnames. A successful lookup from a non-validating resolver is not enough: it can return an answer that a validating resolver would reject.
Watch for validation failures as well as ordinary reachability failures. If validation breaks, pause the rollover and compare the records currently published at the parent and child before making another change. Where your provider supports it, restoring a previously valid overlap may be safer than immediately deleting more records. Keep enough time before signature expiration to investigate; replacing keys does not help if the signatures required by the planned sequence have already expired.
Finish only after the old path is no longer needed
Removing old keys and DS records is the last stage, not the first cleanup task. Confirm that the new chain validates, the parent publishes the intended DS record, and the longest relevant cache window for the old records has passed. Then remove obsolete material according to your provider’s procedure and test validation again.
Keep a brief record of what changed, who made each change, and which checks passed. That record makes a later rollover easier to plan and helps distinguish a DNSSEC problem from an unrelated DNS or service outage. A careful rollover is less about changing keys quickly than about giving every resolver a valid way to verify answers throughout the transition.
