Hochverfügbares DNS im Homelab mit Technitium und UniFi

DNS gehört zu den Diensten, die im Homelab kaum auffallen – bis sie fehlen. Viele Anwendungen funktionieren dann scheinbar „irgendwie nicht“, obwohl Netzwerk und Server erreichbar sind. Ich wollte deshalb zwei voneinander unabhängige DNS-Server betreiben, die interne Namen zuverlässig auflösen und beim Ausfall eines Knotens weiterarbeiten.

Das Ergebnis sind zwei Raspberry Pi 4 mit Technitium DNS Server. dns01 hält die Primary Zone, dns02 erhält sie per AXFR/IXFR und NOTIFY als Secondary. Beide arbeiten außerdem als rekursive Resolver. Die UniFi Dream Machine verteilt beide Adressen per DHCP an die Clients.

Diese Anleitung zeigt den Aufbau von Anfang bis Ende. IP-Adressen und Domain sind Beispiele – vor der Umsetzung bitte an das eigene Netz anpassen.

Zielarchitektur

Die Raspberry Pis stehen physisch getrennt und erhalten feste Adressen. Beide werden den Clients gleichwertig als Resolver angeboten. „Primary“ und „Secondary“ beziehen sich nur auf die Verwaltung der autoritativen Zone – nicht auf eine aktive/passive Client-Nutzung.

Voraussetzungen

• zwei Raspberry Pi 4 oder vergleichbare Linux-Systeme,
• aktuelles 64-bit Raspberry Pi OS Lite,
• feste DHCP Reservations oder statische IP-Konfiguration,
• administrativer Zugriff auf UniFi Network,
• Zugriff per SSH,
• ein eigener interner Subdomain-Name, der nicht .local verwendet.

.local ist für Multicast DNS reserviert und kann je nach Client zu schwer nachvollziehbaren Auflösungswegen führen. Für neue Einträge nutze ich daher home.example.net. Die vorhandenen UniFi-Namen unter .local bleiben während der Migration erreichbar.

1. Beide Raspberry Pis vorbereiten

Zuerst Hostnamen und Betriebssystem aktualisieren. Auf dem ersten Pi:

sudo hostnamectl set-hostname dns01
sudo apt update
sudo apt full-upgrade
sudo reboot

Auf dem zweiten Pi wird entsprechend dns02 gesetzt. Danach prüfen, ob beide Adressen dauerhaft stimmen und sich gegenseitig erreichen:

hostname -f
ip address
ping -c 3 192.168.10.54

Die IPs sollten über DHCP Reservations an die MAC-Adressen gebunden oder im Betriebssystem statisch konfiguriert sein. Zwei DNS-Server mit wechselnden Adressen wären keine stabile Basis.

2. Technitium installieren

Technitium stellt für Linux und Raspberry Pi ein Installationsskript bereit. Vor der Ausführung sollte ein aus dem Internet geladenes Skript immer geprüft werden; danach erfolgt die Installation auf beiden Pis:

curl -sSL https://download.technitium.com/dns/install.sh -o install-technitium.sh
less install-technitium.sh
sudo bash install-technitium.sh

Anschließend ist die Web Console standardmäßig über Port 5380 erreichbar:

http://192.168.10.53:5380/
http://192.168.10.54:5380/

Beim ersten Login sofort ein langes, einzigartiges Admin-Passwort setzen. Der Management-Port wird nicht ins Internet und möglichst nur in ein Admin VLAN freigegeben. Port 53/TCP und 53/UDP benötigen nur die Netze, die DNS verwenden dürfen. Für Zone Transfers muss dns02 dns01 auf Port 53/TCP erreichen können.

3. Rekursive Auflösung testen

Bevor interne Zonen hinzukommen, teste ich jeden Resolver direkt:

dig @192.168.10.53 www.iana.org A
dig @192.168.10.54 www.iana.org A

Beide Antworten sollten status: NOERROR liefern. Dabei nicht nur auf eine IP-Adresse schauen, sondern auch auf den tatsächlich angesprochenen Server und die Antwortzeit.

In Technitium lassen sich Forwarders konfigurieren oder die eingebaute rekursive Auflösung verwenden. Für mein Ziel arbeiten beide Server unabhängig: Fällt ein Pi aus, hängt der andere nicht von ihm als Upstream ab.

4. Primary Zone auf dns01 anlegen

Auf dns01 in der Web Console:

