TP43 reopened: interne BF-Namen über WG am dw — Entscheidung DHCP-Multi [.36/.37/public]

Auslöser: portainer.bf.emsenhuber.net vom dw-Standort (WG-Tunnel up) nicht
auflösbar — dw-FritzBox kennt die interne Zone bf.emsenhuber.net nicht.

- Gitea #32 reopened (status:todo, thema:firewall-dns), Prosa aus dem Archiv
  zurück nach teilprojekte.md (Archiv = ♻️-Zeiger).
- fm-Einwand live entkräftet (dig @.36): bf-Namen → 10.40.0.0/16 (über WG
  erreichbar), fm-Namen → Cloudflare-Anycast, nie 10.101.x.
- Entscheidung: FritzBox verteilt per DHCP die DNS-Liste .36/.37/9.9.9.9;
  .37-Redundanz bleibt, FB entlastet. NXDOMAIN-Failover-Haken + zwei
  On-site-Verifikationen dokumentiert. Umsetzung = eigene On-site-Session.

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

docs/teilprojekte.md

@@ -2725,3 +2725,66 @@ TP22 · TP-R · **TP3.2** (08-17) · **TP5** (08-18) · **TP7.1** (08-18) · **T
 7. **Foundation (2026-07-14):** **TP15** (MikroTik-Switching / Omada-WLAN, 2× CRS326 bestellt) ∥ **TP20 (Platform-Postgres, single-site replication-ready)** → **TP21 (Nautobot Golden Config)** ∥ **TP20.1 (Vaultwarden→PG + 2-Site-HA)**. TP20 hängt an **TP18 ①** (Garage-Bucket für pgBackRest).
 
 </details>
