DNS im Homelab: Warum Pi-hole als Filter vor Technitium als autoritativem Server läuft

DNS ist eine dieser unsichtbaren Infrastrukturen, die im Hintergrund laufen und erst auffallen, wenn sie nicht funktionieren. In meinem Homelab habe ich mich für eine Architektur entschieden, die Security und Flexibilität vereint: Pi-hole als Filter für alle DNS-Anfragen und Technitium als autoritativen Server, der die interne und externe Auflösung von rektor.at steuert. Der Grund ist simpel: Ich will nicht nur Werbung und Tracker blockieren, sondern auch die Kontrolle über meine Domains behalten – ohne Kompromisse bei der Performance oder der Privatsphäre.

Warum Pi-hole als erster Filter?

Pi-hole ist in erster Linie ein DNS-Filter, der Werbung, Tracker und bekannte Malware-Domains blockiert. Das Problem dabei: Viele dieser Listen sind statisch und enthalten oft falsch-positive Einträge, die legitime Dienste blockieren können. In einem Homelab, in dem Dienste wie Home Assistant, Nextcloud oder Perun laufen, kann das schnell zu unerklärlichen Fehlern führen.

Ich nutze Pi-hole trotzdem als ersten Filter, aber nicht als alleinige Lösung. Stattdessen fungiert es als eine Art „Vorfilter“, der offensichtliche Übeltäter aussortiert, bevor die Anfragen an Technitium weitergeleitet werden. Technitium übernimmt dann die eigentliche Auflösung – mit der Möglichkeit, interne und externe Anfragen zu trennen (Split-Horizon). Das hat mehrere Vorteile:

• Performance: Pi-hole filtert die offensichtlichen Requests heraus, bevor sie Technitium erreichen. Das reduziert die Last auf dem autoritativen Server und beschleunigt die Antwortzeiten für legitime Anfragen.
• Flexibilität: Technitium kann gezielt Regeln für interne und externe Auflösungen definieren. Beispielsweise können interne Dienste wie homeassistant.rektor.at oder nextcloud.rektor.at auf lokale IPs aufgelöst werden, während öffentliche Anfragen an rektor.at auf die externe IP weitergeleitet werden.
• Privatsphäre: Pi-hole blockiert nicht nur Werbung, sondern auch DNS-Anfragen an Tracker und Analytics-Dienste. Da die Anfragen erst nach dem Filter an Technitium gehen, bleibt die eigentliche Auflösung anonym – es sei denn, ich entscheide mich, gezielt Logging zu aktivieren.
• Redundanz: Falls Technitium einmal ausfällt, kann Pi-hole als Notlösung dienen – allerdings ohne Split-Horizon-Funktionalität. Das ist zwar nicht ideal, aber besser als gar kein DNS.

Ein weiterer Punkt: Pi-hole läuft auf einem Raspberry Pi, während Technitium auf einem leistungsstarken Server (z. B. einem Intel-NUC) läuft. Die Kombination aus beiden Systemen verteilt die Last und nutzt die Stärken jedes Tools.

Technitium als autoritativer Server mit Split-Horizon

Technitium DNS Server ist ein kostenloser, Open-Source-DNS-Server, der sich hervorragend für kleine bis mittelgroße Netzwerke eignet. Der große Vorteil: Er unterstützt Split-Horizon, also die Trennung zwischen interner und externer Auflösung derselben Domain. Das ist besonders nützlich, wenn man wie ich sowohl interne Dienste als auch öffentliche Websites hostet.

In meiner Architektur sieht das so aus:

• Interne Auflösung: Anfragen von Geräten innerhalb meines LANs werden auf lokale IPs aufgelöst. Beispielsweise wird rektor.at intern auf die IP des Webservers aufgelöst, der hinter dem Reverse Proxy läuft. Gleichzeitig werden Dienste wie homeassistant.rektor.at oder perun.rektor.at direkt auf ihre jeweiligen lokalen IPs weitergeleitet.
• Externe Auflösung: Anfragen von außerhalb meines Netzwerks werden auf die öffentliche IP von rektor.at aufgelöst. Technitium leitet diese Anfragen dann an den Reverse Proxy weiter, der die entsprechenden Dienste über Port-Forwarding oder VPN-Zugriff verfügbar macht.
• Split-Horizon-Regeln: Technitium erlaubt es, gezielt zu definieren, welche Subdomains intern und welche extern aufgelöst werden sollen. Das ist besonders nützlich, wenn man Dienste wie Postiz oder Nextcloud sowohl intern als auch extern verfügbar machen will – aber mit unterschiedlichen Auflösungen.

