Безопасность DNS: настройка DNSSEC и защита от атак

DNS — фундамент интернета, преобразующий доменные имена в IP-адреса. Каждый клик по ссылке, каждый запрос API, каждое письмо — всё начинается с DNS-запроса. И именно эта повсеместность делает DNS одной из самых привлекательных целей для злоумышленников. По данным IDC за 2025 год, 88% организаций столкнулись с DNS-атаками в течение года, а средний ущерб от одного инцидента составил $942 000. В январе 2025 года использование DNSSEC выросло на 127% по сравнению с предыдущим годом — индустрия наконец осознала масштаб проблемы. В этом руководстве мы разберём основные векторы DNS-атак, реальные инциденты последних лет и практические меры защиты — от настройки DNSSEC в BIND9 до внедрения DNS over HTTPS. Статья основана на исследовании Selectel о DNS-безопасности и дополнена комментариями практиков из обсуждения на Habr.

Как работает DNS: краткий обзор для понимания атак

Прежде чем разбирать атаки, необходимо понимать механику DNS. Система доменных имён имеет иерархическую структуру:

• TLD (Top-Level Domain) — корневые домены: .ru, .com, .org, .net. Управляются IANA и делегированными регистратурами.
• SLD (Second-Level Domain) — основной домен организации (например, itfresh в itfresh.ru).
• 3LD (Third-Level Domain) — поддомены: www, api, mail, vpn.

Процесс разрешения имени (DNS resolution) проходит через несколько этапов. Stub resolver на вашем устройстве отправляет запрос рекурсивному резолверу (обычно это DNS-сервер провайдера или публичный — 8.8.8.8, 1.1.1.1). Резолвер проверяет кэш; если записи нет, выполняет итеративные запросы: сначала к корневым серверам (13 кластеров по всему миру), затем к TLD-серверам (.ru), и наконец к авторитетным серверам домена, которые отдают конечный ответ. Критически важный факт: весь этот трафик идёт по UDP (99.17% запросов), без шифрования и без верификации подлинности ответа. Именно это создаёт фундаментальную уязвимость.

Основные типы DNS-атак

DNS-спуфинг (подмена ответов)

Злоумышленник отправляет поддельный DNS-ответ раньше, чем легитимный сервер. Для успешной атаки нужно угадать два параметра: 16-битный Transaction ID (TXID) запроса и UDP-порт источника. В классической атаке Каминского (2008) брутфорс TXID позволял отправить тысячи поддельных ответов за время ожидания настоящего. Современные резолверы рандомизируют исходный UDP-порт, что увеличивает пространство перебора с 65 536 до ~4 миллиардов вариантов, но не исключает атаку полностью.

Отравление кэша DNS (Cache Poisoning)

Если поддельный ответ принят резолвером, ложная запись кэшируется на время TTL (Time To Live). При TTL 86 400 секунд (24 часа) весь трафик домена будет направляться на подконтрольный злоумышленнику IP-адрес в течение суток. Это затрагивает не одного пользователя, а всех клиентов данного резолвера — потенциально миллионы людей.

MITM-атака на DNS

Скомпрометированные маршрутизаторы или rogue DHCP-серверы в сети меняют DNS-настройки клиентов «на лету». Пользователь думает, что использует корпоративный DNS, а на самом деле все запросы идут на вредоносный сервер. Особенно опасно в публичных Wi-Fi сетях и при компрометации домашних роутеров (массовые атаки на MikroTik, TP-Link).

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

Один из самых коварных векторов: данные кодируются в Base64 и передаются как поддомены или TXT-записи. Пример: dGVzdA==.tunnel.evil.com — в поддомене зашифрована строка «test». Таким образом создаются C2-каналы (Command and Control) для ботнетов, которые обходят сетевые фильтры и IDS, потому что DNS-трафик редко анализируется глубоко. Признаки туннелирования: необычно длинные DNS-запросы (более 100 символов), аномально высокая частота запросов к одному домену, большие TXT-ответы.

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

Самый разрушительный сценарий: злоумышленник получает доступ к панели управления DNS (через украденные учётные данные регистратора) и изменяет NS-записи. Это даёт полный контроль над всем трафиком домена: сайтом, почтой, API. Инцидент может оставаться незамеченным часы и даже дни.

DDoS-атаки с использованием DNS

DNS-серверы используются как усилители (amplification): маленький запрос (60-100 байт) генерирует ответ в 10-70 раз больше. В июне 2022 года Google Cloud отразил HTTPS-флуд мощностью 46 миллионов RPS от ботнета Meris. В мае 2024 года зафиксирована пакетная DDoS-атака 2.5 Тбит/с с использованием MikroTik-устройств — 14.88 Mpps маленькими пакетами по 84 байта. Из 99 382 открытых MikroTik-устройств в сети значительная часть использовалась как усилители.

