DNS Phase 4 COMPLETE: single zone — managed zone removed

After upgrading the Mac client 0.68.3 -> 0.71.3 (matching mgmt) and clearing
its NetBird resolver cache (netbird service restart), the managed-zone
deletion works: with 0 managed-zone records, the Mac resolves all
hubris.network names by forwarding to Technitium (192.168.8.2). iPhone
confirmed on cellular (no LAN path -> proves mesh-forward).

The first deletion "failure" was a misdiagnosis: the old 0.68.3 resolver
cache held stale answers and wouldn't clear on down/up (needs daemon
restart); the Mac's dual LAN+mesh paths muddied it. A direct
dig @100.122.255.254 of an unsynced name had shown forwarding working.

Done:
- Deleted all 23 NetBird managed-zone A-records.
- Removed the */10 dns-sync cron. Kept /opt/dns-sync/sync.py + token +
  pre-deletion backup as an emergency-restore tool only.

End state: Technitium is the single DNS source. Mesh peers forward to it
(Core route -> 192.168.8.0/24); LAN/household query it directly. No replica,
no sync. Requires mesh clients on 0.71.x+.

Docs: dns.md + 107-dns.md updated to single-source; subdomain recipe no
longer references the sync.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

containers/107-dns.md

@@ -24,14 +24,14 @@ Authoritative split-horizon DNS for `hubris.network` on the LAN/mesh, plus recur
 - API: `http://192.168.8.2:5380/api/...` (token via `/api/user/login`). Zone was built via the API.
 
 ## Who points here
-- **NetBird mesh peers:** resolve `hubris.network` via the **NetBird managed DNS zone** (kept in sync from this Technitium — see dns-sync below). This is **load-bearing**, not redundant: a Phase 4 test (2026-06-21) that deleted the managed zone broke resolution for mesh peers. The `home-lab-dns` nameserver group (`→ 192.168.8.2`, applied to all peers) shows `Available` but does **not** actually serve queries on the current client (Mac 0.68.3) — forwarding to the routed-LAN IP silently returns nothing. The 2026-06-21 route fix (added `Core` → `192.168.8.0/24`) restored service *connectivity* for roaming peers but did not change DNS-forwarding behavior.
+- **NetBird mesh peers:** resolve `hubris.network` by **forwarding to Technitium** via the `home-lab-dns` nameserver group (`→ 192.168.8.2`, domain `hubris.network`, applied to all peers). The **NetBird managed DNS zone was removed 2026-06-21 (Phase 4)** — Technitium is now the single DNS source for the mesh too. This works because: (a) roaming peers (`Core`) have the `192.168.8.0/24` route to reach `192.168.8.2` (added 2026-06-21), and (b) clients run NetBird **0.71.x** — on the old 0.68.3 client, forwarding reported `Available` but didn't serve queries, and the resolver cache (`100.122.255.254`) wouldn't clear on `down/up`; a `netbird service restart` (or app toggle) clears it. See [dns.md changelog 2026-06-21](../infrastructure/dns.md).
 - **Homelab DHCP clients:** Technitium's own DHCP scope hands out `192.168.8.2` as the DNS server for `192.168.8.x` leases (see DHCP section below).
 - **Plain LAN clients (`192.168.178.x`):** Fritz!Box DHCP still hands out Fritz!Box itself (`192.168.178.1`) as DNS, **but** the Fritz!Box now *forwards* upstream to Technitium — DNSv4 server set to `192.168.8.2` (Internet → Filter → DNS Server, 2026-06-17). So household clients get split-horizon `*.hubris.network` answers via Fritz!Box→Technitium, with **no NetBird dependency**. (This is the change that decoupled the on-prem tier from the mesh — see [dns.md](../infrastructure/dns.md) 2026-06-17.)
 
-## dns-sync (Technitium = authoring source)
-`/opt/dns-sync/sync.py` (cron `*/10`, logs `/var/log/dns-sync.log`) reconciles this zone's named A-records → the NetBird managed DNS zone via the NetBird API (`/api/dns/zones/{id}/records`). Token at `/opt/dns-sync/netbird-token` (mode 600; source of truth in sops `secrets/netbird-pat.yaml`). **Edit DNS only here**; the sync propagates to the mesh. It deletes NetBird records absent from Technitium. Tracked: [scripts/dns-sync.py](../scripts/dns-sync.py).
+## dns-sync (RETIRED 2026-06-21 — Phase 4 complete)
+**The managed-zone sync is no longer scheduled.** `/opt/dns-sync/sync.py` reconciled this zone's named A-records → the NetBird managed DNS zone; the `*/10` cron (`/etc/cron.d/dns-sync`) was **removed 2026-06-21** when the managed zone was retired. Technitium is now the **single** DNS source — mesh peers forward to it (see "Who points here" above), LAN/household clients query it directly.
 
-> **Why this exists — RETAINED (Phase 4 reverted 2026-06-21).** The managed zone is the mechanism that actually answers `hubris.network` for mesh peers. We tried to retire it (forward to Technitium instead) on the theory that a missing route was the only blocker — adding `Core` to the `192.168.8.0/24` distribution did fix roaming-peer *service connectivity*. But deleting the managed zone then broke DNS resolution for mesh peers: forwarding to `192.168.8.2` reports `Available` yet does not serve queries on the current client (Mac 0.68.3). So the original "NetBird won't forward to Technitium for mesh peers" finding stands. The managed zone + this sync are **kept**. To remove them, forwarding must first be made to actually work — candidates: upgrade clients to 0.71.x, or point the nameserver group at a **mesh-native** DNS IP (join CT 107 to the mesh) rather than the routed-LAN `192.168.8.2`. See [dns.md changelog 2026-06-21](../infrastructure/dns.md).
+The script + token + a pre-deletion record backup remain at `/opt/dns-sync/` **as an emergency-restore tool only**: running `python3 /opt/dns-sync/sync.py` once re-creates the managed zone from Technitium (used during the Phase 4 rollback). Do not re-add the cron unless reverting Phase 4. Tracked: [scripts/dns-sync.py](../scripts/dns-sync.py).
 
 ## DHCP