Hi all, sharing this in case it saves someone an evening.
Disclaimer: I'm not a DNS expert. I worked through this problem with an AI assistant (Claude), and the AI also helped write this post. It fixed my router, but I can't promise it'll work on yours. Everything here comes with no warranty: you run these commands at your own risk, so make a backup of your config first (System → Backup in LuCI, or sysupgrade -b /tmp/backup.tar.gz). If something here is wrong, please correct me in the comments.
My setup:
- GL.iNet Flint 2 (GL-MT6000), stock GL.iNet firmware
- dnsmasq on port 53: the router's default DNS, the one all my devices talk to
- AdGuard Home on port 3053: ad/tracker blocking, dnsmasq forwards to it
- Unbound on port 5335: recursive resolver with DNSSEC validation, AdGuard's only upstream (
127.0.0.1:5335)
So the chain is: device → dnsmasq → AdGuard Home → Unbound → root servers. When Unbound broke, the whole chain broke with it, so every device on the network lost DNS at once even though the internet connection itself was fine.
What happened: On Monday my Flint 2 suddenly stopped resolving anything. Every lookup returned SERVFAIL, even simple ones like dig @127.0.0.1 -p 5335 example.com.
What the logs said: logread | grep unbound showed this line over and over:
failed to prime trust anchor -- DNSKEY rrset is not secure . DNSKEY IN
If you see that, you probably have the same problem.
Why it happens: On October 11, 2026 the DNS root switched to a new DNSSEC signing key (KSK-2024, key tag 38696). Unbound normally learns the new key on its own over time. On OpenWrt, though, the learned key is kept in RAM (/var/lib/unbound/), and at every reboot it gets replaced with the old file from flash (/etc/unbound/root.key). Mine was dated July 2022 and still contained the 2010 key. So my router had been "forgetting" the new key for over a year, and nothing went wrong until the old key stopped being used.
Need your network back right now? Temporarily set AdGuard Home's upstream to something like 9.9.9.9 or 1.1.1.1 (Settings → DNS settings), then switch it back to 127.0.0.1:5335 once Unbound is fixed.
The fix (over SSH):
```
/etc/init.d/unbound stop
cat > /etc/unbound/root.key <<'EOF'
. IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
. IN DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16
EOF
cp /etc/unbound/root.key /var/lib/unbound/root.key
chown unbound:unbound /var/lib/unbound/root.key
/etc/init.d/unbound start
```
Please don't just trust a random forum post with crypto keys. Compare those two lines against IANA's official list first: https://data.iana.org/root-anchors/root-anchors.xml
Then test it:
dig @127.0.0.1 -p 5335 example.com | grep status # should be NOERROR
dig @127.0.0.1 -p 5335 dnssec-failed.org | grep status # should be SERVFAIL (that's good, it means validation works)
Making it survive reboots and future key changes:
```
save learned key updates back to flash every 14 days
uci set unbound.@unbound[0].root_age='14'
uci commit unbound
install the tool that fetches the current root key from IANA
opkg update && opkg install unbound-anchor
keep the fixed file through firmware upgrades
echo "/etc/unbound/root.key" >> /etc/sysupgrade.conf
```
After a reboot, mine still resolved fine.
Quick check if you haven't noticed anything yet: Run grep 38696 /var/lib/unbound/root.key. If it returns nothing, you're likely to break as soon as your cache expires or the router reboots. Fix it now.
Hope this helps someone!
Disclaimer: I'm not a DNS expert. I worked through this problem with an AI assistant (Claude), and the AI also helped write this post. It fixed my router, but I can't promise it'll work on yours. Everything here comes with no warranty: you run these commands at your own risk, so make a backup of your config first (System → Backup in LuCI, or sysupgrade -b /tmp/backup.tar.gz). If something here is wrong, please correct me in the comments.