Smart DNS no és una VPN: què canvia realment aquest paràmetre de DNS

Punteu el televisor a un resolutor de Smart DNS, una aplicació d'streaming comença a funcionar i la conclusió s'escriu sola: això és una VPN que costa menys i s'instal·la més de pressa. No ho és, i la diferència no és una subtilesa. El que va canviar és la resposta que va rebre el televisor quan va preguntar on viu un nom d'amfitrió; el que no va canviar és que cada paquet continua sortint de casa vostra a la vista, pel mateix camí, des de la mateixa adreça que el proveïdor ja coneix. El mite és que un paràmetre de DNS és un túnel. La realitat és més estreta i més útil quan la veieu.

El mite: un canvi de DNS redirigeix el vostre trànsit

El DNS ordinari diu a una aplicació on connectar-se. Un servei de Smart DNS respon a noms d'amfitrió seleccionats amb adreces que pertanyen a la infraestructura del propi proveïdor, de manera que l'aplicació es connecta allà en lloc del servei directament. Després el proveïdor retransmet aquest únic flux a la destinació real. Res més del dispositiu no es mou.

Per això el truc funciona en un televisor o una consola. No hi ha client, ni interfície, ni entrada a la taula d'encaminament, ni capa de xifratge. El dispositiu fa exactament el que sempre ha fet: resoldre un nom i connectar-se al que torni. Heu canviat la resposta, no el camí de cada paquet.

L'etiqueta també l'utilitzen projectes de DNS no relacionats, així que consulteu la documentació del proveïdor en lloc de suposar un conjunt de funcions a partir del nom. No hi ha cap protocol Smart DNS estàndard; la cobertura d'un producte no diu res fiable sobre un altre.

Què es dirigeix realment i què no

La distinció és fàcil de veure quan la lliste per flux en lloc de per dispositiu.

Ho podeu veure passar. Demaneu al resolutor del proveïdor un nom d'amfitrió i demaneu el mateix a un resolutor públic:

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

Respostes diferents volen dir direcció a la capa de nom. La mateixa resposta vol dir o bé que el servei no cobreix aquell nom o bé que el dispositiu no fa servir aquell resolutor — una fallada que sembla una mala configuració de DNS i sovint es confon amb un compte espatllat.

Hi ha una segona fallada amb la mateixa olor. Molts proveïdors autoritzen per l'adreça pública que feu servir ara, així que el compte funciona fins que l'adreça canvia. La rotació de NAT de grau operador, o una VPN al damunt, mou aquesta adreça i el repetidor us refusa, mentre la resolució continua tenint èxit. L'entrada al registre és un control d'accés, no una prova d'una sortida exclusiva.

El DNS xifrat és una tercera cosa del tot

DNS sobre HTTPS i DNS sobre TLS protegeixen l'intercanvi entre el vostre dispositiu i el resolutor. Xifren i autentiquen la consulta perquè la xarxa local no la pugui llegir ni reescriure, i DoH la porta en trànsit HTTPS ordinari al port 443, cosa que també explica per què sembla trànsit web a un filtre. És una característica de confidencialitat per a les consultes.

Dirigir un servei és una funció diferent: la mateixa resposta apunta a un intermediari. Un producte pot oferir les dues coses alhora, i molts ho fan, però una no implica l'altra. Xifrar les consultes no ha mogut mai ni un byte de vídeo per un altre país.

Així, «DNS xifrat» respon una pregunta sobre qui pot llegir les vostres consultes. No respon qui pot veure el vostre trànsit, i no us dona una adreça de sortida nova. La especificació de DNS over HTTPS és la referència correcta per al que cobreix aquesta protecció, i no diu res sobre l'encaminament.

Qui veu què en cada disposició

Amb Smart DNS, el resolutor veu els noms que consulteu, el repetidor del proveïdor veu les connexions que transporta, i el vostre proveïdor d'internet encara veu tota la resta en estructura de text obert: a quines adreces us heu connectat, quan i quant. El contingut continua protegit per TLS fins a la destinació en el flux dirigit, així que el repetidor reenvia una sessió xifrada que no pot llegir — però pot veure que us heu connectat, des d'on i durant quant de temps.

Amb una VPN, l'operador del túnel veu el vostre trànsit i les vostres destinacions, cosa que és una única decisió de confiança concentrada, i el vostre proveïdor d'internet només veu un flux xifrat cap a un punt final. Una exposició diferent, no automàticament menor. Cap dels dos models no s'hauria de jutjar per si s'obre un lloc.

La velocitat segueix el camí, no l'etiqueta. Un repetidor selectiu pot mantenir el trànsit no relacionat fora d'un desviament, cosa que és un avantatge real per a un dispositiu que altrament ho tunelitzaria tot. Tampoc no és cap garantia, i cap disposició no promet accés permanent a un servei que intenta detectar-lo activament.

Quan Smart DNS és l'eina adequada

És realment l'eina adequada quan el dispositiu no pot executar cap client de VPN — un televisor, una consola, un descodificador amb la pila de xarxa bloquejada — i quan només importa un servei amb nom. També és raonable quan deliberadament no voleu que cada paquet d'aquell dispositiu passi per un túnel.

És l'eina equivocada quan el requisit és el xifratge, una adreça de sortida per a tot el dispositiu o protecció contra la xarxa local i el proveïdor d'internet. Són propietats de túnel i cap paràmetre de resolutor no les produeix. I si manteniu una VPN al mateix dispositiu, espereu que l'autorització basada en el registre es trenqui, perquè la vostra adreça pública ara és la del túnel.

Executeu aquesta decisió en ordre i atureu-vos a la primera línia que sigui certa:

• Necessiteu el trànsit xifrat i tot el dispositiu en una sortida nova? Feu servir una VPN i reviseu-ne les rutes i les exclusions, no l'indicador de connectat.
• Només necessiteu uns quants serveis amb nom en un dispositiu que no pot tunelitzar? Smart DNS és proporcionat.
• Necessiteu les consultes privades però sense moure el trànsit? Això és DNS xifrat, que no és cap de les coses anteriors.
• El proveïdor depèn de la vostra adreça actual? Espereu una ruptura en el moment que canviï.