DNS doesn't work after modifying settings to function as a DCHP server

During setup (first time user) I wanted to use my Pi as my DHCP server to default all devices to use Pi-hole for DNS, but half way through following tutorials I realised my router/modem/hub would not support it. I finished the tutorial (abandoning modifications being made for DHCP server functionality) but Pi-hole isn't working - using a client (my laptop) set to use my Pi's IP address as my DNS, and find I can ping www.google.co.uk, but cannot resolve in a web browser - it just times out.

The Pi-hole DNS service seems to stop by itself after a minute or so.

There is an error in the Pi-hole log: PHP error (2): fsockopen(): Unable to connect to 127.0.0.1:4711 (Connection refused) in /var/www/html/admin/scripts/pi-hole/php/FTL.php:47

The debug log fails to upload - it fails to connect to tricorder.pi-hole.net port 443.

Running a Raspberry Pi 5 connected on WiFi

This will temporarily reset the nameserver on the Pi.

sudo nano /etc/resolv.conf

Edit the nameserver line to nameserver 9.9.9.9 or your preferred third party DNS service, save and exit.

Run

pihole -d

and upload the debug log.

I've done as you say, with the nameserver set to 9.9.9.9

The debug log still fails to upload, with the following printout:

[✓] ** 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/pihole_debug.log

Can you verify the contents of /etc/resolv.conf please? Run cat /etc/resolv.conf and post the results.

The error from curl is saying that there is no functional DNS server reachable but that should not happen if you have properly set the /etc/resolv.conf to contain the single line nameserver 9.9.9.9.

Contents below. I somehow figured out how to copy the debug log with PowerShell, but it's not a supported file type to upload. I could upload it with a permitted extension, then you could correct it after download?

zed1@raspberrypi:~ $ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 9.9.9.9

You should be able to just copy/paste the file contents, we can hide the paste so that only the support staff can see it.

Before you do that, can you run curl -L https://pi-hole.net and see if there is any raw html code in the terminal? No need to copy/paste that, I want to see if curl is working in general.

In addition to Dan's comments:

Run from your Pi-hole machine, what's the output of:

dig @9.9.9.9 tricorder.pi-hole.net
zed1@raspberrypi:~ $ curl -L https://pi-hole.net
curl: (7) Failed to connect to pi-hole.net port 443 after 32 ms: Couldn't connect to server
zed1@raspberrypi:~ $ dig @9.9.9.9 tricorder.pi-hole.net
;; UDP setup with 9.9.9.9#53(9.9.9.9) for tricorder.pi-hole.net failed: network unreachable.
;; no servers could be reached

;; UDP setup with 9.9.9.9#53(9.9.9.9) for tricorder.pi-hole.net failed: network unreachable.
;; no servers could be reached

;; UDP setup with 9.9.9.9#53(9.9.9.9) for tricorder.pi-hole.net failed: network unreachable.
;; no servers could be reached

zed1@raspberrypi:~ $

