Hoe detecteer je een DNS-lek? 4 stappen voor proxy-DNS

Kernconclusie: als de IP-test slaagt, betekent dat alleen dat het uitgangspunt van je verbinding is gewisseld, niet dat ook je DNS-queries dezelfde route volgen. Proxy en DNS behandelen twee verschillende processen: de proxy bepaalt via welke netwerkuitgang de verbinding vertrekt, terwijl DNS domeinnamen naar IP-adressen vertaalt. Lopen de resolutiequeries via een onverwachte route, dan is er sprake van een DNS-lek. Het opsporen kost vier stappen, en de resultaten begrijpen is belangrijker dan de test zelf draaien.

Je stelt de proxy in, opent een IP-testsite en ziet daar het proxy-IP terug, dus je concludeert dat de netwerkomgeving in orde is. Pas dagen later, bij het uitzoeken van accountproblemen, ontdek je dat de DNS-queries al die tijd via je lokale netwerk liepen.

Het probleem zit misschien niet in de proxy: de DNS ging er nooit langs.

Waarom je DNS moet controleren, ook met proxy aan

Proxy en DNS zijn twee aparte processen; een proxy aanzetten betekent niet dat de DNS ook wordt overgenomen. De proxy bepaalt via welke netwerkuitgang de verbinding verloopt, terwijl DNS de domeinresolutie regelt. Ze raken andere onderdelen van het netwerk, dus een goed werkende proxy garandeert niet dat de DNS-queries verlopen zoals verwacht.

Kijkend naar het verzoek zelf: bij het openen van een site haalt de client ofwel eerst via een DNS-query het IP-adres van de doeldomein op, ofwel draagt de domein over aan de proxyzijde, afhankelijk van het proxyprotocol, de clientimplementatie en de DNS-instellingen van de browser. Met een proxy aan lopen niet automatisch alle resolutiequeries via de verwachte route; dat beoordeel je met een echte test, niet op het 'verbonden'-lampje van de proxy.

Ook een onderscheid dat je moet maken: een DNS-lek is niet hetzelfde als blootstelling van je echte publieke IP. Wat lekt, is de route van domeinquery's, waardoor de resolutiedienst of het lokale netwerk kan zien welke domeinen je opzoekt. Of je echte IP verborgen blijft, bevestig je met een aparte IP-test. De Cyber Security Agency of Singapore behandelt in haar VPN-adviezen de DNS-lektest en de IP-adrestest als twee onafhankelijke controles, precies omdat ze iets anders verifiëren (zie de VPN-richtlijnen van de CSA).

Hoe een DNS-lek meestal ontstaat

Drie bronnen komen het vaakst voor, en ze zitten allemaal in de configuratie, niet in een defecte proxy. Ze één voor één.

De proxy behandelt alleen een deel van het verkeer

Sommige proxy-instellingen nemen alleen de webverzoeken van de browser over, terwijl de resolutie door het lokale systeem blijft lopen, afhankelijk van het proxyprotocol en hoe de client het afhandelt. Lopen de webverzoeken via de proxy maar de resolutiequeries lokaal, dan verschijnt de resolver van het lokale netwerk in de testresultaten.

De browser heeft eigen beveiligde DNS aan staan

Chrome en Firefox ondersteunen DNS over HTTPS (DoH). Staat het aan, dan gaan resolutiequeries via een versleutelde HTTPS-verbinding naar een aangewezen resolutiedienst, wat de kans verkleint dat het lokale netwerk de query's direct ziet. Versleuteling betekent echter niet dat de query's via de proxy lopen, noch dat de gekozen resolutiedienst past bij de huidige omgeving. Deze Firefox-functie laat zich apart aan- en uitzetten; zie de officiële Mozilladocumentatie.

Systeem, browser en proxyclient hebben elk hun eigen

De meest verraderlijke variant. Het systeem gebruikt één resolver, de browser zet met DoH een tweede in en de proxyclient nog een derde; stapel je die op elkaar, dan wordt de resolutieroute een zwarte doos. Uit alleen 'verbonden' in de proxysoftware valt niets af te leiden; je moet zien welke route de draaiende browser echt neemt.

