Root KSK Rollover on 11 October: Prevent DNS Failures

What happens on 11 October 2026

DNSSEC protects answers in the Domain Name System through a chain of signatures. At its upper end sits the Key Signing Key of the root zone, KSK for short. A validating resolver does not trust this key because it looks it up somewhere, but because it has stored it locally as a trust anchor. Every signature check, from the root via the top-level domain down to the individual domain, leads back to this anchor. That is why changing the root KSK is so delicate: if the stored anchor does not match the key that signs the root zone, the resolver can no longer confirm anything as authentic. How the chain is checked in detail and which failure patterns exist is covered in the article on monitoring DNSSEC validation.

The change has been under way for a long time. The current rollover began in 2024, and the new key was first published in the root zone on 11 January 2025 (ICANN). Since then both keys have sat side by side in the zone, while the old KSK-2017 has done the signing. On 11 October 2026 this flips: the root zone then publishes DNSKEY record sets signed exclusively by KSK-2024 (Verisign). Any validating resolver that has not added KSK-2024 to its trust anchors by then will see DNS resolution failures from that date (Verisign). ICANN puts it even more bluntly: without the new key, networks face total DNS resolution failures that cut off internet access for their users (ICANN). It is only the second change of this key in the history of the DNS (ICANN).

In addition, ICANN published updated guidance on 11 August 2026 that explains what operators should expect before, during and after the rollover (ICANN). It explicitly addresses three groups: operators of validating resolvers, vendors of DNS software and operators with manually configured trust anchors (ICANN). Anyone running a server with its own resolver belongs to the first group, often without knowing it.

Why the website stays green while the server goes blind

Reaching a website and reaching something from within a website are two different paths. A visitor who opens your address asks the resolver of their internet provider or company network for the IP address. Your server then answers an HTTP request for which it does not have to resolve any name itself. An availability check from outside follows exactly this path and therefore keeps reporting green on the deadline, even if the resolver on your server has been answering every query with SERVFAIL for hours. Things look different as soon as the server itself wants to reach out. It then asks the resolver entered in its configuration, and that is exactly the one that can fail after the deadline. These four paths are the most affected:

It is exactly this asymmetry that turns the rollover into a monitoring issue rather than just an item on the administration list. Anyone who only checks whether the home page responds measures the direction that stays intact on 11 October. The more revealing question is whether the server itself can still resolve names and open connections to the outside. What a failure of the validation chain looks like in practice was already shown by the outage of the .de zone: there, too, the fault was not on the affected websites but in the chain above them, and the impact depended on which resolver a system used.

How far the transition has progressed

The good news first: most resolvers are prepared. According to ICANN's analysis, more than 95 percent of reporting resolvers have recognised and adopted KSK-2024, and the curve runs almost exactly like the successful 2018 rollover (ICANN). Verisign arrives at a similar picture: after some 500 days, both rollovers show adoption of the new key above 95% (Verisign). These figures are based on trust anchor signals according to RFC 8145, which resolvers send to the root servers (Verisign). That is a sample of the resolvers that send such signals at all, as of July 2026 (Verisign), and not a full count of all resolvers on the internet. The table puts both rollovers side by side:

Why only now? The root zone has been signed with DNSSEC since 2010, and its KSK was changed for the first time in 2018 (Verisign). Originally, the key was meant to change every three years (Verisign). The pandemic interrupted the in-person key signing ceremonies in 2021 (Verisign), and a key generated in 2023 had to be discarded because the hardware security modules protecting it had reached end of support (Verisign). Only after that was today's KSK-2024 created.

The bad news lies in the remainder. About 3.5% of signalling sources still keep KSK-2010, a key created in 2010 and revoked in 2019 (Verisign). This shows how long an outdated anchor survives once a configuration has been frozen. On top of that, the sample only covers resolvers that send signals. A mail server in a virtual machine that has not been touched for years or an appliance in the server cabinet of a mid-sized company shows up in no statistic. For your own infrastructure, therefore, no percentage helps, only a look at the configuration. ICANN explicitly advises checking the configuration by hand rather than assuming that the automatic update worked (ICANN).

Which servers are most at risk

The risk does not lie with those who have enabled DNSSEC for their own domain, but with those who validate DNSSEC answers. As a rule, these are resolvers running on the server itself or in your own network. Look particularly closely at these setups:

• Servers with a local validating resolver - mail servers often use their own resolver so that queries for DANE or blocklists work reliably. These are exactly the resolvers that validate.
• Container images with a bundled anchor file - the file reflects the state on the day of the build. If the image dates from before January 2025, when the new key was first published in the root zone (ICANN), KSK-2024 may be missing from it until the image is rebuilt.
• Appliances and embedded systems - firewalls, routers and storage systems with a built-in anchor only receive a new key through a firmware update.
• Resolvers without write access to their anchor directory - the automatic update recognises the new key but cannot store it permanently (ICANN).
• Manually maintained trust anchors - for example in a static configuration file that was copied once during setup. The ICANN guidance explicitly names operators with manually configured anchors (ICANN).
• Systems recreated from an old image shortly before the deadline - they lack the time to adopt the key automatically.

Checklist: verify the trust anchor

The key you are looking for has the Key Tag 38696 (ICANN). Verisign gives the same value as the identifier of the correct key (Verisign). Where it is stored depends on the resolver software: for ISC BIND in bind.keys, for Unbound and PowerDNS Recursor in root.key, for Knot Resolver in root.keys (ICANN). The paths differ by distribution and package, but the file names are a good starting point for the search. Go through these steps for every server with its own resolver:

• Identify the resolver: which resolver is listed in /etc/resolv.conf or in the configuration of the network service? If the entry points to 127.0.0.1 or an address in your own network, you run a resolver yourself or use one inside the company. If it says 127.0.0.53, the local stub of systemd-resolved is at work: whether it validates itself is determined by its configuration, and its forwarding shows which resolver sits behind it.
• Find the anchor file and confirm that Key Tag 38696 is in it. If it is missing, the resolver is not prepared.
• Read the state where the software reports it: Unbound keeps a state according to RFC 5011 for every key in its anchor file. For KSK-2024 it should say VALID, not ADDPEND.
• Check write access: the resolver process must be allowed to write to the directory where it stores its keys, otherwise the automatic update has no effect (ICANN).
• Enable the automatic update where it is switched off, or update the software. According to Verisign, current versions in most cases ship with KSK-2024 or have picked it up via RFC 5011 (Verisign).
• Record the result: date, server, file, key tag found. On the Monday after the deadline this note is worth more than any recollection.

Container images and appliances: yesterday's anchor

The greatest risk rarely sits on the server that someone looks after every day. It sits in images that were built at some point and have only been started ever since. A container image that contains a resolver including its anchor file preserves the state of the day it was built. If the container runs long enough, RFC 5011 can update the anchor at runtime, provided the process may write and the directory is not discarded on every restart. If, on the other hand, the container is recreated regularly, every start begins with the old anchor again, and the observation period starts over each time. After 11 October, this cosmetic flaw turns into a complete failure of name resolution at the first start. The simplest way to catch this is at build time:

# Update the anchor at build time; unbound-anchor also exits with 1 when it has set a new anchor
RUN unbound-anchor -a /var/lib/unbound/root.key || true

# Abort the build if the trust anchor does not contain KSK-2024
RUN grep -q 38696 /var/lib/unbound/root.key \
    || (echo "Trust anchor without Key Tag 38696"; exit 1)

With appliances the path is shorter and harder at the same time. Shorter, because there is only one contact, the vendor. Harder, because the anchor often sits in the firmware and only changes with an update. For every firewall, router and storage system with built-in DNS, ask whether the installed version contains KSK-2024. That such stragglers are not a theoretical problem is shown by the history: the first rollover was planned for 2017 and postponed by one year because many operators had not yet updated their systems to the new key (ICANN). Verisign also used that time to reach out to software developers who had not updated the key in their code (Verisign).

What can go wrong on the day and how to recognise it

A missing anchor gives no warning. Until the deadline everything runs normally; afterwards, name resolution fails as soon as the resolver fetches the root zone keys again and can no longer confirm them. Because cached answers continue to be used until their validity expires, the outage does not necessarily arrive in the first minute. It can set in with a delay and at first affect only individual names. That makes troubleshooting tedious: one service still works, the next does not, and the connection to the rollover is not obvious. These symptoms are typical:

