DNS-lekktest: Et resolver-navn er ikke ruten

Tre ordninger regnes som riktig DNS for en VPN-bruker: spørringer til operatørens resolver, spørringer til en kryptert resolver du har valgt, og split DNS som sender arbeidsnavn til organisasjonen. En lekktest rapporterer én resolver, og den ene etiketten kan ikke fortelle deg hvilken ordning du faktisk har. Bestem den tiltenkte policyen først, og test deretter mot den. Ellers sammenligner du et tall med en følelse.

Bestem hva du ønsket før du leser resultatet

Navngi policyen i én setning: alle navn til VPN-resolveren, alle navn til en valgt kryptert resolver, eller split DNS med interne navn som går til organisasjonen. Hver er forsvarlig for en annen bruker, og hver gir et annet forventet svar. Uten den setningen virker ethvert resultat som avviker fra et skjermbilde i et foruminnlegg, alarmerende. Skriv ned policyen før den første testen.

En test som utføres før policyen er definert, måler ingenting. Den gir et resolver-navn uten noe referansepunkt.

Et resolver-navn beviser verken ruten eller mottakeren

To spørsmål teller: hvem som mottok spørringen, og hvilken rute som bar den. En tredjepartsresolver kan nås gjennom tunnelen mens en innstillingsskjerm viser leverandørens adresse. Etiketten på en lekktestside beskriver observatørens syn, ikke rutetabellen din.

En nettleser kan bruke sin egen krypterte DNS mens nettstedstrafikken går gjennom tunnelen, og bufrede svar kan la en side lastes uten et nytt oppslag. Derfor sier et offentlig IP-resultat ingenting om DNS. DoH og DoT beskytter spørringen på veien til resolveren, og den resolveren ser fortsatt navnene.

resolvectl status
resolvectl query example.com
dig +short example.com

Split DNS gjør flere resolvere riktige

En organisasjon kan sende interne navn til sin egen DNS og alt annet et annet sted. En test som lister opp flere resolvere kan derfor beskrive den tiltenkte policyen og ikke en feil. Sammenlign settet du observerer, med de dokumenterte split DNS-reglene før du deaktiverer noe. Å slå av den interne resolveren for å få en testside til å se renere ut, bryter private navn.

Split tunneling og split DNS er forskjellige valg: den ene rutet pakker, den andre rutet spørsmål. Å endre en tunnelrute flytter ikke et navneoppslag, og å endre resolveren reparerer ikke en nettbanesti. IPv6 er et tredje spørsmål, siden en utilsiktet IPv6-tilkobling ikke automatisk er en DNS-lekkasje.

Gjør resultatet om til en undersøkelse

Registrer den tiltenkte policyen og nettleserens sikre DNS-innstilling før du tester. Kjør testen med tunnelen aktiv, noter hver resolver den navngir, og sammenlign settet med policyen og ikke med én forventet adresse.

Gjenta etter en gjentilkobling hvis symptomet dukker opp da, fordi en policy som brukes ved tilkobling, kan gå tapt senere. Bruk klientens dokumentasjon for interne DNS-unntak i stedet for å gjette på innstillingene.

Rett opp avviket du fant: et nettleservalg, en VPN-DNS-innstilling eller en split DNS-regel. Hvis spørringer må stoppe når tunnelen svikter, er kill switch en separat innstilling, og DNS-konfigurasjon alene gir den ikke. RFC 8484-spesifikasjonen er nyttig når du må forklare hva en kryptert resolver skjuler og ikke skjuler.