DNSSEC SERVFAIL after the October 2026 rollover: check the resolver, not just the date

If DNS started returning SERVFAIL after the root-key rollover, check whether the affected validating resolver actually trusts KSK-2024, key tag 38696. But first establish that validation—not an unreachable upstream server—is causing the failure.

The rollover occurred on 11 October 2026 at 14:00 UTC. In its 15 October update, ICANN reported that KSK-2024 began signing as scheduled, with no indications of widespread operational disruption. Its operator guidance still says to verify the new trust anchor rather than assume automatic updates succeeded. A local failure is not evidence of an Internet-wide incident. (ICANN rollover status)

What changed—and why unsigned names can fail too

The root KSK signs the root zone’s DNSKEY record set. A validating resolver uses its configured root trust anchor to authenticate that starting point, then follows the chain of trust toward the requested name.

IANA identifies KSK-2024, tag 38696, as the active signing key. KSK-2017, tag 20326, stopped signing on 11 October but remains published; its revocation is scheduled for January 2027. Finding the old key is therefore not itself an error. Relying on it alone is the problem. (IANA key status and schedule)

An unusable root anchor can affect unrelated domains, including unsigned domains: root-based validation also needs to authenticate the delegation where the signed chain ends. Cached data, separately configured trust anchors and resolver policy can make symptoms uneven rather than an immediate failure of every lookup. (RFC 4035, trust anchors, caching and referral authentication)

1. Query the resolver on the failing path

Identify the resolver the application actually uses. Account for local stubs, forwarding resolvers, VPN DNS and application-specific encrypted DNS. Test each relevant resolver separately; a healthy alternative does not prove the failing one is healthy.

These commands target a resolver listening locally on 127.0.0.1. Use the affected resolver’s numeric address instead when it is elsewhere, and substitute the failing name for iana.org:

dig -r @127.0.0.1 iana.org A +dnssec +nocdflag
dig -r @127.0.0.1 iana.org A +dnssec +cdflag

Keep the full output, including the status, flags, OPT pseudosection and server address. Avoid +short, which hides useful diagnostics.

• Normal query returns SERVFAIL; CD query returns an answer: this strongly points toward validation-related rejection on that path. It does not identify which key or zone failed.
• Both return SERVFAIL: inspect resolver logs and upstream reachability. The resolver may also be configured to ignore CD.
• Neither receives a response: investigate a timeout before calling it a DNSSEC failure. See how to find DNS timeouts in Wireshark.

+dnssec sets the DNSSEC OK (DO) bit, requesting DNSSEC records; it does not make dig validate them. +cdflag sets Checking Disabled (CD), requesting that the server return data without rejecting it for failed validation. Treat that data as diagnostic, not authenticated. (BIND’s dig documentation)

2. Look for a root failure, not merely a DNSSEC failure

Query the root DNSKEY set through the same resolver:

dig -r @127.0.0.1 . DNSKEY +dnssec +nocdflag +multiline
dig -r @127.0.0.1 . DNSKEY +dnssec +cdflag +multiline

A root query that fails normally but returns records with CD, combined with failures across unrelated names, makes the root trust anchor a strong suspect. A failure confined to one zone instead directs attention toward that zone’s signatures or parent DS/child DNSKEY relationship.

Seeing key 38696 in a DNS answer proves publication, not local trust. You must inspect the resolver’s trust-anchor state.

Also look for an Extended DNS Error (EDE) in the OPT pseudosection:

EDE	Diagnostic direction
5 — DNSSEC Indeterminate; 6 — DNSSEC Bogus	Inspect validation logs and the failing chain. Neither uniquely identifies a stale root anchor.
7 — Signature Expired; 8 — Signature Not Yet Valid	Check signature dates and the resolver’s system clock.
9 — DNSKEY Missing	Check the parent DS against the child’s supported DNSKEY records.
22 — No Reachable Authority; 23 — Network Error	Investigate upstream communication.

EDE is supplemental diagnostic information, not DNSSEC-authenticated proof of the cause. A secured DNS transaction can protect it in transit. Forwarders may omit it or replace it, so its absence does not rule out validation failure. (RFC 8914)