Belandt de resolutieroute bij de lokale ISP, dan lopen de query's via de resolutiedienst van die ISP; ter vergelijking kun je de werking en toepassingen van een ISP-proxy raadplegen.

Hoe detecteer je een DNS-lek? Vier stappen

De test zelf is niet ingewikkeld; het gaat erom dat je vooraf een verwachting hebt en achteraf vergelijkt. Pas na die vier stappen sta je stevig.

Stap 1: Schrijf eerst het verwachte resultaat op. Leg voor de test drie dingen vast: in welke regio het uitgangspunt van de huidige proxy zit, wie de domeinresolutie zou moeten overnemen en of de browser DoH aan heeft staan. Zonder verwachting kun je ook niets met de resultaten.

Stap 2: Draai de test met de proxy aan. Gebruik een site met DNS-lekdetectie, zoals dnsleaktest.com, en klik op de uitgebreide test (Extended test) zodat de pagina meer resolvers toont; je kunt ook de DNS-testpagina van BrowserLeaks gebruiken om te zien bij welke organisatie de resolvers horen. Noteer de namen van de resolvers, de organisaties en de regio's.

Stap 3: Leg de resultaten naast je verwachting. Controleer of de resolvers in de resultaten passen bij de configuratie van je huidige systeem, browser en proxy. Horen de resolvers bij de verwachte DNS-dienst en is er geen onverwachte lokale resolutieroute, dan mag je de test voorlopig conform verwachting noemen. Duikt er een lokale ISP of een onbekende resolutiedienst op, stel dan eerst vast of dat echt buiten de bedoelde configuratie valt, en ga daarna punt voor punt na: de DNS-afhandeling in de proxyclient, de beveiligde DNS van de browser en de netwerkinstellingen van het systeem; roep niet meteen dat de proxy het begeeft. Eén test weerspiegelt alleen de omstandigheden op dat moment en garandeert niet dat elk verzoek in orde is.

Stap 4: Verander één instelling en test opnieuw. Wil je bijstellen, doe dan per keer één ding: de DNS-afhandeling in de proxyclient, de DoH-schakelaar van de browser of de netwerkinstellingen van het systeem, en test en vergelijk daarna opnieuw. Pas je meerdere dingen tegelijk aan, dan weet je niet wat welk effect had.

Hoe lees je de testresultaten

Dezelfde resultaten zijn bij de juiste lezing een aanwijzing en bij de verkeerde een misvatting. Zo pak je de vijf meest voorkomende uitkomsten aan:

Valkuil: Anycast; de resolverlocatie is niet per se het echte uitgang.

Wat is het verschil tussen DNS-lek, WebRTC-lek en browserfingerprint

Vier controles kijken naar vier verschillende soorten informatie; eentje halen betekent niet dat de rest ook slaagt. Zet ze naast elkaar en de grenzen worden het duidelijkst:

DNS en WebRTC worden het makkelijkst door elkaar gehaald, omdat allebei het woord 'lek' dragen. Hun werkwijze en aanpak liggen volledig uit elkaar; het opsporen en instellen van een WebRTC-lek is al apart besproken, dus daar gaan we hier niet op in. De IPv6-lek is bovendien een ander familielid: die checkt of IPv6-adressen de proxy omzeilen; de methode staat in de gids voor IPv6-lekdetectie.

Die vier controles tonen telkens andere informatie en vullen elkaar niet af. Bij het uitzoeken van een proxyomgeving kun je het beste eerst het publieke IP bevestigen, daarna DNS en WebRTC checken en ten slotte fingerprint en omgevingsconfiguratie nalopen; welke tests je precies doet, hangt af van je scenario.

Hoe deze controles in je MostMate-werkwijze passen

Het advies voor de volgorde: eerst de uitgang, dan de resolutie, dan WebRTC en tot slot de omgevingsconfiguratie. Beheer je meerdere browseromgevingen met MostMate, dan kun je de proxy-connectiviteitstest en de DNS-lektest beter los van elkaar uitvoeren.

