DNS поверх HTTPS: що це таке і як він захищає ваші запити

Альфа-гід » Обчислення » DNS поверх HTTPS: що це таке і як він захищає ваші запити

Коли ви вводите веб-адресу, за лаштунками працює компонент, який гарантує, що ви потрапите на правильний сайт: система доменних імен (DNS). DNS перетворює легко запам'ятовувані імена на IP-адреси , які можуть зрозуміти комп'ютери. Так, це зручно, але роками він працював зі значною вразливістю: ці запити передавались у незашифрованому вигляді. Саме тому DNS через HTTPS, також відомий як DoH, став таким популярним — додатковий рівень захисту, який ускладнює для вашого інтернет-провайдера відстеження того, які домени ви відвідуєте.

Важливо одразу уточнити одну річ: DoH покращує конфіденційність DNS-запитів, але це не VPN, і він не перетворює все ваше з’єднання на секретний тунель . У цій статті ми розглянемо, що саме це таке, чому воно стало популярним, як його активувати в Chrome, Edge та Firefox, його переваги та недоліки, чим воно відрізняється від DNS через TLS та VPN, а також ступінь його технічних та практичних обмежень.

Що таке DNS і чому традиційна система не спрацьовує?

DNS-сервери – це один із тих компонентів, на які майже ніхто не звертає уваги, проте вони лежать в основі значної частини перегляду веб-сторінок. Їхнє завдання полягає в тому, щоб пов’язати доменне ім’я з IP-адресою відповідного сервера . Коли ви відвідуєте веб-сайт, ваш комп’ютер не розпізнає літери: йому потрібна IP-адреса, щоб знати, до якого комп’ютера підключатися. Багато маршрутизаторів постачаються з DNS-серверами, вже налаштованими інтернет-провайдером, що робить процес зручним, хоча це також залишає видимий слід для того, хто контролює цю інфраструктуру.

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

• Пасивне прослуховування: Хтось спостерігає за запитами та робить висновок, які сервіси чи вебсайти ви часто відвідуєте.
• Людина посередині: Зв'язок перехоплюється, а відповідь змінюється таким чином, щоб імітувати сервер.
• Блокування та фільтрація: Це запобігає вирішенню певних доменів, щоб контролювати доступ до контенту.

DNS через HTTPS: Зашифруйте запит, щоб він був невидимим для всіх.

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

Щоб це працювало, DNS-сервер, до якого надсилається запит, також повинен підтримувати DNS на основі домену (DoH ). Простого ввімкнення опції в браузері недостатньо: вибраний резолвер повинен дотримуватися цього стандарту. Специфікація постійно розвивається і досі вважається технологією, що розвивається, хоча з 2018 року такі компанії, як Google і Mozilla Foundation, тестують та інтегрують її. Окрім покращення конфіденційності, тести показують, що DoH може зменшити затримку та пришвидшити обробку запитів, оскільки не завжди необхідно резолвірувати весь домен, а лише мінімально необхідну частину.

Переваги DoH: більше конфіденційності, менше маніпуляцій та краща продуктивність

Найбільш очевидною перевагою є безпека. Оскільки DNS-запити передаються зашифрованими, їх набагато важче стежити за ними або змінювати . Це ускладнює атаки типу «посередник», зменшує ризики в публічних мережах Wi-Fi та не дозволяє локальному оператору чітко бачити, які домени ви запитуєте. Оскільки трафік DoH використовує порт 443, він змішується з іншими HTTPS-з’єднаннями та його важко відрізнити від звичайного веб-відвідування.

Також є причини, пов'язані з продуктивністю. DoH може зменшити затримку та пришвидшити зв'язок DNS завдяки змінам у способі розв'язання імен та кращому використанню кешу. Наприклад, метод GET деяких API розроблений для ефективнішого кешування. На практиці це може призвести до дещо швидшого перегляду веб-сторінок, хоча це не чарівна паличка, і покращення не завжди помітне. Крім того, оскільки це реалізовано в браузері, користувачеві не потрібно чекати, поки його активує інтернет-провайдер.

