Assertion failure if managed-key has seen an algorithm rollover to unsupported algorithm
Summary
tldr; When refreshing managed keys and BIND receives an unsupported DNSSEC algorithm, BIND will exit with an assertion failure.
When configuring managed-keys
BIND will warn and skip any unsupported DNSSEC.
algorithms. However, if setting up a DNSSEC security root with a known
algorithm, an authoritative server may decide to roll their key to an
unsupported algorithm. The next time BIND refreshes the managed keys, it will
hit an assertion failure.
BIND version used
BIND 9.13.5 (Development Release) id:ff20b80
Steps to reproduce
- Set up an authoritative zone, DNSSEC signed with a supported algorithm, for example RSA-SHA256 (8).
- Set up BIND as a resolver. See the section on relevant configuration files.
- Update the authoritative zone, add a new algorithm that is not supported by BIND, for example DSA (3).
- Run
rndc managed-keys refresh
.
You should hit the same error if you do step 2 and the authoritative server already has the DNSKEY with the unsupported algorithm in the zone.
What is the current bug behavior?
BIND will hit an assertion failure.
What is the expected correct behavior?
BIND will log an error and ignore the managed key.
Relevant configuration files
Posted here are the relevant bits.
managed-keys {
5011.isc.pletterpet.nl. initial-key 257 3 8 "AwEAAbOO6f2P9glOwRK7pVRIAW2ugdpc3GUrPXtNvCrIqKUtjV69Xe5T jOzkD8mMBAstXyucTjDryYqX1Ob6ITVBTyzXIKsXAsN8WRtCN6Ip30Ql Dm9rQmWfB7gMcEs96h0LF3dcsY0jvWo7z8juODOi2N8YX+szVPt7QT2a WVGfm+LwbYJDednbKEQ0IcPmNwrKDVi/yz3qMod0o+YXMxdzKCsvpM/S eOAUNZ8e2OgjUZwvrJv+2Dqepbx5YRJniEhElocuAUjcgQiPpwacpcMI 2Oxpepc3P2SWyr98lXnoFh4rl+rexxMkEduHeyriSCQOv0XKZZOlOjpe KqBX+Lis4HM=";
};
options {
...
dnssec-enable yes;
dnssec-validation yes;
recursion yes;
...
};
Dec 12 11:02:52 nibbler named[29227]: 12-Dec-2018 11:02:52.449 dst_api.c:1089: REQUIRE(keyp != ((void *)0) && (__builtin_expect(!!((*keyp) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(*keyp))->magic == ((('D') << 24 | ('S') << 16 | ('T') << 8 | ('K')))), 1))) failed, back trace
Dec 12 11:02:52 nibbler named[29227]: 12-Dec-2018 11:02:52.449 #0 0x450640 in assertion_failed()+0x60
Dec 12 11:02:52 nibbler named[29227]: 12-Dec-2018 11:02:52.449 #1 0x61110a in isc_assertion_failed()+0xa
Dec 12 11:02:52 nibbler named[29227]: 12-Dec-2018 11:02:52.449 #2 0x5e45aa in dst_key_free()+0x1aa
Dec 12 11:02:52 nibbler named[29227]: 12-Dec-2018 11:02:52.449 #3 0x5b16c5 in compute_tag()+0x115
Dec 12 11:02:52 nibbler named[29227]: 12-Dec-2018 11:02:52.449 #4 0x5ca422 in keyfetch_done()+0xdc2
Dec 12 11:02:52 nibbler named[29227]: 12-Dec-2018 11:02:52.449 #5 0x62eabf in run()+0x52f
Dec 12 11:02:52 nibbler named[29227]: 12-Dec-2018 11:02:52.449 #6 0x7f6482f7c6ba in __do_global_dtors_aux_fini_array_entry()+0x7f6482689c8a
Dec 12 11:02:52 nibbler named[29227]: 12-Dec-2018 11:02:52.449 #7 0x7f6482cb241d in __do_global_dtors_aux_fini_array_entry()+0x7f64823bf9ed
Dec 12 11:02:52 nibbler named[29227]: 12-Dec-2018 11:02:52.449 exiting (due to assertion failure)
Possible fixes
The assertion error is easily fixed because this is basically a corrupt call
to dst_key_free()
. However, after this fix BIND will hit a runtime check
error instead:
Dec 12 11:11:02 nibbler named[31365]: 12-Dec-2018 11:11:02.780 zone.c:9600: fatal error:
Dec 12 11:11:02 nibbler named[31365]: 12-Dec-2018 11:11:02.780 RUNTIME_CHECK(result == 0) failed