Von Pi-hole zu Technitium: Ein Server für Blocking, DNSSEC und native HA

In einem früheren Beitrag haben wir Pi-hole und AdGuard Home für netzwerkweites Adblocking verglichen. Wir haben Pi-hole v6 eine Weile produktiv betrieben — und waren zufrieden. Dann wurde Hochverfügbarkeit zum Knackpunkt, und wir haben beide Resolver auf Technitium DNS Server umgezogen. Hier die ehrliche Geschichte: warum, und was wir dabei gewonnen haben.

Der Auslöser: eine HA-Synchronisierung, die keine war

DNS ist kritische Infrastruktur. Ein einzelner Resolver ist ein Single Point of Failure, also betreiben wir zwei — primär und sekundär — und Blocklisten wie Einstellungen müssen zwischen beiden synchron bleiben. Pi-hole hat keine native Synchronisierung zwischen Knoten, also haben wir ein Drittanbieter-Tool davorgeschnallt.

Genau dieses Anbau-Teil ist uns zum Verhängnis geworden. In einer Nacht hat der „Full Sync"-Modus die beiden Datenbanken nicht zusammengeführt, sondern die Blocking-Datenbank des Primärknotens durch eine leere ersetzt. Das Blocking war netzwerkweit tot, die Replikation kaputt. Wir haben aus einem Backup wiederhergestellt — aber die Lehre war eindeutig: Eine Synchronisierung, die den Primärknoten löschen kann, ist keine Hochverfügbarkeit. Wir wollten kein fragiles Add-on um ein Werkzeug herumflicken, das nie fürs Clustern gedacht war.

Was Technitium ist

Technitium DNS Server ist ein kostenloser, quelloffener, plattformübergreifender DNS-Server. Während Pi-hole und AdGuard in erster Linie Adblocker sind, die zufällig DNS sprechen, ist Technitium ein vollwertiger DNS-Server — autoritative Zonen, rekursive Auflösung, Conditional Forwarding, DNSSEC, verschlüsseltes DNS (DoH/DoT/DoQ) — der zusätzlich blockt, per App. Genau dieser Unterschied im Funktionsumfang ist der Punkt.

Was wir gewonnen haben

Der Umzug auf Technitium hat einen Stapel Workarounds durch eingebaute Funktionen ersetzt:

• Natives Clustering. Ein Primär- und ein Sekundärknoten, zu einem Cluster verbunden. Blocklisten, Allow/Deny-Regeln, Apps und Zonen werden am Primärknoten gepflegt und synchronisieren automatisch auf den Sekundärknoten — über Notify/Refresh, nicht über ein destruktives Komplett-Überschreiben. Genau dafür sind wir gekommen.
• DNSSEC-Validierung. Jetzt standardmäßig aktiv. Gefälschte oder manipulierte DNS-Antworten werden abgewiesen.
• Verschlüsselter Upstream (DoT). Unsere Resolver leiten per DNS-over-TLS auf Port 853 an öffentliche Upstreams weiter, statt im Klartext über Port 53. Niemand auf dem Weg sieht unsere Anfragen.
• Advanced Blocking. Dutzende Blocklisten-URLs plus exakte Allow/Deny-Einträge und Regex-Regeln, alles in einer App — mit 0.0.0.0 als geblockter Antwort, wie bei einem Sinkhole.
• Split-Horizon-DNS. Interne Overrides für unsere eigenen Domains, ausgeliefert als Conditional-Forwarder-Zonen — sauber, und Teil des Cluster-Katalogs, also synchronisieren sie mit.
• Query-Logging. Eine SQLite-gestützte Query-Log-App mit Aufbewahrung, im GUI durchsuchbar für die Fehlersuche.

Die Kompromisse — ehrlich

Technitium gibt es nicht zum Nulltarif:

• Kleinere Community. Pi-holes größte Stärke ist die schiere Menge dokumentierter Edge-Cases und ein riesiges Forum. Technitium wird von einem einzelnen, sehr aktiven Maintainer geführt. Die Doku ist gut und das Projekt entwickelt sich schnell — aber gelegentlich ist man der Erste, der auf ein bestimmtes Problem stößt.
• Mehr Stellschrauben. Weil es ein echter DNS-Server ist, gibt es mehr zu verstehen — Forwarder vs. Rekursion, was im Cluster synchronisiert und was pro Knoten gilt, DNSSEC und Zertifikatshandling. Mit der Macht kommt die Komplexität.
• Blocking lebt in einer App. Die Advanced-Blocking-App ist exzellent, aber sie ist eine Schicht, die man konfiguriert — nicht das Aushängeschild mit Ein-Klick-Setup wie bei Pi-hole.

Pi-hole v6 vs. Technitium im Überblick

Wie die Migration lief

Wir haben ohne DNS-Ausfall migriert. Der Trick: den bestehenden Primärknoten die ganze Zeit weiter ausliefern lassen. Wir haben den zweiten Knoten leer neu aufgebaut, ihn als frischen Sekundärknoten auf reinen Cluster-Ports (ohne Port 53) ins Cluster aufgenommen, geprüft, dass die komplette Konfiguration synchronisiert war — und ihn erst dann wieder DNS ausliefern lassen. Die alten Pi-hole-Daten wurden auf jedem Knoten für ein Rollback archiviert, am ersten Tag wurde nichts gelöscht.

Ein paar Dinge haben uns unterwegs geärgert: eine Firewall, die ausgehend nur Port 53 zu unseren gewählten Upstreams erlaubt (also leiten wir per DoT weiter, statt zu rekursieren), und eine Admin-Passwort-Datei, die nur beim ersten Init greift (Passwort in der Konsole ändern, nicht in der Datei). Solche Dinge lernt man nur durch Tun.

Unser Fazit

Wenn Pi-hole oder AdGuard deine Anforderungen abdeckt und du nur eine Box betreibst, gibt es keinen Migrationsdruck — sie sind exzellent, und unser früherer Vergleich gilt weiterhin. Aber sobald du zwei Resolver brauchst, die zuverlässig synchron bleiben, plus DNSSEC und verschlüsselten Upstream ohne Anbauten, spielt Technitium in einer anderen Liga. Bei uns wurden aus drei Workarounds drei Häkchen — und DNS hat seitdem keinen Takt ausgelassen.