+
+
+### TP43 — dw-Standort: interne BF-DNS-Namen über WG auflösbar machen ▸ 🔜 **REOPENED 2026-09-11, Richtung entschieden (DHCP-Multi `[.36/.37/public]`); Umsetzung on-site offen** (verworfene 420-Historie am Ende dieses Abschnitts)
+
+**Live-Auslöser (2026-09-11):** Christoph am dw-Standort, WG-Tunnel zu BF up, kann `portainer.bf.emsenhuber.net`
+nicht erreichen. Direkte IP `https://10.40.20.126:9443` geht ⇒ **reines DNS-, kein Routing-Problem.** Der
+dw-Client nutzt die FritzBox (`10.95.10.1`) als Resolver; die kennt die interne Zone `bf.emsenhuber.net`
+(Split-Horizon `.36/.37 → 10.40.20.40` Caddy) nicht.
+
+**Korrektur gegenüber dem verworfenen Scope:** Der ursprüngliche Fall (`420.teilzeitladen.xyz`) ist ein
+**öffentlicher** CF-Worker und war nie das Problem — der ist via TP41/WARP + CF Access gelöst. Das echte,
+offene Problem sind **interne** BF-Namen (`*.bf.emsenhuber.net`) über den WG-Tunnel.
+
+**Live verifiziert (2026-09-11, `dig @10.40.20.36` über den Tunnel):** `portainer.bf.emsenhuber.net
+→ 10.40.20.40` (Caddy), `macmini.bf.emsenhuber.net → 10.40.20.167` — alle internen bf-Namen landen
+in `10.40.0.0/16`, über WG erreichbar. `ds-fm`/`gateway-fm.emsenhuber.net → 188.114.96.10/.97.10`
+= **Cloudflare-Anycast** (public), **nie `10.101.0.x`**. ⇒ **Der fm-Einwand (10.101.x intern ohne
+Pfad von dw) trifft für `.36/.37` nicht zu** — fm läuft über den public `fm.emsenhuber.net`-Tunnel,
+nicht über interne Records. (WG-Topologie TP10: dw-Peer AllowedIPs BF-seitig = `10.40.0.0/16`, dw
+routet **nicht** nach `10.101.0.0/24`.)
+
+**Constraint am dw:** die 24/7-Geräte `10.95.10.246/.247` sind **Cudy-APs (kein DNS-Host)**, und die
+FritzBox kann **kein Per-Zone-Forwarding** (nur einen globalen Upstream). Ohne Zusatz-Dauerläufer ist
+ein echter conditional forwarder (dnsmasq `server=/bf.emsenhuber.net/.36`) deshalb nicht drin.
+
+**Entscheidung (Christoph, 2026-09-11): DHCP-Multi.** Die dw-FritzBox verteilt **per DHCP** die
+DNS-Serverliste **`10.40.20.36, 10.40.20.37, 9.9.9.9`** an die Clients (FB-eigener Resolver damit
+umgangen). Gewählt gegenüber „FB-Upstream `.36` primär/public sekundär", weil die **`.37`-Redundanz
+bleibt** (3 Server statt FB-2-Slot-Grenze) und die **FB entlastet** ist.
+- **BF-up:** Client fragt `.36` zuerst → interne `bf.*` (Split-Horizon → `.40`) **und** public; der
+  public-Eintrag wird nie konsultiert.
+- **BF-down:** `.36`/`.37` timeouten → Client fällt auf `9.9.9.9` → public lebt, `bf.*` = NXDOMAIN
+  (erwartet).
+
+🔴 **Fundamentaler DNS-Haken (gilt für jede Server-Liste, nicht fixbar):** Failover zwischen
+Nameservern greift nur bei **Timeout/SERVFAIL, nicht bei NXDOMAIN**. Wird der public Server für
+`bf.*` zuerst gefragt, liefert er ein sauberes NXDOMAIN und der Client fragt `.36` nicht mehr →
+funktioniert nur, solange `.36`/`.37` **strikt zuerst** drankommen. Daraus die **zwei
+On-site-Verifikationen** (Christoph, am dw): (1) die dw-FRITZ!OS liefert per DHCP wirklich die
+Fremd-Liste aus (nicht die FB selbst); (2) die realen dw-Clients fragen **strikt in Reihenfolge**
+(kein `options rotate`/Parallel-Query) — mehrfach `nslookup portainer.bf.emsenhuber.net` muss
+**stabil** `10.40.20.40` liefern, nie sporadisch NXDOMAIN. Leakt ein Client-OS dennoch nach public:
+für **dieses Gerät** per-Device-Rückfall — `/etc/hosts`-Zeile `10.40.20.40 <name>` oder WARP mit
+`fallback_domains bf.emsenhuber.net → [.36,.37]` (TP41-Präzedenz).
+
+**Sofort-Workaround (läuft unabhängig):** `https://10.40.20.126:9443` direkt bzw.
+`/etc/hosts`-Zeile `10.40.20.40 portainer.bf.emsenhuber.net`.
+
+**Abhängigkeiten:** WG-Route dw→`10.40.0.0/16` (steht). Grenzt an TP42 (interner Namensraum
+`bf.emsenhuber.net`) und TP10 (Multi-Site-VPN). **Umsetzung = eigene On-site-Session** (FritzBox-DHCP
+ist Christophs manueller Schritt, kein Tool-Zugriff).
+
+---
+
+**Historie — verworfener 420-Scope (angelegt 2026-09-01, verworfen 2026-09-11):**
+
+**Auslöser (2026-09-01, TP41-Follow-up):** Geli soll `420.teilzeitladen.xyz` am dw-Standort erreichen.
+Split-Horizon am dw scheitert an der **FritzBox** (`10.95.10.1`): kein Per-Host-A-Override im Standard
+(nur DNS-Rebind-Ausnahmen ohne IP). Christoph: *„keine Chance im FritzBox-Standard? … lieber ein TP als
+uns verfranzen. Geli kommt rein, das zählt."* — Diese Prämisse fiel weg: `420.teilzeitladen.xyz` ist ein
+public CF-Worker hinter CF Access (löst auf CF-Anycast), kein BF-Origin ⇒ dafür braucht es kein
+Split-Horizon; Zugang via TP41-**WARP** gelöst (Geli 2026-09-10 via Android). Der Override-Bedarf für
+**interne** Namen blieb dabei übersehen — deshalb reopened, s.o.