Files

Christoph Emsenhuber ae4d1e5fcd TP4 DNS: Variante A (RouterOS-DHCP + RFC2136 → BIND9), Technitium verworfen

- Research-Doc: DHCP→DNS-Registrierung standardnah, PowerDNS-vs-BIND9-Vergleich
- teilprojekte TP4 auf BIND9 + RFC2136 umgestellt + Verweis; HW-Notiz angepasst

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

2026-06-15 11:24:05 +02:00

8.2 KiB

Raw Blame History

DNS-Registrierung ohne Technitium — 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.

1. Warum nicht der naive RouterOS-Weg

RouterOS hat keine eingebaute DHCP→DNS-Registrierung. Die kursierenden Lösungen:

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)
Hybrid Lease-Script + Scheduler	eworm-de `dhcp-to-dns`: 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)

→ Beide sind nicht standardnah. Tauglich nur als Notlösung ohne Extra-Host.

2. Der Standard: RFC 2136 (Dynamic DNS Update) + TSIG

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.

RouterOS kann das nativ — Tool /tool dns-update (RFC 2136/3007):

/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

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. Pragmatische Verkleinerung

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.

→ 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.

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.

4. Autoritativer Server: PowerDNS vs. BIND9

Benchmark-Zahlen (computingforgeeks, gecachte Queries):

Metrik	BIND 9.18	PowerDNS 4.9 (auth+rec)
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

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.

Kriterium	BIND9	PowerDNS (Authoritative)
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
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)

Empfehlung: BIND9

Für Variante A konkret, drei Gründe:

RouterOS /tool dns-update ist gegen BIND getestet/dokumentiert — geringstes „funktioniert-es-mit-RouterOS"-Risiko.
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.
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.

8.2 KiB Raw Blame History Unescape Escape