[RESOLVED] PiHole seems to be alive and running, but blacklisted ads getting through

Expected Behaviour:

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).

Debug Token:

https://tricorder.pi-hole.net/rDwOCVwT/

PS: I wasn't sure if I should post it here or in the community. I'll promptly move it if I posted in the wrong section.

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

nslookup pi.hole

nslookup flurry.com 192.168.1.101

nslookup pi.hole
Server: pi.hole
Address: 192.168.1.101
Name: pi.hole
Addresses: fe80::ba10:2bf7:3291:3e88
192.168.1.101

nslookup flurry.com 192.168.1.101
Server: pi.hole
Address: 192.168.1.101
Name: flurry.com
Addresses: ::
0.0.0.0

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.

      dns-server: 192.168.1.101
      dns-server: 192.168.1.1
1 Like

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?

Use these tools to determine the source of the ads.

Do you have IPv6 on your network?

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?

That's not quite what that command does. The command checks to see if a domain is on your blocklists.

Look in the query log and see if you are getting queries for the domains, and if so, if the queries are being blocked as specified.

If you don't see queries for the domains, the client on which you are seeing ads is using a DNS other than Pi-hole.

1 Like

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?

Sadly, my router being a TP-Link, and additionally being a WiFi-6 device, doesn't really have any custom firmware option out there.

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.