Watch

Published content check / validate (push) Failing after 6s

Details

hosts: уточнение по фактам — порядок files→dns, права администратора, и главное: браузер с включённым DoH файл hosts обходит

2026-08-28 21:18:40 +03:00

100 KiB

Raw Permalink Blame History

date

🎣 Перехват DNS на ТСПУ: запросы к 8.8.8.8 и 1.1.1.1 заворачивают на резолверы НСДИ (август 2026)

[!info] О чём заметка В августе 2026 у части российских абонентов обычный DNS-запрос по UDP к публичным серверам Google (8.8.8.8, 8.8.4.4) и Cloudflare (1.1.1.1, 1.0.0.1) перестал доходить до самих Google и Cloudflare. Судя по опубликованным замерам, ТСПУ (Технические Средства Противодействия Угрозам — оборудование фильтрации Роскомнадзора в сетях операторов связи) распознаёт DNS внутри пакета и переписывает адрес получателя на сервер НСДИ (Национальная система доменных имён — государственная DNS-инфраструктура, созданная по закону о «суверенном рунете»). Отвечает уже он: для заблокированных доменов — NXDOMAIN, то есть «такого домена не существует», для остальных — настоящие адреса. Здесь разобрано, как это устроено на уровне пакетов, как проверить подмену у себя тремя независимыми способами, почему одновременно перестали открываться серверы шифрованного DNS и что из этого реально лечится.

[!warning] Статус данных: наблюдения сообщества плюс собственная проверка, а не официальная информация Механизм описан по публикации пользователя Хабра angry_agent от 27 августа 2026 (https://habr.com/ru/articles/1075272/), по сообщениям абонентов в обсуждении на ntc.party (блокировка DoH Google, Cloudflare, Quad9, OpenDNS) и по собственным замерам резолверов НСДИ 28 августа 2026 с хоста за пределами российских сетей. Официальных подтверждений от Роскомнадзора, оператора НСДИ или операторов связи нет; вывод «пакеты заворачивают, переписывая адрес получателя» сделан исследователями из единичных замеров и независимо не воспроизводился. Картина различается по регионам, операторам и отдельным узлам одного оператора, меняется в течение суток, и часть блокировок уже откатывали. Проверяйте своё соединение сами — команды в конце заметки.

Если вы просто хотите починить YouTube

Коротко, без теории. Компьютер не может открыть сайт по имени: сначала он спрашивает у DNS-сервера («справочной службы» интернета) числовой адрес. Если у вас перестали открываться YouTube и другие заблокированные сайты, а российские работают, вероятная причина — ответ на этот вопрос подделан по дороге, и браузер считает, что сайта не существует.

Три шага по порядку:

Проверьте, ваш ли это случай: nslookup youtube.com 8.8.8.8 (Windows) или dig www.youtube.com @8.8.8.8 (Linux, macOS). Ответ «Non-existent domain» / NXDOMAIN означает подделку — настоящий Google так не отвечает.
Переключите резолвинг на шифрованный канал или на туннель: включите DoH в браузере, DoT на телефоне и роутере, либо пустите DNS через VPN. Конкретика — в разделе «Что с этим делать» ниже.
После любой смены DNS сбросьте кеш, иначе старый отказ будет мозолить глаза ещё несколько минут: ipconfig /flushdns в Windows, resolvectl flush-caches в Linux, chrome://net-internals/#dns в Chrome, плюс перезагрузка роутера.

Всё остальное в заметке — как это устроено, как доказать подмену и чего ждать дальше.

TL;DR

Волна сообщений пошла вечером 26 августа 2026 (по датировке публикации на Хабре — «примерно с вечера 26 августа»), отдельные абоненты фиксировали подмену уже 21 августа. Открытый, то есть незашифрованный, DNS по UDP/53 к 8.8.8.8 и 1.1.1.1 у части абонентов не доходит до адресата: ответ выглядит пришедшим от Google или Cloudflare, но формирует его сторонний сервер.
Для заблокированных в России доменов (youtube.com, rutracker.org, www.facebook.com) такой ответ — NXDOMAIN, «домена не существует». Для нейтральных доменов возвращаются настоящие адреса, поэтому со стороны это похоже не на поломку, а на выборочное исчезновение части интернета.
Подмену выдают три независимых признака: отказ NXDOMAIN с флагом aa и пустой секцией AUTHORITY, какого у Google и Cloudflare для чужих зон быть не должно; ICMP-ошибка при малом TTL, внутри которой лежит уже переписанный адрес получателя 195.208.5.1; и сеть сервера, который на самом деле обратился к авторитативному серверу, — вместо Google там оказывается инфраструктура MSK-IX.
195.208.5.1 и 195.208.4.1 отвечают именами b.res-nsdi.ru и a.res-nsdi.ru — это резолверы НСДИ, они же указаны в официальной инструкции по подключению операторов к системе. Проверка 28 августа 2026 показала: они отдают NXDOMAIN на youtube.com и rutracker.org и нормально резолвят ya.ru, github.com, discord.com.
Перехват в опубликованных замерах касается UDP: тот же запрос по TCP (dig +tcp, nslookup -vc) уходит до настоящего резолвера и возвращает реальные адреса.
Работает нестабильно: подмена срабатывает не на каждый запрос, серия одинаковых запросов подряд даёт сначала NXDOMAIN, а потом настоящие ответы, а у одного из операторов перехватываются даже запросы к самим резолверам НСДИ.
DNSSEC ловит подделку только на подписанных зонах. youtube.com, rutracker.org и facebook.com не подписаны, и валидатор подделку там не увидит; а вот на подписанном torproject.org перехваченный ответ проверку не проходит.
Параллельно рвутся TLS-соединения к серверам шифрованного DNS по имени в SNI — dns.google, cloudflare-dns.com, dns.adguard.com, dns.quad9.net, dns.alidns.com, doh.sb, wikimedia-dns.org, dns.aa.net.uk. Это другой механизм, и он, в отличие от подмены, лечится Zapret2/Zapret2-стратегиями по хостлисту.
Что помогает: DNS по TCP, DoT (TCP/853) и DoQ (UDP/853), DoH (TCP/443) при обращении по прямому IP, DNSCrypt (у него вообще нет имени сервера в трафике), DoH через zapret, а надёжнее всего — резолвинг внутри туннеля (VLESS/VLESS, amnezia-3-0/amnezia-3-0), где ТСПУ не видит ни адреса резолвера, ни содержимого запроса.

Как открывается сайт и что здесь ломается

Браузер знает имя youtube.com, но соединяться умеет только с числовым адресом вида 142.251.153.4. Чтобы получить адрес по имени, он обращается к резолверу — справочной службе DNS, адрес которой прописан в настройках системы или роутера либо выдан провайдером. Публичные резолверы Google (8.8.8.8) и Cloudflare (1.1.1.1) прописывают вручную, когда хотят обойти фильтрацию у провайдера.

Резолвер оригинал записей не хранит: он рекурсивный, то есть сам обходит цепочку авторитативных серверов — тех, кто действительно держит зону, набор записей конкретного домена. Зону youtube.com держит Google, зону ya.ru — Яндекс.

Обычный DNS-запрос летит открытым текстом по UDP на порт 53. «Открытый» здесь означает не «общедоступный», а «незашифрованный»: любое оборудование по дороге видит и вопрос, и ответ, и может их изменить. Проверки подлинности в обычном DNS нет — клиент принимает первое, что пришло с нужного адреса. Именно на этом свойстве и построено всё описанное ниже. Зашифрованные варианты — DoH и DoT — появились как ответ на эту проблему, и по ним пошла отдельная волна блокировок, разобранная в предпоследней части заметки.

Что видит обычный пользователь

Симптом обманчиво мирный: интернет работает, пинги идут, российские сервисы открываются, а YouTube показывает «Connect to the internet — you're offline» или браузер сообщает, что не удаётся найти DNS-адрес сервера. Первая мысль — «заблокировали сайт» или «сломался VPN», хотя ломается более ранний шаг.

В браузере это выглядит как страница «Не удаётся открыть эту страницу» с кодом DNS_PROBE_FINISHED_NXDOMAIN внизу. Код прямо называет причину: браузер спросил адрес и получил ответ «такого имени не существует» — до сервера YouTube дело не дошло.

Массовая проверка доменов с одного из затронутых соединений (замер абонента из обсуждения на ntc.party, конец августа 2026) показывает картину целиком. Сайты делятся на две группы: одни отвечают нормально, у других резолвинг проваливается с пометкой «Домен не найден» ещё до всякой попытки установить соединение.

В список «домен не найден» попали www.youtube.com, www.facebook.com, www.instagram.com, www.torproject.org, www.dw.com, www.euronews.com, www.svoboda.org, nnmclub.to, www.canva.com, www.apkmirror.com — в основном домены, ограниченные в России или сами ушедшие с рынка (со списком реестра запрещённых сайтов этот перечень не сверялся). Одновременно у части доменов виден другой симптом — TLS DROP с таймаутом рукопожатия, то есть обрыв при установке защищённого соединения.

Разница между двумя симптомами в стадии, на которой всё разваливается. При «домен не найден» соединение даже не начиналось — сорвался DNS. При TLS DROP адрес получен, соединение началось и было оборвано при рукопожатии; это давно знакомая работа ТСПУ по TLS, разобранная в DPI/tspu-false-blocks-june-2026, и прямой связи с подменой DNS у неё не видно.

Почему то не открывается, то вдруг открывается

Частая картина: страница не грузится, вы обновляете её несколько раз — и внезапно всё работает. Это не совпадение и не «само починилось». Правдоподобных объяснений несколько, и по внешним признакам они не различаются.

Первое и главное: подмена срабатывает не на каждый запрос. Абоненты описывают перехват как работающий через раз, а в опубликованном тесте серия одинаковых запросов подряд дала NXDOMAIN только на первый, а остальные вернулись с настоящими адресами (подробности — в разделе «Странности и дырки реализации»). Нажатие «Обновить» — это и есть повторный запрос, который может уйти мимо правила.

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

Третье: браузер мог переключиться на шифрованный канал. В Chrome и Edge есть «Безопасный DNS» (DoH), который в ряде конфигураций включается автоматически; если DoH-соединение установилось, ответ приходит настоящий, минуя подмену открытого UDP. Проверить состояние можно в настройках безопасности браузера.

Четвёртое: отказ живёт в кеше недолго. Отрицательный ответ кешируется системой и браузером; в подменённых ответах нет записи SOA, задающей срок хранения, поэтому время определяется настройками резолвера и обычно измеряется минутами. Пока отказ лежит в кеше, сайт не открывается даже после того, как правило перестало срабатывать.

Понять, что именно происходит у вас, помогает не браузер, а серия ручных запросов подряд: запустите dig www.youtube.com @8.8.8.8 пять раз и посмотрите, стабильно ли приходит NXDOMAIN. Плавающий результат означает, что перехват нестабилен, и полагаться на «сейчас же работает» нельзя.

Что показывает dig: NXDOMAIN там, где его быть не может

Ручная проверка утилитой dig (инструмент отправки DNS-запросов вручную) подтверждает, что дело в резолвинге. Запрос абонента к Cloudflare, 21 августа 2026:

Тот же запрос к Google, две минуты спустя:

В обоих случаях статус ответа — NXDOMAIN. Это код ошибки DNS, означающий «такого имени не существует» — не «доступ запрещён» и не «сайт заблокирован», а именно «домена нет». Для www.youtube.com это заведомо неправда: и Google, и Cloudflare видят зону youtube.com и обязаны вернуть её адреса.

А тот же вопрос, заданный резолверу Яндекса 77.88.8.8 с того же соединения, отвечает нормально:

Версия «сломались сами Google и Cloudflare» отпадает сразу: те же запросы к тем же адресам с сервера за пределами России возвращают настоящие адреса YouTube (проверено 28 августа 2026). Значит, дело не в резолверах, а в том, что происходит с пакетами по дороге к ним.

Признак первый: флаг `aa` и пустая секция AUTHORITY

В заголовке DNS-ответа есть набор коротких флагов. Значение здесь имеет один из них — aa, сокращение от authoritative answer, «авторитативный ответ»: сервер сам держит эту зону и говорит о ней как хозяин, а не пересказывает узнанное у других. Остальные флаги в этих ответах служебные и стоят всегда: qr — «это ответ, а не вопрос», rd — «клиент просил искать рекурсивно», ra — «сервер это умеет».

Google и Cloudflare зоной youtube.com не владеют. Они рекурсивные: идут за ответом к чужим авторитативным серверам и возвращают полученное без флага aa. Проверка 28 августа 2026 с хоста за пределами российских сетей это подтверждает: и у 8.8.8.8, и у 1.1.1.1, и у 77.88.8.8 флаги ответа одинаковые — qr rd ra, без aa.

В ответах на скриншотах выше строка флагов другая: flags: qr aa rd ra. Кто-то по дороге ответил вместо них — причём ответил как сервер, считающий себя хозяином зоны.

Вторая деталь в тех же скриншотах — счётчик AUTHORITY: 0. Отказ «домена не существует» по RFC 2308 полагается сопровождать записью SOA — «паспортом зоны», из которого клиент узнаёт, кто именно и на какой срок сообщил об отсутствии имени. На практике SOA прикладывают все публичные резолверы, включая сам резолвер НСДИ, когда отвечает честно: dig nonexistent-zzz.com @195.208.5.1 возвращает AUTHORITY: 1 и SOA зоны com. В подменённых ответах секция AUTHORITY пуста. Аномалия здесь именно в сочетании: NXDOMAIN + флаг aa + пустая AUTHORITY.

Проверить это у себя можно одной командой:

dig www.youtube.com @8.8.8.8 | grep -E "^;; (->>HEADER|flags)"

Появился aa рядом с NXDOMAIN — почти наверняка отвечал не Google.

Признак второй: TTL и ICMP показывают настоящего получателя

Второй признак показывает не странность ответа, а физический маршрут пакета. Он построен на поле TTL (Time To Live, «время жизни») в заголовке каждого IP-пакета. TTL — счётчик разрешённых пересылок: каждый маршрутизатор на пути уменьшает его на единицу, а если счётчик дошёл до нуля, пакет уничтожается и отправителю посылают служебное сообщение ICMP Time-to-live exceeded — «ваш пакет умер у меня». На этом свойстве работает traceroute: пакетами с TTL 1, 2, 3 и далее по очереди опрашиваются узлы маршрута.

Ключевая деталь: сообщение ICMP об истёкшем TTL содержит внутри себя копию заголовка убитого пакета — чтобы отправитель понял, о каком пакете речь. То есть внутри ICMP-ошибки видно, какой адрес получателя стоял в пакете в момент его гибели — уже после всех преобразований, которые с ним успели проделать по дороге.

Именно это и снял автор публикации на Хабре, отправив DNS-запрос на 8.8.8.8 с намеренно малым TTL (специальным инструментом вроде hping3; повторять это для диагностики не нужно, хватит проверок из чек-листа в конце):

Внутри ICMP-ошибки лежит пакет с адресом получателя 195.208.5.1, хотя отправлялся он на 8.8.8.8. Порт назначения остался 53, протокол — UDP.

Общая картина в виде диаграммы (адреса условные — абонентский узел 5.5.5.2, его шлюз широкополосного доступа 5.5.5.1 — BRAS, Broadband Remote Access Server, — и выходной маршрутизатор оператора 5.5.6.1):

Пока пакет не дошёл до ТСПУ (верхняя половина схемы, TTL 1), ICMP-ошибка от ближнего узла содержит честный исходный заголовок с адресом 8.8.8.8. Как только TTL хватает, чтобы миновать ТСПУ (нижняя половина, TTL 2), следующий узел присылает ошибку уже с 195.208.5.1 внутри. Значит, адрес переписали где-то между этими двумя узлами.

У письма по дороге меняют адрес на конверте, а копия конверта, вернувшаяся с уведомлением «не доставлено», показывает новый адрес — тот, куда его на самом деле отправили.

Расстояние до точки подмены у автора публикации получилось таким: при отправке запросов прямо с маршрутизатора перехват начинался только с TTL 5, то есть обрабатывающий узел стоял в пяти пересылках от него. С сервера за маршрутизатором хватало TTL 2. Отсюда и разные значения в его экспериментах.

Признак третий: кто на самом деле спросил у авторитативного сервера

Третий способ отвечает на вопрос «через кого реально прошёл мой запрос» прямым текстом, без разбора флагов и ICMP. Им участники обсуждения на ntc.party и снимали свою картину.

Приём опирается на служебный домен whoami.akamai.net. Его авторитативный сервер устроен так, что возвращает IP-адрес того резолвера, который к нему обратился. Спросите это имя через 8.8.8.8 — честный ответ будет содержать адрес из сети Google (не сам 8.8.8.8: наружу резолвер ходит с других адресов, поэтому смотреть надо на владельца сети через whois, поля netname и org). Если сеть чужая — вопрос авторитативному серверу задавал не Google.

В замерах абонентов, опубликованных 25 августа 2026, у затронутых резолверов в этом поле оказывалась инфраструктура MSK-IX. Картина при этом у разных людей разная:

Кто замерял	Что показал `whoami.akamai.net`
Абонент 1	MSK-IX только для `8.8.8.8` и `8.8.4.4`; Cloudflare, Quad9, NextDNS, ControlD, Cisco, Яндекс, AdGuard отвечают из своих сетей
Абонент 2	MSK-IX для всех шестнадцати проверенных адресов, включая Яндекс и AdGuard
Абонент 3	MSK-IX для Google, `1.0.0.1` и одного из адресов Cisco OpenDNS; остальные — из своих сетей
Абонент 4	MSK-IX (`193.232.93.61`) для всех восемнадцати адресов, включая российский XboxDNS и оба адреса Яндекса

У второго и четвёртого абонентов www.youtube.com через все резолверы при этом возвращался с настоящим адресом. Весь DNS-трафик уходил в одну точку, но конкретно этот домен там отдавали честно. Факт перехвата и факт блокировки домена — разные вещи: первое зависит от правила на сети, второе — от списка на стороне резолвера, и меняться они могут независимо.

[!note] Что этот признак не доказывает Случаи, когда в одну точку уходит вообще весь DNS, включая российские резолверы, выглядят так же, как давний прозрачный редирект DNS у самого оператора — практика, существовавшая задолго до августа 2026. Отличить одно от другого только по whoami.akamai.net нельзя: связка «MSK-IX в ответе ⇒ это ТСПУ завернуло на НСДИ» держится лишь вместе с уликой из ICMP.

Приём встроен в самодельный детектор, которым пользуются участники обсуждения (утилита DPI Detector, распространяется в той же теме на ntc.party): начиная с версии 3.5.0 он показывает колонку «Реальный резолвер» рядом с заявленным.

Строки вида 8.8.8.8→RIPN-NS5-RU-MSK, 8.8.4.4→RIPN-NS5-RU-MSK и 1.0.0.1→RIPN-NS5-RU-MSK означают, что запрос обслужила не сеть Google или Cloudflare. Показательно, что на том же скриншоте 1.1.1.1→CLOUDFLARENET, 9.9.9.9→i3Dnet и 77.88.8.8→YANDEX — то есть у этого абонента перехвачены не все адреса подряд, а конкретный набор.

Что такое НСДИ и что отвечает 195.208.5.1

НСДИ (Национальная система доменных имён) — государственная система DNS-серверов, введённая статьёй 14.2 закона «Об информации» в редакции ФЗ № 90 от 1 мая 2019 года, известного как закон о «суверенном рунете». Систему создаёт Роскомнадзор, эксплуатацию обеспечивает подведомственный ему Центр мониторинга и управления сетью связи общего пользования на базе ФГУП «ГРЧЦ» (Главный радиочастотный центр). Обязанность её использовать закреплена отдельно, в статье 56.2 закона «О связи»: операторы связи и владельцы технологических сетей, имеющие номер автономной системы (учётной единицы, которой в интернете описывают сеть под единым управлением), с 1 января 2021 года обязаны применять НСДИ при определении сетевых адресов по доменным именам. Фильтрация как функция системы в законе не описана — это уже свойство конкретной реализации.

Содержимое этой базы уже использовали как рубильник: в феврале 2026 из неё DPI/nsdi-domain-removal-2026, и у абонентов, которые резолвят через провайдера, эти сайты просто перестали существовать. Августовский перехват — следующий шаг той же логики: теперь на систему заворачивают и тех, кто от провайдерского DNS ушёл.

Какие адреса участвуют в перехвате, проверяется открытыми средствами. Обратная DNS-запись 195.208.5.1 — b.res-nsdi.ru, парного 195.208.4.1 — a.res-nsdi.ru; res-nsdi читается как resolver NSDI, и оба адреса перечислены в официальной инструкции по подключению операторов к НСДИ. По данным RIPE, диапазоны 195.208.4.0/24 и 195.208.5.0/24 записаны на MSK-IX (московскую точку обмена трафиком — площадку, где операторы стыкуют свои сети), а анонсирует их автономная система AS41740 с именем NDNS. Не путайте её с AS43832 (RIPN-NS5-RU-MSK) из замеров абонентов: это сеть, из которой резолверы НСДИ ходят к авторитативным серверам, а не сеть их собственных адресов. Обе записаны на одну организацию.

Собственная проверка резолверов 28 августа 2026 с хоста за пределами российских сетей:

Запрос к `195.208.5.1`	Ответ
`youtube.com` A	❌ `NXDOMAIN`, флаги `qr aa rd ra`, `AUTHORITY: 0`
`rutracker.org` A	❌ `NXDOMAIN`
`youtube.com` через `+tcp`	❌ `NXDOMAIN` — сам резолвер фильтрует независимо от транспорта
`www.torproject.org` с `+dnssec`	❌ `NXDOMAIN` без подписанного отрицания — зона подписана, значит валидатор такой ответ отвергнет
`ya.ru` A	✅ `NOERROR`, три настоящих адреса Яндекса
`github.com` A	✅ `NOERROR`
`discord.com` A	✅ `NOERROR`, пять адресов Cloudflare

Здесь важно не перепутать два разных «TCP». Запрос по TCP спасает не потому, что резолвер НСДИ пропускает TCP-трафик, а потому, что по TCP пакет физически доезжает до Google. Если же адресоваться к НСДИ напрямую, отказ придёт по любому транспорту — что и видно в третьей строке таблицы.

Резолвер НСДИ не отключает DNS, а фильтрует его: для нейтральных доменов он работает честно и быстро, для доменов из-под блокировок отвечает «такого имени нет». Один из абонентов сформулировал это точнее технического описания: DNS работает, просто на нежелательные сайты выдаётся неправда, а на остальные — настоящие адреса.

Тот же контраст виден и на стороне пользователя. Запрос к резолверу MSK-IX 62.76.62.76 (dns2.ix.ru) возвращает адреса YouTube:

А запросы к 195.208.4.1, 8.8.8.8 и 1.1.1.1 с того же компьютера — «Non-existent domain»:

Различие тут не «фильтрует / не фильтрует», а в списках. Проверка 28 августа 2026 показала, что публичные резолверы MSK-IX (62.76.62.76 и 62.76.76.62) фильтруют с той же сигнатурой — rutracker.org, www.facebook.com и nnmclub.to они отдают как NXDOMAIN с флагом aa и пустой AUTHORITY. Просто youtube.com есть в списке у НСДИ и отсутствует у них.

Отсюда важная оговорка к признаку первому: связка «NXDOMAIN + aa + пустая AUTHORITY» — подпись российского фильтрующего DNS-контура в целом. Как доказательство «ответил не Google» она работает; как доказательство «ответил именно резолвер НСДИ» — нет.

Похоже на DNAT, а не на подделку ответа

Есть два принципиально разных способа испортить пользователю DNS, и различать их важно, потому что лечатся они по-разному.

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

Второй — DNAT (Destination NAT, подмена адреса назначения): пакет не копируется, а перенаправляется. Оборудование переписывает в заголовке адрес получателя и отправляет пакет другому серверу, а на обратном пути выполняет обратную замену, чтобы для клиента ответ выглядел пришедшим оттуда, куда он спрашивал. Клиенту нечем это заметить: в обычном DNS нет проверки подлинности, а обратный адрес в ответе приведён к ожидаемому. В tcpdump у автора публикации ответ действительно приходит с адреса 8.8.8.8 — обратная замена выполняется.

В том единственном опубликованном ICMP-замере признаки указывают на DNAT: при спуфинге исходный пакет ушёл бы к Google неизменённым, и внутри ICMP-ошибки лежал бы адрес 8.8.8.8. Там 195.208.5.1, то есть пакет физически направили на другой сервер. Замер не воспроизводили независимо, так что вывод держится на нём одном.

У этого различия есть следствие для операторов связи: после ТСПУ трафик уходит уже на адрес НСДИ, поэтому в статистике потоков, которую операторы собирают с маршрутизаторов (netflow), объём обращений к 8.8.8.8 должен просесть, хотя абоненты по-прежнему считают, что пользуются Google. Автор публикации на Хабре обращает на это внимание отдельно.

Условий срабатывания у него получилось два. Подмена происходит, когда внутри UDP-пакета лежит именно DNS-запрос — пакет со случайным содержимым на порт 53 уходил без изменений, — и только для определённых адресов назначения: «не на всех DNS серверах происходит DNAT». То есть решение принимается и по содержимому, и по списку адресов, а не по одному признаку.

Насколько это ново

Прозрачный перехват DNS сам по себе не изобретение августа 2026. Часть операторов заворачивала запросы к чужим резолверам на свои годами: у одного из абонентов проводного «Билайна», по его словам, подмена UDP-запросов работает давно и новостью для него не стала. Отсюда осторожная альтернативная версия: у конкретного оператора перехват мог существовать и раньше, а изменился только список доменов, по которым выдаётся отказ.

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

Странности и дырки реализации

Сбои фильтра воспроизводятся вручную и кое-что говорят о его устройстве.

Транспорт TCP почти не трогают. Классический DNS умеет работать и по TCP — этот режим обязателен по стандарту (RFC 7766) и включается автоматически, когда ответ не помещается в UDP-пакет. В наблюдаемых случаях запрос по TCP спокойно уходит до настоящего резолвера: у автора публикации это dig +tcp, у абонентов Северо-Запада — nslookup -vc. Практическая ценность приёма ограничена: операционная система сама по TCP спрашивать не начнёт, а роутер, systemd-resolved (системную службу резолвинга в Linux) или клиентские приложения нужно к этому принуждать настройками.

Перехват работает через раз. Несколько абонентов описывают одно и то же: запросы перехватываются не всегда, а если перехватываются, то подменяются тоже не всегда. Возможное объяснение — балансировка нагрузки между узлами обработки, при которой часть пакетов уходит мимо правила; проверить это со стороны абонента нельзя. Важно, что это не «гонка ответов», характерная для спуфинга: настоящий ответ не обгоняет поддельный, просто часть пакетов не попадает под правило.

Серия быстрых запросов ломает логику. По опубликованному тесту, пять одинаковых запросов подряд в течение миллисекунд (с одного порта и с одним идентификатором запроса) дают первый ответ с NXDOMAIN, а следующие четыре — с настоящими адресами. Похоже, оборудование заводит на первый пакет запись о «разговоре» и по ней решает судьбу следующих, а пока запись заводится, часть пакетов успевает проскочить.

«Прогрев» низким TTL отменяет подмену. По тому же тесту: если сначала отправить DNS-запрос с TTL 2 — он проходит ТСПУ и умирает на следующем узле, не дойдя ни до одного резолвера, — а потом повторить его с обычным TTL 64, ответ приходит настоящий. Со случайным содержимым вместо DNS-запроса фокус не работает. Вероятное объяснение — та же запись состояния, из-за которой повтор считается уже обработанным.

Перехватывают даже запросы к самим резолверам НСДИ. У абонента Дом.ру запросы к 195.208.4.1, 195.208.5.1 и к резолверам MSK-IX 62.76.62.76 и 62.76.76.62 тоже уходят не туда, куда адресованы: детектор показывает для них реальный резолвер RIPN-RU-RND вместо RIPN-NS5-RU-MSK, как у остальных.

Осторожная оговорка: RIPN-RU-RND — ростовская сеть той же организации, а резолверы НСДИ распределённые, поэтому абонент мог просто попадать на ростовскую площадку системы без всякого перехвата. Если же перехват там действительно есть, правило написано слишком широко — «любой открытый DNS на наш узел», без исключений даже для самой государственной системы.

Подмена может касаться только части типов запросов. У абонента одного из московских провайдеров подменялись только запросы адресов IPv6 (тип AAAA), тогда как IPv4 отвечал честно, — при том что IPv6 у этого провайдера, по его словам, вообще нет. Безобидным это не выглядит: браузер обычно спрашивает оба типа адреса сразу, а NXDOMAIN означает «имени не существует вообще», а не «нет адреса такого типа». Подделанный отказ на AAAA способен сломать открытие сайта и тому, у кого только IPv4.

[!note] Почему «дырки» — плохая основа для обхода Все эти сбои воспроизводятся вручную в терминале, но ни один не превращается в рабочую повседневную настройку: браузер не станет слать запросы пачками, а сетевой стек не умеет «прогревать» путь пакетом с малым TTL. Практическую ценность имеет только смена транспорта — TCP, DoT, DoQ или туннель.

География и динамика

Единой картины по стране нет: отсутствие подмены у вас ничего не говорит о соседе на другом операторе. Каждая строка таблицы — одно-два сообщения абонентов за 21–28 августа 2026, а не измерение по региону:

Кто сообщил	Что наблюдал
Абонент из ЦФО	без изменений, подмены нет
Абонент с Северо-Запада	UDP/53 к `1.1.1.1`, `1.0.0.1`, `8.8.8.8`, `8.8.4.4` подменяется; по TCP всё честно
Абоненты Ростелекома в Поволжье	у одних подмены нет ни по UDP, ни через DoH; у других серверы DoH блокировались, а затем `dns.google` и `cloudflare-dns.com` разблокировали, оставив `dns.adguard.com`
Абонент местного провайдера в Москве	подмена только для запросов IPv6
Абонент Дом.ру	перехватываются в том числе запросы к резолверам НСДИ и MSK-IX
Абонент Йоты в Сибири	блокировок нет: DoT, DoH и открытый UDP к Google и Cloudflare работают

Динамика тоже неровная. Один абонент описывает поведение как плавающее: после подключения какое-то время всё работает нормально, а примерно через час начинается подмена. Другой отмечает обратный эффект — на его операторе внезапно ожил Mullvad, по его словам заблокированный по IP ещё в 2023–2024 годах. Разнонаправленные изменения выглядят так, будто правила перекладывали в эти дни, а не так, будто фильтрация включилась в готовом виде.

DNSSEC: ловит подделку, но не везде

DNSSEC (DNS Security Extensions) — механизм криптографических подписей для DNS: владелец зоны подписывает свои записи, а резолвер, умеющий проверять подписи (валидирующий), отвергает ответ, который с подписью не сходится. Это касается и отрицательных ответов: настоящее «домена не существует» подтверждается специальными подписанными записями отрицания, доказывающими отсутствие имени, а не просто заявляющими его.

Ключевое ограничение, которое часто упускают: защита работает только для подписанных зон. Большинство заблокированных доменов не подписаны — у youtube.com, rutracker.org, facebook.com и instagram.com нет DS-записи в родительской зоне (проверено 28 августа 2026), и валидатор примет подделанный NXDOMAIN как «неподписанный» ответ, ничего не заметив. Для них DNSSEC бесполезен.

А вот torproject.org подписан — и там подделка видна сразу. Собственная проверка: dig +dnssec www.torproject.org @195.208.5.1 возвращает NXDOMAIN с флагом aa, AUTHORITY: 0 и без единой подписи отрицания. У валидирующего резолвера такой ответ не пройдёт проверку и превратится в ошибку SERVFAIL.

Из этого следуют два практических вывода:

Как проверка. Включив валидацию DNSSEC, подмену можно увидеть — но проверять надо на подписанном заблокированном домене, например torproject.org, а не на YouTube. Отказ валидации бывает и по другим причинам (сбитое время на устройстве, кривая зона, ретранслятор по дороге), так что это грубый индикатор, а не однозначный вердикт.
Как побочный эффект. У абонента Ростелекома включение DNSSEC в роутере обрушило вообще весь UDP-DNS. Из механики подмены это напрямую не следует — резолверы НСДИ отдают корректные подписи для нефильтруемых имён, — так что причина такого поведения из наблюдения не выводится; конфигурацию роутера при этом никто не смотрел. Практический вывод один: включайте валидацию для проверки и знайте, как её выключить обратно, если интернет пропадёт.

Вторая половина клещей: DoH режут по SNI

Очевидный ответ на подмену открытого DNS — уйти в шифрованный: DoH (DNS-over-HTTPS, запросы внутри обычного HTTPS-соединения), DoT (DNS-over-TLS, отдельный порт 853/TCP) или DoQ (DNS-over-QUIC, порт 853/UDP). Одновременно с перехватом UDP абоненты сообщили о второй волне — по самим серверам шифрованного DNS.

Механика здесь другая. TLS-соединение начинается с приветствия (ClientHello), в котором открытым текстом передаётся SNI (Server Name Indication — поле с именем сервера, нужное, чтобы один IP-адрес мог обслуживать много разных сайтов). Соединение обрывается сразу после этого приветствия — характерная картина для блокировки по имени:

root@OpenWrt:~# curl -v https://dns.google/dns-query
TLSv1.3 (OUT), TLS handshake, Client hello (1):
TLSv1.3 (OUT), TLS alert, decode error (562):
TLS connect error: error:0A000126:SSL routines::unexpected eof while reading
curl: (35) TLS connect error: error:0A000126:SSL routines::unexpected eof while reading

По сообщениям абонентов за 21–28 августа 2026 под раздачу попадали dns.google, cloudflare-dns.com, dns.adguard.com, dns.adguard-dns.com, dns.quad9.net, dns.alidns.com, dns.aa.net.uk, doh.sb и wikimedia-dns.org. То же видно в логах роутера Keenetic, где встроенный клиент https-dns-proxy не может установить TLS к настроенным резолверам:

У тех абонентов, чьи замеры опубликованы, блокировка привязана к имени, а не к адресу. Нагляднее всего это в прогоне детектора, где строка Cloudflare (обращение по имени) даёт таймаут DoH, а строка Cloudflare (IP) — те же 58 мс, что и обычный UDP:

Ручные проверки того же абонента, у которого открытый UDP уже подменялся, подтверждают: 21 августа 2026 DNS-over-TLS к Cloudflare по прямому адресу работал —

— и DNS-over-HTTPS к нему же тоже:

Оба ответа — NOERROR с восемью настоящими адресами YouTube. Так что «шифрованный DNS запретили» — преувеличение: давят его точечно, по именам серверов, а часть имён (dns.google, cloudflare-dns.com у абонентов Ростелекома в Поволжье) уже успели разблокировать обратно.

Подменить содержимое DoH или DoT при этом нельзя без действующего сертификата на имя резолвера, то есть без полноценного перехвата TLS. Теоретическая лазейка одна — корневой сертификат, которому система доверяет по воле самого пользователя; тема разобрана в nuc/mincifry-nuc-certs-danger-june-2026. Публично о выпуске таких сертификатов на DoH-резолверы не сообщалось.

Отдельное наблюдение автора детектора: популярные серверы DoH временами отвечают медленнее примерно на 270 мс, и эффект то появляется, то пропадает. По его тестам замедление вызывает темп открытия TLS-соединений — залп из нескольких соединений подряд провоцирует реакцию DPI, тогда как одиночные запросы проходят нормально. Это наблюдение одного исследователя на одном соединении; как общий признак блокировки его использовать рано.

Практический вывод: блокировка по SNI обходится теми же средствами, что и блокировка обычного сайта. Домен резолвера добавляется в хостлист (список доменов, к которым применяются стратегии) Zapret2/Zapret2, дальше работают обычные приёмы дробления TLS-приветствия — подробности в заметке Zapret/doh-cherez-zapret. Сообщения «запреткой чинится» относятся именно к этому случаю. С подменой открытого DNS zapret в нынешнем виде ничего сделать не может: там ломается не TLS-соединение, а маршрут UDP-пакета.

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

Варианты по возрастанию устойчивости: верхние строки держатся, пока правило не расширили, нижняя от списка перехватываемых адресов не зависит вовсе.

Решение	Помогает от подмены	Оговорки
Другой открытый резолвер (например, `77.88.8.8`)	⚠️ иногда	У части абонентов не перехватывается, но российские резолверы могут фильтровать по своему списку
DNS по TCP (`dig +tcp`, `nslookup -vc`)	✅ в наблюдаемых случаях	Ручной приём; заставить систему и приложения ходить по TCP непросто, а правило легко расширят и на TCP
DoT (853/TCP) и DoQ (853/UDP)	✅ на 28 августа 2026 работают	По прямому IP порт жив; при обращении по имени соединение могут оборвать
DoH по прямому IP-адресу	✅ на 28 августа 2026 работает	Часть клиентов ругается на сертификат — нужен клиент, умеющий задавать имя отдельно от адреса
Прописать адреса в `hosts`	✅ для перечисленных доменов	Резолвинг для них не выполняется вовсе; масок нет, адреса устаревают, от блокировки по SNI не спасает
DNSCrypt (в том числе Anonymized DNS)	✅ подмена невозможна	Имени сервера в трафике нет, поэтому блокировка по SNI мимо; но адрес резолвера известен и режется по IP — разбор ниже
DoH по имени + Zapret2/Zapret2 по хостлисту	✅ при блокировке по SNI	Бесполезно, если резолвер режут по IP-адресу — см. Zapret/doh-cherez-zapret
Валидация DNSSEC	⚠️ как индикатор	Работает только на подписанных зонах; `youtube.com` не подписан
Собственный рекурсивный резолвер без форвардинга	⚠️ временно	Разбор ниже: работает, пока правило не расширили на корневые и TLD-серверы
DNS внутри туннеля (VLESS/VLESS, amnezia-3-0/amnezia-3-0)	✅ устойчиво	Запросы уходят зашифрованными вместе с остальным трафиком; ТСПУ не видит ни резолвера, ни имени

Где это включается на практике:

Android: Настройки → Подключения → Частный DNS (это DoT). Поле принимает только имя хоста, а имена популярных резолверов как раз и режут по SNI, — если не заработало, вариант остаётся один: туннель.
Windows 11: Параметры → Сеть и Интернет → свойства адаптера → «Назначение DNS-сервера» → изменить → «Шифрование DNS: только зашифрованные».
Браузер: Chrome — Настройки → Конфиденциальность → «Использовать безопасный DNS»; Firefox — Настройки → Приватность → «DNS через HTTPS». Чинит только браузер, остальные приложения продолжат ходить открытым DNS.
Роутер: Keenetic — «Серверы DNS» с указанием DoH/DoT; OpenWrt — пакет https-dns-proxy; на компьютере тот же результат дают dnscrypt-proxy (умеет и DoH, и DNSCrypt — см. разбор ниже), AdGuard Home или YogaDNS, если роутер шифрованный DNS не умеет.
VPN: сам факт подключения ничего не гарантирует — запрос имени может уходить мимо туннеля. В клиенте нужно включить отправку DNS через туннель (в разных клиентах это «Remote DNS», «DNS через прокси», «Route DNS through tunnel») и проверить результат командами из чек-листа.

После любой смены резолвера сбросьте кеш: ipconfig /flushdns в Windows, resolvectl flush-caches в Linux, chrome://net-internals/#dns в Chrome, перезагрузка роутера. Отрицательный ответ кешируется, и без сброса вы будете видеть старую ошибку и решите, что совет не сработал.

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

Самый дешёвый способ: прописать адреса в hosts

Если нужно вернуть один-два конкретных сайта прямо сейчас, можно вообще не спрашивать ни у какого резолвера. Файл hosts — простой список «адрес — имя», который системный резолвер просматривает до отправки DNS-запроса: нашлось имя в файле — запрос в сеть не уходит, и подменять по дороге нечего. В Linux этот порядок прямо задан строкой hosts: files dns в /etc/nsswitch.conf (проверено: запись в /etc/hosts перебивает DNS для getent и ping), в Windows и macOS то же поведение по умолчанию. Сам файл лежит в C:\Windows\System32\drivers\etc\hosts и в /etc/hosts, править нужно с правами администратора или root.

Настоящие адреса берутся из источника, который на вашем соединении отвечает честно: dig +tcp +short www.youtube.com @8.8.8.8, тот же запрос через DoT, из-под туннеля или с зарубежного сервера. После правки сбросьте кеш DNS, иначе система какое-то время будет отдавать старый отказ.

Ограничений у приёма больше, чем кажется:

Браузер с собственным шифрованным DNS может файл не увидеть. Если в Chrome, Edge или Firefox включён «безопасный DNS», браузер резолвит имена сам, минуя системный резолвер, — а вместе с ним и hosts. У Firefox это давняя известная особенность режима TRR (в багтрекере Mozilla — #1624112 и #1511643); обходится переключением режима или списком исключений network.trr.excluded-domains. О таком же поведении Chrome сообщают пользователи. Если запись в файле не действует — первым делом проверьте эту настройку браузера. Системный DoH (например, в Windows 11 или в systemd-resolved) файлу не мешает: запись проверяется раньше, чем формируется запрос.
Масок не существует. Написать *.googlevideo.com нельзя, каждое имя вписывается отдельной строкой. Для страницы сайта это терпимо, для сервисов с сотнями поддоменов — нет.
Адреса протухают. Крупные сервисы отдают разные адреса разным регионам и меняют их постоянно, так что запись рано или поздно станет медленной или мёртвой.
Лечится только шаг с адресом. Если тот же сайт вдобавок режут по имени в TLS-приветствии, hosts не поможет — соединение оборвут уже после того, как адрес получен; там нужен Zapret2/Zapret2 или туннель.
HTTPS при этом не ломается: сертификат проверяется по имени сайта, а имя вы не меняете.

Про сам файл, его правку и встроенный редактор в Zapret GUI — в заметке Zapret/hosts.

Поможет ли DNSCrypt

DNSCrypt — третий протокол шифрованного DNS, старше DoH и DoT и устроенный иначе. Клиент (обычно dnscrypt-proxy) заранее знает три вещи о резолвере: его адрес, порт и долговременный публичный ключ провайдера. Всё это упаковано в «штамп» — строку вида sdns://…, которую вы вставляете в конфигурацию. Дальше клиент забирает у резолвера краткосрочный сертификат, проверяет на нём подпись тем самым известным ключом и только потом начинает слать запросы, зашифрованные и подписанные.

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

Вторая полезная особенность — в DNSCrypt нет поля SNI. Соединение идёт на адрес и порт (по умолчанию 443, но резолверы часто используют и другие), а имя сервера в открытом виде по проводу не передаётся. Та волна блокировок, что сейчас рвёт DoH-соединения по имени dns.google и cloudflare-dns.com, DNSCrypt по этому признаку не задевает в принципе.

Слабые места тоже есть, и о них лучше знать заранее:

Блокировка по IP-адресу. Адреса публичных DNSCrypt-резолверов есть в открытых списках, и заблокировать их по адресу так же просто, как любой другой сервер. Шифрование от этого не спасает.
Протокол не маскируется. Здесь важное отличие от DoH: тот прячется в общей массе обычного HTTPS-трафика, и отличить запрос к резолверу от загрузки любого сайта тяжело. DNSCrypt же ни на что не притворяется — у него собственный формат пакета, начинающийся с восьмибайтового идентификатора выбранного сертификата, а перед первым запросом клиент забирает сертификат обычным DNS-запросом с именем вида 2.dnscrypt-cert.<зона-провайдера>, которое видно открытым текстом. Оборудованию, которое уже разбирает содержимое DNS-пакетов, распознать такой обмен несложно, и забанить его можно прямо по протоколу. Случаев целенаправленной блокировки DNSCrypt в России на 28 августа 2026 не описано, но техническая возможность очевидна.
Anonymized DNS решает другую задачу. Режим с промежуточным ретранслятором скрывает ваш адрес от самого резолвера — то есть защищает от того, кто на другом конце, а не от того, кто по дороге. Против блокировки по IP он помогает лишь в той мере, в какой не заблокирован адрес ретранслятора.

Ставить DNSCrypt нужно руками: браузеры его не поддерживают, галочки «безопасный DNS» тут не хватит. Нужен dnscrypt-proxy — на компьютере или на роутере, в OpenWrt и Keenetic он есть готовым пакетом. Заодно эта же программа умеет DoH и режим Anonymized DNSCrypt через ретрансляторы.

По устойчивости DNSCrypt стоит там же, где DoH и DoT по прямому IP: сегодня работает, потому что до него не дошли руки, а не потому, что его нельзя заблокировать. Это по-прежнему обращение к известному публичному серверу по известному адресу. Единственный вариант, не зависящий от списков, — резолвить внутри туннеля, где DNS-запрос неотличим от остального трафика.

Свой резолвер без форвардинга — и почему это не окончательное решение

Промежуточный вариант, который часто предлагают: поднять у себя — на роутере, домашнем сервере или компьютере — полноценный рекурсивный резолвер вроде Unbound и не настраивать в нём пересылку запросов на чужой публичный сервер. Тогда машина перестаёт спрашивать 8.8.8.8 и делает всю работу сама: обращается к корневым серверам, узнаёт у них адреса серверов зоны верхнего уровня (TLD — Top Level Domain: .com, .org, .ru), затем спрашивает у них адреса авторитативных серверов нужного домена и только потом получает адрес сайта. Вариант для тех, кто уже поднимал сетевые сервисы: в конфигурации Unbound достаточно не задавать ни одного forward-zone.

На 28 августа 2026 это работает. Вероятное объяснение — правило подмены применяется к известным адресам публичных резолверов (сам автор публикации отмечает, что «не на всех DNS серверах происходит DNAT»), а корневые и TLD-серверы в этот список не попали; проверить это со стороны абонента нельзя.

Принципиальной защиты здесь нет. Запросы к корневым серверам и серверам зоны идут тем же открытым DNS по UDP/53, и оборудование, которое уже умеет распознавать DNS внутри пакета и переписывать адрес получателя, технически способно применить правило шире — к любому исходящему DNS-запросу. В таком сценарии цепочка «браузер → локальный резолвер → корневые → TLD → авторитативный сервер» порвалась бы на первом же внешнем шаге, и работающими остались бы только разрешённые резолверы.

[!warning] Это прогноз, а не наблюдение На 28 августа 2026 перехвата запросов к корневым и TLD-серверам не зафиксировано, публичных заявлений о таких планах не встречалось. Речь о технической возможности, вытекающей из уже показанного механизма. Насколько такой шаг вероятен — вопрос не технический: он ломает работу почтовых серверов, антиспам-проверок, DNSSEC-валидации и всего, что ходит в DNS напрямую, поэтому цена сопутствующего ущерба здесь заметно выше, чем у перехвата пары известных адресов.

Если этот сценарий реализуется, устойчивым останется один подход — резолвить внутри туннеля: запрос уходит зашифрованным вместе с остальным трафиком и внешне не отличается от любого другого соединения. Как это устроено в клиентах — в sing-box/architecture и в разделе про DNS у Clash/06-features-protocols.

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

Менять резолвер законно и технически безобидно, но два последствия стоит держать в голове.

Первое — бытовое. С чужим DNS могут отвалиться внутренние ресурсы провайдера, IPTV, корпоративная сеть и страницы авторизации в гостиничном и кафейном Wi-Fi: они резолвятся только «домашним» сервером сети. Включённая валидация DNSSEC на роутере в отдельных случаях оставляла абонентов вообще без работающего DNS, так что знать, как её выключить обратно, стоит заранее.

Второе — приватность, и оно важнее. Если перехват настроен на вашем узле, на государственный резолвер уходят все ваши DNS-запросы, а не только к заблокированным сайтам, — даже когда в настройках прописан Google или Cloudflare. Список запрашиваемых имён — это, по сути, список посещённых сайтов; для нейтральных доменов ответ приходит честный, поэтому заметить сбор данных по поведению системы невозможно. Единственный способ этого избежать — увести резолвинг в шифрованный канал или в туннель, где содержимое запроса недоступно по дороге. Общие приёмы — в Privacy.

Почему тестеры иногда врут

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

Первый пример: сводка «DoH недоступен у всех двенадцати серверов».

Владелец замера отмечает, что тот же результат получается даже при работе через Cloudflare WARP, хотя настроенный на роутере DoH в этот момент исправно резолвит имена. То есть «0/12» здесь указывает скорее на проблему в самой проверке, чем на состояние сети.

Второй пример: вердикт «подмены нет, 6/6» на соединении, где часть резолверов вообще не ответила.

Разгадка в том, что проверка сравнивает адреса, полученные двумя путями — через DoH и через открытый UDP, — и делает вывод только по тем доменам, по которым получила оба ответа. Домены из её списка (rutor.info, flibusta.is, rezka.ag и другие) на этом соединении резолвились одинаково, отсюда и «6/6 не подменяется». Резолверы, которые «не ответили», в счёт не попали, а youtube.com в списке отсутствует вовсе. На другом прогоне того же теста 8.8.8.8 отвечает, сравнение идёт уже с ним — и вердикт снова «6/6», хотя проверены те же шесть доменов, ни один из которых у этого абонента не подменялся:

То есть вердикт описывает не состояние соединения, а результат по конкретному короткому списку доменов.

Проверяйте вручную и на том домене, который у вас не открывается. Сводный вердикт полезен как быстрый обзор, но принимать по нему решение нельзя — ни в одну, ни в другую сторону.

Контекст: часть более широкой перестройки фильтрации

В июле 2026 у 8.8.8.8 DPI/google-dns-8888-block-july-2026, из-за чего «сломались» VPN-клиенты с этим адресом в конфиге: тогда давили шифрованный DNS, теперь взялись за открытый. Параллельно обновлённая версия ТСПУ, раскатанная с начала июня 2026, по наблюдениям сообщества принимает часть обычных TLS-соединений за VPN и растягивает установку соединения — отсюда долгая загрузка игр и вялые сайты, разобранные в DPI/tspu-false-blocks-june-2026. Общее направление описано в DPI/rkn-vpn-2030-roadmap.

Меняются и мелкие детали, о которых легко забыть при диагностике. Флаг Chrome cryptography-compliance-cnsa, который DPI/chrome-cnsa-flag-bypass, в конце августа 2026 у части пользователей начал давать обратный эффект: YouTube переставал открываться, пока флаг не выключали. Проверяется быстро — chrome://flags, найти флаг по имени, поставить Default, перезапустить браузер.

Отдельно стоит мотив, который называет автор публикации на Хабре в обновлении от 28 августа 2026: перехват может быть способом снять нагрузку с самих ТСПУ. Если заблокированный домен не резолвится, соединение к нему не устанавливается вовсе, и оборудованию не приходится разбирать TLS-приветствие и принимать решение по SNI. Экономия здесь именно на разборе TLS — разбирать сами DNS-пакеты фильтру по-прежнему приходится. Это предположение исследователя, а не установленная причина. В обсуждении звучит и более осторожная версия: нынешние волны похожи на обкатку и сбор данных, а не на финальную конфигурацию — но это оценка участников, проверить её нечем.

Как проверить своё соединение

Команды запускать с того устройства, где наблюдается проблема. dig и whois не входят в стандартную поставку: в Debian и Ubuntu это пакеты dnsutils и whois, в Fedora — bind-utils, в OpenWrt — bind-dig; в Windows их нет, там работают через nslookup и веб-сервисы whois.

Проверить подмену: dig www.youtube.com @8.8.8.8 | grep -E "^;; (->>HEADER|flags)" — NXDOMAIN вместе с флагом aa означает подделку. В Windows: nslookup youtube.com 8.8.8.8, признак — ответ «Non-existent domain».
Сравнить с TCP: dig +tcp www.youtube.com @8.8.8.8, в Windows — nslookup -vc youtube.com 8.8.8.8 или в PowerShell Resolve-DnsName youtube.com -Server 8.8.8.8 -TcpOnly. Настоящие адреса по TCP при NXDOMAIN по UDP — подтверждение перехвата.
Узнать реального резолвера: dig +short whoami.akamai.net @8.8.8.8, затем whois полученного адреса — смотреть поля netname и org. Адрес не совпадает с 8.8.8.8 — это нормально; важно, чтобы сеть принадлежала Google.
Проверить на подписанной зоне: dig +dnssec www.torproject.org @8.8.8.8 — NXDOMAIN без подписанных записей отрицания на подписанном домене подделку выдаёт однозначно (в отличие от youtube.com, который DNSSEC не подписан).
Посмотреть маршрут настоящим DNS-запросом: обычный traceroute -U -p 53 тут не годится — он шлёт на порт 53 не DNS-запрос, а набивку, а правило, судя по замерам, реагирует именно на содержимое. Подходит dnstraceroute из пакета dnsdiag: sudo dnstraceroute -x -s 8.8.8.8 -t A www.youtube.com. Путь, обрывающийся внутри России вместо сети Google, означает, что запросы уходят не туда.
Проверить DoH: curl -v https://dns.google/dns-query — обрыв соединения сразу после ClientHello (unexpected eof while reading) означает блокировку по SNI, которая лечится Zapret2/Zapret2. Нормальный результат выглядит иначе: рукопожатие проходит и сервер отвечает HTTP/2 400 со страницей «Query must have a valid 'dns' parameter» — запрос без параметров ему не нравится, но соединение установлено.
Проверить DoT по адресу: dig +tls @1.1.1.1 www.youtube.com — рабочий ответ означает, что порт 853 у вас ещё жив. Ключ +tls есть начиная с BIND 9.18; если dig ругается Invalid option, возьмите kdig +tls @1.1.1.1 www.youtube.com из пакета knot-dnsutils. Проверку сертификата dig по умолчанию не делает — для неё нужен +tls-ca.

Время ответа как признак ненадёжно: 8.8.8.8 и 1.1.1.1 — anycast-адреса с узлами внутри России и по соседству, поэтому даже без перехвата ответ приходит за десятки миллисекунд. Смотрите на содержимое ответа и на владельца сети, а не на скорость.

Состояние меняется по дням и по узлам, поэтому единичный отрицательный результат не доказывает, что перехвата нет: у одного из абонентов подмена включалась примерно через час после подключения.

В роутере несколько DNS — через какой идёт трафик

Частый вопрос при диагностике: в настройках прописаны два-три сервера, какой из них отвечает прямо сейчас? Ответ неприятный: заранее это неизвестно, а «поровну между ними» не делится никогда.

Типичная конфигурация домашнего роутера выглядит примерно так — шесть серверов вперемешку, DoT и DoH, часть задана именем, часть адресом с нестандартным портом:

Обратите внимание на разницу в записях: dns.google задан именем (значит, имя уйдёт в SNI и попадёт под текущую волну блокировок), а 45.155.204.190:853 — адресом с портом, то есть по имени его не отфильтруешь. Порт 444 вместо стандартного 443 у другой записи — то же самое соображение, только про блокировку по порту.

Если резолвингом занимается роутер, чаще всего внутри работает dnsmasq. По умолчанию он не идёт по списку сверху вниз: в документации прямо сказано, что запрос отправляется любому из известных серверов с предпочтением тех, которые «известны как живые», а строгий порядок включается отдельной опцией strict-order. На практике это значит, что предпочтение получает тот, кто отвечает быстрее, — а перехваченный резолвер отвечает очень быстро, потому что ответ формируется рядом, внутри страны. Подделка выигрывает гонку у честного сервера просто по задержке.

В операционной системе логика другая, но результат так же непредсказуем для пользователя: Windows опрашивает предпочитаемый сервер и переключается на альтернативный при неудаче, systemd-resolved в Linux держит «текущий» сервер и меняет его при ошибках. Отказ NXDOMAIN при этом ошибкой не считается — это валидный ответ, поэтому переключения на второй сервер он не вызывает.

Отдельный слой — приложения. Браузер с включённым «безопасным DNS» ходит своим каналом мимо системных настроек, VPN-клиент подставляет собственный резолвер, у контейнеров и WSL свои настройки. Так что ситуация «в системе один DNS, в браузере другой, в VPN третий» — нормальная, если вы что-то из этого настраивали; странно было бы обратное.

Узнать, кто ответил на самом деле, можно теми же средствами, что и в чек-листе:

dig +short whoami.akamai.net без @сервер — покажет адрес резолвера, который реально ходил за ответом от имени вашей системы; дальше whois по этому адресу. Проверено: на машине с двумя серверами в /etc/resolv.conf (1.1.1.1 и 8.8.8.8) команда вернула адрес из сети Cloudflare — то есть отвечал первый.
В Linux — resolvectl status, строка «Current DNS Server»; в Windows — nslookup без аргументов печатает Server: с текущим сервером, а Get-DnsClientServerAddress в PowerShell показывает весь список.
На роутере с OpenWrt — включить log-queries в dnsmasq и посмотреть в логе строки forwarded … to …: там прямо написано, какому апстриму ушёл каждый запрос.
В Chrome и Edge — chrome://net-internals/#dns и настройки безопасного DNS: они покажут, ходит браузер своим каналом или через систему.

Если нужна предсказуемость, лечится это не диагностикой, а конфигурацией: оставить один резолвер, включить strict-order на роутере или увести резолвинг в туннель — тогда вопрос «через какой сервер сейчас» просто не возникает.

📚 См. также

DPI/nsdi-domain-removal-2026 — предыстория: записи YouTube и WhatsApp убрали из самой системы, на которую теперь заворачивают чужой DNS-трафик
DPI/google-dns-8888-block-july-2026 — предыдущая волна по тому же адресу, но с другого конца
Zapret/doh-cherez-zapret — что чинится хостлистом, а что нет
DPI/tspu-false-blocks-june-2026 — сопутствующий ущерб обновлённых правил
DPI/chrome-cnsa-flag-bypass — приём обхода, который в конце августа 2026 начал мешать
nuc/mincifry-nuc-certs-danger-june-2026 — единственная теоретическая лазейка к содержимому DoH
DPI/rkn-vpn-2030-roadmap — куда движется фильтрация по официальным планам
DPI/DPI — обзор всех заметок по теме
🔗 Публикация angry_agent на Хабре, 27 августа 2026 — первоисточник разбора с ICMP и схемой
🔗 Новость Хабра о блокировке DoH, 26 августа 2026 — предыдущий шаг той же волны
🔗 Обсуждение блокировки DoH на ntc.party — замеры абонентов из разных регионов
🔗 Новость на Anti-Malware, 27 августа 2026 — краткий пересказ для нетехнического читателя

[!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: исходник этой заметки · скачать весь репозиторий одним zip-архивом.

100 KiB Raw Permalink Blame History Unescape Escape