Was ist ein DNS-Leak — und wie testet man ihn richtig

Die Kurzfassung: Ein VPN-Tunnel verschlüsselt die IP-Pakete, die dein Gerät an andere Server sendet. DNS ist die Auflösung, die vor dem Versand des Pakets stattfindet — dein Gerät fragt: "Welche IP-Adresse gehört zu example.com?" Wenn diese Anfrage an den Resolver deines ISPs geht statt durch das VPN, sieht dein ISP die Domain, auch wenn er den verschlüsselten Datenverkehr danach nie zu sehen bekommt. Das ist ein Leak. Er unterläuft das zentrale Datenschutzversprechen eines VPNs aus dem einfachsten Grund überhaupt: Der falsche DNS-Resolver wurde angefragt. Die gute Nachricht: Leaks lassen sich leicht erkennen, meist leicht beheben, und die meisten sauber gebauten VPN-Apps verhindern sie standardmäßig. Die schlechte Nachricht: "die meisten" ist nicht "alle" — und einige häufige Konfigurationen verursachen Leaks selbst bei ansonsten korrekten VPN-Setups.

Was DNS eigentlich macht und warum es zu Leaks kommt

DNS — das Domain Name System — ist das Adressbuch des Internets. Jedes Mal, wenn dein Gerät eine Verbindung zu einer Website herstellt, muss es zunächst den menschenlesbaren Hostnamen (example.com) in eine numerische IP-Adresse (etwa 93.184.216.34) umwandeln, an die Router Pakete tatsächlich weiterleiten können. Dieser Übersetzungsschritt ist eine DNS-Anfrage und ist ein separater Netzwerkvorgang gegenüber der eigentlichen Web-Anfrage, die danach folgt.

Bei einer typischen Heimverbindung wird dein DNS-Resolver von deinem ISP per DHCP zugeteilt — demselben Mechanismus, der dir auch deine IP-Adresse zuweist. Wenn du dich mit WLAN verbindest, teilt dir der Router mit: "Dein DNS-Server ist 192.168.1.1, der an den rekursiven Resolver deines ISPs weiterleitet." Jede Domain, die du auflöst, fließt durch diesen Resolver. Der ISP kann sie protokollieren, an einen Datenhändler verkaufen (in den USA ist das legal) oder an Strafverfolgungsbehörden weitergeben.

Wenn du ein VPN verbindest, sollten zwei Dinge passieren. Erstens wird dein Netzwerkverkehr verschlüsselt und durch den VPN-Tunnel geleitet. Zweitens sollte sich dein DNS-Resolver ändern — vom Resolver des ISPs zu einem, der vom VPN-Anbieter (oder einem datenschutzorientierten Drittanbieter-Resolver) betrieben wird und nur über den verschlüsselten Tunnel erreichbar ist. Wenn nur die erste Hälfte passiert, hast du einen DNS-Leak. Der Datenverkehr ist verschlüsselt, aber die Auflösungen, die dem Datenverkehr vorausgingen, fließen weiterhin zum ISP und verraten ihm jede Website, die du besuchen wirst.

Aus datenschutztechnischer Sicht ist eine DNS-Anfrage fast genauso aufschlussreich wie der Datenverkehr selbst. Die Anfrage offenbart die genaue Domain (bis zur Subdomain — mail.example.com ist von www.example.com unterscheidbar) und den Zeitpunkt. In Kombination mit dem verschlüsselten Datenverkehrsvolumen unmittelbar danach liefert ein DNS-leckender VPN einem Beobachter genug Metadaten, um deine Browser-Sitzung in fast jeder wesentlichen Hinsicht zu rekonstruieren.

Die vier Wege, auf denen ein DNS-Leak entsteht

DNS-Leaks sind kein einzelner Fehler. Sie sind eine Familie verwandter Fehlkonfigurationen, jede mit einer anderen Ursache und einem anderen Fix. Grob nach Häufigkeit geordnet:

