Can't use pihole at all. All DNS lookups are refused

Setup

ISP router has DHCP with a static reservation for my internal router, which is attached via ethernet to the WAN port, and is the only thing connected to it.
From now on, whenever I say “router” I mean the internal router, the ISP router is basically just forwarding.

Internal router has DHCP with static reservation for PiHole on 192.168.X.Y
Internal router has DNS set to PiHole @ 192.168.X.Y

Expected Behaviour:

I would expect DNS to be resolved to an IP, instead I only get “REFUSED” and nothing works (can’t connect or resolve anything).

For the purpose of this thread let’s use this config:

  • Raspbian-lite (fresh install)
  • Raspberry 1B
  • Bare metal from apt

Actual Behaviour:

Nothing works. All DNS queries are “REFUSED”

I see a lot of: UDP DNS reply: Timeout - no response from upstream DNS server, Connection error: TCP connection failed while receiving payload length from upstream, WARNING: Connection error (2606:4700:4700::1111#53): failed to send UDP request (Network unreachable)

If go in the router and set Cloudflare (1.1.1.1) or Google (8.8.8.8) as DNS from there (instead of the PiHole), everything works, so it seems to be an internal issue and not related to the router, ISP, or DNS provider.

I have re-installed several times and this is based on a fresh install (Raspbian + apt). The same happens on a “clean” docker install, where I have deleted all folders, volumes, networks and pulled a fresh image.
I have also reset my router several times to make sure that no useless settings were in place and I do think there’s nothing weird in the router itself as evertying works when I switch to DNSs other that PiHoles.

From inside the raspbian system

  • with router DNS pointing to cloudflare:
    dig pi-hole.net => NOERROR
    dig pi-hole.net @127.0.0.1 -p 53 => NOERROR

  • with router DNS pointing to it (192.168.X.Y)
    dig pi-hole.net => timed out
    dig pi-hole.net @1.1.1.1 => timed out

I’m not sure if this has anything to do with it but I’ve disabled IPv6 on my router, and if I do enable it (with Dynamic IP SLAAC/DHCPv6) and point the DNS to cloudflare’s IPv6, then everything works but it just bypasses the PiHole (I can curl doubleclick.com), just as if I were to replace the router’s DNSs with cloudflare’s.

Debug Token:

In order to upload this log, I had to timely switch the DNS in my router to 1.1.1.1 just before pressing y for curl

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

Please help out, I’ve lost a gigantic quantity of time trying to make this work on my own and scouring the internet for similar cases before opening this thread.

You have a connectivity problem between the Pi and the network:

-----tail of pihole.log------
   Nov 29 17:40:47 dnsmasq[731]: forwarded discourse.pi-hole.net to 1.0.0.1
   Nov 29 17:40:47 dnsmasq[731]: failed to send UDP request: Network unreachable
   Nov 29 17:40:47 dnsmasq[731]: failed to send UDP request: Network unreachable
-----tail of FTL.log------
   2025-11-29 17:37:10.008 GMT [731M] WARNING: Connection error (2606:4700:4700::1111#53): failed to send UDP request (Network unreachable)
   2025-11-29 17:37:16.000 GMT [731M] WARNING: Connection error (2606:4700:4700::1111#53): failed to send UDP request (Network unreachable)

The PI is attached via ethernet to the router, and if I switch DNS to something else I’m able to connect to the outside (eg: curl pi-hole.net)

Also I was able to upload the log from there, by switching DNS before hitting send.

The things I’ve thought of are:

  • Router rate-limiting: maybe the router sees a lot of requests from one client and shuts it off… But I can’t find any settings that do that or evidence of it happening in the logs
  • DNS providers/authorities soft-banning my IP, but then it wouldn’t work if I switched them again in the router settings

I agree with you that it seems to be external to the application or hardware, but I can’t understand what the hell it is or how to debug it.

The debug log shows your machine has connectivity issues.

Using 192.168.10.101 or 8.8.8.8 is failing:

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] wp-stats.com is NOERROR on lo (127.0.0.1)
[✗] Failed to resolve wp-stats.com on eth0 (192.168.10.101)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (8.8.8.8)

Do you have a firewall or something else blocking the access?

Just to add to the mix. I have 2 RPi systems. One of them would only work with wi-fi. For whatever reason I could not get ethernet to work. Tried swapping SD cards, different cables, different network ports on the router. Nothing worked.

As it was a new system, and I was using the same OS and such on both systems, I reached out to the supplier. Got shipped a replacement, plugged in the same SD I had been using, and ethernet worked like a charm. Not saying this is your system’s issue, just something to check into.

1 Like

Switch which DNS? The Pi is already using the router as nameserver. And, the debug log test for DNS resolution from Google uses the IP, and with the IP no DNS server is required.

This points to something on the network that may be blocking DNS traffic.

1 Like

I meant switching DNS settings in the router.

If I use the Pi address as DNS provider everything stops suddenly. The exact moment I switch back to cloudflare (or anything else) in the router settings it goes back up.

I am getting the feeling that is my intermediary router that can’t handle a single client spamming all those requests, either blocks it for “safety” reasons that I can’t control, or just hangs.

I have turned off the firewall.

Your debug log shows your router is advertising itself as DNS server, not Pi-hole's IP:

  router: 192.168.10.1
  dns-server: 192.168.10.1
1 Like

Ok. That’s weird.

In the router I have two settings:

  • Global DNS, this setting allows a forced override for all clients
  • DHCP also has two DNS fields

I’m pretty sure I have tried all combinations (both off, one on and the other off, both on).

Do you think I should leave the global setting as is, and instead only use the DHCP DNS field? This test was based on the “global” setting pointing to the Pi while the DNS field in the DHCP config was blank.

Yes.

Each router has different settings, but I think this is the most common usage and it will probably work in your case.

That was it. I can’t believe that single setting had me running in circles for days. I still don’t understand why if I point that to the Pi everything breaks, but at this point I’m not sure I want to figure it out… I’ll mark it as solved, if anyone has insights on why that would be the case please enlighten me!