Недоліки та дискусії: коли шифрування ускладнює життя

Не всі позитивно ставляться до шифрування на основі домену (DoH). Те саме шифрування, яке захищає користувача, також ускладнює моніторинг мережі . Багато програм батьківського контролю покладаються на перевірку DNS-запитів, щоб визначити, до яких веб-сайтів намагаються отримати доступ діти; з DoH це завдання стає набагато складнішим і навіть неможливим. Подібна ситуація існує для адміністраторів корпоративних мереж, які втрачають видимість доменів, до яких надсилаються запити, і не можуть так легко застосовувати певні правила.

Інтернет-провайдери також втрачають можливість контролювати доступ і блокувати певні домени на вимогу установи. Це породжує законні дебати: одні вважають це перемогою конфіденційності, інші — проблемою контролю та управління . У випадку з DoT його також критикують за використання власного розпізнаваного порту, який дозволяє ідентифікувати DNS-запити навіть без точного знання того, що запитується. DoH уникає цього чіткого сигналу, маскуючись під HTTPS-трафік, але натомість мережеві адміністратори отримують менше інструментів для керування своїми комунікаціями.

Як увімкнути DoH у Chrome, Edge та Firefox

Увімкнення системи доменних імен (DNS) у сучасному браузері зазвичай просте, особливо якщо він базується на Chromium або Firefox. Ця опція існує, хоча в деяких випадках вона прихована в меню додаткових налаштувань . Перш ніж щось змінювати, важливо розуміти, що браузер захищає лише власні запити: інші програми на пристрої можуть продовжувати використовувати іншу систему DNS, якщо вона також не налаштована на системному рівні.

Google Chrome

У Chrome швидкий спосіб — це ввести текст chrome://flags/#dns-over-https в адресному рядку. Це перенаправить вас безпосередньо до прапорців Chrome або експериментальних функцій.Ви побачите вибрану опцію під назвою «Безпечний пошук DNS»; натисніть на спадне меню «За замовчуванням» і виберіть «Увімкнено». Потім вам потрібно буде перезапустити браузер, щоб зміни набули чинності.

Microsoft Край

У Edge на базі Chromium процес практично ідентичний. Відкрийте браузер і введіть edge://flags/#dns-over-https у рядку пошукуВи введете прапорці Edge, і з’явиться та сама опція безпечного пошуку DNS. Змініть значення за замовчуванням на Увімкнено та перезапустіть браузер, коли буде запропоновано.

Mozilla Firefox

У Firefox вам не потрібно переходити до розділу «Прапори». Натисніть кнопку меню у верхньому правому куті та виберіть «Параметри» . У розділі «Загальні» прокрутіть униз і натисніть «Налаштування мережі». У вікні, що відкриється, встановіть прапорець «Увімкнути DNS через HTTPS». Потім ви можете вибрати одного з таких постачальників, як Cloudflare та NextDNS, для виконання шифрування через HTTPS.

DNS через TLS (DoT): інший зашифрований шлях

DNS через TLS, або DoT, – це ще один спосіб захисту DNS-запитів. Замість HTTPS використовується TLS через TCP-з’єднання та стандартизований порт 853. TLS є тією ж основою безпеки, що й HTTPS, тому ідея схожа: створити зашифрований тунель, у якому лише два учасники можуть розшифрувати та обробляти інформацію. Це ускладнює атаки типу «людина посередині» та запобігає третій стороні читати або маніпулювати запитом.

DotT має свої переваги, особливо порівняно з традиційним DNS, який не пропонує жодних заходів безпеки. Шифрування запобігає перехопленню запитів кіберзлочинцями, а також перешкоджає певним цензурним заходам . Однак воно вимагає сумісності як від клієнта, так і від сервера. Кілька провайдерів пропонують сумісні сервери, але його використання на настільному комп'ютері або ноутбуці зазвичай вимагає встановлення додаткового програмного забезпечення; на сучасному Android, принаймні, починаючи з Android 9, воно вже інтегроване. Існують рішення для Windows та Linux, хоча вони не завжди такі прозорі, як хотілося б.

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

