DNS поверх HTTPS

Классический DNS передаёт запросы и ответы без шифрования и без проверки подлинности, поэтому любой узел на пути — оператор связи, владелец точки доступа, оборудование фильтрации — способен прочитать список запрашиваемых доменов, а также подменить ответ, реализовав атаку посредника^[3].

К моменту разработки протокола уже существовал DNS over TLS, стандартизированный в 2016 году, однако он использует выделенный порт, который в ряде сетей блокируется наравне с портом 53. DoH создавался как механизм, устойчивый к такому вмешательству и не требующий от сети ничего, кроме обычного доступа к HTTPS. Дополнительным обстоятельством была и остаётся слабая распространённость шифрованного DNS среди резолверов операторов связи, из-за чего пользователю приходится обращаться к сторонним публичным сервисам^[2].

Работа над протоколом велась в рабочей группе DOH Инженерного совета Интернета. В марте 2018 года Mozilla провела в сборках Firefox Nightly эксперимент с механизмом Trusted Recursive Resolver, направлявшим все DNS-запросы участников через DoH-сервер Cloudflare; проведение испытания в режиме отказа от участия вызвало возражения части сообщества^[4]. В июне 2018 года поддержка DoH была добавлена в Firefox 62, но по умолчанию не активировалась^[5].

В промежуточных редакциях проекта использовался тип содержимого application/dns-udpwireformat, в итоговом документе он был заменён на application/dns-message^[1]. В октябре 2018 года документ был опубликован как RFC 8484 в категории Standards Track; авторами выступили Пол Хоффман из ICANN и Патрик Макманус из Mozilla^[1].

В июне 2022 года в независимом потоке публикаций вышел экспериментальный RFC 9230, описывающий Oblivious DNS over HTTPS (ODoH). Расширение вводит два дополнительных участника обмена: прокси видит IP-адрес клиента, но не может прочитать зашифрованный запрос, а цель расшифровывает запрос, но видит лишь адрес прокси^[6][7].

Клиент DoH кодирует один DNS-запрос в один HTTP-запрос, используя метод GET или POST; серверы обязаны реализовать оба метода. Адрес ресурса задаётся шаблоном URI, который клиент получает при настройке — вручную или автоматически, например через DHCP; распространённое значение пути — /dns-query. Один сервер может предлагать несколько шаблонов URI с различающимися свойствами, например с разными требованиями к аутентификации^[1].

При использовании POST двоичное DNS-сообщение помещается в тело HTTP-запроса без дополнительного кодирования, а тип содержимого указывается в заголовке Content-Type. При использовании GET сообщение кодируется в base64url без символов заполнения и передаётся в переменной dns шаблона URI. Запросы методом POST компактнее, а запросы методом GET дружелюбнее к кэшам HTTP; ответы на POST-запросы в общем случае не кэшируются, и стандарт не рекомендует опираться на такое кэширование^[1][8].

Обязательный формат полезной нагрузки — одиночное сообщение DNS в двоичном «проводном» виде, определённом RFC 1035, под типом содержимого application/dns-message; максимальный размер сообщения ограничен 65 535 байтами. В отличие от DNS поверх TCP и DNS over TLS, двухбайтовый префикс длины не используется. Клиенты и серверы обязаны поддерживать этот тип, другие типы могут применяться по механизму согласования содержимого HTTP^[1].

Для лучшей совместимости с кэшами HTTP клиентам рекомендуется указывать нулевой идентификатор в заголовке DNS-сообщения: соответствие запроса и ответа обеспечивает сам HTTP, а переменные идентификаторы приводят к раздельному кэшированию семантически одинаковых запросов^[1].

Помимо стандартного двоичного интерфейса отдельные операторы предоставляют собственный JSON-интерфейс, удобный для скриптовых языков. В реализации Google Public DNS такой интерфейс доступен только методом GET^[8].

Пример запроса методом POST в нотации HTTP/2^[1]:

:method = POST
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query
accept = application/dns-message
content-type = application/dns-message
content-length = 33

Соединение устанавливается по HTTPS, что обеспечивает проверку подлинности сервера по сертификату и шифрование канала. Минимальной рекомендуемой версией транспорта назван HTTP/2: для конкурентоспособной по сравнению с UDP работы нужны изменение порядка сообщений, параллелизм, приоритизация и сжатие заголовков, появившиеся именно в этой версии. Более ранние версии HTTP способны передать те же сообщения, но дают заметно худшую производительность^[1].

Успешный код состояния HTTP из диапазона 2xx возвращается для любого корректного DNS-ответа, включая ответы с кодами ошибок DNS — например, SERVFAIL или NXDOMAIN. Неуспешные коды HTTP означают отсутствие ответа на исходный вопрос, и клиент обрабатывает их по обычным правилам HTTP: повторяет запрос к тому же серверу при ошибке авторизации либо обращается к другому серверу при неподдерживаемом типе содержимого^[1].

Использование механизма server push ограничено: клиент не имеет права применять для разрешения имён данные, полученные с URI, который не входит в его конфигурацию, даже если такой URI обнаружен через server push или сервер прислал незапрошенный ответ, похожий на корректный^[1].

Клиентом может выступать как приложение — прежде всего браузер, — так и системный сервис или локальный прокси, преобразующий обычные запросы на порт 53 в запросы DoH для всей операционной системы^[9].

Шифрование канала лишает промежуточные узлы возможности вести журнал запрашиваемых доменных имён: ни оператор связи, ни владелец точки доступа, ни атакующий в той же сети не видят, какие домены запрашивает пользователь^[3].

