Pi Hole broke suddenly - temporary failure in name resolution now

root@raspberrypi:~# grep -v '^[[:blank:]]*#\|^[[:blank:]]*$' /etc/dhcpcd.conf
hostname
clientid
persistent
option rapid_commit
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
option interface_mtu
require dhcp_server_identifier
slaac private
interface eth0
        static ip_address=192.168.2.2/24
        static routers=192.168.2.1
        static domain_name_servers=127.0.0.1
root@raspberrypi:~#

I rebooted the entire device via the reboot command..

root@raspberrypi:~# date
Wed 20 Apr 2022 02:15:51 PM EDT
root@raspberrypi:~# ping google.com
ping: google.com: Temporary failure in name resolution
root@raspberrypi:~#

The date went back to yesterday, again! Even after manually setting it before a safe reboot! So now instead I should re-issue the date command then just try to restart Pi Hole itself?

Sorry I tried to edit the post to change it to a response to you but ended up having to delete it

I googled how to re-start Pihole without reboot and it was supposedly 'pihole restartdns'

Still have not fixed it sadly

root@raspberrypi:~# date -s '21 APR 2020 15:35:00'
Tue 21 Apr 2020 03:35:00 PM EDT
root@raspberrypi:~# ping google.ca
ping: google.ca: Temporary failure in name resolution
root@raspberrypi:~#
root@raspberrypi:~# pihole restartdns
  [✓] Restarting DNS server
root@raspberrypi:~# date
Tue 21 Apr 2020 03:42:06 PM EDT
root@raspberrypi:~# ping google.ca
ping: google.ca: Temporary failure in name resolution
root@raspberrypi:~#

Oh shoot the command he gave me says 2020 for the year. Let me try fixing that, I literally was cut and pasting his instructions

Maybe reset the DNS server and try uploading a debug?


sudo nano /etc/dhcpcd.conf

static domain_name_servers=8.8.4.4 8.8.8.8

sudo service dhcpcd restart

Holy smokes... here we go

root@raspberrypi:~# date -s '21 APR 2022 15:50:00'
Thu 21 Apr 2022 03:50:00 PM EDT
root@raspberrypi:~# ping google.ca
PING google.ca (172.217.1.3) 56(84) bytes of data.
64 bytes from iad23s25-in-f3.1e100.net (172.217.1.3): icmp_seq=1 ttl=115 time=5.45 ms
64 bytes from iad23s25-in-f3.1e100.net (172.217.1.3): icmp_seq=2 ttl=115 time=4.99 ms
64 bytes from iad23s25-in-f3.1e100.net (172.217.1.3): icmp_seq=3 ttl=115 time=5.60 ms
^C
--- google.ca ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 4.985/5.342/5.595/0.273 ms
root@raspberrypi:~#

WOW, it's alive again.. but will this now stay in sync from this point on ?! Is there anything I should be doing right now to either sync it / make sure it stays sync'ed ? I guess yanking the power cord yesterday is the reason it got so screwed up?

THANK you again for your help thus far everyone.

The long power-down period would have caused the time to be off by too much to be synced, as DanSchaper has explained.
It is easy enough to fix that by manually adjusting the system clock, but it's as easy to forget about that until it happens again.

The most reliable way to address this would be to fit your RPi with a battery-backuped RTC. They are reasonably inexpensive (my DS3231 was about 4 Euros).

As for the chicken-egg issue of syncing with an NTP server when DNSSEC is failiing due to incorrect time, it would be best to cut DNSSEC out of the picture for syncing the time.

Editing your dhcpcd.conf (e.g. as suggested by nprampage) would do just that, by having your Raspberry Pi OS use a public DNS server instead of Pi-hole, allowing it to sync even if the time is off.

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