Jedes Gerät im Haus fragt DNS – und manche fragen, wen sie wollen. Bei mir antworten zwei eigene Technitium-Server, die Firewall sorgt dafür, dass niemand an ihnen vorbeikommt, und ein Feature habe ich dabei glatt übersehen.

Worum geht’s?

DNS ist das Telefonbuch des Internets: Ein Gerät fragt „Welche IP hat example.com?“ und bekommt eine Adresse zurück. Wer diese Fragen beantwortet, sieht ziemlich genau, was im Haus los ist – und kann entscheiden, welche Antworten es überhaupt gibt.

Bisher hat das bei mir der alte Router erledigt. Ein Pi-hole-Container lief früher auch mal, ist aber seit September abgeschaltet. Mit dem Umstieg auf eine FortiGate als Firewall wollte ich DNS sauber neu aufziehen. Meine Wunschliste:

  • Eigene Namen fürs Homelab, damit ich Dienste unter dienst.home.example.com erreiche statt unter einer IP.
  • Werbung und Tracker filtern, für alle Geräte im Haus, ohne dass ich auf jedem etwas installieren muss.
  • Verschlüsselt nach außen, damit mein Provider nicht mitlesen kann, welche Namen ich auflöse.
  • Ausfallsicher: Wenn ein DNS-Server ausfällt, geht im Haus gefühlt das Internet aus. Also zwei.
  • Keine Schlupflöcher: Geräte, die sich ihren eigenen DNS-Server aussuchen, sollen trotzdem bei mir landen.

Voraussetzungen

  • Proxmox VE als Hypervisor
  • Technitium DNS Server 15.6.1 (eingerichtet mit 15.6), in zwei LXC-Containern mit Debian 12, je 1 vCPU und 512 MB RAM
  • FortiGate als Firewall mit mehreren VLANs (getrennten Netzen) für Server, Clients, IoT-Geräte, Gäste und so weiter
  • Quad9 als Upstream-Resolver per DNS-over-TLS
  • Nginx Proxy Manager als Reverse Proxy für die internen Dienste

Warum Technitium und nicht Pi-hole oder AdGuard Home? Technitium ist ein vollwertiger DNS-Server: Er kann echte Zonen verwalten, Zonentransfers, DNS-over-TLS nach außen, Filterlisten – alles in einem. Bei Pi-hole und AdGuard Home fehlten mir genau diese Einstellmöglichkeiten. Und der Abgleich zwischen zwei Servern war bei beiden nicht optimal, das läuft dort meist über zusätzliche Werkzeuge.

Der Aufbau

             Clients, IoT, Gäste, Server …
                        │  DNS (Port 53)
          ┌─────────────┴─────────────┐
          ▼                           ▼
   dns-01 (Primary)  ── Zonentransfer ──▶  dns-02 (Secondary)
          │                           │
          └──────── DNS-over-TLS ─────┘
                        ▼
                      Quad9

Beide Server laufen als LXC-Container auf Proxmox, mit fester IP im Server-Netz (im Beispiel 10.0.10.53 und 10.0.10.54), und starten beim Booten des Hosts als Erste. Der DHCP-Server der FortiGate verteilt in allen Netzen beide Adressen als DNS-Server. Fällt einer aus, fragen die Geräte einfach den anderen.

Die interne Zone

Auf dns-01 liegt die Zone home.example.com als Primary, also als Original. Der wichtigste Eintrag ist ein Wildcard:

*.home.example.com.   300   IN   A   10.0.10.80

Jeder Name unter home.example.com zeigt damit auf den Reverse Proxy, der die Anfrage an den richtigen Dienst weiterreicht. Für einen neuen Dienst muss ich nur im Proxy etwas eintragen, nicht im DNS. Ein paar Namen, die nicht über den Proxy laufen, stehen zusätzlich als eigene A-Einträge drin.

dns-02 hält dieselbe Zone als Secondary: Er holt sie sich per Zonentransfer von dns-01. Damit Änderungen nicht erst beim nächsten regulären Abgleich ankommen, schickt dns-01 bei jeder Änderung ein Notify – eine kurze Nachricht „Hey, es gibt was Neues“, worauf dns-02 sofort nachlädt.

Filterlisten

Auf beiden Servern sind dieselben Listen eingetragen:

  • HaGeZi Multi PRO: blockt Werbung, Tracker und bekannte Schaddomains. Die Liste wird alle 24 Stunden aktualisiert.
  • HaGeZi „Encrypted DNS Bypass“: blockt bekannte Anbieter von DNS-over-HTTPS (DoH). Dazu gleich mehr.
  • use-application-dns.net: Das ist eine „Kanarienvogel-Domain“. Firefox fragt sie ab, bevor er von sich aus DoH einschaltet. Bekommt er keine Antwort, lässt er es bleiben und nutzt das DNS des Netzes.

