Розробники Firefox про включення за промовчанням режиму DNS поверх HTTPS (DoH, DNS over HTTPS) для користувачів із США. Шифрування DNS-трафіку сприймається як важливий чинник захисту користувачів. Починаючи з сьогоднішнього дня, у всіх нових установках, виконаних користувачами зі США, DoH активовано за замовчуванням. Існуючих користувачів із США планується переключити на DoH протягом кількох тижнів. У Євросоюзі та інших країнах активувати DoH за умовчанням поки що .
Після активації DoH користувачу виводиться попередження, яке дозволяє за бажання відмовитися від звернення до централізованих DoH-серверів DNS і повернутися до традиційної схеми надсилання незашифрованих запитів до DNS-сервера провайдера. Замість розподіленої інфраструктури резолверів DNS, у DoH використано прив'язку до певного DoH-сервісу, який може розглядатися як єдина точка відмови. В даний час пропонується робота через два DNS-провайдери - CloudFlare (за замовчуванням) та .
Змінити провайдера або вимкнути DoH у налаштуваннях мережного з'єднання. Наприклад, можна вказати альтернативний сервер DoH "https://dns.google/dns-query" для звернення до серверів Google, "https://dns.quad9.net/dns-query" - Quad9 і "https://doh" .opendns.com/dns-query» - OpenDNS. В about:config також передбачено налаштування network.trr.mode, через яке можна змінити режим роботи DoH: значення 0 повністю відключає DoH; 1 - використовується DNS або DoH, залежно від того, що швидше; 2 - використовується DoH за замовчуванням, а DNS як запасний варіант; 3 - використовується тільки DoH; 4 — режим дзеркалювання, при якому DoH і DNS задіяні паралельно.
Нагадаємо, що DoH може виявитися корисним для виключення витоків відомостей про запитовані імена хостів через DNS-сервери провайдерів, боротьби з MITM-атаками та заміною DNS-трафіку (наприклад, при підключенні до публічних Wi-Fi), протистояння блокуванням на рівні DNS (DoH не може замінити VPN в області обходу блокувань, реалізованих на рівні DPI або для організації роботи у разі неможливості прямого звернення до DNS-серверів (наприклад, при роботі через проксі). Якщо у звичайній ситуації DNS-запити безпосередньо відправляються на визначені в конфігурації системи DNS-сервери, то у разі DoH запит на визначення IP-адреси хоста інкапсулюється в трафік HTTPS і відправляється на сервер HTTP, на якому резолвер обробляє запити через Web API. Існуючий стандарт DNSSEC використовує шифрування лише для автентифікації клієнта та сервера, але не захищає трафік від перехоплення та не гарантує конфіденційність запитів.
Для відбору провайдерів DoH, що пропонуються в Firefox, сформульовані до DNS-резолверів, що заслуговують на довіру, відповідно до яких DNS-оператор може використовувати отримані для резолвінгу дані тільки для забезпечення роботи сервісу, не повинен зберігати логи довше 24 годин, не може передавати дані третім особам і зобов'язаний розкривати відомості про методи обробки даних. Сервіс також має дати зобов'язання не цензурувати, не фільтрувати, не втручатися та не блокувати DNS-трафік, за винятком ситуацій, передбачених законодавством.
Застосовувати DoH слід з обережністю. Наприклад, в РФ IP-адреси 104.16.248.249 та 104.16.249.249, пов'язані з пропонованим за умовчанням у Firefox DoH-сервером mozilla.cloudflare-dns.com, в на вимогу суду м. Ставрополя від 10.06.2013.
Застосування DoH також може призвести до проблем у таких галузях, як системи батьківського контролю, доступ до внутрішніх просторів імен у корпоративних системах, вибір маршрутів у системах оптимізації доставки контенту та виконання судових приписів щодо протидії поширенню нелегального контенту та експлуатації неповнолітніх. Для обходу подібних проблем реалізовано та протестовано систему перевірок, що автоматично відключають DoH за певних умов.
Для визначення корпоративних резолверів виконуються перевірки нетипових доменів першого рівня (TLD) та повернення системним резолвером інтранет-адрес. Для визначення включення батьківського контролю здійснюється спроба резолвінгу імені exampleadultsite.com і якщо результат не збігається з фактичним IP, вважається активним блокування дорослого контенту на рівні DNS. Як ознаки також перевіряються IP-адреси Google і YouTube щодо їх заміни на restrict.youtube.com, forcesafesearch.google.com і restrictmoderate.youtube.com. Дані перевірки дають можливість атакуючим, що контролюють роботу резолвера або здатні втрутитися в трафік, симулювати подібну поведінку для відключення шифрування DNS-трафіку.
Робота через єдиний DoH-сервіс також потенційно може призвести до проблем з оптимізацією трафіку в мережах доставки контенту, які виконують балансування трафіку з використанням DNS (DNS-сервер CDN-мережі формує відповідь з огляду на адресу резолвера та видає найближчий хост для отримання контенту). Надсилання DNS-запиту з найближчого до користувача резолвера в таких CDN призводить до повернення адреси найближчого до користувача хоста, але при надсиланні DNS-запиту з централізованого резолвера буде видана адреса хоста, найближча до сервера DNS-over-HTTPS. Тестування практично показало, що застосування DNS-over-HTTP при використанні CDN практично не призводило до затримок перед початком передачі контенту (для швидких з'єднань затримки не перевищували 10 мілісекунд, а на повільних каналах зв'язку спостерігалося навіть прискорення роботи). Для передачі резолверу CDN відомості про місцезнаходження клієнта було розглянуто застосування розширення EDNS Client Subnet.
Джерело: opennet.ru