Technitium als rekursiver DNS-Resolver im Homelab – und warum das mehr ist als ein Spielzeug

Der Digital Independence Day findet jeden ersten Sonntag im Monat statt. Die Idee dahinter: einen Schritt raus aus der Abhängigkeit von Big-Tech-Plattformen machen, einen Dienst nach dem anderen. DNS ist dabei ein guter Einstieg, weil er unsichtbar ist und genau deshalb so selten hinterfragt wird. Wer mit Ad-Blocking anfangen möchte, findet einen einfachen Einstieg im Pi-hole-Artikel.

DNS ist die Infrastruktur unter der Infrastruktur. Wenn es kaputt ist, ist gefühlt alles kaputt, auch wenn technisch gesehen nur ein einziger Dienst nicht antwortet. Und wer seinen DNS-Traffic zu Cloudflare oder Google schickt, gibt damit mehr preis, als die meisten ahnen. Deswegen lohnt es sich, genau hinzuschauen, was im eigenen Netzwerk passiert, wenn ein Gerät einen Hostnamen auflöst.

In diesem Post geht es darum, wie ich Technitium-DNS in meinem Homelab als vollständig rekursiven Resolver betreibe, ohne externe Forwarder und ohne Abhängigkeit von Quad9 oder Cloudflare. Am Ende schaue ich kurz, warum das Prinzip auch für kleine Unternehmen interessant ist.

Was bedeutet „rekursiv“ überhaupt?

Die meisten Heimnetzwerke funktionieren so: Der Router leitet DNS-Anfragen an den DNS-Server des Internetanbieters weiter, oder an einen Dienst wie Cloudflare (1.1.1.1) oder Google (8.8.8.8). Der Router selbst löst nichts auf, er reicht nur durch. Das nennt sich Forwarding.

Ein rekursiver Resolver macht die Arbeit selbst. Er fragt zuerst einen der 13 Root-Nameserver-Cluster, die das Fundament des DNS bilden. Der Root antwortet: „Für .de bin ich nicht zuständig, frag dort.“ Der Resolver fragt weiter. Dann wieder weiter. Bis er beim autoritativen Nameserver der gesuchten Domain ankommt und die Antwort direkt bekommt.

Der Unterschied ist nicht nur technisch, er ist inhaltlich relevant:

Merkmal	Forwarder-Modus	Rekursiver Modus
Wer sieht alle Queries?	Der Forwarder (Cloudflare, Quad9, ISP)	Niemand – jeder NS sieht nur seinen Teil
Externe Abhängigkeit	Ja, vollständig	Nur Root Hints (statisch, sehr stabil)
Latenz (Cold Cache)	Gering	Etwas höher (volle Auflösungskette)
Latenz (Warm Cache)	Identisch	Identisch
Kontrolle	Mittel	Vollständig
Komplexität	Gering	Mittel

Beim Forwarding verlagert sich das Vertrauen – es verschwindet nicht. Wer Cloudflare als Forwarder nutzt, verschlüsselt zwar den Transport via DoH, aber Cloudflare sieht trotzdem alle Anfragen. Rekursive Auflösung ist kein Vertrauensversprechen, sondern ein technischer Schutz: Kein einzelner Dritter kennt das vollständige Anfragebild meines Netzwerks.

Mein Setup: Technitium DNS-Cluster auf Proxmox

Die Infrastruktur

Mein Homelab läuft auf zwei Dell OptiPlex 5060 Micro als Proxmox-Nodes. Das Netzwerk wird von einem TP-Link Omada Stack verwaltet: ER605 als Router, ein paar Switches, vier EAP653 Access Points. VLANs für alles – Server-LAN (VLAN10, 192.168.3.0/24), Client-LAN, IoT, Guest, Backup-Netz.

DNS läuft auf zwei Technitium-Instanzen als LXC-Container auf Proxmox:

• dns1: 192.168.3.30 (primär, auf pve01)
• dns2: 192.168.3.31 (sekundär, auf pve02)

