Hva er en DNS-lekkasje — og hvordan tester du for det

Kortversjonen: en VPN-tunnel krypterer IP-pakkene enheten din sender til andre servere. DNS er oppslaget som skjer før pakken sendes — enheten din spør «hvilken IP-adresse tilhører example.com?» Hvis det oppslaget går til ISP-ens løser i stedet for gjennom VPN-en, ser ISP-en domenet selv om den aldri ser den krypterte trafikken som følger etter. Det er en lekkasje. Den undergraver det viktigste personvernløftet til en VPN av den enklest mulige grunnen: feil DNS-løser ble spurt. Den gode nyheten er at lekkasjer er enkle å oppdage, vanligvis enkle å fikse, og de fleste VPN-apper som er riktig bygd forhindrer dem som standard. Den dårlige nyheten er at «de fleste» ikke er «alle», og en håndfull vanlige konfigurasjoner forårsaker lekkasjer selv på ellers korrekte VPN-oppsett.

Hva DNS faktisk gjør og hvorfor det lekker

DNS — Domain Name System — er internettets adressebok. Hver gang enheten din kobler til et nettsted, må den først oversette det menneskevennlige vertsnavnet (example.com) til en numerisk IP-adresse (noe som 93.184.216.34) som rutere faktisk kan videresende pakker til. Det oversettingstrinnet er en DNS-spørring, og det er en separat nettverksoperasjon fra den faktiske nettforespørselen som følger etter.

På en typisk hjemforbindelse tildeles DNS-løseren din av ISP-en via DHCP — samme mekanisme som deler ut IP-adressen din. Når du kobler til Wi-Fi, forteller ruteren enheten din «DNS-serveren din er 192.168.1.1, som videresender til ISP-ens rekursive løser». Hvert domene du slår opp, går gjennom den løseren. ISP-en kan logge det, selge det til en datamegler (i USA er dette lovlig), eller utlevere det til politiet.

Når du kobler til en VPN, bør to ting skje. Først krypteres nettverkstrafikken din og rutes gjennom VPN-tunnelen. Deretter bør DNS-løseren din endre seg — fra ISP-ens løser til en som drives av VPN-leverandøren (eller en tredjeparts personvernfokusert løser), nåbar kun gjennom den krypterte tunnelen. Hvis bare den første halvdelen skjer, har du en DNS-lekkasje. Trafikken er kryptert, men oppslagene som foregikk trafikken, flyter fortsatt til ISP-en og forteller dem hvert nettsted du er i ferd med å besøke.

Fra et personvernperspektiv er DNS-spørringen nesten like avslørende som selve trafikken. Spørringen avslører det nøyaktige domenet (ned til underdomene — mail.example.com kan skilles fra www.example.com) og tidspunktet. Kombinert med den krypterte trafikkvolumet umiddelbart etterpå gir en VPN med DNS-lekkasje en observatør nok metadata til å rekonstruere nettleserøkten din på nesten enhver meningsfull måte.

De fire måtene en DNS-lekkasje skjer på

DNS-lekkasjer er ikke én enkelt feil. De er en familie av relaterte feilkonfigurasjoner, hver med en annen grunnårsak og en annen løsning. I omtrentlig hyppighetsrekkefølge:

1. OS-omgåelse — Windows split DNS / Smart Multi-Homed Name Resolution

Windows har en funksjon kalt Smart Multi-Homed Name Resolution som, når den er aktivert, sender DNS-spørringer parallelt til alle tilgjengelige DNS-løsere — inkludert ISP-ens løser på det fysiske grensesnittet, selv når en VPN er aktiv. Den løseren som svarer raskest vinner, og de andre ignoreres, men selve spørringene er allerede sendt. På de fleste Windows-maskiner er dette aktivert som standard. Løsningen er å deaktivere funksjonen via Gruppepolicy eller ved å konfigurere VPN-klienten til å gjøre det ved tilkobling. Linux har et lignende problem med systemd-resolved hvis det ikke er konfigurert riktig; macOS og iOS håndterer dette bedre, men ikke perfekt.

