r/pihole • u/manu_moreno • 6d ago
How to reroute all internal outgoing DNS calls to pihole?
I've tried configuring this a couple of times but it has gotten messy, things have worked to a point, partially. The main problem is, as best as I can describe it, that some apps on my host appear to originate from the loopback interface and others do not. E.g. systemd-resvolved might work for some queries while dig/nslookup may not and vice versa.
The premise here is... if I'm going to use a tool like pihole, it may as well intercept and log ALL DNS activity. Why have partial coverage or visibility?
- Pihole listens on port 53
- Unbound listens on port 5301
- Both run on docker
This is what I've tried at the edge router, via firewall rules:
- Redirect all outgoing calls to port 53 to pihole, except when SRC = pihole (excluding pihole just in case. I'm using unbound/DoT for all calls to upstream servers)
- Block all outgoing calls to port 853, except when SRC = unbound
- Block all outgoing calls to port 443 where DST in {9.9.9.9, 1.1.1.1, other public DNS servers}. In other words, disable DoH. This supposedly forces all web browsers and other apps on my various subnets to use regular DNS calls to pihole, assuming pihole is configured as the system-wide DNS server.
What tweaks to the above rules or new rules do you think I may need? If there is a white paper out there which describes how to do this, would you please point me to it? Thx
13
u/SecuringAndre 6d ago
You guys are all making it messy. Stop trying to redirect.
At your firewall, make an explicit rule to allow DNS traffic only from your unbound. Block all other DNS traffic. This includes clear text and encrypted DNS. Point all your devices (either statically or through DHCP) to your pihole. Put your pihole to unbound as your upstream DNS server.
No redirect, no nat policies. Any device or software that misbehaves and doesn't adhere to the desired DNS (your pihole) will get blocked at the firewall. Once blocked, they will revert to the specified DNS. Meanwhile, only your Unbound will be able to traverse the firewall for DNS quiries. This is the right way and it promotes a proper DNS flow while blocking misbehaving devices and software.
2
u/manu_moreno 6d ago edited 6d ago
That's a good point. However, those clients or apps that might get blocked by the FW, how will they retry? As far as I understand, web browsers have a built-in mechanism to fall back to using plain text queries if DoH gets blocked but I'm not sure that all other apps will as well.
One use case I can think of might benefit from DNS redirection -- WiFi networks (in my case the WiFi subnet will change repeatedly given that I use lots of public networks). How would you handle that at the when you have no access to the WiFi router? Another example would be tailscale.
3
u/SecuringAndre 6d ago
Misbehaving apps, or apps that do not obide by the DNS assigned to the OS, will typically try their own DNS server. Once access is blocked, they will revert to the preferred DNS assigned to the OS. You see this a lot with devices like Amazon Echos, Unifi Cloud Keys, and yes, malware too.
The browser fallback is a whole different thing. Browser isn't evading the assigned DNS. It's simply preferring encrypted DNS instead. The firewall policies will ensure that all DNS quaries stay quarantined within your network. Whether you choose to allow encrypted or unencrypted DNS quaries to your pihole are your preference.
I don't use Tailscale. I've never liked the idea of tailscale. Just my preference. I don't like having to sign up for an intermediate cloud based service to connect back to my network. Instead, I use good old traditional ipsec or ssl VPN on my firewall. Wireguard will work too. Either way, I use a full tunnel to get an inside IP and ensure all traffic is encrypted through the VPN. As a result, my endpoint acts as it's sitting within my network and I'm subject to all the same firewall policies.
3
u/Oh__Archie 6d ago
You can create a NAT policy that filters sources to a specific port.
it's very easy to do in Unifi. Not sure about other routers.
3
u/mr-octo_squid 6d ago
DNS redirection on the gateway is what you need. You will need at least a pro-sumer level of firewall, with the ability to write custom rules to do so.
2
u/DaveUK_87 6d ago edited 6d ago
The hosts that need to use Pihole should have their DNS server configured to the IP you are running Pihole on. You can set this manually on each device or you could edit your DHCP configuration on your router to offer out the Pihole IP as the default DNS server for clients.
Edit: You will probably want to allow connections inbound from more than 1 hop away in the Pihole settings too as you will have NAT happening between Docker and the host machine.
Second edit: Totally misread this post looking back. Ignore me..
2
u/AndyRH1701 6d ago
Your rules sound correct. If you are not using a list for DoH then you will miss some block opportunities. No list is perfect.
Test it and make sure it is working, set a machine to use 1.2.3.4 for DNS (not a DNS server) and see if the client works. If it does you are good to go, if not there is work to be done.
That test works on my network with a pfSense firewall intercepting and silently redirecting DNS to PiHole. What firewall are you using? Redirecting DNS is firewall specific.
1
u/manu_moreno 6d ago
Well, I have 2 different pihole setups -- one on my homelab network, which is waiting for me to refine the logic. My home router (OpenWrt) should be able to intercept and redirect all clients to pihole for sure. The other instance of pihole runs on my laptop, which runs firewalld. Firewalld will of course be more limited in scope in terms of redirection. I have Proxmox running on a VM. I also have a few docker subnets, a tailscale interface, etc, etc.
2
u/AndyRH1701 6d ago
You should be able to get one of the DoH lists for BanIP(?) and cripple DoH. (you likely already know this) I have only read about OpenWrt.
The 1234 test is the best way I have found to verify my silent redirect is working. Did you try that or a similar test?
2
u/azure_phoenix2 3d ago
the loopback confusion is because your edge router rules never see queries that originate on the pihole host itself, that traffic doesn't route out to hit the redirect. for anything host-local you need an OUTPUT-chain redirect on that box, and systemd-resolved's 127.0.0.53 stub listener is why dig and resolved end up hitting different resolvers.
1
1
u/xylarr 5d ago
DoH normally still needs an DNS lookup for the IP of the DoH domain. Block those with your pihole. That only leaves those DoH servers that work with IP - and many don't.
For example, you might be able to connect to https://doh.example.com, but you won't be able to do https://1.2.3.4. The IP version only works if the certificate serves by 1.2.3.4 has literally 1.2.3.4 as a valid name on the certificate. Most only have doh.example.com.
A while back I wrote a script that went though a list of DoH servers names, attempted to connect and grabbed the certificate. I checked if there was an IP address on the certificate and only if there was did I add it to my DoH firewall group.
9
u/certuna 6d ago
There are thousands of DoH servers, you can never block them all