Кратко

  • Неистёкшая RRSIG подтверждает только проверяемость уже подписанного состояния в конкретной точке и в конкретный момент; она не подтверждает сохранность закрытого ключа или способность подписать следующую версию зоны.
  • При отказе ZSK с работоспособным KSK применим Pre-Publication; при отказе KSK нужен Double-DS; при отказе CSK требуется скорректированный Double-DS с более длинным интервалом вывода старого материала.
  • Функцию можно считать восстановленной лишь после раздельных свидетельств о Parent DS, Child DNSKEY, повторной подписи, всех авторитетных и вторичных серверах, SOA, NSEC/NSEC3, ZONEMD, независимых резолверах и работе приложений на всём интервале перекрытия.

TTL превращается из настройки в границу управления

В обычный день TTL воспринимается как компромисс между свежестью и нагрузкой. После утраты закрытого DNSSEC-ключа он становится границей управляемости. Оператор может немедленно создать новый ключ и изменить файл зоны, но не может заставить каждый рекурсивный резолвер забыть старый DS или DNSKEY. Он также не может считать новую RRSIG повсеместной, пока её не отдали все авторитетные экземпляры. В этой аварии время принадлежит не одному владельцу зоны: часть его удерживает Parent, часть — Secondary, часть — независимые кэши.

Фокусный документ, draft-ietf-dnsop-dnssec-keyrestore-02, формулирует проблему узко и полезно. На дату проверки 13 сентября 2026 года IETF Datatracker показывал его как активный Internet-Draft рабочей группы DNSOP, редакцию 02, обновлённую 10 августа 2026 года. Это не RFC. Авторы — Florian Obser и Martin Pels; предполагаемый статус — Informational. Текст должен цитироваться как незавершённая работа и содержит дату истечения 11 февраля 2027 года.

Речь идёт об архитектуре с заранее подписанными записями. Online Signing не рассматривается. Корневая зона тоже исключена: распространение новых якорей доверия способно длиться дольше, чем живут оставшиеся RRSIG. Под «неработоспособным» ключом документ понимает ситуацию, когда закрытая часть DNSKEY в цепочке доверия больше не способна подписывать. Скомпрометированный, но всё ещё технически пригодный ключ — другой класс риска, где продолжение его использования само по себе опасно.

Исходное условие восстановления — полная копия DNSSEC-подписанной зоны, возможно снятая с авторитетного сервера. Если рабочей резервной копии закрытого ключа нет, сам ключ восстановить невозможно. Можно вернуть функцию подписи: создать новый криптографический путь и перевести на него доверие, пока старое подписанное состояние ещё проходит проверку.

Почему отвечающая зона — лишь расходуемый актив

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

Сохранность исходной зоны требует дисциплины. Signer не должен удалять DNSKEY без явной команды и не должен удалять старые RRSIG. Если продукт не умеет сохранять старые подписи, перед публикацией приходится вручную восстановить все прежние RRSIG, кроме старой подписи DNSKEY RRset. Любое изменение данных, которое неработоспособный ключ уже не сможет подписать, способно превратить остаток времени в немедленный Bogus. По той же причине не следует одновременно начинать смену алгоритма, если она не шла раньше: сначала восстанавливается функция с текущим алгоритмом, затем проводится обычный algorithm rollover.

RFC 7583 различает состояния ключа Published, Ready, Active, Retired и Dead. В аварийной работе это не терминологическая аккуратность, а запрет на преждевременные действия. DNSKEY, увиденный на одном сервере, ещё не готов; новый подписывающий ключ не делает старый путь ненужным; истечение расчётного интервала без проверки публикации не доказывает фактического распространения. RFC 6781 задаёт механизмы Pre-Publication, Double-Signature и Double-DS, однако выбор между ними диктует оставшаяся способность подписывать конкретные RRset.

Отказ ZSK: новый ключ должен пережить старые кэши до первого изменения

При раздельных KSK и ZSK работоспособный KSK может подписать изменённый DNSKEY RRset. Неработоспособный старый ZSK не может обновить подписи данных, поэтому до готовности замены зона не меняется. Практический путь — Pre-Publication.

