BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-01-11T11:39:57Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3745rndc delzone crashes named if removed zone was defined in a catalog2023-01-11T11:39:57ZPetr Špačekpspacek@isc.orgrndc delzone crashes named if removed zone was defined in a catalog### Summary
`rndc delzone zonefrom.catalog.example` crashes `named`
### BIND version used
- ~"Affects v9.19": v9_19_8
- ~"Affects v9.18": v9_18_10
- ~"Affects v9.16": v9_16_36
### Steps to reproduce
1. Configure secondary server wit...### Summary
`rndc delzone zonefrom.catalog.example` crashes `named`
### BIND version used
- ~"Affects v9.19": v9_19_8
- ~"Affects v9.18": v9_18_10
- ~"Affects v9.16": v9_16_36
### Steps to reproduce
1. Configure secondary server with a catalog zone
2. Attempt to `rndc delzone` member zone from the catalog
3. Enjoy fireworks
### What is the current *bug* behavior?
`rndc` reports:
```
zone 'z100000.test.' will be deleted.The following files were in use and may now be removed:
__catz___default_catalog.invalid_z100000.test.db
```
`named` exits:
```
server.c:13795: REQUIRE(config != ((void *)0)) failed, back trace
```
Unfortunately the machine does not have debugging tools installed, but I think this should suffice - it's 100 % reproducible.
### Relevant configuration files
Same config as in https://gitlab.isc.org/isc-projects/bind9/-/issues/3744.January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)Tony FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3744small updates to large catalog zones cause CPU consumption spikes2023-03-01T14:47:56ZPetr Špačekpspacek@isc.orgsmall updates to large catalog zones cause CPU consumption spikes### Summary
Single RR modification to CATZ causes CPU spikes.
Here is a latency comparison of 1-minute test run, on 100 k QPS (about 1/4 of capacity) while removing and then adding 1 zone, with 20 seconds in between. Green line shows t...### Summary
Single RR modification to CATZ causes CPU spikes.
Here is a latency comparison of 1-minute test run, on 100 k QPS (about 1/4 of capacity) while removing and then adding 1 zone, with 20 seconds in between. Green line shows the same configuration without addition/deletion:
![latency.svg](/uploads/8e8bef18b96e3f39f27c49ae6905db1c/latency.svg)
Timeout = 10 seconds, axes are log-log, Y in usec.
Test environment:
- A beefy AWS VM type - I've used c5n.4xlarge, 16 CPU threads.
- One CATZ with 100 k small zones.
Result: One update -> one CPU core is blocked for 10 seconds.
### BIND version used
- ~"Affects v9.18" : v9_18_10
### Steps to reproduce
- Generate a large catz and configure primary. Here is a script to do that, [genconf.py](/uploads/dbf27a4ea7b768db5a7f08882ffa0732/genconf.py) + [empty.db](/uploads/6c3650f13e246ef9f879cb37911608d3/empty.db)
- Configure secondary to pull the catalog and zones:
```
options {
catalog-zones {
zone "catalog.invalid." min-update-interval 1 default-primaries { 2600::1; };
};
};
zone "catalog.invalid." {
primaries { 2600::1; };
type secondary;
};
```
- Do one RR modification at a time to the CATZ, adding/deleting single zone at a time. Script to do that:
[gencatupd.py](/uploads/76cb7f2e78b4794ed7ba91678e9e4113/gencatupd.py) . Usage:
```
while true; do python gencatudp.py | nsupdate; done
```
### What is the current *bug* behavior?
```
2022-12-14T11:59:02.929Z general: zone catalog.invalid/IN: notify from 2600:1f18:634c:d17e::da5d#42256: serial 2670950588
2022-12-14T11:59:02.929Z xfer-in: zone catalog.invalid/IN: Transfer started.
2022-12-14T11:59:02.929Z xfer-in: transfer of 'catalog.invalid/IN' from 2600:1f18:634c:d17e::da5d#53: connected using 2600:1f18:634c:d17e::da5d#53
2022-12-14T11:59:02.929Z xfer-in: zone catalog.invalid/IN: transferred serial 2670950588
2022-12-14T11:59:02.929Z general: catz: updating catalog zone 'catalog.invalid' with serial -1624016708
2022-12-14T11:59:02.929Z xfer-in: transfer of 'catalog.invalid/IN' from 2600:1f18:634c:d17e::da5d#53: Transfer status: success
2022-12-14T11:59:02.929Z xfer-in: transfer of 'catalog.invalid/IN' from 2600:1f18:634c:d17e::da5d#53: Transfer completed: 1 messages, 5 records, 223 bytes, 0.001 secs (223000 bytes/sec) (serial 2670950588)
```
<- CPU spins here for 10 sec
```
2022-12-14T11:59:12.449Z general: catz: adding zone 'z100000.test' from catalog 'catalog.invalid' - success
2022-12-14T11:59:12.449Z xfer-in: zone z100000.test/IN: Transfer started.
```
### Relevant logs and/or screenshots
Here is a CPU profile taken while the CPU is spinning madly:
![catz.svg](/uploads/a41ed1e9d7a437fee59875b654f61a31/catz.svg)
### Possible fixes
I suppose one improvement could be to reuse IXFR change sets somehow, when they are available.March 2023 (9.16.39, 9.16.39-S1, 9.18.13, 9.18.13-S1, 9.19.11)Petr Špačekpspacek@isc.orgPetr Špačekpspacek@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3743Unexpected "Prohibited" extended DNS error on allow-recursion2023-01-10T10:02:14ZMatthijs Mekkingmatthijs@isc.orgUnexpected "Prohibited" extended DNS error on allow-recursionClients may see an unexpected extended DNS error in their response on a valid response. This may happen if there is an `allow-recursion` ACL that was not matched.Clients may see an unexpected extended DNS error in their response on a valid response. This may happen if there is an `allow-recursion` ACL that was not matched.January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3742incorrect SOA serial representation in: catz: updating catalog zone 'catalog....2022-12-15T14:02:17ZPetr Špačekpspacek@isc.orgincorrect SOA serial representation in: catz: updating catalog zone 'catalog.invalid' with serial -1624016872### Summary
CATZ prints serial number as signed instead of unsigned number. This breaks serials > 2^31.
### BIND version used
- ~"Affects v9.18": v9_18_10
- I did not check older versions. Please check if backport is necessary.
### ...### Summary
CATZ prints serial number as signed instead of unsigned number. This breaks serials > 2^31.
### BIND version used
- ~"Affects v9.18": v9_18_10
- I did not check older versions. Please check if backport is necessary.
### Steps to reproduce
Use catalog with serial > 2^31, e.g. 2670950424.
### What is the current *bug* behavior?
Log:
```
catz: updating catalog zone 'catalog.invalid' with serial -1624016872
```
### What is the expected *correct* behavior?
Serial 2670950424.
### Relevant configuration files
```
options {
catalog-zones {
zone "catalog.invalid." min-update-interval 1 default-primaries { 2600::; };
};
};
zone "catalog.invalid." {
primaries { 2600::; };
type secondary;
};
```January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3740BIND-9.18.9: "add-soa" modification in RPZ requires restart of named2023-01-03T09:36:22ZThomas AmgartenBIND-9.18.9: "add-soa" modification in RPZ requires restart of named### Summary
Changes in RPZ (for example ````add-soa true|false````) requires a restart of ```named```; ```rndc reload``` isn't sufficient.
### BIND version used
```
named -V
BIND 9.18.9 (Stable Release) <id:e831507>
running on Linux x8...### Summary
Changes in RPZ (for example ````add-soa true|false````) requires a restart of ```named```; ```rndc reload``` isn't sufficient.
### BIND version used
```
named -V
BIND 9.18.9 (Stable Release) <id:e831507>
running on Linux x86_64 4.18.0-305.10.2.el8_4.x86_64 #1 SMP Tue Jul 20 20:34:55 UTC 2021
built by make with '--prefix=/usr/local/bind-9.18.9' '--sysconfdir=/opt/chroot/bind/etc/named/' '--mandir=/usr/local/share/man' '--localstatedir=/opt/chroot/bind/var' '--enable-largefile' '--enable-full-report' '--without-gssapi' '--with-json-c' '--enable-singletrace' '--enable-dnstap' 'PKG_CONFIG_PATH=/usr/local/fstrm/lib/pkgconfig/:/usr/local/h2o/lib64/pkgconfig'
compiled by GCC 8.4.1 20200928 (Red Hat 8.4.1-1)
compiled with OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
linked to OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
compiled with libuv version: 1.41.1
linked to libuv version: 1.41.1
compiled with libnghttp2 version: 1.33.0
linked to libnghttp2 version: 1.33.0
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
compiled with protobuf-c version: 1.3.0
linked to protobuf-c version: 1.3.0
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): no
default paths:
named configuration: /opt/chroot/bind/etc/named/named.conf
rndc configuration: /opt/chroot/bind/etc/named/rndc.conf
DNSSEC root key: /opt/chroot/bind/etc/named/bind.keys
nsupdate session key: /opt/chroot/bind/var/run/named/session.key
named PID file: /opt/chroot/bind/var/run/named/named.pid
named lock file: /opt/chroot/bind/var/run/named/named.lock
```
### Steps to reproduce
**rpz-configuration with "add-soa true"**
```
response-policy {
zone "blacklist-rpz.arcade.ch" policy nxdomain;
} qname-wait-recurse no
break-dnssec no
add-soa true
nsip-wait-recurse no;
...
...
```
**query the server for a blacklisted record (isc.org in this example):**
```
$ dig @test isc.org
; <<>> DiG 9.18.9 <<>> @test isc.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1881
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 7485a1057ec2eed50100000063997e60a1a3962d023c7214 (good)
;; QUESTION SECTION:
;isc.org. IN A
;; ADDITIONAL SECTION:
blacklist-rpz.arcade.ch. 1 IN SOA bastelwurstel.arcade.ch. someone.arcade.ch. 2021102103 28800 7200 604800 900
;; Query time: 16 msec
;; SERVER: 10.100.102.21#53(test) (UDP)
;; WHEN: Wed Dec 14 08:42:24 CET 2022
;; MSG SIZE rcvd: 145
```
**Now changing the "add-soa"-field from "true" to "false" and run "rndc reload"**
```
response-policy {
zone "blacklist-rpz.arcade.ch" policy nxdomain;
} qname-wait-recurse no
break-dnssec no
add-soa false
nsip-wait-recurse no;
...
...
```
```
$ rndc reload
server reload successful
```
**query the same record again:**
```
$ dig @test isc.org
; <<>> DiG 9.18.9 <<>> @test isc.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23842
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 93a808f18eed863a0100000063997eca6ffe934bf7095a46 (good)
;; QUESTION SECTION:
;isc.org. IN A
;; ADDITIONAL SECTION:
blacklist-rpz.arcade.ch. 1 IN SOA bastelwurstel.arcade.ch. someone.arcade.ch. 2021102103 28800 7200 604800 900
;; Query time: 20 msec
;; SERVER: 10.100.102.21#53(test) (UDP)
;; WHEN: Wed Dec 14 08:44:10 CET 2022
;; MSG SIZE rcvd: 145
```
**The SOA record is still here.**
Only after restarting BIND, then ```named``` will prevent sending the SOA record:
```
$ systemctl restart named
```
**Query the rpz-listed domain again:**
```
$ dig @test isc.org
; <<>> DiG 9.18.9 <<>> @test isc.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19144
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: a9e46dda3d5901550100000063997fd7ae33532ad2eb5235 (good)
;; QUESTION SECTION:
;isc.org. IN A
;; Query time: 16 msec
;; SERVER: 10.100.102.21#53(test) (UDP)
;; WHEN: Wed Dec 14 08:48:39 CET 2022
;; MSG SIZE rcvd: 64
```
### What is the current *bug* behavior?
Only a complete restart of named will cause the changes to take effect in a rpz configuration (at least for ```add-soa```).
### What is the expected *correct* behavior?
A simple ```rndc reload``` should be sufficient to cause the changes to take effect.
### Relevant configuration files
---
### Relevant logs and/or screenshots
---
### Possible fixes
---January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)Tony FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3739ADB cleans overzealously under memory pressure2023-01-17T13:51:44ZOndřej SurýADB cleans overzealously under memory pressureThis was found in ~"v9.19", but it applies to ~"v9.18" and ~"v9.16".
When the ADB is overmem, it can clean fetches that are fresh (with running fetches, etc...), see `check_stale_name()`.
The fix for ~"v9.19" will be different than fix...This was found in ~"v9.19", but it applies to ~"v9.18" and ~"v9.16".
When the ADB is overmem, it can clean fetches that are fresh (with running fetches, etc...), see `check_stale_name()`.
The fix for ~"v9.19" will be different than fix for ~"v9.18" and ~"v9.16", but the principle is the same.
NOTE: This is an intrusive change, so ~"v9.16" has been excluded from releases to fix.January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3737fix initialisation of local. in isdotlocal in dig2023-01-11T14:00:27ZMark Andrewsfix initialisation of local. in isdotlocal in digRemove the trailing '\0' as it shouldn't be there. The trailing `\0` in the definition just happens to work with dns_name_issubdomain so there is no operational impact.Remove the trailing '\0' as it shouldn't be there. The trailing `\0` in the definition just happens to work with dns_name_issubdomain so there is no operational impact.January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)https://gitlab.isc.org/isc-projects/bind9/-/issues/3735crash on shutdown: "rpz: reload start" did not finish yet2023-02-14T10:32:30ZPetr Špačekpspacek@isc.orgcrash on shutdown: "rpz: reload start" did not finish yet### Summary
`named` crashes if it is shutting down while
### BIND version used
- ~"Affects v9.19": BIND 9.19.8-dev: 9dea2b9
- I was not able to crash ~"v9.18": 9.18.10-dev 8b8c761 - seems that it has different timing, and also the re...### Summary
`named` crashes if it is shutting down while
### BIND version used
- ~"Affects v9.19": BIND 9.19.8-dev: 9dea2b9
- I was not able to crash ~"v9.18": 9.18.10-dev 8b8c761 - seems that it has different timing, and also the reaction to SIGINT does not interrupt rpz processing
- I was not able to crash ~"v9.16": 9.16.36-dev 5b16afa378c219d8a954272686fcc0ce0e116b36
For ~v9.16 and ~v9.18 the log looks like this:
```
09-Dec-2022 15:08:25.301 rpz: phish: reload start
^C09-Dec-2022 15:08:27.451 shutting down
09-Dec-2022 15:08:27.451 stopping command channel on 127.0.0.1#953
09-Dec-2022 15:08:28.161 rpz: phish: reload done
```
I.e. SIGINT does not seem to cut RPZ processing in the middle.
### Steps to reproduce
1. Start named
2. Wait for "rpz: <zone>: reload start" line to show up
3. SIGINT server _before_ it logs `rpz: <zone>: reload done: success`
4. Enjoy fireworks
### What is the current *bug* behavior?
```
db.c:581: REQUIRE(nodep != ((void *)0) && *nodep != ((void *)0)) failed, back trace
```
```
#2 0x00007f1a53ad353d in abort () from /usr/lib/libc.so.6
#3 0x0000560c3c7522fa in assertion_failed (file=0x7f1a54cae499 "db.c", line=581, type=isc_assertiontype_require, cond=0x7f1a54caead0 "nodep != ((void *)0) && *nodep != ((void *)0)") at main.c:237
#4 0x00007f1a54d5d2ab in isc_assertion_failed (file=0x7f1a54cae499 "db.c", line=581, type=isc_assertiontype_require, cond=0x7f1a54caead0 "nodep != ((void *)0) && *nodep != ((void *)0)") at assertions.c:49
#5 0x00007f1a54aa0632 in dns_db_detachnode (db=0x7f1a4de22000, nodep=0x7f19ee9fd7f0) at db.c:581
#6 0x00007f1a54bf702f in update_nodes (rpz=0x7f1a511e2380, newnodes=0x7f19ea400000) at rpz.c:1740
#7 0x00007f1a54bf7c16 in update_rpz_cb (data=0x7f1a511e2380) at rpz.c:1919
#8 0x00007f1a54d9eecd in isc__work_cb (req=0x7f1a4de12be0) at work.c:27
#9 0x00007f1a546fa726 in uv__queue_work (w=<optimized out>) at src/threadpool.c:326
#10 0x00007f1a546fa8a9 in worker (arg=0x0) at src/threadpool.c:122
```
100 % reproducible, just use large enough RPZ zone so the processing takes a bit of time.
### What is the expected *correct* behavior?
Does not crash.
### Relevant configuration files
```
options {
check-names primary ignore;
check-names secondary ignore;
recursion yes;
response-policy {
zone "phish" min-update-interval 1;
};
check-dup-records warn;
check-integrity no;
check-mx ignore;
check-mx-cname ignore;
check-sibling no;
check-spf ignore;
check-srv-cname ignore;
check-wildcard no;
notify no;
};
zone "phish" {
type primary;
file "phish";
};
```
### Relevant logs and/or screenshots
```
09-Dec-2022 14:51:17.481 rpz: phish: reload start
^C09-Dec-2022 14:51:18.444 no longer listening on 127.0.0.1#53
09-Dec-2022 14:51:18.811 no longer listening on 127.0.0.111#53
...
09-Dec-2022 14:51:18.811 shutting down
09-Dec-2022 14:51:18.811 db.c:581: REQUIRE(nodep != ((void *)0) && *nodep != ((void *)0)) failed, back trace
09-Dec-2022 14:51:18.811 /tmp/main/sbin/named(+0x2814c) [0x560c3c75214c]
09-Dec-2022 14:51:18.811 /tmp/main/lib/libisc-9.19.8-dev.so(isc_assertion_failed+0x31) [0x7f1a54d5d2ab]
09-Dec-2022 14:51:18.811 /tmp/main/lib/libdns-9.19.8-dev.so(dns_db_detachnode+0x7d) [0x7f1a54aa0632]
09-Dec-2022 14:51:18.811 /tmp/main/lib/libdns-9.19.8-dev.so(+0x1a902f) [0x7f1a54bf702f]
09-Dec-2022 14:51:18.811 /tmp/main/lib/libdns-9.19.8-dev.so(+0x1a9c16) [0x7f1a54bf7c16]
09-Dec-2022 14:51:18.811 /tmp/main/lib/libisc-9.19.8-dev.so(+0x7eecd) [0x7f1a54d9eecd]
09-Dec-2022 14:51:18.811 /usr/lib/libuv.so.1(+0x9726) [0x7f1a546fa726]
09-Dec-2022 14:51:18.811 /usr/lib/libuv.so.1(+0x98a9) [0x7f1a546fa8a9]
09-Dec-2022 14:51:18.811 /usr/lib/libc.so.6(+0x868fd) [0x7f1a53b378fd]
09-Dec-2022 14:51:18.811 /usr/lib/libc.so.6(+0x108a60) [0x7f1a53bb9a60]
09-Dec-2022 14:51:18.811 exiting (due to assertion failure)
```January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3731ThreadSanitizer: data race in zonemgr_keymgmt_delete()2023-01-03T09:06:25ZArаm SаrgsyаnThreadSanitizer: data race in zonemgr_keymgmt_delete()See this failed job: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2982394
The TSAN report is here: [tsan.named.32229](/uploads/0c139a7414ae109687c55d02431dec6e/tsan.named.32229).
This was most likely uncovered after #3727 was fixed...See this failed job: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2982394
The TSAN report is here: [tsan.named.32229](/uploads/0c139a7414ae109687c55d02431dec6e/tsan.named.32229).
This was most likely uncovered after #3727 was fixed, as before that the code under the "Delete the entry" comment in zone.c:zonemgr_keymgmt_delete() (see below) wasn't being executed:
```c
if (dns_name_equal(kfio->name, &zone->origin)) {
unsigned int count;
count = atomic_fetch_sub_relaxed(&kfio->count, 1) - 1;
if (count > 0) {
/* Keep the entry. */
break;
}
/* Delete the entry. */
if (prev == NULL) {
mgmt->table[hash] = kfio->next;
} else {
prev->next = kfio->next;
}
isc_mutex_destroy(&kfio->lock);
isc_mem_put(mgmt->mctx, kfio, sizeof(*kfio));
atomic_fetch_sub_relaxed(&mgmt->count, 1); // <---- the report is here
break;
}
```December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)Ondřej SurýOndřej Surý2022-12-09https://gitlab.isc.org/isc-projects/bind9/-/issues/3727dns_keyfileio_t objects are never released2022-12-08T16:09:38ZOndřej Surýdns_keyfileio_t objects are never releasedThere's off-by-one error in reference counting the dns_keyfileio_t objects, so they are never released.There's off-by-one error in reference counting the dns_keyfileio_t objects, so they are never released.December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3725TLS session resumption via session IDs leads to handshake errors when Mutual ...2023-01-03T08:58:48ZOndřej SurýTLS session resumption via session IDs leads to handshake errors when Mutual TLS (client certificate) is used~~When reusing the TLS context to the same endpoint, the previous connection has to be finished otherwise, the following error happens:~~
```
TLS error in tls_cycle_input: error:0A000115:SSL routines::session id context uninitialized
``...~~When reusing the TLS context to the same endpoint, the previous connection has to be finished otherwise, the following error happens:~~
```
TLS error in tls_cycle_input: error:0A000115:SSL routines::session id context uninitialized
```
~~This happens f.e. in the new dispatch where there's a little delay between tearing down the whole TLSDNS connection and starting up the new one.~~
After the investigation is turned out that in order to make TLS session resumption via session IDs work, we need to use `SSL[_CTX]_set_session_id_context()` function to initialise the session identifier within a server TLS context, otherwise we will get the error above.
*(excerpt from the `SSL[_CTX]_set_session_id_context()` documentation)*
> WARNINGS
> If the session id context is not set on an SSL/TLS server and client certificates are used, stored sessions will not be reused but a fatal error will be flagged and the handshake will fail.
As @aram found, there is a specialised check within OpenSSL specifically for that case:
```
if ((s->verify_mode & SSL_VERIFY_PEER) && s->sid_ctx_length == 0) {
/*
* We can't be sure if this session is being used out of context,
* which is especially important for SSL_VERIFY_PEER. The application
* should have used SSL[_CTX]_set_session_id_context. For this error
* case, we generate an error instead of treating the event like a
* cache miss (otherwise it would be easy for applications to
* effectively disable the session cache by accident without anyone
* noticing).
*/
SSLfatal(s, SSL_AD_INTERNAL_ERROR, SSL_F_SSL_GET_PREV_SESSION,
SSL_R_SESSION_ID_CONTEXT_UNINITIALIZED);
fatal = 1;
goto err;
}
```
Unfortunately, we have not been doing that. So, the first resumption attempt after a successful connection in case of Mutual TLS (when client certificates are used) will always fail.
So, the problem was not in the TLS context reuse per se, which is the only way to make TLS session resumption work, but in incomplete server TLS context initialisation procedure for that case.January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3724Update dig +tcp documentation2022-12-08T10:01:18ZMark AndrewsUpdate dig +tcp documentationAdd "To prevent retry over TCP when TC=1 is returned from a UDP query, use +ignore." to +tcp documentationAdd "To prevent retry over TCP when TC=1 is returned from a UDP query, use +ignore." to +tcp documentationDecember 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3723Assertion failure in isc_task_shutdown() in v9_18 when running the "stress" s...2023-01-11T10:54:49ZArаm SаrgsyаnAssertion failure in isc_task_shutdown() in v9_18 when running the "stress" system testSee https://gitlab.isc.org/isc-projects/bind9/-/jobs/2972150 (artifacts are saved).
```
D:stress:Program terminated with signal SIGABRT, Aborted.
D:stress:#0 0x00007ff96c95355c in __pthread_kill_implementation () from /lib64/libc.so.6
...See https://gitlab.isc.org/isc-projects/bind9/-/jobs/2972150 (artifacts are saved).
```
D:stress:Program terminated with signal SIGABRT, Aborted.
D:stress:#0 0x00007ff96c95355c in __pthread_kill_implementation () from /lib64/libc.so.6
D:stress:[Current thread is 1 (Thread 0x7ff96b7ff640 (LWP 1613))]
D:stress:#0 0x00007ff96c95355c in __pthread_kill_implementation () from /lib64/libc.so.6
D:stress:#1 0x00007ff96c906ce6 in raise () from /lib64/libc.so.6
D:stress:#2 0x00007ff96c8da7f3 in abort () from /lib64/libc.so.6
D:stress:#3 0x000000000042150c in assertion_failed (file=<optimized out>, line=<optimized out>, type=isc_assertiontype_require, cond=0x7ff96d518150 "((task) != ((void *)0) && ((const isc__magic_t *)(task))->magic == ((('T') << 24 | ('A') << 16 | ('S') << 8 | ('K'))))") at main.c:237
D:stress:#4 0x00007ff96d4d754b in isc_assertion_failed (file=file@entry=0x7ff96d517f1c "task.c", line=line@entry=726, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7ff96d518150 "((task) != ((void *)0) && ((const isc__magic_t *)(task))->magic == ((('T') << 24 | ('A') << 16 | ('S') << 8 | ('K'))))") at assertions.c:48
D:stress:#5 0x00007ff96d4f4e6d in isc_task_shutdown (task=<optimized out>) at task.c:726
D:stress:#6 0x00007ff96d3a5537 in dns_resolver_create (view=view@entry=0x7ff9500dc800, taskmgr=taskmgr@entry=0x7ff96bdf9000, ntasks=ntasks@entry=384, ndisp=ndisp@entry=16, nm=nm@entry=0x7ff96bc31000, timermgr=timermgr@entry=0x7ff96bdfa000, options=<optimized out>, dispatchmgr=<optimized out>, dispatchv4=<optimized out>, dispatchv6=<optimized out>, resp=<optimized out>) at resolver.c:10485
D:stress:#7 0x00007ff96d3de6da in dns_view_createresolver (view=view@entry=0x7ff9500dc800, taskmgr=0x7ff96bdf9000, ntasks=384, ndisp=16, nm=0x7ff96bc31000, timermgr=0x7ff96bdfa000, options=0, dispatchmgr=0x7ff9680fb000, dispatchv4=0x7ff9501e2200, dispatchv6=0x7ff9501e2400) at view.c:836
D:stress:#8 0x0000000000432ca6 in configure_view (view=0x7ff9500dc800, viewlist=viewlist@entry=0x7ff96b7f99d0, config=0x7ff968214820, vconfig=vconfig@entry=0x7ff9681fd940, cachelist=cachelist@entry=0x7ff96b7f9980, kasplist=kasplist@entry=0x7ff96af3e088, bindkeys=0x0, mctx=0x7ff96bc09000, actx=0x7ff9681950c0, need_hints=false) at server.c:4795
D:stress:#9 0x0000000000445512 in load_configuration (filename=<optimized out>, server=server@entry=0x7ff96af3e000, first_time=first_time@entry=false) at server.c:9395
D:stress:#10 0x0000000000446fd9 in loadconfig (server=server@entry=0x7ff96af3e000) at server.c:10516
D:stress:#11 0x00000000004470a2 in reload (server=server@entry=0x7ff96af3e000) at server.c:10539
D:stress:#12 0x0000000000447266 in named_server_reloadcommand (server=0x7ff96af3e000, lex=<optimized out>, text=text@entry=0x7ff928916ae8) at server.c:10866
D:stress:#13 0x000000000041c125 in named_control_docommand (message=<optimized out>, readonly=<optimized out>, text=text@entry=0x7ff928916ae8) at control.c:254
D:stress:#14 0x000000000041e79b in control_command (task=<optimized out>, event=<optimized out>) at controlconf.c:391
D:stress:#15 0x00007ff96d4f58cc in task_run (task=0x7ff96afa19c0) at task.c:823
D:stress:#16 isc_task_run (task=0x7ff96afa19c0) at task.c:904
D:stress:#17 0x00007ff96d4bdbc9 in isc__nm_async_task (worker=worker@entry=0x7ff96bc34700, ev0=ev0@entry=0x7ff9500b6400) at netmgr/netmgr.c:846
D:stress:#18 0x00007ff96d4c5379 in process_netievent (worker=worker@entry=0x7ff96bc34700, ievent=0x7ff9500b6400) at netmgr/netmgr.c:918
D:stress:#19 0x00007ff96d4c5d49 in process_queue (worker=worker@entry=0x7ff96bc34700, type=type@entry=NETIEVENT_TASK) at netmgr/netmgr.c:1011
D:stress:#20 0x00007ff96d4c67e9 in process_all_queues (worker=0x7ff96bc34700) at netmgr/netmgr.c:765
D:stress:#21 async_cb (handle=0x7ff96bc34a60) at netmgr/netmgr.c:794
D:stress:#22 0x00007ff96cca7b3d in uv.async_io.part () from /lib64/libuv.so.1
D:stress:#23 0x00007ff96ccc385e in uv.io_poll.part () from /lib64/libuv.so.1
D:stress:#24 0x00007ff96ccad5a8 in uv_run () from /lib64/libuv.so.1
D:stress:#25 0x00007ff96d4c6021 in nm_thread (worker0=0x7ff96bc34700) at netmgr/netmgr.c:696
D:stress:#26 0x00007ff96d4fdba1 in isc__trampoline_run (arg=0x2102bb0) at trampoline.c:189
D:stress:#27 0x00007ff96c951812 in start_thread () from /lib64/libc.so.6
D:stress:#28 0x00007ff96c8f1314 in clone () from /lib64/libc.so.6
D:stress:--------------------------------------------------------------------------------
D:stress:full backtrace from stress/ns3/core.1599 saved in stress/ns3/core.1599-backtrace.txt
D:stress:core dump stress/ns3/core.1599 archived as stress/ns3/core.1599.gz
R:stress:FAIL
```January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)https://gitlab.isc.org/isc-projects/bind9/-/issues/3722Back-port GL #3386 (Do not keep stale NXDOMAIN answers in cache) to BIND 9.182022-12-08T13:07:48ZCathy AlmondBack-port GL #3386 (Do not keep stale NXDOMAIN answers in cache) to BIND 9.18We did this in BIND 9.19, and whilst I think it a bit too much of a change for 9.16, I would really like to see [#3386](https://gitlab.isc.org/isc-projects/bind9/-/issues/3386) in BIND 9.18 before or as it becomes an ESV. This should ha...We did this in BIND 9.19, and whilst I think it a bit too much of a change for 9.16, I would really like to see [#3386](https://gitlab.isc.org/isc-projects/bind9/-/issues/3386) in BIND 9.18 before or as it becomes an ESV. This should have a significant impact on excessive cache bloat in environments with 'stale-cache-enable yes'
No one specific customer, but we encounter cache bloat a lot, and oft-times the bulk is negative content for various reasons. Adding generic stale-ttl to max-ncache-ttl negates the advantages of setting a cap on the TTL of negative content.
We discussed this in one of the engineering meeting and thought it would be a good idea - but I realise now, it never got actioned ...December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/3721The nslookup command does not obey the port option when record type ANY is used.2022-12-23T08:53:06ZMarcus KoolThe nslookup command does not obey the port option when record type ANY is used.<!--
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
The nslookup command does not obey the port option when record type ANY is used.
With record type A the port option is used but with ANY it is not.
### BIND version used
Ubuntu 20.04 with bind 9.16.1+patches and Ubuntu 22.04 with bind 9.18.1+patches
### Steps to reproduce
Configure a name server with udp/tcp port 54.
run nslookup -port 54 or nslookup interactive and use 'set port=54'
query type A record for sex.com.
query type ANY record for sex.com.
### What is the current *bug* behavior?
On Ubuntu 20.04 with bind 9.16.1+patches and Ubuntu 22.04 with bind 9.18.1+patches the bug
has different behaviour.
9.16.1 nslookup simply always use port 53 no matter if the -port option of 'set port=' is used.
Note that the used nameserver with port 54 is bind 9.16.1 with a plugin that sends rcode REFUSED for sex.com.
This should not matter since the bug is in the nslookup client.
```
nslookup -timeout=2 -retry=0 -port=54 sex.com 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#**54**
** server can't find sex.com: REFUSED
root@srv024:/local/src/ufdbguard-bind-1.0.0# nslookup -timeout=2 -retry=0 -port=54 -type=**A** sex.com 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#**54**
** server can't find sex.com: REFUSED
root@srv024:/local/src/ufdbguard-bind-1.0.0# nslookup -timeout=2 -retry=0 -port=54 -type=**ANY** sex.com 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#**53**
Non-authoritative answer:
sex.com hinfo = "RFC8482" ""
sex.com nameserver = ligia.ns.cloudflare.com.
sex.com nameserver = aaron.ns.cloudflare.com.
```
9.18.1 nslookup displays a mix of ports (53 and 54). Apparently uses the alternate port
and nslookup dumps core when the nameserver replies with rcode REFUSED.
```
# nslookup
> server 10.1.1.24
Default server: 10.1.1.24
Address: 10.1.1.24#53
> set port=54
> sex.com
Server: 10.1.1.24
Address: 10.1.1.24#**54**
** server can't find sex.com: REFUSED
> set type=ANY
> sex.com
;; Connection to 10.1.1.24#**53**(10.1.1.24) for sex.com failed: connection refused.
;; Connection to 10.1.1.24#**53**(10.1.1.24) for sex.com failed: connection refused.
;; Connection to 10.1.1.24#**53**(10.1.1.24) for sex.com failed: connection refused.
task.c:811: INSIST((task->events).head != (event)) failed, back trace
/lib/x86_64-linux-gnu/libisc-9.18.1-1ubuntu1.2-Ubuntu.so(+0x32073)[0x7f5b335a6073]
/lib/x86_64-linux-gnu/libisc-9.18.1-1ubuntu1.2-Ubuntu.so(isc_assertion_failed+0x10)[0x7f5b335a5560]
/lib/x86_64-linux-gnu/libisc-9.18.1-1ubuntu1.2-Ubuntu.so(isc_task_run+0x422)[0x7f5b335cdcd2]
/lib/x86_64-linux-gnu/libisc-9.18.1-1ubuntu1.2-Ubuntu.so(+0x2572d)[0x7f5b3359972d]
/lib/x86_64-linux-gnu/libisc-9.18.1-1ubuntu1.2-Ubuntu.so(+0x25e05)[0x7f5b33599e05]
/lib/x86_64-linux-gnu/libisc-9.18.1-1ubuntu1.2-Ubuntu.so(+0x265b7)[0x7f5b3359a5b7]
/lib/x86_64-linux-gnu/libuv.so.1(+0x91ed)[0x7f5b330681ed]
/lib/x86_64-linux-gnu/libuv.so.1(+0x2511e)[0x7f5b3308411e]
/lib/x86_64-linux-gnu/libuv.so.1(uv_run+0x678)[0x7f5b3306dc88]
/lib/x86_64-linux-gnu/libisc-9.18.1-1ubuntu1.2-Ubuntu.so(+0x25e9e)[0x7f5b33599e9e]
/lib/x86_64-linux-gnu/libisc-9.18.1-1ubuntu1.2-Ubuntu.so(isc__trampoline_run+0x1a)[0x7f5b335c986a]
/lib/x86_64-linux-gnu/libc.so.6(+0x94b43)[0x7f5b33125b43]
/lib/x86_64-linux-gnu/libc.so.6(+0x126a00)[0x7f5b331b7a00]
Aborted (core dumped)
```
### What is the expected *correct* behavior?
obey -port flag and 'set port=xx' with all record types, including ANY.
### Relevant configuration files
none
### Relevant logs and/or screenshots
none
### Possible fixes
noneDecember 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/3710ARM 9.18.9: Setting DF-Flag for outbound UDP packets is wrong documented2023-04-03T10:31:37ZThomas AmgartenARM 9.18.9: Setting DF-Flag for outbound UDP packets is wrong documented### Summary
ARM 9.18.9: DF-Flag for outbound UDP packets is wrong documented. As agreed on https://lists.isc.org/pipermail/bind-users/2022-November/107021.html, at least the following phrase in https://bind9.readthedocs.io/en/v9_18_9/ref...### Summary
ARM 9.18.9: DF-Flag for outbound UDP packets is wrong documented. As agreed on https://lists.isc.org/pipermail/bind-users/2022-November/107021.html, at least the following phrase in https://bind9.readthedocs.io/en/v9_18_9/reference.html#namedconf-statement-edns-udp-size is no more correct:
> The named now sets the DON’T FRAGMENT flag on outgoing UDP packets.
Setting the DF-Flag (DON'T FRAGMENT) on the IP header for outbound UDP packets seems to be reverted in https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4668/diffs, so the corresponding text should be adjusted.
### BIND version used
ARM 9.18.9
### Steps to reproduce
--
### What is the current *bug* behavior?
--
### What is the expected *correct* behavior?
--
### Relevant configuration files
--
### Relevant logs and/or screenshots
--
### Possible fixes
--April 2023 (9.16.40, 9.16.40-S1, 9.18.14, 9.18.14-S1, 9.19.12)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3707named-checkzone change of behaviour in 9.16.352022-12-21T02:37:50ZThib Dnamed-checkzone change of behaviour in 9.16.35### Summary
Hello,
Not sure this is a bug of feature change, but since it wasn't mentioned in the changelog I believe this was not expected:
named-checkzone text output has changed in 9.16.35 (haven't tested on other new branches).
I...### Summary
Hello,
Not sure this is a bug of feature change, but since it wasn't mentioned in the changelog I believe this was not expected:
named-checkzone text output has changed in 9.16.35 (haven't tested on other new branches).
I believe this comes from this commit : https://gitlab.isc.org/isc-projects/bind9/-/commit/80e66fbd2d8a6dc581387116288f5d5c5cbcb0f6
### BIND version used
9.16.35
### Steps to reproduce
Run named-checkzone on a valid zone.
### What is the current *bug* behavior?
With 9.16.35 :
```
named-checkzone example.com named.example.com
zone example.com/IN: loaded serial 2022113010
OK
zone example.com/IN: final reference detached
```
### What is the expected *correct* behavior?
With 9.16.34 :
```
named-checkzone example.com named.example.com
zone example.com/IN: loaded serial 2022113010
OK
```
Not sure this line is relevant when performing a checkzone, and I'm pretty sure there are a few systems that use named-checkzone are parsing the output when running checkzones.
Best regards,
ThibaudDecember 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/3702man page dig(1): Typo in options2022-12-02T11:39:31ZFabian P. Schmidtman page dig(1): Typo in optionsIn https://gitlab.isc.org/isc-projects/bind9/-/commit/ac0c2378cac7039afb8c717ca9038b1f70681ff3 a typo was introduced in the man page of dig(1) ([line 868](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/man/dig.1in#L868)):
> >...In https://gitlab.isc.org/isc-projects/bind9/-/commit/ac0c2378cac7039afb8c717ca9038b1f70681ff3 a typo was introduced in the man page of dig(1) ([line 868](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/man/dig.1in#L868)):
> > dig +qr www.isc.org any -x 127.0.0.1 isc.org ns **+noqr**
>
> shows how dig can be used from the command line to make three lookups: an ANY query for www.isc.org, a reverse lookup of 127.0.0.1, and a query for the NS records of isc.org. A global query option
> of +qr is applied, so that dig shows the initial query it made for each lookup. The final query has a local query option of **+qr** which means that dig does not print the initial query when it looks up
> the NS records for isc.org.
The second location emphasized in bold should link to `+noqr`.
## Solution
Patch attached:
[0001-Fix-noqr-option-typo-in-dig-1-man-page.patch](/uploads/91fe65e154371b415875914efb70ec96/0001-Fix-noqr-option-typo-in-dig-1-man-page.patch)
If you would like to see this patch submitted directly as a merge request, I'd kindly request the permission to create my fork of the repo on the ISC gitlab server.December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/3700consider deprecating "dialup" option2023-08-04T09:42:20ZPetr Špačekpspacek@isc.orgconsider deprecating "dialup" optionIt is unclear if [dialup](https://bind9.readthedocs.io/en/v9_19_7/reference.html#namedconf-statement-dialup) statement is useful in practice, and at the same time it adds fair amount of logic to zone refresh/notify handling.
Consider th...It is unclear if [dialup](https://bind9.readthedocs.io/en/v9_19_7/reference.html#namedconf-statement-dialup) statement is useful in practice, and at the same time it adds fair amount of logic to zone refresh/notify handling.
Consider the fun of finding out how following flags interact:
`lib/dns/zone.c`:
```c
19964 void
19965 dns_zone_setdialup(dns_zone_t *zone, dns_dialuptype_t dialup) {
19966 REQUIRE(DNS_ZONE_VALID(zone));
19967
19968 LOCK_ZONE(zone);
19969 DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_DIALNOTIFY |
19970 DNS_ZONEFLG_DIALREFRESH |
19971 DNS_ZONEFLG_NOREFRESH);
19972 switch (dialup) {
19973 case dns_dialuptype_no:
19974 break;
19975 case dns_dialuptype_yes:
19976 DNS_ZONE_SETFLAG(zone, (DNS_ZONEFLG_DIALNOTIFY |
19977 DNS_ZONEFLG_DIALREFRESH |
19978 DNS_ZONEFLG_NOREFRESH));
19979 break;
19980 case dns_dialuptype_notify:
19981 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_DIALNOTIFY);
19982 break;
19983 case dns_dialuptype_notifypassive:
19984 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_DIALNOTIFY);
19985 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_NOREFRESH);
19986 break;
19987 case dns_dialuptype_refresh:
19988 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_DIALREFRESH);
19989 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_NOREFRESH);
19990 break;
19991 case dns_dialuptype_passive:
19992 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_NOREFRESH);
19993 break;
19994 default:
19995 UNREACHABLE();
19996 }
19997 UNLOCK_ZONE(zone);
19998 }
```August 2023 (9.16.43, 9.16.43-S1, 9.18.18, 9.18.18-S1, 9.19.16)https://gitlab.isc.org/isc-projects/bind9/-/issues/3699Hang on shutdown in the "tcp" system test2023-08-07T09:16:17ZMichał KępieńHang on shutdown in the "tcp" system testThe `tcp` system test fails fairly often as it puts quite a bit of
strain on the test host, so this [job][1] might not *have* to be a hang,
but the backtrace seems to be a match:
```
D:tcp:#0 0x00007f1ce8f765be in pthread_barrier_wait ...The `tcp` system test fails fairly often as it puts quite a bit of
strain on the test host, so this [job][1] might not *have* to be a hang,
but the backtrace seems to be a match:
```
D:tcp:#0 0x00007f1ce8f765be in pthread_barrier_wait () from /lib64/libpthread.so.0
D:tcp:[Current thread is 1 (Thread 0x7f1cecac22c0 (LWP 22507))]
D:tcp:#0 0x00007f1ce8f765be in pthread_barrier_wait () from /lib64/libpthread.so.0
D:tcp:#1 0x00007f1cea0aca7d in uv_barrier_wait () from /lib64/libuv.so.1
D:tcp:#2 0x00007f1cec14c414 in isc__nm_async_tcpdnsstop (worker=worker@entry=0x7f1ce5276000, ev0=ev0@entry=0x7f1ce4b7d800) at netmgr/tcpdns.c:670
D:tcp:#3 0x00007f1cec146a92 in process_netievent (arg=0x7f1ce4b7d800) at netmgr/netmgr.c:463
D:tcp:#4 0x00007f1cec146db3 in isc__nm_process_ievent (worker=<optimized out>, event=<optimized out>) at netmgr/netmgr.c:567
D:tcp:#5 0x00007f1cec14b585 in stop_tcpdns_child (sock=sock@entry=0x7f1ce53eac00, tid=tid@entry=0) at netmgr/tcpdns.c:605
D:tcp:#6 0x00007f1cec14bed4 in isc__nm_tcpdns_stoplistening (sock=0x7f1ce53eac00) at netmgr/tcpdns.c:632
D:tcp:#7 0x00007f1cec143356 in isc_nm_stoplistening (sock=<optimized out>) at netmgr/netmgr.c:2091
D:tcp:#8 0x00007f1cebae0559 in ns_interface_shutdown (ifp=ifp@entry=0x7f1ce528a500) at interfacemgr.c:742
D:tcp:#9 0x00007f1cebae08d9 in purge_old_interfaces (mgr=mgr@entry=0x7f1ce53d3460) at interfacemgr.c:828
D:tcp:#10 0x00007f1cebae0b8b in ns_interfacemgr_shutdown (mgr=0x7f1ce53d3460) at interfacemgr.c:447
D:tcp:#11 0x000000000044288a in shutdown_server (task=<optimized out>, event=<optimized out>) at server.c:10124
D:tcp:#12 0x00007f1cec178944 in task_run (task=<optimized out>, task@entry=0x7f1ce5225e80) at task.c:470
D:tcp:#13 0x00007f1cec178a85 in task__run (arg=0x7f1ce5225e80) at task.c:287
D:tcp:#14 0x00007f1cec160bf4 in isc__job_cb (idle=0x7f1ce52236c8) at job.c:75
D:tcp:#15 0x00007f1cea0a6a49 in uv.run_idle () from /lib64/libuv.so.1
D:tcp:#16 0x00007f1cea09fbf8 in uv_run () from /lib64/libuv.so.1
D:tcp:#17 0x00007f1cec166d31 in loop_run (loop=0x7f1ce52a1e40) at loop.c:270
D:tcp:#18 loop_thread (arg=0x7f1ce52a1e40) at loop.c:297
D:tcp:#19 0x00007f1cec167dd3 in isc_loopmgr_run (loopmgr=0x7f1ce5223540) at loop.c:477
D:tcp:#20 0x00000000004238e0 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1545
```
I do not recall seeing this particular backtrace before, so I assumed it
makes sense to at least retain job artifacts and have this problem
catalogued as a GitLab issue.
Perhaps a total red herring, but `isc__nm_async_tcpdnsstop()` is also
present in the backtrace for one of the threads in a failed unit test
job reported [elsewhere][2], which also happened on Oracle Linux 8.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2935216
[2]: https://gitlab.isc.org/isc-projects/bind9/-/issues/3642Not planned