Wie erkennt man ein DNS-Leck? Proxy-DNS-Probleme in 4 Schritten prüfen

Kernaussage: Ein bestandener IP-Test zeigt nur, dass der Ausgang gewechselt hat – nicht, dass auch DNS-Anfragen denselben Weg nehmen. Proxy und DNS betreuen zwei getrennte Vorgänge: Der Proxy legt fest, über welchen Netzwerk-Ausgang die Verbindung geht, das DNS löst Domainnamen in IP-Adressen auf. Laufen Auflösungsanfragen über einen unerwarteten Weg, liegt ein DNS-Leck vor. Vier Prüfschritte genügen – wichtiger als der Testlauf selbst ist das richtige Lesen der Ergebnisse.

Proxy konfiguriert, IP-Testseite geöffnet, angezeigt wird die Proxy-IP – also gilt die Netzwerkumgebung als in Ordnung. Tage später, bei der Aufklärung auffälliger Konten, fällt auf: Die DNS-Anfragen liefen die ganze Zeit über das lokale Netz.

Schuld muss nicht der Proxy sein. DNS-Anfragen umgingen ihn.

Proxy aktiv – warum die DNS-Prüfung trotzdem nötig ist

Proxy und DNS sind zwei getrennte Vorgänge; ein aktiver Proxy bedeutet nicht, dass das DNS ebenfalls übernommen wird. Der Proxy legt fest, über welchen Netzwerk-Ausgang die Verbindung gesendet wird, das DNS löst die Domainnamen auf. Beide betreffen unterschiedliche Netzwerkebenen – ein funktionierender Proxy garantiert nicht, dass die DNS-Anfragen wie erwartet verlaufen.

Konkret beim Netzwerk-Request: Beim Aufruf einer Seite holt der Client erst per DNS-Anfrage die IP der Zieldomain oder übergibt den Domainnamen an die Proxy-Seite; welcher Weg gilt, hängt vom Proxy-Protokoll, der Client-Implementierung und den DNS-Einstellungen des Browsers ab. Ein aktiver Proxy bedeutet nicht automatisch, dass alle Auflösungsanfragen auf dem erwarteten Weg laufen. Die Entscheidung verlangt einen echten Test – allein das „Verbunden“-Symbol des Proxys genügt nicht.

Eine Grenze sollte klar sein: Ein DNS-Leck ist nicht gleichbedeutend mit der Offenlegung der echten öffentlichen IP. Lecken tut der Weg der Domainabfragen – dadurch kann der Auflösungsdienst oder das lokale Netz sehen, welche Domains abgefragt wurden. Ob die echte IP offengelegt wird, entscheidet ein eigenständiger IP-Test. Die Cyber Security Agency of Singapore listet in ihren VPN-Empfehlungen den DNS-Leck-Test und den IP-Adress-Leak-Test als zwei getrennte Prüfungen – mit genau der Begründung, dass beide nicht dasselbe Problem verifizieren (siehe CSA-Leitfaden zur VPN-Sicherheit).

Wie DNS-Lecks typischerweise entstehen

Drei Ursachen sind am häufigsten, alle betreffen die Konfiguration und haben mit der Güte des Proxys nichts zu tun. Der Reihe nach.

Der Proxy übernimmt nur einen Teil des Datenverkehrs

Manche Proxy-Konfigurationen übernehmen nur die Webanfragen des Browsers, die Auflösung erledigt weiterhin das lokale System; ob das so ist, entscheidet das Proxy-Protokoll und die Verarbeitung im Client. Läuft der Webtraffic über den Proxy, die Auflösung aber lokal, taucht in den Testergebnissen der Resolver des lokalen Netzes auf.

Der Browser nutzt ein eigenes Secure DNS

Chrome und Firefox unterstützen DNS over HTTPS (DoH). Ist es aktiv, gehen Auflösungsanfragen über eine verschlüsselte HTTPS-Verbindung an den festgelegten Auflösungsdienst; das lokale Netz bekommt seltener Gelegenheit, Abfragen direkt mitzulesen. Verschlüsselung heißt aber weder, dass die Anfragen sicher über den Proxy laufen, noch dass der gewählte Auflösungsdienst zur erwarteten Umgebung passt. In Firefox lässt sich diese Funktion separat ein- und ausschalten, siehe Mozilla-Dokumentation.

System, Browser und Proxy-Client nutzen jeweils eigene Einstellungen

Die tückischste Variante. Das System nutzt einen Resolver, der Browser mit aktiviertem DoH einen anderen, der Proxy-Client konfiguriert noch einen – gestapelt wird der Auflösungsweg zur Blackbox. Allein das „Verbunden“-Symbol der Proxy-Software reicht nicht zur Beurteilung; entscheidend ist, welchen Weg der tatsächlich laufende Browser nimmt.