1. Zones öffnen.
2. Add Zone wählen.
3. Zone Name home.example.net eintragen.
4. Type Primary Zone wählen.
5. Zone erstellen.

Danach werden mindestens die beiden Nameserver als Records benötigt:

Als ersten Testeintrag lege ich beispielsweise nas.home.example.net mit der internen Adresse des NAS an.

dig @192.168.10.53 home.example.net SOA
dig @192.168.10.53 home.example.net NS
dig @192.168.10.53 nas.home.example.net A

5. Zone Transfer und NOTIFY absichern

Auf dns01 öffne ich die Zone Options von home.example.net.

• Zone Transfer: Use Specified Network ACL
• erlaubte Adresse: ausschließlich 192.168.10.54
• Notify: Specified Name Servers oder Zone Name Servers
• Notify-Ziel: 192.168.10.54
• Dynamic Update: Deny, solange es nicht bewusst benötigt wird

Ein offener Zone Transfer würde internen Namensraum unnötig preisgeben. Im Homelab genügt meist die einzelne Secondary-IP als ACL. Für höhere Absicherung unterstützt Technitium zusätzlich TSIG; dann müssen Schlüsselname und Secret auf beiden Seiten übereinstimmen.

AXFR überträgt die vollständige Zone, IXFR nur Änderungen. NOTIFY informiert die Secondary unmittelbar über einen neuen Serial. Ohne NOTIFY würde sie erst beim nächsten SOA Refresh nachsehen.

6. Secondary Zone auf dns02 anlegen

Auf dns02:

1. Zones → Add Zone öffnen.
2. home.example.net eintragen.
3. Type Secondary Zone wählen.
4. Als Primary Name Server 192.168.10.53 angeben.
5. Transfer Protocol auf TCP belassen; bei TSIG den vereinbarten Schlüssel auswählen.
6. Zone erstellen.

Kurz danach sollten dieselben Records sichtbar sein. Die Serial Numbers müssen übereinstimmen:

dig @192.168.10.53 home.example.net SOA +short
dig @192.168.10.54 home.example.net SOA +short
dig @192.168.10.54 nas.home.example.net A +short

Nun auf dns01 einen weiteren Testrecord anlegen und beobachten, ob er ohne manuelles Eingreifen auf dns02 erscheint. Falls nicht, prüfe ich zuerst:

• Port 53/TCP zwischen den Pis,
• Zone Transfer ACL auf dns01,
• Primary-Adresse auf dns02,
• NOTIFY-Ziel und Event Logs,
• SOA Serial auf beiden Seiten.

7. Legacy-Namen aus UniFi weiterreichen

Während der Migration existieren noch Hostnamen unter .local, die UniFi kennt. Auf beiden Technitium-Servern lege ich dafür eine Conditional Forwarder Zone für local an und trage die UDM-Adresse 192.168.10.1 als Forwarder ein.

Damit gilt:

• neue, selbst gepflegte Namen: home.example.net,
• alte UniFi-Namen: Weiterleitung an die UDM,
• öffentliche Namen: rekursive Auflösung beziehungsweise normale Forwarders.

Diese Übergangslösung wird auf beiden Resolvern separat konfiguriert. Sie verhindert, dass der Ausfall von dns01 gleichzeitig die Legacy-Auflösung auf dns02 unbrauchbar macht.

8. DNS per UniFi DHCP verteilen

In UniFi Network werden die DNS-Server pro Virtual Network konfiguriert. In der aktuellen Oberfläche liegt die Einstellung typischerweise unter:

Settings → Networks → [Netzwerk] → DHCP Service Management → DNS Server

Dort trage ich beide Adressen ein:

1. 192.168.10.53
2. 192.168.10.54

Als Domain Name beziehungsweise Search Domain verwende ich home.example.net. Nach dem Speichern müssen Clients ihren DHCP Lease erneuern oder neu verbunden werden.

Wichtig: Viele Clients behandeln den ersten DNS-Server nicht strikt als Primary und den zweiten als Backup. Sie können beide parallel oder nach eigener Logik verwenden. Deshalb müssen beide Server jederzeit vollständige und korrekte Antworten liefern.

Mein Work VLAN bleibt bewusst von dieser Lösung unabhängig und verwendet weiterhin den durch UniFi vorgegebenen Resolver. So bleiben private Namen und Experimente aus dem beruflich genutzten Segment herausgehalten.

9. Testmatrix

