TP42: Live-Bestandsaufnahme + Zielschema-Entscheidung (bf.emsenhuber.net)

Gegen die Geraete gemessen: .bf.lan ist ueberall weg, DHCP-domain auf
emsenhuber.net vereinheitlicht, Core-Static + Caddyfile konsistent auf
.bf.emsenhuber.net (deckt sich mit GC-Template). Drift hat ~80% erledigt.

Kernkonflikt: DHCP verteilt bare emsenhuber.net, Records leben unter
bf.emsenhuber.net -> bare macmini loest nicht. Entscheidung (User):
Zielschema = bf.emsenhuber.net (wenig-Arbeit-Weg); .16 (adguard_bf1)
abbauen, .17 (=FM) bleibt.

Netto-Rest = 2 Infra-Eingriffe: DHCP-domain ->bf.emsenhuber.net ueber die
GC-Pipeline (Template Z.133 + push-gc-template.py + Deploy) und .16-Teardown.
Kein Core-Objekt haengt an .16 (Firewall/NAT/DNS/Addr-List live geprueft).

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

docs/teilprojekte.md

@@ -53,6 +53,11 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
   `caddy/cf-sync.py` von einem Fehlalarm befreit (prüfte nur `http://`, gebaut ist `https://…:443`) und
   **grün** (nur `ds-bf` als bewusst intern). Schritt-6-Teil „MCP auf FQDN" durch TP35 Schicht 1
   umgekehrt (LAN-IP), damit gegenstandslos.
+- ⏳ **TP42 Bestandsaufnahme live durch (2026-09-02):** `.bf.lan` ist überall weg, DHCP-domain auf
+  `emsenhuber.net` vereinheitlicht, Core-Static + Caddyfile konsistent auf `.bf.emsenhuber.net`.
+  Zielschema **`bf.emsenhuber.net`** entschieden (User). Netto-Rest = 2 Infra-Eingriffe: DHCP-domain
+  `→bf.emsenhuber.net` über die GC-Pipeline + `.16`-Container-Abbau (`.17`=FM bleibt). Beide live
+  abgesichert (kein Core-Objekt hängt an `.16`). Wartet auf explizites Go.
 - 🔜 **TP42 Namens-Vereinheitlichung (2026-09-01, angelegt):** internes `.bf.lan` (Core-DNS, DHCP-Search-
   Domain) und die `.bf.emsenhuber.net`-Aliase (Caddyfile) auf **einen** Namensraum `emsenhuber.net`
   ziehen; stale `.16/.17`-Rewrites abbauen; Sollzustand in Nautobot. Handoff:
@@ -506,7 +511,7 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na
 > | TP38 | 🔜 | OOB-Mgmt: untagged-VLAN99-Port je Switch | — |
 > | TP40 | 🔜 | HA-Recorder-Retention: 41 GB `states` beschneiden (Okay 09-01) | — |
 > | TP41 | ⏸️ | CF-Access-Reparatur **zurückgestellt 2026-09-01** (User): **T2/T3/T4/T5 ✅** (GitHub+Google-Login live); **Facebook abgesagt**; **Geli CF-seitig fertig** (zt-humans+geli-Policy) → offen nur noch WARP-Client auf Gelis Gerät, wartet auf User-Info | — |
-> | TP42 | 🔜 | Namens-Vereinheitlichung bf.lan→emsenhuber.net: `.bf.lan`/`.bf.emsenhuber.net` aus allen Geräten raus, in Nautobot festhalten | — |
+> | TP42 | ⏳ | Namens-Vereinheitlichung: `.bf.lan` **weg**, DHCP unified; Zielschema **`bf.emsenhuber.net`** entschieden — Rest = DHCP-domain via GC + `.16`-Abbau (Go offen) | — |
 > | TP43 | 🔜 | dw-Standort-DNS-Uplink: eigener Resolver mit site-Overrides (`420.teilzeitladen.xyz`→BF-Caddy/WG), WG-Disconnect bedacht; Geli sofort per WARP | — |
 > | — | — | **35 archivierte TPs** in `teilprojekte-archiv.md` (inkl. TP39 ✅ 2026-09-01) | — |
 
