Ви спрямовуєте телевізор на резолвер Smart DNS, один застосунок для стрімінгу починає працювати, і висновок пишеться сам: це VPN, який коштує менше і встановлюється швидше. Це не так, і різниця не в причіпках. Змінилася відповідь, яку телевізор отримав, коли запитав, де живе ім'я хоста; не змінилося те, що кожен пакет і далі залишає ваш дім відкрито, тим самим шляхом, з тієї ж адреси, яку провайдер уже знає. Міф у тому, що налаштування DNS — це тунель. Реальність вужча й корисніша, щойно ви її побачите.

Міф: зміна DNS перенаправляє ваш трафік

Звичайний DNS повідомляє застосунку, куди підключатися. Сервіс Smart DNS відповідає на вибрані імена хостів адресами, що належать власній інфраструктурі провайдера, тому застосунок підключається туди, а не безпосередньо до сервісу. Далі провайдер передає цей єдиний потік до справжнього призначення. Більше нічого на пристрої не рухається.

Саме тому трюк узагалі працює на телевізорі чи консолі. Немає клієнта, немає інтерфейсу, немає запису в таблиці маршрутизації, немає шару шифрування. Пристрій робить рівно те, що робив завжди: розв'язує ім'я і підключається до того, що повернулося. Ви змінили відповідь, а не шлях кожного пакета.

Цю мітку використовують і не пов'язані проєкти DNS, тому перевіряйте власну документацію провайдера, а не виводьте набір функцій з назви. Стандартного протоколу Smart DNS не існує; покриття одного продукту нічого надійного не говорить про інший.

Що насправді спрямовується, а що ні

Різницю легко побачити, якщо перелічити її за потоками, а не за пристроями.

FlowSteered by Smart DNS?Why
A supported streaming hostnameYes, usuallyThe resolver returns a provider address for that name
The same app's other hostnamesOnly if the provider lists themSteering is per-name, and lists are curated
Your browser, email, game downloadsNoTheir names resolve to the ordinary destination
Traffic from devices not using that resolverNoNothing forces a device onto a particular resolver
Payload encryptionNoUnrelated to name resolution

Ви можете це побачити. Запитайте резолвер провайдера про ім'я хоста і запитайте публічний резолвер про те саме:

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

Різні відповіді означають спрямування на рівні імені. Та сама відповідь означає або що сервіс не покриває це ім'я, або що пристрій не використовує цей резолвер — збій, який виглядає як неправильне налаштування DNS і часто сприймається за зламаний акаунт.

Є й другий збій із тим самим запахом. Багато провайдерів авторизують за публічною адресою, яку ви використовуєте зараз, тож акаунт працює, доки адреса не зміниться. Ротація NAT операторського рівня або VPN зверху зсуває цю адресу, і ретранслятор відмовляє вам, тоді як розв'язання імені далі успішне. Запис у реєстрі — це контроль доступу, а не доказ виняткового виходу.

Шифрований DNS — це зовсім третя річ

DNS через HTTPS і DNS через TLS захищають обмін між вашим пристроєм і резолвером. Вони шифрують і автентифікують запит, щоб локальна мережа не могла його прочитати чи переписати, а DoH несе його у звичайному трафіку HTTPS на порту 443, тому він і виглядає як вебтрафік для фільтра. Це функція конфіденційності запитів.

Спрямування сервісу — інша функція: сама відповідь указує на посередника. Продукт може пропонувати обидва одразу, і багато хто так робить, але одне не означає іншого. Шифрування ваших запитів жодного разу не перемістило жодного байта відео через іншу країну.

Отже, «шифрований DNS» відповідає на питання, хто може читати ваші запити. Він не відповідає, хто може бачити ваш трафік, і не дає вам нової вихідної адреси. специфікація DNS over HTTPS — правильне посилання на те, що охоплює цей захист, і вона нічого не каже про маршрутизацію.

Хто що бачить у кожному варіанті

Зі Smart DNS резолвер бачить імена, які ви шукаєте, ретранслятор провайдера бачить з'єднання, які він несе, а ваш провайдер і далі бачить усе інше в структурі відкритого тексту: до яких адрес ви зверталися, коли і скільки. Вміст залишається захищеним TLS до призначення у спрямованому потоці, тож ретранслятор передає шифровану сесію, яку не може прочитати — але бачить, що ви підключилися, звідки і на скільки.

З VPN оператор тунелю бачить ваш трафік і ваші призначення, що є одним зосередженим рішенням про довіру, а ваш провайдер бачить лише шифрований потік до однієї кінцевої точки. Інша експозиція, не автоматично менша. Жодну модель не слід оцінювати за тим, чи відкривається один сайт.

Швидкість іде за шляхом, а не за міткою. Вибірковий ретранслятор може тримати не пов'язаний трафік поза об'їздом, що є реальною перевагою для пристрою, який інакше тунелював би все. Це теж не гарантія, і жодна схема не обіцяє постійного доступу до сервісу, який активно намагається його виявити.

Коли Smart DNS — правильний інструмент

Це справді правильний інструмент, коли пристрій узагалі не може запустити клієнт VPN — телевізор, консоль, приставка із замкненим мережевим стеком — і коли важливий лише один названий сервіс. Це також розумно, коли ви навмисно не хочете, щоб кожен пакет на цьому пристрої йшов через тунель.

Це неправильний інструмент, коли потрібне шифрування, вихідна адреса для всього пристрою або захист від локальної мережі й провайдера. Це властивості тунелю, і жодне налаштування резолвера їх не створює. А якщо ви тримаєте VPN на тому ж пристрої, чекайте, що авторизація на основі реєстрації зламається, бо ваша публічна адреса тепер адреса тунелю.

Пройдіть це рішення по порядку і зупиніться на першому правдивому рядку:

  • Вам потрібен шифрований трафік і весь пристрій на новому виході? Використовуйте VPN і перевірте його маршрути та винятки, а не індикатор підключення.
  • Вам потрібно лише кілька названих сервісів на пристрої, який не вміє тунелювати? Smart DNS пропорційний.
  • Вам потрібні приватні запити, але без переміщення трафіку? Це шифрований DNS, який не є жодним із переліченого.
  • Провайдер покладається на вашу поточну адресу? Чекайте на збій тієї ж миті, коли вона зміниться.

Схожі статті