Роскомнадзор взялся за зашифрованный DNS Google и Cloudflare

Роскомнадзор взялся за зашифрованный DNS Google и Cloudflare

изображение: grok

Российские операторы связи начали ограничивать доступ к защищённому DNS от Google и Cloudflare. Пользователи нескольких провайдеров столкнулись с обрывом соединений при использовании DNS over HTTPS и DNS over TLS. Судя по техническим тестам, TCP-сессия устанавливается, а затем трафик обрывается на этапе TLS-рукопожатия.

Первые технические подтверждения появились 21 августа. Авторы канала bypassblock зафиксировали сбои с защищённым DNS в сети одного из мобильных операторов. Позже похожие проблемы стали фиксировать абоненты «Ростелекома», «Дом.ru», «Таттелекома» и петербургского SkyNet. Для российских пользователей это означает риск остаться без рабочего способа скрыть свои DNS-запросы от провайдера.

Сбои затронули сразу несколько операторов и протоколов:

  • DNS over TLS от Cloudflare через 1.1.1.1 и 1.0.0.1 на порту 853;
  • DNS over HTTPS от Google через dns.google, 8.8.8.8 и 8.8.4.4 на порту 443;
  • сети «Ростелекома», «Дом.ru» и «Таттелекома»;
  • сеть петербургского провайдера SkyNet.

Это отличается от обычной блокировки IP-адреса, при которой соединение с сервером не устанавливалось бы вовсе. Здесь сетевой обмен доходит до момента, когда оборудование оператора способно определить характер защищённого соединения и вмешаться в него. Проблемы при этом проявляются неодинаково у разных абонентов. У одних перестают работать сразу несколько публичных резолверов, у других отказывает лишь один протокол или отдельный IP-адрес.

Отмечается, что при подключении к Cloudflare клиент получает принудительный разрыв TCP-сессии сразу после установления соединения, а не привычную блокировку по IP-адресу.

DNS over TLS работает через выделенный TCP-порт 853, поэтому оборудованию оператора несложно определить такой трафик по номеру порта. С DNS over HTTPS ситуация принципиально другая. Запросы передаются внутри обычного HTTPS-соединения через порт 443, и на уровне TCP такой трафик почти не отличается от подключения к любому обычному сайту.

Чтобы ограничить DoH, недостаточно закрыть порт, нужно определить, с каким сервисом устанавливается HTTPS-соединение. Зависание обмена сразу после отправки ClientHello может указывать на фильтрацию не по адресу, а по содержимому самого TLS-запроса.

У разных абонентов сбои проявляются по-своему:

  • Cloudflare через 1.1.1.1 и 1.0.0.1 отдаёт ошибку ECONNRESET сразу после установления TCP-сессии;
  • Google через dns.google, 8.8.8.8 и 8.8.4.4 останавливает обмен после отправки TLS ClientHello;
  • клиент получает тайм-аут либо ошибку unexpected eof while reading;
  • в части сетей обычный незашифрованный DNS продолжает работать без сбоев.

Стоит обратить внимание на случай одного из абонентов Таттелекома, которому техническая поддержка прямо посоветовала отключить DoH и DoT на устройстве.

Обычный DNS передаёт запросы к доменным именам без шифрования, поэтому сетевой оператор видит, какие домены запрашивает устройство, и может вмешаться в обработку таких запросов. DoH и DoT шифруют соединение между устройством и выбранным DNS-резолвером, из-за чего провайдер не получает содержимое DNS-запросов в открытом виде.

При этом сами протоколы не дают полной анонимности пользователю. Факт соединения с конкретным IP-адресом и другие метаданные сетевого соединения остаются видимыми оператору, а DNS остаётся лишь одним элементом интернет-соединения. Полноценный обход сетевых ограничений требует и других инструментов, не только смены DNS-резолвера.

Защищённый DNS решает сразу несколько задач:

  • скрывает от провайдера содержимое DNS-запросов пользователя;
  • снижает возможность подмены ответов на уровне сети;
  • усложняет фильтрацию по доменным именам;
  • остаётся при этом лишь одним элементом защиты интернет-соединения.

Похожая ситуация уже возникала в начале июля, когда абоненты крупных российских операторов также сообщали о проблемах с TCP-соединениями к Google Public DNS. Классический DNS через UDP тогда продолжал работать, а часть альтернативных способов подключения оставалась доступной. Теперь география сообщений расширилась, а сбои одновременно затронули публичные DNS-сервисы Google и Cloudflare.

Само по себе совпадение по времени у разных операторов и разных сервисов делает случайную техническую неполадку менее вероятным объяснением происходящего.

Для российских пользователей системное ограничение защищённого DNS способно означать, что смены DNS-сервера в настройках устройства станет недостаточно, а зашифрованный протокол перестанет работать даже при доступном IP-адресе.

Если ограничение применяется системно, для пользователей это может означать следующее:

  • обычная смена адреса DNS-сервера перестаёт гарантировать доступ к защищённому протоколу;
  • провайдер получает больше возможностей для анализа сетевого трафика;
  • часть привычных инструментов обхода блокировок теряет эффективность;
  • интерес к альтернативным способам шифрования DNS-трафика будет расти.

Ранее сообщалось, что во втором квартале 2026 года крупнейшие перебои с доступом в интернет по всему миру происходили не только из-за действий злоумышленников. Аналитики Cloudflare собрали десятки случаев, когда миллионы пользователей теряли связь из-за землетрясений, тайфунов, аварий на линиях связи, отключений электричества, ошибок при настройке DNS и решений государственных органов. Отчет показывает, насколько цифровые сервисы зависят от событий за пределами дата-центров.

Эксперты CISOCLUB заявили, что переход от блокировки отдельных IP-адресов к точечному контролю над зашифрованными протоколами меняет расстановку сил в противостоянии провайдеров и разработчиков средств защиты трафика.

По их оценке, обрыв соединения происходит на этапе TLS-рукопожатия, что указывает на работу оборудования, способного анализировать характер соединения, а не только его адрес. Рядовым пользователям стоит держать под рукой несколько независимых способов подключения к DNS. При этом без официального заявления регулятора нельзя с уверенностью говорить об одной причине всех сбоев, ведь похожие симптомы иногда дают обычные сетевые неполадки. Дальнейшее развитие событий будет зависеть от того, начнут ли операторы применять подобные ограничения системно по всей стране.

Артем
Автор: Артем
Представитель редакции CISOCLUB. Пишу новости, дайджесты, добавляю мероприятия и отчеты.
Комментарии: