Pi-hole should continue blocking ads as usual, just as until a few days ago.
Actual Behaviour:
Ads getting through! Running pihole -q <domain> does show hits in the blocklists, yet, a number of such domains are accessible. Note, not all, but a number of them. Additionally, I made no change recently (except until yesterday when I decided to reboot RPi after noticing this issue).
From a client that you believe should be connected to the Pi-Hole for DNS (choose one where you see ads), from the command prompt or terminal on that client (and not via ssh or Putty to the Pi), what is the output of
It's interesting to see certain ads getting blocked while others aren't. I just verified using an adult website (purely for the ad test). This was on my desktop computer. I also tried on my Android phone, and could see certain ads a number of times, but not always.
Your router (the DHCP server) is providing its own IP as well as the Pi-hole IP for DNS. Clients are free to use either at any time, which likely is leading to Pi-hole bypass.
That's interesting!
I've explicitly set it up as the only DNS server for the DHCP, and yet the router is injected as a DNS?
Is that visible in the Debug logs? And the other question would be, how come it's been okay thus far!
EDIT: So I modified the DNS entries to both be the same, 192.168.1.101. The log does reflect that as well.
Updated log: https://tricorder.pi-hole.net/zG34qyXs/
However, I'm still seeing ads get through.
Yes, that's exactly what your router's DHCP server is doing.
There are routers that would misbehave in that way (and also other ways) when it comes to DNS.
Yes, within the section that verifies DHCP server replies in your network.
It's the very section that jfb quoted from - I'll give you a bit more context:
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
Scanning all your interfaces for DHCP servers
* Received 300 bytes from eth0:192.168.1.1
Offered IP address: 192.168.1.101
DHCP options:
Message type: DHCPOFFER (2)
dns-server: 192.168.1.101
dns-server: 192.168.1.1
router: 192.168.1.1
The following command may come in handy when trying to verify your DHCP server's behaviour (it's the same command that produces the debug log output):
pihole-FTL dhcp-discover
As long as it is continuing to provide its own IP as dns-server, clients will be able to by-pass Pi-hole completely.
Thank you!
I wasn't aware of this misbehavior of certain routers. Very misleading and annoying, at the very least.
After making 192.168.1.101 as DNS for both DNS entries on the router's DHCP page, I do see this change:
$ pihole-FTL dhcp-discover
Scanning all your interfaces for DHCP servers
...
dns-server: 192.168.1.101
dns-server: 192.168.1.101
router: 192.168.1.1
...
But as I mentioned in the EDIT in my previous comment, a number of ads are still getting through.
What else would you recommend to aid with debugging this?
When I first set up my pi-hole ads got through because the router was still advertising it's own IPv6 address as DNS. The settings for IPv6 are on a different page to IPv4 (on ASUS routers at least).
I have explicitly verified a number of ad sources getting a hit in the blocklist when I query with pihole -q <domain>, and yet I'm seeing ads from the foregoing sources. But like I said, it's strange that this started happening recently (this week) when I manually made no change to my router or Pi-hole setup.
I think there may be a newer way to do this based on MerlilnWRT's feature list, but for my older Merlin firmware Asus router you have to put in the hole's IP into both the Lan->DHCP Server tab's DNS server field AND under WAN->Internet Connection tab WAN DNS Setting DNS Server field. I also have "Connect to DNS Server automatically" as "No", not sure if that's correct, but my setup works for all devices. If I don't set the one under the WAN then some devices, most notably Android phones, use the gateway address as the DNS server which goes to the ISP's DNS server. Changing the WAN setting makes that traffic get redirected to the hole as desired.
No idea why things may have changed other than to suggest that perhaps you just didn't notice the problem before. Did you get a new phone or start using a new device?
I have IPv6 disabled for the internet, however, DHCP doesn't allow disabling it. It is defaulted to SLAAC+Stateless DHCP. That being said, I do not have any IPv6 DNS option enabled, nor do I see it show up in the Pi-hole logs. Is there a way to explicitly verify that other than the logs?
Thanks, everyone!
I think the major issue was certainly the router injecting itself as a secondary DNS. The current scenario seems much better after forcing both DNS entries to point to the same Pi-hole address. As for the ads that are still making it through, I do see an uptick in ad URLs that aren't in my block list (despite around a million adblock entries, excluding regex patterns). Guess the cat-mouse game continues. For now, I'm adding them manually to my blacklist, and will create a pull request for relevant adlist sources.
I'll mark my issue as resolved.