Вы вводите в адресную строку браузера знакомый адрес сайта и через долю секунды попадаете на нужную страницу — простое действие, которое мы совершаем сотню раз в день. Но за этим кликом скрывается невидимый посредник — DNS, система, которая превращает удобные для человека названия в цифровые координаты серверов. А теперь представьте: заходите на «свой» банковский сайт, а это лишь идеальная копия, созданная мошенниками. Или ваш запрос к корпоративной почте теряется из-за подмены DNS-записей. Риск нарваться на подмену высок. Фишинговые сайты-двойники множатся, как грибы после дождя, а пользователи путаются в море похожих названий.

Но паниковать не стоит. Такие атаки работают только там, где DNS оставлен без присмотра. В этой статье разберем, как злоумышленники подделывают DNS-записи, как меняется характер DDoS-атак и какие технологии помогут вам остаться невредимыми. Подробности под катом.

Используйте навигацию, если не хотите читать текст целиком:

→ Основы работы DNS
→ Механизмы атак через поддельные DNS-записи
→ Реальные кейсы и анализ инцидентов
→ Меры защиты и лучшие практики
→ DNS: гонка без финиша

Основы работы DNS

Прежде чем углубляться в основы безопасности сети DNS, давайте разберемся, как устроена сама система доменных имен и что вообще происходит, когда мы вводим URL в браузере. Это поможет лучше понять, где и как можно атаковать и, соответственно, как защититься.

Допустим, у нас есть адрес: www.selectel.ru. На первый взгляд, просто веб-сайт, но в контексте DNS это структура из трех уровней, и читается она с конца вперед:

1. .ru — это домен верхнего уровня (Top-Level Domain, TLD). Та самая «завершающая» часть адреса, которая говорит, к какому глобальному пространству принадлежит домен. Есть общие TLD вроде .com, .org, .net, а есть национальные — .ru, .de, .ai. Их количество ограничено и контролируется централизованно.
2. selectel — это домен второго уровня (Second-Level Domain, 2LD). Это уникальное имя сайта, которое вы выбираете при регистрации в рамках определённого TLD. В данном случае selectel.ru — это основной адрес компании.
3. www — это самый распространенный домен третьего уровня (Third-Level Domain, 3LD), он же поддомен. Он направляет трафик на определенный сервис и чаще всего ассоциируется с главной страницей сайта. В адресах my.selectel.ru, support.selectel.ru и api.selectel.ru домены третьего уровня — это «my», «support» и «api». Кстати, www — лишь условность, поскольку сегодня многие сайты отказываются от него в пользу доступа напрямую через домен второго уровня.

Когда вы вводите my.selectel.ru в браузере, сначала срабатывает локальный кеш, потом — резолвер, который через рекурсивные запросы доходит до авторитетного DNS-сервера зоны selectel.ru. Только тогда получаете IP-адрес, по которому идет подключение к нужному сервису.

Кто до сих пор не понимает разницу между HTTPS и DNS. Кратко: DNS — это как справочная, которая говорит вашему браузеру, куда идти (переводит my.selectel.ru в IP-адрес), а HTTPS — это защищенный способ общения с этим адресом, чтобы никто по пути не подслушал и не подменил данные. DNS работает до установления соединения, а HTTPS — уже во время передачи информации, и одно не заменяет другое, но вместе они обеспечивают доступ и безопасность.

Теперь давайте разберемся, как работает сам DNS

Domain Name System — это распределенная иерархическая система, без которой интернет превратился бы в хаотичный набор IP-адресов. Ее ключевая задача — трансляция доменных имен (например, example.com) в IP-адреса (например, 93.184.216.34). Это обеспечивается через сложную цепочку взаимодействий между клиентами, рекурсивными резолверами, корневыми серверами, TLD-серверами и авторитетными серверами.

