Hoe voorkom je dat macOS DNS-aanvragen lekt (zelfs met een VPN aan)
Je VPN staat aan. Het tunnel-icoontje is groen. Je opent dnsleaktest.com en daar staat hij: de DNS-server van je provider, alsof er nooit een VPN heeft gedraaid. Dus ofwel je Mac is bezeten, ofwel macOS doet iets met DNS dat je VPN-client niet volledig overschrijft.
Het tweede is waarschijnlijker. macOS heeft een eigen manier van DNS afhandelen waar VPN-clients maar gedeeltelijk overheen kunnen schrijven, en in die kier ontstaan de meeste lekken. Het goede nieuws: je kunt het zelf vaststellen en repareren, zonder netwerkengineer te worden. Drie minuten voor de uitleg, ongeveer tien voor de fix.
Dit artikel doet vier dingen, in deze volgorde. Eerst waarom het gebeurt. Dan hoe je bevestigt dat je daadwerkelijk een lek hebt. Dan de fixes, op volgorde van impact. En tot slot wat je doet als je VPN-client zelf het probleem is.
Hoe macOS een DNS-aanvraag oplost
Wanneer een app een IP-adres opvraagt, gaat die aanvraag naar mDNSResponder, de systeemdienst die op macOS verantwoordelijk is voor naamresolutie. mDNSResponder kijkt naar zijn resolver-configuratie en kiest welke server de aanvraag krijgt. Die configuratie kan meerdere resolvers bevatten, elk gekoppeld aan een specifieke interface, een specifiek domein, of een prioriteit. Als je VPN-client zichzelf netjes als systeemresolver inschrijft, gaat de aanvraag door de tunnel. Als macOS om welke reden dan ook een andere resolver kiest, lekt de aanvraag.
Dat klinkt simpel maar is het niet. macOS biedt geen enkele schakelaar die zegt "stuur alle DNS via deze interface." VPN-clients moeten een combinatie van netwerkconfiguratie, kill switches en soms aanpassingen aan /etc/resolver/ gebruiken om dat gedrag te benaderen. Sommige clients doen dat volledig, andere gedeeltelijk.
De vier veelvoorkomende lekken
In de praktijk komen DNS-lekken op een Mac via vier paden binnen.
- IPv6-aanvragen wanneer de VPN alleen IPv4 tunnelt. macOS lost IPv6 dan gewoon op buiten de tunnel om, en de VPN ziet die aanvragen nooit.
- DNS-antwoorden die in de cache zaten van vóór de VPN-verbinding. macOS bewaart antwoorden voor de duur van hun TTL en hergebruikt ze, dus krijg je oude antwoorden van je provider terug, ook al draait de VPN nu.
- DNS over HTTPS (DoH) op browser-niveau. Chrome en Firefox kunnen op eigen houtje DNS opvragen, helemaal langs macOS heen. Een perfect geconfigureerde systeem-DNS vangt die queries niet op.
- iCloud Private Relay, op Macs waar dit aanstaat. Private Relay routeert sommige Safari-queries via Apple's tweedstaps-relay, wat onverwacht kan botsen met wat je VPN als DNS-pad verwacht.
Waarom VPN-clients dit niet altijd zelf oplossen
De combinatie van bovenstaande paden zorgt ervoor dat een VPN-client niet alles vanuit zijn eigen proces kan controleren. Een goed gebouwde client probeert het, maar slaagt alleen als hij actief macOS instructies geeft op meerdere niveaus tegelijk: de systeemresolver, de adapter-DNS, de IPv6-stack en (bij voorkeur) een kill switch die alle niet-VPN-verkeer blokkeert wanneer de tunnel valt. Niet elke client doet dat. Voordat je iets repareert, moet je weten welk pad bij jou lekt.
Test of je daadwerkelijk een DNS lek hebt
Test 1: dnsleaktest.com (Extended Test)
Verbind je VPN. Ga naar dnsleaktest.com en klik op Extended Test, niet Standard. De Extended Test doet enkele tientallen queries en onthult ook secundaire resolvers. Noteer de IP-adressen en hostnamen die verschijnen. Zie je de naam van je provider (Ziggo, KPN, T-Mobile, Vodafone, Odido), dan heb je een lek. Zie je alleen de resolvers van je VPN-aanbieder, dan is Test 1 geslaagd.
Test 2: Gebruik scutil onder terminal
Open macOS Terminal en voer het onderstaande commando uit:
$scutil --dns
De output is een dump van wat macOS zelf denkt over zijn DNS-configuratie. Kijk naar resolver #1, de primaire resolver. De nameserver velden zouden de DNS-servers van je VPN moeten zijn. Zie je de IP's van je provider in resolver #1 of in een andere laag-genummerde resolver, dan heeft je VPN-client de systeem-DNS niet succesvol overschreven. Deze test omzeilt dnsleaktest volledig en vertelt je wat het besturingssysteem feitelijk doet, niet wat een externe website meet.
Test 3: IPv6-leak
Ga naar ipv6-test.com of ipleak.net. Zie je een IPv6-adres in de uitkomst dat overeenkomt met je echte locatie of provider, dan heb je een IPv6-lek. Zie je een IPv6-adres dat hoort bij je VPN, dan tunnelt de VPN IPv6 mee en zit je goed. Dit is veruit de meest voorkomende oorzaak van klachten in de trant van "mijn VPN zegt dat ik in Roemenië zit, maar dnsleaktest laat mijn Nederlandse provider zien."
Met de uitkomst van deze drie tests weet je welk pad lekt. Repareer in de volgorde hieronder.
Stop het lek: macOS-fixes op volgorde van impact
Werk deze fixes van boven naar beneden af. Hervoer na elke fix de relevante test uit de vorige sectie. Stop zodra alle drie de tests slagen.
Fix 1: Dwing je VPN-client om DNS te pushen
Open de instellingen van je VPN-client. Zoek naar een optie die heet "Use VPN DNS," "Force DNS through tunnel," "Custom DNS" of "Override system DNS." Schakel hem in. Sommige clients hebben dit standaard aanstaan, andere niet, en sommige hebben de optie überhaupt niet (wat op zich al een probleem is, daarover later meer). Verbind opnieuw na het aanpassen. Voer scutil --dns opnieuw uit en bevestig dat resolver #1 nu de DNS-servers van je VPN toont.
Fix 2: Schakel IPv6 uit als je VPN het niet tunnelt
Toonde Test 3 een IPv6-lek? Dan zijn er twee opties. De schone fix is IPv6 inschakelen binnen je VPN-client (niet alle clients ondersteunen dat). De botte fix is IPv6 uitschakelen op je netwerkinterface.
Zoek eerst de exacte naam van je interface op:
$networksetup -listallnetworkservices
Schakel IPv6 daarop uit (vervang "Wi-Fi" door de daadwerkelijke naam als die anders is):
$networksetup -setv6off "Wi-Fi"
Voer Test 3 opnieuw uit. Het IPv6-adres hoort weg te zijn, of de testpagina hoort te melden dat er geen IPv6-connectiviteit is. Wil je het later weer aanzetten:
$networksetup -setv6automatic "Wi-Fi"
Fix 3: Overschrijf DNS op interface-niveau
Ook met een VPN-client die DNS keurig pusht, vangt het expliciet instellen van DNS op je netwerkadapter de overige randgevallen op. Open Systeeminstellingen > Netwerk. Klik op je actieve interface (Wi-Fi of Ethernet) en vervolgens op Details. Open het tabblad DNS. Voeg 1.1.1.1 en 1.0.0.1 toe (Cloudflare) of 9.9.9.9 en 149.112.112.112 (Quad9). Verwijder bestaande vermeldingen. Klik OK.
Of via Terminal:
$networksetup -setdnsservers "Wi-Fi" 1.1.1.1 1.0.0.1
Dit is dubbele beveiliging. De VPN-tunnel blijft het primaire pad, en macOS weigert nu nog terug te vallen op de DNS van je provider, zelfs als de DNS-push van de VPN om wat voor reden dan ook faalt. Verifieer met scutil --dns.
Fix 4: Schakel iCloud Private Relay uit
Heb je een iCloud+ abonnement, dan is Private Relay mogelijk actief. Het routeert Safari-verkeer en bepaalde systeemqueries via Apple's tweestapsrelay, wat tot DNS-resultaten leidt die niet matchen met wat je VPN verwacht. Uitschakelen: Systeeminstellingen > [Jouw naam] > iCloud > Private Relay > zet de schakelaar uit. Verbind je VPN opnieuw na deze wijziging. Hervoer dnsleaktest om te bevestigen dat de leak weg is.
Fix 5: Voorkom dat browsers hun eigen DNS gebruiken
Chrome en Firefox kunnen op eigen kracht DNS over HTTPS doen, volledig langs de resolver van macOS heen. Lekt jouw DNS alleen tijdens browsen, dan zit hier de oorzaak.
- Chrome: ga naar chrome://settings/security, scroll naar "Use secure DNS" en zet hem op "With your current service provider" of zet hem helemaal uit. Uit betekent dat Chrome de DNS van macOS volgt, en die volgt nu jouw VPN.
- Firefox: open about:preferences#privacy, scroll naar DNS over HTTPS en zet hem op Off. Of zet hem op Max Protection met een resolver die je vertrouwt.
- Safari: respecteert standaard de systeem-DNS. Geen aparte instelling nodig, tenzij Private Relay aanstaat (zie Fix 4).
Fix 6: Leeg de DNS-cache
Na elke wijziging hierboven moet je de cache van macOS legen, anders blijft het systeem oude antwoorden serveren van vóór je fix:
$sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Sluit daarna alle browsertabs die al openstonden vóór de fix, en open de sites opnieuw. Browsers houden hun eigen DNS-cache bij, en de enige betrouwbare manier om die te wissen is de browser herstarten.
Herhaal de tests en bekijk het resultaat
Voer de drie tests uit de vorige sectie nog een keer uit. Bij een geslaagde fix hoort het volgende beeld:
- dnsleaktest Extended toont alleen de resolvers van je VPN-aanbieder, geen provider.
- scutil --dns toont in resolver #1 de DNS-servers van je VPN.
- ipv6-test.com toont geen IPv6-adres, of het IPv6-adres van je VPN.
Slagen alle drie de tests? Dan ben je klaar. Lekt er nog steeds een test, dan ligt het probleem niet meer bij macOS. Dan zit het probleem in de VPN-client zelf.
Wanneer de VPN-client zelf het probleem is
Heb je elke fix in de vorige sectie toegepast en toont Test 1 nog steeds de DNS van je provider, dan dwingt je VPN-client de DNS niet door de tunnel. Dat is een implementatiekeuze van de client, geen tekortkoming van macOS. Veelvoorkomende signalen: er is geen "force DNS" toggle, geen kill switch, geen IPv6-leak protection, en de documentatie van de ontwikkelaar zwijgt over macOS-specifiek gedrag.
Een goed gebouwde macOS-VPN-client doet vier dingen tegelijk. Hij pusht zijn eigen DNS-servers en verifieert dat ze ook daadwerkelijk op systeemniveau actief zijn (de scutil-test uit de diagnose-sectie hoort altijd te slagen zolang de tunnel staat). Hij handelt IPv6 af, óf door het door de tunnel te sturen óf door het netjes te blokkeren zolang er verbinding is. Hij heeft een kill switch die alle niet-VPN-verkeer blokkeert als de tunnel valt, DNS inbegrepen. En hij documenteert zijn gedrag specifiek voor macOS, in plaats van macOS te behandelen als een willekeurig generiek platform.
Verschillende serieuze VPN's doen dit goed. Windscribe's VPN voor Mac bijvoorbeeld dwingt zijn eigen DNS af op systeemniveau zodra de verbinding tot stand komt, biedt een Firewall-modus die fail-closed werkt (zodat DNS-aanvragen niet kunnen ontsnappen wanneer de tunnel wegvalt) en tunnelt IPv6 in plaats van het te laten lekken. Heb je de zes fixes hierboven doorlopen en blijft de leak bestaan, swap dan naar een client die dit werk uit handen neemt en hervoer de drie tests. De diagnose uit de eerdere sectie vertelt je binnen een minuut of de swap het lek gedicht heeft.
De meeste lezers hoeven geen client te wisselen. De macOS-fixes hierboven dichten het lek voor het overgrote deel van de configuraties. De client-swap is de fallback voor wanneer alles aan macOS-zijde slaagt en het lek toch persistent blijft.
FAQ
Waarom toont dnsleaktest mijn provider nog steeds nadat ik mijn DNS-instellingen heb aangepast?
Twee waarschijnlijke oorzaken. Ten eerste cachet je browser DNS-antwoorden van vóór de wijziging. Herstart de browser. Ten tweede cachet macOS zelf antwoorden. Voer het cache-flush commando uit Fix 6 uit. Zijn beide caches leeg en blijft het lek, voer dan scutil --dns uit om te zien wat macOS daadwerkelijk als resolver hanteert. De Terminal-output is betrouwbaarder voor diagnose dan dnsleaktest.
Moet ik IPv6 permanent uitzetten op mijn Mac?
Alleen als je VPN geen IPv6 tunnelt. De schonere oplossing is een VPN die IPv6 wel netjes afhandelt. Schakel je IPv6 toch uit, houd er dan rekening mee dat een klein aantal diensten alleen via IPv6 bereikbaar is (zeldzaam in 2026, maar mogelijk). Heractiveren is één commando: networksetup -setv6automatic "Wi-Fi".
Beschermt iCloud Private Relay mijn DNS net zoals een VPN?
Nee. Private Relay handelt alleen Safari-verkeer en bepaalde systeemqueries af, niet je hele netwerk. Het routeert ook uitsluitend via Apple's relays, niet via een server van jouw keuze. Wil je volledige DNS-bescherming over alle apps, dan heb je een VPN nodig. Beide tegelijk laten draaien is precies wat de conflicten veroorzaakt die in Fix 4 staan.
Ik gebruik een hosts-bestand of een Pi-hole op mijn LAN. Breken de fixes uit deze gids dat?
Ja. Het overschrijven van DNS op adapter-niveau (Fix 3) en de DNS-push van de VPN (Fix 1) routeren om je lokale resolver heen. Vertrouw je op Pi-hole of een hosts-bestand, configureer je VPN dan om je lokale resolver als upstream DNS te gebruiken, of accepteer dat de VPN-tunnel voorrang neemt zolang je verbonden bent.
| Auteur | appletips redactie | |
| Datum | 07/05/2026 14:23 | |
| Categorie | Gevorderden, macOS | |