1. OS-Bypass — Windows Split DNS / Smart Multi-Homed Name Resolution

Windows verfügt über eine Funktion namens Smart Multi-Homed Name Resolution, die, wenn aktiviert, DNS-Anfragen parallel an jeden verfügbaren DNS-Resolver sendet — einschließlich des ISP-Resolvers auf der physischen Schnittstelle, selbst wenn ein VPN aktiv ist. Welcher Resolver am schnellsten antwortet, gewinnt; die anderen werden ignoriert, aber die Anfragen wurden bereits gesendet. Auf den meisten Windows-Rechnern ist diese Funktion standardmäßig aktiviert. Die Lösung besteht darin, die Funktion per Gruppenrichtlinie oder durch entsprechende Konfiguration des VPN-Clients beim Verbindungsaufbau zu deaktivieren. Linux hat ein ähnliches Problem mit systemd-resolved, wenn es nicht korrekt konfiguriert ist; macOS und iOS gehen damit besser um, aber nicht perfekt.

2. Split-Tunnel-Fehlkonfiguration

Split Tunneling ermöglicht es dir, bestimmte Apps durch das VPN und andere über deine normale Verbindung zu leiten. Ein häufiger Konfigurationsfehler besteht darin, App-basiertes Split Tunneling einzurichten, ohne gleichzeitig DNS pro App zu konfigurieren — was dazu führt, dass eine außerhalb des VPN-Tunnels geroutete App trotzdem versucht, den DNS-Resolver des VPNs zu verwenden, oder umgekehrt, und am Ende durch den vom Betriebssystem bereitgestellten Pfad leckt. Eine schlimmere Variante: Der Split Tunnel leitet den TCP-Datenverkehr der App korrekt außerhalb des Tunnels, aber der systemweite DNS-Resolver ist immer noch der des ISPs, sodass jede App — ob getunnelt oder nicht — ihre DNS-Anfragen an den ISP leakt. Wir behandeln das übergeordnete Thema in unserem Beitrag darüber, was Split Tunneling eigentlich macht.

3. IPv6-Fallback

Viele VPN-Clients wurden entwickelt, als IPv4 die einzige Routing-Überlegung war. Sie installieren IPv4-Firewall- und Routing-Regeln, die DNS korrekt durch den Tunnel leiten, installieren aber keine entsprechenden IPv6-Regeln. Wenn dein Netzwerk über IPv6-Konnektivität verfügt, bevorzugt das Betriebssystem manchmal IPv6 für DNS-Anfragen — und diese Anfragen fließen über die bloße Schnittstelle und umgehen das VPN vollständig. Dies ist einer der häufigsten Leak-Modi in 2026 und tritt besonders häufig bei privaten Breitbandverbindungen auf, die einen Dual-Stack aus IPv4 und IPv6 vom ISP anbieten. Die Lösung besteht entweder darin, IPv6 global zu deaktivieren (radikal, aber zuverlässig) oder einen VPN-Client zu verwenden, der IPv6-Routen explizit behandelt.

4. WebRTC und browser-seitiges DNS

Moderne Browser — Chrome, Edge, Firefox, Safari — können DNS-Auflösungen selbst durchführen, anstatt den OS-Resolver zu nutzen. Der bekannteste Fall ist WebRTC, das Peer-to-Peer-Protokoll für Videochats. WebRTC verwendet STUN-Server, um deine echten lokalen und öffentlichen IP-Adressen zu ermitteln, und sendete diese historisch sogar dann aus, wenn ein VPN aktiv war. Die "echte" IP aus WebRTC ist ein langjähriger browser-seitiger Leak, der eine explizite Gegenmaßnahme erfordert. Unabhängig davon können Browser, die DNS-over-HTTPS (DoH) verwenden, DNS-Anfragen direkt an Cloudflare, Google oder NextDNS routen — unabhängig von der OS-Resolver-Einstellung. Das hilft manchmal (DoH zu einem öffentlichen Resolver ist privater als Klartext an den ISP) und schadet manchmal (der öffentliche Resolver sieht dennoch deine Anfragen, und der Browser umgeht die DNS-Regeln des VPNs).