@@ -3007,8 +3012,35 @@ und `.bf.emsenhuber.net` werden entfernt; Sollzustand in Nautobot dokumentiert.
 (`.36/.37` bleiben); `.1`-als-DNS-Reste auf Clients sind separat/tolerierbar (User: „bis jetzt kein
 Problem"). **Abh.:** TP37 (Nautobot-Datenmodell) für Punkt 4; sonst nichts Offenes.
 
-**Status:** 🔜 angelegt 2026-09-01, Ausarbeitung eigene Session. Handoff:
-[`docs/handoff-20260901-tp42-naming.md`](handoff-20260901-tp42-naming.md).
+#### ✅ Bestandsaufnahme LIVE (2026-09-02) — Drift hat 80 % schon erledigt
+Gegen die Geräte gemessen (MikroMCP + dig), nicht aus dem Handoff:
+
+| Fundstelle | Handoff 09-01 | Live 09-02 |
+|---|---|---|
+| Core `/ip dns static` | 11× `*.bf.lan` | ✅ **0× `.bf.lan`** — 10× `*.bf.emsenhuber.net` (deckt sich mit GC-Template Z.284–293) |
+| DHCP `domain` (7 Netze) | „prüfen" | `emsenhuber.net` (GC-Template Z.133 = gleich ⇒ **keine Drift**), DNS `.36/.37` |
+| `.36/.37` (Soll) | aktiv | `vw.emsenhuber.net→.40` ✅ · `macmini.bf.emsenhuber.net→.20.167` ✅ · **`macmini.emsenhuber.net→leer`** ❌ |
+| Caddyfile | `*.bf.emsenhuber.net`-Aliase | unverändert, **konsistent** mit Core-Static |
+| `.16`/`.17` | tot | laufen (:53), liefern totes VLAN1; **kein Core-Objekt** (Firewall/NAT/DNS-Upstream/Addr-List) hängt an `.16` |
+
+**Kernkonflikt:** DHCP verteilt `emsenhuber.net` (bare), Records leben unter `bf.emsenhuber.net` ⇒ bare `macmini` löst nicht.
+
+#### ✅ Entscheidungen (User, 2026-09-02)
+1. **Zielschema = `bf.emsenhuber.net`** (der wenig-Arbeit-Weg): DHCP-domain → `bf.emsenhuber.net`, dann
+   löst `macmini` bare korrekt; Core-Static + Caddyfile bleiben (tragen schon `.bf.`). Öffentliche Zone
+   `emsenhuber.net` bleibt getrennt.
+2. **`.16` (adguard_bf1) abbauen**, **`.17` (adguard_fm2 = Standort FM) NICHT anfassen.**
+
+#### 🔜 Netto-Rest (2 Eingriffe) — Infra, wartet auf explizites Go
+- **(A) DHCP-domain `emsenhuber.net → bf.emsenhuber.net` über GC** (kein Direkt-Write ⇒ keine Drift):
+  `nautobot/mikrotik_routeros.j2` Z.133 ändern → `routeros/push-gc-template.py` → Nautobot GitRepo-Sync
+  → `gc-configplan.py --refresh-compliance` → gestaffelter Deploy an **crs326-core** → Live-Verify
+  (`/ip dhcp-server network`, bare-Name-Auflösung).
+- **(B) `.16`-Teardown:** Container `adguard_bf1` auf Docker-LXC `.126` (Portainer ep14) stoppen + entfernen.
+- **(C) Nautobot-Soll** (Scope-Punkt 4) bleibt an **TP37** gekoppelt (Datenmodell), separat.
+
+**Status:** ⏳ Bestandsaufnahme + Entscheidungen durch (2026-09-02); Rest = 2 Infra-Eingriffe + TP37-gekoppelter
+Nautobot-Teil. Handoff: [`docs/handoff-20260901-tp42-naming.md`](handoff-20260901-tp42-naming.md).
 
 ### TP43 — dw-Standort-DNS-Uplink (site-spezifische Overrides) ▸ 🔜 ANGELEGT 2026-09-01 (User-Okay erteilt)