С вечера 26 августа 2026 года в части российских сетей открытый DNS к Google Public DNS (8.8.8.8) и Cloudflare (1.1.1.1) перестал доходить до самих Google и Cloudflare. Пакет уходит как будто на привычный адрес, а отвечает уже не он. 27 августа это подробно разобрал пользователь Хабра angry_agent: ТСПУ распознаёт DNS внутри UDP-пакета и делает направленный DNAT на резолвер Национальной системы доменных имён.
На прошлой неделе тот же контур уже резал зашифрованный DNS over HTTPS и DNS over TLS. Теперь очередь дошла до самого обычного UDP/53, которым пользуются Windows, смартфон и «пропиши 8.8.8.8 в настройках сети». Для владельца сайта это выглядит как странный NXDOMAIN у части клиентов. Для администратора офисной сети: адрес, который годами считали «независимым», внезапно врёт так же, как DNS оператора.
Что увидели 26 и 27 августа
В статье на Хабре от 27 августа 2026 года (11:36 мск) автор показывает типичный ответ:
dig youtube.com @8.8.8.8
В опубликованном дампе статус NXDOMAIN, флаги qr aa rd ra, пустые секции ANSWER и AUTHORITY, сервер при этом указан как 8.8.8.8#53 по UDP, время ответа около 9 мс. Та же картина для запроса к 1.1.1.1. Клиент думает, что ответил Google или Cloudflare. По смыслу это «такого домена нет».
Настоящий резолвер Google так на youtube.com не отвечает. И флаг aa (authoritative answer) на NXDOMAIN от публичного рекурсивного сервера здесь лишний: это скорее подпись фильтрующего контура, а не ответ из зоны .com.
Перехват в том же эксперименте работал только для UDP. Запрос по TCP к тому же 8.8.8.8 вернул NOERROR и обычные A-записи. DoH у этих же компаний на прошлой неделе уже ломали отдельно: TCP-сессия успевала установиться, а обмен обрывался на старте TLS. То есть режут не «интернет целиком», а конкретный способ спросить имя.
В опросе под статьёй на Хабре 79,7% из 591 проголосовавшего ответили, что наблюдают перехват (471 «да», 120 «нет», ещё 395 воздержались). Это самоотбор читателей Хабра, не всероссийская статистика. Картина по операторам неровная: у части абонентов UDP уже подменяют, у части нет.
Куда на самом деле уходит запрос
Ключевой опыт автора: DNS-пакет с маленьким TTL (2) до 8.8.8.8. Когда TTL кончается, маршрутизатор возвращает ICMP Time Exceeded и кладёт внутрь кусок исходного пакета. В этом куске адрес назначения уже не 8.8.8.8, а 195.208.5.1.
195.208.5.1 это публичный резолвер НСДИ, в PTR он же b.res-nsdi.ru. Парный адрес 195.208.4.1 (a.res-nsdi.ru). Оба годами фигурируют в инструкции по подключению операторов к НСДИ: Роскомнадзор прямо предлагал ставить их клиентам как основной или дополнительный DNS.
Подмена dst срабатывала только если внутри пакета был DNS. Случайный UDP на порт 53 адрес не менял. Вывод автора: ТСПУ смотрит не «любой трафик на 8.8.8.8», а «это DNS, и dst из короткого списка». Оператор после ТСПУ в netflow видит уже не Google, а НСДИ. Со стороны компьютера ответ по-прежнему приходит «от 8.8.8.8»: обратный DNAT прячет подмену.
Цепочка такая:
- Клиент шлёт UDP/53 на 8.8.8.8 или 1.1.1.1.
- ТСПУ узнаёт DNS и подменяет адрес назначения на резолвер НСДИ (в дампе 195.208.5.1).
- НСДИ смотрит имя. Если ресурс в логике ограничений, отвечает NXDOMAIN.
- Ответ возвращают клиенту так, будто его прислал Google или Cloudflare.
28 августа автор статьи предположил мотив: снять нагрузку с самих ТСПУ. Нет резолва заблокированного имени, нет последующего TLS, DPI не разбирает ClientHello. Это гипотеза, не официальная позиция РКН. На момент подготовки материала отдельного пресс-релиза ведомства по этому перехвату не было.
Почему это важно, даже если ваш сайт не в реестре
Для площадки, которой нет в реестре запрещённой информации, резолв через перехваченный 8.8.8.8 обычно остаётся живым: НСДИ отдаёт нормальный адрес. Ломается другое.
Пользователь годами ставил 8.8.8.8, когда «глючил DNS провайдера». Совет жил в любой инструкции по Wi-Fi. Теперь этот адрес для UDP перестал быть независимым каналом. В офисе, где всем прописали Google DNS «чтобы не зависеть от Ростелекома», зависимость просто сменила вывеску.
Типичные симптомы на стороне сайта:
- часть мобильных клиентов пишет «не удаётся найти сервер» / NXDOMAIN, с домашнего Wi-Fi всё открывается;
- мониторинг с зарубежной точки зелёный, жалобы только из РФ;
- браузер с DoH ведёт себя иначе, чем система с UDP/53;
- корпоративный VPN или «белый» DNS вдруг режет имена, которые раньше резолвились через 8.8.8.8.
Если домен действительно в реестре, пользователь с перехваченным UDP больше не получит даже IP. Раньше DPI мог резать уже TCP/TLS. Теперь отказ случается на этапе имени, и это выглядит как «сайта нет», а не как таймаут.
Как отличить перехват от настоящего сбоя DNS
Проверку лучше делать с той же сети, на которую жалуются, не с VPS за границей. Сначала обычный UDP, затем тот же вопрос по TCP. Поведение в тесте автора на Хабре как раз такое: UDP врёт, TCP доходит до настоящего резолвера.
dig youtube.com @8.8.8.8 dig youtube.com @1.1.1.1 dig +tcp youtube.com @8.8.8.8
На что смотреть в UDP-ответе:
- статус NXDOMAIN при имени, которое точно существует;
- флаг
aaпри пустой AUTHORITY; - время ответа в единицы миллисекунд, слишком быстро для круга до Google;
- в строке SERVER всё ещё 8.8.8.8 или 1.1.1.1, хотя ответ по смыслу не их.
Если UDP даёт NXDOMAIN, а dig +tcp к тому же адресу даёт NOERROR, это не «Google упал». Это расхождение путей: один перехватили, другой пока нет. В Windows ту же пару можно снять так:
nslookup youtube.com 8.8.8.8
Признак в nslookup: Non-existent domain. Сравнить имеет смысл с резолвом через DNS вашего оператора и через любой резолвер, который не из списка 8.8.8.8 / 8.8.4.4 / 1.1.1.1 / 1.0.0.1. Расхождение «на Google имени нет, у провайдера есть» (или наоборот) как раз и есть повод не чинить сайт, а смотреть клиентский DNS.
На Linux полезно понять, кто вообще спрашивает имена у машины:
resolvectl status cat /etc/resolv.conf
Часто в resolv.conf торчит 127.0.0.53 (systemd-resolved), а настоящие апстримы видны только в resolvectl. Если там 8.8.8.8, вы в той же лодке, что и «домашний роутер с Google DNS».
Быстрый взгляд на записи без консоли: Easy DNS Lookup и whois на сайте. Они показывают, что отвечает публичный резолвер с другой точки, не ваш ТСПУ. Расхождение «у меня NXDOMAIN, на проверке A-записи на месте» почти всегда про клиентскую сеть, не про зону домена.
Что было на прошлой неделе с DoH
25 августа 2026 года COMSS и SecurityLab описали сбои зашифрованного DNS Google и Cloudflare. Картина отличалась от нынешней: TCP к 1.1.1.1:853 (DoT) доходил до рукопожатия и получал ECONNRESET, DoH на 443 к dns.google и 8.8.8.8 поднимал TCP, но замирал после ClientHello. Жалобы шли от абонентов «Ростелекома», «Дом.ру», «Таттелекома» и петербургского SkyNet.
Смысл той волны: браузер с «защищённым DNS» не мог уйти в обход резолвера оператора и падал обратно на открытый UDP. Нынешняя волна закрывает как раз этот запасной люк. Сначала режут шифрованный канал к 8.8.8.8/1.1.1.1, затем подменяют открытый. Не «выключили DNS», а сняли два популярных способа не ходить в резолвер провайдера.
Если в браузере включён защищённый DNS (в том числе в Яндекс Браузере), сбой может выглядеть иначе, чем у системы: UDP перехвачен, DoH оборван, остаётся только то, что оператор сам отдаёт клиенту по DHCP.
Где обычно ломается диагностика
Первое: проверка с VPS в Европе. Там 8.8.8.8 отвечает как Google. Вы «доказали», что DNS жив, а у клиента в Поволжье уже NXDOMAIN.
Второе: кэш. Браузер, systemd-resolved, роутер. Один раз поймали подмену, десять минут живёте с чужим ответом. Перед повторным dig сбрасывайте кэш резолвера, иначе сравниваете не сеть, а память.
Третье: IPv6. В статье на Хабре речь про IPv4. Если устройство ходит в 2001:4860:4860::8888, картина может быть другой. Имеет смысл явно спросить и A, и AAAA.
Четвёртое: не все публичные DNS попали под DNAT. Автор отдельно пишет: срабатывает на определённых dst, не на любом резолвере. Отсюда ложный вывод «раз Quad9 отвечает, значит ничего не блокируют».
Пятое: гонка. В дампе Хабра пачка одинаковых UDP-запросов подряд сначала получала NXDOMAIN, через миллисекунды настоящие A-записи. ТСПУ не железный автомат на каждый пакет. Один замер «сейчас открылось» ничего не доказывает.
Шестое: лечить сайт, когда болен клиент. NXDOMAIN на 8.8.8.8 при живой зоне у регистратора это не повод перевыпускать DNSSEC и не повод менять NS. Сначала спросите, какой резолвер у того, кто жалуется.
Что делать администратору
Для рабочего сайта разумнее сначала зафиксировать, с какого DNS смотрит пользователь, чем крутить зону. Если офис сидит на 8.8.8.8 «потому что так стабильнее», имеет смысл вернуть резолвер оператора или свой внутренний unbound/bind и понять, что 8.8.8.8 больше не является независимой точкой зрения на рунет.
НСДИ при этом не серый «левый» сервер. Система закреплена в законе об информации, операторы с номером автономной системы с 2021 года обязаны её использовать. Перехват UDP к Google это не появление НСДИ, а способ направить на неё тех, кто сознательно ушёл на 8.8.8.8.
Не стоит отключать DNSSEC, файрвол или «на всякий случай» открывать порт 53 наружу. Это не лечит подмену на ТСПУ и добавляет отдельные дыры. Если меняете DNS на роутере, сохраните старые адреса, проверьте резолв внутренних имён (AD, почта, VPN-портал) и только потом распространяйте настройку на всех.
Повторять опыт с TTL=2 и разбором ICMP имеет смысл только если вы понимаете, что делаете, и делаете это в своей сети. Для обычной диагностики хватает пары dig UDP/TCP.
Вывод
С 26 августа 2026 года открытый DNS к 8.8.8.8 и 1.1.1.1 в части российских сетей больше не гарантирует ответ Google или Cloudflare. ТСПУ узнаёт UDP-DNS, переписывает назначение на НСДИ и отдаёт NXDOMAIN так, будто ответил сам публичный резолвер. TCP в тесте автора ещё доходил, DoH резали неделей раньше. Это точечное снятие популярных обходов резолвера оператора, а не объявление «DNS выключили».
Если сайт «пропал» только у тех, кто прописал Google DNS, сначала смотрите клиентский резолв, не зону. 8.8.8.8 в настройках сети больше не является нейтральной проверкой «а жив ли интернет».