2. Feilkonfigurasjon av split tunneling

Split tunneling lar deg rute noen apper gjennom VPN-en og andre gjennom den vanlige tilkoblingen. En vanlig konfigurasjonsfeil er å sette opp appbasert split tunneling uten også å konfigurere per-app DNS — noe som betyr at en app som rutes utenfor VPN-tunnelen fortsatt forsøker å bruke VPN-ens DNS-løser, eller omvendt, og ender med å lekke gjennom den stien OS-et gir. En verre variant: split-tunnelen ruter appens TCP-trafikk korrekt utenfor tunnelen, men den systemdekkende DNS-løseren er fortsatt ISP-ens løser, så alle apper — tunnelert eller ikke — lekker DNS-spørringene sine til ISP-en. Vi dekker det bredere temaet i vår gjennomgang av hva split tunneling faktisk gjør.

3. IPv6-tilbakefall

Mange VPN-klienter ble designet da IPv4 var det eneste rutinghensynet. De installerer IPv4-brannmur- og rutingregler som korrekt ruter DNS gjennom tunnelen, men de installerer ikke tilsvarende IPv6-regler. Hvis nettverket ditt har IPv6-tilkobling, vil OS-et noen ganger foretrekke IPv6 for DNS-spørringer — og disse spørringene flyter ut det nakne grensesnittet, og omgår VPN-en fullstendig. Dette er en av de vanligste lekkasjemodusene i 2026, og det er spesielt vanlig på private bredbåndsforbindelser som har dual-stack IPv4/IPv6 fra ISP-en. Løsningen er enten å deaktivere IPv6 globalt (tungvint, men pålitelig), eller å bruke en VPN-klient som eksplisitt håndterer IPv6-ruter.

4. WebRTC og nettleseroppløst DNS

Moderne nettlesere — Chrome, Edge, Firefox, Safari — kan utføre DNS-oppslag selv i stedet for å bruke OS-løseren. Det mest beryktede tilfellet er WebRTC, peer-to-peer-protokollen som brukes av videosamtaler. WebRTC bruker STUN-servere for å oppdage de virkelige lokale og offentlige IP-adressene dine, og historisk sett ville det kringkaste begge selv når en VPN var aktiv. Den «ekte» IP-en fra WebRTC har vært en langvarig lekkasje på nettlesersiden som krever eksplisitt tiltak. Separat kan nettlesere som bruker DNS-over-HTTPS (DoH) rute DNS-spørringer direkte til Cloudflare, Google eller NextDNS uavhengig av OS-løserinnstillingen — noe som noen ganger hjelper (DoH til offentlig løser er mer privat enn klartekst til ISP) og noen ganger skader (den offentlige løseren ser fortsatt spørringene dine, og nettleseren omgår VPN-ens DNS-regler).

Slik tester du for en DNS-lekkasje på under ett minutt

Å teste for en DNS-lekkasje tar lengre tid å beskrive enn å gjøre. Koble til VPN-en din, og besøk deretter ett av disse tre verktøyene. De avslører alle litt forskjellige aspekter av lekkasjeflaten.

dnsleaktest.com

Den klassiske. Besøk dnsleaktest.com, klikk «Extended test», og vent omtrent 20 sekunder. Verktøyet sender en serie DNS-spørringer for unike vertsnavn det kontrollerer, og viser deg deretter hvilke løsere som faktisk utførte disse oppslagene. Hvis du ser ISP-ens navn (Comcast, Verizon, BT osv.) i løserlisten, lekker du. Hvis du bare ser VPN-leverandørens løser (eller en personvernfokusert offentlig løser som Quad9 eller Cloudflares 1.1.1.1), er DNS-stien i OS korrekt.

browserleaks.com/dns

