В России фиксируют сбои защищенного DNS Google и Cloudflare

В российских сетях начали фиксировать проблемы с доступом к отдельным зарубежным сервисам защищенного DNS. У части пользователей не проходят запросы через DNS over HTTPS (DoH) и DNS over TLS (DoT) Google, Cloudflare, AdGuard и других операторов. Первые сообщения в конце прошлой недели касались отдельных сетей, включая «Билайн», затем похожие жалобы появились у абонентов других провайдеров.

Крупнейший опубликованный на данный момент краудсорсинговый замер охватил 3186 проверок 29 DoH-сервисов в 66 автономных системах. Автор исследования «ЗаТелеком» пришел к выводу, что полученные данные не показывают общего отключения DoH как технологии: одни резолверы действительно массово не отвечают, другие работают почти во всех протестированных сетях.

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

Это снижает конфиденциальность DNS-запросов, но не означает, что DoH до сих пор полностью скрывал от оператора все посещаемые сайты. Провайдер в любом случае видит IP-адреса, с которыми соединяется абонент, и ряд других параметров трафика. Для сокрытия имени сайта во время установки TLS-соединения используется отдельный механизм — Encrypted Client Hello, или ECH.

Первые технические отчеты 21 августа описывали недоступность DoT Cloudflare и DoH Google у отдельных абонентов «Билайна». В тестах соединения с Cloudflare на TCP-порту 853 прерывались, а HTTPS-соединения с dns.google через адреса Google завершались тайм-аутом. Эти измерения показывают проблему в конкретной сети, но сами по себе не доказывают общероссийскую блокировку протокола.

25 августа появились сообщения о похожих сбоях у пользователей других операторов. Некоторые публикации уже назвали происходящее блокировкой защищенного DNS Google и Cloudflare со стороны Роскомнадзора. Основным подтверждением при этом стали результаты тестирования «ЗаТелеком». За 22–23 августа исследователь собрал 124 прогона теста в 66 автономных системах — отдельных сетях операторов и организаций. Всего проверялось 29 DoH-резолверов, получилось 3186 отдельных запросов.

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

Результаты сильно различались в зависимости от DNS-сервиса. dns.adguard.com не отвечал примерно в 90% измерений, unfiltered.adguard-dns.com — в 85%, AliDNS — в 39%, OpenDNS — примерно в 23%. Для двух проверенных адресов Cloudflare доля неудачных запросов составляла около 16–17%.

При этом dns.google, отдельный резолвер Cloudflare для Mozilla и несколько других DoH-сервисов не отвечали только примерно в 4–9% тестов. Такое распределение плохо согласуется с версией о едином общероссийском запрете всего DoH-трафика.

В общей выборке обнаружились три небольшие автономные системы с намного большим количеством сбоев. В сети Kompanon не прошли 18 из 20 проверенных сервисов, у NECSTEL и TeleMaks — по 16. Автор исследования считает, что в этих сетях DoH фактически недоступен почти целиком.

У крупных операторов результат оказался менее однозначным. У «Ростелекома», МТС, МГТС и SkyNet во время разных прогонов переставали отвечать несколько сервисов, но набор менялся. Например, у МГТС разные замеры показывали от двух до 17 проблемных резолверов, у «Ростелекома» — от одного до десяти.

Выборка пока ограничена: 51 из 66 автономных систем протестировали только один раз. Более устойчивые данные накопились лишь для семи сетей, где было проведено не менее трех прогонов.

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

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

DoH переносит DNS внутри HTTPS. Cloudflare описывает принцип так: запросы DNS упаковываются в обычные HTTPS-запросы и передаются через порт 443 — тот же порт, через который работает большая часть современного веба.

Google поддерживает такой же механизм для Public DNS. Защищенные варианты нужны именно для того, чтобы посредник между пользователем и резолвером не мог прочитать или незаметно изменить содержимое DNS-запроса. DoT решает ту же задачу через отдельное TLS-соединение и обычно использует TCP-порт 853.