So testest du auf einen DNS-Leak in unter einer Minute

Einen DNS-Leak zu testen dauert in der Beschreibung länger als in der Praxis. Verbinde dein VPN und besuche dann eines dieser drei Tools. Jedes davon beleuchtet leicht unterschiedliche Aspekte der Leak-Oberfläche.

dnsleaktest.com

Der Klassiker. Besuche dnsleaktest.com, klicke auf "Extended test" und warte ca. 20 Sekunden. Das Tool stellt eine Reihe von DNS-Anfragen für eindeutige Hostnamen, die es selbst kontrolliert, und zeigt dir dann, welche Resolver diese Anfragen tatsächlich verarbeitet haben. Wenn du den Namen deines ISPs (Comcast, Verizon, BT usw.) in der Resolver-Liste siehst, leckt es. Wenn du nur den Resolver des VPN-Anbieters (oder einen datenschutzorientierten öffentlichen Resolver wie Quad9 oder Cloudflares 1.1.1.1) siehst, ist der OS-DNS-Pfad korrekt.

browserleaks.com/dns

Detaillierter als dnsleaktest. Es zeigt dir nicht nur, welche Resolver die Anfrage verarbeitet haben, sondern auch deren geografischen Standort, ASN (den Netzbetreiber) und ob sie DNS-over-HTTPS oder DNS-over-TLS unterstützen. Nützlich, um subtile Leaks zu erkennen, bei denen der richtige Resolver-Typ verwendet wird, sich aber im falschen Land befindet, oder um zu bestätigen, dass ein verschlüsseltes DNS-Protokoll tatsächlich genutzt wird.

ipleak.net

Das umfassendste Tool — es testet DNS-Leaks, WebRTC-Leaks, IPv4- und IPv6-Sichtbarkeit und zeigt, wo dein Standort geografisch erscheint. Der WebRTC-Abschnitt ist entscheidend: Wenn du eine "Local IP"-Adresse im Bereich 192.168.x.x oder 10.x.x.x siehst, die neben einer "Public IP" angezeigt wird, die deinem VPN-Endpunkt entspricht, tut dein VPN seinen Job, aber dein Browser leckt über WebRTC. Der IPv6-Abschnitt erfasst IPv6-Fallback-Leaks, die dnsleaktest manchmal übersieht.

Wie ein sauberes Ergebnis aussieht — und wie ein leckiges

Beim Extended Test von dnsleaktest.com mit einem korrekt konfigurierten VPN solltest du etwa Folgendes sehen:

Test results (clean): Server: 1.2.3.4 Hostname: dns.vpn-provider.com ISP: VPNProviderCo Country: Netherlands Server: 1.2.3.5 Hostname: dns.vpn-provider.com ISP: VPNProviderCo Country: Netherlands Conclusion: No DNS leak detected. All queries went to the VPN's resolver.

Und so sieht ein Leak aus:

Test results (leaking): Server: 1.2.3.4 Hostname: dns.vpn-provider.com ISP: VPNProviderCo Country: Netherlands Server: 75.75.75.75 Hostname: cdns01.comcast.net ISP: Comcast Country: United States Server: 75.75.76.76 Hostname: cdns02.comcast.net ISP: Comcast Country: United States Conclusion: DNS leak detected. ISP resolver (Comcast) received queries.

Das entscheidende Signal ist die ISP-Spalte. Wenn dort etwas anderes als dein VPN-Anbieter (oder ein bewusst gewählter öffentlicher Resolver) erscheint, leckt dein DNS. Wenn die Länderspalte dein echtes Land neben dem VPN-Austrittsland zeigt, leckt es. Wenn nur das Land des VPN-Endpunkts erscheint, bist du sauber.

Leak-Typen im Vergleich