Ein konkretes Beispiel: Wenn ich von meinem Laptop aus nextcloud.rektor.at aufrufe, wird die Anfrage intern auf die lokale IP des Nextcloud-Servers aufgelöst. Wenn ich das Gleiche von einem öffentlichen Netzwerk aus mache, wird die Anfrage auf die öffentliche IP weitergeleitet – und der Reverse Proxy leitet mich dann an den internen Nextcloud weiter, sofern ich authentifiziert bin.

Das hat zwei Vorteile: Erstens bleibt die interne Kommunikation lokal und performant, zweitens kann ich öffentliche Dienste gezielt exponieren, ohne die interne Netzwerkstruktur preiszugeben.

Die DNS-Kette: Pi-hole → Technitium → Upstream

Die eigentliche Architektur ist eine Kette aus drei Komponenten:

1. Pi-hole: Empfängt alle DNS-Anfragen und filtert Werbung/Tracker heraus. Die verbleibenden Anfragen werden an Technitium weitergeleitet.
2. Technitium: Nimmt die gefilterten Anfragen entgegen und löst sie entweder intern (Split-Horizon) oder extern auf. Interne Auflösungen gehen direkt an die lokalen IPs, externe Anfragen werden an den Upstream-DNS-Server (z. B. Cloudflare oder Google DNS) weitergeleitet.
3. Upstream-DNS: Falls Technitium eine Anfrage nicht selbst auflösen kann (z. B. für externe Domains), leitet es die Anfrage an einen vertrauenswürdigen Upstream-Server weiter. In meinem Fall nutze ich Cloudflare DNS, da es DNS-over-HTTPS (DoH) und DNSSEC unterstützt.

Diese Kette hat mehrere Vorteile:

• Sicherheit: Pi-hole blockiert schädliche Domains, bevor sie Technitium erreichen. Technitium übernimmt dann die sichere Auflösung mit Split-Horizon.
• Performance: Pi-hole reduziert die Last auf Technitium, indem es offensichtliche Requests herausfiltert. Technitium wiederum beschleunigt die Auflösung interner Anfragen, indem es direkt auf lokale IPs zugreift.
• Flexibilität: Split-Horizon erlaubt es mir, interne und externe Auflösungen gezielt zu steuern. Das ist besonders nützlich, wenn man Dienste wie Home Assistant oder Nextcloud sowohl lokal als auch remote nutzen will.
• Transparenz: Da Technitium Open Source ist, kann ich die Konfiguration und die Logs selbst einsehen. Pi-hole bietet ebenfalls detaillierte Statistiken, sodass ich nachvollziehen kann, welche Domains blockiert wurden.

Ein weiterer Punkt: Beide Systeme laufen auf meiner Infrastruktur – es gibt keine Abhängigkeit von externen DNS-Anbietern. Das ist wichtig, weil ich die Kontrolle über meine eigene Domain behalten will. Externe DNS-Anbieter können zwar praktisch sein, aber sie sind auch ein potenzielles Risiko: Was passiert, wenn der Anbieter die Domain sperrt oder die DNS-Einträge manipuliert? Mit dieser Architektur umgehe ich das Problem.

Praktische Umsetzung: Konfiguration und Fallstricke

Die Umsetzung dieser Architektur erfordert einige Konfiguration, aber sie ist machbar – auch ohne tiefgehende DNS-Kenntnisse. Hier die wichtigsten Schritte:

• Pi-hole einrichten: Pi-hole wird als primärer DNS-Server im Netzwerk konfiguriert. Alle Geräte im LAN nutzen Pi-hole als DNS-Resolver. Pi-hole leitet die Anfragen dann an Technitium weiter. Wichtig: In den Pi-hole-Einstellungen muss die Weiterleitung an Technitium als „Upstream DNS“ konfiguriert werden.
• Technitium konfigurieren: Technitium wird als autoritativer Server für rektor.at eingerichtet. Dazu müssen Zone-Dateien für die interne und externe Auflösung erstellt werden. Für die interne Auflösung können lokale IPs verwendet werden, für die externe Auflösung die öffentliche IP der Domain.
• Split-Horizon aktivieren: Technitium muss so konfiguriert werden, dass es Anfragen basierend auf der Quelle auflöst. In Technitium gibt es dafür die Möglichkeit, „Views“ zu definieren – also unterschiedliche Zonen für interne und externe Anfragen. Alternativ kann man auch Conditional Forwarding nutzen, um interne Anfragen an einen lokalen Resolver weiterzuleiten.
• Reverse Proxy anpassen: Der Reverse Proxy (z. B. Nginx Proxy Manager) muss so konfiguriert werden, dass er sowohl interne als auch externe Anfragen korrekt weiterleitet. Das bedeutet, dass der Proxy die Domain rektor.at sowohl auf lokale als auch auf öffentliche IPs auflösen können muss. Hier kommt die Split-Horizon-Funktionalität von Technitium ins Spiel.
• Firewall-Regeln prüfen: Da Technitium sowohl interne als auch externe Anfragen bearbeitet, müssen die Firewall-Regeln (z. B. UFW) so konfiguriert sein, dass sie sowohl lokalen als auch öffentlichen Traffic zulassen. Gleichzeitig sollte der Zugriff auf Technitium nur aus dem lokalen Netzwerk erlaubt sein, um Angriffe von außen zu verhindern.