С точки зрения фильтрации DoT выделить проще: у него есть характерный выделенный порт. DoH смешивается с HTTPS-трафиком на 443-м порту, но это не делает конкретные публичные резолверы неуязвимыми для ограничений. Их IP-адреса и доменные имена известны, поэтому доступ можно ограничивать на других уровнях.

DoH скрывает DNS-запрос. Он не является VPN и не шифрует заново весь трафик между устройством и сайтом. Предположим, браузер через DoH спрашивает IP example.com. Оператор не видит содержимое этого DNS-запроса. После получения ответа браузеру все равно нужно соединиться с найденным IP-адресом. Этот IP виден сетевому оператору.

С одним адресом могут работать сотни или тысячи сайтов, особенно при использовании крупных облачных платформ и сетей доставки контента, поэтому определить домен только по IP получается далеко не всегда. Но сам факт соединения с IP скрытым не становится.

Есть еще TLS-параметр Server Name Indication, или SNI. Он сообщает серверу, для какого домена клиент хочет установить защищенное соединение. При обычной схеме TLS это имя может быть доступно сетевому посреднику.

Шифрует его уже не DoH, а Encrypted Client Hello. Документация Cloudflare прямо описывает ECH как расширение TLS, которое маскирует SNI: посредник может определить, что пользователь обращается к инфраструктуре Cloudflare, но не видит конкретный ECH-защищенный сайт внутри нее.

Если DoH перестает отвечать, единого поведения для всех устройств нет. Chrome по умолчанию использует защищенный DNS в автоматическом режиме. Google прямо предупреждает: если в этом режиме выполнить защищенный запрос не получается, браузер может повторить разрешение имени в незашифрованном режиме.

В таком случае DNS-запрос снова проходит через обычную системную схему. Если система использует DNS интернет-провайдера, оператор получает возможность видеть запрашиваемые доменные имена.

Но у Chrome есть второй сценарий. Пользователь может явно выбрать определенного поставщика защищенного DNS. Google указывает, что при такой настройке браузер не должен автоматически возвращаться к незашифрованному DNS. Если выбранный DoH-сервер перестал отвечать, пользователь скорее столкнется с ошибкой разрешения имени. Поэтому блокировка конкретного резолвера может дать два совершенно разных результата: незаметный возврат к обычному DNS или поломку открытия сайтов.

Mozilla предлагает несколько уровней защиты DoH. В режиме Default Protection браузер использует защищенный DNS там, где он доступен, но при проблемах может вернуться к стандартным резолверам. Firefox также способен автоматически отключать DoH при некоторых корпоративных настройках, родительском контроле, работе VPN или специальном сигнале со стороны сети.

Режим Max Protection работает жестче. Firefox всегда пытается использовать защищенный DNS и показывает предупреждение, если связаться с резолвером не получилось. Вернуться к системному DNS пользователь может уже через исключение.

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

Например, запрос к: example[.]com будет виден как запрос домена example.com. Это не раскрывает полный адрес страницы: https://example.com/account/private-messageПуть /account/private-message, параметры URL и содержимое страницы при HTTPS остаются внутри защищенного соединения.

Поэтому переход с DoH на обычный DNS уменьшает приватность. Также контроль над DNS упрощает один из вариантов ограничения доступа. Если пользователь обращается к DNS-серверу оператора, тот может не вернуть настоящий IP заблокированного домена, ответить ошибкой или выдать другой адрес. Такая модель применяется. Например, измерения OONI в России фиксировали DNS-блокировки, при которых вместо корректного адреса ресурса возвращались IP, связанные со страницами ограничения доступа.

DoH до независимого резолвера защищает запрос и ответ от незаметного изменения посредником на сетевом пути. Но он не отменяет остальные способы фильтрации. Сайт можно ограничивать по IP-адресу, по открытому SNI, по особенностям протокола или другим признакам, которые способен анализировать сетевой фильтр. Поэтому недоступность DoH не создает для провайдера возможность блокировать сайты «с нуля». Она убирает один из каналов, позволяющих пользователю получать DNS-ответ через зашифрованное соединение с независимым резолвером.

