Recently I encountered the following error in /var/named/data/named.run
on a freshly installed BIND 9 resolver in an AlmaLinux 9 container on podman when dnssec-validation
was set to yes
or auto
in /etc/named.conf
:
managed-keys-zone: Unable to fetch DNSKEY set '.': timed out
The tl;dr of this is try running named
with the -4
argument to force it to only use IPV4. This can be set in /etc/sysconfig/named
in the OPTIONS
variable. Keep reading to understand the troubleshooting that led to a fix.
The root cause was not immediately clear so I started working my way through what could cause this. /etc/named.root.key
was from the package and matched IANA’s active root signing key. The permissions on /var/named/dynamic/
matched the named
process runner and the managed keys files were being populated with some data – dumping the .jnl
file with named-journalprint
didn’t show any clear problems, but I’m not familiar with what it should actually look like.
Checking the key status with rndc
pointed to there being an issue with trust however
# rndc managed-keys status
view: _default
next scheduled event: Wed, 21 Aug 2024 12:34:56 GMT
name: .
keyid: 20326
algorithm: RSASHA256
flags: SEP
next refresh: Wed, 21 Aug 2024 13:34:56 GMT
no trust
At this point it was time for the typical Google blackhole of no valid answers. It seemed like many people gave up and just disabled DNSSEC validation to get around it. At this point I decided to tcpdump
the named
process starting
# tcpdump -i any -n -vv port 53
This ultimately showed BIND reaching out via IPV6 with no responses received. IPV6 is not something available on this system, so not explicitly configuring the container host to disable it could have contributed to this issue.
Note that stopping BIND from listening on IPV6 addresses is not enough – you must pass the -4
flag to stop this behaviour.