507 lines
100 KiB
Markdown
507 lines
100 KiB
Markdown
---
|
||
date: 2026-08-28
|
||
tags:
|
||
- dns
|
||
- doh
|
||
- dot
|
||
- dnssec
|
||
- tspu
|
||
- rkn
|
||
- нсди
|
||
- dnat
|
||
- incident
|
||
- censorship
|
||
aliases:
|
||
- Перехват DNS на ТСПУ август 2026
|
||
- 8.8.8.8 возвращает NXDOMAIN
|
||
- Перехват DNS-запросов к 1.1.1.1
|
||
- Почему youtube.com не резолвится
|
||
- 195.208.5.1 что это за адрес
|
||
- НСДИ подменяет DNS запросы
|
||
- Заблокировали DoH Google Cloudflare август 2026
|
||
- whoami.akamai.net MSK-IX что это значит
|
||
description: "Разбор наблюдений августа 2026: открытый DNS к 8.8.8.8 и 1.1.1.1 заворачивают на резолверы НСДИ. Как проверить подмену у себя и что помогает."
|
||
image: DPI/attachments/tspu-dns-nsdi-dnat-header.webp
|
||
link: https://habr.com/ru/articles/1075272/
|
||
---
|
||
|
||
> [!mirror] Резервное зеркало
|
||
> Актуальная версия этой страницы — на основной вики: [wiki.zapret.moe/DPI/tspu-dns-nsdi-dnat-august-2026](https://wiki.zapret.moe/DPI/tspu-dns-nsdi-dnat-august-2026)
|
||
|
||
# 🎣 Перехват DNS на ТСПУ: запросы к 8.8.8.8 и 1.1.1.1 заворачивают на резолверы НСДИ (август 2026)
|
||
|
||
![[tspu-dns-nsdi-dnat-header.webp]]
|
||
|
||
> [!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](https://ntc.party/t/%D0%B1%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D0%BE%D0%B2%D0%BA%D0%B0-doh-google-cloudflare-quad9-opendns/23007)) и по собственным замерам резолверов НСДИ 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|zapret]]-стратегиями по хостлисту.
|
||
- Что помогает: **DNS по TCP**, **DoT** (TCP/853) и **DoQ** (UDP/853), **DoH** (TCP/443) при обращении по прямому IP, **DNSCrypt** (у него вообще нет имени сервера в трафике), **DoH через zapret**, а надёжнее всего — резолвинг **внутри туннеля** ([[VLESS/VLESS|VLESS]], [[amnezia-3-0/amnezia-3-0|AmneziaWG]]), где ТСПУ не видит ни адреса резолвера, ни содержимого запроса.
|
||
|
||
## Как открывается сайт и что здесь ломается
|
||
|
||
Браузер знает имя `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», хотя ломается более ранний шаг.
|
||
|
||
![[tspu-dns-nsdi-youtube-offline-cnsa-flag.png]]
|
||
|
||
В браузере это выглядит как страница «Не удаётся открыть эту страницу» с кодом `DNS_PROBE_FINISHED_NXDOMAIN` внизу. Код прямо называет причину: браузер спросил адрес и получил ответ «такого имени не существует» — до сервера YouTube дело не дошло.
|
||
|
||
![[tspu-dns-nsdi-browser-nxdomain-error.png]]
|
||
|
||
Массовая проверка доменов с одного из затронутых соединений (замер абонента из обсуждения на ntc.party, конец августа 2026) показывает картину целиком. Сайты делятся на две группы: одни отвечают нормально, у других резолвинг проваливается с пометкой «Домен не найден» ещё до всякой попытки установить соединение.
|
||
|
||
![[tspu-dns-nsdi-domain-check-dns-fail-august-2026.png]]
|
||
|
||
В список «домен не найден» попали `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:
|
||
|
||
![[tspu-dns-nsdi-dig-cloudflare-nxdomain-21august2026.png]]
|
||
|
||
Тот же запрос к Google, две минуты спустя:
|
||
|
||
![[tspu-dns-nsdi-dig-google-nxdomain-21august2026.png]]
|
||
|
||
В обоих случаях статус ответа — `NXDOMAIN`. Это код ошибки DNS, означающий «такого имени не существует» — не «доступ запрещён» и не «сайт заблокирован», а именно «домена нет». Для `www.youtube.com` это заведомо неправда: и Google, и Cloudflare видят зону `youtube.com` и обязаны вернуть её адреса.
|
||
|
||
А тот же вопрос, заданный резолверу Яндекса `77.88.8.8` с того же соединения, отвечает нормально:
|
||
|
||
![[tspu-dns-nsdi-dig-yandex-noerror-21august2026.png]]
|
||
|
||
Версия «сломались сами 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.
|
||
|
||
Проверить это у себя можно одной командой:
|
||
|
||
```bash
|
||
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`; повторять это для диагностики не нужно, хватит проверок из чек-листа в конце):
|
||
|
||
![[tspu-dns-nsdi-icmp-ttl-exceeded-august-2026.png]]
|
||
|
||
Внутри 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`):
|
||
|
||
![[tspu-dns-nsdi-dnat-scheme-august-2026.png]]
|
||
|
||
Пока пакет не дошёл до ТСПУ (верхняя половина схемы, 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 он показывает колонку «Реальный резолвер» рядом с заявленным.
|
||
|
||
![[tspu-dns-nsdi-detector-real-resolver-august-2026.png]]
|
||
|
||
Строки вида `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|убрали записи YouTube и WhatsApp]], и у абонентов, которые резолвят через провайдера, эти сайты просто перестали существовать. Августовский перехват — следующий шаг той же логики: теперь на систему заворачивают и тех, кто от провайдерского 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:
|
||
|
||
![[tspu-dns-nsdi-nslookup-mskix-youtube-ok.png]]
|
||
|
||
А запросы к `195.208.4.1`, `8.8.8.8` и `1.1.1.1` с того же компьютера — «Non-existent domain»:
|
||
|
||
![[tspu-dns-nsdi-nslookup-nsdi-google-cloudflare-nxdomain.png]]
|
||
|
||
Различие тут не «фильтрует / не фильтрует», а в списках. Проверка 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`, как у остальных.
|
||
|
||
![[tspu-dns-nsdi-domru-intercepts-nsdi-mskix.png]]
|
||
|
||
Осторожная оговорка: `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 к настроенным резолверам:
|
||
|
||
![[tspu-doh-keenetic-log-21august2026.png]]
|
||
|
||
У тех абонентов, чьи замеры опубликованы, блокировка привязана к имени, а не к адресу. Нагляднее всего это в прогоне детектора, где строка `Cloudflare` (обращение по имени) даёт таймаут DoH, а строка `Cloudflare (IP)` — те же 58 мс, что и обычный UDP:
|
||
|
||
![[tspu-doh-detector-partial-august-2026.png]]
|
||
|
||
Ручные проверки того же абонента, у которого открытый UDP уже подменялся, подтверждают: 21 августа 2026 DNS-over-TLS к Cloudflare по прямому адресу работал —
|
||
|
||
![[tspu-dns-nsdi-dig-dot-cloudflare-ok-21august2026.png]]
|
||
|
||
— и DNS-over-HTTPS к нему же тоже:
|
||
|
||
![[tspu-dns-nsdi-dig-doh-cloudflare-ok-21august2026.png]]
|
||
|
||
Оба ответа — `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|zapret]], дальше работают обычные приёмы дробления TLS-приветствия — подробности в заметке [[Zapret/doh-cherez-zapret|Поможет ли zapret при блокировке DoH]]. Сообщения «запреткой чинится» относятся именно к этому случаю. С подменой открытого 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\|zapret]] по хостлисту | ✅ при блокировке по SNI | Бесполезно, если резолвер режут по IP-адресу — см. [[Zapret/doh-cherez-zapret\|разбор случаев]] |
|
||
| Валидация DNSSEC | ⚠️ как индикатор | Работает только на подписанных зонах; `youtube.com` не подписан |
|
||
| Собственный рекурсивный резолвер без форвардинга | ⚠️ временно | Разбор ниже: работает, пока правило не расширили на корневые и TLD-серверы |
|
||
| DNS внутри туннеля ([[VLESS/VLESS\|VLESS]], [[amnezia-3-0/amnezia-3-0\|AmneziaWG]]) | ✅ устойчиво | Запросы уходят зашифрованными вместе с остальным трафиком; ТСПУ не видит ни резолвера, ни имени |
|
||
|
||
Где это включается на практике:
|
||
|
||
- **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|zapret]]. Иначе рабочая стратегия будет выглядеть нерабочей — соединение просто не начнётся, потому что адрес сайта получить не удалось.
|
||
|
||
### Самый дешёвый способ: прописать адреса в 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](https://bugzilla.mozilla.org/show_bug.cgi?id=1624112) и [#1511643](https://bugzilla.mozilla.org/show_bug.cgi?id=1511643)); обходится переключением режима или списком исключений `network.trr.excluded-domains`. О таком же поведении Chrome сообщают пользователи. Если запись в файле не действует — первым делом проверьте эту настройку браузера. Системный DoH (например, в Windows 11 или в `systemd-resolved`) файлу не мешает: запись проверяется раньше, чем формируется запрос.
|
||
- **Масок не существует.** Написать `*.googlevideo.com` нельзя, каждое имя вписывается отдельной строкой. Для страницы сайта это терпимо, для сервисов с сотнями поддоменов — нет.
|
||
- **Адреса протухают.** Крупные сервисы отдают разные адреса разным регионам и меняют их постоянно, так что запись рано или поздно станет медленной или мёртвой.
|
||
- **Лечится только шаг с адресом.** Если тот же сайт вдобавок режут по имени в TLS-приветствии, `hosts` не поможет — соединение оборвут уже после того, как адрес получен; там нужен [[Zapret2/Zapret2|zapret]] или туннель.
|
||
- **HTTPS при этом не ломается**: сертификат проверяется по имени сайта, а имя вы не меняете.
|
||
|
||
Про сам файл, его правку и встроенный редактор в Zapret GUI — в заметке [[Zapret/hosts|про hosts и GEO-ограничения]].
|
||
|
||
### Поможет ли 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|архитектуре sing-box]] и в разделе про DNS у [[Clash/06-features-protocols|Clash]].
|
||
|
||
## Чем это грозит лично вам
|
||
|
||
Менять резолвер законно и технически безобидно, но два последствия стоит держать в голове.
|
||
|
||
Первое — бытовое. С чужим DNS могут отвалиться внутренние ресурсы провайдера, IPTV, корпоративная сеть и страницы авторизации в гостиничном и кафейном Wi-Fi: они резолвятся только «домашним» сервером сети. Включённая валидация DNSSEC на роутере в отдельных случаях оставляла абонентов вообще без работающего DNS, так что знать, как её выключить обратно, стоит заранее.
|
||
|
||
Второе — приватность, и оно важнее. Если перехват настроен на вашем узле, **на государственный резолвер уходят все ваши DNS-запросы**, а не только к заблокированным сайтам, — даже когда в настройках прописан Google или Cloudflare. Список запрашиваемых имён — это, по сути, список посещённых сайтов; для нейтральных доменов ответ приходит честный, поэтому заметить сбор данных по поведению системы невозможно. Единственный способ этого избежать — увести резолвинг в шифрованный канал или в туннель, где содержимое запроса недоступно по дороге. Общие приёмы — в [[Privacy|разделе про приватность]].
|
||
|
||
## Почему тестеры иногда врут
|
||
|
||
Отдельная ловушка августа 2026 — автоматические проверялки, выдающие уверенный вердикт на пустом месте. Речь именно о сводных вердиктах: сырая колонка «Реальный резолвер», на которой построен признак третий, остаётся полезной.
|
||
|
||
Первый пример: сводка «DoH недоступен у всех двенадцати серверов».
|
||
|
||
![[tspu-doh-detector-all-timeout-august-2026.png]]
|
||
|
||
Владелец замера отмечает, что тот же результат получается даже при работе через Cloudflare WARP, хотя настроенный на роутере DoH в этот момент исправно резолвит имена. То есть «0/12» здесь указывает скорее на проблему в самой проверке, чем на состояние сети.
|
||
|
||
Второй пример: вердикт «подмены нет, 6/6» на соединении, где часть резолверов вообще не ответила.
|
||
|
||
![[tspu-dns-nsdi-detector-udp-no-answer-6of6.png]]
|
||
|
||
Разгадка в том, что проверка сравнивает адреса, полученные двумя путями — через DoH и через открытый UDP, — и делает вывод только по тем доменам, по которым получила оба ответа. Домены из её списка (`rutor.info`, `flibusta.is`, `rezka.ag` и другие) на этом соединении резолвились одинаково, отсюда и «6/6 не подменяется». Резолверы, которые «не ответили», в счёт не попали, а `youtube.com` в списке отсутствует вовсе. На другом прогоне того же теста `8.8.8.8` отвечает, сравнение идёт уже с ним — и вердикт снова «6/6», хотя проверены те же шесть доменов, ни один из которых у этого абонента не подменялся:
|
||
|
||
![[tspu-dns-nsdi-detector-no-substitution-6of6.png]]
|
||
|
||
То есть вердикт описывает не состояние соединения, а результат по конкретному короткому списку доменов.
|
||
|
||
**Проверяйте вручную и на том домене, который у вас не открывается.** Сводный вердикт полезен как быстрый обзор, но принимать по нему решение нельзя — ни в одну, ни в другую сторону.
|
||
|
||
## Контекст: часть более широкой перестройки фильтрации
|
||
|
||
В июле 2026 у `8.8.8.8` [[DPI/google-dns-8888-block-july-2026|отрезали TCP-транспорт]], из-за чего «сломались» VPN-клиенты с этим адресом в конфиге: тогда давили шифрованный DNS, теперь взялись за открытый. Параллельно обновлённая версия ТСПУ, раскатанная с начала июня 2026, по наблюдениям сообщества принимает часть обычных TLS-соединений за VPN и растягивает установку соединения — отсюда долгая загрузка игр и вялые сайты, разобранные в [[DPI/tspu-false-blocks-june-2026|заметке о ложных блокировках]]. Общее направление описано в [[DPI/rkn-vpn-2030-roadmap|официальных планах до 2030 года]].
|
||
|
||
Меняются и мелкие детали, о которых легко забыть при диагностике. Флаг 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|zapret]]. Нормальный результат выглядит иначе: рукопожатие проходит и сервер отвечает `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, часть задана именем, часть адресом с нестандартным портом:
|
||
|
||
![[tspu-dns-keenetic-multiple-servers.webp]]
|
||
|
||
Обратите внимание на разницу в записях: `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|НСДИ как рубильник: удаление доменов из базы (февраль–март 2026)]] — предыстория: записи YouTube и WhatsApp убрали из самой системы, на которую теперь заворачивают чужой DNS-трафик
|
||
- [[DPI/google-dns-8888-block-july-2026|Инцидент 3 июля 2026: блокировка 8.8.8.8 по TCP]] — предыдущая волна по тому же адресу, но с другого конца
|
||
- [[Zapret/doh-cherez-zapret|Поможет ли zapret при блокировке DoH]] — что чинится хостлистом, а что нет
|
||
- [[DPI/tspu-false-blocks-june-2026|Как ТСПУ ломает легитимные сайты]] — сопутствующий ущерб обновлённых правил
|
||
- [[DPI/chrome-cnsa-flag-bypass|Флаг Chrome cryptography-compliance-cnsa]] — приём обхода, который в конце августа 2026 начал мешать
|
||
- [[nuc/mincifry-nuc-certs-danger-june-2026|Сертификаты НУЦ Минцифры]] — единственная теоретическая лазейка к содержимому DoH
|
||
- [[DPI/rkn-vpn-2030-roadmap|Курс на 2030]] — куда движется фильтрация по официальным планам
|
||
- [[DPI/DPI|Раздел про DPI и ТСПУ]] — обзор всех заметок по теме
|
||
- 🔗 [Публикация angry_agent на Хабре, 27 августа 2026](https://habr.com/ru/articles/1075272/) — первоисточник разбора с ICMP и схемой
|
||
- 🔗 [Новость Хабра о блокировке DoH, 26 августа 2026](https://habr.com/ru/news/1074730/) — предыдущий шаг той же волны
|
||
- 🔗 [Обсуждение блокировки DoH на ntc.party](https://ntc.party/t/%D0%B1%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D0%BE%D0%B2%D0%BA%D0%B0-doh-google-cloudflare-quad9-opendns/23007) — замеры абонентов из разных регионов
|
||
- 🔗 [Новость на Anti-Malware, 27 августа 2026](https://www.anti-malware.ru/news/2026-08-27-111332/51214) — краткий пересказ для нетехнического читателя
|
||
|
||
---
|
||
|
||
> [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ
|
||
> При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/DPI/tspu-dns-nsdi-dnat-august-2026.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip).
|