Ротация DNSSEC-ключей без простоя: KSK/ZSK rollover и проверка делегирования

DNSSEC добавляет критически важный слой доверия к вашей зоне, но только до тех пор, пока вы дисциплинированно вращаете ключи и не ломаете цепочку делегирования. В статье разберём ротацию ZSK и KSK без простоя, аккуратную работу с DS record у родителя, проверку делегирования и практические команды для контроля на каждом этапе.

KSK vs ZSK: роли, отличия и влияние на делегирование

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

• ZSK (Zone Signing Key) — подписывает записи внутри зоны (A/AAAA, MX, TXT, NS, SOA и т.д.). Меняется чаще, его ротация не требует взаимодействия с реестром/регистратором.
• KSK (Key Signing Key) — подписывает набор DNSKEY. Его проверяет родительская зона через запись DS. Любая смена KSK отражается в родительской зоне и затрагивает делегирование.

Цепочка доверия такова: корень доверяет TLD, TLD публикует DS на вашу зону, а валидаторы сопоставляют DS с вашим KSK (через хэш), и далее доверяют DNSKEY и всем его подписям. Если вы только включаете DNSSEC, посмотрите материал Включение DNSSEC для домена: пошагово и безопасно.

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

TTL, кэширование и временные окна безопасности

Чтобы избежать провалов в валидации, учитывайте три параметра:

• TTL в вашей зоне — у DNSKEY, RRSIG, NSEC/NSEC3 и др.
• TTL записи DS у родителя — кэшируется рекурсорами независимо от вашей зоны.
• Время жизни подписей (RRSIG inception/expiration) — подписи должны оставаться валидными на период двойной публикации.

Практическая рекомендация: для каждого критического шага выдерживайте окно не меньше, чем максимальный TTL соответствующей записи, умноженный на 2, плюс небольшой запас. Например, при обновлении DS: минимум 2×TTL(DS) + запас. Для публикации нового DNSKEY и двойной подписи: 2×TTL(DNSKEY) + запас. Такой подход нивелирует несинхронизированные кэши и задержки. Если хотите количественно проверить влияние TTL на кэш и латентность, изучите Бенчмарк TTL и производительности DNS (dnsperf/resperf).

Ротация ZSK: pre-publish/post-publish без согласований с родителем

Ротация ZSK менее рискованна: родитель и DS не участвуют. Наиболее безопасен сценарий pre-publish:

1. Сгенерируйте новый ZSK и опубликуйте его в ответе DNSKEY, не удаляя старый.
2. Подпишите зону сразу двумя ключами (старым и новым ZSK). Валидаторы начнут принимать обе подписи.
3. Дождитесь истечения 2×TTL(DNSKEY) и гарантированной републикации подписей.
4. Удалите старый ZSK и подписи им; оставьте только новый ZSK.

Пример генерации ключей (BIND):

dnssec-keygen -a ECDSAP256SHA256 -b 256 -n ZONE example.com

Если вы ведёте зону в BIND вручную, подпишите зону обеими парами ключей:

dnssec-signzone -A -o example.com -N keep -3 randomsalt zones/example.com.db

В управлении через inline-signing и автоматизацию BIND достаточно включить параметры, затем просто поместить ключ в каталог ключей — сервер выполнит двойную подпись сам. Конфигурация зоны:

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

Ротация KSK: обновление DS и двойная публикация

KSK отвечает за доверие к вашему набору DNSKEY через DS record у родителя, поэтому ошибки здесь приводят к массовой невалидности. Безопасный порядок действий:

1. Сгенерируйте новый KSK и опубликуйте его в вашей зоне наряду со старым.
2. Подпишите RRset DNSKEY двумя KSK (старым и новым), чтобы оба ключа были признаны валидаторами.
3. Сформируйте DS для нового KSK и обновите делегирование у родителя, добавив новый DS, не удаляя старый.
4. Выдержите окно не меньше 2×TTL(DS) + запас, чтобы все рекурсоры увидели новый DS.
5. Удалите старый DS у родителя, затем через 2×TTL(DNSKEY) + запас удалите старый KSK из зоны.

