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

Сначала это выглядело как разовый сбой. К концу месяца выяснилось: речь не о технической аварии, а о системной фильтрации трафика через оборудование ТСПУ, которая добралась и до обычного открытого 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 в российских сетях теперь условная, и опираться на неё в критичных сценариях не стоит.
Источники
Полезное
Читайте также




