Кратко

  • draft-ietf-dnsop-dnssec-keyrestore-02 рассматривает узкий сценарий: закрытый ключ неработоспособен, пригодной резервной копии нет, но сохранились полная заранее подписанная зона и ещё действующие подписи.
  • Безопасное восстановление зависит от разных сроков: RRSIG, распространения DNSKEY, публикации DS родителем, загрузки вторичных серверов и вытеснения старых данных из кэшей. Один оператор подписи не распоряжается всеми этапами.
  • Нужна ведомость часов восстановления, где у каждого перехода есть полномочный участник, расчёт и доказательство. Это предложение Daniel Kade, а не требование IETF.

Успешный DNS-ответ в такой ситуации доказывает только жизнеспособность прошлого состояния. Валидатор ещё может соединить старый DNSKEY, подходящий RRSIG и DS родителя. Но изменить адрес, отозвать скомпрометированный сервис или исправить почтовый маршрут безопасно уже нельзя: для нового RRset нужна новая подпись.

Редакция 02 документа DNSSEC Key Restore опубликована 10 августа 2026 года. Это активный Internet-Draft рабочей группы DNSOP; в отображаемом тексте целевой статус указан как Informational. Документ может измениться, быть заменённым или истечь. Он не является RFC, BCP или обязательством RIPE NCC, где работают авторы. Область действия ограничена заранее подписанными зонами; онлайн-подпись и корневая зона исключены.

Слово «восстановление» не означает возвращение утраченного секрета. Если резервной копии нет, прежний закрытый ключ не появляется вновь. Восстанавливается функция подписи с новым ключом, а старые открытые ключи и подписи сохраняются до окончания зависимости валидаторов.

Работоспособность ответа скрывает замороженную зону

Проект называет закрытый ключ inoperable, когда тот больше не способен подписывать. Причиной могут стать отказ оборудования, бедствие, ошибка оператора или злонамеренное действие. Скомпрометированный, но работающий ключ — другое состояние. Там возможна враждебная подпись; здесь немедленная задача состоит в сохранении непрерывности. Неверная классификация ведёт к неверным исключениям.

В момент отказа зона может оставаться полностью и корректно подписанной. RRSIG нередко живут ещё несколько дней, но это не гарантированный срок. Реальный запас определяют конкретные времена окончания подписей, опубликованные RRset и сочетания, которые уже находятся в рекурсивных кэшах. Следует искать самый ранний предел, а не брать типовую настройку.

Спешка способна уничтожить этот запас. Программа подписи не должна удалять DNSKEY лишь потому, что не находит закрытую часть. Старые RRSIG также нужно удерживать; иногда их приходится возвращать вручную. Неработоспособный ключ уже не создаёт новое состояние, но его открытая часть всё ещё поддерживает действующую цепочку доверия.

При отказе ZSK часы остаются в дочерней зоне

Если ZSK не работает, а KSK доступен, новую ZSK можно добавить в DNSKEY RRset и подписать набор существующей KSK. Однако появление ключа на первичном сервере не делает его готовым. Нужно учесть распространение по авторитетным серверам и TTL DNSKEY: Ipub = Dprp + TTLkey.

Затем новая ZSK подписывает зону. Старая остаётся до завершения подписи, распространения и выхода созданных ею RRSIG из кэшей: Iret = Dsgn + Dprp + TTLsig. Отказ, публикация, готовность, активация и безопасное удаление — разные события.

В протоколе IETF 126 отмечено, что потеря одной ZSK не прерывает непрерывность. Но непрерывность проверки не равна способности менять зону. Старые ответы действуют, пока новые записи остаются заблокированными.

При отказе KSK часы переходят к родителю

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

Публикация рассчитывается как Tpub = Tsbm + Dreg, а готовность добавляет IpubP = DprpP + TTLds. RFC 7583 прямо говорит, что сроки KSK с участием родителя не полностью контролируются управляющим дочерней зоной. Быстрая локальная операция не ускоряет очередь родителя и не очищает удалённые кэши.

Поэтому подача, проверка полномочий, принятие, наблюдаемая публикация и готовность после кэширования должны оставаться отдельными статусами. Ответ «принято» не доказывает публикацию. DS на одном сервере не доказывает полное распространение.

При отказе CSK зависимости соединяются. Один ключ подписывал DNSKEY и данные зоны. Замена должна пройти Double-DS у родителя и вернуть подпись содержимого. Старые CSK и RRSIG остаются на период, включающий время подписи, распространение в дочерней зоне и максимум TTL DNSKEY и RRSIG.

Ручной путь возвращает вопрос о полномочиях

В обычном режиме CDS и CDNSKEY автоматизируют обслуживание DS. Но неработоспособная ZSK или CSK не может надёжно подписать новые записи, которыми запрашивается изменение. Редакция 02 возвращает такой случай в ручной канал родителя.

Ручной не означает недокументированный. DNS-провайдер может контролировать рабочую учётную запись, регистратор — связь с клиентом, реестр или оператор родителя — окончательную публикацию. Нужно установить, кто представляет дочернюю зону, кто проверил новый ключ, кто разрешил исключение и кто подтвердил фактический DS.

Вторичные серверы образуют отдельную границу. Чтобы не менять SOA, который нельзя заново подписать старым ключом, оператор может сохранить SOA при добавлении DNSKEY. Тогда обычный IXFR или AXFR может не загрузить изменение. Вторичные серверы приходится принудительно перезагружать. Правильный ответ первичного сервера не доказывает состояние всей авторитетной системы.

Изменение DNSKEY также делает прежний дайджест ZONEMD неверным. Требуется новый дайджест и подпись. Раздел о Knot DNS указывает, что описанный ручной процесс не поддерживает генерацию нового ZONEMD. Это конкретная граница реализации, а не сравнительная оценка продуктов.

На IETF 126 участники просили подробнее сопоставить TTL и истечение подписей и добавить сведения о реализациях. Докладчик сообщил об опыте с Knot DNS, председатель предложил раздел реализации. Такая запись подтверждает ограниченный опыт, но не межвендорную совместимость.

Ведомость часов восстановления

Двух времён — начала и окончания инцидента — недостаточно. Ведомость сначала фиксирует классификацию отказа, роль ключа, алгоритм и самое раннее окончание реально обслуживаемых подписей. Далее она подтверждает сохранение старых DNSKEY и RRSIG, появление нового ключа на авторитетных экземплярах и входные значения распространения и TTL.

Для KSK и CSK отдельно записываются подача родителю, проверка права, принятие, наблюдаемая публикация и окончание кэшевого горизонта. Для вторичных серверов перечисляются принудительные загрузки и увиденное содержимое. Для ZONEMD указывается новый дайджест либо владелец временного исключения и срок исправления.

Завершение новой подписи, проверка образца RRset, первый безопасный момент снятия старых DNSKEY, DS и RRSIG и фактическое удаление тоже не сливаются. У каждого ручного шага есть принимающий решение и путь коррекции.

Секреты публиковать не нужно. Закрытые ключи, конфигурация HSM и персональные данные остаются закрытыми. Хэши артефактов, key tags, временные метки, версии политик, наблюдаемые RRset и роли организаций дают проверяемую последовательность.

Ведомость не должна притворяться наблюдением за всеми рекурсивными кэшами. TTL задаёт консервативную границу, измерения из нескольких точек дают выборку. Сохранив Dprp, TTLkey, TTLds, TTLsig и Dsgn, можно проверить обоснование. Зелёный индикатор без входных данных проверить нельзя.

Проект описывает технически убедительный способ использовать оставшиеся подписи, не превращая зону намеренно в небезопасную или bogus. Он не устанавливает универсальное время восстановления, SLA родителя, полный обзор резолверов или формат аудита. Управленческий вывод таков: оставшаяся жизнь подписей — общий бюджет. Ответственность появляется, когда каждые часы связаны с участником, способным их продвинуть, и с доказательством перехода.

Источники

  1. DNSSEC Key Restore — редакция 02
  2. Карточка документа в Datatracker
  3. История документа
  4. Протокол DNSOP на IETF 126
  5. Активные документы DNSOP
  6. Устав DNSOP
  7. RFC 9364: DNS Security Extensions
  8. RFC 7583: сроки смены ключей DNSSEC
  9. RFC 8078: управление DS через CDS/CDNSKEY
  10. RFC 8976: дайджест DNS-зоны
  11. RFC 9499: терминология DNS