A DNSSEC rollover changes information that validating resolvers may have cached at different times. Removing a key or updating a DS record too early can cause SERVFAIL even while the application servers are healthy. This guide explains routine KSK/ZSK renewal, parent DS coordination, verification and automation. The objective is to preserve a usable chain of trust throughout the transition; no sequence is a guarantee of zero downtime.
The detailed routine procedures below assume a signed child zone, a parent DS delegation, separate KSK and ZSK roles, and no change of signing algorithm. A combined signing key, a direct trust anchor, an algorithm migration or a multi-signer deployment needs the corresponding procedure. Start by inventorying the current DNSKEY and DS sets, signatures, timing policy and the authority responsible for parent changes.
KSK, ZSK and the Parent DS Relationship
In a common split-key model, the ZSK signs zone data and the KSK signs the DNSKEY RRset. A combined signing key, or CSK, can perform both roles. The DS record is published in the parent zone and identifies a child DNSKEY using its key tag, algorithm and digest. The parent is often a TLD for a registered domain, but a delegated subdomain can have another parent. Validation requires the appropriate keys, signatures and delegation chain, not merely the presence of a DNSKEY record.
A normal same-algorithm ZSK rollover under an unchanged KSK does not require a parent DS change. A KSK or CSK rollover changes the key used by the delegation and therefore requires appropriate parent coordination. Do not assume the child operator can edit the parent’s TTL or control its publication delay. Identify the registrar, registry or other parent operator involved, and measure the actual published DS RRset rather than relying on a dashboard confirmation.
Key and signature overlap allows old and new cached views to remain compatible when used with the timing rules of a specific method. Pre-publication and double-signature ZSK rollover are alternatives; neither makes the other universally mandatory. TLS certificate transitions are a different protocol and do not supply DNSSEC timing rules. The related guide to serving dual ECDSA + RSA certificates on Nginx and Apache concerns that separate certificate layer, not a procedure for changing parent DS records.
Timing: DNSKEY, Data Signatures and Parent DS
Record at least four timing inputs: the previously served DNSKEY TTL, the maximum TTL of relevant old-signed zone data, RRSIG inception/expiration and refresh policy, and the previously served parent DS TTL. Include denial-of-existence data such as NSEC/NSEC3 and the SOA values affecting negative caches. Authoritative publication delays are additional inputs. Your provider may control some or all of these settings. Keep clocks correct and signatures valid throughout the transition; a TTL is a cache lifetime, while signature expiration is a cryptographic validity limit.
For the pre-publication ZSK procedure used here, publish the new key first, wait for old DNSKEY caches, then replace data signatures while retaining the old public key. For the staged KSK procedure, publish both KSKs and their DNSKEY signatures, then coordinate old/new DS overlap at the parent. These are explicit chosen procedures. The KSK sequence uses overlap of both RRsets; it should not be confused with the pure Double-DS method that starts by publishing a new DS.
Start each cache-wait interval after the relevant change is present on every authoritative server, using the value served before the change. Reducing a TTL now does not shorten entries already cached under the old value. Queries from several resolvers help observe the transition but do not enumerate all caches. If a wider migration also changes apex routing, keep those changes separately reviewable; the guide to CNAME at the apex and ANAME/ALIAS covers that distinct DNS configuration problem.
ZSK Rollover: Pre-Publication and Signature Retirement
Pre-publication avoids the need to sign every data RRset with both ZSKs at once. Generate the new key and publish its public DNSKEY alongside the old one, keeping the DNSKEY RRset correctly signed by the existing KSK. Continue serving valid data signatures from the old ZSK during this preparation. Confirm the new DNSKEY set on all authoritative servers before starting the next waiting interval.
Wait at least the previously served DNSKEY TTL after that authoritative publication is complete, with the operational margin defined by your signer’s policy. Only then switch data signing to the new ZSK. An alternative double-signature procedure introduces both the new key and additional signatures while retaining the old key and signatures, then waits for the necessary caches before retirement. Choose a documented method and its timing calculation; do not combine partial instructions from different methods.
In the pre-publication procedure, stop creating old-key data signatures but retain the old ZSK in DNSKEY. Wait until all authoritative servers have stopped serving data signatures that depend on it, then allow the maximum TTL of the previously served relevant data to expire. Monitor signature validity and refresh throughout. Once cached old-signed data no longer depends on the old key, remove that ZSK from DNSKEY and validate again. Stopping signing and deleting the public key are separate events.
A signing service and a key lifecycle manager are not necessarily the same feature. In current BIND, dnssec-policy manages key lifetimes and transitions; inline-signing alone does not define a rollover policy. Check the active policy, DNSKEY TTL, signature timing and the mechanism used to acknowledge parent DS publication. Knot and PowerDNS have their own operational models. Do not infer identical automatic rollover behavior from the fact that a product can sign a zone.
For example, a resolver may still hold an RRset signed only by the old ZSK when it fetches a newer DNSKEY set. If that set no longer contains the old key, validation can fail. Retaining the old public key until those cached dependencies age out prevents this mismatch in the chosen procedure. This is an illustrative failure mode, not a report of a customer incident or a measured migration outcome.
KSK Rollover with Staged DNSKEY and DS Overlap
The following same-algorithm approach retains both KSKs and DNSKEY signatures, and temporarily both parent DS entries. It requires a parent that supports the intended multiple-DS set. It is a staged overlap of both RRsets, not the pure Double-DS sequence described in key-timing references. If only one DS can be published, use a supported documented method such as Double-KSK instead of improvising an add/remove sequence.
First, publish the new KSK alongside the current one and sign the DNSKEY RRset with both. Keep the old DS unchanged. Confirm that every child authoritative server serves both keys and valid DNSKEY signatures. Wait at least the previously served DNSKEY TTL from the completion of that publication before changing the parent. Seeing the new key at one server or in one recursive answer is not enough to establish this condition.
Next, add the DS for the new KSK while retaining the old DS. Check the signer-generated key tag, signing algorithm, digest type and digest against the intended published DNSKEY. Query the parent’s authoritative servers for the actual DS set. CDS/CDNSKEY can request the change only where the parent supports and validates that mechanism. For this overlap procedure, the requested DS set must preserve the old entry as well as include the new one.
After every parent authoritative server serves both DS entries, wait at least the previously served DS TTL before removing the old DS. Verify the new DS/KSK validation path first. Once all parent servers publish the new-only set, wait another interval covering the previously served DS TTL. Keep both KSKs and their DNSKEY signatures valid through that second interval. Then retire the old KSK and its signature, and validate the final chain. The parent wait is separate from the child DNSKEY wait.
A provider migration can require a multi-signer procedure, which is not simply this KSK sequence repeated twice. RFC 8901 describes models with a shared KSK or independent provider KSKs. Other signers’ ZSKs must be available in the appropriate authenticated DNSKEY sets; parent DS and delegation changes must also be coordinated. Ordinary primary/secondary replication does not establish that capability. Use the exact supported model and its propagation/caching plan before serving signed answers from both providers.
An algorithm migration is a separate operation. RFC 6781’s conservative sequence first adds new-algorithm data signatures while retaining the old ones, waits for old data/signature caches, then publishes the new DNSKEYs with the required DNSKEY signatures. After DNSKEY caches expire, update the parent DS. After old DS caches expire, remove the old-algorithm keys; only after old DNSKEY caches expire remove the remaining old-algorithm signatures. Account for authoritative publication at each step and validate the signer’s supported algorithm-rollover policy; simply publishing new keys before their data signatures is not this procedure.
CDS/CDNSKEY and Parent Automation
CDS and CDNSKEY let a child zone signal the DS set it wants the parent to publish. They are not a universal registrar feature or an instruction that takes effect immediately. The parent must support a polling or submission process and apply its authentication and continuity rules. Confirm which record type it consumes, what approvals or observations it requires, and how publication is reported. Manual DS changes and automated signaling must agree about the intended final set.
For the staged overlap here, prepare and validate the new KSK and DNSKEY signatures before signaling a DS addition; retain the old requested DS while the procedure needs it. Observe the parent’s actual records and use the same DS waiting intervals as for a manual change. Absence of CDS/CDNSKEY is not a request to delete DS. Do not routinely remove signaling records after a rollover without checking the ongoing policy; they may be how future changes are managed.
A documented parent API or supported CDS/CDNSKEY process can reduce copying errors, but it does not eliminate cache timing or authentication requirements. Rehearse the expected inputs and published results in a test zone before production. The guide to automating DNS changes with Terraform and Cloudflare covers reviewable infrastructure changes. Treat successful API responses as one piece of evidence and authoritative DNS publication as another; only proceed when the rollover’s actual state and waiting conditions are satisfied.
Verifying Publication and DNSSEC Validation
Use separate checks for publication, cryptographic validation and application behavior. A DNS query that requests DNSSEC records does not automatically validate them. For example, dig +dnssec asks for DNSSEC data; use a validating tool such as delv or a known validating resolver to assess the chain. A single local resolver may have a cached view that hides an incomplete transition elsewhere.
Query every child authoritative server for the expected DNSKEY set and signatures, and query the parent authorities for DS. Compare key tags, algorithms and the intended phase. Test known validating resolvers after publication and during the waiting interval. Do not require old trust paths to fail as a completion test: retirement is based on the documented cache dependencies and the correct new chain, not on demonstrating that every resolver in the world has forgotten a key.
DNSViz can visualize the delegation, key sets, signatures and validation findings. Use it alongside direct authoritative queries and resolver logs when available. A clean graph at one observation time is useful evidence, not a substitute for the required waiting periods or for checking every authoritative server. Investigate inconsistent signatures, stale DS entries, expired RRSIGs and incomplete propagation before advancing the state machine.
Where applications rely on DNSSEC, test an actual validated workflow as well. For DANE/TLSA, use a client or mail system that performs DANE validation; an ordinary successful SMTP message alone does not establish that the TLSA path was checked. Repeat that test during and after the rollover. The guide to SMTP security with MTA‑STS, TLS‑RPT, and DANE/TLSA explains the mail context; application success and DNSSEC-chain correctness are related but distinct checks.
BIND, Knot, PowerDNS and Managed DNS
For current BIND, dnssec-policy is the preferred policy-driven approach to key and signature maintenance. Inline-signing is not itself a lifecycle policy, and old auto-dnssec recipes should not be applied without checking the installed release. Knot supports automatic rollovers when automatic signing and key management are enabled, using its documented methods and lifetime settings. With PowerDNS, distinguish online signing and key activation from the external or operational process controlling rollover timing. Verify the configured feature, not just the product name.
Managed DNS services differ in which key roles they rotate and how parent DS updates are handled. Confirm the provider’s actual policy, supported CDS/CDNSKEY workflow and operator responsibilities. For a signed provider migration, explicit multi-signer support and compatible key exchange matter; identical ordinary zone data alone is insufficient. Delegation TTLs, remaining old-server responses and the DNSKEY/DS transition all belong in the migration plan. Do not treat a temporary primary/secondary arrangement as a universal replacement for multi-signer support.
Protect private key material and preserve the signer’s state and timing metadata in an access-controlled recovery process. Restoring files without the corresponding lifecycle state can reactivate the wrong key or leave the service unable to sign. An HSM changes how keys are stored and used, but it does not remove the need to plan key availability, backups and recovery. Validate a recovery procedure before relying on it during an active rollover.
The same discipline of staged changes and explicit checks also matters outside DNSSEC, but each system has different timing and state requirements. The related guide to cPanel-to-cPanel migrations covers a hosting migration rather than a key-rollover method. Keep application moves and DNSSEC changes separately observable where possible, so a validation failure can be diagnosed without simultaneously untangling unrelated routing or data-transfer changes.
Common Rollover Errors
A useful review compares the intended phase against what is actually published. Common errors include the wrong DS fields, removing a key while cached data still depends on it, or advancing automation before all authorities agree. Define the next-step condition in the runbook instead of relying on elapsed wall-clock time alone. Time, observed publication and successful validation each serve a different purpose.
Check all DS fields: key tag, DNSKEY signing algorithm, digest type and digest value. The digest type is not the same field as the signing algorithm. Generate and verify the DS using trusted signer tooling and a currently supported parent policy; do not copy a digest merely because its label looks familiar. Compare it with the actual DNSKEY you intend to anchor before submitting the parent change.
Removing old dependencies early is especially hazardous. An old ZSK may still be needed by cached data signatures; an old KSK may still be needed by a cached parent DS. Keep the relevant public keys and DNSKEY signatures until the method’s publication and cache waits have completed. “Stop signing with the old key” and “delete the old key from DNSKEY” are different steps, and a parent DS removal has its own waiting interval.
Avoid adding an algorithm change to a routine same-algorithm rollover. The signature-before-DNSKEY ordering of the conservative algorithm procedure and the reverse retirement order need a separate supported plan. A larger set of keys is not enough by itself. Check algorithm compatibility, authoritative distribution and cached combinations throughout; use the software’s documented state machine rather than a generic instruction to double-sign everything.
Automation can pause on observable conditions: every authoritative server has the new key set, the parent publishes the intended DS set, and the relevant old TTL has elapsed since publication completed. It should also monitor signature expiry and signer failures while waiting. Do not assume a scheduled timestamp proves readiness. If a script or dashboard changes a different set than requested, stop advancing phases and reconcile the actual published state.
Use stable existing names for validation tests. Negative DNS answers can be cached too, so repeatedly querying a recently deleted name can produce misleading observations during an unrelated key rollover. Distinguish NXDOMAIN or NODATA from a validation failure, inspect the response and resolver diagnostics, and test the chain at known names. Clearing one local cache does not clear remote caches or satisfy a timing prerequisite.
Compromise Response and Removing DS
A suspected key compromise needs an incident-specific plan based on the affected role, attacker access, available safe keys and parent response time. Shortening routine waits does not flush caches. Fast revocation may be necessary, but it can trade validation continuity for reduced exposure to a compromised key. Do not promise a compressed pre-publish or DS change will be harmless. Record the decision, coordinate the signer and parent, and verify the resulting safe chain.
Removing DS can deliberately end the secure delegation, but it is not an immediate repair for a broken signed zone. Cached DS records continue to require a matching valid chain until their lifetime ends. Where possible, maintain compatible signing until removal has reached every parent authority and the old DS TTL has elapsed. Disabling signing first can worsen failures. A compromise may force a different risk decision; re-enable DNSSEC later through a supported authenticated setup rather than assuming an instant toggle.
A Runbook with Explicit Completion Conditions
Before a routine rollover, record the current keys, DS set, relevant TTLs, publication delay and signature policy. For the ZSK pre-publication method, publish the new key, complete the DNSKEY wait, change data signatures, and retain the old key through old-data cache expiry. For the staged KSK method, prepare both keys/signatures, then add and remove DS with the separate parent waits described above. DNSViz can supplement the direct queries and validating checks recorded at each phase.
Keep phase timestamps and observed records so another operator can explain why the next action is safe. A rollback must also respect caches: if a new DS has been cached, removing its new KSK immediately is not a safe reversal. Preserve recovery material and verify the supported route back to a coherent chain. Related infrastructure work, such as HAProxy changes live without drama, also benefits from reviewable state changes, but its health checks do not replace DNSSEC validation.
Completing and Reviewing the Rollover
The finished state should contain the intended active key material and parent DS, with valid signatures and no remaining old-data dependencies under the chosen procedure. Routine ZSK renewal does not require a DS change under an unchanged KSK; KSK renewal crosses the parent boundary. Both require publication checks and the correct cache intervals. Review the final configuration and monitoring rather than equating a successful dashboard action with completion.
Practice on a zone you control, then use production TTLs and parent behavior when preparing the real runbook. Keep routine renewals separate from compromise response, algorithm migration and multi-signer transitions. The guide to apex CNAMEs with ALIAS/ANAME covers an adjacent apex-routing topic. For DNSSEC, the central requirement remains a verifiable chain for the old and new views that may coexist in caches until their defined lifetimes end.
