DNS Failing to Resolve on Raspberri Pi after upgrading to v6 yesterday

Help
1

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

Expected Behaviour:

After upgrading from v5 to v6, Raspberry Pi should be able to resolve DNS requests without issue.

  • Model: Raspberry Pi 3 Model B Rev 1.2
  • OS: Raspbian GNU/Linux 11 (bullseye)
  • Pi-hole Versions:
    • Core version is v6.0.4 (Latest: N/A)
    • Web version is v6.0.1 (Latest: N/A)
    • FTL version is v6.0.2 (Latest: N/A)

Actual Behaviour:

All DNS requests made by the Raspberry Pi itself failed. For example, running ping google.com would instantly fail, but ping 8.8.8.8 would connect fine.

Troubleshooting Comments

I had upgraded a functional Pi-hole installation last night from v5 to v6, but I noticed devices immediately couldn't connect to the internet. I swapped my router to use a backup DNS while I troubleshooted and quickly found out my Raspberry Pi wasn't resolving any DNS requests on itself. The installation was made with no modifications other than configuring it to use unbound via the official guide.

I ran sudo nano /etc/dhcpcd.conf to make sure the Pi wasn't relying on 127.0.0.1#5335 just in case it was Pi-hole by temporarily switching it to static domain_name_servers=1.1.1.1. Even after rebooting and restarting the service, DNS still wasn't working.

I then ran cat /etc/resolv.conf and saw that it still only had nameserver 127.0.0.1 as its single entry despite already editing dhcpcd.conf with the backup DNSes. I manually added nameserver 1.1.1.1 and nameserver 8.8.4.4 to resolv.conf (not a long-term solution, I know), and DNS queries immediately started working again. Running command resolvectl status returns Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.

I'm not super knowledgeable about Linux/pi-hole so I'm afraid to modify things too much on my own. I don't know how much of this, if any, is due to following the aforementioned unbound guide. I found a semi-related Stack Exchange post that suggested running sudo systemctl enable systemd-resolved.service and then
sudo systemctl start systemd-resolved.service, but I haven't done so yet for fear of messing things up further.

Debug Token:

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

(If you want, I can also remove the two nameservers I added to resolve.conf and re-run the debugger, but I'm not sure how I'd upload the log since I wouldn't be able to connect to the Internet from the Raspberrry Pi.)

2

Enabling systemd-resolved would introduce port conflicts over port 53 with Pi-hole, so it should stay disabled.
Currently, there are already potential port conflicts over ports 80 and 443:

 *** [ DIAGNOSING ]: Ports in use
[✗] tcp:0.0.0.0:80 is in use by civetweb-worker (https://docs.pi-hole.net/main/prerequisites/#ports)
[✗] tcp:0.0.0.0:443 is in use by civetweb-worker (https://docs.pi-hole.net/main/prerequisites/#ports)
[✗] tcp:[::]:80 is in use by civetweb-worker (https://docs.pi-hole.net/main/prerequisites/#ports)
[✗] tcp:[::]:443 is in use by civetweb-worker (https://docs.pi-hole.net/main/prerequisites/#ports)

Pi-hole v6 happens to embed a civetweb webserver component, so it's not yet clear whether that civetweb-worker would be a remnant of a failed pihole-FTL or originally started by another civetweb webserver on your system.

Do you run another (civetweb) webserver on your system?

Your debug log shows that pihole-FTL failed to start, potentially for multiple reasons:

*** [ DIAGNOSING ]: Pi-hole processes
[✓] pihole-FTL daemon is active

*** [ DIAGNOSING ]: Pi-hole-FTL full status
   ● pihole-FTL.service - Pi-hole FTL
     Loaded: loaded (/etc/systemd/system/pihole-FTL.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2025-02-25 15:41:43 CST; 1h 6min ago
   Main PID: 659 (pihole-FTL)
      Tasks: 13 (limit: 2059)
        CPU: 1min 59.206s
     CGroup: /system.slice/pihole-FTL.service
             ├─ 659 /usr/bin/pihole-FTL -f
             └─1035 /usr/bin/pihole-FTL -f

Feb 25 15:41:44 raspberrypi pihole-FTL[659]: 2025-02-25 15:41:44.093 CST [659M] INFO: No other running FTL process found.
Feb 25 15:41:44 raspberrypi pihole-FTL[659]: dnsmasq: Name does not resolve at line 35 of /etc/pihole/dnsmasq.conf
Feb 25 15:41:44 raspberrypi dnsmasq[659]: Name does not resolve at line 35 of /etc/pihole/dnsmasq.conf
Feb 25 15:41:44 raspberrypi dnsmasq[659]: FAILED to start up
Feb 25 15:43:37 raspberrypi dnsmasq[1002]: Cannot resolve server name at line 34 of /etc/pihole/dnsmasq.conf.temp
Feb 25 15:43:37 raspberrypi dnsmasq[1002]: FAILED to start up

It looks like the error may be caused by line 34/35 in your Pi-hole's dnsmasq.conf.

Please share the output of:

grep -nv '^#\|^$' /etc/pihole/dnsmasq.conf

Your debug log also shows a peculiar entry in your routing table:

*** [ DIAGNOSING ]: Network routing table
   1.1.1.1 via 192.168.122.1 dev enxb827eb1b4a00

I guess this was introduced by you...

You probably added 1.1.1.1 as router rather than as DNS server.

Please share the output of:

grep -nv '^#\|^$' /etc/dhcpcd.conf
3

Thanks for the response!

The only other thing I run on this Raspberry Pi is homebridge, which might be reserving ports that I'm unaware of. That said, they were both working fine together immediately before upgrading to Pi-hole v6, so I wondered if there might be a conflict there.

As for /etc/dhcpcd.conf, I only (knowingly) edited line 63 below with a few name servers I hoped would work while I figured things out with the Pi-hole. The Internet on the RBP is currently working still, but I suspect it's because I'm not using the Pi-hole. Anyway, here's the info you requested:

Output of grep -nv '^#\|^$' /etc/pihole/dnsmasq.conf:

24:hostsdir=/etc/pihole/hosts
27:no-resolv
30:port=53
33:server=127.0.0.1#5335
34:server=208.67.222.222
38:cache-size=10000
46:localise-queries
49:log-queries
50:log-async
55:log-facility=/var/log/pihole/pihole.log
60:bogus-priv
64:domain-needed
68:expand-hosts
71:dnssec
74:trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
77:trust-anchor=.,38696,8,2,683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16
81:use-stale-cache=3600
84:local-service
87:rev-server=192.168.122.0/24,192.168.122.1
88:server=/master/192.168.122.1
93:local=//
99:domain=lan
100:local=/lan/
107:server=/test/
108:server=/localhost/
109:server=/invalid/
125:server=/bind/
126:server=/onion/
129:cache-rr=ANY
136:filter-rr=ANY

Output of grep -nv '^#\|^$' /etc/dhcpcd.conf:

8:hostname
11:clientid
19:persistent
24:option rapid_commit
27:option domain_name_servers, domain_name, domain_search, host_name
28:option classless_static_routes
30:option interface_mtu
36:require dhcp_server_identifier
41:slaac private
60:interface eth0
61:        static ip_address=192.168.122.3/24
62:        static routers=192.168.122.1
63:        static domain_name_servers=8.8.8.8 1.1.1.1 9.9.9.9