Successful nslookup pi.hole but fails nslookup flurry.com

hearthmatt · January 18, 2024, 3:00am

I've installed Pi-hole on a Raspberry Pi 3, set the appropriate DNS on my Mac and was testing using the hackaday.com website on my Mac but adverts were being shown. One of the ads was being presented by images.ads.supplyframe.com which I confirmed is on my adlist, so I tried it with the dig command on my Mac

dig images.ads.supplyframe.com
; <<>> DiG 9.10.6 <<>> images.ads.supplyframe.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42938
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;images.ads.supplyframe.com. IN A
;; ANSWER SECTION:
images.ads.supplyframe.com. 300 IN CNAME images.ads.supplyframe.com.edgekey.net.
images.ads.supplyframe.com.edgekey.net. 21600 IN CNAME e6930.g.akamaiedge.net.
e6930.g.akamaiedge.net. 20 IN A 23.4.190.225
;; Query time: 280 msec
;; SERVER: 192.168.4.198#53(192.168.4.198)
;; WHEN: Wed Jan 17 21:34:30 EST 2024
;; MSG SIZE rcvd: 156

And then the dig command on my pi:

dig images.ads.supplyframe.com
; <<>> DiG 9.16.44-Debian <<>> images.ads.supplyframe.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22087
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;images.ads.supplyframe.com. IN A
;; ANSWER SECTION:
images.ads.supplyframe.com. 2 IN A 0.0.0.0
;; Query time: 116 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jan 17 21:44:47 EST 2024
;; MSG SIZE rcvd: 71

I tried the dig command with flurry.com on both systems with similar results.

So it looks like it is working on the pi but not the Mac!

I checked the nameserver settings on my Mac:

nslookup pi.hole
Server: 192.168.4.198
Address: 192.168.4.198#53
Name: pi.hole
Address: 192.168.4.198

And also:

scutil --dns | grep 'nameserver\[[0-9]*\]'
 nameserver[0] : 192.168.4.198
 nameserver[0] : 192.168.4.198

I am confused and not sure what else to try so any help would be appreciated.

Debug token is: https://tricorder.pi-hole.net/OEXW0OUi/

DanSchaper · January 18, 2024, 10:16pm

Do you see any queries or blocks at all on the web interface?

Your networking is a bit non-conventional, you have a bigger subnet than is usually configured 192.168.4.198/22 .

Have you manually configured your clients networking? The router is sending out non-Pi-hole DNS servers:

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   Timeout: 10 seconds
   
   * Received 303 bytes from eth0:192.168.4.1
     Offered IP address: 192.168.4.198
     Server IP address: N/A
     Relay-agent IP address: N/A
     BOOTP server: (empty)
     BOOTP file: (empty)
     DHCP options:
      Message type: DHCPOFFER (2)
      server-identifier: 192.168.4.1
      lease-time: 14400 ( 4h )
      netmask: 255.255.252.0
      router: 192.168.4.1
      dns-server: 1.1.1.1
      dns-server: 1.0.0.1
      broadcast: 192.168.7.255
      ntp-server: 192.168.4.1
         --- end of options ---

However it doesn't look like you have any clients using Pi-hole:


*** [ DIAGNOSING ]: Groups
   id    enabled  name                                                date_added           date_modified        description                                       
   ----  -------  --------------------------------------------------  -------------------  -------------------  --------------------------------------------------
   0           1  Default                                             2024-01-17 14:29:15  2024-01-17 14:29:15  The default group                                 

*** [ DIAGNOSING ]: Domainlist (0/1 = exact white-/blacklist, 2/3 = regex white-/blacklist)

*** [ DIAGNOSING ]: Clients

*** [ DIAGNOSING ]: Adlists
   id     enabled  group_ids     address                                                                                               date_added           date_modified        comment                                           
   -----  -------  ------------  ----------------------------------------------------------------------------------------------------  -------------------  -------------------  --------------------------------------------------
   1            1  0             https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts                                      2024-01-17 14:29:17  2024-01-17 14:29:17  Migrated from /etc/pihole/adlists.list

