Вопросы Теги

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

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

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

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

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

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

  1. Объявление зоны вnamed.conf.local:

    zone "example.com" {
     type master;
     file ".../db.example.com";
     allow-transfer  {... };
     also-notify     {... };
     inline-signing yes;
     auto-dnssec maintain;
     serial-update-method increment;
     key-directory "...";
     sig-validity-interval 64 7;
 };

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

    $TTL 300
@    IN  SOA ns1.example.com. admin.example.com. (
         2021101004      ; Serial
         10m             ; Refresh
         20m             ; Retry
         9w              ; Expire
         1h )            ; Negative Cache TTL
;

example.com. IN  NS  ns1.example.com.
example.com. IN  NS  ns2.example.com.

;...
1
задан 10 October 2021 в 15:14
1 ответ

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

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

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

dnssec-policy example-com-policy {
  dnskey-ttl 300;
  keys {
      ksk key-directory lifetime unlimited algorithm ED25519;
      zsk key-directory lifetime unlimited algorithm ED25519;
  };
  max-zone-ttl 300;
  parent-ds-ttl 300;
  parent-propagation-delay 2h;
  publish-safety 7d;
  retire-safety 7d;
  signatures-refresh 1439h;
  signatures-validity 90d;
  signatures-validity-dnskey 90d;
  zone-propagation-delay 2h;
};

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

zone "example.com" {
     type master;
     file ".../db.example.com";
     allow-transfer  {... };
     also-notify     {... };

     key-directory "...";
     serial-update-method increment;
     dnssec-policy example-com-policy;
};

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

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

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

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

0
ответ дан 12 October 2021 в 20:53

Теги

Похожие вопросы