Undesired dnssec KSK key rotation on zone in multiple views, different dnssec-policy, same key-directory

Summary

After updating my bind installation from (debian packaged) version 1:9.16.8-1bpo10+1 to version 1:9.16.11-2bpo10+1, I encountered a condition where one of my zones kept being assigned a new KSK every time bind9 gets restarted or reloaded. After some investigation I believe that the issue is due to some interaction with the bind views feature; I have two identically-named zones in different views and this is the zone I'm getting KSK issues with.

BIND version used

The issue was observed with debian package version 1:9.16.11-2~bpo10+1; sorry I can not get the named -v version string anymore as I already reverted to the prior working version.

Steps to reproduce

The gist of my setup is as follows:

• in my "public" view, the "lespinasse.org" zone is loaded from /var/lib/bind/db.lespinasse.public, and has the "secure" dnssec-policy applied to it.

• in my "internal" view, the "lespinasse.org" zone is loaded from /etc/bind/db.lespinasse, and has not dnssec applied to it. The view also includes a "public.lespinasse.org" zone which loads the same db.lespinasse.public file as in the public view, but does not apply any dnssec policy to it.

(see more configuration details later down the report).

With this configuration, every bind9 reload or restart causes a new KSK key to be created for the public lespinasse.org zone (and only that one zone - I have several other zones that are behaving as expected).

Digging into my logs, I also noticed that bind9 was complaining about being unable to create a /etc/bind/db.lespinasse.jnl journal, which was odd since db.lespinasse.jnl is only used in my internal lespinasse.org zone, which doesn't allow updates or use any dnssec policy, so there is no reason for it to require a journal...

This lead me to suspect that the bug was triggered by having two zones with identical names in my public and internal views. After commenting out the lespinasse.org zone in my internal view, I was able to confirm that bind9 restarts and reloads do not trigger a KSK rotation in the public lespinasse.org zone anymore. Of course, missing the internal lespinasse.org zone creates other issues on my end, so I ended up reverting to a prior working software version.

What is the current bug behavior?

When restarting or reloading bind9:

• bind9 complains about being unable to create a journal for my internal lespinasse.org zone;
• bind9 creates a new KSK key for my public lespinasse.org zone, which is counter to my set dnssec policy.

What is the expected correct behavior?

• The internal lespinasse.org zone should load without logging any complaints;
• The public lespinasse.org zone should load without creating new KSK keys;
• The configuration of one view should not affect the behavior of another.

Relevant configuration files

This is a sanitized version of my configs, which I hope will be enough to reproduce the issue.

options {
        directory "/var/cache/bind";

        dnssec-validation auto;

        // Default settings, may be overriden for specific views or zones.
        recursion no;
        allow-query { any; };
        allow-transfer { none; };
        allow-update { none; };

        serial-update-method date;
        key-directory "/var/lib/bind/keys";
};

dnssec-policy "secure" {
        // quite similar to the default policy, but I was put off by
        // the note that ksk might get rotated if the default dnssec
        // policy changes signing algorithms in the future
        // so I was trying to avoid that

        dnskey-ttl 3h;
        keys {
                ksk lifetime unlimited algorithm ecdsap256sha256;
                zsk lifetime 4w algorithm ecdsap256sha256;
        };
        publish-safety 12h;
        retire-safety 12h;
        signatures-refresh 2w;
        signatures-validity 4w;
        signatures-validity-dnskey 4w;
};

view "public" {
        match-clients {
                // requests from 192.168.1.1 with the axfr-key
                !{ !key "axfr-key"; any; }; 192.168.1.1;
        };

        notify explicit;
        also-notify { 192.168.1.1; };
        allow-transfer { 192.168.1.1; };

        zone "lespinasse.org" {
                type master;
                file "/var/lib/bind/db.lespinasse.public";
                dnssec-policy "secure";
        };
        zone "test.lespinasse.org" {
                type master;
                file "/var/lib/bind/db.lespinasse.test";
                dnssec-policy "secure";
        };
};

view "internal" {
        match-clients { 127.0.0.1; 10.0.0.0/8; };
        recursion yes;

        include "/etc/bind/named.conf.default-zones";
        zone "lespinasse.org" {
                type master;
                file "/etc/bind/db.lespinasse";
        };
        zone "public.lespinasse.org" {
                type master;
                file "/etc/bind/db.lespinasse.public";
        };
        zone "test.lespinasse.org" { in-view "public"; };
};

(the included test.lespinasse.org zone does not trigger the bug being discussed here; I am only seeing the bug with the lespinasse.org zone(s)).

Relevant logs and/or screenshots

This is what the bind9 output looks like during a restart with the discussed configuration:

all zones loaded
running
zone lespinasse.org/IN/internal: reconfiguring zone keys
zone test.lespinasse.org/IN/public (signed): receive_secure_serial: unchanged
zone public.lespinasse.org/IN/internal: sending notifies (serial 2021013101)
zone lespinasse.org/IN/public (signed): receive_secure_serial: unchanged
keymgr: retire DNSKEY lespinasse.org/ECDSAP256SHA256/58127 (KSK)
keymgr: retire DNSKEY lespinasse.org/ECDSAP256SHA256/3104 (KSK)
keymgr: retire DNSKEY lespinasse.org/ECDSAP256SHA256/34562 (KSK)
keymgr: retire DNSKEY lespinasse.org/ECDSAP256SHA256/6553 (ZSK)
keymgr: retire DNSKEY lespinasse.org/ECDSAP256SHA256/5499 (ZSK)
keymgr: retire DNSKEY lespinasse.org/ECDSAP256SHA256/61198 (KSK)
zone test.lespinasse.org/IN/public (signed): sending notifies (serial 2021013101)
zone test.lespinasse.org/IN/public (signed): reconfiguring zone keys
Fetching lespinasse.org/ECDSAP256SHA256/34562 (KSK) from key repository.
DNSKEY lespinasse.org/ECDSAP256SHA256/34562 (KSK) is now published
Fetching lespinasse.org/ECDSAP256SHA256/6553 (ZSK) from key repository.
DNSKEY lespinasse.org/ECDSAP256SHA256/6553 (ZSK) is now published
DNSKEY lespinasse.org/ECDSAP256SHA256/6553 (ZSK) is now active
CDNSKEY (DELETE) for zone lespinasse.org is now published
CDS (DELETE) for zone lespinasse.org is now published
zone test.lespinasse.org/IN/public (signed): next key event: 04-Feb-2021 11:27:58.679
/etc/bind/db.lespinasse.jnl: create: permission denied
zone lespinasse.org/IN/internal: zone_rekey:dns_journal_open -> unexpected error
zone lespinasse.org/IN/public (signed): sending notifies (serial 2021013118)
zone lespinasse.org/IN/public (signed): reconfiguring zone keys
keymgr: DNSKEY lespinasse.org/ECDSAP256SHA256/44492 (KSK) created for policy secure
DNSKEY lespinasse.org/ECDSAP256SHA256/34562 (KSK) is now inactive
Removing expired key 61198/ECDSAP256SHA256 from DNSKEY RRset.
DNSKEY lespinasse.org/ECDSAP256SHA256/61198 (KSK) is now deleted
Fetching lespinasse.org/ECDSAP256SHA256/44492 (KSK) from key repository.
DNSKEY lespinasse.org/ECDSAP256SHA256/44492 (KSK) is now published
DNSKEY lespinasse.org/ECDSAP256SHA256/44492 (KSK) is now active
zone lespinasse.org/IN/public (signed): update_soa_serial:new serial would be lower than old serial, using increment method 
zone lespinasse.org/IN/public (signed): next key event: 01-Feb-2021 00:31:56.691
zone lespinasse.org/IN/public (signed): update_soa_serial:new serial would be lower than old serial, using increment method 
zone lespinasse.org/IN/public (signed): update_soa_serial:new serial would be lower than old serial, using increment method 

Possible fixes

No idea here :)