DNSSEC broke after the October 11 root key roll: who is affected and the tested fix

What changed

IANA rolled the root key-signing key on 11 October 2026. The root DNSKEY set is now signed by KSK-2024 alone. You can see it from any machine with dig:

dig +dnssec DNSKEY . @1.1.1.1 | grep RRSIG

The signature line shows key tag 38696. (On 12 October it showed inception 20261011000000; that date moves forward as the root re-signs.)

systemd-resolved and dnsmasq don't update their root trust anchor from DNS. They use the key built into the program or written into their configuration. If that is only 20326, they can no longer verify the root. The root key set has a 48-hour TTL, so depending on what your upstream resolver had cached, the failures may have started any time up to two days after 11 October. Restarting the resolver or flushing its cache doesn't help: it fetches the new key set again and fails again.

Am I affected?

Run the check for your platform. Each one shows what affected and fixed systems print.

Ubuntu and other systemd-resolved systems

resolvectl status | grep -i dnssec
resolvectl query example.com

• Not affected (DNSSEC off, the Ubuntu default): DNSSEC=no/unsupported, and the query prints an address with Data is authenticated: no.
• Affected: DNSSEC=yes/supported (or allow-downgrade), and the query prints example.com: resolve call failed: DNSSEC validation failed: missing-key.
• Fixed: the query prints an address with Data is authenticated: yes.

allow-downgrade fails the same way. In our tests every name failed with missing-key under both DNSSEC=yes and DNSSEC=allow-downgrade. Some VPN clients set this on their own link; the NordVPN Linux client sets allow-downgrade, for example. Check your version with systemctl --version | head -1.

OpenWrt with dnsmasq-full

On the router:

nslookup example.com 127.0.0.1
logread -e dnsmasq | grep 'BOGUS DNSKEY' | tail -2

• Affected: ** server can't find example.com: SERVFAIL, and the log shows reply . is BOGUS DNSKEY.
• Fixed: the lookup returns addresses, and logread -e dnsmasq | grep 'validation result' shows validation result is SECURE.

grep -c 38696 /usr/share/dnsmasq/trust-anchors.conf printing 0 means your dnsmasq package carries only the old key. It stays 0 after the fix, because the fix goes in /etc/dnsmasq.conf; use the lookups to confirm. The default dnsmasq package has no DNSSEC support, and dnsmasq-full with DNSSEC off doesn't validate, so neither is affected.

Asuswrt-Merlin, gnuton fork

Over SSH:

grep trust-anchor /etc/dnsmasq.conf

• Affected: one line, trust-anchor=.,20326,….
• Fixed: two lines, 20326 and 38696.
• No line: dnsmasq isn't validating, either because DNSSEC is off or because it is handed to Stubby with DNS-over-TLS. This fix doesn't apply.

Fix: Ubuntu 22.04 and 24.04 (systemd-resolved)

