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.

BIND and Unbound can follow a key roll on their own (RFC 5011), but only by trusting a new key that a key they already trust has signed. A server that kept running while both keys were published, well before the roll, most likely learned the new key that way; we didn't test that case. A new install that starts with only 20326 can't: no key it trusts signs the root key set any more.

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.

BIND, Unbound or PowerDNS Recursor

On the server:

dig @127.0.0.1 example.com
dig @127.0.0.1 google.com

• Affected: both print status: SERVFAIL. google.com isn't signed, so a failure there points at the root key, not the domain. Unbound adds EDE: 6 (DNSSEC Bogus) and PowerDNS Recursor 5 adds EDE: 9 (DNSKEY Missing). BIND logs DNSKEY set for zone '.' could not be verified with current keys.
• Fixed: example.com prints status: NOERROR with ad in the flags: line, and google.com prints status: NOERROR.

To see whether the packaged key file has the new key on Amazon Linux 2023: grep -c 38696 /etc/named.root.key for BIND, or grep -c 38696 /var/lib/unbound/root.key for Unbound. 0 means the file has only the old key. A BIND server that has run since before the roll can still trust the new key through its key database, so the lookups above are the real test. On Ubuntu 20.04 and Debian 11 the file is /etc/bind/bind.keys; the section for those releases has a direct check.

Pi-hole v5

On the Pi-hole host (in Docker, open a shell in the container first, for example docker exec -it pihole bash):

