Bind 9.18.4 managed-keys.bind "placeholder" not replaced with actual key; name resolution fails
Summary
named creates "placeholder" managed-keys.bind
when executed without having a working internet connection, but does never replace it with an actual key and is unable to resolve anything.
BIND version used
BIND 9.18.4 (Stable Release) <id:>
running on Linux x86_64 5.10.121-sp #1 SMP Tue Jun 14 13:50:14 UTC 2022
...
compiled by GCC 8.3.0
compiled with OpenSSL version: OpenSSL 1.1.1l 24 Aug 2021
linked to OpenSSL version: OpenSSL 1.1.1l 24 Aug 2021
compiled with libuv version: 1.27.0
linked to libuv version: 1.27.0
compiled with libnghttp2 version: 1.38.0
linked to libnghttp2 version: 1.38.0
compiled with zlib version: 1.2.12
linked to zlib version: 1.2.12
threads support is enabled
Steps to reproduce
Bind 9.18.4 launched for the first time without an available internet connection, with no managed-keys.bind
present. named.conf
contains the root zone KSK as trust-anchor (see below).
After launching, named creates the corresponding managed-keys.bind
and managed-keys.bind.jnl
files. The former, however contains some kind of placeholder.
$ORIGIN .
$TTL 0 ; 0 seconds
@ IN SOA . . (
4 ; serial
0 ; refresh (0 seconds)
0 ; retry (0 seconds)
0 ; expire (0 seconds)
0 ; minimum (0 seconds)
)
KEYDATA 20220624204221 19700101000000 19700101000000 0 0 0 ; placeholder
Removing this file without an internet connection available, causes it to be recreated the same (minus an updated timestamp) after restarting named.
In this state, with a restored internet connection, named is unable to resolve anything, no matter if it is restarted or not.
If I, with an active internet connection, remove the two managed-keys.bind[.jnl]
files and start named again, the correct KSK from the config is written to managed-keys.bind
and named resolves everything just fine.
What is the current bug behavior?
Named does not resolve until managed-keys.bind
and managed-keys.bind.jnl
are deleted manually and named is restarted when having a working connection to the internet available.
What is the expected correct behavior?
Either named should write the correct KSK right aways or be able to recover from the situation without intervention as soon as an internet connection becomes available. It should be able to resolve names.
Relevant configuration files
trust-anchors {
. initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=";
};
logging {
channel default_syslog {
syslog daemon;
severity debug;
print-time yes;
print-category yes;
print-severity yes;
};
category default { default_syslog; };
category dnssec { default_syslog; };
category config { default_syslog; };
category general { default_syslog; };
};
acl allowed_nwks {
localhost;
localnets;
};
options {
listen-on-v6 {any;};
interface-interval 1;
allow-recursion { allowed_nwks; };
allow-query-cache { allowed_nwks; };
allow-query { allowed_nwks; };
dnssec-validation yes;
managed-keys-directory "/keys";
...
Relevant logs and/or screenshots
Some additional info debugging output, when named is started with the placeholder managed-keys.bind
:
24-Jun-2022 21:47:52.359 dnssec: info: managed-keys-zone: DNSKEY set for zone '.' could not be verified with current keys
24-Jun-2022 21:47:52.389 dnssec: info: validating ./NS: no valid signature found
24-Jun-2022 21:47:52.389 lame-servers: info: no valid RRSIG resolving './NS/IN': 199.9.14.201#53
24-Jun-2022 21:47:52.619 dnssec: info: validating ./NS: no valid signature found
24-Jun-2022 21:47:52.619 lame-servers: info: no valid RRSIG resolving './NS/IN': 192.58.128.30#53
...
Possible fixes
Workaround for me is to remove the two managed-key.bind.[jnl]
files as soon as an internet connection becomes available. This however, ist undesirable as it requires manual intervention or an ugly "always delete those files if you find 'placeholder' in there"-kind-of-hack.
I found some similar issues with the managed-keys.bind
files: #2686 (closed) #2728 (closed). Those are supposed to be fixed.