Протоколы и уязвимости. DNS.

Система доменных имен (DNS) за четыре десятилетия своего существования эволюционировала из простого текстового файла hosts.txt в глобальную, распределенную и критически важную инфраструктуру, обеспечивающую функционирование всей мировой сети. По мере того как интернет трансформировался из академического эксперимента в двигатель глобального прогресса, DNS превратилась в сложную иерархическую систему, где каждый уровень — от корневых серверов до локальных резолверов — стал потенциальной точкой как для технологических инноваций, так и для кибернетических атак. Безопасность DNS определяется не только устойчивостью серверов к DDoS-атакам, но и глубоким внедрением протоколов шифрования, таких как DNS over QUIC (DoQ), и защитой цепочек поставок, которые все чаще становятся основной целью злоумышленников.

Исторический контекст и эволюция иерархии DNS

Путь DNS начался в 1984 году с публикации RFC 920, который заложил основы централизованного управления именами. С тех пор система прошла через этапы монополии Network Solutions в 1990-х годах, создание ICANN в 1998 году и масштабное расширение пространства доменов верхнего уровня (gTLD), которое выходит на новый виток. Современная иерархия DNS построена на древовидной структуре, где корневые серверы (Root Servers) занимают вершину, храня информацию о серверах TLD (например,.com,.org,.net), которые, в свою очередь, направляют запросы к авторитетным серверам второго уровня.

Эволюция DNS привела к тому, что система стала не просто инструментом адресации, но и юридической инфраструктурой. Расширение пространства gTLD до более чем 1200 расширений увеличило поверхность атаки, требуя от владельцев брендов постоянного мониторинга рисков киберсквоттинга и фишинга.

Криптографическая устойчивость корня: Ротация KSK-2024

Безопасность всей иерархии DNS во многом зависит от расширений DNSSEC (DNS Security Extensions), которые обеспечивают аутентичность данных с помощью цифровых подписей. Центральным элементом DNSSEC является ключ подписания ключей корневой зоны (Root Zone Key Signing Key, KSK). В период с 2024 по 2026 годы мировое сообщество проходит через критически важный процесс ротации этого ключа, известный как переход к KSK-2024.

Процесс ротации KSK является многолетним мероприятием. Новый ключ KSK-2024 был сгенерирован в апреле 2024 года и предварительно опубликован в корневой зоне 11 января 2025 года. Это позволило резолверам, использующим протокол RFC 5011 для автоматического обновления якорей доверия (trust anchors), «узнать» новый ключ до того, как он будет применен для создания реальных подписей в октябре 2026 года.

Анализ сигналов RFC 8145, получаемых операторами корневых серверов (такими как Verisign), показывает, что к марту 2025 года около 91.3% резолверов уже успешно добавили KSK-2024 в свою конфигурацию. Этот процесс критически важен, поскольку некорректная настройка якоря доверия может привести к глобальному сбою разрешения имен для всех зон, защищенных DNSSEC.

Протоколы шифрования: От DoT и DoH к DNS over QUIC (DoQ)

Традиционный протокол DNS (порт 53/UDP) не обеспечивает приватности, позволяя любому промежуточному узлу просматривать и модифицировать запросы. Для устранения этого пробела были разработаны DNS over TLS (DoT) и DNS over HTTPS (DoH), а в 2026 году на передний план вышел DNS over QUIC (DoQ), стандартизированный в RFC 9250.

Сравнительный анализ DoH, DoT и DoQ

DoQ объединяет безопасность DoT и гибкость DoH, используя транспортный протокол QUIC, который работает поверх UDP. Основное преимущество DoQ заключается в минимизации задержек за счет использования механизма 0-RTT (Zero Round-Trip Time) и устранения блокировки начала очереди (Head-of-Line Blocking), характерной для TCP-протоколов.

Исследования производительности показывают, что DoH в среднем демонстрирует латентность 12–18 мс, в то время как DoT — 20–25 мс. DoQ, при условии поддержки сессионных ключей, способен превзойти эти показатели, обеспечивая мгновенные ответы при повторных запросах. Более того, DoQ поддерживает миграцию соединений: если устройство переключается с Wi-Fi на мобильную сеть, соединение DNS не обрывается, так как оно привязано к Connection ID, а не к IP-адресу.

DoH/3: Шифрование через HTTP/3