Jeder der vier Leak-Typen hat einen charakteristischen Fingerabdruck in den Testergebnissen, eine bestimmte Gruppe von Beobachtern, die ihn ausnutzen können, und einen spezifischen Fix:

Die vier häufigen Ursachen beheben

OS-Bypass-Leaks (Windows) beheben

Unter Windows 10 und 11 deaktiviere Smart Multi-Homed Name Resolution entweder per Gruppenrichtlinie (Computerkonfiguration → Administrative Vorlagen → Netzwerk → DNS-Client → "Intelligente Multi-Homed-Namensauflösung deaktivieren" → Aktiviert) oder per PowerShell: Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" -Name "DisableParallelAandAAAA" -Value 1. Neustart erforderlich. Einige gut gepflegte VPN-Clients erledigen dies automatisch beim Verbindungsaufbau — wenn deiner das nicht tut, führe es manuell durch.

Split-Tunnel-Leaks beheben

Prüfe dein Split-Tunnel-Regelwerk. Verifiziere für jede App, die geschützt sein soll, dass sowohl ihr TCP-Datenverkehr als auch ihre DNS-Anfragen durch den Tunnel geroutet werden. Manche VPN-Clients erlauben die DNS-Konfiguration pro App; die meisten nicht. Wenn deiner es nicht tut, ist der sicherere Standard, Split Tunneling vollständig zu deaktivieren und einen Full Tunnel zu verwenden — der alles (einschließlich aller DNS-Anfragen) durch das VPN leitet. Für die meisten Nutzer überwiegt der Komfortvorteil von Split Tunneling das Leak-Risiko nicht.

IPv6-Leaks beheben

Die zuverlässigste Lösung ist, einen VPN-Client zu verwenden, der IPv6 innerhalb des Tunnels unterstützt (oder zumindest passende IPv6-Firewall-Regeln installiert, die IPv6-Datenverkehr blockieren, wenn der Tunnel aktiv ist). Wenn du den Client nicht wechseln kannst, deaktiviere IPv6 auf der physischen Netzwerkschnittstelle: unter Windows in den Adaptereigenschaften; unter macOS in Systemeinstellungen → Netzwerk → Erweitert → TCP/IP. Das ist ein radikaler Eingriff (du verlierst IPv6-Konnektivität vollständig), beseitigt aber den Leak-Vektor.

WebRTC-Leaks beheben

Setze in Firefox media.peerconnection.enabled in about:config auf false. In Chrome und Edge installiere eine Erweiterung wie WebRTC Network Limiter oder nutze die WebRTC-Blockierungsoption von uBlock Origin. Safari behandelt WebRTC standardmäßig konservativer, kann in manchen Konfigurationen aber trotzdem lokale IPs leaken; Safari 17+ hat dies deutlich verbessert. Teste die Änderung anschließend mit ipleak.net.

Warum "VPN nutzen" allein keine Leak-Garantie ist

Es gibt eine verbreitete Annahme, dass ein VPN-Verbindungsaufbau DNS-Leaks automatisch verhindert. Das tut er nicht — die Prävention hängt davon ab, dass der VPN-Client eine Reihe von Dingen korrekt erledigt: den System-DNS-Resolver ändern, Firewall-Regeln installieren, die DNS direkt zum ISP blockieren, IPv6 behandeln, Windows SMHNR deaktivieren (oder gleichwertige OS-Bypass-Funktionen) und Netzwerkwechsel (WLAN-Roaming, Schlaf-/Wachzyklen) überstehen, ohne den Leak wieder einzuführen.

Ein gut gebauter VPN-Client erledigt all das automatisch, und du musst dir keine Gedanken darüber machen. Ein schlecht gebauter — oder ein "kostenloser" VPN, der das integrierte VPN-Profil des Betriebssystems ohne zusätzlichen Leak-Schutz nutzt — erledigt nur einen Teil davon und lässt Leak-Vektoren offen. Der einzige Weg, um zu wissen, in welcher Kategorie du dich befindest, ist, nach dem Verbinden tatsächlich einen Leak-Test durchzuführen. Wenn der Test sauber zurückkommt, kannst du aufhören, dir Sorgen zu machen; wenn er Leaks zeigt, hast du spezifische Probleme zu beheben — und weißt jetzt, welche.

