ZSK rollover dnssec-policy: key lifetime is shorter than the time it takes to do a rollover

Summary

Setting up DNSSec using a dnssec policy a previously working configuration now fails due to the Key duration and roll over periods being too "short".

BIND version used

BIND 9.19.2-1+ubuntu22.04.1+isc+1-Ubuntu (Development Release) <id:>
running on Linux x86_64 5.15.0-39-generic #42-Ubuntu SMP Thu Jun 9 23:42:32 UTC 2022
built by make with  '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/bind9-YovKit/bind9-9.19.2=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 11.2.0
compiled with OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
linked to OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
compiled with libuv version: 1.44.1
linked to libuv version: 1.44.1
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.43.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.5.2
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled

default paths:
  named configuration:  /etc/bind/named.conf
  rndc configuration:   /etc/bind/rndc.conf
  DNSSEC root key:      /etc/bind/bind.keys
  nsupdate session key: //run/named/session.key
  named PID file:       //run/named/named.pid
  named lock file:      //run/named/named.lock
  geoip-directory:      /usr/share/GeoIP

Steps to reproduce

Use the policy provided below and apply this to a zone.

What is the current bug behavior?

Service fails to start.

What is the expected correct behavior?

I should expect the dnssec-policy set to honour the configuration. A warning at best, would be appropriate here. This configuration worked in the previous development release.

The duration of the keys is a security consideration and not something BIND should enforce. If I want my keys to roll over every hour, I should be able to allow this.

The warning provides a 30day message when in fact the security policy (provided below) allows BIND to start. It would be useful to see some sort of timeline view in the docs relating to the config values for a dnssec policy as the values are unexplained and best guess values have been used.

Relevant configuration files

none working config

dnssec-policy "standard" {
    keys {
        ksk lifetime PT120M algorithm ECDSAP384SHA384;
        zsk lifetime PT40M algorithm ECDSAP384SHA384;
    };
    // 
    dnskey-ttl PT3M;
    publish-safety PT3M;
    retire-safety PT5M;
    purge-keys PT1M;

    // Signature timings
    signatures-refresh PT5M;
    signatures-validity PT60M;
    signatures-validity-dnskey PT60M;

    //
    max-zone-ttl PT5M;
    parent-ds-ttl PT3M;
    parent-propagation-delay PT3M;
    nsec3param iterations 10 optout no salt-length 16;
};

working modified config (less than 30d)

dnssec-policy "standard" {
    keys {
        ksk lifetime PT120M algorithm ECDSAP384SHA384;
        zsk lifetime PT55M algorithm ECDSAP384SHA384;
    };
    // 
    dnskey-ttl PT3M;
    publish-safety PT3M;
    retire-safety PT5M;
    purge-keys PT1M;

    // Signature timings
    signatures-refresh PT5M;
    signatures-validity PT40M;
    signatures-validity-dnskey PT40M;

    //
    max-zone-ttl PT5M;
    parent-ds-ttl PT3M;
    parent-propagation-delay PT3M;
    nsec3param iterations 10 optout no salt-length 16;
};

Relevant logs and/or screenshots

Jun 17 16:22:02 ninja.flipkick.media named[2161]: /etc/bind/named.options.conf:43: dnssec-policy: key lifetime is shorter than 30 days
Jun 17 16:22:02 ninja.flipkick.media named[2161]: /etc/bind/named.options.conf:66: dnssec-policy: key lifetime is shorter than 30 days
Jun 17 16:22:02 ninja.flipkick.media named[2161]: /etc/bind/named.options.conf:67: dnssec-policy: key lifetime is shorter than 30 days
Jun 17 16:22:02 ninja.flipkick.media named[2161]: /etc/bind/named.options.conf:67: dnssec-policy: key lifetime is shorter than the time it takes to do a ro>
Jun 17 16:22:02 ninja.flipkick.media named[2161]: loading configuration: failure
Jun 17 16:22:02 ninja.flipkick.media named[2161]: exiting (due to fatal error)
Jun 17 16:22:02 ninja.flipkick.media systemd[1]: named.service: Main process exited, code=exited, status=1/FAILURE

Possible fixes

Allow any period for key duration. 30 days is a poor security policy when working with an Edge computing system and I have resolved the CDS/DS key updates https://github.com/flipkickmedia/cme-dnssec-service - I can get a fully working dnssec system up and running in seconds. With this new update, I have to wait 30d to see if the system works.

I would expect a warning at best, and my TLD providers update the DS keys when I update them (<3H)