Mer detaljert enn dnsleaktest. Den viser deg ikke bare hvilke løsere som håndterte spørringen, men også deres geografiske plassering, ASN (nettverksoperatøren) og om de støtter DNS-over-HTTPS eller DNS-over-TLS. Nyttig for å fange subtile lekkasjer der riktig type løser brukes, men den er i feil land, eller for å bekrefte at en kryptert DNS-protokoll faktisk er i bruk.

ipleak.net

Den mest omfattende — den tester DNS-lekkasjer, WebRTC-lekkasjer, IPv4- og IPv6-synlighet, og viser hva geolokasjonen din ser ut til å være. WebRTC-seksjonen er kritisk: hvis du ser en «lokal IP»-adresse i området 192.168.x.x eller 10.x.x.x eksponert ved siden av en «offentlig IP» som samsvarer med VPN-endepunktet ditt, gjør VPN-en jobben sin, men nettleseren din lekker via WebRTC. IPv6-seksjonen fanger IPv6-tilbakefallslekkasjer som dnsleaktest noen ganger går glipp av.

Hvordan et rent resultat ser ut kontra et lekket

På dnsleaktest.coms utvidede test med en korrekt konfigurert VPN bør du se noe slikt:

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.

Og slik ser en lekkasje ut:

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.

Det viktigste signalet er ISP-kolonnen. Hvis noe annet enn VPN-leverandøren din (eller en bevisst valgt offentlig løser) vises, lekker DNS-en din. Hvis landskolonnen viser det virkelige landet ditt ved siden av VPN-utgangslandets, lekker du. Hvis bare VPN-endepunktlandets vises, er du ren.

Lekkasjetyper sammenlignet

Hver av de fire lekkasjetypene har et tydelig fingeravtrykk i testresultatene, et tydelig sett av observatører som kan utnytte det, og en tydelig løsning:

Fikse de fire vanlige årsakene

Fikse OS-omgåelseslekkasjer (Windows)

På Windows 10 og 11, deaktiver Smart Multi-Homed Name Resolution enten via Gruppepolicy (Datamaskinkonfigurasjon → Administrative maler → Nettverk → DNS-klient → «Slå av smart multi-homed navneoppløsning» → Aktivert) eller via PowerShell: Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" -Name "DisableParallelAandAAAA" -Value 1. Start på nytt. Noen godt vedlikeholdte VPN-klienter gjør dette automatisk ved tilkobling — hvis din ikke gjør det, gjør det manuelt.

Fikse split-tunnel-lekkasjer

Gå gjennom split-tunnel-regelsettet ditt. For enhver app som skal beskyttes, verifiser at både TCP-trafikken og DNS-spørringene rutes gjennom tunnelen. Noen VPN-klienter lar deg konfigurere per-app DNS; de fleste gjør det ikke. Hvis din ikke gjør det, er det tryggere standardvalget å deaktivere split tunneling helt og bruke en full tunnel — som ruter alt (inkludert all DNS) gjennom VPN-en. For de fleste brukere er bekvemmelighetsfordelen ved split tunneling ikke verdt lekkasjerisikoen.

Fikse IPv6-lekkasjer

Den mest pålitelige løsningen er å bruke en VPN-klient som støtter IPv6 inne i tunnelen (eller som minimum installerer tilsvarende IPv6-brannmurregler som blokkerer IPv6-trafikk når tunnelen er oppe). Hvis du ikke kan bytte klient, deaktiver IPv6 på det fysiske nettverksgrensesnittet: på Windows, i adapteregenskapene; på macOS, i Systeminnstillinger → Nettverk → Avansert → TCP/IP. Dette er tungvint (du mister IPv6-tilkobling fullstendig), men det eliminerer lekkasjevektoren.

Fikse WebRTC-lekkasjer

I Firefox, sett media.peerconnection.enabled til false i about:config. I Chrome og Edge, installer en utvidelse som WebRTC Network Limiter eller uBlock Origins WebRTC-blokkeringsalternativ. Safari håndterer WebRTC mer konservativt som standard, men du kan fortsatt lekke lokale IP-er i noen konfigurasjoner; Safari 17+ forbedret dette betydelig. Test etter endringen med ipleak.net.

