# 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](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 | ### 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.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). ## 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`](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. 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 / 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](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 | → 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)](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/)