Verschlüsselt nach außen

Was Technitium nicht selbst weiß, fragt er bei Quad9 nach – und zwar per DNS-over-TLS (DoT). DoT ist normales DNS, nur in einem verschlüsselten Tunnel über Port 853. Mein Provider sieht dann nur noch, dass ich mit Quad9 rede, aber nicht mehr, worüber.

Wie viel da zusammenkommt, zeigt das Dashboard von dns-01: In 24 Stunden kamen rund 92 000 Anfragen von 40 Geräten an. Knapp 16 Prozent davon hat Technitium geblockt, also ungefähr jede sechste. Einen Teil der Anfragen beantwortet außerdem dns-02, die echte Gesamtzahl im Haus liegt also noch etwas höher.

Das Technitium-Dashboard von dns-01 über 24 Stunden: Anfragen insgesamt, beantwortet, aus dem Cache und geblockt

Die Firewall passt auf

Eigene DNS-Server bringen wenig, wenn Geräte einfach woanders fragen. Und das tun erstaunlich viele.

Regel 1: DNS nur an die eigenen Server

Auf der FortiGate gibt es zwei Regeln, sinngemäß:

VonNachWasErlaubt?
Clients, IoT, Gäste, Server …die beiden DNS-ServerDNSja
dieselben Netze, außer den DNS-Servern selbstInternetDNS (53) und DoT (853)nein

Nur dns-01 und dns-02 dürfen also selbst nach draußen. Alle anderen Geräte kommen mit DNS nur noch bis zu ihnen.

Regel 2: Wer stur Google fragt, landet trotzdem bei mir

Ein paar Geräte halten sich nicht an den DNS-Server, den ihnen DHCP mitgibt. Bei mir waren das vor allem die Echo-Lautsprecher und der Fire TV: Die fragen fest eingestellt bei Google (8.8.8.8 und 8.8.4.4). Mit Regel 1 würden sie einfach kein DNS mehr bekommen und nicht mehr funktionieren.

Die Lösung auf der FortiGate ist eine Umleitung (dort „VIP“ genannt): Anfragen an Googles DNS-Adressen werden auf meine beiden Server umgeschrieben. Die Geräte glauben, Google habe geantwortet – tatsächlich war es Technitium, inklusive Filterlisten.

Regel 3: Und was ist mit DNS-over-HTTPS?

DoH ist der Endgegner dieser Konstruktion: DNS-Anfragen, verpackt in normales HTTPS über Port 443. Für die Firewall sieht das aus wie jeder andere Webseitenaufruf, eine Portsperre greift nicht.

Hier kommen die zweite Filterliste und die Firefox-Kanarienvogel-Domain ins Spiel: Technitium löst die Namen bekannter DoH-Anbieter einfach nicht auf. Ein Gerät, das per DoH an mir vorbei will, findet seinen DoH-Server gar nicht erst – solange es ihn über Namen sucht. Eine Lücke bleibt: Wer seinen DoH-Server fest per IP kennt, kommt durch. Das nehme ich bewusst in Kauf.

Bonus: Ein zweiter Filter auf der Firewall

Die Regel, mit der die Geräte die DNS-Server erreichen dürfen, hat zusätzlich das DNS-Filterprofil der FortiGate. Die FortiGate schaut sich also jede Anfrage auf dem Weg zu Technitium an und blockt Kategorien wie Schadsoftware, Phishing und frisch registrierte Domains anhand der Herstellerdaten. Zwei unabhängige Filter, die sich ergänzen.

Die bewusste Ausnahme: die Firewall selbst

Die FortiGate fragt nicht meine Technitium-Server, sondern den DNS-Dienst ihres Herstellers, ebenfalls verschlüsselt per DoT. Das ist Absicht.

Die Firewall braucht DNS für ihre eigenen Updates, für Filterdaten, für Regeln mit Domainnamen und für die Prüfung, ob die Internetleitung läuft. Würde sie Technitium fragen, hinge sie an Proxmox. Startet der Proxmox-Host neu oder hat er ein Problem, stünde auch die Firewall ohne DNS da – genau in dem Moment, in dem ich sie am dringendsten brauche. Also bleibt sie unabhängig.

Die PTR-Flut von Home Assistant

Kurz nach dem Umstieg füllte sich mein Firewall-Log mit Hunderten geblockten Anfragen, immer zur gleichen Minute jeder Stunde. Absender: Home Assistant.

