DNSSEC Root Key Rollover: Business Readiness Guide
On 11 October 2026, the cryptographic key used to sign the DNS root changes from KSK-2017 to KSK-2024. For most website owners and Internet users, the rollover should be invisible. The important exception is any organisation or provider operating a DNSSEC-validating recursive resolver that has not learned the new key.
If that resolver cannot validate the root after the switch, healthy websites, cloud applications, APIs, email services and third-party platforms can appear unreachable to users behind it. The web server may be working perfectly; the failing network simply cannot translate names into destinations.
This guide is for Australian business owners, operations managers, IT teams, managed service providers and technology decision-makers. It explains who owns the action, what to verify, how to test the networks that matter and how to respond without making unnecessary domain changes.
Why the DNSSEC root key rollover is trending now
IANA's rollover schedule sets 11 October 2026 as the date KSK-2024 begins signing the root DNSKEY set and KSK-2017 stops signing it. The incoming key has key tag 38696.
This is only the second root KSK rollover. The new public key has been visible in the root zone since 11 January 2025 so standards-compliant resolvers could learn it in advance. The long preparation period is why the event should be routine, but it does not guarantee that every private resolver, security appliance or frozen legacy system completed the update.
ICANN's current reminder is explicit: operators should verify that KSK-2024 is present instead of assuming automatic trust-anchor updates worked.
Who needs to act—and who usually does not
The relevant system is the recursive resolver your users depend on, not automatically the DNS zone that publishes your website records.
Website owner using managed DNS
Usually no key change is required. Confirm who supplies recursive DNS to staff and critical sites, then keep normal availability monitoring active.
Business running its own resolver
Action is required. Verify KSK-2024 key tag 38696 in the resolver's trust-anchor state and follow the software vendor's supported update process if it is absent.
Managed service or network provider
Obtain written confirmation of readiness, affected resolver inventory, monitoring coverage, escalation ownership and the rollback or recovery process.
Cloud or public resolver user
The provider normally manages the trust anchor. Confirm the service you actually use rather than assuming every office, VPN and device follows the same path.
DNSSEC-signed domain owner
Do not rotate your domain's own keys merely because the root key changes. Domain signing and recursive-resolver trust are related but separate responsibilities.
Business with no DNS inventory
Treat the event as a useful ownership test: document domain registrar, authoritative DNS, recursive DNS, network provider, monitoring and escalation contacts.
Verify the path from trust anchor to business service
What is actually changing?
The Domain Name System maps names such as a website address to technical destinations. DNSSEC adds digital signatures so a validating resolver can check that DNS data is authentic and has not been altered in transit. That validation forms a chain of trust beginning at the DNS root.
The root Key Signing Key is the trust anchor at the top of that chain. KSK-2024 is not a new certificate for your website, not a replacement for TLS and not a request to change nameservers. It is the key validating resolvers use to trust signatures at the root.
The rollover has been staged rather than switched abruptly. Under RFC 5011, an automated resolver observes and validates a new key through an add hold-down period of at least 30 days before accepting it as a trust anchor. KSK-2024 has been published since January 2025, providing far more than that minimum window.
What failure looks like to a business
A stale validating resolver may return DNS SERVFAIL after it can no longer validate the root chain. Users behind that resolver can report that many unrelated services stopped working at once: the company website, cloud software, supplier portals, APIs or email lookups.
That pattern is easy to misdiagnose as a web-hosting outage. A website monitor using a healthy public resolver may remain green while staff in one office, warehouse, VPN or customer network cannot resolve the same hostname.
The commercial effect depends on where the resolver sits. A private office resolver may interrupt staff access. An ISP or managed network failure may affect a larger customer group. A resolver used by integrations can break scheduled jobs and API calls even when no person opens a browser.
The distinction matters during triage: if the domain resolves through one trusted public resolver but fails through the affected network, investigate recursive DNS validation before rebuilding the website or changing authoritative records.
Four checks to complete before 11 October
1. Inventory the recursive DNS paths that matter
List the resolver used by each office, branch, warehouse, VPN, remote-access profile, guest network, cloud environment and business-critical integration. Record whether it is operated internally, by an MSP, by an ISP, by a security gateway or by a public DNS provider.
2. Verify KSK-2024 on any resolver you operate
Confirm key tag 38696 in the resolver's trust-anchor state. ICANN identifies common files as bind.keys for BIND, root.key for Unbound and PowerDNS Recursor, and root.keys for Knot Resolver. Use the current documentation for the installed product and version; do not copy an unverified key from a blog post.
3. Test from the real user path
Cloudflare's rollover guidance provides a browser-based readiness test built on the sentinel mechanism in RFC 8509. Run it from the office, VPN and other material networks, not only from a developer laptop on a separate connection.
4. Confirm ownership in writing
If a provider manages recursive DNS, ask for the resolver estate covered, readiness status, monitoring method, escalation contact and incident process. “DNS is managed” is not evidence unless the answer identifies which layer and service is being managed.
How to interpret a readiness test
The RFC 8509 root-key sentinel lets a client ask whether the resolver handling its query trusts a particular key tag. It is useful, but it is not a complete estate audit.
- Ready: the tested resolver path indicates that it trusts KSK-2024.
- Not ready: escalate to the resolver owner and follow the vendor's supported trust-anchor update guidance.
- Indeterminate or inconsistent: repeat the test and inspect the network design. Devices can use multiple resolvers, and some systems retry through another resolver after receiving
SERVFAIL.
A successful test from home does not prove an office resolver is ready. A successful public monitor does not prove a VPN or branch network is ready. Evidence should match the path used by the people and systems whose continuity matters.
Questions to ask your IT, hosting or network provider
- Do you operate DNSSEC-validating recursive resolvers for our staff, sites, VPNs or workloads?
- Which resolver products and versions are in service?
- Has KSK-2024 with key tag 38696 been verified on every active and standby resolver?
- Are automatic RFC 5011 trust-anchor updates enabled and able to write persistent state?
- How was readiness tested from our actual network paths?
- What alert identifies a rise in DNSSEC validation failures or
SERVFAILresponses? - Who owns the escalation on rollover day, including after-hours support?
- What is the supported recovery procedure if a resolver lacks the new trust anchor?
For businesses using Cloudflare authoritative DNS, 1.1.1.1 or Gateway DNS, Cloudflare says those services already trust KSK-2024. That assurance applies to the named Cloudflare service; still verify whether every location and device actually uses it.
Rollover-day monitoring plan
Use monitoring that can distinguish a website fault from a resolver-path fault.
| Layer | What to monitor | Why it matters |
|---|---|---|
| External website | DNS resolution and an HTTP journey from more than one network or resolver | Shows whether the public service is reachable beyond a single provider vantage point |
| Business network | Resolution of company, cloud and supplier domains from each critical site or VPN | Finds resolver-specific disruption that a public monitor can miss |
| Resolver | Validation errors, SERVFAIL rate, process health and upstream reachability | Identifies the failing layer before teams change the website |
| Applications | API failures, webhook queues, scheduled jobs and email-related DNS lookups | Detects machine-to-machine impact that browser checks do not cover |
| Support | Reports grouped by office, ISP, VPN and affected hostname | Reveals a shared DNS path across apparently unrelated incidents |
Capture a normal baseline before the rollover. During the change window, compare error rates and resolution behaviour against that baseline and keep a timestamped incident log.
If resolution fails after the rollover
- Confirm scope. Test the same hostname through the affected resolver path and a known healthy resolver. Record the exact time, network and response.
- Check for DNSSEC validation failure. Look for
SERVFAIL, validation logs and trust-anchor state before changing website infrastructure. - Escalate to the resolver owner. Internal teams should follow the installed product's supported recovery guidance. Provider-managed customers should use the pre-agreed incident contact.
- Protect evidence. Save resolver versions, configurations, logs and test results. Avoid untracked emergency edits that make later diagnosis harder.
- Communicate precisely. Tell users which networks are affected, what remains available and when the next update will be issued.
- Verify recovery end to end. Re-test websites, APIs, email-dependent services, VPN users and scheduled integrations after DNS resolution returns.
Changing nameservers, removing DNSSEC from a domain or republishing unrelated records can add risk without fixing a stale recursive trust anchor. Keep the response focused on the failing layer.
What the adoption data does—and does not—tell us
ICANN reported in July that more than 95% of resolvers sending the relevant trust-anchor signals had recognised and adopted KSK-2024. That is encouraging and helps explain why most users should notice nothing.
It is not a reason to skip a local check. The measurement describes reporting resolvers, not every private resolver, legacy appliance or isolated environment. APNIC's October discussion also emphasises the long, multi-year rollout and the operational importance of resolver behaviour.
The practical conclusion is balanced: do not create panic or make needless website changes, but do verify any validating resolver that your organisation operates or depends on.
Turn a one-day check into better DNS governance
The immediate rollover is a useful trigger to close recurring ownership, monitoring and recovery gaps.
Keep an estate register
Record authoritative DNS, registrar, recursive resolvers, DNSSEC status, owners, providers, support terms and renewal or review dates.
Monitor multiple paths
Combine public synthetic checks with tests from critical offices, VPNs and workloads so resolver-specific failures are visible.
Patch resolver software
Include recursive DNS and security appliances in maintenance, end-of-support and vulnerability-management routines.
Test failover
Confirm redundant resolvers are independently healthy and that clients do not silently depend on one shared failure domain.
Retain evidence
Keep configuration, test results and change records so future key events and incidents start from known state.
Review 2027 milestones
IANA schedules KSK-2017 revocation for 11 January 2027 and removal for 22 March 2027, so maintenance does not end on rollover day.
A practical business checklist
- Identify whether any business, branch, VPN, MSP or cloud environment operates a DNSSEC-validating recursive resolver.
- Verify KSK-2024 key tag 38696 on every resolver you control.
- Obtain provider confirmation for managed resolver paths.
- Run readiness checks from the real networks used by staff and systems.
- Baseline DNS, website, API and integration health before the rollover.
- Monitor from multiple resolver and network vantage points.
- Prepare an escalation path for DNS validation failures and
SERVFAIL. - Avoid changing authoritative DNS or domain signing unless diagnosis shows that layer is actually at fault.
- Retest business journeys after any resolver remediation.
- Review DNS ownership and monitoring again before the January and March 2027 milestones.
Business questions about KSK-2024
Sources checked
- IANA — DNSSEC Trust Anchors and Rollovers
- ICANN — Root Zone KSK Rollover
- ICANN — Preparing for the Root Zone KSK Rollover
- ICANN — Root Zone KSK Rollover FAQ
- Cloudflare — The keys to the Internet change on 11 October 2026
- APNIC — The October 2026 root KSK roll
- RFC Editor — RFC 5011 automated trust-anchor updates
- RFC Editor — RFC 8509 root key trust-anchor sentinel
Sources were accessed on 10 October 2026. Product and provider status can change, so confirm current operational guidance before modifying resolver configuration.