DNS hijacking: как РКН, регуляторы других стран и сами прокси-сервисы управляют вашими DNS-запросами

Материал состоит из двух частей, и вторая важнее первой. В первой — разбираем, как государство перехватывает DNS-запросы: подробно про механику Роскомнадзора (ТСПУ, НСДИ, история с часовой блокировкой 1.1.1.1 и 8.8.8.8, кейс с YouTube в феврале 2026-го), а затем — сравнение с Китаем, Ираном, Турцией, Казахстаном, Пакистаном, Индией, Великобританией, США: разными юрисдикциями, где похожая по сути техника применяется по совершенно разным правовым основаниям — от прямой государственной цензуры до судебных исков правообладателей.

Во второй части — то, ради чего стоит дочитать до конца, а не остановиться на середине списка стран. Первая и самая логичная мысль почти любого, кто столкнулся с блокировкой на уровне государства или провайдера, — «включу прокси или VPN, и вопрос закрыт». На практике это не гарантия: сам прокси-сервис вполне может заниматься ровно тем же самым DNS hijacking, что и государственный DPI, — только вместо блокировки конкретных доменов он перехватывает вообще весь ваш DNS-трафик и уводит его на собственную инфраструктуру, независимо от того, какой резолвер вы явно указали в настройках. Мы разберём это на конкретном практическом тесте, покажем воспроизводимый метод диагностики и в конце подскажем, где можно быстро проверить у себя признаки такой DNS-утечки — на чекере Zloy Detect

Что вообще такое DNS hijacking

Термин «DNS hijacking» в узком смысле означает захват контроля над разрешением доменных имён без согласия владельца ресурса или пользователя: подмену ответа DNS-сервера, взлом регистратора, атаку на сам резолвер. Но в контексте государственного регулирования интернета это понятие давно расширилось и обычно охватывает три технически разных, но функционально похожих сценария:

• DNS spoofing / poisoning (подмена ответа) — на сетевом пути между пользователем и легитимным DNS-сервером стоит устройство (DPI-коробка, пограничный маршрутизатор оператора), которое либо перехватывает UDP-запрос и отвечает быстрее настоящего сервера, либо просто не даёт ответу дойти, подставляя свой.
• Resolver-level filtering (фильтрация на уровне резолвера) — оператор связи или оператор публичного DNS сам администрирует резолвер и по требованию регулятора не возвращает корректный IP для определённых доменов (NXDOMAIN, заглушка, «серый» IP).
• Реестровое/административное удаление записи — домен физически убирается из авторитетной базы (реестра, национальной системы доменных имён), и корректный ответ просто перестаёт существовать где бы то ни было внутри контролируемого контура.

Ниже — разбор того, как это устроено в России, и сравнение с практиками полутора десятков стран, от Китая до Великобритании.

Россия: от точечных блокировок к суверенной инфраструктуре

Что такое ТСПУ

ТСПУ — это, по сути, DPI-инфраструктура («чёрные ящики»), встроенная непосредственно в сети операторов. К 2025 году покрытие ТСПУ на широкополосном доступе в России приблизилось к 100% (для сравнения — три года назад было около 80%), а суммарная пропускная способность оборудования измеряется в терабитах в секунду: у «Ростелекома», по имеющимся данным, пиковая ёмкость достигала 16 Тбит/с при среднем уровне около 9 Тбит/с. DPI на этом оборудовании анализирует трафик по всей модели OSI: для нешифрованных протоколов (HTTP, обычный DNS) доступна полная полезная нагрузка пакета, для TLS — только метаданные (SNI, JA3/JA4-отпечатки, поведенческие паттерны).

От DNS-блокировки к DPI и обратно

Долгое время подмена DNS-ответов в России была лишь одним из нескольких параллельных механизмов — наряду с блокировкой по IP и пакетной фильтрацией — и воспринималась как самый слабый и легко обходимый инструмент: смена DNS-сервера на 8.8.8.8 или 1.1.1.1 обычно решала проблему. Регулятор отреагировал предсказуемо: 8 сентября 2021 года у нескольких крупных операторов через ТСПУ на час были заблокированы сами публичные резолверы 1.1.1.1 (Cloudflare) и 8.8.8.8 (Google) — эксперимент, который независимые наблюдатели зафиксировали и который, по имеющимся данным, обсуждался операторами как кандидат на постоянное внедрение.

