RPZ - silent AXFR failure when SOA probe fails

[rootwyrm]

Found this one due to a frustrating configuration error (I had a typo I kept missing.) But it definitely pointed to a bug. If the SOA is invalid for an RPZ, Unbound will silently fail to transfer the zone, even if forced. Which will leave you scratching your head for a few hours until you turn the verbosity way up.

[1594142119] unbound[3778:0] debug: auth zone malware.rpz. probe: notify addrs updated
[1594142119] unbound[3778:0] debug: auth zone malware.rpz. soa probe sent to 10.53.0.250
[1594142119] unbound[3778:0] debug: auth zone malware.rpz.: bad reply to soa probe
[1594142119] unbound[3778:0] debug: close fd 41
[1594142119] unbound[3778:0] debug: auth zone malware.rpz. probe: notify addrs updated
[1594142119] unbound[3778:0] debug: auth zone malware.rpz. soa probe failed, wait to retry
[1594142119] unbound[3778:0] debug: auth zone malware.rpz. timeout in 6 seconds

The problem here is that these errors do not appear until you turn the verbosity up above I believe 4 or 5.

An SOA probe failure resulting in no AXFR/IXFR should be considered a major operational error - particularly in the RPZ context - and should be logged at verbosity: 1 since the failure will prevent the RPZ from working at all on an initial AXFR. Leaving any environment that doesn't check for the existence of the zone file unaware that their RPZ is non-functioning.

Found this on Unbound 1.10.1;

$ unbound -V
Version 1.10.1

Configure line: --prefix=/usr/local --with-libevent=/usr --enable-pie --enable-relro-now --enable-subnet --enable-tfo-client --enable-tfo-server --enable-dnstap --enable-dnscrypt --enable-cachedb --enable-ipsecmod --enable-ipset
Linked libs: libevent 2.1.11-stable (it uses epoll), OpenSSL 1.1.1g  21 Apr 2020
Linked modules: dns64 cachedb ipsecmod subnetcache ipset respip validator iterator
DNSCrypt feature available
TCP Fastopen feature available

BSD licensed, see LICENSE in source package for details.
Report bugs to [email protected] or https://github.com/NLnetLabs/unbound/issues

[v0rap]

@ralphdolmans Are you interested in help with implementing this? :) I'm more than happy to submit a pull request. :)

I stumbled across this in our production environment, and I do agree that this error message should be displayed even with verbosity level set to 1. Would have saved me a bunch of head scratching if that would have been the case. :)