108 lines
6.8 KiB
Markdown
108 lines
6.8 KiB
Markdown
# 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/)
|