BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-03-28T11:26:32Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4656BIND resolver locks up2024-03-28T11:26:32ZKlemen MihevcBIND resolver locks up### Summary
With dnssec-validation enabled (auto), after ~15 min CPU utilization shoots up and named process becomes unresponsive. Only solution is kill -9 and restart it.
### BIND version affected
```
BIND 9.19.22 (Development Release...### Summary
With dnssec-validation enabled (auto), after ~15 min CPU utilization shoots up and named process becomes unresponsive. Only solution is kill -9 and restart it.
### BIND version affected
```
BIND 9.19.22 (Development Release) <id:d01a4e5>
running on Linux x86_64 6.7.10-gentoo-dist-hardened #1 SMP PREEMPT_DYNAMIC Sat Mar 16 10:24:08 CET 2024
built by make with '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--datarootdir=/usr/share' '--disable-dependency-tracking' '--disable-silent-rules' '--docdir=/usr/share/doc/bind-9.19.22' '--htmldir=/usr/share/doc/bind-9.19.22/html' '--with-sysroot=/' '--libdir=/usr/lib64' '--prefix=/usr' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-full-report' '--without-readline' '--with-openssl=/usr' '--with-jemalloc' '--with-json-c' '--with-zlib' '--disable-dnsrps' '--disable-dnstap' '--enable-doh' '--with-libnghttp2' '--disable-fixed-rrset' '--disable-static' '--disable-geoip' '--without-maxminddb' '--with-gssapi' '--with-libidn2' '--without-lmdb' '--with-libxml2' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-pc-linux-gnu' 'CFLAGS=-march=native -O2 -pipe -fomit-frame-pointer -flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing' 'LDFLAGS=-Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs' 'PKG_CONFIG_PATH=/var/tmp/portage/net-dns/bind-9.19.22/temp/python3.11/pkgconfig' 'PYTHON=/usr/bin/python3.11'
compiled by GCC 13.2.1 20240210
compiled with OpenSSL version: OpenSSL 3.2.1 30 Jan 2024
linked to OpenSSL version: OpenSSL 3.2.1 30 Jan 2024
compiled with libuv version: 1.48.0
linked to libuv version: 1.48.0
compiled with liburcu version: 0.14.0
compiled with jemalloc version: 5.3.0
compiled with libnghttp2 version: 1.60.0
linked to libnghttp2 version: 1.60.0
compiled with libxml2 version: 2.12.6
linked to libxml2 version: 21206
compiled with json-c version: 0.17
linked to json-c version: 0.17
compiled with zlib version: 1.3.1
linked to zlib version: 1.3.1
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): 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: /var/run/named/session.key
named PID file: /var/run/named/named.pid
```
### Steps to reproduce
1. Use _attached_ configuration file
2. Start BIND server with command: `/usr/sbin/named -u named'
3. Clients on local network using recursion, it only takes ~15min for bug to show.
### What is the current *bug* behavior?
Named process locks up and stops responding 'named 31677 158 0.2 469800 45472 ? Rsl 09:12 26:18 /usr/sbin/named -u named', utilization 158...
### What is the expected *correct* behavior?
Named process not locking up? There was no such issue in 9.19.21 or there isnt one in 9.18.25.
### Relevant configuration files
```
key "dhcp" {
algorithm hmac-sha512;
secret "";
};
key "acmechallenge" {
algorithm hmac-sha512;
secret "";
};
tls "local-tls" {
cert-file "/etc/acme-sh/domain.net_ecc/fullchain.cer";
key-file "/etc/acme-sh/domain.net_ecc/domain.net.key";
protocols { TLSv1.2; TLSv1.3; };
ciphers "EECDH+AES256+AESGCM:EECDH+CHACHA20:EECDH+AES128+AESGCM:EECDH+AES256+SHA384";
prefer-server-ciphers yes;
session-tickets no;
};
masters "notifyhenet" {
216.218.130.2;
2001:470:100::2;
};
acl "xferhenet" {
216.218.133.2;
2001:470:600::2;
};
acl "trusted" {
127.0.0.1;
10.0.0.0/16;
IPV4;
::1;
IPV6_SUBNET/56;
};
dnssec-policy "standard" {
keys {
ksk lifetime unlimited algorithm ecdsap256sha256;
zsk lifetime 90d algorithm ecdsap256sha256;
};
dnskey-ttl 86400;
publish-safety 7d;
retire-safety 7d;
purge-keys 7d;
nsec3param iterations 0 optout no salt-length 0;
};
options {
directory "/var/bind";
pid-file "/run/named/named.pid";
server-id "ns.domain.net";
version none;
listen-on { 127.0.0.1; IPV4; 10.0.0.1; };
listen-on-v6 { ::1; IPV6; };
listen-on port 853 tls local-tls { 127.0.0.1; IPV4; 10.0.0.1; };
listen-on-v6 port 853 tls local-tls { ::1; IPV6; };
allow-query { trusted; };
allow-query-cache { trusted; };
allow-recursion { trusted; };
allow-transfer { trusted; };
allow-update { none; };
forward first;
forwarders port 853 tls local-tls {
1.1.1.1; 2606:4700:4700::1111; // Cloudflare DNS
1.0.0.1; 2606:4700:4700::1001; // Cloudflare DNS
/* 8.8.8.8; 2001:4860:4860::8888; // Google DNS
8.8.4.4; 2001:4860:4860::8844; // Google DNS */
};
/* forwarders {
1.1.1.1; 2606:4700:4700::1111; // Cloudflare DNS
1.0.0.1; 2606:4700:4700::1001; // Cloudflare DNS
84.255.209.79; 2a01:260:1:2::3; // T-2 DNS
84.255.210.79; 2a01:260:1:3::3; // T-2 DNS
}; */
bindkeys-file "/etc/bind/bind.keys";
dnssec-validation auto; // auto - check from time to time, a lot of broken dnssec mess
validate-except {
plex.tv;
anker-in.com;
};
max-cache-size 512M;
edns-udp-size 1232;
max-udp-size 1232;
ixfr-from-differences yes;
};
logging {
channel info_log {
file "/var/log/named/named.log";
print-time yes;
print-severity yes;
print-category yes;
severity info;
};
channel notice_log {
file "/var/log/named/named.log";
print-time yes;
print-severity yes;
print-category yes;
severity notice;
};
category default { info_log; };
category lame-servers { notice_log; };
category security { notice_log; };
};
//controls { };
include "/etc/bind/rndc.key";
controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1; ::1; } keys { "rndc-key"; };
inet ::1 port 953 allow { 127.0.0.1; ::1; } keys { "rndc-key"; };
};
/*
statistics-channels {
inet 127.0.0.1 port 8053 allow { 127.0.0.1; ::1; };
inet ::1 port 8053 allow { 127.0.0.1; ::1; };
};
*/
zone "localhost" {
type master;
file "pri/localhost.zone";
notify no;
};
zone "127.in-addr.arpa" {
type master;
file "pri/127.zone";
notify no;
};
zone "0.10.in-addr.arpa" {
type master;
file "dyn/0.10.in-addr.arpa.zone";
notify no;
allow-update { key dhcp; };
};
zone "ipv6subnet.ip6.arpa" {
type master;
file "dyn/ipv6subnet.ip6.arpa.zone";
notify explicit;
also-notify { notifyhenet; };
allow-query { any; };
allow-transfer { xferhenet; trusted; };
allow-update { key dhcp; };
key-directory "keys/ipv6subnet.ip6.arpa";
dnssec-policy standard;
inline-signing yes;
};
zone "domain.net" {
type master;
file "pri/domain.net.zone";
notify explicit;
also-notify { notifyhenet; };
allow-query { any; };
allow-transfer { xferhenet; trusted; };
key-directory "keys/domain.net";
dnssec-policy standard;
inline-signing yes;
};
zone "lan.domain.net" {
type master;
file "dyn/lan.domain.net.zone";
notify explicit;
also-notify { notifyhenet; };
allow-query { any; };
allow-transfer { xferhenet; trusted; };
allow-update { key dhcp; };
key-directory "keys/lan.domain.net";
dnssec-policy standard;
inline-signing yes;
};
zone "acme-challenge.domain.net" {
type master;
file "dyn/acme-challenge.domain.net.zone";
notify no;
allow-query { any; };
allow-update { key acmechallenge; };
key-directory "keys/acme-challenge.domain.net";
dnssec-policy standard;
inline-signing yes;
};
zone "dnswl.org" {
type forward;
forwarders { };
};
zone "uribl.com" {
type forward;
forwarders { };
};
zone "surbl.org" {
type forward;
forwarders { };
};
```
### Relevant logs
From 9:12 to 9:28 was session with broken behavior, there is nothing in logs, session that starts at 9:28 had dnssec-validation turned off (no).
```
26-Mar-2024 09:12:02.547 general: notice: command channel listening on 127.0.0.1#953
26-Mar-2024 09:12:02.547 general: notice: command channel listening on ::1#953
26-Mar-2024 09:12:02.547 network: info: updating TLS context on 127.0.0.1#853
26-Mar-2024 09:12:02.547 network: info: updating TLS context on IPV4#853
26-Mar-2024 09:12:02.547 network: info: updating TLS context on 10.0.0.1#853
26-Mar-2024 09:12:02.547 network: info: updating TLS context on ::1#853
26-Mar-2024 09:12:02.547 network: info: updating TLS context on IPV6#853
26-Mar-2024 09:12:02.547 zoneload: info: managed-keys-zone: loaded serial 259
26-Mar-2024 09:12:02.550 zoneload: info: zone 0.10.in-addr.arpa/IN: loaded serial 2024022951
26-Mar-2024 09:12:02.550 zoneload: info: zone localhost/IN: loaded serial 2008122601
26-Mar-2024 09:12:02.550 zoneload: info: zone 127.in-addr.arpa/IN: loaded serial 2008122601
26-Mar-2024 09:12:02.550 zoneload: info: zone domain.net/IN (unsigned): loaded serial 2024022900
26-Mar-2024 09:12:02.550 zoneload: info: zone ipv6subnet.ip6.arpa/IN (unsigned): loaded serial 2024022843
26-Mar-2024 09:12:02.550 zoneload: info: zone acme-challenge.domain.net/IN (unsigned): loaded serial 2024022800
26-Mar-2024 09:12:02.550 zoneload: info: zone domain.net/IN (signed): loaded serial 2024022983 (DNSSEC signed)
26-Mar-2024 09:12:02.550 zoneload: info: zone lan.domain.net/IN (unsigned): loaded serial 2024023082
26-Mar-2024 09:12:02.550 zoneload: info: zone acme-challenge.domain.net/IN (signed): loaded serial 2024022817 (DNSSEC signed)
26-Mar-2024 09:12:02.550 general: info: zone acme-challenge.domain.net/IN (signed): receive_secure_serial: unchanged
26-Mar-2024 09:12:02.550 zoneload: info: zone ipv6subnet.ip6.arpa/IN (signed): loaded serial 2024022872 (DNSSEC signed)
26-Mar-2024 09:12:02.550 dnssec: info: zone acme-challenge.domain.net/IN (signed): reconfiguring zone keys
26-Mar-2024 09:12:02.550 zoneload: info: zone lan.domain.net/IN (signed): loaded serial 2024023184 (DNSSEC signed)
26-Mar-2024 09:12:02.550 general: notice: all zones loaded
26-Mar-2024 09:12:02.550 general: info: zone ipv6subnet.ip6.arpa/IN (signed): receive_secure_serial: unchanged
26-Mar-2024 09:12:02.550 notify: info: zone ipv6subnet.ip6.arpa/IN (signed): sending notifies (serial 2024022872)
26-Mar-2024 09:12:02.550 dnssec: info: zone ipv6subnet.ip6.arpa/IN (signed): reconfiguring zone keys
26-Mar-2024 09:12:02.550 general: notice: FIPS mode is disabled
26-Mar-2024 09:12:02.550 general: notice: running
26-Mar-2024 09:12:02.550 general: info: zone domain.net/IN (signed): receive_secure_serial: unchanged
26-Mar-2024 09:12:02.550 general: info: zone lan.domain.net/IN (signed): receive_secure_serial: unchanged
26-Mar-2024 09:12:02.550 notify: info: zone domain.net/IN (signed): sending notifies (serial 2024022983)
26-Mar-2024 09:12:02.550 dnssec: info: zone domain.net/IN (signed): reconfiguring zone keys
26-Mar-2024 09:12:02.553 dnssec: info: zone domain.net/IN (signed): next key event: 20-Apr-2024 13:00:00.550
26-Mar-2024 09:12:02.553 notify: info: zone lan.domain.net/IN (signed): sending notifies (serial 2024023184)
26-Mar-2024 09:12:02.553 dnssec: info: zone lan.domain.net/IN (signed): reconfiguring zone keys
26-Mar-2024 09:12:02.557 dnssec: info: zone ipv6subnet.ip6.arpa/IN (signed): next key event: 20-Apr-2024 13:00:00.550
26-Mar-2024 09:12:02.557 notify: info: zone ipv6subnet.ip6.arpa/IN (signed): sending notify to 216.218.130.2#53
26-Mar-2024 09:12:02.557 notify: info: zone ipv6subnet.ip6.arpa/IN (signed): sending notify to 2001:470:100::2#53
26-Mar-2024 09:12:02.560 dnssec: info: zone acme-challenge.domain.net/IN (signed): next key event: 20-Apr-2024 13:00:00.550
26-Mar-2024 09:12:02.560 dnssec: info: zone lan.domain.net/IN (signed): next key event: 20-Apr-2024 13:00:00.553
26-Mar-2024 09:12:02.563 notify: info: zone domain.net/IN (signed): sending notify to 216.218.130.2#53
26-Mar-2024 09:12:02.563 notify: info: zone domain.net/IN (signed): sending notify to 2001:470:100::2#53
26-Mar-2024 09:12:02.563 notify: info: zone lan.domain.net/IN (signed): sending notify to 2001:470:100::2#53
26-Mar-2024 09:12:02.563 notify: info: zone lan.domain.net/IN (signed): sending notify to 216.218.130.2#53
26-Mar-2024 09:12:02.573 dnssec: info: managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete)
26-Mar-2024 09:28:47.548 general: notice: command channel listening on 127.0.0.1#953
26-Mar-2024 09:28:47.548 general: notice: command channel listening on ::1#953
26-Mar-2024 09:28:47.548 network: info: updating TLS context on 127.0.0.1#853
26-Mar-2024 09:28:47.548 network: info: updating TLS context on IPV4#853
26-Mar-2024 09:28:47.548 network: info: updating TLS context on 10.0.0.1#853
26-Mar-2024 09:28:47.548 network: info: updating TLS context on ::1#853
26-Mar-2024 09:28:47.548 network: info: updating TLS context on IPV6#853
26-Mar-2024 09:28:47.548 zoneload: info: zone 0.10.in-addr.arpa/IN: loaded serial 2024022951
26-Mar-2024 09:28:47.548 zoneload: info: zone acme-challenge.domain.net/IN (unsigned): loaded serial 2024022800
26-Mar-2024 09:28:47.548 zoneload: info: zone acme-challenge.domain.net/IN (signed): loaded serial 2024022817 (DNSSEC signed)
26-Mar-2024 09:28:47.548 zoneload: info: zone 127.in-addr.arpa/IN: loaded serial 2008122601
26-Mar-2024 09:28:47.548 zoneload: info: zone ipv6subnet.ip6.arpa/IN (unsigned): loaded serial 2024022843
26-Mar-2024 09:28:47.548 general: info: zone acme-challenge.domain.net/IN (signed): receive_secure_serial: unchanged
26-Mar-2024 09:28:47.548 dnssec: info: zone acme-challenge.domain.net/IN (signed): reconfiguring zone keys
26-Mar-2024 09:28:47.552 zoneload: info: zone ipv6subnet.ip6.arpa/IN (signed): loaded serial 2024022872 (DNSSEC signed)
26-Mar-2024 09:28:47.552 zoneload: info: zone domain.net/IN (unsigned): loaded serial 2024022900
26-Mar-2024 09:28:47.552 zoneload: info: zone localhost/IN: loaded serial 2008122601
26-Mar-2024 09:28:47.552 zoneload: info: zone lan.domain.net/IN (unsigned): loaded serial 2024023082
26-Mar-2024 09:28:47.552 zoneload: info: zone domain.net/IN (signed): loaded serial 2024022983 (DNSSEC signed)
26-Mar-2024 09:28:47.552 general: info: zone domain.net/IN (signed): receive_secure_serial: unchanged
26-Mar-2024 09:28:47.552 notify: info: zone domain.net/IN (signed): sending notifies (serial 2024022983)
26-Mar-2024 09:28:47.552 dnssec: info: zone domain.net/IN (signed): reconfiguring zone keys
26-Mar-2024 09:28:47.552 zoneload: info: zone lan.domain.net/IN (signed): loaded serial 2024023184 (DNSSEC signed)
26-Mar-2024 09:28:47.552 general: notice: all zones loaded
26-Mar-2024 09:28:47.552 general: notice: FIPS mode is disabled
26-Mar-2024 09:28:47.552 general: notice: running
26-Mar-2024 09:28:47.552 general: info: zone ipv6subnet.ip6.arpa/IN (signed): receive_secure_serial: unchanged
26-Mar-2024 09:28:47.552 general: info: zone lan.domain.net/IN (signed): receive_secure_serial: unchanged
26-Mar-2024 09:28:47.552 notify: info: zone ipv6subnet.ip6.arpa/IN (signed): sending notifies (serial 2024022872)
26-Mar-2024 09:28:47.552 dnssec: info: zone ipv6subnet.ip6.arpa/IN (signed): reconfiguring zone keys
26-Mar-2024 09:28:47.558 dnssec: info: zone acme-challenge.domain.net/IN (signed): next key event: 20-Apr-2024 13:00:00.548
26-Mar-2024 09:28:47.562 dnssec: info: zone domain.net/IN (signed): next key event: 20-Apr-2024 13:00:00.552
26-Mar-2024 09:28:47.562 notify: info: zone domain.net/IN (signed): sending notify to 216.218.130.2#53
26-Mar-2024 09:28:47.562 notify: info: zone domain.net/IN (signed): sending notify to 2001:470:100::2#53
26-Mar-2024 09:28:47.565 dnssec: info: zone ipv6subnet.ip6.arpa/IN (signed): next key event: 20-Apr-2024 13:00:00.552
26-Mar-2024 09:28:47.565 notify: info: zone lan.domain.net/IN (signed): sending notifies (serial 2024023184)
26-Mar-2024 09:28:47.565 dnssec: info: zone lan.domain.net/IN (signed): reconfiguring zone keys
26-Mar-2024 09:28:47.572 dnssec: info: zone lan.domain.net/IN (signed): next key event: 20-Apr-2024 13:00:00.565
26-Mar-2024 09:28:47.572 notify: info: zone ipv6subnet.ip6.arpa/IN (signed): sending notify to 216.218.130.2#53
26-Mar-2024 09:28:47.572 notify: info: zone ipv6subnet.ip6.arpa/IN (signed): sending notify to 2001:470:100::2#53
26-Mar-2024 09:28:47.572 notify: info: zone lan.domain.net/IN (signed): sending notify to 2001:470:100::2#53
26-Mar-2024 09:28:47.572 notify: info: zone lan.domain.net/IN (signed): sending notify to 216.218.130.2#53
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4655More statistics counters for average query/response size2024-03-26T12:49:52ZperlangMore statistics counters for average query/response size### Description
(Describe the problem, use cases, benefits, and/or goals.)
To get the average query/response size timely.
Is it possible to add two new statistics counters for total query/response size by byte ?
And even more, to add...### Description
(Describe the problem, use cases, benefits, and/or goals.)
To get the average query/response size timely.
Is it possible to add two new statistics counters for total query/response size by byte ?
And even more, to add a serials of counter to record the accumulate bytes for each range according to the query/response's size in bytes, such as,
```
16-31: 1482763
32-47: 170843916
48-63: 111988356
64-79: 11257767
```
I am not sure if this feature could affect the performance of the server, if it do, it's prefered to be configurable to enable or disable it at compile time or at run time.
### Request
(Describe the solution you'd like to see.)
fetch the statistics data via 'rndc stats' or 'rndc status'.
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4653Are Application-layer Loop DoS Attacks relevant for bind9?2024-03-25T05:26:23ZPetr MenšíkAre Application-layer Loop DoS Attacks relevant for bind9?A new document were shared to me from our security team:
<<redacted>>
They are mentioning DNS, but it seems to be not a problem for any well behaving DNS server. Have you seen this paper already? Do you have already some stance for desc...A new document were shared to me from our security team:
<<redacted>>
They are mentioning DNS, but it seems to be not a problem for any well behaving DNS server. Have you seen this paper already? Do you have already some stance for described attacks? To me it seems this should not affect any well behaving resolver or its client.
Have you already assessed this kind of attack, whether it is relevant on bind9 in any well configured instance?
Can you confirm whether this strange thing is known to be relevant or irelevant to bind9 versions?https://gitlab.isc.org/isc-projects/bind9/-/issues/4650dnssec-validation locks up server with 9.19.222024-03-26T21:39:49ZKlemen Mihevcdnssec-validation locks up server with 9.19.22Hi and thanks for filing an issue! It will be read with care by human beings.
It would be a tremendous help if you could follow these steps first:
- [x] Search the existing issues in GitLab (both open and closed) to see if your report m...Hi and thanks for filing an issue! It will be read with care by human beings.
It would be a tremendous help if you could follow these steps first:
- [x] Search the existing issues in GitLab (both open and closed) to see if your report might be a duplicate. We have a large database here and many issues have already been fixed in the latest versions!
- [x] Make sure this is **not** a support question. If you have specific trouble configuring or debugging your setup, please use the bind-users mailing list: https://lists.isc.org/mailman/listinfo/bind-users
- [x] You have read and understood the "out in the open" support policy: https://blog.powerdns.com/2016/01/18/open-source-support-out-in-the-open/ . Even though it was written by the PowerDNS folks, we follow it as well!
Before continuing, **please select the appropriate issue template in the drop-down menu above, under the heading _Description_**.
i tried to use dnssec-validation (auto) with 9.19.22 and it makes server unresponsive. This didnt happen in 9.19.21. What happens is usually in first half an hour server starts to become unresponsive(LITTERALLY STUCK, need to kill -9) and cpu load rockets sky high without a reason (most i saw was 45% before i killed process manualy). This is not some high usage dns server, it serves for home domain and recursion on home network. There is nothing in the logs even with debug severity... Hopefully you can give me guidance how to help you resolve this issuehttps://gitlab.isc.org/isc-projects/bind9/-/issues/4649All TSAN-enabled builds fail in AWS-based GitLab CI jobs2024-03-25T13:45:40ZMichał KępieńAll TSAN-enabled builds fail in AWS-based GitLab CI jobs[Yesterday's mass-rebuild of Docker images][1] caused some update to be
pulled into `tsan-fedora-39-amd64` that does not play nicely with AWS
hosts because all TSAN-enabled builds now fail with an error message
like:
FATAL: ThreadSa...[Yesterday's mass-rebuild of Docker images][1] caused some update to be
pulled into `tsan-fedora-39-amd64` that does not play nicely with AWS
hosts because all TSAN-enabled builds now fail with an error message
like:
FATAL: ThreadSanitizer: unexpected memory mapping 0x7d00e0772000-0x7d00e0c00000
While it is not clear what exactly happened, here are two jobs that were
run in CI for the same commit:
- [2024-03-20 14:24, passed][2]
- [2024-03-20 16:41, failed][3]
The refreshed TSAN image was pushed to the container registry at 15:13.
The TSAN builds seemingly still work fine with the refreshed TSAN image
on our bare metal runners, which use older kernels. This is consistent
with similar reports found online:
https://stackoverflow.com/questions/77850769/fatal-threadsanitizer-unexpected-memory-mapping-when-running-on-linux-kernels
The simplest course of action is to apply the workaround mentioned in
the StackOverflow post above (`sysctl vm.mmap_rnd_bits=28`) and remove
it once the issue resolves itself as kernels and packages get updated
over time.
[1]: https://gitlab.isc.org/isc-projects/images/-/pipelines/168133
[2]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/4142725
[3]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/4143237April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4648pytest failure oraclelinux8 in rpz/tests_sh_rpz_dnsrps.py2024-03-21T12:09:20ZMark Andrewspytest failure oraclelinux8 in rpz/tests_sh_rpz_dnsrps.pyJob [#4143909](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4143909) failed for ecb043fc7b1a99a7e2ffb3d34974d16c00348471:
```
INTERNALERROR> File "/usr/local/lib/python3.6/site-packages/flaky/flaky_pytest_plugin.py", line 142, in...Job [#4143909](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4143909) failed for ecb043fc7b1a99a7e2ffb3d34974d16c00348471:
```
INTERNALERROR> File "/usr/local/lib/python3.6/site-packages/flaky/flaky_pytest_plugin.py", line 142, in _call_runtest_hook
INTERNALERROR> reraise = (runner.Exit,)
INTERNALERROR> AttributeError: module '_pytest.runner' has no attribute 'Exit'
INTERNALERROR> Traceback (most recent call last):
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4646CID 488065: Null pointer dereferences (REVERSE_INULL)2024-03-19T22:41:36ZMichal NowakCID 488065: Null pointer dereferences (REVERSE_INULL)Coverity Scan claims the following issue:
```c
/lib/dns/qpzone.c: 4805 in addrdataset()
4799 newheader->ttl = rdataset->ttl;
4800 if (rdataset->ttl == 0U) {
4801 DNS_SLABHEADER_SETATTR(newheader, DNS_SLABHEADERATTR_ZEROT...Coverity Scan claims the following issue:
```c
/lib/dns/qpzone.c: 4805 in addrdataset()
4799 newheader->ttl = rdataset->ttl;
4800 if (rdataset->ttl == 0U) {
4801 DNS_SLABHEADER_SETATTR(newheader, DNS_SLABHEADERATTR_ZEROTTL);
4802 }
4803 atomic_init(&newheader->count,
4804 atomic_fetch_add_relaxed(&init_count, 1));
>>> CID 488065: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "version" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
4805 if (version != NULL) {
4806 newheader->serial = version->serial;
4807
4808 if ((rdataset->attributes & DNS_RDATASETATTR_RESIGN) != 0) {
4809 DNS_SLABHEADER_SETATTR(newheader,
4810 DNS_SLABHEADERATTR_RESIGN);
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4645CID 488064: Passing null pointer "version" to "maybe_update_recordsandsize", ...2024-03-19T22:41:36ZMichal NowakCID 488064: Passing null pointer "version" to "maybe_update_recordsandsize", which dereferences itCoverity Scan claims the following issues:
```
/lib/dns/qpzone.c: 1994 in add()
1988 newheader->down = topheader;
1989 topheader->next = newheader;
1990 node->dirty = 1;
1991 if (changed != NULL) {
1992 ...Coverity Scan claims the following issues:
```
/lib/dns/qpzone.c: 1994 in add()
1988 newheader->down = topheader;
1989 topheader->next = newheader;
1990 node->dirty = 1;
1991 if (changed != NULL) {
1992 changed->dirty = true;
1993 }
>>> CID 488064: (FORWARD_NULL)
>>> Passing null pointer "version" to "maybe_update_recordsandsize", which dereferences it.
1994 maybe_update_recordsandsize(false, version, header,
1995 nodename->length);
1996 }
1997 } else {
1998 /*
1999 * No non-IGNORED rdatasets of the given type exist at
/lib/dns/qpzone.c: 1972 in add()
1966 if (topheader_prev != NULL) {
1967 topheader_prev->next = newheader;
1968 } else {
1969 node->data = newheader;
1970 }
1971 newheader->next = topheader->next;
>>> CID 488064: (FORWARD_NULL)
>>> Passing null pointer "version" to "maybe_update_recordsandsize", which dereferences it.
1972 maybe_update_recordsandsize(false, version, header,
1973 nodename->length);
1974 dns_slabheader_destroy(&header);
1975 } else {
1976 idx = HEADERNODE(newheader)->locknum;
1977 if (RESIGN(newheader)) {
/lib/dns/qpzone.c: 1979 in add()
1973 nodename->length);
1974 dns_slabheader_destroy(&header);
1975 } else {
1976 idx = HEADERNODE(newheader)->locknum;
1977 if (RESIGN(newheader)) {
1978 resigninsert(qpdb, idx, newheader);
>>> CID 488064: (FORWARD_NULL)
>>> Passing null pointer "version" to "resigndelete", which dereferences it.
1979 resigndelete(qpdb, version,
1980 header DNS__DB_FLARG_PASS);
1981 }
1982 if (topheader_prev != NULL) {
1983 topheader_prev->next = newheader;
1984 } else {
/lib/dns/qpzone.c: 2061 in add()
2055 newheader->next = node->data;
2056 node->data = newheader;
2057 }
2058 }
2059 }
2060
>>> CID 488064: (FORWARD_NULL)
>>> Passing null pointer "version" to "maybe_update_recordsandsize", which dereferences it.
2061 maybe_update_recordsandsize(true, version, newheader, nodename->length);
2062
2063 /*
2064 * Check if the node now contains CNAME and other data.
2065 */
2066 if (version != NULL && cname_and_other(node, version->serial)) {
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4644Make BIND 9.16.48 got warnings and got errors whtn configure with --enable-de...2024-03-18T03:31:51Znanwn147929@alibaba-inc.comMake BIND 9.16.48 got warnings and got errors whtn configure with --enable-developer<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please make sure that you make the new issue
confident...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please make sure that you make the new issue
confidential by clicking the checkbox at the bottom!
-->
### Summary
Compilation got error when configure with developer mode enabled.
### BIND version affected
BIND 9.16.48
### Steps to reproduce
1. Configure by default options `./configure`, and compile source code `make`
2. Configure by enable tests `./configure --with-cmocka --enable-developer`, and compile source code `make; make test`
### What is the current *bug* behavior?
1. Compilation by default configuration
```
base32.c: In function ‘str_totext’:
./include/isc/buffer.h:845:20: warning: the comparison will always evaluate as ‘true’ for the address of ‘region’ will never be NULL [-Waddress]
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/likely.h:25:43: note: in definition of macro ‘ISC_LIKELY’
#define ISC_LIKELY(x) __builtin_expect(!!(x), 1)
^
./include/isc/buffer.h:845:3: note: in expansion of macro ‘ISC_REQUIRE’
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/buffer.h:1046:36: note: in expansion of macro ‘ISC__BUFFER_AVAILABLEREGION’
#define isc_buffer_availableregion ISC__BUFFER_AVAILABLEREGION
^
base32.c:420:2: note: in expansion of macro ‘isc_buffer_availableregion’
isc_buffer_availableregion(target, ®ion);
^
base32.c: In function ‘mem_tobuffer’:
./include/isc/buffer.h:845:20: warning: the comparison will always evaluate as ‘true’ for the address of ‘tr’ will never be NULL [-Waddress]
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/likely.h:25:43: note: in definition of macro ‘ISC_LIKELY’
#define ISC_LIKELY(x) __builtin_expect(!!(x), 1)
^
./include/isc/buffer.h:845:3: note: in expansion of macro ‘ISC_REQUIRE’
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/buffer.h:1046:36: note: in expansion of macro ‘ISC__BUFFER_AVAILABLEREGION’
#define isc_buffer_availableregion ISC__BUFFER_AVAILABLEREGION
^
base32.c:436:2: note: in expansion of macro ‘isc_buffer_availableregion’
isc_buffer_availableregion(target, &tr);
^
gcc -std=gnu99 -include /home/wn147929/bind/bind-9.16.48/config.h -I/home/wn147929/bind/bind-9.16.48 -I../.. -I./unix/include -I./pthreads/include -I./include -I./include -I. -I/home/wn147929/bind/bind-9.16.48/lib/dns/include -I../../lib/dns/include -DOPENSSL_SUPPRESS_DEPRECATED -g -O2 -pthread -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -Wno-missing-field-initializers -fno-strict-aliasing -c base64.c
In file included from ./include/isc/assertions.h:21:0,
from ./include/isc/list.h:16,
from ./include/isc/types.h:32,
from ./include/isc/base64.h:20,
from base64.c:18:
base64.c: In function ‘str_totext’:
./include/isc/buffer.h:845:20: warning: the comparison will always evaluate as ‘true’ for the address of ‘region’ will never be NULL [-Waddress]
ISC_REQUIRE((_r) != NULL); \
^
```
2. Compilation with developer mode enabled
```
base32.c: In function ‘str_totext’:
./include/isc/buffer.h:845:20: error: the comparison will always evaluate as ‘true’ for the address of ‘region’ will never be NULL [-Werror=address]
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/likely.h:25:43: note: in definition of macro ‘ISC_LIKELY’
#define ISC_LIKELY(x) __builtin_expect(!!(x), 1)
^
./include/isc/buffer.h:845:3: note: in expansion of macro ‘ISC_REQUIRE’
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/buffer.h:1046:36: note: in expansion of macro ‘ISC__BUFFER_AVAILABLEREGION’
#define isc_buffer_availableregion ISC__BUFFER_AVAILABLEREGION
^
base32.c:420:2: note: in expansion of macro ‘isc_buffer_availableregion’
isc_buffer_availableregion(target, ®ion);
^
base32.c: In function ‘mem_tobuffer’:
./include/isc/buffer.h:845:20: error: the comparison will always evaluate as ‘true’ for the address of ‘tr’ will never be NULL [-Werror=address]
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/likely.h:25:43: note: in definition of macro ‘ISC_LIKELY’
#define ISC_LIKELY(x) __builtin_expect(!!(x), 1)
^
./include/isc/buffer.h:845:3: note: in expansion of macro ‘ISC_REQUIRE’
ISC_REQUIRE((_r) != NULL); \
^
./include/isc/buffer.h:1046:36: note: in expansion of macro ‘ISC__BUFFER_AVAILABLEREGION’
#define isc_buffer_availableregion ISC__BUFFER_AVAILABLEREGION
^
base32.c:436:2: note: in expansion of macro ‘isc_buffer_availableregion’
isc_buffer_availableregion(target, &tr);
^
cc1: all warnings being treated as errors
```
### What is the expected *correct* behavior?
Compile success
### Relevant configuration files
<!-- Paste any relevant configuration files here - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential issue, it is advisable to
obscure key secrets; this can be done automatically by using
`named-checkconf -px`. -->
### Relevant logs
<!-- Paste any relevant logs here - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise. -->https://gitlab.isc.org/isc-projects/bind9/-/issues/4642[dig] +ednsflags do not enable EDNS2024-03-17T03:16:43ZStéphane Bortzmeyer[dig] +ednsflags do not enable EDNS### Summary
dig's +ednsflags do not enable EDNS
### BIND version affected
```
BIND 9.19.21 (Development Release) <id:c030a67>
running on Linux x86_64 6.5.0-10022-tuxedo #26 SMP PREEMPT_DYNAMIC Thu Jan 18 02:29:42 UTC 2024
built by mak...### Summary
dig's +ednsflags do not enable EDNS
### BIND version affected
```
BIND 9.19.21 (Development Release) <id:c030a67>
running on Linux x86_64 6.5.0-10022-tuxedo #26 SMP PREEMPT_DYNAMIC Thu Jan 18 02:29:42 UTC 2024
built by make with default
compiled by GCC 11.4.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.43.0
linked to libuv version: 1.43.0
compiled with liburcu version: 0.13.1
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 zlib version: 1.2.11
linked to zlib version: 1.2.11
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): no
default paths:
named configuration: /usr/local/etc/named.conf
rndc configuration: /usr/local/etc/rndc.conf
nsupdate session key: /usr/local/var/run/named/session.key
named PID file: /usr/local/var/run/named/named.pid
```
### Steps to reproduce
```
dig +noedns +ednsflags=0x4000 isc.org SOA
``
### What is the current *bug* behavior?
EDNS is still disabled
### What is the expected *correct* behavior?
+ednsflags should enable EDNS, like +nsid or +dnssec do. (Or may be only if the value is not-zero.)
/label ~Bughttps://gitlab.isc.org/isc-projects/bind9/-/issues/4641dig +ednsflags does not re-enable EDNS2024-03-17T03:12:44ZMark Andrewsdig +ednsflags does not re-enable EDNS+dnssec, +nsid re-enable EDNS if currently disabled. +ednsflags should do the same+dnssec, +nsid re-enable EDNS if currently disabled. +ednsflags should do the sameApril 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4640Checkzone in system test leaks queries2024-03-21T02:40:22ZMark AndrewsCheckzone in system test leaks queriesThe checkzone "checking with max ttl (text)" test leaks queries.The checkzone "checking with max ttl (text)" test leaks queries.April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4639Add OpenSSL Flags to proxystream_test2024-03-14T23:42:27ZSamuel ChiangAdd OpenSSL Flags to proxystream_testproxystream_test does not seem to have OpenSSL Flags defined, which causes issues if OpenSSL is not within the standard path. Adding this adheres to the other test executables that are dependent on OpenSSL in this file. I have a patch pr...proxystream_test does not seem to have OpenSSL Flags defined, which causes issues if OpenSSL is not within the standard path. Adding this adheres to the other test executables that are dependent on OpenSSL in this file. I have a patch provided below :smile:
```
diff --git a/tests/isc/Makefile.am b/tests/isc/Makefile.am
index 5cdd915..6ee1935 100644
--- a/tests/isc/Makefile.am
+++ b/tests/isc/Makefile.am
@@ -115,10 +115,12 @@ proxyheader_test_SOURCES = \
proxyheader_test_data.h
proxystream_test_CPPFLAGS = \
- $(AM_CPPFLAGS)
+ $(AM_CPPFLAGS) \
+ $(OPENSSL_CFLAGS)
proxystream_test_LDADD = \
- $(LDADD)
+ $(LDADD) \
+ $(OPENSSL_LIBS)
proxystream_test_SOURCES = \
proxystream_test.c \
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4637host, dig and nslookup don't resolve IDN domains when not used in a tty2024-03-16T06:49:38ZDirk Stöckerhost, dig and nslookup don't resolve IDN domains when not used in a tty### Summary
When calling the tools host, dig or nslookup getting data for a IDN domain only works in a tty environment. That's an extremely non-obvious bug.
Calling `host stöcker.eu` works, while `host stöcker.eu |cat` cannot resolve t...### Summary
When calling the tools host, dig or nslookup getting data for a IDN domain only works in a tty environment. That's an extremely non-obvious bug.
Calling `host stöcker.eu` works, while `host stöcker.eu |cat` cannot resolve the domain.
See also my initial bug report to perl (https://github.com/Perl/perl5/issues/22080) which points to the exact code location for this bug.
### BIND version affected
I'm using bind-utils-9.18.24-1.1.x86_64 on openSUSE Tumbleweed. Same happens on older version (Ubuntu LTS).
### Steps to reproduce
See description above
1. Call `host stöcker.eu |cat` in Linux shell
### What is the current *bug* behavior?
Does not resolve a correct name
### What is the expected *correct* behavior?
Does resolve the name whether it's a tty or not.
### Relevant configuration files
none
### Relevant logs
noneNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4633Undefined behaviour in rdataslab.c2024-03-21T12:20:05ZMark AndrewsUndefined behaviour in rdataslab.cmemmove can be called with a NULL source pointer if the rdata length is zero. This is triggers undefined behaviour.memmove can be called with a NULL source pointer if the rdata length is zero. This is triggers undefined behaviour.April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4632Intermittent hang in dns__db_findnode() during RPZ-enabled "stress" test2024-03-28T11:26:58ZMichał KępieńIntermittent hang in dns__db_findnode() during RPZ-enabled "stress" test`named` seemingly hung during an RPZ-enabled "stress" test job:
https://gitlab.isc.org/isc-private/bind9/-/jobs/4115448
The same job passed fine in the scheduled pipeline that was run last
night (for the same code - only documentation ...`named` seemingly hung during an RPZ-enabled "stress" test job:
https://gitlab.isc.org/isc-private/bind9/-/jobs/4115448
The same job passed fine in the scheduled pipeline that was run last
night (for the same code - only documentation differs):
https://gitlab.isc.org/isc-projects/bind9/-/jobs/4114341
Artifacts were retained for the failed job.
```
2024-03-12:09:46:32 ERROR: Core dump file /builds/isc-private/bind9/output/ns4/core.24295 found
Core was generated by `/builds/isc-private/bind9/.local/usr/local/sbin/named -f -c ./named.conf'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007ff920ee4107 in read_indicator_wait_until_empty (rwl=rwl@entry=0x7ff91f859658) at rwlock.c:225
225 if (read_indicator_isempty(rwl)) {
[Current thread is 1 (Thread 0x7ff91fc75600 (LWP 24295))]
#0 0x00007ff920ee4107 in read_indicator_wait_until_empty (rwl=rwl@entry=0x7ff91f859658) at rwlock.c:225
#1 0x00007ff920ee4355 in isc_rwlock_wrlock (rwl=rwl@entry=0x7ff91f859658) at rwlock.c:246
#2 0x00007ff920cdf797 in findnode (db=0x7ff91f859500, name=0x7ff91edf0400, create=<optimized out>, nodep=0x7fffc0aa4f58) at qpcache.c:2901
#3 0x00007ff920c4e924 in dns__db_findnode (db=<optimized out>, name=name@entry=0x7ff91edf0400, create=create@entry=true, nodep=nodep@entry=0x7fffc0aa4f58) at db.c:439
#4 0x00007ff920d41d31 in cache_name (fctx=fctx@entry=0x7ff8fa5eec00, name=0x7ff91edf0400, message=message@entry=0x7ff8f9f13c80, addrinfo=addrinfo@entry=0x7ff8f9f067f0, now=now@entry=1710232927) at resolver.c:5803
#5 0x00007ff920d4283d in cache_message (fctx=fctx@entry=0x7ff8fa5eec00, message=0x7ff8f9f13c80, addrinfo=0x7ff8f9f067f0, now=1710232927) at resolver.c:6223
#6 0x00007ff920d4caa2 in resquery_response (eresult=<optimized out>, region=0x7fffc0aa5470, arg=0x7ff8fa2c1000) at resolver.c:7625
#7 0x00007ff920c55e6f in udp_recv (handle=0x7ff8f9d30000, eresult=<optimized out>, region=0x7fffc0aa5470, arg=<optimized out>) at dispatch.c:619
#8 0x00007ff920ea6349 in isc___nm_readcb (arg=<optimized out>) at netmgr/netmgr.c:1856
#9 0x00007ff920ea641b in isc__nm_readcb (sock=sock@entry=0x7ff8fa58e500, uvreq=uvreq@entry=0x7ff8fa539200, eresult=eresult@entry=ISC_R_SUCCESS, async=async@entry=false) at netmgr/netmgr.c:1871
#10 0x00007ff920eb7b40 in isc__nm_udp_read_cb (handle=<optimized out>, nrecv=244, buf=0x7fffc0aa5540, addr=0x7fffc0aa5590, flags=0) at netmgr/udp.c:589
#11 0x00007ff9205bb72a in uv__udp_recvmsg (handle=0x7ff8fa58e7c0) at /usr/src/libuv-v1.48.0/src/unix/udp.c:267
#12 0x00007ff9205bb022 in uv__udp_io (loop=0x7ff91f837020, w=0x7ff8fa58e840, revents=1) at /usr/src/libuv-v1.48.0/src/unix/udp.c:142
#13 0x00007ff9205c0e70 in uv__io_poll (loop=0x7ff91f837020, timeout=612) at /usr/src/libuv-v1.48.0/src/unix/linux.c:1528
#14 0x00007ff9205a5fa4 in uv_run (loop=0x7ff91f837020, mode=UV_RUN_DEFAULT) at /usr/src/libuv-v1.48.0/src/unix/core.c:448
#15 0x00007ff920ecc52d in loop_thread (arg=arg@entry=0x7ff91f837000) at loop.c:284
#16 0x00007ff920edd775 in thread_body (wrap=0x7ff91f8d8380) at thread.c:85
#17 0x00007ff920edd7ef in isc_thread_main (func=func@entry=0x7ff920ecc4a2 <loop_thread>, arg=0x7ff91f837000) at thread.c:116
#18 0x00007ff920ecd204 in isc_loopmgr_run (loopmgr=0x7ff91f80ea80) at loop.c:456
#19 0x0000000000425250 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1574
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4631CID 487884: Dead code in lib/dns/qpcache.c2024-03-14T11:50:20ZMichal NowakCID 487884: Dead code in lib/dns/qpcache.cCoverity Scan claims two instances of dead code in `lib/dns/qpcache.c`:
```c
/lib/dns/qpcache.c: 3459 in add()
3453 }
3454 newheader->next = topheader->next;
3455 newheader->down = topheader;
3456 topheader->...Coverity Scan claims two instances of dead code in `lib/dns/qpcache.c`:
```c
/lib/dns/qpcache.c: 3459 in add()
3453 }
3454 newheader->next = topheader->next;
3455 newheader->down = topheader;
3456 topheader->next = newheader;
3457 qpnode->dirty = 1;
3458 if (changed != NULL) {
>>> CID 487884: (DEADCODE)
>>> Execution cannot reach this statement: "changed->dirty = true;".
3459 changed->dirty = true;
3460 }
3461 } else {
3462 /*
3463 * No rdatasets of the given type exist at the node.
3464 */
```
```c
/lib/dns/qpcache.c: 3409 in add()
3403 }
3404 newheader->next = topheader->next;
3405 newheader->down = topheader;
3406 topheader->next = newheader;
3407 qpnode->dirty = 1;
3408 if (changed != NULL) {
>>> CID 487884: (DEADCODE)
>>> Execution cannot reach this statement: "changed->dirty = true;".
3409 changed->dirty = true;
3410 }
3411 mark_ancient(header);
3412 if (sigheader != NULL) {
3413 mark_ancient(sigheader);
3414 }
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4630CID 487883: Null pointer dereference in lib/dns/qpzone.c2024-03-14T00:31:50ZMichal NowakCID 487883: Null pointer dereference in lib/dns/qpzone.cCoverity Scan claims null pointer dereference in `lib/dns/qpzone.c`.
```c
/lib/dns/qpzone.c: 4935 in addrdataset()
4929
4930 /*
4931 * Update the zone's secure status. If version is non-NULL
4932 * this is deferre...Coverity Scan claims null pointer dereference in `lib/dns/qpzone.c`.
```c
/lib/dns/qpzone.c: 4935 in addrdataset()
4929
4930 /*
4931 * Update the zone's secure status. If version is non-NULL
4932 * this is deferred until closeversion() is called.
4933 */
4934 if (result == ISC_R_SUCCESS && version == NULL) {
>>> CID 487883: Null pointer dereferences (FORWARD_NULL)
>>> Passing null pointer "version" to "setsecure", which dereferences it.
4935 setsecure(db, version, qpdb->origin);
4936 }
4937
4938 return (result);
4939 }
4940
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4629CID 487882: Error handling issues in lib/dns/qpzone.c2024-03-14T14:12:59ZMichal NowakCID 487882: Error handling issues in lib/dns/qpzone.cCoverity Scan claims we should consider checking the return value of `dns_qpiter_next()` in `lib/dns/qpzone.c` as done elsewhere:
```c
/lib/dns/qpzone.c: 2804 in activeempty()
2798 * of the name we were searching for. Step the iter...Coverity Scan claims we should consider checking the return value of `dns_qpiter_next()` in `lib/dns/qpzone.c` as done elsewhere:
```c
/lib/dns/qpzone.c: 2804 in activeempty()
2798 * of the name we were searching for. Step the iterator
2799 * forward, then step() will continue forward until it
2800 * finds a node with active data. If that node is a
2801 * subdomain of the one we were looking for, then we're
2802 * at an active empty nonterminal node.
2803 */
>>> CID 487882: Error handling issues (CHECKED_RETURN)
>>> Calling "dns_qpiter_next" without checking return value (as is done elsewhere 26 out of 27 times).
2804 dns_qpiter_next(it, NULL, NULL, NULL);
2805 return (step(search, it, FORWARD, next) &&
2806 dns_name_issubdomain(next, current));
2807 }
2808
2809 static bool
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4628CID 487827: Control flow issues (DEADCODE) in lib/dns/qp-zonedb.c2024-03-11T18:39:47ZMichal NowakCID 487827: Control flow issues (DEADCODE) in lib/dns/qp-zonedb.cCoverity Scan claims dead code in `lib/dns/qp-zonedb.c` (#4411).
```
/lib/dns/qp-zonedb.c: 1600 in loadnode()
1594 * just now getting an NSEC record.
1595 */
1596 if (node->nsec == DNS_DB_NSEC_HAS_NSEC) {
1597 ...Coverity Scan claims dead code in `lib/dns/qp-zonedb.c` (#4411).
```
/lib/dns/qp-zonedb.c: 1600 in loadnode()
1594 * just now getting an NSEC record.
1595 */
1596 if (node->nsec == DNS_DB_NSEC_HAS_NSEC) {
1597 goto done;
1598 }
1599 } else {
>>> CID 487827: Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "goto done;".
1600 goto done;
1601 }
1602
1603 if (!hasnsec) {
1604 goto done;
1605 }
```March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.org