dnssec-policy key rollover bug when more than two keys are involved

Summary

When using dnssec-policy, key rollovers are scheduled automatically. If a key rollover is halted (because for example the DS was never uploaded), and a new key is introduced to replace the previous successor, at some point dnssec-policy decides that having only the new key is a valid state, removing the two previous keys. This moves the zone into a bogus state, where the DS in the parent mismatches the DNSKEY RRset in the child zone.

BIND version used

9.16.9

Steps to reproduce

Create a dnssec-policy with quick rollovers, wait until the third key is introduced, and then some more. At some point the keymgr decides to remove the first two keys.

What is the current bug behavior?

The first two keys are removed from the zone too soon.

What is the expected correct behavior?

All three keys should stay in the zone, until a valid rndc dnssec -checkds command is issued.

Relevant configuration files

///
/// 20201209 DST, BIND 9.16 dnssec policy test
///

dnssec-policy "test" {
    // Keys
    keys {
        csk key-directory lifetime 7d algorithm 13;
    };

    // Key timings
    dnskey-ttl 3600;
    publish-safety 1h;
    retire-safety 1h;

    // Zone parameters
    max-zone-ttl 3600;
    zone-propagation-delay 300;

    // Parent parameters
    parent-ds-ttl 1h;
    parent-propagation-delay 1h;
};

zone "badware.ch" {
    type master;
    dnssec-policy test;
    key-directory "/etc/bind/inline-signing-keys";
    file "dynamic/badware.ch";
};

Relevant logs and/or screenshots

https://dnsviz.net/d/badware.ch/X-MRAg/dnssec/

Possible fixes