Why a perfect IPv4 setup isn't enough
The usual Pi-hole recipe sets the router's DHCP server to hand out Pi-hole's IPv4 address as the DNS server. That only covers DNS delivered over IPv4.
IPv6 configures devices differently. Routers can include a DNS server in Router Advertisements using an option called RDNSS, hand one out over DHCPv6, or do both. Sherback also reports that many consumer routers advertise themselves out of the box, frequently by a link-local address starting with fe80. A device can therefore end up holding two resolvers, Pi-hole over IPv4 and the router over IPv6.
The relevant standard, RFC 6106, is candid about this. It says that when DNS options come from multiple sources such as RA and DHCP, hosts should keep options from all sources. It then warns that you can't control how a host uses that information or which source it uses to send queries. It adds that mismatched information across sources "may lead to problems". The standard puts the burden on the network administrator to keep the sources consistent.
Pi-hole itself isn't broken here. The problem is which resolver the client picks. Pi-hole community moderators have given the same diagnosis in forum threads. In one, they say the router would be advertising its own IPv6 address as a DNS server, allowing clients to bypass Pi-hole.
Why only some devices leak
Partial leaks are the dangerous kind. If every device bypassed Pi-hole, the dashboard would go quiet and you'd notice. Sherback's point is that when only a few devices leak, the graph still looks healthy.
He says clients differ in how they pick up IPv6 DNS. He describes Android as leaning on RDNSS, and says Windows historically used DHCPv6, gained RDNSS support later, and still prefers a DHCPv6-supplied server when it gets both. That Windows preference is his claim. I couldn't confirm it against Microsoft documentation, so check what your own machines report. RFC 6106 only says that handling of multiple sources is up to the client implementation.
His router example is a TP-Link Archer. It offers ND Proxy, DHCPv6, SLAAC+Stateless DHCP and SLAAC+RDNSS modes. In a stateless-DHCPv6-only mode, Android phones may never pick up an IPv6 resolver and stay on Pi-hole, while Windows machines take the router's. An RDNSS mode hands the router's resolver to the phones as well. That is one router. Other models label and behave differently, so don't assume your router matches.
How to check for the leak
- Compare Pi-hole's Clients view with your real device list. A device that is missing is a lead, not proof.
- Check the DNS servers on the suspect device.
- Windows: run
ipconfig /alland read the DNS Servers entries for the active adapter. Microsoft documents this command for viewing IP configuration details. - macOS: run
scutil --dns. Apple also documents where DNS servers appear in System Settings under Network, then Details, then DNS. - Linux: run
resolvectl status.
- Windows: run
- Look for any resolver that isn't Pi-hole. Sherback treats an fe80 address or an ISP IPv6 resolver sitting next to Pi-hole as the culprit. Be a little more careful than that. An fe80 address is just link-local, and Pi-hole's own Ubiquiti guide shows a Pi-hole host with its own fe80 address. Work out whose address it is. If it belongs to the router or the ISP, you've likely found the leak.
- Confirm with the query log. If the device doesn't appear there while it's browsing, its DNS isn't going through Pi-hole. One community guide makes the same point. It says to check the query log first and to fix DNS routing before touching blocklists.
How to close it
Option 1: advertise Pi-hole over IPv6 (the cleaner fix). Give Pi-hole a stable IPv6 address, then have the router advertise it as the DNS server.
- Pi-hole's Ubiquiti USG guide says to uncheck Auto under DHCPv6/RDNSS DNS Control and enter the Pi-hole's IPv6 address. Clients should then get a single IPv4 and a single IPv6 DNS address. The guide says to toggle Wi-Fi or reconnect the cable if clients don't update quickly.
- Pi-hole's Fritz!Box guide takes the same approach. It suggests enabling ULA addresses, using Pi-hole's stable ULA address as the local DNSv6 server, and also announcing it via router advertisement. It recommends changing the ULA prefix to avoid collisions with other networks.
- A community walkthrough of IPv6 home DNS recommends configuring both RDNSS and DHCPv6, because client support varies.
These are router-specific examples. Look for the equivalent controls on your own model.
Option 2: turn off IPv6 at the router. If you don't use IPv6 services, this is the blunt fix Sherback chose. A Pi-hole forum moderator has suggested it too, provided you don't depend on IPv6. The same thread notes a hard limit: if your router can't change its IPv6 DNS advertisement or switch IPv6 off, IPv6-capable clients can always bypass Pi-hole.
Some ISP routers don't offer the controls. One Verizon G3100 user reported that the router advertised itself as the IPv6 DNS server, and the ISP's support told him to turn IPv6 off completely. That is one user's report and may not apply to your firmware.
After any change, renew the client's connection and recheck the resolver list. A good result is that Pi-hole is the only DNS server shown for both IPv4 and IPv6. The alternative is that no rogue IPv6 resolver is advertised at all.
A stale address can also cause trouble. One Pi-hole forum user kept seeing an old Pi-hole's IPv6 address in ipconfig /all after migrating servers. DNS broke when the old box was switched off.
Other ways around Pi-hole
IPv6 isn't the only bypass. Sherback also lists DNS-over-HTTPS and devices with hardcoded public resolvers. He says Firefox is good at backing off when a block is detected. He also says Pi-hole blocks the domains Apple uses to check whether iCloud Private Relay can run.
Pi-hole's Fritz!Box guide goes further for hardcoded resolvers. It suggests a filter rule that blocks outbound DNS from everything except the Pi-hole. You can then test it with dig google.com @8.8.8.8 +short from the Pi-hole and from another device. The Pi-hole should get an answer, and other devices should get an error. Some devices with hardcoded DNS may break under such a rule, so you may need to exempt them.
What to take away
- Pi-hole's dashboard shows the traffic that reaches it, not proof that every device uses it.
- IPv4 DHCP settings don't control IPv6 DNS. Check the router's separate IPv6 DNS, RDNSS and DHCPv6 settings.
- Which device leaks depends on the router mode and on how each OS handles multiple DNS sources.
- The fix is either to advertise Pi-hole's stable IPv6 address, or to disable IPv6 if you truly don't need it.
- Verify the result on a Windows, Mac or Linux client instead of trusting the dashboard.