DNS-Leak-Test: Ein Resolver-Name ist nicht die Route

Drei Anordnungen gelten als korrektes DNS für einen VPN-Nutzer: Abfragen an den Resolver des Anbieters, Abfragen an einen verschlüsselten Resolver Ihrer Wahl und Split-DNS, das Arbeitsnamen an die Organisation schickt. Ein Leak-Test meldet einen Resolver, und dieses eine Etikett sagt Ihnen nicht, welche Anordnung Sie tatsächlich haben. Legen Sie zuerst die beabsichtigte Richtlinie fest, und testen Sie dann dagegen. Sonst vergleichen Sie eine Zahl mit einem Gefühl.

Legen Sie fest, was Sie wollten, bevor Sie das Ergebnis lesen

Benennen Sie die Richtlinie in einem Satz: alle Namen zum VPN-Resolver, alle Namen zu einem gewählten verschlüsselten Resolver oder Split-DNS, bei dem interne Namen an die Organisation gehen. Jede ist für einen anderen Nutzer vertretbar, und jede erzeugt eine andere erwartete Antwort. Ohne diesen Satz wirkt jedes Ergebnis, das von einem Screenshot in einem Forumsbeitrag abweicht, alarmierend. Schreiben Sie die Richtlinie vor dem ersten Test auf.

Ein Test, der vor der Definition der Richtlinie durchgeführt wird, misst nichts. Er liefert einen Resolver-Namen ohne jeden Bezugspunkt.

Ein Resolver-Name beweist weder den Pfad noch den Empfänger

Zwei Fragen zählen: Wer hat die Abfrage erhalten, und welche Route hat sie getragen. Ein Resolver eines Drittanbieters kann durch den Tunnel erreichbar sein, während ein Einstellungsbildschirm die Adresse des Anbieters zeigt. Das Etikett auf einer Leak-Test-Seite beschreibt die Sicht des Beobachters, nicht Ihre Routing-Tabelle.

Ein Browser kann sein eigenes verschlüsseltes DNS verwenden, während der Website-Verkehr durch den Tunnel läuft, und zwischengespeicherte Antworten können eine Seite ohne neue Abfrage laden lassen. Deshalb sagt ein Public-IP-Ergebnis nichts über DNS aus. DoH und DoT schützen die Abfrage auf dem Weg zum Resolver, und dieser Resolver sieht die Namen weiterhin.

resolvectl status
resolvectl query example.com
dig +short example.com

Split-DNS macht mehrere Resolver korrekt

Eine Organisation kann interne Namen an ihr eigenes DNS senden und alles andere woandershin. Ein Test, der mehrere Resolver auflistet, kann daher die beabsichtigte Richtlinie beschreiben statt eines Fehlers. Vergleichen Sie die beobachtete Menge mit den dokumentierten Split-DNS-Regeln, bevor Sie etwas abschalten. Den internen Resolver abzuschalten, damit eine Testseite sauberer aussieht, zerstört private Namen.

Split-Tunneling und Split-DNS sind verschiedene Entscheidungen: Das eine leitet Pakete, das andere leitet Fragen. Eine Tunnelroute zu ändern verschiebt keine Namensauflösung, und den Resolver zu ändern repariert keinen Website-Pfad. IPv6 ist eine dritte Frage, denn eine unbeabsichtigte IPv6-Verbindung ist nicht automatisch ein DNS-Leak.

Machen Sie aus dem Ergebnis eine Untersuchung

Notieren Sie vor dem Test die beabsichtigte Richtlinie und die Einstellung für sicheres DNS im Browser. Führen Sie den Test bei aktivem Tunnel aus, notieren Sie jeden genannten Resolver und vergleichen Sie die Menge mit der Richtlinie statt mit einer einzigen erwarteten Adresse.

Wiederholen Sie den Test nach einem erneuten Verbinden, wenn das Symptom dann auftritt, denn eine beim Verbinden angewandte Richtlinie kann später verloren gehen. Nutzen Sie die Dokumentation des Clients für interne DNS-Ausnahmen, statt die Einstellungen zu erraten.

Beheben Sie die gefundene Abweichung: eine Browserwahl, eine VPN-DNS-Einstellung oder eine Split-DNS-Regel. Müssen Abfragen stoppen, wenn der Tunnel ausfällt, ist der Kill-Switch eine separate Einstellung, und die DNS-Konfiguration allein liefert ihn nicht. Die Spezifikation RFC 8484 ist nützlich, wenn Sie erklären müssen, was ein verschlüsselter Resolver verbirgt und was nicht.