TP41-Follow-up: App-Launcher D1 (3 Bookmark-Kacheln + Styling), Geli pillepalle670 in zt-humans; TP43 (dw-DNS-Uplink) angelegt; IdP-Kurzanleitungen (Google/Meta)

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

docs/teilprojekte.md

@@ -44,6 +44,10 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
   Domain) und die `.bf.emsenhuber.net`-Aliase (Caddyfile) auf **einen** Namensraum `emsenhuber.net`
   ziehen; stale `.16/.17`-Rewrites abbauen; Sollzustand in Nautobot. Handoff:
   [`docs/handoff-20260901-tp42-naming.md`](handoff-20260901-tp42-naming.md).
+- 🔜 **TP43 dw-Standort-DNS-Uplink (2026-09-01, angelegt):** dem dw-Standort einen eigenen Resolver/
+  DNS-Uplink mit **site-spezifischen Overrides** geben (erster Fall `420.teilzeitladen.xyz` → BF-Caddy
+  über WG), **inkl. Verhalten bei WG-Disconnect** (Override auf BF-interne IP fällt sonst aus). FritzBox
+  standard kann keinen Per-Host-Override. Geli-Sofortlösung = **WARP** (nicht Teil von TP43). Cross-Projekt.
 - ✅ **TP16.3 ABGESCHLOSSEN (2026-09-01):** Flip **und** Abbau durch. Öffentlich laufen nur noch
   `bf-public` (12 Connectoren) und `fm` — die drei Alttunnel `bf-mm`/`bf-nas`/`bf-pve` **und** der
   projektfremde `terpene-db` sind gelöscht, **7 cloudflared-Container** entfernt (inkl.
@@ -490,6 +494,7 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na
 > | TP40 | 🔜 | HA-Recorder-Retention: 41 GB `states` beschneiden (Okay 09-01) | — |
 > | TP41 | ⏳ | CF-Access-Reparatur: **T4/T3/T2 ✅**; Token-Altlast geklärt; offen nur noch User-Aufgaben (T5 IdP-Callbacks = OTP-Fix, d47435-Revoke, T3-WARP-Client-Verify) | — |
 > | TP42 | 🔜 | Namens-Vereinheitlichung bf.lan→emsenhuber.net: `.bf.lan`/`.bf.emsenhuber.net` aus allen Geräten raus, in Nautobot festhalten | — |
+> | 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) | — |
 
 ### TP5.1 — DNS-Visibility & Flow-Observability für Low-Trust-Geräte (Airfryer-Fall) ▸ vorgemerkt
@@ -2944,6 +2949,32 @@ Problem"). **Abh.:** TP37 (Nautobot-Datenmodell) für Punkt 4; sonst nichts Offe
 **Status:** 🔜 angelegt 2026-09-01, Ausarbeitung eigene Session. 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)
+
+**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."*
+
+**Ziel:** dem dw-Standort einen **eigenen Resolver/DNS-Uplink** geben, der **site-spezifische Overrides**
+hält (erster Fall `420.teilzeitladen.xyz` → BF-Caddy über WG), als DNS der FritzBox/Clients gesetzt.
+
+**Kernfrage (explizit):** Verhalten bei **WG-Disconnect.** Ein Override auf eine BF-interne IP
+(`10.40.20.40`) fällt aus, wenn der Tunnel unten ist. Für einen Login-gegateten Dienst gibt es kein
+„kein Login **und** funktioniert bei WG-down" — Optionen: (a) Override nur bei WG-up (Failover-Resolver),
+(b) öffentlicher Pfad (CF, mit Login) als Fallback. Zu entwerfen.
+
+**Sofortlösung (nicht Teil von TP43):** Geli per **WARP** (Session statt täglichem Login, CGNAT egal,
+degradiert sauber: WG-up = nahtlos, WG-down = öffentliche URL + Login).
+
+**BF-seitige Prereqs:** Caddy-vhost `420.teilzeitladen.xyz` → macmini-Worker (`10.40.20.167:8890`) mit
+Cert (DNS-01, `…4148` hat teilzeitladen.xyz-DNS) · WG-Route dw→`10.40.20.40` · Split-Horizon für
+`420.teilzeitladen.xyz` (heute liefern auch `.36/.37` public). **Vorher verifizieren:** FritzOS-Version +
+Dauerläufer am dw. Cross-Projekt (teilzeitladen.xyz). Handoff:
+[`docs/handoff-20260901-tp41-followup.md`](handoff-20260901-tp41-followup.md).
+
+**Status:** 🔜 angelegt 2026-09-01, eigene Session.
+
 ### TP37 — Nautobot als durchgehende Netzwerkdoku: Hosts/Container/Dienste, erster Anwendungsfall CF-Connectoren ▸ 🔜 ANGELEGT 2026-08-30 (User-Okay erteilt)
 > **Christophs Formulierung (2026-08-30):** *„können wir das setup mit den cf-connectoren dann auch in
 > nautobot abbilden. quasi eine durchgehende netzwerkdoku stück für stück. muss eh fast sein, da du auf