После активации DoH пользователю выводится предупреждение, которое позволяет при желании отказаться от обращения к централизованным DoH-серверам DNS и вернуться к традиционной схеме отправки незашифрованных запросов к DNS-серверу провайдера. Вместо распределённой инфраструктуры резолверов DNS, в DoH использована привязка к определённому DoH-сервису, который может рассматриваться как единая точка отказа. В настоящее время предлагается работа через два DNS-провайдера — CloudFlare (по умолчанию) и NextDNS. Изменить провайдера или отключить DoH можно в настройках сетевого соединения. Например, можно указать альтернативный сервер DoH «https://9.9.9.9/dns-query» для обращения к серверам Google, «https://dns.quad9.net/dns-query» — Quad9 и «https://doh.opendns.com/dns-query» — OpenDNS.
Напомним, что DoH может оказаться полезным для исключения утечек сведений о запрашиваемых именах хостов через DNS-серверы провайдеров, борьбы с MITM-атаками и подменой DNS-трафика (например, при подключении к публичным Wi-Fi), противостояния блокировкам на уровне DNS (DoH не может заменить VPN в области обхода блокировок, реализованных на уровне DPI) или для организации работы в случае невозможности прямого обращения к DNS-серверам (например, при работе через прокси). Если в обычной ситуации DNS-запросы напрямую отправляются на определённые в конфигурации системы DNS-серверы, то в случае DoH запрос на определение IP-адреса хоста инкапсулируется в трафик HTTPS и отправляется на HTTP-сервер, на котором резолвер обрабатывает запросы через Web API. Существующий стандарт DNSSEC использует шифрование лишь для аутентификации клиента и сервера, но не защищает трафик от перехвата и не гарантирует конфиденциальность запросов.
В about:config предусмотрено несколько настроек DoH. Через переменную network.trr.mode можно изменить режим работы: значение 0 полностью отключает DoH; 1 — используется DNS или DoH, в зависимости от того, что быстрее; 2 — используется DoH по умолчанию, а DNS как запасной вариант; 3 — используется только DoH; 4 — режим зеркалирования при котором DoH и DNS задействованы параллельно.
Применение 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-запроса c ближайшего к пользователю резолвера в таких CDN приводит к возврату адреса ближайшего к пользователю хоста, но при отправке DNS-запроса с централизованного резолвера будет выдан адрес хоста, ближайший к серверу DNS-over-HTTPS. Тестирование на практике показало, что применение DNS-over-HTTP при использовании CDN практически не приводило к задержкам перед началом передачи контента (для быстрых соединений задержки не превышали 10 миллисекунд, а на медленных каналах связи наблюдалось даже ускорение работы). Для передачи резолверу CDN сведения о местоположении клиента также было рассмотрено применение расширения EDNS Client Subnet. .
Источник: http://www.opennet.ru/opennews/art.shtml?num=52427