Команды для KSK (BIND):

dnssec-keygen -a ECDSAP256SHA256 -b 256 -n ZONE -f KSK example.com

Сгенерируйте DS для нового KSK и получите его tag/алгоритм/дайджест, чтобы применить в делегировании:

dnssec-dsfromkey -2 Kexample.com.+013+12345.key

Обычно DS меняют в панели вашего регистратора домена (например, через регистрацию доменов). После того как у родителя появится новый DS, не спешите удалять старый: выдержите окно по TTL(DS). Далее удалите старый DS, и только после прохождения TTL(DS) и TTL(DNSKEY) — старый KSK из вашей зоны.

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

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

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

Двойной DS у родителя

Если родитель поддерживает несколько DS одновременно (обычно да), используйте стратегию double-DS: публикуете новый DS, ждёте, удаляете старый. Это снижает риск рассинхронизации кэшей у резолверов.

Проверка делегирования и валидности

Контролируйте каждый этап командами, которые явно показывают цепочку доверия, ключи и подписи.

Проверка DS у родителя (сравните key tag и алгоритм):

dig +dnssec example.com DS

Проверка набора DNSKEY и подписей:

dig +dnssec example.com DNSKEY

Диагностика валидации делегирования и цепочки доверия:

delv +vtrace example.com

Проверка зоны инструментами ldns:

drill -S example.com
ldns-verify-zone -k Kexample.com.+013+12345.key zones/example.com.signed

Обратите внимание на:

• Key tag в ответах DNSKEY и соответствие дайджесту в DS.
• Алгоритмы ключей и DS — должны совпадать и быть поддерживаемыми резолверами.
• Сроки RRSIG — подписей хватает на весь период двойной публикации.

Выбор алгоритмов и длины ключей

Для производительности и совместимости на практике часто используют ECDSA P-256 (ECDSAP256SHA256) для ZSK и KSK. Он даёт компактные подписи и умеренную нагрузку на CPU. Длина ZSK 256 бит, KSK может быть 256 или 384 при необходимости. RSA остаётся совместимым, но ключи и подписи многократно больше по размеру, что увеличивает ответы, риск фрагментации и накладные расходы.

При смене алгоритма требуется алгоритмический rollover, то есть публикация параллельных ключей с обоих алгоритмов и двойные подписи, затем обновление DS под новый KSK-алгоритм и выдержка всех окон по TTL. Проверяйте, что ваш авторитативный сервер и провайдер вторичных поддерживают выбранные алгоритмы.

NSEC или NSEC3 и соль

NSEC3 с разумными итерациями и солью усложняет зондирование зоны. При ротации соли не забывайте переподписывать зону и учитывать TTL ответов NSEC3. В командах подписи указывайте соль и повторно запускайте подписант на период двойной публикации.

Автоматизация: BIND dnssec-policy, OpenDNSSEC, Knot DNS, PowerDNS

Современные серверы позволяют автоматизировать политики ротации:

• BIND с inline-signing и auto-dnssec maintain, либо с dnssec-policy (KASP) в новых версиях. Политика описывает сроки генерации, публикации, активации и отзыва.
• OpenDNSSEC управляет жизненным циклом ключей, подписью, уведомлениями и экспортом DS.
• Knot DNS через keymgr и key rollover планирует публикации и подписывает зону на лету.
• PowerDNS поддерживает автоматическую ротацию и хранение ключей в БД; DS можно выгружать через утилиты сервера.

Даже при автоматизации не снимайте мониторинг: автоматически не значит мгновенно, задержки зависят от TTL и кэшей. Для сравнения стеков серверов и их особенностей см. обзор PowerDNS vs BIND: сравнение для продакшна.

Практические тайминги и подготовка

Перед началом составьте чек-лист параметров:

• TTL у DNSKEY, у DS в родителе, у критичных RR (NS, SOA).
• Сроки жизни подписей (RRSIG validity) и период реподписи.
• Есть ли вторичные DNS и как они получают подписанную зону (IXFR/AXFR).
• Поддерживает ли родитель мульти-DS и какие алгоритмы разрешены.