Ein häufiger Fallstrick ist die falsche Konfiguration der Zone-Dateien in Technitium. Wenn man z. B. die interne Auflösung von rektor.at auf eine lokale IP setzt, aber die externe Auflösung auf die öffentliche IP, muss man sicherstellen, dass der Reverse Proxy beide Auflösungen korrekt verarbeitet. Andernfalls kann es zu unerwarteten Redirects oder Fehlern kommen.

Ein weiterer Punkt: DNSSEC sollte aktiviert werden, um Man-in-the-Middle-Angriffe zu verhindern. Technitium unterstützt DNSSEC, sodass man die Signatur der Zone-Dateien prüfen kann. Das ist besonders wichtig, wenn man öffentliche Dienste über rektor.at anbietet.

Wann lohnt sich diese Architektur – und wann nicht?

Diese Architektur ist nicht für jeden geeignet. Hier eine kurze Einschätzung, für wen sie sinnvoll ist:

• Vorteile für Homelab-Betreiber:
  • Vollständige Kontrolle über die DNS-Auflösung – keine Abhängigkeit von externen Anbietern.
  • Split-Horizon ermöglicht eine saubere Trennung zwischen internen und externen Diensten.
  • Pi-hole als Vorfilter reduziert Werbung und Tracker, ohne die Performance zu beeinträchtigen.
  • Technitium als autoritativer Server bietet Flexibilität und Sicherheit.
• Nachteile und Einschränkungen:
  • Aufwand: Die Einrichtung erfordert Zeit und Wissen – besonders bei der Konfiguration von Split-Horizon und DNSSEC.
  • Hardware: Pi-hole läuft auf einem Raspberry Pi oder ähnlichem, Technitium benötigt etwas mehr Leistung. In einem Homelab ist das kein Problem, aber in einer reinen Produktionsumgebung könnte das ein Overhead sein.
  • Wartung: Beide Systeme müssen regelmäßig aktualisiert werden, um Sicherheitslücken zu schließen.
  • Komplexität: Für einfache Netzwerke ist diese Architektur überdimensioniert. Wer nur ein paar Geräte im LAN hat, kommt mit einem einfachen DNS-Server (z. B. dnsmasq) oder einem Cloud-DNS-Anbieter aus.

Für mich überwiegen die Vorteile klar. Ich hoste nicht nur meine Domain, sondern auch interne Dienste wie Home Assistant, Nextcloud und Perun. Die Kombination aus Pi-hole und Technitium gibt mir die Kontrolle, die ich brauche – ohne Kompromisse bei der Sicherheit oder Performance.

Fazit

DNS im Homelab ist kein Hexenwerk, aber es erfordert Planung. Die Architektur mit Pi-hole als Vorfilter und Technitium als autoritativem Server mit Split-Horizon ist eine robuste Lösung, die Sicherheit, Performance und Flexibilität vereint. Sie ist nicht für jeden geeignet, aber für Betreiber, die ihre Domain selbst hosten und sowohl interne als auch externe Dienste verwalten wollen, ist sie eine der besten Optionen.

Der größte Vorteil ist die Kontrolle: Ich entscheide selbst, welche Domains blockiert werden, wie die Auflösung funktioniert und wer auf meine Dienste zugreifen darf. Das ist in einer Zeit, in der viele Dienste auf externe DNS-Anbieter angewiesen sind, ein Luxus – und gleichzeitig eine Notwendigkeit, um die Privatsphäre und Sicherheit zu wahren.

Wer also vor der Frage steht, wie man DNS im Homelab am besten aufbaut, sollte sich diese Architektur ansehen. Sie ist nicht perfekt, aber sie funktioniert – und das ist in der IT oft schon genug.