DNSSEC для домена: что это, как включить и как не лишиться трафика

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

Зачем нужен DNSSEC и что он решает

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

Важно понимать ограничения: DNSSEC не шифрует трафик и не скрывает запросы, он защищает целостность и подлинность ответа. Он не заменяет TLS, не защищает от DDoS, не исправляет ошибки в конфигурации NS. Для почты используйте SPF, DKIM и DMARC — мы разбирали это в материале «аутентификация почты в DNS» по теме SPF/DKIM/DMARC.

Как это работает: краткая теория

У каждой подписанной зоны есть ключи: один или несколько ключей подписи зоны (ZSK) и ключ(и) подписи ключей (KSK). Публичные ключи публикуются в виде записей DNSKEY, а все ресурсные записи получают подписи RRSIG. Для отрицательных ответов используются NSEC или NSEC3. Доверие строится через запись DS в родительской зоне: именно она «связывает» ваш KSK с родителем.

Термины, которые нужно знать

• ZSK — подписывает записи зоны. Ротируется чаще.
• KSK — подписывает набор ключей (DNSKEY). Ротируется реже; на него указывает DS у регистратора.
• DNSKEY — публичные ключи зоны (и KSK, и ZSK).
• RRSIG — подписи наборов записей (RRset) с датами «не раньше/не позже».
• DS — «отпечаток» KSK в родительской зоне (алгоритм и дайджест).
• NSEC/NSEC3 — доказательство несуществования имени/типа записи.
• Key Tag — короткий идентификатор ключа, помогает выбирать правильный DS.

Алгоритмы на практике: ECDSAP256SHA256 (число 13) — оптимальный выбор сегодня. RSASHA256 (8) все еще широко поддерживается, но тяжелее по CPU и размеру подписей.

Варианты включения DNSSEC

1) Управляемый DNS у провайдера/регистратора

Самый простой путь: включение в панели DNS-провайдера. Как правило, провайдер автоматически подпишет зону и предложит опубликовать DS у регистратора. Иногда публикация DS происходит автоматически (если провайдер и регистратор — одна площадка). Контролируйте TTL и дождитесь генерации подписей до публикации DS. Если домен обслуживается через регистрацию доменов, DS публикуется в панели домена.

2) Собственный авторитативный DNS (BIND/Knot/PowerDNS)

Вы полностью управляете ключами и подписью: генерируете ключи, подписываете зону, публикуете DNSKEY, затем добавляете DS у регистратора. Это гибко, но требует аккуратности и автоматики для ротации ключей и продления подписей (RRSIG). Собственные NS удобно размещать на изолированном VDS с NTP и мониторингом.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

Пошаговое включение DNSSEC на своих NS

Шаг 0. Предварительная проверка зоны

• Зона валидна (SOA, NS, серийный номер, коррекция TTL).
• Все авторитативные NS отвечают одинаково и с одинаковым серийным номером.
• Синхронизированы часы на серверах (NTP обязательно) — иначе подписи могут считаться «неактивными» или «просроченными».

Шаг 1. Генерация ключей

Для BIND можно использовать ECDSA:

dnssec-keygen -a ECDSAP256SHA256 -n ZONE example.ru
dnssec-keygen -f KSK -a ECDSAP256SHA256 -n ZONE example.ru

Либо RSA (если требуется совместимость со старым окружением):

dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.ru
dnssec-keygen -f KSK -a RSASHA256 -b 2048 -n ZONE example.ru

Комплект создаст файлы Kexample.ru.+ALG+KEYID.{key,private}. Храните приватные ключи на сервере с ограниченным доступом.

Шаг 2. Включение подписи зоны

Два типовых подхода для BIND.

• Inline-signing + auto-dnssec — сервер сам подпишет и будет поддерживать подписи при изменениях.
• Ручная подпись — вы вызываете dnssec-signzone при каждом изменении.

Пример для inline-signing:

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