Типовой график ZSK pre-publish:

1. День 0: публикация нового ZSK в DNSKEY, двойная подпись.
2. День 0 + 2×TTL(DNSKEY) + запас: удаление старого ZSK.

Типовой график KSK с double-DS:

1. День 0: публикация нового KSK, двойная подпись DNSKEY.
2. День 0: добавление нового DS у родителя.
3. День 0 + 2×TTL(DS) + запас: удаление старого DS у родителя.
4. День 0 + 2×TTL(DS) + 2×TTL(DNSKEY) + запас: удаление старого KSK из зоны.

Вторичные DNS и скрытый мастер

Если у вас вторичные серверы, включите передачу подписанной зоны (IXFR/AXFR) и уведомления. Для BIND со скрытым мастером:

zone "example.com" {
  type master;
  file "zones/example.com.db";
  inline-signing yes;
  auto-dnssec maintain;
  allow-transfer { secondary_ip; };
  also-notify { secondary_ip; };
};

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

Диагностика типовых ошибок

• Неверный DS у родителя: не совпадает key tag/дайджест с KSK. Признак — валидаторы возвращают SERVFAIL при включённой валидации. Решение: сгенерировать DS из актуального KSK и обновить делегирование.
• Слишком раннее удаление старого KSK или DS: часть резолверов ещё кэширует старые значения. Решение: выдерживать окна по 2×TTL соответствующей записи.
• Истекшие RRSIG: автоматический подписант не успел переподписать. Решение: увеличить горизонты подписи и частоту переподписи.
• Несогласованные алгоритмы: DS у родителя ссылается на алгоритм, которого нет в опубликованном KSK. Решение: алгоритмический rollover с параллельной публикацией.
• Фрагментация UDP из-за крупных ответов: большие DNSKEY/DS/RRSIG при RSA. Решение: ECDSA, TCP fallback, настройка минимизации ответов.

Команды для оперативной проверки

Проверить, что резолвер видит валидные подписи и ставит AD-флаг:

dig +dnssec example.com A

Посмотреть только доверительную цепочку и где ломается валидация:

delv example.com A

Сравнить key tag KSK из ответа DNSKEY с DS у родителя:

dig +dnssec example.com DNSKEY
dig +dnssec example.com DS

Сформировать DS для передачи родителю (SHA-256):

dnssec-dsfromkey -2 Kexample.com.+013+12345.key

Здесь ключевой момент — использовать тот файл ключа, который реально опубликован в зоне, и не путать несколько KSK.

Откат в экстренной ситуации

Если после удаления старого DS/KSK часть аудитории видит ошибки валидации:

• При возможности оперативно верните старый DS у родителя и заново опубликуйте старый KSK в зоне.
• Убедитесь, что подписи действительны, и продлите их срок через переподпись.
• Выдержите окно по TTL и повторите процедуру аккуратно, проверяя каждый шаг.

Рекомендации по политикам и мониторингу

• Задать регулярность ротации: ZSK чаще (от недель до месяцев), KSK реже (от кварталов до года), учитывая ваш риск-профиль.
• Снизить TTL перед сложными изменениями (умеренно), дождаться истечения старых TTL и только затем начинать ротацию.
• Вести алерты на истечение RRSIG, рассинхронизацию ключей, отсутствие DS или несоответствие key tag.
• Хранить резерв ключей в защищённом хранилище и обеспечивать аудит действий.

Краткий чек-лист без простоя

• План: известны TTL(DS), TTL(DNSKEY), сроки RRSIG.
• ZSK: pre-publish, двойная подпись, пауза, удаление старого.
• KSK: публикация нового KSK, двойная подпись DNSKEY, добавление нового DS, пауза, удаление старого DS, пауза, удаление старого KSK.
• Проверки: dig/delv/drill на каждом этапе, сверка key tag и дайджестов.
• Мониторинг и логирование на авторитативных и вторичных.

Следуя этим шагам и тщательно выдерживая окна по TTL, вы выполните rollover ZSK и KSK без провалов в валидации и сохраните непрерывную безопасность делегирования для клиентов и поисковых роботов.