Technitium im Homelab: DNS selbst in die Hand nehmen

Warum ich einen funktionierenden Ad-Blocker rausgeworfen habe, um einen richtigen DNS-Server hinzustellen.

Jeder, der ein Homelab hat, kennt das: Man baut immer mal wieder etwas um, nicht weil man es muss, sondern weil man es (noch besser) machen kann. Die alte Lösung läuft, hat getan, was sie sollte – und man wirft sie trotzdem raus.

Genau das habe ich mit AdGuard Home gemacht. Jahrelang lief das hier als mein DNS, hat brav für uns Werbung geblockt, ein hübsches Dashboard angezeigt und nie Probleme bereitet. Trotzdem ist es jetzt rausgeflogen. Ersetzt durch Technitium als DNS-Server.

Aber um den tatsächlichen Grund zusammenzufassen:

• AdGuard Home ist ein Ad-Blocker, der als DNS-Server agiert.
• Technitium ist ein DNS-Server, bei dem Ad-Blocking eines von vielen Features ist.

Und irgendwann war mein Anspruch an mein Netzwerk, es „richtig“ zu machen.

Was ich eigentlich wollte

Der eigentliche Auslöser wird jedem bekannt vorkommen, der zuhause mehr als drei Dienste hinter einem Reverse Proxy hängen hat.

Ich habe für mein Homelab eine eigene Domain, unter der alle gehosteten Dienste als Subdomains laufen. Fotoverwaltung, Medienserver, eigene Cloud, etc. Öffentlich zeigt die Domain auf meine externe IP, intern soll sie auf den Reverse Proxy im Heimnetz zeigen: also gleicher Name, aber unterschiedliche Antwort (je nachdem, wer fragt). Das nennt sich Split-Horizon-DNS und sollte im Homelab der Normalfall sein.

Der Vorteil ist nicht nur Geschwindigkeit (der Traffic geht nicht einmal über den Router raus und wieder rein). Der wichtigere Grund: Intern funktioniert DNS dann auch, wenn das Internet weg ist. Auch wenn mein Provider mal nicht will, möchte ich trotzdem noch an meine Dokumente kommen.

Dazu kam der Wunsch nach Reverse DNS. Jedes Gerät im Netz soll nicht nur einen Namen haben, der auf eine IP zeigt, sondern auch umgekehrt: Jede IP soll einen Namen zurückliefern. Wozu ist das nun wieder gut? Das sorgt z.B. dafür, dass in einem Monitoring-Dashboard nicht nur IP-Adressen stehen, sondern sowas wie datengrab oder sonos-wohnzimmer angezeigt wird.

Es hilft auch sehr, wenn man direkt die Warnung „drucker-johanna ist down“ bekommt, anstatt erst mal nachzuschlagen, welche IP-Adresse welches Gerät ist.

Und schließlich: eine saubere Namenskonvention. Dienste unter dem einen Schema, Geräte unter einem anderen.

Wo AdGuard Home an die Grenze kommt

Um fair zu bleiben: Reverse DNS und Split-Horizon kann man auch mit AdGuard Home machen – irgendwie. Über die DNS-Rewrite-Regeln lassen sich einzelne PTR-Records fälschen, und mit dem $client-Modifier kann man Antworten je nach anfragendem Client unterschiedlich ausliefern. Das ist Split-Horizon per Definition.

Aber das grundsätzliche Problem: AdGuard Home kennt kein Zonenkonzept.

Es gibt keine Zone. Kein SOA, kein NS, keine Delegation, keinen Zonentransfer, kein DNSSEC-Signing, keine Secondary Zone, kein Zonefile. Alles, was bei AdGuard nach DNS aussieht, ist in Wahrheit eine Filterregel. Man fälscht einzelne Antworten, statt eine Zone zu betreiben.

Das ist jetzt nicht nur meine Auslegung, das ist die erklärte Position des Projekts. Der Feature-Request „Add DNS zone via web interface“ liegt seit Jahren geschlossen im Repo, mit der Antwort des Maintainers, dass die DNS-Rewrites vielleicht irgendwann erweitert werden.

Aber: „That’s a bit in the air right now.“ Und bis dahin soll dnsrewrite der Weg bleiben. Und: Das ist völlig legitim. AdGuard Home definiert sich selbst als „network-wide software for blocking ads and tracking“, die als DNS-Server operiert. Es macht also genau das, was es behauptet.

Ich wollte dann aber doch ein bisschen mehr. Wer zehn interne Namen hat, kommt mit Rewrite-Rules gut klar. Aber eine Wildcard-Zone, eine getrennte Geräte-Zone und zwei Reverse-Zonen mit automatisch gepflegten PTR-Records damit bauen, verursacht dann doch eher Kopfschmerzen…

Technitium als Telefonzentrale

Technitium ist ein vollwertiger DNS-Server: autoritativ & rekursiv, mit Web-Oberfläche. Steht unter der GPLv3 und ist im Wesentlichen von einer Person (Shreyas Zare) entwickelt.

Warum Technitium?

