Privat DNS kontra VPN: hva hvert lag egentlig dekker

Telefonen din har privat DNS satt til et vertsnavn fra en leverandør og en VPN-app som kjører samtidig. Det er rimelig å anta at en av dem nå styrer navneoppslagene. Ingen av dem gjør det, i den betydningen setningen antyder, og den raskeste måten å se hvorfor på er å følge én enkelt forespørsel fra det øyeblikket du trykker på en lenke.

Disse to funksjonene sitter på forskjellige punkter i samme reise. Privat DNS krypterer spørsmålet du stiller en resolver. En VPN endrer ruten som forbindelsen til svaret tar.

Gå derfor gjennom det i rekkefølge på en enhet der begge er slått på, og legg merke til hva hvert lag fortsatt kan se.

Trinn én: oppslaget forlater appen

Du trykker på en lenke. Før noe kobler til, trenger appen en adresse for det vertsnavnet. På Android er den relevante skjermen Innstillinger, Nettverk og internett, Privat DNS. Velger du Leverandørens vertsnavn for privat DNS, settes enheten i streng modus: den utfører DNS over TLS til det vertsnavnet på port 853, og hvis den krypterte utvekslingen feiler, feiler oppslaget i stedet for å falle stille tilbake til klartekst på port 53.

Det er en betydelig forskjell fra Automatisk, som bruker opportunistisk kryptering og gjerne bruker en ukryptert resolver når nettverket blander seg inn. Hvis målet ditt er at oppslag aldri skjer i klartekst, er streng modus med et leverandørvertsnavn innstillingen som passer.

Her er det første gjennomgangen avdekker: oppslaget er beskyttet mot det lokale nettverket, og resolveren får likevel vite navnet. Krypteringen dekker hoppet. Operatøren av den resolveren ser forespørselen fordi det er jobben å svare på den.

Trinn to: forbindelsen tar en annen rute

Resolveren returnerer en adresse, og appen kobler til den. Dette trinnet påvirkes ikke av hvordan oppslaget ble kryptert. Uten en tunnel forlater forbindelsen din vanlige offentlige adresse, og mål-IP-en og TLS-håndtrykket gjør vanligvis vertsnavnet synlig for nettverket likevel, med eller uten kryptert DNS.

Slå på VPN-en, og det er dette trinnet som endres. Trafikk som samsvarer med klientens ruteringspolicy, går gjennom tunnelen, det lokale nettverket ser en forbindelse til VPN-endepunktet, og nettstedet ser vanligvis utgangsadressen. Navneoppløsning kan også reise inne i tunnelen, avhengig av hva klienten sender med.

Den separasjonen er hele sammenligningen i én setning. DNS-kryptering svarer på hvem som kan lese spørsmålet. En VPN svarer på hvor samtalen går.

Trinn tre: inne i tunnelen blir DNS et spørsmål om policy

Nå samvirker de to funksjonene, og nettleseren er den vanlige kilden til overraskelser. En nettleser med egen innstilling for sikker DNS kan sende oppslag til sin valgte resolver over HTTPS i stedet for å spørre operativsystemet. Androids innstilling for privat DNS rekker ikke inn i den beslutningen.

I Firefox ligger bryteren under Innstillinger, Personvern og sikkerhet, Aktiver sikker DNS. I Chrome ligger den under Innstillinger, Personvern og sikkerhet, Bruk sikker DNS. Begge kan settes til en bestemt leverandør eller slås av, og når de er på, omgås tunnelens DNS-konfigurasjon for disse oppslagene selv om sidetrafikken fortsatt bruker tunnelen.

Hvis VPN-en sender sin egen resolver og nettleseren insisterer på sin egen, får du en splitting: navn løses, sider lastes, og oppslagene som skulle gå gjennom tunnelen, gikk rett ut. En resolveradresse som avviker fra VPN-endepunktet er ikke bevis på en lekkasje i seg selv, men en oppslagsvei som motsier den uttalte hensikten din, er verdt å rette.

Trinn fire: interne navn er der det bryter

Koble til en jobb-VPN og åpne en intranettvert. Hvis nettleserens sikre DNS er på og peker på en offentlig resolver, finnes ikke det navnet for nettleseren. Tunnelen er oppe, alt annet virker, og ett vertsnavn feiler med en feil som ser ut som at nettstedet er nede.

Den samme feilen vises omvendt på Android. Streng privat DNS med en offentlig leverandør løser ikke navn som bare den interne resolveren kjenner, og streng modus har ingen tilbakefall. Å dele en telefons DNS mellom en offentlig kryptert resolver og en bedriftsresolver er ikke en innstilling; det er et spørsmål om ruteringspolicy som må besvares av den som driver VPN-en.

Sjekk dette før du gir tunnelen skylden: spør etter det interne navnet, og deretter det samme navnet med nettleserens sikre DNS slått av. Hvis det løses, var resolvervalget problemet, ikke forbindelsen.

Hva gjennomgangen sier du skal endre

Fire skjermer bærer nesten alt. Se på dem i denne rekkefølgen og skriv ned hva hver sier, for svaret er vanligvis synlig i kombinasjonen:

1. Android-innstillinger, Nettverk og internett, Privat DNS: Automatisk eller et leverandørvertsnavn, og hvilket vertsnavn.
2. Nettleserens innstilling for sikker DNS: av, eller låst til en bestemt resolver.
3. VPN-klientens DNS-policy: sender den en resolver, og utelukker delt tunnel noe som fortsatt trenger navn?
4. En test av et internt vertsnavn med tunnelen oppe, kjørt to ganger, én gang med nettleser-DNS på og én gang av.

Tilpass deretter rettelsen til kravet, ikke omvendt. Hvis kravet er at oppslag skal gå ut kryptert og til en resolver du har valgt, sett streng privat DNS og få nettleseren til å være enig. Hvis kravet er at trafikken skal gå ut et annet sted, konfigurer tunnelen og slutt å forvente at en DNS-innstilling flytter adressen din.

Og hold grensene i sikte. Ingen av funksjonene gjør en fiendtlig destinasjon trygg, og ingen fjerner en identitet du er logget inn med. Kryptering endrer hvem som kan lese spørsmålet; tunnelen endrer hvor forbindelsen går; ingenting av det anonymiserer kontoen.