thesabear
41a6f569b4
Mermaid diagrams up front, GFM alert callouts for key decisions and gotchas, tables instead of bullet walls - replaces plain prose with the visual template established for security-monitoring.md.
2.2 KiB
🌐 DNS Naming Model
Note
Two internal DNS zones, mirroring each other structurally but serving completely different traffic — deliberately never conflated.
flowchart LR
Browser["Browser / User"] -->|Zone A| Edge["User-facing reverse proxy<br/>mTLS + SSO enforced"]
Service["Another service"] -->|Zone B| Internal["Internal reverse proxy<br/>trusted-IP allowlist"]
Public["Public internet"] -.bypasses both zones.-> EdgeFW["Edge firewall's own<br/>public reverse proxy"]
Edge --> App["App"]
Internal --> App
EdgeFW --> PublicApp["The one genuinely<br/>public-facing app"]
| Zone | Serves | Enforcement |
|---|---|---|
| Browser-facing zone | Users/browsers, via the user-facing reverse proxy | Mutual TLS + SSO enforced at the edge |
| Service-to-service zone | App-to-app traffic (webhooks, API integrations) | Trusted-IP allowlist, no mTLS |
Most apps get one hostname per zone, resolving to a different front door depending on who's asking. The two zones aren't perfectly symmetric at any given moment — a handful of apps exist in only one, which is expected: not every stack needs both zones, driven by actual need rather than blanket symmetry.
Tip
The public exception: one app is genuinely public-facing, routed directly through the edge firewall's own reverse-proxy package, with zero presence in either internal zone. Apps meant for the public internet skip the internal DNS model entirely rather than getting a redundant third record.
Caught during a later audit
Important
A documentation audit caught real drift: an older note claimed an external DNS forwarder was configured for anything outside the two internal zones. Live verification found no such forwarder actually in place — unresolved queries forward to the edge firewall and a couple of standard public resolvers instead, and internal clients are blocked from using any other resolver directly. The takeaway: documentation drift gets caught by checking live state, not by trusting a prior note was still accurate.
Related stacks: stacks/platform/caddy/, stacks/platform/caddy-internal/