Services

infra / planned

AdGuard DNS routing

Notes on how the wildcard DNS rewrite and the reverse proxy work together to route every internal hostname.

What it is

This isn't a service in its own right — it's the routing pattern that makes every internal hostname in this catalog work. Two pieces of infrastructure cooperate: AdGuard Home resolves the name, and Nginx Proxy Manager routes the request.

Why I run it this way

I wanted the cost of adding a new service to the catalog to be one entry in one place. Two-step adds (a DNS record and a proxy host) drift over time — half-deleted DNS entries that no longer match any proxy host, or proxy hosts pointed at hostnames that don't resolve. The wildcard collapses both.

How it works

The whole chain for a request to (say) homepage.lab:

  1. The browser asks DNS for homepage.lab.
  2. AdGuard Home has a single wildcard rewrite, *.lab → <NPM IP>. It returns that IP.
  3. The browser opens an HTTP connection to the NPM IP, sending Host: homepage.lab in the request.
  4. NPM matches the host header against its proxy host list and forwards to the upstream — in this case, my Homepage dashboard.

AdGuard resolves the name. NPM does the routing based on the host header. Both have to be configured for a .lab hostname to work — but thanks to the wildcard, AdGuard automatically covers any new .lab name without per-service edits. Only NPM needs a new entry per service.

Setup notes

Runbook