В России начали блокировать протоколы DoH и DoT
С середины августа 2026 года абоненты некоторых российских операторов стали массово сталкиваться с проблемами при использовании защищённого DNS. Сбои зафиксированы в сетях "Ростелекома", "Дом.ру", "Таттелекома", SkyNet и "Билайна". У пользователей перестали отвечать зашифрованные DNS-сервисы Google и Cloudflare.
Речь не о временных задержках и не о нестабильной маршрутизации. Подключения к одним протоколам принудительно сбрасываются, а другие зависают до истечения тайм-аута. Характер неисправности позволяет предположить, что проблема связана не с самими DNS-сервисами, а с фильтрацией трафика на стороне операторской инфраструктуры.
Как работает защищённый DNS
Обычный DNS передаёт запросы по UDP на порт 53 без шифрования. Провайдер или промежуточное оборудование видит, какой домен запрашивает пользователь, и при необходимости может подменить ответ. Такой способ блокировки сайтов известен как DNS-спуфинг.
Для защиты от перехвата применяются два основных протокола.
DoT (DNS over TLS) передаёт DNS-запросы внутри TLS-соединения. Для этого обычно используется отдельный TCP-порт 853.
DoH (DNS over HTTPS) маскирует DNS-трафик под обычные HTTPS-запросы. Соединение устанавливается через порт 443 - тот же порт, который используют сайты, интернет-магазины, банковские приложения и государственные сервисы.
На уровне назначения протоколы похожи: в обоих случаях запрос шифруется. Однако для систем фильтрации они заметно различаются.
Что именно происходит с подключениями
При проверке DoT-соединения с Cloudflare через утилиту, работающую с DNS over TLS, стандартное TCP-рукопожатие проходит успешно: клиент отправляет SYN, получает SYN-ACK и завершает установку соединения пакетом ACK. Это означает, что IP-адрес сервера не заблокирован полностью.
После начала TLS-сеанса соединение принудительно закрывается пакетом RST. Такое поведение характерно для активного вмешательства посредника в канал связи. Иными словами, оборудование видит подключение к порту 853 и сбрасывает его.
С DoH картина иная. TCP-соединение устанавливается, клиент отправляет TLS ClientHello, после чего ответа нет. Соединение не закрывается явно, но и не развивается дальше. Через некоторое время приложение сообщает о тайм-ауте.
Подобная "чёрная дыра" обычно указывает на пассивное отбрасывание пакетов системой глубокой инспекции трафика - DPI. Фильтр не посылает клиенту команду закрыть соединение, а просто перестаёт пропускать соответствующий поток.
При этом обычные DNS-запросы на адрес 8.8.8.8 через UDP-порт 53 у части абонентов продолжают работать. Это важная деталь: ограничение, судя по всему, направлено не на IP-адреса Google и Cloudflare целиком, а на определённые признаки трафика.
Почему DoT заблокировать проще
Для DoT достаточно обнаружить соединение с портом 853. Этот порт редко используется для других задач, поэтому правило вида "сбросить или отбросить трафик на TCP 853" относительно легко реализовать даже на периферийном сетевом оборудовании.
Фильтру не обязательно анализировать содержимое пакетов или расшифровывать TLS. Достаточно проверить адрес назначения и номер порта. Поэтому блокировка DoT может работать быстро, стабильно и с минимальной вероятностью затронуть легитимные сервисы.
DoH устроен сложнее для фильтрации. Полностью закрыть порт 443 невозможно: это практически парализовало бы современный интернет. Поэтому системе приходится отличать защищённый DNS от обычного HTTPS-трафика.
Как распознаётся DoH
Несмотря на шифрование, при установлении TLS-соединения клиент передаёт некоторые служебные данные. В частности, фильтр может увидеть поле SNI - имя домена, к которому выполняется подключение. Для публичных DNS-сервисов это, например, dns.google или cloudflare-dns.com.
Дополнительно анализируются:
- наборы поддерживаемых шифров;
- значение ALPN;
- последовательность параметров TLS;
- особенности реализации клиента;
- сетевой отпечаток, включая JA3;
- характер и частота последующих запросов.
По совокупности признаков DPI способен предположить, что HTTPS-соединение используется не браузером для просмотра сайта, а конкретной библиотекой DoH. После этого поток может быть отброшен или принудительно разорван.
В TLS 1.3 содержимое запросов скрыто, однако метаданные установления соединения в ряде случаев остаются доступными для анализа. Кроме того, фильтрация может учитывать не только SNI, но и известные IP-адреса DNS-провайдеров.
Чем нынешняя ситуация отличается от прежних сбоев
Похожие проблемы уже наблюдались в начале июля 2026 года. Тогда у клиентов нескольких крупных операторов не устанавливались TCP-соединения с Google Public DNS, хотя UDP-запросы на порт 53 продолжали проходить. Ограничение выглядело скорее как экспериментальная или грубая фильтрация и позднее исчезло.
Новая волна имеет несколько отличительных признаков. Одновременно затронуты Google и Cloudflare, используются разные сценарии блокировки для DoT и DoH, а обычный DNS во многих случаях сохраняет работоспособность. Такое сочетание больше похоже на обновлённые правила DPI, которые распознают конкретные протоколы и точки подключения.
Как проверить проблему самостоятельно
Сначала стоит сравнить работу обычного DNS и защищённых вариантов. Для этого можно временно указать в системе DNS-сервер 8.8.8.8 или 1.1.1.1 и выполнить несколько запросов. Если ответы приходят, значит, маршрутизация до сервера в целом сохраняется.
Затем следует проверить DoT. При успешном подключении к TCP-порту 853 устанавливается TLS-сессия и выполняется DNS-запрос. Если TCP-рукопожатие завершается, а затем соединение закрывается сбросом, вероятна фильтрация по порту или сигнатуре протокола.
Для проверки DoH важно исключить влияние локального разрешения имён. Тестовое подключение можно выполнить напрямую к IP-адресу сервера, сохранив нужное имя хоста для TLS. Если соединение на 443 устанавливается, но после ClientHello возникает длительное молчание, это указывает на фильтрацию HTTPS-потока.
Полезно повторить тест из другой сети - например, через мобильный интернет другого оператора. Если тот же компьютер и программа работают в альтернативной сети, проблема, скорее всего, находится на стороне домашнего провайдера, а не устройства или DNS-сервиса.
Как отличить блокировку по SNI от ограничения по IP
Если соединение не работает только при обращении к определённому доменному имени, но тот же IP-адрес доступен для других задач, вероятна фильтрация по SNI или TLS-сигнатуре.
Когда недоступен сам IP-адрес, не устанавливается даже TCP-соединение, а одинаковые симптомы проявляются для разных портов, можно говорить о более жёсткой блокировке маршрута или адресного диапазона.
Впрочем, эти методы могут сочетаться. Фильтр способен одновременно учитывать IP, порт, SNI и параметры TLS, поэтому один тест не всегда даёт окончательный ответ.
Поможет ли DNSSEC
DNSSEC защищает подлинность DNS-ответа и позволяет обнаружить подмену записи. Однако этот механизм не скрывает сам факт запроса и не предотвращает блокировку соединения. Если DPI просто отбрасывает пакеты или разрывает TLS-сеанс, DNSSEC не сможет восстановить канал.
Поэтому DNSSEC решает другую задачу: он помогает убедиться, что полученный ответ действительно подписан владельцем доменной зоны. DoT и DoH, напротив, защищают транспорт DNS-запроса от просмотра и изменения по пути.
Что можно сделать пользователю
В первую очередь стоит проверить настройки операционной системы, браузера и роутера. Иногда DoH включён в браузере отдельно, а системный DNS продолжает работать по обычной схеме. Из-за этого диагностика становится запутанной: один тип запросов проходит, другой - нет.
Можно попробовать другого DNS-провайдера, поскольку фильтрация может быть привязана к конкретным доменам и адресам. Однако смена сервера не гарантирует результата, если оператор блокирует сам протокол или анализирует TLS-отпечаток.
Также применяются альтернативные защищённые схемы, включая DNS через прокси или VPN. Их работоспособность зависит от используемой инфраструктуры, а качество соединения - от нагрузки, маршрута и ограничений конкретного оператора. Важно помнить, что сторонние приложения получают доступ ко всему трафику, поэтому доверять следует только известным и проверяемым решениям.
Почему это важно
Блокировка DoT и DoH показывает, что фильтрация постепенно смещается от простых правил по IP и портам к анализу поведения сетевых протоколов. Даже если содержимое соединения зашифровано, его технические характеристики могут использоваться для классификации.
Для пользователя это означает, что наличие шифрования само по себе больше не гарантирует доступность сервиса. Протокол может быть защищён криптографически, но при этом легко распознаваться сетевым оборудованием.
Ситуация также подчёркивает уязвимость централизованных публичных DNS-сервисов. Чем шире распространены конкретные домены и IP-адреса резолверов, тем проще создать для них отдельные правила фильтрации. В дальнейшем разработчикам защищённых DNS-клиентов, вероятно, придётся уделять больше внимания маскировке трафика, устойчивости к анализу и распределённой инфраструктуре.
Пока наиболее точный способ понять характер сбоя - сравнить несколько сетей, проверить UDP, DoT и DoH по отдельности и посмотреть, на каком этапе обрывается соединение. Такой подход помогает отделить неисправность у пользователя от системной фильтрации на уровне оператора.