Summary

  • A root KSK rollover publishes the new trust anchor before use and overlaps it with the existing key so validating resolvers can update.
  • BTW analysis: continuity depends on observing resolver acceptance during that window; the centralized rollover operation cannot update distributed resolver software.

Sources: KSK rollover explanation and LACNIC DNSSEC measurement methodology.

DNSSEC validation starts from the root-zone KSK trust anchor and proceeds down the chain of signatures. When that trust anchor changes, resolvers that have not learned the new key may reject otherwise valid answers. To avoid a hard cutover, the IANA Services explanation republished by LACNIC describes publishing the new KSK early and trusting both old and new keys during a deliberate overlap.

That sequence turns time into the main control surface. Operators need enough time to receive the new anchor, verify automated update mechanisms and discover equipment or configurations that remain stale. A small resolver population can still have outsized user impact when it serves a large network.

LACNIC’s DNSSEC research offers an observable test, with limits. Its Atlas measurements queried a domain carrying intentionally invalid signatures. SERVFAIL indicated that a resolver rejected the invalid response; NOERROR indicated that it did not validate. The study also used anonymized traffic captures to identify DNSSEC record queries.

Those methods help measure validation behavior, but the authors warn that Atlas probes may sit disproportionately in advanced networks. The sample can therefore act as an upper bound rather than a census. A pre-rollover test also cannot guarantee behavior throughout the transition.

The operational question is not whether a new key exists. It is whether resolver populations have accepted it before the old anchor retires—and whether operators can see the remaining exceptions soon enough to act.