BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-01-04T17:01:47Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4488Memory/reference leak in lib/dns/zone.c:zone_sign2024-01-04T17:01:47ZMark AndrewsMemory/reference leak in lib/dns/zone.c:zone_signWhen fixing #4466 named was reporting a memory leak on shutdown. This was traced to a misplaced `continue` in `sign_zone` resulting in `dst_key's` not being freed.When fixing #4466 named was reporting a memory leak on shutdown. This was traced to a misplaced `continue` in `sign_zone` resulting in `dst_key's` not being freed.January 2024 (9.16.46, 9.16.46-S1, 9.18.22, 9.18.22-S1, 9.19.20) (❗RECALLED❗)https://gitlab.isc.org/isc-projects/bind9/-/issues/4487Bind unexpected crash - XoT2024-03-28T18:57:42ZEverett FultonBind unexpected crash - XoT(Ref: SF#00001505)
A Support customer has reported a crash on 9.18.18-9.18.20 on secondary auth servers:
```
11-Dec-2023 13:32:26.203 general: debug 1: zone_needdump: zone [redacted]/IN: enter
11-Dec-2023 13:32:26.203 general: debug 1: z...(Ref: SF#00001505)
A Support customer has reported a crash on 9.18.18-9.18.20 on secondary auth servers:
```
11-Dec-2023 13:32:26.203 general: debug 1: zone_needdump: zone [redacted]/IN: enter
11-Dec-2023 13:32:26.203 general: debug 1: zone_settimer: zone [redacted]/IN: enter
11-Dec-2023 13:32:26.203 general: debug 1: zone_settimer: zone [redacted]/IN: enter
11-Dec-2023 13:32:26.204 general: debug 1: zone_settimer: zone [redacted]/IN: enter
11-Dec-2023 13:32:26.204 general: debug 10: zone_settimer: zone [redacted]/IN: settimer inactive
11-Dec-2023 13:32:26.204 general: debug 1: queue_soa_query: zone [redacted]/IN: enter
11-Dec-2023 13:32:26.205 general: critical: xfrin.c:1564: INSIST(__v > 0) failed, back trace
11-Dec-2023 13:32:26.206 general: critical: 0x23b128 <assertion_failed+0x88> at /usr/local/named/sbin/named
11-Dec-2023 13:32:26.206 general: critical: 0x800303f8a <isc_assertion_failed+0xa> at /usr/local/named/lib/libisc-9.18.20.so
11-Dec-2023 13:32:26.206 general: critical: 0x8004fe5ae <dns_xfrin_attach+0x143e> at /usr/local/named/lib/libdns-9.18.20.so
11-Dec-2023 13:32:26.206 general: critical: 0x8002f2856 <isc__nm_async_readcb+0xa6> at /usr/local/named/lib/libisc-9.18.20.so
11-Dec-2023 13:32:26.206 general: critical: 0x8002f126d <isc__nm_readcb+0x11d> at /usr/local/named/lib/libisc-9.18.20.so
11-Dec-2023 13:32:26.206 general: critical: 0x8002fd9fd <isc__nm_tlsdns_processbuffer+0x13d> at /usr/local/named/lib/libisc-9.18.20.so
11-Dec-2023 13:32:26.206 general: critical: 0x8002f1988 <isc__nm_process_sock_buffer+0x58> at /usr/local/named/lib/libisc-9.18.20.so
11-Dec-2023 13:32:26.206 general: critical: 0x8002fcdbe <isc__nm_async_tlsdnsshutdown+0x38e> at /usr/local/named/lib/libisc-9.18.20.so
11-Dec-2023 13:32:26.206 general: critical: 0x8002fdcfd <isc__nm_tlsdns_read_cb+0xbd> at /usr/local/named/lib/libisc-9.18.20.so
11-Dec-2023 13:32:26.206 general: critical: 0x800bb9aee <uv_signal_stop+0xc9e> at /usr/local/lib/libuv.so.1
11-Dec-2023 13:32:26.206 general: critical: 0x800bc0555 <uv_cpu_info+0xd65> at /usr/local/lib/libuv.so.1
11-Dec-2023 13:32:26.206 general: critical: 0x800baf438 <uv_run+0x198> at /usr/local/lib/libuv.so.1
11-Dec-2023 13:32:26.206 general: critical: 0x8002ea9cb <isc__netmgr_create+0x76b> at /usr/local/named/lib/libisc-9.18.20.so
11-Dec-2023 13:32:26.206 general: critical: 0x800329906 <isc__trampoline_run+0x16> at /usr/local/named/lib/libisc-9.18.20.so
11-Dec-2023 13:32:26.206 general: critical: exiting (due to assertion failure)
```
This customer is on FreeBSD 13.1, uses XoT, and a custom primary solution of unknown provenance. Config/log/core/named binary are on workroom.isc.org:/home/support/SF1505-[redacted]
Libraries have also been requested from the customer, but we have not yet received those.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)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4483named logging for category rpz misses some rpz log messages2023-12-12T11:52:05ZEvan Harrisnamed logging for category rpz misses some rpz log messages<!--
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!
-->
### Summary
When bind9/named is configured to log category rpz messages to a file, some
rpz log messages are not captured and end up being sent to an incorrect destination.
### BIND version used
BIND 9.18.19-1~deb12u1-Debian (Extended Support Version) <id:>
running on Linux x86_64 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29)
### Steps to reproduce
Add the following stanza in named.conf.options:
```
logging {
channel rpzlog {
file "/var/log/named/rpz.log" versions unlimited size 100m;
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
category rpz { rpzlog; };
};
```
With this configuration for logging, most rpz log messages are properly
sent to the intended file (NXDOMAIN items), but some rpz messages are not.
So far, the ones that seem not to be properly captured by this log destination
are rpz "passthru" lookups.
Example log messages that end up in the default syslog/journald rather than
the configured log file:
```
Dec 10 01:29:41 somehostn named[327739]: client @0x7fee327a6568 127.0.0.1#35809 (some.domain.name): rpz QNAME PASSTHRU rewrite
some.domain.name/A/IN via some.domain.name.rpz.local
Dec 10 01:29:41 somehost named[327739]: client @0x7fee32785768 127.0.0.1#35809 (some.domain.name): rpz QNAME PASSTHRU rewrite
some.domain.name/AAAA/IN via some.domain.name.rpz.local
```
Example rpz entry that generates log entries that fail to go to the rpz category/destination:
```
some.domain.name CNAME rpz-passthru.
```
Example rpz entry that generates log entries that do go to the proper rpz category/destination:
```
other.domain.name CNAME .
```
### What is the current *bug* behavior?
rpz passthru entries generate log messages that do not go to the intended `category rpz` log destination.
### What is the expected *correct* behavior?
All rpz log messages should be caught by `category rpz`.
### Relevant configuration files
see abovehttps://gitlab.isc.org/isc-projects/bind9/-/issues/4479SERVFAIL without any trace in logs2023-12-07T10:03:52ZrseffnerSERVFAIL without any trace in logs### Summary
rebooted Debian bookworm and can't use bind any more
### BIND version used
```
BIND 9.18.19-1~deb12u1-Debian (Extended Support Version) <id:>
running on Linux x86_64 6.6.3-sus #6 SMP Wed Nov 29 09:06:16 CET 2023
built by mak...### Summary
rebooted Debian bookworm and can't use bind any more
### BIND version used
```
BIND 9.18.19-1~deb12u1-Debian (Extended Support Version) <id:>
running on Linux x86_64 6.6.3-sus #6 SMP Wed Nov 29 09:06:16 CET 2023
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/reproducible-path/bind9-9.18.19=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 12.2.0
compiled with OpenSSL version: OpenSSL 3.0.10 1 Aug 2023
linked to OpenSSL version: OpenSSL 3.0.11 19 Sep 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.52.0
linked to libnghttp2 version: 1.52.0
compiled with libxml2 version: 2.9.14
linked to libxml2 version: 20914
compiled with json-c version: 0.16
linked to json-c version: 0.16
compiled with zlib version: 1.2.13
linked to zlib version: 1.2.13
linked to maxminddb version: 1.7.1
compiled with protobuf-c version: 1.4.1
linked to protobuf-c version: 1.4.1
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
I don't know (on other same-configred Systems this bind-version is working)
### What is the current *bug* behavior?
an 'dig @127.0.0.1" results in SERVFAIL
```
SuS-GW:~# dig @127.0.0.1
; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> @127.0.0.1
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48566
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1460
; COOKIE: fe27014ead9c76b10100000065706180e3a4d408ea8dc854 (good)
;; QUESTION SECTION:
;. IN NS
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Dec 06 12:56:48 CET 2023
;; MSG SIZE rcvd: 56
```
### What is the expected *correct* behavior?
Status: NOERROR and an valid ANSWER
### Relevant configuration files
Its not config-related. I tried to install an new bind into an chroot with same results.
### Relevant logs and/or screenshots
Here is the Problem: I can't find anything helpful in logs (also using 'rndc trace 9') except of:
```
06-Dec-2023 10:37:07.749 general: error: netmgr/uverr2result.c:98:isc___nm_uverr2result(): unexpected error:
06-Dec-2023 10:37:07.749 general: error: unable to convert libuv error code in udp_send_cb (netmgr/udp.c:802) to isc_result: -89: destination address required
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4478Redefinition of 'hmac' as different kind of symbol on NetBSD2024-01-03T14:36:13ZMichal NowakRedefinition of 'hmac' as different kind of symbol on NetBSDSince renaming `hmacname` to `hmac` in ffacf0aec6ac265bba307f4ef5f4915406607b7a BIND 9.19 won't build on NetBSD as this platform already defines `hmac` in the `/usr/include/stdlib.h` header:
```
CC dig.o
In file included from dig....Since renaming `hmacname` to `hmac` in ffacf0aec6ac265bba307f4ef5f4915406607b7a BIND 9.19 won't build on NetBSD as this platform already defines `hmac` in the `/usr/include/stdlib.h` header:
```
CC dig.o
In file included from dig.c:45:
./dighost.h:262:24: error: redefinition of 'hmac' as different kind of symbol
extern dst_algorithm_t hmac;
^
/usr/include/stdlib.h:312:10: note: previous definition is here
ssize_t hmac(const char *, const void *, size_t, const void *, size_t, void *,
^
dig.c:2461:9: error: non-object type 'ssize_t (const char *, const void *, size_t, const void *, size_t, void *, size_t)' (aka 'long (const char *, const void *, unsigned long, const void *, unsigned long, void *, unsigned long)') is not assignable
hmac = DST_ALG_HMACMD5;
~~~~ ^
2 errors generated.
```
This erorr is on NetBSD 10.0 RC1 but `hmac(3)` suggests this will fail on every NetBSD since v8:
```
NAME
hmac – compute a key-Hash Message Authentication Code
...
HISTORY
The hmac() function appeared in NetBSD 8.
```January 2024 (9.16.46, 9.16.46-S1, 9.18.22, 9.18.22-S1, 9.19.20) (❗RECALLED❗)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4477statschannel test intermittently fails with incorrect zone loadtime2023-12-18T09:40:39ZTom Krizekstatschannel test intermittently fails with incorrect zone loadtimeAfter #3983 was fixed and the `loadtime` check was re-enabled, the following tests occasionally [fail](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3848463) because the `loadtime` retrieved over stats channel is 0.
- `statschannel/t...After #3983 was fixed and the `loadtime` check was re-enabled, the following tests occasionally [fail](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3848463) because the `loadtime` retrieved over stats channel is 0.
- `statschannel/tests_xml.py::test_zone_timers_secondary_xml`
- `statschannel/tests_json.py::test_zone_timers_secondary_json`
```
________________________ test_zone_timers_secondary_xml ________________________
[gw1] linux -- Python 3.11.2 /usr/bin/python3
/builds/isc-projects/bind9/bin/tests/system/statschannel/tests_xml.py:118: in test_zone_timers_secondary_xml
generic.test_zone_timers_secondary(
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:101: in test_zone_timers_secondary
check_zone_timers(loaded, expires, refresh, mtime)
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:56: in check_zone_timers
check_loaded(loaded, loaded_exp, now)
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:45: in check_loaded
assert loaded == expected
E assert datetime.datetime(2023, 12, 6, 0, 28, 43) == datetime.datetime(1970, 1, 1, 0, 0)
```January 2024 (9.16.46, 9.16.46-S1, 9.18.22, 9.18.22-S1, 9.19.20) (❗RECALLED❗)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4476CID 469729: Control flow issue in lib/isccfg/kaspconf.c2023-12-06T12:51:25ZMichal NowakCID 469729: Control flow issue in lib/isccfg/kaspconf.cCoverity Scan claims a control flow issue in `lib/isccfg/kaspconf.c` after !8515.
```
*** CID 469729: Control flow issues (UNREACHABLE)
/lib/isccfg/kaspconf.c: 300 in cfg_nsec3param_fromconfig()
294 if (iter != DEFAULT_NSEC3PARAM...Coverity Scan claims a control flow issue in `lib/isccfg/kaspconf.c` after !8515.
```
*** CID 469729: Control flow issues (UNREACHABLE)
/lib/isccfg/kaspconf.c: 300 in cfg_nsec3param_fromconfig()
294 if (iter != DEFAULT_NSEC3PARAM_ITER) {
295 cfg_obj_log(obj, logctx, ISC_LOG_ERROR,
296 "dnssec-policy: nsec3 iterations value %u "
297 "not allowed, must be zero",
298 iter);
299 return (DNS_R_NSEC3ITERRANGE);
>>> CID 469729: Control flow issues (UNREACHABLE)
>>> This code cannot be reached: "return ret;".
300 return (ret);
301 }
302
303 /* Opt-out? */
304 obj = cfg_tuple_get(config, "optout");
305 if (cfg_obj_isboolean(obj)) {
```December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4474Unexpected hash table miss in ixfr system test2023-12-06T05:44:44ZMark AndrewsUnexpected hash table miss in ixfr system testhttps://gitlab.isc.org/isc-private/bind9/-/jobs/3848787
```
2023-12-06 02:05:43 INFO:ixfr I:ixfr_tmp_aodmwieh:testing initial AXFR (1)
2023-12-06 02:05:44 INFO:ixfr I:ixfr_tmp_aodmwieh:ns1 server reload successful
2023-12-06 02:...https://gitlab.isc.org/isc-private/bind9/-/jobs/3848787
```
2023-12-06 02:05:43 INFO:ixfr I:ixfr_tmp_aodmwieh:testing initial AXFR (1)
2023-12-06 02:05:44 INFO:ixfr I:ixfr_tmp_aodmwieh:ns1 server reload successful
2023-12-06 02:05:44 INFO:ixfr I:ixfr_tmp_aodmwieh:testing successful IXFR (2)
2023-12-06 02:05:45 INFO:ixfr I:ixfr_tmp_aodmwieh:ns1 zone refresh queued
2023-12-06 02:05:47 INFO:ixfr I:ixfr_tmp_aodmwieh:failed
2023-12-06 02:05:47 INFO:ixfr I:ixfr_tmp_aodmwieh:testing AXFR fallback after IXFR failure (not exact error) (3)
2023-12-06 02:05:48 INFO:ixfr I:ixfr_tmp_aodmwieh:ns1 zone refresh queued
2023-12-06 02:05:51 INFO:ixfr I:ixfr_tmp_aodmwieh:failed
2023-12-06 02:05:51 INFO:ixfr I:ixfr_tmp_aodmwieh:testing AXFR fallback after IXFR failure (bad SOA owner) (4)
2023-12-06 02:05:51 INFO:ixfr I:ixfr_tmp_aodmwieh:ns1 zone refresh queued
2023-12-06 02:06:00 INFO:ixfr I:ixfr_tmp_aodmwieh:timed out waiting for version 4 of zone nil. to be transferred
2023-12-06 02:06:00 INFO:ixfr I:ixfr_tmp_aodmwieh:ns1 zone refresh queued
2023-12-06 02:06:00 INFO:ixfr I:ixfr_tmp_aodmwieh:failed
2023-12-06 02:06:00 INFO:ixfr I:ixfr_tmp_aodmwieh:testing ixfr-from-differences option (5)
2023-12-06 02:06:01 INFO:ixfr I:ixfr_tmp_aodmwieh:ns3 server reload successful
2023-12-06 02:06:02 INFO:ixfr I:ixfr_tmp_aodmwieh:failed
2023-12-06 02:06:02 INFO:ixfr I:ixfr_tmp_aodmwieh:testing 'request-ixfr no' option inheritance from view (6)
2023-12-06 02:06:04 INFO:ixfr I:ixfr_tmp_aodmwieh:ns3 server reload successful
2023-12-06 02:06:05 INFO:ixfr I:ixfr_tmp_aodmwieh:testing 'request-ixfr yes' option inheritance from view (7)
2023-12-06 02:06:06 INFO:ixfr I:ixfr_tmp_aodmwieh:ns3 server reload successful
2023-12-06 02:06:07 INFO:ixfr I:ixfr_tmp_aodmwieh:testing DiG's handling of a multi message AXFR style IXFR response (8)
2023-12-06 02:06:07 INFO:ixfr I:ixfr_tmp_aodmwieh:test 'dig +notcp ixfr=<value>' vs 'dig ixfr=<value> +notcp' vs 'dig ixfr=<value>' (9)
2023-12-06 02:06:07 INFO:ixfr I:ixfr_tmp_aodmwieh:check estimated IXFR size (10)
2023-12-06 02:06:12 INFO:ixfr I:ixfr_tmp_aodmwieh:test 'provide-ixfr no;' (serial < current) (11)
2023-12-06 02:06:12 INFO:ixfr I:ixfr_tmp_aodmwieh:test 'provide-ixfr no;' (serial = current) (12)
2023-12-06 02:06:12 INFO:ixfr I:ixfr_tmp_aodmwieh:test 'provide-ixfr no;' (serial > current) (13)
2023-12-06 02:06:12 INFO:ixfr I:ixfr_tmp_aodmwieh:checking whether dig calculates IXFR statistics correctly (14)
2023-12-06 02:06:12 INFO:ixfr I:ixfr_tmp_aodmwieh:checking whether named calculates incoming IXFR statistics correctly (15)
2023-12-06 02:06:12 INFO:ixfr I:ixfr_tmp_aodmwieh:checking whether named calculates outgoing IXFR statistics correctly (16)
2023-12-06 02:06:12 INFO:ixfr I:ixfr_tmp_aodmwieh:testing fallback to AXFR when max-ixfr-ratio is exceeded (17)
2023-12-06 02:06:13 INFO:ixfr I:ixfr_tmp_aodmwieh:ns3 server reload successful
2023-12-06 02:06:17 INFO:ixfr I:ixfr_tmp_aodmwieh:exit status: 4
```
```
06-Dec-2023 02:05:45.901 queue_xfrin: zone nil/IN: enter
06-Dec-2023 02:05:45.901 zone nil/IN: Transfer started.
06-Dec-2023 02:05:45.901 req_destroy: request 0x7f232dcf5000
06-Dec-2023 02:05:45.901 zone nil/IN: requesting IXFR from 10.53.0.2#22502
06-Dec-2023 02:05:45.901 dispatchmgr 0x7f23359988c0: dns_dispatch_createtcp: created TCP dispatch 0x7f232dcfa540 for 10.53.0.1#0
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP response 0x7f232dc2a280: connecting from 10.53.0.1#0 to 10.53.0.2#22502, timeout 30000
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: connected from 10.53.0.1#0 to 10.53.0.2#22502: success
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP response 0x7f232dc2a280: start reading
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP reading without response from 0x7f232dcfa8c0
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP response 0x7f232dc2a280: connect callback: success
06-Dec-2023 02:05:45.901 0x7f232dd01000: transfer of 'nil/IN' from 10.53.0.2#22502: connected using 10.53.0.2#22502
06-Dec-2023 02:05:45.901 0x7f232dd01000: transfer of 'nil/IN' from 10.53.0.2#22502: requesting IXFR for serial 1
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP response 0x7f232dc2a280: sending
06-Dec-2023 02:05:45.901 0x7f232dd01000: transfer of 'nil/IN' from 10.53.0.2#22502: sending IXFR request, QID 0
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP response 0x7f232dc2a280: sent: success
06-Dec-2023 02:05:45.901 0x7f232dd01000: transfer of 'nil/IN' from 10.53.0.2#22502: sent request data
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP read:success:requests 1
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP read success, length == 332, addr = 0x7f2335180982
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: got valid DNS message header, /QR 1, id 15280
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: search for response in hashtable: not found
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: shutting down due to TCP receive error: 10.53.0.2#22502: unexpected error
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP response 0x7f232dc2a280: read callback: unexpected error
06-Dec-2023 02:05:45.901 0x7f232dd01000: transfer of 'nil/IN' from 10.53.0.2#22502: failed while receiving responses: unexpected error
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP response 0x7f232dc2a280: canceling response: operation canceled, connected/not reading (canceled/not reading), requests 1
06-Dec-2023 02:05:45.901 zone nil/IN: zone transfer finished: unexpected error
06-Dec-2023 02:05:45.901 0x7f232dd01000: transfer of 'nil/IN' from 10.53.0.2#22502: Transfer status: unexpected error
06-Dec-2023 02:05:45.901 0x7f232dd01000: transfer of 'nil/IN' from 10.53.0.2#22502: Transfer completed: 0 messages, 0 records, 0 bytes, 0.001 secs (0 bytes/sec) (serial 0)
06-Dec-2023 02:05:45.901 0x7f232dd01000: transfer of 'nil/IN' from 10.53.0.2#22502: freeing transfer context
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP response 0x7f232dc2a280: canceling response: operation canceled, canceled/not reading (canceled/not reading), requests 1
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP response 0x7f232dc2a280: destroying
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: destroying dispatch 0x7f232dcfa540
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: detaching TCP handle 0x7f232dcfa8c0 from 0x7f232dcfa568
06-Dec-2023 02:05:45.901 zone__settimer: zone nil/IN: enter
```January 2024 (9.16.46, 9.16.46-S1, 9.18.22, 9.18.22-S1, 9.19.20) (❗RECALLED❗)https://gitlab.isc.org/isc-projects/bind9/-/issues/4467Numerical statistics are truncated to 32-bits on export2024-01-04T16:47:06ZPetr Špačekpspacek@isc.orgNumerical statistics are truncated to 32-bits on export### Summary
In BIND statistics, values larger than 4294967295 overflow during export. E.g. any server which processes more 4294967295 queries will see nonsense in statistics. This can conceivably happen in practice within a single day i...### Summary
In BIND statistics, values larger than 4294967295 overflow during export. E.g. any server which processes more 4294967295 queries will see nonsense in statistics. This can conceivably happen in practice within a single day if server is handling sustained ~ 50 k QPS.
Internally tracking still works up to 2^63-1, i.e. 9223372036854775807, but there is no way to get the data out without using debugger.
### BIND version used
Broken by 4e5edb35e475e4868ccbb8e4796b3fbe8ac90bb7, MR !1493.
* ~"Affects v9.19": f8fece81bf651275c3914d2559717943228a4cfd
* ~"Affects v9.18": acf55e125e946f39df96aca26608b01c46968a7b
* ~"Affects v9.16": 161d69aba357fa830bb6ef2b097b0447929041f0
### Steps to reproduce
It's kinda lengthy. Just do 2^32 queries and check /json/v1/server opcodes[] stats to see if they ever exceed 2^32-1.
### What is the current *bug* behavior?
Counters are not monotonic because of the overflow during export.
### What is the expected *correct* behavior?
No information loss.January 2024 (9.16.46, 9.16.46-S1, 9.18.22, 9.18.22-S1, 9.19.20) (❗RECALLED❗)Petr Špačekpspacek@isc.orgPetr Špačekpspacek@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4466CDS is stuck on an old key.2024-01-12T08:57:15ZBjörn PerssonCDS is stuck on an old key.### Summary
The zone rombobeorn.se seems to be stuck in a CSK rollover that never gets finished. The CDS record still specifies the old key. Thus the parent zone doesn't update DS. Thus the old DNSKEY record can't be removed.
### BIND ...### Summary
The zone rombobeorn.se seems to be stuck in a CSK rollover that never gets finished. The CDS record still specifies the old key. Thus the parent zone doesn't update DS. Thus the old DNSKEY record can't be removed.
### BIND version used
```
# named -V
BIND 9.18.19-1~deb12u1-Debian (Extended Support Version) <id:>
running on Linux x86_64 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29)
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/reproducible-path/bind9-9.18.19=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 12.2.0
compiled with OpenSSL version: OpenSSL 3.0.10 1 Aug 2023
linked to OpenSSL version: OpenSSL 3.0.11 19 Sep 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.52.0
linked to libnghttp2 version: 1.52.0
compiled with libxml2 version: 2.9.14
linked to libxml2 version: 20914
compiled with json-c version: 0.16
linked to json-c version: 0.16
compiled with zlib version: 1.2.13
linked to zlib version: 1.2.13
linked to maxminddb version: 1.7.1
compiled with protobuf-c version: 1.4.1
linked to protobuf-c version: 1.4.1
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
This zone has successfully replaced one CSK with another before. This was the DNSsec policy at the time:
```
dnssec-policy "automatik" {
keys {
csk lifetime P1M algorithm rsasha256 2048;
};
};
```
In an attempt to decrease the time the zone spends with dual keys, I changed the policy to this:
```
dnssec-policy "automatik" {
keys {
csk lifetime P1M algorithm rsasha256 2048;
};
dnskey-ttl P1D;
max-zone-ttl P1D;
signatures-validity P1W;
signatures-refresh P2D;
};
```
### What is the current *bug* behavior?
On 2023-11-20 it was time for another rollover. CSK 58364 was generated and published in a second DNSKEY record. The DNSKEY, CDS and CDNSKEY records were signed with both the old and the new key. Other records had their signatures replaced gradually. Since 2023-12-01 all the records except DNSKEY, CDS and CDNSKEY have signatures only by the new key. Yet CDS and CDNSKEY still show the old key, 44674. You can check it yourself:
```
$ dig +short CDS rombobeorn.se
44674 8 2 DC0A35038C492439E044C0A109A62A7447427B606104613D7BA4B32D 2EDAC3FB
```
On 2023-12-02 it was time to renew the signatures for DNSKEY, CDS and CDNSKEY. They were again signed with both keys. There are still dual DNSKEY records.
Validation still succeeds, presumably because the new key is signed with the old key. Bind seems to understand that it can't remove the old key yet, but it's not publishing a CDS record for the new key.
### What is the expected *correct* behavior?
If the policy I have configured is wrong somehow, then it should have been rejected with an informative error message. Otherwise the CDS record (and CDNSKEY) should have been changed to 58364 by now.
### Relevant configuration files
```
options {
directory "/var/cache/bind";
dnssec-validation auto;
key-directory "/var/lib/bind";
listen-on-v6 { any; };
};
dnssec-policy "som_det_var" {
keys {
ksk lifetime unlimited algorithm rsasha256 2048;
zsk lifetime unlimited algorithm rsasha256 2048;
};
dnskey-ttl P1D;
purge-keys 0;
};
dnssec-policy "automatik" {
keys {
csk lifetime P1M algorithm rsasha256 2048;
};
dnskey-ttl P1D;
max-zone-ttl P1D;
signatures-validity P1W;
signatures-refresh P2D;
};
view "internal" {
match-clients { [omitted] };
recursion yes;
allow-recursion { [omitted] };
allow-transfer { [omitted] };
notify no;
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/zones.rfc1918";
zone "xn--rombobjrn-67a.se" {
type master;
file "/var/lib/bind/db.xn--rombobjrn-67a.se.internal";
dnssec-policy automatik;
parental-agents { ::1; };
inline-signing no;
update-policy { [omitted] };
};
zone "rombobeorn.se" {
type master;
file "/var/lib/bind/db.rombobeorn.se.internal";
dnssec-policy automatik;
parental-agents { ::1; };
inline-signing no;
update-policy { [omitted] };
};
zone "168.192.in-addr.arpa" {
type master;
file "/var/lib/bind/db.168.192";
update-policy { [omitted] };
};
};
view "external" {
match-clients {
any;
};
recursion no;
allow-transfer { [omitted] };
also-notify { [omitted] };
notify explicit;
rate-limit {
responses-per-second 4;
slip 2;
};
zone "xn--rombobjrn-67a.se" {
type master;
file "/var/lib/bind/db.xn--rombobjrn-67a.se.external";
dnssec-policy automatik;
parental-agents { ::1; };
inline-signing no;
update-policy { [omitted] };
};
zone "rombobeorn.se" {
type master;
file "/var/lib/bind/db.rombobeorn.se.external";
dnssec-policy automatik;
parental-agents { ::1; };
inline-signing no;
update-policy { [omitted] };
};
};
```
### Relevant logs and/or screenshots
As a baseline, these messages about two previously retired keys were repeated every hour:
```
2023-11-20T04:05:53.076358+01:00 cutie named[443161]: zone rombobeorn.se/IN/internal: reconfiguring zone keys
2023-11-20T04:05:53.105296+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/50640 (ZSK)
2023-11-20T04:05:53.105790+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/48019 (KSK)
2023-11-20T04:05:53.109375+01:00 cutie named[443161]: zone rombobeorn.se/IN/internal: next key event: 20-Nov-2023 05:04:58.070
2023-11-20T04:05:53.206927+01:00 cutie named[443161]: zone rombobeorn.se/IN/external: reconfiguring zone keys
2023-11-20T04:05:53.237195+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/50640 (ZSK)
2023-11-20T04:05:53.237622+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/48019 (KSK)
2023-11-20T04:05:53.241190+01:00 cutie named[443161]: zone rombobeorn.se/IN/external: next key event: 20-Nov-2023 05:04:58.202
```
Then the new key was generated, and a message about that key was added to the hourly repeats:
```
2023-11-20T05:04:58.076407+01:00 cutie named[443161]: zone rombobeorn.se/IN/internal: reconfiguring zone keys
2023-11-20T05:04:58.105335+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/50640 (ZSK)
2023-11-20T05:04:58.105847+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/48019 (KSK)
2023-11-20T05:05:02.049479+01:00 cutie named[443161]: keymgr: DNSKEY rombobeorn.se/RSASHA256/58364 (CSK) created for policy automatik
2023-11-20T05:05:02.057591+01:00 cutie named[443161]: Fetching rombobeorn.se/RSASHA256/58364 (CSK) from key repository.
2023-11-20T05:05:02.058067+01:00 cutie named[443161]: DNSKEY rombobeorn.se/RSASHA256/58364 (CSK) is now published
2023-11-20T05:05:02.136470+01:00 cutie named[443161]: zone rombobeorn.se/IN/internal: next key event: 20-Nov-2023 06:04:58.070
2023-11-20T05:05:02.137062+01:00 cutie named[443161]: zone rombobeorn.se/IN/external: reconfiguring zone keys
2023-11-20T05:05:02.160374+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/50640 (ZSK)
2023-11-20T05:05:02.160830+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/48019 (KSK)
2023-11-20T05:05:02.163720+01:00 cutie named[443161]: Fetching rombobeorn.se/RSASHA256/58364 (CSK) from key repository.
2023-11-20T05:05:02.164031+01:00 cutie named[443161]: DNSKEY rombobeorn.se/RSASHA256/58364 (CSK) is now published
2023-11-20T05:05:02.242215+01:00 cutie named[443161]: zone rombobeorn.se/IN/external: next key event: 20-Nov-2023 06:05:02.134
2023-11-20T06:04:58.076558+01:00 cutie named[443161]: zone rombobeorn.se/IN/internal: reconfiguring zone keys
2023-11-20T06:04:58.118725+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/50640 (ZSK)
2023-11-20T06:04:58.119254+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/48019 (KSK)
2023-11-20T06:04:58.123463+01:00 cutie named[443161]: DNSKEY rombobeorn.se/RSASHA256/58364 (CSK) is now inactive
2023-11-20T06:04:58.125009+01:00 cutie named[443161]: zone rombobeorn.se/IN/internal: next key event: 20-Nov-2023 07:04:58.072
2023-11-20T06:05:02.140288+01:00 cutie named[443161]: zone rombobeorn.se/IN/external: reconfiguring zone keys
2023-11-20T06:05:02.183496+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/50640 (ZSK)
2023-11-20T06:05:02.183962+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/48019 (KSK)
2023-11-20T06:05:02.188257+01:00 cutie named[443161]: DNSKEY rombobeorn.se/RSASHA256/58364 (CSK) is now inactive
2023-11-20T06:05:02.189804+01:00 cutie named[443161]: zone rombobeorn.se/IN/external: next key event: 20-Nov-2023 07:05:02.136
```
25 hours later the messages started appearing every ten minutes, claiming falsely that CDS and CDNSKEY had been updated:
```
2023-11-21T06:09:58.116346+01:00 cutie named[443161]: zone rombobeorn.se/IN/internal: reconfiguring zone keys
2023-11-21T06:09:58.158703+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/50640 (ZSK)
2023-11-21T06:09:58.159244+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/48019 (KSK)
2023-11-21T06:09:58.171210+01:00 cutie named[443161]: CDS for key rombobeorn.se/RSASHA256/58364 is now published
2023-11-21T06:09:58.171736+01:00 cutie named[443161]: CDNSKEY for key rombobeorn.se/RSASHA256/58364 is now published
2023-11-21T06:09:58.178814+01:00 cutie named[443161]: zone rombobeorn.se/IN/external: reconfiguring zone keys
2023-11-21T06:09:58.219756+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/50640 (ZSK)
2023-11-21T06:09:58.222083+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/48019 (KSK)
2023-11-21T06:09:58.223643+01:00 cutie named[443161]: CDS for key rombobeorn.se/RSASHA256/58364 is now published
2023-11-21T06:09:58.223970+01:00 cutie named[443161]: CDNSKEY for key rombobeorn.se/RSASHA256/58364 is now published
2023-11-21T06:19:58.172402+01:00 cutie named[443161]: zone rombobeorn.se/IN/internal: reconfiguring zone keys
2023-11-21T06:19:58.214907+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/50640 (ZSK)
2023-11-21T06:19:58.215409+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/48019 (KSK)
2023-11-21T06:19:58.220135+01:00 cutie named[443161]: CDS for key rombobeorn.se/RSASHA256/58364 is now published
2023-11-21T06:19:58.220718+01:00 cutie named[443161]: CDNSKEY for key rombobeorn.se/RSASHA256/58364 is now published
2023-11-21T06:19:58.222976+01:00 cutie named[443161]: zone rombobeorn.se/IN/external: reconfiguring zone keys
2023-11-21T06:19:58.261817+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/50640 (ZSK)
2023-11-21T06:19:58.262297+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/48019 (KSK)
2023-11-21T06:19:58.265388+01:00 cutie named[443161]: CDS for key rombobeorn.se/RSASHA256/58364 is now published
2023-11-21T06:19:58.265739+01:00 cutie named[443161]: CDNSKEY for key rombobeorn.se/RSASHA256/58364 is now published
```
After another six days a message about the old key was added:
```
2023-11-27T07:24:01.188353+01:00 cutie named[443161]: zone rombobeorn.se/IN/internal: reconfiguring zone keys
2023-11-27T07:24:01.231048+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/50640 (ZSK)
2023-11-27T07:24:01.231673+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/48019 (KSK)
2023-11-27T07:24:01.249383+01:00 cutie named[443161]: DNSKEY rombobeorn.se/RSASHA256/44674 (CSK) is now inactive
2023-11-27T07:24:01.250501+01:00 cutie named[443161]: CDS for key rombobeorn.se/RSASHA256/58364 is now published
2023-11-27T07:24:01.250919+01:00 cutie named[443161]: CDNSKEY for key rombobeorn.se/RSASHA256/58364 is now published
2023-11-27T07:24:01.253391+01:00 cutie named[443161]: zone rombobeorn.se/IN/external: reconfiguring zone keys
2023-11-27T07:24:01.287956+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/50640 (ZSK)
2023-11-27T07:24:01.288376+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/48019 (KSK)
2023-11-27T07:24:01.290787+01:00 cutie named[443161]: DNSKEY rombobeorn.se/RSASHA256/44674 (CSK) is now inactive
2023-11-27T07:24:01.291398+01:00 cutie named[443161]: CDS for key rombobeorn.se/RSASHA256/58364 is now published
2023-11-27T07:24:01.291732+01:00 cutie named[443161]: CDNSKEY for key rombobeorn.se/RSASHA256/58364 is now published
2023-11-27T07:34:01.256339+01:00 cutie named[443161]: zone rombobeorn.se/IN/internal: reconfiguring zone keys
2023-11-27T07:34:01.299042+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/50640 (ZSK)
2023-11-27T07:34:01.299657+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/48019 (KSK)
2023-11-27T07:34:01.303256+01:00 cutie named[443161]: DNSKEY rombobeorn.se/RSASHA256/44674 (CSK) is now inactive
2023-11-27T07:34:01.304268+01:00 cutie named[443161]: CDS for key rombobeorn.se/RSASHA256/58364 is now published
2023-11-27T07:34:01.304659+01:00 cutie named[443161]: CDNSKEY for key rombobeorn.se/RSASHA256/58364 is now published
2023-11-27T07:34:01.307121+01:00 cutie named[443161]: zone rombobeorn.se/IN/external: reconfiguring zone keys
2023-11-27T07:34:01.346113+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/50640 (ZSK)
2023-11-27T07:34:01.346504+01:00 cutie named[443161]: keymgr: retire DNSKEY rombobeorn.se/RSASHA256/48019 (KSK)
2023-11-27T07:34:01.348830+01:00 cutie named[443161]: DNSKEY rombobeorn.se/RSASHA256/44674 (CSK) is now inactive
2023-11-27T07:34:01.349518+01:00 cutie named[443161]: CDS for key rombobeorn.se/RSASHA256/58364 is now published
2023-11-27T07:34:01.349707+01:00 cutie named[443161]: CDNSKEY for key rombobeorn.se/RSASHA256/58364 is now published
```
Those messages are still being repeated every ten minutes, and that "inactive" key is still current according to CDS.
Here's what the key states were right after the new key was generated at 2023-11-20 05:05:
```
; This is the state of key 44674, for rombobeorn.se.
Algorithm: 8
Length: 2048
Lifetime: 2678400
Predecessor: 26869
Successor: 58364
KSK: yes
ZSK: yes
Generated: 20231020040458 (Fri Oct 20 06:04:58 2023)
Published: 20231020040458 (Fri Oct 20 06:04:58 2023)
Active: 20231020060958 (Fri Oct 20 08:09:58 2023)
Retired: 20231120060958 (Mon Nov 20 07:09:58 2023)
Removed: 20231126071458 (Sun Nov 26 08:14:58 2023)
DSPublish: 20231020160958 (Fri Oct 20 18:09:58 2023)
PublishCDS: 20231020060958 (Fri Oct 20 08:09:58 2023)
DSPubCount: 1
DNSKEYChange: 20231020060958 (Fri Oct 20 08:09:58 2023)
ZRRSIGChange: 20231030071458 (Mon Oct 30 08:14:58 2023)
KRRSIGChange: 20231020060958 (Fri Oct 20 08:09:58 2023)
DSChange: 20231021180958 (Sat Oct 21 20:09:58 2023)
DNSKEYState: omnipresent
ZRRSIGState: omnipresent
KRRSIGState: omnipresent
DSState: omnipresent
GoalState: hidden
```
```
; This is the state of key 58364, for rombobeorn.se.
Algorithm: 8
Length: 2048
Lifetime: 2678400
Predecessor: 44674
KSK: yes
ZSK: yes
Generated: 20231120040458 (Mon Nov 20 05:04:58 2023)
Published: 20231120040458 (Mon Nov 20 05:04:58 2023)
Active: 20231120060958 (Mon Nov 20 07:09:58 2023)
Retired: 20231221060958 (Thu Dec 21 07:09:58 2023)
Removed: 20231227071458 (Wed Dec 27 08:14:58 2023)
PublishCDS: 20231121050958 (Tue Nov 21 06:09:58 2023)
DNSKEYChange: 20231120040458 (Mon Nov 20 05:04:58 2023)
ZRRSIGChange: 20231120040458 (Mon Nov 20 05:04:58 2023)
KRRSIGChange: 20231120040458 (Mon Nov 20 05:04:58 2023)
DSChange: 20231120040458 (Mon Nov 20 05:04:58 2023)
DNSKEYState: rumoured
ZRRSIGState: hidden
KRRSIGState: rumoured
DSState: hidden
GoalState: omnipresent
```
At 2023-11-21 06:09 the new key's state looked like this:
```
; This is the state of key 58364, for rombobeorn.se.
Algorithm: 8
Length: 2048
Lifetime: 2678400
Predecessor: 44674
KSK: yes
ZSK: yes
Generated: 20231120040458 (Mon Nov 20 05:04:58 2023)
Published: 20231120040458 (Mon Nov 20 05:04:58 2023)
Active: 20231120060958 (Mon Nov 20 07:09:58 2023)
Retired: 20231221060958 (Thu Dec 21 07:09:58 2023)
Removed: 20231227071458 (Wed Dec 27 08:14:58 2023)
PublishCDS: 20231121050958 (Tue Nov 21 06:09:58 2023)
DNSKEYChange: 20231121050958 (Tue Nov 21 06:09:58 2023)
ZRRSIGChange: 20231121050958 (Tue Nov 21 06:09:58 2023)
KRRSIGChange: 20231121050958 (Tue Nov 21 06:09:58 2023)
DSChange: 20231121050958 (Tue Nov 21 06:09:58 2023)
DNSKEYState: omnipresent
ZRRSIGState: rumoured
KRRSIGState: omnipresent
DSState: rumoured
GoalState: omnipresent
```
Then, at 2023-11-27 07:24 the key states changed into this:
```
; This is the state of key 44674, for rombobeorn.se.
Algorithm: 8
Length: 2048
Lifetime: 2678400
Predecessor: 26869
Successor: 58364
KSK: yes
ZSK: yes
Generated: 20231020040458 (Fri Oct 20 06:04:58 2023)
Published: 20231020040458 (Fri Oct 20 06:04:58 2023)
Active: 20231020060958 (Fri Oct 20 08:09:58 2023)
Retired: 20231120060958 (Mon Nov 20 07:09:58 2023)
Removed: 20231126071458 (Sun Nov 26 08:14:58 2023)
DSPublish: 20231020160958 (Fri Oct 20 18:09:58 2023)
PublishCDS: 20231020060958 (Fri Oct 20 08:09:58 2023)
DSPubCount: 1
DNSKEYChange: 20231020060958 (Fri Oct 20 08:09:58 2023)
ZRRSIGChange: 20231127062401 (Mon Nov 27 07:24:01 2023)
KRRSIGChange: 20231020060958 (Fri Oct 20 08:09:58 2023)
DSChange: 20231021180958 (Sat Oct 21 20:09:58 2023)
DNSKEYState: omnipresent
ZRRSIGState: unretentive
KRRSIGState: omnipresent
DSState: omnipresent
GoalState: hidden
```
```
; This is the state of key 58364, for rombobeorn.se.
Algorithm: 8
Length: 2048
Lifetime: 2678400
Predecessor: 44674
KSK: yes
ZSK: yes
Generated: 20231120040458 (Mon Nov 20 05:04:58 2023)
Published: 20231120040458 (Mon Nov 20 05:04:58 2023)
Active: 20231120060958 (Mon Nov 20 07:09:58 2023)
Retired: 20231221060958 (Thu Dec 21 07:09:58 2023)
Removed: 20231227071458 (Wed Dec 27 08:14:58 2023)
PublishCDS: 20231121050958 (Tue Nov 21 06:09:58 2023)
DNSKEYChange: 20231121050958 (Tue Nov 21 06:09:58 2023)
ZRRSIGChange: 20231127062401 (Mon Nov 27 07:24:01 2023)
KRRSIGChange: 20231121050958 (Tue Nov 21 06:09:58 2023)
DSChange: 20231121050958 (Tue Nov 21 06:09:58 2023)
DNSKEYState: omnipresent
ZRRSIGState: omnipresent
KRRSIGState: omnipresent
DSState: rumoured
GoalState: omnipresent
```
Most recently, the old key's state changed at 2023-12-03 08:34:
```
; This is the state of key 44674, for rombobeorn.se.
Algorithm: 8
Length: 2048
Lifetime: 2678400
Predecessor: 26869
Successor: 58364
KSK: yes
ZSK: yes
Generated: 20231020040458 (Fri Oct 20 06:04:58 2023)
Published: 20231020040458 (Fri Oct 20 06:04:58 2023)
Active: 20231020060958 (Fri Oct 20 08:09:58 2023)
Retired: 20231120060958 (Mon Nov 20 07:09:58 2023)
Removed: 20231126071458 (Sun Nov 26 08:14:58 2023)
DSPublish: 20231020160958 (Fri Oct 20 18:09:58 2023)
PublishCDS: 20231020060958 (Fri Oct 20 08:09:58 2023)
DSPubCount: 1
DNSKEYChange: 20231020060958 (Fri Oct 20 08:09:58 2023)
ZRRSIGChange: 20231203073446 (Sun Dec 3 08:34:46 2023)
KRRSIGChange: 20231020060958 (Fri Oct 20 08:09:58 2023)
DSChange: 20231021180958 (Sat Oct 21 20:09:58 2023)
DNSKEYState: omnipresent
ZRRSIGState: hidden
KRRSIGState: omnipresent
DSState: omnipresent
GoalState: hidden
```
Other possibly useful state:
```
# rndc dnssec -status rombobeorn.se IN external
dnssec-policy: automatik
current time: Mon Dec 4 10:30:48 2023
key: 26869 (RSASHA256), CSK
published: no
key signing: no
zone signing: no
Key has been removed from the zone
- goal: hidden
- dnskey: hidden
- ds: hidden
- zone rrsig: hidden
- key rrsig: hidden
key: 44674 (RSASHA256), CSK
published: yes - since Fri Oct 20 06:04:58 2023
key signing: yes - since Fri Oct 20 06:04:58 2023
zone signing: no
Key is retired, will be removed on Sun Nov 26 08:14:58 2023
- goal: hidden
- dnskey: omnipresent
- ds: omnipresent
- zone rrsig: hidden
- key rrsig: omnipresent
key: 50640 (RSASHA256), ZSK
published: no
zone signing: no
Key has been removed from the zone
- goal: hidden
- dnskey: hidden
- ds: unretentive
- zone rrsig: hidden
- key rrsig: hidden
key: 48019 (RSASHA256), KSK
published: no
key signing: no
Key has been removed from the zone
- goal: hidden
- dnskey: hidden
- ds: hidden
- zone rrsig: hidden
- key rrsig: hidden
key: 58364 (RSASHA256), CSK
published: yes - since Mon Nov 20 05:04:58 2023
key signing: yes - since Mon Nov 20 05:04:58 2023
zone signing: yes - since Mon Nov 20 07:09:58 2023
Next rollover scheduled on Wed Dec 20 06:04:58 2023
- goal: omnipresent
- dnskey: omnipresent
- ds: rumoured
- zone rrsig: omnipresent
- key rrsig: omnipresent
```
```
# rndc zonestatus rombobeorn.se IN external
name: rombobeorn.se
type: primary
files: /var/lib/bind/db.rombobeorn.se.external
serial: 2023092684
nodes: 14
last loaded: Mon, 23 Oct 2023 21:53:52 GMT
secure: yes
inline signing: no
key maintenance: automatic
next key event: Mon, 04 Dec 2023 09:34:54 GMT
next resign node: rombobeorn.se/MX
next resign time: Mon, 04 Dec 2023 22:20:46 GMT
dynamic: yes
frozen: no
reconfigurable via modzone: no
```January 2024 (9.16.46, 9.16.46-S1, 9.18.22, 9.18.22-S1, 9.19.20) (❗RECALLED❗)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4465Release Checklist for BIND 9.18.21, 9.18.21-S1, 9.19.192024-01-10T07:23:06ZTom KrizekRelease Checklist for BIND 9.18.21, 9.18.21-S1, 9.19.19## Release Schedule
**Code Freeze:** Wednesday, 6 December 2023
**Tagging Deadline:** Monday, 11 December 2023
**Public Release:** Wednesday, 20 December 2023
## Documentation Review Links
**Closed issues assigned to the milestone ...## Release Schedule
**Code Freeze:** Wednesday, 6 December 2023
**Tagging Deadline:** Monday, 11 December 2023
**Public Release:** Wednesday, 20 December 2023
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.18.21](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=December+2023+%289.16.46%2C+9.16.46-S1%2C+9.18.21%2C+9.18.21-S1%2C+9.19.19%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.18)
- [9.18.21-S1](https://gitlab.isc.org/isc-private/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=December+2023+%289.16.46%2C+9.16.46-S1%2C+9.18.21%2C+9.18.21-S1%2C+9.19.19%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.18-S)
- [9.19.19](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=December+2023+%289.16.46%2C+9.16.46-S1%2C+9.18.21%2C+9.18.21-S1%2C+9.19.19%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.19)
**Merge requests merged into the milestone without a release note:**
- [9.18.21](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=December+2023+%289.16.46%2C+9.16.46-S1%2C+9.18.21%2C+9.18.21-S1%2C+9.19.19%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.18)
- [9.18.21-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=December+2023+%289.16.46%2C+9.16.46-S1%2C+9.18.21%2C+9.18.21-S1%2C+9.19.19%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.18-sub)
- [9.19.19](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=December+2023+%289.16.46%2C+9.16.46-S1%2C+9.18.21%2C+9.18.21-S1%2C+9.19.19%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=main)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.18.21](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=December+2023+%289.16.46%2C+9.16.46-S1%2C+9.18.21%2C+9.18.21-S1%2C+9.19.19%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.18)
- [9.18.21-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=December+2023+%289.16.46%2C+9.16.46-S1%2C+9.18.21%2C+9.18.21-S1%2C+9.19.19%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.18-sub)
- [9.19.19](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=December+2023+%289.16.46%2C+9.16.46-S1%2C+9.18.21%2C+9.18.21-S1%2C+9.19.19%29&label_name%5B%5D=No+CHANGES&target_branch=main)
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Rebase -S editions on top of current open-source versions: `git checkout bind-9.18-sub && git rebase origin/bind-9.18`
- [x] ***(QA)*** [Inform](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/inform_supp_marketing.py) Support and Marketing of [impending release](https://mattermost.isc.org/isc/pl/6oeity9pxf8fmbgx43t5ofsm6a) (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform. Check [public](https://gitlab.isc.org/isc-projects/bind9/-/pipelines?scope=all&source=schedule) and [private](https://gitlab.isc.org/isc-private/bind9/-/pipelines?scope=all&source=schedule) scheduled pipelines.
- [x] ***(QA)*** Check charts from `shotgun:*` jobs in the scheduled pipelines to verify there is no unexplained performance drop for any protocol.
- [x] ***(QA)*** Check [Perflab](https://perflab.isc.org/) to ensure there has been no unexplained drop in performance for the versions being released.
- [x] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [x] ***(QA)*** Ensure that there are no outstanding [merge requests in the private repository](https://gitlab.isc.org/isc-private/bind9/-/merge_requests/)[^1] (Subscription Edition only).
- [x] ***(QA)*** [Ensure](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/check_backports.py) all merge requests marked for backporting have been indeed backported.
- [x] ***(QA)*** [Announce](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/inform_code_freeze.py) ([on Mattermost](https://mattermost.isc.org/isc/pl/gdh1dzxaqbyq8dyic4gqbr5wcy)) that the code freeze is in effect.
### 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](https://mattermost.isc.org/isc/pl/epghkxueoiysibjjwgcya4fgey) 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](https://gitlab.isc.org/isc-private/rpms/bind/-/pipelines/156507) ASN and/or Subscription Edition packages (in [cloudsmith branch in private repo](https://gitlab.isc.org/isc-private/rpms/bind/-/tree/cloudsmith)). [Example](https://gitlab.isc.org/isc-private/rpms/bind/-/commit/e2512f4cfaf991827a635e374e7e93b27a5f38ba)
- [x] ***(QA)*** Use the [Printing Press project](https://gitlab.isc.org/isc-private/printing-press/-/wikis/home#adding-new-documents) to prepare a [release announcement email](https://gitlab.isc.org/isc-private/printing-press/-/merge_requests/83).
- [x] ~~***(Marketing)*** Update ASN documents in the SF portal.~~
- [x] ~~***(Marketing)*** Send out ASN emails (if applicable).~~
### On the Day of Public Release
- [x] ~~***(QA)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).~~
- [x] ***(QA)*** Place tarballs in public location on FTP site.
- [x] ***(QA)*** Inform Marketing of the release, providing FTP links for the published tarballs.
- [x] ***(Marketing)*** Publish links to downloads on ISC website. [Example](https://gitlab.isc.org/website/theme-staging-site/-/commit/1ac7b30b73cb03228df4cd5651fa4e774ac35625)
- [x] ***(Marketing)*** Update the BIND -S information document in SF with download links to the new versions. (If this is a security release, this will have already been done as part of the ASN process.)
- [x] ***(Marketing)*** Update the Current Software Versions document in the SF portal if any stable versions were released.
- [x] ***(Marketing)*** Send the release announcement email to the *bind-announce* mailing list (and to *bind-users* if a major release - [example](https://lists.isc.org/pipermail/bind-users/2022-January/105624.html)).
- [x] ***(Marketing)*** Announce release on social media sites.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Support)*** Add the new releases to the [vulnerability matrix in the Knowledge Base](https://kb.isc.org/docs/aa-00913).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages in [private repo](https://gitlab.isc.org/isc-private/rpms/bind/-/tree/cloudsmith). [Example](https://gitlab.isc.org/isc-private/rpms/bind/-/commit/2007d566db81dd9dfd79e571e2f600a3bc284da4)
- [x] ***(QA)*** Build [public RPMs](https://gitlab.isc.org/isc-packages/rpms/bind). [Example commit](https://gitlab.isc.org/isc-packages/rpms/bind/-/commit/3b5e851ea7c4e3570371a4878b5461f02a44f8cc) which triggers [Copr builds](https://copr.fedorainfracloud.org/coprs/isc/) automatically
- [x] ***(SwEng)*** Build Debian/Ubuntu packages.
- [x] ***(SwEng)*** Update Docker files [here](https://gitlab.isc.org/isc-projects/bind9-docker/-/branches) and make sure push is synchronized to [GitHub](https://github.com/isc-projects/bind9-docker). [Docker Hub](https://hub.docker.com/r/internetsystemsconsortium/bind9) should pick it up automatically. [Example](https://gitlab.isc.org/isc-projects/bind9-docker/-/commit/cada7e10e9af951595c98bfffc4bd42512faac05)
- [x] ***(QA)*** Ensure all new tags are annotated and signed. `git show --show-signature v9.19.12`
- [x] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Using [`merge_tag.py`](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/merge_tag.py), merge published release tags back into the their relevant development/maintenance branches.
- [x] ***(QA)*** Ensure `allow_failure: true` is removed from the `cross-version-config-tests` job if it was set during the current release cycle.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public.
- [x] ***(QA)*** Sanitize [confidential issues](https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=milestone_due_desc&state=opened&confidential=yes) which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate[^2].
- [x] ***(QA)*** Update QA tools used in GitLab CI (e.g. Black, PyLint, Sphinx) by modifying the relevant [`Dockerfile`](https://gitlab.isc.org/isc-projects/images/-/merge_requests/228/diffs).
- [x] ***(QA)*** Run a pipeline to rebuild all [images](https://gitlab.isc.org/isc-projects/images) used in GitLab CI.
- [x] ***(QA)*** Update [`metadata.json`](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/metadata.json) with the upcoming release information.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.
[^2]: As a rule of thumb, security vulnerabilities which have reproducers merged to the public repository are considered okay for full disclosure.December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Tom KrizekTom Krizek2023-12-20https://gitlab.isc.org/isc-projects/bind9/-/issues/4464BIND can crash with assertion in the situation when a `tls` entry is used mul...2023-12-06T17:24:11ZArtem BoldarievBIND can crash with assertion in the situation when a `tls` entry is used multiple times to establish an outgoing connectionBIND can crash with assertion in the situation when a `tls` entry is used multiple times to establish an outgoing connection to other servers via TLS.
```
04-Dec-2023 13:38:33.746 tls.c:1187: REQUIRE(pstore != ((void *)0) && *pstore != ...BIND can crash with assertion in the situation when a `tls` entry is used multiple times to establish an outgoing connection to other servers via TLS.
```
04-Dec-2023 13:38:33.746 tls.c:1187: REQUIRE(pstore != ((void *)0) && *pstore != ((void *)0)) failed
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.19.19-dev.so(isc_backtrace_log+0x49) [0x7ffff7f4e6d7]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/bin/named/.libs/named() [0x42c0c6]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.19.19-dev.so(isc_assertion_failed+0x31) [0x7ffff7f4e052]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.19.19-dev.so(isc_tls_cert_store_free+0x42) [0x7ffff7f87ebd]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/dns/.libs/libdns-9.19.19-dev.so(dns_transport_get_tlsctx+0x6f1) [0x7ffff7de49f4]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/dns/.libs/libdns-9.19.19-dev.so(+0x696e6) [0x7ffff7c696e6]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/dns/.libs/libdns-9.19.19-dev.so(dns_dispatch_connect+0xb6) [0x7ffff7c69d32]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/dns/.libs/libdns-9.19.19-dev.so(+0x20acf2) [0x7ffff7e0acf2]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/dns/.libs/libdns-9.19.19-dev.so(dns_xfrin_create+0x2c0) [0x7ffff7e09469]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/dns/.libs/libdns-9.19.19-dev.so(+0x255a9b) [0x7ffff7e55a9b]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.19.19-dev.so(isc__async_cb+0x186) [0x7ffff7f4e500]
04-Dec-2023 13:38:33.746 /nix/store/lsp8kyfkyi35shk51alffb4vsll7030q-libuv-1.46.0/lib/libuv.so.1(+0x10543) [0x7ffff7730543]
04-Dec-2023 13:38:33.746 /nix/store/lsp8kyfkyi35shk51alffb4vsll7030q-libuv-1.46.0/lib/libuv.so.1(+0x238e5) [0x7ffff77438e5]
04-Dec-2023 13:38:33.746 /nix/store/lsp8kyfkyi35shk51alffb4vsll7030q-libuv-1.46.0/lib/libuv.so.1(uv_run+0xb0) [0x7ffff77311c0]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.19.19-dev.so(+0x571e0) [0x7ffff7f6c1e0]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.19.19-dev.so(+0x6e669) [0x7ffff7f83669]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.19.19-dev.so(+0x6e6ad) [0x7ffff7f836ad]
04-Dec-2023 13:38:33.746 /nix/store/qn3ggz5sf3hkjs2c797xf7nan3amdxmp-glibc-2.38-27/lib/libc.so.6(+0x8b084) [0x7ffff6e62084]
04-Dec-2023 13:38:33.746 /nix/store/qn3ggz5sf3hkjs2c797xf7nan3amdxmp-glibc-2.38-27/lib/libc.so.6(+0x10d60c) [0x7ffff6ee460c]
04-Dec-2023 13:38:33.746 exiting (due to assertion failure)
```
In particular, the problem reveals itself when multiple threads are trying to initialise a transport-specific TLS context and associated data from the context of multiple threads, like in the following situation:
```
tls tls-v1.3 {
protocols { TLSv1.3; };
prefer-server-ciphers yes;
};
zone "example-1" {
type secondary;
primaries port 22168 { 10.53.0.1 tls tls-v1.3; };
file "example-1.db";
allow-transfer { any; };
};
zone "example-2" {
type secondary;
primaries port 22169 { 10.53.0.1 tls tls-v1.3; };
file "example-2.db";
allow-transfer { any; };
};
zone "example-3" {
type secondary;
primaries port 22170 { 10.53.0.1 tls tls-v1.3; };
file "example-3.db";
allow-transfer { any; };
};
```
The error handling code is not correct for this case, as in some cases, freeing a TLS certificate store is not required. In this particular case it can be `NULL`.
The problem _does not_ reveal itself on each run.December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4462Crash on shutdown when DNSSEC validation is running: ENSURE(isc_mempool_getal...2023-12-06T18:35:00ZPetr Špačekpspacek@isc.orgCrash on shutdown when DNSSEC validation is running: ENSURE(isc_mempool_getallocated(*namepoolp) == 0) failed### Summary
(Summarize the bug encountered concisely.)
### BIND version used
* ~"Affects v9.19": 235659b95ad53fd51fa90105b17ba1a4e51df5b0
Does not affect:
* ~"v9.18": 6817bf1284fe8aea303365d2dd17bc5523e7a41b
* ~"v9.16": 161d69aba357f...### Summary
(Summarize the bug encountered concisely.)
### BIND version used
* ~"Affects v9.19": 235659b95ad53fd51fa90105b17ba1a4e51df5b0
Does not affect:
* ~"v9.18": 6817bf1284fe8aea303365d2dd17bc5523e7a41b
* ~"v9.16": 161d69aba357fa830bb6ef2b097b0447929041f0
* ~"v9.11 (EoL)": v9.11.37-S1
* Other versions were not tested
### Steps to reproduce
Essentially cause validator to work on something during shutdown. One possibility is simply random subdomain attack against a signed zone.
1. Run an auth:
- zone: [local.testiscorg.ch.zone.signed](/uploads/e33d65b59661293a9a2722c992b9edd7/local.testiscorg.ch.zone.signed)
- config: [auth.conf](/uploads/adcd06cde487e5da3f24dd6359084e2e/auth.conf)
- `named -g -c auth.conf`
2. Run `named` under attack:
- [resolver.conf](/uploads/7c06f9959cfaf7601a89623ae2efffe4/resolver.conf)
- `named -g -c resolver.conf -n1 -D resolver`
The `-n1` makes it easier to trigger.
3. Run random subdomain attack:
- [randnames.py](/uploads/ee30deec22e8da98fa2949b91ae54ce7/randnames.py)
- `python randlabels.py | dnsperf -s 127.0.0.1 -S1 -D`
4. SIGINT the resolver:
- `pkill -f resolver`
### What is the current *bug* behavior?
:boom:
```
message.c:4768: ENSURE(isc_mempool_getallocated(*namepoolp) == 0) failed
```
<details>
```
(gdb) bt
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x00007ffff6bea8a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2 0x00007ffff6b9a668 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007ffff6b824b8 in __GI_abort () at abort.c:79
#4 0x000055555557e3b2 in assertion_failed (file=0x7ffff7eae157 "message.c", line=4768, type=isc_assertiontype_ensure, cond=0x7ffff7eaf818 "isc_mempool_getallocated(*namepoolp) == 0") at main.c:234
#5 0x00007ffff7f502ea in isc_assertion_failed (file=0x7ffff7eae157 "message.c", line=4768, type=isc_assertiontype_ensure, cond=0x7ffff7eaf818 "isc_mempool_getallocated(*namepoolp) == 0") at assertions.c:48
#6 0x00007ffff7cf9a59 in dns_message_destroypools (namepoolp=0x7ffff3e38580, rdspoolp=0x7ffff3e38588) at message.c:4768
#7 0x00007ffff7de87c3 in dns_resolver__destroy (res=0x7ffff3e31c00) at resolver.c:9892
#8 0x00007ffff7dea2b4 in dns_resolver_unref (ptr=0x7ffff3e31c00) at resolver.c:10173
#9 0x00007ffff7dea38d in dns_resolver_detach (ptrp=0x7ffff3e6e848) at resolver.c:10173
#10 0x00007ffff7c6ed52 in destroy (adb=0x7ffff3e6e800) at adb.c:1830
#11 0x00007ffff7c6ef20 in dns_adb_unref (ptr=0x7ffff3e6e800) at adb.c:1838
#12 0x00007ffff7c6eff9 in dns_adb_detach (ptrp=0x7fffffff9dc0) at adb.c:1838
#13 0x00007ffff7e26a56 in dns_view_detach (viewp=0x7ffff13b3e08) at view.c:516
#14 0x00007ffff7e237dd in destroy_validator (val=0x7ffff13b3e00) at validator.c:3122
#15 0x00007ffff7e23f49 in dns_validator_unref (ptr=0x7ffff13b3e00) at validator.c:3226
#16 0x00007ffff7e24022 in dns_validator_detach (ptrp=0x7fffffff9fa0) at validator.c:3226
#17 0x00007ffff7e1c421 in validator_done_cb (arg=0x7ffff13b3e00) at validator.c:211
#18 0x00007ffff7f507ac in isc__async_cb (handle=0x7ffff3e90388) at async.c:111
#19 0x00007ffff78dba1b in uv__async_io (loop=0x7ffff3e90020, w=<optimized out>, events=<optimized out>) at src/unix/async.c:176
#20 0x00007ffff78f8d48 in uv__io_poll (loop=0x7ffff3e90020, timeout=<optimized out>) at src/unix/linux.c:1526
#21 0x00007ffff78e0fbf in uv_run (loop=0x7ffff3e90020, mode=UV_RUN_DEFAULT) at src/unix/core.c:447
#22 0x00007ffff7f6de2c in loop_thread (arg=0x7ffff3e90000) at loop.c:282
#23 0x00007ffff7f847fd in thread_body (wrap=0x7ffff3ee59c0) at thread.c:85
#24 0x00007ffff7f848b6 in isc_thread_main (func=0x7ffff7f6dcb2 <loop_thread>, arg=0x7ffff3e90000) at thread.c:116
#25 0x00007ffff7f6eead in isc_loopmgr_run (loopmgr=0x7ffff3e206c0) at loop.c:454
#26 0x00005555555810e2 in main (argc=5, argv=0x7fffffffe598) at main.c:1574
```
</details>
### What is the expected *correct* behavior?
No crash.December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4459[CVE-2023-50868] Preparing an NSEC3 closest encloser proof can exhaust CPU re...2024-03-28T14:11:11ZPetr Špačekpspacek@isc.org[CVE-2023-50868] Preparing an NSEC3 closest encloser proof can exhaust CPU resources| Quick Links | :link: |
| ------------------------ | ------------------------------------------------------------------------------ |
| Incident Manage...| Quick Links | :link: |
| ------------------------ | ------------------------------------------------------------------------------ |
| Incident Manager: | @pspacek |
| Deputy Incident Manager: | @ebf |
| Public Disclosure Date: | 2024-02-13 |
| CVSS Score: | [7.5][cvss_score] |
| Security Advisory: | isc-private/printing-press!93 |
| Mattermost Channel: | [CVE-2023-50868: NSEC3 closest encloser proof can exhaust CPU][mattermost_url] |
| Support Ticket: | N/A |
| Release Checklist: | #4555 |
[cvss_score]: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H&version=3.1
[mattermost_url]: https://mattermost.isc.org/isc/channels/cve-2023-50868-nsec3-closest-encloser-proof-can-exhaust-cpu
:bulb: **Click [here][checklist_explanations] (internal resource) for general information about the security incident handling process.**
[checklist_explanations]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations
### Earlier Than T-5
- [x] [:link:][step_deputy] **(IM)** Pick a Deputy Incident Manager
- :no_entry_sign: [:link:][step_respond] **(IM)** Respond to the bug reporter - found internally by @pspacek
- [x] [:link:][step_public_mrs] **(SwEng)** Ensure there are no public merge requests which inadvertently disclose the issue
- [x] [:link:][step_assign_cve_id] **(IM)** Assign a CVE identifier
- [x] [:link:][step_note_cve_info] **(SwEng)** Update this issue with the assigned CVE identifier and the CVSS score
- [x] [:link:][step_versions_affected] **(SwEng)** Determine the range of product versions affected (including the Subscription Edition)
- [x] [:link:][step_workarounds] **(SwEng)** Determine whether workarounds for the problem exist
- [x] [:link:][step_coordinate] **(SwEng)** :warning: Coordinate with other parties :warning:
- [x] [:link:][step_earliest_prepare] **(Support)** ~~Prepare "earliest" notification text and hand it off to Marketing~~
- [x] [:link:][step_earliest_send] **(Marketing)** ~~Update "earliest" notification document in SF portal and send bulk email to earliest customers~~
- [x] [:link:][step_advisory_mr] **(Support)** [Create a merge request for the Security Advisory and include all readily available information in it](isc-private/printing-press!93)
- [x] [:link:][step_reproducer_mr] **(SwEng)** ~~[Prepare a private merge request containing a system test reproducing the problem](#note_434474)~~
- [x] [:link:][step_notify_support] **(SwEng)** ~~Notify Support when a reproducer is ready~~
- [x] [:link:][step_code_analysis] **(SwEng)** [Prepare a detailed explanation of the code flow triggering the problem](#note_434480)
- [x] [:link:][step_fix_mr] **(SwEng)** ~~[Prepare a private merge request with the fix](#note_434483)~~
- [x] [:link:][step_review_fix] **(SwEng)** ~~[Ensure the merge request with the fix is reviewed and has no outstanding discussions](#note_434483)~~
- [x] [:link:][step_review_docs] **(Support)** ~~[Review the documentation changes introduced by the merge request with the fix](#note_434483)~~
- [x] [:link:][step_backports] **(SwEng)** ~~[Prepare backports of the merge request addressing the problem for all affected (and still maintained) branches of a given product](#note_434483)~~
- [x] [:link:][step_finish_advisory] **(Support)** Finish preparing the Security Advisory
- [x] [:link:][step_meta_issue] **(QA)** Create (or update) the private issue containing links to fixes & reproducers for all CVEs fixed in a given release cycle
- [x] [:link:][step_changes] **(QA)** (BIND 9 only) Reserve a block of `CHANGES` placeholders once the complete set of vulnerabilities fixed in a given release cycle is determined
- [x] [:link:][step_merge_fixes] **(QA)** ~~[Merge the CVE fixes in CVE identifier order](#note_434483)~~
- [x] [:link:][step_patches] **(QA)** ~~[Prepare a standalone patch for the last stable release of each affected (and still maintained) product branch](#note_434483)~~
- [x] [:link:][step_asn_releases] **(QA)** Prepare ASN releases (as outlined in the Release Checklist)
### At T-5
- [x] [:link:][step_asn_documents] **(Marketing)** Update the text on the T-5 (from the Printing Press project) and "earliest" ASN documents in the SF portal
- [x] [:link:][step_asn_links] **(Marketing)** (BIND 9 only) Update the BIND -S information document in SF with download links to the new versions
- [x] [:link:][step_asn_send] **(Marketing)** Bulk email eligible customers to check the SF portal
- [x] [:link:][step_preannouncement] **(Marketing)** (BIND 9 only) Send a pre-announcement email to the *bind-announce* mailing list to alert users that the upcoming release will include security fixes
### At T-1
- [x] [:link:][step_packager_emails] **(First IM)** Send notifications to OS packagers
### On the Day of Public Disclosure
- [x] [:link:][step_clearance] **(IM)** [Grant QA & Marketing clearance to proceed with public release](https://mattermost.isc.org/isc/pl/rxzn1b4upbnjxrbq75dqx1m96o)
- [x] [:link:][step_publish] **(QA/Marketing)** Publish the releases (as outlined in the release checklist)
- [x] [:link:][step_matrix] **(Support)** (BIND 9 only) Add the new CVEs to the vulnerability matrix in the Knowledge Base
- [x] [:link:][step_publish_advisory] **(Support)** Bump Document Version for the Security Advisory and publish it in the Knowledge Base
- [x] [:link:][step_notifications] **(First IM)** Send notification emails to third parties
- [x] [:link:][step_mitre] **(First IM)** ~~[Advise MITRE about the disclosed CVEs](#note_436522)~~
- [x] [:link:][step_merge_advisory] **(First IM)** Merge the Security Advisory merge request
- [x] [:link:][step_embargo_end] **(IM)** Inform original reporter (if external) that the security disclosure process is complete
- [x] [:link:][step_asn_clear] **(Marketing)** Update the SF portal to clear the ASN
- [x] [:link:][step_customers] **(Marketing)** Email ASN recipients that the embargo is lifted
### After Public Disclosure
- [x] [:link:][step_regression] **(QA)** ~~[Merge a regression test reproducing the bug into all affected (and still maintained) branches](#note_434474)~~
[step_deputy]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#pick-a-deputy-incident-manager
[step_respond]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#respond-to-the-bug-reporter
[step_public_mrs]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#ensure-there-are-no-public-merge-requests-which-inadvertently-disclose-the-issue
[step_assign_cve_id]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#assign-a-cve-identifier
[step_note_cve_info]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#update-this-issue-with-the-assigned-cve-identifier-and-the-cvss-score
[step_versions_affected]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#determine-the-range-of-product-versions-affected-including-the-subscription-edition
[step_workarounds]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#determine-whether-workarounds-for-the-problem-exist
[step_coordinate]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#if-necessary-coordinate-with-other-parties
[step_earliest_prepare]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#prepare-earliest-notification-text-and-hand-it-off-to-marketing
[step_earliest_send]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#update-earliest-notification-document-in-sf-portal-and-send-bulk-email-to-earliest-customers
[step_advisory_mr]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#create-a-merge-request-for-the-security-advisory-and-include-all-readily-available-information-in-it
[step_reproducer_mr]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#prepare-a-private-merge-request-containing-a-system-test-reproducing-the-problem
[step_notify_support]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#notify-support-when-a-reproducer-is-ready
[step_code_analysis]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#prepare-a-detailed-explanation-of-the-code-flow-triggering-the-problem
[step_fix_mr]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#prepare-a-private-merge-request-with-the-fix
[step_review_fix]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#ensure-the-merge-request-with-the-fix-is-reviewed-and-has-no-outstanding-discussions
[step_review_docs]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#review-the-documentation-changes-introduced-by-the-merge-request-with-the-fix
[step_backports]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#prepare-backports-of-the-merge-request-addressing-the-problem-for-all-affected-and-still-maintained-branches-of-a-given-product
[step_finish_advisory]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#finish-preparing-the-security-advisory
[step_meta_issue]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#create-or-update-the-private-issue-containing-links-to-fixes-reproducers-for-all-cves-fixed-in-a-given-release-cycle
[step_changes]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#bind-9-only-reserve-a-block-of-changes-placeholders-once-the-complete-set-of-vulnerabilities-fixed-in-a-given-release-cycle-is-determined
[step_merge_fixes]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#merge-the-cve-fixes-in-cve-identifier-order
[step_patches]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#prepare-a-standalone-patch-for-the-last-stable-release-of-each-affected-and-still-maintained-product-branch
[step_asn_releases]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#prepare-asn-releases-as-outlined-in-the-release-checklist
[step_asn_documents]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#update-the-text-on-the-t-5-from-the-printing-press-project-and-earliest-asn-documents-in-the-sf-portal
[step_asn_links]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#bind-9-only-update-the-bind-s-information-document-in-sf-with-download-links-to-the-new-versions
[step_asn_send]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#bulk-email-eligible-customers-to-check-the-sf-portal
[step_preannouncement]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#bind-9-only-send-a-pre-announcement-email-to-the-bind-announce-mailing-list-to-alert-users-that-the-upcoming-release-will-include-security-fixes
[step_packager_emails]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#send-notifications-to-os-packagers
[step_clearance]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#grant-qa-marketing-clearance-to-proceed-with-public-release
[step_publish]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#publish-the-releases-as-outlined-in-the-release-checklist
[step_matrix]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#bind-9-only-add-the-new-cves-to-the-vulnerability-matrix-in-the-knowledge-base
[step_publish_advisory]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#bump-document-version-for-the-security-advisory-and-publish-it-in-the-knowledge-base
[step_notifications]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#send-notification-emails-to-third-parties
[step_mitre]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#advise-mitre-about-the-disclosed-cves
[step_merge_advisory]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#merge-the-security-advisory-merge-request
[step_embargo_end]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#inform-original-reporter-if-external-that-the-security-disclosure-process-is-complete
[step_asn_clear]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#update-the-sf-portal-to-clear-the-asn
[step_customers]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#email-asn-recipients-that-the-embargo-is-lifted
[step_regression]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#merge-a-regression-test-reproducing-the-bug-into-all-affected-and-still-maintained-branches
### Reproducer
1. Sign an empty zone with NSEC3, 150 iterations, and same NSEC3 salt for a good measure:
- [local.testiscorg.ch.zone](/uploads/b4a147bdabff809350e0a7a7b802758e/local.testiscorg.ch.zone)
- [Klocal.testiscorg.ch.+014+01043.key](/uploads/27aa1a99ac52e271ae1bf618c7fc4138/Klocal.testiscorg.ch.+014+01043.key)
- [Klocal.testiscorg.ch.+014+01043.private](/uploads/346295e7f71ed644dd44bb93e52ea531/Klocal.testiscorg.ch.+014+01043.private)
- `dnssec-signzone -u -3 0122345678912345 -H 150 -e 20380101000000 -S -o local.testiscorg.ch -O full -z local.testiscorg.ch.zone Klocal.testiscorg.ch.+014+01043`
- :point_right_tone1: [local.testiscorg.ch.zone.signed](/uploads/ba12811b13cc749084b6c1cef0c3a04a/local.testiscorg.ch.zone.signed)
2. Run an auth with the zone:
- [auth.conf](/uploads/51139fed8b8efe23eb58b82ce4b82379/auth.conf)
- `named -g -c auth.conf`
3. Run a resolver with the zone:
- [resolver.conf](/uploads/2b9a661105397636c55f9c5be13d8855/resolver.conf)
- `named -g -c resolver.conf`
4. Run attack using dnsperf:
- [randlabels.py](/uploads/30b54afbe090da16c06855f5561755df/randlabels.py)
- `python randlabels.py | dnsperf -s 127.0.0.1 -S1`
### Observed behavior
Around 200 QPS, one CPU maxed out. Tweaking dnsperf params can max out all CPUs with ~ 200 queries per core.
### Problem
For NSEC3 we have to hash all the labels between QNAME and zone name to find out a matching NSEC3 RR in authority section. This inflates number of hashes to potentially ~ `127 labels * <NSEC3 iterations> * <number of NSEC3 RRs in the message>`.
We have to cap this somehow. Coordination with other vendors is needed because BIND, Unbound, Knot Resolver, and PowerDNS in current versions are affected. This seems like a protocol issue so other vendors are most likely also affected, see the NSEC3 algorithm here: https://datatracker.ietf.org/doc/html/rfc5155#section-8.3February 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/4457dig crashes after SIGINT if there are multiple queries2023-12-04T21:59:30ZPetr Špačekpspacek@isc.orgdig crashes after SIGINT if there are multiple queries### Summary
Dig with multiple queries crashes when interrupted.
### BIND version used
* ~"Affects v9.19" : de2009e3c2a
### Steps to reproduce
```
$ dig 2000.delay.getdnsapi.net 3000.delay.getdnsapi.net
```
+ SIGINT before the first qu...### Summary
Dig with multiple queries crashes when interrupted.
### BIND version used
* ~"Affects v9.19" : de2009e3c2a
### Steps to reproduce
```
$ dig 2000.delay.getdnsapi.net 3000.delay.getdnsapi.net
```
+ SIGINT before the first query finishes.
### What is the current *bug* behavior?
:boom:
```
signal.c:78: REQUIRE(((signal) != ((void *)0) && ((const isc__magic_t *)(signal))->magic == ((('S') << 24 | ('I') << 16 | ('G') << 8 | (' '))))) failed, back trace
```
### What is the expected *correct* behavior?
No crash.
### Relevant configuration files
None needed.
### Relevant logs and/or screenshots
Full debug log:
<details>
```
$ dig -d 2000.delay.getdnsapi.net 3000.delay.getdnsapi.net
setup_libs()
setup_system()
create_search_list()
ndots is 1.
timeout is 0.
retries is 3.
get_server_list()
make_server(127.0.0.111)
dig_query_setup
parse_args()
making new lookup
make_empty_lookup()
make_empty_lookup() = 0x7f6faa9aa000->references = 1
digrc (open)
main parsing +timeout=5
main parsing +retry=0
main parsing -d
main parsing 2000.delay.getdnsapi.net
clone_lookup()
make_empty_lookup()
make_empty_lookup() = 0x7f6faa9ab800->references = 1
clone_server_list()
looking up 2000.delay.getdnsapi.net
main parsing 3000.delay.getdnsapi.net
clone_lookup()
make_empty_lookup()
make_empty_lookup() = 0x7f6faa9ad000->references = 1
clone_server_list()
looking up 3000.delay.getdnsapi.net
dig_startup()
start_lookup()
setup_lookup(0x7f6faa9ab800)
resetting lookup counter.
cloning server list
clone_server_list()
make_server(127.0.0.111)
idn_textname: 2000.delay.getdnsapi.net
using root origin
recursive query
AD query
add_question()
starting to render the message
add_opt()
done rendering
create query 0x7f6fab09f540 linked to lookup 0x7f6faa9ab800
dighost.c:2141:lookup_attach(0x7f6faa9ab800) = 2
dighost.c:2652:new_query(0x7f6fab09f540) = 1
do_lookup()
start_udp(0x7f6fab09f540)
dighost.c:3255:query_attach(0x7f6fab09f540) = 2
working on lookup 0x7f6faa9ab800, query 0x7f6fab09f540
dighost.c:3300:query_attach(0x7f6fab09f540) = 3
udp_ready()
udp_ready(0x7f6fab09f700, success, 0x7f6fab09f540)
dighost.c:3147:lookup_attach(0x7f6faa9ab800) = 3
dighost.c:3216:query_attach(0x7f6fab09f540) = 4
recving with lookup=0x7f6faa9ab800, query=0x7f6fab09f540, handle=0x7f6fab09f700
recvcount=1
have local timeout of 5000
dighost.c:3094:query_attach(0x7f6fab09f540) = 5
sending a request
sendcount=1
dighost.c:1729:query_detach(0x7f6fab09f540) = 4
dighost.c:3236:query_detach(0x7f6fab09f540) = 3
dighost.c:3237:lookup_detach(0x7f6faa9ab800) = 2
send_done(0x7f6fab09f700, success, 0x7f6fab09f540)
sendcount=0
dighost.c:2729:lookup_attach(0x7f6faa9ab800) = 3
dighost.c:2746:query_detach(0x7f6fab09f540) = 2
dighost.c:2747:lookup_detach(0x7f6faa9ab800) = 2
check_if_done()
list full
pending lookup 0x7f6faa9ad000
^Crecv_done(0x7f6fab09f700, shutting down, 0x7ffe1fb53710, 0x7f6fab09f540)
recvcount=0
dighost.c:3905:lookup_attach(0x7f6faa9ab800) = 3
recv_done: cancel
dighost.c:3913:_cancel_lookup()
canceling pending query 0x7f6fab09f540, belonging to 0x7f6faa9ab800
dighost.c:2775:query_detach(0x7f6fab09f540) = 1
check_if_done()
list full
pending lookup 0x7f6faa9ad000
dighost.c:3915:query_detach(0x7f6fab09f540) = 0
dighost.c:3915:destroy_query(0x7f6fab09f540) = 0
dighost.c:1687:lookup_detach(0x7f6faa9ab800) = 2
dighost.c:3916:lookup_detach(0x7f6faa9ab800) = 1
clear_current_lookup()
lookup cleared
dighost.c:1820:lookup_detach(0x7f6faa9ab800) = 0
destroy_lookup
freeing server 0x7f6fab072a00 belonging to 0x7f6faa9ab800
start_lookup()
setup_lookup(0x7f6faa9ad000)
resetting lookup counter.
cloning server list
clone_server_list()
make_server(127.0.0.111)
idn_textname: 3000.delay.getdnsapi.net
using root origin
recursive query
AD query
add_question()
starting to render the message
add_opt()
done rendering
create query 0x7f6fab09f540 linked to lookup 0x7f6faa9ad000
dighost.c:2141:lookup_attach(0x7f6faa9ad000) = 2
dighost.c:2652:new_query(0x7f6fab09f540) = 1
do_lookup()
start_udp(0x7f6fab09f540)
dighost.c:3255:query_attach(0x7f6fab09f540) = 2
working on lookup 0x7f6faa9ad000, query 0x7f6fab09f540
signal.c:78: REQUIRE(((signal) != ((void *)0) && ((const isc__magic_t *)(signal))->magic == ((('S') << 24 | ('I') << 16 | ('G') << 8 | (' '))))) failed, back trace
/usr/lib/libisc-9.19.19-dev.so(+0x33891)[0x7f6faef42891]
/usr/lib/libisc-9.19.19-dev.so(isc_assertion_failed+0x31)[0x7f6faef427a2]
/usr/lib/libisc-9.19.19-dev.so(isc_signal_stop+0x44)[0x7f6faef71f5b]
/usr/lib/libisc-9.19.19-dev.so(isc_loopmgr_blocking+0x55)[0x7f6faef61f96]
dig(get_address+0x38)[0x55ddd5ed030b]
dig(+0x1b006)[0x55ddd5ecc006]
dig(do_lookup+0xc8)[0x55ddd5ed067b]
dig(start_lookup+0x285)[0x55ddd5ec6e71]
dig(+0x15485)[0x55ddd5ec6485]
dig(+0x15fcc)[0x55ddd5ec6fcc]
dig(+0x1d23b)[0x55ddd5ece23b]
/usr/lib/libisc-9.19.19-dev.so(+0x1e71d)[0x7f6faef2d71d]
/usr/lib/libisc-9.19.19-dev.so(isc__nm_readcb+0x121)[0x7f6faef2d863]
/usr/lib/libisc-9.19.19-dev.so(isc__nm_udp_failed_read_cb+0x12b)[0x7f6faef420b0]
/usr/lib/libisc-9.19.19-dev.so(isc__nm_failed_read_cb+0x89)[0x7f6faef2ac2c]
/usr/lib/libisc-9.19.19-dev.so(isc__nm_udp_shutdown+0x127)[0x7f6faef42723]
/usr/lib/libisc-9.19.19-dev.so(isc__nmsocket_shutdown+0x6e)[0x7f6faef2dd24]
/usr/lib/libisc-9.19.19-dev.so(+0x1edb4)[0x7f6faef2ddb4]
/usr/lib/libuv.so.1(uv_walk+0x9b)[0x7f6fae9a474b]
/usr/lib/libisc-9.19.19-dev.so(+0x1818b)[0x7f6faef2718b]
/usr/lib/libisc-9.19.19-dev.so(isc__async_cb+0x18d)[0x7f6faef42c6b]
/usr/lib/libuv.so.1(+0x9a1b)[0x7f6fae99fa1b]
/usr/lib/libuv.so.1(+0x26d48)[0x7f6fae9bcd48]
/usr/lib/libuv.so.1(uv_run+0x1bf)[0x7f6fae9a4fbf]
/usr/lib/libisc-9.19.19-dev.so(+0x51370)[0x7f6faef60370]
/usr/lib/libisc-9.19.19-dev.so(+0x66f07)[0x7f6faef75f07]
/usr/lib/libisc-9.19.19-dev.so(isc_thread_main+0x62)[0x7f6faef75fc6]
/usr/lib/libisc-9.19.19-dev.so(isc_loopmgr_run+0x187)[0x7f6faef613fb]
dig(dig_startup+0x48)[0x55ddd5ec0624]
dig(main+0x40)[0x55ddd5ec068a]
/usr/lib/libc.so.6(+0x27cd0)[0x7f6fae9f1cd0]
/usr/lib/libc.so.6(__libc_start_main+0x8a)[0x7f6fae9f1d8a]
dig(_start+0x25)[0x55ddd5eb7045]
Aborted (core dumped)
```
</details>December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4456license question: do bind9 based configs require Mozilla License?2023-11-27T20:54:47ZPJ Fanninglicense question: do bind9 based configs require Mozilla License?I'm a developer on the Apache Pekko project, an open source fork of Akka.
One of our mentors has queried if we have a licensing issue for the files in this directory.
https://github.com/apache/incubator-pekko/tree/main/actor-tests/src/t...I'm a developer on the Apache Pekko project, an open source fork of Akka.
One of our mentors has queried if we have a licensing issue for the files in this directory.
https://github.com/apache/incubator-pekko/tree/main/actor-tests/src/test/bind/etc
The configs there are Bind9 configs used in our tests.
Does the Mozilla Public License have to be applied to our config files?
https://gitlab.isc.org/isc-projects/bind9/-/blob/main/LICENSE
The Mozilla Public License is regarded by the ASF as having copyleft implications.
Any advice on the licensing implications of having config files based on this repo would be appreciated.https://gitlab.isc.org/isc-projects/bind9/-/issues/4455Please backport #3883 transfer statistics to 9.18-S if practical2024-01-03T18:07:30ZVicky Riskvicky@isc.orgPlease backport #3883 transfer statistics to 9.18-S if practicalThe transfer statistics have been requested by users for quite a while, and there is significant interest in them. If the feature doesn't rely on some refactoring in the 9.19 branch, or isn't significantly de-stabilizing for some other r...The transfer statistics have been requested by users for quite a while, and there is significant interest in them. If the feature doesn't rely on some refactoring in the 9.19 branch, or isn't significantly de-stabilizing for some other reason, could we request a backport to 9.18-S please?
https://gitlab.isc.org/isc-projects/bind9/-/issues/3883January 2024 (9.16.46, 9.16.46-S1, 9.18.22, 9.18.22-S1, 9.19.20) (❗RECALLED❗)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4452log more information from pytest assertions in system tests2023-12-05T15:29:43ZTom Krizeklog more information from pytest assertions in system testsSome python system tests contain `assert` expression like
```
assert loaded == expected
```
which provide no useful information in case the check [fails](https://gitlab.isc.org/isc-private/bind9/-/jobs/3820431), e.g.:
```
____________...Some python system tests contain `assert` expression like
```
assert loaded == expected
```
which provide no useful information in case the check [fails](https://gitlab.isc.org/isc-private/bind9/-/jobs/3820431), e.g.:
```
_______________________ test_zone_timers_secondary_json ________________________
[gw1] linux -- Python 3.11.6 /usr/bin/python3
/builds/isc-private/bind9/bin/tests/system/statschannel/tests_json.py:86: in test_zone_timers_secondary_json
generic.test_zone_timers_secondary(
/builds/isc-private/bind9/bin/tests/system/statschannel/generic.py:94: in test_zone_timers_secondary
check_zone_timers(loaded, expires, refresh, mtime)
/builds/isc-private/bind9/bin/tests/system/statschannel/generic.py:49: in check_zone_timers
check_loaded(loaded, loaded_exp, now)
/builds/isc-private/bind9/bin/tests/system/statschannel/generic.py:38: in check_loaded
assert loaded == expected
E AssertionError
```
An informative assert message with the relevant values/data should be added to the assert statements:
```
assert loaded == expected, f"loaded={loaded}, expected={expected}"
```December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4451Cache overmem setting is not reset2023-12-06T18:29:37ZMark AndrewsCache overmem setting is not resetSet a low cache size then send the server a query stream. Once the cache fills the server does not recover.
```
options {
listen-on port 5555 { 127.0.0.1; };
listen-on-v6 port 5555 { ::1; };
pid-file none;
...Set a low cache size then send the server a query stream. Once the cache fills the server does not recover.
```
options {
listen-on port 5555 { 127.0.0.1; };
listen-on-v6 port 5555 { ::1; };
pid-file none;
max-cache-size 1M;
};
```December 2023 (9.18.21, 9.18.21-S1, 9.19.19)https://gitlab.isc.org/isc-projects/bind9/-/issues/4448Improve LRU cleaning behaviour2023-12-13T16:30:56ZMark AndrewsImprove LRU cleaning behaviourThere are a number of biases in the existing LRU cleaning behaviour. We don't currently properly sweep across all locks when cleaning. We do LRU by lock rather than across all the locks.
See also #4441There are a number of biases in the existing LRU cleaning behaviour. We don't currently properly sweep across all locks when cleaning. We do LRU by lock rather than across all the locks.
See also #4441December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Mark AndrewsMark Andrews