DNSSEC: цифровая подпись DNS-записей

DNSSEC (DNS Security Extensions) — набор расширений DNS, добавляющий криптографическую верификацию ответов. По данным Heimdal Security, DNSSEC снижает риск успешных DNS-атак на 80%. Принцип работы: владелец домена подписывает свои DNS-записи приватным ключом, а резолвер проверяет подпись публичным ключом. Если подпись не совпадает — ответ отклоняется.

Ключевые типы записей DNSSEC

• RRSIG — подпись набора ресурсных записей (Resource Record Signature)
• DNSKEY — публичный ключ зоны (Key Signing Key и Zone Signing Key)
• DS — Delegation Signer, хэш DNSKEY, публикуемый в родительской зоне
• NSEC/NSEC3 — доказательство отсутствия записи (authenticated denial of existence)

Настройка DNSSEC в BIND9

BIND 9.18+ поддерживает автоматическое управление ключами DNSSEC (dnssec-policy). Рассмотрим пошаговую настройку для зоны example.ru:

# /etc/bind/named.conf.options
options {
    directory "/var/cache/bind";

    // Включить валидацию DNSSEC для рекурсивных запросов
    dnssec-validation auto;

    // Доверенные якоря (root trust anchors) обновляются автоматически
    // через RFC 5011 (managed-keys)
};

# /etc/bind/named.conf.local
zone "example.ru" {
    type master;
    file "/etc/bind/zones/db.example.ru";

    // Автоматическая политика DNSSEC
    dnssec-policy default;

    // Разрешить динамическое обновление для автоматической подписи
    // inline-signing используется с BIND 9.16+
    inline-signing yes;
};

Политика default в BIND 9.18+ создаёт ECDSAP256SHA256 ключи (KSK и ZSK) и автоматически выполняет ротацию. Для кастомизации:

# Кастомная DNSSEC-политика
dnssec-policy "corporate" {
    keys {
        ksk key-directory lifetime P365D algorithm ecdsap256sha256;
        zsk key-directory lifetime P90D algorithm ecdsap256sha256;
    };

    // Параметры подписи
    dnskey-ttl 3600;
    max-zone-ttl 86400;
    zone-propagation-delay 300;

    // Параметры родительской зоны (для DS-записей)
    parent-ds-ttl 3600;
    parent-propagation-delay 7200;
};

# Перезапустить BIND для применения
sudo systemctl restart named

# Проверить статус DNSSEC
sudo rndc dnssec -status example.ru

# Просмотреть созданные ключи
ls -la /etc/bind/keys/

Публикация DS-записи у регистратора

После подписания зоны необходимо опубликовать DS-запись в родительской зоне (.ru). Это делается через панель управления регистратора домена:

# Получить DS-запись из DNSKEY
dig DNSKEY example.ru @localhost | dnssec-dsfromkey -2 -f - example.ru

# Результат будет вида:
# example.ru. IN DS 12345 13 2 ABCDEF0123456789...

Скопируйте значения Key Tag, Algorithm, Digest Type и Digest в панель регистратора. После публикации DS-записи и её распространения (до 48 часов) DNSSEC заработает для всего мира.

Верификация DNSSEC

# Проверить DNSSEC-подпись домена
dig example.ru +dnssec +short

# Расширенная проверка с выводом цепочки доверия
delv @8.8.8.8 example.ru

# Онлайн-инструменты:
# https://dnsviz.net/ — визуализация цепочки DNSSEC
# https://dnssec-debugger.verisignlabs.com/ — пошаговая проверка

DNS over HTTPS (DoH) и DNS over TLS (DoT)

DNSSEC защищает от подмены записей, но не шифрует DNS-трафик — запросы по-прежнему видны всем узлам на пути (провайдер, роутеры, точки обмена трафиком). Для конфиденциальности DNS-запросов используются протоколы шифрования:

• DNS over TLS (DoT) — RFC 7858, TCP-порт 853. DNS-запросы инкапсулируются в TLS-соединение. Легко блокируется (достаточно закрыть порт 853).
• DNS over HTTPS (DoH) — RFC 8484, TCP-порт 443. DNS-запросы передаются как обычный HTTPS-трафик, неотличимый от веб-запросов. Практически невозможно заблокировать без DPI.

Настройка DoH-клиента на сервере (systemd-resolved)

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
DNSOverTLS=yes
DNSSEC=yes

# Перезапустить
sudo systemctl restart systemd-resolved

# Проверить статус
resolvectl status

