Uebergabe fuer den AGH-DNS-Cutover als eigene Session

Der Split-Horizon-Entscheid (AdGuard statt Core) macht aus 'ein paar
Eintraegen' eine Verschiebung der DNS-Aufloesung des ganzen Standorts in
einen Container -- heute liefert der DHCP in allen sieben VLANs den Core.
Das gehoert nicht ans Ende einer langen Sitzung (Lehre aus TP28).

Handoff enthaelt: Ausgangslage (Caddy produktiv, 16 Sites/17 Zertifikate),
den Auftrag in fuenf Schritten inkl. der IP-Kollision .30 (Nautobot) und
der Vorgabe, AGH als Paar 110/111 zu bauen statt als DNS-SPOF, sowie die
Staffelung VLAN fuer VLAN mit VLAN30 zuletzt.

Vier Fallen mitgegeben, alle in dieser Session bezahlt: Statuscode vom
oeffentlichen FQDN beweist nichts (grafana), pvesm free scheitert an
geschuetzten Snapshots stillschweigend, Startreihenfolge haengt nicht an
der VMID, und Core-Config braucht Golden Config.

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

docs/handoff-20260825-agh-dns-cutover.md

@@ -0,0 +1,73 @@
+# Übergabe — nächste Session: AdGuard als Resolver + Split-Horizon (TP23 Stufe 2 ∥ TP31 Schritt 4)
+
+> **Einstieg:** diese Datei, dann [`teilprojekte.md`](teilprojekte.md) → **TP31** und **TP32**.
+> **Zustand am Netz: stabil.** Caddy läuft produktiv, nichts steht halb offen, keine Config-Transaktion.
+
+## Warum eine eigene Session
+
+Der Schritt verschiebt die **DNS-Auflösung des ganzen Standorts** vom Core in einen Container. Heute
+liefert der DHCP in **allen sieben VLANs** `dns-server = <VLAN>.1`; AdGuard auf `10.40.20.16` bekommt
+**niemand**. Ein Fehler trifft sofort jedes Gerät — und ist schlecht zu diagnostizieren, wenn die
+Auflösung selbst das Kaputte ist. **Nicht ans Ende einer langen Sitzung legen** (Lehre aus TP28).
+
+## Ausgangslage (Stand 2026-08-25, live geprüft)
+
+- ✅ **Caddy produktiv**: LXC **130** `caddy-bf1`, **`10.40.20.40`**, Debian 13, `onboot=1`,
+  `startup order=10`, im Backup-Job. Caddy **v2.11.4** mit `dns.providers.cloudflare`.
+  **16 Sites, 17 Zertifikate** per DNS-01. Config im Repo: **`caddy/Caddyfile`**,
+  Ausrollen mit **`caddy/deploy.sh`** (liest `CF_DNS_API_TOKEN` aus `~/.secrets`, nie auf stdout).
+- ✅ **Aufgeräumt**: LXC `120/121/128/129/130(alt)/131` **und `104`** zerstört, PBS-Snapshots der
+  ersten sechs restlos weg (72/72). **Die 14 Snapshots von `ct/104` stehen bewusst noch** — einzige
+  Kopie etwaiger Grafana-Dashboards.
+- ✅ **Startreihenfolge auf pve repariert** (TP32): fünf Stufen, HA startet jetzt **nach** MariaDB,
+  Docker, MQTT und z2m25.
+- 🟡 **Zwei bekannte Baustellen**, beide **vor** der CNAME-Umstellung fällig:
+  - **`hass` → 400**: Home Assistant braucht `10.40.20.40` in `http.trusted_proxies` +
+    `use_x_forwarded_for: true`.
+  - **`grafana` ist tot** und aus dem Caddyfile entfernt (s.u.).
+
+## Der Auftrag
+
+**User-Entscheid 2026-08-25:** Split-Horizon **nicht** auf dem Core, sondern **in AdGuard, zusammen mit
+TP23 Stufe 2** — „nichts zweimal bauen".
+
+1. **LXC 110 `agh-bf1` und 111 `agh-bf2` bauen.** Muster: exakt wie LXC 130 (Debian 13, `tag=20`,
+   `onboot=1`, `startup order=10`, im Backup-Job `backup-6dcf5c10-610f`).
+   🔑 **Als Paar, nicht einzeln** — TP32 reserviert `110–119` für DNS, und die gelöschten Altlasten
+   hießen `adguard-bf1`/`adguard-bf2`: die Redundanz war schon einmal geplant. **Ein einzelner AGH wäre
+   ein DNS-SPOF auf pve.**
+   ⚠️ **IP-Kollision klären:** TP32 will DNS auf `.3x`, aber **`.30` ist Nautobot** und `.31` der
+   nautobot-worker. Vorschlag `.36`/`.37` als Interim.
+2. **Konfiguration übernehmen** aus dem laufenden Docker-AdGuard (`adguard_bf1`, `10.40.20.16`, in
+   **LXC 400 → Docker**, Netz `vlan20` = ipvlan). Dort stehen bereits DoH zum CF-Gateway und die
+   conditional upstreams `[/bf.lan/]10.40.20.1` und `[/40.10.in-addr.arpa/]10.40.20.1`.
+   Backup laut TP23: `AdGuardHome.yaml.bak-tp23-20260817`.
+3. **Die 16 Rewrites setzen** — alle Service-FQDNs aus `caddy/Caddyfile` → **`10.40.20.40`**.
+4. **Erst testen, dann ausliefern.** Direkt gegen die neuen Resolver abfragen (`dig @<agh-ip>`),
+   **bevor** irgendein DHCP angefasst wird.
+5. **VLAN für VLAN umstellen, nicht alle sieben auf einmal.** Vorschlag: VLAN20 zuerst (dort sitzt die
+   Infrastruktur und man merkt Fehler sofort), dann VLAN10, der Rest zuletzt. **VLAN30 (IoT, 26 Geräte)
+   als letztes** — dort ist ein Reconnect am teuersten.
+
+## Fallen, die schon bezahlt sind
+
+- 🔴 **Ein Statuscode vom öffentlichen FQDN beweist nichts.** `grafana.emsenhuber.net` lieferte
+  monatelang **302** — das war der **Access-Login**, während der Dienst gar nicht existierte (LXC 104
+  gestoppt, konfigurativ auf VLAN1 `10.40.41.109`, Ingress zeigte auf `10.40.20.109`, das es nie gab).
+  **Immer gegen das Origin messen**, nicht gegen die Fassade.
+- 🔴 **`pvesm free` scheitert an geschützten PBS-Snapshots stillschweigend** („cannot remove protected
+  snapshot"). Wer nur Erfolgszähler liest, hält ein halbes Aufräumen für fertig.
+  Entschützen: `pvesh set /nodes/pve/storage/pbs/content/<volid> --protected 0`.
+- 🔴 **Startreihenfolge auf pve hängt NICHT an der VMID**, solange ein Gast ein explizites
+  `startup: order=` trägt: Proxmox startet erst alle mit `order=`, dann den Rest nach VMID.
+- ⚠️ **Core-Config läuft über Nautobot Golden Config.** Die DHCP-`dns-server`-Änderung ist eine
+  Core-Änderung ⇒ Template **und** ComplianceRule, sonst Drift. Aktuell **104/104, 0 Drifts**.
+- ⚠️ **Caddy in LXC 130 hat einen eigenen Netzwerk-Namespace** und ist deshalb nicht von der
+  macvlan/ipvlan-Blindheit betroffen. Ein AGH **im Docker-LXC 400** wäre es — ein weiterer Grund für
+  eigene LXCs.
+
+## Danach offen (TP31 Rest)
+
+Tunnel `bf-public` + cloudflared auf **ap1/ap2** (arm64, 95 MB Flash frei — ⚠️ braucht je einen
+**physischen** `device-mode`-Wechsel am Gerät), CNAMEs umhängen (`n8n` → `gitea` → `hass` → `vw`),
+dann `bf-nas`/`bf-pve`/`bf-mm` löschen und die sechs alten Container entfernen.

docs/teilprojekte.md

@@ -109,7 +109,11 @@ ab jetzt bei jeder Änderung mitgezogen, nicht nur die TP-Abschnitte.)*
 > gebündelt gegen Projektende**, User-Entscheid. Damit ist die ältere Einreihung „hinter TP17.1"
 > gegenstandslos (TP17.1 ist verworfen). **Etappe 1 — die Service-Accounts — ist durch;**
 > das `admin`-Passwort selbst ist **nicht rotiert** und bleibt es bis dahin bewusst.
-> 📌 **Einstieg für die nächste Session: [`handoff-20260824-session.md`](handoff-20260824-session.md)**
+> 📌 **Einstieg für die nächste Session:
+> [`handoff-20260825-agh-dns-cutover.md`](handoff-20260825-agh-dns-cutover.md)** — AdGuard als
+> Resolver + Split-Horizon (TP23 Stufe 2 ∥ TP31 Schritt 4). **Bewusst eigene Session:** der Schritt
+> verschiebt die DNS-Auflösung des ganzen Standorts in einen Container.
+> 📜 Älter: [`handoff-20260824-session.md`](handoff-20260824-session.md)
 > — ⚠️ dessen Empfehlung „Start bei der Passwort-Rotation Etappe 2" ist durch den TP30-Entscheid
 > **überholt**; der Rest der Übergabe gilt. Ältere Sitzungsvorschläge:
 > [`handoff-20260822-naechste-schritte.md`](handoff-20260822-naechste-schritte.md).