Hvorfor «bruk en VPN» alene ikke garanterer ingen lekkasjer

Det er en vanlig antagelse at å koble til en VPN automatisk forhindrer DNS-lekkasjer. Det gjør det ikke — forebyggingen avhenger av at VPN-klienten gjør en rekke ting korrekt: endre system-DNS-løseren, installere brannmurregler for å blokkere direkte-til-ISP DNS, håndtere IPv6, deaktivere Windows SMHNR (eller tilsvarende OS-nivå omgåelsesfunksjoner), og overleve nettverksendringer (Wi-Fi-roaming, søvn/vekk-sykluser) uten å gjeninnføre lekkasjen.

En godt bygd VPN-klient gjør alt dette automatisk, og du trenger aldri å tenke på det. En dårlig bygd en — eller en «gratis» VPN som bruker OS-ets innebygde VPN-profil uten ekstra lekkasjesbeskyttelse — gjør en delmengde av dette, og lar lekkasjevektorer stå åpne. Den eneste måten å vite hvilken kategori du er i, er å faktisk kjøre en lekkasjetest etter tilkobling. Hvis testen kommer tilbake ren, kan du slutte å bekymre deg for det; hvis den viser lekkasjer, har du spesifikke problemer å fikse, og du vet nå hvilke.

DNS-lekkasjeforebygging på iOS, Android, Mac og Windows

iOS

iOS håndterer DNS gjennom NetworkExtension-rammeverket. En riktig bygd VPN-app bruker NEDNSSettings-objektet for å spesifisere en egendefinert løser som brukes mens tunnelen er aktiv. iOS håndhever dette på OS-nivå — apper kan ikke omgå den konfigurerte DNS uten eksplisitt tillatelse. Den viktigste lekkasjevektoren på iOS er iCloud Private Relay, som (når den er aktivert ved siden av en VPN) kan rute DNS gjennom Apples løser i stedet for VPN-ens. Hvis du bruker en VPN for personvern, deaktiver iCloud Private Relay for å forhindre at de to kommer i konflikt. iOS 14 la til includeAllNetworks-flagget (ofte brukt sammen med kill-switch-atferd) som sikrer at selv DNS på systemnivå går gjennom tunnelen.

Android

Androids VpnService API lar VPN-klienten spesifisere DNS-servere som gjelder for all tunnelert trafikk. «Always-on VPN»-systeminnstillingen med «Block connections without VPN» aktivert gir den sterkeste garantien — ingen app kan løse DNS uten at tunnelen er aktiv. Android støtter også system-dekkende privat DNS (Innstillinger → Nettverk og internett → Privat DNS), som tvinger all DNS til å bruke DNS-over-TLS til en valgt leverandør. Å kombinere Always-on VPN med privat DNS gir belte-og-bukseseler-beskyttelse mot DNS-lekkasjer.

macOS

macOS bruker scutil og System Configuration-rammeverket for å administrere DNS-innstillinger. En VPN-klient som kjører gjennom NetworkExtension-rammeverket kan installere DNS-innstillinger som tar forrang mens tunnelen er aktiv. Den viktigste lekkasjevektoren på macOS er DNS-over-HTTPS på nettlesernivå, som omgår systemløseren fullstendig — deaktiver DoH på nettlesernivå eller konfigurer den til å peke på samme løser som VPN-en. Test med scutil --dns i Terminal for å se de aktive løserne; bare VPN-ens løser bør vises i den høyest prioriterte seksjonen.

Windows

Windows har den største lekkasjeflaten av alle større OS-er, primært på grunn av Smart Multi-Homed Name Resolution. Utover å deaktivere SMHNR (dekket ovenfor), sjekk at VPN-ens virtuelle adapter har høyere metrisk prioritet enn den fysiske adapteren din, at IPv6 enten er deaktivert eller korrekt tunnelert, og at ingen app er konfigurert med egne DNS-overstyringer. Windows 11 la til forbedret DNS-innstillingsgrensesnitt, men den underliggende atferden ligner på Windows 10. Kommandoen ipconfig /all viser de aktive løserne per grensesnitt.

