АлекСо

В России начали глушить зашифрованный DNS: что происходит с DoH и DoT у операторов

С середины августа 2026 года у части абонентов «Ростелекома», «Дом.ру», «Таттелекома», SkyNet и «Билайна» одновременно перестал отвечать зашифрованный DNS от Google (8.8.8.8) и Cloudflare (1.1.1.1).

В России начали глушить зашифрованный DNS: что происходит с DoH и DoT у операторов

Сначала это выглядело как разовый сбой. К концу месяца выяснилось: речь не о технической аварии, а о системной фильтрации трафика через оборудование ТСПУ, которая добралась и до обычного открытого DNS. Разбираемся, что именно сломано, почему протоколы ведут себя по-разному и что с этим делать пользователям и администраторам.

Что изменилось?

Первые замеры появились ещё 21 августа в сети «Билайна» — их опубликовал Telegram-канал bypassblock. Затем жалобы посыпались с других провайдеров. Картина оказалась одинаковой у независимых операторов, что указывает на централизованно распространённое правило для ТСПУ, а не на локальную настройку одного игрока.

Есть три разных механизма, и важно их различать:

Тип трафика

Как проявляется

Где рвётся

DoT (DNS over TLS, порт 853)

TCP-сессия поднимается, затем прилетает RST

Активный сброс соединения

DoH (DNS over HTTPS, порт 443)

TCP есть, ClientHello уходит — дальше тишина

«Чёрная дыра», DPI режет по SNI

Обычный DNS (UDP/53)

Возвращается подложный NXDOMAIN

Перехват и подмена ответа через НСДИ

Принципиально важно: блокируют не IP-адреса целиком. Незашифрованный запрос к тем же 8.8.8.8:53 у многих продолжал работать — режется содержимое трафика, а не адрес. Для DoT это тривиально: у него выделенный, легко узнаваемый порт 853. А вот DoH прячется в общем потоке HTTPS вместе с банк-клиентами и госуслугами, поэтому глушить его целиком нельзя — DPI вычленяет такие сессии по полю SNI в TLS ClientHello, по набору cipher suite и JA3-фингерпринту клиента.

Кого касается?

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

Отдельно от блокировок DoH/DoT — история с перехватом открытого DNS. С вечера 26 августа ТСПУ начала перенаправлять обычные запросы к 8.8.8.8 и 1.1.1.1 на собственный резолвер НСДИ (адрес 195.208.5.1). На заблокированные домены вроде youtube.com и rutracker.org она отвечает «домена не существует» — со стороны выглядит как будто сайт просто исчез, хотя интернет в целом жив.

Худшая часть для приватности в другом: если перехват включён, на государственный резолвер уходят все DNS-запросы, а не только к запрещённым ресурсам. Оператор видит полную историю того, куда вы ходите, — независимо от легальности сайта.

Как проверить, что именно сломано у вас?

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

Обычный UDP DNS: `` dig @8.8.8.8 example.com ``

DoT: `` kdig -d @1.1.1.1 +tls example.com ``

DoH (ключевой флаг --resolve — он заставляет curl идти по IP напрямую, минуя системный DNS): `` curl -v --resolve dns.google:443:8.8.8.8 https://dns.google/resolve \ -H 'accept: application/dns-json' -G --data-urlencode 'name=example.com' ``

Диагностика подмены открытого DNS строится на трёх признаках:

  • Флаг aa в ответе. Google Public DNS — рекурсивный резолвер, полномочным (authoritative) он быть не должен. Если в ответе «от 8.8.8.8» стоит aa — отвечал перехватчик, а не Google.

  • TTL-трюк. Запрос с TTL 2 вызывает ICMP Time Exceeded, в котором вместо 8.8.8.8 всплывает адрес 195.208.5.1 (узел НСДИ).

  • whoami.akamai.net. Этот домен честно возвращает IP резолвера, который его реально обработал. Если в ответе адрес из сети MSK-IX, а не инфраструктуры Google — запрос обслуживал перехватчик.

Важная оговорка про DNSSEC: формально он создан именно для защиты от таких подмен, но ловит подделку только в подписанных зонах. У youtube.com, rutracker.org или facebook.com подписи нет — валидатору просто нечего проверять.

Что делать?

Полностью «вылечить» ситуацию на стороне абонента сложно, но некоторые приёмы работают прямо сейчас.

  • Обычный DNS по TCP (вместо UDP). Перехват НСДИ цепляется преимущественно за UDP/53; по TCP часто возвращаются настоящие адреса.

  • DoH/DoT напрямую по IP-адресу, минуя резолвинг по домену (--connect-to / --resolve). Часть фильтров завязана именно на SNI, так что запрос по голому IP иногда проходит. Приём хрупкий: как только начнут резать и по IP — перестанет работать.

  • DoH через GoodbyeDPI или zapret. Обёртка DoH-трафика в прокси по хостлисту лечит именно обрыв TLS-хендшейка — DPI перестаёт видеть исходный SNI.

  • VPN с полным туннелем — единственный по-настоящему надёжный вариант сегодня. ТСПУ не видит ни адреса резолвера, ни самого DNS-вопроса, потому что всё уже завёрнуто в шифрованный туннель на транспортном уровне.

Возможные проблемы

Важно не питать иллюзий насчёт устойчивости обходов. Автор разбора прямо пишет: рассчитывать на зашифрованный DNS как на постоянный канал приватности больше не стоит. С начала года прослеживается вектор — сначала точечные тесты в июле (TCP к Google Public DNS ломался у нескольких операторов, потом ограничение сняли), затем одновременная системная блокировка крупнейших DoH/DoT-провайдеров в августе и подмена открытого DNS через НСДИ.

Скорее всего, следующим шагом доберутся и до остальных публичных резолверов. Любой обход — это гонка вооружений: как только приём становится массовым, сигнатуру для ТСПУ обновляют.

Что это значит в целом?

Если коротко — российская сеть сделала ещё один шаг к централизованной фильтрации DNS. Технически это самая интересная часть истории: точка разрыва переехала с IP-уровня на уровень TLS-хендшейка, что требует полноценного DPI с разбором ClientHello в реальном времени, а не банального firewall-правила. Для рядового пользователя последствия понятнее: приватность публичных резолверов Google и Cloudflare в российских сетях теперь условная, и опираться на неё в критичных сценариях не стоит.

Источники

Полезное

Читайте также