Assertion failure when using tsig keys in v.9.20

[Doug Freed]

On 7/30/25 15:39, Chris Fairfield wrote:
> Hi all,
> 
> I'm hoping to get some guidance into an unusual Assertion Failure we're 
> encountering.
> 
> We're in the process of migrating our DNS Servers to Ubuntu-based hosts, 
> and as part of that we're also migrating to using tsig keys to help 
> manage our  internal and external Zone transfers. We've migrated all of 
> our secondaries without issue.
> 
> However, we've run into an issue with our authoritative servers and 
> v9.20.11 Whenever we  start named, it loads its zones successfully and 
> then dies whenever it attempts to send its first notify. When it does, 
> it generates the following log messages:
> 
>     30-Jul-2025 10:41:55.622 notify: info: zone zonename.redacted/IN/
>     internal: sending notify to XXX.XX.XX.XXX#53 : TSIG (key-name-redacted)
>     30-Jul-2025 10:41:55.622 general: critical: message.c:2849:
>     REQUIRE(msg->tsigkey == ((void *)0) && msg->sig0key == ((void *)0))
>     failed
>     30-Jul-2025 10:41:55.623 general: critical: /lib/x86_64-linux-gnu/
>     libisc-9.20.11-1+ubuntu22.04.1+deb.sury.org+2-
>     Ubuntu.so(isc_backtrace_log+0x46) [0x7d9458072f46]
>     30-Jul-2025 10:41:55.623 general: critical: /usr/sbin/
>     named(+0x21a37) [0x5f64cec99a37]
>     30-Jul-2025 10:41:55.623 general: critical: /lib/x86_64-linux-gnu/
>     libisc-9.20.11-1+ubuntu22.04.1+deb.sury.org+2-
>     Ubuntu.so(isc_assertion_failed+0x10) [0x7d945806bc10]
>     30-Jul-2025 10:41:55.623 general: critical: /lib/x86_64-linux-gnu/
>     libdns-9.20.11-1+ubuntu22.04.1+deb.sury.org+2-Ubuntu.so(+0x93138)
>     [0x7d9457e92138]
>     30-Jul-2025 10:41:55.623 general: critical: /lib/x86_64-linux-gnu/
>     libdns-9.20.11-1+ubuntu22.04.1+deb.sury.org+2-
>     Ubuntu.so(dns_request_create+0x1f8) [0x7d9457f19178]
>     30-Jul-2025 10:41:55.623 general: critical: /lib/x86_64-linux-gnu/
>     libdns-9.20.11-1+ubuntu22.04.1+deb.sury.org+2-Ubuntu.so(+0x1826c4)
>     [0x7d9457f816c4]
>     30-Jul-2025 10:41:55.623 general: critical: /lib/x86_64-linux-gnu/
>     libisc-9.20.11-1+ubuntu22.04.1+deb.sury.org+2-
>     Ubuntu.so(isc__async_cb+0xa7) [0x7d9458072287]
>     30-Jul-2025 10:41:55.623 general: critical: /lib/x86_64-linux-gnu/
>     libuv.so.1(+0x91ad) [0x7d94578a11ad]
>     30-Jul-2025 10:41:55.623 general: critical: /lib/x86_64-linux-gnu/
>     libuv.so.1(+0x250fe) [0x7d94578bd0fe]
>     30-Jul-2025 10:41:55.623 general: critical: /lib/x86_64-linux-gnu/
>     libuv.so.1(uv_run+0x678) [0x7d94578a6c48]
>     30-Jul-2025 10:41:55.623 general: critical: /lib/x86_64-linux-gnu/
>     libisc-9.20.11-1+ubuntu22.04.1+deb.sury.org+2-Ubuntu.so(+0x47553)
>     [0x7d9458082553]
>     30-Jul-2025 10:41:55.623 general: critical: /lib/x86_64-linux-gnu/
>     libisc-9.20.11-1+ubuntu22.04.1+deb.sury.org+2-Ubuntu.so(+0x5bcde)
>     [0x7d9458096cde]
>     30-Jul-2025 10:41:55.623 general: critical: /lib/x86_64-linux-gnu/
>     libc.so.6(+0x94ac3) [0x7d94574c6ac3]
>     30-Jul-2025 10:41:55.623 general: critical: /lib/x86_64-linux-gnu/
>     libc.so.6(+0x126850) [0x7d9457558850]
>     30-Jul-2025 10:41:55.623 general: critical: exiting (due to
>     assertion failure)
> 
> We get the same issue with v9.20.7, v9.20.9, and v9.20.11
> 
> Named starts without issue and is able to successfully send notifies 
> with tsig keys  when using v9.18.28.
> 
> We've verified that removing the tsig keys from the also-notify 
> statements allows named to start and send notifies. We're also running 
> v.9.20.9 on our older authoritative servers (running a different and 
> older Linux-based OS) and those are able to send tsig-signed notifies 
> without issue. There's no configuration file difference between the 
> older, unaffected servers and the new, affected ones.
> 
> The secondaries are all running v9.20.9 without issue.
> 
> Anyone have an idea on what could be the issue here?
> 
> Thanks,
> Chris
> 
> --
> 
> DDI Engineer, UW
> 
> /Pronouns: He/Him/

Could you open an issue on GitLab?

https://gitlab.isc.org/isc-projects/bind9/-/issues

If you could provide a coredump from the assertion failure, that may 
help Engineering track this down more easily.

Thanks!

-Doug Freed