On Mon, Mar 13, 2023 at 12:29:44PM +0100, local10 wrote: > Mar 13, 2023, 10:57 by recovery...@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
