How do I extend the expiration date of every DNSSEC signature in bind9?

Question

I have a dnssec-secured domain that needs to remain valid for 8 weeks when all masters become unreachable.

To my understanding, setting sig-validity-interval to 64 7 in the zone's configuration file should generate SSIGs that last 64 days and that are automatically resigned by bind9 every 7 days.

When I finished implementing this for the domain, I was suprised to see dnsvis showing me that not all generated RRSIGs last 64 days. The RRSIGs for both DNSKEY and SOA do last the expected duration, but all other RRSIGs expire after 11 to 14 days.

I initially thought this might be a caching issue caused by running bind9 before setting the signature validity interval. So I stopped named, cleared /var/cache/bind and removed all DNSSEC files *.jbk, *.jnl, *.signed, and *.signed.jnl, then restarted bind again. This did not resolve the issue.

It's obvious I'm doing something wrong here but I don't know what. Below are the configuration snippets I use for the domain:

1. Zone declaration in 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. Contents of .../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.
   
   ; ...
   

Answer 1

As of bind version 9.16.15 (~2021), it seems that bind only allows control over when RRSIG records expire when custom dnssec-policies are used:

1. First, a custom policy is defined with the options signatures-refresh, signatures-validity, and signatures-validity-dnskey set to the desired values.
2. Then, the custom policy is enabled for a given zone by setting the dnssec-policy option in the zone block.

A custom policy might look something like this:

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;
};

And the zone block might look something like this:

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

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

Be warned, this method comes with a few downsides when compared to the traditional method (i.e. auto-dnssec maintain):

1. I've found that bind becomes unresponsive to rndc/systemctl commands when a single policy is used for multiple domains. Defining a separate policy for each zone seems to have fixed this issue.

2. I've found that bind insists on "retiring" your KSK and ZSK keys regardless of whether they expire or not. I have not found a way to avoid this issue at the time of this writing.

From what I can tell, this is equally applicable to bind in both master and slave configurations.