Pi-hole not blocking ads? Check your router’s DNS and IPv6

A DNS blocker (Pi-hole, AdGuard Home, AdHole’s DNS filter) can only filter the questions it receives. If a device sends its questions somewhere else, even some of the time, the blocker never sees them, and nothing on its dashboard tells you why. So before touching the blocklists, check who your devices are actually asking.

How a device picks its DNS server

When a device joins your network, the router gives it an address and one or more DNS servers. That’s DHCP, for IPv4. On IPv6, the router can also announce DNS servers in its router advertisements: the standard for it, RFC 8106, lets a device get “the DNS information simultaneously without needing DHCPv6”.

With several DNS servers, a device doesn’t split its questions fairly between them. Windows, for example, asks the first server in its list and only moves to the next after a second without an answer. Microsoft’s documentation sums it up: “Client tries new servers only if the previous are unreachable.”

Hence the rule the Pi-hole community repeats: a moderator on its forum puts it this way: “Pi-hole needs to be the only DNS server because it intercepts queries and decides whether or not they should be blocked.” And Pi-hole’s own docs tell you to configure your router so that DHCP clients use Pi-hole as their DNS server.

Trap 1: the router puts itself first

The usual advice is to enter your blocker’s address in the router’s DHCP settings. We tried it on 12 September 2026, on a Bouygues Telecom Bbox (Fast5330b-r1, firmware 24.7.18, a common ISP router in France).

The router’s DNS option pointed to the router itself, greyed out, impossible to change. You can add a second DNS option, but the router doesn’t replace its own: it appends yours behind it.

Before: DNS handed out = 192.168.1.254
After:  DNS handed out = 192.168.1.254, 192.168.1.142   <- the router stays first

We confirmed it by renewing the address lease on a Windows PC, which received both, in that order. Since the router always answers, the blocker behind it is almost never asked, while everything looks correctly set up. We removed the added option afterwards.

Not every router behaves like this. Some let you replace the DNS entirely. Check what yours actually hands out, rather than trusting its settings page:

ipconfig /all

On Windows, this command lists the “DNS Servers” of each network adapter. If the router’s address appears there next to your blocker’s, and especially before it, you have found the leak.

Trap 2: IPv6 goes around the blocker

Even with IPv4 correct, many routers also announce their own resolver over IPv6. The same Bbox did, and the test PC received:

IPv4 DNS: 192.168.1.254
IPv6 DNS: 2001:db8::1   <- the router (address shortened here)

Nothing in that router’s interface changes this announcement, and on our test PC the IPv6 resolver was the one Windows preferred. A contributor on the Pi-hole forum describes the same leak: the router “would advertise its own IPv6 address as DNS server, allowing your clients to by-pass Pi-hole.”

Phones make this harder to fix from the router. Android has long set up IPv6 from the router’s announcements alone: “Until now, Android only supported SLAAC”, Google’s Android team wrote in September 2025, as it announced support for DHCPv6 prefix delegation. For years, a DHCPv6 setting on the router changed nothing for them.

ipconfig /all shows the IPv6 DNS servers too. If one of them belongs to the router, IPv6 is going around your blocker.

Trap 3: devices with a DNS of their own

Some devices ignore the DNS they’re given and use a public resolver directly. Paul Vixie, one of the authors of today’s DNS software, reported on the IETF’s DNS mailing list in 2019 that his Chromecast Ultra “would not start until i began answering 8.8.8.8”, Google’s public resolver. No DNS setting catches those. Only a router that redirects outgoing DNS traffic can.

What works: set the DNS on each device

Setting the DNS by hand on each device goes around the first two traps: the device asks exactly what you typed, and nothing else.

1. Give the blocker a fixed address, with a reservation in the router’s DHCP settings.
2. On each device, in its network settings, switch DNS from automatic to manual and enter the blocker’s address. Leave no second server, or enter the same address twice if a second field is required.
3. If the device uses IPv6, set its IPv6 DNS to manual and leave it empty, or turn IPv6 off on that device. Otherwise it goes back to the router.

It takes a couple of minutes per device, once. The device-by-device guide has the menus for common TVs, consoles and phones.

On the computer where AdHole is installed, you don’t do this by hand: AdHole sets that computer’s DNS to itself and keeps your router behind it as a backup, found automatically, so the connection survives if AdHole stops. For every other device, the manual setting above is the way: AdHole doesn’t change your devices’ settings for you.

The clean fix: a router you control

If you’d rather not touch each device, the lasting fix is a router whose settings you fully control, placed behind your internet provider’s router. Routers running OpenWrt are a common choice. There you can hand out a single DNS server, stop the IPv6 announcement of another one, and redirect outgoing DNS traffic so that devices with a hard-coded resolver are caught too. It’s more work, and it’s the only setup that covers the whole home without exceptions.

A quick diagnosis

AdHole’s dashboard shows the ten devices that ask it the most, and a live feed of requests with the device that made each one: a TV or a console that never appears there, even while you use it, isn’t asking AdHole, whatever its settings page says.

Sources checked on 5 October 2026 and linked in the text. Router test: Bbox Fast5330b-r1, 12 September 2026.