Summary

  • DNSSEC rollover is a sequence of key states, not one ceremony timestamp.
  • Authoritative propagation, cache expiry, parent DS publication and resolver trust-anchor hold-down move on different clocks.
  • Old material remains operationally necessary until every applicable validation combination is safe.
  • A rollover custody record should govern activation, retirement and removal.

Imagine a scheduled key ceremony that appears to finish cleanly. The new DNSKEY is present, the signer produces valid signatures and the control panel records success. The old key is then removed on schedule. Soon afterward, one validating customer cohort starts receiving SERVFAIL, while probes near the authoritative servers continue to pass.

The cryptography did not suddenly weaken. The operating model collapsed several clocks into the ceremony clock.

RFC 7583 describes rollover as a timed progression through states such as Generated, Published, Ready, Active, Retired, Dead and Removed. Those names matter because a key can be visible without being ready, active without being usable by every resolver, or retired while cached material still depends on it. “Safe” means preserving at least one valid path through the changing DNSKEY, RRSIG and, for a KSK, DS combinations.

The first clock is authoritative propagation. A new key published on the primary is not instantly present on every authoritative server. RFC 7583 includes propagation delay in the interval before a key is ready. RFC 6781 makes the same operational point for a pre-published ZSK: introduce the new DNSKEY, allow it to reach the authoritative set, and leave it published for the DNSKEY TTL before using it to sign production data.

The second clock belongs to resolver caches. Validators can hold an older DNSKEY RRset while fetching a newer RRSIG, or retain an old RRSIG while refreshing the key set. A safe method preserves compatible combinations during that overlap. Under pre-publication, the new key waits before use; after signatures switch, the old key remains until old signatures have expired. Under double-signature, old and new keys and signatures overlap, trading larger responses for a simpler compatibility window.

The third clock is the parent delegation. A ZSK rollover can remain within one zone. A KSK rollover normally joins the child DNSKEY RRset to a DS RRset controlled by the parent. The child can submit a new DS but cannot turn submission time into publication time. It must observe the new DS at the parent, account for the previous DS TTL in caches and preserve the old validation path until the successor path is established. Registry workflow and DNS cache time are separate facts.

The fourth clock applies when resolvers maintain configured trust anchors under RFC 5011. A newly observed SEP key enters a pending state. The resolver must wait through the add hold-down and then retrieve and validate another DNSKEY RRset containing the key before accepting it as a trust anchor. The standard sets the add hold-down to 30 days or the original TTL expiry, whichever is greater. For removal, a trust anchor reaches the Removed state only through the specified revocation or absence observations; its state is then retained for a 30-day remove hold-down before bookkeeping is purged. That retention is specific to resolver trust-anchor state, not a generic timer authorizing deletion of a DNSKEY from the zone. This clock lives inside validator state, beyond the zone operator’s direct control.

These are not four copies of one countdown. Each starts from a different observed event, belongs to a different component and proves a different transition. A dashboard that displays only “new key published” cannot authorize activation. One that displays only “new signatures valid here” cannot authorize removal. A parent portal receipt cannot prove cache expiry. A thirty-day wall clock cannot prove the resolver performed the required post-hold-down retrieval.

The useful evidence object is a rollover custody record. It identifies the zone, rollover method, key tags and algorithms; records when each key entered Published, Ready, Active, Retired and Dead states; preserves DNSKEY, RRSIG and DS observations from named vantage points; records TTLs, propagation bounds and signature validity; and separates submission, authoritative observation and cache-expiry deadlines.

For RFC 5011 populations, the record also names the trust point, first validated observation, hold-down deadline and later validated observation that completes acceptance. For every population, it retains validator results across representative resolver cohorts. It identifies the person or system authorized to advance each state and the evidence required to roll back.

This changes the completion statement. “The ceremony ran” means keys were generated or signing actions occurred. “The new key is active” means the selected rollover method has reached a compatible validation state. “The old key is removable” means no applicable cached or trust-anchor state still needs it. The dates may be close. The claims are not interchangeable.

Sources

RFC 7583 — DNSSEC Key Rollover Timing Considerations; RFC 6781 — DNSSEC Operational Practices, Version 2; RFC 5011 — Automated Updates of DNSSEC Trust Anchors.