Pi-hole Installed but Clients Get No DNS Response

Confirm Pi-hole FTL reports a running state

Use the documented pihole status probe to confirm the service state before any deeper check. Run it in the environment where Pi-hole executes: on the bare-metal host directly, or inside the Pi-hole container/runtime using the deployment's documented access method — never as a container command run on the Docker host shell. A stopped FTL explains every downstream symptom and must be handled before upstream, port, or client reasoning begins.[1]

pihole status

Send one direct query to Pi-hole and one past it

Run two probes in two different environments. First, from a client, query a test name at the Pi-hole address: this proves whether the client can reach Pi-hole. Second, from the Pi-hole runtime itself (the bare-metal host, or inside the Pi-hole container/runtime using the deployment's documented access method), query the same name at a configured upstream: this proves whether Pi-hole can reach the upstream. If the client-side Pi-hole query answers, the fault is in what clients use; if the client query is silent but the runtime-side upstream query answers, the fault is at the Pi-hole host level; if the runtime-side upstream query is also silent, the fault is upstream or in basic outbound connectivity.[1][4]

dig @<pihole-ip> <test-name>

dig @<upstream-ip> <test-name>

Do not change upstreams, resolvers, or DHCP before classification

Do not edit the upstream list, disable stub resolvers, or change DHCP-advertised DNS before the probes separate an FTL outage, a port conflict, an upstream failure, and a client bypass. A change made before classification can move every client at once without fixing the actual boundary.[1]

1. Establish whether FTL DNS is running

Confirm through the documented status surface whether pihole-FTL is running and serving DNS. A stopped service is the first branch and exits the deeper tree; only a running service continues to query-level reasoning.[1]

2. Compare the client-to-Pi-hole probe against the Pi-hole-runtime upstream probe

Run the two probes in their separate environments. The client-to-Pi-hole query proves the client can reach Pi-hole. The Pi-hole-runtime upstream query (run on the bare-metal host, or inside the Pi-hole container/runtime using the deployment's documented access method) proves Pi-hole can reach its upstream. Client queries answering while clients still fail points at client configuration; the client probe silent while the runtime upstream probe answers points at the Pi-hole host level; the runtime upstream probe also silent points upstream or at basic outbound connectivity.[1][4]

3. Check who owns port 53 on the Pi-hole host

When Pi-hole is silent but the upstream answers, check which process holds TCP and UDP port 53 on the host. The documented systemd-resolved case applies specifically to hosts running that stub resolver (notably Ubuntu and Fedora derivatives, including Docker hosts): its stub listener prevents Pi-hole from binding port 53. Do not generalize this branch to hosts without that resolver.[2]

4. Verify the resolver the failing client actually uses

When Pi-hole answers direct queries but clients still fail, read the effective resolver on a failing client and the DHCP-advertised DNS before changing anything. The official Post-Install page expects DHCP clients to use Pi-hole, with the built-in DHCP server or manual per-device setup as documented alternatives; prefer this read-only verification over editing DHCP first.[3]

Stopped FTL: return the DNS service through the deployment's documented control

If the status probe shows the service stopped, start it through the deployment's documented service control (system service on bare metal, container restart policy on Docker) and re-run the status probe plus one direct query. This corrects only a stopped service; it does not change upstreams, ports, or clients.[1]

Stale cache behavior: flush and reload the FTL DNS cache

Where the failure follows list or cache changes rather than a stopped service, flush and reload the FTL DNS cache with the documented pihole reloaddns subcommand, run in the environment where Pi-hole executes (on the bare-metal host, or inside the Pi-hole container/runtime using the deployment's documented access method). Note its documented limit: it does not re-read configuration files, so it cannot apply upstream or structural edits.[1]

pihole reloaddns

Broken upstream path: correct the configured upstreams

Replace the unreachable or incorrect upstream servers with working ones chosen from the documented upstream options, using the deployment's documented configuration surface (the FTL configuration reference documents the v6 config file format; apply edits through that surface), then verify with a Pi-hole-runtime upstream query followed by a client query to Pi-hole. Apply any required service handling only through the deployment's documented service control.[4][5][1]

Stub-resolver conflict: free port 53 per the documented stub procedure

Only on hosts running the documented systemd-resolved stub listener that prevents Pi-hole from binding port 53: disable the stub listener with the documented drop-in, repoint the host resolver symlink as documented, and restart the stub service. This branch never applies to hosts without that resolver.[2]

sudo sh -c 'mkdir -p /etc/systemd/resolved.conf.d && printf "[Resolve]\nDNSStubListener=no\n" | tee /etc/systemd/resolved.conf.d/no-stub.conf'

sudo sh -c 'rm -f /etc/resolv.conf && ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf'

systemctl restart systemd-resolved

Client bypass: direct clients at Pi-hole through documented setup

After read-only proof that failing clients use another resolver, direct them at Pi-hole using the documented Post-Install options in order: configure the router so DHCP clients use Pi-hole, or enable the built-in DHCP server after disabling DHCP on the router, or set individual devices manually as a last resort.[3]

If no branch matches: preserve the evidence

Record the installed Pi-hole release line, the FTL status output, the paired direct-probe results, the port 53 ownership, the effective client resolver and DHCP advertisement, and the configured upstreams. Send the sanitized evidence to the operator; the official references describe no procedure for a failure outside these branches.[1]