Августовские сбои появились не в вакууме. 7 августа исследователи «Теплицы социальных технологий» опубликовали серию тестов обычного DNS, DoH, DoT и DoQ для Google, Cloudflare, AdGuard, NextDNS и других резолверов с российских и зарубежных узлов.

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

Для Google, например, необычный ответ воспроизводился и через обычный DNS, и внутри DoT/DoH. Это важная техническая деталь: сетевое оборудование между клиентом и настоящим DoH-сервером не может незаметно переписать содержимое корректно защищенного TLS-сеанса — проверка целостности перестанет сходиться.

В том же исследовании TLS-сертификаты при соединении с Google и Cloudflare оставались подлинными, а трассировка приводила в реальные сети компаний. Авторы поэтому не нашли доказательств классического перехвата HTTPS-соединения с DNS-резолвером и оставили несколько альтернативных объяснений происходящего. Эта работа не объясняет сбои, появившиеся 21–25 августа, но показывает, почему одного тайм-аута или необычного DNS-ответа недостаточно, чтобы определить конкретный механизм фильтрации.

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

Если программа требует определенный DNS-сервис и не допускает перехода на другой резолвер, его недоступность может проявиться неожиданно. Само интернет-соединение остается активным, но приложение не может получить IP нужного API или другого служебного домена.

Пользователь в таком случае увидит ошибку входа, вечную загрузку, частично работающий интерфейс или сообщение о проблеме с соединением.

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

В ряде публикаций ограничения напрямую приписываются ТСПУ — техническим средствам противодействия угрозам, через которые реализуется централизованная фильтрация трафика российских операторов. На момент подготовки материала публичного технического объяснения Роскомнадзора именно по сбоям DoH Google, Cloudflare и других зарубежных резолверов обнаружить не удалось.

Вопросы и ответы

Роскомнадзор уже заблокировал DoH в России?

Подтверждений полной общероссийской блокировки DNS over HTTPS пока нет. Есть технически зафиксированные сбои и практически полная недоступность DoH в нескольких отдельных сетях. Краудсорсинговое исследование 3186 запросов не выявило единого отключения протокола.

Google DNS заблокирован?

Не во всех сетях. Есть измерения, где подключения к dns.google не проходят, включая тесты у абонентов «Билайна». В более широкой выборке Google DoH при этом оказался среди наиболее стабильно работающих резолверов.

Cloudflare DNS перестал работать?

У части пользователей — да. В массовом тесте два проверенных DoH-сервиса Cloudflare дали около 16–17% неудачных запросов. Это заметная доля, но она не означает полной недоступности Cloudflare DNS в России.

Провайдер видит DNS-запрос при использовании DoH?

При корректно установленном DoH-соединении содержимое DNS-запроса находится внутри HTTPS и не передается оператору в открытом виде.

DoH скрывает от оператора посещаемый сайт?

Не полностью. DoH защищает DNS-запрос. Провайдер продолжает видеть IP-адрес назначения, а при определенных вариантах TLS доменное имя может раскрыться через SNI. ECH создан именно для шифрования этой части TLS-рукопожатия.

Что произойдет, если Chrome не сможет подключиться к DoH?

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

Что делает Firefox?

Default Protection допускает возврат к стандартному DNS при проблемах. Max Protection требует защищенный DNS и показывает предупреждение, если подключиться к нему невозможно.

Увидит ли оператор полную страницу, которую я открыл?

Не из DNS. Обычный DNS может раскрыть доменное имя, например example.com, но не путь внутри HTTPS-адреса и не содержимое страницы.

DoH и DoT — одно и то же?

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

Станет ли блокировать сайты проще, если устройство перейдет на DNS провайдера?

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