I'm struggling to force all DNS requests to use my router settings. It works well for the most part but Android (partly, it does list the correct DNS but also includes 8.8.8.8) and Google devices seem to ignore the broadcasted address.
I have a Pi-Hole server setup on my LAN interface and it's IP is broadcasted using DHCP-Options on the LAN interface 6,192.168.1.50. I've used the same IP for the IPv6 settings under Announced Servers.
My DNS forwardings in server settings are set to Cloudflare 1.1.1.1 and 1.0.0.1 and I'm ignoring my resolve file.
The Pi-Hole passes the DNS request back to the router on 192.168.1.1 if it dosent need to do anything which then uses Cloudflare.
This setup was supposed to have allowed Cloudflare to be a fallback to Pi-Hole but dosent seem to work.
My goal is to have all devices on the network use Pi-Hole with their own IP (to display correct IP in Pi-Hole) even if their DNS is set differently unless Pi-Hole isn't available in which case use Cloudflare.
I have looked at various help topics and forums posts but no solution seems to work for me. A few I've tried are:
As for the looping, if you're enabling PiHole's Conditional Forwarding, the DNS set for WAN or WAN6 should not be the same as the PiHole address. It will result in a loop.
As for the fallback, I'm not sure how that can be implemented. Unless each of your devices are configured to run round-robin queries, your devices will choose cloudflare or pihole based on whichever answers the query faster...
I decided to manage my expectations and forget about a fallback. I almost managed to get a fully working solution by port forwarding port 53 from the LAN but it would break unless I specified the outgoing IP.
So I setup two port forward rules specifiing that the outgoing IP would be 8.8.8.8 and 8.8.4.4 and forward them to Pi-hole.
IP has changed since my original post
This works and redirects all my Android and Google devices. However these requests appear to come from the router and not the device meaning I can't setup conditional filtering properly in Pi-Hole.
It would also be nice to be able to specify in the port forward rules to catch all traffic on port 53 except from the Pi-Hole IP instead of specifying each DNS IP. I did add a rule to forward Pi-Hole port 53 to WAN and then another to redirect all DNS to Pi-Hole but it didnt work - im assuming the router would then be blocked?
Anyway I have reverted back to hardcoding DNS settings per device as this keeps my own devices protected whilst not annoying the rest of the household.
Thanks for that link. I can't remember if I have seen it previously as I've scoured the forums and reddit for the solution to my problem but I'll take a look and see how it goes. I'm trying to redirect the hardcoded DNS devices to use Pi-Hole whilst retaining the device IP so I can apply different rules to different devices.
Yes there isn't much traffic from hardcoded DNS devices but on Android devices it appears to use Pi-Hole for half the trafic and 8.8.8.8 for the other half.
In the link you posted it appears that traffic will appear to be coming from the router rather than the device itself which wont allow me to customise blocking rules in Pi-Hole.
I might have to stick with manually specifying DNS entried on devices - it's the most reliable solution I've been able to achieve.
Yep, i don't really think there's a way to make the traffic appear as coming from the client,
since it's bouncing of the firewall.
The only solution I can think of is the Nebulo app for Android (there might be others too, don't know), which will rewrite the DNS call, and hijack it in the client.
But it requires a DoH or DoT for the name resolution to work, not a plain DNS.
In general: the pihole and the google stuff must reside in different networks resp. firewall zones.
My pihole sits in lan network and all smartphones and tablets have their own smart network. So it's easy to catch all DNS traffic (port 53) from the smart zone and redirect it to the pihole IP.
In the pihole logs I can see the DNS queries of every single device in the smart network. Works flawlessly since several months.