Unbound lost blocklist when updating to 23.1.3

[CJ]

I updated to 23.1.3 and everything looked great, but then I noticed that Unbound had no Reporting Details and there were only 96 items in the blocklist.

No idea what those 96 items were but disabling and enabling the blocklist forced a download and now it's showing correctly.

[Christophe999s]

Sometimes (but not always) unbound tries to download the blocklists too soon, I had the same issue: https://forum.opnsense.org/index.php?topic=32327.0
If you look at your Unbound logs (Services: Unbound DNS: Log File), you should see messages that the download failed because a connection could not be established. Can you check?
I was under the impression that this was fixed, maybe @Fright can chime in?

[CJ]

Nope, no errors.  This is what the logs show.

Code: [Select]

[60777:0] info: dnsbl_module: blocklist loaded. length is 96
[60777:0] info: dnsbl_module: updating blocklist.


[Fright]

may be it means that at the time unbound and dnsbl module started there was only 96 records in DNSBL file for some reason (hard to tell more without logs).
dnsbl module (if requests are coming) checks every minute if DNSBL file updated and loads fresh info into the memory.
maybe it was enough to wait a bit (again, it's hard to guess without information)

[CJ]

may be it means that at the time unbound and dnsbl module started there was only 96 records in DNSBL file for some reason (hard to tell more without logs).
dnsbl module (if requests are coming) checks every minute if DNSBL file updated and loads fresh info into the memory.
maybe it was enough to wait a bit (again, it's hard to guess without information)

Looks like I have to take it back.  I hadn't scrolled back far enough in the logs.  I found an instance of this.

Code: [Select]

blocklist download : unable to download file from https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts (error : HTTPSConnectionPool(host='raw.githubusercontent.com', port=443): Max retries exceeded with url: /StevenBlack/hosts/master/hosts (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x8027e3130>: Failed to establish a new connection: [Errno 65] No route to host')))
However, I did see multiple instances of 96, so it doesn't seem like it would have resolved on it's own.  At least not until the cron job forced a reload of the blocklists.

[Fright]

so it doesn't seem like it would have resolved on it's own.  At least not until the cron job forced a reload of the blocklists

yep, with '[Errno 65] No route to host' i can assume that the DNSBL update process started when the connection was not yet fully ready. in this case, the module simply has nowhere to take fresh data until the next cycle of DNSBL download.
does this happen on every reboot?

[CJ]

so it doesn't seem like it would have resolved on it's own.  At least not until the cron job forced a reload of the blocklists

yep, with '[Errno 65] No route to host' i can assume that the DNSBL update process started when the connection was not yet fully ready. in this case, the module simply has nowhere to take fresh data until the next cycle of DNSBL download.
does this happen on every reboot?

No idea.  I rarely reboot.

What's interesting is that it resolved the two other blocklists, which is where the 96 items came from.

When I get a chance I'll try rebooting and see what happens.

[CJ]

so it doesn't seem like it would have resolved on it's own.  At least not until the cron job forced a reload of the blocklists

yep, with '[Errno 65] No route to host' i can assume that the DNSBL update process started when the connection was not yet fully ready. in this case, the module simply has nowhere to take fresh data until the next cycle of DNSBL download.
does this happen on every reboot?

I forgot to reboot but I did just upgrade to the latest version.  I can see in the logs where the DNSBL didn't get downloaded due to being unable to resolve, but when I looked at the Unbound reporting, it still showed the appropriate amount of domain names.

I added a wildcard domain and that appears to have kicked off a successful DNSBL download.