Pihole is broken and I have no idea why

Help
1

pihole is installed on a dedicated raspberry pi running Raspbian 11 (bullseye). I’ve been using it as DNS server for several years now, and as DHCP since the beginning of the year. So far I’ve never had any major problems – until yesterday.

Expected Behaviour:

  • pihole hands out DHCP leases to clients
  • pihole resolves domains

Actual Behaviour:

  • pihole does not hand out DHCP leases to clients. Well, pihole.log shows lines like the following sometimes, but the client does not receive the lease. (I added a static IP address so I could ssh into the Pi.)
Feb 16 20:05:34 dnsmasq-dhcp[8008]: DHCPDISCOVER(enxb827ebf5014e) 192.168.1.3 b4:2e:99:34:2b:c1
Feb 16 20:05:34 dnsmasq-dhcp[8008]: DHCPOFFER(enxb827ebf5014e) 192.168.1.3 b4:2e:99:34:2b:c1
Feb 16 20:05:34 dnsmasq-dhcp[8008]: DHCPSOLICIT(enxb827ebf5014e) 00:04:af:38:32:5f:39:d8:14:2c:28:31:73:e7:81:75:a4:5b
Feb 16 20:05:34 dnsmasq-dhcp[8008]: RTR-SOLICIT(enxb827ebf5014e)
Feb 16 20:05:34 dnsmasq-dhcp[8008]: RTR-ADVERT(enxb827ebf5014e) fd28:68b:320::
Feb 16 20:05:34 dnsmasq-dhcp[8008]: RTR-ADVERT(enxb827ebf5014e) 2001:470:1f0b:273::
  • pihole does not resolve domains. Well, pihole.log shows lines like the following sometimes, but pihole query ntp.ubuntu.com returns “Communication error. Is FTL running?”.
Feb 16 19:53:41 dnsmasq[8008]: forwarded ntp.ubuntu.com to 46.182.19.48
Feb 16 19:53:41 dnsmasq[8008]: forwarded ntp.ubuntu.com to 194.150.168.168
Feb 16 19:53:41 dnsmasq[8008]: forwarded ntp.ubuntu.com to 194.242.2.3
Feb 16 19:53:41 dnsmasq[8008]: dnssec-query[DS] ubuntu.com to 194.150.168.168

I have no idea what might have caused all this – the Pi didn’t reboot, there was no upgrade, nada. I did notice that /etc/hosts was missing the line 127.0.1.1 rpi which caused the machine to not be able to resolve its own hostname. I fixed it but the main problem remains.

I’m completely at a loss. It’s probably something extremely stupid, something that I should have seen right away. But I’m just not getting anywhere on my own anymore.

Please help or send cat pictures.

Debug Token:

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

Cheers
W

2

We can do both.

2018-03-17 10.25.16
2018-03-17 10.25.163024×4032 2.15 MB

3 Likes
3

Aww … You’ve made my day already :slight_smile:

4

From your debug log, a few things noted:

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve img.cqcounter.com on lo (127.0.0.1)
[✗] Failed to resolve img.cqcounter.com on enxb827ebf5014e (192.168.1.10)
[✓] doubleclick.com is 142.251.39.238 via a remote, public DNS server (8.8.8.8)

*** [ DIAGNOSING ]: Pi-hole diagnosis messages
   count   last timestamp       type                  message                                                       blob1                 blob2                 blob3                 blob4                 blob5               
   ------  -------------------  --------------------  ------------------------------------------------------------  --------------------  --------------------  --------------------  --------------------  --------------------
   1       2026-02-16 19:53:41  DNSMASQ_WARN          not using configured address 192.168.1.10 because it is in use by the server or relay

From our documentation page: dnsmasq warnings - Pi-hole documentation

not using configured address ADDRESS because it is in use by the server or relay

Handing out addresses used by known critical infrastructure (like the DHCP server or a relay) is prevented to avoid IPaddress duplication issues.

This can happen when you have configured a static address assignment for the IP address of your Pi-hole. As this could result in an IP address conflict, Pi-hole offers a different free address from your configured DHCP pool. As this means Pi-hole behaves differently than you configured it to, it issues a warning.

