From a803eda2c04f7fab8df15de031a17cd979d25a64 Mon Sep 17 00:00:00 2001 From: CodeGit Date: Fri, 4 Sep 2026 10:20:17 +0100 Subject: [PATCH] docs: fix podinfo/hello-app CNAME target to match actual DNS pattern An earlier commit (22acad8) pointed these at git.boglabob.com under the assumption it was a canonical alias target for the server. Checking the real zone file shows every other hostname (git, photos, music, etc.) is a CNAME straight to the bare apex boglabob.com instead - git.boglabob.com isn't special, just one more independent CNAME. Fix podinfo/hello-app to match. Co-Authored-By: Claude Sonnet 5 Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B --- docs/03-flux.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/docs/03-flux.md b/docs/03-flux.md index b6cf8e6..980b683 100644 --- a/docs/03-flux.md +++ b/docs/03-flux.md @@ -438,14 +438,18 @@ headlamp and the k3s API server are deliberately **not** exposed this way; step 5 above and `docs/04-tofu.md` step 5 cover why and how to reach them instead. -Two DNS records, as CNAMEs pointed at `git.boglabob.com` rather than -duplicating its IP directly — CNAME means "this name is an alias for that -one," so there's one place (that record) to update if the underlying IP -ever changes, instead of several: +Two DNS records, as CNAMEs pointed at the bare apex `boglabob.com` — the +zone's one actual A record — rather than duplicating its IP directly. +This matches every other hostname on this server (`git`, `photos`, +`music`, etc. are all `CNAME`s to the apex too); it's *not* about +`git.boglabob.com` being some special canonical host to alias through — +an earlier version of this doc got that wrong, pointing these two at +`git.boglabob.com` instead of the apex, inconsistent with every other +record in the zone: ``` -podinfo.boglabob.com CNAME git.boglabob.com -hello.boglabob.com CNAME git.boglabob.com +podinfo.boglabob.com CNAME boglabob.com +hello.boglabob.com CNAME boglabob.com ``` Then in Caddy's own config, using the VM's pinned IP from stage 2: