Enabling Conditional Forwarding creates spikes in router traffic every hour

Expected Behaviour:

number of queries processed by pi-hole spikes up to rate_limit exactly every hour. i've changed rate_limit to 3000. All those requests are coming from my router (pfsense 2.5.2). If I disable conditional forwarding, it fixes the problem and I stop getting those spikes in traffic. I don't understand why this is happening.

Actual Behaviour:

router shouldn't be sending so many requests.

Debug Token:

https://tricorder.pi-hole.net/iEJs5tNq/

There is a way to eliminate the need for Conditional Forwarding. I've written a guide for OPNsense as that's what I use, but it should be applicable to pfsense.

See Pi-hole and OPNsense – Pi-hole and let me know if it's something that works.

1 Like

I was really interested in the method @DanSchaper mentioned above. I went through my opnsense config and got everything configured as described in the guid, but I encountered issues when using Google DNS for my upstream.

From what I could gather, the EDNS0 Client Subnet information added from dnsmasq (for the initial client) was subsequently being forwarded to the upstream. I confirmed this with a packet capture, and apparently Google DNS refuses queries with private IPs in the EDNS0 Client Subnet option (which I suppose makes sense). I couldn't determine a way to change this behavior. Maybe I had a configuration issue somewhere...

I read through the guide, and the gist of it seems to be to enable dnsmasq on the router, point DHCP leases to the router as the DNS and disable conditional forwarding on the Pi-Hole?

That's more or less how it was already configured, with the main difference being that I set pfSense to use local dns first (dnsmasq) before falling back to Pi-Hole, so that the routers own requests will go to Pi-Hole? But my DHCP leases point to Pi-Hole directly, because when I disabled that, they were pointing to my router and then I wasn't getting any client separation in Pi-Hole statistics... all requests were coming from the router.

I forgot to mention that the top lookup when conditional forwarding is enabled is to "lb._dns-sd._udp", and as per this Reddit thread ( https://www.reddit.com/r/Adguard/comments/onedt9/a_lot_of_request_lb_dnssd_udp/ ), it's apparently down to Apple device broadcast spams. I followed the suggestion to regex block that address, and will monitor the result.

I'm not a network person, and I'm grappling with understanding the concepts of how DNS interoperates. It would be useful to see a simplified overview of a best practice scenario. For instance; maybe it was wrong of me to enable conditional forwarding in Pi-Hole and DNS forwarding in the router via dnsmasq? If I was using conditional forwarding, should I have disabled both the resolver and the forwarder in pfSense? All I was trying to acheive was to see individual client stats in Pi-Hole and trial and error lead me there.

This is what my pfSense config looks like, with cond. forward. enabled in Pi-Hole:
general settings
dns forwarder settings aka dnsmasq

Well blocking that address using regex solved the problem of the router sending 3000 requests at a certain time every hour (without making any other change to what I list above), but I haven't yet verified if blocking it broke anything on my Apple devices.

The next part of the guide is to set up Unbound as the upstream resolver. You can either use unbound if it is offered on your router, OPNsense has it, or you can use unbound set up on Pi-hole server using unbound - Pi-hole documentation as a guide.

I didn't anticipate that upstream servers would have issues, I have been using unbound on OPNsense set to port 5335 and then setting Pi-hole to use the router as the upstream (192.168.88.2:5335 in my case).

That's what the EDNS0 solution solves.

I have been able to adapt this for use on a RT-AX88U Router running Asuswrt-Merlin firmware.
The firmware solution allows to enable use of local caching on the router as well as robust custom scripts where the add-mac and add-subnet=32,128 works marvelously thanks to RMerlin keeping the DNSMASQ up-to-date. I no longer have to have PiHole IP inside LAN DNS 1. I now let the router default to its own IP for LAN DNS, and I have set the router to use Pihole on its WAN DNS as well I enabled the local caching with dns rebind protection turned off. I then disabled conditional forwarding on the pihole, while enabling the never forward options. Everything appears to be working Marvelously. Thank you for providing such a wonderful guide. Depending on the router, it is completely adaptable to other setups.

1 Like

Awesome!

This does in fact fix the issue I was seeing! Specific to Google dns, if you send a local IP in the ecs, they refuse the query. However, if forwarding through unbound (then to Google dns), unbound strips the ecs information (by default) before it hits Google.

You can actually test this specific Google dns issue by making a query directly on their site with a private IP for ecs. If you then remove the ecs portion, the query works fine.

Thanks again for the guide! I think I'll be switching over to that setup permanently.

Unbound works fine as a recursive resolver on it's own. No need to have it forward to Google or any other upstream.

1 Like

In short, Yes, this works. Thanks for the help.

pfSense has a Custom Options box at the bottom of the DNS Forwarder settings page, and I just pasted your edns0.conf settings straight in there. I was having other issues where I couldn't ping the dns name of the pi-hole and only IP's where showing in the pihole graphs instead of DNS names, but after several hrs of messing, i finally got it working. I think all of those problems were specific to things i'd done wrong, and nothing to do with your guide. All seems great now!

1 Like

Thank you for your support with these matters, I hope you continue to post your guides including incorporation of unbound. That is how my current setup is configured. Great work to you and the rest of Pi-hole Devs.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.