docs(hermes,dns): document the new internal-only exposure surface

Post-change doc reconciliation for the hermes vhosts + DNS deletion batch:

- Hermes-Dashboard.md: access is now the hermesadmin.franksdank.cloud vhost
  (direct Caddy proxy to 192.168.0.143:9119, no guard chain — exempt because the
  dashboard enforces its own basic-auth login), plus the raw LAN port. The old
  text claimed an Authentik-guarded public vhost, which was decommissioned.
- Hermes-WebUI.md: description updated — the webui is now also reachable via the
  unguarded hermes.franksdank.cloud vhost (its own password auth is the gate).
- LAN-DNS.md: "add a name in two places" corrected to a two-or-three-step
  decision; internal-only names (prometheus/loki/grafana/seerr) deliberately get
  no public A record and resolve on the LAN only, and DNS-01 issuance is
  unaffected because the challenge is a TXT record in the same zone.
- Seerr.md: DNS row corrected — addn-hosts only since 2026-09-02; NXDOMAIN on WAN.
- hermes-dashboard.container: unit comment no longer claims Authentik termination.

No behavior change in this commit; tests 233/233 green (docs-completeness seam included).
This commit is contained in:
Frank
2026-09-02 18:57:38 -07:00
parent 1e4daaa24a
commit 1e491fa69f
5 changed files with 38 additions and 12 deletions
@@ -10,7 +10,7 @@ See [[Caddy]] for the reverse proxy that serves the names, and [[Network Archite
|-----------|-------|------|
| Pi-hole | Dankclaw quadlet (`dankclaw/pihole/`) | Answers the flat service names for LAN clients |
| SURFboard G36 | 192.168.0.1 | Hands dnsmasq to clients as the DHCP DNS server |
| Porkbun | Registrar for `franksdank.cloud` | Answers the same names for the WAN |
| Porkbun | Registrar for `franksdank.cloud` | Answers the **public** names for the WAN; internal-only names have no public record and resolve only on the LAN |
| Caddy | Dankclaw (192.168.0.143:443) | Serves every name over HTTPS |
## How a name reaches a client
@@ -52,12 +52,24 @@ Pi-hole FTL is a dnsmasq fork. It serves the same `addn-hosts` file the retired
- **Web UI:** `pihole.franksdank.cloud` (Caddy vhost → 8083), family login
- **Deploy + restart after a change:** `./scripts/deploy-pihole-quadlet.sh dankclaw`
Add a new service name in two places:
Adding a new service name is a two-or-three step decision — decide the exposure
first, because it decides whether the name gets a public record at all:
1. `dankclaw/pihole/addn-hosts` — `192.168.0.143 <name>.franksdank.cloud`
2. Porkbun — A record `<name> 71.227.227.172` (so WAN clients and the DNS-01 challenge work)
1. `dankclaw/pihole/addn-hosts` — `192.168.0.143 <name>.franksdank.cloud` (always).
2. **Public** name only: Porkbun A record `<name> 71.227.227.172`, so WAN clients
resolve it too. An **internal-only** name deliberately gets no public record:
the query falls through to the upstream resolvers, which answer NXDOMAIN for
`franksdank.cloud` subdomains, so off-LAN clients cannot reach the vhost at all.
3. Add the vhost to [[Caddy]] and run `./scripts/deploy.sh dankclaw`. See
[[Pi-hole]] for the full configuration.
Then add the vhost to [[Caddy]] and run `./scripts/deploy.sh dankclaw`. See [[Pi-hole]] for the full configuration.
Internal-only names as of 2026-09-02: `prometheus.`, `loki.`, `grafana.`
(observability) and `seerr.` (the `*arr` request front-end). Their public A
records were deleted from the Porkbun zone that day; each is still served by
Caddy on the same name, so LAN clients see no change and WAN clients get
NXDOMAIN. DNS-01 issuance is unaffected — Caddy's challenge is a TXT record in
the same zone and needs no A record at all, which is why an internal-only vhost
still gets a real Let's Encrypt certificate.
## G36 router DNS hand-off