У старого совета «пропиши 8.8.8.8 или 1.1.1.1 и забудь про DNS провайдера» появилась новая проблема. По замерам, опубликованным на Хабре, часть российских сетей начала перехватывать открытые DNS-запросы к Google Public DNS и Cloudflare. Компьютер отправляет пакет на 8.8.8.8, но запрос, судя по дампам, может оказаться на резолвере Национальной системы доменных имен. Пользователь при этом продолжает видеть в диагностике адрес Google.
История хорошо дополняет то, о чем мы писали несколькими днями раньше. Тогда появились проблемы с защищенными DNS Google и Cloudflare через DoH. Теперь наблюдения затронули классический DNS по UDP на 53-м порту. Я бы пока не говорил о тотальном перехвате DNS по всей России. Опубликованные измерения показывают разные результаты у разных операторов и в разных регионах. Но сам механизм выглядит достаточно убедительно, чтобы перестать считать запись 8.8.8.8 в настройках доказательством того, что запрос действительно дошел до Google.
Что именно происходит с DNS-пакетом
Классический DNS устроен почти неприлично просто. Устройство формирует запрос вроде «какой IP принадлежит youtube.com» и обычно отправляет его UDP-пакетом на порт 53. Такой транспорт предусмотрен еще базовой спецификацией DNS. Шифрования и криптографической аутентификации сервера в обычном UDP-DNS нет.
Поэтому устройство в середине маршрута способно прочитать имя домена и изменить судьбу пакета. Именно такую картину увидел автор эксперимента. Запрос к youtube.com, отправленный на 8.8.8.8, вернул NXDOMAIN. Код означает, что доменного имени якобы не существует.
dig youtube.com @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
;; flags: qr aa rd ra
;; SERVER: 8.8.8.8#53
Сам по себе NXDOMAIN ничего не доказывает. Ошибки DNS случаются. Намного интереснее комбинация признаков.
- Тот же домен существует и нормально разрешается из других сетей. Значит, глобальная зона DNS никуда не исчезла.
- Запрос по TCP на тот же
8.8.8.8:53в опубликованном тесте вернул настоящие адреса. Проблема оказалась привязана не просто к IP Google, а к типу трафика. - В ответе присутствовал флаг
aa. Флаг означает authoritative answer. Для ответа публичного рекурсивного резолвера Google на чужую зону такая картина выглядит аномально. - При эксперименте с малым TTL внутри ICMP-ошибки появился адрес
195.208.5.1. Исходный пакет при этом отправлялся на8.8.8.8.
Последний пункт самый интересный. TTL уменьшается на каждом маршрутизаторе. Когда значение достигает нуля, маршрутизатор возвращает ICMP Time Exceeded вместе с фрагментом пакета, который не смог переслать. В эксперименте внутри такого фрагмента получателем оказался уже не Google, а 195.208.5.1, связанный с инфраструктурой НСДИ.
Картина хорошо согласуется с направленным DNAT. Устройство распознает DNS внутри UDP, меняет адрес назначения и отправляет пакет другому резолверу. Ответ проходит обратное преобразование, поэтому клиент снова видит отправителя 8.8.8.8.
Получается примерно такая цепочка.
Компьютер
|
| DNS UDP/53
| dst 8.8.8.8
v
ТСПУ
|
| распознавание DNS
| dst меняется
v
195.208.5.1
|
| DNS-ответ
| NXDOMAIN для выбранного домена
v
ТСПУ
|
| обратная трансляция
v
Компьютер видит ответ от 8.8.8.8
НСДИ не является каким-то неизвестным сервером из серой зоны. Национальная система доменных имен закреплена в статье 14.2 закона об информации как инфраструктура для хранения и получения сведений о доменных именах и сетевых адресах. ТСПУ, в свою очередь, входят в систему централизованного управления российскими сетями связи.
Есть серьезная оговорка. Опубликованный ICMP-дамп с замененным адресом назначения пока остается единичным детальным измерением. Независимые наблюдения подтверждают странные DNS-ответы и фильтрацию, но я не стал бы превращать один дамп в универсальное описание каждой ТСПУ в стране. Корректнее говорить, что имеющиеся данные хорошо подтверждают версию с перенаправлением DNS на НСДИ в части сетей.
Как проверить свою сеть без гаданий
Для обычной проверки не нужны сложные пакеты с искусственным TTL. Достаточно сравнить несколько ответов. Материал предназначен для легальной сетевой диагностики и защиты собственной инфраструктуры. При работе с DNS, средствами фильтрации и сетевыми ограничениями соблюдайте законодательство своей страны, включая требования законодательства России. Не применяйте инструкции для несанкционированного доступа, нарушения правил сервисов или незаконного обхода ограничений.
В Linux, macOS с установленным dig или WSL я бы начал с обычного UDP-запроса.
dig youtube.com @8.8.8.8
dig youtube.com @1.1.1.1
Смотрите не только на строку SERVER. При прозрачной трансляции адрес сервера вполне может выглядеть правильным. Гораздо полезнее проверить status, флаги и секции ответа.
Следующий шаг состоит в сравнении UDP и TCP.
dig youtube.com @8.8.8.8
dig +tcp youtube.com @8.8.8.8
Если UDP возвращает NXDOMAIN, а TCP через тот же адрес немедленно получает A или AAAA-записи, перед нами очень сильный признак вмешательства по признакам протокола. Но не вечный рецепт. Опубликованные замеры описывают текущее поведение конкретных сетей. Правило фильтра можно изменить и распространить на TCP.
В Windows аналогичную проверку удобно провести через PowerShell.
Resolve-DnsName youtube.com -Server 8.8.8.8
Resolve-DnsName youtube.com -Server 8.8.8.8 -TcpOnly
Еще один признак находится в заголовке ответа. Если запрос к публичному рекурсивному серверу возвращает NXDOMAIN вместе с aa, я бы считал результат подозрительным. Но один флаг aa не позволяет определить конкретный сервер, который подменил ответ. Некоторые фильтрующие DNS-системы формируют похожие ответы.
Есть и тонкая деталь с AUTHORITY. Стандарт отрицательного кэширования RFC 2308 описывает SOA в отрицательных ответах. В наблюдаемых подмененных ответах встречалась комбинация NXDOMAIN, aa и пустой секции AUTHORITY. Такая сигнатура выглядит еще подозрительнее, чем один NXDOMAIN.
| Проверка | Нормальная картина | Что наблюдали при перехвате |
|---|---|---|
| UDP на 8.8.8.8 | Реальный DNS-ответ | NXDOMAIN для выбранных доменов |
| TCP на 8.8.8.8 | Тот же смысловой ответ | В части тестов возвращались настоящие IP |
| Флаг aa | Обычно отсутствует у рекурсивного ответа Google | Присутствовал в подмененном NXDOMAIN |
| SERVER в dig | Адрес настроенного резолвера | Может остаться 8.8.8.8 даже после трансляции |
| ICMP при малом TTL | Исходный адрес назначения | В опубликованном тесте появился 195.208.5.1 |
Обычный traceroute 8.8.8.8 проблему тоже может не показать. Судя по экспериментам, решение принимается после распознавания DNS-содержимого. Произвольный UDP-пакет и настоящий DNS-запрос на один адрес способны пройти через одно оборудование по-разному.
Зачем перехватывать DNS, если уже существует DPI
Самая очевидная причина состоит в контроле резолвинга. Раньше пользователь мог отказаться от DNS провайдера, вручную прописать Google или Cloudflare и получать ответы непосредственно от выбранного публичного резолвера. При прозрачном перехвате смена IP DNS перестает гарантировать смену реального резолвера.
Есть и технически интересная гипотеза, которую автор исходного исследования добавил позже. DNS-фильтрация может снижать нагрузку на ТСПУ. Если устройство получает NXDOMAIN, браузер вообще не устанавливает соединение с нужным сервером. ТСПУ не приходится разбирать последующий TLS ClientHello и применять более тяжелые правила DPI.
Логика правдоподобна, но подтверждений мотива со стороны Роскомнадзора нет. Поэтому я бы разделял установленный механизм и возможную причину. Перенаправление пакетов можно наблюдать. Зачем конкретно регулятору понадобилась такая конфигурация, по публичным данным неизвестно.
Еще недавно ситуация выглядела почти зеркально. Обычный DNS к 8.8.8.8 и 1.1.1.1 работал, а защищенные варианты начали испытывать проблемы. Cloudflare в своей документации прямо описывает разницу. Классический DNS передает запросы открыто, DoT шифрует их через TLS, а DoH упаковывает DNS в HTTPS.
Появление перехвата UDP хорошо показывает слабое место классического DNS. Пользователь выбирает IP резолвера, но сам протокол не удостоверяет для клиента личность сервера. Именно от подобного вмешательства защищают шифрованные транспорты. DoH, например, использует TLS и аутентификацию сервера.
Но превращать DoH в волшебную кнопку тоже не надо. Защищенный DNS может блокироваться отдельно, что уже наблюдалось. Кроме того, DoH скрывает DNS-запрос от промежуточного оператора, но сам выбранный резолвер продолжает видеть запрос. Модель доверия меняется, а не исчезает.
DNSSEC решает другую задачу. Расширение проверяет подлинность подписанных DNS-данных, но не шифрует запросы. RFC 4033 прямо исключает конфиденциальность из задач DNSSEC. Для подписанного домена валидирующий резолвер способен обнаружить подделку, однако значительная часть практической пользы зависит от наличия DNSSEC у конкретной зоны и от того, где именно выполняется проверка. Поэтому совет «просто включите DNSSEC и забудьте» слишком оптимистичен.
Что меняется для пользователей и администраторов
Главное изменение не в блокировке одного конкретного сайта. Меняется сама модель доверия к внешнему DNS. Раньше администратор мог проверить конфигурацию, увидеть 8.8.8.8 и с высокой уверенностью считать Google своим вышестоящим резолвером. Теперь в сетях с прозрачным перехватом такая проверка ничего не гарантирует.
Для корпоративной инфраструктуры последствия неприятнее бытовых. Разные DNS-ответы через UDP и TCP способны создавать трудноуловимые сбои. Один клиент получает NXDOMAIN, другой использует кэш, третий переключается на TCP после большого ответа, браузер держит собственный DNS-кэш, приложение использует встроенный защищенный резолвер. В результате один и тот же домен «существует» на одном компьютере и «не существует» на соседнем.
После диагностических тестов я всегда очищал бы кэш, иначе легко принять старый отрицательный ответ за новый результат.
ipconfig /flushdns
Для Linux с systemd-resolved подойдет команда.
resolvectl flush-caches
Менять DNS на случайный адрес из списка в интернете я бы не советовал. Открытый сторонний резолвер получает ваши DNS-запросы и становится новой доверенной стороной. Скорость в несколько миллисекунд здесь менее интересна, чем политика журналирования, поддержка защищенных протоколов и предсказуемость работы из вашей сети. Мы уже подробно разбирали настройку защищенного DNS и ограничения такого подхода.
Для опытного администратора собственный рекурсивный резолвер вроде Unbound уменьшает зависимость от одного публичного форвардера. Но рекурсивная схема не делает DNS невидимым. Сервер сам обращается к корневым, TLD и авторитетным DNS, причем значительная часть такого трафика по-прежнему использует открытый DNS. Если фильтрация когда-нибудь станет шире и начнет перехватывать произвольные DNS-запросы, собственная рекурсия тоже перестанет быть принципиальной защитой.
Поэтому нынешнюю ситуацию я воспринимаю не как очередной список «рабочих DNS», который завтра устареет. Намного интереснее архитектурное изменение. Сеть получила возможность определить DNS-запрос по содержимому, проигнорировать указанный пользователем резолвер и вернуть ответ так, чтобы обычная диагностика продолжала показывать знакомый 8.8.8.8.
Правда ли, что 8.8.8.8 теперь полностью заблокирован?
Нет. Опубликованные тесты показывают более сложную картину. В части сетей UDP-DNS к 8.8.8.8 перехватывался, тогда как DNS по TCP возвращал обычные ответы. Поведение зависит от оператора и может меняться.
Почему dig показывает SERVER 8.8.8.8, если запрос перехватили?
При stateful DNAT оборудование может изменить адрес назначения исходящего пакета, а для обратного ответа выполнить обратную трансляцию. Клиент в результате видит ожидаемый адрес Google, хотя запрос обрабатывал другой резолвер.
Что означает NXDOMAIN?
NXDOMAIN означает, что запрошенного доменного имени не существует. Если заведомо существующий домен получает NXDOMAIN только через отдельный DNS или только одним транспортом, результат требует дополнительной проверки.
Поможет ли DNS over HTTPS?
DoH защищает запрос между клиентом и резолвером от чтения и простой подмены по пути. Но доступ к отдельным DoH-сервисам тоже может ограничиваться, поэтому универсальной гарантии доступности протокол не дает.
Защитит ли DNSSEC от такого перехвата?
DNSSEC позволяет проверять подлинность подписанных DNS-данных, но не шифрует запрос. При корректной локальной валидации подмена ответа для подписанной зоны может быть обнаружена. Для неподписанной зоны такой гарантии нет.
Как понять, затронул ли перехват моего провайдера?
Сравните ответы одного резолвера по UDP и TCP, проверьте статус NXDOMAIN, флаги ответа и результат из другой независимой сети. Один тест не дает надежного вывода, особенно из-за DNS-кэша.
Мой вывод простой. Записанный в настройках IP DNS-сервера больше нельзя автоматически приравнивать к серверу, который действительно обработал запрос. Пока наблюдения говорят о выборочном перехвате открытого UDP-DNS к известным публичным резолверам, а не о полном контроле любого DNS-трафика. Но техническая граница уже сдвинулась. При странных NXDOMAIN теперь надо проверять не только сам DNS-сервер, но и путь до него, транспорт и то, кто фактически сформировал ответ.