После перезапуска BIND он создаст подписанный файл зоны и начнет отвечать с DNSSEC-дополнениями. На этом этапе не публикуйте DS у регистратора до проверки.

Шаг 3. Проверка подписанной зоны

dig +dnssec +multi example.ru SOA
dig +dnssec +multi example.ru DNSKEY
ldns-verify-zone zones/example.ru.signed
named-checkzone example.ru zones/example.ru.signed

Ищите присутствие RRSIG для наборов записей и корректный набор DNSKEY.

Шаг 4. Генерация DS и публикация у регистратора

Сгенерируйте DS из KSK (не из ZSK):

dnssec-dsfromkey -2 Kexample.ru.+013+*.key

Значение -2 означает дайджест SHA-256. Скопируйте результат в интерфейс регистратора в раздел DS. После публикации подождите репликации в родительской зоне.

Шаг 5. Проверка цепочки доверия

dig +dnssec +multi example.ru A
dig +dnssec +multi example.ru DS
delv example.ru A

Проверяйте, что валидирующий резолвер видит «ad» (Authenticated Data) в ответе, а delv не сообщает о состоянии bogus.

Как не лишиться трафика: чек-лист и частые ошибки

Публикация DS до того, как зона подписана

Критическая ошибка: если в родительской зоне уже есть DS, а ваши NS еще отдают неподписанную зону, большинство валидирующих резолверов будут считать ответы bogus. Последовательность должна быть такой: сначала подписать и убедиться, затем публиковать DS.

Просроченные подписи (RRSIG)

Подписи имеют интервал действия. Если автоматика не продлевает их вовремя (например, упал крон или закончился диск), зона внезапно становится «недоверенной». Настройте мониторинг времени жизни RRSIG и алерты.

Несогласованность между NS

Все авторитативные сервера должны отдавать одинаковую подписанную зону, включая однотипные NSEC/NSEC3 и одинаковые ключи. Микс «подписанная»/«неподписанная» копии под DS — гарантированный провал.

Смена DNS-провайдера при включенном DNSSEC

Опасный кейс: если вы меняете NS и новый провайдер подписывает зону иными ключами, а старый DS все еще в родительской зоне, валидаторы получат несоответствие. Правильная процедура:

1. На новом провайдере подготовить подписанную зону и получить его DS.
2. Переключить NS и убедиться, что новый набор авторитативных серверов отдает корректные DNSKEY/RRSIG.
3. Переопубликовать DS на новый Key Tag и дайджест; только затем удалять старый DS.

Подробнее про перенос домена и сопутствующие шаги описано в руководстве «перенос домена по EPP и DNS» — см. процедуру трансфера домена.

Неверный DS (алгоритм, дайджест, Key Tag)

Частая причина «падения» — ошибочный DS. Проверяйте: соответствует ли Key Tag KSK, совпадает ли алгоритм (например, 13 для ECDSA P-256) и используете ли дайджест SHA-256. При ошибке удаляйте неверный DS, ждите TTL родительской зоны, затем публикуйте корректный.

Часы на сервере и NTP

Подписи чувствительны к времени. Дрейф часов способен «сломать» период валидности. На всех авторитативных NS и системах подписи должен стабильно работать NTP/chrony, а мониторинг — предупреждать об отклонении.

NSEC vs NSEC3, opt-out

Для зон с большим количеством делегаций иногда используют NSEC3 opt-out, чтобы не подписывать каждую подзону. Это экономит ресурсы, но усложняет диагностику. Если не уверены — начните с NSEC3 без opt-out.

Ротация ключей и политика

Рекомендуемая практика: ротировать ZSK чаще (например, раз в 1–3 месяца), KSK — реже (раз в 1–2 года или при компрометации). Два канонических метода ротации:

• Предопубликование (pre-publish) — публикуете новый ключ, подписываете им вместе со старым, затем удаляете старый после истечения всех подписей и кэшей.
• Постопубликование (post-publish) — для некоторых случаев KSK, когда меняется DS в родительской зоне: сначала добавляете новый DS, ждете распространения, затем выводите старый.

Автоматизация в BIND:

auto-dnssec maintain
inline-signing yes

Для ручных сценариев используйте планировщик: периодически вызывать dnssec-signzone, контролировать сроки RRSIG, обновлять ключи командой dnssec-keygen и добавлять/удалять их из зоны в соответствии с методикой.

Проверка, мониторинг и отладка

• Проверка локально: dig +dnssec +multi, delv, drill, ldns-verify-zone, named-checkzone.
• Наблюдение за сроками: скрипт, который опрашивает TTL подписей (RRSIG) и предупреждает, если до истечения осталось, скажем, меньше суток.
• Аномалии: ищите расхождения в DNSKEY между NS, отсутствие RRSIG на отдельных RRset, отличающийся серийный номер зоны.

dig +dnssec +multi example.ru A
dig +dnssec +multi example.ru DNSKEY
delv @9.9.9.9 example.ru A
drill -S example.ru

При отладке фиксируйте, какой резолвер используете, так как кэш может скрывать проблему или, наоборот, удерживать старые данные.

Отключение DNSSEC без потери трафика

Иногда DNSSEC требуется временно выключить (например, при миграции). Порядок действий обратный включению:

1. Сначала удалите DS в родительской зоне (у регистратора). Это переводит зону в состояние «без валидации» для резолверов.
2. Подождите TTL записи в родительской зоне плюс запас для кэшей.
3. Только после этого снимайте подпись зоны (отключайте inline-signing или переставайте выдавать RRSIG).

Если сделать наоборот (сначала убрать подписи, оставив DS), резолверы объявят все ответы bogus.

Специальные случаи и ответы на частые вопросы

Нужен ли DNSSEC для поддоменов?

Если родитель подписан и у вас есть делегирование подзоны, то она может быть подписана независимо. Для подзоны также публикуется DS в родительской зоне.

CDS/CDNSKEY

Некоторые регистраторы поддерживают автоматическую публикацию DS на основе записей CDS/CDNSKEY из дочерней зоны. Это удобно для ротации KSK, но перед включением проверьте политику и тайминги обновления.

DNSSEC и CDN/Anycast

Работает корректно, если все узлы отдают идентичную подписанную зону и синхронно обновляют ключи. Особое внимание на консистентность и серийный номер зоны.

Совместимость алгоритмов

ECDSA P-256 (13) хорошо поддерживается на валидаторах и экономит трафик. Если инфраструктура древняя, используйте RSASHA256 (8). Дайджест для DS — SHA-256.

Можно ли смешивать подписанные и неподписанные данные?

Внутри подписанной зоны отдельные RRset всегда должны иметь RRSIG (кроме некоторых служебных случаев). Делегированные подзоны могут быть неподписанными, если у родителя нет NSEC3 opt-out ограничений; валидаторы корректно обработают делегацию.

Практическая памятка перед публикацией DS

• Зона подписана, все NS отдают одинаковые DNSKEY/RRSIG.
• RRSIG действительны как минимум 48 часов вперед.
• Часы синхронизированы, NTP стабилен.
• Сохранены резервные копии ключей KSK/ZSK и подписанного файла зоны.
• Отлажен мониторинг: падение подписи, изменение DNSKEY, просрочка RRSIG.

Итоги

DNSSEC повышает надежность вашего доменного трафика, защищая пользователей от подмены ответов DNS. Безопасное включение — это правильная последовательность: подписать зону, проверить, затем публиковать DS. Поддержка — это автоматизация продления RRSIG, грамотная ротация ZSK/KSK и мониторинг. А безопасный откат — это в первую очередь удаление DS до снятия подписей. Следуя описанным шагам и чек-листам, вы включите DNSSEC без простоев и неожиданной потери трафика.