TP23 Stufe 6: Bypass-Sperre-Entwurf abgelegt (log-only + reject), NICHT deployt

Zwei RouterOS-Skripte fuer die DNS-Bypass-Sperre der TP5-forward-Kette,
gespiegelt am TP5-Etappen-Stil (idempotent, place-before, Auto-Revert):
- phaseA: Substrat (dns-resolvers/dns-bypass-exempt/jit-dns-bypass) +
  Exempt/JIT-Accepts + log-only TP5-WOULD-DROP-DNS.
- phaseB: reject icmp-port-unreachable + Auto-Revert-Scheduler.

Freigegeben 2026-09-11, bewusst NICHT deployt (Christoph remote, hartes
Vor-Ort-Gate). Zwei Live-Verifikationen vor dem Deploy im Dateikopf markiert:
Egress-Accept-Anker der forward-Kette + Exempt-IPs des dev-MacBooks
(MikroMCP war beim Schreiben zu allen Geraeten tot -> nicht geraten).
log-only wird beim Deploy als gc-Transaktion gefuehrt.

Runbook-Zeiger auf beide Dateien ergaenzt.

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

docs/teilprojekte-archiv.md

@@ -66,7 +66,7 @@ teuerste Eigenschaft der Datei zerstört, um ihr billigstes Problem zu lösen. B
 | [TP34](#tp34) | Caddyfile via Nautobot/GC (generische Reverse-Proxy-Schnittstelle) | ❌ VERWORFEN (2026-09-08) — Caddyfile bleibt manuell |
 | [TP44](#tp44) | Cloudflare-Estate als Dokumentations-SSoT in Nautobot | ✅ DURCH (2026-09-10) |
 | [TP41](#tp41) | CF-Access-Reparatur + Zero-Trust-Konsolidierung | ✅ ABGESCHLOSSEN (2026-09-10) — Gelis WARP via Android eingerichtet, letzter Blocker weg |
-| [TP43](#tp43) | dw-Standort-DNS-Uplink (site-spezifische Overrides) | ❌ VERWORFEN (2026-09-11) — 420 ist public CF-Worker, kein Split-Horizon nötig; Zugang via WARP+CF Access |
+| [TP43](#tp43) | dw-Standort-DNS-Uplink (site-spezifische Overrides) | ♻️ REOPENED (2026-09-11) — Volltext zurück in teilprojekte.md; interne BF-Namen über WG am dw offen |
 | [TP42](#tp42) | Namens-Vereinheitlichung: ein interner Suffix bf.emsenhuber.net | ✅ DURCH (2026-09-02) — `.bf.lan` raus, `.16` abgebaut, Compliance 140/140 |
 
 Dazu am Ende: **[TP25 (Langfassung)](#tp25-lang)** — die Messchronik und die Funde A–E im Volltext.
@@ -1906,31 +1906,12 @@ der Egress ohnehin Cloudflare (nicht diese IP) → der IP-Include wäre dann üb
 **Gitea-Least-Privilege** = eigener künftiger TP (jedes Projekt repo-scoped Login, Admin nur Claude/Christoph).
 - Bezug **TP11** (Monitoring): eine Plattenfüllstand-Warnung hätte das Wochen früher gezeigt.
 
-### TP43 — dw-Standort-DNS-Uplink (site-spezifische Overrides) ▸ ❌ **VERWORFEN (2026-09-11)** — Prämisse (BF-internes 420) gegenstandslos: `420.teilzeitladen.xyz` = public CF-Worker hinter CF Access (löst auf CF-Anycast, NS=Cloudflare), kein BF-Origin ⇒ kein Split-Horizon/Override nötig. Auslöser via TP41-**WARP** gelöst (Geli 2026-09-10 via Android). Keine BF-Altlasten aufzuräumen (kein 420-Caddy-vhost, kein macmini:8890-Container; `terpene-db`/LXC400 = blaueblüten, bleibt). Prosa unten = Historie.
+### TP43 — dw-Standort-DNS-Uplink (site-spezifische Overrides) ▸ ♻️ **REOPENED 2026-09-11 → Volltext zurück in [`teilprojekte.md`](teilprojekte.md) (Abschnitt TP43)**
 
-**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.
+Kurz zwischen 2026-09-11 verworfen und am selben Tag reopened: die 420-Prämisse war gegenstandslos
+(public CF-Worker, via WARP/TP41 gelöst), aber die **interne** BF-Namensauflösung über WG am dw blieb
+dabei offen (`portainer.bf.emsenhuber.net` am dw nicht erreichbar). Korrigierter Scope + verworfene
+420-Historie stehen jetzt aktiv in `teilprojekte.md`. Gitea-Issue #32 = `status:todo` · `thema:firewall-dns`.
 
 ### TP42 — Namens-Vereinheitlichung: ein interner Suffix bf.emsenhuber.net ▸ ✅ **DURCH (2026-09-02)** — ein interner Suffix `bf.emsenhuber.net`, `.bf.lan` raus, `.16` (adguard_bf1) abgebaut, Compliance 140/140. Offen nur der an **TP37** gekoppelte Nautobot-Doku-Teil.
 

docs/teilprojekte.md

@@ -2725,3 +2725,78 @@ 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 ▸ ✅ **UMGESETZT 2026-09-11** — dw-FritzBox: Upstream `.36`+`.37`, DNS-Rebind-Ausnahme `bf.emsenhuber.net`, Fallback-Haken „öffentliche NS bei Unreachbarkeit" **gesetzt** (Ideal-Variante: `.37`-Redundanz bleibt, BF-down → public). (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)**; die
+FritzBox kann **kein Per-Zone-Forwarding** (nur einen globalen Upstream) **und per DHCP nur EINE
+DNS-IP ausliefern** (⇒ „mehrere NS an die Clients" scheidet aus). Ein echter conditional forwarder
+(dnsmasq `server=/bf.emsenhuber.net/.36`) bräuchte einen Zusatz-Dauerläufer — abgelehnt.
+
+**Entscheidung (Christoph, 2026-09-11): FB-Upstream + Rebind-Ausnahme.** Clients bekommen per DHCP
+`10.95.10.1` (die FB selbst, Default); die **FB forwardet an die BF-Resolver**: *DNS-Server → „Andere
+DNSv4-Server"* Bevorzugt **`10.40.20.36`**, Alternativ **`10.40.20.37`** (beide BF, beide
+Voll-Resolver → Redundanz bleibt). Sauberer als der zwischenzeitliche DHCP-Multi-Gedanke: die FB ist
+der **einzige** Client-Resolver und `.36` löst **intern und public** auf → alles geht zuerst an `.36`,
+public wird nur als Unreachable-Fallback konsultiert, **nie „zuerst"** → kein NXDOMAIN-Leak im
+Normalbetrieb.
+
+🔴 **DNS-Rebind-Schutz-Ausnahme `bf.emsenhuber.net`** (*Heimnetz → Netzwerk → Netzwerkeinstellungen →
+DNS-Rebind-Schutz*) ist **zwingend**: sonst filtert die FB die Privat-IP-Antworten (`10.40.x`) als
+Rebind-Angriff weg → bf-Namen liefern nichts, obwohl `.36` korrekt antwortet. Die Ausnahme ist ein
+reines Namens-Whitelist (keine IP).
+
+**BF-down-Fallback (Verzweigung am FRITZ!OS-Stand):** Christoph erinnert ein Setting „öffentliche NS
+verwenden, wenn die primären nicht erreichbar sind". Vorhanden → aktivieren, Upstream bleibt
+`.36`+`.37`, BF-down geht auf public. Fehlt → Alternativ-Slot statt `.37` auf **public `9.9.9.9`**
+(kostet `.37`-Redundanz); dann zusätzlich prüfen, dass die FB **strikt primär** fragt (nicht
+round-robbt), sonst NXDOMAIN-Leak für `bf.*` bei BF-up.
+
+- **BF-up:** FB → `.36` → interne `bf.*` (→ `.40`, dank Rebind-Ausnahme durchgereicht) **und** public.
+- **BF-down:** `.36`/`.37` unreachable → public-Fallback → public lebt, `bf.*` = NXDOMAIN (erwartet).
+
+**Bewusst akzeptierter Tradeoff:** bei BF-up läuft Geli's **gesamter** Haushalt-DNS über Linz
+(`.36`/AdGuard-Filter) — vermeidbar nur mit conditional forwarder (Zusatz-HW, abgelehnt).
+
+**On-site-Verifikationen (Christoph, am dw):** (1) Rebind-Ausnahme greift — `nslookup
+portainer.bf.emsenhuber.net` über die FB → stabil `10.40.20.40`; (2) BF-down-Fallback vorhanden
+(Setting) oder via public-Alternativ-Slot gesetzt; (3) nur falls BF+public gemischt: FB fragt strikt
+primär. Rückfall pro Gerät: `/etc/hosts` `10.40.20.40 <name>` oder WARP `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.

docs/tp23-stufe6-bypass-sperre-runbook.md

@@ -23,6 +23,12 @@ Das ist der letzte Baustein von TP23 und lebt in der **TP5-Firewall** (`forward`
   Reihenfolge-Regel („erst der Ersatz, dann die Sperre").
 - `dns-bypass-exempt`-Gruppe existiert auf dem Resolver-Paar (AGH-Client-Seite).
 
+**Entwurf liegt bereit (freigegeben 2026-09-11, NOCH NICHT deployt — Christoph war remote):**
+- Phase A (Substrat + Exempt/JIT-Accepts + log-only): `routeros/tp23-stufe6-phaseA-exempt-log.rsc`
+- Phase B (reject + Auto-Revert): `routeros/tp23-stufe6-phaseB-reject.rsc`
+- 🔴 **Vor dem Deploy live verifizieren** (im Dateikopf markiert): (1) der Egress-Accept-Anker in
+  der forward-Kette, vor dem die Regeln stehen müssen; (2) die Exempt-IPs des dev-MacBooks.
+
 **Noch zu bauen (Teil dieser Session, VOR dem Drop):**
 - **Firewall-Exempt** ist noch NICHT da: eine Address-List `dns-bypass-exempt` (permanent) mit dem
   dev-MacBook (`10.40.10.183` **und** `10.40.10.82`, dual-homed) + Agent-Toolchain, plus eine

routeros/tp23-stufe6-phaseA-exempt-log.rsc

@@ -0,0 +1,59 @@
+# TP23 Stufe 6 — PHASE A: Substrat + Exempt/JIT-Accepts + log-only-Vorstufe.
+#
+# 🔴🔴 NUR VOR ORT. Dieser Deploy allein bricht noch nichts (kein drop/reject),
+#   aber Phase B (der reject) macht .36/.37 zum DNS-SPOF ohne Fern-Rollback.
+#   Runbook: docs/tp23-stufe6-bypass-sperre-runbook.md.
+#
+# STATUS: ENTWURF, freigegeben 2026-09-11, NOCH NICHT DEPLOYT (Christoph war remote).
+#
+# ┌─ LIVE-VERIFY VOR DEM DEPLOY (nicht raten — MikroMCP war beim Schreiben tot) ─┐
+# │ (1) ANKER <<EGRESS-ACCEPT>>: die forward-Regel, die HEUTE LAN->WAN-DNS zu     │
+# │     8.8.8.8:53 durchlaesst (der generische Internet-Egress-Accept). Meine     │
+# │     Regeln muessen DAVOR stehen, sonst greift der Egress-Accept zuerst und    │
+# │     die log-only-Regel zaehlt 0. Anker aus der Live-Kette holen:              │
+# │       /ip firewall filter print where chain=forward                          │
+# │     und unten das place-before-Kommentar ersetzen. Faellt externer DNS heute  │
+# │     schon in deny-by-default (TVs mit 8.8.8.8 loesen JETZT nicht auf), ist     │
+# │     Stufe 6 gegenstandslos — dann Runbook neu bewerten.                       │
+# │ (2) EXEMPT-IPs: dev-MacBook ist dual-homed. Beide Beine gegen die Realitaet   │
+# │     pruefen (en5/en0 koennen per DHCP gewechselt haben):                      │
+# │       /ip dhcp-server lease print where comment~"macbook"                     │
+# │     und mit der AGH-Seite (clients.persistent 'dns-bypass-exempt') abgleichen.│
+# └───────────────────────────────────────────────────────────────────────────┘
+#
+# Weg (KEIN mikromcp-Direkt-Write — ip-firewall-filter steht unter Drift-Kontrolle):
+#   Backup davor:  create_backup routerId=crs326-core  (core-pre-tp23-s6-<datum>.backup)
+#   Deploy:        python3 nautobot/gc-manual-plan.py --device crs326-core \
+#                    --commands-file routeros/tp23-stufe6-phaseA-exempt-log.rsc \
+#                    --change-id TP23-S6-PhaseA --deploy
+#   log-only als befristeter Versuch fuehren (NICHT als Versehen lesbar machen):
+#                  python3 nautobot/gc-transaktion.py  (Transaktion 'TP23-S6-would-drop-dns')
+#   Soll-Sync (Substrat + Accepts sind Dauerzustand -> ins intended):
+#                  python3 nautobot/ingest-core-firewall.py --apply
+#                  python3 nautobot/gc-configplan.py --refresh-compliance
+# ---------------------------------------------------------------------------
+
+# 0) Substrat: erlaubte Resolver (dst), permanente Exempts (src), leere JIT-Liste.
+:do { :if ([:len [/ip firewall address-list find list="dns-resolvers" address="10.40.20.36"]] = 0) do={ /ip firewall address-list add list=dns-resolvers address=10.40.20.36 comment="TP23-S6: AGH agh-bf1" } } on-error={ :log info "tp23s6A: 00a warf" }
+:do { :if ([:len [/ip firewall address-list find list="dns-resolvers" address="10.40.20.37"]] = 0) do={ /ip firewall address-list add list=dns-resolvers address=10.40.20.37 comment="TP23-S6: AGH agh-bf2" } } on-error={ :log info "tp23s6A: 00b warf" }
+:do { :if ([:len [/ip firewall address-list find list="dns-bypass-exempt" address="10.40.10.183"]] = 0) do={ /ip firewall address-list add list=dns-bypass-exempt address=10.40.10.183 comment="TP23-S6: dev-MacBook en5 (VERIFY)" } } on-error={ :log info "tp23s6A: 00c warf" }
+:do { :if ([:len [/ip firewall address-list find list="dns-bypass-exempt" address="10.40.10.82"]] = 0) do={ /ip firewall address-list add list=dns-bypass-exempt address=10.40.10.82 comment="TP23-S6: dev-MacBook en0 (VERIFY)" } } on-error={ :log info "tp23s6A: 00d warf" }
+
+# 1) Exempt-Accepts. dev-MacBook + Agent-Toolchain behalten ihren DNS-Ausweg.
+#    MUSS vor der log-only-Regel stehen (action=accept terminiert -> Exempt-Traffic
+#    erreicht die Log-Regel nie und taucht im WOULD-DROP-Log korrekt NICHT auf).
+:do { :if ([:len [/ip firewall filter find comment="TP23-S6: dns-exempt udp"]] = 0) do={ /ip firewall filter add chain=forward action=accept src-address-list=dns-bypass-exempt protocol=udp dst-port=53,853 comment="TP23-S6: dns-exempt udp" place-before=[/ip firewall filter find comment="<<EGRESS-ACCEPT — LIVE VERIFY>>"] } } on-error={ :log info "tp23s6A: 01a warf" }
+:do { :if ([:len [/ip firewall filter find comment="TP23-S6: dns-exempt tcp"]] = 0) do={ /ip firewall filter add chain=forward action=accept src-address-list=dns-bypass-exempt protocol=tcp dst-port=53,853 comment="TP23-S6: dns-exempt tcp" place-before=[/ip firewall filter find comment="<<EGRESS-ACCEPT — LIVE VERIFY>>"] } } on-error={ :log info "tp23s6A: 01b warf" }
+
+# 2) JIT-Accepts. Leere, selbstverfallende Liste (Muster jit-admin, tp5-etappe4):
+#      /ip firewall address-list add list=jit-dns-bypass address=<ip> timeout=1h
+:do { :if ([:len [/ip firewall filter find comment="TP23-S6: dns-jit udp"]] = 0) do={ /ip firewall filter add chain=forward action=accept src-address-list=jit-dns-bypass protocol=udp dst-port=53,853 comment="TP23-S6: dns-jit udp" place-before=[/ip firewall filter find comment="<<EGRESS-ACCEPT — LIVE VERIFY>>"] } } on-error={ :log info "tp23s6A: 02a warf" }
+:do { :if ([:len [/ip firewall filter find comment="TP23-S6: dns-jit tcp"]] = 0) do={ /ip firewall filter add chain=forward action=accept src-address-list=jit-dns-bypass protocol=tcp dst-port=53,853 comment="TP23-S6: dns-jit tcp" place-before=[/ip firewall filter find comment="<<EGRESS-ACCEPT — LIVE VERIFY>>"] } } on-error={ :log info "tp23s6A: 02b warf" }
+
+# 3) log-only-Vorstufe. Loggt LAN->extern DNS, das NICHT zu einem erlaubten
+#    Resolver geht. dst-address-list=!dns-resolvers negiert die Liste. Mehrere
+#    Tage lesen (Kollektor 10.40.20.18:514), dann Phase B. NUR 53/853-Zeilen zaehlen.
+:do { :if ([:len [/ip firewall filter find comment="TP23-S6: WOULD-DROP-DNS udp"]] = 0) do={ /ip firewall filter add chain=forward action=log log-prefix="TP5-WOULD-DROP-DNS" protocol=udp dst-port=53,853 dst-address-list=!dns-resolvers comment="TP23-S6: WOULD-DROP-DNS udp" place-before=[/ip firewall filter find comment="<<EGRESS-ACCEPT — LIVE VERIFY>>"] } } on-error={ :log info "tp23s6A: 03a warf" }
+:do { :if ([:len [/ip firewall filter find comment="TP23-S6: WOULD-DROP-DNS tcp"]] = 0) do={ /ip firewall filter add chain=forward action=log log-prefix="TP5-WOULD-DROP-DNS" protocol=tcp dst-port=53,853 dst-address-list=!dns-resolvers comment="TP23-S6: WOULD-DROP-DNS tcp" place-before=[/ip firewall filter find comment="<<EGRESS-ACCEPT — LIVE VERIFY>>"] } } on-error={ :log info "tp23s6A: 03b warf" }
+
+:log info ("tp23s6A: ENDE exempt-udp=" . [:tostr [:len [/ip firewall filter find comment="TP23-S6: dns-exempt udp"]]] . " log-udp=" . [:tostr [:len [/ip firewall filter find comment="TP23-S6: WOULD-DROP-DNS udp"]]] . " resolvers=" . [:tostr [:len [/ip firewall address-list find list="dns-resolvers"]]] . " exempt=" . [:tostr [:len [/ip firewall address-list find list="dns-bypass-exempt"]]])

routeros/tp23-stufe6-phaseB-reject.rsc

@@ -0,0 +1,40 @@
+# TP23 Stufe 6 — PHASE B: der scharfe Schnitt (reject) + Auto-Revert.
+#
+# 🔴🔴 NUR VOR ORT, mit offener Konsole. Erst NACHDEM das WOULD-DROP-DNS-Log
+#   (Phase A) mehrere Tage ruhig/verstanden ist und jeder externe Resolver
+#   entschieden wurde (Reservierung auf AGH / Exempt / bewusst brechen lassen).
+#   AB HIER ist .36/.37 ein DNS-SPOF ohne Fern-Rollback (Runbook, Gate).
+#
+# STATUS: ENTWURF, freigegeben 2026-09-11, NOCH NICHT DEPLOYT.
+#
+# WARUM reject STATT drop: reject icmp-port-unreachable laesst Clients schneller
+#   auf den naechsten (erlaubten) Resolver fallen, statt in einen Timeout zu laufen.
+#
+# WARUM die Log-Regel STEHEN BLEIBT: action=log terminiert NICHT — das Paket wird
+#   geloggt und faellt dann in die reject-Regel darunter. Gleiche Doktrin wie
+#   tp5-etappe3-drop (Log VOR Drop), der Kollektor zeigt weiter, was reject frisst.
+#
+# Weg (wie Phase A, ueber Nautobot GC):
+#   Deploy:  python3 nautobot/gc-manual-plan.py --device crs326-core \
+#              --commands-file routeros/tp23-stufe6-phaseB-reject.rsc \
+#              --change-id TP23-S6-PhaseB --deploy
+#   Danach (reject ist jetzt Dauerzustand -> Soll, log-only-Transaktion schliessen):
+#            python3 nautobot/ingest-core-firewall.py --apply
+#            python3 nautobot/gc-configplan.py --refresh-compliance   # Ziel gruen
+#
+# Rollback sofort (Vor-Ort-Konsole): /ip firewall filter set [find comment~"TP23-S6: reject"] disabled=yes
+#   -> Clients koennen sofort wieder externe Resolver nutzen. Bzw. Auto-Revert unten.
+# ---------------------------------------------------------------------------
+
+# 0) Auto-Revert ZUERST — deaktiviert die reject-Regeln nach 10m, falls nicht
+#    bestaetigt (analog tp5-etappe3/4). Nach der Abnahme abbestellen:
+#      /system scheduler remove [find name="tp23s6autorevert"]
+:do { :if ([:len [/system scheduler find name="tp23s6autorevert"]] = 0) do={ /system scheduler add name="tp23s6autorevert" interval=10m on-event="/ip firewall filter set [find comment~\"TP23-S6: reject\"] disabled=yes; /system scheduler remove [find name=\"tp23s6autorevert\"]; :log warning \"tp23s6: AUTO-REVERT hat die DNS-reject-Regeln abgeschaltet\"" } } on-error={ :log info "tp23s6B: 00 scheduler warf" }
+
+# 1) reject. Gleiche Match-Tupel wie die WOULD-DROP-DNS-Log-Regeln, direkt
+#    dahinter (place-before denselben Egress-Anker -> landet nach den Log-Regeln).
+#    <<EGRESS-ACCEPT>>: derselbe live-verifizierte Anker wie in Phase A.
+:do { :if ([:len [/ip firewall filter find comment="TP23-S6: reject dns udp"]] = 0) do={ /ip firewall filter add chain=forward action=reject reject-with=icmp-port-unreachable protocol=udp dst-port=53,853 dst-address-list=!dns-resolvers comment="TP23-S6: reject dns udp" place-before=[/ip firewall filter find comment="<<EGRESS-ACCEPT — LIVE VERIFY>>"] } } on-error={ :log info "tp23s6B: 01a warf" }
+:do { :if ([:len [/ip firewall filter find comment="TP23-S6: reject dns tcp"]] = 0) do={ /ip firewall filter add chain=forward action=reject reject-with=icmp-port-unreachable protocol=tcp dst-port=53,853 dst-address-list=!dns-resolvers comment="TP23-S6: reject dns tcp" place-before=[/ip firewall filter find comment="<<EGRESS-ACCEPT — LIVE VERIFY>>"] } } on-error={ :log info "tp23s6B: 01b warf" }
+
+:log info ("tp23s6B: ENDE reject-udp=" . [:tostr [:len [/ip firewall filter find comment="TP23-S6: reject dns udp"]]] . " reject-tcp=" . [:tostr [:len [/ip firewall filter find comment="TP23-S6: reject dns tcp"]]] . " autorevert=" . [:tostr [:len [/system scheduler find name="tp23s6autorevert"]]])