feat(dns): PiHole answers an explicit LAN name list, not a zone wildcard

Public names are proxied CNAMEs to the Cloudflare Tunnel since PR #156 and work from the LAN, so they should resolve publicly there too. Replace the address=/${BASE_DOMAIN}/ wildcard with explicit entries: the LAN-only names (derived from every controller:none HTTPRoute), gitea/nextcloud (off Cloudflare's 100 MB / 100 s limits), keycloak/auth, and the L4 VIPs. Add L0 check pihole-lan-names, mutation-tested. Correct docs that still described public names as CNAME to wan. and the cloudflared entrypoint comment. Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-11-08 19:51:49 -06:00
1 parent 020e736541
commit 8fe8d5df8a
@@ -17,6 +17,8 @@ outbound-only from the cluster (no router port forward, no hairpin, no split-DNS
 | `networkpolicy.yaml` | default-deny (single owner — not an app namespace) + Prometheus scrape allow + egress CNP: world 7844 tcp/udp and 443, the Gateway (`ingress` entity), and Gateway backends by `gateway-access=shared` minus the LAN-only namespaces. |
 | `servicemonitor.yaml`, `alerts.yaml` | Headless metrics Service + ServiceMonitor scraping :2000, and the two alerts, both written to fire (not go quiet) when their series vanish. |

-**Phase 1 only.** This component changes no live traffic: Cloudflare sends a hostname through the
-tunnel only when its DNS record is a CNAME to `<UUID>.cfargotunnel.com`, and nothing here creates
-one. Moving DNS (external-dns, Gateway annotations, Pi-hole/CoreDNS split horizon) is a later change.
+Cloudflare sends a hostname through the tunnel only when its DNS record is a proxied CNAME to
+`<UUID>.cfargotunnel.com`; nothing in this directory creates one. Those records are published by
+external-dns from the shared Gateway's target annotation (Phase 2, PR #156; see
+`platform/externaldns/README.md`). LAN resolution: `catalog/pihole.yaml` (explicit names only since
+2026-11-09), so public names reach Cloudflare from the LAN too.