Bind 9.16.8 reuses old keys

Summary

I switched from 9.11.5.P4 to 9.16.8 and from dnssec-keymgr to dnssec-policy. dnssec-keymgr did not remove old keys and Bind now just revived them all without caring for the old state.

BIND version used

BIND 9.16.8-Debian (Stable Release) <id:539f9f0>
running on Linux x86_64 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28)
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--runstatedir=/run' '--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' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--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 -fdebug-prefix-map=/build/bind9-Pv1hAF/bind9-9.16.8=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 8.3.0
compiled with OpenSSL version: OpenSSL 1.1.1d  10 Sep 2019
linked to OpenSSL version: OpenSSL 1.1.1d  10 Sep 2019
compiled with libuv version: 1.24.1
linked to libuv version: 1.24.1
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with json-c version: 0.12.1
linked to json-c version: 0.12.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.3.2
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/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

Switch from dnssec-keymgr based management to dnssec-policy. You also need to have old keys around. dnssec-keymgr lacked cleanup management so they stayed around.

What is the current bug behavior?

Here is an example zone: https://dnsviz.net/d/_kage.duckcorp.org/dnssec/ You can have a look at the previous state. As you can see that's a bit of a mess. I also wonder if Bind is gonna inactive old keys again by itself or if I have to do that myself.

What is the expected correct behavior?

IMHO it would help to have a proper upgrade path from dnssec-keymgr to dnssec-policy. That means reading the .key files (created by dnssec-keymgr) and at least the Inactive field in order to ignore keys that are not relevant.

Relevant configuration files

The configuration with dnssec-keymgr:

zone "hq.duckcorp.org" IN {
        type master;
        allow-transfer { key duckcorp-internal; };
        also-notify { duckland_ns2; };
        file "/var/cache/bind/masters/hq.duckcorp.org.zone";
        inline-signing yes;
        auto-dnssec maintain;
}

with /etc/bind/dnssec-policy.conf:

policy default {
        algorithm RSASHA512;
        keyttl 3600;
        key-size ksk 4096;
        key-size zsk 2048;
        roll-period ksk 1y;
        roll-period zsk 3mo;
        pre-publish ksk 1mo;
        pre-publish zsk 1mo;
        post-publish ksk 1mo;
        post-publish zsk 1mo;
        standby ksk 0;
        standby zsk 0;
        coverage 1y;
};

And now:

zone "hq.duckcorp.org" IN {
        type master;
        allow-transfer { key duckcorp-internal; };
        also-notify { duckland_ns2; };
        file "/var/cache/bind/masters/hq.duckcorp.org.zone";
        dnssec-policy "generated";
}

dnssec-policy "generated" {
    keys {
        ksk key-directory lifetime P1Y algorithm rsasha512 4096;
        zsk key-directory lifetime 30d algorithm rsasha512 2048;
    };
    max-zone-ttl PT1H;
};

Example of key header for one of the obsolete keys K_kage.hq.duckcorp.org.+010+57716.key:

; This is a zone-signing key, keyid 57716, for _kage.hq.duckcorp.org.
; Created: 20190927153144 (Sat Sep 28 00:31:44 2019)
; Publish: 20200224153144 (Tue Feb 25 00:31:44 2020)
; Activate: 20200325153144 (Thu Mar 26 00:31:44 2020)
; Inactive: 20200623153144 (Wed Jun 24 00:31:44 2020)
; Delete: 20200723153144 (Fri Jul 24 00:31:44 2020)

And the corresponding rndc dnssec -status for it:

key: 57716 (RSASHA512), ZSK
  published:      yes - since Tue Feb 25 00:31:44 2020
  zone signing:   yes - since Thu Mar 26 00:31:44 2020

  Rollover is due since Wed Jun 24 00:31:44 2020
  - dnskey:         omnipresent
  - zone rrsig:     omnipresent

Interestingly some are in other states like:

key: 36878 (RSASHA512), ZSK
  published:      no  - scheduled Fri Feb 19 00:31:44 2021
  zone signing:   no  - scheduled Sun Mar 21 00:31:44 2021

  Key will retire on Sat Jun 19 00:31:44 2021
  - dnskey:         hidden
  - zone rrsig:     hidden

key: 49415 (RSASHA512), ZSK
  published:      no
  zone signing:   no

  Key has been removed from the zone
  - goal:           hidden
  - dnskey:         hidden
  - zone rrsig:     unretentive

Regards. \_o<