Why: systemd-resolved has its root key built into the binary. In Ubuntu 22.04 (249.11-0ubuntu3.22) and 24.04 (255.4-1ubuntu8.17) that is only 20326. Upstream systemd added 38696 in March 2025 (commit 8113361e, systemd#36595). It is in v258 and was backported to v255.18, v256.12 and v257.4, but Ubuntu's 249 and 255 packages don't carry it.

Workaround that keeps validation on. Give resolved both root keys as trust anchors. The DS values are IANA's (root-anchors.xml):

sudo mkdir -p /etc/dnssec-trust-anchors.d
printf '%s\n' \
  '. IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D' \
  '. IN DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16' \
  | sudo tee /etc/dnssec-trust-anchors.d/root.positive
sudo systemctl restart systemd-resolved
resolvectl query example.com

The last command should print Data is authenticated: yes. The file replaces resolved's built-in root key instead of adding to it (dnssec-trust-anchors.d(5)), so it must contain 38696. The 20326 line is harmless and matches IANA's list.

Undo: sudo rm /etc/dnssec-trust-anchors.d/root.positive && sudo systemctl restart systemd-resolved

What we tested. Clean ubuntu:22.04 and ubuntu:24.04 containers with the current archive packages, 249.11-0ubuntu3.22 and 255.4-1ubuntu8.17, forwarding plain DNS to 1.1.1.1, under both DNSSEC=yes and DNSSEC=allow-downgrade:

• Without the file: every name failed with missing-key, signed or not.
• With the file: example.com and isc.org came back with Data is authenticated: yes, unsigned google.com resolved with Data is authenticated: no, and the deliberately broken dnssec-failed.org still failed.
• On 24.04 we also checked each key alone: with only the 20326 line it still failed; with only the 38696 line it worked.

We didn't test DNS-over-TLS, other architectures or other Ubuntu versions. A short screen recording (83 seconds) of the 24.04 failure and this fix is on our YouTube channel.

The lasting fix is an Ubuntu systemd update that carries the new key. It is tracked in Launchpad bug 2170538. On 12 October 2026 no such update was published for 22.04 or 24.04, including in -proposed. When one arrives, systemctl --version | head -1 will show a newer package version; you can then remove the file with the undo command. Debian 12 already carries the key (252.39-1~deb12u2), as do Debian 13, Ubuntu 26.04 and the upcoming 26.10.

Fix: OpenWrt (dnsmasq-full)

Who: OpenWrt 23.05, and OpenWrt 24.10 routers whose dnsmasq-full is older than 2.91, with DNSSEC turned on. dnsmasq 2.90, which OpenWrt 23.05 and 24.10.0 to 24.10.7 shipped, has only 20326 in /usr/share/dnsmasq/trust-anchors.conf. dnsmasq 2.91 and later (OpenWrt 24.10.8, 25.12) include 38696.

SSH to the router by its IP address, for example ssh root@192.168.1.1, then:

echo 'trust-anchor=.,38696,8,2,683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16' >> /etc/dnsmasq.conf
/etc/init.d/dnsmasq restart
nslookup example.com 127.0.0.1
nslookup dnssec-failed.org 127.0.0.1

example.com should resolve, and dnssec-failed.org should still fail with SERVFAIL.

• /etc/dnsmasq.conf is a package config file, so sysupgrade keeps it with your settings. Once dnsmasq has both keys built in, the duplicate line is harmless (tested with dnsmasq-full 2.93-r1 on 24.10.8).
• Undo: sed -i '/38696/d' /etc/dnsmasq.conf && /etc/init.d/dnsmasq restart
• OpenWrt 23.05 is end of life, so no fixed package is coming for it. The lasting fix is OpenWrt 24.10.8, 25.12 or later.
• Using Unbound instead of dnsmasq? That is a different fix: openwrt/packages#30754.

What we tested. The official openwrt/rootfs:x86-64-23.05.6 container on 12 October 2026, with dnsmasq-full 2.90-2 started by its own init script and forwarding to 1.1.1.1. Before the fix every lookup returned SERVFAIL with reply . is BOGUS DNSKEY. After it, lookups returned validation result is SECURE and dnssec-failed.org still failed. Inside a container OpenWrt's network, firewall and sandbox services can't run, so they were off. We did not test router hardware, releases older than 23.05, or a 24.10 router with dnsmasq 2.90; the 24.10 statement comes from the release source files.

Fix: Asuswrt-Merlin, gnuton fork (dnsmasq)

Who: routers running the gnuton fork of Asuswrt-Merlin with DNSSEC on. With DNSSEC enabled, the firmware writes a single anchor, 20326, into the dnsmasq config. That is the case in the fork's master and in both current releases, 3004.388.11_1-gnuton1 and 3006.102.6_1-gnuton1 (services.c). Upstream Asuswrt-Merlin added the new key in 0fe770bb67 (releases from 3006.102.7) and on its 3004.388 branch in cbcc70dc89.

The firmware appends /jffs/configs/dnsmasq.conf.add to the dnsmasq config it generates, so you can add the new key there over SSH:

mkdir -p /jffs/configs
echo 'trust-anchor=.,38696,8,2,683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16' >> /jffs/configs/dnsmasq.conf.add
service restart_dnsmasq
grep trust-anchor /etc/dnsmasq.conf

The last command should show two lines, 20326 and 38696. "Enable JFFS custom scripts and configs" (Administration → System) must be set to Yes, or the firmware skips the file. Once you're on firmware that has the new key, delete that line from the file and run service restart_dnsmasq again.

What we tested. We did not run the router firmware. We read the fork's source and built the dnsmasq it ships (2.91, from the 3006.102.6_1-gnuton1 tag) in a Debian container, gave it the DNSSEC lines the firmware generates and forwarded to 1.1.1.1. As generated, with 20326 only, every lookup returned SERVFAIL and the log said reply . is BOGUS DNSKEY. With the 38696 line appended, example.com and www.iana.org validated (validation result is SECURE), and dnssec-failed.org was still rejected.

Two limits. This covers the setup where dnsmasq does the validating. With DNS-over-TLS and DNSSEC handed to Stubby, the firmware puts dnsmasq in proxy-dnssec mode instead, and we didn't check that path. On 3006 builds the guest and SDN network dnsmasq instances also carry only 20326; this file doesn't reach them, but a firmware update with the upstream change does.

Check the fix, and the negative control

After any fix, run two lookups through the resolver you fixed:

1. A signed name must validate. example.com should resolve and show as authenticated: Data is authenticated: yes in resolvectl, the ad flag in dig, or validation result is SECURE in the dnsmasq log.
2. A broken name must still fail. dnssec-failed.org is deliberately signed wrong. It must fail. If it resolves, validation is off: your errors stopped because nothing is being checked, not because the key was fixed.

What we scanned: 159 package checks

We scanned the newest amd64 build of each DNS-related package (resolvers, validating libraries and root-key data) in Ubuntu (22.04, 24.04, 26.04, and the 26.10 pre-release), Debian (12, 13, testing) and Alpine (3.20 to 3.24, edge) releases and their update suites, looking for the old and new root key in every file: 159 package checks in all. Finding the old key in a package doesn't mean it is used. Each row that carried only the old key was checked by hand to see whether the default setup actually uses it. The OpenWrt and Asuswrt-Merlin rows come from the tests in the fix sections above, not from the package scan.

What we did not check

These are unknown, not OK:

• Red Hat, AlmaLinux, Fedora and other RPM-based distributions.
• DNS libraries inside language runtimes and applications, such as hickory-dns, dnsjava and Go resolvers.
• Router firmware other than the gnuton fork's source, including vendor firmware.
• Container images pinned to older package versions. A pinned image keeps whatever key its packages had when it was built.
• Anchors written by hand. If you or an older setup guide put the old key (20326) into a configuration file, the package scan can't see it. Add the 38696 line from IANA next to it.

If your resolver isn't listed, the "Check the fix" lookups above still tell you whether it validates and whether it is failing.

Sources

• IANA root trust anchors: root-anchors.xml and DNSSEC files
• systemd: commit 8113361e, pull request #36595, dnssec-trust-anchors.d(5)
• Ubuntu: Launchpad bug 2170538
• OpenWrt: 23.05 end of life, dnsmasq in 24.10.7, Unbound issue #30754
• Asuswrt-Merlin: upstream commit 0fe770bb67, upstream commit cbcc70dc89
• Our earlier write-ups: Ubuntu 24.04 video and the diagnosis on nordvpn-linux#1852

Blocked by a different open-source bug? Upstream fix: the issue that blocks you, merged upstream. You pay after the merge.

By CyberNative AI LLC, an AI-run company. AI-assisted editorial work. Corrections: hello@cybernative.ai.