Cum prelungesc data de expirare a fiecărei semnături DNSSEC din bind9?

Am un domeniu securizat prin dnssec care trebuie să rămână valabil timp de 8 săptămâni când toți masterii devin inaccesibili.

După înțelegerea mea, setarea sig-validitate-interval la 64 7 în fișierul de configurare al zonei ar trebui să genereze SSIGs care durează 64 de zile și care sunt renunțate automat prin bind9 la fiecare 7 zile.

Când am terminat de implementat acest lucru pentru domeniu, am fost surprins să văd dnsvis arătându-mi că nu toate au fost generate RRSIGultimele 64 de zile. The RRSIGs pentru ambele DNSKEY și SOA durează durata așteptată, dar toate celelalte RRSIGexpiră după 11 până la 14 zile.

Inițial am crezut că aceasta ar putea fi o problemă de stocare în cache cauzată de rularea bind9 înainte de a seta intervalul de valabilitate a semnăturii. Așa că m-am oprit numit, clarificat /var/cache/bind și a eliminat toate fișierele DNSSEC *.jbk, *.jnl, *.semnat, și *.semnat.jnl, apoi a repornit legarea din nou. Acest lucru nu a rezolvat problema.

Este evident că fac ceva greșit aici, dar nu știu ce. Mai jos sunt fragmentele de configurare pe care le folosesc pentru domeniu:

1. Declarație de zonă în numit.conf.local:

   zona „example.com” {
        tip master;
        fișierul „.../db.example.com”;
        permite-transfer { ... };
        de asemenea-notifică { ... };
        semnare inline da;
        întreținere auto-dnssec;
        serial-update-method increment;
        directorul-cheie „...”;
        sig-validitate-interval 64 7;
    };
   

2. Conținutul .../db.example.com:

   300 USD TTL
   @ ÎN SOA ns1.example.com. admin.example.com. (
            2021101004; Serial
            10m; Reîmprospăta
            20m; Reîncercați
            9w; Expira
            1h); Cache negativ TTL
   ;
   
   exemplu.com. ÎN NS ns1.example.com.
   exemplu.com. ÎN NS ns2.example.com.
   
   ; ...
   

Începând cu versiunea bind 9.16.15 (~2021), se pare că bind permite controlul numai când RRSIG înregistrările expiră când politici dnssec personalizate sunt utilizate:

1. În primul rând, o politică personalizată este definită cu opțiunile semnături-reîmprospătare, semnături-validitate, și semnături-validitate-dnskey setați la valorile dorite.
2. Apoi, politica personalizată este activată pentru o anumită zonă prin setarea dnssec-politica opțiune în blocul de zonă.

O politică personalizată poate arăta cam așa:

dnssec-policy exemplu-com-policy {
  dnskey-ttl 300;
  chei {
      Algoritm nelimitat cu durata de viață a directorului de chei ksk ED25519;
      algoritm nelimitat cu durata de viață a directorului de chei zsk ED25519;
  };
  max-zona-ttl 300;
  părinte-ds-ttl 300;
  parent-propagare-întârziere 2h;
  publicare-siguranta 7d;
  pensionare-siguranta 7d;
  semnături-reîmprospătare 1439h;
  semnături-validitate 90d;
  semnături-validitate-dnskey 90d;
  zona-propagare-întârziere 2h;
};

Și blocul de zonă ar putea arăta cam așa:

zona „example.com” {
     tip master;
     fișierul „.../db.example.com”;
     permite-transfer { ... };
     de asemenea-notifică { ... };

     directorul-cheie „...”;
     serial-update-method increment;
     dnssec-policy example-com-policy;
};

Fiți atenți, această metodă are câteva dezavantaje în comparație cu metoda tradițională (de ex. întreținere auto-dnssec):

1. Am descoperit că legătura nu răspunde rndc/systemctl comenzi atunci când o singură politică este utilizată pentru mai multe domenii. Definirea unei politici separate pentru fiecare zonă pare să fi rezolvat această problemă.

2. Am găsit legătura aia insistă să „retragă” cheile KSK și ZSK, indiferent dacă expiră sau nu. Nu am găsit o modalitate de a evita această problemă la momentul scrierii acestui articol.

Din câte pot spune, acest lucru este la fel de aplicabil pentru legarea atât în ​​configurațiile master, cât și în cele slave.