Kurz gesagt
Jeden Namen, den dein Gerät nachschlägt, erfährt der Auflöser — meist der deines Zugangsanbieters — und, solange die Frage unverschlüsselt reist, jeder auf dem Weg dorthin, etwa der Betreiber eines WLANs. DNS über HTTPS oder TLS verschlüsselt diesen Weg, aber der Auflöser sieht die Namen weiterhin, und dein Zugangsanbieter erkennt das Ziel oft trotzdem am Aufbau der Verbindung. Mit einem VPN sollte auch das Nachschlagen durch den Tunnel laufen. Nimmt es einen Weg daran vorbei, etwa über IPv6, ist das ein DNS-Leck. Einen eigenen Test dafür hat HexWarte noch nicht; er ist geplant.
Wer beim Nachschlagen mitliest
Bevor dein Browser eine Seite lädt, fragt dein Gerät einen Auflöser nach der Adresse zum Namen — wie das grundsätzlich funktioniert, steht unter DNS (Namensauflösung). Klassisch reist diese Frage unverschlüsselt; der Standard von 1987 sieht nichts anderes vor. Wer im selben WLAN sitzt oder das Netz betreibt, kann mitlesen, welche Namen du ansteuerst.
Am meisten erfährt der Auflöser selbst: jeden Namen, deine IP-Adresse und die Uhrzeit. Die IETF, die die Internetstandards schreibt, sagt es knapp: Dein Auflöser weiß viel über dich. Kennt er die Antwort noch nicht, fragt er sich durch — bei der Wurzel des Namenssystems, bei der Stelle für die Endung wie „.de“ und zuletzt beim Nameserver der Website. Diese Server sehen die Adresse des Auflösers, nicht deine.
Auflöser nach RFC 9156 nennen der Wurzel und der Endungsstelle nur den Teil des Namens, den diese brauchen. Umgekehrt reichen manche Auflöser einen gekürzten Teil deiner Adresse an den Nameserver der Website weiter, damit er einen Server in deiner Nähe nennen kann (RFC 7871) — Google Public DNS höchstens die ersten drei der vier Zahlenblöcke einer IPv4-Adresse.
Was verschlüsseltes DNS ändert — und was nicht
Zwei Verfahren verschlüsseln den Weg zum Auflöser. DNS über TLS (RFC 7858, 2016) benutzt einen eigenen Port, also eine eigene Nummer am Server, und lässt sich daran erkennen und sperren. DNS über HTTPS (RFC 8484, 2018) reist auf demselben Weg wie jede verschlüsselte Website. Android beherrscht DNS über TLS seit Fassung 9 unter dem Namen „Privates DNS“.
Chrome verschlüsselt das Nachschlagen (Einstellung „Sicheres DNS verwenden“) von Haus aus nur, wenn dein bisheriger Auflöser das selbst anbietet, und fällt bei Problemen auf das unverschlüsselte Nachschlagen zurück. Firefox schaltet DNS über HTTPS von Haus aus nur am Computer und nur in vier Ländern ein — den USA, Kanada, Russland und der Ukraine, nicht in Deutschland — und im „Standardschutz“ wieder ab, sobald es ein VPN, Jugendschutz oder Unternehmensrichtlinien erkennt.
Was die Verschlüsselung nicht ändert: Der Auflöser sieht jeden Namen weiterhin. Die IETF schreibt sogar, verschlüsselter Transport verringere die Daten beim Auflöser nicht und könne ihm eher mehr über dich zeigen. Und dein Zugangsanbieter sieht weiter, mit welchem Server du dich danach verbindest — meist auch den Namen, weil der Browser ihn beim Aufbau der verschlüsselten Verbindung offen nennt, siehe TLS.
Diese Lücke schließt Encrypted Client Hello, kurz ECH, seit März 2026 als RFC 9849 veröffentlicht: Der Name reist mitverschlüsselt. Chrome kann das seit Fassung 117, Firefox seit 118. Es wirkt aber nur bei Websites, die es anbieten, und den Schlüssel dafür holt der Browser aus dem DNS. Ohne verschlüsseltes DNS nützt es deshalb weniger, schreibt das RFC selbst: Wer mitliest, sieht den Namen dann schon in der offenen Frage nach dem Schlüssel. Die Adresse des Servers bleibt ohnehin sichtbar.
Was ein DNS-Leck ist — und woran es liegt
Mit einem VPN sollte auch das Nachschlagen durch den Tunnel laufen, meist zu einem Auflöser des VPN-Anbieters. Ein DNS-Leck heißt im engen Sinn: Die Fragen nehmen einen Weg am Tunnel vorbei, und dein Zugangsanbieter oder der Betreiber des WLANs sieht die Namen weiterhin. Manche VPN-Anbieter fassen den Begriff weiter: Für sie ist jede Frage ein Leck, die nicht bei ihrem eigenen Auflöser ankommt. Typische Ursachen:
- IPv6 am Tunnel vorbei. IPv6 ist die neuere Form der Internetadressen, viele Anschlüsse haben beide Formen. Leitet das VPN-Programm nur IPv4 um, kann Verkehr über IPv6 am Tunnel vorbei direkt ins Netz vor Ort gehen — das Nachschlagen eingeschlossen, meist unverschlüsselt. Die IETF beschrieb dieses Leck schon 2014 (RFC 7359).
- Mehrere Netze zugleich. Mit VPN hängt dein Gerät in zwei Netzen: im WLAN und im Tunnel. Windows kann dieselbe Frage in der Grundeinstellung parallel an die Auflöser aller verbundenen Netze schicken, um schneller zu antworten; so beschreibt es Microsoft. Dann landet sie auch beim Auflöser des WLANs.
- Eigene Einstellungen. Ein im System oder im VPN-Programm fest eingetragener Auflöser, Virenschutz oder Erweiterungen, die das Nachschlagen umleiten, gehen am Auflöser des VPN vorbei — ein Leck mindestens im weiten Sinn.
- Der eigene Auflöser des Browsers. Hast du für sicheres DNS einen festen Anbieter gewählt, fragt der Browser ihn auch mit VPN. Läuft alles durch den Tunnel, erfährt dein Zugangsanbieter davon nichts — ein Leck nur im weiten Sinn, aber ein zusätzlicher Betreiber kennt deine Namen.
- Ein Abbruch. Reißt der Tunnel ab, läuft ohne Notbremse alles über das normale Netz. Manche VPN-Programme sperren dann den Verkehr, bis der Tunnel wieder steht — oft „Kill Switch“ genannt.
Wie ein Lecktest arbeitet — und was HexWarte plant
Ein Lecktest lässt deinen Browser einen zufälligen Namen unter einer eigenen Domain nachschlagen. Kein Auflöser kennt die Antwort, also muss er beim Nameserver des Testbetreibers fragen — und der sieht, von welcher Adresse die Frage kommt. Diese Adresse zeigt dir der Test, oft mit dem Netzbetreiber. Steht dort trotz VPN das Netz deines Zugangsanbieters oder des WLANs, ist das ein Leck.
Zwei Dinge gehören zum Ergebnis dazu. Der Test sieht die Adresse, mit der der Auflöser nach außen fragt — bei großen öffentlichen Auflösern nicht die, die du eingetragen hast. Und er prüft nur den Weg des Browsers; andere Programme können anders nachschlagen.
Bei HexWarte geplant, nicht gebautIm Prüfkatalog steht der Test unter „Braucht eigene Technik“. Er bräuchte einen eigenen Nameserver, der kurz festhält, welcher Auflöser fragt — das berührt die Zusage, nichts aufzuzeichnen. Gebaut wird er deshalb erst nach einer ausdrücklichen Entscheidung über Umfang und Löschfrist.
Beim IPv6-Leck hilft dir Kammer 1 schon heute. HexWarte ist über beide Formen erreichbar, und Browser bevorzugen IPv6. Steht dort trotz VPN eine IPv6-Adresse mit deinem Zugangsanbieter als Netzbetreiber, läuft IPv6 am Tunnel vorbei — und mit ihm womöglich auch das Nachschlagen.
Ein Beispiel: Selin im Café
Selin sitzt mit ihrem Laptop und eingeschaltetem VPN im WLAN eines Cafés. Sie ruft die Seite einer Schuldnerberatung auf. Die Seite ist nur über IPv4 erreichbar und sieht die Adresse des VPN-Servers. Für Selin wirkt alles dicht.
- Das WLAN des Cafés verteilt auch IPv6-Adressen und nennt einen Auflöser mit IPv6-Adresse. Selins VPN-Programm leitet nur IPv4 um.
- Ihr Laptop schickt die Frage nach der Beratungsseite über IPv6 an diesen Auflöser — am Tunnel vorbei und unverschlüsselt. Der Zugangsanbieter des Cafés erfährt den Namen samt Uhrzeit, und wer das WLAN betreibt, kann ihn mitlesen.
- Ein Lecktest zeigt ihr zwei Auflöser: den ihres VPN-Anbieters und einen aus dem Netz des Café-Anbieters. Der zweite ist das Leck.
- Kammer 1 zeigt es auch: eine IPv6-Adresse aus dem Netz des Café-Anbieters; erst die Karte „Deine Adresse gegenüber einem IPv4-Server“ nennt den VPN-Server.
Selin stellt im VPN-Programm ein, dass IPv6 durch den Tunnel geht oder gesperrt wird. Danach zeigen Test und Kammer 1 nur noch Adressen ihres VPN-Anbieters.
Was ein dichter Weg voraussetzt
- Ein VPN-Programm, das einen eigenen Auflöser mitbringt und IPv6 durch den Tunnel führt oder sperrt. IPv6 ganz abzuschalten nennt RFC 7359 nur eine Übergangslösung.
- Eine eingeschaltete Notbremse für den Fall, dass der Tunnel abreißt.
- Eine klare Entscheidung im Browser: Sicheres DNS in der Grundeinstellung lassen, dann richtet sich der Browser meist nach dem Auflöser, den das VPN dem System gibt — oder bewusst einen eigenen Anbieter wählen und wissen, dass dieser die Namen sieht.
- Vertrauen in den, der übrig bleibt: ohne VPN dein Zugangsanbieter oder der gewählte Anbieter für sicheres DNS, mit VPN der VPN-Anbieter. Mozilla verpflichtet die Anbieter in Firefox etwa, Daten, die auf dich zurückführen, höchstens 24 Stunden zu behalten und nicht weiterzugeben; nachprüfen kannst du das nicht.
Schritt für Schritt nachprüfen kannst du das mit Prüfen, ob dein VPN dicht ist; den zweiten typischen Weg am Tunnel vorbei beschreibt Wie WebRTC deine Adresse am VPN vorbei verraten kann.
Was dieser Artikel nicht sagt
- Dieser Artikel empfiehlt keinen Auflöser und keinen VPN-Anbieter. Was sie speichern und wie lange, steht nur in ihren eigenen Zusagen.
- Ein Lecktest — auch der geplante von HexWarte — beweist kein dichtes VPN. Er zeigt, welcher Auflöser in diesem Moment für diesen Browser gefragt hat.
- Ob und wie lange Zugangsanbieter Namensabfragen speichern dürfen, bewertet er nicht. Die Einordnung ist eine fachliche, keine rechtliche.
Weiter
In Kammer 1 nachsehen, ob neben dem VPN eine IPv6-Adresse deines Anschlusses erscheint →Passende Artikel
Begriffe dazu
Quellen
Geprüft am 3. Oktober 2026. Die Einordnung ist eine fachliche Bewertung, keine Rechtsberatung. Einen Fehler gefunden? Die Kontaktdaten stehen im Impressum.