Summary

  • When an unavailable DNSSEC private key has no usable backup, the key cannot be recovered. A still-valid pre-signed zone buys time to restore the signing function, but only while old DNSKEY and RRSIG state is deliberately preserved.
  • Recovery is not one event. It is an evidence chain across replacement-key publication, parent DS timing, authoritative propagation, cache expiry, complete re-signing, denial and zone-digest consistency, independent resolver validation and application continuity.

At the moment a DNSSEC private key becomes unusable, nothing visible may fail. Authoritative servers can keep answering from a zone that was signed hours or days earlier. Its RRSIGs can still be within their validity periods. Recursive validators can continue to classify answers as secure. The website stays up; the mail exchanger resolves; monitoring remains green.

That calm is easy to misread. It does not show that the signing system is healthy. It shows that previously produced cryptographic inventory has not yet expired.

This distinction is the useful centre of draft-ietf-dnsop-dnssec-keyrestore-02. As verified on 13 September 2026, the document is revision 02 of an active DNSOP working-group Internet-Draft, last updated on 10 August 2026. It is not an RFC. Its own status text calls it work in progress, and its procedures may change. The draft nevertheless isolates a production condition that ordinary rollover diagrams often assume away: a private key in the chain of trust can no longer sign, no functioning backup is available, yet a complete signed copy of the zone survives.

The draft's language is exact. The private key cannot be restored because there is no usable copy. What may be restored is the zone's signing function. The difference determines both the response and the standard of proof.

A cryptographic inventory with a use-by date

A pre-signed zone is a stock of assertions. Each RRset has signatures produced earlier; the DNSKEY RRset exposes public keys; the parent may publish a DS that connects one of those keys to the wider chain of trust. The stock remains useful only while its combinations still validate.

The first operational instruction is therefore counter-intuitive: do less. The draft says signing software must not delete DNSKEYs until instructed and should not remove old RRSIGs. A signer that notices the private key is absent may regard the corresponding public key and signatures as obsolete output. During recovery they are the bridge. If the software cannot retain the old signatures, the operator must put them back before publication, apart from the old DNSKEY RRset signature that the surviving or replacement key path will handle.

This is why a fresh-looking zone can be more dangerous than an old one. Changing the SOA while an inoperable ZSK or CSK cannot sign it may leave signatures over ordinary existing records usable while making denial-of-existence answers bogus. Adding CDS or CDNSKEY changes the apex NSEC or NSEC3 type bitmap; if the relevant signing key is unavailable, the changed denial record cannot be safely signed. Replacing the DNSKEY RRset also invalidates an existing ZONEMD digest. A mechanically regenerated zone can destroy the only remaining coherent signed state before its replacement is ready.

The value of the old zone is thus not its age but its internal closure: RRsets, RRSIGs, DNSKEYs, denial proofs, SOA and any ZONEMD record must describe one state that validators can still traverse. The safest first evidence is an immutable capture of that state, including RRSIG inception and expiration times, DNSKEY TTL, maximum signature TTL, parent DS TTL, authoritative topology and the latest confirmed zone loaded by each secondary.

ZSK failure: publish before signing

In a split-key design, an operable KSK can still sign the DNSKEY RRset when the ZSK is lost. The new ZSK therefore enters through Pre-Publication.

At publication time, Tpub, the operator adds the new ZSK to the DNSKEY RRset while retaining the inoperable ZSK and every old signature it created. The KSK can authenticate the expanded DNSKEY set. But seeing the new key at one authoritative address does not make it ready. The draft inherits the timing model of RFC 7583: the publication interval is Ipub = Dprp + TTLkey. Dprp covers propagation to all authoritative instances; TTLkey allows older cached DNSKEY RRsets to age out. Only at Trdy = Tpub + Ipub can an operator rely on validators being able to obtain a DNSKEY set containing the replacement.

The zone can then be changed and signed with the new ZSK. That is activation, not closure. Every RRset must receive an appropriate new signature, the result must propagate, and signatures made by the old key may still exist in caches. The inoperable ZSK stays published until a retirement interval has passed: Iret = Dsgn + Dprp + TTLsig. The variables cover complete signing, authoritative propagation and the maximum TTL of signatures. Only after that interval can the old ZSK leave DNSKEY safely.

The practical receipt for this sequence is not “new key generated”. It is a time-indexed table: which authoritative instance served which DNSKEY set; when the last RRset acquired a replacement signature; what maximum RRSIG TTL applies; and which independent validators could validate positive and negative answers before, during and after retirement. A packet captured from one server proves that packet, not the global state assumed by the equation.

KSK failure: the parent clock comes first

An inoperable KSK creates a different dependency. The operator cannot change the child DNSKEY RRset and authenticate that change with the old KSK. The draft therefore uses Double-DS.

The replacement begins outside the child. A new DS is submitted to the parent at Tsbm. Administrative acceptance by a registrar or registry is only the first receipt. After registration delay Dreg, the DS must actually appear in the parent at Tpub. It then remains published for IpubP = DprpP + TTLds: enough time to reach every authoritative instance of the parent and to displace previously cached DS sets. The new KSK becomes ready at Trdy = Tpub + IpubP.

