Privat DNS kontra VPN: hvad hvert lag egentlig dækker

Din telefon har privat DNS sat til et udbyder-værtsnavn og en VPN-app kørende på samme tid. Det er rimeligt at antage, at en af dem nu styrer navneopslag. Det gør ingen af dem, i den betydning sætningen antyder, og den hurtigste måde at se hvorfor er at følge en enkelt forespørgsel fra det øjeblik, du trykker på et link.

Disse to funktioner sidder på forskellige punkter i samme rejse. Privat DNS krypterer det spørgsmål, du stiller en resolver. En VPN ændrer den rute, som forbindelsen til svaret tager.

Gå det derfor igennem i rækkefølge på en enhed, hvor begge er slået til, og læg mærke til, hvad hvert lag stadig kan se.

Trin et: opslaget forlader appen

Du trykker på et link. Før noget forbinder, har appen brug for en adresse til det værtsnavn. På Android er den relevante skærm Indstillinger, Netværk og internet, Privat DNS. Vælger du udbyder-værtsnavn til privat DNS, sætter det enheden i streng tilstand: den udfører DNS over TLS til det værtsnavn på port 853, og hvis den krypterede udveksling fejler, fejler opslaget i stedet for stille at falde tilbage til klartekst på port 53.

Det er en væsentlig forskel fra Automatisk, som bruger opportunistisk kryptering og gerne bruger en ukrypteret resolver, når netværket blander sig. Hvis dit mål er, at opslag aldrig foregår i klartekst, er streng tilstand med et udbyder-værtsnavn den indstilling, der passer til det.

Her er det første, gennemgangen afslører: opslaget er beskyttet mod det lokale netværk, og resolveren lærer stadig navnet. Kryptering dækker springet. Operatøren af den resolver ser forespørgslen, fordi det er jobbet at besvare den.

Trin to: forbindelsen tager en anden rute

Resolveren returnerer en adresse, og appen forbinder til den. Dette trin påvirkes ikke af, hvordan opslaget blev krypteret. Uden en tunnel forlader forbindelsen din normale offentlige adresse, og destinations-IP'en og TLS-håndtrykket gør normalt værtsnavnet synligt for netværket alligevel, med eller uden krypteret DNS.

Slå VPN'en til, og det er dette trin, der ændrer sig. Trafik, der matcher klientens rutepolitik, går gennem tunnelen, det lokale netværk ser en forbindelse til VPN-endepunktet, og webstedet ser som regel udgangsadressen. Navneopløsning kan også rejse inde i tunnelen, afhængigt af hvad klienten sender med.

Den adskillelse er hele sammenligningen i én sætning. DNS-kryptering svarer på, hvem der kan læse spørgsmålet. En VPN svarer på, hvor samtalen går hen.

Trin tre: inde i tunnelen bliver DNS et spørgsmål om politik

Nu samvirker de to funktioner, og browseren er den sædvanlige kilde til overraskelser. En browser med sin egen indstilling for sikker DNS kan sende opslag til sin valgte resolver over HTTPS i stedet for at spørge styresystemet. Androids indstilling for privat DNS rækker ikke ind i den beslutning.

I Firefox er kontakten under Indstillinger, Privatliv og sikkerhed, Aktivér sikker DNS. I Chrome er den under Indstillinger, Privatliv og sikkerhed, Brug sikker DNS. Begge kan sættes til en bestemt udbyder eller slås fra, og når de er slået til, omgås tunnelens DNS-konfiguration for de opslag, selv om sidetrafikken stadig bruger tunnelen.

Hvis VPN'en sender sin egen resolver, og browseren insisterer på sin egen, får du en opsplitning: navne opløses, sider indlæses, og de opslag, der skulle gennem tunnelen, gik direkte ud. En resolveradresse, der afviger fra VPN-endepunktet, er ikke i sig selv bevis på en lækage, men en opslagsvej, der modsiger din erklærede hensigt, er værd at rette.

Trin fire: interne navne er der, hvor det bryder

Opret forbindelse til en arbejds-VPN og åbn en intranet-vært. Hvis browserens sikre DNS er slået til og peger på en offentlig resolver, findes det navn ikke set fra browseren. Tunnelen er oppe, alt andet virker, og et værtsnavn fejler med en fejl, der ligner, at webstedet er nede.

Den samme fejl vises omvendt på Android. Streng privat DNS med en offentlig udbyder opløser ikke navne, som kun den interne resolver kender, og streng tilstand har ingen tilbagefald. At dele en telefons DNS mellem en offentlig krypteret resolver og en virksomhedsresolver er ikke en indstilling; det er et spørgsmål om rutepolitik, som den, der driver VPN'en, skal svare på.

Tjek dette, før du giver tunnelen skylden: forespørg det interne navn, og derefter det samme navn med browserens sikre DNS slået fra. Hvis det opløses, var resolvervalget problemet, ikke forbindelsen.

Hvad gennemgangen siger, du skal ændre

Fire skærme bærer næsten det hele. Se dem i denne rækkefølge, og skriv ned, hvad hver enkelt siger, for svaret er som regel synligt i kombinationen:

1. Android-indstillinger, Netværk og internet, Privat DNS: Automatisk eller et udbyder-værtsnavn, og hvilket værtsnavn.
2. Browserens indstilling for sikker DNS: slået fra eller låst til en bestemt resolver.
3. VPN-klientens DNS-politik: sender den en resolver, og udelukker delt tunnelling noget, der stadig har brug for navne?
4. En test af et internt værtsnavn med tunnelen oppe, kørt to gange, en gang med browser-DNS slået til og en gang fra.

Tilpas derefter rettelsen til kravet, ikke omvendt. Hvis kravet er, at opslag forlader enheden krypteret og går til en resolver, du har valgt, så sæt streng privat DNS og få browseren til at være enig. Hvis kravet er, at trafikken går ud et andet sted, så konfigurer tunnelen og hold op med at forvente, at en DNS-indstilling flytter din adresse.

Og hold grænserne i syne. Ingen af funktionerne gør en fjendtlig destination sikker, og ingen af dem fjerner en identitet, du er logget ind med. Kryptering ændrer, hvem der kan læse spørgsmålet; tunnelen ændrer, hvor forbindelsen går hen; intet af det anonymiserer kontoen.