Hallo Forum,
ich habe eine Anleitung gefunden um auf einem VPS einen eigenen privaten DNS-
Resolver zu bauen: https://www.patreon.com/posts/dns-guide-157177525
Ich habe mir diese Anleitung durchgelesen und bin mir nicht sicher was ich davon halten soll. Wie seht ihr das, spricht etwas gegen dieses Setup? Setze ich mich eines unnötigen Risikos aus, wenn ich das so betreibe?
Über Feedback von den Profis hier würde ich mich freuen.
Liebe Grüße 
Stelle dir erst einmal die Frage was du erreichen willst. Wenn du den DNS von überall, also auch unterwegs mit dem Ackerschnacker nutzen willst - ohne VPN nach Hause - kann diese Variante Sinn ergeben. Rein technisch scheint das Konzept - so weit ich das beurteilen kann - in Ordnung.
Wenn es nur für dich zu Hause sein soll, geht es auch einfacher.
Habe ich selbst auch zu laufen. Besteht bei mir aus einem Router mit OpnSense und unbound sowie AdGuardHome (alles auf dem Router). Macht im Grunde nichts anderes als das was da beschrieben ist. Und ist vermutlich einfacher zu betreiben und abzusichern, weil alles ohnehin hinter der FW hängt. Mal abgesehen von den laufenden Kosten für einen VPS.
Danke @Pittiplatsch für deine Einschätzung. 
Wie machst du das mit Unbound und DoH? Ich kenne die Anleitung vom Mike mit dem Pi-Hole und Unbound. Wenn ich das Ganze aber noch zusätzlich mit DoH nutzen möchte, brauche ich doch eine Domain. Oder verstehe ich da etwas total falsch?
Kann man prinzipiell so machen. Ich würde allerdings eine Container-basierte Lösung bevorzugen, da einfacher zu managen, man eine getestete Umgebung bekommt und man mit minimalem Overhead verschiedene Services parallel laufen lassen kann. Nachteil ist allerdings, dass man zusätzlich lernen muss mit Containern umzugehen. Wenn man mehre Services selbst hosten will, lohnt sich das allerdings.
Randnotiz: Finde das Hosten eines eigenen DNS-Resolvers ziemlich unnötig, da man sowieso den Resolver des VPNs verwenden sollte.
Ich würde zunächst prüfen, ob Unbound bei dir überhaupt wirklich rekursiv arbeitet oder aufgrund von Debian/OpenResolv unbeabsichtigt als Forwarder läuft. Das ist unter Bullseye/Bookworm leider nicht ganz unüblich.
Der aussagekräftigste Test ist:
sudo unbound-control lookup example.com
Bei echter Rekursion sieht man dort die DNS-Hierarchie bzw. Delegationskette (Root-/TLD-/autoritative Nameserver). Wenn stattdessen nur lokale oder externe Resolver auftauchen bzw. forwarding request: erscheint, arbeitet Unbound als Forwarder.
Zur eigentlichen DoH-Frage:
Bei einem rekursiven Resolver bringt DoH deutlich weniger als bei klassischen Upstream-Resolvern wie Cloudflare oder Quad9. In deinem Setup würde DoH typischerweise nur noch die Verbindung zwischen Client und dem eigenen Resolver verschlüsseln. Die rekursive Kommunikation von Unbound zu Root-, TLD- und autoritativen Nameservern erfolgt weiterhin über klassisches DNS (UDP/TCP 53).
Wichtig ist dabei: Wenn man DoH nutzen möchte, muss als DoH-Server der eigene Resolver (also die eigene Pi-hole-/Unbound-Instanz) eingetragen werden. Trägt man stattdessen z. B. Quad9 oder Cloudflare im Client ein, wird das lokale Pi-hole-/Unbound-Setup vollständig umgangen und der Client spricht direkt mit dem externen Resolver.
Für eigenes DoH benötigt man außerdem einen HTTPS-Endpunkt inklusive TLS-Zertifikat. Das bedeutet einen HTTPS-fähigen Webserver bzw. Reverse Proxy vor Unbound sowie ein entsprechendes Zertifikat (z. B. Let’s Encrypt oder Self-signed). Ich denke darauf wolltest du mit deiner Frage nach der „eigenen Domain“ auch hinaus. Anyway: Für ein Heimnetz mit rekursivem Unbound erscheint mir der zusätzliche Aufwand im Verhältnis zum Nutzen eher gering.
Fazit: Der eigentliche Privacy-Vorteil eines rekursiven Resolvers entsteht bereits dadurch, dass keine zentrale DNS-Instanz mehr alle Anfragen sieht. DoH bringt in diesem Szenario hauptsächlich noch auf der Strecke zwischen Client und lokalem Resolver einen zusätzlichen Vorteil.
Entschuldige bitte. Ich habe mich da in meinem Beitrag falsch ausgedrückt. Ich nutze eben nicht DoT oder DoH. Ich will die DNS-Filterfunktionen nutzen und nicht durch DoT erschweren oder gar durch DoH umgehen.
DoT und inbesondere DoH machen daher für mich überhaupt keinen Sinn. Die kann ich nämlich nicht ohne Weiteres im DNS filtern. Denn ich müsste um irgend etwas filtern zu können, entweder wie hier bereits beschrieben einen DoH-fähigen DNS-Server aufsetzen, was mir zu aufwendig und kompliziert ist. Unbound zumindest unter OpnSense (BSD-basiert) kann m. W. weder DoT noch DoH.
Oder aber ich müsste die Verschlüsselung aufbrechen, um DoH zu verhindern bzw. zu filtern. Das wiederum ist das Letzte was ich tun werde. Und das hat auch einen praktischen Grund. Ich bräuchte einen Proxy etc., an dem die Verschlüsselung zwecks Paketinspektion terminiert wird. So was gibt es z. B. in Form der TrutzBox. Anschließend würde dieses Gerät die Verbindung dann zum eigentlichen Ziel verschlüsseln, zurück das Ganze „in Grün“.
Aber aus eigener dienstlicher Erfahrung weiß ich, dass ich in so einem Fall nie das SSL-/TLS-Zertifikat der Gegenstelle zu sehen bekomme. Und spätestens beim Homebanking z. B. wäre mir das zu unsicher.
@Cyberduck , ich will mich nicht zu deinen technischen Angaben äußern. Da bist du von uns beiden offenbar der besser informierte.
Aber was DoT und DoH an sich anbelangt, sehe ich da hinsichtlich Datenschutz keine echten Vorteile gegenüber DNSsec. Denn ob man meine DNS-Abfragen unterwegs mitliest oder anschließend die Datenpakete mitschneidet, die ich an das Ziel sende ist letztlich weitgehend irrelevant. Beides kann ich nicht wirklich verhindern und beides verrät das Ziel. Wenn auch nicht den Inhalt. Aber mit unbound als Round-Rubin-Resolver direkt an die DNS-Root-Server können zumindest die Betreiber der sonstigen vielen DNS-Resolver nicht alle Abfragen mitlesen. Und selbst die Root-Server bekommen nicht alles durchgehend mit, weil es halt „reihum“ geht.
Ich glaube, hier werden gerade ein paar unterschiedliche Ebenen vermischt. Dass DoH die lokale DNS-Filterung erschwert bzw. teilweise umgeht, stimmt natürlich. Genau aus diesem Grund nutzen viele bewusst kein externes DoH, beispielsweise mit Pi-hole oder Unbound.
Der zitierte Abschnitt beschreibt allerdings eher TLS-/HTTPS-Inspektion bzw. einen klassischen MITM-Proxy. Das ist technisch etwas anderes als eigenes DoH mit vorgeschaltetem HTTPS-Endpunkt bzw. Reverse Proxy. Für eigenes DoH muss man keine HTTPS-Verbindungen von Webseiten „aufbrechen” oder Zertifikate von Banking-Seiten ersetzen. Benötigt wird lediglich ein HTTPS-Endpunkt inklusive Zertifikat für den eigenen DNS-Resolver. Die eigentlichen Webseiten-Zertifikate bleiben davon unberührt. DNS-Verschlüsselung und HTTPS-Verschlüsselung sind zwei unterschiedliche Sachen.
Im Kern wollte ich das auch (fast) so verstanden wissen. Meiner Meinung nach entsteht der eigentliche Privacy-Vorteil eines rekursiven Resolvers vor allem dadurch, dass keine zentrale DNS-Instanz mehr sämtliche Anfragen vollständig mitlesen kann. Stattdessen verteilt sich die Auflösung über Root-, TLD- und autoritative Nameserver.
DNSSEC und DoH/DoT erfüllen dabei allerdings unterschiedliche Aufgaben. DNSSEC stellt die Integrität und Authentizität der DNS-Antworten sicher, aber nichts wird verschlüsselt. Im Kontext des Datenschutzes also praktisch irrelevant. DoH/DoT verschlüsseln hingegen den Transportweg zwischen Client und Resolver.
Bei einem rekursiven Resolver reduziert sich der zusätzliche Privacy-Gewinn von DoH/DoT, da ohnehin keine zentrale Resolver-Instanz alle Anfragen sieht. Die Root-Server sehen auch nicht die komplette Zielauflösung, sondern primär die Delegation zur jeweiligen TLD. Die vollständige Domain sieht letztlich erst der autoritative Nameserver der Zielzone.
In einem Heimnetz erscheint mir rekursives Unbound mit DNSSEC daher sinnvoller und transparenter als DoH zu einem zentralen Anbieter wie Cloudflare oder Quad9. DNSSEC ist bei Unbound ohnehin integraler Bestandteil der rekursiven Validierung und wird insbesondere bei Root- und vielen TLD-Zonen bereits weit verbreitet eingesetzt. Das konnten wir ja erst vorgestern bei der Störung der DENIC erleben.
Danke für euren Input und die Denkanstöße.