Параллельно шла работа над блокировкой шифрованных DNS-протоколов. Ещё в 2019 году обсуждался законопроект о запрете протоколов шифрования, скрывающих имя сайта (TLS 1.3, ESNI, DoH, DoT), а в феврале 2020 года было подписано постановление правительства, наделяющее РКН соответствующими полномочиями.

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

НСДИ как новый рычаг: кейс февраля 2026

В феврале 2026 года Роскомнадзор впервые публично применил именно НСДИ (а не «традиционную» связку ТСПУ+DPI) как самостоятельный инструмент блокировки. 10 февраля домен youtube.com был полностью удалён из базы подконтрольных РКН DNS-серверов — то есть резолверы перестали возвращать для него какой-либо корректный адрес. К 11 февраля из НСДИ, по независимым подсчётам, было убрано не менее 13 доменов крупных ресурсов, включая Facebook, Instagram, WhatsApp и ряд СМИ. Технологически это отличается от точечной DPI-блокировки конкретного домена: удаление записи из национальной адресной книги — это репетиция куда более фундаментального сценария — частичной или полной изоляции рунета от глобальной корневой системы DNS в случае, если такая политическая команда будет отдана. Наблюдатели интерпретировали это как тест инфраструктуры «суверенного рунета», а не как окончательное решение технической проблемы: обходные пути (VPN, альтернативные резолверы) продолжали работать без изменений.

По итогам 2025 года РКН отчитался о росте объёма удалённых по требованию ведомства материалов на 59% год к году, а на 2026 год заявлен переход к фильтрации трафика с использованием машинного обучения — с бюджетом порядка 2,27 млрд рублей на эти цели. Это симптоматично: чисто DNS/DPI-сигнатурная модель блокировок исчерпывает эффективность против растущей доли шифрованного и обфусцированного трафика, и регулятор идёт в сторону поведенческого анализа — того же направления, в котором развиваются и коммерческие инструменты детекции прокси/VPN.

Думаете только только власти РФ занимаются DNS hijacking?

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

Китай: Great Firewall — эталон DNS poisoning

Китайский Golden Shield / Great Firewall (GFW), концептуально заложенный ещё в конце 1990-х, остаётся самой изученной и технически продвинутой системой censorship middleware в мире. Механизм DNS-отравления там устроен как классическая гонка пакетов: пограничные узлы GFW отслеживают DNS-запросы (в основном на незащищённом UDP) к доменам из чёрного списка и инжектируют поддельный ответ быстрее, чем успевает прийти легитимный — из-за отсутствия аутентификации в стандартном DNS выиграть эту гонку технически несложно. Поддельный ответ кэшируется вышестоящими резолверами и распространяется дальше, из-за чего эффект «отравления» иногда выходит далеко за пределы Китая, затрагивая публичные резолверы по всему миру, если их трафик хоть раз прошёл через китайский транзитный узел.

Масштаб системы хорошо задокументирован академическими измерениями: если в 2010 году исследователи фиксировали около 9 поддельных IP-адресов, используемых в отравленных ответах, то позже это число выросло до 1,5 тысяч и более, а по недавним данным GFW оперирует пулом из 3,6 тысяч уникальных поддельных IPv4/IPv6-адресов. Долгосрочные измерительные проекты (GFWatch и аналогичные) фиксировали до 311 тысяч цензурируемых доменов при ежедневном тестировании более 400 миллионов доменных имён. DNS-инъекция в GFW работает в связке с двумя другими инструментами — сбросом TCP-соединений (RST-инъекция) и блокировкой по IP через инжекцию маршрутов BGP на границе автономных систем («null routing»), которая физически роняет весь исходящий трафик к заблокированным адресам. В 2025 году исследователи NDSS обнаружили в DNS-инжектирующей подсистеме GFW уязвимость переполнения буфера (получившую имя Wallbleed), позволяющую утечку служебной памяти цензурирующего оборудования — редкий случай, когда сама инфраструктура цензуры оказалась уязвима для внешнего анализа.

Иран: постоянная DNS-блокировка как норма

Иранская модель проще технически, но показательна по устойчивости: блокировка Twitter в Иране реализована именно на уровне DNS — местный резолвер (например, у провайдера Shatel) на запрос к twitter.com годами стабильно отдаёт заведомо невалидный внутренний адрес, ведущий на страницу с уведомлением о цензуре. Особенность иранского кейса в том, что смена резолвера на публичный (тот же 8.8.8.8) при этом не всегда помогает — перехват DNS-запроса происходит на пути, а не только на резолвере провайдера, то есть уже ближе к классическому on-path hijacking, а не просто к «плохому» DNS-серверу.