The solution would be to either remove the static reservation for the Pi-hole itself (see ADDRESS in the warning) or simply accept this warning as it should only happen during debug log generation. When this warning appears outside of a running DHCP test, check that your Pi-hole is indeed using a static address.

5

I think the dnsmasq warning may have been just a side effect of the debug log's DHCP discovery test. If it shows up again if you rerun a debug log, you probably can ignore it.

Your debug log shows that all tests for blocked domains have failed:

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve img.cqcounter.com on lo (127.0.0.1)
[✗] Failed to resolve img.cqcounter.com on enxb827<redacted> (192.168.1.10)
[✓] doubleclick.com is 142.251.39.238 via a remote, public DNS server (8.8.8.8)

*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve 5y6ipuyqc6k46w.cfd on lo (::1)
[✗] Failed to resolve 5y6ipuyqc6k46w.cfd on enxb827<redacted> (fd28:<redacted>a5)
[✗] Failed to resolve 5y6ipuyqc6k46w.cfd on enxb827<redacted> (2001:<redacted>24)
[✗] Failed to resolve 5y6ipuyqc6k46w.cfd on enxb827<redacted> (fe80::58<redacted>%enxb827<redacted>)
[✓] doubleclick.com is 2a00:1450:400a:1001::65 via a remote, public DNS server (2001:4860:4860::8888)

In addition, your debug log has no DHCP or RA replies from your Pi-hole, despite Pi-hole being configured as DHCP server.

Combined, that may suggest that pihole-FTL has been either inactive or unresponsive when the respective tests ran.

The latter seems more likely, as all the right ports show up in your debug log, and the service unit also reported pihole-FTL as running:

