managed-keys update when outgoing UDP is blocked

[Evan Hunt]

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 -- each at isc.org
Internet Systems Consortium, Inc.