Что такое doh сервер
Что такое DNS-over-HTTPS и как настроить это в браузере?
Технология «DNS поверх HTTPS» (DNS-over-HTTPS, DoH) помогает защитить пользователей от сбора данных на сайтах и последующей их продажи рекламодателям. Конфиденциальность достигается за счёт шифрования запросов посетителя к веб-ресурсу. Разберёмся в нюансах технологии и расскажем, как правильно настроить DoH в браузере.
Введение
Ежедневно мы посещаем различные ресурсы в интернете, связанные с образованием, профессиональной информацией, развлечениями, интересами, товарами и прочим. Запросы в адрес различных ресурсов могут вполне определённо идентифицировать человека, определить сферу и род его деятельности, интересы и желания. Не всем пользователям нравится, что кто-то, будь то государство, провайдер или сторонние организации, может полностью отслеживать их поведение в интернете. Более того, такая информация продаётся сторонним лицам, которые занимаются таргетированной рекламой, отсюда надоедливые баннеры с информацией о ваших запросах на различных сайтах.
Обеспечить анонимность запросов призвана технология «DNS поверх HTTPS» (далее — DoH).
DNS и угрозы безопасности
DNS — это служба помогающая пользователям взаимодействовать с сайтами в интернете. Подробное её описание можно найти здесь.
В контексте DNS-запросов и возможного злоупотребления ими существует две основных угрозы безопасности пользователей: трекинг и спуфинг.
О трекинге было отчасти упомянуто выше: это сбор информации о запросах пользователя и продажа её сторонним лицам. Даже если дома или на работе используются надёжные DNS-серверы, в общественных местах всегда есть вероятность подключиться к беспроводной сети с небезопасным DNS-сервером, который будет отслеживать все ваши запросы и передавать их куда не следует.
Спуфинг — это реализация атаки «Человек посередине» (Man-in-the-Middle, MitM). Злоумышленник, который видит ваши запросы, может подменить ответ от DNS-сервера и направить вас на вредоносный или фишинговый сайт. Если пользователь не будет внимателен в таких случаях, это может закончиться установкой различных вредоносных программ на компьютер и раскрытием данных (аккаунтов, паролей, данных о платёжных картах), что делает эту угрозу особенно опасной. Частично проблема решается технологией DNSSEC, использующей принцип асимметричного шифрования с открытым ключом. Все ответы от DNS-сервера подписаны цифровой подписью, проверить подпись может любой, а для подписания используется секретный ключ.
Что такое «DNS поверх HTTPS»
В октябре 2018 года инженерный совет интернета (IETF) опубликовал документ RFC 8484, в котором была описана технология DoH. В ней DNS-запросы выполняются с использованием технологии HTTPS. Для обмена по этому протоколу должны быть установлены сертификаты открытого и закрытого ключей. Данные шифруются закрытым ключом и расшифровываются с помощью открытого. Клиент и сервер обмениваются ключами, после чего все данные передаются в зашифрованном виде. Таким образом, при использовании этой технологии ваши запросы к DNS-серверу и ответы от него будут передаваться в зашифрованном виде.
Технология DoH используется популярными браузерами Chrome и Firefox, а также публичными DNS-серверами от Google, Cloudflare, OpenDNS и др.
Стоит отметить, что не все DNS-запросы от вас будут передаваться в зашифрованном виде. Вначале DNS-серверу будет передан запрос содержащий имя ресурса — SNI (Server Name Indicator). SNI используется протоколом шифрования TLS для запроса сертификата определённого ресурса, благодаря чему на одном IP-адресе в интернете могут размещаться разные сайты. Соответственно, ваш провайдер и маршрутизаторы на пути следования запроса будут его видеть, но после установки соединения всё будет зашифровано. Таким образом, остаётся проблема раскрытия имени ресурса при первоначальном запросе.
Для её решения была разработана технология Encrypted Server Name Indicator (ESNI). Это расширение протокола TLS, позволяющее шифровать SNI публичным ключом DNS-сервера. Использование этой технологии может затруднить доступ к некоторым сайтам, если провайдер использует систему фильтрации DPI, поскольку она проверяет SNI и отбрасывает запрос, если индикатор скрыт.
Как настроить DoH в вашем браузере
Настройка очень проста, приведём примеры её выполнения в двух популярных браузерах — Mozilla Firefox и Google Chrome.
Mozilla Firefox
Если вы пользуетесь Mozilla Firefox, перейдите в «Настройки», в разделе «Основные» прокрутите до «Параметры сети» и нажмите кнопку «Настроить», внизу поставьте галочку на «Включить DNS через HTTPS». По умолчанию используется сервер Cloudflare, при необходимости можно заменить его на другой.
Рисунок 1. Настройка DoH в Mozilla Firefox
Google Chrome
При работе с Chrome откройте «Настройки», далее — вкладка «Безопасность» в разделе «Конфиденциальность и безопасность». В разделе «Дополнительные» включите опцию «Использовать безопасный DNS-сервер». Можно использовать DoH с DNS-сервером имеющегося поставщика услуг, выбрать готовый вариант из списка рекомендуемых или указать другой сервер.
Рисунок 2. Настройка DoH в Chrome
Злоупотребление DoH
Для защиты информационной инфраструктуры компаний и ведомств применяются антивирусы, системы обнаружения и предотвращения вторжений. Эти средства обеспечения безопасности используют сигнатурный анализ вредоносной активности. При обработке сетевого трафика, в частности, проверяется тело пакета данных. Средства защиты сравнивают запросы, команды, пути и другую информацию в сетевом пакете с базой своих сигнатур, и при выявлении совпадений происходит блокировка.
Сейчас появляются вредоносные программы, которые злоупотребляют DoH, используя эту технологию для установки шифрованного соединения между заражённым компьютером и командно-контрольным сервером (C&C). Запросы и ответы будут зашифрованы, поэтому не удастся обнаружить и заблокировать вредоносную активность с помощью описанных средств защиты информации. Поэтому злоупотребление DoH является очень привлекательной возможностью для злоумышленников.
Ограничение использования технологии DoH
Многие организации, занимающиеся информационной безопасностью, собирают события со своих DNS-серверов для мониторинга вредоносной активности. По DNS-запросам можно определить целевые атаки на информационные системы, а также выявить заражение компьютеров вредоносными программами. Также на их основе создаются правила корреляции для SIEM-систем. Поэтому использование DoH сильно затрудняет мониторинг вредоносной активности. Для решения проблемы были придуманы «канареечные» (проверочные) домены. Для отключения DoH нужно добавить запись с таким доменом на локальный DNS-сервер. Например, Firefox проверяет имя «use-application-dns.net», и если DNS-сервер ответит ошибкой на запрос такого имени, браузер будет использовать DoH. В обратном случае информация о таком домене будет получена и DoH использоваться не будет.
Кроме того, в популярных DNS-серверах реализована функция родительского контроля (ограничения ресурсов нежелательных для детей); соответственно, при использовании DoH её работа будет некорректной. Эта проблема также решается с помощью «канареечных» доменов, но имена будут запрашиваться уже у публичных серверов. Информация о том, какие именно имена используются для отключения DoH при использовании конкретного сервиса, не разглашается.
Выводы
Технология DoH полезна и заслуживает повсеместного использования. Вы можете повысить свою анонимность и безопасность, выполнив несложную настройку браузера. DoH поддерживается популярными браузерами и DNS-серверами. Сейчас, когда прошло почти три года с момента создания технологии, пользователь не ощутит никаких трудностей в её использовании. Стоит, впрочем, заметить, что периодически появляются новости о возможном запрещении технологий использующих криптографические алгоритмы для скрытия имён запрашиваемых ресурсов, что не может не беспокоить ИТ-специалистов.
Глубокий в-DoH. Разбираемся, как работает DNS over HTTPS и кому (не) выгодно его внедрение
Содержание статьи
Шаткая скрепа DNS
Для порядка и связности изложения кратко вспомним основные понятия. Система доменных имен DNS — одна из технологий, лежащих в самой основе современного интернета. С ее помощью соотносятся числовые IP-адреса и более удобные для человека доменные имена. Она построена по принципу иерархического взаимодействия DNS-серверов.
Важный момент: разрабатывалась эта система еще в 1983 году, и поэтому у нее есть некоторые проблемы с безопасностью. Ведь интернет тогда, как известно, был сетью, которая связывала американские научные и военные учреждения, и подключать к ней кого попало не планировалось.
Если вкратце, то корень проблемы в том, что базовая система DNS принимает и передает любые запросы, поступающие в нее. Как во многих других решениях, которые появились на заре интернета, защиты от злонамеренного использования здесь нет. В те времена считалось, что главное — это простота и масштабируемость.
В результате появились разные методы атак на DNS-серверы (например, отравление кеша DNS или перехват DNS). Результат таких атак — перенаправление клиентских браузеров куда-то, куда пользователи попадать не собирались.
Для борьбы с этими бедами Инженерный совет интернета разработал набор расширений DNSSEC, который добавил к DNS-запросам подпись-аутентификацию на основе криптографии с открытым ключом. Но разрабатывался этот набор расширений очень долго. Проблема стала очевидной еще в начале девяностых, направление работы над проблемой определили к 1993 году, первую версию DNSSEC подготовили к 1997 году, попытались внедрить, стали вносить изменения.
Если хочешь подробнее разобраться, от каких угроз DNSSEC должен был защитить DNS, то можешь почитать доклад об анализе угроз того самого Инженерного совета интернета от 2004 года. Как пишут его авторы, спустя десять лет после начала работ настало время отчитаться о том, с какими проблемами и как именно мы собираемся бороться.
Но DNSSEC решает только часть проблемы — он гарантирует аутентичность и целостность данных, но не их приватность. В борьбе за эту цель логичным средством выступает шифрование. Вопрос в том, как именно его реализовать.
Варианты шифрования
Несколько групп разработчиков предложили свои варианты технологических решений. Среди них есть те, которые используют оригинальные способы шифрования, например DNSCrypt или DNSCurve, в котором применяется шифрование с использованием эллиптических кривых. Но решения, оказавшиеся в итоге более популярными, опираются на широко распространенный протокол безопасности TLS. Такими решениями являются DoT (DNS over TLS) и DoH, основной предмет этой статьи.
DoT, как и следует из его названия, использует для зашифрованной передачи DNS-запросов сам протокол TLS. Это влечет за собой смену основных портов и протоколов — вместо UDP по порту 53 используется TCP по порту 853.
DoH устроен иначе и по-другому использует TLS. В DoH TLS-шифрование применяется на уровне протокола HTTPS, с использованием HTTPS-запросов и обращением к HTTP-портам DNS-сервера.
Звучит сложновато? Ян Шауман рассказывает об этом очень точно и доходчиво:
Поскольку HTTPS использует TLS, можно было бы позанудствовать и подоказывать, что технически DoH — это тоже DNS через TLS. Но это было бы неверно. DoT отправляет запросы базового протокола DNS через TLS-соединение на отдельном выделенном порте. DoH использует протокол HTTP на уровне протокола прикладного уровня (HTTP application layer protocol), чтобы отправлять запросы на HTTPS-порт сервера, используя и включая все элементы обычных сообщений HTTP.
DoHодим до сути
Здесь резонно задаться вопросом: а в чем вообще тут может быть проблема? Чем больше безопасности, тем лучше, разве не так?
Ответ на этот вопрос лежит в нюансах выбранных решений, их сильных и слабых сторонах. А именно в том, как новая технология взаимодействует с разными участниками системы DNS, кого из них ее разработчики считают условно заслуживающими доверия, а кого — источниками угрозы. И речь сейчас даже не о хакерах-злоумышленниках, имеющих откровенно преступные цели.
Речь о том, что между пользовательским устройством и конечным сайтом находятся посредники. Администратор сети, файрвол, провайдер интернета — все они могут в своих интересах взаимодействовать с системой DNS, задавая своим резолверам имен DNS настройки того, какие запросы отслеживать, блокировать, модифицировать. Так можно встраивать рекламу, отсекать вредоносный контент, не пускать на определенные ресурсы.
Путь запроса от клиента до сервера может проходить через множество резолверов
DoT, работая через TLS с его системой сертификатов доверия, точно так же нуждается в DNS-резолвере, которому он сможет доверять. Присутствует гибкая возможность настройки списка доверенных резолверов, возможность централизованного изменения настроек в предварительно доверенной (например, корпоративной) среде, а также возможность переключаться обратно на базовый DNS, если с новой версией возникнут проблемы.
Поскольку для DoT используется новый, выделенный порт, возможно заметить передаваемый трафик и наблюдать за его объемами, шифрование этому никак не помешает. При желании можно даже заблокировать его вовсе.
В общем, DoT нужно грамотно настроить, но зато он содержит некоторые крайне полезные для системных администраторов и сетевых инженеров функции. Поэтому многие из профессионалов и хвалят за это DoT.
С DoH история другая. Эта технология разрабатывалась с расчетом на пользовательские приложения, а именно — браузеры. Это ключевая деталь во всей этой истории. Означает она вот что. При использовании DoH весь трафик, который не относится к браузерам, идет через базовый DNS, но браузерный трафик при этом обходит любые настройки DNS — на уровне операционной системы, локальной сети, провайдера — и, минуя промежуточные этапы, по HTTPS попадает сразу к поддерживающему DoH резолверу DNS.
И к этой схеме есть ряд серьезных вопросов.
Коварные злодеи и теории заговора
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
DNS-доступ под защитой: DoT и DoH
Автор статьи: Александр Венедюхин, ведущий аналитик ТЦИ
Технологии DNS-over-TLS (DoT) и DNS-over-HTTPS (DoH) предназначены для защиты DNS-трафика (запросов и ответов) от перехвата и подмены. В базовых протоколах DNS исторически нет эффективных механизмов защиты, которые отвечали бы развитой модели угроз современного Интернета. DoT и DoH возникли как ответ на изменение ландшафта атак. Они определяют новый транспорт для передачи DNS-информации, то есть не изменяют саму систему доменных имён, но добавляют защищённый способ работы с DNS для приложений.
Аббревиатура DNS традиционно обозначает два фундаментальных для Интернета технологических механизма: систему доменных имён и службу (или сервис) доменных имён. Система доменных имён представляет собой распределённую базу данных с иерархической структурой, в которой хранятся пары «ключ – значение». Служба доменных имён — инструмент, выполняющий поиск в этой базе данных. Типичное применение DNS – это поиск IP-адреса, соответствующего имени сервера (имени хоста): здесь система доменных имён хранит пару «имя хоста – IP-адрес» (соответствующая структура называется «A-запись»), а служба выполняет рекурсивный опрос DNS-серверов и находит требуемый ответ (либо обнаруживает, что заданному имени хоста никакой IP-адрес в DNS не сопоставлен).
Каждый шаг сценария работы пользователя с вебом, как с основным пользовательским сервисом Интернета, задействует, прямо или косвенно, DNS. Для того, чтобы веб-браузер смог загрузить код разметки и отобразить веб-страницу по заданному адресу, часто требуются десятки DNS-запросов. Обычно эти запросы обслуживаются не клиентским компьютером, а внешними серверами. Поэтому возможны утечки информации о том, к каким веб-узлам подключался данный пользователь. Естественно, утечки касаются не только веб-протоколов. Более того, DNS позволяет реализовать сложные схемы идентификации пользователей, основанные на построении профилей активности. DNS-over-TLS и DNS-over-HTTPS делают некоторые из каналов таких утечек неэффективными, повышая тем самым «приватность пользователя». Это одна из решаемых данными технологиями задач, но не единственная.
Утечки информации
Может показаться, что провайдер доступа и так знает по IP-адресам все узлы, к которым обращается пользователь, а поэтому просмотр DNS-запросов не даёт никакой новой информации. Это не так. Дело в том, что DNS предоставляет информацию другого уровня — уровня приложений, поэтому позволяет, в том числе, собирать данные, принципиально недоступные на более низком уровне. Прежде всего, DNS раскрывает имена узлов, а это совсем не то же самое, что IP-адреса. Часть DNS-трафика относится к различным вспомогательным протоколам (например, каталогизация на стороне приложения адресов доступных узлов, обращения к которым по IP может и не происходить). DNS играет важную служебную роль во многих протоколах, раскрывая их специфические характеристики (примеры здесь разнообразны: инструменты для майнинга криптовалют, мессенджеры, системы телеконференций, системы IP-телефонии и так далее).
Нередко информация о DNS-активности утекает даже при использовании VPN (Virtual Private Network — виртуальная частная сеть), если в защищённую виртуальную сеть направлен только основной IP-трафик, а обработка DNS оставлена резолверу провайдера доступа (согласно системной конфигурации).
В случае HTTPS для веба, работающего поверх TLS, имя сервера, с которым соединяется программа-клиент (браузер), обычно передаётся в открытом виде — то есть, оно может быть извлечено из TCP-потока на промежуточном узле. Однако существует технология (ESNI, а точнее – современная её версия, ECH – Encrypted Client Hello), которая позволяет клиенту зашифровать имя сервера в TLS. Соответственно, без DNS-трафика промежуточные узлы провайдера увидят только IP-адрес веб-узла, а один IP-адрес может соответствовать нескольким тысячам веб-узлов.
Таким образом, прослушивание DNS поставляет много важной информации о работе клиента на уровне приложений. Естественно, анализировать DNS-запросы, извлекая их из трафика, может не только провайдер доступа, но и вообще любой промежуточный узел, если только DNS-трафик не зашифрован.
DoH и DoT зашифровывают трафик, исключая только что описанную утечку. Естественно, для защиты клиентского DNS-трафика данные технологии должны внедряться на пути от клиента до рекурсивного резолвера (это минимум — см. ниже). Типовая конфигурация сейчас подразумевает, что поддержка DoH включена прямо в браузере, а в качестве рекурсивного резолвера сконфигурирован тот или иной внешний DNS-сервис. Например, для браузера Firefox это может быть сервис Cloudflare, который рекомендует Mozilla (и не только рекомендует, но может и включить по умолчанию). Ключевой момент такой конфигурации, – обозначающий, ни много ни мало, смену парадигмы, – состоит в том, что приложение (браузер) работает с DNS, минуя и локальную системную службу, и резолвер провайдера доступа. Браузер по защищённому каналу обращается к другому приложению, работающему на внешнем сервере, и доверяет именно ему в поиске DNS-информации.
Протокольные надстройки
С точки зрения стороны, анализирующей трафик, ситуация выглядит следующим образом: вместо DNS-запросов и DNS-ответов обнаруживается только факт установления TLS-соединения между клиентом и сервером с некоторым IP-адресом. Так как DNS работает внутри TLS-соединения, а оно зашифровано, то никаких сведений об использовании DNS анализатор трафика не получает. Однако, так как речь идёт только о «последней миле», то есть о канале от клиента до рекурсивного резолвера, оператор резолвера видит всю DNS-активность своего клиента. Но это, обычно, внешний резолвер, недоступный провайдеру доступа. DNS-over-HTTPS использует для отправки запросов и получения ответов сервера протокол HTTP (рекомендован HTTP/2). Надо отметить, что это довольно серьёзная «надстройка» для DNS.
Действительно, классическая конфигурация DNS базируется на UDP в качестве основного транспорта. UDP – один из древнейших протоколов Интернета, предоставляющий простой механизм отправки пакетов, без сессий и, соответственно, без гарантии доставки. Несмотря на такие ограничения, UDP — очень и очень быстрый протокол, приближающийся к оптимальным показателям на уровне сетевой аппаратуры. По этой причине UDP используется не только в DNS, но, например, и в многопользовательских играх, где важна минимальная задержка при доставке пакетов данных.
А вот реализация DoH требует и HTTP/2, и TLS, и TCP, и всё это не отменяет DNS, хоть последний протокол и преломляется существенно в ходе приспособления к HTTP. В сравнении с UDP-транспортом увеличение сложности тут огромное. А обусловлен такой выбор тем, что готовая поддержка HTTPS распространена как на клиентах, так и на серверах. В более важном здесь случае с клиентом (речь про браузеры), где, по понятным причинам, обязательно имеется интерфейс доступа к HTTP «на уровне исходных данных», реализация «заворачивания» DNS в HTTPS не требует разработки объёмных дополнительных модулей. (На стороне сервера DoH сейчас поддерживается основными пакетами, например, Unbound и PowerDNS.)
DNS-over-TLS содержит меньше уровней: здесь предполагается, что сообщения DNS передаются внутри защищённой TLS-сессии, но, по сути, это те же DNS-сообщения и та же схема обмена. В частности, поддержку DoT можно реализовать для DNS-сервера без всяких доработок последнего, просто добавив на сервере TLS-туннель, преобразующий DNS-запросы/ответы из защищённой формы в открытую и обратно. (Несомненно, «прозрачная» трансляция возможна и для DoH, но этот вариант потребует больше уровней.) Так как DoT предоставляет только некоторую обёртку вокруг классического протокола DNS, эту технологию можно применять не только на «последней миле», разделяющей клиента и рекурсивный резолвер провайдера, но и между рекурсивным резолвером и авторитативными серверами. То есть при широком распространении DoT, и рекурсивный опрос может выполняться полностью в защищённом виде.
Процесс рекурсивного опроса DNS подразумевает отправку запросов авторитативным серверам имён, то есть серверам, которые поддерживают заданную зону. Если третья сторона прослушивает трафик на каком-то промежуточном узле, и через этот узел проходят в открытом виде пакеты DNS, адресованные некоторому авторитативному серверу, то эта третья сторона сможет видеть состав DNS-запросов и DNS-ответов. Однако такая утечка уже является весьма размытой: во-первых, прослушивающая сторона видит только некоторую часть запросов, скорее всего, небольшую; во-вторых, связать конкретные запросы с конкретным клиентом DNS-резолвера очень сложно, особенно если вести речь об универсальном методе. Тем не менее, внедрение DoT на пути от рекурсивного резолвера к авторитативному серверу исключит и эту возможность.
Использование TLS позволяет побороть и другую угрозу, активную. В классическом случае локальный узел, отправивший запрос внешнему DNS-резолверу, не может определить, кто именно прислал ответ. Это касается и UDP, и, в меньшей степени, TCP. Дело в том, что ответить вместо узла с заданным IP-адресом может любой промежуточный узел. Это не составляет большого труда, хотя и требует вмешательства в работу сетевого оборудования. Пакет, отправленный к (условному) резолверу по адресу 1.1.1.1, до «подлинного» обладателя этого IP-адреса не дойдёт, а клиент получит ответ от близкого к нему промежуточного узла. И, в случае DNS-запроса, ответ этот может быть произвольным. TLS позволяет клиенту аутентифицировать сервер (и наоборот, но аутентификация клиента используется редко), после чего продолжать работу только с узлом, который смог подтвердить свою подлинность. Для практических приложений, в случае DoH, такая проверка скорее обязательна, а для DoT в современном состоянии клиент на практике может легко пропустить шаг аутентификации сервера.
Технологический ландшафт и фильтрация
Для DNS существует и более старая технология защиты адресной информации от подмены — DNSSEC. Нужно заметить, что ни DoT, ни DoH не отменяют DNSSEC, так как работают на совсем другом уровне: DoT/DoH защищают DNS-трафик только в момент передачи через промежуточные узлы; DNSSEC защищает при помощи механизма электронной подписи подлинность и неизменность самой информации DNS. При этом DNSSEC никак не скрывает запросы или ответы серверов: данные передаются в открытом виде. Однако, если клиент умеет проверять подписи DNSSEC и знает корневой открытый ключ глобальной DNS, то для такого клиента не имеет значения, как именно получены DNS-данные, от доверенного узла или нет, — валидная подпись гарантирует, что данные не были изменены и сформированы авторизованным источником. А вот если клиент подключился по DoT или DoH к злонамеренному DNS-резолверу, то эти технологии никак не помогут клиенту отличить верный DNS-ответ, присланный резолвером, от поддельного, который этот же резолвер сгенерировал, поскольку они гарантируют только подлинность узла-резолвера, но не DNS-информации. Иными словами, DoT/DoH и DNSSEC — совершенно разные технологии, которые могут эффективно дополнить друг друга.
Ещё одной важной отличительной чертой DoH и DoT при применении между клиентом и резолвером является номер используемого сервером порта TCP. Как известно, TCP-соединения, помимо прочей информации, характеризуются номерами портов. Есть так называемые «хорошо известные» номера, которые соответствуют конкретным типам сервисов (серверных служб). Так, за HTTP закреплён номер 80. А за HTTPS — номер 443. DNS соответствует номер порта назначения 53 (и для UDP, и для TCP). Чтобы различать классический вариант DNS и DoT, для последнего выделен номер порта 853. Номер уникальный, а это означает, что соединения DoT можно фильтровать на уровне сетевого транспорта просто по номеру порта и надеяться, что при этом у пользователя не сломается вообще всё, а только лишь исчезнет возможность использовать внешний сервис DNS-резолвера.
Ситуация с DoH совсем другая: предполагается, что данный протокол работает по HTTPS на номере порта 443, то есть точно так же, как и привычный доступ к веб-узлам по HTTPS. Если же кто-то решится заблокировать весь трафик по номеру 443, то таким образом этот кто-то отключит и все значимые веб-узлы, для которых HTTPS давно является основным протоколом (в двадцатых годах двадцать первого века веб-сайт не должен использовать незащищённый протокол HTTP, за исключением, быть может, весьма экзотических случаев обратной совместимости). Несомненно, дополнительные затруднения, связанные с тем, что отличить DNS внутри HTTPS от «обычного» HTTPS доставки веб-страниц сложно, могут составить ценное преимущество. Или составить критический недостаток, который испортит всё дело. Тут, как иногда говорят матёрые адвокаты, многое «зависит от того, на чьей стороне выступаем».
Что означает возможное повсеместное распространение DoT и DoH в приложениях с точки зрения информационно-технологической архитектуры? Прежде всего, клиенты «внезапно» начинают использовать для обнаружения DNS-информации внешние (относительно привычной архитектуры) узлы. Когда поддержка сторонних сервисов DNS встроена непосредственно в браузер, то пользователю даже не нужно знать, как изменить настройки DNS в операционной системе — браузер в этом вопросе от операционной системы уже не зависит.
При помощи DNS нередко осуществляется ограничение доступа к тем или иным ресурсам, например, к небезопасным доменам (в том числе в рамках «антивирусной защиты»). Другой случай — отдельная адресация для внутренних ресурсов, то есть для узлов, находящихся в локальной сети: собственный резолвер может знать имена этих ресурсов и, при получении DNS-запроса, отвечать локальным клиентам правильным адресом. И первый, и второй случаи распространены в корпоративных средах, а также часто используются на этапе разработки интернет-сервисов. Всё это ломается, если на компьютере пользователя сконфигурирован внешний, неподконтрольный локальному системному администратору, резолвер DNS. И если администраторы корпоративной сети могут надеяться обнаружить использование внешнего DNS-резолвера простыми методами, то трафик DoH способен доставить им проблемы.
Естественно, никто не мешает настроить поддержку DoT/DoH на внутреннем DNS-резолвере, будь то корпоративный резолвер или резолвер провайдера доступа. В таком случае останется доступным даже пассивный анализ трафика. Дело в том, что оператор резолвера может выгружать на инспектирующий узел секретные ключи TLS, а это позволяет расшифровывать трафик. Но данный ход не отменяет возможности использования других резолверов и не упрощает обнаружение факта такого использования.
Сложившаяся практика внедрения DoH/DoT (в особенности — DoH) очень хорошо показывает, что хоть сами технологии и не подразумевают какой-то дополнительной централизации, эта централизация всё же происходит: повсеместно используют DNS-сервисы лишь от нескольких глобальных провайдеров (прежде всего, Cloudflare и Google), которые поддерживают работу через DNS-over-HTTPS. Более того, эта технология, скорее всего, достаточно быстро разовьётся в конфигурацию, когда браузер будет получать всю нужную вспомогательную информацию по HTTPS из единого источника. Под «всей нужной» информацией здесь подразумеваются и DNS, и, собственно, HTTP, и различные дополнительные ресурсы, требуемые для извлечения и отображения веб-страниц: адреса CDN (Content Delivery Network – служба доставки контента), криптографические ключи и т. д. То есть возникнет новый протокол (уже не как DoH, а под другим названием) обнаружения параметров доступа к серверным приложениям. И этот протокол будет работать через некоторую единую «точку входа».Сразу после старта браузер будет подключаться к указанному в настройках узлу, – естественно, проверив подлинность, – получать текущие параметры DNS, а также списки резервных узлов доступа, перечни TLS-сертификатов, коллекции криптографических ключей, описания и адреса CDN, прокси-серверов, различных «веб-ускорителей» и, вероятно, даже доступ к VPN. В сформированной среде браузер, как приложение, будет взаимодействовать с другими доверенными приложениями на различных серверах. Для стороны, пытающейся фильтровать трафик, либо собирать метаинформацию об активности пользователя, весь трафик различных пользователей будет выглядеть одинаково, отличаясь лишь IP-адресами узлов, да и то, далеко не так сильно, как сейчас. Попытка блокирования доступа к узлам по IP-адресу приведёт либо к полной неработоспособности для пользователя непредсказуемого по составу набора приложений, либо к простой замене IP-адресов для преодоления блокировки: новые адреса будут переданы (например) браузеру в рамках только что описанного протокола обнаружения.