The Pi has internet access but cannot access pi-hole.net in a web browser (my laptop can, it's on the same WiFI network)

Would ping 9.9.9.9 succeed from your Pi-hole machine?

I tried pinging that, and google for reference. It can resolve www.google.co.uk but not it's IP address it seems.

zed1@raspberrypi:~ $ ping 9.9.9.9
ping: connect: Network is unreachable
zed1@raspberrypi:~ $ ping 8.8.8.8
ping: connect: Network is unreachable
zed1@raspberrypi:~ $ ping www.google.co.uk
PING www.google.co.uk(lhr25s32-in-x03.1e100.net (2a00:1450:4009:81e::2003)) 56 data bytes

This is an OS level networking issue rather than a DNS one:
The machine hosting your Pi-hole cannot reach 9.9.9.9 nor 8.8.8.8 (and possibly neither any other IP), and network unreachable would indicate a more fundamental issue than just a missing route - probably, your machine isn't connected to any network via IPv4, or it isn't aware of a gateway.

What's the output of

ip route
ip -6 route
1 Like
zed1@raspberrypi:~ $ ip -6 route
2a00:23c6:9d95:2e01::/64 dev wlan0 proto ra metric 600 pref medium
fe80::/64 dev wlan0 proto kernel metric 1024 pref medium
default via fe80::def5:1bff:fe41:631b dev wlan0 proto ra metric 600 pref medium
zed1@raspberrypi:~ $ ip route
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.111 metric 600

If my Pi wasn't connected to any network via IPv4, it wouldn't be able to resolve www.google.co.uk, right?

Wrong.

As I guessed, your machine isn't aware of an IPv4 gateway, and thus lacking a default route.

When preparing your machine for DHCP duties, did you configure a static IP on that machine itself? If so, verify that you did provide an IPv4 gateway as well.

Your IPv6 has a default route, likely learned via auto-configuration from your router's RAs, so you could check if IPv6 connectivity is operational:

dig +short -x 2620:fe::9 @2620:fe::9
dig @2620:fe::9 tricorder.pi-hole.net
ping 2620:fe::9

Edit: If those work, you can replace 9.9.9.9 with 2620:fe::9 in /etc/resolv.conf and upload a debug log.

However, addressing that missing gateway should be your priority.
It is likely that this significantly contributes to your original observation.

Not really.
Given your routes if www.google.co.uk resolve to an ipv6 address you should be able to reach it (usually the ping also prints the actual address it is pinging, maybe if you can also paste the result of ping we can confirm it).
It seems you have a default route for ipv6, but you lack the default route for ipv4. That means that if you try to reach an ipv6 destination it has a route for it, but if you try to reach an ipv4 destination outside your lan it has no route

I know it seems an easy way out, but "did you try turning it off and on again" [cit.]?
Your ipv4 default route somehow disappeared, by rebooting your pi your OS will reset the default configuration on boot.
If you don't want to/can't reboot you can try by adding the default route if you know the ipv4 address of your router:

sudo ip route add default via 192.168.1.X dev wlan0

where you change X with the right number identifying your router

I understand now - I didn't consider an IPv6 DNS.

  1. I ran the commands / checks without issue, and went back into /etc/resolv.conf to replace the nameserver as advised (note it wasn't 9.9.9.9 before changing).
  2. I've rebooted the Pi (as REz suggested).
  3. I re-ran the checks for IPv6 connectivity, but they failed. I tried running pihole -d but the debug log is still unable to upload.
  4. I ran sudo ip route add default via 192.168.1.254 dev wlan0
  5. I re-ran the checks for IPv6 connectivity and pihole -d successfully. The debug token is https://tricorder.pi-hole.net/tkmaljQv/

In Pi-hole, I still have the diagnostic message:
Type:
DNSMASQ_CONFIG
Message:
FTL failed to start due to cannot open or create lease file /var/lib/misc/dnsmasq.leases: Permission denied

I've also tried installing AdGuard, but got the following error:

zed1@raspberrypi:~ $ curl -s -S -L https://raw.githubusercontent.com/Adg... | sh -s -- -v
sh: 1: 400:: not found

My instructions didn't ask you to reboot your machine.
It probably would have been better to follow instructions separately, instead of mixing them with REz's. :wink:

Note that manually adding a route won't survive reboots.
You'd yet have to look into your OS's network configuration tool and verify its settings.

Anyway, we have a debug log now, and that shows that you are running dnsmasq in addition to Pi-hole, causing port conflicts:

*** [ DIAGNOSING ]: Ports in use
[✗] udp:0.0.0.0:53 is in use by dnsmasq (https://docs.pi-hole.net/main/prerequisites/#ports)
    udp:0.0.0.0:67 is in use by dnsmasq
[✗] udp:*:53 is in use by dnsmasq (https://docs.pi-hole.net/main/prerequisites/#ports)
[✗] tcp:0.0.0.0:53 is in use by dnsmasq (https://docs.pi-hole.net/main/prerequisites/#ports)
[✗] tcp:[::]:53 is in use by dnsmasq (https://docs.pi-hole.net/main/prerequisites/#ports)

You'd have to disable and/or uninstall dnsmasq.

Your debug log also suggests that NetworkManager would be your OS's networking tool.

If you can confirm it is, you should be able to check your current wifi configuration, specifically its [ipv4] section (usually stored in a file under /etc/NetworkManager/system-connections/ - if you decide to share it, don't do so without redacting your wifi password!).

If you do not want to run Pi-hole as DHCP, that section should simply read method=auto.

Running Pihole as DHCP server would require you to set a static IP on device.
So if that [ipv4] section does not contain a static IP, DNS and gateway, you should use one of NetworkManager's tools to configure it, e.g. nmtui.

Above would be mute if some other tool instead of NetworkManager would control your network interface configuration, e.g. NM would ignore all interfaces declared in /etc/network/interfaces.

I've checked the current WiFi config - I can't see anything related to dnsmasq or NetworkManager in the SSH printout...but I am looking at a file in NetworkManager so I guess that counts.

(homeassistant) zed1@raspberrypi:/usr/src/Python-3.12.0 $ sudo cat /etc/NetworkManager/system-connections/BT-2RFJW3.nmconnection
[connection]
id=BT-2RFJW3
uuid=47c54bfa-daa9-465b-8f96-8b8f537a7e3d
type=wifi
interface-name=wlan0
timestamp=1731889240

[wifi]
mode=infrastructure
ssid=BT-2RFJW3

[wifi-security]
key-mgmt=wpa-psk
psk=***

[ipv4]
address1=192.168.1.111/24
method=manual

[ipv6]
addr-gen-mode=stable-privacy
method=auto

[proxy]
(homeassistant) zed1@raspberrypi:/usr/src/Python-3.12.0 $

What are my next steps? Disable / uninstall dnsmasq and set method=auto ? I don't want to run my Pi as a DHCP server...yet. I just want to get Pi-hole functional.

Sorry, I won't interfere with the instructions further, just going to say a couple of thing:

  • It's odd that after reboot you still didn't have any default gateway for ipv4, you'll need to look into it ( NetworkManager saves these settings in /etc/NetworkManager/system-connections/<name-of-connection>) or the next time your Pi will reboot it won't be able to work properly.
  • I wouldn't install AdGuard and PiHole in the same network, they do the same thing... stick on just one of the two. (P.S. you couldn't install it because you tried to run a link that was broken, you need to type the full url instead of that one shortened by ...)
  • Last but not least: the /etc/resolv.conf file that you modified won't persist, as it is written in it, it's generated by NetworkManager, so it will be overwritten. (Probably it's already gone after your reboot) If you want/need to change it's value you need to configure the NetworkManager service

[edit] just noticed you had already posted, if you want to fix your default route problem keeping your current configuration (static ip) just edit your /etc/NetworkManager/system-connections/BT-2RFJW3.nmconnection replacing

[ipv4]
address1=192.168.1.111/24
method=manual

with

[ipv4]
address1=192.168.1.111/24,192.168.1.254
method=manual

it defines the default gateway for the network

As already inferred by our investigations, you are missing a gateway.

A more complete section may have looked similar to:

[ipv4]
address1=192.168.1.111/24
gateway=192.168.1.254
dns=127.0.0.1,9.9.9.9
method=manual

If you decide to set a static IP on your Pi-hole machine, I'd recommend to do so via nmtui, rather than editing files directly (which is also discouraged by NM's documentation).
This would also make sure that the information is stored in the correct syntax, and with the correct permissions.

As mentioned, a static IP would be required if you run Pi-hole as DHCP server, but you could opt to set it anyway, so you would be prepared if you tried to make that switch later.

If you opt for acquiring an IP from your router's DHCP server, use nmtui to switch your interface back to automatic.