Christoph Emsenhuber
e15edc22d7
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>
6.8 KiB
Lokale DNS-Auflösung — Research & Entscheidung (Stand 2026-06-15)
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. Kann RouterOS das nativ? — Nein (und das ist ein bekannter Gap)
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".
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.
2. Warum die „sauberen" Wege hier ausscheiden
| 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) |
| DNS-Container auf dem hAP | siehe HW-Check unten — gegen MikroTik-Empfehlung, Flash-Wear, kein USB |
HW-Check ap1 (live, 2026-06-15)
| hAP ax² (ap1) | |
|---|---|
| Flash gesamt / frei | 128 MB / ~90 MB |
| RAM frei | 680 MB |
| USB | keins |
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).
→ 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.
3. Entscheidung: RouterOS-nativer DNS, nur statische Einträge
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.
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.10usw. → 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).
4. Re-Evaluation nur, falls sich eine Randbedingung ändert
- 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.
Anhang — Variante A & PowerDNS-vs-BIND (parkiert, falls HW-Vorgabe fällt)
Variante A: RouterOS-DHCP bleibt am Gateway, pusht Leases per nativem
/tool dns-update (RFC 2136/3007,
hmac-md5-TSIG, Uhr-Drift max. 5 min) an einen autoritativen DNS. Trigger = Lease-Script + Scheduler-Reconcile.
Benchmark (computingforgeeks, gecacht):
| Metrik | BIND 9.18 | PowerDNS 4.9 |
|---|---|---|
| Queries/s | 47.613 | 67.712 |
| Latenz Ø | 0,29 ms | 0,95 ms |
| RAM idle / Last | 38 / 45 MB | 24 / 29 MB |
Für ein Heimnetz (<100 QPS) ist Performance irrelevant. Auswahl:
| Kriterium | BIND9 | PowerDNS |
|---|---|---|
| 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 |
| Adblock | RPZ nativ (Technitium-Ersatz) | via Recursor-Lua |
| Moving parts | 1 Daemon deckt alles | mehr Teile, aber API/DB/Web-UI |
→ 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) wäre der Lehrbuch-Weg, falls DHCP ohnehin auf einen Host auslagert.