BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-02-14T09:58:47Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4577bind 9.18.24 on Ubuntu 20.04 doesn't start due to "type=notify" in named.service2024-02-14T09:58:47ZPascal Ernsterbind 9.18.24 on Ubuntu 20.04 doesn't start due to "type=notify" in named.service### Summary
When installing `bind9 1:9.18.24-1+ubuntu20.04.1+deb.sury.org+1` from ISC's PPA on Ubuntu 20.04, the `named.service` unit hangs during the post-install phase of the package installation, and more generally, always when the `...### Summary
When installing `bind9 1:9.18.24-1+ubuntu20.04.1+deb.sury.org+1` from ISC's PPA on Ubuntu 20.04, the `named.service` unit hangs during the post-install phase of the package installation, and more generally, always when the `named.service` unit is started. This is caused by the `type=notify` line that is present in the `named.service` unit although the actual support for systemd notify is only present in bind's 9.19.x version branch. After a 90 seconds, the unit runs into a timeout, and the `bind9` package is left in an unconfigured/semi-configured state in apt/aptitude.
Note: Ubuntu's `bind` package was installed and running on my machine, and I encountered this bug today when I tried to migrate to the `bind9` package from ISC's PPA. To be sure that this is not caused by any remains from the previous installation, I have completely purged all bind-related packages, manually deleted the `bind` user and the `/etc/bind`, `/var/cache/bind` and `/var/lib/bind` directories. Even after this cleanup, I still encountered this bug when trying to install `bind9 1:9.18.24-1+ubuntu20.04.1+deb.sury.org+1`. I've used the following workaround to solve to issue for me until the bug is fixed in the PPA package:
#### Temporary workaround for other users encountering the same bug
Prior to installing the package, run `sudo systemctl edit named.service`, then enter the following two lines and save the file:
```
[Service]
Type=simple
```
You should now be able to install/reconfigure the `bind9` package and to start `named.service` without issues.
### BIND version affected
```
named -V
BIND 9.18.24-1+ubuntu20.04.1+deb.sury.org+1-Ubuntu (Extended Support Version) <id:>
running on Linux x86_64 5.4.0-173-generic #191-Ubuntu SMP Fri Feb 2 13:55:07 UTC 2024
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-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--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' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-gw9jNu/bind9-9.18.24=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 9.4.0
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.40.0
linked to libnghttp2 version: 1.40.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
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
linked to maxminddb version: 1.4.2
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
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
1. Try to install the `bind9` 9.18.24 package from ISC's Ubuntu 20.04 PPA, for example using `apt install bind9`
2. Notice that the package installation fails/aborts during the post-install phase after about 90 seconds.
3. Check the ouput of `journalctl -ru named | grep --extended-regexp '(timeout|timed out)'`
### What is the current *bug* behavior?
The systemd unit `named.service` times out after 90 seconds.
### What is the expected *correct* behavior?
The systemd unit `named.service` shouldn't time out.
### Relevant configuration files
The bug occurs even with the unchanged config that ships with the package.
### Relevant logs
Excerpt from `journalctl -u named.service`:
```
Feb 13 19:06:53 ns systemd[1]: Starting BIND Domain Name Server...
Feb 13 19:06:53 ns named[6454]: starting BIND 9.18.24-1+ubuntu20.04.1+deb.sury.org+1-Ubuntu (Extended Support Version) <id:>
Feb 13 19:06:53 ns named[6454]: running on Linux x86_64 5.4.0-173-generic #191-Ubuntu SMP Fri Feb 2 13:55:07 UTC 2024
Feb 13 19:06:53 ns named[6454]: built with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable>
Feb 13 19:06:53 ns named[6454]: running as: named -f -u bind
Feb 13 19:06:53 ns named[6454]: compiled by GCC 9.4.0
Feb 13 19:06:53 ns named[6454]: compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
Feb 13 19:06:53 ns named[6454]: linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
Feb 13 19:06:53 ns named[6454]: compiled with libuv version: 1.44.2
Feb 13 19:06:53 ns named[6454]: linked to libuv version: 1.44.2
Feb 13 19:06:53 ns named[6454]: compiled with libxml2 version: 2.9.10
Feb 13 19:06:53 ns named[6454]: linked to libxml2 version: 20910
Feb 13 19:06:53 ns named[6454]: compiled with json-c version: 0.13.1
Feb 13 19:06:53 ns named[6454]: linked to json-c version: 0.13.1
Feb 13 19:06:53 ns named[6454]: compiled with zlib version: 1.2.11
Feb 13 19:06:53 ns named[6454]: linked to zlib version: 1.2.11
Feb 13 19:06:53 ns named[6454]: ----------------------------------------------------
Feb 13 19:06:53 ns named[6454]: BIND 9 is maintained by Internet Systems Consortium,
Feb 13 19:06:53 ns named[6454]: Inc. (ISC), a non-profit 501(c)(3) public-benefit
Feb 13 19:06:53 ns named[6454]: corporation. Support and training for BIND 9 are
Feb 13 19:06:53 ns named[6454]: available at https://www.isc.org/support
Feb 13 19:06:53 ns named[6454]: ----------------------------------------------------
Feb 13 19:06:53 ns named[6454]: adjusted limit on open files from 524288 to 1048576
Feb 13 19:06:53 ns named[6454]: found 1 CPU, using 1 worker thread
Feb 13 19:06:53 ns named[6454]: using 1 UDP listener per interface
Feb 13 19:06:53 ns named[6454]: DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
Feb 13 19:06:53 ns named[6454]: DS algorithms: SHA-1 SHA-256 SHA-384
Feb 13 19:06:53 ns named[6454]: HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
Feb 13 19:06:53 ns named[6454]: TKEY mode 2 support (Diffie-Hellman): yes
Feb 13 19:06:53 ns named[6454]: TKEY mode 3 support (GSS-API): yes
Feb 13 19:06:53 ns named[6454]: loading configuration from '/etc/bind/named.conf'
[…]
Feb 13 19:08:23 ns systemd[1]: named.service: start operation timed out. Terminating.
Feb 13 19:08:23 ns named[6454]: no longer listening on 127.0.0.1#53
Feb 13 19:08:23 ns named[6454]: no longer listening on […]#53
Feb 13 19:08:23 ns named[6454]: no longer listening on ::1#53
Feb 13 19:08:23 ns named[6454]: no longer listening on […]#53
Feb 13 19:08:23 ns named[6454]: shutting down
Feb 13 19:08:23 ns named[6454]: stopping command channel on 127.0.0.1#953
Feb 13 19:08:23 ns named[6454]: stopping command channel on ::1#953
Feb 13 19:08:23 ns named[6454]: exiting
Feb 13 19:08:23 ns systemd[1]: named.service: Failed with result 'timeout'.
Feb 13 19:08:23 ns systemd[1]: Failed to start BIND Domain Name Server.
Feb 13 19:08:24 ns systemd[1]: named.service: Scheduled restart job, restart counter is at 1.
Feb 13 19:08:24 ns systemd[1]: Stopped BIND Domain Name Server.
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4576#error "isc/stdatomic.h does not support your compiler"2024-02-13T21:49:44ZMarcus Kool#error "isc/stdatomic.h does not support your compiler"<!--
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 make sure that you make the new issue
confident...<!--
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 make sure that you make the new issue
confidential by clicking the checkbox at the bottom!
-->
### Summary
When compiling a plugin outside the bind source tree a fatal error is thrown by
#error "isc/stdatomic.h does not support your compiler"
### BIND version affected
<!--
Make sure you are testing with the **latest** supported version of BIND
for a given branch. Many bugs have been fixed over time!
See https://kb.isc.org/docs/supported-platforms for the current list.
The latest source is available from https://www.isc.org/download/#BIND
Paste the output of `named -V` here.
-->
all 9.18.x versions
### Steps to reproduce
<!--
This is extremely important! Be precise and use itemized lists, please.
Even if a default configuration is affected, please include the full configuration
files _you were testing with_.
Example:
1. Use _attached_ configuration file
2. Start BIND server with command: `named -g -c named.conf ...`
3. Simulate legitimate clients using command `dnsperf -S1 -d legit-queries ...`
4. Simulate attack traffic using command `dnsperf -S1 -d attack-queries ...`
-->
1. copy a plugin to outside the bind tree
2. make sure the plugin includes isc/log.h which triggers the inclusion of isc/stdatomic.h
3. use gcc 5.0 or higher
### What is the current *bug* behavior?
<!-- What actually happens. -->
The copiler issues a fatal error:
```
In file included from /local/src/bind/urlfilterdb-isc-bind-918/lib/isc/include/isc/atomic.h:19,
from /local/src/bind/urlfilterdb-isc-bind-918/lib/isc/include/isc/types.h:16,
from /local/src/bind/urlfilterdb-isc-bind-918/lib/isc/include/isc/log.h:25,
from ufdb-bind-log.h:12,
from ufdb-bind-log.c:19:
/local/src/bind/urlfilterdb-isc-bind-918/lib/isc/include/isc/stdatomic.h:29:2: error: #error "isc/stdatomic.h does not support your compiler"
29 | #error "isc/stdatomic.h does not support your compiler"
| ^~~~~
```
### What is the expected *correct* behavior?
<!-- What you should see instead. -->
compilation is successful
### Relevant configuration files
<!-- Paste any relevant configuration files here - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential issue, it is advisable to
obscure key secrets; this can be done automatically by using
`named-checkconf -px`. -->
### Relevant logs
<!-- Paste any relevant logs here - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise. -->https://gitlab.isc.org/isc-projects/bind9/-/issues/4572TLS forwarder lookup fails in resolver.c when TLS CA certificate not available2024-02-21T20:41:29ZTobias WolterTLS forwarder lookup fails in resolver.c when TLS CA certificate not available### Summary
When configuring a forwarder with a TLS configuration that specifies a CA file to verify the remote certificate, BIND dies at the RUNTIME_CHECK in resolver.c when it cannot read the CA file.
### BIND version affected
BIND ...### Summary
When configuring a forwarder with a TLS configuration that specifies a CA file to verify the remote certificate, BIND dies at the RUNTIME_CHECK in resolver.c when it cannot read the CA file.
### BIND version affected
BIND 9.19.19-1+0~20231220.107+debian12~1.gbpfc5ec0-Debian (Development Release) <id:>
### Steps to reproduce
1. Use the provided configuration snippet in any working configuration.
2. Do *not* have a `/certificates` directory.
3. Look up something from test.example.com.
### What is the current *bug* behavior?
BIND crashes in the resolver library due to the TLS context not being set up correctly.
### What is the expected *correct* behavior?
BIND complains about not being able to read about the CA certificate on startup.
### Relevant configuration files
* named.conf (excerpt):
```
tls auth1 {
ca-file "/certificates/ca.crt";
remote-hostname "auth1";
};
tls auth2 {
ca-file "/certificates/ca.crt";
remote-hostname "auth2";
};
zone test.example.com {
type forward;
forwarders port 853 { 172.23.23.11 tls auth1; 172.23.23.12 tls auth2; };
forward only;
};
```
### Relevant logs
```
recursive-2 | 12-Feb-2024 08:57:44.370 client @0x713184c1c000 172.23.23.23#45455 (foo.test.example.com): query: foo.test.example.com IN A +E(0)K (172.23.23.14)
recursive-2 | fetch: foo.test.example.com/A
recursive-2 | QNAME minimization - minimized, qmintype 2 qminname corp
recursive-2 | resolver.c:2175:fctx_query(): fatal error:
recursive-2 | RUNTIME_CHECK(result == ISC_R_SUCCESS) failed
recursive-2 | exiting (due to fatal error in library)
recursive-2 exited with code 139
```March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4571findnsec3proofs failed to disassociate all rdatasets returned by dns_ncache_c...2024-03-08T08:24:37ZMark Andrewsfindnsec3proofs failed to disassociate all rdatasets returned by dns_ncache_currentThese are not currently reference counted by if they where it would introduce a memory/reference leak.These are not currently reference counted by if they where it would introduce a memory/reference leak.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4570CID 486327: Control flow issues (UNREACHABLE)2024-03-08T08:20:30ZMark AndrewsCID 486327: Control flow issues (UNREACHABLE)Just need to be removed.
```
** CID 486327: Control flow issues (UNREACHABLE)
/lib/isc/netmgr/netmgr.c: 750 in isc___nmsocket_init()
____________________________________________________________________________________________________...Just need to be removed.
```
** CID 486327: Control flow issues (UNREACHABLE)
/lib/isc/netmgr/netmgr.c: 750 in isc___nmsocket_init()
________________________________________________________________________________________________________
*** CID 486327: Control flow issues (UNREACHABLE)
/lib/isc/netmgr/netmgr.c: 750 in isc___nmsocket_init()
744 sock->statsindex = tcp6statsindex;
745 break;
746 default:
747 UNREACHABLE();
748 }
749 break;
CID 486327: Control flow issues (UNREACHABLE)
This code cannot be reached: "switch (family) {
case 2:...".
750 switch (family) {
751 case AF_INET:
752 sock->statsindex = tcp4statsindex;
753 break;
754 case AF_INET6:
755 sock->statsindex = tcp6statsindex;
```March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4569** CID 486326: Memory - corruptions (OVERRUN)2024-03-08T08:23:03ZMark Andrews** CID 486326: Memory - corruptions (OVERRUN)This is cosmetic but should be addressed. sizeof(type.sa) is smaller than sizeof(type) and sizeof(type.sin6) so
while this overruns type.sa it doesn't actually overrun the union.
```
** CID 486326: Memory - corruptions (OVERRUN)
/lib/...This is cosmetic but should be addressed. sizeof(type.sa) is smaller than sizeof(type) and sizeof(type.sin6) so
while this overruns type.sa it doesn't actually overrun the union.
```
** CID 486326: Memory - corruptions (OVERRUN)
/lib/dns/resconf.c: 248 in add_server()
________________________________________________________________________________________________________
*** CID 486326: Memory - corruptions (OVERRUN)
/lib/dns/resconf.c: 248 in add_server()
242 if (res->ai_addrlen > sizeof(address->type)) {
243 isc_mem_put(mctx, address, sizeof(*address));
244 result = ISC_R_RANGE;
245 goto cleanup;
246 }
247 address->length = (unsigned int)res->ai_addrlen;
CID 486326: Memory - corruptions (OVERRUN)
Overrunning struct type sockaddr of 16 bytes by passing it to a function which accesses it at byte offset 27 using argument "res->ai_addrlen" (which evaluates to 28). [Note: The source code implementation of the function has been overridden by a builtin model.]
248 memmove(&address->type.sa, res->ai_addr, res->ai_addrlen);
249 ISC_LINK_INIT(address, link);
250 ISC_LIST_APPEND(*nameservers, address, link);
251
252 cleanup:
253 freeaddrinfo(res);
```March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4568isc_ht case insensitive matching is broken2024-03-07T21:26:35ZOndřej Surýisc_ht case insensitive matching is brokenThe `isc__ht_node_match()` ignores the case_sensitivity setting and always uses `memcmp()` that is case sensitive.The `isc__ht_node_match()` ignores the case_sensitivity setting and always uses `memcmp()` that is case sensitive.February 2024 (9.16.47/9.16.48, 9.16.47/9.16.48-S1, 9.18.23/9.18.24, 9.18.23/9.18.24-S1, 9.19.21)https://gitlab.isc.org/isc-projects/bind9/-/issues/4566slow zone transfer takes longer than expected in statschannel test2024-02-21T23:36:33ZTom Krizekslow zone transfer takes longer than expected in statschannel test`statschannel` system test recently became more unstable, [failing](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4006014) on the following check:
```
2024-02-08 00:32:57 INFO:statschannel I:statschannel_tmp_0gqlueys:Wait for slo...`statschannel` system test recently became more unstable, [failing](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4006014) on the following check:
```
2024-02-08 00:32:57 INFO:statschannel I:statschannel_tmp_0gqlueys:Wait for slow zone transfer to complete (29)
2024-02-08 00:33:16 INFO:statschannel I:statschannel_tmp_0gqlueys:exceeded time limit waiting for literal 'zone example/IN: zone transfer finished: success' in ns3/named.run
2024-02-08 00:33:16 INFO:statschannel I:statschannel_tmp_0gqlueys:failed
```
The check in question uses `-T transferslowly` option which makes the code use `select()` with a one second timeout to delay the individual packets. `ns1` uses the `transfer-format one-answer;` for the transfer to `ns3`. The `example.db` zone has 8 records and the check allows 20 second timeout, which should be more than sufficient. However, the records are delayed more than expected on the sending side:
```
08-Feb-2024 00:32:57.116 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': AXFR question section OK
08-Feb-2024 00:32:57.116 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': AXFR authority section OK
08-Feb-2024 00:32:57.116 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': AXFR started (serial 1)
08-Feb-2024 00:32:57.116 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': starting maxtime timer 7200000 ms
08-Feb-2024 00:32:57.116 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': sending TCP message of 77 bytes
08-Feb-2024 00:32:58.120 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': sending TCP message of 48 bytes
08-Feb-2024 00:32:59.124 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': sending TCP message of 48 bytes
08-Feb-2024 00:33:02.140 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': sending TCP message of 53 bytes
08-Feb-2024 00:33:05.152 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': sending TCP message of 785 bytes
08-Feb-2024 00:33:08.165 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': sending TCP message of 51 bytes
08-Feb-2024 00:33:11.177 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': sending TCP message of 50 bytes
08-Feb-2024 00:33:14.189 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': sending TCP message of 59 bytes
08-Feb-2024 00:33:17.201 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': sending TCP message of 71 bytes
08-Feb-2024 00:33:19.209 client @0x7b780001f800 10.53.0.3#41203 (example): transfer of 'example/IN': send: operation canceled
```
After the first three record are transmitted, each following record is delayed by just over 3 seconds (rather than 1 second). It could be caused by the load in the CI due to parallelization, but the fact this pattern (first 3 records have 1s delay, remaining record have 3s delay) repeats in another [job](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4007776) makes this a bit suspicious:
```
08-Feb-2024 09:55:12.719 client @0x7f559a027000 10.53.0.3#46059 (example): transfer of 'example/IN': sending TCP message of 77 bytes
08-Feb-2024 09:55:13.719 client @0x7f559a027000 10.53.0.3#46059 (example): transfer of 'example/IN': sending TCP message of 48 bytes
08-Feb-2024 09:55:14.724 client @0x7f559a027000 10.53.0.3#46059 (example): transfer of 'example/IN': sending TCP message of 48 bytes
08-Feb-2024 09:55:17.728 client @0x7f559a027000 10.53.0.3#46059 (example): transfer of 'example/IN': sending TCP message of 53 bytes
08-Feb-2024 09:55:21.740 client @0x7f559a027000 10.53.0.3#46059 (example): transfer of 'example/IN': sending TCP message of 785 bytes
08-Feb-2024 09:55:24.748 client @0x7f559a027000 10.53.0.3#46059 (example): transfer of 'example/IN': sending TCP message of 51 bytes
08-Feb-2024 09:55:28.756 client @0x7f559a027000 10.53.0.3#46059 (example): transfer of 'example/IN': sending TCP message of 50 bytes
08-Feb-2024 09:55:31.765 client @0x7f559a027000 10.53.0.3#46059 (example): transfer of 'example/IN': sending TCP message of 59 bytes
```March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4563Dynamic ipsets updates following named requests2024-03-19T16:19:58ZBenoit AnquetinDynamic ipsets updates following named requests### Description
I propose a plugin that is able to update netfilter ipsets when some specific requests are received by `named`. This may be useful in a situation where:
* `named` is running on a LAN
* the same server is forwarding pack...### Description
I propose a plugin that is able to update netfilter ipsets when some specific requests are received by `named`. This may be useful in a situation where:
* `named` is running on a LAN
* the same server is forwarding packets to the internet and handles firewall rules
The use case can be:
* we block all outgoing traffic (all internet request must use a secured proxy)
* but for some internet servers we want to allow traffic based on the IPs that where securely given by `named`. The idea is if the request name matches a wildcard, it then adds the address to an A or AAAA ipset.
* this is useful for some 'approved' domains that have many public addresses and would more reliable than looping on the name.
### Request
I already have a working plugin that has the following features:
* independent plugin
* can be linked with libipset or libnftnl libraries (ipset or nft sets)
* reacts when an A or AAAA answer will be given to the client, and if the wildcards matches something in the set, it adds the address to it before answering to the client (in this case the answer will be a few ms longer, but this will allow success of the tcp connection afterwards)
* when there is no match the timings overhead is negligible
The configuration is as follows, for updating 'entertainment' ipset of filter nft table with all IP address that we got from \*.example.com :
```plaintext
plugin query "update-ipset.so" {
ipset entertainment {
sites {
*.example.com.;
*.other-example.com.;
};
ttl 3600;
nftable filter; family inet;
};
};
```
I made a patch that is working on my systems, however:
* I didn't made unit tests yet. I would like to see the community first feedbacks first
* I tried to follow the coding rules, and checked for memory leaks in different situations
### Links / references
[0001-Plugin-for-updating-ipsets-during-name-resolution.patch](/uploads/f5dbc3ceae31999eefcd4c8e23495e53/0001-Plugin-for-updating-ipsets-during-name-resolution.patch)https://gitlab.isc.org/isc-projects/bind9/-/issues/4562dispatch test needs to ignore unexpected sources2024-03-07T22:42:57ZMark Andrewsdispatch test needs to ignore unexpected sourcesJob [#3999076](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3999076) failed for 30026fb052bbbefdb2416e4538c9dc973b000541:
```
FAILED dispatch/tests_connreset.py::test_connreset - dns.query.UnexpectedSource: got a response from ('10....Job [#3999076](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3999076) failed for 30026fb052bbbefdb2416e4538c9dc973b000541:
```
FAILED dispatch/tests_connreset.py::test_connreset - dns.query.UnexpectedSource: got a response from ('10.53.0.3', 25547) instead of ('10.53.0.2', 25227)
```
dnspython supports ignoring unexpected responses
```
*ignore_unexpected*, a ``bool``. If ``True``, ignore responses from unexpected sources.
```
This will most probably need to be applied to most dns.query.udp calls.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4561Shutdown test doesn't log everything to named.run2024-03-07T22:43:03ZMark AndrewsShutdown test doesn't log everything to named.runThe rest of the system tests log everything to stderr using `-d 99 -g`. The named instances started by the shutdown test do not do this which causes logging to be lost at the start and at the end after logging has been shutdown, i.e. me...The rest of the system tests log everything to stderr using `-d 99 -g`. The named instances started by the shutdown test do not do this which causes logging to be lost at the start and at the end after logging has been shutdown, i.e. memory issues being reported. They use the logging clause.
This will also cause the system's log to be spammed with messages from the test system.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4560All tests for "make test" returning "ERROR" even though logs show most tests ...2024-03-26T10:30:37ZEric SchultzAll tests for "make test" returning "ERROR" even though logs show most tests passed### Summary
When I run "make test" after a successful configure/make, all of the tests throw "ERROR", but if you look at the log for each test or the xml output, it will show as passed.
### BIND version affected
bind-9.18.21
### St...### Summary
When I run "make test" after a successful configure/make, all of the tests throw "ERROR", but if you look at the log for each test or the xml output, it will show as passed.
### BIND version affected
bind-9.18.21
### Steps to reproduce
```
% cat /etc/redhat-release
Red Hat Enterprise Linux release 8.9 (Ootpa)
% cat /etc/oracle-release
Oracle Linux Server release 8.9
# Install required packages (though many of these are not listed as required on the BIND site! Namely the python RPMs.)
sudo yum install automake autoconf libtool libcap-devel python3-pytest python3 perl-Net-DNS python3-dns
# Download and install jemalloc RPMs from EPEL:
wget https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/j/jemalloc-5.2.1-2.el8.x86_64.rpm
wget https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/j/jemalloc-devel-5.2.1-2.el8.x86_64.rpm
sudo yum install jemalloc-5.2.1-2.el8.x86_64.rpm jemalloc-devel-5.2.1-2.el8.x86_64.rpm
```
Build accessory software as needed:
```
wget https://www.zlib.net/zlib-1.3.1.tar.gz
tar xzf zlib-1.3.1.tar.gz
cd zlib-1.3.1
./configure --prefix=/usr/local/zlib-1.3.1
make
make test
sudo make install
cd ../
sudo vi /etc/ld.so.conf.d/bind-libs.conf
# add /usr/local/zlib-1.3.1/lib
sudo ldconfig
wget https://www.openssl.org/source/openssl-3.0.13.tar.gz
tar xzf openssl-3.0.13.tar.gz
cd openssl-3.0.13
./config --prefix=/usr/local/openssl-3.0.13 --with-zlib-lib=/usr/local/zlib-1.3.1/lib
make
make test
sudo make install
cd ../
sudo vi /etc/ld.so.conf.d/bind-libs.conf
# update to /usr/local/openssl-3.0.13/lib64
sudo ldconfig
# Probably could use libuv RPM here but chose to get newest source
wget --no-check-certificate https://dist.libuv.org/dist/v1.47.0/libuv-v1.47.0.tar.gz
tar xzf libuv-v1.47.0.tar.gz
cd libuv-v1.47.0
sh autogen.sh
./configure --prefix=/usr/local/libuv-1.47.0
make
make check
sudo make install
cd ../
sudo vi /etc/ld.so.conf.d/bind-libs.conf
# add: /usr/local/libuv-1.47.0/lib
sudo ldconfig
# Now build BIND itself
wget https://downloads.isc.org/isc/bind9/9.18.21/bind-9.18.21.tar.xz
tar xJf bind-9.18.21.tar.xz
cd bind-9.18.21
export PKG_CONFIG_PATH=/usr/local/openssl-3.0.13/lib64/pkgconfig:/usr/local/zlib-1.3.1/lib/pkgconfig:/usr/local/libuv-1.47.0/lib/pkgconfig
./configure --prefix=/usr/local/bind-9.18.21 --mandir=/usr/local/bind-9.18.21/man --with-openssl=/usr/local/openssl-3.0.13 --with-jemalloc --with-gnu-ld --with-libxml2=no --with-gssapi=no --disable-auto-validation --disable-doh
make
sudo bin/tests/system/ifconfig.sh up
make test
```
### What is the current *bug* behavior?
"make test" will start generating ERROR for each test:
<snip>
make check-TESTS
make[6]: Entering directory '/tmp_mnt/homefs/mnt/eschultz/projects/bind-9.18.21-rhe8/bind-9.18.21/bin/tests/system'
make[7]: Entering directory '/tmp_mnt/homefs/mnt/eschultz/projects/bind-9.18.21-rhe8/bind-9.18.21/bin/tests/system'
ERROR: rpz
ERROR: rpzrecurse
ERROR: serve-stale
ERROR: timeouts
ERROR: upforwd
<snip>
But the log itself (and .xml) shows 100% PASSED:
```
% tail bin/tests/system/rpz.log
2024-02-05 08:11:28 INFO:rpz I:rpz_tmp_mrhdwc8_:checking that rewriting CD=1 queries handles pending data correctly (29)
2024-02-05 08:11:28 INFO:rpz I:rpz_tmp_mrhdwc8_:status (native RPZ sub-test): 0 (pass)
2024-02-05 08:11:28 INFO:rpz I:rpz_tmp_mrhdwc8_:attempting to configure servers with DNSRPS...
2024-02-05 08:11:32 INFO:rpz I:rpz_tmp_mrhdwc8_:DNSRPS disabled at compile time
2024-02-05 08:11:32 INFO:rpz I:rpz_tmp_mrhdwc8_:DNSRPS sub-test skipped
PASSED [100%]
generated xml file: /home/eschultz/projects/bind-9.18.21-rhe8/bind-9.18.21/bin/tests/system/rpz.xml
========================== 1 passed in 98.66 seconds ===========================
ERROR rpz (exit status: 99)
```
Every single test has exit status 99.
### What is the expected *correct* behavior?
These tests should almost all have result PASS, when checking the logs (except for two that show 50% PASSED):
```
% grep PASSED bin/tests/system/test-suite.log
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [ 50%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [ 50%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
PASSED [100%]
```
### Relevant configuration files
I don't believe there is anything relevant for the build.
### Relevant logs
```
% cat bin/tests/system/rpz.log
============================= test session starts ==============================
platform linux -- Python 3.6.8, pytest-3.4.2, py-1.5.3, pluggy-0.6.0 -- /bin/python3
cachedir: ../.pytest_cache
rootdir: /tmp_mnt/homefs/mnt/eschultz/projects/bind-9.18.21-rhe8/bind-9.18.21/bin/tests/system, inifile: pytest.ini
collecting ... collected 1 item
tests_sh_rpz.py::test_rpz
-------------------------------- live log setup --------------------------------
2024-02-05 09:23:29 INFO:rpz test started: rpz/tests_sh_rpz.py
2024-02-05 09:23:29 INFO:rpz using port range: <25322, 25341>
-------------------------------- live log call ---------------------------------
2024-02-05 09:23:35 INFO:rpz I:rpz_tmp_zaujh5m9:running native RPZ sub-test
2024-02-05 09:23:35 INFO:rpz I:rpz_tmp_zaujh5m9:checking QNAME rewrites (1)
2024-02-05 09:23:42 INFO:rpz I:rpz_tmp_zaujh5m9:checking NXDOMAIN/NODATA action on QNAME trigger (2)
2024-02-05 09:23:46 INFO:rpz I:rpz_tmp_zaujh5m9:checking IP rewrites (3)
2024-02-05 09:23:48 INFO:rpz I:rpz_tmp_zaujh5m9:ns2 zone reload queued
2024-02-05 09:23:49 INFO:rpz I:rpz_tmp_zaujh5m9:ns2 zone reload queued
2024-02-05 09:23:50 INFO:rpz I:rpz_tmp_zaujh5m9:checking radix tree deletions (4)
2024-02-05 09:23:52 INFO:rpz I:rpz_tmp_zaujh5m9:checking NSDNAME rewrites (5)
2024-02-05 09:23:54 INFO:rpz I:rpz_tmp_zaujh5m9:checking NSIP rewrites (6)
2024-02-05 09:23:55 INFO:rpz I:rpz_tmp_zaujh5m9:checking walled garden NSIP rewrites (7)
2024-02-05 09:23:56 INFO:rpz I:rpz_tmp_zaujh5m9:checking policy overrides (8)
2024-02-05 09:24:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking crashes (9)
2024-02-05 09:24:04 INFO:rpz I:rpz_tmp_zaujh5m9:performance not checked; queryperf not available
2024-02-05 09:24:06 INFO:rpz I:rpz_tmp_zaujh5m9:checking that ns3 with broken rpz does not crash (10)
2024-02-05 09:24:11 INFO:rpz I:rpz_tmp_zaujh5m9:checking if rpz survives a certain class of failed reconfiguration attempts (11)
2024-02-05 09:24:12 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz failed update will keep previous rpz rules (12)
2024-02-05 09:24:13 INFO:rpz I:rpz_tmp_zaujh5m9:ns3 zone reload queued
2024-02-05 09:24:14 INFO:rpz I:rpz_tmp_zaujh5m9:checking reload of a mixed-case RPZ zone (13)
2024-02-05 09:24:14 INFO:rpz I:rpz_tmp_zaujh5m9:ns3 zone reload queued
2024-02-05 09:24:14 INFO:rpz I:rpz_tmp_zaujh5m9:checking that ttl values are not zeroed when qtype is '*' (14)
2024-02-05 09:24:14 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz updates/transfers with parent nodes added after children (15)
2024-02-05 09:24:56 INFO:rpz I:rpz_tmp_zaujh5m9:checking that going from an empty policy zone works (16)
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:ns7 zone refresh queued
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:checking that add-soa no at rpz zone level works (17)
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:checking that add-soa yes at response-policy level works (18)
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:reconfiguring server with 'add-soa no' (19)
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:checking that 'add-soa no' at response-policy level works (19)
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:checking that 'add-soa unset' works (20)
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz with delegation fails correctly (21)
2024-02-05 09:24:59 INFO:rpz I:rpz_tmp_zaujh5m9:checking policies from expired zone are no longer in effect (22)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz 'CNAME *.' (NODATA) with dns64, AAAA lookup with A-only (23)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz 'CNAME *.' (NODATA) with dns64, A lookup with A-only (24)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz 'CNAME *.' (NODATA) with dns64, AAAA lookup with no A or AAAA (25)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz 'CNAME *.' (NODATA) with dns64, A lookup with no A or AAAA (26)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz 'CNAME *.' (NODATA) with dns64, AAAA lookup with A and AAAA (27)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking rpz 'CNAME *.' (NODATA) with dns64, A lookup with A and AAAA (28)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:checking that rewriting CD=1 queries handles pending data correctly (29)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:status (native RPZ sub-test): 0 (pass)
2024-02-05 09:25:00 INFO:rpz I:rpz_tmp_zaujh5m9:attempting to configure servers with DNSRPS...
2024-02-05 09:25:04 INFO:rpz I:rpz_tmp_zaujh5m9:DNSRPS disabled at compile time
2024-02-05 09:25:04 INFO:rpz I:rpz_tmp_zaujh5m9:DNSRPS sub-test skipped
PASSED [100%]
generated xml file: /home/eschultz/projects/bind-9.18.21-rhe8/bind-9.18.21/bin/tests/system/rpz.xml
========================== 1 passed in 97.72 seconds ===========================
ERROR rpz (exit status: 99)
```
```
% cat bin/tests/system/rpz.xml
<?xml version="1.0" encoding="utf-8"?><testsuite errors="0" failures="0" name="pytest" skips="0" tests="1" time="97.721"><testcase classname="rpz.tests_sh_rpz" file="rpz/tests_sh_rpz.py" line="12" name="test_rpz" time="97.68873071670532"></testcase></testsuite>
```March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4557dnstap logging support for name server operator policy applied to DNS message...2024-02-02T08:32:32ZMatt Braundnstap logging support for name server operator policy applied to DNS messages like RPZ### Description
dnstap format supports since 2021 to log name server policies applied to DNS messages. Bind does not currently log RPZ policy hits via dnstap logging.
### Request
Implement RPZ policy dns message processing via dnstap....### Description
dnstap format supports since 2021 to log name server policies applied to DNS messages. Bind does not currently log RPZ policy hits via dnstap logging.
### Request
Implement RPZ policy dns message processing via dnstap.
### Links / references
https://github.com/dnstap/dnstap.pb/blob/master/dnstap.proto#L70https://gitlab.isc.org/isc-projects/bind9/-/issues/4556CI build issues with BIND 9.112024-02-22T08:54:19ZMark AndrewsCI build issues with BIND 9.11Minimal changes to continue to build and run test on bind9.11 so we can test security back ports.
Support newer compilers, address python, openssl and Net::DNS changes. etc.Minimal changes to continue to build and run test on bind9.11 so we can test security back ports.
Support newer compilers, address python, openssl and Net::DNS changes. etc.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4555Release Checklist for BIND 9.16.48, 9.16.48-S1, 9.18.24, 9.18.24-S1, 9.19.212024-02-14T15:30:46ZMichal NowakRelease Checklist for BIND 9.16.48, 9.16.48-S1, 9.18.24, 9.18.24-S1, 9.19.21## Release Schedule
**Code Freeze:** Tuesday, 30 January 2024
**Tagging Deadline:** Friday, 2 February 2024
**Public Release:** Tuesday, 13 February 2024
## Release Checklist
### Before the Tagging Deadline
- [x] ***(QA)*** Inspec...## Release Schedule
**Code Freeze:** Tuesday, 30 January 2024
**Tagging Deadline:** Friday, 2 February 2024
**Public Release:** Tuesday, 13 February 2024
## Release Checklist
### 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] ***(Marketing)*** Prepare and send out ASN emails (as outlined in the CVE checklist; 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.](https://mattermost.isc.org/isc/pl/dkc5s77ct3nkfxf8afyuxwfu7r)
- [x] ***(QA)*** [Use the Printing Press project to prepare a release announcement email.](isc-private/printing-press!96)
- [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.
[^2]: As a rule of thumb, security vulnerabilities which have reproducers merged to the public repository are considered okay for full disclosure.February 2024 (9.16.47/9.16.48, 9.16.47/9.16.48-S1, 9.18.23/9.18.24, 9.18.23/9.18.24-S1, 9.19.21)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4553return value for check DS shadows value for running keymgr2024-03-07T22:43:18ZMatthijs Mekkingmatthijs@isc.orgreturn value for check DS shadows value for running keymgrChecking the DS at the parent only happens if `dns_zone_getdnsseckeys()` returns success. However, if this function somehow fails, it can also prevent the keymgr from running.Checking the DS at the parent only happens if `dns_zone_getdnsseckeys()` returns success. However, if this function somehow fails, it can also prevent the keymgr from running.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/4552keymgr: bug in Depends function2024-03-13T10:53:30ZMatthijs Mekkingmatthijs@isc.orgkeymgr: bug in Depends functionWhile working on the `dnssec` system test I noticed a bug in the `keymgr` code. The function `keymgr_dep` implements the `Depends` function, described as follows:
---
The `Depends` relation refers to types of rollovers in which a certa...While working on the `dnssec` system test I noticed a bug in the `keymgr` code. The function `keymgr_dep` implements the `Depends` function, described as follows:
---
The `Depends` relation refers to types of rollovers in which a certain record type is going to be swapped. For example, with the ZSK Pre-Publish rollover method the signatures created by the successor key `z` are being propagated first, so that the zone signatures for `x` and `z` can be swapped (smooth rollover). In this case, we say that `z` is the successor of `x` for the `ZRRSIG` record type. Here, `x` is the predecessor key that is going to be withdrawn from the zone. The set `Dep(x, T)` is a separately administrated set of keys that have a dependency on `x` for record type `T`.
For example, with the ZSK Pre-Publish method, the `ZRRSIG` records of key `x` can be withdrawn if there is a succeeding `ZRRSIG` of key `z` introduced in the zone. Key `x` now depends on key `z`, therefore `z` will be in the set `Dep(x, ZRRSIG)`. The successor relation requires that the predecessor key must not have any other keys relying on it. In other words, the set `Dep(x, T)` must be empty.
---
But if the key is phased out (all its states are in `HIDDEN`), there is no longer a dependency. Since the relationship is still maintained (`Predecessor` and `Successor` metadata), the `keymgr_dep` function still returned `true`. In other words, the set `Dep(x, T)` is not considered empty.
This slows down key rollovers, only retiring keys when the successor key has been fully propagated.April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4551dnssec-keygen man page contradictory on whether TSIG keys can be generated2024-03-08T05:39:15ZChristopher Headdnssec-keygen man page contradictory on whether TSIG keys can be generated### Summary
At the top of the `dnssec-keygen` man page appears this text:
> It can also generate keys for use with TSIG (Transaction Signatures) as defined in RFC 2845, or TKEY (Transaction Key) as defined in RFC 2930.
Under the secti...### Summary
At the top of the `dnssec-keygen` man page appears this text:
> It can also generate keys for use with TSIG (Transaction Signatures) as defined in RFC 2845, or TKEY (Transaction Key) as defined in RFC 2930.
Under the section for the `-a` option:
> In prior releases, HMAC algorithms could be generated for use as TSIG keys, but that feature was removed in BIND 9.13.0. Use tsig-keygen to generate TSIG keys.
It looks like the top matter probably wasn’t updated when TSIG was spun out into `tsig-keygen`.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/4549heap-use-after-free lib/isccc/ccmsg.c:160 in ccmsg_senddone2024-03-08T07:52:43ZMichal Nowakheap-use-after-free lib/isccc/ccmsg.c:160 in ccmsg_senddoneJob [#3977008](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3977008) failed for 6b00e831e1f7dad6c02766721f3f921935f9d82d in the `shutdown` system test.
```
WARNING: ThreadSanitizer: heap-use-after-free
Write of size 8 at 0x0000000...Job [#3977008](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3977008) failed for 6b00e831e1f7dad6c02766721f3f921935f9d82d in the `shutdown` system test.
```
WARNING: ThreadSanitizer: heap-use-after-free
Write of size 8 at 0x000000000001 by main thread:
#0 ccmsg_senddone lib/isccc/ccmsg.c:160 (BuildId: d832ce616f43e7826d71895c29b8d1a636594d28)
#1 isc___nm_sendcb netmgr/netmgr.c:1882 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#2 isc__job_cb lib/isc/job.c:78 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#3 uv__run_idle /usr/src/libuv-v1.47.0/src/unix/loop-watcher.c:68 (BuildId: 073e85ad3e8928fc579b193a4ac75e2ebba7da2f)
#4 thread_body lib/isc/thread.c:85 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#5 isc_thread_main lib/isc/thread.c:116 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#6 isc_loopmgr_run lib/isc/loop.c:454 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#7 main bin/named/main.c:1574 (BuildId: 4133e9ffbbb7b06add829acea0965b1d834d5316)
Previous write of size 8 at 0x000000000001 by main thread:
#0 free <null> (BuildId: 732e44e7f1cd4f0f9ca7d27895a253bebdea6827)
#1 sdallocx lib/isc/jemalloc_shim.h:82 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#2 mem_put lib/isc/mem.c:328
#3 isc__mem_put lib/isc/mem.c:692
#4 conn_free bin/named/controlconf.c:597 (BuildId: 4133e9ffbbb7b06add829acea0965b1d834d5316)
#5 controlconnection_unref bin/named/controlconf.c:200
#6 controlconnection_detach bin/named/controlconf.c:200 (BuildId: 4133e9ffbbb7b06add829acea0965b1d834d5316)
#7 control_senddone bin/named/controlconf.c:284 (BuildId: 4133e9ffbbb7b06add829acea0965b1d834d5316)
#8 ccmsg_senddone lib/isccc/ccmsg.c:159 (BuildId: d832ce616f43e7826d71895c29b8d1a636594d28)
#9 isc___nm_sendcb netmgr/netmgr.c:1882 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#10 isc__job_cb lib/isc/job.c:78 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#11 uv__run_idle /usr/src/libuv-v1.47.0/src/unix/loop-watcher.c:68 (BuildId: 073e85ad3e8928fc579b193a4ac75e2ebba7da2f)
#12 thread_body lib/isc/thread.c:85 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#13 isc_thread_main lib/isc/thread.c:116 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#14 isc_loopmgr_run lib/isc/loop.c:454 (BuildId: e8eda90bc85b7cc4a5338c8afd79fad6b27213e4)
#15 main bin/named/main.c:1574 (BuildId: 4133e9ffbbb7b06add829acea0965b1d834d5316)
SUMMARY: ThreadSanitizer: heap-use-after-free lib/isccc/ccmsg.c:160 in ccmsg_senddone
```
We had a similar issue #4501 before.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/4547Add support for nginx load balancing with “X-Real-IP”2024-01-24T11:56:31ZMr BenAdd support for nginx load balancing with “X-Real-IP”### Description
When I use doh, I hope bind can be deployed behind nginx and also be able to identify the client source IP. I have some views, and the policies of these views are judged based on the source IP.
This is not currently supp...### Description
When I use doh, I hope bind can be deployed behind nginx and also be able to identify the client source IP. I have some views, and the policies of these views are judged based on the source IP.
This is not currently supported. Perhaps X-Real-IP should be added to the header of http, and the IP can be passed to the dns module to make policy judgments instead of the source IP of the IP layer.
### Request
Perhaps X-Real-IP should be added to the header of http, and the IP can be passed to the dns module to make policy judgments instead of the source IP of the IP layer.
### Links / references