В момент Tpub новый ZSK добавляется в DNSKEY RRset. Старый ZSK и все необходимые старые RRSIG сохраняются. SOA обычно не меняют только ради добавления ключа; вторичные и остальные авторитетные экземпляры приходится принудительно перевести на новую версию. Затем выдерживается Ipub = Dprp + TTLkey, где Dprp — доставка до всех авторитетных экземпляров, а TTLkey — TTL DNSKEY. Новый ZSK готов только в Trdy = Tpub + Ipub. До этого резолвер вправе использовать закэшированный DNSKEY RRset без нового ключа и отвергнуть подпись, которой его прежнее представление не соответствует.

После Trdy данные можно менять и подписывать новым ZSK. Старые RRSIG уже можно выводить, но старый ZSK остаётся в DNSKEY. Для него действует Iret = Dsgn + Dprp + TTLsig: задержка подписи, распространение по авторитетной системе и максимальный TTL RRSIG. Теоретический Double-Signature в этой ситуации медленнее, поскольку изменения данных пришлось бы отложить до конца Dsgn + Dprp + max(TTLkey, TTLsig).

Следовательно, наблюдение нового ZSK на одном endpoint подтверждает только одну публикацию. Оно ничего не говорит о каждом Anycast-backend, о фактической загрузке Secondary или о резолверах, чей старый DNSKEY ещё законно живёт в кэше.

Отказ KSK: сначала должен стать наблюдаемым новый якорь у Parent

Неработоспособный KSK не способен подписать изменённый DNSKEY RRset. Поэтому при разделённых ролях применим только Double-DS. Если одновременно отказал ZSK, сначала восстанавливают функцию KSK и не пытаются смешать оба перехода.

Новый DS подаётся Parent в Tsbm. Ответ регистратора или реестра о принятии доказывает максимум административную приёмку. После задержки Dreg DS публикуется в Tpub. Далее проходит родительский интервал IpubP = DprpP + TTLds: распространение по всем авторитетным серверам Parent плюс TTL записи DS. Только в Trdy = Tpub + IpubP новый KSK готов к активации.

При активации новый KSK добавляется в Child DNSKEY и подписывает этот RRset. Старый неработоспособный KSK может покинуть DNSKEY, ZSK остаётся. Но прежний DS у Parent нужно держать ещё Iret = DprpC + TTLkey после активации. Это поддерживает резолверы, в которых сохранился прежний DNSKEY RRset дочерней зоны. Самое раннее удаление Parent DS — Trem = Tact + Iret.

Статусы «запрос DS принят», «DS опубликован», «DS одинаков на каждом Parent-сервере» и «после подтверждённой публикации прошёл TTLds» нельзя объединять. У них разные владельцы, времена и доказательная сила. Иначе административный чек ошибочно становится разрешением менять криптографическую цепочку.

Отказ CSK: обе роли удерживают старый путь дольше

CSK подписывает и DNSKEY, и данные зоны. Когда его закрытая часть недоступна, применяется скорректированный Double-DS. Новый DS публикуется у Parent; после Dreg и IpubP = DprpP + TTLds активируется новый CSK. Его добавляют в Child DNSKEY и подписывают им RRset, но старый CSK и старые RRSIG сохраняют. SOA не следует менять небезопасным образом, а Secondary необходимо принудительно загрузить.

Интервал вывода равен Iret = Dsgn + DprpC + max(TTLkey, TTLsig). Только в Trem = Tact + Iret одновременно удаляются старый Parent DS, старый CSK и старые подписи, после чего допустимы обычные изменения зоны. Более длинное перекрытие отражает двойную роль: ещё могут существовать кэши старого DNSKEY и старых подписей данных, а доверие начинается с DS.

Незаметные расхождения SOA, отрицательных ответов и ZONEMD

При восстановлении ZSK или CSK SOA не следует менять лишь для внесения нового DNSKEY. Старый ключ не подпишет новую SOA. Положительные ответы по существующим именам могут оставаться Secure, тогда как доказательства отсутствия имени или типа становятся Bogus. NSEC и NSEC3 содержат bitmap типов. Если на apex впервые добавить CDS или CDNSKEY, bitmap тоже изменится и потребует подписи, которую потерянный ZSK или CSK создать не сможет.

Поэтому обычная автоматизация DS не всегда спасает аварийный случай. RFC 8078 описывает управление Parent DS через CDS/CDNSKEY, однако новая инструкция, не получившая проверяемой подписи, не является надёжным сигналом. Может понадобиться ручное обновление Parent по аутентифицированному каналу. RFC 10026 помогает отделять решение и его учёт от самой DNS-публикации; запись о принятом решении всё равно не доказывает прохождение кэшей.

Изменение DNSKEY RRset также делает ранее опубликованный дайджест ZONEMD неверным. Нужно создать новый ZONEMD для изменившейся зоны и подписать его DNSSEC. RFC 8976 показывает зависимый порядок ZONEMD, покрывающей его RRSIG и построения NSEC/NSEC3. Проверенный дайджест подтверждает целостность содержимого в рамках этого механизма, но не заменяет проверку цепочки и наблюдение реальной услуги.

Отсутствие изменения SOA создаёт отдельную проблему доставки. Secondary, ориентированный на serial и IXFR/AXFR, может не забрать версию с новым DNSKEY без принудительного действия. RFC 1996 и RFC 9103 задают уведомление и перенос зоны, но запрос на перенос не равен подтверждённой загрузке. Совпавший SOA serial полезен для диагностики версии, однако не является криптографическим доказательством идентичного содержимого.

Таблица смысла, а не таблица зелёных флажков

Каждое свидетельство должно сопровождаться явным пределом вывода.

  1. Старый DNSKEY и неистёкшая старая RRSIG на одном авторитетном сервере доказывают проверяемость одной старой выдачи в момент измерения. Они не доказывают существование закрытого ключа, способность новой подписи или единство всех серверов.
  2. Новый DNSKEY на одном сервере доказывает публикацию в одной точке, но не полную авторитетную доставку и не истечение всех старых DNSKEY-кэшей.
  3. Принятие нового DS регистратором доказывает подачу или административное принятие. Оно не доказывает запись в Parent, распространение, прохождение TTLds или видимость резолверам.
  4. Новая RRSIG, проверяемая новым ключом, доказывает связь конкретного RRset, подписи и ключа в один момент. Она не доказывает повторную подпись всех RRset, согласованность отрицательных доказательств, совпадение ZONEMD или готовность удалить старый путь.
  5. Одинаковый SOA serial — подсказка о переносе, не доказательство побайтового равенства зоны.
  6. Валидный ответ NSEC или NSEC3 подтверждает один отрицательный ответ. Он не охватывает все имена, все bitmap типов и все серверы.
  7. Secure от одного валидирующего резолвера подтверждает его цепочку и кэш в эту секунду. Оно не показывает глобальную сходимость.
  8. Успешные HTTP, TLS или прикладная транзакция подтверждают один путь обслуживания. Они не доказывают проверку DNSSEC каждым клиентом и не разрешают завершать переход.

Смысл DNSKEY, DS, RRSIG и результатов валидации закреплён в RFC 4034, RFC 4035 и RFC 9364. Криптографическая валидность необходима проверяющему клиенту, но не равна доступности, правильной маршрутизации трафика или отсутствию пользовательского ущерба.

Как собрать доказательство восстановленной функции

Первый артефакт — неизменяемая копия последней хорошей подписанной зоны. Вместе с ней фиксируются DNSKEY и DS, время начала и окончания RRSIG, SOA, NSEC или NSEC3 и ZONEMD. Это исходная точка для понимания, какое старое состояние ещё можно сохранить и сколько оно проживёт.

Затем каждый авторитетный экземпляр проверяется отдельно: остался ли старый материал, появился ли новый, какие DNSKEY и RRSIG он действительно отдаёт, как отвечает на положительные и отрицательные запросы. По возможности измеряются отдельные Anycast- и Unicast-backend. Для Parent ведётся последовательность подачи DS, принятия, публикации на всех доступных авторитетных серверах и прохождения TTL. Для Child отдельно отмечаются публикация, готовность, активация, полная повторная подпись RRset, доставка и вывод старых данных.

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

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

Internet-Draft сообщает о проверке процедур с Knot DNS. При этом действия содержат ручные этапы, а описанный путь не поддерживает ручную генерацию нового ZONEMD. Это свидетельство одной реализации, а не обещание универсальной поддержки. Неизвестное время распространения и неоднородная авторитетная инфраструктура расширяют неопределённость; формулы остаются консервативными лишь при верных максимумах и подтверждённой публикации.

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

Источники