Yes, the DNSBL implementation changed. The Unbound configuration method had the drawback of having a significant reload time, regardless of whether this was done dynamically or statically. The blocklists themselves are still being preprocessed by https://github.com/opnsense/core/blob/master/src/opnsense/scripts/unbound/blocklists.py
You can check out the following actions: https://github.com/opnsense/core/blob/master/src/opnsense/service/conf/actions.d/actions_unbound.conf#L19-L47 which handle the reporting end, but can also be utilized to query some details. DuckDb is used to store queries up to a maximum of 7 days, so as to not needlessly fill up disk space.
For logging purposes you can also consider enabling logging in Unbound -> Advanced, we've done a bit of work there to better differentiate between query/reply if you want to run the data through syslog.
[66717:1] query: 192.168.1.42 blocked.example.com. A IN[66717:1] reply: 192.168.1.42 blocked.example.com. A IN NOERROR 0.000000 0 54[66717:3] query: 192.168.1.42 allowed.example.com. A IN[66717:3] reply: 192.168.1.42 allowed.example.com. A IN NOERROR 0.000000 0 84
I knew about the actions and API and had already looked at that but I'd prefer to have the info inside the logs themselves instead of having to correlate from an additional source.
I have query and reply logging turned on but it doesn't provide me any information about the blocklists.
What do you suggest putting as a prefix for the log statement besides just "dnsbl_module:"? I'm currently using Result but not sure if there's anything better.
I have it working locally. Now I just need to figure out the config setup to add a UI toggle.
Perhaps "logger:" would suffice, it should only be unique within the scope of Unbound. I need to think a bit on this, but this can always be reviewed in the PR.
Most of the steps required to build this are documented: https://docs.opnsense.org/development/frontend.html. Luckily the general page was already migrated to MVC, so this should be plug&play.What might not be obvious is the communication to the dnsbl_module itself. There's a concrete example here: https://github.com/opnsense/core/blob/master/src/opnsense/service/templates/OPNsense/Unbound/core/dnsbl_module.py#L167, in combination with https://github.com/opnsense/core/blob/master/src/etc/inc/plugins.inc.d/unbound.inc#L413