DNS Lab: Eigener Resolver mit AdGuard Home, Unbound und DoH/DoT
DNS ist einer dieser Dienste, die man lange ignoriert, bis man merkt, wie viel Metadaten darüber laufen. Im Lab sortiere ich AdGuard Home, Unbound, DoH/DoT und den Weg zum späteren Runbook.
DNS Lab:
DNS ist einer dieser Dienste, die man jahrelang einfach benutzt.
Router vom Provider.
Irgendein automatisch verteilter Resolver.
Vielleicht Google.
Vielleicht Cloudflare.
Vielleicht Vodafone, Telekom oder was auch immer gerade per DHCP reinkommt.
Und dann kommt irgendwann dieser Moment, an dem man sich fragt:
Warum entscheidet eigentlich irgendein fremder Resolver, welche Namen meine Geräte auflösen?
Natürlich ist DNS nicht das komplette Privacy-Problem im Internet. Wer das behauptet, verkauft wahrscheinlich gerade eine zu einfache Lösung. Cookies, Fingerprinting, Logins, IP-Adressen, App-Telemetrie und Browser-Tracking verschwinden nicht, nur weil man einen eigenen Resolver betreibt.
Aber DNS ist eben auch nicht egal.
DNS ist ein ziemlich zentraler Metadatenstrom: Welche Domains werden angefragt, wann, von welchem Gerät, wie oft?
Der Ideengeber für diesen Lab-Post war ein Video von The Morpheus Tutorials auf YouTube:
„Diese Schwachstelle haben wir alle unterschätzt“
Das war für mich nicht der Punkt “blind nachbauen und fertig”. Eher: guter Anlass, das Thema sauber für mein eigenes Setup zu sortieren.
AdGuard Home.
Unbound.
DoH.
DoT.
Blocklisten.
Mobile Geräte.
Firewall.
Allowlist.
Und die unangenehme Frage, ab wann ein privater Resolver wirklich privat ist.
Das hier ist deshalb bewusst ein Lab.
Kein finales Runbook.
Kein “kopiere diese Befehle und alles ist sicher”.
Sondern der Denkweg vor der Umsetzung.
Inspiration / Shoutout
Shoutout an The Morpheus Tutorials
Die Grundidee zu diesem DNS-Lab kam durch The Morpheus Tutorials. Sein Video und der dazu veröffentlichte DNS-Guide waren für mich der Auslöser, das Thema nicht nur oberflächlich anzuschauen, sondern sauber für mein eigenes Setup zu durchdenken.
Besonders wertvoll war für mich nicht einfach nur das Was, sondern das Wie: praxisnah, mit Blick auf echte Risiken und mit dem wichtigen Hinweis, dass ein Resolver ohne saubere Zugriffskontrolle schnell zum falschen Projekt wird.
Mein Artikel baut darauf nicht 1:1 auf, sondern dokumentiert den Weg, wie ich die Ideen gegen mein eigenes Setup halte, konsolidiere und später in ein generisches Runbook überführen will.
Moment — ich habe doch schon einen Pi-hole
Die naheliegende Frage ist natürlich:
Warum der ganze Aufwand, wenn ich doch schon einen Pi-hole habe?
Und die Frage ist berechtigt.
Pi-hole ist nicht schlecht. Im Gegenteil. Für das Heimnetz ist Pi-hole seit Jahren eine sehr gute Lösung: Geräte bekommen per DHCP den Pi-hole als DNS, Werbung und Tracker werden zentral geblockt, man sieht recht schnell, welche Geräte auffällig viel nach Hause telefonieren, und für viele Setups reicht das völlig aus.
Wenn es nur darum ginge, im LAN ein bisschen Werbung und Telemetrie zu reduzieren, müsste ich dieses Lab wahrscheinlich gar nicht anfangen.
Der Punkt ist ein anderer.
Mein bisheriges Pi-hole-Setup ist eher ein Heimnetz-Baustein. Was ich jetzt sortiere, ist ein anderer Betriebsmodus:
DNS nicht nur zuhause
DNS auch unterwegs
DNS verschlüsselt erreichbar
DNS mit eigenem Resolver dahinter
DNS als Teil meiner VPS-/Security-/Monitoring-ArchitekturDas ist eine andere Ebene.
Pi-hole beantwortet für mich vor allem diese Frage:
Wie filtere ich DNS-Anfragen in meinem lokalen Netz?Das neue Lab beantwortet eher:
Wie baue ich einen privaten DNS-Endpunkt, den ich bewusst betreibe,
absichere, überwache und auch mobil nutzen kann?Das ist mehr Aufwand, ja.
Mehr Konfiguration.
Mehr Zertifikate.
Mehr Firewall.
Mehr Monitoring.
Mehr Verantwortung.
Aber auch mehr Kontrolle.
Der effektive Gewinn wäre für mich:
DoH/DoT für Geräte außerhalb des Heimnetzes
zentrale DNS-Policy für mobile Geräte
weniger Abhängigkeit vom Provider-DNS
Unbound als eigener rekursiver Resolver
saubere Trennung zwischen Filter-Frontend und Resolver
bessere Integration in mein VPS-Betriebsmodell
dns1/dns2 als späteres Zielbild
Monitoring und Healthchecks wie bei anderen DienstenGleichzeitig will ich mir nichts schönreden.
Wenn am Ende nur ein zweites DNS-System entsteht, das mehr Pflege braucht und kaum echten Mehrwert bringt, dann ist das kein Fortschritt. Dann ist es nur Verwaltungsaufwand mit hübscherem Diagramm.
Genau deshalb ist dieser Beitrag ein Lab und noch kein Runbook.
Ich will zuerst klären:
Was gewinne ich gegenüber Pi-hole wirklich?
Welche Teile sind nur Spielerei?
Welche Teile sind sicherheitsrelevant?
Welche Teile brauche ich für mobile Geräte?
Welche Teile gehören später in ein sauberes Runbook?Der Pi-hole bleibt damit nicht “alt” oder “falsch”.
Er ist eher der Referenzpunkt.
Das neue Setup muss gegen ihn gewinnen. Nicht theoretisch, sondern praktisch.
Wenn AdGuard Home + Unbound + DoH/DoT am Ende nur komplexer ist, aber nicht besser in meinen Alltag passt, dann wäre die richtige Entscheidung nicht “trotzdem bauen”, sondern “Pi-hole behalten und gut”.
Aber wenn ich damit DNS sauberer aus dem reinen Heimnetz herauslöse, mobil nutzbar mache, verschlüsselt anbinde und in mein VPS-Monitoring bekomme, dann ist der Aufwand nicht Selbstzweck.
Dann wird aus einem Heimnetz-Filter ein bewusst betriebener DNS-Dienst.
Warum überhaupt ein eigener DNS-Resolver?
Ich will DNS nicht mehr einfach als Nebengeräusch behandeln.
In meinem Setup hängen inzwischen genug Geräte und Dienste daran:
MacBook
iPhone
Android
Smart TV
Server
VPS
Browser
Apps
Container
Monitoring
Und alle fragen ständig Namen ab.
Das ist technisch völlig normal. Ohne DNS macht das Internet wenig Spaß. Aber die Frage ist, wer diese Anfragen sieht und wer sie beeinflussen kann.
Ein eigener Resolver löst nicht alles. Aber er verschiebt Kontrolle zurück ins eigene Setup.
Das Ziel ist nicht:
Ich werde komplett anonym.
Das Ziel ist realistischer:
Ich verstehe besser, wo meine DNS-Anfragen landen.
Ich kann Werbung, Tracker und Malware-Domains zentral blocken.
Ich sehe pro Gerät, wer eigentlich wie laut ist.
Ich kann mobile Geräte per DoH/DoT anbinden.
Ich bin weniger abhängig vom Provider-DNS.
Ich kann DNS als Teil meiner eigenen Infrastruktur betreiben.
Das ist für mich schon ein deutlicher Schritt.
Was ich bauen will
Der Ziel-Stack ist im Kern überschaubar:
Clients
-> AdGuard Home
-> Unbound
-> Root / TLD / autoritative Nameserver
Oder etwas genauer:
Gerät
-> DoH / DoT / internes DNS
-> AdGuard Home als Filter-Frontend
-> Unbound als lokaler rekursiver Resolver
-> echte DNS-Hierarchie
AdGuard Home ist dabei der sichtbare Teil: UI, Clients, Query-Log, Blocklisten, DoH/DoT-Endpunkte.
Unbound ist der Resolver dahinter: rekursiv, lokal, DNSSEC-validierend, nicht einfach nur Forwarder zu Google oder Cloudflare.
Genau diese Trennung gefällt mir.
AdGuard Home ist bequem.
Unbound ist sauber.
Zusammen ergibt das einen Stack, der praktisch und trotzdem nachvollziehbar bleibt.
Was ich ausdrücklich nicht verspreche
Das muss direkt rein, sonst wird der Artikel unseriös.
Ein eigener DNS-Resolver ist kein magischer Privacy-Schild.
Er verhindert nicht automatisch:
Tracking über Cookies
Tracking über Logins
Tracking über Apps
Browser-Fingerprinting
IP-basierte Zuordnung
SNI/TLS-Metadaten
Telemetrie direkt über IPs
Hardcoded Resolver in Apps
DoH-Bypass einzelner Anwendungen
Und DNS-Blocking ersetzt auch keinen Browser-Adblocker.
DNS-Blocking arbeitet grob auf Domain-Ebene. Das ist sehr nützlich, aber nicht fein genug für alles. Ein Browser-Blocker kann zusätzlich auf URL-, Script- und Element-Ebene arbeiten.
Sauber formuliert:
DNS-Blocking ist eine starke Basis, aber nicht die komplette Lösung.
Genau das ist der Unterschied zwischen “klingt geil” und “kann ich später ehrlich betreiben”.
Die wichtigste Lehre aus dem Guide
Der wichtigste Punkt aus dem Morpheus-Guide ist für mich nicht “installiere Paket X”.
Der wichtigste Punkt ist:
Verschlüsselt heißt nicht automatisch privat.
Ein DoH- oder DoT-Endpunkt ist zwar verschlüsselt, aber ohne Zugriffskontrolle kann ihn im Zweifel jeder benutzen.
Das ist die Stelle, an der man sich leicht selbst belügt.
DoH aktiv
TLS gültig
AdGuard läuft
Unbound läuft
Port 53 ist zu
Klingt gut.
Aber wenn /dns-query öffentlich für jeden antwortet, betreibe ich trotzdem einen öffentlichen Resolver. Nur eben einen über HTTPS.
Für mich ist deshalb die erste harte Designentscheidung:
DoH/DoT nur mit Zugriffskontrolle.
Plain DNS niemals öffentlich.
Admin UI niemals öffentlich.
Das klingt streng, ist aber genau der Punkt. Ein privater Resolver wird nicht durch TLS privat. Er wird durch TLS und Zugriffskontrolle privat.
Architekturvariante A: schnell und einfach
Die einfachste Variante wäre:
Client -> AdGuard Home -> externer DoH/DoT Resolver
Also zum Beispiel:
MacBook -> AdGuard Home -> Quad9 / Cloudflare / AdGuard DNS / Mullvad DNS
Vorteile:
schnell eingerichtet
weniger Debugging
zentrales Blocking
verschlüsselter Upstream
gute UI
Nachteile:
externer Resolver bleibt im Spiel
Privacy hängt stark am Anbieter
du ersetzt Provider-DNS nur durch einen anderen zentralen Resolver
Das ist nicht sinnlos. Für viele Setups ist das sogar völlig okay.
Aber es ist nicht das, was ich eigentlich testen will.
Architekturvariante B: AdGuard Home plus Unbound rekursiv
Das ist die Variante, die mich am meisten interessiert:
Client -> AdGuard Home -> Unbound recursive -> DNS-Hierarchie
AdGuard filtert.
Unbound löst rekursiv auf.
Vorteile:
weniger Abhängigkeit von zentralen Public Resolvers
lokaler Cache
DNSSEC-Validierung in Unbound
QNAME-Minimization möglich
mehr Kontrolle
gute Selfhosting-DNA
Nachteile:
mehr Betrieb
mehr Debugging
Cold-Cache kann langsamer sein
VPS-Standort kann CDN/GeoDNS beeinflussen
rekursive Auflösung ist nicht durchgehend verschlüsselt
Der letzte Punkt ist wichtig.
Unbound rekursiv bedeutet nicht, dass jede Verbindung zu autoritativen Nameservern verschlüsselt ist. Der Privacy-Gewinn liegt eher darin, dass nicht ein einzelner großer Resolver deinen gesamten DNS-Verlauf zentral sieht.
Die Sichtbarkeit verteilt sich.
Das ist besser als “alles an einen Public Resolver”, aber nicht dasselbe wie Anonymität.
Architekturvariante C: Unbound als DoT-Forwarder
Die Mischvariante wäre:
Client -> AdGuard Home -> Unbound -> externer DoT Resolver
Hier nutzt man Unbound lokal, aber nicht vollständig rekursiv. Unbound forwardet verschlüsselt an definierte Upstream-Resolver.
Vorteile:
lokale Policy
lokaler Cache
verschlüsselter Upstream
saubere Komponententrennung
Nachteile:
externer Resolver bleibt zentrale Stelle
mehr Komponenten als nötig
weniger konsequent als rekursiver Betrieb
Das kann sinnvoll sein, wenn man bewusst einen vertrauenswürdigen Resolver nutzen will.
Für dieses Lab ist es aber eher die Ausweichvariante, nicht mein Favorit.
Mein geplanter Weg
Für mein Zielbild ist der geplante Weg:
AdGuard Home als Frontend
Unbound lokal auf 127.0.0.1:5335
AdGuard Upstream nur 127.0.0.1:5335
DoH über Reverse Proxy auf /dns-query
Plain DNS nur intern oder über WireGuard
DoT später nur, wenn das Zugriffskonzept sauber ist
Also erstmal:
Client -> DoH -> Reverse Proxy -> AdGuard Home -> Unbound
Und für Router/Home:
Router -> WireGuard -> AdGuard Home :53 -> Unbound
Das passt zu meiner Infrastruktur-DNA: öffentliche Dienste gehören hinter einen Reverse Proxy, interne Dienste gehören nicht einfach ins Internet, und Admin-Oberflächen haben draußen nichts verloren.
Das spätere Runbook soll trotzdem generisch bleiben. Keine privaten Automatisierungs-Skripte, keine produktiven Domains, keine Tokens, keine internen Sonderpfade.
Nur der nachvollziehbare Weg.
Was ich vor der Umsetzung festlegen muss
Bevor daraus ein Runbook wird, müssen ein paar Entscheidungen sauber getroffen werden.
Nicht währenddessen. Vorher.
Das ist genau der Sinn von Lab.
Entscheidung 1: Zugriffskontrolle ist Pflicht
Der Resolver darf nicht “aus Versehen öffentlich” sein.
Für DoH ist die wahrscheinlich sinnvollste erste Variante:
https://dns.example.tld/dns-query/<clientid>
Also DoH mit ClientID pro Gerät oder Gerätegruppe.
Für feste Netze kann zusätzlich eine IP- oder CIDR-Allowlist sinnvoll sein:
Heim-IP
WireGuard-Netz
eigene Server-Netze
Aber mobile Geräte wechseln ständig Netze. Genau deshalb reicht IP-Allowlisting für Mobile nicht aus.
Entscheidung 2: DoT kommt nicht blind in Phase 1
Android kann zwar nativ “Privates DNS”, und das ist bequem.
Aber genau diese Bequemlichkeit kann gefährlich werden.
Wenn ich Port 853 einfach öffne, damit Android glücklich ist, aber keine saubere ClientID-/Wildcard-/Allowlist-Strategie habe, ist das nicht privat. Dann ist es nur komfortabel.
Mein Phasenmodell ist deshalb:
Phase 1: DoH mit ClientID / Allowlist
Phase 2: WireGuard- oder VPN-DNS für eigene Netze
Phase 3: DoT nur mit sauberem Wildcard-/ClientID-Modell
Das ist weniger spektakulär als “alles sofort”, aber deutlich sauberer.
Entscheidung 3: Public Port 53 bleibt tabu
Plain DNS auf Port 53 gehört nicht öffentlich ins Internet.
Punkt.
Wenn Plain DNS gebraucht wird, dann nur intern:
WireGuard
LAN
Router
lokaler Client
Aber nicht:
Internet -> VPS:53
Das ist eine der Regeln, bei denen ich keine kreative Ausnahme brauche.
Entscheidung 4: Admin UI bleibt nicht öffentlich
AdGuard Home hat eine Admin-Oberfläche. Die ist praktisch.
Aber eine praktische Admin-Oberfläche ist kein Grund, sie öffentlich erreichbar zu machen.
Mein Zielbild:
Admin UI auf 127.0.0.1
Zugriff per SSH-Tunnel
oder Zugriff nur über VPN
oder Reverse Proxy mit sehr striktem Path-Matching, falls wirklich nötig
Für mein Setup reicht wahrscheinlich:
ssh -L 3000:127.0.0.1:3000 user@dns-server
Dann lokal im Browser öffnen.
Langweilig. Aber gut.
Entscheidung 5: Cloudflare Proxy ist hier keine Hilfe
Wenn die Subdomain für den Resolver über Cloudflare läuft, darf sie für dieses Setup nicht orange-geclouded sein.
Warum?
Weil dann Cloudflare TLS terminiert.
Und wenn Cloudflare TLS terminiert, sieht Cloudflare den DoH-Traffic.
Das kann man bewusst machen, aber dann ist es ein anderes Zielbild.
Für einen selbst betriebenen privaten Resolver gilt deshalb:
DNS record: DNS only
keine orange Cloud
A/AAAA zeigt direkt auf den Resolver
DoT funktioniert über Cloudflare Proxy ohnehin nicht
Das ist genau so ein Detail, das später im Runbook fett markiert werden muss.
Entscheidung 6: IPv6 nicht nebenbei aktivieren
IPv6 ist nicht automatisch schlecht.
Aber halb aktiviertes IPv6 ist schlecht.
Wenn ein AAAA-Record gesetzt ist, aber Firewall, Monitoring oder Dienstbindung nur für IPv4 sauber gedacht sind, habe ich mir einen blinden Fleck gebaut.
Also:
erst IPv6 Outbound prüfen
dann Firewall prüfen
dann Dienstbindung prüfen
dann extern scannen
dann AAAA setzen
Nicht andersherum.
Für Unbound gilt ebenfalls:
do-ip6: yes nur, wenn der VPS wirklich funktionierendes IPv6 hat
Sonst erzeugt man sich nur Timeouts und merkwürdige Latenz.
Blocklisten: nicht alles auf Maximum
Für die erste Runde will ich nicht “alles maximal”.
HaGeZi ist attraktiv, aber ich will nicht direkt die aggressivsten Varianten aktivieren und danach jede zweite App allowlisten.
Mein Start wäre eher konservativ:
AdGuard DNS Filter
HaGeZi Multi NORMAL
HaGeZi Threat Intelligence Feeds
optional später Dandelion Sprout Anti-Malware
Danach beobachten:
Was wird geblockt?
Was bricht?
Welche Geräte sind laut?
Welche Allowlist brauche ich wirklich?
Gerade Smart TVs und Streaming-Apps sind hier der Praxistest.
Privacy ist gut. Wohnzimmer kaputt ist schlecht.
Geräte: Der echte Alltagstest
Technisch kann so ein Setup schnell funktionieren.
Die spannendere Frage ist: Funktioniert es auf echten Geräten im Alltag?
Desktop / Browser
Am Desktop kann man DNS relativ einfach setzen. Aber Browser können eigene DoH-Einstellungen haben.
Das heißt: Nur weil das Betriebssystem meinen Resolver nutzt, muss der Browser das nicht automatisch tun.
Das gehört ins spätere Runbook:
System-DNS prüfen
Browser-DoH prüfen
Fallback-Verhalten prüfen
iPhone / macOS
Bei Apple-Geräten läuft es eher über Profile beziehungsweise verwaltete DNS-Einstellungen.
Das ist nicht schlimm, aber es muss sauber dokumentiert werden:
Profil erzeugen
Profil installieren
Profil testen
Profil entfernen
Gerade der Rückbau gehört dazu. Ein Profil, das man später nicht mehr versteht, ist keine gute Idee.
Android
Android ist bequem und gleichzeitig der Grund, warum man DoT zu früh öffnen möchte.
“Privates DNS” ist für Nutzer angenehm, aber bei ClientID/Allowlist-Konzepten muss man genauer hinschauen.
Für Phase 1 ist DoH mit ClientID über eine App eventuell der bessere Weg. Für langfristig saubere UX kann DoT mit Wildcard-Zertifikat und Subdomain-ClientIDs interessant werden.
Aber nicht als Schnellschuss.
Smart TV
Smart TVs sind der Teil, auf den ich fast am meisten gespannt bin.
Nicht weil sie technisch schön sind. Eher im Gegenteil.
Viele TVs und Streaming-Apps sind extrem gesprächig. Genau da kann DNS-Blocking sichtbar etwas bringen.
Aber hier ist auch das Risiko für False Positives hoch.
Wenn nach dem Einschalten erstmal Netflix, Disney, YouTube oder die Mediathek zickt, ist das Setup zu aggressiv.
Dann hat man nicht gewonnen. Dann hat man nur ein neues Problem gebaut.
Betrieb: DNS ist Infrastruktur
Ein eigener Resolver ist kein “set and forget”.
Wenn DNS kaputt ist, fühlt sich für normale Nutzer das ganze Internet kaputt an.
Deshalb gehören in den späteren Betrieb:
Healthcheck
Cert-Renewal-Check
DNSSEC-Negativtest
Open-Resolver-Test
DoH-Test von außen
Portscan IPv4 und IPv6
Backup von AdGuard/Unbound/Cert-Konfig
zweiter Resolver
Monitoring
Der Cert-Renewal-Punkt ist besonders fies.
Ein Zertifikat läuft nicht dramatisch aus. Es ist einfach irgendwann kaputt. Und dann funktionieren DoH/DoT-Clients still nicht mehr.
Genau das muss Monitoring sehen.
Auch ein zweiter Resolver ist langfristig sinnvoll.
Nicht zwingend am ersten Lab-Abend, aber als Zielbild:
dns1.example.tld
dns2.example.tld
Am besten nicht beide beim gleichen Provider und nicht beide im gleichen Fehlerbereich.
Sonst ist die Redundanz eher Deko.
Was später ins Runbook gehört
Das spätere Runbook soll eine generische Umsetzung zeigen.
Nicht mein privates Setup.
Nicht meine internen Automatisierungs-Skripte.
Nicht meine echten Domains.
Nicht meine Tokens.
Nicht meine produktiven Pfade.
Sondern:
Debian 12 Basis
AdGuard Home installieren
Unbound installieren
Unbound auf 127.0.0.1:5335
AdGuard Upstream auf 127.0.0.1:5335
Reverse Proxy nur für /dns-query
Admin UI nur lokal / SSH-Tunnel
Allowlist / ClientID Pflicht
Port 53 niemals öffentlich
DoT erst später sauber
Tests mit dig/kdig
Open-Resolver-Test
Cert-Renewal-Test
Rollback
Das ist der Kompromiss:
öffentlich nachvollziehbar
technisch sauber
keine privaten Ops-Skripte
keine echten Secrets
keine unnötige Angriffsfläche
Und genau so sollte es sein.
Was ich vor dem Runbook noch testen will
Bevor ich daraus ein Runbook schreibe, will ich diese Punkte wirklich testen:
Funktioniert DoH mit ClientID stabil?
Wie sauber greifen Allowed Clients in AdGuard Home?
Wie verhält sich iOS/macOS mit Profilen?
Welche Android-Variante ist im Alltag am brauchbarsten?
Wie stark steigen Latenzen bei rekursivem Unbound?
Welche Blocklisten sind alltagstauglich?
Welche Streaming-Apps brechen bei zu aggressiven Listen?
Wie prüfe ich zuverlässig, dass ich kein Open Resolver bin?
Wie überwache ich Cert-Renewal sinnvoll?
Wie sieht ein sauberer Fallback mit dns2 aus?
Das ist der Punkt, an dem Lab endet und Runbook beginnt.
Lab ist Denken, Sortieren, Testfragen formulieren.
Runbook ist: umsetzen, prüfen, verproben.
Mein aktuelles Zielbild
Nach dem Quellenabgleich ist mein Zielbild klarer geworden:
dns1 und später dns2 als eigene Resolver-Nodes
AdGuard Home als Filter-Frontend
Unbound rekursiv dahinter
DoH über Reverse Proxy
nur /dns-query öffentlich
Admin UI nicht öffentlich
Plain DNS nur intern/VPN
DoT nicht in Phase 1
Allowlist / ClientID verpflichtend
IPv6 bewusst, nicht nebenbei
Monitoring für DNSSEC, DoH, Certs und Open-Resolver-Zustand
Das ist nicht die schnellste Variante.
Aber sie passt zu dem, was ich eigentlich will: ein Setup, das ich verstehe und später betreiben kann.
Fazit
Der Morpheus-Impuls war gut, weil er das Thema wieder auf den Tisch gelegt hat.
DNS ist nicht nur ein technisches Detail. DNS ist ein ziemlich zentraler Teil der eigenen Infrastruktur.
Aber genau deshalb will ich es nicht schnell zusammenklicken.
AdGuard Home + Unbound ist ein sehr guter Stack. DoH/DoT sind sinnvoll. Blocklisten bringen echten Alltagsnutzen. Aber “verschlüsselt” ist nicht automatisch “privat”, und ein öffentlicher DoH-Endpunkt ohne Zugriffskontrolle wäre nur ein neues Problem mit schönerem Protokoll.
Für mich ist der Lab-Stand deshalb:
Ja, eigener DNS-Resolver ergibt Sinn.
Ja, AdGuard Home + Unbound ist der richtige Start.
Ja, DoH ist Phase 1.
Ja, WireGuard-DNS ist für eigene Netze sinnvoll.
Nein, DoT kommt nicht blind in Phase 1.
Nein, Port 53 wird nicht öffentlich.
Nein, ohne Allowlist/ClientID ist das Setup nicht fertig.Der nächste Schritt ist damit klar:
Erst das Zielbild sauber festlegen.
Dann die kritischen Sicherheitsentscheidungen treffen.
Dann eine generische Umsetzung entwickeln und testen.
Und erst danach daraus ein Runbook machen.
Nicht andersherum.
Denn ein DNS-Resolver ist kein Spielzeugdienst. Wenn er falsch offen ist, betreibt man schnell keinen privaten Resolver, sondern einen öffentlichen Dienst mit hübscher Verschlüsselung.
Genau deshalb gehört dieser Artikel zuerst ins Lab: als Denkweg, Architekturabgleich und Sicherheitsnotiz vor der eigentlichen Umsetzung.
Quellen / Ideengeber
- The Morpheus: „Diese Schwachstelle haben wir alle unterschätzt“
https://youtu.be/0cBZR4wy3ec?si=OJHfd_UDmM-Hw7AC - The Morpheus Tutorials: Patreon-Post „DNS Guide“
https://www.patreon.com/posts/157177525 - AdGuard Home Wiki: Configuration
https://github.com/AdguardTeam/AdGuardHome/wiki/Configuration - AdGuard Home Wiki: Encryption
https://github.com/AdguardTeam/AdGuardHome/wiki/Encryption - AdGuard Home Wiki: Clients
https://github.com/AdguardTeam/AdGuardHome/wiki/Clients - NLnet Labs: Unbound documentation / unbound.conf
https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html - HaGeZi DNS Blocklists
https://github.com/hagezi/dns-blocklists - HaGeZi DNS Blocklists FAQ
https://github.com/hagezi/dns-blocklists/wiki/FAQ - Apple Developer Documentation: DNS Settings
https://developer.apple.com/documentation/networkextension/dns-settings