Hva gode VPN-apper gjør bak kulissene for å forhindre lekkasjer

En godt konstruert VPN-klient ber deg ikke tenke på DNS-lekkasjer. Den håndterer dem som en grunnleggende del av tilkoblingsprosessen. Nærmere bestemt:

• Konfigurerer en egendefinert løser ved tilkobling. Klienten forteller OS-et «mens jeg er tilkoblet, går alle DNS-spørringer til denne spesifikke IP-adressen» — vanligvis VPN-leverandørens egen løser, nåbar bare gjennom tunnelen. Klienten gjenoppretter også de tidligere DNS-innstillingene ved frakobling.
• Installerer brannmurregler for å blokkere direkte DNS. Selv om en app forsøker å spørre en DNS-server på egen hånd (f.eks. en hardkodet spørring til 8.8.8.8), blokkerer brannmurregelen den utgående pakken på UDP port 53. Den eneste DNS-en som kan forlate enheten er det som flyter gjennom tunnelen.
• Bruker kryptert DNS (DoT eller DoH) inne i tunnelen. Selv etter at spørringen er inne i tunnelen, er løser-til-server-hoppet kryptert med DNS-over-TLS (RFC 7858) eller DNS-over-HTTPS slik at den overordnede operatøren ikke kan se spørringsinnholdet. Vår gjennomgang av DNS-over-HTTPS vs DNS-over-TLS dekker avveiningene mellom de to protokollene.
• Håndterer IPv6 eksplisitt. IPv6-ruter enten tunneleres gjennom VPN-en (foretrukket) eller blokkeres i brannmuren for å forhindre IPv6-tilbakefall. Klienten lar aldri IPv6-routing være ukonfigurert.
• Kombineres med en kill switch. Hvis tunnelen faller midlertidig, blokkerer kill switchen all trafikk — inkludert DNS — til tunnelen er gjenopprettet. Dette forhindrer «tunnel falt, DNS lekket, tunnel kom tilbake»-kappløpet. Vi dekker dette i detalj i hva er en VPN kill switch.
• Tester ved hver tilkobling. Noen klienter kjører en innebygd lekkasjetest etter hver tilkobling og varsler brukeren om avvik. Dette er sjeldent, men det er den sterkest mulige modellen.

Casper's Cloak bruker en egendefinert DNS-løser som kun er nåbar inne i WireGuard-tunnelen, kryptert ende-til-ende via DNS-over-TLS, med IPv6-ruter eksplisitt tunnelert og Windows SMHNR deaktivert ved installasjon. Trusselbeskyttelsesfunksjonen utfører DNS-nivåfiltrering mot kjente ondsinnede domener ved samme løser, slik at den samme DNS-en som er lekkasjebeskytte, også aktivt blokkerer phishing og skadevare. Mekanismen er dokumentert i vår gjennomgang av hvordan DNS-nivåfiltrering faktisk fungerer. Den kombinerte effekten: korrekt konfigurert som standard, ingen lekkasjer under noen av de fire vanlige feilmodusene, og aktiv filtrering på toppen.

For bakgrunnsinformasjon om den underliggende protokollen er IETF-spesifikasjonen for DNS-over-TLS dokumentert i RFC 7858, som dekker de kryptografiske og transportlagkravene for å sende DNS over en TLS-sikret kanal. Det samme rammeverket er det personvernfokuserte offentlige løsere (Cloudflare, Quad9, NextDNS) bruker for sine sikre DNS-endepunkter.

Kortversjon: en DNS-lekkasje er den vanligste måten en VPN-s personvernløfte stille svikter på. Det er enkelt å teste for, vanligvis enkelt å fikse, og enhver VPN du stoler på, bør bestå en lekkasjetest uten manuell inngripen. Hvis din VPN ikke gjør det, er det et signal — enten feilkonfigurert, eller gå videre.