Dessen Geräteerkennung fragt regelmäßig für das komplette Netz nach, welcher Name zu welcher IP gehört. Diese Rückwärtsabfragen heißen PTR-Abfragen. Gerichtet waren sie an das Gateway, also an die FortiGate – und die hatte keinen DNS-Dienst, also hat sie jede einzelne verworfen. Rund 700 pro Stunde, alle im Log.

Die Lösung: Auf der Schnittstelle zum Server-Netz, und nur dort, beantwortet die FortiGate DNS-Anfragen jetzt selbst, indem sie sie weiterreicht:

config system dns-server
    edit "<SERVER-INTERFACE>"
        set mode forward-only
    next
end

Die PTR-Anfragen für private Adressen bekommen damit ein schnelles „gibt es nicht“ (NXDOMAIN), und das Log ist wieder ruhig. Getestet habe ich das mit:

dig -x 10.0.10.20 @10.0.10.254

Stolperfallen & Learnings

Beim Update braucht Technitium ein paar Sekunden. Ich habe beide Server mit dem offiziellen Installationsskript aktualisiert und direkt danach getestet: connection refused. Kurzer Schreck – dabei braucht Technitium nach dem Neustart einfach ein paar Sekunden, bis er wieder auf Port 53 lauscht. Seitdem gilt: nach dem Update kurz warten, und erst den Secondary aktualisieren, testen, dann den Primary. So beantwortet immer mindestens ein Server die Anfragen.

„Server-Reset“ heißt nicht „blockiert“. Im Firewall-Log sah ich bei den DoT-Verbindungen zu Quad9 lauter Einträge mit server-rst und dachte zuerst, die Firewall würde DoT blocken. Tatsächlich ist das nur der Grund, warum eine Verbindung beendet wurde: Quad9 hat sie nach getaner Arbeit zugemacht. Ein echter Block steht dort als deny. In den Einträgen standen außerdem übertragene Bytes in beide Richtungen – es lief also alles.

Manche Geräte sind DNS-Querulanten. Ohne die Umleitung für Googles DNS wären meine Echos nach Regel 1 einfach verstummt. Wer DNS sperrt, sollte vorher ins Log schauen, wer bisher wohin gefragt hat.

Ich habe ein Feature übersehen. Gebaut habe ich die Redundanz klassisch: Primary, Secondary, Zonentransfer. So habe ich das in meiner Laufbahn irgendwie immer gemacht, und auf den Cluster bin ich schlicht nicht gekommen. Erst beim Schreiben dieses Artikels ist mir aufgefallen, dass Technitium seit Version 14 einen eigenen Cluster kann – also schon in der Version, die ich installiert habe.

Der Unterschied ist nicht klein:

  • Zonentransfer gleicht nur die Zonen ab. Alles andere – Filterlisten, Einstellungen, Benutzer – pflege ich auf beiden Servern doppelt. Dafür ist es Standard-DNS und funktioniert mit jeder DNS-Software.
  • Ein Cluster verwaltet die Konfiguration zentral: Filterlisten, Einstellungen, Apps und Benutzer kommen vom primären Knoten, Zonen lassen sich über eine Katalog-Zone mitnehmen. Voraussetzung ist unter anderem HTTPS für die Weboberfläche, und den Cluster-Domainnamen kann man später nicht mehr ändern.

Für mein Setup wäre der Cluster vermutlich die bequemere Wahl gewesen – ausgerechnet der Abgleich zwischen zwei Servern war ja einer meiner Gründe für Technitium. Kaputt ist nichts – aber ich pflege seit Wochen Dinge doppelt, die ich nicht doppelt pflegen müsste. Ist blöd, lässt sich aber korrigieren. 😉

Fazit

DNS im Heimnetz selbst zu betreiben, ist kein Hexenwerk, aber erst mit der Firewall wird es rund: Die Technitium-Server liefern Namen, Filter und Verschlüsselung, die FortiGate sorgt dafür, dass niemand an ihnen vorbeikommt. Dazu eine bewusste Ausnahme für die Firewall selbst, damit sie nicht von Proxmox abhängt. Und eine Lektion zum Schluss: Was man seit Jahren so macht, ist nicht automatisch der beste Weg. Nachlesen, was die Software inzwischen kann, lohnt sich.

Was als Nächstes kommt

  • Umbau auf den Technitium-Cluster – mit eigenem Artikel, wenn es so weit ist.
  • AirPrint über VLAN-Grenzen per DNS: Mein Drucker steht in einem eigenen Netz, und die iPhones finden ihn trotzdem. Wie das mit ein paar DNS-Einträgen klappt, kommt in einem eigenen Artikel.