Процесс разрешения имен начинается с stub resolver — клиентской библиотеки, которая формирует DNS-запрос. Этот запрос перехватывается рекурсивным резолвером (например, 8.8.8.8 от Google или 1.1.1.1 от Cloudflare), который проверяет локальный кэш, учитывая TTL (Time to Live) записей. Если ответ не найден, резолвер запускает цепочку итеративных запросов. Сначала к корневым серверам (например, a.root-servers.net), которые определяют TLD-сервер (например, .com), затем к TLD-серверам (например, gtld-servers.net), возвращающим NS-записи авторитетных серверов домена, и наконец — к авторитетным серверам (например, ns1.example.com). Последние отдают запрашиваемую ресурсную запись (A, AAAA, MX и т. д.). Полученный ответ кэшируется на всех уровнях, что ускоряет последующие запросы.

Экскурс в типы DNS-записей

Чуть подробнее о типах DNS-записей можно почитать в статье «DNS-хостинг для начинающих: разбираемся в многообразии ресурсных записей». В ней разбираемся, какие типы ресурсных записей бывают и зачем их так много, а еще смотрим на примеры их добавления.

A-записи: связывают доменное имя с IPv4-адресом.
AAAA-записи: связывают доменное имя с IPv6-адресом.
CNAME-записи: псевдонимы для доменных имен, упрощают управление и перенаправление трафика.
MX-записи: указывают серверы для обработки электронной почты.
NS-записи: указывают авторитетные серверы для домена.
TXT-записи: используются для хранения текстовой информации (например, SPF-записи для защиты от спама).
SRV-записи: указывают серверы для определенных сервисов, например, для VoIP.
DNS абстрагирует сложные IP-адреса, позволяя работать с человеко-читаемыми доменами. Это дает гибкость: смена хостинга требует только обновления A/AAAA-записей, а не изменения домена. Масштабируемость достигается через round-robin DNS, распределяя нагрузку между серверами. Однако технология уязвима из-за своей нейтральности (RFC 1035).

Теперь, когда основы DNS понятны, давайте взглянем на его уязвимости. Злоумышленники могут использовать поддельные DNS-записи для атак, и для этого не нужно быть экспертом.

Механизмы атак через поддельные DNS-записи

Домены и IP — выдуманы, совпадения с реальностью — случайны.

Вариантов совершить хакерскую атаку с использованием DNS существует множество. От банального спуфинга до изощренного туннелирования через TXT-записи, при котором базовые функции протокола становятся не такими уж безопасными. Раньше такие атаки требовали глубоких знаний, а сегодня даже скрипт-кидди может за пару минут сгенерировать фишинговый домен через ChatGPT или подменить CNAME через облачный DNS-хостинг.


Как работает DNS-атака. Источник.

DNS-спуфинг

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

Возьмем классику жанра — отравление кэша DNS-резолвера. По своей сути, отравление вводит в заблуждение систему, отдавая ложные данные в кэши DNS Resolvers — важнейших посредников, ответственных за перевод доменных имен, подходящих для человека, в машинные IP-адреса.

Как это работает? Здесь в ход идут брутфорс 16-битных TXID и эксплуатация статических UDP-портов. Это позволяет подсунуть фейковый ответ раньше легитимного. Добавьте сюда TTL в 86 400 секунд — и ложная запись будет «жить» в кэше сутки, направляя трафик в чужие руки. Например, атакующий может подменить IP для example.com на 185.239.239.х, направив всех пользователей на фишинговый клон, пока резолвер не обнаружит подмену через сутки.

MITM-атака

Эта атака чуть поднимает ставки, внедряя физическое присутствие в саму цепочку данных. Ее еще называют «атака посредника» или атака типа «человек посередине». Скомпрометированные роутеры в публичных сетях или rogue DHCP-серверы в корпоративном сегменте меняют DNS-настройки клиентов на лету. Для понимания представим ситуацию: в офисе раздают DHCP с DNS 8.8.8.8, но это не привычный многим Google, а сервер злоумышленника, подменяющий MX-записи.

Компрометация авторитетных серверов

Но что, если атакующие идут дальше и берут под прицел самих «хранителей» DNS?

Речь о компрометации авторитетных серверов, тех самых, что хранят «исходники» DNS-зон. Пример бы выглядел так: Злоумышленник получает доступ к аккаунту Cloudflare через поддельную форму входа, маскирующуюся под легитимный сервис. Он крадет логин и пароль администратора, изменяет NS-записи домена shop.example, перенаправляя их на ns.shop.example.com. Это позволяет контролировать весь трафик сайта. Теперь под его контролем оказываются все DNS-записи домена.

DNS-туннелирование

Подход используется, если злоумышленнику нужно остаться незамеченным. Данные кодируются в Base64-субдоменах вида dC1yZXhfbXlfbG92ZQ.exfil.example или прячутся в TXT-записях, которые файрволы часто игнорируют. Вредонос на зараженном ПК может запрашивать cmd.evilexample.com, получая через TXT-команды вроде «download https://evilexample.com/ransomware.exe». Это тихий обход любой сетевой защиты.

Подмена CNAME через CDN

И напоследок вишенка на торте нашего небольшого сборника проблем, специально для эстетов. Злоумышленник регистрирует домен с привлекательным названием(trusted-cdn.example.com) и затем настраивает для него CNAME-запись, которая перенаправляет запросы на другой домен (legit-cdn.example.com), контролируемый хакером. Если DNS-резолверы не проверяют всю цепочку доверия, трафик перенаправляется на вредоносный сервер, что позволяет злоумышленнику, например, вставлять скрипты с майнерами или эксплойтами через CDN.

Реальные кейсы и анализ инцидентов

MaginotDNS. Как уязвимость в CDNS-резолверах поставила под угрозу весь интернет

В 2023 году исследователи из Калифорнийского университета и Университета Цинхуа вскрыли критическую уязвимость в условных DNS-резолверах (CDNS), названную «MaginotDNS». Атака позволяла злоумышленникам отравлять кэш DNS-серверов, перенаправляя трафик целых доменов верхнего уровня (TLD) на подконтрольные ресурсы. Уязвимость заключалась в несоответствиях проверок безопасности в популярном DNS-софте: BIND9, Knot Resolver, Microsoft DNS и Technitium. Например, в некоторых конфигурациях серверы ошибочно обрабатывали записи как корневые, что открывало лазейку для подмены ответов.

Злоумышленники использовали два сценария.

• On-path. Перехват трафика между резолвером и сервером для внедрения фальшивых DNS-ответов.
• Out-path. Предсказание исходного порта и TXID (идентификатора транзакции) через брутфорс или SADDNS, чтобы отправить поддельный ответ раньше легитимного.

Из 1,2 млн просканированных DNS-резолверов 154 000 оказались CDNS, а 54 900 — уязвимыми. 88% из них допускали атаки даже без прямого доступа к трафику. Последствия могли быть катастрофическими: подмена записей для доменов вроде .com или .org парализовала бы доступ к миллионам сайтов, а пользователи массово попадали бы на фишинговые ресурсы.

Команды разработчиков BIND, Microsoft и других вендоров оперативно выпустили патчи (CVE-2021-25220, CVE-2022-32983 и др). Однако администраторам пришлось вручную обновлять софт и менять конфигурации. Например, запрещать обработку запросов как корневых и активировать DNSSEC для проверки подписей.

Google блокирует «крупнейшую в истории» веб-DDoS-атаку

Сложно говорить об атаках на DNS, не упомянув DDoS. Даже если хакеры не целятся напрямую в серверы, их методы парализуют DNS-инфраструктуру через коллапс сетевого стека. Современные атаки вроде PPS-флуда, генерирующего миллионы микроскопических UDP-пакетов, бьют не по DNS-запросам, а по маршрутизаторам и файрволам, которые их обрабатывают. Когда ACL-таблицы захлебываются, а IRQ-шторм выжигает CPU, DNS-резолверы становятся недоступными — не из-за уязвимостей протокола, а из-за того, что сеть под ними превращается в «кисель». Это делает DDoS неотъемлемой частью разговора о DNS: угроза здесь не в подмене записей, а в полном уничтожении доступности — основы любой DNS-системы. Так что начнем.

Когда в июне 2022 года клиент Google Cloud подвергся HTTPS-атаке в 46 млн RPS (Layer 7). Это был не просто «крупный DDoS». Это демонстрация эволюции угроз, где даже TLS-шифрование стало инструментом атакующих. Злоумышленники, вероятно, из семейства Mēris, маскировались через уязвимые прокси и Tor-выходы (22% IP, но лишь 3% трафика — классический «шумовой» финт). Однако их главный козырь — HTTP pipelining — сыграл против них: минимизация TLS-рукопожатий позволила Google расшифровать и проанализировать трафик без перегрузки.


График DDoS-атак с пиком в 46 млн запросов в секунду. Источник.

Система, обученная на baseline-профиле трафика (анализ User-Agent, ASN, HTTP-методов, гео-дисперсии), за восемь минут распознала аномалию. Алгоритмы кластеризации выделили паттерны, характерные для ботнетов: нестандартные HTTP-заголовки (например, отсутствие Accept-Encoding), повторяющиеся URI-паттерны (сканеры в /wp-login.php или /admin), аномальная TLS-сигнатура (устаревшие cipher suites, нестандартные расширения). Сгенерированное правило блокировки, основанное на этих признаках, клиент протестировал в режиме pre-production (аналог «песочницы» для правил WAF), убедившись, что 99,8% легитимного трафика (по метрикам Google) не попадёт под раздачу.

HTTPS-флуд требует в разы больше ресурсов для анализа, чем UDP-атаки. Cloud Armor использовал TLS-termination на edge-узлах, расшифровывая трафик параллельно на тысячах серверов. Tor-трафик стал «побочным ущербом» — даже 1,3 млн RPS с его узлов не пробили защиту, так как Cloud Armor фильтрует его через репутационные базы (например, блокируя IP с историей abuse). Mēris-методология снова подтвердила: ботнеты эволюционируют, но их уязвимые прокси-серверы (например, MikroTik с CVE-2018-14847) остаются слабым звеном.

Атака провалилась не из-за «толстых труб», а из-за прогнозной аналитики. Google Cloud Armor не просто дропал запросы — он предсказал поведение ботнета, используя ML для оценки 50+ параметров трафика. Это кибервойна будущего: алгоритмы против алгоритмов.

Пакетная война: как миллионы маленьких пакетов свели с ума сети

25 мая 2024 года произошел один занимательный случай с применением DDoS-атак. В один момент системы зафиксировали атаку, стартовавшую с 1,5 Тбит/с, а затем в рекордном всплеске пиковая мощность достигла 2,5 Тбит/с. Эти цифры не только шокировали, но и поставили под вопрос всю концепцию современных защитных механизмов. Это была не просто атака, а настоящий вызов, который напомнил о том, что злоумышленники давно перестали довольствоваться традиционным методом «заливки» гигантскими объемами мусорного трафика. Они перешли на тактику, основанную на генерации огромного количества маленьких пакетов, что позволяет перегружать вычислительные мощности сетевых устройств буквально за доли секунды.


Атака мощностью 1,5 Тбит/с, за которой последовала самая большая скорость передачи данных, когда-либо зафиксированная в OVHcloud, — 2,5 Тбит/с на пике. Источник.

Чтобы понять всю глубину проблемы, достаточно взглянуть на математику: при 10 Гбит/с с обычными пакетами размером 1 480 байт мы получаем около 0,85 Mpps, а если взять минимальные пакеты — 84 байта — то это может дать до 14,88 Mpps. Переводя это в контекст современных 100 Гбит/с линий, можно легко представить, что при определенных условиях мы говорим о сотнях миллионов пакетов в секунду. На таком уровне каждая наносекунда и каждый цикл CPU становятся критичными. Если, скажем, на 100 Гбит/с линии приходится 149 Mpps, то на одном ядре с тактовой частотой 3 ГГц приходится всего около шесть наносекунд на обработку одного пакета. Это ставит перед защитными системами абсолютно невообразимые вычислительные нагрузки.

