Pi-hole randomly stops responding to DNS requests / even on clean install of Buster & Pi-hole

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

Expected Behaviour:

Pi-hole should respond to DNS requests

Actual Behaviour:

Pi-hole randomly stops responding to DNS requests

Debug Token:

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

When that fails, please check (and respond with) the output of

sudo systemctl status pihole-FTL.service

Ok. I did an nslookup from my computer the last time it happened and it timed out. Here’s a few lines of what was going on in the pihole.log when it wasn’t responding. The .130 address is an iPad, and there were a lot of DHCP requests from an Ecobee thermostat. The pattern in this log just kept repeating while the DNS wasn’t responding. During this time, neither my Mac nor Windows PC could get a response from the pihole DNS. The DNS started working again after about two minutes and about 200 log entries for queries and replies appeared in 1 second.

My pihole is running on a Pi 3B+. I formatted the sd card and installed Buster and then pihole a couple of weeks ago. I’ve made no config changes to the default other than adding a few block lists, enabling DHCP, and selecting “Listen on all interfaces” when I was troubleshooting this issue.

Oct 21 13:23:56 dnsmasq-dhcp[606]: DHCPREQUEST(eth0) 192.168.0.101 44:61:32:f0:2c:f4 
Oct 21 13:23:56 dnsmasq-dhcp[606]: DHCPACK(eth0) 192.168.0.101 44:61:32:f0:2c:f4 Ecobee
Oct 21 13:24:04 dnsmasq[606]: reply prod.webextstoragesync.prod.cloudops.mozgcp.net is 34.95.71.207
Oct 21 13:24:04 dnsmasq-dhcp[606]: DHCPREQUEST(eth0) 192.168.0.101 44:61:32:f0:2c:f4 
Oct 21 13:24:04 dnsmasq-dhcp[606]: DHCPACK(eth0) 192.168.0.101 44:61:32:f0:2c:f4 Ecobee
Oct 21 13:24:11 dnsmasq[606]: query[A] p64-keyvalueservice.icloud.com from 192.168.0.130
Oct 21 13:24:11 dnsmasq[606]: forwarded p64-keyvalueservice.icloud.com to 1.0.0.1
Oct 21 13:24:11 dnsmasq-dhcp[606]: DHCPREQUEST(eth0) 192.168.0.101 44:61:32:f0:2c:f4 
Oct 21 13:24:11 dnsmasq-dhcp[606]: DHCPACK(eth0) 192.168.0.101 44:61:32:f0:2c:f4 Ecobee
Oct 21 13:24:18 dnsmasq[606]: query[A] incoming.telemetry.mozilla.org from 192.168.0.10
Oct 21 13:24:18 dnsmasq[606]: /etc/pihole/gravity.list incoming.telemetry.mozilla.org is 0.0.0.0
Oct 21 13:24:18 dnsmasq-dhcp[606]: DHCPREQUEST(eth0) 192.168.0.101 44:61:32:f0:2c:f4 
Oct 21 13:24:18 dnsmasq-dhcp[606]: DHCPACK(eth0) 192.168.0.101 44:61:32:f0:2c:f4 Ecobee
Oct 21 13:24:25 dnsmasq[606]: query[A] p64-keyvalueservice.icloud.com from 192.168.0.130
Oct 21 13:24:25 dnsmasq[606]: forwarded p64-keyvalueservice.icloud.com to 1.1.1.1
Oct 21 13:24:25 dnsmasq[606]: forwarded p64-keyvalueservice.icloud.com to 1.0.0.1
Oct 21 13:24:25 dnsmasq-dhcp[606]: DHCPREQUEST(eth0) 192.168.0.101 44:61:32:f0:2c:f4 
Oct 21 13:24:25 dnsmasq-dhcp[606]: DHCPACK(eth0) 192.168.0.101 44:61:32:f0:2c:f4 Ecobee

It seems to be working OK right now, but I ran this anyway:

sudo systemctl status pihole-FTL.service

And this was the output. Should it not say “raspberrypi pihole-FTL[349]: Not running”?

● pihole-FTL.service - LSB: pihole-FTL daemon
   Loaded: loaded (/etc/init.d/pihole-FTL; generated)
   Active: active (exited) since Mon 2019-10-21 09:11:03 EDT; 5h 47min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 349 ExecStart=/etc/init.d/pihole-FTL start (code=exited, status=0/SUCCESS)

Oct 21 09:10:50 raspberrypi systemd[1]: Starting LSB: pihole-FTL daemon...
Oct 21 09:10:50 raspberrypi pihole-FTL[349]: Not running
Oct 21 09:11:01 raspberrypi su[585]: (to pihole) root on none
Oct 21 09:11:01 raspberrypi su[585]: pam_unix(su:session): session opened for user pihole by (uid=0)
Oct 21 09:11:03 raspberrypi pihole-FTL[349]: FTL started!
Oct 21 09:11:03 raspberrypi systemd[1]: Started LSB: pihole-FTL daemon.

Yes that is to be expected as it’s up and running.

We want to know/see what state it is, when it’s not.

That is literally the same second as the process start.
11 seconds later the process is fully loaded and 13 seconds later, FTL is up and running.

Indeed that is, there are quite a few.

I’ve seen this happen within my network too with my honeywell thermostat.

I ended up using DHCP IP reservation for that MAC address, prevented it from actually chatting so much with the DHCP server.

See if you can define the IP manually in the interface too. That would be the best option …

DNS stopped responding again. Here’s the output from “sudo systemctl status pihole-FTL.service”. Seems the same as before when DNS was responding.

● pihole-FTL.service - LSB: pihole-FTL daemon
   Loaded: loaded (/etc/init.d/pihole-FTL; generated)
   Active: active (exited) since Mon 2019-10-21 16:08:52 EDT; 2min 5s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 11816 ExecStart=/etc/init.d/pihole-FTL start (code=exited, status=0/SUCCESS)

Oct 21 16:08:41 raspberrypi systemd[1]: Starting LSB: pihole-FTL daemon...
Oct 21 16:08:41 raspberrypi pihole-FTL[11816]: Not running
Oct 21 16:08:51 raspberrypi su[11871]: (to pihole) root on none
Oct 21 16:08:51 raspberrypi su[11871]: pam_unix(su:session): session opened for user pihole by (uid=0)
Oct 21 16:08:52 raspberrypi pihole-FTL[11816]: FTL started!
Oct 21 16:08:52 raspberrypi systemd[1]: Started LSB: pihole-FTL daemon.

I’ve wondered if my issues might be related to IPV6, although having DNS completely stop responding doesn’t seem like an IPV6 issue. I do have an Archer C9 router that someone mentions as having IPV6 issues in this post:

Can't get IPv6 working

pihole-FTL seems to be working properly.

When it’s not working run a nslookup and see what is used to resolve.

You can use nslookup flurry.com 192.168.0.250 on your client (it should return NXDOMAIN).

I have been having this problem for over a year, on PI-2, reinstalled OS and pi-hole and same issue. If you ping the PI, DNS starts responding to NSLookup again.