PiHole blocks DNS queries for nslookup, but not wget (http-get)

GybiBite · February 3, 2021, 11:18pm

I'm back posting here again with an issue that really seems unlike anything else I've seen here.

PiHole works just fine for normal DNS queries (supposedly), as running nslookup on an ad domain returns 0.0.0.0/:: just as it should. Running wget, however, still returns the webpage, but only sometimes. Consequently, that also means it doesn't block ads on websites. Most of the time it returns the webpage, indicating it didn't block the domain, but rarely wget can't resolve the address, as it should when PiHole is running.

I haven't noticed any pattern to it blocking ads, it seems totally random whether it works it not. I've tried restarting the DNS resolver, flushing the cache on both PiHole and my client (Windows desktop), restarting the Raspberry Pi, client, and router, and repairing PiHole. When PiHole does work, it works perfectly for every device as it should. If I use my VPN (PiVPN w/WireGuard) from my Android device, domains are blocked as expected.

The DHCP server works as expected and assigns PiHole as the IPv4 DNS, but not the IPv6 DNS, which I fixed by doing that manually.

Output of testing connection to ad domains from my Windows desktop

Expected Behaviour:

Ads to be blocked from any DNS query on Windows client

Actual Behaviour:

Still able to contact ad domains (googleads.g.doubleclick.net) via wget/HTTP-GET

Debug Token:

_https://tricorder.pi-hole.net/645ar0o3x3_

jfb · February 4, 2021, 12:46am

What DNS server(s) is the Windows client using? Output of the following from the Windows command prompt, and not via ssh session to the Pi-hole host OS:

ipconfig /all

GybiBite · February 4, 2021, 12:48am

Here's a link to the output of ipconfig /all from my client.

DanSchaper · February 4, 2021, 1:35am

Name:    googleads.g.doubleclick.net.lan
Addresses:  ::
          0.0.0.0

!=

wget googleads.g.doubleclick.net

nslookup will add the local domain to the end if you don't end the query with a dot.

nslookup googleads.g.doubleclick.net.

Note the last char.

GybiBite · February 4, 2021, 3:26am

C:\Users\user>nslookup googleads.g.doubleclick.net.
Server:  raspberrypi.lan
Address:  2601:603:a81:2a10:94ce:e11b:7abe:eca

Non-authoritative answer:
Name:    pagead46.l.doubleclick.net
Addresses:  2607:f8b0:400e:c0c::9b
          2607:f8b0:400e:c0c::9d
          2607:f8b0:400e:c0c::9c
          2607:f8b0:400e:c0c::9a
          108.177.98.156
          108.177.98.157
          108.177.98.154
          108.177.98.155
Aliases:  googleads.g.doubleclick.net

Alright, well that's irritating. So it's blocking the ad domains, but only versions of them with .lan at the end, which aren't the real ones so nothing's being blocked. I wonder how it only works sometimes then...
Is there a way to just block domains that would be ad domains if it weren't for the .lan suffix? Or any other fix for this?

DL6ER · February 4, 2021, 3:33am

Does this get reflected on the Query Log (green lines for the queries)? Or do they somehow manage to evade your Pi-hole?

I agree this is strange, it shouldn't do that. Instead, the expected behavior is

googleads.g.doubleclick.net      ---> blocked
googleads.g.doubleclick.net.lan  ---> NXDOMAIN

NXDOMAIN because such a domain really doesn't exist in your local .lan network.

Hopefully the screenshots from Query Log will reveal more information here.

GybiBite · February 4, 2021, 3:41am

According to my query log, all of it is blocked, which isn't true because I still get a response. Here's my results after running nslookup on the ad domain, with and without the . at the end.

GybiBite · February 4, 2021, 3:46am

followup: forgot to do wget to show it being reflected in the query log too. Here's that picture

DL6ER · February 4, 2021, 6:35am

Which makes me fairly certain that your client somehow manages to evade the Pi-hole and source the information from elsewhere.

Just for testing, run sudo service pihole-FTL stop on your Pi-hole. This will stop the DNS server altogether. Can you commands still resolve the domain? If so, that explains what is happening. Run sudo service pihole-FTL start one you are done testing.

GybiBite · February 4, 2021, 6:59am

This is interesting.

PS C:\Users\user> nslookup google.com
Server:  UnKnown
Address:  2601:603:a81:2a10:94ce:e11b:7abe:eca

*** UnKnown can't find google.com: No response from server

However, every website loads just as fast. Maybe a DNS leak? Are you familiar with Discord? I noticed something a little odd. With pihole-FTL not running, it took a really long time to connect to a voice channel. Maybe that's it trying to connect through pihole (which is disabled at the moment) and then it finds a different DNS server? Really weird. Also tried nslookup with .lan. and .` at the end of the domain, no difference.

DL6ER · February 4, 2021, 7:07am