Настройка Unbound как локального DoH-резолвера

# /etc/unbound/unbound.conf
server:
    interface: 127.0.0.1
    port: 53

    # Включить DNSSEC-валидацию
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    val-clean-additional: yes

    # Кэширование
    cache-min-ttl: 300
    cache-max-ttl: 86400
    prefetch: yes

forward-zone:
    name: "."
    # Upstream через DoT (TLS)
    forward-tls-upstream: yes
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 1.0.0.1@853#cloudflare-dns.com
    forward-addr: 8.8.8.8@853#dns.google
    forward-addr: 8.8.4.4@853#dns.google

# Установить и запустить
sudo apt install unbound -y
sudo systemctl enable --now unbound

# Проверить работу
dig @127.0.0.1 example.com

Мониторинг DNS-трафика: обнаружение аномалий

Пассивный мониторинг DNS-трафика позволяет обнаружить атаки на ранней стадии. Ключевые индикаторы:

• Аномальная длина запросов — поддомены длиннее 50 символов — признак туннелирования
• Резкий рост запросов к одному домену — возможная эксфильтрация данных или C2-активность
• Большие TXT-ответы — часто используются для DNS-туннелей
• Запросы к только что зарегистрированным доменам (NRD) — типичный паттерн фишинга
• Необычные типы записей — массовые NULL, HINFO, CHAOS — возможная разведка

Мониторинг с помощью dnstop и tcpdump

# Установить dnstop
sudo apt install dnstop -y

# Мониторинг DNS-трафика в реальном времени
sudo dnstop eth0

# Захват DNS-трафика для анализа
sudo tcpdump -i eth0 port 53 -w /tmp/dns-capture.pcap -c 10000

# Анализ в tshark (CLI-версия Wireshark)
tshark -r /tmp/dns-capture.pcap -T fields -e dns.qry.name -e dns.qry.type | sort | uniq -c | sort -rn | head -20

Аудит DNS-записей: что проверять регулярно

Регулярный аудит DNS-записей предотвращает subdomain takeover, утечку почты и незаметный перехват трафика:

# Проверить все записи домена
dig example.ru ANY +noall +answer

# Проверить NS-записи (не изменены ли?)
dig NS example.ru +short

# Проверить MX-записи (критично для почты)
dig MX example.ru +short

# Проверить SPF (TXT-запись для защиты от спуфинга email)
dig TXT example.ru +short

# Поиск «висящих» CNAME (subdomain takeover risk)
dig CNAME www.example.ru +short
dig CNAME blog.example.ru +short
# Если CNAME указывает на несуществующий ресурс — это уязвимость!

Настройка кэширования DNS: баланс производительности и безопасности

TTL (Time To Live) DNS-записей напрямую влияет на безопасность:

• Низкий TTL (300 секунд) — для критичных сервисов (основной домен, MX, API). Быстрое переключение при инциденте, но высокая нагрузка на авторитетные серверы.
• Средний TTL (3600 секунд) — для статичных ресурсов (CDN, изображения). Оптимальный баланс.
• Высокий TTL (86400 секунд) — для редко изменяемых записей (NS, TXT для SPF/DKIM). Минимальная нагрузка, но медленное переключение.

Для DNS-резолверов важен механизм скавенинга — автоматическое удаление устаревших записей из кэша. В Windows DNS Server настройте: DNS Manager → Server Properties → Advanced → Enable scavenging.

Практические рекомендации по защите DNS-инфраструктуры

1. Включите DNSSEC для всех доменов организации. В 2026 году это must-have, а не nice-to-have.
2. Используйте DoH/DoT для рекурсивных запросов. Настройте Unbound или systemd-resolved с TLS-upstream.
3. Мониторьте DNS-трафик на аномалии: длинные запросы, необычные типы записей, всплески к одному домену.
4. Разделяйте авторитетные и рекурсивные серверы. Никогда не совмещайте обе роли на одном сервере.
5. Защитите панель регистратора двухфакторной аутентификацией. Включите Registry Lock для критичных доменов.
6. Обновляйте DNS-серверы. BIND 9.18+, Unbound 1.17+, PowerDNS 4.8+ — проверяйте CVE регулярно.
7. Настройте TSIG для аутентификации трансферов зон (AXFR/IXFR) между master и slave серверами.
8. Ограничьте рекурсию. Рекурсивный резолвер должен обслуживать только внутренних клиентов, не весь интернет.
9. Внедрите RPZ (Response Policy Zones) для блокировки вредоносных доменов на уровне DNS.
10. Проводите аудит DNS-записей не реже раза в месяц. Сравнивайте текущее состояние с эталоном.