Развитие протоколов привело к появлению DoH/3 (DNS over HTTPS/3), который также использует QUIC, но сохраняет уровень абстракции HTTP/3. В то время как DoQ переносит DNS-сообщения напрямую через QUIC-потоки, DoH/3 инкапсулирует их в HTTP-запросы. Статистика 2026 года показывает, что почти 100% DoQ-резолверов поддерживают возобновление сессий, в то время как среди DoH/3-резолверов этот показатель составляет около 65%. Тем не менее, DoH/3 остается предпочтительным для веб-браузеров из-за глубокой интеграции с существующей инфраструктурой доставки контента.

Ландшафт угроз: Уязвимости ПО и векторы атак

Безопасность DNS сталкивается с новыми вызовами, начиная от ошибок в реализации популярных серверов и заканчивая сложными атаками на цепочки поставок.

Критическая уязвимость кэша: CVE-2025-40778

Одной из самых значимых угроз 2025 года стало обнаружение уязвимости CVE-2025-40778 в BIND 9. Проблема была вызвана избыточной «мягкостью» логики резолвера при обработке ответов. В определенных сценариях BIND принимал записи из секций Answer, которые не соответствовали исходному запросу, что позволяло злоумышленникам проводить атаки по отравлению кэша (Cache Poisoning).

Другие актуальные угрозы DNS в 2026 году

Помимо отравления кэша, выделяются следующие типы атак:

1. DNS Tunneling: Использование DNS-запросов для скрытой передачи данных или команд управления вредоносным ПО (C2), обходя традиционные брандмауэры.
2. Random Subdomain Attack: Заполнение ресурсов резолвера и авторитетного сервера огромным количеством запросов к несуществующим поддоменам (например, uniqueID.example.com), что приводит к отказу в обслуживании (DoS).
3. DNS Rebinding: Атака, использующая смену IP-адреса в ответах для обхода политики Same-Origin в браузерах, позволяя внешнему сайту обращаться к внутренним ресурсам сети жертвы.
4. Phantom Domain Attack: Создание множества доменов, которые никогда не отвечают на запросы, заставляя резолвер тратить ресурсы на ожидание и тайм-ауты.

DNS как критическое звено атак на цепочки поставок

Атаки на цепочки поставок (Supply Chain Attacks) стали одним из самых опасных методов компрометации организаций через их доверенных партнеров или программные зависимости. DNS играет здесь двоякую роль: как вектор для перехвата трафика и как инструмент для распространения вредоносного ПО.

Резонансные инциденты 2025 года

В сентябре 2025 года крупные автомобильные и производственные гиганты, такие как Jaguar Land Rover и Asahi, пострадали от атак на цепочки поставок, что привело к остановке производства и миллиардным убыткам. В случае с DNS это часто реализуется через компрометацию регистраторов доменов или провайдеров управляемого DNS (Managed DNS Providers).

Злоумышленники используют DNS-инфраструктуру для перенаправления обновлений ПО на свои серверы (например, атака Lotus Blossom на Notepad++ в 2025 году через CVE-2025-15556). Это подчеркивает необходимость внедрения строгих политик проверки целостности и мониторинга любых изменений в DNS-записях критически важных сервисов.

Практические рекомендации по защите и настройке ПО DNS.

Современные стандарты требуют от системных администраторов перехода к проактивной защите и регулярному обновлению серверного ПО. Ключевыми инструментами остаются BIND, Unbound, PowerDNS и CoreDNS.

BIND 9: Харденинг и противодействие атакам

BIND остается самым популярным DNS-сервером, но его сложность требует тщательной настройки. Основной рекомендацией является строгое ограничение рекурсии и использование DNSSEC-валидации по умолчанию.

Ключевые меры для BIND:

• Ограничение доступа к рекурсивным запросам только для доверенных IP-адресов через ACL (allow-query { trusted; };).
• Минимизация времени жизни кэша для снижения окна атаки при попытках отравления (max-cache-ttl).
• Внедрение Response Policy Zones (RPZ) для автоматической блокировки известных вредоносных доменов на основе фидов Threat Intelligence.

Unbound: Рекурсивный резолвер с упором на приватность

Unbound от NLnet Labs предлагает одну из лучших реализаций DNS over QUIC для клиентских соединений (downstream DoQ). Версия 1.24.0 и выше позволяет использовать OpenSSL 3.5.0 для нативной поддержки QUIC без необходимости сборки кастомных форков.

