Today I decided I would create some way of visualizing my unbound DNS requests/blocks on OPNsense. Adguard does a good job at this but I have issue with added third party repos and plugins, especially at the router level.
Anyway…since the last time I’ve dug into this OPNsense has built in Unbound DNS reporting (since 23.1) and it’s amazing! Arguably just as good as Pihole or Adguard. Graphs, lists of top blocked and allowed domains, query logs, quick buttons to block or whitelist next to each domain. I’m impressed.
Not sure if this is the right community, but just wanted to share if some of you weren’t aware of this option.
So this would basically allow me to use unbound as a DNS filter and resolver? Any reason why one would use adguard/blocky in their setup? Would it be more performant to use blocky + unbound, or have all your filtering done using unbound?
Its… worked as a recursive resolver, with filtering/blacklist features for years now?
That’s cool, so why would someone run pihole/adguard/blocky with unbound?
Not a clue.
Maybe they like the pretty dashboard pihole has.
I pull all my data into Grafana anyway, so dashboarding on any platform holds little attraction for my use case.
That said, my pair of Pi-hole servers pre-dates my OPNsense setup, plus I use a lot of internal hostname resolution for service portability. My single instance of OPNsense doesn’t tick all those boxes for DNS.
Unbound will do complete domain redirection to another service on itself or individual host overrides if you wanted to do that in the OPNsense box alone. What I like about the host overrides being on the Opnsense box is that you can have DHCP make the clients register their hostnames with Unbound for automatic registration, and if you combine that with IP reservations, it’s that much more predictable.
Yeah, no doubt there’s some benefits there. My problem is that I don’t (yet) have the storage system to make my Proxmox cluster properly HA. Technically, a hardware fault could still take down my OPNsense instance, whereas I have a secondary Pi-hole running on a RasPi, for redundancy.