*** [ 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 Mon 2026-02-16 19:32:17 CET; 21min ago
   Main PID: 8008 (pihole-FTL)
      Tasks: 18 (limit: 414)
        CPU: 18min 24.070s
     CGroup: /system.slice/pihole-FTL.service
             └─8008 /usr/bin/pihole-FTL -f

What's remarkable about the above output is that pihole-FTL has been running for just 21 minutes while consuming almost 18.5 minutes of CPU, i.e. it was indeed very busy during that time. On my system, the service status output shows CPU time as about 5% of running time.

You said you didn't reboot your Pi.
Did you restart Pi-hole on Mon 2026-02-16 around 19:32?

6

That warning is correct: pihole has a static IP address which lies inside its own DHCP IP range. I assumed it wasn’t important since it’s only a warning.

I’ve now updated the config so that I’m keeping the pihole’s static address, but I’ve shrunk the DHCP range so the pihole’s address is no longer included. So far nothing’s changed – still no DHCP lease, still no DNS.

There was one weird thing though: When I was switching my desktop’s network connection back to automatic, I accidentally kept a non-pihole DNS server’s IP address in the corresponding field. I could then connect via DHCP and get a lease. Once I removed the additional DNS server, that behavior stopped and I could not connect anymore.

Even with this DHCP lease I could not resolve domains, though.

7

Well, yes, I did reboot the pihole multiple times today, including around 19:32. What I meant with my original remark was that I did not reboot the machine before this behavior started, so a reboot can’t have caused things to break. Right now it seems like one day everything worked fine, the next it did not.

The high CPU load could be a result of the fact that it’s a very old, and therefore slow, Raspberry Pi. I have had the occasional diagnosis warning about the long-term load being larger than the number of processors, but there were never any crashes or the like.

That being said, I just watched the output of top for a bit, and pihole-FTL has been over 90% CPU load the entire time. I’m pretty sure that’s too high to be normal.

8

I've run Pi-hole on a Zero for quite some time, which has the same single core CPU as your model B, if at a higher clock speed. It had sporadic high loads, e.g. during gravity updates, but CPU to running time quota was still well below 10%.

There are no obvious pointers to misconfigurations in your debug log, so I've to speculate a bit.

Your debug log is void of any max concurrent or rate limit warnings, but they may have been flushed by a restart.

Your query database is about 330M in size - are you perhaps seeing a substantial increase in DNS requests lately that may contribute to a sustained high load?

Also, you mention:

If those requests were never followed by a reply, that would indicate that none of those upstream DNS servers has ever answered, i.e. they have been inaccessible or unresponsive.

If you run into DNS outages next time, you could check that with direct nslookups to those upstreams, e.g. nslookup ntp.ubuntu.com 46.182.19.48. If those would fail or be slow to resolve, you could consider to switch to other usptreams.

With no upstream replies, DNS requests will quickly pile up in Pi-hole, triggering a warning, and once upstreams start responding again, Pi-hole may be busy for a while working through that pile.

That exchange shows that Pi-hole correctly answered your client's DHCPDISCOVER with a DHCPOFFER, but the client did not follow that up with a DHCPREQUEST.

One possibility for that could be that your client chose to request a lease from another DHCP server that it received an offer from.

Your debug log doesn't show any DHCP servers on your Pi-hole machine's link, but it shows two IPv6 RAs: One from your main router, and another one presumably from a TP-Link device.
What kind of device is that?

On a side note:
Your debug log reports your model B to work with 429M of RAM.
That could suggest that you split 64M for GPU usage. If you are using your Pi as headless server, you could consider to decrease that to 16M, which could give your Pi-hole a little more headroom to handle large blocklists during gravity updates.

9

Thanks for all your help, I really appreciate it.

The 90% CPU load seem to have been an outlier. This morning it’s strictly below 10. Also, I don’t think there was an increase in DNS requests in the past days. At least I didn’t notice anything unusual.

The upstream DNS requests from the log were being answered correctly. It took more than 40 seconds, though.

Feb 16 19:54:22 dnsmasq[8008]: reply ntp.ubuntu.com is 185.125.190.58
Feb 16 19:54:22 dnsmasq[8008]: reply ntp.ubuntu.com is 91.189.91.157
Feb 16 19:54:22 dnsmasq[8008]: reply ntp.ubuntu.com is 185.125.190.56
Feb 16 19:54:22 dnsmasq[8008]: reply ntp.ubuntu.com is 185.125.190.57

When I tried the same request from the command line today, the results differed for each of my upstream servers:

  • 46.182.19.48 took 11 seconds to answer correctly. User and sys time were negligible, almost all time was spent waiting
  • 194.150.168.168 answered immediately with the correct IPs
  • 194.242.2.3 answered immediately with server can't find ntp.ubuntu.com: REFUSED

The TP-Link device you mention is a TD-W9980 wireless router. I’ve been using it exclusively as my wifi access point for a few years and never had any problems.
Sidenote: When I switched from my main router’s DHCP server to the pihole’s, the TP-Link stopped requesting/receiving IPv4 addresses. This never caused any problems, though.

P.S.: Just reduced my GPU memory down to 16 MB :slight_smile:

10

It would seem that out of your three upstreams, only 194.150.168.168 is reliably operational. This could explain your observation, as far as failing DNS resolution is concerned, and perhaps it may at least have contributed to your DHCP issues.

Digitalcourage's DNS server (46.182.19.48) unfortunately is often overloaded, and it would seem that Mullvad's DNS server (194.242.2.3) is not accepting any DNS requests. And as adblock.dns.mullvad.net no longer resolves, it would seem they may have retired their public DNS servers.

You should remove those two from your Pi-hole's upstream DNS servers.

Have you been picking them mainly for privacy reasons?
Then you may consider to run unbound as your own recursive resolver instead of entrusting your DNS data to a public one, see unbound - Pi-hole documentation.

11

Well, the pihole is running again, but only because I cheated. After spending way too much time on this issue and starting to run behind with everything else, I decided to nuke the old system from orbit and set up a new one from scratch. Now I’m running Trixie, pihole serves DNS and DHCP requests like a charm, and I’ll probably never find out what went wrong with the old installation.

I did keep an image of the old system, though. Let me know if you’re interested in really boring detective work … :slight_smile:

Thanks again for your help, it’s much appreciated