Турция: показательная эскалация 2014 года

Турецкий кейс 2014 года — один из самых наглядных учебных примеров того, как DNS-блокировка проваливается технически и почему регуляторы от неё отказываются в пользу более грубых инструментов. После утечки записи с критикой в адрес премьер-министра власти обязали ISP заблокировать Twitter, и первая реализация была предельно простой: провайдеры перестали отдавать корректный ответ для домена на своих DNS-серверах. Обход занял часы — жители массово переключились на Google Public DNS, а по городу появились граффити с адресами 8.8.8.8 и 8.8.4.4. Внутри страны трафик из Twitter, по некоторым оценкам, даже вырос на 130+% на фоне огласки. Власти отреагировали блокировкой уже самих IP-адресов публичных DNS-резолверов, а затем перешли к блокировке по IP самого Twitter — это заставило часть пользователей переключиться на VPN и Tor. Позже в Турции было принято более широкое законодательство о цензуре и слежке, ориентированное уже на URL-фильтрацию, которую простой сменой DNS обойти нельзя.

Казахстан: административные блокировки без суда и попытка MITM

В Казахстане с 2014 года блокировка ресурсов может проводиться не только по решению суда, но и по требованию Генеральной прокуратуры или профильного министерства — без судебного контроля вообще. Итог был статистически заметен: если с 2014 по 2018 год по решению суда заблокировали порядка 8 240 материалов, то только за следующие три года по требованиям госорганов без суда было ограничено свыше 50 тысяч материалов. Отдельно стоит эпизод 2019 года, когда государственный провайдер обязал часть абонентов установить корневой сертификат, позволяющий выполнять перехват TLS-трафика (по сути MITM-атаку) при обращении к ряду сайтов, включая соцсети и почтовые сервисы — эксперимент, вызвавший международную критику именно за подрыв модели доверия шифрования, а не просто за блокировку доступа. В 2022 году, во время массовых протестов, Казахстан прибегал уже к полным отключениям интернета на уровне магистральных каналов — DNS-инструменты в такой ситуации становятся избыточными.

Пакистан: от точечных блокировок к амбициям «Великого файрвола»

Пакистанский регулятор PTA годами практикует блокировку по решению административных органов и судебным искам: YouTube был заблокирован полностью с 2012 по 2016 год, Wikipedia — на два дня в 2023-м из-за спорного контента, а по данным, озвученным в парламенте, на определённый момент было заблокировано порядка 900 тысяч URL. Отдельная линия — периодические попытки внедрить централизованную национальную систему фильтрации трафика по образцу китайской модели («Great Firewall of Pakistan»), которые встречали как техническую критику (риск деградации всей национальной сети), так и судебные иски от гражданских активистов, оспаривающих блокировки без предварительного уведомления владельцев сайтов.

Индия: непрозрачность и «лоскутная» DNS-цензура

Индийская модель отличается масштабом и одновременно крайней непрозрачностью. Независимые измерения (в частности, по методологии OONI) показывают, что индийские провайдеры массово используют DNS poisoning и IP-блэклистинг, но делают это несогласованно: один и тот же сайт может быть заблокирован у одного оператора и свободно доступен у другого. Отдельное исследование, протестировавшее DNS-серверы шести крупных провайдеров почти по всему видимому пространству доменных имён (порядка 294 миллионов доменов), обнаружило заблокированными не только политически чувствительные ресурсы, но и значительное число вредоносных доменов — которые формально можно было бы считать блокировкой «в общественных интересах», если бы процесс был публичным.

Великобритания: конвейер судебных приказов

С 2011 года (дело Twentieth Century Fox v. British Telecommunications) в Великобритании действует отлаженный механизм блокировок на основании статьи 97A Закона об авторском праве, промышленных образцах и патентах (CDPA). Иск подаётся правообладателем (обычно объединениями вроде Motion Picture Association) против крупнейших ISP — BT, Sky, TalkTalk, Virgin Media и других, обеспечивающих порядка 90% широкополосного доступа в стране; сам заблокированный сайт стороной процесса не является и не может защищаться в суде. За прошедшие годы таким образом заблокированы сотни доменов (с учётом зеркал и прокси — тысячи). Примечательно, что попытка сделать блокировки административными, а не судебными (разделы 17-18 Digital Economy Act 2010, предполагавшие полномочия Ofcom), была свёрнута правительством ещё в 2011 году — из-за оценки стоимости (свыше £8 млн в год), лёгкости обхода через VPN и риска непропорционального вреда добросовестным пользователям. То есть Британия сознательно выбрала более медленный, но подконтрольный суду процесс вместо административного.

