Summary

  • Revision 05 of DNSSEC automation is an active DNSOP Internet-Draft. Datatracker calls its intended status Informational while the draft header says Standards Track; neither description is an RFC or evidence of deployment.
  • The draft gives multi-signer DNSSEC transitions a disciplined sequence: distribute keys, publish combined child signals, observe parent DS and NS changes, respect DNSKEY, DS, NS and RRSIG waiting bounds, then remove old authority.
  • A waiting interval is a safety precondition, not proof that every signer, secondary, parent, cache or resolver reached the intended state. Each transition needs an observation tied to the object whose authority is changing.
  • Zone-content synchronization is explicitly outside the draft's scope. Matching infrastructure records can therefore coexist with divergent application data, and a clean key transition can still deliver inconsistent answers.

Automation exposes the joins

Multi-provider DNSSEC is attractive because no single signer needs to carry the entire availability burden. Under Model 2 of RFC 8901, each operator retains its own signing keys while the group serves one zone. The design avoids handing one provider every private key. It also multiplies the number of states that must agree before a transition is safe.

Revision 05 of DNSSEC automation turns those states into procedures for forming a group, adding and removing a signer, rolling ZSKs and KSKs or CSKs, and moving the group across algorithms. It combines Model 2 with CDS/CDNSKEY for parent DS maintenance and CSYNC for delegation data. The draft is valuable precisely because it does not pretend that “DNSSEC enabled” is one switch.

The procedure moves authority through a chain. A signer receives foreign public keys. All signers expose a combined DNSKEY view. They publish common CDS/CDNSKEY intent. The parent observes and accepts that intent, then publishes a DS set. Later the signer group exposes a common NS view and may publish CSYNC so the parent can change the delegation. Only after the relevant waiting conditions may an old signer or key disappear.

Each edge has a different owner. Each produces a different kind of evidence. Automation can schedule the edges. It cannot collapse them into a single green state without discarding the information that makes a failure explainable.

Four waits protect four different exposures

The draft names four timing concepts. They look similar in an implementation because all may become countdowns. Their evidence semantics are different.

DS-Wait-Time begins after the parent has picked up and published the new DS set. Its minimum is the DS RRset TTL. It protects the interval during which resolvers may still hold the old parent-side trust material. Starting it when a signer publishes CDS would be premature: child intent is not parent publication.

DNSKEY-Wait-Time follows publication of the intended DNSKEY sets across the signers. Its minimum includes the largest relevant DNSKEY TTL plus the time needed to publish the zone on all secondaries. It protects resolvers that may still hold an earlier key view. A controller must therefore know both when the new RRset became authoritative and when secondaries received it.

NS-Wait-Time follows parent publication of the intended NS set. Its lower bound is the maximum of the parent delegation TTL and the signer-side NS TTLs. It protects reachability during a delegation change. It does not begin when CSYNC is written or when a parent-side job acknowledges receipt.

RRSIG-Wait-Time follows the point at which a signer stops producing signatures with an old key. That key remains in the DNSKEY sets until data signed by it can have left resolver caches. The relevant exposure includes zone publication time and the maximum TTL of data signed by that key. A key is not safe to remove merely because the rollover job finished.

The labels are operationally useful because they prevent one TTL from standing in for every risk. They are also dangerous if a dashboard renders all four as equivalent hourglasses. The start event, protected object, owner and exit observation must remain attached to each timer.

A clock needs an observed start

A duration cannot compensate for an uncertain beginning. If the controller starts DS-Wait-Time when it sends an update, the interval includes time during which the parent may not yet have accepted or published anything. If it starts NS-Wait-Time from a registrar acknowledgement, it treats workflow receipt as authoritative DNS state. If it starts DNSKEY-Wait-Time from a local write, it ignores secondaries.

The safe sequence begins with a state observation. Record the exact RRset, authoritative source, serial or equivalent zone-generation evidence, observation time, TTL and validation status. Only then compute the applicable lower bound. The closeout should observe the successor state again rather than assume that sleeping made it true.

This is not a demand to query every cache on the Internet. DNS provides bounded expiration, not global cache enumeration. It is a demand to distinguish the normative cache horizon from evidence that the authoritative prerequisites existed before that horizon began. The controller can say that the old state should no longer be valid under the recorded bounds. It cannot say that every resolver observed the new state.