Vor dem produktiven Einsatz teste ich nicht nur einzelne Queries, sondern die vorgesehenen Pfade:

# interne Zone direkt gegen beide Resolver
dig @192.168.10.53 nas.home.example.net A
dig @192.168.10.54 nas.home.example.net A

# autoritative Daten und Serial
dig @192.168.10.53 home.example.net SOA
dig @192.168.10.54 home.example.net SOA

# öffentlicher Name
dig @192.168.10.53 www.iana.org A
dig @192.168.10.54 www.iana.org A

# Legacy-Ziel über Conditional Forwarder
dig @192.168.10.53 vorhandener-host.local A
dig @192.168.10.54 vorhandener-host.local A

# vom Client verwendete Resolver prüfen
scutil --dns        # macOS
resolvectl status   # Linux mit systemd-resolved
ipconfig /all       # Windows

Für jeden VLAN-Typ prüfe ich internen Namen, öffentlichen Namen, bewusst nicht existierenden Namen und einen blockierten Pfad. NXDOMAIN ist dabei ebenfalls ein wichtiges korrektes Ergebnis.

10. Kontrollierter Ausfalltest

Hochverfügbarkeit ist erst nach einem Test eine belastbare Aussage.

1. Auf einem Client den DHCP Lease erneuern und prüfen, ob beide DNS-Adressen vorhanden sind.
2. Wiederholt interne und öffentliche Namen auflösen.
3. dns01 sauber herunterfahren: sudo poweroff.
4. Caches berücksichtigen und neue, noch nicht abgefragte Namen testen.
5. Applikationen öffnen, die DNS aktiv benötigen.
6. Antwortzeiten und Fehler beobachten.
7. dns01 wieder starten und prüfen, ob beide SOA Serials übereinstimmen.
8. Den Test umgekehrt mit dns02 wiederholen.

Ein Client-Cache kann einen Fehler verdecken. Deshalb verwende ich für den Test zusätzlich direkte dig-Abfragen und neue Testrecords.

Backup und Wiederherstellung

Redundanz ersetzt kein Backup. Eine versehentlich gelöschte Zone wird sonst zuverlässig auf beide Server übertragen. Ich sichere deshalb regelmäßig:

• die Technitium-Konfiguration beider Server,
• Zone Files und Settings,
• eine lesbare Dokumentation der IPs, ACLs und DHCP-Werte,
• das Admin-Passwort im Password Manager,
• die verwendeten TSIG Secrets, falls aktiviert.

Der Restore wird mindestens einmal auf einem temporären System getestet. Für einen schnellen Rollback halte ich außerdem fest, wie UniFi DHCP kurzfristig wieder auf die UDM oder einen externen Resolver umgestellt werden kann.

Betrieb und Härtung

• Web Console nur aus einem Admin-Netz erreichbar machen.
• DNS-Anfragen per Firewall auf interne VLANs begrenzen.
• Zone Transfers ausschließlich zur Secondary erlauben.
• Software und Raspberry Pi OS regelmäßig aktualisieren.
• Logs und Speicherplatz beobachten.
• Netzteile und SD-Karten beziehungsweise SSDs nicht als identische Single Points of Failure behandeln.
• Änderungen zuerst an einem dokumentierten Testrecord validieren.
• Keine internen Zonen versehentlich an öffentliche Upstreams forwarden.

Nächster Schritt: interne Zertifikate

Mit einer stabilen internen Zone entsteht eine gute Basis für einen Reverse Proxy und automatisierte Zertifikate. Für nicht öffentlich erreichbare Dienste eignet sich ACME DNS-01, weil der Nachweis über einen DNS TXT Record erfolgt. Bevor Dynamic Updates aktiviert werden, sollte dafür ein eigener, eng begrenzter TSIG Key oder eine delegierte Challenge-Zone verwendet werden.

Der wichtigste Lerneffekt dieses Projekts: Zwei Server allein ergeben noch keine Hochverfügbarkeit. Erst unabhängige Rekursion, korrekte Zonenreplikation, DHCP-Verteilung, dokumentierter Fallback und ein echter Ausfalltest machen daraus einen belastbaren Dienst.

Quellen

• Technitium DNS Server – offizielles Repository
• Technitium DNS Server API und Zonenoptionen
• UniFi DHCP Server
• UniFi DNS Records and Local Hostnames

Ursprünglichen Beitrag auf LinkedIn öffnen ↗