SavePearlHarbor

В России начали блокировать протоколы DoH и DoT

—

от автора

admin

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

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

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

Обычный 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 0curl: (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 0curl: (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-трюк с ICMP. Отправляем запрос с искусственно заниженным TTL так, чтобы пакет не долетел до настоящего получателя и по пути сгенерировал ICMP Time Exceeded — в этой ошибке виден реальный узел, который ответ обработал:

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

Служебный домен-маркер 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/dns-query -H 'accept: application/dns-json' -G --data-urlencode 'name=example.com' --data-urlencode 'type=A'

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

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

Если поменять только SNI, оставив IP тот же (например, через curl --connect-to ), и трафик пойдёт — вы нашли 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 как дополнительное средство приватности: рассчитывать на этот канал как на постоянный больше не стоит.

ссылка на оригинал статьи https://habr.com/ru/articles/1077682/