The difference matters in an incident. “The job waited 3,600 seconds” is not enough to reconstruct which publication event the countdown followed. “The parent served DS hash X from authority set Y at time T, with TTL Z; removal occurred after T+Z and a fresh parent observation” is auditable.

Membership is not just a list of providers

Joining a multi-signer group means importing another operator's public signing material into every participant's DNSKEY view. The controller must distinguish local keys from foreign keys and locally managed NS records from records introduced for peers. Otherwise cleanup can remove the wrong object or preserve an orphan forever.

The join procedure then compiles CDS/CDNSKEY for all KSKs or CSKs represented in the group. Every signer must publish that same intent before the parent is expected to act. One signer's correct view does not prove the others are ready. Parent publication of the combined DS set is the external authority transition that makes validation depend on the expanded key population.

Only after the DS and DNSKEY conditions are protected does the group compile and publish the combined NS set. If the parent differs, CSYNC can signal the desired delegation and glue changes. Again, the signal is not the mutation. The parent may scan, receive Generalized NOTIFY, apply policy, reject, delay or require manual action.

The membership ledger should therefore record more than “provider B joined.” It should preserve every signer's observed key set, combined child signal, parent result, delegation result and the evidence that each waiting interval followed the correct publication. Group membership is a claim about shared obligations, not an account roster.

Leaving is the harder proof

Addition can often fail safely by leaving the old signer in place. Removal destroys fallback paths. Revision 05 orders the withdrawal carefully: remove the exiting signer's NS records from the remaining signers; get the parent to publish the reduced delegation; wait; stop the exiting signer from answering; publish CDS/CDNSKEY for the remaining keys; wait for signatures made by the exiting signer to age out; then remove its key material.

That order contains two independent safety questions. Is traffic no longer expected to reach the exiting authority? And can validators still encounter data signed by its key? NS-Wait-Time addresses the first exposure. RRSIG-Wait-Time and continued DNSKEY publication address the second. Neither substitutes for the other.

A provider contract may end on a fixed date, while the DNS state is not ready. Commercial offboarding and protocol-safe withdrawal need an explicit arbitration rule. If the organization lets the contract date stop service first, the protocol sequence may be broken. If it extends service silently, responsibility and cost become unclear. Leadership has to assign who can delay termination, who pays for the overlap and what evidence releases the old operator.

The retiring signer also needs a durable closeout receipt. It should show the last served zone generation, the last signing time for each key, the delegation state after removal, the remaining group key set and the point after which its keys could be deleted. “Account closed” is not that receipt.

Infrastructure agreement can hide data disagreement

The draft explicitly excludes synchronization of ordinary zone contents. It coordinates infrastructure records such as NS, DNSKEY and CDS, but does not define how the actual zone data travels among providers.

That boundary prevents a category error. Three signers can expose the same DNSKEY and NS sets and still answer differently for application names. They may have different SOA serials, missing records, unequal denial-of-existence structures or different signed generations. Each answer can validate under a key trusted by the parent while the service view remains inconsistent.

For an operator transition, that means key continuity is necessary but not sufficient. The incoming signer needs a separately governed data distribution path, serial or content comparison, transfer authorization, signing-policy compatibility and query sampling. The controller must not promote “multi-signer formed” into “zone migrated” unless that second plane closes.

The same distinction applies to steady-state diversity. Multiple valid signatures do not prove equivalent content. A resolver can correctly validate two contradictory positive and negative answers seen from different authorities. DNSSEC authenticates the data served under its rules; it does not choose which operator's dataset reflects the owner's latest intent.

Centralized and decentralized control fail differently

In the centralized model, one controller calculates the waits and changes every signer. This concentrates visibility and authorization. It can produce a coherent ledger, but a stale or overprivileged controller can move the entire group through the wrong state.

In the decentralized model, signers exchange configuration details and each computes the applicable restrictions. This reduces dependence on one controller but creates a consensus problem. Peers can hold different TTL inputs, publication observations or membership views. A locally correct timer derived from stale group data can still advance globally unsafe work.

