Unique key directories reported as reused in 9.16.17, regression vs 9.16.16

Summary

A regression in BIND 9.16.17 (versus 9.16.16) causes per-view key directories to no longer be considered as isolating same-zone keys from one another, resulting in duplicate key-directory errors that prevent BIND from starting. A typical fatal error message looks like this:

/etc/bind/named.conf:193: key-directory 'example.com/(null)' already in use by zone example.com with policy internet: /etc/bind/named.conf:119

BIND version used

BIND 9.16.17 (Stable Release) <id:fe79347>
running on Linux x86_64 5.12.11 #1 SMP Thu Jun 17 02:04:48 EDT 2021
built by make with '--build=x86_64-slackware-linux-gnu' '--docdir=/usr/doc/bind-9.16.17' '--sysconfdir=/etc/bind' '--infodir=/usr/info' '--libdir=/usr/lib64' '--mandir=/usr/man' '--prefix=/usr' '--localstatedir=/var' '--enable-largefile' '--with-libtool' '--enable-shared' '--with-gssapi=/usr' '--with-libidn2' '--with-dlopen' '--with-dlz-filesystem' '--with-dlz-stub' '--enable-auto-validation' '--enable-dnsrps' '--enable-full-report' '--enable-fixed-rrset' '--enable-querytrace' '--with-python=/usr/bin/python3' '--with-openssl' 'build_alias=x86_64-slackware-linux-gnu' 'CFLAGS=-g -O2 -fPIC -march=opteron' 'PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig:/usr/local/share/pkgconfig:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 10.3.0
compiled with OpenSSL version: OpenSSL 1.1.1k  25 Mar 2021
linked to OpenSSL version: OpenSSL 1.1.1k  25 Mar 2021
compiled with libuv version: 1.41.0
linked to libuv version: 1.41.0
compiled with libxml2 version: 2.9.12
linked to libxml2 version: 20912
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
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: /var/run/named/session.key
  named PID file:       /var/run/named/named.pid
  named lock file:      /var/run/named/named.lock

Steps to reproduce

1. Create a named.conf with a split-horizon view, similar to the sample in the Relevant configuration files heading, below.
2. To avoid key collisions (different content in each view for the same example.com zone), keep keys for each view in their own private, per-view directory. Again, see the sample config, below.
3. Upgrade bind from 9.16.16 to 9.16.17 (might also apply to other bind branches, but I haven't tested this).

What is the current bug behavior?

Bind thinks that the key directories are somehow not unique. It's use of the string "/(null)" in the error hints that there might be a missing-string coding bug. That is, where the two key directories would be represented by the strings "example.com/internal/keys" and "example.com/external/keys" in BIND 9.16.16, they are now represented in 9.16.17 by the strings "example.com/(null)" and "example.com/(null)" – a collision. But this is just a wild guess; I haven't traced the code in question.

What is the expected correct behavior?

Bind loads the config, maintains the key directories as per dnssec-policy, starts and runs normally.

Relevant configuration files

Here is a stripped-down version of the named.conf, substituting the well-known example.com in place of the "*.moonlit-rail.com" used in my actual config.

options {
    directory "/var/named/db";
};

include "/etc/bind/dnssec-policy.conf";

view "external" {
    match-clients { ... };
    key-directory "external/keys";
    zone "example.com" IN {
        type master;
        file "external/example.com.zone";
        dnssec-policy "internet";
    };
};

view "internal" {
    match-clients { ... };
    key-directory "internal/keys";
    zone "example.com" IN {
        type master;
        file "internal/example.com.zone";
        dnssec-policy "intranet";
    };
    zone "something.example.com" IN {
        type master;
        file "internal/something.example.com.zone";
        dnssec-policy "intranet";
    };
};

The dnssec-policy.conf is mostly default:

dnssec-policy "internet" {
  keys {
    ksk   key-directory   lifetime unlimited   algorithm ecdsa256;
    zsk   key-directory   lifetime P90D        algorithm ecdsa256;
  };

  nsec3param iterations 15 optout no salt-length 8;
};

dnssec-policy "intranet" {
  keys {
    ksk   key-directory   lifetime unlimited   algorithm ecdsa256;
    zsk   key-directory   lifetime P30D        algorithm ecdsa256;
  };
  nsec3param iterations 15 optout no salt-length 8;
};

Relevant logs and/or screenshots

Jun 17 16:03:14 bindserver named[1000]: /etc/bind/named.conf:193: key-directory 'example.com/(null)' already in use by zone example.com with policy internet: /etc/bind/named.conf:119

Note that the two named.conf line numbers, 193 and 119, correspond with the line zone "example.com" IN { in the internal and external views, respectively.

Possible fixes

I could git-bisect, but I suspect one of the devos here will already have a clue.