On Mon, Feb 24, 2020 at 09:47:01PM +0100, Branko Mijuskovic wrote: > We have an authoritative DNS hidden master (bind-9.11.4-9) running behind > the network where outgoing UDP traffic to unlisted IPs is blocked. > > We are using DNSSEC and I've noticed that we are getting following errors > in the bind9 logfile: 'managed-keys-zone/default: Unable to fetch DNSKEY > set '.': timed out'
If the server is authoritative-only, then it only uses recursion for limited internal purposes (looking up the addresses of servers to send NOTIFY messages to, for example), and it's unlikely that DNSSEC validation is needed for that. You could disable it with "dnssec-validation no", which should silence these log messages. > My question is does bind uses 'try-tcp-refresh' when it fails to get the > keys via UDP from the root servers? No, that option isn't applicable to managed-key zones. It's about refreshing secondary zones, not keys - a different process altogether. (Though, since they're both called "refresh", it might be sensible if the option did apply in this case.) > This is because our keys are regularly updated, but I'm not sure how. I think it's just updating the "next refresh" timer, not the keys themselves. The log message indicates the key refresh query failed, so it would schedule itself to try again in an hour. > # rndc managed-keys status > view: default > next scheduled event: Tue, 25 Feb 2020 19:16:47 GMT > > name: . > keyid: 20326 > algorithm: RSASHA256 > flags: SEP > next refresh: Tue, 25 Feb 2020 19:16:47 GMT > trusted since: Mon, 03 Feb 2020 18:10:26 GMT "trusted since" indicates it managed to get at least query through on Feburary 3. If it hadn't, it should be saying "trust pending". -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
