Just a quick note on some interesting behavior:
I recently decided to give the Unbound blocklists a try (Services > Unbound DNS > Blocklists). I was quite pleased with with how they were working and how the reporting was working (Reporting > Unbound DNS).
I then noticed that even with a cron configured to update the blocklists (System > Settings > Cron), the reported size of the blocklists was not changing over several days, which was unexpected behavior.
As a result of this, I decided to restart Unbound to see if the lists were indeed updating but reporting wasn't picking up the new counts for some reason.
Upon restarting Unbound the counts immediately updated in reporting which leads be to believe Unbound isn't automatically reloading the updated lists.
I'm wondering if this is the intended behavior. Do the updated lists not automatically get loaded into Unbound or is it a reporting issue?
I would hazard to guess that most would expect the list refresh cron to also reload the updated lists within Unbound without having to schedule an additional Unbound service recycle.
For now, I've scheduled both a blocklist list refresh and an unbound recycle (+30m later) to make sure the new lists are picked up and used.
It might be nice to have a list status page/tab, perhaps under reporting, that gives you information on the configured lists showing last successful fetch date/time and a few list stats, etc. There you could also note the requirement(s) for keeping the lists refreshed properly and link directly to the cron page.
Yes I see the same thing. According to the Unbound logs the blocklist are updating but then a few hours later I see this in the log -
<Database auto restore from /var/cache/unbound.duckdb for cleanup reasons in 0.44 seconds>
In Reporting, Unbound shows a blocklist size from two days ago (it's updated daily). The logs show that the DNSBLs were updated but then Unbound auto restored the database after the last two updates. Maybe corruption or size issues? I don't know
Quote from: C0S on March 17, 2026, 02:52:31 PMUpon restarting Unbound the counts immediately updated in reporting which leads be to believe Unbound isn't automatically reloading the updated lists.
I'm wondering if this is the intended behavior.
I noticed this, too. You can work around it with another cron to reload Unbound but that may clear the cache if that setting is enabled in Unbound configs. Definitely not ideal.
Can you raise a ticket in GitHub for this?
https://github.com/opnsense/core/blob/f8364f426a986f879ecd4c40a0ed4b15f67b5fa9/src/opnsense/scripts/unbound-dnsbl/lib/dnsbl.py#L62
_update_dnsbl() is called each time from policy_match() on line 122. So I think the way this works (could be wrong) is that every time you do a DNS query it checks if there is a new DSNBL to load, but it limits the loading to only once each 60s and only if the timestamp of the DNSBL file on disk has changed.
So if you update the DNSBL, at most, you should see the new number reflected in Reporting within a minute or so. And then only if there actually were changes (domains added/removed).
I don't know if this solves it, but at least we know the trigger.
Quote from: OPNenthu on March 17, 2026, 03:44:31 PMI noticed this, too. You can work around it with another cron to reload Unbound but that may clear the cache if that setting is enabled in Unbound configs. Definitely not ideal.
Can you raise a ticket in GitHub for this?
Issue raised, please feel free to add additional context here: https://github.com/opnsense/core/issues/10001
Thanks!
Quote from: OPNenthu on March 17, 2026, 04:54:43 PMSo if you update the DNSBL, at most, you should see the new number reflected in Reporting within a minute or so. And then only if there actually were changes (domains added/removed).
Already the best answer here.
Cheers,
Franco