Some background info.
I've run cat /etc/resolv.conf and get back:
nameserver 127.0.1.1
search lan (lan is the pi-hole domain name)
Also, nslookup pi.hole
Server: 127.0.1.1
Address: 127.0.1.1#53
Name: pi.hole
Address: 192.168.0.22
and nslookup pi.hole 192.168.0.22
Server: 192.168.0.22
Address: 192.168.0.22#53
Name: pi.hole
Address: 192.168.0.22
Thanks!
Ads should be blocked.
Ads aren't blocked.
2df3iw1tq8
I assume all those commands are run from the Pi terminal? If so, the output is normal. The Pi device is set to use itself as the nameserver, which means it is using Pi-Hole as the nameserver. Pi-Hole correctly received the DNS request and provided the correct response.
This section of your debug log tests whether Pi-Hole can block a domain known to be on the block list, and the test passed:
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] a.mologiq.net is 0.0.0.0 via localhost (127.0.0.1)
[✓] a.mologiq.net is 0.0.0.0 via Pi-hole (192.168.0.22)
[✓] doubleclick.com is 172.217.11.238 via a remote, public DNS server (8.8.8.8)
Your debug log shows that DNS queries were received from 4 clients.
Where are you seeing ads? Everywhere or only on selected sites (i.e. Facebook, YouTube, etc.). If clients are using DNS other than Pi-Hole, then Pi-Hole does not have the opportunity to block.
Please post the output of this command from a client on which you see ads:
nslookup pi.hole
nslookup flurry.com
From the Pi terminal, please post the output of this command:
echo ">top-clients withzero (15)" | nc 127.0.0.1 4711
Thanks for the help! I tested several different websites that I know have ads, like engadget.
From my laptop
nslookup pi.hole
Server: 127.0.1.1
Address: 127.0.1.1#53
Name: pi.hole
Address: 192.168.0.22
nslookup flurry.com
Server: 127.0.1.1
Address: 127.0.1.1#53
Name: flurry.com
Address: 0.0.0.0
From the pi
echo ">top-clients withzero (15)" | nc 127.0.0.1 4711
0 1050 192.168.0.227
1 489 192.168.0.14
2 109 192.168.0.234
3 103 127.0.0.1 localhost
4 2 192.168.0.22 raspberrypi
5 2 ::1 localhost
6 2 2601:8c0:0:1e20:f0af:4760:4b76:b012 raspberrypi
7 1 192.168.0.218
---EOM---
What OS is on the laptop, and is Pi-Hole running in a VM on that laptop (from your debug log it appears not). Both nslookups returned the correct results, but I would not expect the laptop to use the loopback for DNS resolution.
Please post a screen snap of what you see on engadget, including the exact URL you loaded. You can paste your clipboard directly into a reply here. What browser and OS is on the client that is showing ads?
The laptop is running Ubuntu 16.04. The Pi-hole is running on a Raspberry Pi 3B+ running Stretch.
Engadget is having some trouble loading right now, but here's an adblock testing site.
Since Pi-Hole appears to be working based on your debug log, let’s look at whether or not clients are using Pi-Hole for DNS and whether Pi-Hole can block ads on the visited site. I would use the engadget site for consistency.
Use these tools while loading that site (clear the browser cache first), and see if the traffic in the Pi-Hole log matches the domains that the site is loading.
I can see all of the same domains in both. I refreshed the page several times while trying to figure this out. What's weird is that the ads don't show up for the first few times I load the page after I clear the cache. After I refresh several times, they start to pop up. Once an ad has appeared, it doesn't go away again until I clear the cache (not necessarily the same ad, but just an ad in that space on the website).
I would bet there is an alternate DNS path available to your client. I would change browsers, review browser settings, etc.
My isp forces leach like dns onto me. Without the proper hardware/software there is noway around it. I hope this is not your issue. Just pointing out that it is also a possibility.
https://www.dnsleaktest.com/what-is-transparent-dns-proxy.html
" Transparent DNS proxies
Some ISP's are now using a technology called 'Transparent DNS proxy'. Using this technology, they will intercept all DNS lookup requests (TCP/UDP port 53) and transparently proxy the results. This effectively forces you to use their DNS service for all DNS lookups.
If you have changed your DNS settings to use an 'open' DNS service such as Google, Comodo or OpenDNS, expecting that your DNS traffic is no longer being sent to your ISP's DNS server, you may be surprised to find out that they are using transparent DNS proxying."
Yep. Turns out that my ISP was doing exactly this. There are some hidden DNS proxies with my ISP's name on them running in parallel with the one Cloudfare one I set up with Pi-hole. It even explains a lot of the other behaviour I was seeing, like the websites sometimes showing the ads and sometimes not. When I clear the cache, it takes a few refreshes for my ISP's DNS to show up, but once it does, it stays there. I did try researching a little bit and ended up here, but that didn't work for me. I'm still seeing my ISP's DNS.
Who is your ISP and are you using their router/modem or your own?
The only thing that i can suggest to you is to use your own equipment. I have a netgear r6400 flashed with DD-Wrt to get around the problem. A lot more people have this problem and don't know about it.
My isp is spectrum/legacyTWC btw.
Its been sometime since I have checked. I suppose things could have changed.
When it was happening to me my selfOWNED router wouldn't shake it either. It wasn't until I applied some firewall/dnsmasq rules/settings.
This should be able to be fixed by using non standard ports. The key is the non-use of port 53. Perhaps finding a dns server that supports this.
check here… https://www.reddit.com/r/HomeNetworking/comments/4f1nkk/bypass_dns_hijacking_transparent_dns_proxy_with/
however iirc this did not work for me either.
Ultimate goal here is to REDIRECT port 53 to pihole then use dot/doh. I had it working both ways with or without a proxy. I blocked the FORWARD chain to their ip's and redirected 53 to pihole with iptables.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.