The browser (whichever you are using) may have an internal cache so doesn't see the disabled DNS server. Last time I checked, Firefox didn't had something like this. For Chrome, you may find it under chrome://net-internals/#dns.

Yes, that's what I'm guessing as well. Maybe try https://www.dnsleaktest.com

For me, the test returns only one server that is my own public IP. This is expected as I run my own local unbound instance to be completely independent from any third-party DNS provider.

GybiBite · February 4, 2021, 7:52am

Thanks, I actually forgot about the internal DNS cache on Chrome.
So after ipconfig /flushdns and clearing the Chrome DNS cache...

I'm at a loss for words. I'm convinced my ISP or my router is trolling me lol. I couldn't make this up if I tried. If I turn my DNS server back on, flush all my caches and such, I get "WoodyNet" which is the Quad9 servers I expect, and not this. Any explanation besides literal magic?

DL6ER · February 4, 2021, 7:57am

This is a very interesting result (putting it mildly). Is this your correct ISP and the expected location for them?

Can you run also the extended test with your Pi-hole ON? Maybe a few times. Does it really always reveal only Cloudflare?

Rest assured we're not at the end of all possibilities Next step is traffic monitoring to check if it is your particular computer that chooses to contact this interesting DNS provider when Pi-hole is disabled.

GybiBite · February 4, 2021, 8:15am

My ISP is Comcast/Xfinity, but their servers haven't showed up at all on the DNS test.
First attempt (it's still there...)

Second attempt

Before my third attempt, I restarted PiHole, flushed the DNS cache of PiHole, my computer, and Chrome, and restarted my PC. I'm beginning to think there's another problem

Maybe I have some form of malware? This DNS can't be coming from nowhere

DL6ER · February 4, 2021, 8:20am

I agree. Something is telling your computer that this is usable. I'm just wondering who is doing the request to this domain. Do you have more computers on your network to verify this is not limited to a single computer? Like running the test from a mobile phone connected to your WiFi network?

GybiBite · February 4, 2021, 8:24am

I ran the test twice with the same results each time. It isn't using PiHole, but that's not the main issue here. It all says comcast.

DL6ER · February 4, 2021, 8:31am

Could you make your phone using Pi-hole for the test? Just like you configured it for the computer?

GybiBite · February 4, 2021, 8:36am

When I said my phone isn't using it, I meant as indicated by the test. Supposedly it is, it's supposed to, as PiHole is my DHCP server. I installed an app called "NetTools" which claims my default DNS server is 10.0.0.80 (my pi) but I've read online that it's kinda hard to get an Android to cooperate since I can't chance or disable my IPv6. Interestingly enough though NetTools claims that I'm using it, and returns NXDOMAIN if I lookup googleads.g.doubleclick.net. It's the only app that seems to claim I'm using PiHole.

GybiBite · February 4, 2021, 8:39am

I forgot to mention right as I posted this! I can turn on my VPN, and PiHole works exactly as expected. All Ads blocked when it's on, and effectively no internet when it's off.
*On my android

DL6ER · February 4, 2021, 8:41am

Okay, that's a fair point.

So it IS the computer misbehaving somehow. Maybe your speculations about a malware prove to be correct. Let's see.

So, the next step would be disabling the Pi-hole again, and then running the DNS leak test again, but this time we'll record what is happening.

The following command will record all traffic on port 53:

sudo tcpdump -w /tmp/dns.pcap port 53

Now run the test (the simple one should suffice).

Once you are done with the test, terminate the command above using Ctrl+C. This should print a summary saying how many packets were captured and stored. The shorter your capturing period is, the easier it will be to analyze them.

Next, you can use tcpdump to analyze your recording, like

tcpdump -n -ttt -r /tmp/dns.pcap -vvv

(-n shows IP addresses, -ttt shows the time relative to the first recorded package and -vvv shows as much information as possible).

Example

reading from file /tmp/dns.pcap, link-type EN10MB (Ethernet)
 00:00:00.000000 IP (tos 0x0, ttl 64, id 47075, offset 0, flags [DF], proto UDP (17), length 55)
    192.168.2.224.34661 > 192.168.2.10.53: [bad udp cksum 0x866f -> 0x4807!] 32+ A? google.de. (27)
 00:00:00.056041 IP (tos 0x0, ttl 64, id 32467, offset 0, flags [DF], proto UDP (17), length 71)
    192.168.2.10.53 > 192.168.2.224.34661: [udp sum ok] 32 q: A? google.de. 1/0/0 google.de. [5m] A 142.250.185.163 (43)

Here, you can see that I ran dig A google.de from 192.168.2.224 to 192.168.2.10 (my Pi-hole). The second line shows that the result came 56 milliseconds later and told my dig that the answer to my query is A 142.250.185.163.

You can also share the file with us for further analysis and/or use wireshark to analyze your recording.