Pi Hole as the DNS unable to resolve domains

Help
1

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

Expected Behaviour:

Pi Hole should resolve domains.

Actual Behaviour:

Websites are unable to be resolved and I receive screens that say "This site can't be reached."

Debug Token:

https://tricorder.pi-hole.net/e408otg6v4

I want to add that I'm just some dude. I have very little technical knowledge outside of being a user. So if you have suggestions for troubleshooting, I ask that you provide specific instructions on how to do or how to get to something you refer to.

I just installed a brand new Raspberry Pi 3 Model B+ and put the July 2019 (Kernel 4.19) version of Buster Lite on it.

I followed this guide to set up my Pi Hole. The device is connected via ethernet cable to my Netgear Nighthawk R7800 router (firmware version V1.0.2.62).

Below are some settings that might help in troubleshooting:

Upstream DNS Servers: OpenDNS (ECS) - IPv4 only
Interface Listening Behavior: Listen on all interfaces
Advanced DNS Settings: None selected
DHCP Server: NOT enabled

2

Your debug log shows that Pi-Hole is receiving and processing requests. One client will be the Pi, the other is likely the router (and all your DNS queries from the clients are being shown as coming from the router). The output below shows the activity in the 24 hours prior to running the debug log.

   [2019-08-25 15:19:36.573 7676] Imported 72296 queries from the long-term database
   [2019-08-25 15:19:36.574 7676]  -> Total DNS queries: 72296
   [2019-08-25 15:19:36.574 7676]  -> Cached DNS queries: 658
   [2019-08-25 15:19:36.574 7676]  -> Forwarded DNS queries: 71279
   [2019-08-25 15:19:36.574 7676]  -> Exactly blocked DNS queries: 359
   [2019-08-25 15:19:36.574 7676]  -> Unknown DNS queries: 0
   [2019-08-25 15:19:36.574 7676]  -> Unique domains: 399
   [2019-08-25 15:19:36.574 7676]  -> Unique clients: 2
   [2019-08-25 15:19:36.574 7676]  -> Known forward destinations: 4

Here is some basic troubleshooting. Run these commands and post the output here (copy and paste will work fine).

From the Pi terminal in Linux:

dig cnn.com

dig flurry.com

echo ">top-domains" | nc 127.0.0.1 4711

echo ">top-ads" | nc 127.0.0.1 4711

tail -n20 /var/log/pihole.log

From a client with a command line (Windows, as an example)

nslookup pi.hole

5

Looking at your original debug log, there were a number or repeated requests for this domain, which may have overloaded Pi-Hole. This may be causing the error seen in your tail of the pihole.log.

   -----head of pihole.log------
   Aug 25 01:17:08 dnsmasq[10479]: query[A] cf4ad3672c07a9d5836235778572287a.api.appsee.com from 192.168.1.1
   Aug 25 01:17:08 dnsmasq[10479]: forwarded cf4ad3672c07a9d5836235778572287a.api.appsee.com to 1.0.0.1

Aug 25 12:45:20 dnsmasq[607]: Maximum number of concurrent DNS queries reach (max: 150)

What appears to be happening is that your Pi-Hole is being flooded with DNS requests from network client(s), and your upstream DNS resolver is not resolving this, causing an error.

Try these steps to troubleshoot and resolve.

From the Pi terminal: ping -c3 1.0.0.1

Change your upstream DNS server in Pi-Hole from OpenDNS to one or two of the other choices.

6

Here is the output for that command:

ping -c 1.0.0.1

Usage: ping [-aAbBdDfhLnOqrTVvV64] [-c count] [-i interval] [-I interface]
	    [-m mark] [-M pmtudisc_option] [-l preload] [-p pattern] [-Q tos]
            [-s packetsize] [-S sndbuf] [-t tt] [-T timestamp_option]
            [-w deadline] [-W timeout] [hop1 ...] destination
Usage: ping -6 [-aAbBdDfhLnOqrTVvV64] [-c count] [-i interval] [-I interface]
            [-l preload] [-m mark] [-M pmtudisc_option]
            [-N nodeinfo_option] [-p pattern] [-Q tclass] [-s packetsize]
            [-S sndbuf] [-t ttl] [-T timestamp_option] [-w deadline]
            [-W timeout] destination

I looked up this appsee and it's a "visual mobile analytics platform that enables app developers and publishers to measure, understand and improve the user experience (UX) in their mobile app." I wonder if my Nest Thermostat E is constantly sending DNS requests so it can stay up to date?

I'll try disabling the Nest's Wi-Fi connection and see if that changes anything. If not, I'll switch the DNS settings like you suggested. I'll report back.

7

You missed a digit. ping -c3...

8

You're right I did. Here is the correct output.

ping -c3 1.0.0.1

PING 1.0.0.1 (1.0.0.1) 56(84) bytes of data.
64 bytes from 1.0.0.1: icmp_seq=1 ttl=58 time=36.4 ms
64 bytes from 1.0.0.1: icmp_seq=2 ttl=58 time=29.6 ms
64 bytes from 1.0.0.1: icmp_seq=3 ttl=58 time=29.5 ms

--- 1.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 6ms
rtt min/avg/max/mdev = 29.495/31.832/36.432/3.258 ms

