DNS-lækagetest: Et resolver-navn er ikke ruten

Tre ordninger tæller som korrekt DNS for en VPN-bruger: forespørgsler til udbyderens resolver, forespørgsler til en krypteret resolver, du selv valgte, og split DNS, der sender arbejdsnavne til organisationen. En lækagetest rapporterer en resolver, og den ene etiket kan ikke fortælle, hvilken ordning du faktisk har. Beslut først den tilsigtede politik, og test derefter imod den. Ellers sammenligner du et tal med en fornemmelse.

Beslut, hvad du ønskede, før du læser resultatet

Navngiv politikken i en sætning: alle navne til VPN-resolveren, alle navne til en valgt krypteret resolver, eller split DNS, hvor interne navne går til organisationen. Hver er forsvarlig for en forskellig bruger, og hver giver et forskelligt forventet svar. Uden den sætning ser ethvert resultat, der afviger fra et skærmbillede i et forumindlæg, alarmerende ud. Skriv politikken ned før den første test.

En test, der udføres, før politikken er defineret, måler intet. Den giver et resolver-navn uden noget referencepunkt.

Et resolver-navn beviser hverken vejen eller modtageren

To spørgsmål er vigtige: hvem modtog forespørgslen, og hvilken rute bar den. En tredjepartsresolver kan nås gennem tunnelen, mens en indstillingsskærm viser udbyderens adresse. Etiketten på en lækagetestside beskriver observatørens syn, ikke din routingtabel.

En browser kan bruge sin egen krypterede DNS, mens webstedsrafik går gennem tunnelen, og cachelagrede svar kan få en side til at indlæse uden et nyt opslag. Derfor siger et offentligt IP-resultat intet om DNS. DoH og DoT beskytter forespørgslen på vejen til resolveren, og den resolver ser stadig navnene.

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

Split DNS gør flere resolvere korrekte

En organisation kan sende interne navne til sin egen DNS og alt andet andre steder hen. En test, der viser flere resolvere, kan derfor beskrive den tilsigtede politik frem for en fejl. Sammenlign det observerede sæt med de dokumenterede split DNS-regler, før du deaktiverer noget. At slukke den interne resolver for at få en testside til at se renere ud ødelægger private navne.

Split tunneling og split DNS er forskellige valg: den ene ruter pakker, den anden ruter spørgsmål. Ændring af en tunnelrute flytter ikke et navneopslag, og ændring af resolveren retter ikke en webstedsrute. IPv6 er et tredje spørgsmål, da en utilsigtet IPv6-forbindelse ikke automatisk er en DNS-lækage.

Gør resultatet til en undersøgelse

Noter den tilsigtede politik og browserens indstilling for sikker DNS før testen. Kør testen med tunnelen aktiv, noter hver resolver, den nævner, og sammenlign sættet med politikken frem for med en forventet adresse.

Gentag efter en genopkobling, hvis symptomet viser sig der, fordi en politik, der anvendes ved forbindelse, kan gå tabt senere. Brug klientens dokumentation til interne DNS-undtagelser i stedet for at gætte på indstillingerne.

Ret den uoverensstemmelse, du fandt: et browservalg, en VPN DNS-indstilling eller en split DNS-regel. Hvis forespørgsler skal stoppe, når tunnelen svigter, er kill switch en separat indstilling, og DNS-konfiguration alene giver den ikke. Specifikationen RFC 8484 er nyttig, når du skal forklare, hvad en krypteret resolver skjuler, og hvad den ikke skjuler.