Hello there, been running a Pi Hole on a 2B for a long time. Had a modem upgrade yesterday and all devices in the house work fine except the Pi Hole.
If I ssh into the device and attempt to ping something, it all just comes back as "Temporary failure in name resolution"
I have gone into the Pi Hole web interface dozens of times, and tried changing the Upstream DNS servers to all kinds of different options. Makes zero difference. The device is still unable to resolve domain names.
However pinging by IP address works perfectly fine - so it clearly has connectivity. I can ping 8.8.8.8 or 4.2.2.1 for example.
I am at my wits end here and simply do not understand why this piece of absolute junk is broken and gives no information about what it's problem is.
[✓] ** FINISHED DEBUGGING! **
* The debug log can be uploaded to tricorder.pi-hole.net for sharing with developers only.
[?] Would you like to upload the log? [y/N] y
* Using curl for transmission.
* curl failed, contact Pi-hole support for assistance.
* Error message: curl: (6) Could not resolve host: tricorder.pi-hole.net
[✗] There was an error uploading your debug log.
* Please try again or contact the Pi-hole team for assistance.
* A local copy of the debug log can be found at: /var/log/pihole_debug.log
LMAO
Pi Hole depends on ... DNS ... to upload it's error logs..
Did you try temporarily changing the DNS server on the machine your working from (the one from which you launched SSH)? Just to get the debug log uploaded if nothing else.
1.1.1.1
9.9.9.9
8.8.8.8
should all work for your short-term purposes.
Run from your Pi-hole host machine, what's the output of
ip address
cat /etc/resolv.conf
The computer I am SSHing from is working perfectly fine - because I stopped using the broken Pi Hole as a DNS server. I am unsure how to change the DNS on the Pi Hole itself, I am a novice user. But it STILL is 100% down, cannot resolve anything at all.
root@raspberrypi:/etc# ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:27:eb:70:0a:e1 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.2/24 brd 192.168.2.255 scope global noprefixroute eth0
valid_lft forever preferred_lft forever
inet6 fe80::89e5:532a:89f4:98bf/64 scope link
valid_lft forever preferred_lft forever
root@raspberrypi:/etc# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
root@raspberrypi:/etc#
Run from your Pi-hole host machine, please provide the output of the following commands:
dig +short @127.0.0.1 chaos txt version.bind
nslookup flurry.com 9.9.9.9
nslookup flurry.com 192.168.2.2
pi@raspberrypi:~ $ ping google.com
ping: google.com: Temporary failure in name resolution
pi@raspberrypi:~ $ sudo -i
root@raspberrypi:~#
root@raspberrypi:~# dig +short @127.0.0.1 chaos txt version.bind
"dnsmasq-pi-hole-2.87test8"
root@raspberrypi:~# nslookup flurry.com 9.9.9.9
Server: 9.9.9.9
Address: 9.9.9.9#53
Non-authoritative answer:
Name: flurry.com
Address: 74.6.136.150
Name: flurry.com
Address: 98.136.103.23
Name: flurry.com
Address: 212.82.100.150
root@raspberrypi:~# nslookup flurry.com 192.168.2.2
Server: 192.168.2.2
Address: 192.168.2.2#53
Name: flurry.com
Address: 0.0.0.0
Name: flurry.com
Address: ::
root@raspberrypi:~#
Ok, so the DNS server listening on you host's 127.0.0.1 is indeed Pi-hole.
Your host machine can resolve flurry.com via 9.9.9.9, a public DNS resolver.
And your Pi-hole at 192.168.2.2 correctly blocks flurry.com as expected.
Let's see what happens when you ask Pi-hole to resolve google.com:
dig google.com @192.168.2.2
1 Like
root@raspberrypi:~# dig google.com @192.168.2.2
; <<>> DiG 9.11.5-P4-5.1+deb10u6-Raspbian <<>> google.com @192.168.2.2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14698
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; OPT=15: 00 08 ("..")
;; QUESTION SECTION:
;google.com. IN A
;; Query time: 15 msec
;; SERVER: 192.168.2.2#53(192.168.2.2)
;; WHEN: Wed Apr 20 22:35:15 EDT 2022
;; MSG SIZE rcvd: 45
root@raspberrypi:~# ping google.com
ping: google.com: Temporary failure in name resolution
root@raspberrypi:~#
Thank you for taking the time to help so far
Option 15 signals an EDE error code, where an info-code of 8 stands for an error in DNSSEC validation (Signature Not Yet Valid).
Please check the time of your Pi-hole host machine.
The most common cause for DNSSEC related failures would be wrong time information on the computer it runs on. RPis would be especially prone to that, as they lack a batttery-backuped RTC, potentially leaving them off-sync after longer periods of power-downs, until they can update their time from an NTP server. And with DNSSEC enabled, they cannot do so, as they won't be able to resolve a time server name to an IP address.
Thanks again for your reply - I am a novice user and not exactly sure how to check or correct that. I tried 'time' and that gave me some weird milliseconds output so now I tried 'date'
root@raspberrypi:~# date
Wed 20 Apr 2022 10:54:45 PM EDT
It is wrong indeed - and this device was unplugged for most of the day yesterday while the Fiber technicians installed my new gigabit internet. Is there a way to make this thing automatically sync when it gets online? I will also google this now and see if I can figure out how to change it
Try setting your time manually, e.g. by
sudo date -s '2022-04-22 20:00:00'
Adjust actual time as appropriate for your location, and also make sure your RPi's time zone information is correct (check via raspi-config).
Raspberry Pi OS will try to sync when online, but as explained, that would fail if DNSSEC is enabled while the time is still wrong.
You could work around this by not using 127.0.0.1 (your DNSSEC enabled Pi-hole) as the resolver for your Raspberry Pi OS, or -provided your router supports acting as a local time server- by adding your router's IP to the list of time servers to be used by your RPi OS.
root@raspberrypi:~# raspi-config
Current default time zone: 'America/New_York'
Local time is now: Wed Apr 20 23:12:25 EDT 2022.
Universal Time is now: Thu Apr 21 03:12:25 UTC 2022.
I set the time zone to something similar to mine (Toronto), but the date is still wrong here
root@raspberrypi:~# timedatectl status
Local time: Wed 2022-04-20 23:14:33 EDT
Universal time: Thu 2022-04-21 03:14:33 UTC
RTC time: n/a
Time zone: America/New_York (EDT, -0400)
System clock synchronized: no
NTP service: active
RTC in local TZ: no
I typed this, found in the guide about syncing time above and this is the output. Unlike in the guide, it doesn't say anything is synchronized and he doesn't explain in the guide what to do when it isn't.
I will try setting manually as per instructions above but was hoping to get something more accurate
I am not quite sure how to apply any of those changes unfortunately, but I will see if I can research "changing resolver for raspberry pi os" if that's what I should do? Will also google how to add time servers and see if I can add my router which would be 192.168.2.1 ?
Thanks again
NTP will only correct small time offsets. A day off is too much for NTP to account for.
First step is to use
sudo date -s '21 APR 2020 15:15:00
verify that with date again.
Once you are within about an hour of actual time then NTP will keep things in sync.
Raspberry Pi devices lack an onboard Real Time Clock so it is pretty important to never pull the power and make sure you always safely shut down the Pi when you need to turn it off.
root@raspberrypi:~# date -s '21 APR 2020 15:20:00'
Tue 21 Apr 2020 03:20:00 PM EDT
root@raspberrypi:~# date
Tue 21 Apr 2020 03:20:05 PM EDT
root@raspberrypi:~#
Thank you- I completed that command, what should I do next?
root@raspberrypi:~# ping google.com
ping: google.com: Temporary failure in name resolution```
Still getting this unfortunately
On Raspberry Pi OS, that's often found in dhcpcd.conf.
What's the output of
grep -v '^[[:blank:]]*#\|^[[:blank:]]*$' /etc/dhcpcd.conf