В части российских сетей зафиксировали новый механизм обработки DNS-запросов: обращения к публичным DNS-серверам Google 8.8.8.8 и Cloudflare 1.1.1.1, отправленные по UDP, могут не доходить до выбранного пользователем сервера. Опубликованные сетевые замеры показывают, что такой трафик перенаправляется на резолвер Национальной системы доменных имён — НСДИ.
Механизм подробно разобрали 27 августа. Автор исследования на Хабре обнаружил, что запрос youtube.com к 8.8.8.8 возвращает NXDOMAIN, то есть ответ «доменного имени не существует». Аналогичный результат получался при запросе rutracker.org через Cloudflare 1.1.1.1. При этом запрос к Google DNS через TCP в той же сети возвращал реальные IP-адреса YouTube.
Это важное отличие от простой недоступности 8.8.8.8: устройство продолжает отправлять запрос на знакомый IP-адрес и получает ответ, который внешне выглядит как ответ от этого же адреса. Но дополнительные проверки показывают, что часть DNS-трафика по дороге меняет получателя.
DNS, или система доменных имён, переводит адрес вроде example.com в IP-адрес сервера. Google официально предлагает 8.8.8.8 и 8.8.4.4 в качестве адресов своего общедоступного DNS-сервиса. Cloudflare использует для аналогичного сервиса 1.1.1.1 и 1.0.0.1.
Обычная схема: пользователь задаёт DNS-сервер, устройство отправляет ему запрос, а резолвер ищет нужную DNS-запись и возвращает ответ.
В опубликованном эксперименте маршрут оказался другим. Исследователь отправил DNS-запрос к 8.8.8.8 с небольшим значением TTL — времени жизни IP-пакета. TTL ограничивает количество сетевых узлов, которое пакет может пройти. Если значение заканчивается раньше пункта назначения, промежуточный маршрутизатор обычно возвращает служебное ICMP-сообщение.
Внутри такого сообщения исследователь обнаружил, что адрес назначения пакета уже изменился: вместо 8.8.8.8 там находился 195.208.5.1. Это адрес b.res-nsdi.ru, одного из публичных резолверов НСДИ.
Другой публичный сервер системы — a.res-nsdi.ru — использует адрес 195.208.4.1. Оба адреса перечислены в инструкции по подключению операторов связи к НСДИ.
Картина соответствует DNAT — трансляции адреса назначения. Сетевое оборудование меняет IP получателя пакета: устройство отправляет DNS-запрос на 8.8.8.8, но дальше он направляется к другому резолверу.
После обработки обратная трансляция может снова подставить исходный адрес. Поэтому программа dig, nslookup или само устройство пользователя продолжает считать, что ответ пришёл от Google либо Cloudflare.
Поведение самого резолвера НСДИ удалось проверить отдельно. Технический проект zapret.moe 28 августа отправил запросы непосредственно на 195.208.5.1. youtube.com и rutracker.org получили NXDOMAIN, при этом ya.ru, github.com и discord.com разрешались штатно. Проверка показала и важную деталь: непосредственно сервер НСДИ возвращал NXDOMAIN для YouTube и через UDP, и через TCP.
NXDOMAIN — стандартный DNS-код, означающий, что запрошенного доменного имени не существует.
В глобальной DNS домен YouTube при этом существует. Значит, такой ответ нельзя объяснить исчезновением домена или аварией Google.
Для пользователя результат выглядит просто: браузер запрашивает адрес сайта, получает сообщение «такого имени нет» и даже не переходит к установлению соединения с веб-сервером.
Здесь есть нюанс. В эксперименте с 8.8.8.8 перехватывались запросы DNS поверх UDP, а команда dig +tcp youtube.com @8.8.8.8 добралась до Google и получила четыре IP-адреса. Это не означает, что НСДИ сама разрешает домен при использовании TCP. Прямой запрос к резолверу НСДИ через TCP тоже возвращал NXDOMAIN. Разница возникает раньше: правило перенаправления в исследованной сети применялось к UDP-запросу, направленному на публичный DNS Google, но не срабатывало для DNS поверх TCP.
Обычный DNS действительно умеет работать по обоим транспортным протоколам. Стандарт RFC 7766 требует поддержки и UDP, и TCP полноценными реализациями DNS и прямо рассматривает TCP как нормальный транспорт, а не исключительно аварийный запасной вариант.
Эксперимент позволил проверить ещё один момент. Когда автор отправлял произвольный UDP-пакет с небольшим TTL, адрес назначения не менялся. Подмена возникала, когда внутри пакета находился корректный DNS-запрос. Это указывает на более точное правило обработки, чем обычное перенаправление всего UDP-трафика к определённому IP.
Дополнительный технический разбор собрал три признака такого механизма: необычные DNS-ответы, изменённый адрес назначения внутри ICMP-сообщения и сетевую принадлежность инфраструктуры, которая фактически выполняет запросы. Авторы пришли к той же версии — DNS-трафик к популярным зарубежным резолверам перенаправляется на НСДИ.
История с обычным DNS появилась после сообщений о проблемах с защищёнными DNS-протоколами.
26 августа пользователи нескольких российских сетей сообщили о сбоях DNS over HTTPS и DNS over TLS — DoH и DoT. Хабр собрал наблюдения абонентов разных операторов, но результаты заметно отличались: у части пользователей сервисы Google и Cloudflare не работали, у других продолжали работать штатно. Это не позволяет говорить о полном отключении DoH и DoT по всей России.
Разница между протоколами принципиальна. Обычные DNS-запросы через UDP или TCP передаются без шифрования. Google прямо предупреждает, что традиционный DNS можно наблюдать и изменять на сетевом маршруте, а DoH и DoT шифруют обмен между клиентом и DNS-резолвером.
Cloudflare описывает тот же принцип: обычный DNS передаётся открытым текстом, DoT помещает запрос в зашифрованное TLS-соединение, а DoH передаёт его внутри HTTPS.
Поэтому перехват обычного DNS технически проще: сетевое оборудование видит, что перед ним DNS-пакет, адрес резолвера и запрашиваемое доменное имя.
Незашифрованный DNS действительно раскрывает доменное имя тому, кто способен наблюдать трафик между устройством и резолвером.
Если компьютер делает запрос example.com, оператор сети потенциально может увидеть это имя или изменить ответ.
Но DNS не передаёт полный адрес открываемой страницы. Из DNS-запроса нельзя автоматически получить строку вроде https://example.com/private/account?id=123: система разрешения имён работает прежде всего с доменами.
Защищённый DNS уменьшает именно видимость DNS-запросов для промежуточных сетевых узлов. Он не превращает всё интернет-соединение в VPN и не скрывает автоматически остальные сетевые признаки.
Установка стороннего DNS давно используется вместо резолвера, который оператор выдаёт автоматически. Если ограничение реализовано именно через DNS провайдера, смена резолвера иногда меняет результат. Но этот способ никогда не обходил все виды сетевых ограничений: ресурс можно ограничивать по IP-адресам и другим характеристикам трафика.
Теперь появляется ещё одна проблема. При активном перенаправлении запись 8.8.8.8 в настройках устройства больше не доказывает, что открытый DNS-запрос действительно обработал Google. Аналогичная ситуация возможна с 1.1.1.1.
Пользователь может этого вообще не заметить. Если перенаправленный резолвер возвращает такой же адрес сайта, результат выглядит нормально. Разница проявляется для доменов, на которые НСДИ отвечает NXDOMAIN.
Сам Google при этом продолжает указывать 8.8.8.8 и 8.8.4.4 как действующие адреса Google Public DNS, а Cloudflare документирует 1.1.1.1 как свой общедоступный резолвер без фильтрации содержимого.
Под публикацией на Хабре автор запустил опрос: наблюдают ли читатели перехват открытых DNS-запросов к Google и Cloudflare. На момент актуального среза ответ «да» выбрали 474 человека, или 79,53% проголосовавших, «нет» — 122 человека, или 20,47%. Всего проголосовали 596 пользователей, ещё 396 воздержались.
Опубликованные данные подтверждают саму техническую возможность и её практическое применение в отдельных российских сетях: DNS-запрос, адресованный 8.8.8.8 или 1.1.1.1, может быть перенаправлен на резолвер НСДИ.
Данные из разных сетей при этом неоднородны. В обсуждениях пользователи сообщают как о воспроизводимом NXDOMAIN, так и о нормальной работе Google DNS. Ранее собранные проверки DoH тоже сильно различались между автономными системами и провайдерами.
Вопросы и ответы
Google DNS 8.8.8.8 заблокировали в России?
Так говорить некорректно. В опубликованных измерениях сам адрес оставался доступен, но часть обычных DNS-запросов по UDP перенаправлялась на другой резолвер. Через TCP в исследованной сети запрос к Google проходил нормально.
Cloudflare 1.1.1.1 тоже перехватывают?
Такие результаты опубликованы для 1.1.1.1. Cloudflare при этом продолжает использовать этот адрес как штатный публичный DNS-резолвер.
Почему компьютер показывает, что ответил 8.8.8.8?
При трансляции адреса назначения оборудование может изменить адрес на пути к серверу, а перед отправкой ответа пользователю выполнить обратную замену. Для конечного устройства ответ поэтому выглядит пришедшим от первоначального адреса.
Перехватываются все DNS-серверы?
Доказательств этого нет. Опубликованные эксперименты касаются прежде всего нескольких популярных адресов Google и Cloudflare. Даже автор исследования отдельно отмечает, что перенаправление происходит не для всех DNS-серверов.
Перехватывается только UDP?
В исследованной сети правило срабатывало для DNS по UDP, а запрос к 8.8.8.8 через TCP доходил до Google. Это наблюдение нельзя автоматически распространять на всех операторов или считать постоянным свойством системы.
TCP-DNS зашифрован?
Нет. Обычный DNS через TCP так же не обеспечивает шифрование содержимого запроса. Для шифрования используются DoH и DoT.
Провайдер теперь видит все сайты пользователя?
При обычном незашифрованном DNS сетевой оператор технически способен увидеть запрашиваемые доменные имена. Полный URL страницы DNS-запрос при этом не раскрывает.
Что означает NXDOMAIN?
Это стандартный DNS-ответ «такого доменного имени не существует». В данном случае он интересен тем, что глобально проверяемый домен продолжает существовать, а отрицательный ответ появляется на конкретном пути разрешения имени.
Есть новость? Станьте автором.
Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.