DNS-Leak-Prävention auf iOS, Android, Mac und Windows

iOS

iOS verwaltet DNS über das NetworkExtension-Framework. Eine ordentlich gebaute VPN-App verwendet das NEDNSSettings-Objekt, um einen benutzerdefinierten Resolver anzugeben, der verwendet wird, solange der Tunnel aktiv ist. iOS erzwingt dies auf OS-Ebene — Apps können das konfigurierte DNS nicht ohne explizite Genehmigung umgehen. Der wichtigste Leak-Vektor auf iOS ist iCloud Private Relay, das (wenn es gleichzeitig mit einem VPN aktiviert ist) DNS über Apples Resolver statt über den des VPNs routen kann. Wenn du ein VPN zum Datenschutz nutzt, deaktiviere iCloud Private Relay, um Konflikte zwischen beiden zu vermeiden. iOS 14 hat das includeAllNetworks-Flag eingeführt (oft in Verbindung mit Kill-Switch-Verhalten), das sicherstellt, dass auch DNS auf Systemebene durch den Tunnel geleitet wird.

Android

Androids VpnService-API ermöglicht es dem VPN-Client, DNS-Server anzugeben, die für den gesamten getunnelten Datenverkehr gelten. Die Systemeinstellung "Immer aktives VPN" mit aktiviertem "Verbindungen ohne VPN blockieren" bietet die stärkste Garantie — keine App kann DNS auflösen, ohne dass der Tunnel aktiv ist. Android unterstützt auch systemweites privates DNS (Einstellungen → Netzwerk & Internet → Privates DNS), das alle DNS-Anfragen über DNS-over-TLS zu einem gewählten Anbieter erzwingt. Die Kombination aus Always-on VPN und privatem DNS bietet doppelten Schutz vor DNS-Leaks.

macOS

macOS verwendet scutil und das System Configuration Framework zur Verwaltung von DNS-Einstellungen. Ein VPN-Client, der über das NetworkExtension-Framework läuft, kann DNS-Einstellungen installieren, die Vorrang haben, solange der Tunnel aktiv ist. Der wichtigste Leak-Vektor auf macOS ist browser-seitiges DNS-over-HTTPS, das den Systemresolver vollständig umgeht — deaktiviere browser-seitiges DoH oder konfiguriere es so, dass es auf denselben Resolver wie das VPN zeigt. Teste mit scutil --dns im Terminal, um die aktiven Resolver anzuzeigen; nur der Resolver des VPNs sollte im Abschnitt mit höchster Priorität erscheinen.

Windows

Windows hat die größte Leak-Oberfläche aller gängigen Betriebssysteme, hauptsächlich wegen Smart Multi-Homed Name Resolution. Neben der Deaktivierung von SMHNR (oben beschrieben) überprüfe, ob der virtuelle Adapter des VPNs eine höhere Metrik-Priorität als dein physischer Adapter hat, ob IPv6 entweder deaktiviert oder korrekt getunnelt ist, und ob keine App mit eigenen DNS-Overrides konfiguriert ist. Windows 11 hat eine verbesserte DNS-Einstellungs-Benutzeroberfläche hinzugefügt, aber das zugrunde liegende Verhalten ähnelt Windows 10. Der Befehl ipconfig /all zeigt die aktiven Resolver pro Schnittstelle an.

Was gute VPN-Apps intern tun, um Leaks zu verhindern

Ein gut durchdachter VPN-Client fordert dich nicht auf, über DNS-Leaks nachzudenken. Er behandelt sie als grundlegenden Teil des Verbindungsprozesses. Im Einzelnen:

