Pi-Hole should block ads on mobile and web, and all clients should be using Pi-Hole as their DNS, as defined in the router's network settings:
Eufy Tunable Light Bulbs, Pixel 3 XL and iPhone 12 Pro are either not using Pi-Hole or allowing ads, specifically ones with AdChoices beneath them on mobile and web browsers.
Your debug log shows that Pi-hole is working normally. Let's take a look at the details on one of the MBPs.
From the terminal on the Mac (and not via ssh to the Pi), what are the outputs of the following:
scutil --dns | head -n20
nslookup pi.hole
nslookup pi.hole 192.168.10.201
nslookup flurry.com 192.168.10.201
Hi @jfb, thanks so much for your help. Here are the outputs:
scutil --dns | head -n20 returns:
DNS configuration
resolver #1
search domain[0] : localdomain
nameserver[0] : 2601:645:4301:a940::1
nameserver[1] : 192.168.10.201
if_index : 6 (en0)
flags : Request A records, Request AAAA records
reach : 0x00020002 (Reachable,Directly Reachable Address)
resolver #2
domain : local
options : mdns
timeout : 5
flags : Request A records, Request AAAA records
reach : 0x00000000 (Not Reachable)
order : 300000
resolver #3
domain : 254.169.in-addr.arpa
nslookup pi.hole returns:
Server: 2601:645:4301:a940::1
Address: 2601:645:4301:a940::1#53
** server can't find pi.hole: NXDOMAIN
nslookup pi.hole 192.168.10.201 returns:
Server: 192.168.10.201
Address: 192.168.10.201#53
Name: pi.hole
Address: 192.168.10.201
nslookup flurry.com 192.168.10.201 returns:
Server: 192.168.10.201
Address: 192.168.10.201#53
Name: flurry.com
Address: 0.0.0.0
I should mention that at some point overnight, my Hue Bridge and iPhone lost connection to my WiFi network. The two most recent changes I made prior to my first debug were to change my interface listening behavior™ from eth0 to all interfaces and check the second upstream DNS server IPv6 box for CloudFlare. I rolled back the listening behavior to eth0 only, and everything was able to connect again. Let me know if I should do another debug.
I suspect that IPv6 address to belong to your router.
If that's the case, your clients are able to by-pass Pi-hole via IPv6.
You'd have to find a way to configure your router to advertise your Pi-hole host machine's IPv6 as DNS server instead of its own.
You'd have to consult your router's documentation sources on further details for its IPv6 configuration options.
If your router doesn't support configuring IPv6 DNS, you could consider disabling IPv6 altogether.
If your router doesn't support that either, your clients will bypass Pi-hole via IPv6.
Thanks for the response, @Bucking_Horn. I updated my router at the WAN level first according to the instructions found here and then set up for my primary LAN, but when I tried to configure my IoT network with the same IPv6 address, I get an error stating that the IP/Subnet overlaps with the defined in Primary LAN. I tried using one of the alternative IPv6 addresses outputs from ifconfig, but one of them has a prefix length of 128, and the other starts with fe80:: instead of 2601:. What would you recommend I do next?
I can't guide you much further.
I specifically cannot comment on your router's configuration, as I do not know it.
As far as router configuration is concerned, your router's documentation and support channels are probably a better source of information.
In addition, to better attract those of our community users who would perhaps use the same router as you do, consider including your router's make and model in your topic's title here.
For a start, note that local IPv6 DNS configuration differs from IPv4.
An IPv6 client may request DNS server information via DHCPv6 from your router, or it may pick it up from the advertisements your router broadcasts via NDP's RDNSS.
It would depend on the client which method it would use to figure its DNS configuration, e.g. Android will never use DHCPv6, and MS support for RDNSS only started with Win10. In a network with mixed clients, you have to make sure you meet their requirements and cover all of those options.
If you find your router to support configuration of a local IPv6 DNS server, make sure your Pi-hole is the sole such one.
As for the IPv6 address to use, you may list all IPv6 addresses of your Pi-hole's host machine by running:
ip -6 address show
You probably should avoid using a public GUA (range 2000::/3) for Pi-hole, as the IPv6 prefix is subject to be changed by your ISP (some ISP's switch prefixes on a regular basis, e.g. once every week or 24 hours) and the interface identifier may also change if IPv6 privacy extensions are active.
If your router supports it, you could consider to Use IPv6 ULA addresses for Pi-hole (range fd00::/8).
If it doesn't, using your Pi-hole's link-local address (range fe80::/10) is also an option, though that will only work if all your clients are on the same link/network segment as Pi-hole. For a single router home network, that's usually the case. Additional network equipment like switches and wifi access points may or may not split your network into multiple segments.
And as mentioned before, if you do not have to rely on IPv6 for some reason, you could also consider to disable IPv6 in your network as an ultimate measure, provided your router supports it.
That's a great idea, @Bucking_Horn, I've updated the title as suggested. That would be a great prompt to include in the template that shows up when creating a new help topic.
I was able to determine that my router does support local IPv6 DNS server configuration, including DHCPv6 at the LAN level so that's taken care of. It does not support ULA addresses. I found a blog post from Dec '20 which spoke of "a BusyBox operating system with DNSMasq performing the IPv6 router advertisements and DHCPv6 functions. The configuration more or less forces you to use DHCPv6, which is completely unnecessary for an autoconfigured IPv6 network (which was more or less a key point of IPv6)." I'm out of my depths here, so I'd prefer to avoid using the script-based workaround the author shares.
The IPv6 address you referenced in your initial reply is the same as the Pi-Hole IPv6 address found in the web admin network settings. When I plug that into an online subnet calculator, the range returns as /64. However, my understanding is that my ISP (Comcast Xfinity) only supports IPv6 ranges of /60. On top of that, when I run ip -6 address show, I see a /128 but a local link of /64.
My topology comprises 2 VLANs and 2 APs, so I'm guessing that takes using the Pi-Hole's link-local address out of consideration. Given my rudimentary understanding that IPv6 delivers certain benefits not found in IPv4 and is net-net good for the internet, I have a fairly strong preference against disabling IPv6 entirely.
In the current transition phase, it is difficult to judge whether you would overall benefit from IPv6, e.g. your favourite website may run IPv4 servers world-wide so data is served from the closest node, while it may run IPv6 only in its head-office country, so IPv6 packets may actually take longer. Also, there are still a lot of IPv4 only sites out there.
It's true that IPv6 offers certain advantages over IPv4, but organisational and computational benefits (e.g. larger address space, easier renumbering, faster routing, less load on routing nodes) lie mostly with ISPs and Internet infrastructure providers.
None of those are really relevant within a home network.
The only tangible advantage I can think of would be if you would run multiple publically accessible servers on the same port from your home network, which is but a bit easier and cleaner with IPv6 than setting up multiple forwards for different ports with IPv4.
/128 would be perfectly normal for either loopback or stateful DHCPv6 assigned IPv6 addresses. Your ISP supplied prefix length has nothing to do with neither.
You probably could consider to add a virtual MACVLAN interface to your Pi-hole's host network interfaces for each of your VLANs (using several statements like ip link add ... type macvlan - but that really is out of scope for Pi-hole 
).
You probably should further familiarise yourself with IPv6.
I doubt that to be correct: Pi-hole wouldn't have answered with that NXDOMAIN from your previous nslookup results, and ::1 is commonly what a router assigns itself.
Please share a new debug token, and also the output of ip -6 address show.
That wouldn't help with IPv6 issues - DHCP is strictly an IPv4 protocol.
And even if you enable IPv6 support in Pi-hole's web UI, that would only make Pi-hole's services available in addition to your router's - i.e. your clients still could make use of your router's IPv6 services as offered. Doing so would only make sense if you can completely disable propagation of IPv6 DNS servers in your router.
If you are able to do so, it may be worth to give that isolated router config a try.by itself.
By specifically disabling just IPv6 DNS servers in your router, you may force your clients to request DNS resolution exclusively via IPv4 (assuming all your clients are dual-stack, though).
For a large part, your remaining questions are not about Pi-hole specifically, but rather about IPv6 networking in general (click for more).
Thanks for the feedback; I was seeking to understand if I could use the Pi-hole to enable IPv6 instead of using my router given the fact that IPv6 config is supported by my router. I'm an amateur hobbyist at best, so it's hard enough explaining why we couldn't just keep using the old router 
Here's my new debug token and the output:
pi@raspberrypi:~ $ ip -6 address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2601:645:4301:a943::34c/128 scope global dynamic noprefixroute
valid_lft 79129sec preferred_lft 79129sec
inet6 2601:645:4301:a943:9f0e:447d:53e7:6424/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 86136sec preferred_lft 86136sec
inet6 fe80::d0dd:1d57:97dc:4642/64 scope link
valid_lft forever preferred_lft forever
I can disable it, so depending on what this output and latest debug show you, perhaps I let Pi-hole take over for IPv4/v6? I'd still want to understand if I can isolate my wife's work computer, but that's a bridge for later.
Pi-hole's core discipline is DNS.
The intention of Pi-hole's DHCP option is to provide a last resort measure for users with routers that wouldn't allow to configure DNS properly.
If your router would allow you to correctly configure Pi-hole's IPv4 and IPv6 address as local DNS server, there would be little reason to switch DHCP server functionalities.
As suspected, your Pi-hole doesn't live at ::1, but at ::34c, and both the shortness of that interface identifier as well as the /128 indicate that this is its stateful DHCPv6 address.
In absence of a ULA prefix and in the light of your VLAN requirements, you could consider to configure that address as Pi-hole's IPv6 in your router - provided your ISP wouldn't change your IPv6 prefix on a regular basis.
If it doesn't, you should make PI-hole aware of that IPv6 address by running
pihole -r
with Reconfigure.
If your network is subject to frequent IPv6 prefix changes, you probably should consider to work with additional macvlan interfaces on your Pi-hole host (as mentioned before).
Sounds like a plan, I'll consult my router's documentation to make these changes. I'm cautiously optimistic that it will be as straightforward as you make it out to be. 
Thanks so much for your patience and help troubleshooting, I really appreciate it!
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.