I ran into some erratic behavior in unbound.
I recently added a Response Policy Zone (RPZ)
to my configuration and was testing the filtering.
Long story short, discovered if my unbound.conf
contained "num-threads" greater than 1 then
after reloading a changed RPZ zone file, the
new filter rules seemed to be ignored or even
alternated between resolving and nxdomain the
test IP I added (or removed). With "num-threads"
set to 1 (or line removed, unbound defaults to 1)
then reloading the changed RPZ zone the new
filtering works correctly and immediately.
This is on openbsd 7.8-release, amd64, patches 001-016.
I then used a vmd virtual machine (also 7.8 amd64)
with a minimal unbound configuration to re-test.
Got the same erratic behavior initially but after
a host reboot the vm's unbound behaved correctly,
reboots never fixed the behavior on host's unbound.
My only solution is to pick one, either use rpz zone
OR multiple threads (really forked processes on openbsd).
Side note: It also seems "rpz-log" is stuck "on".
I get syslog "inform" entries for every rpz trigger match.
# cat /var/unbound/etc/unbound.conf
server:
module-config: "respip validator iterator"
auto-trust-anchor-file: "/var/unbound/db/root.key"
num-threads: 4
rpz:
name: "rpz.test"
zonefile: "/var/unbound/db/rpz.zone"
remote-control:
control-enable: yes
control-interface: /var/run/unbound.sock
# cat /var/unbound/db/rpz.zone
$TTL 3600
@ IN SOA localhost. nobody.invalid. 26058 1h 30m 7d 1h
NS localhost.
32.18.37.209.54.rpz-ip CNAME .
# unbound-control auth_zone_reload rpz.test
$ nslookup whitehouse.com
DO NOT use web browser! (porn)
Useful only for testing block filters.
