Отказ DoH и DoT у российских операторов: что подтверждено, а что оспаривается

Что описывают издания

SecurityLab 25 августа в 15:38 МСК и Anti-Malware 26 августа в 14:28 сообщили об одном и том же: у абонентов «Ростелекома», «Дом.ру», «Таттелекома» и петербургского SkyNet перестают работать DNS over HTTPS и DNS over TLS у Google и Cloudflare. Адреса и порты называются конкретные: 1.1.1.1 и 1.0.0.1 на TCP-порту 853 у Cloudflare, 8.8.8.8, 8.8.4.4 и dns.google на порту 443 у Google.

Механика в обоих описаниях одинаковая и заметно отличается от обычной блокировки по адресу. TCP-соединение устанавливается нормально — то есть узел доступен. Разваливается следующий этап: у Cloudflare соединение принудительно сбрасывается с ошибкой ECONNRESET до завершения TLS-аутентификации, у Google после отправки ClientHello ответы просто прекращаются. Обычные незашифрованные DNS-запросы при этом в большинстве случаев продолжают работать.

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

Здесь важно назвать, на чём это держится. Первоисточником фактуры у обоих изданий выступает телеграм-канал bypassblock — не оператор, не регулятор и не собственный замер редакции. Официального подтверждения нет ни от Роскомнадзора, ни от самих операторов; Anti-Malware прямо пишет, что централизованного подтверждения на момент публикации не было.

Отдельно стоит назвать независимое свидетельство, которое появилось уже после публикаций. 26 августа в трекере net4people/bbs заведено обращение «dns hijacking in russia» за авторством its0ka — это другой автор и другая площадка. Речь там о смежном, но ином явлении: обычные незашифрованные запросы по UDP к 8.8.8.8 возвращают не адреса Google. Запрос whoami.akamai.net отдаёт адреса MSK-IX — 193.232.230.48, 193.232.160.49, 193.232.93.81 и 193.232.236.51, — а домены в зоне .ua, whatsapp.com и youtube.com отвечают NXDOMAIN. Тот же запрос к тому же 8.8.8.8, но по TCP, отрабатывает корректно. Автор связывает это с ТСПУ, а не с настройками отдельных операторов, ссылаясь на одновременность у разных провайдеров.

Как это соотносится с первым сюжетом, стоит сказать точно, не сваливая в кучу. Это разные наблюдения: там рвался шифрованный канал, здесь подменяется ответ на незашифрованный запрос. Общего у них то, что оба указывают на вмешательство в разрешение имён выше уровня оператора. Но обращение в трекере — это тоже сообщение отдельного человека, а не измерение редакции или официальное подтверждение.

Что оспаривается и что проверили мы

25 августа в 21:50 главный редактор издания Runet Владимир Зыков заявил, что сообщения о новых блокировках DNS-сервисов Google и Cloudflare в России не подтверждаются. Его основание: вместе с коллегами он проверил ситуацию по сервисам мониторинга и необычного роста числа сбоев не увидел. Отдельно он уточнил, что ограничения доступа к Cloudflare и Google DNS в России действуют давно, поэтому оснований говорить о новой волне нет.

Обратите внимание, что стороны спорят не об одном и том же. Издания описывают, как именно рвётся соединение у конкретных абонентов. Возражение касается другого утверждения — что это новое событие, а не давно существующее состояние. Обе позиции могут быть верны одновременно: ограничения действуют давно, а прирост жалоб на этой неделе может быть и локальным, и незаметным на фоне общей статистики сбоев.

Что мы можем проверить сами и что проверили. Утром 27 августа из сети за пределами России мы обратились к обеим службам напрямую: DoH Cloudflare и DoH Google ответили кодом 200 за 46 и 134 миллисекунды соответственно, TCP-порт 853 открыт и у 1.1.1.1, и у 8.8.8.8. Это закрывает одну версию целиком — со стороны Google и Cloudflare ничего не сломано, службы работают. Значит, предмет спора — поведение на пути внутри российских сетей, а его из-за границы не измерить, и выдавать наш замер за проверку самих жалоб мы не станем.

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

Что это значит на практике

Шифрованный DNS — это не туннель и не средство обхода блокировок. Его задача узкая: скрыть от посредника на линии, какое доменное имя вы запрашиваете. Сам трафик к сайту он не прячет и маршрут не меняет. Поэтому «включил DoH» и «включил VPN» решают разные задачи, и подменять одно другим не стоит.

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

Возвращать незашифрованный DNS ради работоспособности — размен, о котором стоит знать явно: запросы имён снова становятся видны и посреднику на линии, и оператору. Это осознанное решение, а не нейтральное «починил».

Когда соединение идёт через туннель, DNS-запросы штатно уходят внутри него, и описанная картина отказа к ним не относится. Оговорка обязательна: в клиентах существует раздельное туннелирование и собственные настройки DNS, при которых часть запросов уходит мимо туннеля — так что фразу «с туннелем этой проблемы нет» без проверки конкретной конфигурации принимать не надо.