DoH проти DoT: два способи захистити одну й ту саму річ

Основна відмінність між DoH та DoT полягає в порту та способі маскування трафіку. DoT використовує власний порт, 853, тоді як DoH використовує 443 та зливається зі звичайними HTTPS-з'єднаннями . Ця, здавалося б, незначна різниця викликала значні дискусії. З точки зору конфіденційності, невідрізненість DNS-запитів від іншого трафіку є перевагою: якщо їх не розпізнати, ними не так легко маніпулювати. Однак з точки зору управління мережею, контроль втрачається, і стає складніше впроваджувати політики безпеки або фільтрації.

По суті, існують два бачення. IETF, консорціум, який розробляє багато інтернет-стандартів, стоїть за DoT , тоді як Google та Mozilla Foundation активно просувають DoH. Це не протилежні технології, але вони представляють різні способи розуміння конфіденційності, видимості мережі та ролі посередників. Вибір між одним та іншим залежить від того, що потрібно захистити та хто має керувати мережею.

DoH проти VPN: захищає питання, а не всю подорож

DoH та VPN часто згадуються в одних і тих самих розмовах про конфіденційність, але вони не роблять одного й того ж. DoH захищає запит імені; VPN захищає шлях, яким прямують ваші дані . Найпростіший спосіб зрозуміти це – уявити, як DoH поміщає конфіденційне запитання в запечатаний конверт, тоді як VPN прокладає всю подорож через приватний тунель, перш ніж повернутися на дорогу загального користування. Обидва можуть покращити конфіденційність, але лише один розроблений для комплексного покриття трафіку телефонів, планшетів та комп’ютерів.

Що робить DNS перед завантаженням сайту?

Перш ніж ваш браузер зможе завантажити веб-сайт, вашому пристрою потрібно знати його місцезнаходження. DNS працює як телефонна книга, перетворюючи назву веб-сайту на IP-адресу . Це відбувається постійно: коли ви відкриваєте сторінку, запускаєте програму, оновлюєте електронну пошту або відтворюєте відео. Здебільшого це відбувається непомітно, і ви цього не помічаєте, що чудово для зручності, але також дозволяє легко ігнорувати це як проблему конфіденційності. Традиційні DNS-запити не шифруються, тому ваш інтернет-провайдер, ваш роботодавець, ваша школа, Wi-Fi кав’ярні або мережа готелю можуть бачити, до яких доменів намагається дістатися ваш пристрій. Вони не бачать повного вмісту сторінки HTTPS, але отримують досить показовий огляд вашої активності.

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

Що приховує DoH, а що розкриває?

DoH надсилає DNS-запити через HTTPS, той самий зашифрований протокол, який використовується безпечними веб-сайтами. Запит залишає ваш пристрій зашифрованим і надходить до резолвера, який підтримує стандарт . У громадських мережах Wi-Fi це може ускладнити випадкове зчитування ваших запитів оператором мережі. Якщо ваш інтернет-провайдер керує DNS, перехід на резолвер DoH може запобігти перегляду цих запитів звичайним способом. Крім того, якщо мережа маніпулює результатами розпізнавання імен, зашифрований DNS може зменшити деякі форми маніпуляцій.

Тепер DoH приховує запит, а не всю розмову. Це може перешкодити деяким спостерігачам чітко бачити пошук домену, але це не перетворює все ваше інтернет-з’єднання на зашифрований тунель . Щойно пристрій дізнається IP-адресу, решта з’єднання йде своїм звичайним шляхом, якщо інший інструмент конфіденційності не змінить цей маршрут. DoH не приховує вашу справжню IP-адресу від веб-сайтів, програм чи сервісів, до яких ви підключаєтеся, а також не створює враження, що ви перебуваєте в іншому місті чи країні. Якщо ви входите в обліковий запис, сервіс знає, що це ви. Якщо браузер має файли cookie, збережені сеанси, рекламні ідентифікатори або розпізнаваний відбиток пальця, DoH не видаляє ці сигнали.

