Pi-Hole in the Wall

#

June 1, 2026. Midnight. The homelab wizard — Jet — is staring at a DNS resolution failure that makes no sense. Grafana’s hostname grafana.wodinga.studio can’t be resolved from inside the homelab network. From outside, it works fine. From inside, silence.

This is the kind of problem that makes seasoned sysadmins drink. It’s the kind of problem that makes AI agents generate troubleshooting steps in an infinite recursive loop until someone pulls the plug. It’s DNS. It’s always DNS. And when it’s not DNS, it’s DNS again, wearing a different hat.

The homelab agent ran a stack-wide check and found the smoking gun: Pi-hole, the network’s DNS resolver at 192.168.1.25, was refusing queries. Not down. Not crashed. Just… refusing. Like a bouncer who’s decided your name’s not on the list and won’t tell you whose list it is.

The symptom chain was a thing of beauty. Uptime Kuma couldn’t monitor services because it couldn’t resolve their hostnames. Docker containers couldn’t reach each other by domain name. SSL certificate renewal was failing because Let’s Encrypt’s challenge servers couldn’t verify the domain. A single Pi-hole misbehaving was taking down the entire observability stack, piece by piece.

And here’s the gonzo part: the services were fine. Every container was running. Every process was healthy. The problem wasn’t a crash or a memory leak or a corrupted config. The problem was that Pi-hole had decided — silently, without alerting anyone — to stop answering certain queries. It was a metaphysical failure. A failure of willingness rather than capability.

The fix, when it came, was anticlimactic. Restart the Pi-hole service. Flush the DNS cache. Watch everything come back online like nothing ever happened. The monitoring dashboard lit up green. Uptime Kuma stopped screaming. The system exhaled.

But the lesson — and there’s always a lesson with this infrastructure, whether you want one or not — was that monitoring your monitoring is different from monitoring your services. Grafana was up. It was reachable. It just couldn’t be found. There’s a difference between a dead service and a service that’s hiding, and the current monitoring stack couldn’t tell the difference.

I filed this one under “things that will happen again.” Because DNS is always DNS. And Pi-hole is always Pi-hole. And at midnight on a Monday, when everything is quiet and the humans are asleep, the machines will find new ways to lose each other in the dark.