BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2022-01-11T14:18:57Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3056TLS/HTTPS interfaces should only be shut down when reconfiguring2022-01-11T14:18:57ZEvan HuntTLS/HTTPS interfaces should only be shut down when reconfiguringAfter #3053 was merged, scanning interfaces became a destructive process - whenever there's a change to the listening interfaces, all TLS and HTTPS listeners are shut down and recreated. This was only meant to happen when the server was ...After #3053 was merged, scanning interfaces became a destructive process - whenever there's a change to the listening interfaces, all TLS and HTTPS listeners are shut down and recreated. This was only meant to happen when the server was being reconfigured, and we need to fix it so that's the only time it does happen.January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3055interface scanning happens much too often2022-01-11T14:37:05ZEvan Huntinterface scanning happens much too oftenThe route socket is supposed to detect changes in configured interfaces by listening for `RTM_NEWADDR` and `RTM_DELADDR` messages; these messages trigger a call to `ns_interface_scan()` which causes the listening interfaces to be updated...The route socket is supposed to detect changes in configured interfaces by listening for `RTM_NEWADDR` and `RTM_DELADDR` messages; these messages trigger a call to `ns_interface_scan()` which causes the listening interfaces to be updated.
On my system, such messages are sent every few seconds, and there seems to be one for each configured address on the system. So in the log I see bursts that look like this:
```
14-Dec-2021 00:05:02.196 route_recv: success
14-Dec-2021 00:05:02.200 route_recv: success
14-Dec-2021 00:05:02.200 route_recv: success
14-Dec-2021 00:05:02.200 route_recv: success
14-Dec-2021 00:05:02.200 route_recv: success
14-Dec-2021 00:05:02.200 route_recv: success
14-Dec-2021 00:05:02.204 route_recv: success
14-Dec-2021 00:05:02.204 route_recv: success
14-Dec-2021 00:05:02.204 route_recv: success
14-Dec-2021 00:05:02.204 route_recv: success
14-Dec-2021 00:05:02.308 route_recv: success
14-Dec-2021 00:05:02.308 route_recv: success
14-Dec-2021 00:05:02.312 route_recv: success
14-Dec-2021 00:05:02.312 route_recv: success
14-Dec-2021 00:05:02.312 route_recv: success
14-Dec-2021 00:05:02.316 route_recv: success
14-Dec-2021 00:05:02.316 route_recv: success
14-Dec-2021 00:05:02.316 route_recv: success
14-Dec-2021 00:05:02.316 route_recv: success
14-Dec-2021 00:05:02.320 route_recv: success
```
... and *each* of those causes the interfaces to be re-scanned. And then it happens again 3-5 seconds later.
This wasn't a fatal error until #3053 was merged, which caused re-scanning of interfaces to be destructive - each of those events will cause TLS and HTTPS interfaces to be shut down and recreated. But that's a separate bug I'll report it as a separate issue. (#3056)January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3048The hp_max_threads initial value is maximum value2022-01-20T10:21:45ZOndřej SurýThe hp_max_threads initial value is maximum valueIn a011d422117, the `isc_hp_init()` was changed, so the maximum number of threads cannot ever go down, only up. At the same time the initial value of `isc__hp_max_threads` is set to the maximum, so in the end, it's always the maximum (`...In a011d422117, the `isc_hp_init()` was changed, so the maximum number of threads cannot ever go down, only up. At the same time the initial value of `isc__hp_max_threads` is set to the maximum, so in the end, it's always the maximum (`128` threads).
Related issue: #2398January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3042TCP dispatch can still hang with non-matching response2022-01-11T14:14:49ZEvan HuntTCP dispatch can still hang with non-matching responseWhile testing a fix for #3040 @michal observed another shutdown hang, which turned out to be a missed case from #3026. A TCP dispatch resumes listening after receiving a response by calling `dispatch_getnext()`, and then the response cal...While testing a fix for #3040 @michal observed another shutdown hang, which turned out to be a missed case from #3026. A TCP dispatch resumes listening after receiving a response by calling `dispatch_getnext()`, and then the response callback sees that the response didn't match the question and calls `dns_dispatch_getnext()`, which uselessly calls `dispatch_getnext()` again, bumping the dispatch reference count.
This can currently be observed with the query:
`dig @localhost -x 74.213.100.99`
The delegation to 74.in-addr.arpa is lame, all servers are responding with REFUSED. This leads to the following being logged:
```
02-Dec-2021 10:45:37.815 received packet from 24.138.252.19#53
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 19192
;; flags: qr; QUESTION: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
02-Dec-2021 10:45:37.815 DNS format error from 24.138.252.19#53 resolving 99.100.213.74.in-addr.arpa/PTR for 127.0.0.1#41988: empty question section
02-Dec-2021 10:45:37.815 fctx 0x7f30ed826000(99.100.213.74.in-addr.arpa/PTR): [result: FORMERR] response did not match question
02-Dec-2021 10:45:37.815 fctx 0x7f30ed826000(99.100.213.74.in-addr.arpa/PTR): [result: FORMERR] query canceled in rctx_done(); responding
```
It looks to me like the best fix is to make `dispatch_getnext()` idempotent.January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3041Decide what to do with reject-000 and other obscure options for synth-from-dn...2021-12-23T05:14:57ZPetr Špačekpspacek@isc.orgDecide what to do with reject-000 and other obscure options for synth-from-dnssec featureThe following discussions from !5446 should be addressed:
Should we have obscure options like `reject-000` and company? They were merged into 9.18.0rc1 in interest of time, so now we can discuss calmly with more time.
- [ ] @pspacek st...The following discussions from !5446 should be addressed:
Should we have obscure options like `reject-000` and company? They were merged into 9.18.0rc1 in interest of time, so now we can discuss calmly with more time.
- [ ] @pspacek started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5446#note_251408): (+17 comments)
- [ ] @pspacek started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5446#note_251760): (+4 comments)January 2022 (9.16.25, 9.16.25-S1, 9.17.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/3010ThreadSanitizer: data race in closedir2021-12-23T14:43:22ZMichal NowakThreadSanitizer: data race in closedirSame issue as isc-projects/bind9#2457 [this time on Debian 11 with Clang](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2094359):
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 closed...Same issue as isc-projects/bind9#2457 [this time on Debian 11 with Clang](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2094359):
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 closedir <null>
#1 isc_dir_close lib/isc/dir.c:134:8
#2 dns_dnssec_findmatchingkeys lib/dns/dnssec.c:1514:3
#3 zone_rekey lib/dns/zone.c:21567:11
#4 zone_maintenance lib/dns/zone.c:11386:4
#5 zone_timer lib/dns/zone.c:15039:2
#6 task_run lib/isc/task.c:827:5
#7 isc_task_run lib/isc/task.c:907:10
#8 isc__nm_async_task lib/isc/netmgr/netmgr.c:834:11
#9 process_netievent lib/isc/netmgr/netmgr.c
#10 process_queue lib/isc/netmgr/netmgr.c:1007:16
#11 process_all_queues lib/isc/netmgr/netmgr.c:753:25
#12 async_cb lib/isc/netmgr/netmgr.c:782:6
#13 <null> <null>
#14 isc__trampoline_run lib/isc/trampoline.c:185:11
Previous read of size 8 at 0x000000000001 by thread T2:
#0 epoll_ctl <null>
#1 <null> <null>
#2 uv_run <null>
#3 isc__trampoline_run lib/isc/trampoline.c:185:11
Location is file descriptor 105 created by thread T2 at:
#0 accept4 <null>
#1 <null> <null>
#2 isc__trampoline_run lib/isc/trampoline.c:185:11
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/thread.c:79:8
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:328:3
#3 isc_managers_create lib/isc/managers.c:36:2
#4 create_managers bin/named/main.c:920:11
#5 setup bin/named/main.c:1184:11
#6 main bin/named/main.c:1452:2
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/thread.c:79:8
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:328:3
#3 isc_managers_create lib/isc/managers.c:36:2
#4 create_managers bin/named/main.c:920:11
#5 setup bin/named/main.c:1184:11
#6 main bin/named/main.c:1452:2
SUMMARY: ThreadSanitizer: data race in closedir
```
A blocker for base image upgrade from Debian 10 to Debian 11 (isc-projects/bind9!5367).
The solution is to have custom libuv for Debian 11 as have for Fedora already (https://gitlab.isc.org/isc-projects/images/-/merge_requests/112/diffs?commit_id=dd3c9f1d49f98a8d3584ef73478da8e9fdc2fd84).January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2977Add system with OpenSSL 3.0.0 to CI2022-01-04T09:03:35ZMark AndrewsAdd system with OpenSSL 3.0.0 to CIRequired for isc-projects/bind9!5385.Required for isc-projects/bind9!5385.January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2264Use ECDSA P-256 instead of 4096-bit RSA for 'tls ephemeral'2022-01-26T11:33:41ZOndřej SurýUse ECDSA P-256 instead of 4096-bit RSA for 'tls ephemeral'The following discussion from !3532 should be addressed:
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3532#note_175394):
> This should really be ECCThe following discussion from !3532 should be addressed:
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3532#note_175394):
> This should really be ECCJanuary 2022 (9.16.25, 9.16.25-S1, 9.17.22)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3108bind9 fails to start on machines where glibc does not provide L1 cache size2022-02-25T13:19:31ZDustin L. Howettbind9 fails to start on machines where glibc does not provide L1 cache size### Summary
There are machines where sysconf() cannot return a value for the L1 cache size, so it returns `0`.
### BIND version used
```
# named -V
os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed
Aborted
```
Based...### Summary
There are machines where sysconf() cannot return a value for the L1 cache size, so it returns `0`.
### BIND version used
```
# named -V
os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed
Aborted
```
Based on my package manager, I believe this is bind9-9.17.22.
### Steps to reproduce
Run bind9-9.17.22 on arm32.
### What is the current *bug* behavior?
The change in https://gitlab.isc.org/isc-projects/bind9/-/commit/4f78f9d72a5dc3f6a596251e662d00cb80cd5e6d introduced a runtime assert that the compiled-in cache line size matches the runtime one.
However, on 32-bit ARM machines, glibc will not report an L1 cache line size. It appears as though sysconf() is not implemented specifically in glibc's ARM port.
It falls through to the implementation [here](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/posix/sysconf.c;h=8b74ad6184cc724b2291c35249021a059e331fcc;hb=HEAD#l1170), which returns `0`.¹
Unfortunately, this all happens after (1) we check whether sysconf is available and (2) we check whether `_SC_LEVEL1_DCACHE_LINESIZE` is available. It is available, but wrong.
¹I don't understand why it returns `0` when the documented return value in a failure is `-1`. This is discussed briefly on the [binutils mailing list](https://binutils.sourceware.narkive.com/FAQQWMTY/are-syconf-sc-xxx-issues-glibc-or-kernel-issues).
### What is the expected *correct* behavior?
`named`, `dig`, ... run.
### Relevant configuration files
None - this happens in early startup regardless of config.
### Relevant logs and/or screenshots
```
root@deneb:~# named -V
os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed
Aborted
root@deneb:~# dig @localhost google.com
os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed
Aborted
root@deneb:~# nslookup howett.net
os.c:84: fatal error: RUNTIME_CHECK((size_t)s == (size_t)64) failed
Aborted
```January 2022 (9.18.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/3087ephemeral TLS certificate incompatible with GnuTLS and NSS libraries2022-01-27T05:30:45ZPetr Špačekpspacek@isc.orgephemeral TLS certificate incompatible with GnuTLS and NSS libraries### Summary
It seems that GnuTLS and NSS libraries do not accept ephemeral TLS certificate we generate internally in `named`.
### BIND version used
* ~"Affects v9.17": 47a9915888b188d9e612b0f79e71cf72b84b511c
* openssl 1.1.1.m-1
* gnu...### Summary
It seems that GnuTLS and NSS libraries do not accept ephemeral TLS certificate we generate internally in `named`.
### BIND version used
* ~"Affects v9.17": 47a9915888b188d9e612b0f79e71cf72b84b511c
* openssl 1.1.1.m-1
* gnutls 3.7.2-2
* firefox 95.0.2-1
Arch Linux, 64-bit x86_64.
### Steps to reproduce
* Configure BIND to use ephemeral TLS certificate: [named.conf](/uploads/8b4f1cc392a72a994987eaf91a914bd9/named.conf) (It does not matter if it is DoT or DoH.)
* Try to connect to BIND over TLS using GnuTLS or Firefox (NSS) libraries.
### What is the current *bug* behavior?
* GnuTLS reports:
```
$ gnutls-cli --no-ca-verification 127.0.0.1:4433
Connecting to '127.0.0.1:4433'...
*** Fatal error: Error in parsing.
```
* Firefox reports:
```
An error occurred during a connection to 127.0.0.1:4433. Peer’s certificate has an invalid signature.
Error code: SEC_ERROR_BAD_SIGNATURE
```
### What is the expected *correct* behavior?
Well, all usual libraries should be able to use the cert.
### Relevant configuration files
[named.conf](/uploads/8b4f1cc392a72a994987eaf91a914bd9/named.conf)
### Relevant logs and/or screenshots
GnuTLS debug log: [gnutls.log](/uploads/6aacb4ce6290a1435c3480a2f0607e90/gnutls.log) (generated using -d 999)
PCAP: [pcap](/uploads/d131de40ea1fde80b1a3c2035d03edae/pcap)
pre-master secrets: [tlskeys](/uploads/9eed6628650cfb01afb986e23f7201c4/tlskeys)January 2022 (9.18.0)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/858Use configured paths in documentation2023-11-03T07:42:59ZOndřej SurýUse configured paths in documentationCurrently, the documentation contains stuff like this:
> This creates a file <filename>rndc.key</filename>
> in <filename>/usr/local/etc</filename> (or whatever
> <varname>sysconfdir</varname>
> was specified as when <acronym>BIND</acro...Currently, the documentation contains stuff like this:
> This creates a file <filename>rndc.key</filename>
> in <filename>/usr/local/etc</filename> (or whatever
> <varname>sysconfdir</varname>
> was specified as when <acronym>BIND</acronym> was
> built)
while it should really use the paths configure via autoconf.January 2022 (9.18.0)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3095Invalid recvmmsg detection2022-01-21T07:43:23ZOndřej SurýInvalid recvmmsg detectionThe code in `netmgr/udp.c` uses `#ifdef` for checking whether the `recvmmsg` in libuv is available. But because the checked symbols are actually `enum` members and not preprocessor macros, the checks are always false effectively renderi...The code in `netmgr/udp.c` uses `#ifdef` for checking whether the `recvmmsg` in libuv is available. But because the checked symbols are actually `enum` members and not preprocessor macros, the checks are always false effectively rendering the `recvmmsg` support enabled only with libuv >= 1.35.0 where implicit `recvmmsg` support was added and << 1.37.0 where the `recvmmsg` use needs to be explicitly enabled with a flag to `uv_udp_init_ex()`.January 2022 (9.18.0)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3093"unable to convert libuv error code" on Dragonfly BSD2022-04-27T10:14:29ZMichal Nowak"unable to convert libuv error code" on Dragonfly BSDAbout a dozen system tests fail on Dragonfly BSD 6.2.1 because `dig` fails in `netmgr/tcp.c` with `unable to convert libuv error code in tcp_connect_direct to isc_result: -45: operation not supported on socket` on `main`, e.g.:
```
$ ../...About a dozen system tests fail on Dragonfly BSD 6.2.1 because `dig` fails in `netmgr/tcp.c` with `unable to convert libuv error code in tcp_connect_direct to isc_result: -45: operation not supported on socket` on `main`, e.g.:
```
$ ../../dig/dig -p 5300 +tcp @10.53.0.2 -6 +mapped A a.example
netmgr/tcpdns.c:151: unable to convert libuv error code in tcpdns_connect_direct to isc_result: -45: operation not supported on socket
;; Connection to ::ffff:10.53.0.2#5300(::ffff:10.53.0.2) for a.example failed: unexpected error.
netmgr/tcpdns.c:151: unable to convert libuv error code in tcpdns_connect_direct to isc_result: -45: operation not supported on socket
;; Connection to ::ffff:10.53.0.2#5300(::ffff:10.53.0.2) for a.example failed: unexpected error.
netmgr/tcpdns.c:151: unable to convert libuv error code in tcpdns_connect_direct to isc_result: -45: operation not supported on socket
;; Connection to ::ffff:10.53.0.2#5300(::ffff:10.53.0.2) for a.example failed: unexpected error.
[newman@dragonflybsd ~/bind9/bin/tests/system]$ scp digdelv.log newman@192.168.122.1:Downloads/
```
[digdelv.log](/uploads/74a1603a1b04ba511e26be85c342c80c/digdelv.log)January 2022 (9.18.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/3080`rndc` sometimes crashes when it's interrupted by a signal2022-11-02T17:11:04ZPetr Špačekpspacek@isc.org`rndc` sometimes crashes when it's interrupted by a signal### Summary
`rndc` sometimes crashes when it's interrupted by a signal
### BIND version used
* ~"Affects v9.17" : ca1a664005f849eb5720192832e7b283b480198b
* ~"Affects v9.16" : ebec9c701a9f7676becbf6304ff06edd63a9af78
### Steps to rep...### Summary
`rndc` sometimes crashes when it's interrupted by a signal
### BIND version used
* ~"Affects v9.17" : ca1a664005f849eb5720192832e7b283b480198b
* ~"Affects v9.16" : ebec9c701a9f7676becbf6304ff06edd63a9af78
### Steps to reproduce
* configure control channel: `rndc-confgen -a`
* run `named` with an arbitrary configuration, `-c /dev/null`
* run `rndc` in a loop, signal to terminate in short time so it is likely to get interrupted in the middle of operation:
```
while true; do timeout 0.01 rndc flush; done
```
* play with 0.01 timeout to find a fit for your machine
### What is the current *bug* behavior?
`rndc` crashes:
~"Affects v9.17" :
```
rndc: connect failed: 127.0.0.1#953: shutting down
task.c:721: REQUIRE(((task) != ((void *)0) && ((const isc__magic_t *)(task))->magic == ((('T') << 24 | ('A') << 16 | ('S') << 8 | ('K'))))) failed, back trace
```
~"Affects v9.16" :
```
task.c:293: INSIST(__v > 0 && __v < (4294967295U)) failed, back trace
```
### What is the expected *correct* behavior?
Well, it should not crash :-)
### Relevant configuration files
None.
### Relevant logs and/or screenshots
gdb back trace ~"Affects v9.17" :
<details>
```
(gdb) bt
#0 0x00007fac6c407d22 in raise () from /usr/lib/libc.so.6
#1 0x00007fac6c3f1862 in abort () from /usr/lib/libc.so.6
#2 0x00007fac6d367740 in isc_assertion_failed (file=0x7fac6d3c36ed "task.c", line=721,
type=isc_assertiontype_require,
cond=0x7fac6d3c3ca0 "((task) != ((void *)0) && ((const isc__magic_t *)(task))->magic == ((('T') << 24 | ('A') << 16 | ('S') << 8 | ('K'))))") at assertions.c:48
#3 0x00007fac6d3956ec in isc_task_shutdown (task=0x0) at task.c:721
#4 0x00005557fb200e81 in rndc_recvdone (handle=0x7fac6881f000, result=ISC_R_NOTFOUND,
arg=0x5557fb208ba0 <rndc_ccmsg>) at rndc.c:394
#5 0x00007fac6d04732c in recv_data (handle=0x7fac6881f000, eresult=ISC_R_SUCCESS, region=0x7fac69579f80,
arg=0x5557fb208ba0 <rndc_ccmsg>) at ccmsg.c:110
#6 0x00007fac6d34f5db in isc__nm_async_readcb (worker=0x0, ev0=0x7fac69579ff0) at netmgr/netmgr.c:2807
#7 0x00007fac6d34f3db in isc__nm_readcb (sock=0x7fac68800000, uvreq=0x7fac6881a000, eresult=ISC_R_SUCCESS)
at netmgr/netmgr.c:2780
#8 0x00007fac6d35438c in isc__nm_tcp_read_cb (stream=0x7fac688005b0, nread=261, buf=0x7fac6957a100)
at netmgr/tcp.c:884
#9 0x00007fac6cdb23a1 in ?? () from /usr/lib/libuv.so.1
#10 0x00007fac6cdb2cf8 in ?? () from /usr/lib/libuv.so.1
#11 0x00007fac6cdbb266 in ?? () from /usr/lib/libuv.so.1
#12 0x00007fac6cda7897 in uv_run () from /usr/lib/libuv.so.1
#13 0x00007fac6d34656b in nm_thread (worker0=0x7fac69cc3000) at netmgr/netmgr.c:689
#14 0x00007fac6d39f8b0 in isc__trampoline_run (arg=0x7fac69c77c80) at trampoline.c:185
#15 0x00007fac6c5a0259 in start_thread () from /usr/lib/libpthread.so.0
#16 0x00007fac6c4c95e3 in clone () from /usr/lib/libc.so.6
```
</details>
gdb back trace ~"Affects v9.16" :
<details>
```
(gdb) bt
#0 0x00007f4cf8861d22 in raise () from /usr/lib/libc.so.6
#1 0x00007f4cf884b862 in abort () from /usr/lib/libc.so.6
#2 0x0000563710a317dc in isc_assertion_failed (file=0x563710a99c8d "task.c", line=293,
type=isc_assertiontype_insist, cond=0x563710a9a058 "__v > 0 && __v < (4294967295U)") at assertions.c:47
#3 0x0000563710a69f32 in isc_task_attach (source=0x563711deca30, targetp=0x7f4cf5cc4470) at task.c:293
#4 0x0000563710a7e542 in isc_socket_connect (sock=0x7f4cf0000b60, addr=0x563710ab71a0 <serveraddrs>,
task=0x563711deca30, action=0x563710a16e33 <rndc_connected>, arg=0x0) at socket.c:4780
#5 0x0000563710a176b1 in rndc_startconnect (addr=0x563710ab71a0 <serveraddrs>, task=0x563711deca30)
at ./rndc.c:573
#6 0x0000563710a17770 in rndc_start (task=0x563711deca30, event=0x0) at ./rndc.c:583
#7 0x0000563710a6c10d in task_run (task=0x563711deca30) at task.c:857
#8 0x0000563710a6c386 in isc_task_run (task=0x563711deca30) at task.c:950
#9 0x0000563710a48555 in isc__nm_async_task (worker=0x563711dee210, ev0=0x563711e4c7a0) at netmgr.c:859
#10 0x0000563710a4880d in process_netievent (worker=0x563711dee210, ievent=0x563711e4c7a0) at netmgr.c:938
#11 0x0000563710a48f79 in process_queue (worker=0x563711dee210, type=NETIEVENT_TASK) at netmgr.c:1007
#12 0x0000563710a483a1 in process_all_queues (worker=0x563711dee210) at netmgr.c:778
#13 0x0000563710a48425 in async_cb (handle=0x563711dee570) at netmgr.c:807
#14 0x00007f4cf8a28fcd in ?? () from /usr/lib/libuv.so.1
#15 0x00007f4cf8a3d266 in ?? () from /usr/lib/libuv.so.1
#16 0x00007f4cf8a29897 in uv_run () from /usr/lib/libuv.so.1
#17 0x0000563710a47f61 in nm_thread (worker0=0x563711dee210) at netmgr.c:713
#18 0x0000563710a6ef3b in isc__trampoline_run (arg=0x563711defa20) at trampoline.c:196
#19 0x00007f4cf89fa259 in start_thread () from /usr/lib/libpthread.so.0
#20 0x00007f4cf89235e3 in clone () from /usr/lib/libc.so.6
```
</details>January 2022 (9.18.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/3079Assertion failure on TCP read (raw TCP - rndc and stats)2022-01-21T09:57:43ZOndřej SurýAssertion failure on TCP read (raw TCP - rndc and stats)The `isc__nm_tcp_resumeread()` could directly process the network manager `netievent` causing the read callback to call the `isc__nm_alloc_cb()` function before the previous read callback has called `isc__nm_free_cb()` causing an asserti...The `isc__nm_tcp_resumeread()` could directly process the network manager `netievent` causing the read callback to call the `isc__nm_alloc_cb()` function before the previous read callback has called `isc__nm_free_cb()` causing an assertion failure, because the worker receive buffer would still be marked as "in use".
```
(gdb) bt
#0 0x00007f5481d0f93f in raise () from /lib64/libc.so.6
#1 0x00007f5481cf9c95 in abort () from /lib64/libc.so.6
#2 0x000000000041427a in assertion_failed (file=<optimized out>, line=<optimized out>, type=isc_assertiontype_insist, cond=0x7f548572b628 "!worker->recvbuf_inuse || sock->type == isc_nm_udpsocket") at main.c:236
#3 0x00007f54856fa16a in isc_assertion_failed (file=file@entry=0x7f548572b314 "netmgr/netmgr.c", line=line@entry=2225, type=type@entry=isc_assertiontype_insist,
cond=cond@entry=0x7f548572b628 "!worker->recvbuf_inuse || sock->type == isc_nm_udpsocket") at assertions.c:47
#4 0x00007f54856e4019 in isc__nm_alloc_cb (handle=<optimized out>, size=65536, buf=0x7f547866f170) at netmgr/netmgr.c:2225
#5 0x00007f5482e8beab in uv.read () from /lib64/libuv.so.1
#6 0x00007f5482e8cbb8 in uv.stream_io () from /lib64/libuv.so.1
#7 0x00007f5482e92888 in uv.io_poll () from /lib64/libuv.so.1
#8 0x00007f5482e82035 in uv_run () from /lib64/libuv.so.1
#9 0x00007f54856ea6af in nm_thread (worker0=0x7f54802b8d90) at netmgr/netmgr.c:689
#10 0x00007f5485720995 in isc__trampoline_run (arg=0x7f5480274760) at trampoline.c:185
#11 0x00007f54820a42de in start_thread () from /lib64/libpthread.so.0
#12 0x00007f5481dd4a63 in clone () from /lib64/libc.so.6
```
Version: d27d20e6d4bafbb229046db5b4ae09ac293ff08a and laterJanuary 2022 (9.18.0)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3086Remove workaround for server mishandling NOTIFY with SOA record in ANSWER sec...2022-01-21T07:21:06ZOndřej SurýRemove workaround for server mishandling NOTIFY with SOA record in ANSWER sectionIn d39e56173d65178cdb2eb1cf31f9293c507cb139, a workaround was added to retry sending `NOTIFY` without `SOA` record when the peer would return `FORMERR`. This is no longer needed.In d39e56173d65178cdb2eb1cf31f9293c507cb139, a workaround was added to retry sending `NOTIFY` without `SOA` record when the peer would return `FORMERR`. This is no longer needed.January 2022 (9.18.0)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3069"resolver" test fails intermittently2022-04-01T13:07:44ZMichał Kępień"resolver" test fails intermittentlyThe recently-added (only on `main`) check for a SERVFAIL response to a
TCP query with an empty question section fails pretty frequently. The
check was added in commit 2f3ded7652e31be2a278c49b6e8e6219a11411b1 (part
of !5616). Despite a ...The recently-added (only on `main`) check for a SERVFAIL response to a
TCP query with an empty question section fails pretty frequently. The
check was added in commit 2f3ded7652e31be2a278c49b6e8e6219a11411b1 (part
of !5616). Despite a [code comment][1] suggesting otherwise, the test
fails due to `dig` hitting a timeout instead of receiving a SERVFAIL
response:
```
$ cat dig.ns5.out.70
; <<>> DiG 9.17.21 <<>> -p 29349 @10.53.0.5 -b 10.53.0.5 +tcp tcpalso.no-questions. a +tries=3 +time=4
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
```
Example occurrences:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2197750
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2197749
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2197279
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2196581
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2185707
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2185704
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2185288
Most of these happened on FreeBSD, but two happened on Linux (under
TSAN), so the common denominator seems to be "machine under load" rather
than "only happens on FreeBSD".
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/cb22ed049207c165c0f986a032e96c16986ffd48/bin/tests/system/resolver/tests.sh#L829-831January 2022 (9.18.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/2951assertion failure in req_senddone2022-01-21T07:32:54ZMark Andrewsassertion failure in req_senddoneJob [#2037401](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2037401) failed for c177c33c2773d7efa4b5af5460fd354450529d05:
```
D:checkds:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D checkds-ns9 -X named.l...Job [#2037401](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2037401) failed for c177c33c2773d7efa4b5af5460fd354450529d05:
```
D:checkds:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D checkds-ns9 -X named.lock -'.
D:checkds:Program terminated with signal SIGABRT, Aborted.
D:checkds:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:checkds:[Current thread is 1 (Thread 0x7f81a97fa700 (LWP 1941))]
D:checkds:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:checkds:#1 0x00007f81b069e535 in __GI_abort () at abort.c:79
D:checkds:#2 0x0000000000420cac in assertion_failed (file=0x7f81b12ee461 "request.c", line=<optimized out>, type=<optimized out>, cond=<optimized out>) at main.c:237
D:checkds:#3 0x00007f81b1372b7a in isc_assertion_failed (file=0x2 <error: Cannot access memory at address 0x2>, line=-1451276416, line@entry=1029, type=type@entry=isc_assertiontype_require, cond=0x7f81b06b37bb <__GI_raise+267> "H\213\214$\b\001") at assertions.c:47
D:checkds:#4 0x00007f81b123b4e2 in req_senddone (eresult=<optimized out>, region=<optimized out>, arg=<optimized out>) at request.c:1029
D:checkds:#5 0x00007f81b11727f6 in send_done (handle=0x7f819db70d80, result=ISC_R_CANCELED, cbarg=<optimized out>) at dispatch.c:1770
D:checkds:#6 0x00007f81b1363b7f in isc__nm_async_sendcb (worker=<optimized out>, ev0=ev0@entry=0x7f81a5843580) at netmgr/netmgr.c:2788
D:checkds:#7 0x00007f81b13603c6 in process_netievent (worker=worker@entry=0x7f81adc4a030, ievent=ievent@entry=0x7f81a5843580) at netmgr/netmgr.c:960
D:checkds:#8 0x00007f81b135baf1 in process_queue (worker=0x7f81adc4a030, type=NETIEVENT_NORMAL) at netmgr/netmgr.c:998
D:checkds:#9 process_all_queues (worker=0x7f81adc4a030) at netmgr/netmgr.c:746
D:checkds:#10 async_cb (handle=0x7f81adc4a390) at netmgr/netmgr.c:775
D:checkds:#11 0x00007f81b0c976d8 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:checkds:#12 0x00007f81b0ca6530 in uv.io_poll () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:checkds:#13 0x00007f81b0c97ff5 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:checkds:#14 0x00007f81b135bc39 in nm_thread (worker0=0x7f81adc4a030) at netmgr/netmgr.c:681
D:checkds:#15 0x00007f81b13a1aea in isc__trampoline_run (arg=0x1948b00) at trampoline.c:185
D:checkds:#16 0x00007f81b0844fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
D:checkds:#17 0x00007f81b07754cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
```
Thread 1 (Thread 0x7f81a97fa700 (LWP 1941)):
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
set = {__val = {16387, 0, 0, 0, 3905522674892552757, 140195000463360, 140195000513668, 140195000691568, 140195006326720, 140194998247424, 0, 140194998247424, 140194871224000, 140194942605624, 140194942605616, 5}}
pid = <optimized out>
tid = <optimized out>
ret = <optimized out>
#1 0x00007f81b069e535 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x7f81b0c5e900, sa_sigaction = 0x7f81b0c5e900}, sa_mask = {__val = {140194987098112, 140194987177249, 140194988119184, 140195000149089, 140194871199616, 31, 1483, 140194175012544, 13, 140194993269024, 17674366533170704384, 206158430256, 4575977, 140195000149089, 14, 206158430248}}, sa_flags = -1451275824, sa_restorer = 0xe}
sigs = {__val = {32, 0 <repeats 15 times>}}
#2 0x0000000000420cac in assertion_failed (file=0x7f81b12ee461 "request.c", line=<optimized out>, type=<optimized out>, cond=<optimized out>) at main.c:237
tracebuf = {0x420cc4 <assertion_failed+148>, 0x7f81b1372b7a <isc_assertion_failed+10>, 0x7f81b123b4e2 <req_senddone+450>, 0x7f81b11727f6 <send_done+54>, 0x7f81b1363b7f <isc__nm_async_sendcb+143>, 0x7f81b13603c6 <process_netievent+1222>, 0x7f81b135baf1 <async_cb+145>, 0x7f81b0c976d8, 0x7f81b0ca6530 <uv.io_poll+800>, 0x7f81b0c97ff5 <uv_run+277>, 0x7f81b135bc39 <nm_thread+121>, 0x7f81b13a1aea <isc__trampoline_run+74>, 0x7f81b0844fa3 <start_thread+243>, 0x7f81b07754cf <clone+63>, 0x7f81b07754cf <clone+63>, 0x0, 0x0, 0x405, 0x7f81b12ee461, 0x7f81a576f990, 0x7f81b0679668, 0x7f819c2b4e00, 0x7f81adc4a030, 0x7f81b18e2b00 <_dl_fixup+208>, 0x5, 0xffff00001f80, 0x7f816e473000, 0xa0, 0x7f819ca05748, 0x7f81a97f4e10, 0x0, 0x7f81a97f9080, 0x7f819ca05708, 0x7f81b043efaf, 0x7f81ade5f740, 0x7f81adea5040, 0x7f81adedc6c0, 0x7f81adedc6c0, 0x7f81adedc6c0, 0x7f81adedd340, 0x7f81adedd340, 0x7f81adedd440, 0xdededededededede, 0xdededededededede, 0xff00ffff00ff00, 0xff00ff00ff00ff, 0xff000000, 0x0, 0x3036346536313866, 0x756873203a303034, 0x0, 0x10, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7325732500732520, 0x7325732573257325, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x4200000042, 0x4200000042, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7f81adc09000, 0x7f816e460400, 0x7f81b138437b <isc__mem_put+171>, 0x0, 0x7f816e460400, 0x7f819da00000, 0x7f816e460410, 0x0, 0x1, 0x7f816e460560, 0x7f816e460410, 0x2, 0x800000000000000e, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7f81a97f4e70, 0x7f81b1171054 <tcp_recv+1828>, 0x7f81a56e2000, 0x700350a1f640002, 0x0 <repeats 15 times>, 0x10, 0xffffffffffffffff, 0xffffffffffffffff, 0x700350a1f640002, 0x0, 0x0, 0x0, 0x0, 0xf547f6b817b13000, 0x0, 0x7f81adc09000, 0x7f81a97f4e10, 0x7f81b13ac7a8, 0x7b0, 0x7f81adc09008}
nframes = <optimized out>
#3 0x00007f81b1372b7a in isc_assertion_failed (file=0x2 <error: Cannot access memory at address 0x2>, line=-1451276416, line@entry=1029, type=type@entry=isc_assertiontype_require, cond=0x7f81b06b37bb <__GI_raise+267> "H\213\214$\b\001") at assertions.c:47
No locals.
#4 0x00007f81b123b4e2 in req_senddone (eresult=<optimized out>, region=<optimized out>, arg=<optimized out>) at request.c:1029
request = <optimized out>
#5 0x00007f81b11727f6 in send_done (handle=0x7f819db70d80, result=ISC_R_CANCELED, cbarg=<optimized out>) at dispatch.c:1770
resp = 0x0
#6 0x00007f81b1363b7f in isc__nm_async_sendcb (worker=<optimized out>, ev0=ev0@entry=0x7f81a5843580) at netmgr/netmgr.c:2788
ievent = <optimized out>
sock = 0x7f816e473000
uvreq = 0x0
eresult = ISC_R_CANCELED
#7 0x00007f81b13603c6 in process_netievent (worker=worker@entry=0x7f81adc4a030, ievent=ievent@entry=0x7f81a5843580) at netmgr/netmgr.c:960
No locals.
#8 0x00007f81b135baf1 in process_queue (worker=0x7f81adc4a030, type=NETIEVENT_NORMAL) at netmgr/netmgr.c:998
waiting = 4
ievent = 0x7f81a5843580
stop = <optimized out>
#9 process_all_queues (worker=0x7f81adc4a030) at netmgr/netmgr.c:746
result = <optimized out>
type = 3
reschedule = true
type = <optimized out>
result = <optimized out>
#10 async_cb (handle=0x7f81adc4a390) at netmgr/netmgr.c:775
worker = 0x7f81adc4a030
#11 0x00007f81b0c976d8 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#12 0x00007f81b0ca6530 in uv.io_poll () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#13 0x00007f81b0c97ff5 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#14 0x00007f81b135bc39 in nm_thread (worker0=0x7f81adc4a030) at netmgr/netmgr.c:681
r = <optimized out>
worker = 0x7f81adc4a030
mgr = 0x7f81adc45000
#15 0x00007f81b13a1aea in isc__trampoline_run (arg=0x1948b00) at trampoline.c:185
trampoline = 0x1948b00
result = <optimized out>
#16 0x00007f81b0844fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
ret = <optimized out>
pd = <optimized out>
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140194871224064, -130959809494454272, 140721831580654, 140721831580655, 140194871224064, 26512128, 84985927855435776, 84967749757497344}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#17 0x00007f81b07754cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
```January 2022 (9.18.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/3110Release Checklist for BIND 9.18.02022-01-26T14:34:39ZMichał KępieńRelease Checklist for BIND 9.18.0## Release Schedule
**Code Freeze:** Wednesday, January 19th, 2022
**Tagging Deadline:** Monday, January 24th, 2022
**Public Release:** Wednesday, January 26th, 2022
## Documentation Review Links
**Closed issues assigned to the mile...## Release Schedule
**Code Freeze:** Wednesday, January 19th, 2022
**Tagging Deadline:** Monday, January 24th, 2022
**Public Release:** Wednesday, January 26th, 2022
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.18.0](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&state=closed&milestone_title=January%202022%20(9.18.0)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.17)
**Merge requests merged into the milestone without a release note:**
- [9.18.0](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&state=merged&milestone_title=January%202022%20(9.18.0)¬[label_name][]=Release%20Notes&target_branch=main)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.18.0](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&state=merged&milestone_title=January%202022%20(9.18.0)&label_name[]=No%20CHANGES&target_branch=main)
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Inform Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform.
- [x] ***(QA)*** Check Perflab 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[^1] (Subscription Edition only).
- [x] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is in effect.
### Before the Tagging Deadline
- [x] ***(QA)*** Look for outstanding documentation issues (e.g. `CHANGES` mistakes) and address them if any are found.
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
- [x] ***(QA)*** Update API files for libraries with new version information.
- [x] ***(QA)*** Change software version and library versions in `configure.ac` (new major release only).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
- [x] ***(QA)*** Update `CHANGES`.
- [x] ***(QA)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ***(QA)*** Update `README.md`.
- [x] ***(QA)*** Update `version`.
- [x] ***(QA)*** Build documentation on `docs.isc.org`.
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [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)*** Verify GitLab CI results for the tags created and prepare a QA report for the releases to be published.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is over.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again.
- [x] ***(Support)*** 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.
- [x] ***(QA)*** Notify Support that the releases have been prepared.
- [x] ***(Support)*** Send out ASNs (if applicable).
### On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *bind-announce*.
- [x] ***(Support)*** Write email to *bind-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription Edition (update the -S edition delivery tickets, even if those links were provided earlier via an ASN ticket).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages.
- [x] ***(QA)*** Build public RPMs.
- [x] ***(SwEng)*** Build Debian/Ubuntu packages.
- [x] ***(SwEng)*** Update Docker images.
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(QA)*** Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made.
- [x] ***(Marketing)*** Post short note to Twitter.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(QA)*** Ensure all new tags are annotated and signed.
- [x] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Merge the automatically prepared `prep 9.x.y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_x`).
- [x] ***(QA)*** For each maintained branch, update the `BIND_BASELINE_VERSION` variable for the `abi-check` job in `.gitlab-ci.yml` to the latest published BIND version tag for a given branch.
- [x] ***(QA)*** Prepare empty release notes for the next set of releases.
- [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 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. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^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.January 2022 (9.18.0)Michał KępieńMichał Kępień2022-01-26https://gitlab.isc.org/isc-projects/bind9/-/issues/3101doth: enable max-age checking in system test on OpenBSD2022-01-21T07:37:17ZMichal Nowakdoth: enable max-age checking in system test on OpenBSDOpenBSD's `curl` has HTTP/2 support but because of differences in `grep` implementation, a check in `doth` test [disables](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2233880) max-age checking tests which need HTTP/2 aware `curl` an...OpenBSD's `curl` has HTTP/2 support but because of differences in `grep` implementation, a check in `doth` test [disables](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2233880) max-age checking tests which need HTTP/2 aware `curl` and are skipped with `The available version of CURL does not have HTTP/2 support` message.
`curl -V`:
```
curl 7.79.0 (x86_64-unknown-openbsd7.0) libcurl/7.79.0 LibreSSL/3.4.1 zlib/1.2.11 nghttp2/1.44.0
Release-Date: 2021-09-15
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS HSTS HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL UnixSockets
```
But the current check won't detect it:
```
$ /usr/local/bin/curl --version | grep '^Features:.* HTTP2\( \|$\)'
$
```
This should do (also tested on Fedora 35 & FreeBSD 12.3):
```
$ /usr/local/bin/curl --version | grep -E '^Features:.* HTTP2( |$)'
Features: alt-svc AsynchDNS HSTS HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL UnixSockets
```
The check originated here: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5585#note_250222.January 2022 (9.18.0)Artem BoldarievArtem Boldariev