Landet der Auflösungsweg beim lokalen ISP, laufen die Anfragen über den Resolver des Anbieters; ein Abgleich lohnt sich mit ISP-Proxys: Funktionsweise und Einsatzbereiche.

DNS-Leck prüfen: vier Schritte

Der Test selbst ist unkompliziert; entscheidend ist, vor dem Test eine Erwartung zu haben und danach abzugleichen. Erst wenn alle vier Schritte erledigt sind, trägt das Fazit.

Schritt 1: Zuerst das erwartete Ergebnis notieren. Vor dem Test drei Punkte festhalten: In welcher Region liegt der Ausgang des aktuellen Proxys? Wer soll die Domainauflösung übernehmen? Ist DoH im Browser aktiv? Ohne Erwartung lässt sich das Ergebnis nicht bewerten.

Schritt 2: Bei aktivem Proxy den Test ausführen. Eine Seite mit DNS-Leck-Erkennung nutzen, etwa dnsleaktest.com – der erweiterte Test (Extended test) zeigt mehrere Resolver an; alternativ zeigt die DNS-Prüfseite von BrowserLeaks, welcher Organisation die Resolver zugeordnet sind. Namen, Organisation und Region der Resolver notieren.

Schritt 3: Mit der Erwartung abgleichen. Prüfen, ob die angezeigten Resolver zur Konfiguration von System, Browser und Proxy passen. Gehören die Resolver zum erwarteten DNS-Dienst und taucht kein unerwarteter lokaler Auflösungsweg auf, kann dieser Test vorläufig als im Rahmen der Erwartung gelten. Zeigt sich der lokale ISP oder ein unbekannter Auflösungsdienst, zuerst klären, ob er wirklich aus einer unerwarteten Konfiguration stammt; erst dann die DNS-Behandlung des Proxy-Clients, das Secure DNS des Browsers und die Netzwerkeinstellungen des Systems Punkt für Punkt durchgehen – nicht vorschnell den Proxy für defekt erklären. Ein einzelner Test spiegelt nur die Bedingungen dieses Laufs wider und garantiert nicht, dass alle Anfragen dauerhaft problemlos bleiben.

Schritt 4: Eine Einstellung ändern, erneut testen. Wenn schon anpassen, dann immer nur an einer Stelle: DNS-Behandlung des Proxy-Clients, DoH-Schalter im Browser oder Netzwerkeinstellungen des Systems – ändern, neu testen, vergleichen. Wer mehrere Punkte auf einmal ändert, kann später nicht mehr zuordnen, welche Änderung gewirkt hat.

Testergebnisse richtig lesen

Dasselbe Ergebnis ist richtig gelesen ein Hinweis, falsch gelesen ein Fehlurteil. Die fünf häufigsten Ergebnisse und das weitere Vorgehen:

Eine Stolperfalle bleibt: Öffentliche Resolver nutzen meist Anycast und verteilte Knoten, deshalb entspricht der auf der Prüfseite angezeigte Standort des Resolvers nicht zwangsläufig dem Standort des Servers, der die Abfrage tatsächlich bearbeitet – und ist erst recht kein Leck. Für die Beurteilung zählt allein, ob die Abfrage einen unerwarteten Weg genommen hat; taucht ein Resolver aus einer unbekannten Region auf, erst die Konfiguration prüfen, dann das Urteil fällen.

DNS-Leck, WebRTC-Leck und Browser-Fingerprint – was unterscheidet sie?

Vier Prüfungen blicken auf vier verschiedene Informationen; einer bestanden heißt nicht, dass die übrigen ebenfalls bestanden sind. Nebeneinander gestellt zeigt sich die Abgrenzung am deutlichsten:

DNS und WebRTC tragen beide das Wort „Leck“ im Namen und werden deshalb am leichtesten verwechselt. Ihre Prüfprinzipien und ihr Umgang unterscheiden sich jedoch völlig; die Prüfung und Einstellung von WebRTC-Lecks haben wir in einem eigenen Artikel behandelt und gehen hier nicht erneut darauf ein. Zudem gehört das IPv6-Leck zur selben Familie: Es prüft, ob IPv6-Adressen den Proxy umgehen; das Vorgehen beschreibt die Anleitung zur IPv6-Leck-Erkennung.

Diese vier Punkte liefern jeweils andere Informationen und ersetzen einander nicht. Bei der Fehlersuche in einer Proxy-Umgebung empfiehlt sich die Reihenfolge: zuerst die öffentliche IP bestätigen, dann DNS und WebRTC prüfen, zuletzt Fingerprint und Umgebungskonfiguration abgleichen; welche Punkte im Vordergrund stehen, entscheidet das jeweilige Szenario.

Mit MostMate: Wie diese Prüfungen in den Ablauf passen

