unboundplus: move dnsbls from .conf to control

[kulikov-a]

for #4518

[AdSchellevis]

I'm not sure this is the best approach either, not everybody uses the blacklists, in which case /var/unbound/etc/dnsbl.list wouldn't exists and some of the configd calls would crash now.

To be honest, if we do want to use some sort of lazy loading for the blacklists, I do think we should either integrate it into the python script and only try to load if there is anything configured or define some location where all lists we should process reside in. The complication there is we don't want to reload on boot, to avoid slowing down the boot process.

An option might be to allocate a directory in /usr/local/etc for unbound to include after load, but this would also require an update of the documentation (https://docs.opnsense.org/manual/unbound.html#advanced-configurations).

Since there are a couple of issues around the unbound setup, it's probably better to spend some time on designing before pulling different patches in.

[kulikov-a]

@AdSchellevis
so we can add load_dnsbl.sh to /usr/local/opnsense/scripts/ubound/
with:
if [ -f /var/unbound/etc/dnsbl.list ]; then /usr/local/sbin/unbound-control -c /var/unbound/unbound.conf local_datas < /var/unbound/etc/dnsbl.list fi
and replace configd actions with this script?
I'm just trying to make the smallest changes to the overall logic so that nothing is ruined

[AdSchellevis]

@kulikov-a we're going to postpone this for now, I understand that you would like to prepare the smallest fix, but we should also be careful for foot shooting in the near future if the fixes only cover part of the issue(s).

[kulikov-a]

Ok. Thanks!
I really don't see a potential shot in the foot here, but again, i definitely don't know enough about the unbound issues.
just one more: when (and if) you come back to this, please also look at the DNSSEC check before trust anchor fetching.
(for my test VM if grep -q "auto-trust-anchor-file: /var/unbound/root.key" /var/unbound/unbound.conf before calling unbound-anchor works well)
Thanks again!
should i close this PR o leave as is?

[AdSchellevis]

let's leave the PR open, I don't think we're going to change much on the intent of it, just don't want to rush into fixes at the moment.

[fichtner]

different proposal via #4938