HomeTechOps

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.
GuideFollow in order

Step-by-step procedure

1

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.

2

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.

3

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.

4

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.

5

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.

6

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.

Pi-hole documentationUsed as the first-party reference for Pi-hole install, configuration, and the v6 documentation set.Mozilla Support: Canary domain — use-application-dns.netUsed for disabling Firefox default DNS-over-HTTPS network-wide by returning NXDOMAIN for the canary domain.AdGuard Home wiki: Comparison with Pi-holeUsed for the AdGuard Home feature delta — built-in DHCP and native encrypted-DNS (DoH/DoT/DoQ) upstream and server — versus Pi-hole.FCC: Home network tipsUsed for router placement, congestion, and baseline home-network troubleshooting guidance.