Smart DNS ne estas VPN: kion tiu DNS-agordo vere ŝanĝas

Vi turnas la televidilon al Smart DNS-eligilo, unu elsenda aplikaĵo ekfunkcias, kaj la konkludo skribiĝas mem: ĉi tio estas VPN, kiu kostas malpli kaj instaliĝas pli rapide. Ne estas, kaj la diferenco ne estas pedanteco. Kio ŝanĝiĝis estas la respondo, kiun la televidilo ricevis, kiam ĝi demandis, kie loĝas gastigantnomo; kio ne ŝanĝiĝis estas, ke ĉiu pako ankoraŭ forlasas vian domon malkaŝe, sur la sama vojo, de la sama adreso, kiun la ISP jam konas. La mito estas, ke DNS-agordo estas tunelo. La realo estas pli mallarĝa kaj pli utila, kiam vi vidas ĝin.

La mito: DNS-ŝanĝo alidirektas vian trafikon

Ordinara DNS diras al aplikaĵo, kien konektiĝi. Smart DNS-servo respondas al elektitaj gastigantnomoj per adresoj apartenantaj al la propra infrastrukturo de la provizanto, do la aplikaĵo konektiĝas tien anstataŭ rekte al la servo. La provizanto tiam plusendas tiun unu fluon al la vera celo. Nenio alia sur la aparato moviĝas.

Tial la truko entute funkcias sur televidilo aŭ konzolo. Ne estas kliento, ne estas interfaco, ne estas enskribo en la vojiga tabelo, ne estas ĉifra tavolo. La aparato faras ĝuste tion, kion ĝi ĉiam faris: solvas nomon kaj konektiĝas al io ajn, kio revenas. Vi ŝanĝis la respondon, ne la vojon de ĉiu pako.

La etikedon uzas ankaŭ nerilataj DNS-projektoj, do kontrolu la propran dokumentaron de la provizanto anstataŭ supozi funkcionaron el la nomo. Ne ekzistas norma Smart DNS-protokolo; la kovrado de unu produkto diras nenion fidindan pri alia.

Kio efektive estas direktata, kaj kio ne

La distingo estas facile videbla, kiam vi listigas ĝin laŭ fluo anstataŭ laŭ aparato.

Vi povas vidi ĝin okazi. Demandu la eligilon de la provizanto pri gastigantnomo kaj demandu publikan eligilon pri la sama:

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

Malsamaj respondoj signifas direktadon ĉe la noma tavolo. La sama respondo signifas aŭ ke la servo ne kovras tiun nomon aŭ ke la aparato ne uzas tiun eligilon — fiasko, kiu aspektas kiel malĝusta DNS-agordo kaj ofte estas konfuzata kun rompita konto.

Ekzistas dua fiasko kun la sama odoro. Multaj provizantoj rajtigas laŭ la publika adreso, kiun vi nun uzas, do la konto funkcias ĝis la adreso ŝanĝiĝas. Carrier-grade NAT-rotacio, aŭ VPN sur tavolo supre, movas tiun adreson kaj la relajso rifuzas vin, dum la solvado daŭre sukcesas. La registra enskribo estas alirkontrolo, ne pruvo de ekskluziva eliro.

Ĉifrita DNS estas tute tria afero

DNS super HTTPS kaj DNS super TLS protektas la interŝanĝon inter via aparato kaj la eligilo. Ili ĉifras kaj aŭtentikas la peton, por ke la loka reto ne povu legi aŭ reskribi ĝin, kaj DoH portas ĝin en ordinara HTTPS-trafiko sur pordo 443, kio ankaŭ estas la kialo, ke ĝi aspektas kiel rettrafiko al filtrilo. Tio estas konfidenceca funkcio por serĉoj.

Direkti servon estas alia funkcio: la respondo mem montras al peranto. Produkto povas oferti ambaŭ samtempe, kaj multaj faras tion, sed unu ne implicas la alian. Ĉifri viajn serĉojn neniam movis eĉ unu bajton da video tra alia lando.

Do „ĉifrita DNS“ respondas demandon pri tio, kiu povas legi viajn petojn. Ĝi ne respondas, kiu povas vidi vian trafikon, kaj ĝi ne donas al vi novan eliran adreson. La specifikaĵo de DNS over HTTPS estas la ĝusta referenco pri tio, kion tiu protekto kovras, kaj ĝi diras nenion pri vojigado.

Kiu vidas kion en ĉiu aranĝo

Kun Smart DNS, la eligilo vidas la nomojn, kiujn vi serĉas, la relajso de la provizanto vidas la konektojn, kiujn ĝi portas, kaj via ISP ankoraŭ vidas ĉion alian en strukturo de malkaŝa teksto: kiujn adresojn vi kontaktis, kiam kaj kiom. La enhavo restas protektita per TLS ĝis la celo en la direktata fluo, do la relajso plusendas ĉifritan sesion, kiun ĝi ne povas legi — sed ĝi povas vidi, ke vi konektiĝis, de kie kaj por kiom longe.

Kun VPN, la tunela funkciiganto vidas vian trafikon kaj viajn celojn, kio estas unu koncentrita fida decido, kaj via ISP vidas nur ĉifritan fluon al unu finpunkto. Malsama eksponiĝo, ne aŭtomate malpli. Neniu modelo estu juĝata laŭ tio, ĉu unu retejo malfermiĝas.

Rapideco sekvas la vojon anstataŭ la etikedon. Selektema relajso povas teni nerilatan trafikon ekster ĉirkaŭvojo, kio estas vera avantaĝo por aparato, kiu alie tunelus ĉion. Ĝi ankaŭ ne estas garantio, kaj neniu aranĝo promesas permanentan aliron al servo, kiu aktive provas ĝin detekti.

Kiam Smart DNS estas la ĝusta ilo

Ĝi estas vere la ĝusta ilo, kiam la aparato tute ne povas ruli VPN-klienton — televidilo, konzolo, set-top-skatolo kun ŝlosita reta stako — kaj kiam nur unu nomita servo gravas. Ĝi ankaŭ estas racia, kiam vi intence ne volas, ke ĉiu pako sur tiu aparato estu tunelita.

Ĝi estas la malĝusta ilo, kiam la postulo estas ĉifrado, elira adreso por la tuta aparato aŭ protekto kontraŭ la loka reto kaj la ISP. Tiuj estas tunelaj ecoj, kaj neniu eligila agordo produktas ilin. Kaj se vi tenas VPN sur la sama aparato, atendu, ke la rajtigo bazita sur registriĝo rompiĝos, ĉar via publika adreso nun estas tiu de la tunelo.

Rulu ĉi tiun decidon laŭorde kaj haltu ĉe la unua linio, kiu estas vera:

• Ĉu vi bezonas la trafikon ĉifrita kaj la tutan aparaton sur nova eliro? Uzu VPN, kaj kontrolu ĝiajn vojojn kaj esceptojn anstataŭ ĝian konektitan indikilon.
• Ĉu vi bezonas nur kelkajn nomitajn servojn sur aparato, kiu ne povas tuneli? Smart DNS estas proporcia.
• Ĉu vi bezonas privatajn serĉojn sed ne movitan trafikon? Tio estas ĉifrita DNS, kiu estas nek unu nek la alia el la supre.
• Ĉu la provizanto dependas de via nuna adreso? Atendu rompon en la momento, kiam ĝi ŝanĝiĝos.