I am very new to Pi-Hole as of a couple days ago, and unsure if I have done the right thing. First off, what a wonderful job y'all have done, phew, this is fantastic, thank you!
Raspberry Pi 1B+ with a fresh install of the latest Raspberry Pi OS. This is the only application on this Pi
ISP is Comcast (US)
TP-Link AX3000 router. Its DHCP statically sets the IP of the Raspberry Pi (let's say 192.168.0.123), which is then used as Primary DNS while secondary DNS is 9.9.9.9.
Pi-Hole's upstream DNS servers for IPv4 are set to "Quad9 (filtered, DNSSEC)" (resp. 9.9.9.9 and 149.112.112.112), nothing set for IPv6.
DNS resolver privacy level is set to "Show everything and record everything"
Running my tests on a macOS laptop with Chrome. Client ad-blocker used below is uBlock Origin. I normally always have uBlock Origin enabled, but after seeing just as many ads on my phone, I decided to disable it while running some tests.
Nothing in whitelists/blacklists
Adlists as follows, the default list from Steven Black + a bunch from the Firebog (Suspicious lists #1 to #3, Advertising lists #1 to #5, Tracking & Telemetry lists #1 to #5, Malicious lists #1 to #5). I correctly updated gravity after adding those lists.
Expected Behaviour:
The combination of lists above results in 340,395 domains being monitored. Currently 11.4% of my queries are blocked (4,327 out of 37,935 at the time of writing this).
Given all of this, I would expect that most ads I run into get trapped by Pi-Hole. In fact, I would expect that some websites are ad-free, like cnn.com which I have seen recommended as a test with blatant results.
Actual Behaviour:
In practice, it looks and feels like... Pi-Hole is not even working. I see extremely few differences whether Pi-Hole is enabled or disabled.
(To be clear, I am talking about regular ads in web pages, not ads on, say, Youtube/Hulu/etc. as I realize those are outside the scope of Pi-Hole.)
See the following screenshots that display some pages with Pi-Hole enabled vs. what I see with uBlock Origin enabled for some sort of comparison.
I did not include the screenshots with Pi-Hole disabled because they are literally the exact same ones as with Pi-Hole enabled.
I am dumbfounded, what am I missing here?!
Did I forget a simple step or 2? Is it just a matter of needing to add more lists?
Is cnn.com supposed to display those ads with Pi-Hole?
I think the problem is the use of that secondary DNS in the router's DHCP. The primary DNS is the Pi-hole, which is great, but the secondary is Quad9's server.
It's commonly believed that primary and secondary means "use primary, unless it's not available, in which case use secondary". However that's not the case. Most current OS will use all available DNS servers, and usually have some metric which goes with the fastest or most reliable over time. Therefore it's highly likely that your computers are often simply using Quad9 and ignoring Pi-hole.
What are you seeing in Pi-hole's Query Log? Are you seeing queries from your test computer for CNN and the various other sites you're trying? Or is it looking very quiet in there, which is another indication it's not using Pi-hole?
Are you able to remove that secondary DNS from your router's DHCP so it's only giving out Pi-hole's IP? If it requires two servers, you could try making both entries the Pi-hole IP as a workaround; that sometimes works (depends on the router and its firmware). Then take the computer offf and back on the network to pick up the new settings, and test again.
Oh interesting, I thought it was in my best interest to have a secondary DNS setup if, say, my RPi were to die or something.
I have removed the secondary DNS from the router DHCP, switched off wifi on the laptop then back on to rejoin the network, but unfortunately same result on cnn.com, ads galore.
After this change (I forgot to look before, sorry!), I wouldn't say the Query Log is quiet, there is definitely activity and even mention of "cnn.com", but it's not as busy as I would have expected.
Adding a few more details to the context:
Running scutil --dns | grep 'nameserver\[[0-9]*\]' on the laptop returns:
I was surprised to see the following however on my router's status page, although outside of the DHCP configuration (therefore not editable), and I'm not sure if that has any impact:
You can see in your screenshot that the router's IP might still be in use here for DNS. If so, that will also bypass Pi-hole. You want Pi-hole's IP to be the only DNS in use.
Those are Comcast DNS servers for the router to use. Think of them as the router's upstream DNS servers. With you directing clients to use Pi-hole instead they're not so relevant, although the router itself can still use them. If you want you can use those with Pi-hole, by setting them as the Custom 1 and Custom 2 servers in Settings > DNS, and unticking the others.
Do you know how I can possibly remove my router's IP from that list?
I'm sure I can do it from the macOS settings, but that would kind of defeat the purpose as it doesn't seem practical to do that from the few dozen clients I have on the network (if even possible in some cases).
Makes total sense re: Comcast DNS, and no I don't think I would like to route them more data than they need to know lol.
However, I just saw that I can indeed update those values:
You have your Pi-hole IP, plus the router's IP and both Google IPv6 public servers in use. The Google servers would theoretically allow Pi-hole to be bypassed, but your debug log happens to test for IPv6 resolution, and it was unable to reach Google's IPv6 public server, suggesting you don't have IPv6 outside of your LAN. This means the Mac wouldn't be able to use those two Google DNS addresses.
As for the router IP, it may be that this router silently advertises itself in the DHCP response, as well as the servers you specify in its settings. You can poke this a bit and see what you get – on the Mac (at least on older macOS) it's in System Preferences > Network > select the wired/wireless interface in use > Advanced... > DNS.
You can see the items offered by DHCP in there as greyed out entries. You may find that some of them are relics from a previous setup and can be deleted. Once you're happy with it, try going back to the TCP/IP tab and using Renew DHCP Lease to hit the router for updated values. Then go back to the DNS tab and see if they've all come back again. Should help determine where they're coming/came from.
You asked about changing your router's upstream values, and then tried it and it broke things. I was going to reply to say you can leave those alone, since those are the DNS servers used by the router itself, and any clients using the router for DNS. The fact that it broke things shows that your Mac is indeed bypassing the Pi-hole and using the router. Try those earlier DNS edits in the Mac settings and see if you can get it down to just the Pi-hole IP, even if temporarily for testing.
Nice one, that little hack often works. You may be seeing ads because those domains previously resolved and they are cached in the Mac. You can flush that cache – in macOS 10.12 and above it's:
Oh, interesting. Again, I'm not super knowledgeable about this so that's helpful, thanks. I don't know if this helps inform anything, but this is the IPv6 config in my router settings:
Sadly nothing too relic-ey as the match what the CLI command returns.
I cannot delete any of these of course, but I can set the Pi as the only value in there:
Alright I did that and the DNS tab still shows the only server I set (last screenshot). If I remove it, I have the same 4 servers as the screenshot before that.
That's helpful, thanks!
I did just that (last screenshot), renewed the DHCP lease, tried again... ads and ads again
Neither of these things worked either, unfortunately.
Any other idea?
I wanted to wait and see how Pi-Hole runs on my network before setting up Unbound on the Raspberry Pi, but could it help at all?
Also I'd rather avoid setting the Pi as the DHCP server if possible...
Just a suggestion from a fellow user: you may want to toggle off the IPv6 setting button on your router, especially while you're getting things set up for the first time. Since the router is making IPv6 available to your LAN, you have to make sure your Pihole is expecting that and it requires chasing down the right DNS addresses, etc.
When I ran a Synology router, I tried a similar effort as you with IPv6 but kept running into unexpected ads and other things. So I turned IPv6 off and stuck to IPv4, and my Pihole situation was much easier to manage. I didn't miss out on a thing by not allowing my router to use IPv6, since Pihole can resolve AAAA records (IPv6) either way.
You can always turn it back on when you feel like you've got a good handle on Pihole/Unbound with IPv4, or you can leave it off.
Thank you @nprampage, I'm going to try this. @chrislph, do you confirm this is something I might want to look into? Or is there anything else I should try instead / on top of it?
Omg that was it! I don't know why I didn't try that earlier, tbh. Maybe because I don't like not running IPv6 (mostly an opinion initially, then turned muscle memory).
Anyway, I can easily test back and forth, enabling/disabling IPv6 on my router and reconnecting to the network, and each test correctly hides or shows ads accordingly. I'll be damned.
You're right, I'm going to leave it disabled for now while I'm testing things and making progress, but I'd love to try and enable this later on once Unbound/etc. are satifactory to me. Let me know if you have any resource on the Pi-Hole + IPv6 topic I could learn from
Thank you, fellow user! (and @chrislph as well of course, I learned a ton!!)
As for other IPv6 resources, 95% of the useful information I gained was from searching on this forum. I played with it for a while but eventually left it behind as everything was running fine with IPv4 and IPv6 wasn't really gaining anything for me.
In order to get IPv6 working reliably under Pihole for DNS lookups, I had the best results using the non-changing v6 address assigned to my RPi Ethernet adapter - the one that begins with fe80: in my case. I think that's the link-local address?
The challenge that came up and eventually moved me to drop the whole thing: my client machine IPv6 addresses made it appear as a different machine from the IPv4 address, if that makes sense. For example, the Pihole clients list would show my main PC as 192.168.1.48, and it would have a unique entry for the same main PC but with an IPv6 address of, say, fe80::802a:635b:f8f0:1234.
It just became too much of a hassle to reconcile these so that the Dashboard didn't have redundant entries. And again, since from an operational standpoint, I really didn't gain anything from IPv6, I simply turned it off at the router. Your mileage may vary, but that was my experience and reasoning.