Eerst komt de proxyconfiguratie. Nadat je de proxy aan de omgeving hebt gekoppeld, controleer je met de proxytest in het product de verbindingsstatus en check je meteen het protocoltype (HTTP, HTTPS, SOCKS5, SSH) en de authenticatiegegevens. Let op: een geslaagde proxytest vervangt de DNS-lektest niet, want de echte route van de DNS-queries hangt nog steeds af van de configuratie van proxyclient, browser en systeem.

Open daarna in de omgevingen die aan die proxy hangen de DNS-testpagina, doorloop weer de vier stappen van hierboven en kijk of de herkomst van de resolvers aan je verwachting voldoet.

Het tweede punt is de isolatie van de omgeving zelf. Bij meerdere accounts horen proxy, cookies en fingerprintparameters van elke omgeving onafhankelijk te zijn en niet geleend; de precieze reikwijdte staat in de reikwijdte en configuratie van browseromgevingsisolatie. Heeft een omgeving de verkeerde proxy of deelt hij configuratie, dan verliezen de testresultaten hun vergelijkingswaarde. Isolatie helpt bij het beheren van sessies en configuraties, maar maakt de DNS-route niet automatisch juist en vervangt geen externe test.

Het derde punt is de grens bewaken: de fingerprint-browser houdt de omgeving overzichtelijk, maar of de proxy werkt en of de DNS de verwachte route neemt, verifieer je nog steeds met een externe test. Ook een geslaagde test geldt niet voor altijd; herhaal hem na een configuratiewijziging of systeemupdate.

Veelgestelde vragen

Mijn proxy staat aan, maar de DNS-test toont een lokale resolver. Betekent dat dat de proxy het begeeft?

Niet per se. Misschien neemt de proxy alleen de webverzoeken over en verwerkt het systeem of de browser de resolutie afzonderlijk. Loop de DNS-afhandeling in de proxyclient en de DoH-instellingen van de browser na, en test telkens na één wijziging.

Legt een DNS-lek mijn echte IP bloot?

Dat valt niet gelijk te stellen. Een DNS-lek laat de route van domeinresolutieverzoeken zien; wat er precies blootkomt, hangt af van je netwerkconfiguratie en het testscenario. Of je echte publieke IP verborgen blijft, bevestig je met een aparte IP-test; de resolutieroute controleer je los daarvan.

Kan er ook met een fingerprint-browser een DNS-lek ontstaan?

Ja, dat kan. Een fingerprint-browser beheert omgevingsisolatie en fingerprintparameters, terwijl het DNS-gedrag afhangt van het proxyprotocol en de configuratie van systeem en browser — de test kun je dus niet overslaan.

Wat moet ik nog meer controleren als de DNS-test slaagt?

Er blijven twee punten over: het WebRTC-lek en de browserfingerprint, elk te verifiëren met het eigen gereedschap. Pas als alles slaagt, is de netwerklaag van die omgeving volledig gecontroleerd.

Tot slot

De waarde van een DNS-lektest zit niet in een 'geslaagd' of 'mislukt', maar in de bevestiging dat de netwerkverzoeken van je huidige omgeving verlopen zoals verwacht. Publiek IP, DNS, WebRTC en browserfingerprint hebben elk hun eigen controlemethode, en de uitkomst van de ene test vervangt de verificatie van de anderen niet. Welke fingerprint-browser je ook gebruikt, herhaal de test na elke wijziging in proxy- of netwerkconfiguratie.

Wil je meerdere browseromgevingen beheren, maak je dan eerst vertrouwd met de omgevingsconfiguratie en het proxybeheer van MostMate en verifieer daarna alles stap voor stap volgens dit artikel; wil je de proxy-laag steviger inrichten, dan kun je MostMate downloaden — de gratis versie heeft twee omgevingen, dus loop eerst de volledige testprocedure door voor je eerste omgeving.