I have an issue with the unbound DNS resolver gradually consuming RAM over the course of up to three weeks, until all 512M are consumed at which point DNS resolution stops working.
Is this a known issue? Is there a way I can get visibility into what unbound is doing with all this memory to help figure out the problem?
verbosity: <number>
The verbosity number, level 0 means no verbosity, only errors.
Level 1 gives operational information. Level 2 gives detailed
operational information. Level 3 gives query level information,
output per query. Level 4 gives algorithm level information.
Level 5 logs client identification for cache misses. Default is
level 1. The verbosity can also be increased from the command-
line, see unbound(8).
I'd also double check that your config isn't one tailored for high-volume use. (Edit: OP has config extract in their post above, no "smoking gun" seen.) A caching resolver is going to consume memory for the cache. Creeping RAM usage might come from a slowly filling cache ("slowly" compared to an enterprise deployment answering thousands of queries per second). Many of the example configs for unbound assume RAM sizes in the gigabytes.
Edit: I took a quick look at unbound-control stats_noreset on one of my DNS servers (v1.7.0) and I don't see anything there immediately useful around cache or memory utilization. status didn't show anything RAM/cache-related either.
The only changes I made outside of LuCI were to add DNS-over-HTTPS encryption via /etc/unbound/unbound_ext.conf (included in the troubleshooting output above).
In LuCI I have "Memory Resource: default" which I assumed would result in a sane value for embedded devices. (This is one of those WRT3200ACMs with half a gig of RAM, so I'd expect the default to be well below what this device can handle.)
Just saw the config extract scrolling down and I didn't immediately see anything inconsistent with what man unbound.conf suggests for "settings that reduce memory usage"
# example settings that reduce memory usage
server:
num-threads: 1
outgoing-num-tcp: 1 # this limits TCP service, uses less buffers.
incoming-num-tcp: 1
outgoing-range: 60 # uses less memory, but less performance.
msg-buffer-size: 8192 # note this limits service, 'no huge stuff'.
msg-cache-size: 100k
msg-cache-slabs: 1
rrset-cache-size: 100k
rrset-cache-slabs: 1
infra-cache-numhosts: 200
infra-cache-slabs: 1
key-cache-size: 100k
key-cache-slabs: 1
neg-cache-size: 10k
num-queries-per-thread: 30
target-fetch-policy: "2 1 0 0 0 0"
harden-large-queries: "yes"
harden-short-bufsize: "yes"
Do you have SSL upstream enabled? I noticed this RAM / memory leak issue only with SSL when unbound has to use TCP on forward servers. Without TLS, unbound uses regular UDP so memory use remained static.
Edit: I checked your github issue entry that saw that you have SSL upstream enabled. That is the culprit at least for my setup.
Thanks @EricLuehrsen. Would you like it to be kept in this state to gather info later, or are you already able to reproduce it without too much effort?
If it's trivial for you to reproduce, I might throw in a cron job to restart unbound (or unbound-control reload if that frees the memory) as a workaround until you folks can come up with a better workaround or fix.
I don't mind keeping it in this state if it might help, there's probably another week before it becomes a problem again.