Auditing Your Own Infra and Finding the Thing You Forgot

The traefik-selfhosted README ends with a single sentence, almost an afterthought after a full page of TLS and networking detail: "Note that traefik.nissaar.com — the host in the ping and api router labels — does not currently resolve, so the dashboard and healthcheck are unreachable." Nothing failed to trigger that sentence being written. It was found by looking, on purpose, for no reason other than that it hadn't been checked in a while.

The config side was correct the whole time. Nobody had checked the DNS side against it.

Why this specific gap is invisible by default

Every new service on this stack needs two independent things to actually work: a Traefik router (handled almost automatically by the defaultRule convention covered earlier in this series) and a Cloudflare DNS record (which is never automatic — nothing in this stack creates DNS records on a container's behalf). traefik.nissaar.com got the first half. Whether it ever got the second half is a completely separate question that the router configuration itself has no way to answer.

That asymmetry is what makes the gap silent rather than loud. A router with no matching DNS record doesn't produce an error anywhere Traefik logs to — Traefik doesn't know or care whether the hostname it's configured to match resolves for anyone. There's no failed health check, because a health check needs a resolvable target to fail against; here, the request never leaves the querying machine in the first place. curl https://traefik.nissaar.com just times out at the DNS resolution step, indistinguishable from a typo, a network problem, or nothing being wrong at all until you specifically go looking.

What finding it actually took

Not a monitoring alert, not a user report — a manual pass, comparing what the router labels in docker-compose.yml claim as hostnames against what Cloudflare's DNS panel actually lists. That's a five-minute exercise for a homelab with a handful of services. It doesn't scale as an ongoing practice by memory alone, but it doesn't need sophisticated tooling either — dig +short <every hostname referenced anywhere in the repo> against the list of A/CNAME records in the zone would have caught this in seconds, run periodically rather than never.

The habit worth building

This is a narrow instance of a broader, boring, easy-to-skip practice: periodically checking your own infrastructure's claims about itself against its actual observable state, without waiting for an incident to force the comparison. The router label claimed a working hostname. The claim was false, and had presumably been false since whenever that label was written — dashboards and healthchecks tend to go unused for stretches, especially on a single-operator homelab, which is exactly the condition under which a stale reference like this survives unnoticed.

None of this needed new tooling, new alerting, or new infrastructure. It needed someone to read every hostname mentioned in a router label and go check whether it resolves — the same kind of pass this whole series has been an example of, applied one more time, to DNS instead of TLS modes or network subnets or key permissions. The value of periodically auditing your own setup isn't that it always finds something dramatic. Most of the time it finds nothing, or it finds exactly this: one dead reference, cheap to fix once you know it's there, invisible for as long as nobody looks.

Series: The Self-Hosting Stack. This closes out the series — Traefik's TLS termination, its socket proxy, its network segmentation, its zero-config discovery, and the SOPS-backed secrets and deploy-key model behind the stack it fronts.