Пример настройки DoQ в unbound.conf:

server:
interface: 0.0.0.0@853
quic-port: 853
tls-service-key: "server.key"
tls-service-pem: "server.crt"
# Параметры безопасности
harden-glue: yes
harden-below-nxdomain: yes
qname-minimisation: yes
use-caps-for-id: yes

server:
interface: 0.0.0.0@853
quic-port: 853
tls-service-key: "server.key"
tls-service-pem: "server.crt"
# Параметры безопасности
harden-glue: yes
harden-below-nxdomain: yes
qname-minimisation: yes
use-caps-for-id: yes

Настройка qname-minimisation: yes критически важна для приватности, так как резолвер будет запрашивать у авторитетных серверов только ту часть имени, которая необходима для получения следующей ссылки в иерархии, не раскрывая полный запрос.

PowerDNS: Автоматизация DNSSEC для авторитетных серверов

PowerDNS выделяется своей способностью полностью автоматизировать управление ключами DNSSEC (Online Signing). Это минимизирует риски ошибок администратора при ротации ключей. Рекомендуется использовать алгоритм 13 (ECDSA P-256), который обеспечивает высокую скорость подписи и малый размер ответов, что снижает эффективность атак типа DNS Amplification.

CoreDNS: Особенности безопасности в Kubernetes

CoreDNS является стандартным резолвером для кластеров Kubernetes, что делает его критическим элементом облачной безопасности. Администраторам следует обратить внимание на уязвимость CVE-2026-26018, связанную с плагином loop, который может вызвать бесконечный цикл обработки запросов и падение пода.

Рекомендации по харденингу CoreDNS в K8s:

• Обновление до версии 1.14.2 или новее.
• Использование NetworkPolicies для ограничения доступа к CoreDNS только со стороны авторизованных подов.
• Настройка Liveness и Readiness проб для предотвращения каскадных сбоев при DoS-атаках.

Новые стандарты и будущее протоколов: JSON и IPv6

Развитие DNS направлено на упрощение интеграции и поддержку современных сетевых протоколов. Одним из перспективных направлений является стандарт DNS Update with JSON (DUJ), предложенный в рамках IETF.

DNS Update with JSON (DUJ)

DUJ разработан для упрощения процесса ручного обновления зон пользователями, которым необходимо доказать владение доменом (например, для получения SSL-сертификатов или верификации в социальных медиа). Вместо сложных инструкций «добавьте TXT запись с таким-то значением», сервис предоставляет JSON-строку, которую пользователь просто вставляет в интерфейс своего DNS-провайдера.

Пример структуры DUJ:

{
  "DUJS": {
    "add":
  }
}

{
  "DUJS": {
    "add":
  }
}

Этот формат снижает вероятность ошибок при копировании данных и позволяет операторам автоматизировать процесс валидации вносимых изменений.

IPv6 и DNS64

В условиях исчерпания IPv4-адресов критически важным становится механизм DNS64 (RFC 6147), который позволяет IPv6-хостам обращаться к IPv4-серверов. Новое расширение Router Advertisement (RA) DNS64 Flag позволяет сетям автоматически уведомлять клиентов о наличии DNS64-резолверов, что упрощает развертывание в сетях типа IPv6-only.

Резюме: Стратегия защиты DNS

Анализ современного состояния протоколов и их уязвимостей позволяет сформировать комплексную стратегию безопасности DNS для любого уровня ИТ-инфраструктуры.

1. Шифрование везде: Переход на DNS over QUIC (DoQ) для клиентских устройств обеспечивает не только приватность, но и значительный прирост производительности.
2. Гигиена DNSSEC: Убедитесь, что ваши резолверы поддерживают KSK-2024 и настроены на автоматическое обновление якорей доверия согласно RFC 5011.
3. Защита от Cache Poisoning: Регулярное обновление ПО (особенно BIND 9) до версий, исправляющих CVE-2025-40778, является обязательным требованием для предотвращения атак по перехвату трафика.
4. Мониторинг цепочек поставок: Контроль доступа к панелям управления доменами через MFA и аудит прав доступа регистраторов — единственный способ предотвратить масштабные Supply Chain атаки.
5. Облачная безопасность: В среде Kubernetes DNS-сервер (CoreDNS) должен рассматриваться как критический актив, защищенный сетевыми политиками и строгим RBAC.