Wat is een DNS-lek — en hoe test je er in de praktijk op

De korte versie: een VPN-tunnel versleutelt de IP-pakketten die je apparaat naar andere servers stuurt. DNS is de opzoeking die vóór het versturen van het pakket plaatsvindt — je apparaat vraagt "welk IP-adres hoort bij example.com?" Als die opzoeking naar de resolver van je ISP gaat in plaats van via de VPN, ziet je ISP het domein ook al ziet hij nooit het versleutelde verkeer dat daarna volgt. Dat is een lek. Het ondermijnt de belangrijkste privacybelofte van een VPN om de meest eenvoudige reden: de verkeerde DNS-resolver werd gevraagd. Het goede nieuws is dat lekken makkelijk te detecteren zijn, meestal makkelijk te verhelpen, en de meeste goed gebouwde VPN-apps ze standaard voorkomen. Het slechte nieuws is dat "de meeste" niet "alle" is, en een handvol veelvoorkomende configuraties lekken veroorzaken zelfs bij verder correcte VPN-instellingen.

Wat DNS eigenlijk doet en waarom het lekt

DNS — het Domain Name System — is het adresboek van het internet. Elke keer dat je apparaat verbinding maakt met een website, moet het eerst de voor mensen leesbare hostnaam (example.com) vertalen naar een numeriek IP-adres (zoiets als 93.184.216.34) waar routers pakketten naartoe kunnen sturen. Die vertaalstap is een DNS-verzoek, en het is een afzonderlijke netwerkoperatie los van het eigenlijke webverzoek dat erna komt.

Op een typische thuisverbinding wordt je DNS-resolver toegewezen door je ISP via DHCP — hetzelfde mechanisme dat je IP-adres uitdeelt. Wanneer je verbinding maakt met Wi-Fi, vertelt de router je apparaat: "je DNS-server is 192.168.1.1, die doorstuurt naar de recursieve resolver van je ISP." Elk domein dat je opzoekt loopt door die resolver. De ISP kan het loggen, verkopen aan een datamakelaardij (in de Verenigde Staten is dit legaal), of overhandigen aan wetshandhaving.

Wanneer je een VPN aansluit, zouden er twee dingen moeten gebeuren. Ten eerste wordt je netwerkverkeer versleuteld en via de VPN-tunnel gerouteerd. Ten tweede moet je DNS-resolver veranderen — van de resolver van de ISP naar een resolver die wordt beheerd door de VPN-aanbieder (of een privacygerichte resolver van derden), alleen bereikbaar via de versleutelde tunnel. Als alleen de eerste helft plaatsvindt, heb je een DNS-lek. Het verkeer is versleuteld, maar de opzoekingen die voorafgingen aan het verkeer stromen nog steeds naar de ISP, die zo elk domein kan zien dat je op het punt staat te bezoeken.

Vanuit privacyoogpunt is het DNS-verzoek bijna net zo onthullend als het verkeer zelf. Het verzoek onthult het exacte domein (tot aan subdomein — mail.example.com is te onderscheiden van www.example.com) en de timing. Gecombineerd met het versleutelde verkeersvolume onmiddellijk daarna, geeft een DNS-lekke VPN een waarnemer genoeg metadata om je browsesessie op vrijwel elke zinvolle manier te reconstrueren.

De vier manieren waarop een DNS-lek ontstaat

DNS-lekken zijn geen enkelvoudige bug. Het is een familie van gerelateerde misconfiguraties, elk met een andere oorzaak en een andere oplossing. Ruwweg op volgorde van frequentie:

1. OS-bypass — Windows split DNS / Smart Multi-Homed Name Resolution

Windows heeft een functie genaamd Smart Multi-Homed Name Resolution die, wanneer ingeschakeld, DNS-verzoeken parallel naar elke beschikbare DNS-resolver stuurt — inclusief de resolver van de ISP op de fysieke interface, ook als een VPN actief is. Welke resolver het snelst antwoordt wint, en de anderen worden genegeerd, maar de verzoeken zijn al verzonden. Op de meeste Windows-machines staat dit standaard aan. De oplossing is om de functie uit te schakelen via Groepsbeleid of door de VPN-client dit bij verbinding te laten doen. Linux heeft een vergelijkbaar probleem met systemd-resolved als dit niet correct is geconfigureerd; macOS en iOS gaan hier beter mee om, maar niet perfect.

