The DNSSEC root-key rollover is scheduled for 11 October 2026. If you operate a DNSSEC-validating recursive resolver, the useful question is not whether your websites are online today. It is whether the resolver actually trusts KSK-2024, key tag 38696, before that key takes over root signing duties.
IANA’s current schedule identifies the replacement key and rollover date. This is a planned trust-anchor transition, not an announcement that the Internet is shutting down. The readiness work belongs primarily to resolver operators, including ISPs and enterprise network teams.
Evidence and scope: This guide was checked against official documentation on 7 October 2026. CoreSecTech has not reproduced a rollover failure or tested a production resolver fleet. The workflow below is our documentation-based operational recommendation; example queries are not measured results.
1. Decide whether you own the affected component
A recursive resolver looks up DNS answers for clients. An authoritative DNS service publishes answers for a domain. Those are different responsibilities. Cloudflare’s 6 October explanation says most website operators need no changes for this rollover; it also says its 1.1.1.1 and Gateway DNS systems already trust the new key.
| Your role | First action | Avoid |
|---|---|---|
| Website owner using managed authoritative DNS | Identify who provides recursive DNS for your devices or organization. | Changing nameservers or deleting your domain’s DS records just because of this rollover. |
| Ordinary user on an ISP or managed network | Ask the resolver provider for readiness confirmation if a test is inconclusive. | Treating a browser test as permission to change a corporate network. |
| Operator of a validating resolver | Inspect the trust-anchor state of the deployed resolver instance. | Assuming every node is ready because one client works. |
CoreSecTech’s recommendation is to name an owner before changing anything. A hosting dashboard, a domain registration, and a resolver configuration are not interchangeable control surfaces.
2. Understand what must be trusted
The root key-signing key authenticates the root DNSKEY set. That set contains the zone-signing keys used to authenticate other root-zone data. A trust anchor is the locally trusted starting point for that chain. The ICANN rollover FAQ explains why validating systems need the replacement public key.
Finding a key in a downloaded file is not the same as establishing that the running resolver trusts it. Likewise, a successful lookup today can still use the current trust arrangement. Record the configured trust-anchor source and the running instance’s accepted state, not just the software package version.
3. Build a small resolver-path inventory
Before testing, make a worksheet for each distinct path you actually need to support. Keep it small enough to verify, but do not collapse a redundant pair or a remote-office path into a single assumed result.
- Record the resolver endpoint, node or service, operator, software/package version, and whether DNSSEC validation is enabled.
- Record whether the client forwards to another resolver or uses browser Secure DNS, a VPN, or an application-specific resolver.
- Record how trust anchors are supplied: vendor packaging, automatic management, or an explicitly maintained configuration.
- For every check, save the timestamp, network context, target endpoint, evidence, result, and person responsible for any follow-up.
Keep browser-path evidence separate from server-instance evidence. Label a result “this path checked,” not “the organization is ready,” unless the inventory supports that broader conclusion.
4. Use the browser readiness test as evidence, not a guarantee
Cloudflare provides a KSK-2024 readiness test. It checks valid and deliberately invalid DNSSEC names as controls, plus trust-anchor sentinel queries. Read the controls before interpreting the replacement-key result.
The test documentation warns that blocked requests can reflect browser or network problems, and timeouts are inconclusive. Secure DNS, VPNs and multiple resolvers can change the path under examination. A browser result is a snapshot of that path, not a fleet-wide certificate of readiness.
5. Interpret the two sentinel questions together
RFC 8509 defines special handling for supporting, validating resolvers. The is-ta query asks whether the nominated key is trusted; not-ta asks the opposite. The response pattern matters more than whether an individual query appears to “fail.”
| Observed pair | Meaning when controls and sentinel support are established | Next check |
|---|---|---|
| is-ta returns an answer; not-ta returns SERVFAIL | The queried resolver trusts the nominated key. | Record the endpoint and verify other required nodes. |
| is-ta returns SERVFAIL; not-ta returns an answer | The nominated key is not trusted by that resolver. | Have its operator inspect accepted trust-anchor state. |
| Both return answers | No reliable readiness conclusion from the pair alone. | Check sentinel support and possible mixed resolver paths. |
| Both fail, or a control fails | Do not classify the key state from this evidence alone. | Investigate connectivity, DNSSEC validation and test support. |
A SERVFAIL response to not-ta-38696 is expected when a supporting resolver trusts KSK-2024. RFC 8509 also excludes pending and revoked keys from the active trusted state used by this mechanism. Other causes of SERVFAIL exist, so never use one error response as a diagnosis by itself.
Read-only queries: be precise about the endpoint
The following pair uses the test names documented by Cloudflare and explicitly queries 1.1.1.1. It does not test your ISP resolver, internal DNS server, or browser’s configured Secure DNS provider. Run it only where dig is already available; do not install a tool merely to produce article-style output.
dig @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev. A +dnssec
dig @1.1.1.1 root-key-sentinel-not-ta-38696.dnstest.dev. A +dnssecOperators checking their own service should use their approved diagnostic tooling and the actual authorized resolver endpoint, with the valid/invalid control queries from the test page. Keep the query type and validation behavior consistent. Do not add checking-disabled flags to make a failing test appear successful.
6. Verify accepted trust state, not merely automatic-update settings
ICANN’s operator reminder specifically says not to assume automatic trust-anchor updates succeeded. Confirm KSK-2024 is present in the trust-anchor configuration and, if missing, follow the resolver vendor’s update procedure.
RFC 5011 includes an add hold-down period of 30 days or the original DNSKEY set’s TTL, whichever is greater. Enabling automatic updates shortly before the deadline is therefore not equivalent to demonstrating that a replacement key is already accepted. A key in a pending state is not yet usable as an accepted trust anchor.
Unbound: check the configured file and its management path
For Unbound, consult the official configuration documentation rather than assuming a universal file path. It explains auto-trust-anchor-file, distribution-dependent locations, and the need for the daemon to read and write the managed file.
The unbound-anchor manual describes a setup/update tool, not a purely read-only readiness probe. It also documents exit-code behavior that includes errors returning zero. Do not interpret a zero exit code alone as a clean readiness result, or run the tool against a production file without following the deployment’s maintenance procedure.
CoreSecTech recommends retaining the existing configuration and management-state evidence before any approved remediation. Have the responsible operator verify the vendor-supported correction on the actual instance and confirm it survives the deployment’s normal restart or replacement process. Do not delete the managed key file as a generic shortcut.
7. Plan verification after the signing change
The ICANN “What to Expect” guide explains that cached root-key data can delay visible failures. A quiet moment immediately after the change does not establish readiness. Applications can also use resolver paths that differ from the host’s normal configuration.
Our recommended handover is a named operator, saved pre-change evidence, monitored validation errors, and a documented escalation route. Compare affected and unaffected paths before blaming an application or its hosting. Preserve validation protections; repairing the trust configuration is the goal, not hiding a failure by making the resolver stop checking signatures.
Verification checklist
- The current IANA/ICANN schedule has been rechecked; 11 October is still scheduled, not reported here as already completed.
- Every required resolver path has an owner and separately recorded evidence.
- KSK-2024, key tag 38696, is accepted by the running validating instance—not merely downloaded or pending.
- Browser/sentinel results include controls and are labeled inconclusive when appropriate.
- Any remediation follows the actual vendor/package procedure with a recovery plan.
- Post-change monitoring and an escalation owner are arranged. No domain-DNS change is being made merely to satisfy this checklist.
FAQ
Should a website owner change nameservers for this rollover?
Not simply because the root key is changing. Establish whether you operate a validating recursive resolver. Authoritative hosting and recursive validation have different roles; ask the responsible provider instead of making unrelated domain changes.
Does an inconclusive readiness test mean KSK-2024 is missing?
No. Unsupported sentinels, failed controls or the wrong resolver path can prevent a conclusion. Request accepted trust-anchor evidence from the operator.
Is a successful lookup today enough?
No. It does not by itself show acceptance of the replacement key. Check the deployed trust state and use controls when interpreting sentinel evidence.
Should I disable DNSSEC if a check fails?
Not as a readiness shortcut. Escalate to the resolver operator, establish the cause, and follow its supported recovery procedure. This guide does not prescribe a security-bypass configuration.
The practical decision
If you do not operate the resolver, obtain a provider answer rather than changing an unrelated setting. If you do operate it, verify accepted KSK-2024 trust on each required path and keep evidence that another operator can understand. The useful outcome is a defensible readiness record—not a green browser result without context.