Self-Hosting / Networking

Pi-hole — Reviewed Mid-Deployment on a Real Home Network

Pi-hole's pitch is simple. A small self-hosted DNS server that blocks ads and trackers for every device on your network, with no per-device app or browser extension. I deployed it on a dedicated container to supplement my router's own DNS filtering. This is what that process actually looked like, including a router-level gotcha and a finding about container health checks that changed how I evaluate "is this working".

What this is, and what it is not. This deployment is paused before going fully live. Deliberately, for reasons below, not because anything failed. There is no "months of daily use" verdict here yet. What follows is real hands-on deployment experience, a genuine architectural gotcha if you run a UniFi network or any router with its own DNS filtering, and an honest account of a problem this evaluation uncovered. I will follow up once it carries production DNS traffic.

What Pi-hole actually is (and isn't)

Pi-hole is a DNS server that answers most queries normally and returns a blocked response for domains on its blocklists. Mostly ad networks and trackers, from large, actively maintained community lists. Same style of list a browser extension like uBlock Origin uses, applied at the network's DNS layer instead of per-browser. Point your router's DHCP-assigned DNS server at it and every device on the network gets ad and tracker blocking with nothing installed. Phones, smart TVs and IoT devices that could never run a browser extension included.

Why not just use my router's built-in filtering?

Most consumer and prosumer routers with a content-filtering feature do something different, UniFi included. They do category-based filtering. Block "Adult Content", block "Malware", a fixed list of buckets. That is not general ad and tracker blocking. Three real differences matter:

Coverage. A router's content-filter categories do not touch ad networks or trackers at all. That is not what the feature is for. Pi-hole's blocklists are curated for exactly that traffic.
Visibility. Pi-hole gives you a real dashboard. Every query, every client, what got blocked and why, over time. A router's content filter is a blunt on/off toggle per category with no query-level log at all.
Control. Custom block and allow lists. Per-client rules. The ability to see exactly why something got blocked when a site breaks. A fixed category system gives you none of that.

They are not really competing products. A router's content filter aims at parental-control category blocking. Pi-hole aims at ad and tracker suppression with real visibility. Want both and you have to think about how they coexist, which turned out to be the first real decision point here.

The deployment itself: straightforward

Pi-hole's Docker image is genuinely easy to stand up. A single container. Host networking, so it binds DNS's standard ports directly. A web admin panel on the usual HTTP and HTTPS ports. No complex config to get it answering DNS queries correctly from its own local network segment. If the story ended there this would be a short, boring, entirely positive review.

The real gotcha: your router might already own port 53, silently

BE WARNED: if your router has its own DNS-based content filtering enabled, pointing a client's DNS at Pi-hole may not work, and the failure mode is confusing. On a UniFi network, enabling DNS filtering on a network transparently intercepts all outbound port-53 traffic on it and redirects that to the gateway. Whatever DNS server a client thinks it is using. I confirmed this with a packet-level test. ICMP and plain HTTP to the Pi-hole box worked fine, so it was not a routing or firewall problem in general. DNS queries timed out completely, both UDP and TCP on port 53, while Pi-hole's own resolver was correctly bound and listening on every interface. The router was eating the DNS traffic before it reached the box.

Know this before you spend an hour debugging Pi-hole itself. Nothing about Pi-hole is broken in this scenario. It never sees the query. If clients on a UniFi or similar network are not resolving through Pi-hole despite correct DHCP and DNS settings, check whether the router's own DNS filtering is enabled on that segment first. Before you assume a Pi-hole-side misconfiguration.

The coexistence question, if you also use built-in content filtering for something real

If your router's content filtering already does real work, do not disable it as a side effect of adding Pi-hole. Parental controls on a specific network, for instance. Make that decision deliberately rather than stumbling into it. You have three options. Run Pi-hole only on the segments that do not depend on the router's filtering. Replace the router's filtering with something Pi-hole-based everywhere, which is more consistent and more work. Or hold off until you have decided. There is no universally correct answer. It depends on what the existing filtering is protecting.

Why this deployment is currently paused

Past the coexistence question above, I am holding off on redirecting network DNS to Pi-hole until some unrelated topology changes land. New switching hardware, some interfaces getting re-cabled. Pi-hole becomes a single point of failure for DNS on whatever segment it serves. I want that sitting on settled infrastructure, not infrastructure about to change out from under it. Nothing about the pause reflects on Pi-hole itself.

A finding this review itself surfaced: don't trust "the container is running"

BE WARNED: a container reporting healthy uptime is not the same claim as "this service works". While auditing this deployment I checked Docker's own health-check status on the Pi-hole container. I had not looked at it before, since the box sat quietly with no complaints. It had been reporting unhealthy for essentially its entire uptime, failing its own internal DNS self-check the whole time. The container process was alive and had never crashed or restarted. It just could not reliably resolve anything through its own upstream. A plain "is it running" check never catches that.

The lesson generalizes past Pi-hole. A container that is up, has not crashed, and throws no errors in its logs can still be functionally broken. Only its own health check will tell you, if it has one and if you look. docker ps showing a container as running is a much weaker claim than it feels like. Check docker inspect for the health status, not just whether the process is alive.

Verdict (so far)

Pi-hole's value proposition holds up on paper and in the parts I have tested directly. It does something a router's content filter does not, real ad and tracker blocking with real visibility. It is simple to deploy. It is light enough to justify a small dedicated container. This evaluation also turned up two real, non-obvious problems before it ever went live. A router that silently eats the exact traffic Pi-hole needs to see. A container that looked fine by every surface signal while its own health check said otherwise the entire time. Both are fixable. Neither is a knock against Pi-hole's design. They are exactly what "just deploy it and it'll work" advice skips. Full verdict once it carries real traffic, after the network topology work it is waiting on.