{"id":448,"date":"2026-09-07T12:20:00","date_gmt":"2026-09-07T10:20:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/?p=448"},"modified":"2026-10-24T00:58:26","modified_gmt":"2026-10-23T22:58:26","slug":"zero-trust-dns-infrastruktur-unbound-pi-hole-mit-doh-und-dnssec","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/it-networks-de\/tutorials-de-it-networks-de\/zero-trust-dns-infrastruktur-unbound-pi-hole-mit-doh-und-dnssec\/","title":{"rendered":"Zero-Trust-DNS-Infrastruktur: Unbound & Pi-hole mit DoH und DNSSEC"},"content":{"rendered":"
Pi-hole und Unbound \u00fcbernehmen zwei unterschiedliche Aufgaben: Pi-hole filtert DNS-Namen anhand von Regeln, Unbound ermittelt die zugeh\u00f6rigen Antworten und pr\u00fcft DNSSEC. Damit entf\u00e4llt ein zentraler \u00f6ffentlicher Resolver als vorgeschaltete Sammelstelle. Abh\u00e4ngigkeiten von Root-, TLD- und autoritativen DNS-Servern bleiben bestehen. Die Kombination allein ergibt noch keine vollst\u00e4ndige Zero-Trust-Architektur.<\/p>\n
1. Was Filter, Rekursion und DNSSEC leisten<\/h2>\n
DNS \u00fcbersetzt Namen wie example.com<\/code> in Adressen. Ein \u00f6ffentlicher Resolver kann die empfangenen Namen protokollieren; vollst\u00e4ndige URL-Pfade, Seiteninhalte und s\u00e4mtliche Netzwerkmetadaten geh\u00f6ren jedoch nicht zu einer gew\u00f6hnlichen DNS-Abfrage.<\/p>\n
\n
Pi-hole:<\/strong> bearbeitet Abfragen von Ger\u00e4ten, die Pi-hole tats\u00e4chlich als DNS-Server verwenden. Blocklisten erfassen bestimmte Domains, keine vollst\u00e4ndige Werbe- oder Schadsoftware-Erkennung. Browser mit eigenem DoH k\u00f6nnen den lokalen Filter umgehen.<\/li>\n
Unbound:<\/strong> beantwortet erlaubte, nicht bereits zwischengespeicherte Anfragen durch Rekursion. Dabei f\u00fchren Verweise von Root- \u00fcber TLD- zu autoritativen Servern; vorhandene Cache-Eintr\u00e4ge verk\u00fcrzen den Weg.<\/li>\n
DNSSEC:<\/strong> pr\u00fcft signierte DNS-Daten anhand einer Vertrauenskette. Fehlerhafte Signaturen f\u00fchren zur Ablehnung. Korrekt als unsigniert erkannte Zonen bleiben nutzbar, erhalten aber keine kryptografisch best\u00e4tigte Echtheit. DNSSEC verschl\u00fcsselt keine Anfragen.<\/li>\n<\/ul>\nPi-hole filtert konfigurierte Clients; Unbound l\u00f6st Namen auf und pr\u00fcft signierte DNS-Daten. Direkte Rekursion nutzt gew\u00f6hnlich unverschl\u00fcsselten Transport.<\/figcaption><\/figure>\n
2. Beispiel f\u00fcr Debian oder Raspberry Pi OS<\/h2>\n
Das Beispiel setzt Pi-hole und Unbound auf demselben Host ohne getrennte Container-Netze voraus. \u00c4nderungen an einem verwendeten DNS-Dienst k\u00f6nnen die Namensaufl\u00f6sung unterbrechen; eine Sicherung der bisherigen Konfiguration und ein erreichbarer Verwaltungszugang geh\u00f6ren zur Vorbereitung. Ausgehendes UDP und TCP auf Port 53 m\u00fcssen f\u00fcr die Rekursion verf\u00fcgbar sein.<\/p>\n
Installation aus den gepflegten Distributionspaketen:<\/p>\n
Vor einer zus\u00e4tzlichen Konfiguration ist die Paketkonfiguration unter \/etc\/unbound\/<\/code> zu pr\u00fcfen. Debian-Pakete richten \u00fcblicherweise Root-Hints und den DNSSEC-Vertrauensanker bereits ein. Ein vorhandenes auto-trust-anchor-file<\/code> darf nicht nochmals f\u00fcr dieselbe Datei eingetragen werden. Der Unbound-Dienst braucht Schreibzugriff auf den automatisch gepflegten Anker. Fehlt diese Einrichtung, ist zun\u00e4chst die Anleitung des Distributionspakets ma\u00dfgeblich.<\/p>\n
Folgendes Fragment f\u00fcr \/etc\/unbound\/unbound.conf.d\/pi-hole.conf<\/code> erg\u00e4nzt diese Paketkonfiguration:<\/p>\n
do-ip6: no<\/code> w\u00e4hlt hier IPv4 f\u00fcr den Transport; AAAA-Datens\u00e4tze bleiben abfragbar. Bei funktionierender nativer IPv6-Anbindung kann yes<\/code> sinnvoll sein. Das Fragment definiert bewusst keinen zweiten Vertrauensanker und ist keine eigenst\u00e4ndige vollst\u00e4ndige Konfiguration.<\/p>\n
Erst nach erfolgreicher Konfigurationspr\u00fcfung folgt der Neustart. Die folgenden Zeilen sind nacheinander auszuf\u00fchren; bei einem Fehler der ersten Pr\u00fcfung ist der Neustart abzubrechen:<\/p>\n
Der erste DNS-Test soll SERVFAIL<\/code> liefern, der zweite NOERROR<\/code> mit ad<\/code> im Flag-Feld. Ein einzelnes SERVFAIL<\/code> beweist keine funktionierende Validierung: Auch Verbindungsfehler k\u00f6nnen diese Antwort verursachen. Eine korrekte Systemzeit ist f\u00fcr DNSSEC erforderlich. restart<\/code> aktiviert keinen Autostart; is-enabled<\/code> pr\u00fcft den bestehenden Zustand.<\/p>\n
3. Pi-hole verbinden und den tats\u00e4chlichen Weg pr\u00fcfen<\/h2>\n
Unter Settings > DNS<\/code> wird 127.0.0.1#5335<\/code> als benutzerdefinierter Upstream eingetragen. F\u00fcr ausschlie\u00dflich lokale Rekursion werden andere Upstreams entfernt. Nach dem Speichern sollte eine Testabfrage an Pi-hole im Abfrageprotokoll Unbound als Weiterleitungsziel zeigen. Bei getrennten Containern bezeichnet 127.0.0.1<\/code> jeweils den eigenen Container; dort ist diese Adresse ungeeignet.<\/p>\n
Die Option Use DNSSEC<\/code> aktiviert zus\u00e4tzliche Validierung in Pi-hole und ist keine blo\u00dfe Weitergabe von Statusflags. Unbound validiert bereits unabh\u00e4ngig davon. Falls die zus\u00e4tzliche Pr\u00fcfung aktiviert wird, sind beide DNSSEC-Tests nochmals \u00fcber Pi-hole auszuf\u00fchren. Vorhandene openresolv<\/code>– oder unbound-resolvconf<\/code>-Integration ben\u00f6tigt ebenfalls Kontrolle: Ein Eintrag f\u00fcr Port 53 darf keine Schleife zum lokalen Dienst erzeugen.<\/p>\n
4. DoH als andere Betriebsart<\/h2>\n
Bei direkter Rekursion verlassen gew\u00f6hnliche DNS-Anfragen das Netz unverschl\u00fcsselt. QNAME-Minimierung reduziert die Namensteile, die einzelne Server erhalten; ein Beobachter auf der Internetleitung kann weiterhin Anfragen mitlesen.<\/p>\n
Ein bewusst eingerichteter DoH-Upstream verschl\u00fcsselt die Verbindung zu einem gew\u00e4hlten Resolver. Dieser Resolver erh\u00e4lt die weitergeleiteten Namen. Das ist eine andere Architektur, kein automatisch vorhandener R\u00fcckfallmodus. Ein zus\u00e4tzlicher Pi-hole-Upstream ist auch keine garantierte Reihenfolge f\u00fcr Ausf\u00e4lle. Zertifikatspr\u00fcfung, Bootstrap-Aufl\u00f6sung und das Verhalten bei Nichterreichbarkeit ben\u00f6tigen eine eigene Konfiguration.<\/p>\n
cloudflared proxy-dns<\/code> wurde ab Version 2026.2.0 entfernt und ist keine aktuelle Installationsoption. Unbounds dokumentierte DoH-Unterst\u00fctzung f\u00fcr eingehende Client-Abfragen ist au\u00dferdem von ausgehender DoH-Weiterleitung zu unterscheiden.<\/p>\n
\n
Fragen und Antworten<\/h2>\n
Sch\u00fctzt das vor Beobachtung durch den Internetanbieter?<\/h3>\n
Direkte Rekursion allein nicht. DoH sch\u00fctzt den Inhalt der jeweiligen DNS-Verbindung; Ziel-IP-Adressen sp\u00e4terer Verbindungen bleiben grunds\u00e4tzlich sichtbar. DNSSEC sch\u00fctzt signierte Daten vor unbemerkter Ver\u00e4nderung, verhindert aber weder Blockaden noch Angriffe auf unsignierte DNS-Daten. Verschl\u00fcsselte Client-Verbindungen zu einem eigenen Resolver lassen sich mit Rekursion kombinieren; dadurch wird der Weg vom Resolver zu autoritativen Servern nicht automatisch verschl\u00fcsselt.<\/p>\n
Warum fehlen Antworten mit privaten IP-Adressen?<\/h3>\n
private-address<\/code> verhindert, dass \u00f6ffentliche DNS-Antworten die genannten privaten Adressen einschleusen. F\u00fcr einen absichtlich intern aufl\u00f6senden Namen kann eine eng begrenzte Ausnahme wie private-domain: \"internal.example.com\"<\/code> erforderlich sein. Eine Ausnahme f\u00fcr eine ganze Domain gilt auch f\u00fcr Unterdomains und schw\u00e4cht dort den Rebinding-Schutz. Direkt in Pi-hole beantwortete lokale Eintr\u00e4ge laufen nicht durch Unbound.<\/p>\n<\/div>\n
![\"Pi-hole](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/quality-448-20261024.png\")