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.