dnssec-policy always generates new keys

Summary

I've been testing the dnssec-policy feature, but either I've come across a bug, or my understanding of the configuration is incomplete.

Whenever BIND restarts, it adds a new key (or keys, depending on the policy) into the configured key directory. It uses this new key or keys to sign the zone, apparently ignoring previously created keys, although the DNSKEY records remain within the zone. I have observed the same behaviour if I initiate an rndc loadkeys .

I've tried both the default policy and an explicitly configured policy with the same results.

There's nothing in the logs indicating an error loading previous keys.

Although the behaviour I described above appeared to apply to both ZSK and KSKs, I have not been able to reliably reproduce the fault with ZSKs. The behaviour is repeatable for KSKs.

BIND version used

BIND 9.15.8 (Development Release) <id:9c5547b>
running on Linux x86_64 3.10.0-1062.9.1.el7.x86_64 #1 SMP Fri Dec 6 15:49:49 UTC 2019
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/opt/isc/isc-bind/root/usr' '--exec-prefix=/opt/isc/isc-bind/root/usr' '--bindir=/opt/isc/isc-bind/root/usr/bin' '--sbindir=/opt/isc/isc-bind/root/usr/sbin' '--sysconfdir=/etc/opt/isc/isc-bind' '--datadir=/opt/isc/isc-bind/root/usr/share' '--includedir=/opt/isc/isc-bind/root/usr/include' '--libdir=/opt/isc/isc-bind/root/usr/lib64' '--libexecdir=/opt/isc/isc-bind/root/usr/libexec' '--localstatedir=/var/opt/isc/isc-bind' '--sharedstatedir=/var/opt/isc/isc-bind/lib' '--mandir=/opt/isc/isc-bind/root/usr/share/man' '--infodir=/opt/isc/isc-bind/root/usr/share/info' '--disable-static' '--enable-dnstap' '--with-pic' '--with-gssapi' '--with-json-c' '--with-libtool' '--with-libxml2' '--without-lmdb' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--with-python' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS= -L/opt/isc/isc-bind/root/usr/lib64' 'PKG_CONFIG_PATH=:/opt/isc/isc-bind/root/usr/lib64/pkgconfig:/opt/isc/isc-bind/root/usr/share/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39)
compiled with OpenSSL version: OpenSSL 1.0.2k  26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips  26 Jan 2017
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with json-c version: 0.11
linked to json-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
compiled with protobuf-c version: 1.3.1
linked to protobuf-c version: 1.3.1
threads support is enabled

default paths:
  named configuration:  /etc/opt/isc/isc-bind/named.conf
  rndc configuration:   /etc/opt/isc/isc-bind/rndc.conf
  DNSSEC root key:      /etc/opt/isc/isc-bind/bind.keys
  nsupdate session key: /var/opt/isc/isc-bind/run/named/session.key
  named PID file:       /var/opt/isc/isc-bind/run/named/named.pid
  named lock file:      /var/opt/isc/isc-bind/run/named/named.lock

Steps to reproduce

Add dnssec-policy to a zone. This can be the default policy or an explicitly defined policy. Restart BIND or reconfig or rndc loadkeys all result in the same behaviour

What is the current bug behavior?

a new KSK is created each time BIND restarts, is reloaded or loadkeys is called. These keys are added to the configured key directory. DNSKEY RRset is signed by all relevant keys (type 257)

What is the expected correct behavior?

New keys are only generated to replace soon to be inactive keys. Keys which are within their active period are used to sign the zone.

Relevant configuration files

Explicit dnssec-policy from named.conf

dnssec-policy simple {
  dnskey-ttl 3600;
  keys {
      ksk key-directory lifetime P6M algorithm 13;
      zsk key-directory lifetime P2M algorithm 13;
  };
  parent-ds-ttl P1D;
  parent-propagation-delay PT1H;
  parent-registration-delay P1D;
  publish-safety PT4H;
  retire-safety PT4H;
  signatures-refresh P7D;
  signatures-validity P4W;
  signatures-validity-dnskey P4W;
  zone-max-ttl PT48H;
  zone-propagation-delay PT1H;

};

Zone statement:

zone "new.org.example" IN {
  type primary;
  file "pri/new.org.example/new.org.example.db";
  //also-notify ;
  allow-query { any; };
  update-policy local;
  dnssec-policy "simple";
  key-directory "pri/new.org.example/keys";
};

Relevant logs and/or screenshots

log from

03-Feb-2020 00:15:38.176 general: info: received control channel command 'loadkeys new.org.example'
03-Feb-2020 00:15:38.179 dnssec: info: zone new.org.example/IN (signed): reconfiguring zone keys
03-Feb-2020 00:15:38.185 dnssec: info: keymgr: DNSKEY new.org.example/ECDSAP256SHA256/58804 (KSK) created for policy simple
03-Feb-2020 00:15:38.195 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/11836 (KSK) is now inactive
03-Feb-2020 00:15:38.196 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/17734 (KSK) is now inactive
03-Feb-2020 00:15:38.196 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/1093 (KSK) is now inactive
03-Feb-2020 00:15:38.196 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/40789 (KSK) is now inactive
03-Feb-2020 00:15:38.196 dnssec: info: Fetching new.org.example/ECDSAP256SHA256/58804 (KSK) from key repository.

03-Feb-2020 00:15:38.196 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/58804 (KSK) is now published
03-Feb-2020 00:15:38.196 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/58804 (KSK) is now active
03-Feb-2020 00:15:38.210 dnssec: info: zone new.org.example/IN (signed): next key event: 03-Feb-2020 02:00:22.179
03-Feb-2020 00:15:38.210 notify: info: zone new.org.example/IN (signed): sending notifies (serial 1580649338)
03-Feb-2020 00:19:54.330 general: info: received control channel command 'loadkeys new.org.example'
03-Feb-2020 00:19:54.331 dnssec: info: zone new.org.example/IN (signed): reconfiguring zone keys
03-Feb-2020 00:19:54.336 dnssec: info: keymgr: DNSKEY new.org.example/ECDSAP256SHA256/39638 (KSK) created for policy simple
03-Feb-2020 00:19:54.349 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/11836 (KSK) is now inactive
03-Feb-2020 00:19:54.349 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/17734 (KSK) is now inactive
03-Feb-2020 00:19:54.349 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/1093 (KSK) is now inactive
03-Feb-2020 00:19:54.349 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/40789 (KSK) is now inactive
03-Feb-2020 00:19:54.349 dnssec: info: Fetching new.org.example/ECDSAP256SHA256/39638 (KSK) from key repository.

03-Feb-2020 00:19:54.349 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/39638 (KSK) is now published
03-Feb-2020 00:19:54.349 dnssec: info: DNSKEY new.org.example/ECDSAP256SHA256/39638 (KSK) is now active
03-Feb-2020 00:19:54.364 dnssec: info: zone new.org.example/IN (signed): next key event: 03-Feb-2020 02:00:22.331
03-Feb-2020 00:19:54.364 notify: info: zone new.org.example/IN (signed): sending notifies (serial 1580649594)

Possible fixes