Empfohlene Reihenfolge: erst der Ausgang, dann die Auflösung, dann WebRTC, zuletzt die Umgebungskonfiguration. Verwaltet man mit MostMate mehrere Browser-Umgebungen, lässt sich die Proxy-Verbindungsprüfung von der DNS-Leck-Prüfung trennen.

Der erste Punkt ist die Proxy-Konfiguration. Nach dem Binden des Proxys an eine Umgebung bestätigt der Proxy-Test im Produkt den Verbindungsstatus; Protokolltyp (HTTP, HTTPS, SOCKS5, SSH) und Authentifizierungsdaten werden gleich mit kontrolliert. Wichtig: Ein bestandener Proxy-Test ersetzt die DNS-Leck-Prüfung nicht, denn der tatsächliche Weg der DNS-Anfragen hängt weiterhin von Proxy-Client, Browser und System ab.

Danach die DNS-Prüfseite in dieser Umgebung öffnen. Vorgehen wie oben.

Der zweite Punkt ist die Isolation der Umgebung selbst. In Szenarien mit mehreren Konten sollten Proxy, Cookies und Fingerprint-Parameter jeder Umgebung eigenständig bleiben und nicht gegenseitig ausgeliehen werden; den genauen Umfang der Isolation beschreibt der Artikel zu Umfang und Konfiguration der Browser-Umgebungs-Isolation. Ist der Proxy einer Umgebung falsch gebunden oder die Konfiguration geteilt, verliert das Testergebnis seinen Vergleichswert. Isolation hilft, Sitzungen und Konfigurationen zu verwalten – sie bedeutet nicht, dass der DNS-Weg automatisch stimmt, und ersetzt keine externe Prüfung.

Der dritte Punkt ist die Grenze: Der Fingerprint-Browser sorgt dafür, dass die Umgebung klar organisiert ist; ob der Proxy tatsächlich wirkt und ob das DNS den erwarteten Weg nimmt, muss weiterhin eine externe Prüfung zeigen. Auch ein bestandener Test gilt nicht für alle Zeiten – nach Konfigurationsänderungen oder Systemupdates empfiehlt sich ein erneuter Test.

Häufige Fragen

Proxy ist aktiv, aber die DNS-Prüfung zeigt einen lokalen Resolver. Ist der Proxy defekt?

Nicht zwangsläufig. Möglicherweise übernimmt der Proxy nur die Webanfragen, während das System oder der Browser die Auflösung separat erledigt. DNS-Behandlung des Proxy-Clients und DoH-Einstellungen des Browsers Punkt für Punkt prüfen – eine Änderung, ein Test.

Legt ein DNS-Leck meine echte IP offen?

Das lässt sich nicht direkt gleichsetzen. Ein DNS-Leck zeigt den Weg der Domainauflösungsanfragen auf; was tatsächlich offengelegt wird, hängt von der Netzwerkkonfiguration und dem Prüfszenario ab. Ob die echte öffentliche IP verborgen bleibt, bestätigt ein eigenständiger IP-Test, der Auflösungsweg wird separat geprüft.

Kann trotz Fingerprint-Browser ein DNS-Leck auftreten?

Ja, das ist möglich. Der Fingerprint-Browser verwaltet Umgebungs-Isolation und Fingerprint-Parameter; das DNS-Verhalten hängt vom Proxy-Protokoll sowie von System- und Browsereinstellungen ab – auf die Prüfung darf nicht verzichtet werden.

Was muss nach einer bestandenen DNS-Prüfung noch geprüft werden?

WebRTC-Leck und Browser-Fingerprint stehen noch aus, beide werden mit ihrem eigenen Werkzeug verifiziert. Erst wenn alle bestanden sind, ist die Prüfung der Netzwerkebene dieser Umgebung vollständig.

Fazit

Der Wert der DNS-Leck-Prüfung liegt nicht darin, ein „bestanden“ oder „durchgefallen“ zu erhalten, sondern darin zu bestätigen, dass die Netzwerkanfragen der aktuellen Umgebung der Erwartung entsprechen. Öffentliche IP, DNS, WebRTC und Browser-Fingerprint haben jeweils eigene Prüfmethoden; das Ergebnis eines Punktes ersetzt die Prüfung der anderen nicht. Welchen Fingerprint-Browser Sie auch nutzen: Nach Änderungen am Proxy oder an den Netzwerkeinstellungen lohnt sich ein erneuter Test.

Wenn Sie mehrere Browser-Umgebungen verwalten, verschaffen Sie sich zuerst einen Eindruck von den Umgebungseinstellungen und der Proxy-Verwaltung von MostMate und gehen die Schritte dieses Artikels anschließend einzeln durch; für eine stabilere Proxy-Konfiguration können Sie MostMate herunterladen – die Gratisversion umfasst zwei Umgebungen, ideal, um den Prüfprozess zuerst in der ersten Umgebung komplett zu durchlaufen.