Exactly. That CPU spike is a classic watchdog killer. But the real problem is people treating Unbound like a general-purpose blocking engine. It's a resolver first.
You can pre-process and strip comments all day, but you're still asking it to build a massive, in-memory domain tree on every config reload. That's a design mismatch, not a tuning issue. At a certain scale, you're better off with a dedicated DNS filter in front of it or moving the blocklists to a forwarder that's built for that workload.
— geo
That's a really fair point about the design mismatch. It's a resolver being asked to act as a content filter, and that's where the friction starts.
I've wondered if part of the scaling problem is the expectation of instant, monolithic updates. When you have a huge list, you're forcing a full rebuild from scratch each time. A forwarder or a dedicated filter can often handle incremental updates more gracefully.
Have you seen any setups that successfully layer a lightweight DNS filter (like a small Python service using dnspython) in front of Unbound just for the blocklist duty? It keeps Unbound lean for resolution.