capitalize headings

docs/dns-naming.md

@@ -11,14 +11,14 @@
 | **Depends on** | Nothing upstream for internal resolution — it's the root of trust for internal naming |
 | **Depended on by** | Every system in this repo that resolves a hostname — which is effectively all of them |
 
-## Why self-hosted DNS at all
+## Why Self-hosted DNS At All
 
 A homelab this size could get away with a shared hosts file or a single flat zone. Two things specifically ruled that out:
 
 1. **The two-zone trust model needs a real answer to "which front door am I behind."** Splitting traffic into a mutual-TLS-enforced browser zone and a lighter trusted-IP internal zone (see [`docs/firewall-and-network.md`](firewall-and-network.md)) only works if something authoritative decides, per-hostname, which zone a request lands in. A hosts file can't do that at scale across a dozen-plus hosts; a real DNS server with two real zones can.
 2. **Every other system needs one source of truth for internal names.** The secrets platform issues a certificate to the DNS server's own admin interface (see below); the orchestration engine resolves every fleet host by name before it can SSH anywhere; the observability pipeline ships DNS query logs as their own dedicated stream. Hand-rolling internal name resolution per-app would mean N inconsistent answers instead of one.
 
-## The two zones
+## The Two Zones
 
 ![Anything on the LAN queries Technitium, which either answers from one of its two authoritative internal zones — browser-facing, routing to the user-facing reverse proxy with mTLS+SSO, or app-to-app, routing to the internal reverse proxy with a trusted-IP bypass — or forwards unresolved queries upstream to the edge firewall and a public resolver](../assets/dns-naming-zones.svg)
 
@@ -46,12 +46,12 @@ Same result for `loki` and `wazuh-indexer` (caddy-zone only), and the reverse fo
 | App-to-app | `NXDOMAIN` |
 | Browser-facing | `NXDOMAIN` |
 
-## DNS as an enforced boundary, not just a convenience
+## DNS As An Enforced Boundary, Not Just a Convenience
 
 > [!IMPORTANT]
 > Every host on the LAN has its resolver pointed at this one internal DNS server — and that's enforced, not just configured. Direct outbound DNS queries to anywhere else (a public resolver, another host acting as its own resolver) are blocked at the firewall level, covered in [`docs/firewall-and-network.md`](firewall-and-network.md). This closes a real bypass: without it, any host could sidestep the internal zones entirely by just asking a public resolver instead, which would quietly undermine the whole two-zone trust model above. DNS enforcement is what makes the rest of this architecture actually load-bearing instead of advisory.
 
-## Two things live-checking found the documentation had wrong
+## Two Things Live-checking Found The Documentation Had Wrong
 
 Trusting the KB without re-checking it against the running server would have kept both of these wrong indefinitely — so both got checked directly against the real config and the real zone data, not taken on the KB's word:
 
@@ -68,7 +68,7 @@ $ strings /etc/dns/dns.config | grep -E '^\d+\.\d+\.\d+\.\d+$'
 
 Neither is a security problem — the reverse zone being broader than described doesn't leak anything, and the missing forwarder just means one less redundant upstream. What they have in common is more useful than either fact alone: documentation describing what a system does isn't the same as verifying it, and the gap between the two doesn't announce itself until something actually goes and checks.
 
-## Where DNS shows up in every other system
+## Where DNS Shows Up In Every Other System
 
 DNS isn't a standalone concern in this fleet — it's a dependency almost everything else sits on top of: