OpnSense is sending way too many requests (e.g. 800.000 in 10 minutes) for periods of time to the upstream DNS (my pihole). This happens now and then and causes problems on the pihole.
The requests come from OpnSense directly, not from downstream clients (Outbound NAT is disabled completely). They are all the same requests, usually for one host in it's own network, e.g. proxmox1.opnsense, and are forwarded to Opnsense (see below).
My servers are in an OpnSense subnet. The subnet uses .opnsense and pihole is configured to conditionally forward .opnsense to OpnSense (true,10.0.0.0/24,10.0.0.1,opnsense). I suspect some kind of loop but can't get behind it. DHCP sets the pihole ip as dns-server [6].
I only use dnsmasq to have DHCP and to resolve.opnsense from the pihole - including the proxmox hosts which aren't doing dhcp but static IP - those are added to dnsmasq.d like this:
root@OPNsense:/usr/local/etc/dnsmasq.conf.d # cat proxmox-hosts-dns-records.conf
address=/proxmox1.opnsense/10.0.0.10
address=/proxmox2.opnsense/10.0.0.11
These are often (but not exclusively) the hosts that opnsense is requesting in those surge periods.
I recently upgraded from 25.7 to 26.1 and switched from ISC to dnsmasq for DHCP - I think that's when the issue started.
/var/log/dnsmasq/$latest.log is only 128 lines and is nothing but some DHCPREQUEST/DHCPACK in the time period.
The setup generally works fine, but after these spikes, pihole has some hiccups. Any help on how to nail this further down would be appreciated.
Ubound, KEA and ISC are disabled.
Versions
OPNsense 26.1.3-amd64
FreeBSD 14.3-RELEASE-p9
OpenSSL 3.0.19
Bare Metal (PC Engine APU)
Edit: The diagram was missing
That number of requests is a bit high, I'm assuming they're coming from a lot of lists or aliases.
More importantly though, you're lacking a DNS caching capability.
I've solved this issue by having AdguardHome installed on the FWs and by setting up caching there, with a minimum of 20 minutes and a maximum of 40. Everything works fine and any misbehaving clients that ignore the above values and continue to make requests are served by AGH from cache.
Quote from: newsense on March 08, 2026, 10:22:53 PMThat number of requests is a bit high, I'm assuming they're coming from a lot of lists or aliases.
As I said, it's the same request for one of the .opnsense hosts over and over again. What do you mean they come from lists/aliases?
Quote from: newsense on March 08, 2026, 10:22:53 PMMore importantly though, you're lacking a DNS caching capability.
What do you mean by this? I think pihole caches. But dnsmasq is supposed to only resolve it's DHCP hosts and the 2 extra entries I posted, nothing else, so I'm not sure what it's supposed to cache.
Quote from: gardener on March 09, 2026, 08:54:40 PMI think pihole caches.
Pi-Hole's FTLDNS (which is DNSmasqd with additional features!) ofcourse caches everything it processes, but only for the length of the TTL of a specific A/AAAA/SRV and all other DNS Records.
So if you want 20 or 40 minutes for certain records you will have to add some DNSmasqd magic to your pihole.toml file for all the DNS Records that need to be remembered longer !!
My guess is that the new feature called
HostWatch is doing nasty things so try disabling it and see what happens afterwards :)
But the real question is : Why does your OPNsense query Pi-Hole at all ?!
IMHO you should only give the Pi-Hole DNS IP Address to your DHCP Clients and nothing more than that!
There are two options available in both Unbound and Dnsmasq that are not exposed in the GUI, that can help with minimizing the outbound DNS traffic.
Quote—max-cache-ttl=<time>
Set a maximum TTL value for entries in the cache.
--min-cache-ttl=<time>
Extend short TTL values to the time given when caching them. Note that artificially extending TTL values is in general a bad idea, do not do it unless you have a good reason, and understand what you are doing. Dnsmasq limits the value of this option to one hour, unless recompiled.
It would be best to open a feature request ticket on GitHub OPNsense/core for this referencing this thread.
It is important to have these options to both resolvers since people may use one resolver or another.