Защита остаётся частичной. Сам стандарт указывает, что каждый уровень стека — IP, TCP, TLS, HTTP — несёт собственные механизмы корреляции запросов: адрес клиента, cookie сессии TLS и TCP Fast Open, HTTP cookie, заголовки User-Agent и Accept-Language. По этой причине принимать HTTP cookie клиентам DoH не рекомендуется, если это не требуется явным сценарием использования^[1]. Выбранный резолвер по-прежнему видит и адрес клиента, и содержимое запросов; эту проблему решает расширение ODoH, которое поддерживает, в частности, резолвер Cloudflare в роли цели по адресу odoh.cloudflare-dns.com^[7].

Проверка серверного сертификата и целостность защищённого соединения препятствуют подмене и модификации DNS-трафика на пути, а также снимают характерные для UDP-версии DNS сценарии атак с усилением трафика^[1][10].

При этом HTTPS защищает лишь участок между клиентом и резолвером и не даёт той целостности данных DNS, которую обеспечивает DNSSEC. Стандарт прямо называет DoH и DNSSEC независимыми и полностью совместимыми протоколами, решающими разные задачи: клиент либо проводит проверку DNSSEC самостоятельно, либо доверяет её резолверу и опирается на бит AD в полученном сообщении^[1].

DoH использует тот же порт 443, что и обычный веб-трафик, поэтому его запросы маскируются среди прочих соединений HTTPS и с точки зрения администратора сети выглядят как обращения к сайтам и веб-приложениям^[10][11]. Мультиплексирование нескольких обменов в одном соединении и кэширование GET-запросов позволяют сократить задержки при разрешении множества имён^[1][8].

Массовое внедрение DoH на уровне браузеров переносит разрешение имён от резолвера оператора связи к небольшому числу крупных провайдеров, задаваемых по умолчанию. Критики указывают, что это концентрирует данные о просмотре у нескольких компаний, а не устраняет наблюдение как таковое; включение DoH по умолчанию в Firefox с резолвером Cloudflare обсуждалось именно в этом ключе^[12][13].

Стандарт прямо отмечает, что системы фильтрации и инспекции, рассчитанные на незащищённый транспорт DNS, в среде DoH работать не будут из-за конфиденциальности и целостности, обеспечиваемых TLS^[1]. На практике протокол обходит настройки DNS, заданные в сети или на устройстве, из-за чего перестают действовать родительский контроль, корпоративные политики доступа и предписанная законом блокировка ресурсов.

Заблокировать сам протокол также непросто. DNS over TLS отсекается по номеру порта, тогда как DoH приходится фильтровать по IP-адресам, значению расширения SNI в TLS и сочетанию с номером порта, а перечни известных DoH-резолверов неполны, что не позволяет администратору перекрыть все такие соединения^[14].

В 2019 году Ассоциация интернет-провайдеров Великобритании (ISPA) включила Mozilla в число претендентов на антипремию «Интернет-злодей года» за намерение включить DoH по умолчанию, полагая, что это подорвёт национальные механизмы фильтрации. После волны критики ассоциация отозвала как саму номинацию, так и категорию целиком, сохранив при этом возражения против протокола; Mozilla заявила, что не будет включать DoH по умолчанию в Великобритании^[15].

Установление защищённого соединения и обработка HTTP добавляют накладные расходы по сравнению с одиночной UDP-датаграммой. Стандарт описывает и специфические эксплуатационные сложности: возможен взаимоблокирующий сценарий, когда проверка отзыва сертификата по OCSP или загрузка списка отзыва сама требует разрешения имени, а также задача первоначальной загрузки, при которой клиент не может разрешить имя своего DoH-сервера через этот же сервер. Кроме того, DoH не даёт гарантий порядка обработки разных запросов и не может служить транспортом для протоколов, требующих строгой упорядоченности^[1].

Выбор резолвера влияет на результат разрешения: при локальных политиках или расщеплённой конфигурации DNS разные серверы дают разные ответы на один вопрос, что может нарушить, например, работу трансляции адресов DNS64^[1]. Для администраторов усложняется диагностика, поскольку DNS-обмен более не выделяется в отдельный поток трафика.

DNS over TLS (DoT), стандартизированный в 2016 году документом RFC 7858, также шифрует DNS-обмен и не позволяет подделать или изменить трафик, но передаёт сообщения непосредственно поверх TLS на выделенном порте 853, без слоя HTTP. Из-за отдельного порта такой трафик легко выделяется и фильтруется, зато он прозрачнее для сетевого администрирования и мониторинга^[10][14]. Форматы полезной нагрузки различаются: в DoT сообщение предваряется двумя байтами длины, которых в DoH нет^[1].

DNSCrypt шифрует и аутентифицирует обмен между клиентом и резолвером, предотвращая подмену ответов, однако не проходил процедуру стандартизации IETF и не описан отдельным RFC. Протокол распространён главным образом через клиент dnscrypt-proxy, который умеет работать и как клиент DoH; ряд публичных операторов, включая AdGuard DNS и Quad9, предоставляет конечные точки одновременно по DNSCrypt, DoH и DoT^[9][23].

Классический DNS передаёт запросы открытым текстом по UDP или TCP на порте 53. Он остаётся наиболее быстрым по накладным расходам и полностью прозрачным для сетевых средств управления, но уязвим и для пассивного наблюдения, и для активного вмешательства устройств на пути следования трафика^[1][2].