Smart DNS är inte en VPN: vad den DNS-inställningen egentligen ändrar

Du pekar tv:n mot en Smart DNS-resolver, en streamingapp börjar fungera, och slutsatsen skriver sig själv: det här är en VPN som kostar mindre och installeras snabbare. Det är det inte, och skillnaden är inte petighet. Det som ändrades är svaret tv:n fick när den frågade var ett värdnamn bor; det som inte ändrades är att varje paket fortfarande lämnar ditt hem i klartext, på samma väg, från samma adress som leverantören redan känner till. Myten är att en DNS-inställning är en tunnel. Verkligheten är snävare och mer användbar när du väl ser den.

Myten: en DNS-ändring omdirigerar din trafik

Vanlig DNS berättar för en applikation var den ska ansluta. En Smart DNS-tjänst svarar på utvalda värdnamn med adresser som tillhör leverantörens egen infrastruktur, så appen ansluter dit i stället för direkt till tjänsten. Leverantören vidarebefordrar sedan det enda flödet till den riktiga destinationen. Inget annat på enheten rör sig.

Det är därför tricket överhuvudtaget fungerar på en tv eller en konsol. Det finns ingen klient, inget gränssnitt, ingen post i routingtabellen, inget krypteringslager. Enheten gör precis det den alltid har gjort: löser upp ett namn och ansluter till det som kommer tillbaka. Du ändrade svaret, inte vägen för varje paket.

Etiketten används också av orelaterade DNS-projekt, så kontrollera leverantörens egen dokumentation i stället för att anta en funktionsuppsättning utifrån namnet. Det finns inget standardiserat Smart DNS-protokoll; ett produkts täckning säger ingenting tillförlitligt om en annan.

Vad som faktiskt styrs, och vad som inte gör det

Skillnaden är lätt att se när du listar den per flöde i stället för per enhet.

Du kan se det hända. Fråga leverantörens resolver efter ett värdnamn och fråga en offentlig resolver efter samma:

dig +short @<provider-resolver> example-stream.example
dig +short @1.1.1.1 example-stream.example

Olika svar betyder styrning på namnnivån. Samma svar betyder antingen att tjänsten inte täcker det namnet eller att enheten inte använder den resolvern — ett fel som ser ut som en felaktig DNS-konfiguration och ofta tas för ett trasigt konto.

Det finns ett andra fel med samma lukt. Många leverantörer auktoriserar utifrån den offentliga adress du använder just nu, så kontot fungerar tills adressen ändras. Carrier-grade NAT-rotation, eller en VPN ovanpå, flyttar den adressen och reläet nekar dig, medan uppslagningen fortsätter att lyckas. Registerposten är en åtkomstkontroll, inte bevis på en exklusiv utgång.

Krypterad DNS är något helt tredje

DNS över HTTPS och DNS över TLS skyddar utbytet mellan din enhet och resolvern. De krypterar och autentiserar frågan så att det lokala nätet inte kan läsa eller skriva om den, och DoH bär den i vanlig HTTPS-trafik på port 443, vilket också är anledningen till att den ser ut som webbtrafik för ett filter. Det är en konfidentialitetsfunktion för uppslagningar.

Att styra en tjänst är en annan funktion: själva svaret pekar på en mellanhand. En produkt kan erbjuda båda samtidigt, och många gör det, men det ena innebär inte det andra. Att kryptera dina uppslagningar har aldrig flyttat en enda byte video genom ett annat land.

Så „krypterad DNS“ svarar på en fråga om vem som kan läsa dina frågor. Det svarar inte på vem som kan se din trafik, och det ger dig ingen ny utgångsadress. specifikationen för DNS over HTTPS är den rätta referensen för vad det skyddet täcker, och den säger ingenting om routing.

Vem ser vad i varje uppställning

Med Smart DNS ser resolvern de namn du slår upp, leverantörens relä ser de anslutningar det bär, och din leverantör ser fortfarande allt annat i öppen textstruktur: vilka adresser du kontaktade, när och hur mycket. Innehållet fortsätter att skyddas av TLS till destinationen i det styrda flödet, så reläet vidarebefordrar en krypterad session som det inte kan läsa — men det kan se att du anslöt, varifrån och hur länge.

Med en VPN ser tunneloperatören din trafik och dina destinationer, vilket är ett enda koncentrerat förtroendebeslut, och din leverantör ser bara ett krypterat flöde till en enda slutpunkt. Annan exponering, inte automatiskt mindre. Ingen av modellerna bör bedömas efter om en enda webbplats öppnas.

Hastigheten följer vägen, inte etiketten. Ett selektivt relä kan hålla orelaterad trafik utanför en omväg, vilket är en verklig fördel för en enhet som annars skulle tunna allt. Det är inte heller någon garanti, och ingen uppställning lovar permanent åtkomst till en tjänst som aktivt försöker upptäcka det.

När Smart DNS är rätt verktyg

Det är verkligen rätt verktyg när enheten inte alls kan köra en VPN-klient — en tv, en konsol, en set-top-box med låst nätverksstack — och när bara en namngiven tjänst spelar roll. Det är också rimligt när du medvetet inte vill att varje paket på den enheten ska tunnlas.

Det är fel verktyg när kravet är kryptering, en utgångsadress för hela enheten eller skydd mot det lokala nätet och leverantören. Det är tunnelegenskaper, och ingen resolverinställning skapar dem. Och om du har en VPN igång på samma enhet, räkna med att den registreringsbaserade auktoriseringen bryter ihop, eftersom din offentliga adress nu är tunnelns.

Gå igenom det här beslutet i ordning och stanna vid den första rad som är sann:

• Behöver du trafiken krypterad och hela enheten på en ny utgång? Använd en VPN, och kontrollera dess rutter och undantag, inte dess ansluten-indikator.
• Behöver du bara några få namngivna tjänster på en enhet som inte kan tunnlas? Smart DNS är proportionellt.
• Behöver du privata uppslagningar men inte att flytta trafiken? Det är krypterad DNS, som inte är något av ovanstående.
• Är leverantören beroende av din nuvarande adress? Räkna med avbrott i samma ögonblick som den ändras.