BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-11-09T09:35:42Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4416ccmsg doesn't support multiple message read in the single TCP read2023-11-09T09:35:42ZDominik Thalhammerccmsg doesn't support multiple message read in the single TCP read### Summary
Sending multiple messages (without waiting for the previous responses to arrive) to bind via rndc causes messages to get lost/bind to loose sync on the stream.
### BIND version used
Docker image `ubuntu/bind9:9.18-22.04_be...### Summary
Sending multiple messages (without waiting for the previous responses to arrive) to bind via rndc causes messages to get lost/bind to loose sync on the stream.
### BIND version used
Docker image `ubuntu/bind9:9.18-22.04_beta`
```
BIND 9.18.12-0ubuntu0.22.04.3-Ubuntu (Extended Support Version) <id:>
running on Linux x86_64 6.2.0-36-generic #37~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Oct 9 15:34:04 UTC 2
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/bind9-B5s8Yi/bind9-9.18.12=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 11.4.0
compiled with OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
linked to OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
compiled with libuv version: 1.43.0
linked to libuv version: 1.43.0
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.43.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
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
linked to maxminddb version: 1.5.2
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
Send multiple requests via rndc in rapid succession. The particular program used to initially observe the issue is closed source and tightly integrated, however the following script using `bind9-rndc-node` experiences the same behaviour.
```js
var RNDC = require('bind9-rndc');
var key = 'BzDBJ1B/JbQg9iXJYAGZLQ==';
var session = RNDC.connect('172.17.0.2', 953, key, 'md5');
var test_count = 10;
var recv_count = 0;
session.on('ready', () => {
for(var i = 0; i < test_count; i++)
session.send('status');
});
session.on('data', (obj) => {
recv_count++;
console.log("Got " + recv_count);
console.log(obj);
});
session.on('error', console.log);
```
### What is the current *bug* behavior?
Bind correctly handles some of the requests but drops others. Depending on the message size and timing the indices of the recognized messages vary and sometimes bind looses track entirely until it drops the connection with a timeout.
### What is the expected *correct* behavior?
The number of responses is equal to the number of requests (the order can vary, thats what `_ser` is for) and the stream stays in sync, regardless of the timing when sending messages. If bind can not keep up with the client it should use the tcp blocking to signal this instead of dropping data.
### Relevant configuration files
named.conf
```
key "rndc-key" {
algorithm hmac-md5;
secret "BzDBJ1B/JbQg9iXJYAGZLQ==";
};
controls {
inet 0.0.0.0 allow { any; } keys { "rndc-key"; };
};
options {
directory "/var/cache/bind";
version none;
allow-query { any; };
allow-recursion { any; };
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { };
listen-on { any; };
};
```
### Relevant logs and/or screenshots
Sample output of script (note theres a rather long pause before `warning: unread...`):
```
(node:10142) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
Got 1
Map(0) {
type: 'status',
result: '0',
text: 'version: BIND 9.18.12-0ubuntu0.22.04.3-Ubuntu (Extended Support Version) <id:> (version.bind/txt/ch disabled)\n' +
'running on 54d01852d58b: Linux x86_64 6.2.0-36-generic #37~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Oct 9 15:34:04 UTC 2\n' +
'boot time: Sat, 04 Nov 2023 14:45:41 GMT\n' +
'last configured: Sat, 04 Nov 2023 14:45:41 GMT\n' +
'configuration file: /etc/bind/named.conf\n' +
'CPUs found: 16\n' +
'worker threads: 16\n' +
'UDP listeners per interface: 16\n' +
'number of zones: 101 (99 automatic)\n' +
'debug level: 0\n' +
'xfers running: 0\n' +
'xfers deferred: 0\n' +
'soa queries in progress: 0\n' +
'query logging is OFF\n' +
'recursive clients: 0/900/1000\n' +
'tcp clients: 0/150\n' +
'TCP high-water: 0\n' +
'server is up and running'
}
warning: unread data left over
```
Relevant log output for this transaction:
`04-Nov-2023 15:12:17.519 invalid command from 172.17.0.1#40764: timed out`
### Possible fixes
I am not familiar with the bind9 source code, but I will take a look if I can find something (along with retesting on the master branch).
A fix for clients is to ensure that there is never more than one message in flight. This fixes the issue, but vastly degrades performance if the latency between server and client is huge.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4414shutdown crash in control_recvmessage(): INSIST(!conn->shuttingdown)2023-12-06T18:25:29ZMichal Nowakshutdown crash in control_recvmessage(): INSIST(!conn->shuttingdown)Job [#3776566](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3776566) failed for 7d650fde89ab2306eaf520c10370ae7a45b6b640.
This is a `main` shutdown crash in `control_recvmessage()` of `bin/named/controlconf.c`: `INSIST(!conn->shutti...Job [#3776566](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3776566) failed for 7d650fde89ab2306eaf520c10370ae7a45b6b640.
This is a `main` shutdown crash in `control_recvmessage()` of `bin/named/controlconf.c`: `INSIST(!conn->shuttingdown);`.
```
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:Core was generated by `/builds/isc-projects/bind9/workspace/bin/named/.libs/named -c /builds/isc-proje'.
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:Program terminated with signal SIGABRT, Aborted.
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:Download failed: Invalid argument. Continuing without source file ./nptl/./nptl/pthread_kill.c.
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:[Current thread is 1 (Thread 0x7fdcd5101500 (LWP 377769))]
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:#1 0x00007fdcd7c42d9f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:#2 0x00007fdcd7bf3f32 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:#3 0x00007fdcd7bde472 in __GI_abort () at ./stdlib/abort.c:79
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:#4 0x0000564f929377b5 in assertion_failed (file=<optimized out>, line=410, type=isc_assertiontype_insist, cond=0x564f92972bf0 "!conn->shuttingdown") at /builds/isc-projects/bind9/bin/named/main.c:234
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:#5 0x00007fdcd8886649 in isc_assertion_failed (file=file@entry=0x564f929721e0 "/builds/isc-projects/bind9/bin/named/controlconf.c", line=line@entry=410, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x564f92972bf0 "!conn->shuttingdown") at /builds/isc-projects/bind9/lib/isc/assertions.c:48
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:#6 0x0000564f92933b05 in control_recvmessage (handle=<optimized out>, result=result@entry=ISC_R_SHUTTINGDOWN, arg=<optimized out>) at /builds/isc-projects/bind9/bin/named/controlconf.c:410
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:#7 0x0000564f92933f39 in shutdown_listener (listener=<optimized out>) at /builds/isc-projects/bind9/bin/named/controlconf.c:204
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:#8 0x0000564f9293411b in controls_shutdown (controls=controls@entry=0x7fdcd4c141a0) at /builds/isc-projects/bind9/bin/named/controlconf.c:642
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:#9 0x0000564f92934422 in named_controls_shutdown (controls=0x7fdcd4c141a0) at /builds/isc-projects/bind9/bin/named/controlconf.c:648
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:#10 0x0000564f929599de in shutdown_server (arg=0x7fdcd4c9f700) at /builds/isc-projects/bind9/bin/named/server.c:9896
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:#11 0x00007fdcd8886976 in isc__async_cb (handle=<optimized out>) at /builds/isc-projects/bind9/lib/isc/async.c:111
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:#12 0x00007fdcd8089749 in uv__async_io (loop=0x7fdcd4cae820, w=0x7fdcd4cae9e8, events=1) at /usr/src/libuv-v1.46.0/src/unix/async.c:176
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:#13 0x00007fdcd80a4f9b in uv__io_poll (loop=0x7fdcd4cae820, timeout=29999) at /usr/src/libuv-v1.46.0/src/unix/linux.c:1476
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:#14 0x00007fdcd808a62c in uv_run (loop=0x7fdcd4cae820, mode=UV_RUN_DEFAULT) at /usr/src/libuv-v1.46.0/src/unix/core.c:447
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:#15 0x00007fdcd8899b24 in loop_thread (arg=arg@entry=0x7fdcd4cae800) at /builds/isc-projects/bind9/lib/isc/loop.c:282
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:#16 0x00007fdcd88a89ba in thread_body (wrap=0x564f9304a1f0) at /builds/isc-projects/bind9/lib/isc/thread.c:85
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:#17 0x00007fdcd88a8a34 in isc_thread_main (func=func@entry=0x7fdcd8899a99 <loop_thread>, arg=0x7fdcd4cae800) at /builds/isc-projects/bind9/lib/isc/thread.c:116
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:#18 0x00007fdcd889a817 in isc_loopmgr_run (loopmgr=0x7fdcd4c696c0) at /builds/isc-projects/bind9/lib/isc/loop.c:454
2023-11-03 00:23:07 INFO:shutdown D:/builds/isc-projects/bind9/workspace/bin/tests/system/shutdown_tmp_f2a3q9qs:#19 0x0000564f9293a0ee in main (argc=<optimized out>, argv=<optimized out>) at /builds/isc-projects/bind9/bin/named/main.c:1574
```
[core.377769-backtrace.txt](/uploads/5e442072838418b35b9601d4c92aee5a/core.377769-backtrace.txt)
[named.run](/uploads/01a56e1fddc884569ab5c210b6718d8f/named.run)December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4413Add RESINFO (261) type to named2024-03-20T13:50:45ZMark AndrewsAdd RESINFO (261) type to namedIt's a singleton, TXT clone. https://datatracker.ietf.org/doc/draft-ietf-add-resolver-info/It's a singleton, TXT clone. https://datatracker.ietf.org/doc/draft-ietf-add-resolver-info/March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4412Question about response to ANY query2023-11-02T21:14:26ZAmauvpQuestion about response to ANY queryHello, I'm a student in the Master in Cybersecurity organized by the Free University of Brussels. As part of my Master's thesis, I have to implement a DNS amplification scenario within a Cyber Range. Before doing so, I need to measure th...Hello, I'm a student in the Master in Cybersecurity organized by the Free University of Brussels. As part of my Master's thesis, I have to implement a DNS amplification scenario within a Cyber Range. Before doing so, I need to measure the amplification rate for each DNS request. However, I know that BIND is designed to respond to ANY requests via TCP for security reasons. So my question is: how can I make my BIND9 server respond to ANY queries via UDP and not TCP for the purposes of my thesis?
Thank you in advance for your reply.https://gitlab.isc.org/isc-projects/bind9/-/issues/4411QPDB lite2024-03-11T09:12:31ZPetr Špačekpspacek@isc.orgQPDB liteData structure replacement: Replace `dns_rbt_` calls in RBTDB with single-threaded qptrie-equivalents.
Assumptions:
- We will use structure self-cleaning ability instead of wonky RBT cleaning.
- It is not hard and can be done before 9.2...Data structure replacement: Replace `dns_rbt_` calls in RBTDB with single-threaded qptrie-equivalents.
Assumptions:
- We will use structure self-cleaning ability instead of wonky RBT cleaning.
- It is not hard and can be done before 9.20 cutoff.
Test plan:
- Write shim which acts like the current dns_rbt_ API and we will fuzz old RBT in lockstep with the new QPtrip-based API and check consistency of API behavior. If these two match it should be relatively low risk operation.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4408Release Checklist for BIND 9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.182024-01-10T07:22:57ZPetr Špačekpspacek@isc.orgRelease Checklist for BIND 9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18## Release Schedule
**Code Freeze:** Wednesday, 1 November 2023
**Tagging Deadline:** Monday, 6 November 2023
**Public Release:** Wednesday, 15 November 2023
## Documentation Review Links
**Closed issues assigned to the milestone ...## Release Schedule
**Code Freeze:** Wednesday, 1 November 2023
**Tagging Deadline:** Monday, 6 November 2023
**Public Release:** Wednesday, 15 November 2023
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.16.45](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=November+2023+%289.16.45%2C+9.16.45-S1%2C+9.18.20%2C+9.18.20-S1%2C+9.19.18%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.16)
- [9.16.45-S1](https://gitlab.isc.org/isc-private/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=November+2023+%289.16.45%2C+9.16.45-S1%2C+9.18.20%2C+9.18.20-S1%2C+9.19.18%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.16-S)
- [9.18.20](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=November+2023+%289.16.45%2C+9.16.45-S1%2C+9.18.20%2C+9.18.20-S1%2C+9.19.18%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.18)
- [9.18.20-S1](https://gitlab.isc.org/isc-private/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=November+2023+%289.16.45%2C+9.16.45-S1%2C+9.18.20%2C+9.18.20-S1%2C+9.19.18%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.18-S)
- [9.19.18](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=November+2023+%289.16.45%2C+9.16.45-S1%2C+9.18.20%2C+9.18.20-S1%2C+9.19.18%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.19)
**Merge requests merged into the milestone without a release note:**
- [9.16.45](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=November+2023+%289.16.45%2C+9.16.45-S1%2C+9.18.20%2C+9.18.20-S1%2C+9.19.18%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.16)
- [9.16.45-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=November+2023+%289.16.45%2C+9.16.45-S1%2C+9.18.20%2C+9.18.20-S1%2C+9.19.18%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.16-sub)
- [9.18.20](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=November+2023+%289.16.45%2C+9.16.45-S1%2C+9.18.20%2C+9.18.20-S1%2C+9.19.18%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.18)
- [9.18.20-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=November+2023+%289.16.45%2C+9.16.45-S1%2C+9.18.20%2C+9.18.20-S1%2C+9.19.18%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.18-sub)
- [9.19.18](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=November+2023+%289.16.45%2C+9.16.45-S1%2C+9.18.20%2C+9.18.20-S1%2C+9.19.18%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=main)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.16.45](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=November+2023+%289.16.45%2C+9.16.45-S1%2C+9.18.20%2C+9.18.20-S1%2C+9.19.18%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.16)
- [9.16.45-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=November+2023+%289.16.45%2C+9.16.45-S1%2C+9.18.20%2C+9.18.20-S1%2C+9.19.18%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.16-sub)
- [9.18.20](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=November+2023+%289.16.45%2C+9.16.45-S1%2C+9.18.20%2C+9.18.20-S1%2C+9.19.18%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.18)
- [9.18.20-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=November+2023+%289.16.45%2C+9.16.45-S1%2C+9.18.20%2C+9.18.20-S1%2C+9.19.18%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.18-sub)
- [9.19.18](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=November+2023+%289.16.45%2C+9.16.45-S1%2C+9.18.20%2C+9.18.20-S1%2C+9.19.18%29&label_name%5B%5D=No+CHANGES&target_branch=main)
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Rebase -S editions on top of current open-source versions: `git checkout bind-9.18-sub && git rebase origin/bind-9.18`
- [x] ***(QA)*** [Inform Support and Marketing of impending release (and give estimated release dates).](https://mattermost.isc.org/isc/pl/gjwhu93hqty798zom8wsfuashc)
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform. Check [public](https://gitlab.isc.org/isc-projects/bind9/-/pipelines?scope=all&source=schedule) and [private](https://gitlab.isc.org/isc-private/bind9/-/pipelines?scope=all&source=schedule) scheduled pipelines: https://gitlab.isc.org/isc-projects/bind9/-/issues/4408#note_414255
- [x] ***(QA)*** Check charts from `shotgun:*` jobs in the scheduled pipelines to verify there is no unexplained performance drop for any protocol.
- [x] ***(QA)*** Check [Perflab](https://perflab.isc.org/) to ensure there has been no unexplained drop in performance for the versions being released.
- [x] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [x] ***(QA)*** Ensure that there are no outstanding [merge requests in the private repository](https://gitlab.isc.org/isc-private/bind9/-/merge_requests/)[^1] (Subscription Edition only).
- [x] ***(QA)*** [Ensure](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/check_backports.py) all merge requests marked for backporting have been indeed backported: https://gitlab.isc.org/isc-projects/bind9/-/issues/4408#note_414265
- [x] ***(QA)*** [Announce (on Mattermost) that the code freeze is in effect.](https://mattermost.isc.org/isc/pl/7ah5g9yc57gh3rppwz9s9uhrfo)
### Before the Tagging Deadline
- [x] ***(QA)*** Inspect the current output of the `cross-version-config-tests` job to verify that no unexpected backward-incompatible change was introduced in the current release cycle.
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well. [Example](https://gitlab.isc.org/isc-private/bind9/-/merge_requests/510)
- [x] ***(QA)*** Add a release marker to `CHANGES`. Examples: [9.18](https://gitlab.isc.org/isc-projects/bind9/-/commit/f14d8ad78c0506fd4247187f2177f8eceeb6b3b9), [9.16](https://gitlab.isc.org/isc-projects/bind9/-/commit/1bcdf21874f99a00da389d723e0ad07dfd70f9f1)
- [x] ***(QA)*** Add a release marker to `CHANGES.SE` (Subscription Edition only). [Example](https://gitlab.isc.org/isc-private/bind9/-/commit/0f03d5737bcbdaa1bf713c6db1887b14938c3421)
- [x] ***(QA)*** Update BIND 9 version in `configure.ac` ([9.18+](https://gitlab.isc.org/isc-projects/bind9/-/commit/3c85ab7f4c35e6d8acef1393606002a0a8730100)) or `version` ([9.16](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7692/diffs?commit_id=1bcdf21874f99a00da389d723e0ad07dfd70f9f1)).
- [x] ***(QA)*** ~~Rebuild `configure` using Autoconf on `docs.isc.org` (9.16).~~
- [x] ***(QA)*** ~~Update GitLab settings for all maintained branches to disallow merging to them: [public](https://gitlab.isc.org/isc-projects/bind9/-/settings/repository), [private](https://gitlab.isc.org/isc-private/bind9/-/settings/repository)~~
- [x] ***(QA)*** Tag the releases in the private repository (`git tag -s -m "BIND 9.x.y" v9.x.y`).
### Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Check that the formatting is correct for the HTML version of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Verify GitLab CI results [for the tags](https://gitlab.isc.org/isc-private/bind9/-/pipelines?scope=tags) created and sign off on the releases to be published.
- [x] ***(QA)*** ~~Update GitLab settings for all maintained branches to allow merging to them again: [public](https://gitlab.isc.org/isc-projects/bind9/-/settings/repository), [private](https://gitlab.isc.org/isc-private/bind9/-/settings/repository)~~
- [x] ***(QA)*** Prepare (using [`version_bump.py`](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/version_bump.py)) and merge MRs resetting the release notes and updating the version string for each maintained branch.
- [x] ***(QA)*** Rebase the Subscription Edition branches (including recent release prep commits) on top of the open source branches with updated version strings.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is over.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums. Ask [signers on Mattermost](https://mattermost.isc.org/isc/channels/bind-9-qa).
- [x] ***(Signers)*** Ensure that the contents of tarballs and tags are identical.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again: Run `publish_bind.sh` on repo.isc.org to pre-publish.
- [x] ~~***(QA)*** Prepare the `patches/` subdirectory for each security release (if applicable).~~
- [x] ***(QA)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages (in [cloudsmith branch in private repo](https://gitlab.isc.org/isc-private/rpms/bind/-/tree/cloudsmith)). [Example](https://gitlab.isc.org/isc-private/rpms/bind/-/commit/e2512f4cfaf991827a635e374e7e93b27a5f38ba)
- [x] ***(QA)*** [Use the Printing Press project to prepare a release announcement email.](isc-private/printing-press!75)
- [x] ~~***(Marketing)*** Update ASN documents in the SF portal.~~
- [x] ~~***(Marketing)*** Send out ASN emails (if applicable).~~
### On the Day of Public Release
- [x] ***(QA)*** ~~Wait for clearance from Security Officer to proceed with the public release (if applicable).~~
- [x] ***(QA)*** Place tarballs in public location on FTP site.
- [x] ***(QA)*** Inform Marketing of the release, providing FTP links for the published tarballs.
- [x] ***(Marketing)*** Publish links to downloads on ISC website. [Example](https://gitlab.isc.org/website/theme-staging-site/-/commit/1ac7b30b73cb03228df4cd5651fa4e774ac35625)
- [x] ***(Marketing)*** Update the BIND -S information document in SF with download links to the new versions. (If this is a security release, this will have already been done as part of the ASN process.)
- [x] ***(Marketing)*** Update the Current Software Versions document in the SF portal if any stable versions were released.
- [x] ***(Marketing)*** Send the release announcement email to the *bind-announce* mailing list (and to *bind-users* if a major release - [example](https://lists.isc.org/pipermail/bind-users/2022-January/105624.html)).
- [x] ***(Marketing)*** Announce release on social media sites.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Support)*** Add the new releases to the [vulnerability matrix in the Knowledge Base](https://kb.isc.org/docs/aa-00913).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages in [private repo](https://gitlab.isc.org/isc-private/rpms/bind/-/tree/cloudsmith). [Example](https://gitlab.isc.org/isc-private/rpms/bind/-/commit/2007d566db81dd9dfd79e571e2f600a3bc284da4)
- [x] ***(QA)*** Build [public RPMs](https://gitlab.isc.org/isc-packages/rpms/bind). [Example commit](https://gitlab.isc.org/isc-packages/rpms/bind/-/commit/3b5e851ea7c4e3570371a4878b5461f02a44f8cc) which triggers [Copr builds](https://copr.fedorainfracloud.org/coprs/isc/) automatically
- [x] ***(SwEng)*** Build Debian/Ubuntu packages.
- [x] ***(SwEng)*** Update Docker files [here](https://gitlab.isc.org/isc-projects/bind9-docker/-/branches) and make sure push is synchronized to [GitHub](https://github.com/isc-projects/bind9-docker). [Docker Hub](https://hub.docker.com/r/internetsystemsconsortium/bind9) should pick it up automatically. [Example](https://gitlab.isc.org/isc-projects/bind9-docker/-/commit/cada7e10e9af951595c98bfffc4bd42512faac05)
- [x] ***(QA)*** Ensure all new tags are annotated and signed. `git show --show-signature v9.19.12`
- [x] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Using [`merge_tag.py`](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/merge_tag.py), merge published release tags back into the their relevant development/maintenance branches.
- [x] ***(QA)*** ~~Ensure `allow_failure: true` is removed from the `cross-version-config-tests` job if it was set during the current release cycle.~~
- [x] ***(QA)*** Sanitize confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public.
- [x] ***(QA)*** Sanitize [confidential issues](https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=milestone_due_desc&state=opened&confidential=yes) which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate[^2].
- [x] ***(QA)*** Update QA tools used in GitLab CI (e.g. Black, PyLint, Sphinx) by modifying the relevant [`Dockerfile`](https://gitlab.isc.org/isc-projects/images/-/merge_requests/228/diffs).
- [x] ***(QA)*** Run a pipeline to rebuild all [images](https://gitlab.isc.org/isc-projects/images) used in GitLab CI.
- [x] ***(QA)*** Update [`metadata.json`](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/metadata.json) with the upcoming release information.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.
[^2]: As a rule of thumb, security vulnerabilities which have reproducers merged to the public repository are considered okay for full disclosure.November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Petr Špačekpspacek@isc.orgPetr Špačekpspacek@isc.org2023-11-15https://gitlab.isc.org/isc-projects/bind9/-/issues/4407TSAN error in isc_hashmap_iter_create2023-11-07T11:00:59ZMark AndrewsTSAN error in isc_hashmap_iter_createJob [#3773372](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3773372) failed for 0482451f84b0f266dab1e2d2f2ba78ca20ec5b73:
Missing lock / atomics on iterator count.
hashmap->iterators++;
```
WARNING: ThreadSanitizer: data race
...Job [#3773372](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3773372) failed for 0482451f84b0f266dab1e2d2f2ba78ca20ec5b73:
Missing lock / atomics on iterator count.
hashmap->iterators++;
```
WARNING: ThreadSanitizer: data race
Read of size 8 at 0x000000000001 by thread T0001:
#0 isc_hashmap_iter_create lib/isc/hashmap.c:608 (BuildId: 7ec65504b258e2240d31f1743404da3227b2aed3)
#1 dns_tsigkeyring_dump lib/dns/tsig.c:472 (BuildId: cf5fbb2a379d17cf79b5c2d5fd3b945525f46b2c)
#2 destroy lib/dns/view.c:231 (BuildId: cf5fbb2a379d17cf79b5c2d5fd3b945525f46b2c)
#3 dns_view_weakdetach lib/dns/view.c:578 (BuildId: cf5fbb2a379d17cf79b5c2d5fd3b945525f46b2c)
#4 zone_shutdown lib/dns/zone.c:14527 (BuildId: cf5fbb2a379d17cf79b5c2d5fd3b945525f46b2c)
#5 isc__async_cb lib/isc/async.c:111 (BuildId: 7ec65504b258e2240d31f1743404da3227b2aed3)
#6 uv__async_io /usr/src/libuv-v1.46.0/src/unix/async.c:176 (BuildId: 797e130002e5c7a3ee5c0e181992b461482df75b)
#7 thread_body lib/isc/thread.c:85 (BuildId: 7ec65504b258e2240d31f1743404da3227b2aed3)
#8 thread_run lib/isc/thread.c:100 (BuildId: 7ec65504b258e2240d31f1743404da3227b2aed3)
Previous write of size 8 at 0x000000000001 by thread T0002:
#0 isc_hashmap_iter_create lib/isc/hashmap.c:608 (BuildId: 7ec65504b258e2240d31f1743404da3227b2aed3)
#1 dns_tsigkeyring_dump lib/dns/tsig.c:472 (BuildId: cf5fbb2a379d17cf79b5c2d5fd3b945525f46b2c)
#2 destroy lib/dns/view.c:231 (BuildId: cf5fbb2a379d17cf79b5c2d5fd3b945525f46b2c)
#3 dns_view_weakdetach lib/dns/view.c:578 (BuildId: cf5fbb2a379d17cf79b5c2d5fd3b945525f46b2c)
#4 zone_shutdown lib/dns/zone.c:14527 (BuildId: cf5fbb2a379d17cf79b5c2d5fd3b945525f46b2c)
#5 isc__async_cb lib/isc/async.c:111 (BuildId: 7ec65504b258e2240d31f1743404da3227b2aed3)
#6 uv__async_io /usr/src/libuv-v1.46.0/src/unix/async.c:176 (BuildId: 797e130002e5c7a3ee5c0e181992b461482df75b)
#7 thread_body lib/isc/thread.c:85 (BuildId: 7ec65504b258e2240d31f1743404da3227b2aed3)
#8 thread_run lib/isc/thread.c:100 (BuildId: 7ec65504b258e2240d31f1743404da3227b2aed3)
Location is heap block of size 88 at 0x000000000012 allocated by main thread:
#0 malloc <null> (BuildId: 78ee840c3fb04c49132c060982867c27b52d0ffb)
#1 mallocx lib/isc/jemalloc_shim.h:67 (BuildId: 7ec65504b258e2240d31f1743404da3227b2aed3)
#2 mem_get lib/isc/mem.c:305
#3 isc__mem_get lib/isc/mem.c:744 (BuildId: 7ec65504b258e2240d31f1743404da3227b2aed3)
#4 isc_hashmap_create lib/isc/hashmap.c:210 (BuildId: 7ec65504b258e2240d31f1743404da3227b2aed3)
#5 dns_tsigkeyring_create lib/dns/tsig.c:1588 (BuildId: cf5fbb2a379d17cf79b5c2d5fd3b945525f46b2c)
#6 dns_view_create lib/dns/view.c:144 (BuildId: cf5fbb2a379d17cf79b5c2d5fd3b945525f46b2c)
#7 create_view bin/named/server.c:6423 (BuildId: 7bf7fd2425148f507bca7f65a93860eed28a6abc)
#8 load_configuration bin/named/server.c:9018 (BuildId: 7bf7fd2425148f507bca7f65a93860eed28a6abc)
#9 run_server bin/named/server.c:9859 (BuildId: 7bf7fd2425148f507bca7f65a93860eed28a6abc)
#10 isc__async_cb lib/isc/async.c:111 (BuildId: 7ec65504b258e2240d31f1743404da3227b2aed3)
#11 uv__async_io /usr/src/libuv-v1.46.0/src/unix/async.c:176 (BuildId: 797e130002e5c7a3ee5c0e181992b461482df75b)
#12 thread_body lib/isc/thread.c:85 (BuildId: 7ec65504b258e2240d31f1743404da3227b2aed3)
#13 isc_thread_main lib/isc/thread.c:116 (BuildId: 7ec65504b258e2240d31f1743404da3227b2aed3)
#14 isc_loopmgr_run lib/isc/loop.c:454 (BuildId: 7ec65504b258e2240d31f1743404da3227b2aed3)
#15 main bin/named/main.c:1574 (BuildId: 7bf7fd2425148f507bca7f65a93860eed28a6abc)
Thread T0001 'isc-loop-0002' (running) created by main thread at:
#0 pthread_create <null> (BuildId: 78ee840c3fb04c49132c060982867c27b52d0ffb)
#1 isc_thread_create lib/isc/thread.c:139 (BuildId: 7ec65504b258e2240d31f1743404da3227b2aed3)
#2 isc_loopmgr_run lib/isc/loop.c:448 (BuildId: 7ec65504b258e2240d31f1743404da3227b2aed3)
#3 main bin/named/main.c:1574 (BuildId: 7bf7fd2425148f507bca7f65a93860eed28a6abc)
Thread T0002 'isc-loop-0003' (running) created by main thread at:
#0 pthread_create <null> (BuildId: 78ee840c3fb04c49132c060982867c27b52d0ffb)
#1 isc_thread_create lib/isc/thread.c:139 (BuildId: 7ec65504b258e2240d31f1743404da3227b2aed3)
#2 isc_loopmgr_run lib/isc/loop.c:448 (BuildId: 7ec65504b258e2240d31f1743404da3227b2aed3)
#3 main bin/named/main.c:1574 (BuildId: 7bf7fd2425148f507bca7f65a93860eed28a6abc)
SUMMARY: ThreadSanitizer: data race lib/isc/hashmap.c:608 in isc_hashmap_iter_create
```December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4406cleanup 'b' in dnstap-read main2023-11-07T10:27:34ZMark Andrewscleanup 'b' in dnstap-read main'b' is unused.'b' is unused.November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4405deprecate/remove resolver-nonbackoff-tries, resolver-retry-interval2023-12-08T12:18:01ZEvan Huntdeprecate/remove resolver-nonbackoff-tries, resolver-retry-intervalThese options were added to `named` at the same time as serve-stale support. I suspect they were meant to be used for testing, but they weren't documented as test-only options (or, really, as anything else either - see #1687).
They are ...These options were added to `named` at the same time as serve-stale support. I suspect they were meant to be used for testing, but they weren't documented as test-only options (or, really, as anything else either - see #1687).
They are not, in fact, used in any of the system tests, and I can't think of a reason one would want to modify them in production. I suggest we remove them as of 9.20.December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/4404Unexpected partial use of jemalloc by BIND (tested on 9.18.19-S1)2024-03-08T05:26:15ZCathy AlmondUnexpected partial use of jemalloc by BIND (tested on 9.18.19-S1)### Summary
As reported in case SF#1428:
====
I've been trying to use jemalloc to build BIND 9.18.x, and noticed something bit awkward that might not be intentional.
I've manually installed jemalloc 5.3.0, and then built BIND 9.18.19...### Summary
As reported in case SF#1428:
====
I've been trying to use jemalloc to build BIND 9.18.x, and noticed something bit awkward that might not be intentional.
I've manually installed jemalloc 5.3.0, and then built BIND 9.18.19-S1 with --with-jemalloc (which shouldn't be necessary but I wanted to make it explicit). It's indeed linked with libjemalloc:
```
root@c45a8371918a:/tmp/bind-9.18.19-S1# ldd bin/named/.libs/named
linux-vdso.so.1 (0x00007ffcb6bfe000)
libisc-9.18.19-S1.so => /usr/local/lib/libisc-9.18.19-S1.so (0x00007f6052fc6000)
libdns-9.18.19-S1.so => /usr/local/lib/libdns-9.18.19-S1.so (0x00007f6052b9f000)
libns-9.18.19-S1.so => /usr/local/lib/libns-9.18.19-S1.so (0x00007f605294e000)
libisccc-9.18.19-S1.so => /usr/local/lib/libisccc-9.18.19-S1.so (0x00007f6052745000)
libisccfg-9.18.19-S1.so => /usr/local/lib/libisccfg-9.18.19-S1.so (0x00007f605250f000)
libbind9-9.18.19-S1.so => /usr/local/lib/libbind9-9.18.19-S1.so (0x00007f60522f8000)
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f6051e2d000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f6051c27000)
libuv.so.1 => /usr/lib/x86_64-linux-gnu/libuv.so.1 (0x00007f6051a01000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f60517e4000)
libjson-c.so.3 => /lib/x86_64-linux-gnu/libjson-c.so.3 (0x00007f60515d9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f60513ba000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6050fc9000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6050dc1000)
libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f6050b34000)
libjemalloc.so.2 => /usr/local/lib/libjemalloc.so.2 (0x00007f6050675000)
[...]
```
I then confirmed the call to malloc() in isc__trampoline_attach is the one defined in the standard libc (see the attached file). That seems to defeat the intent of this malloc call described in the comment:
```
/*
* Ensure every thread starts with a malloc() call to prevent memory
* bloat caused by a jemalloc quirk. While this dummy allocation is
* not used for anything, free() must not be immediately called for it
* so that an optimizing compiler does not strip away such a pair of
* malloc() + free() calls altogether, as it would foil the fix.
*/
```
I suspect this is because libc is seemingly loaded before libjemalloc (as shown in the above ldd output), and so libc's malloc is first found and used. isc_mem_xxx still uses jemalloc since it calls jemalloc's custom functions. Also, if I set LD_PRELOAD to /usr/local/lib/libjemalloc.so to run named, malloc defined in jemalloc is used in isc__trampoline_attach (and apparently anywhere else).
Now my question is: is this behavior intentional? I'm actually planning to set LD_PRELOAD for some other reasons, but if the current behavior is intentional (i.e., using libc's malloc/free etc for anywhere else than isc_mem_xxx), is there a reason why I "should not" set LD_PRELOAD?
### BIND version used
9.18.19-S1
### Steps to reproduce
See above
### What is the current *bug* behavior?
See above
### What is the expected *correct* behavior?
See above
### Relevant configuration files
See above
### Relevant logs and/or screenshots
See above
### Possible fixes
See aboveNovember 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4403Resolve spike in memory when named starts2023-12-05T15:58:58ZMatthijs Mekkingmatthijs@isc.orgResolve spike in memory when named starts9.19 resolver does better parallelization of work with cold cache, and thus consumes a more memory and CPU resources right after startup.
We should investigate if it works fine in face of limited resources, e.g. when the initial memory ...9.19 resolver does better parallelization of work with cold cache, and thus consumes a more memory and CPU resources right after startup.
We should investigate if it works fine in face of limited resources, e.g. when the initial memory spike exceeds available memory.
![all-groups-resmon.memory.current-docker](/uploads/b5fa63c677bb0c903ffca45b994375ac/all-groups-resmon.memory.current-docker.png)
![all-groups-resmon.cpu.usage_percent.cg-docker](/uploads/314f7c9f1c396f303bdd6397dd2dc73a/all-groups-resmon.cpu.usage_percent.cg-docker.png)
![all-groups-latency-since_0-until_150](/uploads/3ba559d2fd3a18335eaf45796874482c/all-groups-latency-since_0-until_150.png)BIND 9.19.xOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4402Change system tests to not use dnssec-validation auto2024-01-08T17:22:40ZMatthijs Mekkingmatthijs@isc.orgChange system tests to not use dnssec-validation autoIt breaks all tests when root key rolls.It breaks all tests when root key rolls.January 2024 (9.16.46, 9.16.46-S1, 9.18.22, 9.18.22-S1, 9.19.20) (❗RECALLED❗)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4401make check may throw KeyError while processing pytest's junitxml output2023-11-02T09:03:21ZTom Krizekmake check may throw KeyError while processing pytest's junitxml output`make check` may end up with the following python error:
```
Traceback (most recent call last):
File "/usr/home/ondrej/Projects/bind9/bin/tests/system/./convert-junit-to-trs.py", line 70, in <module>
main()
File "/usr/home/ondre...`make check` may end up with the following python error:
```
Traceback (most recent call last):
File "/usr/home/ondrej/Projects/bind9/bin/tests/system/./convert-junit-to-trs.py", line 70, in <module>
main()
File "/usr/home/ondrej/Projects/bind9/bin/tests/system/./convert-junit-to-trs.py", line 66, in main
sys.exit(junit_to_trs(junit_xml))
File "/usr/home/ondrej/Projects/bind9/bin/tests/system/./convert-junit-to-trs.py", line 37, in junit_to_trs
if node.attrib["type"] == "pytest.xfail":
KeyError: 'type'
```
Related #4262, #3810November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4400CID 467118: Control flow issue in lib/dns/message.c2024-02-24T07:55:29ZMichal NowakCID 467118: Control flow issue in lib/dns/message.cCoverity Scan claims control flow issue in `lib/dns/message.c` (suspect: !8400).
```
*** CID 467118: Control flow issues (DEADCODE)
/lib/dns/message.c: 1076 in getquestions()
1070 return (DNS_R_RECOVERABLE);
1071 }
1072 ...Coverity Scan claims control flow issue in `lib/dns/message.c` (suspect: !8400).
```
*** CID 467118: Control flow issues (DEADCODE)
/lib/dns/message.c: 1076 in getquestions()
1070 return (DNS_R_RECOVERABLE);
1071 }
1072 return (ISC_R_SUCCESS);
1073
1074 cleanup:
1075 if (rdataset != NULL) {
>>> CID 467118: Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "dns_message_puttemprdataset...".
1076 dns_message_puttemprdataset(msg, &rdataset);
1077 }
1078 if (free_name) {
1079 dns_message_puttempname(msg, &name);
1080 }
1081
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4397util/checklibs.sh script doesn't work2023-11-07T11:26:13ZMark Andrewsutil/checklibs.sh script doesn't workIt looks like the automatic formatting of shell scripts broke util/checklibs.sh on MacOS at least.
The script now has a case statement inside a $() and the shell doesn't cope with this. It doesn't find
the correct ')' to end the $(). ...It looks like the automatic formatting of shell scripts broke util/checklibs.sh on MacOS at least.
The script now has a case statement inside a $() and the shell doesn't cope with this. It doesn't find
the correct ')' to end the $(). Converting the case to a if/elif/fi series addresses this.
```
% sh util/checklibs.sh
util/checklibs.sh: line 90: syntax error near unexpected token `;;'
util/checklibs.sh: line 90: ` isc_ntsecurity_getaccountgroups) continue ;; # internal'
%
```
```
diff --git a/util/checklibs.sh b/util/checklibs.sh
index ef96a9519b9..c30bb8be3b1 100755
--- a/util/checklibs.sh
+++ b/util/checklibs.sh
@@ -86,10 +86,11 @@ for lib in $(git ls-files -c lib \
| xargs grep "$pat" \
| sed -e 's/.*://' -e 's/(.*//' \
| while read p; do
- case $p in
- isc_ntsecurity_getaccountgroups) continue ;; # internal
- isc_socketmgr_getmaxsockets) p=isc__socketmgr_getmaxsockets ;;
- esac
+ if test "$p" = isc_ntsecurity_getaccountgroups; then
+ continue
+ elif test "$p" = isc_socketmgr_getmaxsockets; then
+ p=isc__socketmgr_getmaxsockets
+ fi
grep -q "^${p}"'$' $def && continue
test $lib = isc -a -f lib/isc/win32/libisc.def.exclude \
&& grep -q "^${p}"'$' lib/isc/win32/libisc.def.exclude \
```November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/4396dig does not display YAML output for errors when using protocols other than UDP2023-12-06T18:26:17ZAtahualpa Ledesmadig does not display YAML output for errors when using protocols other than UDP### Summary
When running dig with the +yaml option no output is returned when an error occurs using a protocol other than UDP
### BIND version used
DiG 9.18.16
### Steps to reproduce
1) Run dig with +tcp and an invalid resolver: dig...### Summary
When running dig with the +yaml option no output is returned when an error occurs using a protocol other than UDP
### BIND version used
DiG 9.18.16
### Steps to reproduce
1) Run dig with +tcp and an invalid resolver: dig +yaml +tries=1 +time=1 +tcp @1.1.1.4 google.com A -4
2) no output is returned
3) exit code is 9
### What is the current _bug_ behavior?
No output is returned for +tcp, +tls or +http errors
### What is the expected _correct_ behavior?
dig should return the following output when failing to contact a resolver using any of the supported protocols:
dig +yaml +tries=1 +time=1 +notcp @1.1.1.4 google.com A -4
type: DIG_ERROR message: | no servers could be reached
### Relevant configuration files
N/A
### Relevant logs and/or screenshots
**dig with +notcp:**
user@box\> dig +yaml +tries=1 +time=1 +notcp @1.1.1.4 google.com A -4
type: DIG_ERROR message: | no servers could be reached
user@box\> echo $?\
9
**dig with +tcp:**
user@box\> dig +yaml +tries=1 +time=1 +tcp @1.1.1.4 google.com A -4
user@box\> echo $?\
9
### Possible fixes
(If you can, link to the line of code that might be responsible for the problem.)December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4395Extend rate-limit features to protect recursor from bad clients2023-10-27T14:11:50ZVictor CarcelerExtend rate-limit features to protect recursor from bad clients### Description
In our organization, some users are using `resperf` to send many queries to our DNS with the intention of degrading the service or even blocking it for legitimate users.
We have used our firewall to rate limit access to...### Description
In our organization, some users are using `resperf` to send many queries to our DNS with the intention of degrading the service or even blocking it for legitimate users.
We have used our firewall to rate limit access to ports 53 UDP and TCP per client.
We have also verified that BIND9's rate-limit functions, which are designed to prevent other types of attacks, can also be used in this case to block excessive UDP queries.
Something like:
```
rate-limit {
responses-per-second 75;
all-per-second 200;
window 3;
max-table-size 2000000;
min-table-size 500000;
ipv4-prefix-length 32;
};
```
Blocks excessive queries from the attacker and preserves resources for the rest of the users when the attacker uses UDP to make queries.
### Request
It would be great if BIND9's rate-limit functions could rate limit queries sent by attackers regardless of the protocol used by the attacker.
Thank you very much.
### Links / references
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-rate-limithttps://gitlab.isc.org/isc-projects/bind9/-/issues/4394Cannot configure Zone to work properly2023-10-26T22:54:48ZWisameldin EsmaelCannot configure Zone to work properlyTo be honest I am not sure this is a bug maybe issue with the implementation of the app I installed it on Ubunto 20 and configured two zones
Options config file
```
acl internal {
localhost;
localnets;
192.168.70....To be honest I am not sure this is a bug maybe issue with the implementation of the app I installed it on Ubunto 20 and configured two zones
Options config file
```
acl internal {
localhost;
localnets;
192.168.70.0/24;
10.200.157.0/24;
};
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 9.9.9.9;
// };
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation yes;
//auth-nxdomain no;
//listen-on port 53 { 127.0.0.1; 192.168.70.66; };
//listen-on-v6 port 53 { ::1; };
};
`
Local config file
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
zone "wisam.rph" {
type master;
file "/etc/bind/forward.wisam.rph";
};
zone "70.168.192.in-addr.arpa" {
type master;
file "/etc/bind/reverse.wisam.rph";
};
```
Forward Zone
```
;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA nameserver.wisam.rph. root.nameserver.wisam.rph. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS nameserver.wisam.rph.
nameserver IN A 192.168.70.66
www IN A 192.168.70.66
@ IN AAAA ::1
```
Reverse Zone
```
;
; BIND reverse data file for local loopback interface
;
$TTL 604800
@ IN SOA nameserver.wisam.rph. root.nameserver.wisam.rph. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS nameserver.wisam.rph.
nameserver IN A 192.168.70.66
66 IN PTR nameserver.wisam.rph.
```
Note IP of the server is 192.168.70.66
I have disabled systemd-resolved removed the resolv.conf file and recreated with the following contents
resolv.conf
nameserver 192.168.70.66
search wisam.rph
within the server if i execute "dig nameserver.wisam.rph" the result I get is
```
; <<>> DiG 9.16.1-Ubuntu <<>> nameserver.wisam.rph
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61584
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 32e45ecf7d5069f601000000653a9e7e43d963d1c233e471 (good)
;; QUESTION SECTION:
;nameserver.wisam.rph. IN A
;; ANSWER SECTION:
nameserver.wisam.rph. 604800 IN A 192.168.70.66
;; Query time: 0 msec
;; SERVER: 192.168.70.66#53(192.168.70.66)
;; WHEN: Thu Oct 26 17:14:38 UTC 2023
;; MSG SIZE rcvd: 93
```
and for the reverse "dig -x 192.168.70.66" I get
```
; <<>> DiG 9.16.1-Ubuntu <<>> -x 192.168.70.66
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45455
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: add17d7373cfe21c01000000653a9ed0d83ec9b4b4f3cfb0 (good)
;; QUESTION SECTION:
;66.70.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
66.70.168.192.in-addr.arpa. 604800 IN PTR nameserver.wisam.rph.
;; Query time: 0 msec
;; SERVER: 192.168.70.66#53(192.168.70.66)
;; WHEN: Thu Oct 26 17:16:00 UTC 2023
;; MSG SIZE rcvd: 117
```
At this point I can't find any issues
I did run the command "sudo ufw allow Bind9" to be sure the traffic is allowed
Yet on another ubuntu 20 desktop setting the dns to 192.168.70.66 and try to execute this command "dig nameserver.wisam.rph @192.168.70.66" I get
```
; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> nameserver.wisam.rph @192.168.70.66
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46698
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nameserver.wisam.rph. IN A
;; Query time: 4 msec
;; SERVER: 192.168.70.66#53(192.168.70.66) (UDP)
;; WHEN: Thu Oct 26 13:19:36 EDT 2023
;; MSG SIZE rcvd: 49
```
Yet if I ping it I get
```
PING 192.168.70.66 (192.168.70.66) 56(84) bytes of data.
64 bytes from 192.168.70.66: icmp_seq=1 ttl=64 time=0.937 ms
64 bytes from 192.168.70.66: icmp_seq=2 ttl=64 time=0.644 ms
64 bytes from 192.168.70.66: icmp_seq=3 ttl=64 time=0.803 ms
64 bytes from 192.168.70.66: icmp_seq=4 ttl=64 time=0.707 ms
64 bytes from 192.168.70.66: icmp_seq=5 ttl=64 time=0.660 ms
64 bytes from 192.168.70.66: icmp_seq=6 ttl=64 time=0.690 ms
64 bytes from 192.168.70.66: icmp_seq=7 ttl=64 time=0.751 ms
64 bytes from 192.168.70.66: icmp_seq=8 ttl=64 time=0.784 ms
64 bytes from 192.168.70.66: icmp_seq=9 ttl=64 time=0.675 ms
64 bytes from 192.168.70.66: icmp_seq=10 ttl=64 time=0.384 ms
64 bytes from 192.168.70.66: icmp_seq=11 ttl=64 time=0.504 ms
64 bytes from 192.168.70.66: icmp_seq=12 ttl=64 time=0.378 ms
64 bytes from 192.168.70.66: icmp_seq=13 ttl=64 time=0.558 ms
64 bytes from 192.168.70.66: icmp_seq=14 ttl=64 time=0.401 ms
64 bytes from 192.168.70.66: icmp_seq=15 ttl=64 time=1.13 ms
64 bytes from 192.168.70.66: icmp_seq=16 ttl=64 time=0.355 ms
64 bytes from 192.168.70.66: icmp_seq=17 ttl=64 time=0.340 ms
64 bytes from 192.168.70.66: icmp_seq=18 ttl=64 time=0.359 ms
64 bytes from 192.168.70.66: icmp_seq=19 ttl=64 time=0.290 ms
64 bytes from 192.168.70.66: icmp_seq=20 ttl=64 time=0.410 ms
64 bytes from 192.168.70.66: icmp_seq=21 ttl=64 time=0.426 ms
64 bytes from 192.168.70.66: icmp_seq=22 ttl=64 time=0.605 ms
64 bytes from 192.168.70.66: icmp_seq=23 ttl=64 time=0.420 ms
64 bytes from 192.168.70.66: icmp_seq=24 ttl=64 time=0.412 ms
64 bytes from 192.168.70.66: icmp_seq=25 ttl=64 time=0.428 ms
```
And if I execute "dig google.com @192.168.70.66" I get
```
; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> google.com @192.168.70.66
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57387
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 33 IN A 142.250.176.206
;; Query time: 12 msec
;; SERVER: 192.168.70.66#53(192.168.70.66) (UDP)
;; WHEN: Thu Oct 26 13:21:55 EDT 2023
;; MSG SIZE rcvd: 55
```
What am I missing? For the lines I commented I tried with and without same result
Your attention to this matter is highly appreciatedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4393error: variable 'engine' set but not used on OpenBSD 7.42023-11-07T10:10:58ZMichal Nowakerror: variable 'engine' set but not used on OpenBSD 7.4Job [#3754698](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3754698) failed for 524ba9a77081484bc6e8f803ae0cc3ae1ee6f3de.
BIND 9.16 fails to build on OpenBSD 7.4:
```
opensslrsa_link.c:900:14: error: variable 'engine' set but not us...Job [#3754698](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3754698) failed for 524ba9a77081484bc6e8f803ae0cc3ae1ee6f3de.
BIND 9.16 fails to build on OpenBSD 7.4:
```
opensslrsa_link.c:900:14: error: variable 'engine' set but not used [-Werror,-Wunused-but-set-variable]
const char *engine = NULL, *label = NULL;
^
```November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4392dispatch_newtcp check failed on OL8 FIPS2023-11-15T08:33:37ZMichal Nowakdispatch_newtcp check failed on OL8 FIPSThe new `dispatch_newtcp` check of the `dispatch` unit test failed on OL8 FIPS job [#3750824](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3750824) (8983bf8ed23f99abaef837395435e1eed5d692fe).
```
[==========] Running 10 test(s).
[ R...The new `dispatch_newtcp` check of the `dispatch` unit test failed on OL8 FIPS job [#3750824](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3750824) (8983bf8ed23f99abaef837395435e1eed5d692fe).
```
[==========] Running 10 test(s).
[ RUN ] dispatch_gettcp
[ OK ] dispatch_gettcp
[ RUN ] dispatch_newtcp
ASSERT: eresult == ISC_R_SUCCESS
[ LINE ] --- dispatch_test.c:477
```
```
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ff137074ea5 in __GI_abort () at abort.c:79
#2 0x00007ff137fd39b7 in exit_test (quit_application=1) at /usr/src/debug/cmocka-1.1.5-1.el8.x86_64/src/cmocka.c:404
#3 0x00007ff137fd3a2e in _fail (file=0x4048d0 "dispatch_test.c", line=477) at /usr/src/debug/cmocka-1.1.5-1.el8.x86_64/src/cmocka.c:2196
#4 0x000000000040384f in stop_listening (arg=<optimized out>) at dispatch_test.c:598
#5 0x00007ff1382342c7 in tcp_connected (handle=<optimized out>, eresult=<optimized out>, arg=<optimized out>) at dispatch.c:1851
#6 0x00007ff138a58de3 in streamdns_call_connect_cb (sock=0x7ff133035c00, handle=0x7ff133010380, result=result@entry=ISC_R_TIMEDOUT) at netmgr/streamdns.c:275
#7 0x00007ff138a59153 in streamdns_transport_connected (handle=0x7ff133010a80, result=ISC_R_TIMEDOUT, cbarg=<optimized out>) at netmgr/streamdns.c:364
#8 0x00007ff138a57964 in isc___nm_connectcb (arg=arg@entry=0x7ff1331f5700) at netmgr/netmgr.c:1735
#9 0x00007ff138a57a66 in isc__nm_connectcb (sock=sock@entry=0x7ff133036600, uvreq=uvreq@entry=0x7ff1331f5700, eresult=eresult@entry=ISC_R_TIMEDOUT, async=async@entry=false) at netmgr/netmgr.c:1750
#10 0x00007ff138a580f7 in isc__nm_failed_connect_cb (sock=sock@entry=0x7ff133036600, req=req@entry=0x7ff1331f5700, eresult=ISC_R_TIMEDOUT, async=async@entry=false) at netmgr/netmgr.c:1011
#11 0x00007ff138a5e0d1 in tcp_connect_cb (uvreq=<optimized out>, status=-125) at netmgr/tcp.c:215
#12 0x00007ff138825276 in uv__stream_destroy (stream=stream@entry=0x7ff133036bc8) at src/unix/stream.c:464
#13 0x00007ff138819ae8 in uv__finish_close (handle=0x7ff133036bc8) at src/unix/core.c:287
#14 uv__run_closing_handles (loop=0x7ff133032020) at src/unix/core.c:317
#15 uv_run (loop=loop@entry=0x7ff133032020, mode=mode@entry=UV_RUN_DEFAULT) at src/unix/core.c:395
#16 0x00007ff138a7a6dd in loop_thread (arg=arg@entry=0x7ff133032000) at loop.c:282
#17 0x00007ff138a89399 in thread_body (wrap=0x10ebcc0) at thread.c:85
#18 0x00007ff138a89413 in isc_thread_main (func=func@entry=0x7ff138a7a652 <loop_thread>, arg=0x7ff133032000) at thread.c:116
#19 0x00007ff138a7b665 in isc_loopmgr_run (loopmgr=0x7ff13302f000) at loop.c:454
#20 0x00000000004027d6 in make_dispatchset (dispatchmgr=<optimized out>, ndisps=941470056, dsetp=0x7ff137fd39d0 <exception_handler>) at dispatch_test.c:254
#21 0x00007ff137fd5f37 in cmocka_run_one_test_or_fixture (function_name=0x404950 "dispatch_newtcp", test_func=0x4027b2 <make_dispatchset+42>, setup_func=setup_func@entry=0x0,
teardown_func=teardown_func@entry=0x0, state=state@entry=0x10e4f10, heap_check_point=heap_check_point@entry=0x0) at /usr/src/debug/cmocka-1.1.5-1.el8.x86_64/src/cmocka.c:2801
#22 0x00007ff137fd68a1 in cmocka_run_one_tests (test_state=0x10e4f00) at /usr/src/debug/cmocka-1.1.5-1.el8.x86_64/src/cmocka.c:2909
#23 _cmocka_run_group_tests (group_name=0x40493a "tests", tests=<optimized out>, num_tests=<optimized out>, group_setup=<optimized out>, group_teardown=0x0)
at /usr/src/debug/cmocka-1.1.5-1.el8.x86_64/src/cmocka.c:3040
#24 0x000000000040454c in setup_workers (state=<optimized out>) at isc.c:67
#25 0x00007ff13708de45 in __libc_start_main (main=0x404501 <main+80>, argc=1, argv=0x7ffeb9a1f1e8, init=0x404820 <__libc_csu_init+80>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffeb9a1f1d8)
at ../csu/libc-start.c:302
#26 0x000000000040259e in register_tm_clones ()
#27 0x00007ffeb9a1f1d8 in ?? ()
#28 0x00007ff138eea100 in ?? () from /lib64/ld-linux-x86-64.so.2
#29 0x0000000000000001 in ?? ()
#30 0x00007ffeb9a1ffa6 in ?? ()
#31 0x0000000000000000 in ?? ()
```
[bt.all.txt](/uploads/101a857cba9c5edb31946920f38b3b85/bt.all.txt)November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Ondřej SurýOndřej Surý