Unbound stopps suddenly

[Kinerg]

I 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.

[xavx]

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.

Code Select Expand

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).

[Patrick M. Hausen]

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.