/var/log/pihole/pihole.log really only shows the debug queries, but it does show that blocking is functional:

   Jan 17 21:15:48 dnsmasq[30535]: query[AAAA] unspoiilednature.site from ::1
   Jan 17 21:15:48 dnsmasq[30535]: gravity blocked unspoiilednature.site is ::
   Jan 17 21:15:48 dnsmasq[30535]: query[AAAA] unspoiilednature.site from fd37:7fb8:fec:bc6c:24ba:3e95:785d:55f9
   Jan 17 21:15:48 dnsmasq[30535]: gravity blocked unspoiilednature.site is ::
   Jan 17 21:15:48 dnsmasq[30535]: query[PTR] 198.4.168.192.in-addr.arpa from 127.0.0.1
   Jan 17 21:15:48 dnsmasq[30535]: config 198.4.168.192.in-addr.arpa is <PTR>
   Jan 17 21:15:48 dnsmasq[30535]: query[PTR] 9.f.5.5.d.5.8.7.5.9.e.3.a.b.4.2.c.6.c.b.c.e.f.0.8.b.f.7.7.3.d.f.ip6.arpa from 127.0.0.1
   Jan 17 21:15:48 dnsmasq[30535]: config 9.f.5.5.d.5.8.7.5.9.e.3.a.b.4.2.c.6.c.b.c.e.f.0.8.b.f.7.7.3.d.f.ip6.arpa is <PTR>
   Jan 17 21:15:48 dnsmasq[30535]: query[AAAA] unspoiilednature.site from fda9:8613:1987:1:76b8:f251:4da1:6354
   Jan 17 21:15:48 dnsmasq[30535]: gravity blocked unspoiilednature.site is ::
   Jan 17 21:15:48 dnsmasq[30535]: query[AAAA] unspoiilednature.site from fe80::51c8:4bea:1c89:bf
   Jan 17 21:15:49 dnsmasq[30535]: gravity blocked unspoiilednature.site is ::
   Jan 17 21:15:49 dnsmasq[30535]: query[PTR] 4.5.3.6.1.a.d.4.1.5.2.f.8.b.6.7.1.0.0.0.7.8.9.1.3.1.6.8.9.a.d.f.ip6.arpa from 127.0.0.1
   Jan 17 21:15:49 dnsmasq[30535]: config 4.5.3.6.1.a.d.4.1.5.2.f.8.b.6.7.1.0.0.0.7.8.9.1.3.1.6.8.9.a.d.f.ip6.arpa is <PTR>
   Jan 17 21:15:49 dnsmasq[30535]: query[PTR] f.b.0.0.9.8.c.1.a.e.b.4.8.c.1.5.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa from 127.0.0.1
   Jan 17 21:15:49 dnsmasq[30535]: config f.b.0.0.9.8.c.1.a.e.b.4.8.c.1.5.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa is <PTR>

hearthmatt · January 20, 2024, 12:06am

Thank you for taking a look at this. I agree the subnet is a bit unusual, I hadn't noticed this before. As far as I can remember it was set when I installed an eero mesh network. I do have a lot of automated home devices connected to my network but clearly nowhere near as many as can be accommodated with this setting.

I have manually configured the client DNS server settings as required but left the eero router with the 1.1.1.1, 1.0.0.1 settings.

I am seeing queries and blocks on the server:

Jan 19 18:57:35: query[HTTPS] static.narrativ.com from 192.168.4.41 **
Jan 19 18:57:35: gravity blocked static.narrativ.com is NODATA** **
Jan 19 18:57:35: query[A] static.narrativ.com from 192.168.4.41** **
Jan 19 18:57:35: gravity blocked static.narrativ.com is 0.0.0.0**

I have also now installed unbound to run alongside pi-hole. Perhaps I should resolve my issue first?

DanSchaper · January 20, 2024, 6:32pm

Do you see clients on the admin display now?

How does your Network panel look?

I do find it easier to resolve issues when there are fewer variables to consider.

hearthmatt · January 20, 2024, 8:51pm

I've unset the link to Unbound to hopefully simplify the environment.

I flushed DNS caches and cleared the cache in my browser (Firefox) then opened up the hackaday.com website. Pi-hole shows it is blocking several urls including images.ads.supplyframe.com but I am still seeing ads on the hackaday.com web page.

rdwebdesign · January 20, 2024, 9:03pm

Maybe it's a cached image.

chrislph · January 20, 2024, 9:11pm

Try running the Extended test at DNS leak test using the same browser and setup. You're not really testing for leaks in this scenario but it's useful for showing which DNS servers are responding from the browser's point of view. It may reveal the presence of a setting somewhere which is allowing the browser to resolve the image domain via another server (if not cached as rdwebdesign points out).

If you're using Pi-hole you should only be seeing the chosen upstream servers. If that is Unbound then you should see your own public IP (since that's how the Internet will see any traffic from your Unbound, same as any other traffic from your LAN).

DanSchaper · January 20, 2024, 9:12pm

What does curl -sSL https://images.ads.supplyframe.com/382cd2e2ece26c65e289cf5970780cb6.gif show from a terminal? There shouldn't be any content in the response.

dan@Viking:~$ curl -sSL https://images.ads.supplyframe.com/382cd2e2ece26c65e289cf5970780cb6.gif
curl: (7) Failed to connect to images.ads.supplyframe.com port 443 after 20 ms: Couldn't connect to server

hearthmatt · January 20, 2024, 10:20pm

I get the following on the pi-hole server:

matthew@raspberrypi3**:~ $ curl sSL https://images.ads.supplyframe.com/382cd2e2ece26c65e289cf5970780cb6.gif
curl: (7) Failed to connect to images.ads.supplyframe.com port 443: Connection refused

On my mac I do not get any response:
Matthew@OnesOneMac /etc % curl -sSL https://images.ads.supplyframe.com/382cd2e2ece26c65e289cf5970780cb6.gif
Matthew@OnesOneMac /etc %

I ran tail on the pihole.log, went to hackaday.com and saw:
Jan 20 17:02:58: query[A] uib.ff.avast.com from 192.168.4.41
Jan 20 17:02:58: gravity blocked uib.ff.avast.com is 0.0.0.0
Jan 20 17:02:58: query[A] analytics.supplyframe.com from 192.168.4.41
Jan 20 17:02:58: gravity blocked analytics.supplyframe.com is 0.0.0.0
Jan 20 17:02:58: query[A] www.googletagmanager.com from 192.168.4.41
Jan 20 17:02:58: gravity blocked www.googletagmanager.com is 0.0.0.0
Jan 20 17:02:58: query[A] stats.wp.com from 192.168.4.41
Jan 20 17:02:58: gravity blocked stats.wp.com is 0.0.0.0
Jan 20 17:02:58: query[A] ads.supplyframe.com from 192.168.4.41
Jan 20 17:02:58: gravity blocked ads.supplyframe.com is 0.0.0.0
Jan 20 17:02:59: query[A] images.ads.supplyframe.com from 192.168.4.41
Jan 20 17:02:59: gravity blocked images.ads.supplyframe.com is 0.0.0.0
Jan 20 17:02:59: query[A] tag.perfectaudience.com from 192.168.4.41
Jan 20 17:02:59: gravity blocked tag.perfectaudience.com is 0.0.0.0
Jan 20 17:02:59: query[A] search.supplyframe.com from 192.168.4.41
Jan 20 17:02:59: gravity blocked search.supplyframe.com is 0.0.0.0
Jan 20 17:02:59: query[A] www.google-analytics.com from 192.168.4.41
Jan 20 17:02:59: gravity blocked www.google-analytics.com is 0.0.0.0
Jan 20 17:02:59: query[A] pixel.wp.com from 192.168.4.41
Jan 20 17:02:59: gravity blocked pixel.wp.com is 0.0.0.0

But I am still seeing the ads on the hackady.com website

hearthmatt · January 20, 2024, 10:26pm

I got the following:

chrislph · January 20, 2024, 11:04pm

Does either of those match your Pi-hole upstream server(s)?

Firefox has DNS over HTTPS enabled as default using Cloudflare. It's in Settings > Privacy & Security > DNS over HTTPS at the bottom (or search for DNS in the Settings). Turn it Off to ensure all DNS is going to your OS-configured resolver, ie Pi-hole.

Was it set on? If so and you're turned it off, try running the leak test again. That Cloudflare entry should be gone (assuming it came from Firefox). Is that other setting your configured upstream (or your IP if you're running Unbound)?

If it's all good then the domain lookup on Hackaday should expire and result in a box saying unable to connect to that *.supplyframe.com domain.

Note you should test using a Private window, or if you've tested using a normal window, clear the cache and cookies and then switch to testing with a Private window, to avoid earlier downloads from tainting current results.

hearthmatt · January 20, 2024, 11:19pm

Thanks for that, however I switched it off and it didn't make a difference.

I think I have the solution from a post I found on reddit. I use Avast anti-virus which, under its Core Shields setting has an option call "Real Site" which "Blocks fake sites for safer shopping and banking". I disabled it and now my browsing is behaving as it should and adverts are being blocked!

Thanks to everyone who responded, I really appreciate that you took the time out to help.

chrislph · January 20, 2024, 11:45pm

If you run the Leak test again you should be seeing just your Pi-hole upstream servers or your own IP for Unbound, that will confirm no sneaky OS or application settings lingering on.

As you use Firefox, take a look at the uBlock Origin extension. Since it works at the browser level it will automatically block and hide elements relating to adverts. So as well as them not loading, they completey disappear. I'm not sure if it's available for Firefox for Mac but hopefully so.

For anyone using Safari, the paid extension called Wipr works really well for similarly blocking adverts and their elements.

DanSchaper · January 21, 2024, 8:57pm

Yep, that will do it. As will McAfee or any of the other 'anti-virus' bloatware.

hearthmatt · January 22, 2024, 2:17am

I ran the leak test again and as you predicted I only saw my own IP.

I'll check out Wipr as I use Safari for most of my browsing. I was using Firefox for the testing.

hearthmatt · January 22, 2024, 2:19am

Yes, I initially thought that might be the case so I made sure to clear the browser cache before each test.

system · February 12, 2024, 2:19am

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.