The last column is the core of the problem. An availability check from outside is blind to this fault because it uses the path that stays intact. There is also a side effect that can increase the damage: if name resolution only fails after a waiting period, requests hold on to their processes for longer. If enough page views depend on an interface whose name no longer resolves, the worker pool fills up, and at some point the website itself responds slowly or not at all. How this shows up in response times before the first 502 arrives is described in the article on worker pool exhaustion.

How XICTRAQ helps and where the limit is

A particularly reliable indicator of a resolver that no longer resolves is a signal the server itself has to send to the outside. That is exactly how XICTRAQ heartbeat monitoring works: a cron job on your server calls a ping address at a fixed rhythm. If the ping does not arrive within the configured tolerance, XICTRAQ raises an alert. The call needs a hostname and therefore the server's name resolution. If its resolver can no longer validate after the deadline, the ping stays away, and that is precisely the signal you need. Basics and patterns for this kind of monitoring are covered in the article on heartbeat monitoring for cron jobs.

#!/bin/sh
# Checks name resolution via this server's resolver and
# only reports in when all names resolve.
# Replace the example names with your own interfaces.
for host in payment.example.invalid shipping.example.invalid; do
  getent hosts "$host" >/dev/null || exit 1
done
curl -fsS --max-time 10 \
  https://api.xictraq.com/api/heartbeat/YOUR-ID/ping >/dev/null

# Crontab entry, every five minutes:
# */5 * * * * /usr/local/bin/dns-heartbeat.sh

The loop over the hostnames of your most important interfaces is more than duplication. The ping would stay away even without it, because api.xictraq.com also has to be resolved. The loop, however, catches the case in which one name still comes from the cache while another already fails. With getent, the script uses the same path via the system configuration as the mail server, PHP and most other programs on the server. An immediate failure report via the fail address does not help in this case, by the way, because it also needs a resolved name. Here, the absence is the signal. How to report the start, end and failure of a run separately is described in the heartbeat API documentation.

The second building block is API monitoring. Here XICTRAQ calls an endpoint from outside and checks the response, for example the HTTP status, the response time or a value in the JSON. This can be put to use for the rollover: set up a small check endpoint on your server that internally resolves the names of your payment and shipping interfaces and returns the result as JSON, for example in a field called dns_ok. XICTRAQ then measures the endpoint, and the endpoint measures your resolver. The home page stays green, the check endpoint reports the fault, and the alert travels through the same channels as all the others you have set up in alerting.

The third building block is DNS and domain monitoring with its DNSSEC check. It queries your domain via a public validating resolver and evaluates whether that resolver confirms the answer as authenticated. This tells you whether your own zone validates cleanly from outside. The public tool for checking a domain's DNSSEC also gives you a one-off look. For the rollover this is a helpful distinction: if your zone validates flawlessly outside while the heartbeat stays away, the cause most likely lies with your server's resolver and not with your domain.

On the day, it is not the website that fails but its view of the outside world. A check that only looks in from outside cannot see that. A server that has to report in by itself can.

— XICTRAQ

After the deadline: reading Monday morning correctly

If something fails on the day or the day after despite all preparation, a fixed order of steps helps. It prevents a team from spending hours searching interfaces and credentials although the cause lies one level deeper:

1. On the affected server, query a well-known name via the configured resolver. If SERVFAIL comes back while the same name resolves via another resolver, validation is the most likely cause.
2. Check the anchor file for Key Tag 38696 as described in the checklist above.
3. Update the anchor: bring the resolver software to a current version or regenerate the anchor file with the software's own tool, then restart the resolver.
4. Let queues drain: mail servers deliver the backlog as soon as resolution works again. Webhooks that have already been discarded, however, have to be triggered again deliberately.
5. Watch the heartbeat: once the ping arrives again, the path to the outside is clear.

A word on the shortcut that suggests itself in such moments: switching off DNSSEC validation removes the symptom immediately, but it also removes the protection against forged answers. Anyone using it as a stopgap should document the step and give it a fixed date for reversal. Otherwise a night with an outage becomes a year without validation.

Documenting this check has a second benefit. Anyone who manages servers for clients is increasingly asked for evidence that security risks are being actively handled. A note with date, server and key tag found is such evidence, as is the history of a heartbeat. What evidence insurers and clients typically want to see for websites is described in the article on cyber insurance and website evidence.