Der Aufruf einer Website beginnt meist mit einer stillen Frage: Welche IP-Adresse gehört zu diesem Domainnamen? Diese Anfrage geht an einen sogenannten DNS-Resolver. Dessen Betreiber kann die aufgelösten Domains sehen, soweit die Antworten nicht bereits zwischengespeichert sind oder ein anderer verschlüsselter DNS-Dienst verwendet wird. Genau hier entsteht das Risiko: Läuft die Anfrage am VPN-Tunnel vorbei, kann der Internetanbieter weiterhin einen Teil Ihrer aufgerufenen Dienste erkennen, während der eigentliche Datenverkehr durch den VPN-Tunnel fließt. Das VPN meldet „verbunden“, erfasst aber nicht den vorgesehenen gesamten Pfad.
Wie ein DNS-Leak entsteht
Ein DNS-Leak ist selten Absicht, meist ist es eine technische Lücke im Zusammenspiel von Betriebssystem, Protokoll und VPN-Client. Vier Ursachen treten immer wieder auf.
IPv6 am IPv4-Tunnel vorbei. Fast jeder deutsche Anschluss läuft heute mit IPv4 und IPv6 parallel. Viele VPN-Clients leiten aber nur den IPv4-Verkehr in den Tunnel und lassen die IPv6-Routing-Tabelle unangetastet. Da moderne Systeme IPv6 bevorzugen, sobald eine Adresse verfügbar ist (so festgelegt im Standard RFC 6724), wandern IPv6-Verbindungen samt ihrer DNS-Anfragen ungeschützt über die native Leitung. Die grundlegende Untersuchung von Perta und Kollegen (PETS 2015) nannte das „den Kern des IPv6-Lecks“: Solange ein Client IPv6 nicht bewusst mittunnelt oder blockiert, bleibt das Leck unsichtbar. Das ist auch der Grund, warum reine IPv4-Tests dieses Problem übersehen; unser IPv6-Leak-Test prüft es gezielt.
Windows und die parallele Namensauflösung. Windows kennt keine einzelne, globale DNS-Einstellung: Jede Netzwerkschnittstelle bringt ihren eigenen Resolver mit. Über die „Smart Multi-Homed Name Resolution“, seit Windows 8 standardmäßig aktiv, schickt das System Anfragen gleichzeitig über alle Schnittstellen und nimmt die schnellste Antwort. Antwortet der Resolver Ihres Providers schneller als der des VPN, ist die Domain bereits verraten (dokumentiert unter anderem in einem Paper des SANS Institute von 2021). Diese Bauart hat Windows lange zur Hauptplattform für DNS-Leaks gemacht.
Der Moment des Verbindungsabbruchs. Bricht der Tunnel ab, lassen manche Clients DNS-Anfragen bewusst am Kill-Switch vorbei, um den Servernamen neu aufzulösen und die Verbindung wiederherzustellen. Die VPNalyzer-Studie (NDSS 2022) hat dieses Verhalten als erste systematisch gemessen: 26 von 80 getesteten Desktop-Anbietern gaben beim Tunnelabbruch DNS-Anfragen an den Provider preis. Ein Angreifer, der einen Abbruch gezielt herbeiführt, kann dieses Fenster ausnutzen. Protokolle wie WireGuard entschärfen das, indem sie Servernamen schon beim Verbindungsaufbau auflösen.
Der Browser über WebRTC. Ein technisch verwandter Sonderfall ist das WebRTC-Leck. Die WebRTC-Schnittstelle für Videoanrufe im Browser sammelt alle IP-Adressen des Geräts. Bei einem VPN im Split-Tunnel-Betrieb kann sie dabei nicht nur die VPN-Adresse, sondern auch die dahinterliegende echte Provider-Adresse offenlegen (so beschrieben im Standard RFC 8828). Der Datenverkehr bleibt verschlüsselt, die Identität wandert trotzdem nach außen. Ob Ihr Browser dicht ist, zeigt unser WebRTC-Leak-Test.
Warum ein DNS-Leak so schwer wiegt
Die Tücke am DNS-Leak ist seine Unauffälligkeit. Ihre Inhalte sind verschlüsselt, Ihre IP-Adresse nach außen verschleiert, alles wirkt in Ordnung. Doch die Liste der aufgerufenen Domains ist bereits ein feines Profil: Sie verrät, welche Banken, Nachrichtenseiten, Gesundheitsportale oder Foren Sie besuchen, in welcher Reihenfolge und wie oft. Genau dieses Profil wollten viele Nutzer dem Provider mit dem VPN entziehen. Ein DNS-Leak macht diesen Schutz zunichte, ohne dass eine einzige Warnung erscheint. Deshalb zählt die Frage, ob DNS wirklich durch den Tunnel läuft, für uns zu den grundlegenden Prüfpunkten, nicht zu den Feinheiten.
Wie wir das prüfen
DNS-Leaks gehören zu den Schutzmerkmalen, für die unser Prüfprotokoll einen praktischen Test verlangt. Ein Ergebnis darf nur dann als bestanden in einen Testbericht einfließen, wenn bei aktivem VPN die tatsächlich verwendeten Resolver ermittelt und zugeordnet wurden. Die bloße erfolgreiche Namensauflösung reicht dafür nicht. Denselben Resolver-Test können Sie mit unserem kostenlosen DNS-Leak-Test selbst ausführen.
Die Methode dahinter ist einfacher, als oft behauptet wird, und sie wird häufig falsch erklärt: Ein DNS-Leak-Test schneidet keine Pakete auf Ihrer Leitung mit. Stattdessen lässt er Ihr Gerät mehrere einzigartige, zufällig erzeugte Domainnamen auflösen, die absichtlich nirgends zwischengespeichert sind. Der zuständige Server für diese Testdomain beobachtet dann, welche Resolver-Adressen nach der Auflösung fragen. Erscheinen dort nur Server Ihres VPN-Anbieters, ist alles dicht. Tauchen Server Ihres Internetanbieters auf, liegt ein Leck vor. Sichtbar wird also, wer Ihre Anfragen sieht, nicht deren Inhalt. Dass dabei mehrere Resolver-Adressen erscheinen, ist übrigens normal: Ein einzelner Resolver verteilt seine Last oft auf viele Server im Hintergrund.
Auf die Gründlichkeit kommt es an. Ein kurzer Standardtest genügt, um ein dauerhaftes Leck zu erkennen. Sporadische oder IPv6-spezifische Lecks zeigen sich erst, wenn man mehrere Runden testet und IPv6-Namen einbezieht. Deshalb prüfen wir DNS, WebRTC und IPv6 getrennt; ein einzelner Haken über alle drei wäre unehrlich.
Worauf Sie bei einem Anbieter achten sollten
Ein VPN schützt nicht automatisch vor DNS-Leaks. Entscheidend ist, wie sorgfältig der Anbieter drei Dinge löst:
- Nachvollziehbare DNS-Resolver. Einige Anbieter betreiben eigene DNS-Server, andere verwenden klar benannte externe Resolver. Entscheidend ist, dass die Anfragen durch den Tunnel laufen, kein Resolver des Zugangsproviders erscheint und der Umgang mit DNS-Daten transparent beschrieben ist. Proton VPN dokumentiert beispielsweise den Betrieb eigener Resolver.
- Fail-closed-Absicherung. Sorgfältig konfigurierte Clients erlauben DNS-Verkehr über Port 53 ausschließlich zu den eigenen Resolvern und blockieren alles andere. Mullvad setzt das über Firewall-Regeln um, nachlesbar direkt im offenen Quellcode. Darin steckt dieselbe Logik wie im Kill-Switch.
- Sauberer Umgang mit IPv6. Der Anbieter sollte IPv6 entweder vollständig mittunneln oder konsequent blockieren, niemals einfach ignorieren.
Die notwendige Ergänzung ist eine geprüfte No-Logs-Richtlinie: Auch der eigene DNS-Resolver des Anbieters sieht Ihre Anfragen, es zählt also, dass davon nichts gespeichert wird.
Häufige Irrtümer und Grenzen
„Ein VPN verhindert DNS-Leaks automatisch.“ Falsch. Die beschriebenen Lücken entstehen gerade trotz aktivem VPN; der Schutz muss vom Client aktiv umgesetzt werden.
„Ein Test genügt für immer.“ Nur bedingt. Ein Update, ein Serverwechsel oder eine geänderte Netzwerkeinstellung kann ein zuvor dichtes System wieder undicht machen. Ein kurzer Nachtest nach größeren Updates lohnt sich.
Grenze DNS-over-HTTPS. Löst Ihr Browser über sein eigenes DNS-over-HTTPS auf (DoH über Port 443), kann er am DNS-Resolver des VPN vorbei zu einem Drittanbieter gehen. Das ist kein klassisches Leck zum Provider, verlagert das Vertrauen aber vom VPN zu diesem DoH-Dienst, ein Punkt, den die meisten Leak-Tests nicht abbilden.
Zur Einordnung. Wie verbreitet Lecks einmal waren, zeigen ältere Messungen: Die PETS-Studie 2015 fand IPv6-Lecks bei rund elf von vierzehn Desktop-Clients, eine Android-Untersuchung (IMC 2016) bei etwa 66 Prozent der Apps beim DNS und 84 Prozent beim IPv6. Diese Werte sind Momentaufnahmen der Jahre 2014 bis 2021; der Schutz ist seither deutlich besser geworden. Blind verlassen sollten Sie sich darauf trotzdem nicht, sondern nachmessen.
Quellen
- Perta et al., „A Glance through the VPN Looking Glass: IPv6 Leakage and DNS Hijacking in Commercial VPN Clients“, PETS 2015
- IETF: RFC 6724 (Adressauswahl bei Dual-Stack), RFC 7359 (Leakage von VPN-Verkehr), RFC 8828 (WebRTC IP Address Handling)
- Ramesh und Ensafi, VPNalyzer, NDSS 2022
- SANS Institute, Preventing Windows 10 SMHNR DNS Leakage, 2021
- Ikram et al. (IMC 2016) und Khan et al. (IMC 2018) zur Verbreitung von DNS- und IPv6-Lecks
- Dokumentation von Proton VPN und Mullvad zum DNS-Schutz