Disabling the Nest E did not have any impact. Let me try changing the DNS settings to something other than OpenDNS.

1 Like
10

These are all problems. I would run pihole -r and select reconfigure.

11

How much free space do you have left? That /var/log/pihole.log is huge and the latest timestamps are old.

Can you run df -h and see if you are out of space?

12

I did a reconfigure. Here are the answers I gave during the process when given an option.

This installer will transform your device into a network-wide ad blocker!

  • Yes

Choose An Interface (press space to select)

  • enxb827eb0559c3 - (I have no idea what this is. The first time I did this the option was called "eth0"

Select an Upstream DNS Provider. To use your own, select Custom.

  • OpenDNS (ECS)

Pi-hole relies on third party lists in order to block ads...

  • left all options selected

Select Protocols (press space to select)

  • left IPv4 and IPv6 selected

Do you want to use your current network settings as a static address?

  • Yes

Do you wish to install the web admin interface?

  • On

Do you wish to install the web server (lighttpd)?

  • On

Do you want to log queries?

  • On

Select a privacy mode for FTL

  • Show everything

I then rebooted the Pi for good measure.

I am still not able to resolve domains. Strangely though, while the Pi was my DNS, I was successfully able to upload the newest debug log. All the other times I tried to do this with the Pi as my DNS, it failed (hence me copy and pasting it).

Log: https://tricorder.pi-hole.net/6hqwat80ik

13

@DanSchaper

df -h

Filesystem	Size	Used	Avail	Use% 	Mounted on
/dev/root	15G	1.3G	13G	10%	/
devtmpfs	459M	0	459M	0%	/dev
tmpfs		464M	7.0M	457M	2%	/dev/shm
tmpfs		464M	6.3M	457M	2%	/run
tmpfs		5.0M	4.0K	5.0M	1%	/run/lock
tmpfs		464M	0	464M	0%	/sys/fs/cgroup
/dev/mmcblk0p1	253M	40M	214M	16%	/boot
tmpfs		93M	0	93M	0%	/run/user/999
tmpfs		93M	0	93M	0%	/run/user/1000
14

The log file isn't appending data. Check the permissions, sudo ls -lah /var/log/pihole.log and then try sudo tail -f /var/log/pihole.log while attempting to resolve domains. You should see logs scrolling with information on what is being attempted.

15

sudo ls -lah /var/log/pihole.log

--rw-r--r-- 1 pihole 22M Aug 25 18:19 /var/log/pihole.log

sudo tail -f /var/log/pihole.log

Aug 25 18:19:40 dnsmasq[609]: reply error is REFUSED
[this about nine more times)

16

Something is actively choosing to not respond to your queries.

17

@DanSchaper so it seems. Any idea what to check next?

18

Change your upstream DNS server for Pi-Hole to a different provider and see if that resolves your problem.

Edit - we’ve done this already, my error

19

@jfb I tried that earlier as one of your suggestions to no avail. I changed it from OpenDNS to something else. When I reconfigured, I selected OpenDNS again.

20

Are you able to dig on the Pi-hole device using the IP addresses from /etc/pihole/setupVars.conf for the DNS1 and DNS2?

21

@DanSchaper Sorry for the delayed response. Long day.

dig 208.67.222.222

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> 208.67.222.222
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NERROR, id: 3295
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
208.67.222.222.		0	IN 	A	208.67.222.222

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Aug 26 17:51:07 EDT 2019
;; MSG SIZE  rcvd: 59

dig 208.67.220.220

; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> 208.67.222.222
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NERROR, id: 11359
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION
208.67.220.220		0	IN	A	208.67.220.220

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Aug 26 17:55:59 EDT 2019
;; MSG SIZE  rcvd: 59
22

That's not quite the command. You already have the IP, you now want to direct a dig to that IP and see if the DNS resolver at the other end will resolve the query. Try these:

dig flurry.com @208.67.222.222

dig flurry.com @208.67.222.220

dig flurry.com

1 Like
23

@jfb Thanks for the correction. I will run those if need be, but something interesting just happened.

I had a hunch and ran a test. I turned set the Pi as my DNS in my router settings, selected all the upstream DNS servers (because why not), and restarted my DNS resolver. This worked! At least for a time. After testing a few sites (google, facebook, cnn, etc.), I though "Why not turn off query logging and flush the logs so I don't fill up space without reason?"

This was a mistake. As soon as I did this from the console UI, the Pi began failing to resolve domains again.

So I started over. I turned query logging back on, ensured the Pi was still set as my DNS in my router, and then restart my DNS resolver again. As I type this, I am resolving queries through my Pi.

In case you want to see a debug log of the functional Pi, it's at: https://tricorder.pi-hole.net/5m97py39ti

Why would turning off query logging and flushing logs have this impact? It may just be a coincidence, but I've done this twice with the same results.

EDIT

I spoke too soon. Now I'm thinking it has nothing to do with turning off query logging. After I posted the original version of this comment, I stopped being able to resolve queries after having successfully resolved numerous websites. It seemed to work for a couple minutes and then died again.

Regarding those dig commands, the first (208.67.222.222) succeeded in over two seconds, the second (208.67.222.220) timed out, and the last (flurry.com) succeeded in 951 msec).