2. Split-tunnel misconfiguratie

Met split-tunneling kun je sommige apps via de VPN laten lopen en andere via je normale verbinding. Een veelgemaakte configuratiefout is het instellen van op apps gebaseerd split-tunneling zonder ook per-app DNS te configureren — wat betekent dat een app die buiten de VPN-tunnel wordt gerouteerd nog steeds probeert de DNS-resolver van de VPN te gebruiken, of andersom, en uiteindelijk lekt via welk pad het besturingssysteem ook biedt. Een ergere variant: de split-tunnel routeert het TCP-verkeer van de app correct buiten de tunnel, maar de systeembrede DNS-resolver is nog steeds die van de ISP, zodat elke app — getunneld of niet — zijn DNS-verzoeken naar de ISP lekt. We behandelen het bredere onderwerp in onze uitleg over wat split-tunneling eigenlijk doet.

3. IPv6-fallback

Veel VPN-clients zijn ontworpen toen IPv4 het enige routeringsprobleem was. Ze installeren IPv4-firewall- en routeringsregels die DNS correct via de tunnel sturen, maar geen overeenkomende IPv6-regels. Als je netwerk IPv6-connectiviteit heeft, geeft het besturingssysteem soms de voorkeur aan IPv6 voor DNS-verzoeken — en die verzoeken stromen via de kale interface, waarbij de VPN volledig wordt omzeild. Dit is een van de meest voorkomende lekvormen in 2026 en het komt bijzonder vaak voor op residentiële breedbandverbindingen met dual-stack IPv4/IPv6 van de ISP. De oplossing is ofwel IPv6 volledig uitschakelen (ingrijpend maar betrouwbaar), of een VPN-client gebruiken die expliciet IPv6-routes afhandelt.

4. WebRTC en door de browser opgeloste DNS

Moderne browsers — Chrome, Edge, Firefox, Safari — kunnen zelf DNS-opzoekingen uitvoeren in plaats van de OS-resolver te gebruiken. Het meest beruchte geval is WebRTC, het peer-to-peer-protocol dat wordt gebruikt door videochat. WebRTC gebruikt STUN-servers om je echte lokale en publieke IP-adressen te ontdekken, en historisch gezien zond het beide uit zelfs als een VPN actief was. Het "echte" IP van WebRTC is al lang een lek aan de browserkant dat expliciete mitigatie vereist. Afzonderlijk kunnen browsers die DNS-over-HTTPS (DoH) gebruiken DNS-verzoeken rechtstreeks naar Cloudflare, Google of NextDNS sturen, ongeacht de instelling van de OS-resolver — wat soms helpt (DoH naar een publieke resolver is privater dan plaintext naar de ISP) en soms kwaad doet (de publieke resolver ziet je verzoeken nog steeds, en de browser omzeilt de DNS-regels van de VPN).

Hoe je in minder dan een minuut op een DNS-lek test

Testen op een DNS-lek kost meer tijd om te beschrijven dan om te doen. Verbind je VPN en bezoek daarna een van deze drie tools. Ze onthullen elk een iets ander aspect van het lekoppervlak.

dnsleaktest.com