grep -h -E '^(dnssec|trust-anchor)' /etc/dnsmasq.d/*.conf

• Affected: dnssec and one line, trust-anchor=.,20326,….
• Fixed: a second line, trust-anchor=.,38696,….
• No dnssec line: DNSSEC is off, so Pi-hole isn't validating. Nothing to fix.

Look for 38696, not 20326. A fixed setup still has the 20326 line, so finding 20326 tells you nothing. pihole -v shows your version; v6 isn't affected.

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. Before the 14 October update, Ubuntu 22.04 (249.11-0ubuntu3.22) and 24.04 (255.4-1ubuntu8.17) had 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 didn't carry it until that update.

Fix: upgrade. On 14 October 2026 Ubuntu published systemd 249.11-0ubuntu3.23 for 22.04 and 255.4-1ubuntu8.18 for 24.04 as security updates. They add 38696 to the built-in key. Run sudo apt update && sudo apt upgrade, then systemctl --version | head -1 should show the new version. We checked both published packages on 14 October: with no workaround file, signed names came back authenticated, unsigned names still resolved, and the deliberately broken dnssec-failed.org still failed. If you added the workaround file below, remove it with the undo command only once the new version shows. The update carries the backport we attached to Launchpad bug 2170538; here is how it got into Ubuntu.

If you can't upgrade yet: a 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.

Use the DS lines exactly; DNSKEY lines don't work here. With both root keys written as DNSKEY records instead, resolved loads them and still fails every lookup with missing-key (systemd#44145). We reproduced that on Ubuntu 22.04, 24.04 and 26.04 and on Debian 13. Don't copy /usr/share/dns/root.key into the directory either; it fails the same way. In our tests resolved couldn't even parse its lines (it logs Failed to parse DNSKEY key data), skipped them and fell back to its built-in key, which on 22.04 and 24.04 is the old one. /usr/share/dns/root.ds has the same two DS lines as the command above, byte for byte, so if the dns-root-data package is installed (minimal server images may not have it), sudo cp /usr/share/dns/root.ds /etc/dnssec-trust-anchors.d/root.positive writes the same file.

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 archive packages from before the update, 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 or other architectures. Ubuntu 20.04 has its own section below. A short screen recording (83 seconds) of the 24.04 failure and this fix is on our YouTube channel.

Other releases. Debian 12 already carries the key (252.39-1~deb12u2), as do Debian 13, Ubuntu 26.04 and the upcoming 26.10.

Fix: Ubuntu 20.04 and Debian 11 (BIND and systemd-resolved)

Why BIND fails: the newest public builds, 1:9.18.30-0ubuntu0.20.04.2 on Ubuntu 20.04 and 1:9.16.50-1~deb11u6 on Debian 11, validate by default (dnssec-validation auto) and take the root key from /etc/bind/bind.keys. That file holds only 20326. Since 11 October a server that starts from it fails every lookup, unsigned names included. On 13 October 2026 neither release had a fixed build in its public archive.

Who is hit: new installs, rebuilt containers and VMs, and servers that lost the key database in /var/cache/bind. A server that has kept running with that database since early 2025, when the new key was first published, should have learned 38696 on its own; we didn't test that case.

Check:

sudo rndc managed-keys status

• Fine: the output lists keyid: 38696 as trusted.
• Affected: it shows keyid: 0 with no trust, or only keyid: 20326.

Fix. Add the KSK-2024 line to /etc/bind/bind.keys, clear the key database while named is stopped, and start it again:

grep -q 38696 /etc/bind/bind.keys || sudo sed -i 's|^};|\t. initial-ds 38696 8 2 "683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16";\n};|' /etc/bind/bind.keys
grep -c 38696 /etc/bind/bind.keys
sudo systemctl stop named
sudo rm -f /var/cache/bind/managed-keys.bind /var/cache/bind/managed-keys.bind.jnl
sudo systemctl start named
sudo rndc managed-keys status
dig @127.0.0.1 example.com

grep -c should print 1; the first line does nothing if the key is already there. You can also add the line by hand inside the trust-anchors { … }; block, next to the existing key:

. initial-ds 38696 8 2 "683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16";

named rebuilds the key database from bind.keys when it starts. rndc should then list 20326 and 38696 as trusted, and dig should print status: NOERROR with the ad flag. If your configuration uses views, each view keeps its own database in /var/cache/bind, in files ending in .mkeys and .mkeys.jnl; remove those too.

If your configuration sets dnssec-validation yes, named doesn't use bind.keys; it trusts only the root key in your own configuration. Find that block (trust-anchors, managed-keys or trusted-keys, with a line starting .) and replace it with this one. Don't add this block next to an old managed-keys or trusted-keys block: named rejects the configuration and won't start.

trust-anchors {
    . initial-ds 20326 8 2 "E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D";
    . initial-ds 38696 8 2 "683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16";
};

Then check the configuration and restart:

sudo named-checkconf && sudo systemctl restart named
sudo rndc managed-keys status

named-checkconf prints nothing when the configuration is valid. rndc should list 20326 and 38696 as trusted.

systemd-resolved on Ubuntu 20.04 (245.4-4ubuntu3.24) and Debian 11 (247.3-7+deb11u8) also has only 20326 built in. DNSSEC is off by default. With DNSSEC=yes or allow-downgrade, every lookup fails with missing-key, as on 22.04 and 24.04, and the DS-line file from the Ubuntu 22.04 and 24.04 fix works unchanged. Keep it until a systemd update that carries the new key is published for your release; on 13 October 2026 neither release had one.

Debian 11 package sources. Debian 11's security updates have moved to archive.debian.org/debian-security. On 13 October a stock debian:11 image couldn't install bind9 from its default sources: security.debian.org and deb.debian.org still list the packages but return 404 for the files. For the test we changed the security line in /etc/apt/sources.list to deb http://archive.debian.org/debian-security bullseye-security main and ran sudo apt-get update.

What we tested. Fresh ubuntu:20.04 and debian:11 containers, fully updated on 13 October 2026. named forwarded to 1.1.1.1 and still validated.

• As packaged: isc.org, example.com, google.com and dnssec-failed.org all returned SERVFAIL, and rndc managed-keys status showed keyid: 0 with no trust.
• With the line in bind.keys (auto kept): isc.org and example.com returned NOERROR with ad, google.com returned NOERROR, dnssec-failed.org still failed, and rndc listed 20326 and 38696 as trusted.
• With dnssec-validation yes and the two-line block: the same results, whether it replaced an old 20326-only block or was the only one. Next to an old managed-keys or trusted-keys block, named-checkconf failed.
• systemd-resolved: without the file, every name returned SERVFAIL (resolvectl reported missing-key) under both DNSSEC=yes and allow-downgrade; with it, example.com returned Data is authenticated: yes and dnssec-failed.org still failed.

We ran named and resolved directly in the containers, not through systemd. We didn't test the Ubuntu Pro (ESM) or Debian Extended LTS builds, or a server that has run since before the roll.

Fix: Amazon Linux 2023 (BIND and Unbound)

BIND

Fix: upgrade. Since Amazon Linux 2023 release 2023.12.20261013 (13 October), the bind package has both keys in /etc/named.root.key: bind-9.18.50-1.amzn2023.0.4 and later, with 0.5 current. An instance or container image from an older release is locked to that release, so a plain dnf upgrade reports "Nothing to do". rpm -q system-release shows your release. Ask for the latest release, then restart named:

sudo dnf upgrade --releasever=latest bind
grep initial-ds /etc/named.root.key
sudo systemctl restart named
dig @127.0.0.1 example.com

grep should show two initial-ds lines, 20326 and 38696. dig should print status: NOERROR with the ad flag. If dnf says No match for argument: bind, BIND isn't installed; skip this part. Restart even if the upgrade looks complete. In our container, named kept failing until it was restarted or told to reload. On a systemd host the package update normally asks named to reload by itself, but we didn't test that.

If you already added the 38696 line by hand (the fix below), dnf keeps your edited file and prints warning: /etc/named.root.key created as /etc/named.root.key.rpmnew. That's expected. Your file already has both keys, as the grep shows, so leave it in place and don't run the Undo line below.

Why it broke: the packaged /etc/named.conf turns validation on with dnssec-validation yes; and reads its root key from /etc/named.root.key. Up to bind-9.18.50-1.amzn2023.0.3, the newest build on 12 October, that file held only 20326, and named doesn't fetch a key from anywhere else. On a new install, or a new instance or container, every lookup failed, unsigned names included.

If you can't upgrade yet, add the KSK-2024 line next to the existing one and restart named:

sudo sed -i 's|^\(\s*\)\(\. initial-ds 20326 .*\)$|\1\2\n\1. initial-ds 38696 8 2 "683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16";|' /etc/named.root.key
grep initial-ds /etc/named.root.key
sudo named-checkconf && sudo systemctl restart named
dig @127.0.0.1 example.com

grep should show two initial-ds lines, 20326 and 38696. You can also add the line by hand inside the trust-anchors { … }; block:

. initial-ds 38696 8 2 "683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16";

dig should print status: NOERROR with the ad flag. named logs DNSKEY ID 38696 is now trusted when it starts from an empty key database.

Undo, only before you upgrade: sudo sed -i '/initial-ds 38696/d' /etc/named.root.key && sudo systemctl restart named. After an upgrade it removes the only 38696 line, because the upgrade kept your file, and named fails again, at once or when its key database is next reset.

What we tested. On 12 October, a fresh amazonlinux:2023 container (release 2023.12.20260930) with the packaged config. The only change was forwarding to 1.1.1.1 (forward only), and named still validated.

• As packaged: isc.org, example.com, google.com and dnssec-failed.org all returned SERVFAIL.
• With the line: isc.org and example.com returned NOERROR with ad, google.com returned NOERROR, and dnssec-failed.org still failed.
• Already started once: on a server that had already started after the roll with only the old key, adding the line and restarting was enough. We didn't have to delete the key database in /var/named/dynamic.

On 30 October we tested the upgrade in the same image, with BIND and Unbound installed and both failing:

• Plain dnf upgrade bind unbound-libs: "Nothing to do"; the image stays on its own release.
• With --releasever=latest: bind moved to 0.5 and unbound to 1.17.1-1.amzn2023.0.17, and both key files then held 20326 and 38696. The running servers still failed until we restarted them or sent them a reload signal.
• After the restart: isc.org and example.com returned NOERROR with ad, google.com returned NOERROR, and dnssec-failed.org still failed, on both BIND and Unbound.
• New install from the current repository: the same results with no change.
• Line added by hand first, then upgraded: BIND kept our edited named.root.key and wrote Amazon's copy as .rpmnew. Unbound replaced our edited root.key and saved ours as .rpmsave. Both then returned NOERROR with ad for isc.org and example.com. Removing the 38696 line from BIND's kept file afterwards made every name fail again once named's key database was reset.

We ran named with the service's own command line in a container, not through systemd on EC2. Fedora, CentOS Stream and AlmaLinux ship both keys in named.root.key.

Unbound

Fix: upgrade. Since the same 13 October release, unbound-libs has both keys in /var/lib/unbound/root.key: 1.17.1-1.amzn2023.0.16 and later, with 0.17 current. As with BIND, an older instance or image needs --releasever=latest:

sudo dnf upgrade --releasever=latest unbound-libs
grep -c 38696 /var/lib/unbound/root.key
sudo systemctl restart unbound
dig @127.0.0.1 example.com

grep should print 1. Restart for the same reason as named. The upgrade always replaces this file: in our test it did so after Unbound had already started and failed with the old one. If you had added the line by hand, dnf saves your copy as root.key.rpmsave and prints a warning; the new file has both keys. If dnf says No match for argument: unbound-libs, Unbound isn't installed; skip this part. In a container image, run the upgrade in the build. A build from the current amazonlinux:2023 tag (release 2023.12.20261021 on 30 October) already installs the fixed package.

Why it broke: up to unbound-libs-1.17.1-1.amzn2023.0.15, the newest build on 12 October, the packaged root key file, /var/lib/unbound/root.key, held only 20326. On a normal systemd host this usually repairs itself. Starting unbound.service first starts unbound-anchor.service, which downloads IANA's signed key file and rewrites root.key. Unbound fails every lookup with SERVFAIL and EDE: 6 (DNSSEC Bogus) when it starts with the old file and without that step:

• containers that run unbound -d directly;
• hosts with DISABLE_UNBOUND_ANCHOR=yes in /etc/sysconfig/unbound, or with unbound-anchor.service masked;
• presumably, hosts that can't reach data.iana.org over HTTPS, since that is where the update comes from (we didn't test this).

If you can't upgrade yet, add the KSK-2024 line to the key file and restart Unbound:

echo '. IN DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16' | sudo tee -a /var/lib/unbound/root.key
sudo systemctl restart unbound
dig @127.0.0.1 example.com

In a container image, add the same echo … >> /var/lib/unbound/root.key line to the build. Running unbound-anchor -a /var/lib/unbound/root.key before Unbound starts, then chown unbound:unbound /var/lib/unbound/root.key, also worked in our test.

What we tested. On 12 October, the same container image with the packaged unbound.conf. The only change was forwarding to 1.1.1.1 over TLS, and Unbound still validated.

• As packaged: all four names returned SERVFAIL with EDE: 6 (DNSSEC Bogus).
• With the line, or after unbound-anchor: isc.org and example.com returned NOERROR with ad, google.com returned NOERROR, and dnssec-failed.org still failed.
• The service path: we ran the command unbound-anchor.service runs, as the unbound user with the packaged options. It printed success: the anchor has been updated using the cert, and the file then held 20326 and 38696.

The 30 October upgrade test is in the BIND part above. We didn't run systemd itself or test on EC2.

Fix: PowerDNS Recursor (openSUSE Leap 16.0, EPEL 8 and 9)

Who:

• openSUSE Leap 16.0, pdns-recursor-5.1.1. The packaged /etc/pdns/recursor.conf sets dnssec=validate, and the recursor's built-in root key is 20326 only, so every lookup fails. PowerDNS added the new key upstream in 5.1.4; openSUSE Tumbleweed (5.2.5) has it.
• EPEL 8 and 9, pdns-recursor-4.8.9. The default is dnssec=process. Ordinary lookups from programs still resolve, without validation. Every query that asks for validation fails with SERVFAIL, including dig's default query and clients that set the AD bit.

Fix. Give the recursor the new key in a Lua config file. On openSUSE Leap 16.0:

echo "addTA('.', '38696 8 2 683d2d0acb8c9b712a1948b27f741219298d0a450d612c483af444a4c0fb2b16')" | sudo tee /etc/pdns/ksk2024.lua
echo 'lua-config-file=/etc/pdns/ksk2024.lua' | sudo tee -a /etc/pdns/recursor.conf
sudo systemctl restart pdns-recursor
dig @127.0.0.1 example.com

On EPEL the config directory is /etc/pdns-recursor/, so use /etc/pdns-recursor/ksk2024.lua and /etc/pdns-recursor/recursor.conf. If your recursor.conf already sets lua-config-file, add the addTA line to that file instead. addTA adds to the built-in key; it doesn't replace it (PowerDNS docs).

With dnssec=process the recursor validates only for clients that ask. Run the negative control with plain dig, which asks: dig @127.0.0.1 dnssec-failed.org must return SERVFAIL. dig +noad resolves it by design.

What we tested. Fresh openSUSE Leap 16.0 and AlmaLinux 9 with EPEL containers on 12 October 2026, with the packaged configs. The only change was forwarding to 1.1.1.1, and the recursor still validated.

• Leap, as packaged: every name failed with EDE: 9 (DNSKEY Missing), with or without validation asked for.
• EPEL 9, as packaged: plain lookups resolved without validation. Every dig default query failed, unsigned google.com included.
• With addTA: isc.org and example.com returned NOERROR with ad, google.com returned NOERROR, and dnssec-failed.org still failed for validating queries.

We didn't run EPEL 8, which carries the same version, and we ran the recursor directly, not through systemd.

Fix: Pi-hole v5 with DNSSEC on

Who: Pi-hole v5, installed directly or from the Docker images up to pihole/pihole:2024.07.0, with "Use DNSSEC" turned on. It is off by default. When it is on, Pi-hole v5 writes one root key, 20326, into /etc/dnsmasq.d/01-pihole.conf (webpage.sh in v5.18.3). Every lookup it forwards upstream then fails for every device that uses the Pi-hole, unsigned names included, and the Pi-hole log shows reply . is BOGUS DNSKEY. Pi-hole v6 has the new key built in (FTL pull request #2018) and isn't affected.

Fix. Put the new key in a file of its own. Pi-hole rewrites 01-pihole.conf whenever its settings change, but doesn't touch a file of your own in /etc/dnsmasq.d:

echo 'trust-anchor=.,38696,8,2,683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16' | sudo tee /etc/dnsmasq.d/99-ksk-2024.conf
pihole restartdns

In Docker, create the same file, 99-ksk-2024.conf with that one line, in the host folder you mount at /etc/dnsmasq.d (./etc-dnsmasq.d in Pi-hole's example setup), then restart the container. Without that mount, a file you add inside the container is lost when the container is recreated.

Upgrading to Pi-hole v6 also fixes it.

Undo: sudo rm /etc/dnsmasq.d/99-ksk-2024.conf && pihole restartdns. In Docker, delete the file from the mounted folder and restart the container.

What we tested. A fresh pihole/pihole:2024.07.0 container (FTL v5.25.2) on 12 October 2026, with DNSSEC=true and 1.1.1.1 as the upstream server.

• As shipped: isc.org, example.com and google.com returned SERVFAIL with EDE: 6 (DNSSEC Bogus). Plain queries without the AD flag, as most devices send, failed too.
• With the file: isc.org and example.com returned NOERROR with ad, google.com returned NOERROR, and dnssec-failed.org still failed. We added the file before Pi-hole started; it stayed in place when Pi-hole wrote its own 01-pihole.conf at start.

We didn't run a bare-metal Pi-hole or pihole restartdns. Bare-metal v5 writes its dnsmasq config with the same script.

Fix: DNS server Docker images

A container starts from the files in its image each time it is created. A root key the server learned while running is lost unless it is stored on a volume. So an image built with only the old key now fails every time its container is created or recreated.

On 12 October 2026 we checked the current tag of 10 popular DNS server images and the last Pi-hole v5 image. We ran each one except klutchell/unbound as a fresh container with its default settings, apart from the changes noted below. Pull counts are Docker Hub's on the same day.

PowerDNS lists Recursor 4.x, 5.0, 5.1 and 5.2 as end of life. None of the images above with the old key has been updated since 2024, so keep the fixes below until you move to a maintained image.

BIND images. Add this line to named.conf.local:

trust-anchors { . initial-ds 38696 8 2 "683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16"; };

• sameersbn/bind: on first start the image moves its config into the data volume. Add the line to bind/etc/named.conf.local in the volume you mount at /data, then restart the container.
• cytopia/bind: add it in your own image built on cytopia/bind:

FROM cytopia/bind:latest
RUN echo 'trust-anchors { . initial-ds 38696 8 2 "683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16"; };' >> /etc/bind/named.conf.local

secns/unbound. Build your own image with the new key added to the key file:

FROM secns/unbound:latest
RUN echo '. IN DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16' >> /usr/local/etc/unbound/root.key

Don't mount a single root.key file into the container instead. Unbound updates the file by replacing it, which fails on a mounted file, and Unbound exits.

PowerDNS Recursor 4.8 and 4.9 images. Write the new key into a Lua file:

echo "addTA('.', '38696 8 2 683d2d0acb8c9b712a1948b27f741219298d0a450d612c483af444a4c0fb2b16')" > ksk2024.lua

Mount it into the container, for example with -v "$PWD/ksk2024.lua:/etc/powerdns/ksk2024.lua:ro", and add --lua-config-file=/etc/powerdns/ksk2024.lua after the image name, where the recursor's options go. If your setup already uses a Lua config file, add the addTA line to that file instead. As with EPEL, run the negative control with plain dig, which asks for validation.

What we tested. A fresh container of each image's current tag, with its default settings. Where the image resolves from the root servers itself, we changed one thing: forwarding to 1.1.1.1. Validation still ran in the image.

• As shipped: sameersbn/bind, secns/unbound and cytopia/bind (with validation on) returned SERVFAIL for isc.org, example.com and google.com. The PowerDNS 4.8 and 4.9 images answered plain queries but returned SERVFAIL for every query that asks for validation, including dig's default.
• With the fixes: isc.org and example.com returned NOERROR with ad, google.com returned NOERROR, and dnssec-failed.org still failed.
• How we applied them: we added each line inside the container before the image's own start script ran, which is what the build step does. We didn't build the images. For sameersbn/bind we edited the config before its first start, not the copy in the volume. For PowerDNS we created the Lua file inside the container rather than mounting it, and passed it with --lua-config-file.

A container that keeps its key database on a volume and has run since before the roll may have learned the new key; we didn't test that. sameersbn/bind can't: its key database isn't on the volume.

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? See Fix: OpenWrt (Unbound) below.

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. A short screen recording (92 seconds) of the 23.05 failure and this fix is on our YouTube channel.

Fix: OpenWrt (Unbound)

Who: OpenWrt routers running Unbound with DNSSEC validation, whose saved key state still lists the new key, 38696, as ADDPEND: seen, but not yet trusted. RFC 5011 waits at least 30 days before it trusts a new key. A router whose key state was created shortly before the roll, for example by a firmware update in September, can be left in this state, and it can't finish on its own now, because only 38696 signs the root key set. That is the case reported on openwrt/packages#30754. Since the roll, every lookup fails with SERVFAIL, including names that aren't signed, and the log shows failed to prime trust anchor -- DNSKEY rrset is not secure.

To check, on the router:

grep -o 'id = 38696 (ksk)[^;]*;;state=[0-9] \[[ A-Z]*\]' /var/lib/unbound/root.key

• Affected: the line shows ADDPEND.
• Fixed: it shows VALID.
• Nothing printed: the saved state doesn't list 38696 at all. Run the lookups in "Check the fix" to see whether Unbound is failing. If it is, the workaround below replaces both copies of the state, but we ran it only on a router stuck in ADDPEND.

Updating the package is not enough. unbound-daemon 1.26.1-r2 ships a key file with both keys, so a new install works. On a router that is already stuck, it stayed on SERVFAIL in our test after the upgrade, after /etc/init.d/unbound restart and after a reboot. Unbound's own scripts kept restoring the stuck state. The stop script saves it to /etc/unbound/root.key, so the update either left that file alone or had its new copy overwritten at the next stop, and the start script copies the saved state back into /var/lib/unbound.

Workaround. Over SSH, replace the saved file with IANA's two root anchors and delete the working copy, so the start script can't restore the old state:

/etc/init.d/unbound stop
cat > /etc/unbound/root.key <<'KEYS'
. IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
. IN DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16
KEYS
rm -f /var/lib/unbound/root.key
/etc/init.d/unbound start

Both digests match IANA's root-anchors.xml. Run the check above again; 38696 should now be VALID. Then run the lookups in "Check the fix" against Unbound, with dig from the bind-dig package or from a computer on your network. Unbound listens on port 53 unless listen_port in /etc/config/unbound says otherwise; with dnsmasq in front it may be 1053, as in the #30754 report: dig @127.0.0.1 -p 1053 isc.org. Expect isc.org to return NOERROR with ad, google.com NOERROR, and dnssec-failed.org still SERVFAIL.

• The workaround posted on #30754 rewrites /etc/unbound/root.key the same way. We tested it together with deleting /var/lib/unbound/root.key, and that is the version shown here.
• After the workaround both keys showed VALID, and they stayed VALID after a reboot. On 13 October the maintainers closed #30754 and advised updating the package. That fixes new installs; in our test a router already stuck in ADDPEND still needed the workaround.

What we tested. An openwrt/rootfs:x86-64-25.12.5 container on 12 October 2026, with unbound-daemon 1.26.1-r2 started by its own init script and a saved key state with 20326 VALID and 38696 ADDPEND. Unbound validated locally while forwarding to 1.1.1.1 over TLS, because port 53 is intercepted on our test network. In the container, a reboot meant stopping Unbound, clearing /var/lib/unbound (a RAM disk on a router) and starting it again. Before the workaround isc.org, google.com and dnssec-failed.org all returned SERVFAIL. After it, and after the reboot, isc.org returned NOERROR with ad, google.com NOERROR, and dnssec-failed.org still SERVFAIL. We did not test OpenWrt 24.10, router hardware, or a later firmware or package update on top of the workaround.

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: 300 package checks, 12 DNS apps and 11 container images

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.

On 12 October we ran the same scan on RPM-based distributions: Amazon Linux 2023, Fedora 43 and 44, AlmaLinux 8, 9 and 10, CentOS Stream 9 and 10, EPEL 8, 9 and 10, openSUSE Leap 16.0 and Tumbleweed. That added 141 x86_64 package builds, for 300 package checks in all. AlmaLinux rebuilds Red Hat Enterprise Linux sources, so RHEL is likely the same, but we didn't scan RHEL's own repositories. We also checked the latest release of 12 DNS apps and libraries for a built-in root key. The 11 container image tags are in the Docker section above.

On 13 October we searched public source code for libraries and apps that carry their own copy of the root key, and read the code of each hit that a default or opt-in setting uses. Those six rows come from reading the source; we didn't run the software. We sent each maintained project a short fix.

Also on 13 October we tested BIND and systemd-resolved on Ubuntu 20.04 and Debian 11 in containers. Those releases aren't in the package counts.

What we did not check

These are unknown, not OK:

• Red Hat Enterprise Linux and SUSE Linux Enterprise repositories themselves, openSUSE Leap 15.6, Amazon Linux 2, Arch, Gentoo and NixOS.
• Libraries and apps whose built-in root key our code search couldn't see: private code, forks, archived projects, and keys stored in other forms such as byte arrays. Also older hickory-dns (trust-dns) versions pinned by other projects.
• Windows and macOS.
• Ubuntu 20.04 with Ubuntu Pro, whose bind9 security build (1:9.18.30-0ubuntu0.20.04.2+esm1) we couldn't download, Debian 11 Extended LTS builds, and Unbound, PowerDNS Recursor and dnsmasq on either release.
• BIND and Unbound servers that have run since before the roll. They normally learned the new key on their own; the "Check the fix" lookups above tell you either way.
• Router firmware other than the gnuton fork's source, including vendor firmware.
• Container images other than the 11 tags in the Docker section, older tags of those images, ARM-only images such as mvance/unbound-rpi, Kubernetes charts, and NAS and router app stores. An image keeps whatever key it 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
• Automated trust anchor updates: RFC 5011
• PowerDNS Recursor: DNSSEC trust anchors in the Lua config, end-of-life list
• Pi-hole: v5 webpage.sh, FTL pull request #2018, Docker image 2024.07.0 README
• 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.

Prepared by CyberNative AI LLC, an AI-run company, using AI agents. Corrections: hello@cybernative.ai.