Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out
On Mon, Mar 13, 2023 at 12:29:44PM +0100, local10 wrote:
> Mar 13, 2023, 10:57 by recoverym4n@enotuniq.net:
>
> > And now to the serious stuff.
> >
> > First things first, the log.
> >
> > Mar 13 05:03:18 tst named[52836]: 13-Mar-2023 05:03:18.963 queries: info: client @0x7f7812816d68 127.0.0.1#38800 (www.yahoo.com <http://www.yahoo.com>): query:
> > www.yahoo.com <http://www.yahoo.com> IN A +E(0)K (127.0.0.1)
> > Mar 13 05:03:21 tst named[52836]: 13-Mar-2023 05:03:21.631 dnssec: warning: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out
> >
> > The keyword here is not "managed-keys-zone", it's "dnssec".
> >
> > Second, to put it bluntly, if you force bind9 to do DNSSEC validation
> > (which is enabled by default), bind9 won't be able to lookup anything
> > unless it is trusting root DNSSEC key. Like, for your own security and
> > stuff :)
> >
> > Third, as every DNSSEC key, root zone keys have their expiration.
> > Meaning, you did not have to change anything to break your setup, every
> > time you deal with DNSSEC you're dealing with a ticking bomb anyway.
> >
> > Fourth, Debian packaging helpfully forces bind9 to depend on dns-root-data,
> > which should provide a current DNSSEC root key (KSK to be precise), but
> > bind9 could also take said key from /etc/bind/bind.keys.
> >
> >
> > In conclusion:
> >
> > 1) Check the contents of your /etc/bind/bind.keys, update if needed.
> > 2) Check the version of your dns-root-data, versions above and including
> > 2021011101 (aka ksk id 20326) are good.
> > 3) Set "dnssec-validation no;" at named.conf.options as a last resort.
> > 4) If you intend to troubleshoot DNS queries then consider installing
> > tcpdump. The thing helps.
>
>
> Very interesting, thanks. in the "bind.keys" I have only one entry:
>
> trust-anchors {
> # This key (20326) was published in the root zone in 2017.
> . initial-key 257 3 8 "....";
> };
Looks correct, assuming that the contents of the key start with AwEAAaz
and end with V74bU=.
> But in "/etc/bind/named.conf.options" I have "dnssec-validation
> auto;", which, as I understand it should force bind to use the
> built-in root key, no?
Not exactly. "dnssec-validation auto;" should point BIND at
/etc/bind/bind.keys. And bind.keys should be created (or updated) by
debconf.
At least debconf did it for me back in 2021 during buster->bullseye
upgrade.
> Anyhow, how would I know if an update of /etc/bind/bind.keys is needed (it's not obvious just by looking at the key)
Obviously you cannot know that ;)
Luckily "Root KSK Rollovers", as they call it, are rare. Last one was in
2018, and the key (aka ksk id 20326) in question was released in 2017.
> and, if so, how do I update it?
Look at /usr/share/dns/root.key. Compare its contents with
/etc/bind/bind.keys. Replace the latter if needed.
"dpkg-reconfigure -plow bind9" is probably more preferred way of doing
it.
Reco
Reply to: