Won't Block Ads

rufus · January 23, 2019, 4:11pm

Debug log was moved to private.

jfb · January 23, 2019, 6:36pm

There is only one problem showing in your debug log

[i] Default IPv4 gateway: 192.168.1.1

* Pinging 192.168.1.1…
[✗] Gateway did not respond. ([Why is a default gateway important for Pi-hole?](https://discourse.pi-hole.net/t/why-is-a-default-gateway-important-for-pi-hole/3546))

But, further down the test for blocking both within the Pi (on the localhost and on the IP of the Pi) are working, as is the ability of the Pi-Hole to contact the Google DNS server.

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] [count731.51yes.com](http://count731.51yes.com) is 0.0.0.0 via localhost (127.0.0.1)
[✓] [count731.51yes.com](http://count731.51yes.com) is 0.0.0.0 via Pi-hole (192.168.1.6)
[✓] [doubleclick.com](http://doubleclick.com) is 216.58.217.110 via a remote, public DNS server (8.8.8.8)

What is the output of these commands from the Pi terminal:

echo ">stats" | nc localhost 4711

dig cnn.com

dig cnn.com @192.168.1.6

dig cnn.com @8.8.8.8

rufus · January 23, 2019, 7:01pm

Not sure what to to about the gateway but here are the restults

domains_being_blocked 112495
dns_queries_today 3492
ads_blocked_today 84
ads_percentage_today 2.405498
unique_domains 247
queries_forwarded 1019
queries_cached 2389
clients_ever_seen 5
unique_clients 4
dns_queries_all_types 3492
reply_NODATA 66
reply_NXDOMAIN 3
reply_CNAME 1176
reply_IP 2231
privacy_level 0
status enabled

dig cnn.com

; <<>> DiG 9.10.3-P4-Raspbian <<>> cnn.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57709
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cnn.com.                       IN      A

;; ANSWER SECTION:
cnn.com.                22      IN      A       151.101.65.67
cnn.com.                22      IN      A       151.101.1.67
cnn.com.                22      IN      A       151.101.129.67
cnn.com.                22      IN      A       151.101.193.67

;; Query time: 51 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Wed Jan 23 14:00:22 EST 2019
;; MSG SIZE  rcvd: 100

dig cnn.com @192.168.1.6

; <<>> DiG 9.10.3-P4-Raspbian <<>> cnn.com @192.168.1.6
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46153
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cnn.com.                       IN      A

;; ANSWER SECTION:
cnn.com.                17      IN      A       151.101.1.67
cnn.com.                17      IN      A       151.101.65.67
cnn.com.                17      IN      A       151.101.129.67
cnn.com.                17      IN      A       151.101.193.67

;; Query time: 17 msec
;; SERVER: 192.168.1.6#53(192.168.1.6)
;; WHEN: Wed Jan 23 14:00:52 EST 2019
;; MSG SIZE  rcvd: 100

dig cnn.com @8.8.8.8

; <<>> DiG 9.10.3-P4-Raspbian <<>> cnn.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47153
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;cnn.com.                       IN      A

;; ANSWER SECTION:
cnn.com.                37      IN      A       151.101.65.67
cnn.com.                37      IN      A       151.101.1.67
cnn.com.                37      IN      A       151.101.193.67
cnn.com.                37      IN      A       151.101.129.67

;; Query time: 19 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Jan 23 14:01:06 EST 2019
;; MSG SIZE  rcvd: 100

jfb · January 23, 2019, 7:24pm

These results show that your Pi-Hole is/was working in the past 24 hours. The first output is a summary of the activity in the past 24 hours. We have only tested DNS lookups for a domain not likely to be on a block list. Let's run a few more checks.

From the Pi terminal, run these commands for a domain that is on the default block lists.

dig flurry.com

dig flurry.com @1.1.1.1

dig flurry.com @127.0.0.1

Then, from the client that is seeing ads, run (dig or nslookup, depending on your system)

dig pi.hole
or
nslookup pi.hole

dig flurry.com
or
nslookup flurry.com

rufus · January 23, 2019, 8:28pm

dig flurry.com

; <<>> DiG 9.10.3-P4-Raspbian <<>> flurry.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55292
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;flurry.com.                    IN      A

;; ANSWER SECTION:
flurry.com.             300     IN      A       212.82.100.153
flurry.com.             300     IN      A       98.136.103.26
flurry.com.             300     IN      A       74.6.136.153

;; Query time: 41 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Wed Jan 23 15:25:13 EST 2019
;; MSG SIZE  rcvd: 87

dig flurry.com @1.1.1.1

; <<>> DiG 9.10.3-P4-Raspbian <<>> flurry.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18346
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;flurry.com.                    IN      A

;; ANSWER SECTION:
flurry.com.             218     IN      A       74.6.136.153
flurry.com.             218     IN      A       98.136.103.26
flurry.com.             218     IN      A       212.82.100.153

;; Query time: 20 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Jan 23 15:25:44 EST 2019
;; MSG SIZE  rcvd: 87

dig flurry.com @127.0.0.1

; <<>> DiG 9.10.3-P4-Raspbian <<>> flurry.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25268
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;flurry.com.                    IN      A

;; ANSWER SECTION:
flurry.com.             2       IN      A       0.0.0.0

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jan 23 15:25:59 EST 2019
;; MSG SIZE  rcvd: 55

nslookup pi.hole

Server:  resolver1.opendns.com
Address:  208.67.222.222

*** resolver1.opendns.com can't find pi.hole: Non-existent domain

nslookup flurry.com

Server:  resolver1.opendns.com                                                                                          
Address:  208.67.222.222                                                                                                                                                                                                                        Non-authoritative answer:  
Name:    flurry.com                                                                                                     
Addresses:  
74.6.136.153                                                                                                          
98.136.103.26                                                                                                           
212.82.100.153

rufus · January 25, 2019, 5:58pm

do you have any thoughts?

jfb · January 25, 2019, 6:11pm

Apologies for the delay - I missed your reply. Here's what those digs and nslookups are telling us:

dig flurry.com should have returned 0.0.0.0, since this is a blocked domain.

dig flurry.com @1.1.1.1 returned the correct address, which is expected. This confirms that the Pi can get to the internet as well.

dig flurry.com @127.0.0.1 (the Pi loopback address) returned the correct result.

The two nslookup commands from your client both show that the clients are not using Pi-Hole for DNS, as the requests went to an OpenDNS resolver directly. This is a configuration problem in your client or router.

Please generate a new debug log, upload it when prompted, and post the token here.

rufus · January 25, 2019, 7:45pm

it still won't upload (see below)
What do I need to add/enable in my firewall so the pi would upload and generate a token?

[?] Would you like to upload the log? [y/N] y
* Using openssl for transmission.
[✗] There was an error uploading your debug log.

Please try again or contact the Pi-hole team for assistance.

jfb · January 25, 2019, 8:54pm

Temporarily edit the nameserver on your Pi:

sudo nano /etc/resolv.conf

edit nameserver 127.0.0.1 to nameserver 9.9.9.9 or your preferred third party DNS service

save and exit

Then try to upload the debug log

rufus · January 25, 2019, 9:01pm

look back out thread, we did that before and I haven't gone back to change it yet
still can't upload

jfb · January 25, 2019, 9:07pm

OK. Then upload the debug log in a reply, and we'll hide it again.

rufus · January 25, 2019, 9:09pm

Debug log made private by moderator

jfb · January 25, 2019, 9:25pm

Your debug log is showing the same problem as last time, but is properly resolving DNS queries. The problem appears to be in the interface between your router/clients and Pi-Hole, as shown by the nslookups that are going directly to OpenDNS and bypassing Pi-Hole.

[i] Default IPv4 gateway: 192.168.1.1
   * Pinging 192.168.1.1...
[✗] Gateway did not respond. (https://discourse.pi-hole.net/t/why-is-a-default-gateway-important-for-pi-hole/3546)

The reason ads are not being blocked is that some of the clients are not sending their DNS requests to Pi-Hole.

Please run the following commands from the Pi terminal:

echo ">top-clients withzero (25)" | nc 127.0.0.1 4711 and post the result here

sudo service pihole-FTL restart

cat /var/log/pihole-FTL.log and post the result here

rufus · January 25, 2019, 9:37pm

echo ">top-clients withzero (25)" | nc 127.0.0.1 4711

0 3139 192.168.1.1
1 2 127.0.0.1 localhost
2 2 192.168.1.6
3 2 ::1 localhost
4 0 2002:45fb:5811:0:cd8f:7395:e48b:df79

cat /var/log/pihole-FTL.log

[2019-01-25 01:50:20.150] Notice: Increasing overTime struct size from 600 to 700
[2019-01-25 16:37:27.432] Shutting down...
[2019-01-25 16:37:27.512] Finished final database update
[2019-01-25 16:37:27.513] ########## FTL terminated after 328739552.0 ms! ##########
[2019-01-25 16:37:29.496] Using log file /var/log/pihole-FTL.log
[2019-01-25 16:37:29.497] ########## FTL started! ##########
[2019-01-25 16:37:29.497] FTL branch: master
[2019-01-25 16:37:29.497] FTL version: v4.1.2
[2019-01-25 16:37:29.497] FTL commit: b06eedf
[2019-01-25 16:37:29.498] FTL date: 2018-12-21 14:43:34 -0600
[2019-01-25 16:37:29.498] FTL user: pihole
[2019-01-25 16:37:29.498] Starting config file parsing (/etc/pihole/pihole-FTL.conf)
[2019-01-25 16:37:29.498]    SOCKET_LISTENING: only local
[2019-01-25 16:37:29.499]    AAAA_QUERY_ANALYSIS: Show AAAA queries
[2019-01-25 16:37:29.499]    MAXDBDAYS: max age for stored queries is 365 days
[2019-01-25 16:37:29.499]    RESOLVE_IPV6: Resolve IPv6 addresses
[2019-01-25 16:37:29.499]    RESOLVE_IPV4: Resolve IPv4 addresses
[2019-01-25 16:37:29.500]    DBINTERVAL: saving to DB file every minute
[2019-01-25 16:37:29.500]    DBFILE: Using /etc/pihole/pihole-FTL.db
[2019-01-25 16:37:29.500]    MAXLOGAGE: Importing up to 24.0 hours of log data
[2019-01-25 16:37:29.500]    PRIVACYLEVEL: Set to 0
[2019-01-25 16:37:29.501]    IGNORE_LOCALHOST: Show queries from localhost
[2019-01-25 16:37:29.501]    BLOCKINGMODE: Null IPs for blocked domains
[2019-01-25 16:37:29.501]    REGEX_DEBUGMODE: Inactive
[2019-01-25 16:37:29.501]    ANALYZE_ONLY_A_AND_AAAA: Disabled. Analyzing all queries
[2019-01-25 16:37:29.502]    DBIMPORT: Importing history from database
[2019-01-25 16:37:29.502]    PIDFILE: Using /var/run/pihole-FTL.pid
[2019-01-25 16:37:29.502]    PORTFILE: Using /var/run/pihole-FTL.port
[2019-01-25 16:37:29.502]    SOCKETFILE: Using /var/run/pihole/FTL.sock
[2019-01-25 16:37:29.503]    WHITELISTFILE: Using /etc/pihole/whitelist.txt
[2019-01-25 16:37:29.503]    BLACKLISTFILE: Using /etc/pihole/black.list
[2019-01-25 16:37:29.503]    GRAVITYFILE: Using /etc/pihole/gravity.list
[2019-01-25 16:37:29.503]    REGEXLISTFILE: Using /etc/pihole/regex.list
[2019-01-25 16:37:29.503]    SETUPVARSFILE: Using /etc/pihole/setupVars.conf
[2019-01-25 16:37:29.504]    AUDITLISTFILE: Using /etc/pihole/auditlog.list
[2019-01-25 16:37:29.504] Finished config file parsing
[2019-01-25 16:37:29.504] INFO: No whitelist file found
[2019-01-25 16:37:29.505] Compiled 0 Regex filters and 0 whitelisted domains in 0.4 msec (0 errors)
[2019-01-25 16:37:29.512] Database successfully initialized
[2019-01-25 16:37:29.515] Notice: Increasing queries struct size from 0 to 10000
[2019-01-25 16:37:29.515] Notice: Increasing domains struct size from 0 to 1000
[2019-01-25 16:37:29.516] Notice: Increasing clients struct size from 0 to 10
[2019-01-25 16:37:29.516] Notice: Increasing overTime struct size from 0 to 100
[2019-01-25 16:37:29.516] New forward server: 208.67.222.222 (0/0)
[2019-01-25 16:37:29.517] Notice: Increasing forwarded struct size from 0 to 4
[2019-01-25 16:37:29.517] New forward server: 208.67.220.220 (1/4)
[2019-01-25 16:37:29.549] Notice: Increasing overTime struct size from 100 to 200
[2019-01-25 16:37:29.567] Imported 3068 queries from the long-term database
[2019-01-25 16:37:29.568]  -> Total DNS queries: 3068
[2019-01-25 16:37:29.568]  -> Cached DNS queries: 2223
[2019-01-25 16:37:29.568]  -> Forwarded DNS queries: 839
[2019-01-25 16:37:29.568]  -> Exactly blocked DNS queries: 6
[2019-01-25 16:37:29.569]  -> Unknown DNS queries: 0
[2019-01-25 16:37:29.569]  -> Unique domains: 19
[2019-01-25 16:37:29.569]  -> Unique clients: 4
[2019-01-25 16:37:29.569]  -> Known forward destinations: 2
[2019-01-25 16:37:29.569] Successfully accessed setupVars.conf
[2019-01-25 16:37:29.614] PID of FTL process: 18721
[2019-01-25 16:37:29.614] Listening on port 4711 for incoming IPv4 telnet connections
[2019-01-25 16:37:29.626] Listening on port 4711 for incoming IPv6 telnet connections
[2019-01-25 16:37:29.626] Listening on Unix socket
[2019-01-25 16:37:29.629] INFO: No whitelist file found
[2019-01-25 16:37:29.629] Compiled 0 Regex filters and 0 whitelisted domains in 0.5 msec (0 errors)
[2019-01-25 16:37:31.315] /etc/pihole/gravity.list: parsed 112495 domains (took 1684.2 ms)

jfb · January 25, 2019, 10:05pm

The first output tells us that the IPv4 clients are the router, the Pi itself and Pi-Hole. If there are other clients, they are coming through the router and shown as the router.

From a client, please run the following and post the output.

nslookup cnn.com 192.168.1.6

nslookup flurry.com 192.168.1.6

rufus · January 25, 2019, 10:22pm

nslookup cnn.com 192.168.1.6
Server:  raspberrypi
Address:  192.168.1.6

Non-authoritative answer:
Name:    cnn.com
Addresses:  2a04:4e42:200::323
      2a04:4e42::323
      2a04:4e42:400::323
      2a04:4e42:600::323
      151.101.1.67
      151.101.129.67
      151.101.65.67
      151.101.193.67

nslookup flurry.com 192.168.1.6                                                                         
Server:  raspberrypi                                                                                                    
Address:  192.168.1.6                                                                                                                                                                                                                           Name:    flurry.com                                                                                                     
Addresses:  ::  0.0.0.0

jfb · January 25, 2019, 10:49pm

Those results show the Pi-Hole is working for that client.

The Pi-Hole is not the problem - if other clients are using other DNS and seeing ads, then the problem is with those clients.

rufus · January 27, 2019, 5:48pm

this is from that client
it looks like it the ads are not blocked
what am i missing?

jfb · January 27, 2019, 6:11pm

We have established that Pi-Hole is properly processing received DNS requests.

Your problem appears to be that some of the DNS traffic from clients is bypassing Pi-Hole, and the ads are coming through those unfiltered domains.

You will need to take a careful look at your router and client configuration to see where the other DNS path is occuring, and correct then. Once you get ALL your DNS traffic going to your Pi-Hole, you should no longer see ads.

system · February 17, 2019, 6:11pm

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