• Echte Zonen. Primary, Secondary, Stub, Conditional Forwarder. Mit SOA, NS, Delegation, Zonentransfer (AXFR/IXFR), NOTIFY und DNSSEC-Signing. Also all das, was AdGuard nicht bieten kann.
• Autoritativ und rekursiv in einem Dienst. Das macht es für das Homelab bequem: Man braucht eben nicht Pi-hole für Blocking und Unbound für Rekursion und irgendwas für die eigenen Zonen – sondern nur einen Dienst mit einer UI.
• Ad-Blocking ist trotzdem drin. Blocklisten per URL, „Quick Add“ für die üblichen Verdächtigen. Die „Advanced Blocking“-App kann sogar unterschiedliche Blocklisten je Client oder Subnetz und blockt CNAME-Cloaking.
• Split-Horizon. Über die Split-Horizon-App, per Mapping Subnetz → Antwort.
• DHCP mit automatischem DNS. Der eingebaute DHCP-Server legt Forward- und Reverse-Records automatisch an. Man vergisst nix und der Reverse DNS „pflegt sich selbst“ anstatt als „nette Idee“ bei neuen Diensten vergessen zu werden.
• DoH/DoT/DoQ selbst hosten, nicht nur als Upstream nutzen. Plus API, 2FA, DNSSEC-Validierung & QNAME Minimization.

Die Migration selbst war tatsächlich unspektakulär: Ich habe Technitium auf dieselbe IP und denselben Port wie vorher AdGuard gesetzt. Damit musste ich am Router genau nichts umkonfigurieren. Für alle Geräte im Haus hat sich schlicht nichts geändert.

Der Aufbau danach:

• Eine primäre Zone für meine Homelab-Domain, mit einer Wildcard. Alles, was *.meine-domain heißt, landet beim Reverse Proxy. Bedeutet: Neuer Dienst = neuer Proxy-Host. Kein DNS-Eintrag mehr nötig. Mehr Komfort im Alltag 😊
• Eine separate Zone für Geräte, in der Hostnamen direkt auf ihre IPs zeigen.
• Zwei Reverse-Zonen für zwei unterschiedliche VLANs, mit PTR-Records.
• Und: keine Forwarder. Dazu gleich mehr.

Die Namenskonvention, die dabei rauskam, ist simpel genug, um sie sich zu merken: dienst.meine-domain geht immer über den Reverse Proxy. gerät.internal.meine-domain geht direkt ans Gerät, ohne Proxy dazwischen. Wenn ich einen Namen sehe, weiß ich sofort, in welche Kategorie er gehört.

Keine Forwarder – und der Trade-off

Das ist vielleicht der Teil, bei dem ich am längsten hin und her überlegt habe.

Normalerweise fragt der DNS-Server im Haus einen der großen Anbieter (Cloudflare, Google, den Provider selbst, …) und reicht die Antwort dann durch. Das nennt man Forwarder.

Die Alternative ist rekursive Auflösung: Der Server fragt sich selbst durch, von den Root-Servern über die TLD-Server bis zum zuständigen Nameserver der Zieldomain. Da ist dann kein Dritter dazwischen.

Der Vorteil ist Privatsphäre: Kein einzelner Anbieter sieht mehr meine vollständige DNS-Historie. Die Google-Server erfahren, dass ich eine Google-Seite aufrufe – aber nicht, dass ich kurz darauf mein Online-Banking oder Spiegel Online öffne. Bei einem Forwarder weiß der Upstream alles.

Der Nachteil ist Geschwindigkeit, und das muss einem bewusst sein: Der erste Aufruf einer Domain unter einer bisher unbekannten TLD kann bis zu einer Sekunde dauern, mit DNSSEC auch länger. Danach liegt alles im Cache und Folgeanfragen sind im Bereich von unter 0,1 Sekunden. Die großen Anbieter haben praktisch alles Gängige permanent im Cache – dagegen kommt eine kleine Instanz bei mir im Keller nicht an.

Das Argument „aber CDNs liefern dir dann schlechtere Server“ (EDNS Client Subnet) trifft bei einem Resolver im eigenen Haus übrigens deutlich weniger zu: Das Problem entsteht dadurch, dass der Resolver weit weg vom Client steht. Meiner steht aber im selben Netz.

Was man dagegen auf dem Zettel haben sollte, weil es sich fies debuggen lässt: Manche Provider und Consumer-Router fangen Port 53 ab und leiten ihn um, ohne irgendeinen Hinweis. Manche CG-NAT-Setups lassen UDP durch, verwerfen dann aber stillschweigend TCP auf Port 53 – das braucht man aber für DNSSEC-Antworten. Wenn Rekursion sich seltsam verhält, liegt das möglicherweise genau daran.

Da ich Glasfaser habe und die Latenz im Alltag schlicht nicht merke, war die Entscheidung bei mir leicht(er). Wer aber an einem langsamen Anschluss hängt oder ein Haus voller ungeduldiger Menschen hat, kann das ggf. anders gewichten. Es ist ein Trade-off – kein „richtig“ oder „falsch“.

Die Schattenseiten

