Unbound stopps suddenly

Started by MiRei, July 17, 2026, 09:11:04 AM

Previous topic - Next topic
Quote from: MiRei on August 26, 2026, 10:53:11 AMI have 4 GB of RAM in the system. The system is running at 30% capacity.
When unbound crashing it occurs after the DNS blocklist is updated,
which is done via cron once a day.
However, unbound does not crash every day after the cron job runs.


4 GB is not enough for newer versions with larger blocklists. It doesn't consume much while running, but dynamically it can shoot up rather high, especially for Unbound using blocklists. Try disabling them and see if the crashing changes.

What I've done for both unbound and suricata is to create 2 small bash scripts to monitor their status. If they get killed, they are restarted automatically.
root@fwall:~ # cat dnscheck.sh
#!/usr/local/bin/bash

LOGFILE="/root/log/unbound_monitor.log"
TIMESTAMP=$(date "+%Y-%m-%d %H:%M:%S")

if ! pgrep -x "unbound" > /dev/null; then
    echo "$TIMESTAMP: Unbound process not found, restarting..." >> $LOGFILE
    /usr/local/sbin/configctl unbound restart
    echo "$TIMESTAMP: Unbound restart command executed" >> $LOGFILE
fi

root@fwall:~ # cat /etc/cron.d/dnscheck
*/5      *       *       *       *    root   /root/dnscheck.sh > /dev/null

A major issue with DNSBL on opnsense is the lack of memory usage optimization when the blocklists get updated.
First issue is the blocklist update process loads all the blocklists in RAM then format them for Unbound, instead of streaming them.
Second issue is at DNSBL swap time, Unbound effectively has 2x all the blocklists loaded for a brief moment before releasing the old blocklist.
Both situations can lead to the highest memory consumer being killed by FreeBSD (expected behavior).

If you like to use DNSBL I recommend delegating that to a servicd that is designed specifically with large lists in mind. Like AdGuard Home which can run directly on OPNsense and comes with a much nicer UI to manage excepted devices, manual allowlists, statistics etc.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Adguard is indeed the "easiest" way to keep large blocklists without butchering Unbound implementation on Opnsense.
It's unfortunate though that the Adguard plugin isn't officially supported as it's the only viable way.
Unless the Opnsense devs move to RPZ, Unbound will continue to consume 4 times the amount of RAM for DNSBL compared to Adguard.

> Second issue is at DNSBL swap time, Unbound effectively has 2x all the blocklists loaded for a brief moment before releasing the old blocklist.

This is a very generic issue that requires intricate implementations to overcome. Alias loading in pf has the exact same issue as an example.


Cheers,
Franco

@Franco, what are the odds AGH will ever be included as an official community plugin? I mean, there's a FreeBSD port/package, no need to pull obscure binaries from Github or some such. Would be even easier if you would build your ports in Poudriere ;-)
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Last time Michael checked he said the ports binaries didn't work, but that may have been a long time ago.

Not super comfortable to bring such a thing into the supported ecosystem and people making AI plugins for it rather sooner than later.  There's probably more noise and support questions then.

Other core devs will probably have similar views but we can talk about it at EuroBSDCon.


Cheers,
Franco