Privat DNS kontra VPN: vad varje lager egentligen täcker

Din telefon har privat DNS inställt på ett värdsnamn från en leverantör och en VPN-app igång samtidigt. Det är rimligt att anta att en av dem nu sköter namnslagen. Ingen av dem gör det, i den mening som meningen antyder, och det snabbaste sättet att se varför är att följa en enda förfrågan från det att du trycker på en länk.

De här två funktionerna sitter på olika punkter i samma resa. Privat DNS krypterar frågan du ställer till en resolver. En VPN ändrar den väg som anslutningen till svaret tar.

Gå igenom det därför i ordning på en enhet där båda är påslagna, och notera vad varje lager fortfarande kan se.

Steg ett: slaget lämnar appen

Du trycker på en länk. Innan något ansluter behöver appen en adress för det värdsnamnet. På Android är den relevanta skärmen Inställningar, Nätverk och internet, Privat DNS. Väljer du Leverantörsvärdsnamn för privat DNS sätts enheten i strikt läge: den gör DNS över TLS till det värdsnamnet på port 853, och om det krypterade utbytet misslyckas misslyckas slaget i stället för att tyst falla tillbaka till klartext på port 53.

Det är en betydande skillnad mot Automatiskt, som använder opportunistisk kryptering och gärna använder en okrypterad resolver när nätverket stör. Om ditt mål är att slag aldrig sker i klartext är strikt läge med ett leverantörsvärdsnamn den inställning som passar.

Här är det första som genomgången avslöjar: slaget är skyddat mot det lokala nätverket, och resolvern får ändå veta namnet. Krypteringen täcker hoppet. Operatören av den resolvern ser förfrågan eftersom det är dess jobb att svara på den.

Steg två: anslutningen tar en annan väg

Resolvern returnerar en adress och appen ansluter till den. Det här steget påverkas inte av hur slaget krypterades. Utan tunnel lämnar anslutningen din vanliga offentliga adress, och mål-IP:n och TLS-handskakningen gör oftast värdsnamnet synligt för nätverket ändå, med eller utan krypterad DNS.

Slå på VPN:en och det är det här steget som ändras. Trafik som matchar klientens routningspolicy går genom tunneln, det lokala nätverket ser en anslutning till VPN-slutpunkten, och webbplatsen ser vanligtvis utgångsadressen. Namnuppslagning kan också färdas inuti tunneln, beroende på vad klienten skickar med.

Den åtskillnaden är hela jämförelsen i en mening. DNS-kryptering svarar på vem som kan läsa frågan. En VPN svarar på vart samtalet tar vägen.

Steg tre: inne i tunneln blir DNS en policyfråga

Nu samspelar de två funktionerna, och webbläsaren är den vanliga källan till överraskningar. En webbläsare med egen inställning för säker DNS kan skicka slag till sin valda resolver över HTTPS i stället för att fråga operativsystemet. Androids inställning för privat DNS når inte in i det beslutet.

I Firefox ligger reglaget under Inställningar, Integritet och säkerhet, Aktivera säker DNS. I Chrome ligger det under Inställningar, Integritet och säkerhet, Använd säker DNS. Båda kan ställas till en viss leverantör eller lämnas avstängda, och när de är på kringgås tunnelns DNS-konfiguration för de slagen även om sidtrafiken fortfarande använder tunneln.

Om VPN:en skickar med sin egen resolver och webbläsaren insisterar på sin egen får du en delning: namn löses upp, sidor laddas, och slagen som skulle gå genom tunneln gick ut direkt. En resolveradress som skiljer sig från VPN-slutpunkten är inte bevis på en läcka i sig, men en slagsväg som motsäger din uttalade avsikt är värd att rätta.

Steg fyra: interna namn är där det brister

Anslut till ett arbets-VPN och öppna en intranätvärd. Om webbläsarens säkra DNS är på och pekar på en offentlig resolver finns det namnet inte för webbläsaren. Tunneln är uppe, allt annat fungerar, och ett värdsnamn misslyckas med ett fel som ser ut som att webbplatsen ligger nere.

Samma fel visas omvänt på Android. Strikt privat DNS med en offentlig leverantör löser inte namn som bara den interna resolvern känner till, och strikt läge har ingen återgång. Att dela en telefons DNS mellan en offentlig krypterad resolver och en företagsresolver är inte en inställning; det är en routningspolicyfråga som måste besvaras av den som driver VPN:en.

Kontrollera det här innan du skyller på tunneln: fråga efter det interna namnet, och sedan samma namn med webbläsarens säkra DNS avstängd. Om det löses upp var resolvervalet problemet, inte anslutningen.

Vad genomgången säger att du ska ändra

Fyra skärmar bär nästan allt. Titta på dem i den här ordningen och skriv ned vad var och en säger, för svaret syns oftast i kombinationen:

1. Android-inställningar, Nätverk och internet, Privat DNS: Automatiskt eller ett leverantörsvärdsnamn, och vilket värdsnamn.
2. Webbläsarens inställning för säker DNS: avstängd eller låst till en viss resolver.
3. VPN-klientens DNS-policy: skickar den med en resolver, och utesluter delad tunnel något som fortfarande behöver namn?
4. Ett test av ett internt värdsnamn med tunneln uppe, kört två gånger, en gång med webbläsarens DNS på och en gång av.

Anpassa sedan åtgärden efter kravet, inte tvärtom. Om kravet är att slag ska gå ut krypterat och till en resolver du valt, ställ in strikt privat DNS och få webbläsaren att hålla med. Om kravet är att trafiken ska gå ut någon annanstans, konfigurera tunneln och sluta förvänta dig att en DNS-inställning flyttar din adress.

Och håll gränserna i sikte. Ingen av funktionerna gör en fientlig destination säker, och ingen tar bort en identitet du loggat in med. Krypteringen ändrar vem som kan läsa frågan; tunneln ändrar vart anslutningen tar vägen; inget av det anonymiserar kontot.