3. Read the packet fields at the right capture point

Capture only traffic and systems you own or are authorized to inspect. For visible, decoded DNS in Wireshark, use these display filters separately:

dns.flags.response == 1 && dns.flags.rcode == 2
dns.flags.checkdisable == 1
dns.opt.ext_error.info_code

The first finds SERVFAIL responses: a reply arrived, but the resolver could not complete the lookup successfully. The second locates CD-bearing messages for the comparison test. The third finds EDE-bearing messages; inspect the code and extra text. These fields are documented in the Wireshark DNS filter reference; the EDE fields require Wireshark 3.6 or later.

A client-side capture can show the rejection but cannot reveal which anchors the resolver trusts. A resolver-side capture may expose DNSKEY, DS and RRSIG exchanges, unless caches satisfy them or that upstream leg is encrypted. Pair packets with validator logs. An ordinary encrypted-DNS capture will not expose these DNS fields without authorized access to the decoded messages. Redact names, addresses, identifiers and sensitive payloads before sharing captures or logs.

If the client-to-resolver UDP exchange stalls or shows truncation, repeat the relevant dig query with +tcp. Success over TCP directs attention toward transport handling on that leg; it does not repair a trust anchor or force the resolver’s upstream queries to use TCP. dig normally retries truncated UDP responses over TCP. (BIND transport options)

4. Verify and repair the actual trust-anchor state

For BIND, with authorized access to its control channel:

rndc managed-keys status
rndc secroots -
rndc validation status

The first reports RFC 5011 managed-key state; the second prints security roots and negative trust anchors; the third checks whether validation is enabled. Inspect the root entry in the relevant view for trusted key 38696—not merely an initializing or pending key. (BIND control-command documentation)

For Unbound, inspect the file selected by the active auto-trust-anchor-file configuration and its tracked key state. Do not assume a file named root.key elsewhere is the one in use. If the deployment uses static anchors instead, inspect its configured trust-anchor-file or trust-anchor entries. Unbound’s automatic anchor maintenance requires write access to both the file and its containing directory, with the file inside the chroot when one is used. (Unbound configuration reference)

If 38696 is missing or not trusted:

1. Preserve the configuration, anchor state and relevant logs before changing them.
2. Follow the resolver vendor’s recovery procedure using current software and authenticated IANA trust-anchor data. Simply enabling automatic updates now is not proof of recovery.
3. Correct any persistence or configuration problem: permissions, read-only storage, an old restored image or the wrong configured file.
4. Load the repaired state using the vendor-prescribed restart or reload procedure, then verify the running resolver again.

IANA publishes the trust-anchor data and verification files and explicitly recommends vendor-specific update instructions. Do not install a key copied from a packet capture or an arbitrary troubleshooting page. (IANA trust-anchor distribution)

Unbound’s unbound-anchor is an update utility, not a read-only inspection command. Its documented workflow runs before starting Unbound and verifies downloaded anchor data. Its exit code alone is not a reliable success check: code 0 can also mean an error occurred. Use verbose diagnostics and inspect the resulting state. (unbound-anchor manual)

Verify recovery with validation still enabled

Repeat the normal queries without CD, including the root DNSKEY query and the originally failing name. Check multiple unrelated names through each affected resolver and confirm that validator logs no longer show the root failure. Allow cached errors to expire or clear them using the implementation’s documented procedure.

Confirm that validation is enabled and that no troubleshooting bypass remains—for example, a BIND negative trust anchor covering the tested name, or Unbound’s val-permissive-mode or an applicable domain-insecure setting. (BIND control commands, Unbound validation settings)

An AD response flag on an expected secure answer is the resolver’s assertion that it authenticated the data; rely on it only from a trusted resolver over a secure client-to-resolver channel. Its absence alone is not failure—an unsigned answer need not carry AD. (RFC 4035, AD handling)

Do not count “queries work after disabling DNSSEC” as recovery. Recovery means the affected running resolver trusts the current root anchor and resolves normally with validation enabled.