BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2020-10-22T07:52:55Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2121Possible memory leak in filter-aaaa.so2020-10-22T07:52:55ZPeter DaviesPossible memory leak in filter-aaaa.so### Title
Possible memory leak in filter-aaaa.so
may be the same issue as seen in #1041
### Customer reports:
I've noticed the filter-aaaa plugin can (seemingly) leak memory if its
internal type-A query is canceled (e.g., due to...### Title
Possible memory leak in filter-aaaa.so
may be the same issue as seen in #1041
### Customer reports:
I've noticed the filter-aaaa plugin can (seemingly) leak memory if its
internal type-A query is canceled (e.g., due to recursion quota).
I've only confirmed it by applying the attached diff to quickly
emulate the situation, but I believe that can happen without it.
With this diff, the corresponding "client_state" leaks since on
resuming from recursion fetch_callback() returns query_error instead
of query_resume (in which the filter-aaaa hook is called and the state
is freed). you can see the leak on shutdown as an assertion failure:
```
02-Sep-2020 16:56:17.187 stopping command channel on 127.0.0.1#9053
02-Sep-2020 16:56:17.196 mem.c:1675: unexpected error:
02-Sep-2020 16:56:17.196 isc_mempool_destroy(): mempool leaked memory
02-Sep-2020 16:56:17.196 mem.c:1681: REQUIRE(mpctx->allocated == 0) failed, back trace
```
You may also want to consider it to be a sensitive (security) bug,
because, if I understand it correctly, it could be triggered by
someone who can send a AAAA query causing recursion and control the
target zone (delaying answering the A queries while sending other
queries so some of the A queries are canceled due to recursion
quota). The attack wouldn't be easy, though.
```
diff --git a/bind-9.16/bin/plugins/filter-aaaa.c b/bind-9.16/bin/plugins/filter-aaaa.c
index e787b43..fee2847 100644
--- a/bind-9.16/bin/plugins/filter-aaaa.c
+++ b/bind-9.16/bin/plugins/filter-aaaa.c
@@ -790,6 +790,7 @@ filter_respond_begin(void *arg, void *cbdata, isc_result_t *resp) {
qctx->client->query.attributes |=
NS_QUERYATTR_RECURSING;
}
+ ns_query_cancel(qctx->client); /* XXX for testing */
}
} else if (qctx->qtype == dns_rdatatype_a &&
(client_state->flags & FILTER_AAAA_RECURSING) != 0)
```
RT [#17073](https://support.isc.org/Ticket/Display.html?id=17073).October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2059Failed assertion during shutdown: REQUIRE(VALID_NMHANDLE(handle));2020-09-30T15:45:09ZMichał KępieńFailed assertion during shutdown: REQUIRE(VALID_NMHANDLE(handle));https://gitlab.isc.org/isc-projects/bind9/-/jobs/1046503
```
D:shutdown:Program terminated with signal SIGABRT, Aborted.
D:shutdown:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:shutdown:[Current thread is ...https://gitlab.isc.org/isc-projects/bind9/-/jobs/1046503
```
D:shutdown:Program terminated with signal SIGABRT, Aborted.
D:shutdown:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:shutdown:[Current thread is 1 (Thread 0x7fd36f2b6700 (LWP 14624))]
D:shutdown:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:shutdown:#1 0x00007fd37dd81535 in __GI_abort () at abort.c:79
D:shutdown:#2 0x0000557fb2e42397 in assertion_failed (file=<optimized out>, line=<optimized out>, type=isc_assertiontype_require, cond=<optimized out>) at main.c:254
D:shutdown:#3 0x00007fd37eb9043c in isc_assertion_failed (file=file@entry=0x7fd37ebc6e9b "netmgr/netmgr.c", line=line@entry=1129, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7fd37ebc3060 "((__builtin_expect(!!((handle) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(handle))->magic == ((('N') << 24 | ('M') << 16 | ('H') << 8 | ('D')))), 1)) && ({ typeof((&(handle)->r"...) at assertions.c:46
D:shutdown:#4 0x00007fd37eb733a8 in isc_nmhandle_ref (handle=<optimized out>) at netmgr/netmgr.c:1131
D:shutdown:#5 0x0000557fb2e3ffb1 in control_command (task=<optimized out>, event=<optimized out>) at controlconf.c:364
D:shutdown:#6 0x00007fd37ebb331f in dispatch (threadid=<optimized out>, manager=0x557fb40743a0) at task.c:1152
D:shutdown:#7 run (queuep=<optimized out>) at task.c:1344
D:shutdown:#8 0x00007fd37e31bfa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
D:shutdown:#9 0x00007fd37de584cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
This is more than likely yet another manifestation of reference counting
issues introduced by !3724. Perhaps a fix for one of the related issues
(#2036, #2047, #2052, #2057) will make this one go away, but I decided
to open a separate issue nevertheless to keep track of all the distinct
crashes just to make sure we get all of them sorted out in due time.October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/2057Hangs on shutdown with netmgr-based rndc (reference counting glitch?)2021-04-28T09:31:28ZMichal NowakHangs on shutdown with netmgr-based rndc (reference counting glitch?)The `dnstap` test [fails](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1044433#L7898) 50 % of time on FreeBSD 12.1:
```
S:dnstap:2020-07-29T15:32:53+0200
T:dnstap:1:A
A:dnstap:System test dnstap
I:dnstap:PORTS:5421,5422,5423,5424,542...The `dnstap` test [fails](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1044433#L7898) 50 % of time on FreeBSD 12.1:
```
S:dnstap:2020-07-29T15:32:53+0200
T:dnstap:1:A
A:dnstap:System test dnstap
I:dnstap:PORTS:5421,5422,5423,5424,5425,5426,5427,5428,5429,5430
I:dnstap:starting servers
I:dnstap:checking that named-checkconf detects error in bad-fstrm-reopen-interval.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-buffer-hint-max.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-buffer-hint-min.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-flush-timeout-max.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-flush-timeout-min.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-input-queue-size-max.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-input-queue-size-min.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-input-queue-size-po2.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-output-notify-threshold.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-output-queue-size-max.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-output-queue-size-min.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-reopen-interval-max.conf
I:dnstap:checking that named-checkconf detects error in bad-fstrm-set-reopen-interval-min.conf
I:dnstap:checking that named-checkconf detects error in bad-missing-dnstap-output-view.conf
I:dnstap:checking that named-checkconf detects error in bad-missing-dnstap-output.conf
I:dnstap:checking that named-checkconf detects error in bad-size-version.conf
I:dnstap:checking that named-checkconf detects no error in good-dnstap-in-options.conf
I:dnstap:checking that named-checkconf detects no error in good-dnstap-in-view.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-reopen-interval.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-buffer-hint.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-flush-timeout.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-input-queue-size.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-output-notify-threshold.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-output-queue-model-mpsc.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-output-queue-model-spsc.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-output-queue-size.conf
I:dnstap:checking that named-checkconf detects no error in good-fstrm-set-reopen-interval.conf
I:dnstap:checking that named-checkconf detects no error in good-size-unlimited.conf
I:dnstap:checking that named-checkconf detects no error in good-size-version.conf
I:dnstap:wait for servers to finish loading
I:dnstap:checking initial message counts
I:dnstap:checking UDP message counts
I:dnstap:checking TCP message counts
I:dnstap:checking AUTH_QUERY message counts
I:dnstap:checking AUTH_RESPONSE message counts
I:dnstap:checking CLIENT_QUERY message counts
I:dnstap:checking CLIENT_RESPONSE message counts
I:dnstap:checking RESOLVER_QUERY message counts
I:dnstap:checking RESOLVER_RESPONSE message counts
I:dnstap:checking UPDATE_QUERY message counts
I:dnstap:checking UPDATE_RESPONSE message counts
I:dnstap:checking reopened message counts
dnstap-read: dns_dt_openfile: failure
dnstap-read: dns_dt_openfile: failure
dnstap-read: dns_dt_openfile: failure
dnstap-read: dns_dt_openfile: failure
dnstap-read: dns_dt_openfile: failure
dnstap-read: dns_dt_openfile: failure
dnstap-read: dns_dt_openfile: failure
dnstap-read: dns_dt_openfile: failure
dnstap-read: dns_dt_openfile: failure
dnstap-read: dns_dt_openfile: failure
I:dnstap:checking UDP message counts
I:dnstap:ns3 0 expected 2
I:dnstap:failed
I:dnstap:checking TCP message counts
I:dnstap:checking AUTH_QUERY message counts
I:dnstap:checking AUTH_RESPONSE message counts
I:dnstap:checking CLIENT_QUERY message counts
I:dnstap:ns3 0 expected 1
I:dnstap:failed
I:dnstap:checking CLIENT_RESPONSE message counts
I:dnstap:ns3 0 expected 1
I:dnstap:failed
I:dnstap:checking RESOLVER_QUERY message counts
I:dnstap:checking RESOLVER_RESPONSE message counts
I:dnstap:checking UPDATE_QUERY message counts
I:dnstap:checking UPDATE_RESPONSE message counts
I:dnstap:checking dnstap-read hex output
dnstap-read: dns_dt_openfile: failure
I:dnstap:failed
I:dnstap:checking unix socket message counts
I:dnstap:checking UDP message counts
I:dnstap:checking TCP message counts
I:dnstap:checking AUTH_QUERY message counts
I:dnstap:checking AUTH_RESPONSE message counts
I:dnstap:checking CLIENT_QUERY message counts
I:dnstap:checking CLIENT_RESPONSE message counts
I:dnstap:checking RESOLVER_QUERY message counts
I:dnstap:checking RESOLVER_RESPONSE message counts
I:dnstap:checking UPDATE_QUERY message counts
I:dnstap:checking UPDATE_RESPONSE message counts
I:dnstap:checking reopened unix socket message counts
I:dnstap:checking UDP message counts
I:dnstap:checking TCP message counts
I:dnstap:checking AUTH_QUERY message counts
I:dnstap:checking AUTH_RESPONSE message counts
I:dnstap:checking CLIENT_QUERY message counts
I:dnstap:checking CLIENT_RESPONSE message counts
I:dnstap:checking RESOLVER_QUERY message counts
I:dnstap:checking RESOLVER_RESPONSE message counts
I:dnstap:checking UPDATE_QUERY message counts
I:dnstap:checking UPDATE_RESPONSE message counts
I:dnstap:checking large packet printing
I:dnstap:checking 'rndc -roll <value>' (no versions)
I:dnstap:no response from ns3
I:dnstap:failed
I:dnstap:ns3 didn't die when sent a SIGTERM
rndc: connect failed: 10.53.0.3#5430: connection refused
I:dnstap:failed
I:dnstap:checking 'rndc -roll <value>' (versions)
I:dnstap:exit status: 5
I:dnstap:stopping servers
I:dnstap:ns3 died before a SIGTERM was sent
I:dnstap:stopping servers failed
I:dnstap:Core dump(s) found: dnstap/ns3/named.core
D:dnstap:backtrace from dnstap/ns3/named.core:
D:dnstap:--------------------------------------------------------------------------------
D:dnstap:Core was generated by `/usr/home/newman/bind9/bin/named/.libs/named -D dnstap-ns3 -X named.lock -m reco'.
D:dnstap:Program terminated with signal SIGABRT, Aborted.
D:dnstap:#0 0x0000000800e7793a in _nanosleep () from /lib/libc.so.7
D:dnstap:[Current thread is 1 (LWP 100491)]
D:dnstap:#0 0x0000000800e7793a in _nanosleep () from /lib/libc.so.7
D:dnstap:#1 0x0000000800d0f11c in ?? () from /lib/libthr.so.3
D:dnstap:#2 0x0000000800ecd356 in usleep () from /lib/libc.so.7
D:dnstap:#3 0x00000008002e65fa in isc_nm_destroy (mgr0=0x2740b0 <named_g_nm>) at netmgr/netmgr.c:422
D:dnstap:#4 0x000000000023884e in destroy_managers () at main.c:970
D:dnstap:#5 cleanup () at main.c:1304
D:dnstap:#6 main (argc=<optimized out>, argv=0x7fffffffda50) at main.c:1561
D:dnstap:--------------------------------------------------------------------------------
D:dnstap:full backtrace from dnstap/ns3/named.core saved in named.core-backtrace.txt
D:dnstap:core dump dnstap/ns3/named.core archived as dnstap/ns3/named.core.gz
R:dnstap:FAIL
E:dnstap:2020-07-29T15:35:09+0200
FAIL dnstap (exit status: 1)
```
(If the framework can't stop the server `ABRT` is sent, hence the backtrace.)
NS3 `named.run` file: [named.run](/uploads/a447239a4552585a689ddbe22a003ee8/named.run)
Git bisect says that 3551d3ffd2afe6542e79a5571b326bd77fdd265e is the culprit:
```
3551d3ffd2afe6542e79a5571b326bd77fdd265e is the first bad commit
commit 3551d3ffd2afe6542e79a5571b326bd77fdd265e
Author: Evan Hunt <each@isc.org>
Date: Thu Apr 16 13:06:42 2020 -0700
convert rndc and control channel to use netmgr
```October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/2052Failed assertion during shutdown: INSIST(VALID_CCMSG(ccmsg));2020-09-30T06:26:50ZMichał KępieńFailed assertion during shutdown: INSIST(VALID_CCMSG(ccmsg));Example occurrence:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/1036796
```
D:shutdown:Program terminated with signal SIGABRT, Aborted.
D:shutdown:#0 0xf7eea069 in __kernel_vsyscall ()
D:shutdown:[Current thread is 1 (Thread 0xee...Example occurrence:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/1036796
```
D:shutdown:Program terminated with signal SIGABRT, Aborted.
D:shutdown:#0 0xf7eea069 in __kernel_vsyscall ()
D:shutdown:[Current thread is 1 (Thread 0xeea72b40 (LWP 14438))]
D:shutdown:#0 0xf7eea069 in __kernel_vsyscall ()
D:shutdown:#1 0xf75038e2 in __libc_signal_restore_set (set=0xeea6e6bc) at ../sysdeps/unix/sysv/linux/internal-signals.h:84
D:shutdown:#2 __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
D:shutdown:#3 0xf74ec309 in __GI_abort () at abort.c:79
D:shutdown:#4 0x565963ef in assertion_failed (file=0xf7c18598 "ccmsg.c", line=48, type=isc_assertiontype_insist, cond=0xf7c18478 "(__builtin_expect(!!((ccmsg) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(ccmsg))->magic == ((('C') << 24 | ('C') << 16 | ('m') << 8 | ('s')))), 1))") at main.c:253
D:shutdown:#5 0xf7e99662 in isc_assertion_failed (file=0xf7c18598 "ccmsg.c", line=48, type=isc_assertiontype_insist, cond=0xf7c18478 "(__builtin_expect(!!((ccmsg) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(ccmsg))->magic == ((('C') << 24 | ('C') << 16 | ('m') << 8 | ('s')))), 1))") at assertions.c:46
D:shutdown:#6 0xf7c15bc9 in recv_data (handle=0xdbe894e0, eresult=20, region=0x0, arg=0xdbe89618) at ccmsg.c:102
D:shutdown:#7 0xf7e8420a in isc__nm_tcp_shutdown (sock=0xe15c1570) at netmgr/tcp.c:1094
D:shutdown:#8 0xf7e7e6b9 in shutdown_walk_cb (handle=0xe15c1634, arg=0x0) at netmgr/netmgr.c:1451
D:shutdown:#9 0xf74a6bea in uv_walk () from /usr/lib/i386-linux-gnu/libuv.so.1
D:shutdown:#10 0xf7e802bf in isc__nm_async_shutdown (worker=0x56d50a6c, ev0=0xe1939b58) at netmgr/netmgr.c:1461
D:shutdown:#11 0xf7e81ab6 in process_queue (worker=worker@entry=0x56d50a6c, queue=0xf113a380) at netmgr/netmgr.c:640
D:shutdown:#12 0xf7e81e02 in async_cb (handle=0x56d50c44) at netmgr/netmgr.c:580
D:shutdown:#13 0xf74a79fb in ?? () from /usr/lib/i386-linux-gnu/libuv.so.1
D:shutdown:#14 0xf74b9de8 in ?? () from /usr/lib/i386-linux-gnu/libuv.so.1
D:shutdown:#15 0xf74a820e in uv_run () from /usr/lib/i386-linux-gnu/libuv.so.1
D:shutdown:#16 0xf7e81b26 in nm_thread (worker0=<optimized out>) at netmgr/netmgr.c:484
D:shutdown:#17 0xf76bb082 in start_thread (arg=<optimized out>) at pthread_create.c:479
D:shutdown:#18 0xf75d0f86 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108
```
@each [strongly believes][1] this can only happen as a result of an
`rndc stop` or `rndc halt`.
I am marking this only with ~v9.17 as it looks like an artifact of
migrating `rndc` to netmgr.
Pinging @wpk as well without assigning anyone to the issue for the time
being.
[1]: https://mattermost.isc.org/isc/pl/3kemx93nofypmgg49o1a343x4cOctober 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2031Windows crashes with netmgr-based statschannel2020-07-27T21:33:09ZMichał KępieńWindows crashes with netmgr-based statschannelThe following crash happened in the `statistics` system test for both
Windows builds (Release and Debug) in a [pipeline][1] run for
f27c0c32572aad530514700ab2033f20c897c3f4:
```
16-Jul-2020 21:34:32.694 c:\builds\isc-projects\bind9\lib\...The following crash happened in the `statistics` system test for both
Windows builds (Release and Debug) in a [pipeline][1] run for
f27c0c32572aad530514700ab2033f20c897c3f4:
```
16-Jul-2020 21:34:32.694 c:\builds\isc-projects\bind9\lib\isc\buffer.c:76: REQUIRE((((b) != ((void *)0)) && (((const isc__magic_t *)(b))->magic == (0x42756621U)))) failed
```
Given that:
- I have not seen such crashes before,
- a pipeline ran for d8e6b32a18e6d4cc17830af237c00899de1c4912 did not
trigger these crashes,
- the only code-related MR merged between the last successful pipeline
and the first crashing one was !3847,
there is a fair chance that !3847 introduced a Windows-specific bug (or
a generic one that is simply easier to trigger on Windows).
@each: assigning you as the author for !3847, please take a look.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/pipelines/46984August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1978Cross-compilation doesn’t work in 9.172021-01-07T02:49:43ZOndřej SurýCross-compilation doesn’t work in 9.17The `gen` and `cfg_gen` miss the `BUILD` specification, it’s build with `HOST` cc.The `gen` and `cfg_gen` miss the `BUILD` specification, it’s build with `HOST` cc.January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1942[v9_11] TCP performance on FreeBSD much lower than on Linux2021-01-07T21:03:15ZMichal Nowak[v9_11] TCP performance on FreeBSD much lower than on LinuxBIND 9.11.20 and 9.11.19 (and probably older versions too) on a FreeBSD 12.1 (in a VM) has about a half of TCP query performance of Linux.
The [stress test](https://gitlab.isc.org/isc-private/bind-qa/-/tree/master/bind9/stress) executes...BIND 9.11.20 and 9.11.19 (and probably older versions too) on a FreeBSD 12.1 (in a VM) has about a half of TCP query performance of Linux.
The [stress test](https://gitlab.isc.org/isc-private/bind-qa/-/tree/master/bind9/stress) executes four instances of Flamethrower: UDP IPv6, UDP IPv4, TCP IPv6, and TCP IPv4. Knowing that each TCP Flamethrower runs with 30 concurrent generators, each sending 100 queries every 1000 ms we can calculate number of expected TCP queries processed by BIND. If at least 90 % of this target is processed, the test is considered pass.
This test does pass on Linux (Fedora 32) but fails on FreeBSD 12.1. Some difference can be accounted to difference between these two environments as the former is a bare metal, the latter a KVM VM. (But still this test passes on 9.16.3 on FreeBSD 12.1.)
**9.16.3: Stress test (FreeBSD 12.1 / recursive / 1 hour)**
```
INFO: Recursive server 'ns3' received 21066269 TCP queries
INFO: About 21600000 TCP queries were expected
INFO: Minimum number of TCP queries required to pass is 19440000
INFO: BIND processed enough TCP queries
```
**9.11.20: Stress test (Fedora 32 / recursive / 1 hour)**
```
INFO: Recursive server 'ns3' received 21257316 TCP queries
INFO: About 21600000 TCP queries were expected
INFO: Minimum number of TCP queries required to pass is 19440000
INFO: BIND processed enough TCP queries
```
**9.11.20: Stress test (FreeBSD 12.1 / recursive / 12 hour)**
```
INFO: Recursive server 'ns3' received 136973904 TCP queries
INFO: About 259200000 TCP queries were expected
INFO: Minimum number of TCP queries required to pass is 233280000
ERROR: BIND did not process enough TCP queries
```
This is similar but believed to be different to https://gitlab.isc.org/isc-projects/bind9/-/issues/1941.January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)https://gitlab.isc.org/isc-projects/bind9/-/issues/1939kasp system test intermittent test failures for "rumoured.kasp" zone2020-07-03T16:24:36ZMichał Kępieńkasp system test intermittent test failures for "rumoured.kasp" zoneSome checks recently added to the `kasp` system test fail very often as
they do not tolerate certain events taking more than 1 second to happen:
```
I:kasp:check key timing metadata for key KEY1 id 49258 zone rumoured.kasp (110)
I:kasp:...Some checks recently added to the `kasp` system test fail very often as
they do not tolerate certain events taking more than 1 second to happen:
```
I:kasp:check key timing metadata for key KEY1 id 49258 zone rumoured.kasp (110)
I:kasp:check key timing metadata for key KEY2 id 10506 zone rumoured.kasp (111)
I:kasp:check key timing metadata for key KEY3 id 25185 zone rumoured.kasp (112)
I:kasp:error: mismatch publish comment in ns3/Krumoured.kasp.+005+25185.key (expected 20200615091205)
I:kasp:error: mismatch publish in ns3/Krumoured.kasp.+005+25185.private (expected 20200615091205)
I:kasp:error: mismatch publish in ns3/Krumoured.kasp.+005+25185.state (expected 20200615091205)
I:kasp:error: mismatch active comment in ns3/Krumoured.kasp.+005+25185.key (expected 20200616091205)
I:kasp:error: mismatch active in ns3/Krumoured.kasp.+005+25185.private (expected 20200616091205)
I:kasp:error: mismatch active in ns3/Krumoured.kasp.+005+25185.state (expected 20200616091205)
I:kasp:error: mismatch retired comment in ns3/Krumoured.kasp.+005+25185.key (expected 20210616091205)
I:kasp:error: mismatch retired in ns3/Krumoured.kasp.+005+25185.private (expected 20210616091205)
I:kasp:error: mismatch retired in ns3/Krumoured.kasp.+005+25185.state (expected 20210616091205)
I:kasp:error: mismatch removed comment in ns3/Krumoured.kasp.+005+25185.key (expected 20210626101705)
I:kasp:error: mismatch removed in ns3/Krumoured.kasp.+005+25185.private (expected 20210626101705)
I:kasp:error: mismatch removed in ns3/Krumoured.kasp.+005+25185.state (expected 20210626101705)
I:kasp:failed
```
Meanwhile, in the artifacts:
```
$ cat bin/tests/system/kasp/ns3/Krumoured.kasp.+005+25185.key
; This is a zone-signing key, keyid 25185, for rumoured.kasp.
; Created: 20200615091204 (Mon Jun 15 09:12:04 2020)
; Publish: 20200615091204 (Mon Jun 15 09:12:04 2020)
; Activate: 20200616091204 (Tue Jun 16 09:12:04 2020)
; Inactive: 20210616091204 (Wed Jun 16 09:12:04 2021)
; Delete: 20210626101704 (Sat Jun 26 10:17:04 2021)
rumoured.kasp. 1234 IN DNSKEY 256 3 5 AwEAAbmPnkXcnAF0iTlpP57eQnoDD05ldTahTcUkOUVaeRqF1gSpYYU6 zp9mQrmYty57kLYe7EuG6xbPHIK2DT+7sAQxGM+J+oFLxFKkxCQE+Cm6 ubhaZZ5sbBpwQMy06iuZFJ3pNFT2Q1FzIz4zCjqbnupySShsC34SsvGT zgExa/73Jy9f7k8/8JT12mbcNYByamiSnvHzMTdyqGA/jiruRPRApgYG +Gh+nS0inf5r9pX/rzu54XrZ/n8CNYAYvp2wWgIO6uWJvDgj2oszgKn4 HUTsS/x6hu+CHiFeSOZPAyW2fXVRUTqARnDzLedyupO3WNgRVipBtE/X iwE=
```
Example instances of this failure mode taken from just one pipeline:
- https://gitlab.isc.org/isc-private/bind9/-/jobs/953093
- https://gitlab.isc.org/isc-private/bind9/-/jobs/953097
- https://gitlab.isc.org/isc-private/bind9/-/jobs/953103July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1871RNDC command to dump stats2023-05-31T11:52:38ZVicky Riskvicky@isc.orgRNDC command to dump statsWe have a request, from a resolver operator, to be able to issue an rndc command to dump a file of statistics in some format that can be imported and processed by Prometheus. I think the use case is, the node might be in a remote pop wit...We have a request, from a resolver operator, to be able to issue an rndc command to dump a file of statistics in some format that can be imported and processed by Prometheus. I think the use case is, the node might be in a remote pop with limited connectivity and setting up on-going streaming may be difficult for some reason, or perhaps there isn't the access for that.
entered on behalf of cmosher@quad9.netBIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1869tsig-confgen dumps core2021-10-05T12:25:35ZMichal Nowaktsig-confgen dumps core`tsig-confgen` from BIND `master` (6f576b2c184c3ffdae7ecbea5f7cb40e6d302b0d) dumps core on CentOS 8:
```
$ gdb tsig-confgen
...
(gdb) continue
Continuing.
warning: Loadable section ".note.gnu.property" outside of ELF segments
ddns-confg...`tsig-confgen` from BIND `master` (6f576b2c184c3ffdae7ecbea5f7cb40e6d302b0d) dumps core on CentOS 8:
```
$ gdb tsig-confgen
...
(gdb) continue
Continuing.
warning: Loadable section ".note.gnu.property" outside of ELF segments
ddns-confgen.c:133: INSIST(0) failed, back trace
/lib64/libisc.so.1701(+0x2e5c3) [0x7ffff7b8c5c3]
/lib64/libisc.so.1701(isc_assertion_failed+0xa) [0x7ffff7b8c537]
/usr/sbin/tsig-confgen() [0x4014ed]
/lib64/libc.so.6(__libc_start_main+0xf3) [0x7ffff558c873]
/usr/sbin/tsig-confgen() [0x40125e]
Program received signal SIGABRT, Aborted.
0x00007ffff55a08df in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install libgcc-8.3.1-4.5.el8.x86_64
(gdb) thread apply all bt full
Thread 1 (Thread 0x7ffff7fe10c0 (LWP 4396)):
#0 0x00007ffff55a08df in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007ffff558acf5 in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x00007ffff7b8c53c in isc_assertion_failed (file=file@entry=0x402794 "ddns-confgen.c", line=line@entry=133, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x402792 "0") at assertions.c:47
No locals.
#3 0x00000000004014ed in main (argc=1, argv=0x7fffffffd998) at ddns-confgen.c:133
result = <optimized out>
show_final_mem = false
quiet = false
key_txtbuffer = {magic = 0, base = 0x0, length = 255, used = 0, current = 4096, active = 0, link = {prev = 0x1020, next = 0x0}, mctx = 0x0, autore = 221}
key_txtsecret = "\000\000\000\000\000\000\000\000\067\351^\365\377\177\000\000 \020\000\000\000\000\000\000\020\000\000\000\000\000\000\000\243\220x\364\377\177\000\000\230\331\377\377\377\177\000\000\250\331\377\377\377\177\000\000\256$_\365\377\177\000\000\243\220x\364\377\177\000\000\243\220x\364\377\177\000\000\000\000\000\000\000\000\000\000n\fw\364\377\177\000\000\000\020\000\000\000\000\000\000\000\020", '\000' <repeats 63 times>, "\020\000\000\000\000\000\000\377", '\000' <repeats 31 times>...
mctx = 0x0
keyname = 0x0
zone = 0x0
self_domain = 0x0
keybuf = 0x0
alg = 163 '\243'
algname = <optimized out>
keysize = 256
len = 0
ch = <optimized out>
```BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1867Fix the system tests on Windows2020-07-14T12:50:33ZOndřej SurýFix the system tests on WindowsNow, that the BIND 9 builds on Windows again, we need to fix the system tests:
```
$ & sh.exe runall.sh $TEST_PARALLEL_JOBS
/bin/bash: ./run.sh: No such file or directory
[...]
/bin/bash: ./run.sh: No such file or directory
I:System test...Now, that the BIND 9 builds on Windows again, we need to fix the system tests:
```
$ & sh.exe runall.sh $TEST_PARALLEL_JOBS
/bin/bash: ./run.sh: No such file or directory
[...]
/bin/bash: ./run.sh: No such file or directory
I:System test result summary:
I:Found 0 test results, but 95 tests were run
```June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1849CIDR rejected by 9.11.18 and higher2023-03-21T19:04:05ZWilliam D ColburnCIDR rejected by 9.11.18 and higher<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
ondrej@isc.org requested I file this as a regression rather than a feature drop. We have a very old setup that did something clever with CIDR notation. The two CIDRs we use are 10.80.201.0/19 and 10.80.211.0/19 which (as I understand it) covers a range of addresses in 5 class C networks that need access. Making changes is hard, and it was requested that we not change how this works during the pandemic. But the new secretiive bug announcement makes me worry that this is important and we should stop lurking at 9.11.7. When I wrote the email I assumed that the CIDR change had gone from warning to error.
My original email:
```
> On 14 May 2020, at 15:03, William D. Colburn <wcolburn@nrao.edu> wrote:
>
> That this upcoming security announcement is pre-announced makes me worry
> that it is very imporant, and not one we can ignore. Not that we should
> have ignored the last four either, but changes like this are hard.
>
> BIND stopped working for us at 9.11.8, and because of the intricacies of
> making massive changes to our infrastructure, we have been sitting at
> 9.11.7 for quite a while. The problem we have is that you deprecated
> support for legacy CIDR, and our configuration is now invalid. No one
> wants to attempt any changes to the BIND config right now because we are
> in an infectous disease status and almost no one is at work.
>
> The CIDRs in question are 10.80.201.0/19, and 10.80.211.0/19, which we
> use to control access of special hardware across a range of IP
> addresses. It's a "clever" solution, and clever is never really a good
> idea, but it has been in place for more than a decade. The official
> request was not to change those during this pandemic. Unfortunately,
> the system serving these systems is also the system public-facing to the
> internet.
>
> Is there something I can do when compiling this new bind to make CIDR
> notation work again, as in an option at compile time?
>
> --Schlake
```
### BIND version used
WORKS:
```
root@anotheruvula</home/anotheruvula/services/named># bind-9.11.7/*/named -V
BIND 9.11.7 (Extended Support Version) <id:084ef47>
running on Linux x86_64 3.10.0-957.21.3.el7.x86_64 #1 SMP Fri Jun 14 02:54:29 EDT 2019
built by make with '--disable-openssl-version-check' '--prefix=/opt/services/named/bind-9.11.7' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-ipv6' '--with-openssl=yes'
compiled by GCC 4.4.7 20120313 (Red Hat 4.4.7-18)
compiled with OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
linked to OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
compiled with libxml2 version: 2.7.6
linked to libxml2 version: 20901
compiled with zlib version: 1.2.3
linked to zlib version: 1.2.7
threads support is enabled
```
FAILS:
```
root@anotheruvula</home/anotheruvula/services/named># bind-9.11.18/*/named -V
BIND 9.11.18 (Extended Support Version) <id:bc6c00f>
running on Linux x86_64 3.10.0-957.21.3.el7.x86_64 #1 SMP Fri Jun 14 02:54:29 EDT 2019
built by make with '--disable-openssl-version-check' '--prefix=/opt/services/named/bind-9.11.18' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-ipv6' '--with-openssl=yes'
compiled by GCC 4.4.7 20120313 (Red Hat 4.4.7-23)
compiled with OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
linked to OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
compiled with libxml2 version: 2.7.6
linked to libxml2 version: 20901
compiled with zlib version: 1.2.3
linked to zlib version: 1.2.7
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/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
```
allow-update {
10.80.201.0/19;
10.80.211.0/19;
}
```
### What is the current *bug* behavior?
The named exits without starting.
syslog errors:
```
May 14 11:54:15 anotheruvula named[9737]: /etc/named.conf:518: '10.80.201.0/19': address/prefix length mismatch '19'
May 14 11:54:15 anotheruvula named[9737]: loading configuration: failure
May 14 11:54:15 anotheruvula named[9737]: exiting (due to fatal error)
```
### What is the expected *correct* behavior?
I'd expect no error, but for many versions I got this warning:
```
May 14 11:54:31 anotheruvula named[9781]: /etc/named.conf:518: '10.80.201.0/19': address/prefix length mismatch
May 14 11:54:31 anotheruvula named[9781]: /etc/named.conf:519: '10.80.211.0/19': address/prefix length mismatch
```
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
Just the allow-update is needed, as above.
```
allow-update {
10.80.201.0/19;
10.80.211.0/19;
}
```
### Relevant logs and/or screenshots
```
May 14 11:54:31 anotheruvula named[9781]: /etc/named.conf:518: '10.80.201.0/19': address/prefix length mismatch
May 14 11:54:31 anotheruvula named[9781]: /etc/named.conf:519: '10.80.211.0/19': address/prefix length mismatch
```
and
```
May 14 11:54:15 anotheruvula named[9737]: /etc/named.conf:518: '10.80.201.0/19': address/prefix length mismatch '19'
May 14 11:54:15 anotheruvula named[9737]: loading configuration: failure
May 14 11:54:15 anotheruvula named[9737]: exiting (due to fatal error)
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1838Integrate RFC compliance list into ARM on RTD2020-11-12T00:25:37ZVicky Riskvicky@isc.orgIntegrate RFC compliance list into ARM on RTDWe have a request to publish a list of supported RFCs.
I know this is very difficult to do with extreme accuracy, but we do have a list at a reasonable level of accuracy (https://gitlab.isc.org/isc-projects/bind9/-/blob/master/doc/misc/...We have a request to publish a list of supported RFCs.
I know this is very difficult to do with extreme accuracy, but we do have a list at a reasonable level of accuracy (https://gitlab.isc.org/isc-projects/bind9/-/blob/master/doc/misc/rfc-compliance) but this is not incorporated into the ARM.
This issue is to add an appendix to the ARM (in Sphinx at least) to include the rfc-compliance file, so I can link to it on the web site.BIND 9.17 BackburnerSuzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1837[ISC-support #14369] Considering changing ECS caching strategy or negative data2024-03-13T13:17:48ZBrian Conry[ISC-support #14369] Considering changing ECS caching strategy or negative dataCurrently our ECS implementation caches all negative responses at the global scope.
A customer has requested that we store them at the learned scope.
RFC 7871 (Informational only) section 7.4, paragraph 4 notes that the original spec w...Currently our ECS implementation caches all negative responses at the global scope.
A customer has requested that we store them at the learned scope.
RFC 7871 (Informational only) section 7.4, paragraph 4 notes that the original spec was ambiguous and hints that the interpretation of scoping negative answers is more likely to be used in future protocol specifications (if any) than caching them globally.
> This issue is expected to be revisited in a future revision of the protocol, possibly blessing the mixing of positive and negative answers. There are implications for cache data structures that developers should consider when writing new ECS code.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1751abi-check does not know which source is older, newer2020-04-29T12:11:59ZMichal Nowakabi-check does not know which source is older, newerWe are not bumping the API version number compared to the reference version, so this results in abi-checker being unable to discern which version is "older" and which one is "newer". As a result, it uses git commit hashes to tell them ap...We are not bumping the API version number compared to the reference version, so this results in abi-checker being unable to discern which version is "older" and which one is "newer". As a result, it uses git commit hashes to tell them apart. In case of https://gitlab.isc.org/isc-projects/bind9/-/jobs/814076 current `HEAD` of `v9_16` to be treated as "old":
```
Report: compat_reports/libns/1601.0.0-2c0adf7e5a_to_1601.0.0-d497c325e7/compat_report.html
```
```
commit d497c325e70400f082bf59f61430e3f20a708d0d
Author: Tinderbox User <tbox@isc.org>
Date: Wed Mar 11 16:35:45 2020 +0000
commit 2c0adf7e5abf1ad7932eb845e7dce9231e505d45
Merge: e11d690ae7 ad79e7c080
Author: Ondřej Surý <ondrej@isc.org>
Date: Wed Apr 8 15:13:10 2020 +0000
```May 2020 (9.11.19, 9.11.19-S1, 9.14.12, 9.16.3)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1740The gssapi and krb5 headers polute the public API2021-03-22T11:02:58ZOndřej SurýThe gssapi and krb5 headers polute the public APIThe GSSAPI usage currently exports the gssapi.h headers to the public API of libdns. The use of GSSAPI and KRB5 needs to become opaque, so it does not polute the libdns public API, so there's no need to include the headers in downstream...The GSSAPI usage currently exports the gssapi.h headers to the public API of libdns. The use of GSSAPI and KRB5 needs to become opaque, so it does not polute the libdns public API, so there's no need to include the headers in downstream users of the library.March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1699Test building DLZ modules in CI2023-10-23T12:28:54ZMichał KępieńTest building DLZ modules in CIOver the past few years, we have received reports about a number of DLZ module build issues caused by changes introduced in recent BIND versions. We should test building DLZ modules CI to catch such issues in advance; I think running su...Over the past few years, we have received reports about a number of DLZ module build issues caused by changes introduced in recent BIND versions. We should test building DLZ modules CI to catch such issues in advance; I think running such tests on just one operating system would be more than enough?
We should probably first discuss whether the DLZ modules should be moved to a separate Git repository.https://gitlab.isc.org/isc-projects/bind9/-/issues/1640BIND 9.16.0 fails to build on FreeBSD 12.12020-02-28T14:30:07ZMichał KępieńBIND 9.16.0 fails to build on FreeBSD 12.1```
...
making all in /root/bind9/lib/isc/tests
/bin/sh /root/bind9/libtool --mode=link cc -g -O2 -pthread -I/usr/local/include -I /usr/local/include -fPIC -Wl,-E -o aes_test aes_test.lo ../libisc.la -L/usr/lib -lcrypto -L/usr/local/...```
...
making all in /root/bind9/lib/isc/tests
/bin/sh /root/bind9/libtool --mode=link cc -g -O2 -pthread -I/usr/local/include -I /usr/local/include -fPIC -Wl,-E -o aes_test aes_test.lo ../libisc.la -L/usr/lib -lcrypto -L/usr/local/lib -ljson-c -L/usr/local/lib -lxml2 -llmdb -L/usr/local/lib -luv -lrt -lpthread -ldl -L/usr/local/lib -L/usr/local/lib -lcmocka
libtool: link: cc -g -O2 -pthread -I/usr/local/include -I /usr/local/include -fPIC -Wl,-E -o .libs/aes_test .libs/aes_test.o ../.libs/libisc.so -L/usr/lib -L/usr/local/lib -lcrypto -ljson-c -lxml2 -llmdb -luv -lrt -lpthread -ldl -lcmocka -pthread -Wl,-rpath -Wl,/usr/local/lib
ld: error: ../.libs/libisc.so: undefined reference to deflate
ld: error: ../.libs/libisc.so: undefined reference to deflateEnd
ld: error: ../.libs/libisc.so: undefined reference to deflateInit_
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1
```
The problem only affects libtool builds. Everything worked fine on FreeBSD 12.0.
Interestingly enough, the problem goes away on FreeBSD 12.1 when `-ldl` is removed from the command line - which makes me think we only started hitting this problem now due to some recent change in FreeBSD's libdl (or in the C toolchain?). However, I do not think `-ldl` can be removed from the command line because `pkgconf --libs libuv` adds it and BIND 9.16+ cannot be built without libuv.March 2020 (9.11.17, 9.16.1, 9.17.0)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1607dig assertion failed on FreeBSD 12.12023-03-16T11:03:08ZMichal Nowakdig assertion failed on FreeBSD 12.1I have a FreeBSD 12.1 under KVM (6 vCPU, 8 G RAM), where -- similarly to https://gitlab.isc.org/isc-projects/bind9/issues/1604 and https://gitlab.isc.org/isc-projects/bind9/issues/1606 -- I triggered a core dump of `dig` by running syste...I have a FreeBSD 12.1 under KVM (6 vCPU, 8 G RAM), where -- similarly to https://gitlab.isc.org/isc-projects/bind9/issues/1604 and https://gitlab.isc.org/isc-projects/bind9/issues/1606 -- I triggered a core dump of `dig` by running system test under a tight loop (e.g. `while true; do make -j6 -k test V=1; done`) and pressed `Ctrl-C`.
I am afraid I have only this low-quality backtrace no more detailed backtrace, the core file, nor the `dig` binary:
```
#0 0x0000000800da145a in thr_kill () from /lib/libc.so.7
#1 0x0000000800d9f844 in raise () from /lib/libc.so.7
#2 0x0000000800d12079 in abort () from /lib/libc.so.7
#3 0x00000008006b633f in isc_assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>) at assertions.c:49
#4 0x00000008006d6ced in isc_task_attach (source0=<optimized out>, targetp=<optimized out>) at task.c:357
#5 0x00000008006e3f60 in socket_recv (sock=0x8011aa700, dev=0x80119c850, task=0x0, flags=0) at socket.c:3949
#6 0x00000008006e3ea1 in isc_socket_recv2 (sock0=0x18afa, region=<optimized out>, minimum=<optimized out>, task=<optimized out>, event=0x0, flags=0) at socket.c:4047
#7 0x00000008006e3d6e in isc_socket_recv (sock0=0x8011aa700, region=0x7fffdfffde68, minimum=0, task=0x0, action=<optimized out>, arg=<optimized out>) at socket.c:4018
#8 0x00000000002183c7 in launch_next_query (query=0x8011a9708, include_question=true) at dighost.c:3162
#9 0x000000000021899c in connect_done (task=<optimized out>, event=0x8011ab770) at dighost.c:3294
#10 0x00000008006da329 in dispatch (manager=0x80119d700, threadid=<optimized out>) at task.c:1150
#11 0x00000008006d84af in run (queuep=<optimized out>) at task.c:1340
#12 0x0000000800bcb776 in ?? () from /lib/libthr.so.3
#13 0x0000000000000000 in ?? ()
```https://gitlab.isc.org/isc-projects/bind9/-/issues/1589Intermittent kasp system test failure2020-03-09T08:22:40ZMatthijs Mekkingmatthijs@isc.orgIntermittent kasp system test failurehttps://gitlab.isc.org/isc-projects/bind9/-/jobs/608445https://gitlab.isc.org/isc-projects/bind9/-/jobs/608445February 2020 (9.11.16, 9.14.11, 9.16.0, 9.16.0-S)