Wi-Fi & Network
Force every device through Pi-hole
A Pi-hole only filters the queries that reach it. This guide closes the common bypass paths in order — DHCP, IPv6, browser/OS encrypted DNS, and hardcoded resolvers — so the whole network actually resolves through it.
Who this is for
Home operators who already run Pi-hole (or AdGuard Home) but find that some devices still see ads or resolve through a public DNS — and want every client on the LAN to resolve through the filter, not just the ones that behave.
Outcome
A network where DHCP hands out the Pi-hole address for IPv4 and IPv6, browser and OS encrypted-DNS leaks are closed, and hardcoded-resolver devices are redirected or blocked at the firewall — verified by seeing every client's lookups appear in the Pi-hole query log, with any genuine exceptions documented.
Required inputs
- A working Pi-hole/AdGuard Home on a fixed LAN IP (static or DHCP reservation), reachable by all clients.
- Admin access to your router or firewall — for DHCP DNS options (IPv4 and IPv6/RA) and, ideally, NAT/firewall rules for outbound port 53 and DoH endpoints.
- A test client you can read network settings on (Windows ipconfig /all, or the Wi-Fi details on macOS/iOS/Android) to confirm the handed-out DNS.
- A reversible mindset: roll changes out, watch for the one or two devices that break, and allow them explicitly.
Step-by-step procedure
Pin Pi-hole to a fixed address and set it as the only DNS in DHCP
Do: Give Pi-hole a static IP or DHCP reservation. In the router/DHCP settings, set the DNS server handed to clients to that IP and remove any second/ISP DNS entry. Renew the lease on a test client.
Expected result: On the test client, ipconfig /all (or the OS Wi-Fi details) shows the Pi-hole IP as the only IPv4 DNS server.
If not: If a second/public DNS still appears, the router is handing out a fallback or you edited the wrong field — clients will use whichever answers first, so remove the extra entry before continuing.
Close the IPv6 DNS leak
Do: Check whether the router advertises an IPv6 DNS (via Router Advertisements/RDNSS or DHCPv6). Point IPv6 DNS at Pi-hole's IPv6 address, or disable the router advertising a non-Pi-hole IPv6 resolver. If you don't run IPv6 DNS through Pi-hole at all, ensure clients aren't being handed an ISP IPv6 resolver.
Expected result: The client's IPv6 DNS is Pi-hole (or no rogue IPv6 resolver is advertised), so IPv6-preferring clients still resolve through the filter.
If not: If clients keep an ISP IPv6 DNS, they'll silently bypass Pi-hole for IPv6 lookups even though IPv4 is correct — fix the RA/DHCPv6 DNS option or disable that advertisement.
Disable or block browser DNS-over-HTTPS
Do: Turn off Secure DNS/DoH in browsers (Chrome/Edge 'Use secure DNS', Firefox 'DNS over HTTPS'). To do it network-wide for Firefox, configure Pi-hole to return NXDOMAIN for the canary domain use-application-dns.net so Firefox disables its default DoH automatically.
Expected result: After disabling DoH, lookups from that browser appear in the Pi-hole query log.
If not: If a browser still bypasses, it may be using DoH by raw IP — block known DoH endpoints at the firewall (see step 5) rather than relying on the canary alone.
Turn off OS-level encrypted DNS bypasses on clients
Do: On phones/tablets, set Android 'Private DNS' to off/automatic (not a public DoT provider), and on Apple devices turn off iCloud Private Relay for the home Wi-Fi if you want that traffic filtered. Note any always-on VPN that carries DNS elsewhere.
Expected result: Mobile clients' lookups now land in the Pi-hole log on home Wi-Fi.
If not: If a managed/work device enforces its own DNS or VPN, accept it as outside your filter rather than fighting policy — document it as an exception.
Redirect or block hardcoded resolvers at the firewall
Do: For devices that ignore DHCP (some streaming sticks query 8.8.8.8 directly), add a firewall rule to redirect all LAN outbound port 53 to Pi-hole — and include the SNAT/masquerade so replies translate back — or simply block outbound 53 to anything but Pi-hole. Block known DoH provider endpoints too so they fall back to plain DNS.
Expected result: The stubborn device's lookups now appear in the Pi-hole log (or it falls back to the LAN resolver), confirmed against the firewall logs.
If not: If a redirect 'works' in nslookup but real apps freeze, you almost certainly omitted the SNAT/masquerade rule — replies are arriving from the wrong source IP and being dropped.
Verify end-to-end and document exceptions
Do: Walk each device class (laptop, phone, TV, IoT) and confirm its queries appear in the Pi-hole log. For anything that broke when forced, add an explicit allow/exception and write down why.
Expected result: Every device either resolves through Pi-hole or is a documented, intentional exception.
If not: If a device still bypasses with no obvious leak left, re-check IPv6 and DoH-by-IP — those are the two most-missed paths.
Commands and settings paths
Confirm the handed-out resolver
ipconfig /all (Windows) • Wi-Fi > network details (macOS/iOS/Android)
Where: On a test client after renewing its DHCP lease.
Expected: Pi-hole's IP is the only DNS server listed, for both IPv4 and IPv6.
Failure means: A public/ISP resolver or a second DNS entry means DHCP or IPv6 RA is still overriding Pi-hole.
Safe next step: Remove the extra/IPv6 resolver in the router and re-renew the lease.
Prove queries reach Pi-hole
nslookup pi.hole then watch Pi-hole > Query Log filtered to the client IP
Where: On each device class while browsing.
Expected: pi.hole resolves to the Pi-hole IP and the client's lookups stream into the log.
Failure means: An empty log for a client confirms a remaining bypass (DoH, Private DNS, VPN, or hardcoded resolver).
Safe next step: Identify the bypass via the steps above and close it; block port 53/DoH for hardcoded devices.
Check for hardcoded outbound DNS
Firewall/router logs for outbound UDP/TCP 53 to a non-Pi-hole IP
Where: In the router/firewall logging view.
Expected: No client reaches an external resolver directly (or only documented exceptions do).
Failure means: A device querying 8.8.8.8/1.1.1.1 directly is ignoring DHCP DNS.
Safe next step: Add the redirect (with SNAT) or block rule for that device, then re-verify.
Evidence to record
- The handed-out DNS on a representative client for both IPv4 and IPv6 (screenshot or ipconfig /all output).
- Whether the router advertises an IPv6 DNS and what it points at.
- Which clients required a firewall redirect/block for port 53 or DoH, and which are documented exceptions.
- A query-log snapshot showing lookups from each device class after the changes.
Common mistakes
- Setting only the router's *upstream* DNS to Pi-hole and assuming clients are covered — clients get DNS from DHCP, not from the router's own upstream.
- Fixing IPv4 but leaving an ISP IPv6 resolver advertised — IPv6-preferring clients bypass Pi-hole silently.
- NAT-redirecting port 53 without the SNAT/masquerade rule — nslookup looks fine while real apps and games quietly time out.
- Blocking DoH by domain only — a client using a DoH server by raw IP sails past a domain blocklist; block the endpoints by IP/port.
- Expecting forced DNS to remove YouTube/first-party ads — that's a structural DNS limit, not a configuration gap.
Stop points
- Stop and allow an exception rather than escalating if a device (smart TV, work VPN, captive portal) genuinely breaks when its DNS is forced.
- Stop before blocking outbound 53 network-wide if Pi-hole itself isn't reachable/healthy — you'll take down all resolution.
- Stop before disabling iCloud Private Relay or a work VPN on a managed device without the owner's say-so.
Last reviewed
2026-06-02
Source-backed checks
HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.
Did this solve your problem?
Your answer helps us improve this page.
No account or personal details. We store the page, answer, optional reason and day with a 90-day retention period. A random reference in this browser prevents repeat votes. Feedback privacy
Get the deal & firmware alerts
Home Stack Field Notes: NAS deals, firmware changes worth acting on, restore-test reminders, and new decision guides — plus the capacity & backup sizing cheatsheets from our calculators. Unsubscribe anytime.
Subscribe on beehiiv