США: DNS-блокировка, которая не состоялась

Показательно, что в самих США попытка законодательно закрепить обязательную DNS-блокировку (законопроекты SOPA и PIPA, 2011-2012) провалилась — причём один из решающих аргументов был чисто техническим: DNS-фильтрация несовместима с DNSSEC и системно ослабляет безопасность всей системы доменных имён, а не просто «неудобна для обхода». После массовых протестов и совместного заявления представителей администрации Белого дома спонсор SOPA публично отказался от DNS-блокирующих положений в январе 2012 года. Это не означает, что в США нет механизмов вмешательства в доменные имена вообще — ведомство ICE годами практикует изъятие доменов (domain seizure) через регистратора по требованию суда, что технически ближе к «отзыву записи», чем к DNS hijacking в узком смысле, и сопровождалось резонансными ошибками (в частности, случаем 2011 года, когда ICE по ошибке на несколько дней заблокировало десятки тысяч доменов на общем IP-адресе).

Второй фронт: когда DNS перехватывает сам прокси

Почему прокси не решает проблему DNS hijacking?

Из всего разобранного выше напрашивается очевидный вывод: если DNS блокируют на уровне государства или оператора, значит, нужно просто взять прокси или VPN — тогда DNS-запрос будет уходить не в резолвер провайдера, а туда, куда укажет пользователь, либо в резолвер, встроенный в сам сервис. Мысль логичная и в большинстве случаев рабочая. Но у неё есть слепое пятно: сам факт использования прокси ничего не говорит о том, что происходит с DNS-запросом внутри этого прокси. А там иногда происходит буквально тот же самый DNS hijacking — просто оператором перехвата выступает не РКН и не DPI-коробка оператора связи, а сам прокси-провайдер. Поэтому тестировать прокси на нативность DNS нужно каждый раз.

Когда Proxy сам занимается DNS hijacking: разбор реального кейса

Ниже — обезличенный разбор собственного технического теста одного прокси-сервиса, предоставляющего «резидентные» exit-ноды — то есть IP-адреса, которые должны выглядеть как реальные адреса домашних абонентов конкретного интернет-провайдера. В качестве эталонной сети для проверки использовалась RCN — реальный американский кабельный оператор, работающий в Пенсильвании и Иллинойсе.

Методика теста простая и полностью воспроизводимая:

1. Берётся уникальный (canary) поддомен в контролируемой авторитативной DNS-зоне — такой, который прежде никогда не резолвился и не мог быть закэширован ни на одном промежуточном резолвере.
2. С клиента, работающего через тестируемый прокси, на этот поддомен отправляется DNS-запрос, явно адресованный конкретному резолверу (публичному 8.8.8.8/1.1.1.1, официальному DNS-серверу конкретного провайдера или произвольному внутреннему адресу).
3. На авторитативном сервере поддомена в логах фиксируется, с какого реального IP и от какой автономной системы (ASN) фактически пришёл запрос — это и есть тот, кто на самом деле выполнил резолвинг, вне зависимости от того, что было указано клиентом.

Результат оказался устойчивым и повторяемым. При обращении через тестируемый прокси к официальным DNS-серверам RCN (ns1.dns.rcn.net и другим адресам из их официального пула) ответы фактически формировала инфраструктура Amazon и Cloudflare — а не сама сеть RCN. Дальше — контрольная выборка: из базы взяли 25 реальных IP-адресов, принадлежащих диапазонам RCN в Пенсильвании и Иллинойсе (Nazareth, Allentown, Streamwood, Чикаго), и для каждого прогнали тот же canary-тест через прокси. Результат: все 25 без единого исключения оказались зарезолвлены не через инфраструктуру, соответствующую заявленному адресу или региону, а всего через два фиксированных адреса на Amazon EC2 (18.215.55.101 и 44.217.58.170, оба — регион us-east-1).