Only then is the new KSK added to the child DNSKEY RRset and used to sign it. The old KSK can leave the child set, but the old DS must remain in the parent while cached child DNSKEY sets that contain only the old KSK can still exist. The child retirement interval is Iret = DprpC + TTLkey; parent removal is no earlier than Trem = Tact + Iret.

This order separates four facts often compressed into “DS updated”: request, acceptance, authoritative publication and cache passage. RFC 10026's recommendation that parental agents retain structured DS-decision records is valuable here, but an audit record does not replace DNS observation. The operator needs both the institutional evidence—who authenticated and applied the request—and the wire evidence—what every observed parent server and independent resolver returned over time.

If both KSK and ZSK are inoperable, sequence matters. The draft says not to restore the ZSK first. Re-establish the KSK path using Double-DS; preserve the existing zone and ZSK state; then perform the ZSK Pre-Publication procedure. Trying to solve both clocks at once increases the number of partially valid combinations at the point where the operator has the least signing capacity.

CSK failure: one key, two coupled retirements

A Combined Signing Key concentrates the failure. It authenticates the DNSKEY RRset and signs the rest of the zone. Its replacement also begins with Double-DS, but the retirement interval must cover both roles.

After the new DS is published at the parent and survives IpubP, the new CSK can enter the child DNSKEY set and sign that set. The old inoperable CSK and all its RRSIGs remain. The operator should avoid an unsafe SOA change and may have to force every secondary that relies on IXFR or AXFR to load the new version.

The old path cannot retire until Iret = Dsgn + DprpC + max(TTLkey, TTLsig). Complete re-signing and child propagation must finish, and the longer of the cached DNSKEY or RRSIG lifetime must pass. Only then can the old DS, old CSK and old signatures be removed together. Only then does the draft say the zone can change normally again.

That longer formula expresses concentration risk. A CSK simplifies the normal key inventory but couples the parent-delegation recovery to the full-zone signature replacement. A split design can isolate an operable KSK from a failed ZSK; a CSK failure consumes both margins at once.

State must move even when the serial should not

The draft exposes an awkward operational fact: the safest recovery edit may avoid changing SOA, while ordinary secondary convergence commonly treats the SOA serial as the signal that a new version exists. Operators may need to force IXFR/AXFR-dependent secondaries to load the modified zone.

This makes “serials match” a weak closure criterion. A matching serial can coexist with different DNSKEY sets if the special load did not reach every instance. Conversely, a deliberately unchanged serial does not prove no authorised recovery edit occurred. Evidence has to descend to the actual RRsets served by each authoritative endpoint, including anycast backends where a single address hides multiple machines.

Negative answers need their own tests. A positive A or MX lookup may continue to validate from old signatures while an NSEC or NSEC3 type bitmap no longer corresponds to the apex record set. Query names and nonexistent types should be chosen to exercise denial proofs, not merely confirm that one popular hostname resolves.

ZONEMD adds another ledger. RFC 8976 orders digest construction, denial records and signatures carefully. Once DNSKEY changes, the old digest no longer represents the zone. A new digest that matches a captured zone and carries a valid signature strengthens evidence that the transferred content is coherent. It does not prove the parent chain, the global cache state or application reachability. It answers one question well; promoting it to a universal health certificate would repeat the same category error.

From secure answers to continuity

DNSSEC validation is observer-specific. One resolver returning a Secure result proves that its chosen authoritative path, cached DS and DNSKEY material, RRset and RRSIG formed a valid chain at that instant. A warm cache may be relying on the predecessor. A cold cache may already use the successor. Another network may reach a lagging authoritative instance.

A defensible recovery record therefore uses several independently operated validating resolvers, distributed vantage points and repeated observations. It exercises old and new paths across the overlap, waits through the declared DS, DNSKEY and RRSIG intervals, and checks both positive data and authenticated denial. It records response bytes, key tags, signature inception and expiration, TTL remaining and the authoritative source rather than retaining only a green status label.

Business continuity is one step further away. An HTTP request succeeding after DNS resolution demonstrates one application path. It does not show that validating mail systems, APIs, branch networks or customers behind different recursive operators are unaffected. Service checks should span the applications that matter and continue through the old-material retirement point. The decisive evidence is not the first successful query after activation; it is the absence of a cliff when predecessor material finally disappears.

The draft's implementation-status section reports that the procedure has been verified with Knot DNS, using manual steps that import old public keys, build a replacement DNSKEY set in an empty zone, transplant the DNSKEY set and signatures, and load the modified zone with automatic signing disabled. It also notes that manual creation of a new ZONEMD digest is not supported in that path. This is valuable implementation evidence, but it is evidence for one exercised toolchain—not proof that other signers preserve state, that automation will choose safe actions, or that production topology has converged.

The correct closing statement after private-key loss is therefore deliberately narrow: the signing function has been restored when the successor chain has been published, observed, used to sign all required data, kept valid through every relevant cache interval and shown to support real service after the predecessor's final retirement. Until then, the apparently healthy zone is spending a finite reserve of old signatures.

Sources