РКН взялся за защищённый DNS? Что на самом деле показали 3186 проверок

Пользователи нескольких российских операторов столкнулись со сбоями в работе защищённых DNS-сервисов Google и Cloudflare. В соцсетях происходящее уже назвали новой блокировкой Роскомнадзора, которая должна упростить контроль над посещаемыми сайтами. Проблема действительно существует, однако доступные измерения пока не подтверждают ни общероссийского запрета DoH, ни непосредственного участия регулятора.

С чего начались разговоры о блокировке

Первые сообщения появились у абонентов «Билайна». По данным Techora, в мобильной сети оператора перестал стабильно работать DNS over TLS от Cloudflare: соединения с адресами 1.1.1.1 и 1.0.0.1 через порт 853 сбрасывались. Одновременно пользователи сообщили о тайм-аутах при попытке обратиться к сервису Google DoH по адресу dns.google.

Позднее похожие жалобы поступили от клиентов «Ростелекома» в Архангельске, «Дом.ру» и SkyNet в Санкт-Петербурге. В отдельных случаях обычные незашифрованные запросы к DNS-серверам Google и Cloudflare продолжали проходить, тогда как защищённые соединения не устанавливались. Такое поведение действительно может указывать на фильтрацию конкретных протоколов или адресов, но само по себе ещё не доказывает централизованную блокировку.

В публикациях не приводится официального комментария Роскомнадзора или операторов. Основой сообщений стали пользовательские наблюдения и результаты самостоятельных тестов.

Что обнаружили 3186 проверок

Наиболее масштабный из доступных замеров провёл телеком-канал «ЗаТелеком». За 22–23 августа его участники выполнили 3186 проверок: 124 запуска теста в 66 автономных системах с обращением к 29 DoH-серверам.

На первый взгляд результат выглядел тревожно: успешными оказались только 55% запросов. Однако после исключения заведомо неработавших контрольных адресов и ошибок, связанных с устаревшей версией curl, показатель вырос до 73%.

Некоторые адреса действительно выделялись аномальным количеством сбоев. Старый домен AdGuard dns.adguard.com не ответил в 90% проверок и оказался недоступен в 61 сети из 66. При этом другой адрес того же сервиса, dns.adguard-dns.com, показал лишь 8% неудачных соединений. Это скорее указывает на ограничения или технические проблемы конкретного адреса, чем на запрет всего протокола.

Два проверявшихся сервиса Cloudflare не сработали в 16–17% случаев. В то же время dns.google, специальный адрес Mozilla для Cloudflare и ряд других DoH-серверов вошли в группу наиболее доступных — доля сбоев у них составляла от 4 до 9%.

Почти полная недоступность защищённого DNS обнаружилась у трёх небольших провайдеров — Kompanon, NECSTEL и TeleMaks. У «Ростелекома», МТС, МГТС и SkyNet результаты менялись от запуска к запуску: в одной и той же сети могли не отвечать от двух до 17 сервисов. Причина таких колебаний не установлена.

У исследования есть ещё одно существенное ограничение: 51 из 66 сетей проверили только один раз. Более или менее устойчивые выводы можно делать лишь по семи операторам, где состоялось не менее трёх запусков. Поэтому автор замера сформулировал итог прямо: признаков блокировки DoH как протокола пока не обнаружено.

Иными словами, широко разошедшееся утверждение о том, что «более трёх тысяч проверок подтвердили блокировку», противоречит выводу самого исследователя. Проверки подтвердили неоднородные сбои отдельных серверов и сетей, но не общенациональный запрет.

Что скрывает защищённый DNS

Прежде чем открыть сайт, устройство должно узнать соответствующий его домену IP-адрес. Для этого оно обращается к DNS-серверу — своеобразной адресной книге интернета.

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

DoH передаёт такой запрос внутри обычного HTTPS-соединения. Протокол описан в RFC 8484. Похожую задачу решает DoT, но он использует отдельное TLS-соединение и стандартный порт 853, что закреплено в RFC 7858.

Шифрование не делает пользователя невидимым. Провайдер не видит содержание DNS-запроса, но знает адрес выбранного DNS-сервера и по-прежнему наблюдает последующие соединения с IP-адресами сайтов. Сам оператор DoH — например, Google или Cloudflare — получает запросы пользователя, поэтому технология фактически переносит доверие от интернет-провайдера к внешнему DNS-сервису.

Кроме того, DoH сам по себе не скрывает SNI — имя сервера, которое может передаваться при установлении HTTPS-соединения. Для его защиты нужна отдельная технология Encrypted Client Hello: именно ECH, согласно документации Cloudflare, маскирует SNI. Поэтому утверждение, что одного DoH достаточно для полного сокрытия посещаемых доменов, технически неверно.

Увидит ли провайдер всю историю посещений

Если защищённый DNS перестанет отвечать, дальнейшее поведение зависит от устройства, браузера и выбранного режима. Некоторые программы автоматически возвращаются к системному DNS. Например, Firefox в стандартном режиме допускает такой переход, тогда как максимальный уровень защиты блокирует соединение и показывает предупреждение — это прямо указано в инструкции Mozilla.

При переходе на обычный DNS оператор действительно сможет видеть доменные запросы. Но это не означает, что ему откроется полная история браузера. HTTPS продолжит скрывать содержимое страниц, точные адреса после доменного имени, поисковые запросы, переписку и передаваемые формы. Речь идёт прежде всего о метаданных: к каким доменам и примерно когда обращалось устройство.

Блокировать сайты через собственный DNS провайдеру станет проще, однако российская система фильтрации и сейчас не ограничивается DNS. Технические средства противодействия угрозам позволяют ограничивать соединения по IP-адресам, протоколам и незашифрованному SNI. Внешний DoH способен обойти DNS-подмену, но не гарантирует доступ к ресурсу, заблокированному другими способами.

Почему РКН всё равно оказался под подозрением

Подозрения возникли не на пустом месте. Ещё в сентябре 2021 года Роскомнадзор предупреждал о тестировании ограничений зарубежных протоколов, скрывающих доменные запросы, включая DoH. Государственным организациям тогда рекомендовали перейти на DNS российских операторов или Национальную систему доменных имён, писал «Коммерсантъ».

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

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

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

Об авторе
Недавние публикации

Digital Report

Digital-Report.ru — информационно-аналитический портал, который отслеживает изменения цифровой экономики. Мы описываем все технологические тренды, делаем обзоры устройств и технологических событий, которые влияют на жизнь людей.

Digital Report недавно публиковал (посмотреть все)