Він також не захищає кожну програму, якщо це не налаштовано на системному рівні, і програма не враховує цей параметр. Один браузер може використовувати безпечний DNS, тоді як інша програма на тому ж пристрої використовує інший шлях DNS . Деякі програми керують власною мережею та не завжди узгоджуються з налаштуваннями системи чи браузера. Таким чином, DoH може створювати хибне відчуття повного захисту: він покращує конфіденційність DNS-запитів, але не захищає передачу файлів, трафік повідомлень, відеодзвінки, ігрові з’єднання, фонову синхронізацію або потокові програми так, як це робить VPN.

Що захищає VPN, а що він не може приховати

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

Комплексний VPN може захистити браузери, потокові програми, поштові клієнти, інструменти резервного копіювання в хмару, програми обміну повідомленнями, ігри та фонові служби. Він також може направляти DNS-запити через зашифрований тунель за умови правильного налаштування , тому варто провести тест на витік DNS. Однак VPN — це не магія. Якщо ви входите в соціальну мережу, обліковий запис електронної пошти, потоковий сервіс або інтернет-магазин, цей сервіс все одно знає, хто ви. Він може приховати вашу оригінальну IP-адресу, але не анонімізує ваш логін. Те саме стосується всього, що ви надсилаєте безпосередньо: ваше ім’я, адресу електронної пошти, платіжні дані, адресу доставки, фотографії чи повідомлення.

Файли cookie та цифрові відбитки браузера все ще мають значення. Програми можуть створювати подібні проблеми через рекламні ідентифікатори, дозволи, доступ до місцезнаходження, сканування Bluetooth, імена сусідніх мереж Wi-Fi та інструменти сканування. Шкідливе програмне забезпечення є ще однією серйозною перешкодою, оскільки воно може захоплювати дані ще до того, як вони досягнуть тунелю VPN . Коротше кажучи, VPN приховує та шифрує багато активності, але він не маскує кожен цифровий відбиток.

DoH та VPN можна використовувати одночасно

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

Проблема виникає, коли браузер використовує власну конфігурацію авторизації домену (DoH), тоді як VPN намагається керувати DNS на системному рівні. Нічого може не зламатися, але виникає плутанина : ви можете думати, що всі запити проходять через VPN, але насправді браузер самостійно надсилає деякі до іншого резолвера. Саме тут стане в нагоді тест на витік DNS. Якщо після підключення до VPN ви бачите DNS-сервери вашого інтернет-провайдера, щось працює не так, як очікувалося; якщо ви бачите сервери, пов’язані з VPN, конфігурація, швидше за все, працює правильно.

Коли достатньо DoH, а коли доцільно використовувати VPN?

DoH може бути достатнім, коли вашою основною турботою є базова конфіденційність DNS-запитів у вашому браузері. У надійній домашній мережі ввімкнення Secure DNS зменшує ризики використання відкритого тексту, не вимагаючи від вас зміни місцезнаходження чи захисту всіх ваших програм . Це також корисно в мережах, де фільтрація або маніпулювання DNS є проблемою, оскільки переміщення по HTTPS ускладнює легку перевірку або зміну. ​​Це не означає, що це обходить усі обмеження або є захищеним від цензури, але це значне покращення порівняно з незашифрованим DNS. Крім того, це легкий спосіб: вам не потрібно вибирати VPN-сервер або суттєво змінювати маршрутизацію, і ви зазвичай не помітите значного впливу на швидкість.

VPN має найбільший сенс, коли вам потрібен захист усього пристрою, а не лише пошук DNS. Це включає аеропорти, готелі, школи, коворкінги, кафе та орендоване житло . У спільних мережах ви не знаєте, хто керує маршрутизатором, хто ще підключений або чи хтось намагається перехопити трафік. VPN також допомагає, коли ви не хочете, щоб ваш інтернет-провайдер створював профіль ваших шаблонів перегляду: навіть якщо HTTPS захищає вміст сторінки, метадані мережі все одно можуть розкривати корисні шаблони. Подорожі – ще один яскравий приклад: VPN може зробити ваше з’єднання стабільнішим, захистити вас у незнайомих мережах і дозволити веб-сайтам бачити місцезнаходження VPN-сервера замість вашого тимчасового локального з’єднання.

Технічні деталі API DoH публічного DNS Google

Публічний DNS Google пропонує два різних DoH API. Один розроблений для RFC 8484 і приймає запити GET та POST за адресою https://dns.google/dns-query; інший — це JSON API, який підтримує лише запити GET за адресою https://dns.google/resolve . Також є веб-інтерфейс за адресою https://dns.google/, який відображає результати JSON у браузері, але він не реалізує повний API. Цей інтерфейс не слід плутати з URL-адресами API або з https://dns.google/query. Сервіс не підтримує незахищені HTTP URL-адреси, а DoH також підтримується публічним сервісом DNS64 від Google, хоча в цьому випадку підтримується лише IPv6. Документація Google щодо безпечного транспортування містить приклади curl та детальну інформацію про TLS, DoT та DoH.

Доступні методи HTTP

Метод GET може зменшити затримку, оскільки він ефективніше кешує. Запити GET згідно з RFC 8484 повинні містити параметр `?dns=` з DNS-повідомленням у кодуванні Base64Url , і це єдиний метод, що підтримується JSON API. Метод POST також доступний лише в RFC 8484 та використовує двійкове DNS-повідомлення з `application/dns-message` як у тілі запиту, так і в тілі відповіді. Метод HEAD наразі не підтримується та повертає помилку 400 Bad Request. Інші методи повертають помилку 501 Not Implemented.

Коди стану та помилки

API повертає кілька HTTP-кодів, які варто знати. Код 200 OK вказує на успішний HTTP-аналіз та зв'язок з DNS-резолвером ; тіло відповіді може бути двійковою відповіддю DNS або JSON залежно від кінцевої точки, заголовка Accept та параметрів GET. Примітка: помилка HTTP також може бути збоєм DNS, тому рекомендується перевірити код відповіді DNS, наприклад, поле "Status" JSON, на наявність таких помилок, як SERVFAIL, FORMERR, REFUSED або NOTIMP.

• 301 Переміщено назавжди: Клієнт повинен повторити спробу запиту за URL-адресою, зазначеною в полі «Розташування». Якщо початковий запит був POST, спробу слід повторити за допомогою GET, лише якщо нова URL-адреса вказує параметр DNS; в іншому випадку спробу потрібно повторити за допомогою POST. Також можуть з’являтися коди стану 302, 307 та 308, і клієнти DoH повинні обробляти всі чотири. Постійні коди стану 301 та 308 можна кешувати необмежений час. Запити POST, які отримують код стану 307 або 308, завжди потрібно повторювати за допомогою POST.
• Поганий запит 400: Проблеми з розбором параметрів GET або недійсне повідомлення DNS-запиту. Більшість недійсних повідомлень DNS отримують помилку 200 OK з FORMERR, але помилки HTTP виникають для нечитабельних повідомлень без розділу запитання, з QR-кодом, що вказує на відповідь, або з безглуздими комбінаціями кодів.
• 413 Корисне навантаження занадто велике: Тіло запиту POST RFC 8484 перевищує максимальний розмір повідомлення в 512 байт.
• 414 URI занадто довгий: Заголовок запиту GET був занадто великим, або параметр dns перевищив 512 байт.
• 415 Непідтримуваний тип носія: Тіло POST не містило заголовка типу контенту application/dns-message.
• 429 Забагато запитів: За заданий період надіслано забагато запитів. Клієнт має зачекати до часу, зазначеного в заголовку Retry-After.
• Внутрішня помилка сервера 500: Внутрішні помилки в службі DoH.
• 501 не реалізовано: Реалізовано лише GET та POST; решта повертають цю помилку.
• Поганий шлюз 502: Служба DoH не змогла зв’язатися з резолверами публічного DNS Google. Можливо, спрацює спроба іншої адреси, але ефективнішим резервним планом є спроба іншої служби DoH або перехід на традиційний DNS за допомогою UDP або TCP на адресі 8.8.8.8.

