Ads not blocking, flurry.com returns 0.0.0.0

Please follow the below template, it will help us to help you!

Expected Behaviour:

Ad blocking, flurry.com returning with actual IP addresses

Actual Behaviour:

After reinstalling Raspian and Pihole onto my Raspi, and resetting my router settings, the ads are still there. Some of the charts on the dashboard show something is working, but not only are the ads still showing up, nothing under the Blacklist is... well, blacking. After trying a bajillion different solutions, I think I found something actually replicable. Given that it's a URL, it's even harder to find

Not entirely sure what flurry.com is, but I found a few threads advising to run a few commands. When I run nslookup furry.com on my Pi, I just get Address 0.0.0.0, when I run on my Mac, I get the following:

Non-authoritative answer:
Name:	flurry.com
Address: 98.136.103.26
Name:	flurry.com
Address: 212.82.100.153
Name:	flurry.com
Address: 74.6.136.153

Given that my clue is but a URL, it is even harder to find. So given everything I have tried, whatever is behind flurry.com seems to be the only thing. Running ifconfig doesn't seem to return anything interesting with either:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 192.168.50.251  netmask 255.255.255.0  broadcast 192.168.50.255
inet6 fe80::1933:33b:9fd0:5da5  prefixlen 64  scopeid 0x20<link>
ether b8:27:eb:fb:ef:ba  txqueuelen 1000  (Ethernet)
RX packets 83361  bytes 35172538 (33.5 MiB)
RX errors 0  dropped 9  overruns 0  frame 0
TX packets 25709  bytes 8292305 (7.9 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10<host>
loop  txqueuelen 1000  (Local Loopback)
RX packets 62186  bytes 4144294 (3.9 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 62186  bytes 4144294 (3.9 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Debug Token:

tn5qpl5pde

So

Wut do?

(EDIT: added dazzling deets about what I installed it onto)

Oh bugger, I forgot to say.
I am working on my Mac, I am SSHing into my Raspberry Pi which is running Pihole.

And yes, I have DHCP turned off on my router.

Your debug log shows that Pi-Hole is working properly. The 0.0.0.0 (or NULL) return is expected for a blocked domain, and flurry.com is a blocked domain.

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] opqyo.voluumtrk.com is 0.0.0.0 via localhost (127.0.0.1)
[✓] opqyo.voluumtrk.com is 0.0.0.0 via Pi-hole (192.168.50.251)
[✓] doubleclick.com is 172.217.2.174 via a remote, public DNS server (8.8.8.8)

The debug log shows that in the 24 hours prior to today at 08:06 am, the following activity was recorded by Pi-Hole:

   [2019-01-22 08:06:15.414] Imported 1373 queries from the long-term database
   [2019-01-22 08:06:15.414]  -> Total DNS queries: 1373
   [2019-01-22 08:06:15.414]  -> Cached DNS queries: 55
   [2019-01-22 08:06:15.415]  -> Forwarded DNS queries: 1045
   [2019-01-22 08:06:15.415]  -> Exactly blocked DNS queries: 273
   [2019-01-22 08:06:15.415]  -> Unknown DNS queries: 0
   [2019-01-22 08:06:15.415]  -> Unique domains: 404
   [2019-01-22 08:06:15.415]  -> Unique clients: 3
   [2019-01-22 08:06:15.415]  -> Known forward destinations: 2

Since the domain lookup from the Pi correctly returned the NULL IP and the lookup from the Mac did not, the Mac does not appear to be using Pi-Hole for DNS. If you run this command from the Mac terminal, it will show you the true order of the nameservers the Mac is using:

scutil --dns

Well that would make sense, but if Flurry is supposed to be blocked, why is Facebook (and any other ad) not?12%20PM

As for scutil,

resolver #1
search domain[0] : lan
nameserver[0] : 8.8.8.8
nameserver[1] : 8.8.4.4
flags    : Request A records
reach    : 0x00000002 (Reachable)

resolver #2
domain   : local
options  : mdns
timeout  : 5
flags    : Request A records
reach    : 0x00000000 (Not Reachable)
order    : 300000

resolver #3
domain   : 254.169.in-addr.arpa
options  : mdns
timeout  : 5
flags    : Request A records
reach    : 0x00000000 (Not Reachable)
order    : 300200

resolver #4
domain   : 8.e.f.ip6.arpa
options  : mdns
timeout  : 5
 flags    : Request A records
reach    : 0x00000000 (Not Reachable)
order    : 300400

resolver #5
domain   : 9.e.f.ip6.arpa
options  : mdns
timeout  : 5
flags    : Request A records
reach    : 0x00000000 (Not Reachable)
order    : 300600


resolver #6
domain   : a.e.f.ip6.arpa
options  : mdns
timeout  : 5
flags    : Request A records
reach    : 0x00000000 (Not Reachable)
order    : 300800

resolver #7
domain   : b.e.f.ip6.arpa
options  : mdns
timeout  : 5
flags    : Request A records
reach    : 0x00000000 (Not Reachable)
order    : 301000

DNS configuration (for scoped queries)

resolver #1
search domain[0] : lan
nameserver[0] : 8.8.8.8
nameserver[1] : 8.8.4.4
if_index : 5 (en0)
flags    : Scoped, Request A records
reach    : 0x00000002 (Reachable)

This is telling you that the Mac is not properly configured to use Pi-Hole. it is using Google for DNS and bypassing Pi-Hole. What do you see on this network DNS panel on your Mac? It is likely the same numbers. If so, then edit the settings and put the Pi-Hole IP there, and nothing else. Then apply the changes.

You can clear the Mac DNS cache with this command from the Mac Terminal:

sudo killall -HUP mDNSResponder

Oh bugger! I had some issues with my DNS a week or so ago, so I guess that is where I changed that. When I deleted the Google DNS servers, it 'defaulted' to 192.168.50.251, do I need a second one?

You do not need (or want) a second one.

WELL THAT WAS A FAIRLY SIMPLE FIX
Thank you kindly, sir

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