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.
34 lines
2.2 KiB
Markdown
34 lines
2.2 KiB
Markdown
# 🌐 DNS Naming Model
|
|
|
|
> [!NOTE]
|
|
> Two internal DNS zones, mirroring each other structurally but serving completely different traffic — deliberately never conflated.
|
|
|
|
```mermaid
|
|
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/), [`stacks/platform/caddy-internal/`](../stacks/platform/caddy-internal/)
|