admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
- 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>
This commit is contained in:
Christoph Emsenhuber
2026-06-15 11:24:05 +02:00
parent 3ae7321865
commit ae4d1e5fcd
2 changed files with 126 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

123
docs/research/dns-registration-options.md Normal file
View File

@@ -0,0 +1,123 @@
# 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](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) |
→ 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`](https://help.mikrotik.com/docs/spaces/ROS/pages/139067407/Dynamic+DNS) (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](https://computingforgeeks.com/bind-vs-dnsmasq-vs-powerdns-vs-unbound/), 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](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) |
### 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.
---
## 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)
- [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)

5
docs/teilprojekte.md
View File

@@ -23,7 +23,7 @@ ALLNET-Core `.11` (FW2.2.1, VLANs 10/20/30/40/90/99/100 benannt; GE8→Trunk in
2× hAP ax² (7.23.1): ap1 `.1` (Core P1), ap2 `.2` (Core P2 — **bleibt vorerst**). FB6660 = Router/Telefon (`.254`).
Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen (inline) · Omada → Controller (TP2).
> ⚠️ **HW-Constraint hAP ax²:** 1 GB RAM, aber nur **128 MB Flash + KEIN USB** → **Container auf dem Router NICHT praktikabel**.
> Folge: **native RouterOS-Features bevorzugen** (z.B. Built-in-mDNS statt Container); Container (mDNS-Reflector, Technitium, Omada-Controller) laufen auf **NAS/pve**, nicht am hAP.
> Folge: **native RouterOS-Features bevorzugen** (z.B. Built-in-mDNS statt Container); Container (mDNS-Reflector, BIND9-DNS, Omada-Controller) laufen auf **NAS/pve**, nicht am hAP.
---
@@ -45,7 +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=Technitium**, **NAT**, FB→**Bridge-Mode/Exposed-Host**.
- 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`.
- **FB-Bridge testen** (LAN4-Native-Bridge-Hack) → kein Double-NAT; sonst Exposed-Host-Fallback.
- Abh.: TP1, TP3. Ziel: VLAN-SSILs nutzbar + Telefonie-Fix aktiv.