• Konfiguriert beim Verbinden einen benutzerdefinierten Resolver. Der Client teilt dem Betriebssystem mit: "Während ich verbunden bin, gehen alle DNS-Anfragen an diese spezifische IP-Adresse" — in der Regel der eigene Resolver des VPN-Anbieters, der nur über den Tunnel erreichbar ist. Der Client stellt beim Trennen auch die vorherigen DNS-Einstellungen wieder her.
• Installiert Firewall-Regeln, um direktes DNS zu blockieren. Selbst wenn eine App versucht, einen DNS-Server eigenständig abzufragen (z. B. eine fest codierte Anfrage an 8.8.8.8), blockiert die Firewall-Regel das ausgehende Paket auf UDP-Port 53. Das einzige DNS, das das Gerät verlassen kann, ist das, was durch den Tunnel fließt.
• Verwendet verschlüsseltes DNS (DoT oder DoH) innerhalb des Tunnels. Selbst nachdem die Anfrage im Tunnel ist, wird der Hop vom Resolver zum Server mit DNS-over-TLS (RFC 7858) oder DNS-over-HTTPS verschlüsselt, sodass der vorgelagerte Betreiber den Anfrageinhalt nicht sehen kann. Unser Beitrag zu DNS-over-HTTPS vs. DNS-over-TLS behandelt die Abwägungen zwischen den beiden Protokollen.
• Behandelt IPv6 explizit. IPv6-Routen werden entweder durch das VPN getunnelt (bevorzugt) oder auf der Firewall blockiert, um IPv6-Fallback zu verhindern. Der Client lässt IPv6-Routing niemals unkonfiguriert.
• Ist mit einem Kill Switch gekoppelt. Wenn der Tunnel kurz abbricht, blockiert der Kill Switch den gesamten Datenverkehr — einschließlich DNS — bis der Tunnel wieder hergestellt ist. Dies verhindert die Race Condition "Tunnel abgebrochen, DNS geleakt, Tunnel wiederhergestellt". Wir behandeln das ausführlich in was ist ein VPN Kill Switch.
• Testet bei jeder Verbindung. Manche Clients führen nach jedem Verbindungsaufbau einen eingebauten Leak-Test durch und weisen den Benutzer auf jede Anomalie hin. Das ist selten, aber es ist das stärkste denkbare Modell.

Casper's Cloak verwendet einen benutzerdefinierten DNS-Resolver, der nur innerhalb des WireGuard-Tunnels erreichbar ist, durchgehend mit DNS-over-TLS verschlüsselt, mit explizit getunnelten IPv6-Routen und Windows SMHNR, das bei der Installation deaktiviert wird. Die Bedrohungsschutz-Funktion führt DNS-basiertes Filtern gegen bekannte schädliche Domains an demselben Resolver durch — sodass das leak-geschützte DNS auch aktiv Phishing und Malware blockiert. Der Mechanismus ist in unserem Beitrag zu wie DNS-basiertes Filtern wirklich funktioniert dokumentiert. Der kombinierte Effekt: standardmäßig korrekt konfiguriert, kein Leak unter keinem der vier häufigen Fehlermodi und aktives Filtern obendrauf.

Als Hintergrund zum zugrunde liegenden Protokoll ist die IETF-Spezifikation von DNS-over-TLS in RFC 7858 dokumentiert, das die kryptografischen und transportschichtbezogenen Anforderungen für die Übertragung von DNS über einen TLS-gesicherten Kanal beschreibt. Dasselbe Framework nutzen datenschutzorientierte öffentliche Resolver (Cloudflare, Quad9, NextDNS) für ihre sicheren DNS-Endpunkte.

Fazit: Ein DNS-Leak ist der häufigste Weg, auf dem das Datenschutzversprechen eines VPNs still und leise scheitert. Er lässt sich leicht testen, meist leicht beheben, und jedes VPN, dem du vertraust, sollte einen Leak-Test ohne manuellen Eingriff bestehen. Wenn deins das nicht tut, ist das ein Signal — entweder die Konfiguration korrigieren oder wechseln.