С середины августа 2026 года у части абонентов «Ростелекома», «Дом.ру», «Таттелекома», SkyNet и «Билайна» одновременно перестал работать зашифрованный DNS от Google и Cloudflare. Не зависал, не подтормаживал, а именно перестал отвечать. Причём ложился он по‑разному в зависимости от протокола, и это различие — самое интересное в истории.

Давайте разберём, что именно происходит на проводе, почему DoT и DoH ломаются не одинаково, как это потрогать руками, и что со всем этим делать.

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

Немного теории

Обычный DNS — это UDP‑пакет на порт 53, открытым текстом. Провайдер видит каждый ваш запрос к example.com и может подменить ответ, что и используется много лет для блокировок по DNS‑спуфингу.

Есть два способа это обойти:

• DoT (DNS over TLS) — DNS заворачивается в TLS‑туннель на выделенном TCP порту 853.

• DoH (DNS over HTTPS) — DNS‑запрос идет как HTTPS‑запрос (обычно POST или GET с base64) на порт 443, тот же самый, на котором работает большинство web сайтов.

Здесь видно ключевое отличие: у DoT есть отдельный, легко узнаваемый порт. У DoH — нет, он прячется в общем потоке HTTPS‑трафика вместе с другими сайтами.

Что сломалось

Первые замеры выложил Telegram‑канал bypassblock, 21 августа, в сети «Билайна». Дальше подтянулись жалобы с других провайдеров.

Итак, DoT к Cloudflare через dnstls:

c:\>dnstls google.com @1.1.1.1 -p853 +tls-host=cloudflare-dns.com
...
Error: read ECONNRESET

TCP SYN/SYN‑ACK/ACK отрабатывает штатно — то есть IP не заблокирован пакетным фильтром на уровне маршрутизации. А вот дальше прилетает RST. Это подача форс‑мажорного сброса TCP‑сессии от посредника в канале (в данном случае ТСПУ)

DoH к Google через curl, с явным указанием IP через --connect-to, чтобы обойти собственный резолвинг curl:

# curl -4 -v --connect-to ::8.8.8.8 https://dns.google --max-time 5
* Connecting to hostname: 8.8.8.8
*   Trying 8.8.8.8:443...
* Connected to (nil) (8.8.8.8) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* Operation timed out after 5000 milliseconds with 0 bytes received
* Closing connection 0
curl: (28) Operation timed out after 5000 milliseconds with 0 bytes received
# curl -4 -v --connect-to ::8.8.4.4 https://dns.google --max-time 5
* Connecting to hostname: 8.8.4.4
*   Trying 8.8.4.4:443...
* Connected to (nil) (8.8.4.4) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* Operation timed out after 5001 milliseconds with 0 bytes received
* Closing connection 0
curl: (28) Operation timed out after 5001 milliseconds with 0 bytes received

Здесь другая картина: TCP тоже поднимается, ClientHello уходит, но после этого — тишина. Ни RST, ни ответа. Клиент просто ждёт и потом падает по таймауту. Это уже не активный сброс, а «чёрная дыра» — классический признак DPI.

Обычный незашифрованный запрос на 8.8.8.8:53 при этом у многих продолжал работать. То есть блокируют не IP целиком — что‑то в канале (ТСПУ) смотрит содержимое трафика и выборочно его режет.

Почему DoT “спалить” проще, чем DoH

Это буквально написано в архитектуре протоколов, и разница объясняет асимметрию в поведении блокировок.

DoT живёт на выделенном порту 853. Оборудованию DPI даже не нужно смотреть содержимое пакета — достаточно правила dst_port == 853 -> сброс/дроп. Это тривиальная и дешёвая по ресурсам операция, которую можно повесить на пограничный маршрутизатор ещё на уровне ACL, без глубокого разбора трафика. Именно поэтому DoT ловится и глушится системно и стабильно — 853-й порт мало кто использует для чего‑то ещё, и ущерба почти нет.

DoH же делит порт 443 с половиной интернета. Заблокировать 443 целиком — значит уронить банк‑клиенты, госуслуги и всё остальное. Значит, нужно отличать именно DoH‑сессию от обычного HTTPS‑сайта, находясь при этом всё ещё «снаружи» шифрованного канала (внутри TLS 1.3 всё зашифровано, включая сертификат сервера).

Единственное, что доступно DPI на этом этапе — незашифрованные поля TLS ClientHello:

• SNI (Server Name Indication) — поле, в котором клиент открытым текстом говорит серверу, к какому домену он подключается. Именно по SNI dns.google или cloudflare-dns.com фильтр и опознаёт DoH‑сессию.

• набор cipher suite, ALPN, JA3-фингерпринт клиента — по совокупности этих параметров можно с высокой точностью отличить трафик конкретной DoHбиблиотеки от трафика браузера, идущего на обычный сайт.

Наблюдаемая картина прямо соответствует этой модели: DPI разобрал SNI из ClientHello, распознал известный домен резолвера и либо тихо дропнул все последующие пакеты сессии (вариант с Google), либо среагировал чуть раньше и сбросил TCP.

Немного предыстории

В начале июля 2026-го уже была похожая история — TCP‑подключения к Google Public DNS ломались у нескольких крупных операторов, но UDP‑запросы на 53-й порт продолжали работать, и через некоторое время ограничение сняли. Это было похоже на более грубую, тестовую фильтрацию.

Нынешняя волна отличается сразу по нескольким признакам:

1. Бьёт одновременно и по Google, и по Cloudflare — два независимых поставщика DNS, два разных набора IP‑адресов, два разных протокола.

2. Затрагивает разных операторов независимо друг от друга — то есть похоже на централизованно распространённую сигнатуру/правило для оборудования ТСПУ, а не на локальную настройку одного оператора.

3. Точка разрыва — не IP‑уровень, а TLS‑хендшейк, что требует специфичного функционала DPI (разбор ClientHello в реальном времени), а не банального firewall‑правила.

DNS‑спуфинг

Пока часть пользователей воевала с DoH/DoT, у другой части ломался вообще не зашифрованный, а самый обычный DNS — и это принципиально другая история. Симптом на первый взгляд обычный: открываете YouTube — DNS_PROBE_FINISHED_NXDOMAIN. Домен якобы не существует. Но домен, разумеется, существует — просто запрос к 8.8.8.8 или 1.1.1.1 до Google/Cloudflare физически не долетает.

На ТСПУ пакет перехватывается и переадресуется на резолвер НСДИ. Отвечает уже она: на заблокированные домены — «домена не существует», на все остальные ‑честные адреса. Именно поэтому со стороны кажется, что интернет в целом жив, просто конкретный сайт «исчез».

Это отдельный механизм: если там рвётся TLS‑сессия (проблема на уровне транспорта), здесь — подменяется сам ответ по обычному открытому UDP DNS (проблема на уровне контента ответа), причём соединение при этом даже не разрывается.

Как поймать подмену

Флаг aa (Authoritative Answer) в ответе. Легитимный Google Public DNS не является полномочным сервером для чужих доменов — он рекурсивный резолвер, aa‑флага там быть не должно. Если в дампе ответа от «8.8.8.8» вдруг стоит aa — значит отвечал не Google, а кто‑то, кто держит собственную (поддельную) зону:

dig @8.8.8.8 youtube.com ;; flags: qr aa rd ra;   
# aa не должно быть в ответе настоящего Google DNS

TTL‑трюк. В некоторых случаях поведение перехвата можно изменить, отправив один и тот же DNS‑запрос сначала с небольшим TTL, а затем повторно с обычным TTL. Например:

dig @8.8.8.8 youtube.com +bufsize=512 -4 
# в связке с traceroute/tracert на 8.8.8.8 по UDP/53 можно увидеть, 
# что пакет на самом деле разворачивается на 195.208.5.1 (b.res-nsdi.ru), # а не доходит до реального Google

После первого запроса с TTL 2 второй запрос с TTL 64 возвращает настоящий ответ от Google DNS вместо подменённого NXDOMAIN. При TTL 2 пакет с DNS‑запросом вызывает ICMP Time Exceeded, в котором вместо адреса 8.8.8.8 появляется адрес 195.208.5.1 — узла НСДИ. Подробности эксперимента приведены в первоисточнике.

Служебный домен‑маркер whoami.akamai.net. Это специальный домен Akamai, который в ответе честно возвращает IP того резолвера, который его фактически обработал — приём, которым пользуются для диагностики CDN‑маршрутизации.

dig @8.8.8.8 whoami.akamai.net 
# нормальный ответ должен указывать на инфраструктуру Google; 
# если в ответе всплывает адрес из сети MSK-IX — запрос 
# обслуживал не Google, а перехватчик на ТСПУ

А как же DNSSEC — разве он не должен был это ловить?

Формально DNSSEC как раз создан для защиты от подмены DNS‑ответов криптографической подписью. Но на практике он ловит подделку только там, где зона подписана — а youtube.com, rutracker.org и facebook.com подписи не имеют, поэтому валидатор попросту не видит криминала: подмена происходит там, где ему нечего проверять. Продемонстрировать работу DNSSEC‑защиты можно на подписанной зоне — например, torproject.org, где при попытке подмены валидатор сразу выдаст ошибку SERVFAIL с пометкой bogus.

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

Проверяем обычный UDP DNS:

dig @8.8.8.8 example.com 
# если отвечает нормально — базовая связность с 8.8.8.8 есть

Проверяем DoT

kdig -d @1.1.1.1 +tls example.com 
# или 
openssl s_client -connect 1.1.1.1:853 -tls1_3 2>&1 | head -20

Смотрим, на каком шаге обрыв: если TCP не поднимается вообще — блокировка по IP/порту грубым способом (ACL/дроп). Если TCP есть, а TLS обрывается сразу после ClientHello — это DPI.

Проверяем DoH

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' --data-urlencode 'type=A'

Флаг --resolve тут принципиален: он заставляет curl подключаться напрямую по IP, минуя обычный системный DNS, — так вы гарантированно тестируете именно TLS‑сессию к резолверу, а не что‑то ещё в цепочке.

Разделяем SNI‑фильтрацию от блокировки по IP

Если поменять только SNI, оставив IP тот же, и трафик пойдёт — вы нашли SNI‑фильтрацию, а не блокировку по адресу:

curl -v https://1.1.1.1/dns-query \
-H 'host: dns.google' \
-H 'accept: application/dns-json' \
-G --data-urlencode 'name=example.com'

Что с этим делать

• DNS по TCP (обычный незашифрованный DNS, но через TCP вместо UDP) — часто проходит мимо подмены НСДИ, поскольку перехватывается преимущественно UDP/53.

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

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

• Резолвинг внутри полноценного туннеля (весь трафик, включая DNS‑запросы, идёт через VPN) — единственный по‑настоящему надёжный вариант на сегодня: ТСПУ в этом случае не видит ни адреса резолвера, ни самого DNSвопроса, потому что всё это уже завёрнуто в шифрованный туннель на транспортном уровне, а не является отдельной легко узнаваемой TLS/DoH сессией.

И отдельное напоминание про приватность, которое легко упустить за технической стороной: если перехват DNS через НСДИ у вас включён, на государственный резолвер уходят все ваши DNS‑запросы, а не только к заблокированным ресурсам — то есть провайдер (точнее, стоящая на его сети инфраструктура) в этот момент видит полную историю того, куда вы обращаетесь, вне зависимости от того, легален сайт или нет.

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

Это не единичный случай. С начала года прослеживается вектор: сначала точечные тесты в июле, потом системная одновременная блокировка крупнейших DoH/DoT‑провайдеров в августе и подмена через НСДИ на уровне открытого DNS. Дальше, скорее всего, доберутся и до остальных публичных резолверов.

Итак, практический вывод для тех, кто использовал зашифрованный DNS как дополнительное средство приватности: рассчитывать на этот канал как на постоянный больше не стоит.

Дополнительные источники

На ТСПУ начали перехватывать открытые DNS запросы к 1.1.1.1, 8.8.8.8