Technitium synchronisiert Zonen automatisch zwischen den beiden Instanzen über seinen eingebauten Cluster-Mechanismus. Fällt einer der Nodes aus, übernimmt der andere nahtlos. Keine manuelle Intervention, keine Downtime für die Clients.

Rekursive Auflösung aktivieren

Die Umstellung auf rekursiven Betrieb ist in Technitium überraschend unspektakulär: Im Tab „Proxy & Forwarders“ einfach alle konfigurierten Forwarder entfernen. Das war es.

Technitium erkennt automatisch, dass keine Forwarder mehr gesetzt sind, und schaltet auf rekursive Auflösung via Root Hints um. Die Root Hints sind die Adressen der 13 Root-Nameserver-Cluster von a.root-servers.net bis m.root-servers.net. Sie sind im Programm hinterlegt und werden automatisch aktuell gehalten.

Recursion-Einstellungen im Detail

Im Tab „Recursion“ habe ich folgende Konfiguration. Eine vollständige Übersicht aller Einstellungen findet sich in der offiziellen Dokumentation.

Recursion: Allow Recursion Only For Private Networks

Das ist die wichtigste Sicherheitseinstellung. Sie verhindert, dass der Resolver von außen als offener Resolver missbraucht werden kann. Nur Anfragen aus privaten Netzen (RFC 1918) werden rekursiv beantwortet – kein DNS-Amplification-Angriff über meinen Server.

QNAME Minimization: aktiviert

QNAME Minimization sorgt dafür, dass jeder Nameserver auf dem Auflösungspfad nur das erfährt, was er für seinen Schritt benötigt. Der Root-Nameserver sieht nur die TLD, der TLD-Nameserver nur die Second-Level-Domain. Das reduziert, was jeder einzelne externe Nameserver über das Surfverhalten des Netzwerks erfährt. Auch im rekursiven Modus bleibt das sinnvoll.

Randomize Name: deaktiviert

Diese Option aktiviert QNAME Case Randomization als zusätzliche Schutzmaßnahme gegen DNS-Spoofing. Das Problem: Manche Nameserver-Implementierungen reagieren auf case-randomized Queries falsch. Technitium erkennt solche Fälle zwar und fällt auf TCP zurück, aber der Overhead lohnt sich nicht, da Technitium Spoofing-Versuche ohnehin erkennt.

Resolver Retries: 2 / Timeout: 1500ms / Concurrency: 2 / Max Stack Count: 16

Standardwerte, die gut passen. Technitium nutzt intern einen Epsilon-Greedy-Algorithmus: Er lernt mit der Zeit, welche Nameserver für welche Domains schnell antworten, und bevorzugt diese automatisch. Das System kalibriert sich selbst.

Der Auflösungspfad

Client
  → Technitium (lokaler rekursiver Resolver, Blocklisten, Cache)
    → Root Nameserver (z.B. a.root-servers.net)
      → TLD Nameserver (z.B. für .de)
        → Autoritativer Nameserver der Domain

Kein Dritter sieht alle Anfragen. Jeder Nameserver auf dem Weg sieht nur das, was er für seinen Teil der Auflösung benötigt, und dank QNAME Minimization noch weniger als ohne.

Was Technitium noch mitbringt

Internes DNS: home.sascharupp.de

Technitium ist autoritativ für meine interne Zone home.sascharupp.de. Alle Hostnamen im Homelab leben dort: Proxmox-Nodes, Container, VMs, NAS. Der rekursive Modus greift nur für Domains, die nicht lokal bekannt sind.

Tipp am Rande: Die interne Zone nicht als .local betreiben. .local ist per RFC 6762 für mDNS reserviert und führt zu subtilen Konflikten. Eine echte Subdomain unter einer registrierten Domain ist sauberer. Mit einem Wildcard-Zertifikat via Let’s Encrypt und Cloudflare DNS-Challenge läuft HTTPS intern dann auch problemlos.

Blocklisten direkt in Technitium