De klassieke. Bezoek dnsleaktest.com, klik op "Extended test" en wacht ongeveer 20 seconden. De tool verstuurt een reeks DNS-verzoeken voor unieke hostnamen die het beheert en laat je dan zien welke resolvers die opzoekingen daadwerkelijk hebben uitgevoerd. Als je de naam van je ISP ziet (Comcast, Verizon, BT, etc.) in de resolverlijst, lek je. Als je alleen de resolver van de VPN-aanbieder ziet (of een privacygerichte publieke resolver zoals Quad9 of Cloudflare's 1.1.1.1), is het OS DNS-pad correct.

browserleaks.com/dns

Gedetailleerder dan dnsleaktest. Het toont je niet alleen welke resolvers het verzoek hebben afgehandeld, maar ook hun geografische locatie, ASN (de netwerkoperator), en of ze DNS-over-HTTPS of DNS-over-TLS ondersteunen. Nuttig voor het opsporen van subtiele lekken waarbij het juiste type resolver wordt gebruikt maar in het verkeerde land, of voor het bevestigen dat een versleuteld DNS-protocol daadwerkelijk in gebruik is.

ipleak.net

De meest uitgebreide — het test DNS-lekken, WebRTC-lekken, IPv4- en IPv6-zichtbaarheid, en toont hoe je geolocatie er van buitenaf uitziet. Het WebRTC-gedeelte is cruciaal: als je een "lokaal IP"-adres in het 192.168.x.x- of 10.x.x.x-bereik ziet naast een "publiek IP" dat overeenkomt met je VPN-eindpunt, doet je VPN zijn werk maar lekt je browser via WebRTC. Het IPv6-gedeelte vangt IPv6-fallback-lekken op die dnsleaktest soms mist.

Hoe een schoon resultaat eruitziet versus een lekresultaat

Op de extended test van dnsleaktest.com met een correct geconfigureerde VPN zou je iets als dit moeten zien:

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.

En zo ziet een lek eruit:

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.

Het belangrijkste signaal is de ISP-kolom. Als er iets anders dan je VPN-aanbieder (of een bewust gekozen publieke resolver) verschijnt, lekt je DNS. Als de landkolom je echte land toont naast het exitland van de VPN, lek je. Als alleen het eindpuntland van de VPN verschijnt, ben je schoon.

Lektypen vergeleken

Elk van de vier lektypen heeft een duidelijke vingerafdruk in de testresultaten, een specifieke groep waarnemers die het kunnen misbruiken, en een specifieke oplossing:

De vier veelvoorkomende oorzaken verhelpen

OS-bypass-lekken verhelpen (Windows)

Op Windows 10 en 11 schakel je Smart Multi-Homed Name Resolution uit via Groepsbeleid (Computerconfiguratie → Beheersjablonen → Netwerk → DNS-client → "Slimme multithuis naamomzetting uitschakelen" → Ingeschakeld) of via PowerShell: Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" -Name "DisableParallelAandAAAA" -Value 1. Herstart. Sommige goed onderhouden VPN-clients doen dit automatisch bij verbinding — als die van jou dat niet doet, doe het dan handmatig.

Split-tunnel-lekken verhelpen

Controleer je split-tunnel-regelset. Controleer voor elke app die beschermd moet worden of zowel het TCP-verkeer als de DNS-verzoeken via de tunnel worden gerouteerd. Sommige VPN-clients laten je per-app DNS configureren; de meeste niet. Als die van jou dat niet doet, is de veiligere standaard om split-tunneling volledig uit te schakelen en een volledige tunnel te gebruiken — die alles (inclusief alle DNS) via de VPN routeert. Voor de meeste gebruikers weegt het gemakvoordeel van split-tunneling niet op tegen het lekrisico.

IPv6-lekken verhelpen

De meest betrouwbare oplossing is een VPN-client gebruiken die IPv6 binnen de tunnel ondersteunt (of op zijn minst overeenkomende IPv6-firewallregels installeert die IPv6-verkeer blokkeren wanneer de tunnel actief is). Als je niet van client kunt wisselen, schakel IPv6 dan uit op de fysieke netwerkinterface: op Windows, in de adapteropties; op macOS, in Systeeminstellingen → Netwerk → Geavanceerd → TCP/IP. Dit is ingrijpend (je verliest IPv6-connectiviteit volledig), maar het elimineert de lekroute.

WebRTC-lekken verhelpen

In Firefox, stel media.peerconnection.enabled in op false in about:config. In Chrome en Edge, installeer een extensie zoals WebRTC Network Limiter of de WebRTC-blokkeringsoptie van uBlock Origin. Safari gaat standaard conservatiever om met WebRTC, maar je kunt nog steeds lokale IP's lekken in bepaalde configuraties; Safari 17+ heeft dit aanzienlijk verbeterd. Test na de wijziging met ipleak.net.

Waarom "gebruik een VPN" alleen geen garantie geeft op geen lekken

Er bestaat een veelgehoorde aanname dat verbinding maken met een VPN DNS-lekken automatisch voorkomt. Dat doet het niet — de preventie hangt af van de VPN-client die een reeks dingen correct doet: de systeem-DNS-resolver wijzigen, firewallregels installeren om directe DNS-verbindingen naar de ISP te blokkeren, IPv6 afhandelen, Windows SMHNR uitschakelen (of equivalente OS-bypass-functies), en het doorstaan van netwerkwijzigingen (Wi-Fi-roams, slaap/waak-cycli) zonder het lek opnieuw te introduceren.

Een goed gebouwde VPN-client doet dit allemaal automatisch en je hoeft er nooit over na te denken. Een slecht gebouwde — of een "gratis" VPN die het ingebouwde VPN-profiel van het besturingssysteem gebruikt zonder extra lekbescherming — doet een deel ervan, waardoor lekroutes open blijven. De enige manier om te weten in welke categorie je valt, is daadwerkelijk een lektest uitvoeren na het verbinden. Als de test schoon terugkomt, hoef je je er geen zorgen meer over te maken; als het lekken aantoont, heb je specifieke problemen om op te lossen en weet je nu welke.

DNS-lekpreventie op iOS, Android, Mac en Windows

iOS

iOS verwerkt DNS via het NetworkExtension-framework. Een goed gebouwde VPN-app gebruikt het NEDNSSettings-object om een aangepaste resolver op te geven die wordt gebruikt terwijl de tunnel actief is. iOS dwingt dit af op OS-niveau — apps kunnen de geconfigureerde DNS niet omzeilen zonder expliciete toestemming. De belangrijkste lekroute op iOS is iCloud Private Relay, dat (wanneer naast een VPN ingeschakeld) DNS via de resolver van Apple kan routeren in plaats van die van de VPN. Als je een VPN voor privacy gebruikt, schakel iCloud Private Relay dan uit om te voorkomen dat de twee conflicteren. iOS 14 voegde de includeAllNetworks-vlag toe (vaak gebruikt samen met kill-switch-gedrag) die ervoor zorgt dat zelfs DNS op systeemniveau via de tunnel gaat.

Android

De VpnService API van Android laat de VPN-client DNS-servers opgeven die gelden voor al het getunnelde verkeer. De systeeminstelling "Altijd actieve VPN" met "Verbindingen zonder VPN blokkeren" ingeschakeld geeft de sterkste garantie — geen app kan DNS oplossen zonder dat de tunnel actief is. Android ondersteunt ook systeem brede private DNS (Instellingen → Netwerk en internet → Private DNS), waardoor alle DNS DNS-over-TLS naar een gekozen aanbieder gebruikt. Het combineren van Altijd actieve VPN met Private DNS geeft dubbele bescherming tegen DNS-lekken.

macOS

macOS gebruikt scutil en het System Configuration-framework om DNS-instellingen te beheren. Een VPN-client die via het NetworkExtension-framework draait, kan DNS-instellingen installeren die voorrang krijgen terwijl de tunnel actief is. De belangrijkste lekroute op macOS is DNS-over-HTTPS op browserniveau, die de systeemresolver volledig omzeilt — schakel DoH op browserniveau uit of configureer het om naar dezelfde resolver als de VPN te wijzen. Test met scutil --dns in Terminal om de actieve resolvers te zien; alleen de resolver van de VPN zou in de sectie met de hoogste prioriteit moeten verschijnen.

Windows

Windows heeft het grootste lekoppervlak van alle grote besturingssystemen, voornamelijk vanwege Smart Multi-Homed Name Resolution. Controleer naast het uitschakelen van SMHNR (hierboven behandeld) of de virtuele adapter van de VPN een hogere metrische prioriteit heeft dan je fysieke adapter, of IPv6 is uitgeschakeld of correct getunneld, en of geen enkele app is geconfigureerd met eigen DNS-overschrijvingen. Windows 11 heeft een verbeterde DNS-instellingen-UI toegevoegd, maar het onderliggende gedrag is vergelijkbaar met Windows 10. Het commando ipconfig /all toont de actieve resolvers per interface.

Wat goede VPN-apps achter de schermen doen om lekken te voorkomen

Een goed ontwikkelde VPN-client vraagt je niet om na te denken over DNS-lekken. Die worden afgehandeld als een basaal onderdeel van het verbindingsproces. Concreet:

• Configureert bij verbinding een aangepaste resolver. De client vertelt het besturingssysteem "terwijl ik verbonden ben, gaan alle DNS-verzoeken naar dit specifieke IP-adres" — doorgaans de eigen resolver van de VPN-aanbieder, alleen bereikbaar via de tunnel. De client herstelt ook de vorige DNS-instellingen bij verbreken van de verbinding.
• Installeert firewallregels om directe DNS te blokkeren. Zelfs als een app een DNS-server op eigen initiatief probeert te bevragen (bijv. een hardgecodeerd verzoek aan 8.8.8.8), blokkeert de firewallregel het uitgaande pakket op UDP-poort 53. De enige DNS die het apparaat kan verlaten, is wat via de tunnel stroomt.
• Gebruikt versleutelde DNS (DoT of DoH) binnen de tunnel. Zelfs nadat het verzoek binnen de tunnel is, wordt de resolver-naar-server-stap versleuteld met DNS-over-TLS (RFC 7858) of DNS-over-HTTPS, zodat de upstream-beheerder de inhoud van het verzoek niet kan zien. Onze uitleg over DNS-over-HTTPS vs DNS-over-TLS behandelt de afwegingen tussen de twee protocollen.
• Handelt IPv6 expliciet af. IPv6-routes worden ofwel via de VPN getunneld (voorkeur) of geblokkeerd door de firewall om IPv6-fallback te voorkomen. De client laat IPv6-routering nooit ongeconfigureerd.
• Werkt samen met een kill switch. Als de tunnel even wegvalt, blokkeert de kill switch al het verkeer — inclusief DNS — totdat de tunnel opnieuw is opgezet. Dit voorkomt de race condition waarbij de "tunnel valt weg, DNS lekt, tunnel herstelt". We behandelen dit in detail in wat is een VPN kill switch.
• Test bij elke verbinding. Sommige clients voeren na elke verbinding een ingebouwde lektest uit en markeren eventuele afwijkingen voor de gebruiker. Dit is zeldzaam, maar het is het sterkst mogelijke model.

Casper's Cloak gebruikt een aangepaste DNS-resolver die alleen bereikbaar is binnen de WireGuard-tunnel, end-to-end versleuteld via DNS-over-TLS, met IPv6-routes die expliciet worden getunneld en Windows SMHNR dat bij installatie wordt uitgeschakeld. De bedreigingsbeschermingsfunctie voert DNS-niveau-filtering uit op bekende kwaadaardige domeinen bij dezelfde resolver, zodat dezelfde DNS die lekbestendig is ook actief phishing en malware blokkeert. Het mechanisme is gedocumenteerd in onze uitleg over hoe DNS-niveau-filtering eigenlijk werkt. Het gecombineerde effect: standaard correct geconfigureerd, geen lekken bij alle vier veelvoorkomende storingssituaties, en actieve filtering bovenop.

Voor de achterliggende protocolachtergrond is de IETF-specificatie van DNS-over-TLS gedocumenteerd in RFC 7858, dat de cryptografische en transportlaagvereisten behandelt voor het verzenden van DNS via een TLS-beveiligd kanaal. Hetzelfde framework is wat privacygerichte publieke resolvers (Cloudflare, Quad9, NextDNS) gebruiken voor hun beveiligde DNS-eindpunten.

Samengevat: een DNS-lek is de meest voorkomende manier waarop de privacybelofte van een VPN stilletjes mislukt. Het is makkelijk op te testen, meestal makkelijk te verhelpen, en elke VPN die je vertrouwt, zou een lektest moeten doorstaan zonder handmatige tussenkomst. Als je VPN dat niet doet, is dat een signaal — ofwel misconfiguratie of verder kijken.