DNSSEC: включение в корпоративной зоне без даунтайма и сюрпризов

Семёнов Евгений Сергеевич, директор АйТи Фреш. DNS по своей природе беззащитен: любой в пути от резолвера к авторитативному серверу может подменить ответ. DNSSEC закрывает эту дыру криптографически — подписывает каждую запись зоны и строит цепочку доверия от корневой зоны до ваших A/MX/TXT. У нас на практике включение DNSSEC занимает рабочий день на подготовку и ещё два дня на полную валидацию. Разберём процесс пошагово.

Как устроен DNSSEC

DNSSEC добавляет в DNS четыре новых типа записей:

• DNSKEY — публичные ключи (KSK и ZSK).
• RRSIG — цифровая подпись набора RR (Resource Record Set).
• DS — хэш KSK-а, публикуется в родительской зоне (в зоне .ru для example.ru).
• NSEC/NSEC3 — доказательство отсутствия записи (защита от NXDOMAIN-spoofing).

Цепочка доверия: корневой ключ (встроен в валидатор) → DS в .ru → DNSKEY в example.ru → RRSIG на каждой записи. Если подпись не сходится — валидатор считает ответ BOGUS и отдаёт SERVFAIL.

Предусловия

• Свой контроль над авторитативными NS (BIND9/PowerDNS).
• Регистратор домена поддерживает публикацию DS (все российские регистраторы поддерживают).
• Точное время (NTP) на всех NS-серверах — подписи имеют inception/expiration.
• Возможность увеличить UDP MTU: подписанные ответы больше 512 байт, нужен EDNS0 с буфером 4096.

Подписание зоны в BIND9

# Создаём каталог для ключей
mkdir -p /etc/bind/keys/example.ru
cd /etc/bind/keys/example.ru

# KSK (длинный, редкая ротация)
dnssec-keygen -a ECDSAP256SHA256 -f KSK -n ZONE example.ru

# ZSK (короче, частая ротация)
dnssec-keygen -a ECDSAP256SHA256 -n ZONE example.ru

chown -R bind:bind /etc/bind/keys
chmod 700 /etc/bind/keys
chmod 600 /etc/bind/keys/example.ru/*

В named.conf добавляем параметры для зоны:

zone "example.ru" {
    type master;
    file "/etc/bind/zones/db.example.ru";
    inline-signing yes;
    auto-dnssec maintain;
    key-directory "/etc/bind/keys/example.ru";
};

named-checkconf
rndc reload example.ru
rndc signing -list example.ru

# Должна появиться подпись и DNSKEY-записи
dig @localhost example.ru DNSKEY +dnssec

Подписание зоны в PowerDNS

# На PowerDNS-master
pdnsutil secure-zone example.ru
pdnsutil show-zone example.ru

# Генерируем DS-запись для регистратора
pdnsutil show-zone example.ru | grep -A4 "KSK"
# или
pdnsutil export-zone-ds example.ru

Если нужно сменить алгоритм (по умолчанию PowerDNS ставит ECDSAP256SHA256, что современно и быстро):

pdnsutil disable-dnssec example.ru
pdnsutil set-nsec3 example.ru
pdnsutil add-zone-key example.ru ksk 2048 rsasha256
pdnsutil add-zone-key example.ru zsk 1024 rsasha256
pdnsutil rectify-zone example.ru

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

Получаем DS-запись из нашей зоны:

# BIND
dnssec-dsfromkey /etc/bind/keys/example.ru/Kexample.ru.+013+12345.key

# PowerDNS
pdnsutil export-zone-ds example.ru

# Пример вывода:
# example.ru. 3600 IN DS 12345 13 2 ABCDEF0123...567890

Идём в панель регистратора (Reg.ru, RU-CENTER, Nethouse и т. д.), раздел DNSSEC, добавляем запись с параметрами:

• Key Tag — число из DS (12345)
• Algorithm — 13 (ECDSA P-256)
• Digest Type — 2 (SHA-256)
• Digest — hex-строка

После публикации DS попадает в зону .ru и через 24-48 часов полностью пропагирует.

Проверка валидации

# Через публичный валидирующий резолвер
dig @8.8.8.8 example.ru +dnssec +multi
# Должен быть флаг "ad" и RRSIG-записи

# Онлайн:
# https://dnsviz.net/d/example.ru/dnssec/
# https://dnssec-analyzer.verisignlabs.com/example.ru
# https://dnssec-debugger.verisignlabs.com/example.ru

# Локально — делегация
dig @a.dns.ripn.net example.ru DS

KSK/ZSK rollover

Ключи живут не вечно. Практика — ZSK раз в 30-90 дней, KSK раз в 1-2 года. BIND с auto-dnssec maintain делает ротацию сам:

# Подготовить новый ZSK
dnssec-keygen -a ECDSAP256SHA256 -n ZONE -P +0 -A +3d -I +40d -D +55d \
  -K /etc/bind/keys/example.ru example.ru

# Параметры:
# -P Publish: когда опубликовать в DNSKEY
# -A Active: когда начать подписывать им
# -I Inactive: когда прекратить подписывать
# -D Delete: когда удалить из DNSKEY
rndc loadkeys example.ru

Для KSK — более сложный процесс, потому что нужно обновить DS у регистратора:

1. Сгенерировать новый KSK, опубликовать в зоне (оба KSK видны).
2. Сгенерировать DS для нового KSK, опубликовать у регистратора (оба DS видны).
3. Подождать TTL DS-записи (обычно 3600 секунд) + запас 24-48 часов.
4. Удалить старый DS у регистратора.
5. Через TTL удалить старый KSK из зоны.

В PowerDNS есть автоматизация через pdnsutil activate-zone-key и deactivate-zone-key. В BIND 9.16+ есть policy dnssec-policy, которая делает rollover полностью автоматически.

Мониторинг зоны

Минимум, который я ставлю на все зоны с DNSSEC:

# Скрипт проверки: запускается каждые 15 минут
#!/bin/bash
ZONE="$1"
RES=$(dig @8.8.8.8 "$ZONE" +dnssec +short)
AD=$(dig @8.8.8.8 "$ZONE" | grep -c "flags:.* ad")

if [ "$AD" -eq 0 ]; then
  curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" \
    -d chat_id="$CHAT" \
    --data-urlencode text="DNSSEC FAIL на $ZONE — нет AD-флага"
  exit 2
fi

# Проверка истечения подписей (за 7 дней)
EXP=$(dig @localhost "$ZONE" RRSIG +short | awk '{print $5}' | head -1)
# Парсим дату, сравниваем с сегодня+7

Готовые инструменты: DNSViz как CLI (pip install dnsviz), Prometheus-экспортёр dnssec_exporter, RIPE Atlas probes с анкорами на важные зоны.

Реальный кейс: DNSSEC для регулируемого клиента

В декабре 2025 обратилась страховая компания — 6 публичных зон, требование аудита по ГОСТ Р 57580. Аудитор прямо написал в замечаниях: «отсутствие DNSSEC — высокий риск, рекомендуется устранить в течение квартала». Клиент держал зоны на BIND9 в локальной инфраструктуре.

Провели за 3 рабочих дня:

1. Обновили BIND9 до 9.18, перешли на dnssec-policy (декларативная ротация).
2. Подписали все 6 зон с ECDSAP256SHA256 (короткие подписи, быстрая валидация).
3. Опубликовали DS у RU-CENTER через тикеты в поддержку (у них нет self-service для DNSSEC на некоторых тарифах).
4. Настроили мониторинг в Prometheus с алертами на истечение подписей и отсутствие AD-флага.
5. Обучили IT-команду клиента процедурам KSK-rollover и аварийного выключения.

Стоимость — 62 000 руб. за все 6 зон. Через неделю клиент получил повторный аудит — замечание снято. Одна из зон, которая сидела на устаревшем хостинге без поддержки EDNS0, потребовала переноса на нашу инфраструктуру в дата-центре МТС Москва; взяли в сопровождение за 15 000 руб./мес.

Типичные ошибки

• DS не публикуется или публикуется с ошибкой. Domain становится BOGUS для части пользователей. Всегда проверяйте через DNSViz после публикации.
• Time skew. Подписи привязаны к времени. Если NS ушёл на 10 минут вперёд — подписи ещё не активны, зона BOGUS.
• Слабый алгоритм. RSA-1024 устарел, RSA-2048 работает, но медленно. ECDSAP256SHA256 быстрее и с короткими подписями.
• Нет мониторинга. Ключи истекают, никто не замечает, зона перестаёт резолвиться — 2 часа простоя, пока админ разберётся.
• Rollover без проверки DS. Убрали старый KSK до того, как новый DS опубликован у регистратора — бум.

FAQ — вопросы о DNSSEC

Что защищает DNSSEC, а что — нет?

Защищает от подмены ответов DNS и кэш-отравления. НЕ защищает от DDoS, утечки запросов и не шифрует трафик (для этого DoH/DoT).

Нужен ли DNSSEC для внутренней зоны?

Для публичных — обязателен. Для внутренней — по желанию: защищает от spoofing внутри сети.

Что такое KSK и ZSK?

KSK — длинный ключ для подписи DNSKEY, ротация раз в 1-2 года. ZSK — короче, подписывает остальные записи, ротация каждые 1-3 месяца.

Что будет, если неправильно сделать rollover?

Валидаторы закэшировали старый DNSKEY, новый недоступен — зона BOGUS, SERVFAIL. Вернуть ключ и подождать TTL.

Как проверить, что DNSSEC работает?

dig +dnssec должен вернуть RRSIG и флаг AD. DNSViz.net показывает цепочку доверия визуально.