BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-01-18T12:35:31Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2364CID 314969: Control flow issues (DEADCODE) in zoneconf.c2021-01-18T12:35:31ZMichal NowakCID 314969: Control flow issues (DEADCODE) in zoneconf.cCoverity Scan identified the following issue in `bin/named/zoneconf.c` on Sunday December 27 on `v9_16` and `main`:
```
*** CID 314969: Control flow issues (DEADCODE)
/bin/named/zoneconf.c: 2212 in named_zone_inlinesigning()
2206 ...Coverity Scan identified the following issue in `bin/named/zoneconf.c` on Sunday December 27 on `v9_16` and `main`:
```
*** CID 314969: Control flow issues (DEADCODE)
/bin/named/zoneconf.c: 2212 in named_zone_inlinesigning()
2206 if (!inline_signing && !zone_is_dynamic &&
2207 cfg_map_get(zoptions, "dnssec-policy", &signing) == ISC_R_SUCCESS &&
2208 signing != NULL)
2209 {
2210 if (strcmp(cfg_obj_asstring(signing), "none") != 0) {
2211 inline_signing = true;
>>> CID 314969: Control flow issues (DEADCODE)
>>> Execution cannot reach the expression ""no"" inside this statement: "dns_zone_log(zone, 1, "inli...".
2212 dns_zone_log(
2213 zone, ISC_LOG_DEBUG(1), "inline-signing: %s",
2214 inline_signing
2215 ? "implicitly through dnssec-policy"
2216 : "no");
2217 } else {
```
The culprit likely lies in cf420b2af0d45693d0f5f34d9113ea411b5f2225 as it's the only change in that file between last two Coverity Scan runs.
Coverity Scan link: https://scan8.coverity.com/reports.htm#v38342/p12579/fileInstanceId=38520332&defectInstanceId=11383777&mergedDefectId=314969.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2354[CVE-2020-8625] ZDI-CAN-12302: ISC BIND TKEY Query Heap-based Buffer Overflow...2023-06-19T09:07:00ZCathy Almond[CVE-2020-8625] ZDI-CAN-12302: ISC BIND TKEY Query Heap-based Buffer Overflow Remote Code Execution Vulnerability### CVE-specific actions
- [x] Assign a CVE identifier
- [x] Determine CVSS score
- [x] Determine the range of BIND versions affected (including the Subscription Edition)
- [x] Determine whether workarounds for the problem exist...### CVE-specific actions
- [x] Assign a CVE identifier
- [x] Determine CVSS score
- [x] Determine the range of BIND versions affected (including the Subscription Edition)
- [x] Determine whether workarounds for the problem exists
- [x] Prepare a detailed description of the problem which should include the following by default:
- instructions for reproducing the problem (a system test is good enough)
- explanation of code flow which triggers the problem (a system test is *not* good enough)
- [x] Prepare a private merge request containing the following items in separate commits:
- a test for the issue (may be moved to a separate merge request for deferred merging)
- a fix for the issue
- documentation updates (`CHANGES`, release notes, anything else applicable)
- [x] Ensure the merge request from the previous step is reviewed by SWENG staff and has no outstanding discussions
- [x] Ensure the documentation changes introduced by the merge request addressing the problem are reviewed by Support and Marketing staff
- [x] Prepare backports of the merge request addressing the problem for all affected (and still maintained) BIND branches (backporting might affect the issue's scope and/or description)
- [x] Prepare a standalone patch for the last stable release of each affected (and still maintained) BIND branch
### Release-specific actions
- [x] Create/update the private issue containing links to fixes & reproducers for all CVEs fixed in a given release cycle: isc-private/bind9#34
- [x] Reserve a block of `CHANGES` placeholders once the complete set of vulnerabilities fixed in a given release cycle is determined
- [x] Ensure the merge requests containing CVE fixes are merged into `security-*` branches in CVE identifier order
---
As reported to ISC Security Officer:
ZDI-CAN-12302: ISC BIND TKEY Query Heap-based Buffer Overflow Remote Code Execution Vulnerability
-- CVSS -----------------------------------------
8.1: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
-- ABSTRACT -------------------------------------
Trend Micro's Zero Day Initiative has identified a vulnerability affecting the following products:
ISC - BIND
-- VULNERABILITY DETAILS ------------------------
* Version tested:9.16.9
* Installer file:bind-9.16.9.tar.xz
* Platform tested:ubuntu 20.04.1 desktop edition
---
### Analysis
```
the bug is CVE-2006-5989, ISC did not merge the patch
https://bugzilla.redhat.com/show_bug.cgi?id=206736
it leads to heap overflow off-by-4
it affected the latest Current-Stable, 9.16.9
it require the tkey-gssapi-keytab config in named.conf
```
~~~C++
static int
der_get_oid(const unsigned char *p, size_t len, oid *data, size_t *size) {
...
data->components = malloc(len * sizeof(*data->components));
if (data->components == NULL) {
return (ENOMEM);
}
data->components[0] = (*p) / 40;
data->components[1] = (*p) % 40; <--- (1) two element is written
--len; <--- (2) but len is plus one only
++p;
for (n = 2; len > 0U; ++n) {
unsigned u = 0;
do {
--len;
u = u * 128 + (*p++ % 128);
} while (len > 0U && p[-1] & 0x80);
data->components[n] = u; <--- (3) off-by-4
}
...
return (0);
}
~~~
debug log
```
(gdb) b *0x18E27E+0x7fb83fd83000
Breakpoint 1 at 0x7fb83ff1127e
(gdb) b *0x18E309+0x7fb83fd83000
Breakpoint 2 at 0x7fb83ff11309
(gdb) c
Continuing.
[Switching to Thread 0x7fb83d1f8700 (LWP 77138)]
Thread 2 "isc-net-0000" hit Breakpoint 1, 0x00007fb83ff1127e in ?? () from /lib/x86_64-linux-gnu/libdns.so.1601
(gdb) x/i $pc
=> 0x7fb83ff1127e: call 0x7fb83fdab5d0 <malloc@plt>
(gdb) i r $rdi
rdi 0x28 40
(gdb) ni
0x00007fb83ff11283 in ?? () from /lib/x86_64-linux-gnu/libdns.so.1601
(gdb) x/30xg $rax-0x10
0x7fb82c0164b0: 0x0000000000000000 0x0000000000000035
0x7fb82c0164c0: 0x00007fb82c016650 0x0000000000000000
0x7fb82c0164d0: 0x0000000000000000 0x0000000000000000
0x7fb82c0164e0: 0x0000000000000000 0x0000000000000025
0x7fb82c0164f0: 0x00007fb82c016230 0x00007fb83f55fc20
0x7fb82c016500: 0x0000000000000000 0x0000000000000025
0x7fb82c016510: 0x00007fb82c016530 0x00007fb82c0008d0
0x7fb82c016520: 0x0000000000000000 0x0000000000000025
0x7fb82c016530: 0x0000000000000000 0x00007fb82c0008d0
0x7fb82c016540: 0x0000000000000000 0x00000000000000b5
0x7fb82c016550: 0x00007fb82c015120 0x00007fb82c0008d0
0x7fb82c016560: 0x0000000000000000 0x00000000ffffffff
0x7fb82c016570: 0x0000000000000000 0x0000000000000000
0x7fb82c016580: 0x0000000000000000 0x0000000000000000
0x7fb82c016590: 0x0000000000000000 0x0000000000000000
(gdb) c
Continuing.
Thread 2 "isc-net-0000" hit Breakpoint 2, 0x00007fb83ff11309 in ?? () from /lib/x86_64-linux-gnu/libdns.so.1601
(gdb) x/i $pc
=> 0x7fb83ff11309: mov DWORD PTR [rax+rcx*4],edi // overwrite next chunk header
(gdb) x/xg $rax+$rcx*4
0x7fb82c0164e8: 0x0000000000000025
(gdb) bt
#0 0x00007fb83ff11309 in ?? () from /lib/x86_64-linux-gnu/libdns.so.1601
#1 0x00007fb83ff1144a in ?? () from /lib/x86_64-linux-gnu/libdns.so.1601
#2 0x00007fb83ff11a2d in gss_accept_sec_context_spnego () from /lib/x86_64-linux-gnu/libdns.so.1601
#3 0x00007fb83ff1d083 in dst_gssapi_acceptctx () from /lib/x86_64-linux-gnu/libdns.so.1601
#4 0x00007fb83feb65cd in dns_tkey_processquery () from /lib/x86_64-linux-gnu/libdns.so.1601
#5 0x00007fb83ffcf27f in ns_query_start () from /lib/x86_64-linux-gnu/libns.so.1601
#6 0x00007fb83ffb2131 in ns.client_request () from /lib/x86_64-linux-gnu/libns.so.1601
#7 0x00007fb83fce2b26 in ?? () from /lib/x86_64-linux-gnu/libisc.so.1601
#8 0x00007fb83fce33cd in ?? () from /lib/x86_64-linux-gnu/libisc.so.1601
#9 0x00007fb83fcdf74c in ?? () from /lib/x86_64-linux-gnu/libisc.so.1601
#10 0x00007fb83f470b01 in ?? () from /lib/x86_64-linux-gnu/libuv.so.1
#11 0x00007fb83f471638 in ?? () from /lib/x86_64-linux-gnu/libuv.so.1
#12 0x00007fb83f476ae0 in uv.io_poll () from /lib/x86_64-linux-gnu/libuv.so.1
#13 0x00007fb83f4667ac in uv_run () from /lib/x86_64-linux-gnu/libuv.so.1
#14 0x00007fb83fcdec2d in ?? () from /lib/x86_64-linux-gnu/libisc.so.1601
#15 0x00007fb83f7b4609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#16 0x00007fb83f6d5293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) c
Continuing.
Thread 3 "isc-net-0001" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fb83c8b6700 (LWP 77139)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb)
```
-- CREDIT ---------------------------------------
This vulnerability was discovered by:
Anonymous working with Trend Micro Zero Day InitiativeFebruary 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)https://gitlab.isc.org/isc-projects/bind9/-/issues/2349Should we back-port max-ixfr-ratio from 9.17 to earlier versions of BIND?2021-05-10T16:49:36ZCathy AlmondShould we back-port max-ixfr-ratio from 9.17 to earlier versions of BIND?I can't see any other elegant option currently that could be used to 'protect' a zone hosting set-up from receipt and onward propagation of a massive IXFR to the service-providing authoritatives.
This happens sometimes accidentally (see...I can't see any other elegant option currently that could be used to 'protect' a zone hosting set-up from receipt and onward propagation of a massive IXFR to the service-providing authoritatives.
This happens sometimes accidentally (see [Support Ticket #17366](https://support.isc.org/Ticket/Display.html?id=17366)) and I would rather provide a solid solution in named, than encourage scripting that spots when something like this happens, and then goes off to delete .jnl or zone files on disk to prevent the same IXFR heading out to Internet-facing servers, where the effects of applying it can be seriously detrimental to server performance.
!3113
#1515February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2342rndc retransfer issues misleading diagnostic on primary zone2021-01-27T22:45:04ZJP Mensrndc retransfer issues misleading diagnostic on primary zone### Summary
The `rndc` command has a subcommand `retransfer` which retransfers a single zone without checking serial number. When used on a primary zone on a primary server, the command issues the following diagnostic:
```console
% rnd...### Summary
The `rndc` command has a subcommand `retransfer` which retransfers a single zone without checking serial number. When used on a primary zone on a primary server, the command issues the following diagnostic:
```console
% rndc retransfer inline.zone12.dane.onl
rndc: 'retransfer' failed: not found
```
However, if the zone doesn't exist at all, `rndc` emits this clearer message:
```console
% rndc retransfer yyy
rndc: 'retransfer' failed: not found
no matching zone 'yyy' in any view
```
### BIND version used
```
BIND 9.16.9 (Stable Release) <id:b3f41b7>
running on Linux x86_64 4.18.0-193.6.3.el8_2.x86_64 #1 SMP Wed Jun 10 11:09:32 UTC 2020
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/opt/isc/isc-bind/root/usr' '--exec-prefix=/opt/isc/isc-bind/root/usr' '--bindir=/opt/isc/isc-bind/root/usr/bin' '--sbindir=/opt/isc/isc-bind/root/usr/sbin' '--sysconfdir=/etc/opt/isc/scls/isc-bind' '--datadir=/opt/isc/isc-bind/root/usr/share' '--includedir=/opt/isc/isc-bind/root/usr/include' '--libdir=/opt/isc/isc-bind/root/usr/lib64' '--libexecdir=/opt/isc/isc-bind/root/usr/libexec' '--localstatedir=/var/opt/isc/scls/isc-bind' '--sharedstatedir=/var/opt/isc/scls/isc-bind/lib' '--mandir=/opt/isc/isc-bind/root/usr/share/man' '--infodir=/opt/isc/isc-bind/root/usr/share/info' '--disable-static' '--enable-dnstap' '--with-pic' '--with-gssapi' '--with-json-c' '--with-libtool' '--with-libxml2' '--without-lmdb' '--with-python' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/opt/isc/isc-bind/root/usr/lib64' 'LT_SYS_LIBRARY_PATH=/usr/lib64' 'PKG_CONFIG_PATH=:/opt/isc/isc-bind/root/usr/lib64/pkgconfig:/opt/isc/isc-bind/root/usr/share/pkgconfig' 'SPHINX_BUILD=/builddir/build/BUILD/bind-9.16.9/sphinx/bin/sphinx-build'
compiled by GCC 8.3.1 20191121 (Red Hat 8.3.1-5)
compiled with OpenSSL version: OpenSSL 1.1.1c FIPS 28 May 2019
linked to OpenSSL version: OpenSSL 1.1.1c FIPS 28 May 2019
compiled with libuv version: 1.40.0
linked to libuv version: 1.40.0
compiled with libxml2 version: 2.9.7
linked to libxml2 version: 20907
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
default paths:
named configuration: /etc/opt/isc/scls/isc-bind/named.conf
rndc configuration: /etc/opt/isc/scls/isc-bind/rndc.conf
DNSSEC root key: /etc/opt/isc/scls/isc-bind/bind.keys
nsupdate session key: /var/opt/isc/scls/isc-bind/run/named/session.key
named PID file: /var/opt/isc/scls/isc-bind/run/named/named.pid
named lock file: /var/opt/isc/scls/isc-bind/run/named/named.lock
```
### Steps to reproduce
1. configure a primary zone, say, `example`
2. issue `rndc retransfer example`
### What is the current *bug* behavior?
Diagnostic as shown above
### What is the expected *correct* behavior?
What I would like to see is `rndc` telling me that the zone is a primary zone and cannot be retransferred.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)https://gitlab.isc.org/isc-projects/bind9/-/issues/2335TLSDNS refactoring2021-02-26T15:14:59ZOndřej SurýTLSDNS refactoringThe TLSDNS needs to be refactored to use libuv/OpenSSL directly, and not via netmgr layers.The TLSDNS needs to be refactored to use libuv/OpenSSL directly, and not via netmgr layers.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2323Add non-threaded build to 9.11 CI2021-01-19T06:18:32ZMark AndrewsAdd non-threaded build to 9.11 CIFebruary 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2263Follow-up from "Server-side TLS support in netmgr"2021-01-28T16:36:48ZOndřej SurýFollow-up from "Server-side TLS support in netmgr"The following discussion from !3532 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3532#note_175388):
> Optionally, we should use `SSL_set0_rbio()` and `SSL_set...The following discussion from !3532 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3532#note_175388):
> Optionally, we should use `SSL_set0_rbio()` and `SSL_set0_wbio()`, as `SSL_set_bio()` is considered legacy function.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2256Make the nmhandle attach/detach transparent2021-01-28T16:39:38ZOndřej SurýMake the nmhandle attach/detach transparentCurrently, the netmgr callbacks need to manually attach/detach to the `isc_nmhandle_t` which makes the usage very error prone (it's fairly easy to forgot some weird path).
The code needs to be refactored, so the attach/detach is interna...Currently, the netmgr callbacks need to manually attach/detach to the `isc_nmhandle_t` which makes the usage very error prone (it's fairly easy to forgot some weird path).
The code needs to be refactored, so the attach/detach is internal to the netmgr and not visible to the outside, e.g. instead of doing:
```
isc_nm_udpconnect(..., connect_cb, ...);
void
connect_cb(handle, ...) {
isc_nmhandle_attach(handle, &read_handle);
isc_nm_read(read_handle, read_cb, ...);
isc_nmhandle_attach(handle, &send_handle);
isc_nm_send(send_handle, send_cb, ...);
isc_nmhandle_detach(&handle);
}
void
read_cb(handle, ...) {
/* process data */
isc_nmhandle_detach(&handle);
}
void
send_cb(handle, ...) {
/* process */
isc_nmhandle_detach(&handle);
}
```
we should just do:
```
isc_nm_udpconnect(..., connect_cb, ...);
void
connect_cb(handle, ...) {
isc_nm_read(handle, read_cb, ...);
isc_nm_send(handle, send_cb, ...);
}
void
read_cb(handle, ...) {
/* process */
}
void
send_cb(handle, ...) {
/* process */
}
```
Basically, the `isc_nm_read()`, `isc_nm_send()` and others needs to attach to the handle itself, and detach after calling the use supplied callback. It's probably going to be a little bit more complicated than that, but it should be fairly straightforward to fix all the paths in the code.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2248Update serve-stale configuration defaults2021-02-03T08:25:09ZMatthijs Mekkingmatthijs@isc.orgUpdate serve-stale configuration defaultsUpdate the defaults to the RFC 8767 recommended values (`stale-answer-ttl 30`, `max-stale-ttl 1d`, `stale-refresh-time 30s` or higher).Update the defaults to the RFC 8767 recommended values (`stale-answer-ttl 30`, `max-stale-ttl 1d`, `stale-refresh-time 30s` or higher).February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2247Add serve-stale option to set client timeout2021-01-29T09:51:55ZMatthijs Mekkingmatthijs@isc.orgAdd serve-stale option to set client timeoutImplement `stale-answer-client-timeout`, which is the maximum amount of time a recursive resolver should allow between the receipt of a resolution request and sending its response (only to be used if `stale-answer-enable` is set).Implement `stale-answer-client-timeout`, which is the maximum amount of time a recursive resolver should allow between the receipt of a resolution request and sending its response (only to be used if `stale-answer-enable` is set).February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/2217TLS offloading with DOH2021-02-03T16:10:01ZVicky Riskvicky@isc.orgTLS offloading with DOHApparently the https library we are using for DOH supports http. At least one user would like to be able to use a TLS proxy.
some reasons:
* certificate rotation - e.g. Apache or nginx proxy can use ACME to automate all the certificate...Apparently the https library we are using for DOH supports http. At least one user would like to be able to use a TLS proxy.
some reasons:
* certificate rotation - e.g. Apache or nginx proxy can use ACME to automate all the certificate dance
* client authentication - TLS client certs + augmenting HTTP headers with proxied-for information
* logging at HTTP level
* offload the TLS processing on a dedicated system to reduce the impact of TLS on the BIND server and to centralize the certificate mgmt
- [ ] Please test this to see if it works
- [ ] Please document that this is supported in the ARM
ref: https://support.isc.org/Ticket/ModifyLinks.html?id=16797February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2178dnssec-keyfromlabel ECDSAP256SHA256 error on AEP Keypers HSM2021-01-29T13:19:28ZPeter Daviesdnssec-keyfromlabel ECDSAP256SHA256 error on AEP Keypers HSM
### Summary
When attempting to generate a ECDSAP256SHA256 key pair from a AEP Keypers HSM dnssec-keyfromlabel exits with a segment fault. For core an binary see [RT #17055](https://support.isc.org/Ticket/Display.html?id=17055)
### BIN...
### Summary
When attempting to generate a ECDSAP256SHA256 key pair from a AEP Keypers HSM dnssec-keyfromlabel exits with a segment fault. For core an binary see [RT #17055](https://support.isc.org/Ticket/Display.html?id=17055)
### BIND version used
BIND 9.16.6 (Stable Release) <id:25846cf>
running on Linux x86_64 3.10.0-1062.12.1.el7.x86_64 #1 SMP Tue Feb 4 23:02:59 UTC 2020
built by make with '--with-openssl=/opt/openssl-versions/openssl-1.1.1g/' '--prefix=/opt/bind-versions/bind-9.16.6' '--with-pkcs11=/opt/Keyper/PKCS11Provider-versions/PKCS11Provider-5.05/pkcs11.so'
+'PKG_CONFIG_PATH=/opt/openssl-versions/openssl-1.1.1g/lib/pkgconfig'.
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39).
compiled with OpenSSL version: OpenSSL 1.1.1g 21 Apr 2020
linked to OpenSSL version: OpenSSL 1.1.1g 21 Apr 2020
compiled with libuv version: 1.38.0
linked to libuv version: 1.38.0
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
threads support is enabled
default paths:
named configuration: /opt/bind-versions/bind-9.16.6/etc/named.conf
rndc configuration: /opt/bind-versions/bind-9.16.6/etc/rndc.conf
DNSSEC root key: /opt/bind-versions/bind-9.16.6/etc/bind.keys
nsupdate session key: /opt/bind-versions/bind-9.16.6/var/run/named/session.key
named PID file: /opt/bind-versions/bind-9.16.6/var/run/named/named.pid
named lock file: /opt/bind-versions/bind-9.16.6/var/run/named/named.lock
### Steps to reproduce
dnssec-keyfromlabel -E pkcs11 -a ECDSAP256SHA256 -l "token=prod.fr;object=re9166-zsk;pin-value=XXXX"
### What is the current *bug* behavior?
Segmentation fault (core dumped)
### What is the expected *correct* behavior?
Generation of key pair
### Relevant configuration files
OpenSSL 1.1.1g 21 Apr 202
OpenSSL configuration:
openssl_conf = openssl_init
[...]
[ openssl_init ]
engines = engine_section
[ engine_section ]
pkcs11 = pkcs11_section
[ pkcs11_section ]
engine_id = pkcs11
dynamic_path = /opt/bind/engines/pkcs11.so
MODULE_PATH = /opt/Keyper/PKCS11Provider-versions/PKCS11Provider-5.05/pkcs11.so
init = 0February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2093tsan files are not being captured by unit tests2021-02-03T07:25:37ZMark Andrewstsan files are not being captured by unit testsFebruary 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2073dnssec-verify tries all keys which results in poor performance2021-02-17T21:37:02ZDaniel Stirnimanndnssec-verify tries all keys which results in poor performance<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
I noticed that for zones with many signatures (>= ~50'000) `dnssec-verify` can perform
noticeably slower the more stand-by keys are included in the DNSKEY RR.
It looks like all ZSK keys in the DNSKEY RR are tried to verify the signatures until one is
found which succeeds. It now depends on the DNSKEY RR data structure which key is tried first and whether
the validation process is fast or slow. It would be good to first compare the RRSIG key-id with the DNSKEY key-id before attempting any cryptographic operations.
### BIND version used
dnssec-verify 9.16.5
### Steps to reproduce
````
# Create keys
# KSK
dnssec-keygen -a ECDSAP256SHA256 -f KSK foo.
Generating key pair.
Kfoo.+013+59071
# ZSK
dnssec-keygen -a ECDSAP256SHA256 foo.
Generating key pair.
Kfoo.+013+29053
# Add keys to foo.zone using an editor
$INCLUDE Kfoo.+013+59071.key
$INCLUDE Kfoo.+013+29053.key
# sign zone
dnssec-signzone -o foo. -P -t -x foo.zone Kfoo.+013+59071.private Kfoo.+013+29053.private
# verify zone
time dnssec-verify -o foo. foo.zone.signed
````
### What is the current *bug* behavior?
Depending on the key id and how many stand-by keys are present, the validation time of `dnssec-verify` slows down noticeably.
Some examples below:
**active ZSK: Kfoo.+013+39828, no stand-by ZSK**
```
time dnssec-verify -o foo. foo.zone.signed
Loading zone 'foo.' from file 'foo.zone.signed'
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
real 0m9.677s
user 0m9.645s
sys 0m0.026s
```
About ~9-10sec is the baseline
**active ZSK: Kfoo.+013+59286 , stand-by ZSK: Kfoo.+013+39828**
```
time dnssec-verify -o foo. foo.zone.signed
Loading zone 'foo.' from file 'foo.zone.signed'
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 1 stand-by, 0 revoked
real 0m9.662s
user 0m9.630s
sys 0m0.026s
```
Result is correct and within the baseline.
**active ZSK: Kfoo.+013+39828 , stand-by ZSK: Kfoo.+013+59286**
```
time dnssec-verify -o foo. foo.zone.signed
Loading zone 'foo.' from file 'foo.zone.signed'
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 1 stand-by, 0 revoked
real 0m14.210s
user 0m14.173s
sys 0m0.029s
```
Result is **poor**!
**active ZSK: Kfoo.+013+39828 , stand-by ZSK: Kfoo.+013+59286, Kfoo.+013+51653**
```
time dnssec-verify -o foo. foo.zone.signed
Loading zone 'foo.' from file 'foo.zone.signed'
Verifying the zone using the following algorithms: ECDSAP256SHA256.
Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 2 stand-by, 0 revoked
real 0m18.310s
user 0m18.274s
sys 0m0.029s
```
Result is **poor**!
### What is the expected *correct* behavior?
No matter how many stand-by keys are present, the validation time is more or less constant.
### Possible fixes
Check the key id before attempting to validate each signature with each key.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)https://gitlab.isc.org/isc-projects/bind9/-/issues/2071BIND stuck after error "unable to obtain neither an IPv4 nor an IPv6 dispatch"2021-10-08T14:37:43ZAnand BuddhdevBIND stuck after error "unable to obtain neither an IPv4 nor an IPv6 dispatch"### Summary
Server appeared to be stuck in some strange state after "rndc reconfig".
### BIND version used
```
BIND 9.16.5 (Stable Release) <id:c00b458>
running on Linux x86_64 3.10.0-1127.13.1.el7.x86_64 #1 SMP Tue Jun 23 15:46:38 UT...### Summary
Server appeared to be stuck in some strange state after "rndc reconfig".
### BIND version used
```
BIND 9.16.5 (Stable Release) <id:c00b458>
running on Linux x86_64 3.10.0-1127.13.1.el7.x86_64 #1 SMP Tue Jun 23 15:46:38 UTC 2020
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/named' '--disable-static' '--with-pic' '--without-python' '--with-libtool' '--without-lmdb' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39)
compiled with OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with json-c version: 0.11
linked to json-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
threads support is enabled
default paths:
named configuration: /etc/named/named.conf
rndc configuration: /etc/named/rndc.conf
DNSSEC root key: /etc/named/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
### Steps to reproduce
Haven't been able to reproduce this. We run "rndc reconfig" frequently on many of our BIND servers, and this is the first time I've seen such behaviour. On this specific server, after log rotation, logrotate ran "rndc reconfig" and BIND logged this:
### What is the current *bug* behavior?
After logging that error, BIND appeared to be stuck in a strange state. It was answering queries over UDP (did not check TCP). However, it was not refreshing any of the secondary zones. However, I don't know what was going on, because logrotate compressed the rotated log file and deleted the original, but the named process still held it open. However, it couldn't write any logs. "rndc zonestatus" for various zones showed them loaded and stuck on older serials.
### What is the expected *correct* behavior?
BIND should have reloaded its configuration and created a new log file in /var/log/named/named.log
### Relevant configuration files
I'm not including the entire config file here, but here are the relevant snippets:
```
logging {
channel "default" {
file "/var/log/named/named.log";
severity info;
print-time yes;
print-category yes;
};
channel "ratelimit" {
file "/var/log/named/ratelimit.ringlog" versions 10 size 10485760;
print-time yes;
};
category "default" {
"default";
};
category "rate-limit" {
"ratelimit";
};
category "update" {
"null";
};
category "update-security" {
"null";
};
};
options {
answer-cookie no;
directory "/var/named";
keep-response-order {
"any";
};
listen-on {
127.0.0.1/32;
IPv4 address/32;
};
listen-on-v6 {
::1/128;
IPv6 address/128;
};
server-id hostname;
tcp-clients 1000;
transfers-in 100;
transfers-out 100;
version "9.16";
dnssec-validation no;
ixfr-from-differences yes;
minimal-responses yes;
recursion no;
allow-transfer {
"internal";
};
max-journal-size 10485760;
notify explicit;
zero-no-soa-ttl no;
zone-statistics none;
};
```
### Relevant logs and/or screenshots
This was the last thing logged in the rotated file:
```
10-Aug-2020 09:21:29.548 general: received control channel command 'reconfig'
10-Aug-2020 09:21:29.548 general: loading configuration from '/etc/named/named.conf'
10-Aug-2020 09:21:29.848 general: unable to open '/etc/named/bind.keys'; using built-in keys instead
10-Aug-2020 09:21:29.851 general: using default UDP/IPv4 port range: [32768, 60999]
10-Aug-2020 09:21:29.851 general: using default UDP/IPv6 port range: [32768, 60999]
10-Aug-2020 09:21:29.853 general: sizing zone task pool based on 4615 zones
10-Aug-2020 09:21:30.253 config: none:98: 'max-cache-size 90%' - setting to 57795MB (out of 64216MB)
10-Aug-2020 09:21:30.253 general: ./server.c:4530: unexpected error:
10-Aug-2020 09:21:30.253 general: unable to obtain neither an IPv4 nor an IPv6 dispatch
10-Aug-2020 09:21:30.276 general: reloading configuration failed: unexpected error
```
We were debugging the issue the next day, on Aug 11. When we couldn't figure anything out, we tried to restart BIND. It runs under systemd on our server, and this is what appeared in the systemd journal:
```
Aug 11 09:08:00 hostname systemd[1]: Stopping BIND...
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:08:01 hostname named[3686]: named: src/unix/udp.c:119: uv__udp_finish_close: Assertion `handle->send_queue_size == 0' failed.
Aug 11 09:09:30 hostname systemd[1]: named.service stop-sigterm timed out. Killing.
```
BIND logged those errors, but failed to exit, so systemd sent it a KILL signal after 90s.
### Possible fixes
I don't have any suggestion for a fix.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)https://gitlab.isc.org/isc-projects/bind9/-/issues/1992Backport primaries and documentation changes to v9.162021-06-28T09:15:09ZOndřej SurýBackport primaries and documentation changes to v9.16* [x] !3703
* [x] !3679
* [x] !3692
* [x] !3644
* [x] !3676
* [x] !3793
* [x] !3591
* [x] !3800* [x] !3703
* [x] !3679
* [x] !3692
* [x] !3644
* [x] !3676
* [x] !3793
* [x] !3591
* [x] !3800February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1923Teach danger about placeholder in CHANGES.2021-01-29T12:54:40ZMark AndrewsTeach danger about placeholder in CHANGES.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1922SoftHSM 2.6 is causing hangs in BIND 9.112021-01-29T13:12:58ZMichał KępieńSoftHSM 2.6 is causing hangs in BIND 9.11 - https://gitlab.isc.org/isc-projects/bind9/-/jobs/932569
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/933078 - https://gitlab.isc.org/isc-projects/bind9/-/jobs/932569
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/933078February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1917danger, security and CVE.2021-01-29T12:54:56ZMark Andrewsdanger, security and CVE.It would be useful if danger checked that the CHANGES and release notes entries for [security] changes contain a CVE number.It would be useful if danger checked that the CHANGES and release notes entries for [security] changes contain a CVE number.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1815TLS/DoT configuration parsing2021-02-03T18:37:19ZWitold KrecickiTLS/DoT configuration parsingFebruary 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)