Как продлить срок действия каждой подписи DNSSEC в bind9?

У меня есть домен, защищенный dnssec, который должен оставаться действительным в течение 8 недель, когда все мастера станут недоступны.

Насколько я понимаю, установка sig-валидность-интервал к 64 7 в конфигурационном файле зоны должен генерироваться SSIGs, которые длятся 64 дня и автоматически сбрасываются bind9 каждые 7 дней.

Когда я закончил реализовывать это для домена, я был удивлен, увидев, что dnsvis показывает мне, что не все сгенерированные RRSIGпоследние 64 дня. RRSIGс для обоих DNSKEY и СОА действительно длится ожидаемую продолжительность, но все остальные RRSIGs истекает через 11-14 дней.

Сначала я подумал, что это может быть проблема с кэшированием, вызванная запуском bind9 до установки интервала действия подписи. Поэтому я остановился названный, очищено /var/кэш/привязка и удалил все файлы DNSSEC *.jbk, *.jnl, *.подписано, и *.signed.jnl, затем снова перезапустил привязку. Это не решило проблему.

Очевидно, что я делаю что-то не так, но я не знаю, что. Ниже приведены фрагменты конфигурации, которые я использую для домена:

1. Декларация зоны в named.conf.local:

   зона "example.com" {
        тип мастер;
        файл ".../db.example.com";
        разрешить передачу {...};
        также-уведомить {...};
        встроенная подпись да;
        поддержка авто-dnssec;
        приращение метода последовательного обновления;
        ключ-каталог "...";
        sig-validity-interval 64 7;
    };
   

2. Содержание .../db.example.com:

   300 долларов США
   @ В SOA ns1.example.com. admin.example.com. (
            2021101004 ; Серийный
            10 м ; Обновить
            20 м ; Повторить попытку
            9 Вт ; Срок действия
            1 ч ); Отрицательный TTL кэша
   ;
   
   пример.com. В NS ns1.example.com.
   пример.com. В NS ns2.example.com.
   
   ; ...
   

Начиная с версии привязки 9.16.15 (~ 2021 г.), кажется, что привязка позволяет управлять только тогда, когда RRSIG записи истекают, когда пользовательские dnssec-политики используются:

1. Сначала определяется пользовательская политика с параметрами подписи-обновить, подписи-действительность, и подпись-валидность-dnskey установить нужные значения.
2. Затем пользовательская политика включается для данной зоны путем установки параметра dnssec-политика опция в блоке зоны.

Пользовательская политика может выглядеть примерно так:

dnssec-policy пример-ком-политики {
  DNS-ключ-ttl 300;
  ключи {
      ksk key-directory алгоритм с неограниченным сроком действия ED25519;
      Алгоритм неограниченного срока службы каталога ключей zsk ED25519;
  };
  максимальная зона-ttl 300;
  родитель-DS-ttl 300;
  задержка распространения родителя 2 часа;
  публикация-безопасность 7d;
  пенсионная безопасность 7d;
  подписи-обновление 1439ч;
  подписи-срок действия 90d;
  подпись-валидность-dnskey 90d;
  задержка распространения зоны 2 часа;
};

И блок зоны может выглядеть примерно так:

зона "example.com" {
     тип мастер;
     файл ".../db.example.com";
     разрешить передачу {...};
     также-уведомить {...};

     ключ-каталог "...";
     приращение метода последовательного обновления;
     dnssec-policy пример-ком-политики;
};

Имейте в виду, этот метод имеет несколько недостатков по сравнению с традиционным методом (т.е. поддержка авто-dnssec):

1. Я обнаружил, что привязка перестает отвечать на rndc/systemctl команды, когда одна политика используется для нескольких доменов. Определение отдельной политики для каждой зоны, по-видимому, решило эту проблему.

2. Я нашел эту привязку настаивает на «удалении» ваших ключей KSK и ZSK независимо от того, истек ли срок их действия или нет. На момент написания этой статьи я не нашел способа избежать этой проблемы.

Насколько я могу судить, это в равной степени применимо для привязки как в конфигурации master, так и в slave.