The operating contract should name the authoritative source for each input and how disagreement is handled. Progress should halt on conflicting signer views, not select the shortest timer or the first successful response. A later correction must append a new state; it must not erase the observation that led a participant to advance.

Neither model escapes bootstrap. The draft's “trust mechanism” is an authenticated channel capable of changing DNSKEY, CDS/CDNSKEY, CSYNC and NS state, but its detailed design is out of scope. That channel needs its own principal, scope, credential lifecycle, approval boundary and audit trail. A perfectly implemented state machine controlled by the wrong principal remains wrong.

Parent state has its own authority

Child-side publication expresses intent. The parent owns DS and delegation publication. Automation must therefore preserve the boundary between a record that asks, a process that accepts, an authoritative zone that publishes and resolvers that later observe.

RFC 8078 and related CDS/CDNSKEY procedures constrain how a parent can use child signals. CSYNC similarly communicates requested child-to-parent synchronization. Generalized NOTIFY can reduce delay by telling the parent that relevant state may have changed. None of these mechanisms forces acceptance or proves that the public parent zone changed.

The controller should record the child's exact request, the parent's applicable policy, the authoritative parent response and the subsequent cache horizon separately. If manual action substitutes for scanning or notification, the human approval and resulting DNS state remain different receipts.

This separation protects both sides. The child cannot claim a secure delegation merely because it published a valid signal. The parent cannot claim successful migration merely because its update system accepted a request. The resolver cannot infer current child content merely because the chain validates.

Draft status bounds every conclusion

At the evidence freeze, Datatracker lists revision 05 as active DNSOP work, last updated 5 July 2026, with the working-group state “Waiting for WG Chair Go-Ahead.” Datatracker labels the intended status Informational. The document header says Standards Track and gives an expiry of 6 January 2027.

That discrepancy is part of the source state. It should not be silently normalized into a stronger claim. The document may change, be reclassified, expire, be replaced or never become an RFC. Its implementation-status section and references can identify experimentation; they do not prove adoption, interoperability or production safety.

No source in this packet proves that a named provider ran the sequence, that a zone completed a migration, that an outage was avoided or caused, or that the constructed opening happened. The article uses the draft to expose an evidence architecture, not to announce an Internet-wide operational fact.

The useful product is a transition ledger

A robust controller should emit a transition ledger whose rows correspond to state changes, not a final success message. Each row names the zone, group generation, participant, object, expected RRset hash, observed RRset hash, authoritative vantage, security status, policy decision, observation time, TTL, computed earliest-next-action and approving principal.

For parent changes, preserve child intent and parent publication separately. For signer changes, preserve every participant's view. For cache retirement, preserve the assumptions and upper-bound calculation. For zone content, attach a separate synchronization and query-sampling receipt. For application continuity, record the service-level observation without treating it as DNS proof.

Unknowns must remain visible. If the controller cannot identify when all secondaries published the DNSKEY set, it cannot manufacture a precise DNSKEY-Wait-Time start. If it cannot prove parent publication, a registrar ticket does not fill the gap. If ordinary content synchronization is not integrated, the final state should say infrastructure converged and content unverified.

That language may feel less decisive than “migration complete.” It is more useful. It tells an operator which authority can safely be removed, which observation remains open and what a rollback would actually restore.

Leadership should govern the overlap

Multi-signer automation creates a period when multiple organizations legitimately hold authority over one namespace. The overlap improves continuity, but it also expands credentials, signing paths, commercial dependencies and opportunities for divergent state.

Leadership must decide who owns group membership, who can authorize foreign keys, who can ask the parent to change DS or NS, who controls the trust mechanism, who computes and approves the waits, and who certifies content equivalence. Those roles should not collapse into the convenience of one automation account.

The decisive metric is not how quickly every timer turns green. It is how often the organization can show the evidence behind each authority transition and halt when that evidence disagrees. A slow state machine with clear receipts is safer than a fast one that mistakes elapsed time for observation.

The durable claim remains narrow: the procedure can impose necessary ordering and lower-bound waits on a multi-signer DNSSEC transition. It cannot, by itself, prove global cache state, synchronized zone content, correct application answers or a successful migration. Those claims need their own observers and their own owners.

Sources