Что еще более интригующе, так это то, что ядром этих атак стали устройства, работающие под управлением RouterOS от MikroTik. Конкретно — модели Cloud Core Router CCR1036 и CCR1072. Эти устройства, несмотря на регулярное обновление прошивок, продолжают оставаться уязвимыми из-за специфической конфигурации и особенностей встроенных функций, таких как «тест пропускной способности». Функция, которую задумывали для диагностики и измерения реальной производительности сети, оказалась идеальным инструментом для злоумышленников, позволяющим генерировать огромные объемы пакетов. Открытые административные интерфейсы лишь усугубляют ситуацию, давая хакерам легкий доступ к критическим настройкам.

На протяжении последних 18 месяцев, а особенно с ноября прошлого года, наблюдалось резкое увеличение DDoS-атак с пакетной скоростью более 100 Mpps. Ранее атаки такого масштаба были редкостью и происходили еженедельно, а теперь они стали почти ежедневными. Рекордная атака с пиком в 840 Mpps, зафиксированная в апреле 2024 года, стала ярким свидетельством того, как злоумышленники изменили свою тактику. Интересно, что 99% трафика исходило из всего лишь нескольких географических точек, преимущественно с западного побережья США. Это вызывает вопросы о методах распределения ботнетов и оптимизации маршрутов.


Рекордная DDoS-атака. Источник.

Используя инструменты вроде Onyphe, можно обнаружить, что в сети открыто до 99 382 устройств, использующих Cloud Core Router от MikroTik. Среди них CCR1036-8G-2S+ и CCR1072-1G-8S+ — модели, способные генерировать, в зависимости от их вычислительных возможностей, около 4 и 12 Mpps соответственно. Если даже небольшой процент таких устройств оказывается скомпрометированным, потенциальный ботнет может генерировать трафик, измеряемый в миллиардах пакетов в секунду. Такой сценарий полностью переворачивает привычное понимание масштабов DDoS-атак и подчеркивает необходимость новых подходов в защите.


Модели устройств, найденных в открытом доступе в Интернете, по данным Onyphe. Источник.

Лично я считаю, что этот кейс — сигнал для всей отрасли. Мы находимся на пороге новой эры DDoS-атак, где не важен лишь объем трафика, а ключевым становится именно количество пакетов в секунду. Это заставляет переосмыслить архитектуру систем защиты, оптимизировать их до предела, и, возможно, внедрять решения на базе FPGA и DPDK для эффективного преодоления вычислительных ограничений. В конечном итоге, если современные атаки развиваются таким образом, наши защитные меры должны идти в ногу, иначе даже самые продвинутые системы могут оказаться беспомощными перед ботнетами, способными «сжечь» процессоры сетевых устройств буквально за секунды.

Эксперты уже продолжительное время наблюдают тенденцию к непрерывному росту количества и мощности DDoS-атак. Подробнее об этом можно почитать в нашем аналитическом отчете за второе полугодие 2024 года.

Меры защиты и лучшие практики

После таких примеров хочется узнать, как же обстоят дела с безопасностью. Не секрет, что есть компании, которые игнорируют DNS-риски, пока их серверы превращаются в зомби для C2-каналов, то есть каналов управления ботнетами или DDoS-пушек. Но необязательно жить в страхе, что ваш домен станет бэкдором для ботов. Давайте разберемся.

Первое, что приходит в голову — DNSSEC. Он добавляет цифровые подписи к DNS-записям, что позволяет проверять их подлинность и предотвращать атаки, такие как спуфинг и отравление кэша. Согласно отчету исследователей, 88% компаний столкнулись с DNS-атаками в 2022 году, а средний ущерб от таких инцидентов составил 942 000 долларов. Внедрение DNSSEC, по данным Heimdal Security, снижает риск успешных атак на 80%, что делает эту технологию стандартом для крупных организаций в 2025 году. Тем не менее, DNSSEC требует регулярного мониторинга состояния ключей и своевременного обновления записей, чтобы избежать ошибок, таких как некорректные DS-записи или истекшие ключи.

Также важным аспектом защиты является правильная настройка кэширования DNS-записей. Уменьшение времени жизни (TTL) до 300 секунд для критически важных доменов помогает существенно снизить окно для атак через отравление кэша. Для статичных ресурсов, таких как CDN, можно увеличить TTL до 3 600 секунд, чтобы улучшить производительность. Кроме того, механизм скавенинга, который автоматически удаляет устаревшие записи, помогает предотвратить использование забытых поддоменов злоумышленниками. Например, атаки через устаревшие CNAME-записи могут перенаправлять трафик на скомпрометированные серверы, что еще раз подтверждает важность поддержания актуальности всех записей.

Мониторинг DNS-трафика становится неотъемлемой частью защиты. Использование файрволов позволяет оперативно выявлять аномалии. Например, резкий рост запросов к подозрительным доменам или необычно длинные DNS-запросы могут сигнализировать о попытках туннелирования данных.

Для организаций, использующих DNS-хостинг с поддержкой современных методов защиты, важным шагом будет автоматизация процессов с интеграцией в облачные платформы. Современные решения, такие как DNS-хостинг с поддержкой DNSSEC и возможности для автоматизации через API, значительно повышают уровень безопасности. Подробнее о возможностях таких сервисов можете почитать в документации.

Не стоит забывать и о важности регулярного аудита DNS-записей. Это включает проверку CNAME, MX и NS записей на наличие подозрительных направлений. Например, поддельные NS-записи могут полностью перехватить управление доменом, что ставит под угрозу всю инфраструктуру. Важно также внедрять технологии DNS over HTTPS (DoH) и DNS over TLS (DoT), которые шифруют трафик и защищают от MITM-атак. Эти технологии, по мнению Better Stack Community, становятся стандартом для корпоративных сетей в 2025 году.

Регулярная ротация TSIG-ключей и обновление программного обеспечения, например, BIND 9.18+, являются важными мерами, позволяющими снизить риски компрометации и сохранить безопасность всей DNS-инфраструктуры.

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

DNS: гонка без финиша

Теперь, когда мы разобрали механизмы атак и защиты DNS, пора задуматься о будущем этой бесконечной гонки.

Понимание механизмов атак и внедрение современных мер безопасности, таких как DNSSEC, помогают значительно повысить уровень защиты. За январь 2025 года, использование DNSSEC увеличилось на 127%, что свидетельствует о стремлении организаций усилить безопасность своих доменных имен.


Источник.

Кроме того, данные диаграмм демонстрируют, что около 75,77% DNS-запросов используют IPv4, а 24,23% — IPv6, при этом подавляющее большинство (99,17%) передаются по UDP. Это означает, что даже при переходе на современный протокол IPv6, основная нагрузка все еще ложится на IPv4, а использование UDP позволяет быстро обрабатывать огромный объём запросов без необходимости устанавливать соединение. Такой баланс подчеркивает эффективность и масштабируемость современной DNS-инфраструктуры.

Однако, несмотря на эти усилия, количество DDoS-атак продолжает расти. Согласно отчету 2025 года, уже фиксируется тренд в увеличении на 137% числа DDoS-атак по сравнению с предыдущим годом. Это не про «поставил DNSSEC и забыл» это про то, как каждые полгода злоумышленники придумывают новый способ отравить кэш, а вы как переписать правила фаервола. Современные угрозы вроде подмены NS-записей через фишинг панелей Cloudflare или туннелирования данных через TXT-записи требуют не «галочек», а холистического подхода: DNS-хостинг, автоматический мониторинг и ротация ключей.