• Die Doku hat Lücken. Split-Horizon ist so ein Fall: Es funktioniert, aber die offizielle Dokumentation dazu fehlt schlicht. Der Entwickler räumt das in den GitHub-Discussions selbst ein. Man landet also beim Zusammensuchen aus Diskussionen und Forenbeiträgen. Bei AdGuard Home war die Doku deutlich runder.
• Kleines Projekt, große Verantwortung. Technitium hängt (bisher) sehr stark an einer Person. Das ist bei Open-Source-Projekten jetzt nicht ungewöhnlich, aber DNS ist der Dienst, an dem im Haus dann doch so ziemlich alles hängt.
• Deutlich mehr Konzepte. Wer nur Werbung blocken will, bekommt hier eine Zonenverwaltung, Zonentypen, TSIG-Keys und DNSSEC-Optionen mitgeliefert, die er wohl nie brauchen wird. Das kann man Technitium nicht vorwerfen – aber es ist natürlich Overkill, wenn man nichts davon braucht oder will.
• Der Klassiker = SPoF (Single Point of Failure). Wenn DNS steht, steht alles, und zwar auf eine besonders verwirrende Art (nichts ist „kaputt“, es geht nur nichts mehr). Technitium hat für den Fall die richtigen Werkzeuge – Secondary Zones per AXFR mit TSIG, dazu Catalog Zones, damit man neue Zonen nicht auf jedem Server einzeln anlegen muss, und inzwischen auch ein Clustering-Feature, das Blocklisten und Apps über mehrere Instanzen synchronisiert.
  Bei mir läuft trotzdem aktuell nur eine Instanz. Das ist eine Lücke in meinem Setup, und sie steht auf der ToDo-Liste. (Falls jemand denselben Weg geht: Clustering synct die Konfiguration, es ist kein Failover und kein Load Balancer.)

Kurz zu den Alternativen (die ich mir nicht alle im Detail angeguckt habe):

• Pi-hole ist der Klassiker und im Kern dasselbe Prinzip wie AdGuard Home: Blocking über DNS. Für Zonen und alles Weitere schiebt man dnsmasq-Configs unter. Damit hat man dann zwei Konfigurationsebenen, von denen die eine nicht im UI auftaucht. Wollte ich nicht.
• Die klassische Kombination Pi-hole + Unbound löst genau meinen Rekursions-Wunsch – aber eben auch nur den. Zonenverwaltung bleibt Handarbeit, und man betreibt zwei Dienste statt einem.
• BIND 9 ist die Referenz, kann alles, was ich wollte, inklusive echter Views für Split-Horizon. Konfiguration dafür ausschließlich über named.conf, keine GUI und kein Ad-Blocking. Passt so nicht für mich.

• Blocky sieht zu großen Teilen prima aus: ein einziges Go-Binary, YAML-Konfiguration, Blocklisten pro Client-Gruppe, Prometheus-Metriken. Mega, wenn man alles als Code will. Nur eben kein autoritativer DNS → es kann also die Namen für mein eigenes Netz nicht selbst vergeben und beantworten.
  Ansonsten: Beim Thema Logo/Maskottchen gewinnt Blocky den Vergleich mit allen anderen Tools haushoch…
• dnsmasq und CoreDNS sind beide top, aber jeder in seiner Nische. dnsmasq ist ein leichtgewichtiger Klassiker auf Routern und in Embedded-Systemen, und vereint DNS-Weiterleitung, Caching und DHCP in einem kleinen Paket – ist aber auch kein vollwertiger autoritativer Server. CoreDNS ist der plugin-basierte Standard-DNS aus der Kubernetes-Welt, aber man müsste sich vieles selbst zusammenstöpseln ohne GUI und ohne Ad-Blocking.

Fazit

War das unbedingt nötig? Nö. AdGuard Home hätte auch weiterhin noch seine Dienste getan und ist für viele vermutlich die richtige Wahl: einfacher, besser dokumentiert – und tut, was es soll.

Der Wechsel lohnt sich aber, wenn man merkt, dass man anfängt, DNS-Konzepte mit Filterregeln nachzubauen. Wenn du eine Handvoll interner Namen umbiegst: bleib bei AdGuard oder Pi-hole. Aber wer anfängt, sich Wildcards, Reverse-Zonen und Split-Horizon zusammenzubasteln, kämpft gegen das Tool – und sollte besser das Werkzeug wechseln.

Das Schönste am neuen Setup ist dann auch gar nicht der Zonenkram, sondern der oben erwähnte zusätzliche Komfort im täglichen Gebrauch: Ich lege einen neuen Dienst an, trage ihn im Reverse Proxy ein, und die Wildcard-Zone hat den Rest schon erledigt. Kein DNS-Eintrag, kein Nacharbeiten. Und im Monitoring stehen Namen statt Nummern, weil der DHCP-Server die PTR-Records von selbst pflegt.

Learning:

Ein Ad-Blocker, der DNS spricht, ist etwas anderes als ein DNS-Server, der auch Ads blocken kann. Man merkt den Unterschied erst, wenn man mehr will als nur Blocken – dann merkt man ihn aber sofort.