BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-11-02T16:26:08Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3011rndc addzone accepts secondary zone without primaries2023-11-02T16:26:08ZJP Mensrndc addzone accepts secondary zone without primaries`rndc addzone` accepts addition of secondary zone to a running server without me specifying primaries, even though such a configuration is not permitted in `named.conf`. Is this an error or does it cater for a use-case I'm not familiar w...`rndc addzone` accepts addition of secondary zone to a running server without me specifying primaries, even though such a configuration is not permitted in `named.conf`. Is this an error or does it cater for a use-case I'm not familiar with?
`BIND 9.17.19 (Development Release) <id:e8d1dd3>`
#### named.conf
```
key "rndc-key" {
algorithm hmac-sha256;
secret "4tFLJTPa4EXIY0bkrIzJOj1WNp1KSvYI4HJE+n2vrbo=";
};
options {
directory "/tmp/named";
allow-query { any; };
listen-on { 127.0.0.2; };
listen-on-v6 { none; };
allow-new-zones yes;
recursion no;
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
```
#### named -g
```
# named -g
11-Nov-2021 09:41:36.716 starting BIND 9.17.19 (Development Release) <id:e8d1dd3>
11-Nov-2021 09:41:36.716 running on Darwin x86_64 19.6.0 Darwin Kernel Version 19.6.0: Thu Sep 16 20:58:47 PDT 2021; root:xnu-6153.141.40.1~1/RELEASE_X86_64
11-Nov-2021 09:41:36.716 built with '--prefix=/usr/local/bind9git' '--with-libxml2' '--with-json-c' '--with-openssl=/usr/local/Cellar/openssl@1.1/1.1.1l_1/' 'LDFLAGS=-L/usr/local/Cellar/openssl@1.1/1.1.1l_1//lib/' 'CPPFLAGS=-I/usr/local/Cellar/openssl@1.1/1.1.1l_1//include/' 'PYTHON=/usr/local/bin/python3.9'
11-Nov-2021 09:41:36.716 running as: named -g -c /usr/local/etc/named-addzones.conf
11-Nov-2021 09:41:36.716 compiled by CLANG Apple LLVM 12.0.0 (clang-1200.0.32.29)
11-Nov-2021 09:41:36.716 compiled with OpenSSL version: OpenSSL 1.1.1l 24 Aug 2021
11-Nov-2021 09:41:36.716 linked to OpenSSL version: OpenSSL 1.1.1l 24 Aug 2021
11-Nov-2021 09:41:36.716 compiled with libxml2 version: 2.9.4
11-Nov-2021 09:41:36.716 linked to libxml2 version: 20904
11-Nov-2021 09:41:36.716 compiled with json-c version: 0.15
11-Nov-2021 09:41:36.716 linked to json-c version: 0.15
11-Nov-2021 09:41:36.716 compiled with zlib version: 1.2.11
11-Nov-2021 09:41:36.716 linked to zlib version: 1.2.11
...
11-Nov-2021 09:41:44.997 received control channel command 'addzone example.com { type secondary; file "example.com"; };'
11-Nov-2021 09:41:44.997 zone example.com/IN: cannot refresh: no primaries
11-Nov-2021 09:41:44.998 added zone example.com in view _default via addzone
```
#### rndc addzone
```console
$ rndc -k rndc.key addzone example.com '{ type secondary; file "example.com"; };'
```
#### nzf file
```console
# named-nzd2nzf /tmp/named/_default.nzd
zone "example.com" { type secondary; file "example.com"; };
```
If I try to load a `named.conf` with a statically configured secondary without primaries
```
zone "example.net" IN {
type secondary;
file "example.net";
};
```
I get an error:
```
named-addzones.conf:22: zone 'example.net': missing 'primaries' entry
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3010ThreadSanitizer: data race in closedir2021-12-23T14:43:22ZMichal NowakThreadSanitizer: data race in closedirSame issue as isc-projects/bind9#2457 [this time on Debian 11 with Clang](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2094359):
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 closed...Same issue as isc-projects/bind9#2457 [this time on Debian 11 with Clang](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2094359):
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 closedir <null>
#1 isc_dir_close lib/isc/dir.c:134:8
#2 dns_dnssec_findmatchingkeys lib/dns/dnssec.c:1514:3
#3 zone_rekey lib/dns/zone.c:21567:11
#4 zone_maintenance lib/dns/zone.c:11386:4
#5 zone_timer lib/dns/zone.c:15039:2
#6 task_run lib/isc/task.c:827:5
#7 isc_task_run lib/isc/task.c:907:10
#8 isc__nm_async_task lib/isc/netmgr/netmgr.c:834:11
#9 process_netievent lib/isc/netmgr/netmgr.c
#10 process_queue lib/isc/netmgr/netmgr.c:1007:16
#11 process_all_queues lib/isc/netmgr/netmgr.c:753:25
#12 async_cb lib/isc/netmgr/netmgr.c:782:6
#13 <null> <null>
#14 isc__trampoline_run lib/isc/trampoline.c:185:11
Previous read of size 8 at 0x000000000001 by thread T2:
#0 epoll_ctl <null>
#1 <null> <null>
#2 uv_run <null>
#3 isc__trampoline_run lib/isc/trampoline.c:185:11
Location is file descriptor 105 created by thread T2 at:
#0 accept4 <null>
#1 <null> <null>
#2 isc__trampoline_run lib/isc/trampoline.c:185:11
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/thread.c:79:8
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:328:3
#3 isc_managers_create lib/isc/managers.c:36:2
#4 create_managers bin/named/main.c:920:11
#5 setup bin/named/main.c:1184:11
#6 main bin/named/main.c:1452:2
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/thread.c:79:8
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:328:3
#3 isc_managers_create lib/isc/managers.c:36:2
#4 create_managers bin/named/main.c:920:11
#5 setup bin/named/main.c:1184:11
#6 main bin/named/main.c:1452:2
SUMMARY: ThreadSanitizer: data race in closedir
```
A blocker for base image upgrade from Debian 10 to Debian 11 (isc-projects/bind9!5367).
The solution is to have custom libuv for Debian 11 as have for Fedora already (https://gitlab.isc.org/isc-projects/images/-/merge_requests/112/diffs?commit_id=dd3c9f1d49f98a8d3584ef73478da8e9fdc2fd84).January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3009Set -DOPENSSL_SUPPRESS_DEPRECATED for 9.16 and 9.112022-03-01T09:44:10ZMark AndrewsSet -DOPENSSL_SUPPRESS_DEPRECATED for 9.16 and 9.11Given we are not planning to back port OpenSSL 3.0 changes to 9.16 and 9.11, perhaps we should just silence the deprecated warnings on these branches as they impact on --enable-developer / --enable-warn-error.Given we are not planning to back port OpenSSL 3.0 changes to 9.16 and 9.11, perhaps we should just silence the deprecated warnings on these branches as they impact on --enable-developer / --enable-warn-error.December 2021 (9.16.24, 9.16.24-S1, 9.17.21)https://gitlab.isc.org/isc-projects/bind9/-/issues/3008Bind9 going down with error rbtdb->next_serial2021-11-08T22:09:24ZAleksandr NikitinBind9 going down with error rbtdb->next_serial### Summary
I have some instances bind9, and some of them going down with error
```
Nov 04 02:30:46 vm-name named[10257]: 04-Nov-2021 02:30:46.319 general: critical: ../../../lib/dns/rbtdb.c:1497: fatal error:
Nov 04 02:30:46 vm-name na...### Summary
I have some instances bind9, and some of them going down with error
```
Nov 04 02:30:46 vm-name named[10257]: 04-Nov-2021 02:30:46.319 general: critical: ../../../lib/dns/rbtdb.c:1497: fatal error:
Nov 04 02:30:46 vm-name named[10257]: 04-Nov-2021 02:30:46.319 general: critical: RUNTIME_CHECK(rbtdb->next_serial != 0) failed
Nov 04 02:30:46 vm-name named[10257]: 04-Nov-2021 02:30:46.319 general: critical: exiting (due to fatal error in library)
Nov 04 02:30:46 vm-name systemd[1]: bind9.service: Main process exited, code=killed, status=6/ABRT
Nov 04 02:30:46 vm-name systemd[1]: bind9.service: Failed with result 'signal'.
```
### BIND version used
```
BIND 9.11.5-P4-5.1+deb10u6-Debian (Extended Support Version) <id:998753c>
running on Linux x86_64 4.19.0-18-cloud-amd64 #1 SMP Debian 4.19.208-1 (2021-09-29)
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--libexecdir=/usr/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' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--disable-isc-spnego' '--with-libidn2' '--with-libjson=/usr' '--with-lmdb=/usr' '--with-gnu-ld' '--with-geoip=/usr' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib/softhsm/libsofthsm2.so' '--with-randomdev=/dev/urandom' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-gHNcz0/bind9-9.11.5.P4+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 8.3.0
compiled with OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019
linked to OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with libjson-c version: 0.12.1
linked to libjson-c version: 0.12.1
threads support is enabled
```
### Steps to reproduce
Run bind9 with configuration, files down in text
### What is the current *bug* behavior?
Bind9 fails and not automaticaly restarts
```
Nov 04 02:30:46 vm-name named[10257]: 04-Nov-2021 02:30:46.319 general: critical: ../../../lib/dns/rbtdb.c:1497: fatal error:
Nov 04 02:30:46 vm-name named[10257]: 04-Nov-2021 02:30:46.319 general: critical: RUNTIME_CHECK(rbtdb->next_serial != 0) failed
Nov 04 02:30:46 vm-name named[10257]: 04-Nov-2021 02:30:46.319 general: critical: exiting (due to fatal error in library)
Nov 04 02:30:46 vm-name systemd[1]: bind9.service: Main process exited, code=killed, status=6/ABRT
Nov 04 02:30:46 vm-name systemd[1]: bind9.service: Failed with result 'signal'.
```
### What is the expected *correct* behavior?
Bind9 not going down
### Relevant configuration files
My configuration is:
named.conf
```
key key.for.internal.domain {
algorithm HMAC-MD5;
secret "[masked]";
};
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
```
named.conf.options
```
acl "private" {
127.0.0.1/32; # localhost
172.16.1.0/24; # wg
};
options {
directory "/var/cache/bind";
allow-query { private; };
recursion yes;
forwarders {
127.0.0.1 port 5053;
1.1.1.1;
1.0.0.1;
8.8.8.8;
8.8.4.4;
};
dnssec-enable no;
dnssec-validation no;
listen-on { any; };
listen-on-v6 { none; };
};
```
named.conf.local
```
zone "dc1.internal.domain" {
type master;
file "/etc/bind/dc1.internal.domain.db";
allow-update { key "key.for.internal.domain"; };
};
zone "156.10.in-addr.arpa" {
type master;
file "/etc/bind/156.10.in-addr.arpa.db";
allow-update { key "key.for.internal.domain"; };
};
zone "dc2.internal.domain" {
type slave;
file "/etc/bind/slave_dc2.internal.domain.db";
masters { 10.60.0.1; };
};
zone "60.10.in-addr.arpa" {
type slave;
file "/etc/bind/slave_60.10.in-addr.arpa.db";
masters { 10.60.0.1; };
};
zone "dc3.internal.domain" {
type slave;
file "/etc/bind/slave_dc3.internal.domain.db";
masters { 10.200.0.1; };
};
zone "200.10.in-addr.arpa" {
type slave;
file "/etc/bind/slave_200.10.in-addr.arpa.db";
masters { 10.200.0.1; };
};
zone "dc4.internal.domain" {
type slave;
file "/etc/bind/slave_dc4.internal.domain.db";
masters { 10.90.0.1; };
};
zone "90.10.in-addr.arpa" {
type slave;
file "/etc/bind/slave_90.10.in-addr.arpa.db";
masters { 10.90.0.1; };
};
zone "dc5.internal.domain" {
type slave;
file "/etc/bind/slave_dc5.internal.domain.db";
masters { 10.9.96.1; };
};
zone "9.10.in-addr.arpa" {
type slave;
file "/etc/bind/slave_9.10.in-addr.arpa.db";
masters { 10.9.96.1; };
};
```
named.conf.default-zones
```
zone "." {
type hint;
file "/usr/share/dns/root.hints";
};
zone "internal.domain" {
type master;
file "/etc/bind/internal.domain.db";
};
zone "another.domain" {
type master;
file "/etc/bind/another.domain.db";
};
zone "third.domain" {
type master;
file "/etc/bind/third.domain.db";
};
zone "fourth.domain" {
type master;
file "/etc/bind/fourth.domain.db";
};
```https://gitlab.isc.org/isc-projects/bind9/-/issues/3007DNS resolution fails temporarily2021-11-08T12:02:25ZK VDNS resolution fails temporarilyWe are using two Named Servers in our Production system.
BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.3 (Extended Support Version) on Linux x86_64 4.9.215-36.el7.x86_64
Recently, we started to see a trend when the DNS resolution fails betwe...We are using two Named Servers in our Production system.
BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.3 (Extended Support Version) on Linux x86_64 4.9.215-36.el7.x86_64
Recently, we started to see a trend when the DNS resolution fails between a specific time period for random domain names(out of over 100 records). Each record may fail for max 10 minutes. At all other times, it works absolutely fine.
AT THE TIME OF ISSUE:
```
dig @MY_DNS_SERVER docker.mycompany.net
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.3 <<>> @MY_DNS_SERVER docker.mycompany.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 33467
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;docker.mycompany.net. IN A
;; AUTHORITY SECTION:
mycompany.net. 58 IN SOA ns-604.awsdns-11.net. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
;; Query time: 0 msec
;; SERVER: MY_DNS_SERVER#53(MY_DNS_SERVER)
;; WHEN: Thu Nov 04 10:22:01 UTC 2021
;; MSG SIZE rcvd: 128
```
NORMAL TIMES:
```
dig @MY_DNS_SERVER docker.mycompany.net
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.3 <<>> @MY_DNS_SERVER docker.mycompany.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28581
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 7
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;docker.mycompany.net. IN A
;; ANSWER SECTION:
docker.mycompany.net. 54 IN A PROPER IP
docker.mycompany.net. 54 IN A PROPER IP
;; AUTHORITY SECTION:
mycompany.net. 81323 IN NS ns-16.awsdns-02.com.
mycompany.net. 81323 IN NS ns-1158.awsdns-16.org.
mycompany.net. 81323 IN NS ns-604.awsdns-11.net.
mycompany.net. 81323 IN NS ns-1731.awsdns-24.co.uk.
;; ADDITIONAL SECTION:
ns-1158.awsdns-16.org. 47096 IN A 205.251.196.134
ns-16.awsdns-02.com. 25941 IN A 205.251.192.16
ns-604.awsdns-11.net. 81323 IN A 205.251.194.92
ns-1158.awsdns-16.org. 68043 IN AAAA 2600:9000:5304:8600::1
ns-16.awsdns-02.com. 60863 IN AAAA 2600:9000:5300:1000::1
ns-1731.awsdns-24.co.uk. 38132 IN AAAA 2600:9000:5306:c300::1
;; Query time: 0 msec
;; SERVER: MY_DNS_SERVER#53(MY_DNS_SERVER)
;; WHEN: Thu Nov 04 10:29:03 UTC 2021
;; MSG SIZE rcvd: 347
```
The BIND Cache metrics shows a trend where it exactly starts to increase around the start of the issue(2:30pm IST). Though the DNS Resolution resolves within an hour, the graph shows a continuous upward trend which decreases only beyond midnight that day.
![BIND_CACHE_METRICS](/uploads/e26bda06452d8554a835d37e73128beb/BIND_CACHE_METRICS.PNG)
This is badly affecting Production users. Please share your suggestions as soon as possible.https://gitlab.isc.org/isc-projects/bind9/-/issues/3005[ISC-support #19488] IXFR changes committed before failing with "extra data"2021-11-30T10:42:51ZEverett Fulton[ISC-support #19488] IXFR changes committed before failing with "extra data"Ref: https://support.isc.org/Ticket/Display.html?id=19488
A Support customer has reported an awkward response by BIND to a malformed inbound IXFR from a non-BIND server, in which there are records sent after the closing SOA:
- BIND emi...Ref: https://support.isc.org/Ticket/Display.html?id=19488
A Support customer has reported an awkward response by BIND to a malformed inbound IXFR from a non-BIND server, in which there are records sent after the closing SOA:
- BIND emits a log indicating an xfr failure due to "extra data"
- Changes excluding the additional RRs are committed to the zone
- No immediate fallback from IXFR to AXFR happened (it triggers a refresh as usual)
Mark A. has mentioned that the journal code was designed with committing single deltas at a time. The journal commit could be made to cover multiple deltas and be made only after the check for extra data has been made.
This undesired behavior only occurs with malformed IXFR streams.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3004dig and named crash when receiving XFR over TLS2021-12-01T15:01:19ZCesar Kuroiwadig and named crash when receiving XFR over TLS### Summary
On some occasions, `dig` and `named` crash when making a zone transfer over TLS (client-side). This seems to become more often on larger zones, where there is a need for more DNS messages to complete the transfer.
### BIND ...### Summary
On some occasions, `dig` and `named` crash when making a zone transfer over TLS (client-side). This seems to become more often on larger zones, where there is a need for more DNS messages to complete the transfer.
### BIND version used
9.17.19
### See also
* #2986
*Note: privacy sensitive data was removed from the issue upon making it non-confidential.*December 2021 (9.16.24, 9.16.24-S1, 9.17.21)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3003Greedy regular expression causes intermittent "nsupdate" system test failures2021-11-10T01:51:51ZMichał KępieńGreedy regular expression causes intermittent "nsupdate" system test failuresOne of the checks in the `nsupdate` system test [prepares][1] an
`nsupdate` script by processing a response to a DNSKEY query.
Specifically, it attempts to change the TTL of the DNSKEY RRset (from 10
to 600). However, a greedy regular e...One of the checks in the `nsupdate` system test [prepares][1] an
`nsupdate` script by processing a response to a DNSKEY query.
Specifically, it attempts to change the TTL of the DNSKEY RRset (from 10
to 600). However, a greedy regular expression involved in that process
may cause DNSKEY RDATA to be mangled instead of the TTL:
https://gitlab.isc.org/isc-private/bind9/-/jobs/2088895
```
05-Nov-2021 11:50:17.573 received client packet from 10.53.0.3#60245
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 38838
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 2, ADDITIONAL: 0
;; ZONE SECTION:
;dnskey.test. IN SOA
;; UPDATE SECTION:
;dnskey.test. 600 IN DNSKEY 256 3 5 (
; AwEAAdS72SeIDeDR/y7ZxEToyLSQ
; Q/rm7f3dQBo/GK8RjRZTjTxMchRW
; itmi/kCJxSOW0rFV/ueWJTwcJbSq
; upYYo1bgNUGNmLDoYfPEDIsClZrK
; jaLjlSWb2v7nYGVuMpLGJX5D2NCm
; QJz5uOQR+b7r/8uSW1eQzodpsLTm
; XQCnuKvj
; ) ; ZSK; alg = RSASHA1 ; key id = 40375
;dnskey.test. 10 IN DNSKEY 257 3 5 (
; AwEAAa600INEzZ8hHtv3d2j5grzq
; 7gAvaWk2TxHTuFhRUuIVJxUNTpTa
; vHvSbZglx/AXSGIIgfXDKd0VVXTa
; sW0eewfCpjNol5Cgfnb+VlO5kmjW
; 6nr1UnLgd+H/sRdG1Ip8amR+D0Xi
; pYmXnOFuO2VvFRBizPlWCFu1sQFr
; sCRYXhB/
; ) ; KSK; alg = RSASHA1 ; key id = 19267
```
Note that the second DNSKEY RR still has a TTL of 10 seconds and
contains the string `600` in its RDATA. Looking at the contents of
`ns3/dnskey.test.db` confirms that the relevant RDATA originally
contained a string matching the regular expression `10.IN`, breaking the
replacement:
```
$TTL 10
dnskey.test. IN SOA dnskey.test. hostmaster.dnskey.test. 1 3600 900 2419200 3600
dnskey.test. IN NS dnskey.test.
dnskey.test. IN A 10.53.0.3
; This is a key-signing key, keyid 18947, for dnskey.test.
; Created: 20211105114907 (Fri Nov 5 11:49:07 2021)
; Publish: 20211105114907 (Fri Nov 5 11:49:07 2021)
; Activate: 20211105114907 (Fri Nov 5 11:49:07 2021)
dnskey.test. IN DNSKEY 257 3 5 AwEAAa100INEzZ8hHtv3d2j5grzq7gAvaWk2TxHTuFhRUuIVJxUNTpTa vHvSbZglx/AXSGIIgfXDKd0VVXTasW0eewfCpjNol5Cgfnb+VlO5kmjW 6nr1UnLgd+H/sRdG1Ip8amR+D0XipYmXnOFuO2VvFRBizPlWCFu1sQFr sCRYXhB/
```
This cannot end well:
```
05-Nov-2021 11:50:17.573 dns_dnssec_findzonekeys2: error reading Kdnskey.test.+005+19267.private: file not found
```
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/b69dfd6a7503ebb02496e115c3c05cbbf5f5f4bc/bin/tests/system/nsupdate/tests.sh#L751-755December 2021 (9.16.24, 9.16.24-S1, 9.17.21)https://gitlab.isc.org/isc-projects/bind9/-/issues/3002BIND 9.17.20 leaks memory when used as a recursive resolver2021-11-23T14:40:45ZMichał KępieńBIND 9.17.20 leaks memory when used as a recursive resolver[BIND 9.17.20 release testing][1] revealed that memory use grows
significantly over time when `named` is used as a resolver.
This was already suspected in #2953, but the problem was not as apparent
back then.
The tricky part about find...[BIND 9.17.20 release testing][1] revealed that memory use grows
significantly over time when `named` is used as a resolver.
This was already suspected in #2953, but the problem was not as apparent
back then.
The tricky part about finding the root cause of this problem is that it
does not manifest itself all the time. For example, consider the
following 3 jobs, all of which were ran over the weekend 2 weeks ago for
the exact same code revision (the results quoted come from FreeBSD
jobs):
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2065864
<details>
<summary><b>OK</b> (click to expand)</summary>
<pre>2021-10-23:10:31:17 INFO: analysis for directory /var/tmp/gitlab_runner/builds/e-TSUMFs/0/isc-projects/bind9/output/ns3
Total of 121 measurements
Mid point of run:
Minimum: 303,776 KiB
Maximum: 333,344 KiB
Average: 314,357 KiB
End of run:
Minimum: 312,740 KiB
Maximum: 341,716 KiB
Average: 325,141 KiB</pre>
</details>
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2066591
<details>
<summary><b>OK</b> (click to expand)</summary>
<pre>2021-10-24:10:31:39 INFO: analysis for directory /var/tmp/gitlab_runner/builds/e-TSUMFs/0/isc-projects/bind9/output/ns3
Total of 121 measurements
Mid point of run:
Minimum: 291,820 KiB
Maximum: 319,860 KiB
Average: 305,058 KiB
End of run:
Minimum: 298,416 KiB
Maximum: 336,140 KiB
Average: 315,823 KiB</pre>
</details>
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2067629
<details>
<summary><b>ERROR</b> (click to expand)</summary>
<pre>2021-10-25:10:31:52 INFO: analysis for directory /var/tmp/gitlab_runner/builds/e-TSUMFs/0/isc-projects/bind9/output/ns3
Total of 121 measurements
Mid point of run:
Minimum: 376,972 KiB
Maximum: 547,596 KiB
Average: 452,970 KiB
End of run:
Minimum: 595,488 KiB
Maximum: 747,184 KiB
Average: 676,506 KiB</pre>
</details>
We need to get to the bottom of this before BIND 9.18.0 is released.
[1]: https://wiki.isc.org/bin/view/QA/BindQaResults_9_16_23December 2021 (9.16.24, 9.16.24-S1, 9.17.21)https://gitlab.isc.org/isc-projects/bind9/-/issues/3001checkds test fails if Python < 3.72023-09-01T08:27:35ZAnton Castellicheckds test fails if Python < 3.7<!--
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
If Python version is less than 3.7 and the dnspython module is installed, the checkds test fails with a Python error.
### BIND version used
9.16.22
### Steps to reproduce
Python version is 3.6
dnspython module is installed
```
./configure --prefix=/usr --sysconfdir=/etc --enable-static --localstatedir=/var --with-python=/usr/bin/python3.6
make -j $(nproc)
sudo bin/tests/system/ifconfig.sh up
make check
```
### What is the current *bug* behavior?
The test fails with a Python error. See attached log.
### What is the expected *correct* behavior?
The test succeeds, or at least doesn't have a Python error.
### Relevant configuration files
### Relevant logs and/or screenshots
See attached log of checkds test output. [checkds.log](/uploads/14c23d78a2cf139bb43ad06712afb9a0/checkds.log)
### Possible fixes
The cause of the error is this line: [bin/tests/system/checkds/tests-checkds.py#L78](bin/tests/system/checkds/tests-checkds.py#L78)
The `capture_output` argument of the `subprocess.run` function was [added in Python 3.7](https://docs.python.org/3/library/subprocess.html#subprocess.run). Older versions of Python will fail with the error `TypeError: __init__() got an unexpected keyword argument 'capture_output'` as seen in the attached log.
A possible fix is to add an additional prerequisite check for the Python version being 3.7 or greater.September 2023 (9.16.44, 9.16.44-S1, 9.18.19, 9.18.19-S1, 9.19.17)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3000HTTP pipelining in statistics channels do not work - browser hangs2021-12-03T11:07:08ZPetr Špačekpspacek@isc.orgHTTP pipelining in statistics channels do not work - browser hangs### Summary
Web browser hands for 30 seconds while loading XML statistics, and after a timeout it loads the page successfully. This is most likely caused by broken HTTP pipelining.
### BIND version used
main - d48fa3b
```
$ curl --ver...### Summary
Web browser hands for 30 seconds while loading XML statistics, and after a timeout it loads the page successfully. This is most likely caused by broken HTTP pipelining.
### BIND version used
main - d48fa3b
```
$ curl --version
curl 7.79.1 (x86_64-pc-linux-gnu) libcurl/7.79.1 OpenSSL/1.1.1l zlib/1.2.11 brotli/1.0.9 zstd/1.5.0 libidn2/2.3.2 libpsl/0.21.1 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.46.0
Release-Date: 2021-09-22
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd
$ pacman -Q curl
curl 7.79.1-1
```
BIND branches 9.11 and 9.16 are not affected. A possible regression in !5455?
### Steps to reproduce
Request two URLs and use pipelining. cURL does this by default on my system:
```bash
$ curl -v -o /dev/null http://127.0.0.1:8888/bind9.xsl -o /dev/null http://127.0.0.1:8888/bind9.xsl
```
### What is the current *bug* behavior?
First file is downloaded immediately and the second file just hangs until cURL times out.
<details>
$ curl -v -o /dev/null http://127.0.0.1:8888/bind9.xsl -o /dev/null http://127.0.0.1:8888/bind9.xsl
* Trying 127.0.0.1:8888...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 127.0.0.1 (127.0.0.1) port 8888 (#0)
> GET /bind9.xsl HTTP/1.1
> Host: 127.0.0.1:8888
> User-Agent: curl/7.79.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: text/xslt+xml
< Date: Wed, 03 Nov 2021 14:15:19 GMT
< Expires: Wed, 03 Nov 2021 14:15:19 GMT
< Last-Modified: Wed, 03 Nov 2021 14:12:44 GMT
< Cache-Control: public
< Server: libisc
< Content-Length: 38976
<
{ [7007 bytes data]
100 38976 100 38976 0 0 31.6M 0 --:--:-- --:--:-- --:--:-- 37.1M
* Connection #0 to host 127.0.0.1 left intact
* Found bundle for host 127.0.0.1: 0x5649e7d7a9a0 [serially]
* Can not multiplex, even if we wanted to!
* Re-using existing connection! (#0) with host 127.0.0.1
* Connected to 127.0.0.1 (127.0.0.1) port 8888 (#0)
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0> GET /bind9.xsl HTTP/1.1
> Host: 127.0.0.1:8888
> User-Agent: curl/7.79.1
> Accept: */*
>
0 0 0 0 0 0 0 0 --:--:-- 0:00:30 --:--:-- 0* Connection died, retrying a fresh connect (retry count: 1)
0 0 0 0 0 0 0 0 --:--:-- 0:00:30 --:--:-- 0
* Closing connection 0
* Issue another request to this URL: 'http://127.0.0.1:8888/bind9.xsl'
* Hostname 127.0.0.1 was found in DNS cache
* Trying 127.0.0.1:8888...
* Connected to 127.0.0.1 (127.0.0.1) port 8888 (#1)
> GET /bind9.xsl HTTP/1.1
> Host: 127.0.0.1:8888
> User-Agent: curl/7.79.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: text/xslt+xml
< Date: Wed, 03 Nov 2021 14:15:49 GMT
< Expires: Wed, 03 Nov 2021 14:15:49 GMT
< Last-Modified: Wed, 03 Nov 2021 14:12:44 GMT
< Cache-Control: public
< Server: libisc
< Content-Length: 38976
<
{ [7007 bytes data]
100 38976 100 38976 0 0 1298 0 0:00:30 0:00:30 --:--:-- 1298
* Connection #1 to host 127.0.0.1 left intact
</details>
### What is the expected *correct* behavior?
HTTP Persistent Connections either correctly serve multiple requests, or are correctly terminated with `Connection: close` HTTP header.
### Relevant configuration files
```
statistics-channels {
inet 127.0.0.1 port 8888;
};
```
### Relevant logs and/or screenshots
None.
### Possible fixes
Either:
- Fix persistent HTTP connections in statistics channel
- Signal connection closure after each HTTP response (`Connection: close` header)
- Downgrade to HTTP/1.0 which does not use persistent connections by default - we most likely don't need HTTP 1.1 features anyway.December 2021 (9.16.24, 9.16.24-S1, 9.17.21)https://gitlab.isc.org/isc-projects/bind9/-/issues/2999remove duplicate code between DLZ example & dlzexternal test2022-01-07T09:40:28ZPetr Špačekpspacek@isc.orgremove duplicate code between DLZ example & dlzexternal testVersion: main branch, 4bebcd45033400a6b1a3057c60c3a2cfd5fd4029
These two files are substantially the same:
- contrib/dlz/example/dlz_example.c
- bin/tests/system/dlzexternal/driver/driver.c
I think we should remove one of them and use ...Version: main branch, 4bebcd45033400a6b1a3057c60c3a2cfd5fd4029
These two files are substantially the same:
- contrib/dlz/example/dlz_example.c
- bin/tests/system/dlzexternal/driver/driver.c
I think we should remove one of them and use symlink instead of copy. Updating two files is ... suboptimal.Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2998CID 340918: Uninitialized variables (UNINIT)2021-11-03T14:35:18ZMichal NowakCID 340918: Uninitialized variables (UNINIT)It seems to point to 78066157145b6a75f58ff843ac32ffabe62b2143:
```
790 static isc_result_t
791. opensslrsa_tofile(const dst_key_t *key, const char *directory) {
792 isc_result_t ret;
1. var_decl: Declaring variable p...It seems to point to 78066157145b6a75f58ff843ac32ffabe62b2143:
```
790 static isc_result_t
791. opensslrsa_tofile(const dst_key_t *key, const char *directory) {
792 isc_result_t ret;
1. var_decl: Declaring variable priv without initializer.
793 dst_private_t priv;
794 unsigned char *bufs[8] = { NULL };
795 unsigned short i = 0;
796 EVP_PKEY *pkey;
797. #if OPENSSL_VERSION_NUMBER < 0x30000000L
798 RSA *rsa = NULL;
799 const BIGNUM *n = NULL, *e = NULL, *d = NULL;
800 const BIGNUM *p = NULL, *q = NULL;
801 const BIGNUM *dmp1 = NULL, *dmq1 = NULL, *iqmp = NULL;
802 #else
803 BIGNUM *n = NULL, *e = NULL, *d = NULL;
804 BIGNUM *p = NULL, *q = NULL;
805 BIGNUM *dmp1 = NULL, *dmq1 = NULL, *iqmp = NULL;
806. #endif /* OPENSSL_VERSION_NUMBER < 0x30000000L */
807
2. Condition key->keydata.pkey == NULL, taking true branch.
808 if (key->keydata.pkey == NULL) {
3. Jumping to label err.
809 DST_RET(DST_R_NULLKEY);
810 }
```
```
*** CID 340918: Uninitialized variables (UNINIT)
/lib/dns/opensslrsa_link.c: 937 in opensslrsa_tofile()
931 priv.nelements = i;
932 ret = dst__privstruct_writefile(key, &priv, directory);
933
934 err:
935 for (i = 0; i < ARRAY_SIZE(bufs); i++) {
936 if (bufs[i] != NULL) {
>>> CID 340918: Uninitialized variables (UNINIT)
>>> Using uninitialized value "priv.elements[i].length" when calling "isc__mem_put".
937 isc_mem_put(key->mctx, bufs[i],
938 priv.elements[i].length);
939 }
940 }
941 #if OPENSSL_VERSION_NUMBER < 0x30000000L
942 RSA_free(rsa);
```November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2997nsupdate command return infomation: dns_request_createvia3: address in use2021-11-03T06:10:24Z395096713nsupdate command return infomation: dns_request_createvia3: address in usehi admin:
i meet a problem ,when use nudapte to add record ,the return infomation is dns_request_createvia3: address in use
my os is centos7
my bind-ver is bind-9.11.0.3
please help me,what's the reason of this problem?hi admin:
i meet a problem ,when use nudapte to add record ,the return infomation is dns_request_createvia3: address in use
my os is centos7
my bind-ver is bind-9.11.0.3
please help me,what's the reason of this problem?https://gitlab.isc.org/isc-projects/bind9/-/issues/2996Migrate PKCS11 from "engine" to "provider"2022-12-26T19:20:52ZMark AndrewsMigrate PKCS11 from "engine" to "provider"OpenSSL 3.0.0 has deprecated the `engine` api in favour of the `provider` api. We currently use the `engine` api and OpenSC for pkcs11 access to HSMs. We need to move to using the `provider` api as soon as possible.
OpenSC has an open...OpenSSL 3.0.0 has deprecated the `engine` api in favour of the `provider` api. We currently use the `engine` api and OpenSC for pkcs11 access to HSMs. We need to move to using the `provider` api as soon as possible.
OpenSC has an open ticket for OpenSSL 3.0.0 https://github.com/OpenSC/OpenSC/issues/2308Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2995about PKCS11 document2022-03-01T09:43:12Zperlangabout PKCS11 documentFrom release note of 9.16.22, there is following line,
The use of native PKCS#11 for Public-Key Cryptography in BIND 9 has been deprecated in favor of the engine_pkcs11 OpenSSL engine from the OpenSC project.
but in section 5.11.2 Nati...From release note of 9.16.22, there is following line,
The use of native PKCS#11 for Public-Key Cryptography in BIND 9 has been deprecated in favor of the engine_pkcs11 OpenSSL engine from the OpenSC project.
but in section 5.11.2 Native PKCS#11 of Bv9ARM(9.16.22), there is one opposite meaning line,
(Note: Eventually, when more HSMs become capable of supporting native PKCS#11, it is expected that OpenSSL-based PKCS#11 will be deprecated.)
I guess the latter(5.11.2) should be outdated. But not too sure.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2994query_test failure on Ubuntu 21.10 (Impish)2023-10-12T11:14:49ZJean-Christophe Manciotquery_test failure on Ubuntu 21.10 (Impish)
Does not pass the tests when built on Ubuntu impish.
### BIND version used
v9_17_19
### Some packages of interest
- autoconf: 2.69-14
- make: 4.3-4ubuntu1
- gcc-11: 11.2.0-7ubuntu2
- python3.9: 3.9.7-4
- pytest: 6.2.5
### Steps to ...
Does not pass the tests when built on Ubuntu impish.
### BIND version used
v9_17_19
### Some packages of interest
- autoconf: 2.69-14
- make: 4.3-4ubuntu1
- gcc-11: 11.2.0-7ubuntu2
- python3.9: 3.9.7-4
- pytest: 6.2.5
### Steps to reproduce
```
git checkout v9_17_19
export CFLAGS+=-Wno-error
export NOCONFIGURE=yes
autoreconf -f -i
./configure --build=x86_64-pc-linux-gnu \
--prefix=/usr --sysconfdir=/etc/bind --localstatedir=/ \
--datarootdir=/usr/share --docdir=/usr/share/doc --mandir=/usr/share/man \
--disable-native-pkcs11 \
--disable-querytrace \
--enable-auto-validation \
--enable-developer \
--enable-dnstap \
--enable-fixed-rrset \
--enable-full-report \
--enable-largefile \
--enable-linux-caps \
--enable-shared=yes \
--with-cmocka=yes \
--with-gnu-ld=yes \
--with-gssapi=/usr/bin/krb5-config \
--with-jemalloc=detect \
--with-json-c=yes \
--with-libidn2 \
--with-libxml2=yes \
--with-lmdb=auto \
--with-maxminddb=yes \
--with-openssl=/usr/lib/x86_64-linux-gnu \
--with-tuning=large \
--with-zlib=yes
make all
make doc html pdf
sudo pip3 install -I pytest
sudo bin/tests/system/ifconfig.sh up
make check
```
leads to:
```
...
make[5]: Entering directory 'git-bind9/lib/ns/tests'
make[6]: Entering directory 'git-bind9/lib/ns/tests'
PASS: listenlist_test
PASS: notify_test
PASS: plugin_test
FAIL: query_test
============================================================================
Testsuite summary for BIND 9.17.19
============================================================================
# TOTAL: 4
# PASS: 3
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
============================================================================
See lib/ns/tests/test-suite.log
Please report to info@isc.org
============================================================================
```
**test-suite.log**
```
===============================================
BIND 9.17.19: lib/ns/tests/test-suite.log
===============================================
# TOTAL: 4
# PASS: 3
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: query_test
================
[==========] Running 4 test(s).
[ RUN ] ns__query_sfcache_test
[ OK ] ns__query_sfcache_test
[ RUN ] ns__query_start_test
[ OK ] ns__query_start_test
[ RUN ] ns__query_hookasync_test
netmgr/tcpdns.c:334: fatal error: RUNTIME_CHECK(result == ISC_R_SUCCESS) failed
FAIL query_test (exit status: 134)
```Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2993Replace instances of ARRAYSIZE with ARRAY_SIZE2021-11-02T15:03:50ZMark AndrewsReplace instances of ARRAYSIZE with ARRAY_SIZEARRAY_SIZE is defined in isc/util.h if not already defined by the host systemARRAY_SIZE is defined in isc/util.h if not already defined by the host systemNovember 2021 (9.16.23, 9.16.23-S1, 9.17.20)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2992Replace "tcp-only" with a more generic option2023-11-02T17:02:20ZArtem BoldarievReplace "tcp-only" with a more generic optionBind has a `tcp-only` option to force interaction with a server using TCP only.
```
server <address> {
...
tcp-only yes;
...
};
```
This option was enough when DNS was using UDP and TCP only (Do53), however as it becomes po...Bind has a `tcp-only` option to force interaction with a server using TCP only.
```
server <address> {
...
tcp-only yes;
...
};
```
This option was enough when DNS was using UDP and TCP only (Do53), however as it becomes possible to carry DNS traffic with more transports, we might need to replace this option with a more generic one which could specify the desired transport explicitly, e.g.:
```
server <address> {
...
transport tcp; # or "tls", or "quic" (in the future), etc
...
};
```
When the option is omitted, it means use the default (Do53 - the current behaviour).
This issue, in a way, mirrors #2776.Not plannedArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2991Address reports by Coverity in updated OpenSSL code !53852021-11-02T14:49:08ZMark AndrewsAddress reports by Coverity in updated OpenSSL code !5385```
** CID 340808: Control flow issues (DEADCODE)
/lib/dns/openssldh_link.c: 1209 in openssldh_parse()
________________________________________________________________________________________________________
*** CID 340808: Control ...```
** CID 340808: Control flow issues (DEADCODE)
/lib/dns/openssldh_link.c: 1209 in openssldh_parse()
________________________________________________________________________________________________________
*** CID 340808: Control flow issues (DEADCODE)
/lib/dns/openssldh_link.c: 1209 in openssldh_parse()
1203 key->key_size = (unsigned int)key_size;
1204 ret = ISC_R_SUCCESS;
1205
1206 err:
1207 #if OPENSSL_VERSION_NUMBER < 0x30000000L
1208 if (dh != NULL) {
CID 340808: Control flow issues (DEADCODE)
Execution cannot reach this statement: "DH_free(dh);".
1209 DH_free(dh);
1210 }
1211 #else
1212 if (pkey != NULL) {
1213 EVP_PKEY_free(pkey);
1214 }
```
```
** CID 340807: (OVERRUN)
/lib/dns/opensslrsa_link.c: 931 in opensslrsa_tofile()
/lib/dns/opensslrsa_link.c: 930 in opensslrsa_tofile()
/lib/dns/opensslrsa_link.c: 931 in opensslrsa_tofile()
________________________________________________________________________________________________________
*** CID 340807: (OVERRUN)
/lib/dns/opensslrsa_link.c: 931 in opensslrsa_tofile()
925 priv.nelements = i;
926 ret = dst__privstruct_writefile(key, &priv, directory);
927
928 err:
929 while (i--) {
930 if (bufs[i] != NULL) {
CID 340807: (OVERRUN)
Overrunning array "bufs" of 8 8-byte elements at element index 9 (byte offset 79) using index "i" (which evaluates to 9).
931 isc_mem_put(key->mctx, bufs[i],
932 priv.elements[i].length);
933 }
934 }
935 #if OPENSSL_VERSION_NUMBER < 0x30000000L
936 RSA_free(rsa);
/lib/dns/opensslrsa_link.c: 930 in opensslrsa_tofile()
924
925 priv.nelements = i;
926 ret = dst__privstruct_writefile(key, &priv, directory);
927
928 err:
929 while (i--) {
CID 340807: (OVERRUN)
Overrunning array "bufs" of 8 8-byte elements at element index 9 (byte offset 79) using index "i" (which evaluates to 9).
930 if (bufs[i] != NULL) {
931 isc_mem_put(key->mctx, bufs[i],
932 priv.elements[i].length);
933 }
934 }
935 #if OPENSSL_VERSION_NUMBER < 0x30000000L
/lib/dns/opensslrsa_link.c: 931 in opensslrsa_tofile()
925 priv.nelements = i;
926 ret = dst__privstruct_writefile(key, &priv, directory);
927
928 err:
929 while (i--) {
930 if (bufs[i] != NULL) {
CID 340807: (OVERRUN)
Overrunning array "bufs" of 8 8-byte elements at element index 9 (byte offset 79) using index "i" (which evaluates to 9).
931 isc_mem_put(key->mctx, bufs[i],
932 priv.elements[i].length);
933 }
934 }
935 #if OPENSSL_VERSION_NUMBER < 0x30000000L
936 RSA_free(rsa);
```November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Mark AndrewsMark Andrews