TP4 DNS: Entscheidung auf RouterOS-nativ + nur statische Records

Variante A (BIND/RFC2136) verworfen: HW-Vorgabe "Container nur am Router
oder gar nicht, keine NAS/pve-Abhaengigkeit" + hAP kann praktikabel keinen
DNS-Container hosten (live: ~90MB frei, kein USB, Flash-Wear).

- research-Doc umgeschrieben: Entscheidung + Variante A als parkierter Anhang
- teilprojekte TP4 auf finale Entscheidung
- technitium/ -> dns/ umbenannt + README

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

dns/README.md

@@ -0,0 +1,14 @@
+# dns/
+
+Lokale DNS-Auflösung für das BF-Netz.
+
+**Entscheidung (2026-06-15):** RouterOS-nativer DNS + **nur statische Records** — keine DHCP→DNS-Auto-Registrierung,
+kein externer DNS-Server, kein Container. Begründung, verworfene Alternativen (Technitium, BIND/RFC2136, Lease-Script)
+und parkierte Variante A: [`../docs/research/dns-registration-options.md`](../docs/research/dns-registration-options.md).
+
+Umsetzung erfolgt in **TP4 (Router-Cutover)** auf ap1/ap2:
+- `/ip dns` als Resolver, DoH-Upstream (Filtering/DNSSEC, TP3).
+- `/ip dns static` je Infra-Host unter `bf.lan` — gemeinsam mit der DHCP-Reservierung pflegen.
+- HA: identische statische Einträge auf ap1 **und** ap2.
+
+> Verzeichnis war früher `technitium/` (Technitium verworfen) → umbenannt.

docs/research/dns-registration-options.md

@@ -1,123 +1,107 @@
-# DNS-Registrierung ohne Technitium — Research & Entscheidung (Stand 2026-06-15)
+# Lokale DNS-Auflösung — Research & Entscheidung (Stand 2026-06-15)
 
-> **Kontext:** TP4-Split = **DHCP auf RouterOS, DNS separat**. Technitium wurde verworfen (User-Wunsch:
-> standardnah bleiben, keine All-in-one-GUI-Appliance). Gesucht: saubere, standardisierte DHCP→DNS-Registrierung.
-> **Entscheidung: Variante A** — DHCP bleibt auf RouterOS, RouterOS pusht Lease-Daten per **RFC 2136** an einen
-> schlanken **autoritativen DNS** (BIND9) auf NAS/pve. Diese Datei hält Recherche, Begründung und Config-Skizze fest.
+> **Kontext:** TP4-Split = **DHCP auf RouterOS**, DNS separat. Technitium verworfen (keine GUI-Appliance).
+> Zusätzliche **harte Vorgabe (User):** *Container nur auf den Routern oder gar nicht — keine unnötigen
+> Abhängigkeiten von fremder Hardware (NAS/pve) für Kern-Netzdienste.*
+>
+> **Entscheidung: RouterOS-nativer DNS + nur statische Records.** Keine DHCP→DNS-Auto-Registrierung, kein Script,
+> kein externer DNS-Server. Infra-Hosts werden als statische DNS-Einträge gepflegt (haben ohnehin DHCP-Reservierungen);
+> dynamische Clients (Handys/IoT) sind bewusst **nicht** per Name erreichbar.
 
 ---
 
-## 1. Warum nicht der naive RouterOS-Weg
+## 1. Kann RouterOS das nativ? — Nein (und das ist ein bekannter Gap)
 
-RouterOS hat keine eingebaute DHCP→DNS-Registrierung. Die kursierenden Lösungen:
+Der RouterOS-DNS ist ein **Caching-Forwarder + manuelle statische Einträge** — es gibt **keine** Verbindung zwischen
+DHCP-Leases und DNS, keinen „Lease-Hostnames registrieren"-Schalter. MikroTiks Forum-Antwort dazu war seit Jahren:
+„nimm ein Lease-Script".
 
