DNS · 16 мин чтения

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

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

Привет! Евгений Семёнов, директор ITFresh. Знаете, DNS сам по себе довольно уязвим: кто угодно может перехватить или подменить ответ, пока он летит от резолвера к авторитативному серверу. Именно здесь на помощь приходит DNSSEC – он криптографически затыкает эту брешь. По сути, DNSSEC подписывает каждую запись в зоне, выстраивая целую цепь доверия – прямо от корневой зоны и до ваших A, MX или TXT записей. На нашей практике, чтобы включить DNSSEC, нам обычно хватает одного рабочего дня на подготовку и ещё пары дней на полную валидацию. Хотите узнать, как это происходит? Давайте пройдёмся по процессу шаг за шагом!

Как устроен DNSSEC

DNSSEC не просто так защищает – для этого он добавляет четыре совершенно новых типа записей в DNS:

Как строится эта цепочка доверия? Всё начинается с корневого ключа, который уже встроен в валидатор. Дальше идёт DS в зоне .ru, потом DNSKEY в вашем example.ru, и наконец, RRSIG на каждой отдельной записи. Если хоть где-то подпись не сошлась — валидатор без вопросов посчитает ответ BOGUS и выдаст SERVFAIL. Никаких компромиссов!

Предусловия

Подписание зоны в 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. Там и добавляем запись со всеми нужными параметрами:

Как только вы опубликуете 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 — раз в один-два года. Хорошая новость: 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-ключ. Затем его опубликовали прямо в DNS-зоне. И что важно, на этом этапе оба 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 полностью автоматически.

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

Вот тот минимум, который мы в ITFresh всегда настраиваем для всех зон с включённым 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. Мы успешно подписали все шесть DNS-зон клиента. Использовали для этого алгоритм ECDSAP256SHA256. Почему? Да потому что он даёт нам сразу два плюса: подписи получаются короткими, а валидация – молниеносной. Эффективность, как говорится, наше всё!
  3. А вот с RU-CENTER вышла небольшая заминка. Чтобы опубликовать DS-записи, пришлось общаться с их поддержкой через тикеты. Оказалось, что на некоторых тарифах у них до сих пор нет удобного self-service для DNSSEC. Что ж, справились, но это отнимает время.
  4. А как же без постоянного контроля? Мы сразу настроили мониторинг в Prometheus. Теперь система бдит и выдаёт алерты, если подписи вдруг начнут истекать или, что ещё хуже, пропадёт AD-флаг. Так мы уверены, что всё под нашим чутким надзором.
  5. И конечно, мы не просто всё настроили, но и передали знания! Наша команда обучила IT-специалистов клиента всем тонкостям процедур KSK-rollover. А ещё показали, как действовать в случае аварийного выключения. Теперь они полностью готовы к любым неожиданностям.

Что по цене? За все 6 зон вышло 62 000 рублей. И представьте, всего через неделю клиент получил повторный аудит – замечание успешно снято! Был, правда, один нюанс: одна из зон, совсем уже древняя, сидела на хостинге без поддержки EDNS0. Пришлось переносить её к нам, в нашу инфраструктуру в дата-центре МТС Москва. Её мы взяли на сопровождение, это ещё 15 000 рублей в месяц.

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

Включим DNSSEC в вашей зоне корректно и без простоя

Мы берём на себя всё: от самого подписания зоны и публикации DS до постоянного мониторинга и полной автоматизации rollover. Все зоны мы размещаем на наших собственных DNS-серверах, которые находятся в дата-центре МТС Москва – это 8 мощных серверов Dell Xeon Platinum 8280 с 40G Mellanox. По стоимости могу сказать, что проект на одну зону начинается от 12 000 руб., а ежемесячное сопровождение – от 3 000 руб./мес. И, кстати, базовый аудит DNSSEC мы делаем абсолютно бесплатно.

Телефон: +7 903 729-62-41
Telegram: @ITfresh_Boss
Семёнов Евгений Сергеевич, директор АйТи Фреш

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 показывает цепочку доверия визуально.

Похожие статьи

Подпишитесь на рассылку ITfresh

Хотите получать только самое полезное? Раз в неделю мы отправляем практические гайды: для руководителя IT и сисадмина. Только по делу: безопасность, 1С, миграции, резервные копии – всё с лайфхаками, прямиком из наших реальных проектов.

Реквизиты оператора персональных данных

ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.