Требуется, чтобы это сохраняет зону DNSSEC новой?

TL;DR Вы только что обнаружили, что может быть серьезным недостатком DNSSEC (особенно в отношении DNS) или, по крайней мере, очень важным моментом, о котором всегда следует помнить: DNSSEC — это НЕ просто -time toggle, что-то добавить и закончить с этим. Нет, наоборот, вынуждает регулярно обслуживать зону, а значит выделять для этого ресурсы (автоматизация, мониторинг и т.д.).

Записи RRSIG имеют дату создания (недействительна до этого, обычно около «сейчас» при создании) и дату истечения срока действия (недействительна после).

Наличие записи RRSIG с датой истечения срока действия в прошлом, поэтому срок действия уже истек, является ошибкой. Это означает, что в подписанной записи нет действительной подписи, поэтому это сбой DNSSEC.

Вот почему вам не нужны записи RRSIG с истекшим сроком действия.

Теперь инстинктивным ответом может быть: «Давайте тогда просто заставим их истекать через несколько лет в будущем».

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

А почему бы и нет?

В основном по двум причинам:

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

См. 4.4.2 из https://tools.ietf.org/html/rfc6781#section-4.4.2

4.4.2. Срок действия подписи

4.4.2.1. Максимальное значение

Первое соображение при выборе максимальной действительности подписи
период — это риск повторной атаки. Для малоценных, долгосрочных
стабильные ресурсы, риски могут быть минимальными, а подпись
срок действия может составлять несколько месяцев. Хотя действительность подписи
допускаются многолетние периоды, та же «оперативная привычка»
играют роль аргументы, приведенные в Разделе 3.2.2: Когда зона переподписываются с некоторой периодичностью, то администраторы зоны остаются
осознавая оперативную необходимость повторного подписания.

Обратите внимание, что по тем же причинам срок действия ключей также истекает. У них нет даты истечения срока действия в их записях DNS, но операционная практика заключается в их ротации. Типичные сроки — несколько месяцев для ZSK и несколько лет для KSK. Вы также должны учитывать изменения в криптографии, где, например, в настоящее время SHA-1 считается устаревшим,и ключи на основе RSA имеют рекомендации по длине, меняющиеся в течение года (сначала 1024 бита, теперь 2048 и т. д.)

Любая «серьезная» зона, использующая DNSSEC, и особенно TLD и корень, должна опубликовать «Заявление о практике DNSSEC» с изложением их политики и жизненные циклы ключей и подписей. См., например, RFC 6841: «Структура для политик DNSSEC и практические заявления DNSSEC». в котором говорится:

4.5.3. Другие аспекты управления парой ключей

Для зоны необходимо учитывать другие аспекты управления ключами. оператор и другие участники. Для каждого из этих типов
могут потребоваться ответы на следующие вопросы:

1. Каковы состояния жизненного цикла для управления любой ключи?

2. Каков срок службы этих ключей? Каково использование периоды или активное время жизни для пар?

и

4.6.5. Срок действия подписи и частота повторной подписи

Этот подкомпонент описывает жизненный цикл записи ресурса
. Запись подписи (RRSIG).

Например, вы можете прочитать корневую (.) практику DNSSEC по адресу https://www.iana.org/dnssec/procedures/zsk-operator/dps-zsk-operator-v2.1.pdf Среди прочего в нем говорится:

Для каждого из этих слотов имеется предварительно сгенерированный набор ключей DNSKEY, который подписывается на церемонии ключа со сроком действия не менее 15 дней, чтобы обеспечить перекрытие до 50%.

Если вы делаете запрос DNS прямо сейчас:

$ dig . DNSKEY +dnssec

[..]

;; ANSWER SECTION:
[..]

.           6h17m42s IN RRSIG DNSKEY 8 0 172800 (
                20210512000000 20210421000000 20326 .
[..]

Текущая подпись действительна с 2021-04-21T00:00:00 по 2021-05-12T00:00:00, ровно 21 день.