Verschlüsseltes DNS ohne VPN verbirgt die Abfrage, nicht Ihre Adresse
Verschlüsseltes DNS schützt einen Austausch mit einem Resolver. Es verbirgt Ihre Adresse nicht und macht den Resolver nicht blind, also legen Sie das Ziel fest, bevor Sie einen Leak-Test lesen.
Ein DNS-Leak-Test, der Ihr Heimnetz zeigt, ist kein Beweis dafür, dass verschlüsseltes DNS versagt hat, und auch kein Beweis dafür, dass irgendetwas funktioniert hat. Der Test beantwortet eine Frage: Welcher Resolver hat diese Abfrage aus diesem Netz erreicht. Ob das ein Problem ist, hängt davon ab, wovor und vor wem Sie geschützt haben.
Schreiben Sie das Ziel auf, bevor Sie irgendeinen Test ausführen.
Schritt 1: Benennen Sie den Schutz, den Sie wirklich wollen
Drei Ziele vermischen sich. Vielleicht möchten Sie, dass ein Beobachter auf dem Pfad aufhört, Abfragen zu lesen. Vielleicht möchten Sie, dass ein bestimmter Resolver aufhört, sie zu empfangen. Vielleicht möchten Sie, dass die Websites, die Sie besuchen, aufhören, Ihre Heimatadresse zu sehen. Verschlüsseltes DNS dient dem ersten, ändert, wer das zweite erfüllt, und tut für das dritte überhaupt nichts.
Ein VPN dient dem dritten und, je nach Anbieter, dem ersten. Keines der Werkzeuge ist eine Obermenge des anderen.
Schritt 2: Wählen Sie einen Resolver und prüfen Sie seine Identität
DNS over TLS verpackt die Abfrage in eine TLS-Sitzung mit dem Resolver, und DNS over HTTPS verpackt sie in eine HTTP-Anfrage; RFC 7858 und RFC 8484 beschreiben beides, und keines braucht einen Tunnel. Operativ entscheidend ist, dass das Zertifikat gegen den von Ihnen konfigurierten Namen geprüft wird, denn eine verschlüsselte Sitzung mit der falschen Seite ist schlimmer als Klartext mit der richtigen. Das bedeutet strenger Modus, wo die Plattform ihn anbietet, nicht ein opportunistischer Modus, der bei fehlgeschlagener Prüfung zurückfällt. Prüfen Sie die Sitzung direkt, bevor Sie der Einstellung vertrauen: openssl s_client -connect 9.9.9.9:853 -servername dns.quad9.net -brief.
Der Handshake sollte den von Ihnen konfigurierten Resolver nennen und eine Kette zurückgeben, die Sie prüfen können.
Schritt 3: Legen Sie das Verhalten bei Fehlern fest
Jede Implementierung hat eine Richtlinie für einen nicht erreichbaren verschlüsselten Resolver, und diese Richtlinie ist die Datenschutzentscheidung. Der strenge Modus lässt die Auflösung scheitern, was sichtbar und lästig ist. Der opportunistische Modus versucht es im Klartext erneut, was unsichtbar ist und den Zweck genau an dem Tag zunichtemacht, an dem es darauf ankommt. Wählen Sie bewusst und notieren Sie die Wahl neben der Anforderung.
Auf systemd-resolved bedeutet das DNSOverTLS=yes statt opportunistic; auf Android bedeutet es den Hostnamen-Modus für Private DNS statt automatisch.
Prüfen Sie mit Folgendem, was tatsächlich in Kraft ist: resolvectl status | grep -i -A1 "dns over tls", denn eine drop-in-Datei, die nie neu geladen wurde, ändert nichts.
Schritt 4: Prüfen Sie, ob Anwendungen dem System-Resolver folgen
Ein Browser mit eigener Einstellung für sicheres DNS umgeht die Systemkonfiguration vollständig, ebenso eine Container-Runtime mit eingebettetem Resolver oder eine Sprach-Runtime, die eine fest codierte Liste liest. Bringen Sie diese entweder dazu, dem System zu folgen, oder konfigurieren Sie sie ausdrücklich und halten Sie das fest. Schauen Sie sich dann das Rückfallverhalten jedes Einzelnen an, denn nicht alle scheitern geschlossen. Das Inventar ist in der Praxis kurz: Browser, Container-Runtime und welchen VPN-Client Sie sonst noch betreiben.
Private Organisationsnamen bleiben beim freigegebenen internen Resolver. Sie an einen öffentlichen Dienst zu schicken, damit ein Test ordentlich aussieht, schafft absichtlich ein anderes Problem.
Schritt 5: Lesen Sie den Leak-Test gegen die Anforderung
Ein Test, der einen unerwarteten Resolver meldet, ist ein Hinweis, kein Urteil. Möglicherweise hat er Ihren beabsichtigten verschlüsselten Resolver beobachtet, eine anwendungsspezifische Einstellung oder einen Klartext-Rückfall, den Sie nicht kannten. Vergleichen Sie den gemeldeten Resolver mit dem, was Schritt 2 konfiguriert hat, und vergleichen Sie das Ergebnis mit dem Ziel aus Schritt 1.
Wenn das Ziel war, Abfragen vom lokalen Netz fernzuhalten, ist ein Test, der Ihren gewöhnlichen Resolver zeigt, ein echter Befund. Wenn das Ziel Anonymität beim Surfen war, hätte keine DNS-Einstellung das je geliefert.
Schreiben Sie die Abnahmebedingung in der Sprache des Ziels: Diese Auflösungen verwenden diesen geprüften Resolver unter diesen Bedingungen. Alles Weitergehende ist eine Behauptung, die Sie nicht testen können.