Найкращі практики для забезпечення конфіденційності та продуктивності

Розробникам DoH-застосунків слід обмежувати HTTP-заголовки. Такі заголовки, як Cookie, User-Agent та Accept-Language, можуть розкривати інформацію про реалізацію клієнта та сприяти деанонімізації . Рекомендується надсилати лише заголовки, необхідні для DoH: Host, Content-Type (для POST-запитів) та, за потреби, Accept. Заголовок User-Agent слід включати у версії для розробки або тестування. Також рекомендується використовувати параметри доповнення EDNS, щоб скоротити запити до загальної довжини та ускладнити аналіз трафіку. Доповнення HTTP/2 можливе, але на відміну від доповнення EDNS, воно не генерує доповнення у відповідях сервера DoH.

Метод POST у RFC 8484 слід використовувати лише в програмах, що чутливі до конфіденційності, або в режимах браузера. Використання POST зменшує обсяг кешу та може збільшити затримку, тому його зазвичай не рекомендується використовувати . Однак зменшення розміру кешу може бути доцільним для програм, які хочуть запобігти атакам синхронізації веб-програм, спрямованим на виявлення доменів, які користувач нещодавно відвідував. Підхід HTTPS також має практичні переваги: ​​API HTTPS широко доступні та підтримуються, що спрощує реалізацію; сервіс HTTPS надає веб-програмам доступ до всіх типів записів DNS, уникаючи обмежень API браузера або операційної системи, які зазвичай обмежуються пошуком хост-адреса; а клієнти, які реалізують HTTPS через UDP з QUIC, можуть уникнути таких проблем, як блокування заголовка рядка, що виникають із TCP. Якщо ви зіткнулися з помилкою або хочете запросити нову функцію, вам слід повідомити про проблему, пов'язану з DoH, через звичайні канали.

Поширені запитання про DoH та VPN

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

Ще одне поширене питання: чи забороняє DoH вашому інтернет-провайдеру бачити, які веб-сайти ви відвідуєте. DoH приховує DNS-запити від багатьох спостерігачів, але не видаляє всі метадані та не приховує вашу IP-адресу : ваш інтернет-провайдер все ще може бачити, до яких IP-адрес ви підключаєтеся, та іншу мережеву інформацію. Для ширшого захисту вам потрібна VPN або комбінація кількох рівнів конфіденційності.

Також варто запитати, чи достатньо DomainHost (DoH) для публічних мереж Wi-Fi. Це може допомогти запобігти легкому зчитуванню DNS-запитів оператором мережі, але не захищає все з’єднання або трафік усіх програм . В аеропортах, готелях і кафе використання VPN зазвичай є більш комплексним, особливо якщо ви не знаєте, хто керує маршрутизатором або чи підключені інші люди.

Система доменних імен (DoH) та VPN не є прямими конкурентами, а радше інструментами з різними можливостями. DoH шифрує пошук домену та зменшує розкриття цієї частини процесу; VPN шифрує шлях між вашим пристроєм та сервером і змінює IP-адресу, яку бачать пункти призначення . Жоден з них не робить вас невидимим: облікові записи, файли cookie, відбитки браузера, дозволи програм, шкідливе програмне забезпечення та будь-які дані, якими ви ділитеся безпосередньо, все ще можуть ідентифікувати вас. Але це не робить їх марними. Це просто означає, що кожен з них має свою роль. DoH захищає пошук адреси; VPN захищає набагато більшу частину шляху ваших даних.