docs: add security/hardening deep-dive write-ups

Secrets & PKI, Secret Distribution Model, SSO & Identity,
Firewall & Network Segmentation, DNS Naming Model, and Security
Monitoring - the first batch of per-system write-ups linked from
the new README, sourced and sanitized from the internal KB.

docs/dns-naming.md

@@ -0,0 +1,23 @@
+# DNS Naming Model
+
+## Two zones, deliberately never conflated
+
+Internal DNS is authoritative for two zones that mirror each other structurally but serve different traffic:
+
+| 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), via the internal reverse proxy | Trusted-IP allowlist, no mTLS |
+
+Most apps get one hostname per zone, resolving to a different front door depending on who's asking — a browser gets the mTLS-enforced path, another service gets the lighter-weight internal path. The two zones aren't perfectly identical at any given moment; a handful of apps exist in only one zone rather than both, which is expected — not every stack needs both zones, driven by actual need rather than blanket symmetry.
+
+## The public exception
+
+One app is a deliberate exception to the whole two-zone model: it's genuinely public-facing, routed directly through the edge firewall's own reverse-proxy package, and has zero presence in either internal zone. Apps meant for the public internet skip the internal DNS model entirely rather than getting a third, redundant record.
+
+## Caught during a later audit
+
+A later documentation audit caught real drift from what had been assumed: an older note claimed an external DNS forwarder (a third-party provider) was configured for anything outside the two internal zones. Live verification found no such forwarder actually configured — 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 kept from that audit: documentation drift is caught by checking live state, not by assuming a prior note was still accurate.
+
+---
+Related stacks: [`stacks/platform/caddy/`](../stacks/platform/caddy/), [`stacks/platform/caddy-internal/`](../stacks/platform/caddy-internal/)