Дальше тест довели до предела специально, чтобы исключить любые альтернативные объяснения: в качестве «DNS-сервера» на клиенте указывали заведомо нерабочие для внешнего резолвинга адреса — публичные 1.1.1.1 и 8.8.8.8, а также сугубо приватные RFC1918-адреса вроде 192.168.1.1, 10.0.0.1, 172.16.0.1, которые в принципе не могут быть валидным внешним DNS-сервером. Результат не изменился: canary-домен резолвился ровно через те же два адреса на AWS, что и раньше — то есть прокси-клиент не читает и не учитывает указанный резолвер вообще, а перехватывает любой исходящий DNS-запрос на лету и подменяет его собственным. Контрольная проверка со сменой прокси при абсолютно той же локальной сети (L2-уровень намеренно не менялся, чтобы исключить влияние оборудования или сети самого тестировщика) показала принципиально другое поведение: DNS резолвился уже через настоящую инфраструктуру RCN — то есть аномалия локализована именно в конкретном прокси-продукте, а не в тестовой среде.

Почему это тот же самый DNS hijacking, только приватный

Механически разницы между тем, что делает такая прокси-надстройка, и тем, что делает ТСПУ, GFW или, скажем, «агрессивный» transparent DNS proxy у британского провайдера Sky (см. раздел про Великобританию выше), — нет никакой. И там, и там устройство или сервис на пути запроса игнорирует то, что реально указал пользователь, и подменяет либо сам ответ, либо источник ответа на собственный. Разница только в том, кто это делает и зачем: государственный регулятор — ради блокировки конкретных доменов, прокси-провайдер — ради централизованного контроля (логирования, кэширования, а в худшем случае — выборочной подмены ответов для отдельных доменов) над всем DNS-трафиком своих клиентов.

Как проверить это у себя

Метод, описанный выше (уникальный поддомен + явно указанный резолвер + сверка того, кто реально ответил на авторитативном сервере), — базовый, и при желании его можно повторить вручную через dig и любой контролируемый DNS-домен. Тот же принцип — только уже в готовом виде, без необходимости поднимать свою зону, — лежит в основе автоматических чекеров DNS-утечек: клиенту выдаётся уникальный тестовый поддомен, а сервис показывает, с какого реального адреса и от какой сети пришёл запрос, сравнивая это с тем, что клиент ожидал увидеть. Если хочется быстро проверить, не подменяется ли DNS прямо сейчас — вручную или через используемый прокси/VPN, — для этого есть чекер dnsdetect.zl0y.team: он анализирует DNS-ответы и оценивает вероятность того, что резолвинг идёт не туда, куда должен, включая признаки использования прокси или VPN с нештатным поведением DNS.

Почему все выбирают именно с DNS hijacking как базу и как защититься

Общий паттерн виден невооружённым глазом. DNS оказывается первым инструментом блокировки почти везде по одной и той же причине: это самый дешёвый и быстрый в развёртывании рычаг. Не нужно анализировать полезную нагрузку пакетов, не нужно вычислять IP-адреса CDN, которые могут меняться десятки раз в день — достаточно один раз занести домен в список и заставить резолвер (свой или чужой, как в кейсе Quad9) отдавать неверный ответ.

Но по той же причине DNS-блокировка — самый нестабильный инструмент: она ломается о смену резолвера, о DoH/DoT, о локальный hosts-файл, о VPN. Именно поэтому во всех разобранных юрисдикциях, где ставки для регулятора высоки (Китай, Россия, Турция, отчасти Иран), DNS-уровень со временем становится не финальным барьером, а первым и самым дешёвым фильтром, снимающим часть нагрузки с более тяжёлых и дорогих механизмов — DPI, инспекции SNI/TLS-отпечатков, RST-инъекции, блокировки по IP и null routing на уровне BGP. Рост доли шифрованного DNS-трафика (DoH, DoT, а в перспективе DoQ поверх QUIC) и технологий сокрытия SNI (ECH) меняет саму экономику блокировок: регуляторам приходится переходить от простого сопоставления по спискам доменов к фингерпринтингу зашифрованных сессий и поведенческому анализу трафика — то есть к куда более ресурсоёмким и менее точным методам, что подтверждается и заявленным на 2026 год переходом РКН к ML-фильтрации.

Для конечного пользователя из этого следует практический вывод: в будущем государства и прокси провайдеры врят-ли откажутся от DNS hijacking, а блокировки будут только усиливаться. Первые по причине его простоты в качестве базы для контроля за пользователями своей страны (страны всё больше смотрят на успешный опыт Китайского Great Firewall и перенимают его), а вторые с точки зрения экономичекой эффективнсти. При этом всегда будут существовать технические средства, такие как ZloyRouter которые будут помогать преодалевать эти ограничения и подставлять нативные ДНС автоматически проверяя их каждый раз на наличие DNS hijacking. Это извечная битва щита и меча, воды и огня - так было, так есть и так будет всегда.