Technitium bringt Blocklisten direkt mit. Über die „Blocked“-Sektion lassen sich gängige Formate einbinden: Hosts-Dateien, reine Domain-Listen, Regex. Bewährt haben sich unter anderem oisd big, HaGeZi Pro und StevenBlack. Das lässt sich pro Zone oder global steuern und funktioniert unabhängig vom Auflösungsmodus.

Wer ausschließlich Ad-Blocking sucht und keinen vollwertigen DNS-Server betreiben möchte, ist mit Pi-hole wahrscheinlich besser bedient. Pi-hole ist genau dafür gemacht, hat eine ausgereifte Oberfläche und eine große Community. Wer ohnehin einen lokalen Resolver betreibt, braucht Pi-hole aber nicht zusätzlich.

VLAN-Enforcement

Auf dem ER605 ist Port 53 für das IoT-VLAN geblockt. Geräte dort können keinen eigenen DNS-Server nutzen, sie müssen durch den lokalen Resolver. Das verhindert, dass smarte Glühbirnen und fragwürdige Firmware stillschweigend an externen Resolvern vorbei auflösen.

Cluster und Redundanz

Beide Instanzen laufen im Cluster-Verbund. Zonenänderungen werden automatisch synchronisiert, inkrementell via IXFR, das heißt nur Änderungen werden übertragen, nicht jedes Mal der komplette Zoneninhalt. Im Query-Log sieht man den Unterschied deutlich: Externe Auflösungen erscheinen als „Recursive“, interne Anfragen in eigenen Zonen als „Authoritative“.

Und für kleine Unternehmen?

Das Prinzip skaliert. Was ich im Homelab betreibe, ist strukturell identisch mit dem, was ein kleines Büro mit 10 bis 30 Geräten benötigt: ein lokaler Resolver, der interne Namen kennt, Werbung und Tracking blockt und nicht von einem externen Dienst abhängt. Redundanz ist optional, aber mit einem zweiten Container schnell erledigt.

Technitium läuft auf sehr bescheidener Hardware, ein einzelner Mini-PC oder eine VM auf einem vorhandenen Server reicht. Die Web-UI ist ohne Vorkenntnisse bedienbar, Zonen lassen sich über eine GUI pflegen und Blocklisten werden automatisch aktualisiert. Für einen IT-Dienstleister, der kleine Unternehmen betreut, ist das eine interessante Alternative zu teuren Hardware-Appliances oder cloudbasierten DNS-Filterlösungen.

Wer DNSSEC, interne Split-Horizon-Zonen und zentrales Logging benötigt: Technitium bietet das alles. Wer einfach nur will, dass DNS zuverlässig und unabhängig funktioniert, bekommt das mit minimalem Aufwand. Das Projekt ist kostenlos und Open Source, die Projektseite listet alle Features und Installationswege.

Fazit

Rekursive DNS-Auflösung ist kein esoterisches Homelab-Thema. Es ist die Antwort auf eine einfache Frage: Wem vertraust du mit dem vollständigen Bild dessen, was dein Netzwerk im Internet sucht? Ein Forwarder verschiebt dieses Vertrauen zu einem Dritten. Ein rekursiver Resolver behält es bei sich.

Technitium macht das zugänglich. Es ist kein Kompromiss zwischen Funktion und Komfort. Rekursiver Resolver, DNS-Verwaltung, Blocklisten und Cluster-Betrieb stecken in einem einzigen Paket. Wer am nächsten DI.DAY einen konkreten Schritt Richtung digitale Unabhängigkeit machen will: DNS ist kein schlechter Anfang.

Setup-Übersicht: Proxmox Dual-Node (Dell OptiPlex 5060 Micro), TP-Link Omada (ER605, SG3428X, EAP653), Technitium DNS Cluster (dns1: 192.168.3.30, dns2: 192.168.3.31), QNAP TS-431X NAS. Internes DNS über home.sascharupp.de, externe Auflösung rekursiv via Root Hints.