-| Ansatz | Mechanik | Problem |
-|---|---|---|
-| **Lease-Script (naiv)** | Script am DHCP-Server, läuft bei issue/release/expire | Feuert **nicht bei Renewal** → Gerät erneuert nach Standby seine Lease, bekommt keinen DNS-Eintrag → unzuverlässig ([Ctrl blog](https://www.ctrl.blog/entry/routeros-dhcp-lease-script.html)) |
-| **Hybrid Lease-Script + Scheduler** | [eworm-de `dhcp-to-dns`](https://github.com/eworm-de/routeros-scripts/blob/main/doc/dhcp-to-dns.md): Lease-Script + alle 15 min Reconcile/Cleanup | Zuverlässig, **aber** RouterOS-proprietär, MAC-basierte A-Records (`00-11-22-….domain`), Reverse-DNS mit Hostnames explizit unzuverlässig. DNS bliebe schwacher RouterOS-Forwarder (kein DNSSEC-Validate) |
+Die billige Konkurrenz macht's besser: alles **dnsmasq**-basierte (OpenWrt, pfSense/OPNsense, dd-wrt) und sogar die
+FritzBox liefern lokale Namensauflösung aus DHCP **out-of-the-box** — dnsmasq *ist* DHCP+DNS in einem Prozess.
+**Warum MikroTik nicht:** RouterOS zielt auf ISP/Enterprise-Routing, wo der Router nicht der autoritative LAN-DNS sein
+soll. Die Heim-Bequemlichkeit wurde nie gebaut. → Der „Flickwerk"-Eindruck ist berechtigt.
 
-→ Beide sind **nicht standardnah**. Tauglich nur als Notlösung ohne Extra-Host.
+## 2. Warum die „sauberen" Wege hier ausscheiden
 
-## 2. Der Standard: RFC 2136 (Dynamic DNS Update) + TSIG
+| Weg | Warum verworfen |
+|---|---|
+| **Technitium / AdGuard / dnsmasq auf NAS/pve** | GUI-Appliance + **fremde HW-Abhängigkeit** → gegen User-Vorgabe |
+| **Variante A: RouterOS-DHCP + RFC 2136 → BIND/PowerDNS** (standardnah) | BIND muss *irgendwo* laufen; einziger erlaubter Ort wäre der hAP selbst → **nicht praktikabel** (s.u.). Der saubere Standard verlangt einen Host, den die Vorgabe verbietet. |
+| **Lease-Script-Hybrid (eworm dhcp-to-dns)** | Self-contained, aber genau das **Script-Flickwerk**, das vermieden werden soll; MAC-basierte Records, Reverse-DNS unzuverlässig, Renewal-Lücke ([Ctrl blog](https://www.ctrl.blog/entry/routeros-dhcp-lease-script.html)) |
+| **DNS-Container auf dem hAP** | siehe HW-Check unten — gegen MikroTik-Empfehlung, Flash-Wear, kein USB |
 
-Der herstellerneutrale Weg: DHCP-Server schickt nach jeder Lease ein **TSIG-signiertes RFC-2136-Update** an einen
-**autoritativen** DNS-Server, der die Zone `bf.lan` (+ Reverse) hält.
+### HW-Check ap1 (live, 2026-06-15)
+| | hAP ax² (ap1) |
+|---|---|
+| Flash gesamt / **frei** | 128 MB / **~90 MB** |
+| RAM frei | 680 MB |
+| USB | **keins** |
 
-**RouterOS kann das nativ** — Tool [`/tool dns-update`](https://help.mikrotik.com/docs/spaces/ROS/pages/139067407/Dynamic+DNS) (RFC 2136/3007):
+90 MB frei würden ein winziges Image *theoretisch* fassen, aber: MikroTik empfiehlt für Container **externen Speicher**
+(USB/NVMe — fehlt), das Image konkurriert mit Config/Logs auf demselben Flash, und **Flash-Write-Wear** durch einen
+dauernd schreibenden DNS ist real. → Container-DNS auf dem hAP bleibt **nicht praktikabel** (bestätigt CLAUDE.md/TP-R).
 
-```
-/tool dns-update dns-server=10.40.20.10 zone=bf.lan name=$hostname \
-    address=$leaseActIP key-name=dhcp-key key=<tsig-secret> ttl=300
-```
+→ **Fazit:** Auf dieser Hardware sind „sauberer Standard-DNS" **und** „kein Flickwerk" **und** „keine Fremd-Abhängigkeit"
+nicht gleichzeitig erreichbar. Da die Abhängigkeits-Vorgabe gewinnt, bleibt nur **router-nativ** — und ohne Script heißt
+das: **statische Records**.
 
-**Constraints (wichtig):**
-- TSIG nur **hmac-md5** (kein SHA-256) → der autoritative Server muss diesen (alten, aber unterstützten) Algo zulassen.
-  Im vertrauenswürdigen Server-VLAN (INFRA/20) unkritisch: Integrität, nicht Vertraulichkeit, niedriges Threat-Model.
-- Router-Uhr darf max. **5 min** vom DNS-Server abweichen → NTP ist ohnehin aktiv.
-- `/tool dns-update` ist ein **manuelles Tool** → muss getriggert werden: aus dem **Lease-Script** (sofort) **plus**
-  einem **Scheduler** (Reconcile/Cleanup gegen die Renewal-Lücke). Die eworm-Logik bleibt also als Trigger nützlich,
-  aber das Ziel ist eine **echte autoritative Zone**, kein Forwarder-Cache.
+## 3. Entscheidung: RouterOS-nativer DNS, nur statische Einträge
 
-## 3. Pragmatische Verkleinerung
+**Schlüsseleinsicht:** Auto-Registrierung braucht man fast nur für die dynamische Klientel (Handys/IoT) — und die
+spricht man selten per Name an. Alles, was man wirklich per Name erreicht (NAS, HA, pve, Drucker, AppleTV), hat ohnehin
+eine **statische DHCP-Reservierung**. Diese Hosts als statische DNS-Einträge zu pflegen ist **dieselbe Arbeit** wie die
+Reservierung — kein Mehraufwand, kein Script, keine Abhängigkeit.
 
-Auto-Registrierung braucht man fast nur für die **dynamische Klientel** (Handys/IoT) — und die spricht man selten per
-Name an. Alles, was man wirklich per Name erreicht (NAS, HA, pve, Drucker, AppleTV), hat ohnehin eine **statische
-DHCP-Reservierung**.
+**Umsetzung (in TP4):**
+- RouterOS-DNS aktiv (`/ip dns`), als Resolver für alle VLANs (per DHCP-Option 6 verteilt).
+- Statische Forward-Einträge je Infra-Host: `/ip dns static add name=nas.bf.lan address=10.40.20.10` usw.
+  → gemeinsam mit der DHCP-Reservierung pflegen (eine Stelle, ein Vorgang).
+- Einheitliche lokale Domain `bf.lan`.
+- **Filtering/DNSSEC** standardnah über den **Upstream**: DoH zu Cloudflare/NextDNS (TP3) — filtert + validiert,
+  ohne lokalen Server. Adblock damit am Upstream, nicht lokal.
+- Dynamische Clients: bewusst **keine** Namensauflösung. Falls später doch nötig → Re-Eval (Abschnitt 4).
+- **HA (TP9):** zweiter RouterOS-Resolver auf ap2; statische Einträge müssen auf beiden gepflegt werden
+  (gleiches „identische-Config"-Thema wie DHCP/Firewall).
 
-→ Infra-Hosts als **statische autoritative Records** in `bf.lan` pflegen (fällt bei Reservierungen eh an), RFC-2136-Auto-Reg
-nur optional für den dynamischen Pool. Damit schrumpft das fragile Auto-Reg-Thema auf ein Nice-to-have.
+## 4. Re-Evaluation nur, falls sich eine Randbedingung ändert
 
-**Filtering/DNSSEC** (wofür ursprünglich Technitium gedacht war) standardnah abdecken über:
-- DoH-Upstream zu Cloudflare/NextDNS (filtert + DNSSEC, ist in TP3 ohnehin geplant), **oder**
-- **BIND RPZ** (Response Policy Zones) + DNSSEC-Validierung lokal → BIND ersetzt Technitiums Adblock/DNSSEC nativ.
+- **Auto-Reg dynamischer Clients wird doch gebraucht** → entweder Lease-Script-Hybrid (eworm) akzeptieren
+  *oder* HW-Vorgabe lockern.
+- **HW-Vorgabe gelockert / Router mit USB+Storage** → dann **Variante A** (RouterOS-DHCP + RFC 2136 → BIND9) ist der
+  saubere Standard-Weg. Details/Vergleich im Anhang.
 
 ---
 
-## 4. Autoritativer Server: PowerDNS vs. BIND9
+## Anhang — Variante A & PowerDNS-vs-BIND (parkiert, falls HW-Vorgabe fällt)
 
-Benchmark-Zahlen ([computingforgeeks](https://computingforgeeks.com/bind-vs-dnsmasq-vs-powerdns-vs-unbound/), gecachte Queries):
+**Variante A:** RouterOS-DHCP bleibt am Gateway, pusht Leases per nativem
+[`/tool dns-update`](https://help.mikrotik.com/docs/spaces/ROS/pages/139067407/Dynamic+DNS) (RFC 2136/3007,
+hmac-md5-TSIG, Uhr-Drift max. 5 min) an einen autoritativen DNS. Trigger = Lease-Script + Scheduler-Reconcile.
 
-| Metrik | BIND 9.18 | PowerDNS 4.9 (auth+rec) |
+Benchmark ([computingforgeeks](https://computingforgeeks.com/bind-vs-dnsmasq-vs-powerdns-vs-unbound/), gecacht):
+
+| Metrik | BIND 9.18 | PowerDNS 4.9 |
 |---|---|---|
 | Queries/s | 47.613 | 67.712 |
 | Latenz Ø | 0,29 ms | 0,95 ms |
-| RAM idle | 38 MB | 24 MB |
-| RAM unter Last | 45 MB | 29 MB |
+| RAM idle / Last | 38 / 45 MB | 24 / 29 MB |
 
-> Beide Werte sind für ein Heimnetz **massiv überdimensioniert** (du machst <100 QPS). Performance ist hier **kein**
-> Entscheidungskriterium — der ~10 MB RAM-Unterschied auf NAS/pve ist irrelevant.
+Für ein Heimnetz (<100 QPS) ist Performance irrelevant. Auswahl:
 
-| Kriterium | BIND9 | PowerDNS (Authoritative) |
+| Kriterium | BIND9 | PowerDNS |
 |---|---|---|
-| **Architektur** | Ein Prozess = autoritativ **+** recursive **+** DNSSEC-Validate **+** RPZ | Auth-Server **+** separater Recursor; Auth braucht **Backend** (BIND-Zonefile / LMDB / SQLite / MySQL) |
-| **RFC 2136 / TSIG** | Referenz-Implementierung; alle TSIG-Algos inkl. **hmac-md5** | Unterstützt RFC 2136 + TSIG (hmac-md5 ✓); LMDB-Backend erst seit 5.0; in der Vergangenheit [RFC2136-Regressions zwischen Versionen](https://github.com/PowerDNS/pdns/issues/12332) |
-| **RouterOS-Kompatibilität** | MikroTik-Doku: „**works only with the BIND server**" → explizit dagegen getestet | Sollte gehen (implementiert RFC2136), aber **nicht** das, wogegen RouterOS getestet ist → Restrisiko |
-| **DNSSEC** | Validate **und** Signieren in einem | Signieren ja (Backend); Validierung macht der Recursor |
-| **Filtering/Adblock** | **RPZ** nativ (= Technitium-Ersatz, standardnah) | via Recursor-Lua/Scripts |
-| **Config** | Crustige Syntax, viele Knöpfe; Zonefiles | DB-Backend + API + Web-UI; mehr Komfort, mehr Teile |
-| **RAM (Container)** | ~40–45 MB | ~24–29 MB (+ Recursor extra) |
-| **Reifegrad** | Referenz-Server seit 1980ern, ISC; max. Doku/Community | Sehr reif, modern, gut für DB-getriebene/Multi-Zone-Setups |
-| **Moving parts** | **1 Daemon** deckt alles ab | Auth + Backend (+ Recursor für Rekursion) |
+| Architektur | 1 Prozess = autoritativ + recursive + DNSSEC-Validate + RPZ-Adblock | Auth + separater Recursor + Backend |
+| RFC 2136 / RouterOS | Referenz; MikroTik-Doku: „works only with the BIND server" | implementiert RFC2136, aber nicht das RouterOS-Testziel; [Regressions #12332](https://github.com/PowerDNS/pdns/issues/12332) |
+| Adblock | RPZ nativ (Technitium-Ersatz) | via Recursor-Lua |
+| Moving parts | 1 Daemon deckt alles | mehr Teile, aber API/DB/Web-UI |
 
-### Empfehlung: **BIND9**
-
-Für **Variante A** konkret, drei Gründe:
-1. **RouterOS `/tool dns-update` ist gegen BIND getestet/dokumentiert** — geringstes „funktioniert-es-mit-RouterOS"-Risiko.
-2. **Ein Prozess deckt alles ab**, was Technitium konnte: autoritative `bf.lan`, recursive Resolver, DNSSEC-Validierung,
-   Adblock via RPZ. PowerDNS bräuchte dafür Auth **+** Recursor **+** Backend = mehr Teile.
-3. RFC 2136 + hmac-md5-TSIG ist BIND-Heimspiel.
-
-Kosten: ~10 MB mehr RAM und sperrigere Config — auf NAS/pve egal.
-
-**PowerDNS** ist die Alternative, falls später API/DB-Backend/Web-UI oder viele dynamische Zonen wichtig werden.
-
----
-
-## 5. Config-Skizze Variante A (BIND9)
-
-**DNS-Server** (Container auf NAS/pve, INFRA-VLAN, z.B. `10.40.20.10`):
-- TSIG-Key erzeugen: `tsig-keygen -a hmac-md5 dhcp-key` → Secret in `named.conf` **und** RouterOS hinterlegen.
-- Zone `bf.lan` (primary) + Reverse-Zonen (`10.40.x.in-addr.arpa`), Zonefiles **beschreibbar** (z.B. `/var/lib/bind/`).
-- `allow-update { key dhcp-key; };` auf den dynamischen Zonen.
-- Statische Infra-Records von Hand in der Zone (NAS/HA/pve/Drucker/AppleTV).
-- Optional: recursive + DNSSEC-Validate + RPZ-Blockliste; Upstream-Forward DoH-seitig via TP3 oder direkt.
-
-**RouterOS (hAP#1 als Router, nach Cutover):**
-- DHCP pro VLAN wie geplant.
-- **Lease-Script** ruft `/tool dns-update … name=$hostname address=$leaseActIP` (forward) + Reverse-Update.
-- **Scheduler** (z.B. alle 5–15 min) reconciled alle aktiven Leases → DNS (deckt Renewal/Reboot-Lücke ab).
-- Clients bekommen per DHCP-Option 6 den BIND-Resolver (+ 2. Resolver für HA, TP9).
-
-**HA (TP9):** zweite BIND-Instanz (pve) als **Secondary** der `bf.lan`-Zone (AXFR/IXFR) → DNS redundant.
-DHCP bleibt am Gateway (VRRP), NAS wird **nicht** zur DHCP-Abhängigkeit.
-
----
+→ Falls Variante A je gebaut wird: **BIND9** (gegen RouterOS getestet, ein Prozess deckt alles ab). PowerDNS nur bei
+Bedarf an API/DB-Backend. **Kea + DDNS → BIND** ([Doku](https://kea.readthedocs.io/en/latest/arm/ddns.html)) wäre der
+Lehrbuch-Weg, falls DHCP ohnehin auf einen Host auslagert.
 
 ## Quellen
 - [Don't use RouterOS DHCP lease scripts to manage DNS — Ctrl blog](https://www.ctrl.blog/entry/routeros-dhcp-lease-script.html)
 - [eworm-de/routeros-scripts: dhcp-to-dns](https://github.com/eworm-de/routeros-scripts/blob/main/doc/dhcp-to-dns.md)
 - [MikroTik Dynamic DNS (`/tool dns-update`, RFC 2136/3007)](https://help.mikrotik.com/docs/spaces/ROS/pages/139067407/Dynamic+DNS)
-- [Kea DHCP-DDNS (D2) — Alternative falls DHCP doch auslagert](https://kea.readthedocs.io/en/latest/arm/ddns.html)
-- [PowerDNS: Dynamic DNS Update (RFC 2136)](https://docs.powerdns.com/authoritative/dnsupdate.html) · [PowerDNS TSIG](https://doc.powerdns.com/authoritative/tsig.html) · [RFC2136-Regression #12332](https://github.com/PowerDNS/pdns/issues/12332)
+- [Kea DHCP-DDNS (D2)](https://kea.readthedocs.io/en/latest/arm/ddns.html) · [PowerDNS RFC2136](https://docs.powerdns.com/authoritative/dnsupdate.html)
 - [BIND vs dnsmasq vs PowerDNS vs Unbound — Benchmark](https://computingforgeeks.com/bind-vs-dnsmasq-vs-powerdns-vs-unbound/)
-- [BIND vs PowerDNS vs Knot — Auswahlkriterien](https://ipaddresslocation.net/articles/bind-vs-powerdns-vs-knot-dns-which-authoritative-server-to-choose)

docs/teilprojekte.md

@@ -45,8 +45,8 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen (inline) · Oma
 - Abh.: TP8 (für 802.1X). research: CAPsMAN-bound, mesh.
 
 ### TP4 — Router-Cutover (hAP#1 = Router) ▸ disruptiv, geplant
-- Per-VLAN L3-Interface `.1`, **DHCP** (RouterOS), **DNS = autoritatives BIND9 auf NAS/pve**, **NAT**, FB→**Bridge-Mode/Exposed-Host**.
-- **DNS-Registrierung = Variante A** (Technitium verworfen): RouterOS-DHCP bleibt am Gateway, pusht Leases per **RFC 2136** (`/tool dns-update`, hmac-md5-TSIG) an BIND. Lease-Script + Scheduler-Reconcile; Infra-Hosts als statische Records. Detail/Begründung/PowerDNS-Vergleich: `docs/research/dns-registration-options.md`.
+- Per-VLAN L3-Interface `.1`, **DHCP** (RouterOS), **DNS = RouterOS-nativ + nur statische Records**, **NAT**, FB→**Bridge-Mode/Exposed-Host**.
+- **DNS-Entscheidung** (Technitium **und** externer BIND verworfen — Vorgabe: kein Container außer am Router, keine NAS/pve-Abhängigkeit; hAP kann praktikabel keinen DNS-Container hosten): RouterOS-DNS als Resolver, **keine DHCP→DNS-Auto-Registrierung**. Infra-Hosts (haben eh DHCP-Reservierungen) als statische `/ip dns static`-Einträge unter `bf.lan`; dynamische Clients bewusst ohne Namen. Filtering/DNSSEC via DoH-Upstream (TP3). HA: 2. Resolver auf ap2, statische Einträge beidseitig pflegen. Begründung/parkierte Variante A: `docs/research/dns-registration-options.md`.
 - **FB-Bridge testen** (LAN4-Native-Bridge-Hack) → kein Double-NAT; sonst Exposed-Host-Fallback.
 - Abh.: TP1, TP3. Ziel: VLAN-SSILs nutzbar + Telefonie-Fix aktiv.