BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-04-26T09:47:46Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2653notify-source disables querys2021-04-26T09:47:46Ztubercelnotify-source disables querys<!--
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).
-->
If notify-source is set bind stops answering queries on that IP.
### BIND version used
~~~
BIND 9.16.12 (Stable Release) <id:aeb943d>
running on FreeBSD amd64 12.2-STABLE FreeBSD 12.2-STABLE r369225 XENET
built by make with '--disable-linux-caps' '--localstatedir=/var' '--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--with-libxml2' '--with-openssl=/usr' '--with-readline=-L/usr/local/lib -ledit' '--with-dlz-filesystem=yes' '--enable-dnstap' '--disable-fixed-rrset' '--disable-geoip' '--without-maxminddb' '--without-gssapi' '--with-libidn2=/usr/local' '--without-json-c' '--disable-largefile' '--with-lmdb=/usr/local' '--disable-native-pkcs11' '--without-python' '--disable-querytrace' '--enable-tcp-fastopen' '--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd12.2' 'build_alias=amd64-portbld-freebsd12.2' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf'
compiled by CLANG FreeBSD Clang 10.0.1 (git@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2)
compiled with OpenSSL version: OpenSSL 1.1.1i-freebsd 8 Dec 2020
linked to OpenSSL version: OpenSSL 1.1.1i-freebsd 8 Dec 2020
compiled with libuv version: 1.41.0
linked to libuv version: 1.41.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
compiled with protobuf-c version: 1.3.2
linked to protobuf-c version: 1.3.2
threads support is enabled
default paths:
named configuration: /usr/local/etc/namedb/named.conf
rndc configuration: /usr/local/etc/namedb/rndc.conf
DNSSEC root key: /usr/local/etc/namedb/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/pid
named lock file: /var/run/named/named.lock
~~~
### Steps to reproduce
Use the following named.conf an uncomment notify-source
~~~
//-----------------------------------------------------------------------------------------
// Nameserver
//-----------------------------------------------------------------------------------------
options {
directory "/usr/local/etc/namedb/working";
pid-file "/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
listen-on {
213.131.254.195;
127.0.0.1;
};
query-source address 213.131.254.195 port *;
// notify-source 213.131.254.195 port 53;
transfer-source 213.131.254.195 port 53;
disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
notify explicit;
recursion no;
allow-transfer { none; };
};
include "/usr/local/etc/namedb/named.logging.conf";
zone "." { type hint; file "/usr/local/etc/namedb/named.root"; };
include "/usr/local/etc/namedb/default-zones.conf";
include "/usr/local/etc/namedb/master-zones.conf";
~~~
### What is the current *bug* behavior?
With notify-source commented out external queries work fine.
With notify-source queries are not answered.
No query is logged no answer ist sent.
### What is the expected *correct* behavior?
notify-source must not interfer with normal queries.
### Relevant configuration files
### Relevant logs and/or screenshots
### Possible fixeshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2654Create isc_managers API2021-05-11T08:58:27ZOndřej SurýCreate isc_managers APIAll the BIND 9 binaries have the same sequence of taskmgr/netmgr/timermgr/... ctors and dtors. Move this into a separate API, so we don't duplicate the code at various places.All the BIND 9 binaries have the same sequence of taskmgr/netmgr/timermgr/... ctors and dtors. Move this into a separate API, so we don't duplicate the code at various places.May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2655Assertion failure in rdataset.c:2642021-08-05T14:18:00ZGiedrius TuminauskasAssertion failure in rdataset.c:264During weekly logrotate cron job (on Sunday), when named-pkcs11 is reloaded - stops working
Affected versions:
```
bind-9.11.4-26.P2.el7_9.4.x86_64
bind-9.11.20-5.el8.x86_64
```
```
25-Apr-2021 06:45:07.219 reloading configuration succ...During weekly logrotate cron job (on Sunday), when named-pkcs11 is reloaded - stops working
Affected versions:
```
bind-9.11.4-26.P2.el7_9.4.x86_64
bind-9.11.20-5.el8.x86_64
```
```
25-Apr-2021 06:45:07.219 reloading configuration succeeded
25-Apr-2021 06:45:07.219 reloading zones succeeded
25-Apr-2021 06:45:07.219 shutting down automatic empty zones to enable forwarding for domain '.'
25-Apr-2021 06:45:07.347 ../../../lib/dns-pkcs11/rdataset.c:264: REQUIRE(rdataset->methods != ((void *)0)) failed, back trace
25-Apr-2021 06:45:07.347 #0 0x556d08b4c744 in ??
25-Apr-2021 06:45:07.347 #1 0x7fe0e582bb10 in ??
25-Apr-2021 06:45:07.347 #2 0x7fe0e5bb812a in ??
25-Apr-2021 06:45:07.347 #3 0x7fe0e5bce008 in ??
25-Apr-2021 06:45:07.347 #4 0x7fe0e5bd0b49 in ??
25-Apr-2021 06:45:07.347 #5 0x7fe0e5bd19a0 in ??
25-Apr-2021 06:45:07.347 #6 0x7fe0e58522bf in ??
25-Apr-2021 06:45:07.347 #7 0x7fe0e327b14a in ??
25-Apr-2021 06:45:07.347 #8 0x7fe0e2c44f23 in ??
25-Apr-2021 06:45:07.347 exiting (due to assertion failure)
```https://gitlab.isc.org/isc-projects/bind9/-/issues/2656resolver system test fails on macOS2021-05-12T03:40:54ZMark Andrewsresolver system test fails on macOSThe application context is not properly initialised in isc_appctx_create() resulting in isc_mutex_lock failures.
```
diff --git a/lib/isc/app.c b/lib/isc/app.c
index 04f4712434..7bc1e57a9c 100644
--- a/lib/isc/app.c
+++ b/lib/isc/app.c
...The application context is not properly initialised in isc_appctx_create() resulting in isc_mutex_lock failures.
```
diff --git a/lib/isc/app.c b/lib/isc/app.c
index 04f4712434..7bc1e57a9c 100644
--- a/lib/isc/app.c
+++ b/lib/isc/app.c
@@ -518,6 +518,13 @@ isc_appctx_create(isc_mem_t *mctx, isc_appctx_t **ctxp) {
ctx = isc_mem_get(mctx, sizeof(*ctx));
*ctx = (isc_appctx_t){ .magic = 0 };
+ isc_mutex_init(&ctx->lock);
+
+#ifndef WIN32
+ isc_mutex_init(&ctx->readylock);
+ isc_condition_init(&ctx->ready);
+#endif
+
isc_mem_attach(mctx, &ctx->mctx);
ctx->magic = APPCTX_MAGIC;
```
The above is incomplete w.r.t. windows builds.
```
S:resolver:2021-05-06T09:36:57+1000
T:resolver:1:A
A:resolver:System test resolver
I:resolver:PORTS:5300,5301,5302,5303,5304,5305,5306,5307,5308,5309,5310,5311,5312
I:resolver:starting servers
I:resolver:checking non-cachable NXDOMAIN response handling (1)
I:resolver:checking non-cachable NXDOMAIN response handling using dns_client (2)
tests.sh: line 37: 58105 Abort trap: 6 (core dumped) $RESOLVE $RESOLVOPTS -t a -s 10.53.0.1 nxdomain.example.net 2> resolve.out.ns1.test${n}
I:resolver:failed
I:resolver:checking that local bound address can be set (Can't query from a denied address) (3)
tests.sh: line 55: 58127 Abort trap: 6 (core dumped) ${RESOLVE} -b 10.53.0.8 $RESOLVOPTS -t a -s 10.53.0.1 www.example.org 2> resolve.out.ns1.test${n}
I:resolver:failed
I:resolver:checking that local bound address can be set (Can query from an allowed address) (4)
app.c:242: fatal error: RUNTIME_CHECK(((pthread_mutex_lock(((&ctx->lock))) == 0) ? 0 : 34) == 0) failed
tests.sh: line 55: 58148 Abort trap: 6 (core dumped) ${RESOLVE} -b 10.53.0.1 $RESOLVOPTS -t a -s 10.53.0.1 www.example.org > resolve.out.ns1.test${n}
I:resolver:failed
I:resolver:checking non-cachable NODATA response handling (5)
I:resolver:checking non-cachable NODATA response handling using dns_client (6)
tests.sh: line 73: 58188 Abort trap: 6 (core dumped) $RESOLVE $RESOLVOPTS -t a -s 10.53.0.1 nodata.example.net 2> resolve.out.ns1.test${n}
I:resolver:failed
I:resolver:checking handling of bogus referrals (7)
I:resolver:checking handling of bogus referrals using dns_client (8)
tests.sh: line 88: 58228 Abort trap: 6 (core dumped) $RESOLVE $RESOLVOPTS -t a -s 10.53.0.1 www.example.com 2> resolve.out.ns1.test${n}
I:resolver:failed
I:resolver:check handling of cname + other data / 1 (9)
I:resolver:check handling of cname + other data / 2 (10)
I:resolver:check that server is still running (11)
I:resolver:checking answer IPv4 address filtering (deny) (12)
I:resolver:checking answer IPv6 address filtering (deny) (13)
I:resolver:checking answer IPv4 address filtering (accept) (14)
I:resolver:checking answer IPv4 address filtering using dns_client (accept) (15)
app.c:242: fatal error: RUNTIME_CHECK(((pthread_mutex_lock(((&ctx->lock))) == 0) ? 0 : 34) == 0) failed
tests.sh: line 135: 58357 Abort trap: 6 (core dumped) $RESOLVE $RESOLVOPTS -t a -s 10.53.0.1 www.example.org > resolve.out.ns1.test${n}
I:resolver:failed
I:resolver:checking answer IPv6 address filtering (accept) (16)
I:resolver:checking answer IPv6 address filtering using dns_client (accept) (17)
app.c:242: fatal error: RUNTIME_CHECK(((pthread_mutex_lock(((&ctx->lock))) == 0) ? 0 : 34) == 0) failed
tests.sh: line 153: 58398 Abort trap: 6 (core dumped) $RESOLVE $RESOLVOPTS -t aaaa -s 10.53.0.1 www.example.org > resolve.out.ns1.test${n}
I:resolver:failed
I:resolver:checking CNAME target filtering (deny) (18)
I:resolver:checking CNAME target filtering (accept) (19)
I:resolver:checking CNAME target filtering using dns_client (accept) (20)
app.c:242: fatal error: RUNTIME_CHECK(((pthread_mutex_lock(((&ctx->lock))) == 0) ? 0 : 34) == 0) failed
tests.sh: line 180: 58458 Abort trap: 6 (core dumped) $RESOLVE $RESOLVOPTS -t a -s 10.53.0.1 goodcname.example.net > resolve.out.ns1.test${n}
I:resolver:failed
I:resolver:checking CNAME target filtering (accept due to subdomain) (21)
I:resolver:checking CNAME target filtering using dns_client (accept due to subdomain) (22)
app.c:242: fatal error: RUNTIME_CHECK(((pthread_mutex_lock(((&ctx->lock))) == 0) ? 0 : 34) == 0) failed
tests.sh: line 199: 58500 Abort trap: 6 (core dumped) $RESOLVE $RESOLVOPTS -t a -s 10.53.0.1 cname.sub.example.org > resolve.out.ns1.test${n}
I:resolver:failed
I:resolver:checking DNAME target filtering (deny) (23)
I:resolver:checking DNAME target filtering (accept) (24)
I:resolver:checking DNAME target filtering using dns_client (accept) (25)
app.c:242: fatal error: RUNTIME_CHECK(((pthread_mutex_lock(((&ctx->lock))) == 0) ? 0 : 34) == 0) failed
tests.sh: line 227: 58561 Abort trap: 6 (core dumped) $RESOLVE $RESOLVOPTS -t a -s 10.53.0.1 foo.gooddname.example.net > resolve.out.ns1.test${n}
I:resolver:failed
I:resolver:checking DNAME target filtering (accept due to subdomain) (26)
I:resolver:checking DNAME target filtering using dns_client (accept due to subdomain) (27)
app.c:242: fatal error: RUNTIME_CHECK(((pthread_mutex_lock(((&ctx->lock))) == 0) ? 0 : 34) == 0) failed
tests.sh: line 246: 58604 Abort trap: 6 (core dumped) $RESOLVE $RESOLVOPTS -t a -s 10.53.0.1 www.dname.sub.example.org > resolve.out.ns1.test${n}
I:resolver:failed
I:resolver:check that the resolver accepts a referral response with a non-empty ANSWER section (28)
I:resolver:check that the resolver limits the number of NS records it follows in a referral response (29)
I:resolver:RT21594 regression test check setup (30)
I:resolver:RT21594 regression test positive answers (31)
I:resolver:RT21594 regression test NODATA answers (32)
I:resolver:RT21594 regression test NXDOMAIN answers (33)
I:resolver:check that replacement of additional data by a negative cache no data entry clears the additional RRSIGs (34)
I:resolver:checking that update a nameservers address has immediate effects (35)
I:resolver:checking that update a nameservers glue has immediate effects (36)
I:resolver:checking empty RFC 1918 reverse zones (37)
I:resolver:checking that removal of a delegation is honoured (38)
I:resolver:ns4 zone reload queued
I:resolver:check for improved error message with SOA mismatch (39)
I:resolver:check resolution on the listening port (40)
I:resolver:check prefetch (41)
I:resolver:check prefetch of validated DS's RRSIG TTL is updated (42)
I:resolver:check prefetch disabled (43)
I:resolver:check prefetch qtype * (44)
I:resolver:check that E was logged on EDNS queries in the query log (45)
I:resolver:check that '-t aaaa' in .digrc does not have unexpected side effects (46)
I:resolver:check that EDNS version is logged (47)
I:resolver:check that CNAME nameserver is logged correctly (48)
I:resolver:check that unexpected opcodes are handled correctly (49)
I:resolver:check that EDNS client subnet with non-zeroed bits is handled correctly (50)
I:resolver:check that dig +subnet zeros address bits correctly (51)
I:resolver:check that SOA query returns data for delegation-only apex (52)
I:resolver:check that NS query returns data for delegation-only apex (54)
I:resolver:check that A query returns data for delegation-only A apex (55)
I:resolver:check that CDS query returns data for delegation-only apex (56)
I:resolver:check that AAAA query returns data for delegation-only AAAA apex (57)
I:resolver:check that DNSKEY query returns data for delegation-only apex (58)
I:resolver:check that CDNSKEY query returns data for delegation-only apex (59)
I:resolver:check that NXDOMAIN is returned for delegation-only non-apex A data (60)
I:resolver:check that NXDOMAIN is returned for delegation-only non-apex CDS data (61)
I:resolver:check that NXDOMAIN is returned for delegation-only non-apex AAAA data (62)
I:resolver:check that NXDOMAIN is returned for delegation-only non-apex CDNSKEY data (63)
I:resolver:check zero ttl not returned for learnt non zero ttl records (64)
I:resolver:check zero ttl is returned for learnt zero ttl records (65)
I:resolver:check that 'ad' in not returned in truncated answer with empty answer and authority sections to request with +ad (66)
I:resolver:check that 'ad' in not returned in truncated answer with empty answer and authority sections to request with +dnssec (67)
I:resolver:check that the resolver accepts a reply with empty question section with TC=1 and retries over TCP (68)
I:resolver:check that the resolver rejects a reply with empty question section with TC=0 (69)
I:resolver:checking SERVFAIL is returned when all authoritative servers return FORMERR (70)
I:resolver:check logged command line (71)
I:resolver:checking NXDOMAIN is returned when querying non existing domain in CH class (72)
I:resolver:exit status: 11
I:resolver:stopping servers
R:resolver:FAIL
E:resolver:2021-05-06T09:39:12+1000
FAIL: resolver
```June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)https://gitlab.isc.org/isc-projects/bind9/-/issues/2657Fedora 34 COPR packages missing/deprecated/delayed?2021-05-18T12:17:22ZpgndFedora 34 COPR packages missing/deprecated/delayed?We normally track/use ISC's Fedora builds @ COPR:
https://copr.fedorainfracloud.org/coprs/isc/bind/
Currently, on bind 9.16.x pkgs for F33
F34's officially released today.
F34 packages are missing from ISC's COPR builds.
F34 now pac...We normally track/use ISC's Fedora builds @ COPR:
https://copr.fedorainfracloud.org/coprs/isc/bind/
Currently, on bind 9.16.x pkgs for F33
F34's officially released today.
F34 packages are missing from ISC's COPR builds.
F34 now packages bind 9.16x directly @ distro.
Are ISC's builds planned to be enabled/built for F34? Or have current builds now 'moved' (back) to @distro?https://gitlab.isc.org/isc-projects/bind9/-/issues/2658Update ZONEMD now that RFC 8976 has been issued.2021-05-11T07:01:57ZMark AndrewsUpdate ZONEMD now that RFC 8976 has been issued.Changes to record format since -05
- Algorithm type moved location.
- Digest type 2 defined (SHA512).
- Reserved -> scheme
The algorithm location move makes the current fromwire / fromtext incompatible with record definition in RFC 8976.Changes to record format since -05
- Algorithm type moved location.
- Digest type 2 defined (SHA512).
- Reserved -> scheme
The algorithm location move makes the current fromwire / fromtext incompatible with record definition in RFC 8976.May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)https://gitlab.isc.org/isc-projects/bind9/-/issues/2659named shutdown hang in inline system test2021-09-02T09:47:48ZMichal Nowaknamed shutdown hang in inline system test`named` [hangs](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1670553) on ~"v9.16" (looks similar to https://gitlab.isc.org/isc-projects/bind9/-/issues/2057):
```
S:inline:2021-04-28T03:14:39+0000
T:inline:1:A
A:inline:System test in...`named` [hangs](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1670553) on ~"v9.16" (looks similar to https://gitlab.isc.org/isc-projects/bind9/-/issues/2057):
```
S:inline:2021-04-28T03:14:39+0000
T:inline:1:A
A:inline:System test inline
I:inline:PORTRANGE:8500 - 8599
I:inline:starting servers
I:inline:checking that an unsupported algorithm is not used for signing (1)
I:inline:checking that rrsigs are replaced with ksk only (2)
I:inline:checking that the zone is signed on initial transfer (3)
I:inline:checking expired signatures are updated on load (4)
I:inline:checking removal of private type record via 'rndc signing -clear' (5)
I:inline:checking private type was properly signed (6)
I:inline:checking removal of remaining private type record via 'rndc signing -clear all' (7)
I:inline:checking negative private type response was properly signed (8)
I:inline:checking that the record is added on the hidden primary (9)
I:inline:checking that update has been transferred and has been signed (10)
I:inline:checking YYYYMMDDVV (2011072400) serial on hidden primary (11)
I:inline:checking YYYYMMDDVV (2011072400) serial in signed zone (12)
I:inline:checking that the zone is signed on initial transfer, noixfr (13)
I:inline:checking that the record is added on the hidden primary, noixfr (14)
I:inline:checking that update has been transferred and has been signed, noixfr (15)
I:inline:checking YYYYMMDDVV (2011072400) serial on hidden primary, noixfr (16)
I:inline:checking YYYYMMDDVV (2011072400) serial in signed zone, noixfr (17)
I:inline:checking that the primary zone signed on initial load (18)
I:inline:checking removal of private type record via 'rndc signing -clear' (primary) (19)
I:inline:checking private type was properly signed (primary) (20)
I:inline:checking removal of remaining private type record via 'rndc signing -clear' (primary) (21)
I:inline:check adding of record to unsigned primary (22)
I:inline:ns3 zone reload queued
I:inline:check adding record fails when SOA serial not changed (23)
I:inline:ns3 server reload successful
I:inline:check adding record works after updating SOA serial (24)
I:inline:ns3 zone reload queued
I:inline:check the added record was properly signed (25)
I:inline:checking that the dynamic primary zone signed on initial load (26)
I:inline:checking primary zone that was updated while offline is correct (27)
I:inline:checking adding of record to unsigned primary using UPDATE (28)
I:inline:stop bump in the wire signer server (29)
I:inline:restart bump in the wire signer server (30)
I:inline:checking YYYYMMDDVV (2011072450) serial on hidden primary (31)
I:inline:checking YYYYMMDDVV (2011072450) serial in signed zone (32)
I:inline:checking YYYYMMDDVV (2011072450) serial on hidden primary, noixfr (33)
I:inline:checking YYYYMMDDVV (2011072450) serial in signed zone, noixfr (34)
I:inline:checking forwarded update on hidden primary (35)
I:inline:checking forwarded update on signed zone (36)
I:inline:checking forwarded update on hidden primary, noixfr (37)
I:inline:checking forwarded update on signed zone, noixfr (38)
I:inline:checking turning on of inline signing in a secondary zone via reload (39)
I:inline:ns5 server reload successful
I:inline:checking rndc freeze/thaw of dynamic inline zone no change (40)
I:inline:checking rndc freeze/thaw of dynamic inline zone (41)
I:inline:check added record freeze1.dynamic (42)
I:inline:checking rndc freeze/thaw of server (43)
I:inline:check added record freeze2.dynamic (44)
I:inline:check rndc reload allows reuse of inline-signing zones (45)
I:inline:ns3 server reload successful
I:inline:check rndc sync removes both signed and unsigned journals (46)
I:inline:checking that the retransfer record is added on the hidden primary (47)
I:inline:checking that the change has not been transferred due to notify (48)
I:inline:check rndc retransfer of a inline secondary zone works (49)
I:inline:check 'rndc signing -nsec3param' requests are queued for zones which are not loaded (50)
I:inline:check rndc retransfer of a inline nsec3 secondary retains nsec3 (51)
I:inline:check rndc retransfer of a inline nsec3 secondary does not trigger an infinite loop (52)
I:inline:stop bump in the wire signer server (53)
I:inline:update SOA record while stopped
I:inline:restart bump in the wire signer server (54)
I:inline:updates to SOA parameters other than serial while stopped are reflected in signed zone (55)
I:inline:check that reloading all zones does not cause zone maintenance to cease for inline-signed zones (56)
I:inline:ns3 server reload successful
I:inline:check that reloading errors prevent synchronization (57)
I:inline:ns3 server reload successful
I:inline:check inline-signing with an include file (58)
I:inline:ns3 server reload successful
I:inline:test add/del zone combinations (59)
I:inline:testing adding external keys to a inline zone (60)
I:inline:checking NSEC3RSASHA1
I:inline:testing imported key won't overwrite a private key (61)
I:inline:testing updating inline secure serial via 'rndc signing -serial' (62)
I:inline:testing updating inline secure serial via 'rndc signing -serial' with negative change (63)
I:inline:testing updating inline secure serial via 'rndc signing -serial' when frozen (64)
I:inline:testing updating dynamic serial via 'rndc signing -serial' (65)
I:inline:testing updating dynamic serial via 'rndc signing -serial' with negative change (66)
I:inline:testing updating dynamic serial via 'rndc signing -serial' when frozen (67)
I:inline:testing that inline signing works with inactive ZSK and active KSK (68)
I:inline:testing that inline signing works with inactive KSK and active ZSK (69)
I:inline:checking that changes to raw zone are applied to a previously unsigned secure zone (70)
I:inline:checking that changes to raw zone are not applied to a previously signed secure zone with no keys available (primary) (71)
I:inline:checking that backlogged changes to raw zone are applied after keys become available (primary) (72)
I:inline:checking that changes to raw zone are not applied to a previously signed secure zone with no keys available (secondary) (73)
I:inline:checking that backlogged changes to raw zone are applied after keys become available (secondary) (74)
I:inline:checking that records added from a journal are scheduled to be resigned (75)
I:inline:ns3 didn't die when sent a SIGTERM
I:inline:check that zonestatus reports 'type: primary' for an inline primary zone (76)
I:inline:check that zonestatus reports 'type: secondary' for an inline secondary zone (77)
I:inline:checking reload of touched inline zones (78)
I:inline: pre-reload 'next key event'
I:inline: found: 16/16
I:inline: touch and reload
I:inline:ns3 server reload successful
I:inline: post-reload 'next key event'
I:inline: found: 16/16
I:inline:exit status: 0
I:inline:stopping servers
I:inline:Core dump(s) found: inline/ns3/core.18034
R:inline:FAIL
D:inline:backtrace from inline/ns3/core.18034:
D:inline:--------------------------------------------------------------------------------
D:inline:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D inline-ns3 -X named.lock -m'.
D:inline:Program terminated with signal SIGABRT, Aborted.
D:inline:#0 0x00007f5877aeb495 in __GI___pthread_timedjoin_ex (threadid=140017740494592, thread_return=0x0, abstime=0x0, block=<optimized out>) at pthread_join_common.c:89
D:inline:[Current thread is 1 (Thread 0x7f5875369440 (LWP 18034))]
D:inline:#0 0x00007f5877aeb495 in __GI___pthread_timedjoin_ex (threadid=140017740494592, thread_return=0x0, abstime=0x0, block=<optimized out>) at pthread_join_common.c:89
D:inline:#1 0x0000000000441552 in pthread_join ()
D:inline:#2 0x00007f5877fc0938 in isc_thread_join (thread=140017740495312, result=result@entry=0x0) at thread.c:92
D:inline:#3 0x00007f5877fa4150 in isc_taskmgr_destroy (managerp=0xfa8e90 <named_g_taskmgr>) at task.c:1512
D:inline:#4 0x00000000004dd202 in destroy_managers () at ./main.c:981
D:inline:#5 0x00000000004db9f5 in cleanup () at ./main.c:1357
D:inline:#6 0x00000000004da369 in main (argc=<optimized out>, argv=<optimized out>) at ./main.c:1615
D:inline:--------------------------------------------------------------------------------
D:inline:full backtrace from inline/ns3/core.18034 saved in inline/ns3/core.18034-backtrace.txt
D:inline:core dump inline/ns3/core.18034 archived as inline/ns3/core.18034.gz
E:inline:2021-04-28T03:17:52+0000
```
Full backtrace: [core.18034-backtrace.txt](/uploads/3a4ee8563e679fc3512a073d9ebbf899/core.18034-backtrace.txt)
Core file: [core.18034.gz](/uploads/c9eaa2c6522800ddd94521129e7ee0c1/core.18034.gz)September 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/2660named shutdown hang in notify system test2021-09-02T09:47:29ZMichal Nowaknamed shutdown hang in notify system testJob [#1670803](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1670803) produced a shutdown hang for 99a4f6119a99e9b15c33488940c1f1d4f356239f on `main`.
```
S:notify:2021-04-28T04:21:42+0000
T:notify:1:A
A:notify:System test notify
I:n...Job [#1670803](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1670803) produced a shutdown hang for 99a4f6119a99e9b15c33488940c1f1d4f356239f on `main`.
```
S:notify:2021-04-28T04:21:42+0000
T:notify:1:A
A:notify:System test notify
I:notify:PORTS:23243,23244,23245,23246,23247,23248,23249,23250,23251,23252,23253,23254,23255
I:notify:starting servers
I:notify:checking initial status (1)
I:notify:checking startup notify rate limit (2)
I:notify:reloading with example2 using HUP and waiting up to 45 seconds
I:notify:checking notify message was logged (3)
I:notify:checking example2 loaded (4)
I:notify:checking example2 contents have been transferred after HUP reload (5)
I:notify:stopping master and restarting with example4 then waiting up to 45 seconds
I:notify:checking notify message was logged (6)
I:notify:checking example4 loaded (7)
I:notify:checking example4 contents have been transferred after restart (8)
I:notify:checking notify to alternate port with master inheritance (9)
I:notify:checking notify to multiple views using tsig (10)
I:notify:exit status: 0
I:notify:stopping servers
I:notify:ns2 didn't die when sent a SIGTERM
I:notify:stopping servers failed
I:notify:Core dump(s) found: notify/ns2/core.15610
D:notify:backtrace from notify/ns2/core.15610:
D:notify:--------------------------------------------------------------------------------
D:notify:Core was generated by `/builds/isc-projects/bind9/bind-9.17.11/bin/named/.libs/named -D notify-ns2 -X'.
D:notify:Program terminated with signal SIGABRT, Aborted.
D:notify:#0 0x00007f41a3e05720 in __GI___nanosleep (requested_time=requested_time@entry=0x7ffd666405b0, remaining=remaining@entry=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
D:notify:[Current thread is 1 (Thread 0x7f41a19b8880 (LWP 15610))]
D:notify:#0 0x00007f41a3e05720 in __GI___nanosleep (requested_time=requested_time@entry=0x7ffd666405b0, remaining=remaining@entry=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
D:notify:#1 0x00007f41a3e30874 in usleep (useconds=useconds@entry=10000) at ../sysdeps/posix/usleep.c:32
D:notify:#2 0x00007f41a4a3607a in isc_nm_destroy (mgr0=0x561d43970f60 <named_g_nm>) at netmgr/netmgr.c:537
D:notify:#3 0x0000561d43902a22 in destroy_managers () at main.c:1014
D:notify:#4 cleanup () at main.c:1350
D:notify:#5 main (argc=<optimized out>, argv=<optimized out>) at main.c:1598
D:notify:--------------------------------------------------------------------------------
D:notify:full backtrace from notify/ns2/core.15610 saved in notify/ns2/core.15610-backtrace.txt
D:notify:core dump notify/ns2/core.15610 archived as notify/ns2/core.15610.gz
R:notify:FAIL
E:notify:2021-04-28T04:23:12+0000
FAIL notify (exit status: 1)
```
Full backtrace: [core.15610-backtrace.txt](/uploads/7c39760a5a0f9c5526dbf0b208566deb/core.15610-backtrace.txt)
Core file: [core.15610.gz](/uploads/a68c6b374a259bd637d91095f313bd08/core.15610.gz)October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)https://gitlab.isc.org/isc-projects/bind9/-/issues/2661Release Checklist for BIND 9.11.32, BIND 9.11.32-S1, BIND 9.16.16, BIND 9.16....2021-05-20T12:46:04ZMichał KępieńRelease Checklist for BIND 9.11.32, BIND 9.11.32-S1, BIND 9.16.16, BIND 9.16.16-S1, 9.17.13## Release Schedule
**Code Freeze:** Wednesday, May 5th, 2021
**Tagging Deadline:** Monday, May 10th, 2021
**Public Release:** Wednesday, May 19th, 2021
## Documentation Review Links
**Closed issues assigned to the milestone without...## Release Schedule
**Code Freeze:** Wednesday, May 5th, 2021
**Tagging Deadline:** Monday, May 10th, 2021
**Public Release:** Wednesday, May 19th, 2021
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.17.13](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=May%202021%20(9.11.32%2C%209.11.32-S1%2C%209.16.16%2C%209.16.16-S1%2C%209.17.13)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.17)
- [9.16.16](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=May%202021%20(9.11.32%2C%209.11.32-S1%2C%209.16.16%2C%209.16.16-S1%2C%209.17.13)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.16)
- [9.11.32](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=May%202021%20(9.11.32%2C%209.11.32-S1%2C%209.16.16%2C%209.16.16-S1%2C%209.17.13)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.11)
**Merge requests merged into the milestone without a release note:**
- [9.17.13](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=May%202021%20(9.11.32%2C%209.11.32-S1%2C%209.16.16%2C%209.16.16-S1%2C%209.17.13)¬[label_name][]=Release%20Notes&target_branch=main)
- [9.16.16](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=May%202021%20(9.11.32%2C%209.11.32-S1%2C%209.16.16%2C%209.16.16-S1%2C%209.17.13)¬[label_name][]=Release%20Notes&target_branch=v9_16)
- [9.11.32](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=May%202021%20(9.11.32%2C%209.11.32-S1%2C%209.16.16%2C%209.16.16-S1%2C%209.17.13)¬[label_name][]=Release%20Notes&target_branch=v9_11)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.17.13](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=May%202021%20(9.11.32%2C%209.11.32-S1%2C%209.16.16%2C%209.16.16-S1%2C%209.17.13)&label_name[]=No%20CHANGES&target_branch=main)
- [9.16.16](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=May%202021%20(9.11.32%2C%209.11.32-S1%2C%209.16.16%2C%209.16.16-S1%2C%209.17.13)&label_name[]=No%20CHANGES&target_branch=v9_16)
- [9.11.32](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=May%202021%20(9.11.32%2C%209.11.32-S1%2C%209.16.16%2C%209.16.16-S1%2C%209.17.13)&label_name[]=No%20CHANGES&target_branch=v9_11)
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Inform Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform.
- [x] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
- [x] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [x] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only).
- [x] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported.
### Before the Tagging Deadline
- [x] ***(QA)*** Look for outstanding documentation issues (e.g. `CHANGES` mistakes) and address them if any are found.
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
- [x] ***(QA)*** Update API files for libraries with new version information.
- [x] ***(QA)*** Change software version and library versions in `configure.ac` (new major release only).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
- [x] ***(QA)*** Update `CHANGES`.
- [x] ***(QA)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ***(QA)*** Update `README.md`.
- [x] ***(QA)*** Update `version`.
- [x] ***(QA)*** Build documentation on `docs.isc.org`.
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Tag the releases in the private repository (`git tag -s -m "BIND 9.x.y" v9_x_y`).
### Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Verify GitLab CI results for the tags created and prepare a QA report for the releases to be published.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again.
- [x] ***(Support)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages.
- [x] ***(QA)*** Notify Support that the releases have been prepared.
- [x] ***(Support)*** Send out ASNs (if applicable).
### On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *bind-announce*.
- [x] ***(Support)*** Write email to *bind-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription Edition (update the -S edition delivery tickets, even if those links were provided earlier via an ASN ticket).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages.
- [x] ***(QA)*** Build public packages (`*.deb`, RPMs).
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(QA)*** Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made.
- [x] ***(Marketing)*** Post short note to Twitter.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(QA)*** Ensure all new tags are annotated and signed.
- [x] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Merge the automatically prepared `prep 9.x.y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_x`).
- [x] ***(QA)*** For each maintained branch, update the `BIND_BASELINE_VERSION` variable for the `abi-check` job in `.gitlab-ci.yml` to the latest published BIND version tag for a given branch.
- [x] ***(QA)*** Prepare empty release notes for the next set of releases.
- [x] ***(QA)*** Sanitize all confidential issues assigned to the release milestone and make them public.
- [x] ***(QA)*** Update QA tools used in GitLab CI (e.g. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)Michał KępieńMichał Kępień2021-05-19https://gitlab.isc.org/isc-projects/bind9/-/issues/2662System tests cleaned even when SYSTEMTEST_NO_CLEAN=12021-05-24T15:17:04ZBrian ConrySystem tests cleaned even when SYSTEMTEST_NO_CLEAN=1Setting `SYSTEMTEST_NO_CLEAN=1` does not preserve artifacts from a test run using `run.sh`.
Observed on main 99a4f6119a99e9b15c33488940c1f1d4f356239fSetting `SYSTEMTEST_NO_CLEAN=1` does not preserve artifacts from a test run using `run.sh`.
Observed on main 99a4f6119a99e9b15c33488940c1f1d4f356239fJune 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Brian ConryBrian Conryhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2663Add memory context size-specific stats to stats channel when configured with ...2023-01-24T11:19:41ZBrian ConryAdd memory context size-specific stats to stats channel when configured with --enable-developerTo aid in some investigative/optimization efforts. This will add a lot of data to the stats channel output and isn't something that would be of use to a typical operator.To aid in some investigative/optimization efforts. This will add a lot of data to the stats channel output and isn't something that would be of use to a typical operator.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2664Data race in fwrite, memcpy, and free in dnstap_test with atomics disabled2021-11-02T15:49:26ZMichal NowakData race in fwrite, memcpy, and free in dnstap_test with atomics disabled[GCC](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1672799) and [Clang](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1672800) report TSAN errors on ~"v9.11" with dnstap enabled and atomics disabled in the `dnstap_test`. These err...[GCC](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1672799) and [Clang](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1672800) report TSAN errors on ~"v9.11" with dnstap enabled and atomics disabled in the `dnstap_test`. These errors should not come from `libfstrm.so` as these are suppressed. Before !4618 gets integrated see the `mnowak/configure-with-enable-dnstap-by-default-v9_11` branch and set `CI_REGISTRY_IMAGE=registry.gitlab.isc.org/isc-projects/images/bind9-staging`.
```
WARNING: ThreadSanitizer: data race
Read of size 8 at 0x000000000001 by thread T1:
#0 memcpy <null>
#1 <null> <null>
Previous write of size 8 at 0x000000000001 by main thread:
#0 memcpy <null>
#1 <null> <null>
#2 dns_dt_send lib/dns/dnstap.c:780:3
#3 send_test lib/dns/tests/dnstap_test.c:259:3
#4 <null> <null>
#5 __libc_start_main /build/glibc-vjB4T2/glibc-2.28/csu/../csu/libc-start.c:308:16
Location is heap block of size 16384 at 0x000000000009 allocated by main thread:
#0 calloc <null>
#1 <null> <null>
#2 send_test lib/dns/tests/dnstap_test.c:176:11
#3 <null> <null>
#4 __libc_start_main /build/glibc-vjB4T2/glibc-2.28/csu/../csu/libc-start.c:308:16
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 fstrm_iothr_init <null>
#2 send_test lib/dns/tests/dnstap_test.c:176:11
#3 <null> <null>
#4 __libc_start_main /build/glibc-vjB4T2/glibc-2.28/csu/../csu/libc-start.c:308:16
SUMMARY: ThreadSanitizer: data race in memcpy
```
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 free <null>
#1 <null> <null>
Previous write of size 8 at 0x000000000001 by main thread:
#0 malloc <null>
#1 pack_dt lib/dns/dnstap.c:543:14
#2 dns_dt_send lib/dns/dnstap.c:779:6
#3 send_test lib/dns/tests/dnstap_test.c:257:3
#4 <null> <null>
#5 __libc_start_main /build/glibc-vjB4T2/glibc-2.28/csu/../csu/libc-start.c:308:16
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 fstrm_iothr_init <null>
#2 send_test lib/dns/tests/dnstap_test.c:176:11
#3 <null> <null>
#4 __libc_start_main /build/glibc-vjB4T2/glibc-2.28/csu/../csu/libc-start.c:308:16
SUMMARY: ThreadSanitizer: data race in free
```
```
WARNING: ThreadSanitizer: data race
Read of size 8 at 0x000000000001 by thread T1:
#0 fwrite <null>
#1 <null> <null>
Previous write of size 8 at 0x000000000001 by main thread:
#0 malloc <null>
#1 pack_dt lib/dns/dnstap.c:543:14
#2 dns_dt_send lib/dns/dnstap.c:779:6
#3 send_test lib/dns/tests/dnstap_test.c:254:3
#4 <null> <null>
#5 __libc_start_main /build/glibc-vjB4T2/glibc-2.28/csu/../csu/libc-start.c:308:16
Location is heap block of size 256 at 0x000000000001 allocated by main thread:
#0 malloc <null>
#1 pack_dt lib/dns/dnstap.c:543:14
#2 dns_dt_send lib/dns/dnstap.c:779:6
#3 send_test lib/dns/tests/dnstap_test.c:254:3
#4 <null> <null>
#5 __libc_start_main /build/glibc-vjB4T2/glibc-2.28/csu/../csu/libc-start.c:308:16
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 fstrm_iothr_init <null>
#2 send_test lib/dns/tests/dnstap_test.c:176:11
#3 <null> <null>
#4 __libc_start_main /build/glibc-vjB4T2/glibc-2.28/csu/../csu/libc-start.c:308:16
SUMMARY: ThreadSanitizer: data race in fwrite
```
I'll just disable dnstap in `unit:gcc:tsan:noatomics` and `unit:clang:tsan:noatomics` if we decide not to fix these errors given the phase ~"v9.11" is in.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)https://gitlab.isc.org/isc-projects/bind9/-/issues/2665Resolver does not appear to attempt qname minimization after first resolution.2021-11-17T06:31:28ZWil KnollResolver does not appear to attempt qname minimization after first resolution.9.16.13-Ubuntu
Installed from ppa:isc/bind
Afternoon. We are trying to validate that Bind is following qname minimization using the test provided by NLnet Labs. Their test is a TXT record that is hosted at a.b.qnamemin-test.internet.nl...9.16.13-Ubuntu
Installed from ppa:isc/bind
Afternoon. We are trying to validate that Bind is following qname minimization using the test provided by NLnet Labs. Their test is a TXT record that is hosted at a.b.qnamemin-test.internet.nl. We are not sure if we are misunderstanding what qname-minimization should be doing or if this is the intended actions of the resolver.
This test was run on a clean ubuntu 18.04VM with the defaults for bind beyond having logging to file. qname-minimization defaults to "relaxed". We have also tried this with "strict" set but the output below is with the default. Apology for me editing the debug output, and I can provide full log if wanted. But I think I kept what was important here.
The first request for this TXT record follows the proper minimization path.
```
27-Apr-2021 20:57:43.948 resolver: debug 1: fetch: a.b.qnamemin-test.internet.nl/TXT
27-Apr-2021 20:57:43.948 resolver: debug 10: log_ns_ttl: fctx 0x7ff8a4015cd0: fctx_create: a.b.qnamemin-test.internet.nl (in '.'?): 1 518365
27-Apr-2021 20:57:43.948 resolver: debug 5: QNAME minimization - minimized, qmintype 2 qminname nl
27-Apr-2021 20:57:43.948 resolver: debug 1: fetch: nl/NS
27-Apr-2021 20:57:44.184 resolver: debug 1: fetch: nl/DNSKEY
27-Apr-2021 20:57:44.280 resolver: debug 1: fetch: internet.nl/NS
27-Apr-2021 20:57:44.432 resolver: debug 1: fetch: internet.nl/DNSKEY
27-Apr-2021 20:57:44.604 resolver: debug 1: fetch: qnamemin-test.internet.nl/NS
27-Apr-2021 20:57:44.868 resolver: debug 1: fetch: qnamemin-test.internet.nl/DS
27-Apr-2021 20:57:44.960 resolver: debug 1: fetch: b.qnamemin-test.internet.nl/NS
```
Part of the logic of the NLnet Labs test is that the NS query for b.qnamemin-test.internet.nl will send you to a different server for the final record than if you request the non-minimized QNAME. The NS record returned sends us to 185.49.140.63 for our TXT record lookup. Both this NS record, and the next TXT record with the "HOORAY" message have 10 second TTLs.
```
27-Apr-2021 20:57:44.960 resolver: debug 10: log_ns_ttl: fctx 0x7ff89802c180: fctx_create: b.qnamemin-test.internet.nl (in 'qnamemin-test.internet.nl'?): 1 11
27-Apr-2021 20:57:45.128 resolver: debug 10: received packet from 185.49.140.61#53
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34670
;; flags: qr; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;b.qnamemin-test.internet.nl. IN NS
;; AUTHORITY SECTION:
;b.qnamemin-test.internet.nl. 10 IN NS ns.b.qnamemin-test.internet.nl.
;; ADDITIONAL SECTION:
;ns.b.qnamemin-test.internet.nl. 10 IN A 185.49.140.63
;ns.b.qnamemin-test.internet.nl. 10 IN AAAA 2a04:b900::8:0:0:63
27-Apr-2021 20:57:45.296 resolver: debug 3: fctx 0x7ff8a4015cd0(a.b.qnamemin-test.internet.nl/TXT): createfind for 127.0.0.1#34294/56587 - success
27-Apr-2021 20:57:45.468 resolver: debug 10: received packet from 185.49.140.63#53
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57792
;; flags: qr aa; QUESTION: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 4c8bb7557733e1ae0100000060887ac9de1433595eeeb769
;; QUESTION SECTION:
;a.b.qnamemin-test.internet.nl. IN TXT
;; ANSWER SECTION:
;a.b.qnamemin-test.internet.nl. 10 IN TXT "HOORAY - QNAME minimisation is enabled on your resolver :)!"
;; AUTHORITY SECTION:
;a.b.qnamemin-test.internet.nl. 10 IN NS ns.a.b.qnamemin-test.internet.nl.
;; ADDITIONAL SECTION:
;ns.a.b.qnamemin-test.internet.nl. 10 IN A 185.49.140.63
;ns.a.b.qnamemin-test.internet.nl. 10 IN AAAA 2a04:b900::8:0:0:63
```
While in cache, BIND serves the "HOORAY" TXT record. When that record, and the b.qnamemin-test.internet.nl NS record's TTL expires however, it appears that BIND does not attempt minimization on the next request.
```
27-Apr-2021 20:57:45.468 database: debug 1: delete_node(): 0x7ff8af6b18d0 a.b.qnamemin-test.internet.nl (bucket 27)
27-Apr-2021 20:57:45.468 database: debug 1: delete_node(): 0x7ff8af6b18d0 a.b.qnamemin-test.internet.nl (bucket 27)
27-Apr-2021 20:57:45.468 database: debug 1: delete_node(): 0x7ff8af6b18d0 ns.a.b.qnamemin-test.internet.nl (bucket 5)
27-Apr-2021 20:57:59.981 resolver: debug 1: fetch: a.b.qnamemin-test.internet.nl/TXT
27-Apr-2021 20:57:59.981 resolver: debug 10: log_ns_ttl: fctx 0x7ff8a0002cb0: fctx_create: a.b.qnamemin-test.internet.nl (in 'internet.nl'?): 1 3585
27-Apr-2021 20:57:59.981 resolver: debug 5: QNAME minimization - minimized, qmintype 2 qminname qnamemin-test.internet.nl
```
This looks proper so far, the largest suffix we have for the QNAME in cache is internet.nl, which has a 1 hour TTL. So we do the next step, requesting the NS for qnamemin-test.internet.nl.
```
27-Apr-2021 20:58:00.157 resolver: debug 10: log_ns_ttl: fctx 0x7ff89802c180: rctx_answer_none: qnamemin-test.internet.nl (in 'internet.nl'?): 1 3585
27-Apr-2021 20:58:00.157 resolver: debug 10: log_ns_ttl: fctx 0x7ff89802c180: DELEGATION: qnamemin-test.internet.nl (in 'qnamemin-test.internet.nl'?): 0 3585
27-Apr-2021 20:58:00.157 database: debug 5: dns_adb_destroyfind on find 0x7ff8aeda7210
27-Apr-2021 20:58:00.157 database: debug 5: dns_adb_destroyfind on find 0x7ff8aedaed10
27-Apr-2021 20:58:00.157 database: debug 5: expiring v4 for name 0x7ff8aedb13a0
27-Apr-2021 20:58:00.157 database: debug 5: dns_adb_createfind: found A for name ns.qnamemin-test.internet.nl (0x7ff8aedb13a0) in db
27-Apr-2021 20:58:00.157 resolver: debug 3: fctx 0x7ff89802c180(qnamemin-test.internet.nl/NS): createfind for <unknown>/0 - success
27-Apr-2021 20:58:00.329 resolver: debug 10: received packet from 185.49.140.61#53
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13741
;; flags: qr aa; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;qnamemin-test.internet.nl. IN NS
;; ANSWER SECTION:
;qnamemin-test.internet.nl. 10 IN NS ns.qnamemin-test.internet.nl.
;; ADDITIONAL SECTION:
;ns.qnamemin-test.internet.nl. 10 IN A 185.49.140.61
;ns.qnamemin-test.internet.nl. 10 IN AAAA 2a04:b900::8:0:0:61
```
The resolver's next step should be to query for the NS of b.qnamein-test.internet.nl. That's where we would be sent to the server hosting the "HOORAY" TXT record, on 185.49.140.63.
Instead, BIND asks the TXT record a.b.qnamemin-test.internet.nl from 185.49.140.61.
```
27-Apr-2021 20:58:00.329 resolver: debug 5: QNAME minimization - not minimized, qmintype 16 qminname a.b.qnamemin-test.internet.nl
27-Apr-2021 20:58:00.329 database: debug 5: dns_adb_destroyfind on find 0x7ff8aedaef10
27-Apr-2021 20:58:00.329 database: debug 5: dns_adb_destroyfind on find 0x7ff8aeda7110
27-Apr-2021 20:58:00.329 resolver: debug 3: fctx 0x7ff8a0002cb0(a.b.qnamemin-test.internet.nl/TXT): createfind for 127.0.0.1#35679/64023 - success
27-Apr-2021 20:58:00.329 database: debug 5: dns_adb_destroyfind on find 0x7ff8aedaed10
27-Apr-2021 20:58:00.497 resolver: debug 10: received packet from 185.49.140.61#53
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38154
;; flags: qr aa; QUESTION: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;a.b.qnamemin-test.internet.nl. IN TXT
;; ANSWER SECTION:
;a.b.qnamemin-test.internet.nl. 10 IN TXT "NO - QNAME minimisation is NOT enabled on your resolver :("
;; AUTHORITY SECTION:
;a.b.qnamemin-test.internet.nl. 10 IN NS ns.a.b.qnamemin-test.internet.nl.
;; ADDITIONAL SECTION:
;ns.a.b.qnamemin-test.internet.nl. 10 IN A 185.49.140.61
;ns.a.b.qnamemin-test.internet.nl. 10 IN AAAA 2a04:b900::8:0:0:61
```
It's that last step there that we are wondering about. Our understanding is that bind should have requested the NS of b.qnamemin-test.internet.nl, not the TXT for a.b.qnamemin-test.internet.nl.
This has the result where the qnamemin-test appears to be successful once, and then fails after the first ten seconds. we've waited for an hour to let the internet.nl record expire after that to see if that changed things, but we sill kept asking the wrong server for that TXT record if we are following what we expected qname minimization to do.
Please let us know if we've mis-understood this, or if we can provide anything else to clear this up.
Cheers,
WilSeptember 2021 (9.16.21, 9.16.21-S1, 9.17.18)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2666Document test only options2023-11-02T16:26:06ZMatthijs Mekkingmatthijs@isc.orgDocument test only optionsFrom the following discussion from !4925 should be addressed:
- [ ] @matthijs started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4925#note_209969): (+2 comments)
> I am not too fond on having `too-ma...From the following discussion from !4925 should be addressed:
- [ ] @matthijs started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4925#note_209969): (+2 comments)
> I am not too fond on having `too-many`. I would prefer an option that would disable the iteration value checking.
>
> Either way, this needs to be documented. Probably the manfile is the best place for it.
This option should be documented. There are more test options that should be documented.
1. Document `dnssec-signzone -H too-many`
2. Find other undocumented test options
3. Document those.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2667Configuration issues on Solaris 11.42021-10-11T19:21:38ZStacey MarshallConfiguration issues on Solaris 11.4### Summary
`gmake configure` for BIND 9.11.31 failed to complete cleanly without modification to configure.ac.
In addition the summary failed to display compiler version.
### BIND version used
9.11.31
### Steps to reproduce
```
$ g...### Summary
`gmake configure` for BIND 9.11.31 failed to complete cleanly without modification to configure.ac.
In addition the summary failed to display compiler version.
### BIND version used
9.11.31
### Steps to reproduce
```
$ gmake configure
(/bin/rm -f -rf /builds/bind/components/bind/build/amd64 ; /bin/mkdir -p /builds/bind/components/bind/build/amd64)
(cd /builds/bind/components/bind/build/amd64 ; /usr/bin/env \
CONFIG_SHELL="/bin/bash" PKG_CONFIG_PATH="/usr/lib/amd64/pkgconfig" \
CC="/opt/developerstudio12.6/bin/cc"
CXX="/opt/developerstudio12.6/bin/CC" \
PATH="/usr/bin/amd64:/usr/bin:/usr/gnu/bin" \
CC_FOR_BUILD="/opt/developerstudio12.6/bin/cc -m64" \
CXX_FOR_BUILD="/opt/developerstudio12.6/bin/CC -m64" \
CPPFLAGS="-m64" "ac_cv_func_realloc_0_nonnull=yes" \
"NM=/usr/gnu/bin/nm" INTLTOOL_PERL="/usr/perl5/5.22/bin/perl"
CFLAGS="-m64 -xO4 -g -preserve_argvalues=complete -xchip=generic -Ui386 -U__i386 -xregs=no%frameptr -mt" \
CXXFLAGS="-norunpath -m64 -xO4 -g -preserve_argvalues=complete -xchip=generic -Ui386 -U__i386 -xregs=no%frameptr" \
LDFLAGS="" http_proxy= https_proxy= ftp_proxy= /bin/bash \
/builds/bind/components/bind/bind-9.11.31/configure --prefix=/usr \
--mandir=/usr/share/man --bindir=/usr/bin --sbindir=/usr/sbin --libdir=/usr/lib/dns/amd64 \
--enable-full-report --with-python=/usr/bin/python3.7 --with-libtool --with-openssl=/usr \
--with-pkcs11=/usr/lib/amd64/libpkcs11.so.1 --with-libxml2=/usr --enable-threads \
--enable-devpoll --enable-fixed-rrset --with-tuning=large --enable-largefile \
--sysconfdir=/etc --localstatedir=/var --with-randomdev=/dev/random \
--with-gssapi=krb5-config --with-docbook-xsl=/usr/share/sgml/docbook
--with-python-install-dir=/usr/lib/python3.7/vendor-packages)
```
### What is the current *bug* behavior?
Configure fails to link with GSSAPI
### What is the expected *correct* behavior?
Configuration summary shown.
### Relevant configuration files
### Relevant logs and/or screenshots
```
checking for gcc... (cached) /opt/developerstudio12.6/bin/cc
checking whether we are using the GNU C compiler... (cached) no
checking whether /opt/developerstudio12.6/bin/cc accepts -g... (cached) yes
checking for /opt/developerstudio12.6/bin/cc option to accept ISO C89... (cached) none needed
checking for /opt/developerstudio12.6/bin/cc option to accept ISO C99... none needed
checking for ANSI C header files... (cached) yes
checking for fcntl.h... yes
checking for regex.h... yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking for sys/mman.h... yes
checking for sys/sockio.h... yes
checking for sys/select.h... yes
checking for sys/param.h... yes
checking for sys/sysctl.h... no
checking for net/if6.h... no
checking for sys/socket.h... yes
checking for net/route.h... yes
checking for linux/netlink.h... no
checking for linux/rtnetlink.h... no
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for working volatile... yes
checking for sysctlbyname... no
checking for flexible array members... yes
checking for mmap... yes
checking for seteuid... yes
checking for setresuid... no
checking for setegid... yes
checking for setresgid... no
checking for ftello... yes
checking for fseeko... yes
checking for static inline breakage... no
checking for size_t... yes
checking for ssize_t... yes
checking for uintptr_t... yes
checking for socklen_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking for long long... yes
checking for uname... yes
checking for GCC noreturn attribute... yes
checking for struct lifconf... yes
checking for kqueue... no
checking epoll support... no
checking sys/devpoll.h usability... yes
checking sys/devpoll.h presence... yes
checking for sys/devpoll.h... yes
checking devpoll.h usability... yes
checking devpoll.h presence... yes
checking for devpoll.h... yes
checking if unistd.h or sys/types.h defines fd_set... yes
checking whether byte ordering is bigendian... no
checking for GSSAPI library... trying krb5-config
checking for krb5-config... /usr/bin/krb5-config
checking gssapi.h usability... yes
checking gssapi.h presence... yes
checking for gssapi.h... yes
checking gssapi/gssapi.h usability... yes
checking gssapi/gssapi.h presence... yes
checking for gssapi/gssapi.h... yes
checking krb5/krb5.h usability... yes
checking krb5/krb5.h presence... yes
checking for krb5/krb5.h... yes
checking krb5.h usability... yes
checking krb5.h presence... yes
checking for krb5.h... yes
checking krb5-config linking as -lkrb5 -lk5crypto -lcom_err... krb5-config: could not determine proper GSSAPI linkage
checking for GSSAPI library, non krb5-config method... looking in /usr/lib
checking for gssapi.h... (cached) yes
checking for gssapi/gssapi.h... (cached) yes
checking gssapi_krb5.h usability... no
checking gssapi_krb5.h presence... no
checking for gssapi_krb5.h... no
checking gssapi/gssapi_krb5.h usability... no
checking gssapi/gssapi_krb5.h presence... no
checking for gssapi/gssapi_krb5.h... no
checking for krb5.h... (cached) yes
checking for krb5/krb5.h... (cached) yes
checking kerberosv5/krb5.h usability... no
checking kerberosv5/krb5.h presence... no
checking for kerberosv5/krb5.h... no
checking linking as -lgssapi_krb5... no
checking linking as -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err... no
checking linking as -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv... no
checking linking as -lgssapi... no
checking linking as -lgssapi -lkrb5 -ldes -lcrypt -lasn1 -lroken -lcom_err... no
checking linking as -lgssapi -lkrb5 -lcrypto -lcrypt -lasn1 -lroken -lcom_err... no
checking linking as -lgssapi -lkrb5 -lgssapi_krb5 -lcrypto -lcrypt -lasn1 -lroken -lcom_err... no
checking linking as -lgssapi -lkrb5 -lhx509 -lcrypto -lcrypt -lasn1 -lroken -lcom_err... no
checking linking as -lgss -lkrb5... no
configure: error: could not determine proper GSSAPI linkage
gmake: *** [/builds/bind/make-rules/configure.mk:176: /builds/bind/components/bind/build/amd64/.configured] Error 1
```
The compiler version issue:
```
-------------------------------------------------------------------------------
Compiler: /opt/developerstudio12.6/bin/cc
cc: Warning: Option --version passed to ld, if ld is invoked, ignored otherwise
usage: cc [ options ] files. Use 'cc -flags' for details
===============================================================================
```
### Possible fixes
Patch being applied to release 9.11.31
```
Addresses several issues with configuration for Solaris build.
* krb5-config was not providing correct arguments, instead
it was printing the krb5 options!
* When using Studio compiler the summary did not report the version.
* The '-mt' option to Studio compiler was only ever for CFLAGS, not libs.
Either-way it has not been needed for some time now.
Patch will be passed back to ISC.
--- a/configure.ac 2021-04-19 07:10:40.000000000 -0700
+++ b/configure.ac 2021-04-28 09:41:01.159252398 -0700
@@ -921,8 +921,16 @@
else
KRB5_CONFIG="$use_gssapi"
fi
- gssapi_cflags=`$KRB5_CONFIG --cflags gssapi krb5`
- gssapi_libs=`$KRB5_CONFIG --libs gssapi krb5`
+ case "$host_os" in
+ solaris*)
+ gssapi_cflags=`$KRB5_CONFIG --cflags gssapi`
+ gssapi_libs=`$KRB5_CONFIG --libs gssapi`
+ ;;
+ *)
+ gssapi_cflags=`$KRB5_CONFIG --cflags gssapi krb5`
+ gssapi_libs=`$KRB5_CONFIG --libs gssapi krb5`
+ ;;
+ esac
saved_cppflags="$CPPFLAGS"
CPPFLAGS="$gssapi_cflags $CPPFLAGS"
AC_CHECK_HEADERS(gssapi.h gssapi/gssapi.h,
@@ -1282,7 +1290,7 @@
CCNOOPT="$CCNOOPT -pthread"
;;
*-solaris*)
- CC="$CC -mt"
+ CC="$CC"
CCOPT="$CCOPT -mt"
CCNOOPT="$CCNOOPT -mt"
;;
@@ -5726,8 +5734,17 @@
echo " localstatedir: $localstatedir"
echo "-------------------------------------------------------------------------------"
echo "Compiler: $CC"
- $CC --version 2>&1 | sed 's/^/ /'
-
+ if test "yes" == "$GCC"; then
+ $CC --version 2>&1 | sed 's/^/ /'
+ else
+ case "$host_os" in
+ solaris*)
+ $CC -V 2>&1 | sed 's/^/ /'
+ ;;
+ *)
+ $CC --version 2>&1 | sed 's/^/ /'
+ esac
+ fi
if test "X$ac_unrecognized_opts" != "X"; then
echo "Unrecognized options:"
echo " $ac_unrecognized_opts"
```July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)https://gitlab.isc.org/isc-projects/bind9/-/issues/2668Handle Net::DNS versions that don't support NSEC3PARAM2021-05-11T07:02:49ZMark AndrewsHandle Net::DNS versions that don't support NSEC3PARAMxenial builds where failing on lack of NSEC3PARAM support in Net::DNS.xenial builds where failing on lack of NSEC3PARAM support in Net::DNS.May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)https://gitlab.isc.org/isc-projects/bind9/-/issues/26699.16.15: dns_journal_compact failed: unexpected error2021-07-27T13:15:59ZThomas Amgarten9.16.15: dns_journal_compact failed: unexpected error<!--
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
After upgrading one slave to 9.16.15, named reports errors on a couple of zones:
```
03-May-2021 02:10:41.333 general: error: slave/pluz.ch.hosts.jnw: journal file corrupt: expected serial 2021042500, got 2021050200
03-May-2021 02:10:41.333 general: error: zone pluz.ch/IN: dns_journal_compact failed: unexpected error
```
On a updated resolver, the same error for the "managed-keys.bind"-file:
```
30-Apr-2021 14:09:19.611 general: error: managed-keys.bind.jnl: journal file corrupt: expected serial 1824, got 1825
30-Apr-2021 14:09:19.611 general: error: managed-keys-zone: dns_journal_compact failed: unexpected error
```
### BIND version used
```
BIND 9.16.15 (Stable Release) <id:4469e3e>
```
### Steps to reproduce
It occurs sometimes on several zones
### What is the current *bug* behavior?
named reports errors on a couple of zones:
```
03-May-2021 02:10:41.333 general: error: slave/pluz.ch.hosts.jnw: journal file corrupt: expected serial 2021042500, got 2021050200
03-May-2021 02:10:41.333 general: error: zone pluz.ch/IN: dns_journal_compact failed: unexpected error
```
### What is the expected *correct* behavior?
### Relevant configuration files
### Relevant logs and/or screenshots
### Possible fixesJuly 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2670Always set 'rewrite' when compacting a version 1 journal.2021-05-11T07:37:22ZMark AndrewsAlways set 'rewrite' when compacting a version 1 journal.As version 1 journals can have corrupted transaction headers always process
the compaction using the recovery code.As version 1 journals can have corrupted transaction headers always process
the compaction using the recovery code.May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2671Change default for max-ixfr-ratio to 'unlimited' on BIND 9.162021-05-11T07:36:50ZCathy AlmondChange default for max-ixfr-ratio to 'unlimited' on BIND 9.16This is a new back-ported feature, which we chose to include because it would be useful in a stable production version of BIND rather than waiting until 9.18 production release.
However, it should be disabled by default, following the p...This is a new back-ported feature, which we chose to include because it would be useful in a stable production version of BIND rather than waiting until 9.18 production release.
However, it should be disabled by default, following the principle of 'no surprises'
[Support ticket RT #18457](https://support.isc.org/Ticket/Display.html?id=18457)May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)https://gitlab.isc.org/isc-projects/bind9/-/issues/2672random port re-use for zone refresh SOA queries - when it doesn't work it rea...2022-12-14T07:42:14ZCathy Almondrandom port re-use for zone refresh SOA queries - when it doesn't work it really doesn't workThere's a well-known issue with SOA queries for zone refreshes, where the path to an authoritative server from a secondary has some random ports blocked.
The issue is that for these refresh queries alone, BIND reuses an existing dispatc...There's a well-known issue with SOA queries for zone refreshes, where the path to an authoritative server from a secondary has some random ports blocked.
The issue is that for these refresh queries alone, BIND reuses an existing dispatch to the same server IP address. It does so for performance reasons, so that it's not creating and then tearing down sockets all the time, between it and a frequently-used provider of zone updates. But there is a down-side to this strategy, as previously encountered before, and that has not yet made it into a KB article.
IF a socket has been opened for a refresh query to another server, but the packets to the other server are all being dropped (because of the source port that has been chosen randomly by the OS - for example, then this refresh query will have to wait to time-out. This makes it quite likely (on a busy authoritative server, particularly one participating in a multi-layered tree-like zone propagation strategy) another zone refresh will come along and see the existing socket that has been opened, so will also send its own refresh query that way.
When the first query times out, the socket persists because there's now another zone refresh using it ... and so-on. Essentially nothing more can be refreshed from this server because there's always at least one outstanding query waiting to time out and keeping the port open and the dispatch active.
See: https://bugs.isc.org/Ticket/Display.html?id=26974
The obvious mitigation is to prevent named from using source ports that are known not to work. For example some providers are blocking port 11211 in response to memcached DDoS activity: https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/ so add this to named.conf:
avoid-v4-udp-ports { 11211; };
But this is 'whack-a-mole' - the problem is bigger than this - how do you know in advance which random ports are not going to work for zone refreshes?
Can BIND 'do it better' than it is doing now?
It would potentially be messy (touches too many areas of other processing) to add an additional field to the structure handling the socket in order to count timeouts - but that might be the only way to do this?
We can't use something in ADB, because it's only a timeout problem to this server for specific source ports.
It also doesn't work to retry the same server again immediately with a different random source port - we don't know if the timeout is because the server is silently unreachable, or if it's only this source port that is problematic. And we don't want to double (or more) the time to getting back a good SOA RR and the initiating the zone update.
And then finally, we don't know that our port is a 'bad' port until we've tried the server and succeeded with a 'good' port - so again, I'm not sure what the best process would be to try to address this in named's own processing logic.
So final thought, is to add a couple of counters to the dispatch so that after it has been used 'x' times or has timed-out 'y' times, it's no longer permissable to reuse it - a new socket with a new random port has to be opened ...
====
Further musing:
Would the ephemeral/dynamic range (49152–65535) be any safer than using the full 1024-65535? For sure, you're reducing randomness, and just because a port isn't in use by a registered service locally, doesn't guarantee that a firewall along the way hasn't decided to block it? But a thought?
====
Footnote: This is *only* a problem where the port blocking doesn't result in a send failure (ICMP something or other) that can get back to the sending process. It's silent drops and/or faulty network stacks that don't pass the failure up to the sending socket call that are going to cause this issue.BIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2673clean up FREE_CAP2021-05-04T15:23:44ZRoland Illigclean up FREE_CAP### Description
The NetBSD project has a local patch for `named/os.c` that converts the macro `FREE_CAP` to the standard form using the do-while-0 pattern.
The current code in os.c lacks in clarity since merely writing `FREE_CAP;` does...### Description
The NetBSD project has a local patch for `named/os.c` that converts the macro `FREE_CAP` to the standard form using the do-while-0 pattern.
The current code in os.c lacks in clarity since merely writing `FREE_CAP;` does not look like a function call, it doesn't look like idiomatic C at all, and it hides the fact that it accesses the local variables `cap` and `curcaps`.
### Request
The macro should either be inlined in the two places where it is used, or it should be converted to a `static` function, for the benefit of human readers.
Maybe it's even better for long-term maintainability to replace the macros with ordinary functions since then a debugging version of `named` includes helpful line numbers for the code in question.
### Links / references
* [os.c in NetBSD](https://github.com/NetBSD/src/blob/c56820366d978dc674b11ceb7ed3a506e190c345/external/mpl/bind/dist/bin/named/unix/os.c#L129)https://gitlab.isc.org/isc-projects/bind9/-/issues/2674stray semicolon in CHECKALG in dst_api.c2021-05-04T15:49:54ZRoland Illigstray semicolon in CHECKALG in dst_api.cThe macro `CHECKALG` should not end with a semicolon.
It would be good to have a tool that detects these kinds of bugs automatically, but I don't know whether that already exists.The macro `CHECKALG` should not end with a semicolon.
It would be good to have a tool that detects these kinds of bugs automatically, but I don't know whether that already exists.https://gitlab.isc.org/isc-projects/bind9/-/issues/2675Wrong RFC reference in name.c2021-05-11T07:30:30ZRoland IlligWrong RFC reference in name.cname.c says
> RFC292/RFC1123 hostname
RFC 292 is about network graphics, not name resolution.
In NetBSD, this has been patched to RFC 952.name.c says
> RFC292/RFC1123 hostname
RFC 292 is about network graphics, not name resolution.
In NetBSD, this has been patched to RFC 952.May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)https://gitlab.isc.org/isc-projects/bind9/-/issues/2676Missing May backports2021-05-28T06:11:32ZMichal NowakMissing May backportsThe following merge requests merged to %"May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)" milestone indicate that they also should be backported in %"May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)" but they wer...The following merge requests merged to %"May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)" milestone indicate that they also should be backported in %"May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)" but they were not. For them not to be forgotten I list them here:
**BIND 9.11.32**
- @ondrej
- [x] isc-projects/bind9!4928 (backported by @mnowak)
**BIND 9.11.32-S1**
- @matthijs
- [x] isc-projects/bind9!4799 (moved to `v9_11_sub-with-serve-stale-improvements` branch in the private project and is [scheduled](https://mattermost.isc.org/isc/pl/6zrhycx1etr3mq8eajf7y8xzbr) to be merged to `v9_11_sub` early in June merge window with the rest of the 9.11-S serve-stale work)
**BIND 9.16.16**
- @marka
- [x] isc-projects/bind9!4751
- [x] isc-projects/bind9!5013
- [x] isc-projects/bind9!4947
- @ondrej
- [x] isc-projects/bind9!4918 - backported in isc-projects/bind9!5018
- [x] isc-projects/bind9!4928 (backported by @mnowak)
- [x] isc-projects/bind9!4980 - as isc-projects/bind9!5025
- [x] isc-projects/bind9!4981 - partially as isc-projects/bind9!5026, partially in isc-projects/bind9!5018
- [x] isc-projects/bind9!4982 - not needed, Windows-only, too intrusive
- [x] isc-projects/bind9!4983 - backported in isc-projects/bind9!5018
- [x] isc-projects/bind9!5006 - backported in isc-projects/bind9!5018
- [x] isc-projects/bind9!5008 - backported in isc-projects/bind9!5018
- [x] isc-projects/bind9!5009 - backported in isc-projects/bind9!5018
- [x] isc-projects/bind9!5010 - backported in isc-projects/bind9!5018
- [x] isc-projects/bind9!5021 - backported in isc-projects/bind9!5018
- @dfronza
- [x] #2529 to be backported in %"June 2021 (9.11.33, 9.11.33-S1, 9.16.17, 9.16.17-S1, 9.17.14)", see !5001June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)https://gitlab.isc.org/isc-projects/bind9/-/issues/2677ThreadSanitizer: data race in memmove2021-09-02T09:40:26ZMichal NowakThreadSanitizer: data race in memmovehttps://gitlab.isc.org/isc-projects/bind9/-/jobs/1692745:
```
WARNING: ThreadSanitizer: data race
Read of size 8 at 0x000000000001 by thread T1:
#0 memmove <null>
#1 isc_buffer_copyregion lib/isc/buffer.c:530:3
#2 dns_zone...https://gitlab.isc.org/isc-projects/bind9/-/jobs/1692745:
```
WARNING: ThreadSanitizer: data race
Read of size 8 at 0x000000000001 by thread T1:
#0 memmove <null>
#1 isc_buffer_copyregion lib/isc/buffer.c:530:3
#2 dns_zone_forwardupdate lib/dns/zone.c:17752:11
#3 forward_action lib/ns/update.c:3556:11
#4 dispatch lib/isc/task.c:1132:7
#5 run lib/isc/task.c:1324:2
#6 isc__trampoline_run lib/isc/trampoline.c:191:11
Previous write of size 8 at 0x000000000001 by thread T2:
#0 recvmsg <null>
#1 <null> <null>
#2 isc__trampoline_run lib/isc/trampoline.c:191:11
Location is heap block of size 1310737 at 0x000000000011 allocated by main thread:
#0 malloc <null>
#1 default_memalloc lib/isc/mem.c:715:8
#2 mem_get lib/isc/mem.c:624:8
#3 mem_allocateunlocked lib/isc/mem.c:1290:8
#4 isc___mem_allocate lib/isc/mem.c:1310:7
#5 isc__mem_allocate lib/isc/mem.c:2538:10
#6 isc___mem_get lib/isc/mem.c:1059:11
#7 isc__mem_get lib/isc/mem.c:2517:10
#8 isc_nm_start lib/isc/netmgr/netmgr.c:279:21
#9 create_managers bin/named/./main.c:925:15
#10 setup bin/named/./main.c:1272:11
#11 main bin/named/./main.c:1575:2
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:79:8
#2 isc_taskmgr_create lib/isc/task.c:1412:3
#3 create_managers bin/named/./main.c:931:11
#4 setup bin/named/./main.c:1272:11
#5 main bin/named/./main.c:1575:2
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:79:8
#2 isc_nm_start lib/isc/netmgr/netmgr.c:288:3
#3 create_managers bin/named/./main.c:925:15
#4 setup bin/named/./main.c:1272:11
#5 main bin/named/./main.c:1575:2
SUMMARY: ThreadSanitizer: data race in memmove
```September 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/2678named-checkconf doesn't catch redefinition of dnssec-policy insecure2021-05-11T07:32:31ZMark Andrewsnamed-checkconf doesn't catch redefinition of dnssec-policy insecureMay 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)https://gitlab.isc.org/isc-projects/bind9/-/issues/2679"task" unit test fails with "atomic_load(&d) <= 3"2022-03-01T09:40:45ZMichal Nowak"task" unit test fails with "atomic_load(&d) <= 3"The `task` unit test failed on `main` in the [`unit:gcc:softhsm2.4` job](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1694507):
```
[==========] Running 14 test(s).
[ RUN ] manytasks
[ OK ] manytasks
[ RUN ] all_even...The `task` unit test failed on `main` in the [`unit:gcc:softhsm2.4` job](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1694507):
```
[==========] Running 14 test(s).
[ RUN ] manytasks
[ OK ] manytasks
[ RUN ] all_events
[ OK ] all_events
[ RUN ] basic
[ OK ] basic
[ RUN ] create_task
[ OK ] create_task
[ RUN ] pause_unpause
[ OK ] pause_unpause
[ RUN ] post_shutdown
[ OK ] post_shutdown
[ RUN ] privilege_drop
atomic_load(&d) <= 3
[ LINE ] --- task_test.c:402: error: Failure!I:task_test:Core dump found: ./core.7161
D:task_test:backtrace from ./core.7161 start
[New LWP 7161]
[New LWP 7441]
[New LWP 7443]
[New LWP 7445]
[New LWP 7447]
[New LWP 7449]
[New LWP 7448]
[New LWP 7451]
[New LWP 7450]
[New LWP 7454]
[New LWP 7453]
[New LWP 7446]
[New LWP 7444]
[New LWP 7452]
[New LWP 7442]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/builds/isc-projects/bind9/lib/isc/tests/.libs/task_test'.
Program terminated with signal SIGABRT, Aborted.
#0 __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.
[Current thread is 1 (Thread 0x7f6c48c30ec0 (LWP 7161))]
Thread 15 (Thread 0x7f6c36ffd700 (LWP 7442)):
#0 futex_wait_cancelable (private=0, expected=0, futex_word=0x55767e52e120) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
__ret = 0
oldtype = 0
err = <optimized out>
oldtype = <optimized out>
err = <optimized out>
__ret = <optimized out>
resultvar = <optimized out>
__arg4 = <optimized out>
__arg3 = <optimized out>
__arg2 = <optimized out>
__arg1 = <optimized out>
_a4 = <optimized out>
_a3 = <optimized out>
_a2 = <optimized out>
_a1 = <optimized out>
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x55767e52e0a0, cond=0x55767e52e0f8) at pthread_cond_wait.c:502
spin = 0
buffer = {__routine = 0x7f6c4b7bad80 <__condvar_cleanup_waiting>, __arg = 0x7f6c36ffcc40, __canceltype = 2122456320, __prev = 0x0}
cbuffer = {wseq = 18, cond = 0x55767e52e0f8, mutex = 0x55767e52e0a0, private = 0}
rt = <optimized out>
err = <optimized out>
g = 0
flags = <optimized out>
g1_start = <optimized out>
signals = <optimized out>
result = 0
wseq = 18
seq = 9
private = 0
maxspin = <optimized out>
err = <optimized out>
result = <optimized out>
wseq = <optimized out>
g = <optimized out>
seq = <optimized out>
flags = <optimized out>
private = <optimized out>
signals = <optimized out>
g1_start = <optimized out>
spin = <optimized out>
buffer = <optimized out>
cbuffer = <optimized out>
rt = <optimized out>
s = <optimized out>
#2 __pthread_cond_wait (cond=cond@entry=0x55767e52e0f8, mutex=mutex@entry=0x55767e52e0a0) at pthread_cond_wait.c:655
No locals.
#3 0x00007f6c4b7f71fd in nm_thread (worker0=0x55767e65a7e0) at netmgr/netmgr.c:652
r = 1
worker = 0x55767e65a7e0
mgr = 0x55767e52e080
#4 0x00007f6c4b83ca2a in isc__trampoline_run (arg=0x55767f8567f0) at trampoline.c:184
trampoline = 0x55767f8567f0
result = <optimized out>
#5 0x00007f6c4b7b4fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
ret = <optimized out>
pd = <optimized out>
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140102755931904, 3335179980514494415, 140726091752270, 140726091752271, 140102755931904, 93967433497696, -3418058969693845553, -3418119472830117937}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#6 0x00007f6c4b6bd4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
Thread 14 (Thread 0x7f6c45426700 (LWP 7452)):
#0 0x00007f6c4b6bd62e in __GI_epoll_pwait (epfd=55, events=0x7f6c45422bf0, maxevents=1024, timeout=-1, set=0x0) at ../sysdeps/unix/sysv/linux/epoll_pwait.c:42
resultvar = 18446744073709551612
sc_cancel_oldtype = 0
sc_ret = <optimized out>
#1 0x00007f6c4b5aa399 in uv.io_poll () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#2 0x00007f6c4b59bf85 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#3 0x00007f6c4b7f6eef in nm_thread (worker0=0x55767e65d580) at netmgr/netmgr.c:612
r = <optimized out>
worker = 0x55767e65d580
mgr = 0x55767e52e080
#4 0x00007f6c4b83ca2a in isc__trampoline_run (arg=0x55767f5c7f30) at trampoline.c:184
trampoline = 0x55767f5c7f30
result = <optimized out>
#5 0x00007f6c4b7b4fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
ret = <optimized out>
pd = <optimized out>
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140102995175168, 3335179980514494415, 140726091752270, 140726091752271, 140102995175168, 93967433951312, -3418097971754989617, -3418119472830117937}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#6 0x00007f6c4b6bd4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
Thread 13 (Thread 0x7f6c37fff700 (LWP 7444)):
#0 0x00007f6c4b6bd62e in __GI_epoll_pwait (epfd=21, events=0x7f6c37ffbbf0, maxevents=1024, timeout=-1, set=0x0) at ../sysdeps/unix/sysv/linux/epoll_pwait.c:42
resultvar = 18446744073709551612
sc_cancel_oldtype = 0
sc_ret = <optimized out>
#1 0x00007f6c4b5aa399 in uv.io_poll () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#2 0x00007f6c4b59bf85 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#3 0x00007f6c4b7f6eef in nm_thread (worker0=0x55767e65b100) at netmgr/netmgr.c:612
r = <optimized out>
worker = 0x55767e65b100
mgr = 0x55767e52e080
#4 0x00007f6c4b83ca2a in isc__trampoline_run (arg=0x55767eb44a40) at trampoline.c:184
trampoline = 0x55767eb44a40
result = <optimized out>
#5 0x00007f6c4b7b4fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
ret = <optimized out>
pd = <optimized out>
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140102772717312, 3335179980514494415, 140726091752270, 140726091752271, 140102772717312, 93967420316976, -3418056769596848177, -3418119472830117937}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#6 0x00007f6c4b6bd4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
Thread 12 (Thread 0x7f6c4842c700 (LWP 7446)):
#0 0x00007f6c4b6bd62e in __GI_epoll_pwait (epfd=29, events=0x7f6c48428bf0, maxevents=1024, timeout=-1, set=0x0) at ../sysdeps/unix/sysv/linux/epoll_pwait.c:42
resultvar = 18446744073709551612
sc_cancel_oldtype = 0
sc_ret = <optimized out>
#1 0x00007f6c4b5aa399 in uv.io_poll () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#2 0x00007f6c4b59bf85 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#3 0x00007f6c4b7f6eef in nm_thread (worker0=0x55767e65ba20) at netmgr/netmgr.c:612
r = <optimized out>
worker = 0x55767e65ba20
mgr = 0x55767e52e080
#4 0x00007f6c4b83ca2a in isc__trampoline_run (arg=0x55767f7696c0) at trampoline.c:184
trampoline = 0x55767f7696c0
result = <optimized out>
#5 0x00007f6c4b7b4fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
ret = <optimized out>
pd = <optimized out>
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140103045531392, 3335179980514494415, 140726091752270, 140726091752271, 140103045531392, 93967433951312, -3418126560131053617, -3418119472830117937}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#6 0x00007f6c4b6bd4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
Thread 11 (Thread 0x7f6c44c25700 (LWP 7453)):
#0 futex_wait_cancelable (private=0, expected=0, futex_word=0x55767febaa28) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
__ret = -512
oldtype = 0
err = <optimized out>
oldtype = <optimized out>
err = <optimized out>
__ret = <optimized out>
resultvar = <optimized out>
__arg4 = <optimized out>
__arg3 = <optimized out>
__arg2 = <optimized out>
__arg1 = <optimized out>
_a4 = <optimized out>
_a3 = <optimized out>
_a2 = <optimized out>
_a1 = <optimized out>
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x55767feba9b0, cond=0x55767febaa00) at pthread_cond_wait.c:502
spin = 0
buffer = {__routine = 0x7f6c4b7bad80 <__condvar_cleanup_waiting>, __arg = 0x7f6c44c24c10, __canceltype = 0, __prev = 0x0}
cbuffer = {wseq = 0, cond = 0x55767febaa00, mutex = 0x55767feba9b0, private = 0}
rt = <optimized out>
err = <optimized out>
g = 0
flags = <optimized out>
g1_start = <optimized out>
signals = <optimized out>
result = 0
wseq = 0
seq = 0
private = 0
maxspin = <optimized out>
err = <optimized out>
result = <optimized out>
wseq = <optimized out>
g = <optimized out>
seq = <optimized out>
flags = <optimized out>
private = <optimized out>
signals = <optimized out>
g1_start = <optimized out>
spin = <optimized out>
buffer = <optimized out>
cbuffer = <optimized out>
rt = <optimized out>
s = <optimized out>
#2 __pthread_cond_wait (cond=cond@entry=0x55767febaa00, mutex=mutex@entry=0x55767feba9b0) at pthread_cond_wait.c:655
No locals.
#3 0x00007f6c4b83a6ad in run (uap=0x55767feba9a0) at timer.c:627
manager = 0x55767feba9a0
now = {seconds = 1620187993, nanoseconds = 389499008}
result = <optimized out>
#4 0x00007f6c4b83ca2a in isc__trampoline_run (arg=0x55767f5c8380) at trampoline.c:184
trampoline = 0x55767f5c8380
result = <optimized out>
#5 0x00007f6c4b7b4fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
ret = <optimized out>
pd = <optimized out>
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140102986782464, 3335179980514494415, 140726091752350, 140726091752351, 140102986782464, 140726091753456, -3418099071803488305, -3418119472830117937}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#6 0x00007f6c4b6bd4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
Thread 10 (Thread 0x7f6c35ffb700 (LWP 7454)):
#0 0x00007f6c4b6bd7ef in epoll_wait (epfd=65, events=0x55767ff1ce00, maxevents=2048, timeout=timeout@entry=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
resultvar = 18446744073709551612
sc_cancel_oldtype = 0
sc_ret = <optimized out>
#1 0x00007f6c4b80faaf in netthread (uap=0x55767e530d90) at unix/socket.c:3394
thread = 0x55767e530d90
manager = <optimized out>
done = false
cc = <optimized out>
fnname = <optimized out>
strbuf = '\000' <repeats 127 times>
#2 0x00007f6c4b83ca2a in isc__trampoline_run (arg=0x55767f5d26d0) at trampoline.c:184
trampoline = 0x55767f5d26d0
result = <optimized out>
#3 0x00007f6c4b7b4fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
ret = <optimized out>
pd = <optimized out>
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140102739146496, 3335179980514494415, 140726091751390, 140726091751391, 140102739146496, 0, -3418061165495875633, -3418119472830117937}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#4 0x00007f6c4b6bd4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
Thread 9 (Thread 0x7f6c46428700 (LWP 7450)):
#0 0x00007f6c4b6bd62e in __GI_epoll_pwait (epfd=45, events=0x7f6c46424bf0, maxevents=1024, timeout=-1, set=0x0) at ../sysdeps/unix/sysv/linux/epoll_pwait.c:42
resultvar = 18446744073709551612
sc_cancel_oldtype = 0
sc_ret = <optimized out>
#1 0x00007f6c4b5aa399 in uv.io_poll () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#2 0x00007f6c4b59bf85 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#3 0x00007f6c4b7f6eef in nm_thread (worker0=0x55767e65cc60) at netmgr/netmgr.c:612
r = <optimized out>
worker = 0x55767e65cc60
mgr = 0x55767e52e080
#4 0x00007f6c4b83ca2a in isc__trampoline_run (arg=0x55767f197870) at trampoline.c:184
trampoline = 0x55767f197870
result = <optimized out>
#5 0x00007f6c4b7b4fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
ret = <optimized out>
pd = <optimized out>
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140103011960576, 3335179980514494415, 140726091752270, 140726091752271, 140103011960576, 93967433951312, -3418095771657992241, -3418119472830117937}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#6 0x00007f6c4b6bd4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
Thread 8 (Thread 0x7f6c45c27700 (LWP 7451)):
#0 0x00007f6c4b6bd62e in __GI_epoll_pwait (epfd=49, events=0x7f6c45c23bf0, maxevents=1024, timeout=-1, set=0x0) at ../sysdeps/unix/sysv/linux/epoll_pwait.c:42
resultvar = 18446744073709551612
sc_cancel_oldtype = 0
sc_ret = <optimized out>
#1 0x00007f6c4b5aa399 in uv.io_poll () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#2 0x00007f6c4b59bf85 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#3 0x00007f6c4b7f6eef in nm_thread (worker0=0x55767e65d0f0) at netmgr/netmgr.c:612
r = <optimized out>
worker = 0x55767e65d0f0
mgr = 0x55767e52e080
#4 0x00007f6c4b83ca2a in isc__trampoline_run (arg=0x55767f3b79d0) at trampoline.c:184
trampoline = 0x55767f3b79d0
result = <optimized out>
#5 0x00007f6c4b7b4fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
ret = <optimized out>
pd = <optimized out>
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140103003567872, 3335179980514494415, 140726091752270, 140726091752271, 140103003567872, 93967433951312, -3418096871706490929, -3418119472830117937}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#6 0x00007f6c4b6bd4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
Thread 7 (Thread 0x7f6c4742a700 (LWP 7448)):
#0 0x00007f6c4b6bd62e in __GI_epoll_pwait (epfd=37, events=0x7f6c47426bf0, maxevents=1024, timeout=-1, set=0x0) at ../sysdeps/unix/sysv/linux/epoll_pwait.c:42
resultvar = 18446744073709551612
sc_cancel_oldtype = 0
sc_ret = <optimized out>
#1 0x00007f6c4b5aa399 in uv.io_poll () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#2 0x00007f6c4b59bf85 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#3 0x00007f6c4b7f6eef in nm_thread (worker0=0x55767e65c340) at netmgr/netmgr.c:612
r = <optimized out>
worker = 0x55767e65c340
mgr = 0x55767e52e080
#4 0x00007f6c4b83ca2a in isc__trampoline_run (arg=0x55767ed575b0) at trampoline.c:184
trampoline = 0x55767ed575b0
result = <optimized out>
#5 0x00007f6c4b7b4fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
ret = <optimized out>
pd = <optimized out>
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140103028745984, 3335179980514494415, 140726091752270, 140726091752271, 140103028745984, 93967433951312, -3418093575855962161, -3418119472830117937}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#6 0x00007f6c4b6bd4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
Thread 6 (Thread 0x7f6c46c29700 (LWP 7449)):
#0 0x00007f6c4b6bd62e in __GI_epoll_pwait (epfd=41, events=0x7f6c46c25bf0, maxevents=1024, timeout=-1, set=0x0) at ../sysdeps/unix/sysv/linux/epoll_pwait.c:42
resultvar = 18446744073709551612
sc_cancel_oldtype = 0
sc_ret = <optimized out>
#1 0x00007f6c4b5aa399 in uv.io_poll () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#2 0x00007f6c4b59bf85 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#3 0x00007f6c4b7f6eef in nm_thread (worker0=0x55767e65c7d0) at netmgr/netmgr.c:612
r = <optimized out>
worker = 0x55767e65c7d0
mgr = 0x55767e52e080
#4 0x00007f6c4b83ca2a in isc__trampoline_run (arg=0x55767ef77710) at trampoline.c:184
trampoline = 0x55767ef77710
result = <optimized out>
#5 0x00007f6c4b7b4fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
ret = <optimized out>
pd = <optimized out>
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140103020353280, 3335179980514494415, 140726091752270, 140726091752271, 140103020353280, 93967433951312, -3418094675904460849, -3418119472830117937}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#6 0x00007f6c4b6bd4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
Thread 5 (Thread 0x7f6c47c2b700 (LWP 7447)):
#0 0x00007f6c4b6bd62e in __GI_epoll_pwait (epfd=33, events=0x7f6c47c27bf0, maxevents=1024, timeout=-1, set=0x0) at ../sysdeps/unix/sysv/linux/epoll_pwait.c:42
resultvar = 18446744073709551612
sc_cancel_oldtype = 0
sc_ret = <optimized out>
#1 0x00007f6c4b5aa399 in uv.io_poll () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#2 0x00007f6c4b59bf85 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#3 0x00007f6c4b7f6eef in nm_thread (worker0=0x55767e65beb0) at netmgr/netmgr.c:612
r = <optimized out>
worker = 0x55767e65beb0
mgr = 0x55767e52e080
#4 0x00007f6c4b83ca2a in isc__trampoline_run (arg=0x55767fe9bf80) at trampoline.c:184
trampoline = 0x55767fe9bf80
result = <optimized out>
#5 0x00007f6c4b7b4fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
ret = <optimized out>
pd = <optimized out>
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140103037138688, 3335179980514494415, 140726091752270, 140726091752271, 140103037138688, 93967433951312, -3418092475807463473, -3418119472830117937}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#6 0x00007f6c4b6bd4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
Thread 4 (Thread 0x7f6c48c2d700 (LWP 7445)):
#0 0x00007f6c4b6bd62e in __GI_epoll_pwait (epfd=25, events=0x7f6c48c29bf0, maxevents=1024, timeout=-1, set=0x0) at ../sysdeps/unix/sysv/linux/epoll_pwait.c:42
resultvar = 18446744073709551612
sc_cancel_oldtype = 0
sc_ret = <optimized out>
#1 0x00007f6c4b5aa399 in uv.io_poll () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#2 0x00007f6c4b59bf85 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#3 0x00007f6c4b7f6eef in nm_thread (worker0=0x55767e65b590) at netmgr/netmgr.c:612
r = <optimized out>
worker = 0x55767e65b590
mgr = 0x55767e52e080
#4 0x00007f6c4b83ca2a in isc__trampoline_run (arg=0x55767e8185c0) at trampoline.c:184
trampoline = 0x55767e8185c0
result = <optimized out>
#5 0x00007f6c4b7b4fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
ret = <optimized out>
pd = <optimized out>
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140103053924096, 3335179980514494415, 140726091752270, 140726091752271, 140103053924096, 93967433951312, -3418125464377522225, -3418119472830117937}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#6 0x00007f6c4b6bd4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
Thread 3 (Thread 0x7f6c367fc700 (LWP 7443)):
#0 0x00007f6c4b6bd62e in __GI_epoll_pwait (epfd=17, events=0x7f6c367f8bf0, maxevents=1024, timeout=-1, set=0x0) at ../sysdeps/unix/sysv/linux/epoll_pwait.c:42
resultvar = 18446744073709551612
sc_cancel_oldtype = 0
sc_ret = <optimized out>
#1 0x00007f6c4b5aa399 in uv.io_poll () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#2 0x00007f6c4b59bf85 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#3 0x00007f6c4b7f6eef in nm_thread (worker0=0x55767e65ac70) at netmgr/netmgr.c:612
r = <optimized out>
worker = 0x55767e65ac70
mgr = 0x55767e52e080
#4 0x00007f6c4b83ca2a in isc__trampoline_run (arg=0x55767fa1bc80) at trampoline.c:184
trampoline = 0x55767fa1bc80
result = <optimized out>
#5 0x00007f6c4b7b4fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
ret = <optimized out>
pd = <optimized out>
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140102747539200, 3335179980514494415, 140726091752270, 140726091752271, 140102747539200, 93967433498800, -3418060065447376945, -3418119472830117937}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#6 0x00007f6c4b6bd4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
Thread 2 (Thread 0x7f6c377fe700 (LWP 7441)):
#0 0x00007f6c4b6bd62e in __GI_epoll_pwait (epfd=3, events=0x7f6c377fabf0, maxevents=1024, timeout=-1, set=0x0) at ../sysdeps/unix/sysv/linux/epoll_pwait.c:42
resultvar = 18446744073709551612
sc_cancel_oldtype = 0
sc_ret = <optimized out>
#1 0x00007f6c4b5aa399 in uv.io_poll () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#2 0x00007f6c4b59bf85 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#3 0x00007f6c4b7f6eef in nm_thread (worker0=0x55767e65a350) at netmgr/netmgr.c:612
r = <optimized out>
worker = 0x55767e65a350
mgr = 0x55767e52e080
#4 0x00007f6c4b83ca2a in isc__trampoline_run (arg=0x55767f859dd0) at trampoline.c:184
trampoline = 0x55767f859dd0
result = <optimized out>
#5 0x00007f6c4b7b4fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
ret = <optimized out>
pd = <optimized out>
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140102764324608, 3335179980514494415, 140726091752270, 140726091752271, 140102764324608, 93967431334672, -3418057869645346865, -3418119472830117937}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#6 0x00007f6c4b6bd4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
Thread 1 (Thread 0x7f6c48c30ec0 (LWP 7161)):
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
set = {__val = {0 <repeats 12 times>, 47, 96, 48, 0}}
pid = <optimized out>
tid = <optimized out>
ret = <optimized out>
#1 0x00007f6c4b5e6535 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x7f6c48c31820, sa_sigaction = 0x7f6c48c31820}, sa_mask = {__val = {8, 140103099350080, 10240, 0, 93967431334640, 28, 0, 0, 93967413862528, 140726091753008, 140103097767218, 93967413862528, 140103097767218, 0, 93967385772036, 402}}, sa_flags = 1267105120, sa_restorer = 0x7f6c4b871168}
sigs = {__val = {32, 0 <repeats 15 times>}}
#2 0x00007f6c4b867d47 in ?? () from /usr/lib/x86_64-linux-gnu/libcmocka.so.0
No symbol table info available.
#3 0x00007f6c4b867daa in _fail () from /usr/lib/x86_64-linux-gnu/libcmocka.so.0
No symbol table info available.
#4 0x000055767ca62477 in privilege_drop (state=<optimized out>) at task_test.c:414
result = <optimized out>
task1 = 0x55767f5d4c20
task2 = 0x55767f5d4d30
event = 0x0
a = 1
b = 2
c = 3
d = 5
e = 4
i = <optimized out>
#5 0x00007f6c4b86a0d9 in ?? () from /usr/lib/x86_64-linux-gnu/libcmocka.so.0
No symbol table info available.
#6 0x00007f6c4b86aa49 in _cmocka_run_group_tests () from /usr/lib/x86_64-linux-gnu/libcmocka.so.0
No symbol table info available.
#7 0x000055767ca6367b in main (argc=1, argv=0x7ffd58b5b5e8) at task_test.c:1588
tests = {{name = 0x55767ca6420b "manytasks", test_func = 0x55767ca63184 <manytasks>, setup_func = 0x0, teardown_func = 0x0, initial_state = 0x0}, {name = 0x55767ca64215 "all_events", test_func = 0x55767ca62f49 <all_events>, setup_func = 0x55767ca5fd92 <_setup>, teardown_func = 0x55767ca62f2d <_teardown>, initial_state = 0x0}, {name = 0x55767ca64220 "basic", test_func = 0x55767ca62aa7 <basic>, setup_func = 0x55767ca5fcda <_setup2>, teardown_func = 0x55767ca62f2d <_teardown>, initial_state = 0x0}, {name = 0x55767ca64226 "create_task", test_func = 0x55767ca62526 <create_task>, setup_func = 0x55767ca5fd92 <_setup>, teardown_func = 0x55767ca62f2d <_teardown>, initial_state = 0x0}, {name = 0x55767ca64232 "pause_unpause", test_func = 0x55767ca62729 <pause_unpause>, setup_func = 0x55767ca5fd92 <_setup>, teardown_func = 0x55767ca62f2d <_teardown>, initial_state = 0x0}, {name = 0x55767ca64240 "post_shutdown", test_func = 0x55767ca6031f <post_shutdown>, setup_func = 0x55767ca5fcda <_setup2>, teardown_func = 0x55767ca62f2d <_teardown>, initial_state = 0x0}, {name = 0x55767ca6424e "privilege_drop", test_func = 0x55767ca61ed0 <privilege_drop>, setup_func = 0x55767ca5fd92 <_setup>, teardown_func = 0x55767ca62f2d <_teardown>, initial_state = 0x0}, {name = 0x55767ca6425d "privileged_events", test_func = 0x55767ca6183a <privileged_events>, setup_func = 0x55767ca5fd92 <_setup>, teardown_func = 0x55767ca62f2d <_teardown>, initial_state = 0x0}, {name = 0x55767ca64288 "purge", test_func = 0x55767ca61246 <purge>, setup_func = 0x55767ca5fcda <_setup2>, teardown_func = 0x55767ca62f2d <_teardown>, initial_state = 0x0}, {name = 0x55767ca6426f "purgeevent", test_func = 0x55767ca6182a <purgeevent>, setup_func = 0x55767ca5fcda <_setup2>, teardown_func = 0x55767ca62f2d <_teardown>, initial_state = 0x0}, {name = 0x55767ca6427a "purgeevent_notpurge", test_func = 0x55767ca6181a <purgeevent_notpurge>, setup_func = 0x55767ca5fd92 <_setup>, teardown_func = 0x55767ca62f2d <_teardown>, initial_state = 0x0}, {name = 0x55767ca6428e "purgerange", test_func = 0x55767ca6103c <purgerange>, setup_func = 0x55767ca5fd92 <_setup>, teardown_func = 0x55767ca62f2d <_teardown>, initial_state = 0x0}, {name = 0x55767ca64245 "shutdown", test_func = 0x55767ca5fe4a <shutdown>, setup_func = 0x55767ca5fc22 <_setup4>, teardown_func = 0x55767ca62f2d <_teardown>, initial_state = 0x0}, {name = 0x55767ca64299 "task_exclusive", test_func = 0x55767ca5f5c5 <task_exclusive>, setup_func = 0x55767ca5fc22 <_setup4>, teardown_func = 0x55767ca62f2d <_teardown>, initial_state = 0x0}}
selected = {{name = 0x0, test_func = 0x0, setup_func = 0x0, teardown_func = 0x0, initial_state = 0x0} <repeats 14 times>}
i = <optimized out>
c = <optimized out>
D:task_test:backtrace from ./core.7161 end
FAIL task_test (exit status: 134)
```
core file: [core.7161.gz](/uploads/92ace901038632ab8bb8890e73c36a5d/core.7161.gz)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2680BIND logs "no valid signature found" but returns an answer2021-05-05T09:47:49ZStéphane GaubertBIND logs "no valid signature found" but returns an answer<!--
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
(Summarize the bug encountered concisely.)
When DNSSEC validation is activated in BIND v9.16.15 it logs "no valid signature found" for domains that seem to be validated because the answer is returned.
### BIND version used
(Paste the output of `named -V`.)
```
BIND 9.16.15-RH (Stable Release) <id:4469e3e>
running on Linux x86_64 3.10.0-1160.21.1.el7.x86_64 #1 SMP Mon Feb 22 18:03:13 EST 2021
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' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-python=/usr/bin/python' '--with-libtool' '--localstatedir=/var' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-libidn2' '--with-maxminddb' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes' '--with-gssapi=yes' '--with-lmdb=no' '--without-libjson' '--with-json-c' '--enable-fixed-rrset' '--enable-full-report' '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-44)
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 libuv version: 1.41.0
linked to libuv version: 1.41.0
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
linked to maxminddb version: 1.2.0
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/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
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
(How one can reproduce the issue - this is very important.)
For exemple this request can be executed to produce the issue :
dig www.lepoint.fr A
This domain is just an example amongst many.
### What is the current *bug* behavior?
(What actually happens.)
This message gets logged :
```
05-May-2021 10:28:00.949 dnssec: info: validating www.lepoint.fr/CNAME: no valid signature found
But the name server returne a result :
; <<>> DiG 9.11.2-P1-RedHat-9.11.2-1.P1.fc26 <<>> @nshcp-p-i-rec02 www.lepoint.fr A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9024
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 1f429b5cf0d875740100000060925710293e286eb819c305 (good)
;; QUESTION SECTION:
;www.lepoint.fr. IN A
;; ANSWER SECTION:
www.lepoint.fr. 300 IN CNAME lepoint-rvp-https-vip.sdv.fr.
lepoint-rvp-https-vip.sdv.fr. 22837 IN A 212.95.74.45
;; Query time: 16 msec
;; SERVER: 192.168.2.40#53(192.168.2.40)
;; WHEN: mer. mai 05 10:28:00 CEST 2021
;; MSG SIZE rcvd: 129
```
### What is the expected *correct* behavior?
(What you should see instead.)
As the message "no valid signature found" is documented as being a DNSSEC validation error and that there is apparently no validation error, I would expect no message logged by BIND in this case.
We have a lot of "no valid signature found" messages logged on our recursive name servers for domains that seem to be correctly validated. We'd rather have this messages logged only when "no valid signature" has been found.
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
```
logging {
channel "default_log" {
file "log/default" versions 3 size 2097152;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
channel "auth_servers_log" {
file "log/auth_servers" versions 3 size 2097152;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
channel "dnssec_log" {
file "log/dnssec" versions 3 size 2097152;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
channel "zone_transfers_log" {
file "log/zone_transfers" versions 3 size 2097152;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
channel "ddns_log" {
file "log/ddns" versions 3 size 2097152;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
channel "client_security_log" {
file "log/client_security" versions 3 size 2097152;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
channel "rate_limiting_log" {
file "log/rate_limiting" versions 3 size 2097152;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
channel "rpz_log" {
file "log/rpz" versions 3 size 2097152;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
channel "queries_log" {
file "log/queries" versions 100 size 2097152;
severity info;
print-time yes;
print-severity yes;
print-category yes;
};
channel "query-errors_log" {
file "log/query-errors" versions 3 size 2097152;
severity dynamic;
print-time yes;
print-severity yes;
print-category yes;
};
channel "default_debug" {
file "data/named.run" versions 5 size 1048576;
severity dynamic;
print-time yes;
print-severity yes;
print-category yes;
};
category "default" {
"default_syslog";
"default_debug";
"default_log";
};
category "resolver" {
"auth_servers_log";
"default_debug";
};
category "delegation-only" {
"auth_servers_log";
"default_debug";
};
category "lame-servers" {
"auth_servers_log";
"default_debug";
};
category "edns-disabled" {
"auth_servers_log";
"default_debug";
};
category "dnssec" {
"dnssec_log";
"default_debug";
};
category "notify" {
"zone_transfers_log";
"default_debug";
};
category "xfer-in" {
"zone_transfers_log";
"default_debug";
};
category "xfer-out" {
"zone_transfers_log";
"default_debug";
};
category "update" {
"ddns_log";
"default_debug";
};
category "update-security" {
"ddns_log";
"default_debug";
};
category "client" {
"client_security_log";
"default_debug";
};
category "security" {
"client_security_log";
"default_debug";
};
category "rate-limit" {
"rate_limiting_log";
"default_debug";
};
category "database" {
"rate_limiting_log";
"default_debug";
};
category "rpz" {
"rpz_log";
"default_debug";
};
category "queries" {
"queries_log";
};
category "query-errors" {
"query-errors_log";
};
};
options {
bindkeys-file "/etc/named.root.key";
cookie-secret "????????????????????????????????";
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
managed-keys-directory "/var/named/dynamic";
memstatistics-file "/var/named/data/named_mem_stats.txt";
pid-file "/run/named/named.pid";
querylog no;
recursing-file "/var/named/data/named.recursing";
recursive-clients 2000;
secroots-file "/var/named/data/named.secroots";
session-keyfile "/run/named/session.key";
statistics-file "/var/named/data/named_stats.txt";
allow-recursion {
"any";
};
dnssec-validation auto;
empty-zones-enable yes;
filter-aaaa-on-v4 yes;
recursion yes;
validate-except {
"msanet";
"soltimfm";
"union.local";
"wpad";
};
allow-query {
"any";
};
};
server ::/0 {
bogus yes;
};
trust-anchors {
"." initial-ds 20326 8 2 "E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D";
};
zone "." IN {
type hint;
file "named.ca";
};
zone "localhost.localdomain" IN {
type master;
file "named.localhost";
allow-update {
"none";
};
};
zone "localhost" IN {
type master;
file "named.localhost";
allow-update {
"none";
};
};
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
type master;
file "named.loopback";
allow-update {
"none";
};
};
zone "1.0.0.127.in-addr.arpa" IN {
type master;
file "named.loopback";
allow-update {
"none";
};
};
zone "0.in-addr.arpa" IN {
type master;
file "named.empty";
allow-update {
"none";
};
};
zone "ader.gouv.fr" {
type forward;
forward only;
forwarders {
100.77.2.20;
100.77.2.30;
100.77.6.20;
100.77.6.30;
};
};
zone "rie.gouv.fr" {
type forward;
forward only;
forwarders {
100.77.2.20;
100.77.2.30;
100.77.6.20;
100.77.6.30;
};
};
zone "ader.senat.fr" {
type forward;
forward only;
forwarders {
100.77.2.20;
100.77.2.30;
100.77.6.20;
100.77.6.30;
};
};
zone "rie.senat.fr" {
type forward;
forward only;
forwarders {
100.77.2.20;
100.77.2.30;
100.77.6.20;
100.77.6.30;
};
};
zone "ader.elysee.fr" {
type forward;
forward only;
forwarders {
100.77.2.20;
100.77.2.30;
100.77.6.20;
100.77.6.30;
};
};
zone "din.developpement-durable.gouv.fr" {
type forward;
forward only;
forwarders {
100.77.2.20;
100.77.2.30;
100.77.6.20;
100.77.6.30;
};
};
zone "webconf.numerique.gouv.fr" {
type forward;
forward only;
forwarders {
100.77.2.20;
100.77.2.30;
100.77.6.20;
100.77.6.30;
};
};
zone "48.161.in-addr.arpa" {
type forward;
forward only;
forwarders {
100.77.2.20;
100.77.2.30;
100.77.6.20;
100.77.6.30;
};
};
zone "64.100.in-addr.arpa" {
type forward;
forward only;
forwarders {
100.77.2.20;
100.77.2.30;
100.77.6.20;
100.77.6.30;
};
};
zone "65.100.in-addr.arpa" {
type forward;
forward only;
forwarders {
100.77.2.20;
100.77.2.30;
100.77.6.20;
100.77.6.30;
};
};
zone "66.100.in-addr.arpa" {
type forward;
forward only;
forwarders {
100.77.2.20;
100.77.2.30;
100.77.6.20;
100.77.6.30;
};
};
zone "67.100.in-addr.arpa" {
type forward;
forward only;
forwarders {
100.77.2.20;
100.77.2.30;
100.77.6.20;
100.77.6.30;
};
};
zone "68.100.in-addr.arpa" {
type forward;
forward only;
forwarders {
100.77.2.20;
100.77.2.30;
100.77.6.20;
100.77.6.30;
};
};
zone "69.100.in-addr.arpa" {
type forward;
forward only;
forwarders {
100.77.2.20;
100.77.2.30;
100.77.6.20;
100.77.6.30;
};
};
zone "77.100.in-addr.arpa" {
type forward;
forward only;
forwarders {
100.77.2.20;
100.77.2.30;
100.77.6.20;
100.77.6.30;
};
};
zone "78.100.in-addr.arpa" {
type forward;
forward only;
forwarders {
100.77.2.20;
100.77.2.30;
100.77.6.20;
100.77.6.30;
};
};
zone "126.100.in-addr.arpa" {
type forward;
forward only;
forwarders {
100.77.2.20;
100.77.2.30;
100.77.6.20;
100.77.6.30;
};
};
zone "airfrance-is.com" {
type forward;
forward only;
forwarders {
193.57.251.253;
193.57.251.254;
};
};
zone "union.local" {
type forward;
forward only;
forwarders {
172.30.204.200;
};
};
zone "sniiram.cnamts.fr" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "esquif.fr" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "soltimfm" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "131.131.in-addr.arpa" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "62.18.172.in-addr.arpa" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "msanet" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "senat.fr" {
type stub;
masters {
172.31.137.20;
172.31.137.21;
};
};
zone "xn--sn-bja.at" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "clubsenat.fr" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "diffusion-senat.fr" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "parlement-ue2008.fr" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "senateurs.fr" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "clubsenat.net" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "use-application-dns.net" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "carrefourlocal.org" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "senateurope.org" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "wpad" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "17.172.in-addr.arpa" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "20.172.in-addr.arpa" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "23.172.in-addr.arpa" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "25.172.in-addr.arpa" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "28.172.in-addr.arpa" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "29.172.in-addr.arpa" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "30.172.in-addr.arpa" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "31.172.in-addr.arpa" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
zone "168.192.in-addr.arpa" {
type static-stub;
server-names {
"ns1-in.senat.fr.";
"ns2-in.senat.fr.";
};
};
```
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
05-May-2021 10:28:00.949 dnssec: info: validating www.lepoint.fr/CNAME: no valid signature found
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)https://gitlab.isc.org/isc-projects/bind9/-/issues/2683Increase the logging level of some IXFR messages2022-08-22T10:04:56ZMichal NowakIncrease the logging level of some IXFR messages(Originally reported as https://gitlab.isc.org/isc-projects/bind9/-/issues/2671#note_211777.)
I'd like to suggest that we increase the logging level of these messages:
```
xfrout_log1(client, question_name, ques...(Originally reported as https://gitlab.isc.org/isc-projects/bind9/-/issues/2671#note_211777.)
I'd like to suggest that we increase the logging level of these messages:
```
xfrout_log1(client, question_name, question_class,
ISC_LOG_DEBUG(4),
"IXFR version not in journal, "
"falling back to AXFR");
[...]
xfrout_log1(client, question_name,
question_class, ISC_LOG_DEBUG(4),
"IXFR delta size (%zu bytes) "
"exceeds the maximum ratio to "
"database size "
"(%" PRIu64 " bytes), "
"falling back to AXFR",
jsize, dbsize);
```
...perhaps all the way to `ISC_LOG_INFO`. It's not helpful for this to be a mysterious black box. Spurious AXFR fallbacks could be caused by a still-undetected corruption in the journal file, or a computational error counting the size of the database or the journal transactions, and without debug logging, or a full before-and-after copy of the database and journal, it's difficult to sort out which it is.August 2022 (9.16.32, 9.16.32-S1, 9.18.6, 9.19.4)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2685max-ixfr-ratio appears to be forcing AXFR very prematurely on BIND 9.16.152021-05-28T10:26:15ZCathy Almondmax-ixfr-ratio appears to be forcing AXFR very prematurely on BIND 9.16.15We have three reports of problems with authoritative servers frequently (most of the time) responding with AXFR instead of the requested IXFR since updating to BIND 9.16.15. In two of the cases (we have not yet received results from the...We have three reports of problems with authoritative servers frequently (most of the time) responding with AXFR instead of the requested IXFR since updating to BIND 9.16.15. In two of the cases (we have not yet received results from the third), disabling max-ixfr-ratio returned the servers to their expected behaviour:
`max-ixfr-ratio unlimited;`
The symptom appears to be a problem in the calculation of the comparative sizes of zone and incremental update - although it may turn out to be an issue with .jnl file format (each increment header carries the 'size' of the update), or with the the way that the size of the zone itself is determined. In at least one case, the zone involved is very large.June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/26869.16.15 authoritative-only server problem with managed-keys.bind and managed-...2022-10-28T08:35:49ZCathy Almond9.16.15 authoritative-only server problem with managed-keys.bind and managed-keys.bind.jnlAfter upgrading from a BIND 9.11 to BIND 9.16.15, on an authoritative-only server, the managed-keys directory seems to be acquiring a proliferation of randomly-named files:
```
-rw-r--r-- 1 exampgrp examp 388 May 4 19:00 db-3yL0fLNf
-...After upgrading from a BIND 9.11 to BIND 9.16.15, on an authoritative-only server, the managed-keys directory seems to be acquiring a proliferation of randomly-named files:
```
-rw-r--r-- 1 exampgrp examp 388 May 4 19:00 db-3yL0fLNf
-rw-r--r-- 1 exampgrp examp 388 May 4 15:00 db-4adyLhrt
-rw-r--r-- 1 exampgrp examp 388 May 5 03:00 db-7cCsPU4J
-rw-r--r-- 1 exampgrp examp 388 May 4 23:00 db-b3WBFwr6
-rw-r--r-- 1 exampgrp examp 388 May 5 15:00 db-SrQjIXGa
-rw-r--r-- 1 exampgrp examp 388 May 5 11:00 db-TJOlU34F
-rw-r--r-- 1 exampgrp examp 388 May 5 07:00 db-Ye1zfBJ6
-rw-r--r-- 1 exampgrp examp 2184 May 4 15:00 jn-gxAa8SHH
-rw-r--r-- 1 exampgrp examp 2184 May 4 23:00 jn-icq7YhrW
-rw-r--r-- 1 exampgrp examp 2184 May 5 15:00 jn-k7K4TU56
-rw-r--r-- 1 exampgrp examp 2184 May 5 03:00 jn-UCuOnEb5
-rw-r--r-- 1 exampgrp examp 2184 May 5 07:00 jn-UOSzEplT
-rw-r--r-- 1 exampgrp examp 2184 May 4 19:00 jn-xzjQr64l
-rw-r--r-- 1 exampgrp examp 2184 May 5 11:00 jn-zS215QN1
-rw-r--r-- 1 exampgrp examp 388 May 5 16:20 managed-keys.bind
-rw-r--r-- 1 exampgrp examp 1697 May 5 16:20 managed-keys.bind.jnl
```
What is unusual about this server is that it cannot reach the Internet (it is used for provisioning only). It has no client-based recursive role, and has nothing in named.conf relating to dnssec-validation.
When upgrading from BIND 9.11 to BIND 9.16, the default changed from `dnssec-validation yes;` (which does nothing without a manually-configured trust anchor) to `dnssec-validation auto;`. This uses the built-on root trust anchor, which it then attempts to refresh.
Disabling dnssec-validation resolves the problem on this server, but it looks as if there is an unexpected edge case in named's behaviour nevertheless, to do with the zone database and associated jnl file that are being used to keep track of any root trust anchor changes.
Here's what is logged, that is generating these temporary backup db and jn files:
```
06-May-2021 09:40:08.691 general: error: dns_rdata_fromtext: managed-keys/managed-keys.bind:10: near eol: unexpected end of input
06-May-2021 09:40:08.691 zoneload: error: managed-keys-zone: loading from master file managed-keys/managed-keys.bind failed: unexpected end of input
06-May-2021 09:40:08.691 zoneload: error: managed-keys-zone: journal rollforward failed: journal out of sync with zone
06-May-2021 09:40:08.691 general: warning: managed-keys-zone: unable to load from 'managed-keys/managed-keys.bind.jnl'; renaming file to 'managed-keys/jn-chyMHlcj' for failure analysis and retransferring.
06-May-2021 09:40:08.691 general: warning: managed-keys-zone: unable to load from 'managed-keys/managed-keys.bind'; renaming file to 'managed-keys/db-uDFb1cWj' for failure analysis and retransferring.
```
Along with:
```
06-May-2021 09:40:08.691 dnssec: error: managed-keys-zone: failed to initialize managed-keys (out of range): DNSSEC validation is at risk
```
This happens every 4 hours (just as named is restarted as it happens, although named is restarted much more often than this - every 10 minutes on this server - a quirk of the provisioning strategy).
In addition, as named is restarted (every 10 minutes or so), we see this being logged, but without the temporary db and jn files being created:
```
05-May-2021 10:20:08.227 zoneload: error: managed-keys-zone: loading from master file managed-keys/managed-keys.bind failed: unexpected end of input
05-May-2021 10:20:08.228 zoneload: info: managed-keys-zone: loaded serial 4
```
Meanwhile (and apart from the variants in the SOA), this is what's in both managed-keys.bind, and in the various temporary copies of it:
```
$ORIGIN .
$TTL 0 ; 0 seconds
@ IN SOA . . (
17 ; serial
0 ; refresh (0 seconds)
0 ; retry (0 seconds)
0 ; expire (0 seconds)
0 ; minimum (0 seconds)
)
KEYDATA 20210506172018 19700101000000 19700101000000 0 0 0 (
) ; ZSK; alg = 0; key id = 0
; next refresh: Thu, 06 May 2021 17:20:18 GMT
; no trust
```
The situation is anyway broken (really, don't enable DNSSEC validation on a server that cannot reach the Internet and that doesn't need to do recursion!), but I'm opening this issue in case anyone else encounters the same problem. There may also be some edge-case management of .jnl file formats that need to be sorted out?
Details and uploaded files available in [Support Ticket #18475](https://support.isc.org/Ticket/Display.html?id=18475)July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)https://gitlab.isc.org/isc-projects/bind9/-/issues/2687Adding CNAME record restarts named service2021-05-11T10:45:12Zsuhajda3Adding CNAME record restarts named service<!--
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
When adding the following CNAME record makes the named service restart
### BIND version used
BIND 9.10.3
### Steps to reproduce
Create a CNAME record that points to the following address: d-3uxpxr28ik.execute-api.eu-central-1.amazonaws.com
### What is the current *bug* behavior?
Named service automatically restarts, CNAME record not created
### What is the expected *correct* behavior?
Add the specified CNAME record
### Relevant configuration files
api 3600 CNAME d-3uxpxr28ik.execute-api.eu-central-1.amazonaws.com.
### Relevant logs and/or screenshots
ns.mydomain.com - 11.05.2021-10:39 - WARNING - Writing BIND domain file failed: /etc/bind/pri.mydomain.com dns_master_load: /etc/bind/pri.mydomain.com:19: api.mydomain.com: CNAME and other data zone mydomain.com/IN: loading from master file /etc/bind/pri.mydomain.com failed: CNAME and other data zone mydomain.com/IN: not loaded due to errors.https://gitlab.isc.org/isc-projects/bind9/-/issues/2688CID 331478: Null pointer dereferences (FORWARD_NULL)2021-05-19T07:07:12ZMichal NowakCID 331478: Null pointer dereferences (FORWARD_NULL)This seems to be a result of 3e6fc49c165c203b3d2c3c58b93bcb18d18fcf40:
```
*** CID 331478: Null pointer dereferences (FORWARD_NULL)
/lib/dns/keymgr.c: 1731 in keymgr_key_rollover()
1725 /* It is time to do key rollover, we need a...This seems to be a result of 3e6fc49c165c203b3d2c3c58b93bcb18d18fcf40:
```
*** CID 331478: Null pointer dereferences (FORWARD_NULL)
/lib/dns/keymgr.c: 1731 in keymgr_key_rollover()
1725 /* It is time to do key rollover, we need a new key. */
1726
1727 /*
1728 * If rollover is not allowed, warn.
1729 */
1730 if (!rollover) {
>>> CID 331478: Null pointer dereferences (FORWARD_NULL)
>>> Dereferencing null pointer "active_key".
1731 dst_key_format(active_key->key, keystr, sizeof(keystr));
1732 isc_log_write(dns_lctx, DNS_LOGCATEGORY_DNSSEC,
1733 DNS_LOGMODULE_DNSSEC, ISC_LOG_WARNING,
1734 "keymgr: DNSKEY %s (%s) is offline in policy %s, "
1735 "cannot start rollover",
1736 keystr, keymgr_keyrole(active_key->key),
```June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2689CID 331477: Resource leaks (RESOURCE_LEAK)2021-05-24T13:55:09ZMichal NowakCID 331477: Resource leaks (RESOURCE_LEAK)This seems to be a result of fa05c1b8da1ee9dfe5b005a00edf8178c2e884d4:
```
*** CID 331477: Resource leaks (RESOURCE_LEAK)
/lib/dns/dst_api.c: 653 in dst_key_fromnamedfile()
647 return (ISC_R_SUCCESS);
648 }
649
650 ...This seems to be a result of fa05c1b8da1ee9dfe5b005a00edf8178c2e884d4:
```
*** CID 331477: Resource leaks (RESOURCE_LEAK)
/lib/dns/dst_api.c: 653 in dst_key_fromnamedfile()
647 return (ISC_R_SUCCESS);
648 }
649
650 result = algorithm_status(pubkey->key_alg);
651 if (result != ISC_R_SUCCESS) {
652 dst_key_free(&pubkey);
>>> CID 331477: Resource leaks (RESOURCE_LEAK)
>>> Variable "statefilename" going out of scope leaks the storage it points to.
653 return (result);
654 }
655
656 key = get_key_struct(pubkey->key_name, pubkey->key_alg,
657 pubkey->key_flags, pubkey->key_proto,
658 pubkey->key_size, pubkey->key_class,
```June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2690Remove Windows support for BIND 9.17/9.18+2022-01-21T13:43:04ZOndřej SurýRemove Windows support for BIND 9.17/9.18+This is a tracking issue to remove the Windows port from BIND 9 source code for the next stable release.This is a tracking issue to remove the Windows port from BIND 9 source code for the next stable release.July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2691Remove native PKCS#11 support from BIND 9.17/9.18+2022-01-19T11:20:49ZOndřej SurýRemove native PKCS#11 support from BIND 9.17/9.18+This a tracking issue to remove the native PKCS#11 implementation from BIND 9 source code (including the documentation).This a tracking issue to remove the native PKCS#11 implementation from BIND 9 source code (including the documentation).October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2692grep from FreeBSD 13.0 stumbles on '\r' in digdelv test2021-05-17T11:38:35ZMichal Nowakgrep from FreeBSD 13.0 stumbles on '\r' in digdelv testgrep from FreeBSD 13.0 stumbles on `\r` in the digdelv system test:
```
I:digdelv:check that dig +bufsize=0 +edns sends EDNS with bufsize of 0 (81)
grep: trailing backslash (\)
I:digdelv:failed
```
This is because, according to FreeBSD 1...grep from FreeBSD 13.0 stumbles on `\r` in the digdelv system test:
```
I:digdelv:check that dig +bufsize=0 +edns sends EDNS with bufsize of 0 (81)
grep: trailing backslash (\)
I:digdelv:failed
```
This is because, according to FreeBSD 13.0 [release notes](https://www.freebsd.org/releases/13.0R/relnotes/), FreeBSD 13.0 uses BSD grep instead of GNU grep:
> The BSD version of grep(1) is now installed by default. The obsolete GNU version that was the previous default has been removed. 8aff76fb37b5, 47d1ad2413da
Which also recently dropped support for escape codes:
> The regex(3) function no longer accepts redundant escapes for most ordinary characters. This will cause applications such as sed(1) and grep(1) to reject regular expressions using these escapes. adeebf4cd47c
```
[newman@freebsd13 ~/bind9/bin/tests/system]$ grep -E 'EDNS:.* udp: 0\r{0,1}$' digdelv/dig.out.test81
grep: trailing backslash (\)
[newman@freebsd13 ~/bind9/bin/tests/system]$ /usr/local/bin/grep -E 'EDNS:.* udp: 0\r{0,1}$' digdelv/dig.out.test81
; EDNS: version: 0, flags:; udp: 0
```
`grep` from FreeBSD [11.4](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1710615#L3401) and [12.2](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1710616#L3486) does not exhibit this problem, because it's actually GNU grep 2.5.
This appears to be the fix:
```patch
diff --git a/bin/tests/system/digdelv/tests.sh b/bin/tests/system/digdelv/tests.sh
index 099e08e87e..9d1f5171d5 100644
--- a/bin/tests/system/digdelv/tests.sh
+++ b/bin/tests/system/digdelv/tests.sh
@@ -975,7 +975,8 @@ if [ -x "$DIG" ] ; then
echo_i "check that dig +bufsize=0 +edns sends EDNS with bufsize of 0 ($n)"
ret=0
dig_with_opts @10.53.0.3 a.example +bufsize=0 +edns +qr > dig.out.test$n 2>&1 || ret=1
- grep -E 'EDNS:.* udp: 0\r{0,1}$' dig.out.test$n > /dev/null|| ret=1
+ pat='EDNS:.* udp: 0{0,1}$'
+ tr -d '\r' < dig.out.test$n | grep -E "$pat" > /dev/null || ret=1
if [ $ret -ne 0 ]; then echo_i "failed"; fi
status=$((status+ret))
```June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2693Add py.test to the list of tested pytest names2021-05-17T09:30:35ZMichal NowakAdd py.test to the list of tested pytest namespytest is not being detected on OpenBSD 6.9:
```
checking for pytest-3... no
checking for py.test-3... no
checking for pytest... no
checking for pytest-pypy... no
configure: WARNING: pytest not found, some system tests will be skipped
``...pytest is not being detected on OpenBSD 6.9:
```
checking for pytest-3... no
checking for py.test-3... no
checking for pytest... no
checking for pytest-pypy... no
configure: WARNING: pytest not found, some system tests will be skipped
```
It works for OpenBSD 6.8:
```
checking for pytest-3... no
checking for py.test-3... /usr/local/bin/py.test-3
```
It seems that pytest was renamed from `py.test-3` to `py.test`. (This might be the [change](https://github.com/openbsd/ports/commit/248932be7402afca2547890b0036909453504f48).)
The `configure.ac` check needs to be updated to detect `py.test`:
```
checking for pytest-3... no
checking for py.test... /usr/local/bin/py.test
```
This works:
```patch
diff --git a/configure.ac b/configure.ac
index 2518969534..9157c8bc01 100644
--- a/configure.ac
+++ b/configure.ac
@@ -303,7 +303,7 @@ AM_CONDITIONAL([HAVE_PERLMOD_TIME_HIRES],
AM_PATH_PYTHON([3.4], [], [:])
AM_CONDITIONAL([HAVE_PYTHON], [test "$PYTHON" != ":"])
-AC_PATH_PROGS([PYTEST], [pytest-3 py.test-3 pytest pytest-pypy], [])
+AC_PATH_PROGS([PYTEST], [pytest-3 py.test py.test-3 pytest pytest-pypy], [])
AS_IF([test -z "$PYTEST"],
[AC_MSG_WARN([pytest not found, some system tests will be skipped])])
AC_SUBST([PYTEST])
```June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2694Drop seq command from views/tests.sh2021-05-19T14:56:20ZMichal NowakDrop seq command from views/tests.sh`seq` is not present on OpenBSD and should be replaced with something else.
```
bin/tests/system/views/tests.sh:for i in `seq 1 50`; do
````seq` is not present on OpenBSD and should be replaced with something else.
```
bin/tests/system/views/tests.sh:for i in `seq 1 50`; do
```June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2695Launchpad PPA for Ubuntu 21.04 (Hirsute Hippo)2021-06-09T15:18:42ZTobias GüntherLaunchpad PPA for Ubuntu 21.04 (Hirsute Hippo)Similar to https://gitlab.isc.org/isc-projects/bind9/-/issues/1294 and https://gitlab.isc.org/isc-projects/bind9/-/issues/1801 I would like to request the release in the repository for the now released Ubuntu 21.04 codenamed: "hirsute hi...Similar to https://gitlab.isc.org/isc-projects/bind9/-/issues/1294 and https://gitlab.isc.org/isc-projects/bind9/-/issues/1801 I would like to request the release in the repository for the now released Ubuntu 21.04 codenamed: "hirsute hippo"
Again, thanks for the great work!
Are these kind of "Issues" desired, or is this tracked already somewhere ?July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2696Misleading diagnostic in update_soa_serial indicates BIND will use increment ...2021-05-24T13:58:17ZJP MensMisleading diagnostic in update_soa_serial indicates BIND will use increment but it doesn'tIt seems to me there's a misleading (or inaccurate) diagnostic reported by BIND 9.17.11 configured with inline-signing:
```
zone "example" IN {
type master;
file "example";
auto-dnssec maintain;
inline-s...It seems to me there's a misleading (or inaccurate) diagnostic reported by BIND 9.17.11 configured with inline-signing:
```
zone "example" IN {
type master;
file "example";
auto-dnssec maintain;
inline-signing yes;
serial-update-method date;
};
```
Upon launching named in the foreground (`named -g`) it reports the new serial would be lower than old serial, but I don't see that occurring.
Here named loads the unsigned zone with SOA serial `1`:
```
14-May-2021 12:46:23.485 zone example/IN (unsigned): loaded serial 1
14-May-2021 12:42:33.648 zone example/IN (signed): loaded serial 1
14-May-2021 12:42:33.649 zone example/IN (signed): receive_secure_serial: unchanged
14-May-2021 12:42:33.649 zone example/IN (signed): reconfiguring zone keys
14-May-2021 12:42:33.655 zone example/IN (signed): next key event: 14-May-2021 13:42:33.649
14-May-2021 12:42:33.662 zone example/IN (signed): update_soa_serial:new serial would be lower than old serial, using increment method instead
```
Querying the SOA, I see a reasonable-looking SOA serial:
```
example. 86400 IN SOA localhost. jp. 2021051401 10800 3600 604800 3600
```
When the unsigned zone is loaded with serial `2021051483`, the following diagnostic message is printed:
```
14-May-2021 12:44:41.265 zone example/IN (unsigned): loaded serial 2021051483
14-May-2021 12:44:41.266 zone example/IN (signed): loaded serial 2021051483
14-May-2021 12:44:41.267 zone example/IN (signed): receive_secure_serial: unchanged
14-May-2021 12:44:41.269 zone example/IN (signed): update_soa_serial:new serial would be lower than old serial, using increment method instead
14-May-2021 12:44:41.272 zone example/IN (signed): next key event: 14-May-2021 13:44:41.267
14-May-2021 12:44:41.279 zone example/IN (signed): update_soa_serial:new serial would be lower than old serial, using increment method instead
```
and querying that zone's SOA shows me:
```
example. 86400 IN SOA localhost. jp. 2021051485 10800 3600 604800 3600
```
In both cases the value I specified as SOA serial in the unsigned zone has been correctly set to a date.June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2697Further taskmgr refactoring2022-03-01T09:56:48ZOndřej SurýFurther taskmgr refactoringJust dumping notes/ideas:
* schedule events directly onto the worker loops, not tasks
* thus events will have to attach to task (or just reference count running events)
* as the last event schedule conditional task cleanup (move the logi...Just dumping notes/ideas:
* schedule events directly onto the worker loops, not tasks
* thus events will have to attach to task (or just reference count running events)
* as the last event schedule conditional task cleanup (move the logic from task_run there)
* use isc_queue_t to store task events instead of locked LIST to remove contention
This should further simplify the taskmgr logic.Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2698Issues with cppcheck 2.4.1, 2.52022-01-11T14:25:31ZMichał KępieńIssues with cppcheck 2.4.1, 2.5cppcheck 2.4.1 is now available, but, while it fixes one of the issues
with cppcheck 2.3, it also introduces a new set of false positives we
would have to deal with. IMHO we should skip updating to this version
for the time being.
---
...cppcheck 2.4.1 is now available, but, while it fixes one of the issues
with cppcheck 2.3, it also introduces a new set of false positives we
would have to deal with. IMHO we should skip updating to this version
for the time being.
---
cppcheck 2.4.1 triggers the following type of false positives:
```
lib/isc/netaddr.c:274:8: warning: The address of local variable 'in' might be accessed at non-zero index. [objectIndex]
if (p[i] != 0xFF) {
^
lib/isc/netaddr.c:263:30: note: Address of variable taken here.
p = (const unsigned char *)&s->type.in;
^
lib/isc/netaddr.c:274:8: note: The address of local variable 'in' might be accessed at non-zero index.
if (p[i] != 0xFF) {
^
```
The affected files are:
- `bin/dnssec/dnssec-cds.c`
- `lib/dns/ecs.c`
- `lib/dns/resolver.c`
- `lib/isc/netaddr.c`
- `lib/ns/client.c`
It seems that cppcheck gets confused about data sizes when structure
pointers are explicitly cast.
Multiple upstream reports about similar issues are already opened:
- https://trac.cppcheck.net/ticket/10133
- https://trac.cppcheck.net/ticket/10213
- https://trac.cppcheck.net/ticket/10154
- https://trac.cppcheck.net/ticket/10156
None of the above problems have yet been resolved in cppcheck's `main`
branch, therefore I did not bother to create yet another upstream issue
for this. I suggest we wait and see what happens in future cppcheck
releases.
---
[Upstream commit c267d85640523c045c7d43ba7ce9c0f305423c5d][1] triggers
the following type of false positives:
```
lib/isc/base64.c:119:10: warning: Either the condition 'ctx->digits==4' is redundant or the array 'ctx->val[4]' is accessed at index 4, which is out of bounds. [arrayIndexOutOfBoundsCond]
ctx->val[ctx->digits++] = (int)(s - base64);
^
lib/isc/base64.c:120:18: note: Assuming that condition 'ctx->digits==4' is not redundant
if (ctx->digits == 4) {
^
lib/isc/base64.c:119:10: note: Array index out of bounds
ctx->val[ctx->digits++] = (int)(s - base64);
^
```
The affected files are:
- `lib/isc/base64.c`
- `lib/isc/base32.c`
- `lib/isc/hex.c`
I [reported this upstream][2] because it is still not addressed in
cppcheck's development branch.
[1]: https://github.com/danmar/cppcheck/commit/c267d85640523c045c7d43ba7ce9c0f305423c5d
[2]: https://sourceforge.net/p/cppcheck/discussion/general/thread/128272da00/January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2699RNDC - how feasible is it to have it report when a change needs a daemon rest...2021-05-17T12:58:50ZChuck StearnsRNDC - how feasible is it to have it report when a change needs a daemon restart?### Description
Changes made with rndc affect the running config, but some changes still require a daemon restart in order to take effect, but there is no reporting of that in rndc's output.
### Request
Perhaps a stderr or part of `rn...### Description
Changes made with rndc affect the running config, but some changes still require a daemon restart in order to take effect, but there is no reporting of that in rndc's output.
### Request
Perhaps a stderr or part of `rndc status` suggesting that the running and static configs are in sync and/or whether or not a daemon restart is necessary.
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2700Accepting TCP connection failed: socket is not connected2021-12-02T13:20:43ZChuck StearnsAccepting TCP connection failed: socket is not connectedLatency, dropped connections, and degraded performance through various minor versions of the 9.16 branch.Latency, dropped connections, and degraded performance through various minor versions of the 9.16 branch.December 2021 (9.16.24, 9.16.24-S1, 9.17.21)https://gitlab.isc.org/isc-projects/bind9/-/issues/2701gcc-10+ -fanalyzer reports: dereference of NULL ‘label’ in lib/dns/name.c:11672021-05-18T06:46:15ZOndřej Surýgcc-10+ -fanalyzer reports: dereference of NULL ‘label’ in lib/dns/name.c:1167Full report:
```
name.c: In function ‘dns_name_fromtext’:
name.c:1167:40: error: dereference of NULL ‘label’ [CWE-476] [-Werror=analyzer-null-dereference]
1167 | *label = count;
| ...Full report:
```
name.c: In function ‘dns_name_fromtext’:
name.c:1167:40: error: dereference of NULL ‘label’ [CWE-476] [-Werror=analyzer-null-dereference]
1167 | *label = count;
| ~~~~~~~^~~~~~~
‘dns_name_fromstring’: events 1-2
|
| 2429 | dns_name_fromstring(dns_name_t *target, const char *src, unsigned int options,
| | ^~~~~~~~~~~~~~~~~~~
| | |
| | (1) entry to ‘dns_name_fromstring’
| 2430 | isc_mem_t *mctx) {
| 2431 | return (dns_name_fromstring2(target, src, dns_rootname, options, mctx));
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (2) calling ‘dns_name_fromstring2’ from ‘dns_name_fromstring’
|
+--> ‘dns_name_fromstring2’: event 3
|
| 2435 | dns_name_fromstring2(dns_name_t *target, const char *src,
| | ^~~~~~~~~~~~~~~~~~~~
| | |
| | (3) entry to ‘dns_name_fromstring2’
|
‘dns_name_fromstring2’: event 4
|
|../../lib/isc/include/isc/util.h:287:20:
| 287 | #define REQUIRE(e) assert(e)
| | ^~~~~~
| | |
| | (4) following ‘true’ branch (when ‘src’ is non-NULL)...
name.c:2443:9: note: in expansion of macro ‘REQUIRE’
| 2443 | REQUIRE(src != NULL);
| | ^~~~~~~
|
‘dns_name_fromstring2’: event 5
|
|../../lib/isc/include/isc/buffer.h:1051:9:
| 1051 | do { \
| | ^~
| | |
| | (5) ...to here
name.c:2445:9: note: in expansion of macro ‘isc_buffer_constinit’
| 2445 | isc_buffer_constinit(&buf, src, strlen(src));
| | ^~~~~~~~~~~~~~~~~~~~
|
‘dns_name_fromstring2’: event 6
|
| 2453 | result = dns_name_fromtext(name, &buf, origin, options, NULL);
| | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (6) calling ‘dns_name_fromtext’ from ‘dns_name_fromstring2’
|
+--> ‘dns_name_fromtext’: event 7
|
| 1057 | dns_name_fromtext(dns_name_t *name, isc_buffer_t *source,
| | ^~~~~~~~~~~~~~~~~
| | |
| | (7) entry to ‘dns_name_fromtext’
|
‘dns_name_fromtext’: event 8
|
|../../lib/isc/include/isc/util.h:287:20:
| 287 | #define REQUIRE(e) assert(e)
| | ^~~~~~
| | |
| | (8) following ‘true’ branch...
name.c:1082:9: note: in expansion of macro ‘REQUIRE’
| 1082 | REQUIRE(VALID_NAME(name));
| | ^~~~~~~
|
‘dns_name_fromtext’: event 9
|
|../../lib/isc/include/isc/util.h:287:20:
| 287 | #define REQUIRE(e) assert(e)
| | ^~~~~~
| | |
| | (9) ...to here
name.c:1083:9: note: in expansion of macro ‘REQUIRE’
| 1083 | REQUIRE(ISC_BUFFER_VALID(source));
| | ^~~~~~~
|
‘dns_name_fromtext’: event 10
|
|../../lib/isc/include/isc/util.h:287:20:
| 287 | #define REQUIRE(e) assert(e)
| | ^~~~~~
| | |
| | (10) following ‘true’ branch...
name.c:1083:9: note: in expansion of macro ‘REQUIRE’
| 1083 | REQUIRE(ISC_BUFFER_VALID(source));
| | ^~~~~~~
|
‘dns_name_fromtext’: event 11
|
|../../lib/isc/include/isc/util.h:287:20:
| 287 | #define REQUIRE(e) assert(e)
| | ^~~~~~
| | |
| | (11) ...to here
name.c:1084:9: note: in expansion of macro ‘REQUIRE’
| 1084 | REQUIRE((target != NULL && ISC_BUFFER_VALID(target)) ||
| | ^~~~~~~
|
‘dns_name_fromtext’: event 12
|
|../../lib/isc/include/isc/util.h:287:20:
| 287 | #define REQUIRE(e) assert(e)
| | ^~~~~~
| | |
| | (12) following ‘false’ branch (when ‘target’ is NULL)...
name.c:1084:9: note: in expansion of macro ‘REQUIRE’
| 1084 | REQUIRE((target != NULL && ISC_BUFFER_VALID(target)) ||
| | ^~~~~~~
|
‘dns_name_fromtext’: event 13
|
| 1084 | REQUIRE((target != NULL && ISC_BUFFER_VALID(target)) ||
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
| | |
| | (13) ...to here
| 1085 | (target == NULL && ISC_BUFFER_VALID(name->buffer)));
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
name.c:1084:9: note: in expansion of macro ‘REQUIRE’
| 1084 | REQUIRE((target != NULL && ISC_BUFFER_VALID(target)) ||
| | ^~~~~~~
|
‘dns_name_fromtext’: event 14
|
| 1084 | REQUIRE((target != NULL && ISC_BUFFER_VALID(target)) ||
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
| | |
| | (14) following ‘true’ branch...
| 1085 | (target == NULL && ISC_BUFFER_VALID(name->buffer)));
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
name.c:1084:9: note: in expansion of macro ‘REQUIRE’
| 1084 | REQUIRE((target != NULL && ISC_BUFFER_VALID(target)) ||
| | ^~~~~~~
|
‘dns_name_fromtext’: events 15-17
|
| 1087 | downcase = ((options & DNS_NAME_DOWNCASE) != 0);
| | ^~~~~~~~
| | |
| | (15) ...to here
| 1088 |
| 1089 | if (target == NULL && name->buffer != NULL) {
| | ~
| | |
| | (16) following ‘true’ branch...
| 1090 | target = name->buffer;
| | ~~~~~~
| | |
| | (17) ...to here
|
‘dns_name_fromtext’: event 18
|
|../../lib/isc/include/isc/util.h:287:20:
| 287 | #define REQUIRE(e) assert(e)
| | ^~~~~~
| | |
| | (18) following ‘true’ branch...
name.c:1094:9: note: in expansion of macro ‘REQUIRE’
| 1094 | REQUIRE(BINDABLE(name));
| | ^~~~~~~
|
‘dns_name_fromtext’: event 19
|
| 96 | if ((name)->offsets != NULL) \
| | ^~
| | |
| | (19) ...to here
name.c:1096:9: note: in expansion of macro ‘INIT_OFFSETS’
| 1096 | INIT_OFFSETS(name, offsets, odata);
| | ^~~~~~~~~~~~
|
‘dns_name_fromtext’: events 20-26
|
| 1120 | while (nrem > 0 && tlen > 0 && !done) {
| | ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
| | |
| | (20) following ‘true’ branch...
| | (21) ...to here
| | (22) following ‘false’ branch (when ‘done == 0’)...
| 1121 | c = *tdata++;
| | ~
| | |
| | (23) ...to here
|......
| 1125 | switch (state) {
| | ~~~~~~
| | |
| | (24) following ‘case 0:’ branch...
| 1126 | case ft_init:
| | ~~~~
| | |
| | (25) ...to here
|......
| 1141 | if (c == '@' && tlen == 0) {
| | ~
| | |
| | (26) following ‘true’ branch...
|
‘dns_name_fromtext’: event 27
|
|cc1:
| (27): ...to here
|
‘dns_name_fromtext’: events 28-42
|
|
```June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)https://gitlab.isc.org/isc-projects/bind9/-/issues/2702gcc-10+ -fanalyzer reports:2021-05-18T05:49:37ZOndřej Surýgcc-10+ -fanalyzer reports:```
rbtdb.c: In function ‘previous_closest_nsec’:
rbtdb.c:3714:21: error: dereference of NULL ‘firstp’ [CWE-476] [-Werror=analyzer-null-dereference]
3714 | if (*firstp) {
| ^~~~~~~
‘find_close...```
rbtdb.c: In function ‘previous_closest_nsec’:
rbtdb.c:3714:21: error: dereference of NULL ‘firstp’ [CWE-476] [-Werror=analyzer-null-dereference]
3714 | if (*firstp) {
| ^~~~~~~
‘find_closest_nsec’: events 1-2
|
| 3805 | find_closest_nsec(rbtdb_search_t *search, dns_dbnode_t **nodep,
| | ^~~~~~~~~~~~~~~~~
| | |
| | (1) entry to ‘find_closest_nsec’
|......
| 3842 | if (result != ISC_R_SUCCESS) {
| | ~
| | |
| | (2) following ‘false’ branch (when ‘result == 0’)...
|
‘find_closest_nsec’: event 3
|
|cc1:
| (3): ...to here
|
‘find_closest_nsec’: event 4
|
|../../lib/isc/include/isc/util.h:322:26:
| 322 | #define RUNTIME_CHECK(e) assert(e)
| | ^~~~~~
| | |
| | (4) following ‘true’ branch...
../../lib/isc/include/isc/util.h:162:17: note: in expansion of macro ‘RUNTIME_CHECK’
| 162 | RUNTIME_CHECK(isc_rwlock_lock((lp), (t)) == ISC_R_SUCCESS); \
| | ^~~~~~~~~~~~~
rbtdb.c:167:29: note: in expansion of macro ‘RWLOCK’
| 167 | #define NODE_LOCK(l, t) RWLOCK((l), (t))
| | ^~~~~~
rbtdb.c:3846:17: note: in expansion of macro ‘NODE_LOCK’
| 3846 | NODE_LOCK(&(search->rbtdb->node_locks[node->locknum].lock),
| | ^~~~~~~~~
|
‘find_closest_nsec’: event 5
|
|../../lib/isc/include/isc/util.h:164:71:
| 164 | (lp), (t), __FILE__, __LINE__)); \
| | ^
| | |
| | (5) ...to here
rbtdb.c:167:29: note: in expansion of macro ‘RWLOCK’
| 167 | #define NODE_LOCK(l, t) RWLOCK((l), (t))
| | ^~~~~~
rbtdb.c:3846:17: note: in expansion of macro ‘NODE_LOCK’
| 3846 | NODE_LOCK(&(search->rbtdb->node_locks[node->locknum].lock),
| | ^~~~~~~~~
|
‘find_closest_nsec’: events 6-14
|
| 3851 | for (header = node->data; header != NULL; header = header_next)
| | ^
| | |
| | (6) following ‘true’ branch (when ‘header’ is non-NULL)...
| 3852 | {
| 3853 | header_next = header->next;
| | ~~~~~~~~~~~
| | |
| | (7) ...to here
|......
| 3864 | if (NONEXISTENT(header)) {
| | ~
| | |
| | (8) following ‘false’ branch...
|......
| 3872 | if (header != NULL) {
| | ~~ ~
| | | |
| | | (10) following ‘true’ branch (when ‘header’ is non-NULL)...
| | (9) ...to here
|......
| 3877 | empty_node = false;
| | ~~~~~~~~~~
| | |
| | (11) ...to here
| 3878 | if (header->type == type) {
| | ~
| | |
| | (12) following ‘true’ branch...
| 3879 | found = header;
| | ~~~~~
| | |
| | (13) ...to here
| 3880 | if (foundsig != NULL) {
| | ~
| | |
| | (14) following ‘false’ branch (when ‘foundsig’ is NULL)...
|
‘find_closest_nsec’: event 15
|
|cc1:
| (15): ...to here
|
‘find_closest_nsec’: events 16-20
|
| 3891 | if (!empty_node) {
| | ^
| | |
| | (16) following ‘false’ branch (when ‘empty_node == 0’)...
| 3892 | if (found != NULL && search->rbtversion->havensec3 &&
| | ~~ ~
| | | |
| | | (18) following ‘true’ branch...
| | (17) ...to here
| 3893 | found->type == dns_rdatatype_nsec3 &&
| 3894 | !matchparams(found, search))
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (19) ...to here
| | (20) calling ‘matchparams’ from ‘find_closest_nsec’
|
+--> ‘matchparams’: event 21
|
| 3649 | matchparams(rdatasetheader_t *header, rbtdb_search_t *search) {
| | ^~~~~~~~~~~
| | |
| | (21) entry to ‘matchparams’
|
‘matchparams’: event 22
|
|../../lib/isc/include/isc/util.h:287:20:
| 287 | #define REQUIRE(e) assert(e)
| | ^~~~~~
| | |
| | (22) following ‘true’ branch...
rbtdb.c:3657:9: note: in expansion of macro ‘REQUIRE’
| 3657 | REQUIRE(header->type == dns_rdatatype_nsec3);
| | ^~~~~~~
|
‘matchparams’: event 23
|
| 3659 | raw = (unsigned char *)header + sizeof(*header);
| | ^~~
| | |
| | (23) ...to here
|
<------+
|
‘find_closest_nsec’: events 24-27
|
| 3892 | if (found != NULL && search->rbtversion->havensec3 &&
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 3893 | found->type == dns_rdatatype_nsec3 &&
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (25) following ‘false’ branch...
| 3894 | !matchparams(found, search))
| | ~^~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (24) returning to ‘find_closest_nsec’ from ‘matchparams’
| 3895 | {
| 3896 | empty_node = true;
| | ~~~~~~~~~~
| | |
| | (26) ...to here
|......
| 3899 | result = previous_closest_nsec(
| | ~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (27) calling ‘previous_closest_nsec’ from ‘find_closest_nsec’
| 3900 | type, search, name, origin, &prevnode,
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| 3901 | NULL, NULL);
| | ~~~~~~~~~~~
|
+--> ‘previous_closest_nsec’: event 28
|
| 3690 | previous_closest_nsec(dns_rdatatype_t type, rbtdb_search_t *search,
| | ^~~~~~~~~~~~~~~~~~~~~
| | |
| | (28) entry to ‘previous_closest_nsec’
|
‘previous_closest_nsec’: event 29
|
|../../lib/isc/include/isc/util.h:287:20:
| 287 | #define REQUIRE(e) assert(e)
| | ^~~~~~
| | |
| | (29) following ‘true’ branch...
rbtdb.c:3699:9: note: in expansion of macro ‘REQUIRE’
| 3699 | REQUIRE(nodep != NULL && *nodep == NULL);
| | ^~~~~~~
|
‘previous_closest_nsec’: events 30-33
|
| 3701 | if (type == dns_rdatatype_nsec3) {
| | ^~ ~
| | | |
| | | (31) following ‘false’ branch (when ‘type != 50’)...
| | (30) ...to here
|......
| 3711 | target = dns_fixedname_initname(&ftarget);
| | ~~~~~~
| | |
| | (32) ...to here
|......
| 3714 | if (*firstp) {
| | ~~~~~~~
| | |
| | (33) dereference of NULL ‘firstp’
|
rbtdb.c: In function ‘update_recordsandxfrsize’:
rbtdb.c:6100:37: error: dereference of NULL ‘rbtversion’ [CWE-476] [-Werror=analyzer-null-dereference]
6100 | rbtversion->records += dns_rdataslab_count(hdr, hdrsize);
| ^~
‘add32’: events 1-5
|
| 6113 | add32(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, const dns_name_t *nodename,
| | ^~~~~
| | |
| | (1) entry to ‘add32’
|......
| 6151 | if (rbtversion != NULL && !loading) {
| | ~
| | |
| | (2) following ‘false’ branch...
|......
| 6164 | newheader_nx = NONEXISTENT(newheader) ? true : false;
| | ~~~~~~~~~~~~
| | |
| | (3) ...to here
|......
| 6168 | if (rbtversion == NULL && !newheader_nx) {
| | ~
| | |
| | (4) following ‘true’ branch...
| 6169 | rdtype = RBTDB_RDATATYPE_BASE(newheader->type);
| | ~~~~~~
| | |
| | (5) ...to here
|
‘add32’: events 6-7
|
| 6187 | topheader != NULL;
| | ^
| | |
| | (6) following ‘false’ branch (when ‘topheader’ is NULL)...
|......
| 6192 | goto find_header;
| | ~~~~
| | |
| | (7) ...to here
|
‘add32’: events 8-20
|
| 6275 | while (header != NULL && IGNORE(header)) {
| | ^
| | |
| | (8) following ‘false’ branch (when ‘header’ is NULL)...
|......
| 6278 | if (header != NULL) {
| | ~~ ~
| | | |
| | | (10) following ‘false’ branch (when ‘header’ is NULL)...
| | (9) ...to here
|......
| 6584 | if (newheader_nx) {
| | ~~ ~
| | | |
| | | (12) following ‘false’ branch...
| | (11) ...to here
|......
| 6589 | idx = newheader->node->locknum;
| | ~~~
| | |
| | (13) ...to here
|......
| 6604 | } else if (RESIGN(newheader)) {
| | ~
| | |
| | (14) following ‘false’ branch...
|......
| 6614 | if (topheader != NULL) {
| | ~~ ~
| | | |
| | | (16) following ‘false’ branch (when ‘topheader’ is NULL)...
| | (15) ...to here
|......
| 6642 | newheader->next = rbtnode->data;
| | ~~~~~~~~~
| | |
| | (17) ...to here
|......
| 6648 | if (rbtversion != NULL && !newheader_nx) {
| | ~
| | |
| | (18) following ‘true’ branch...
| 6649 | update_recordsandxfrsize(true, rbtversion, newheader,
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (19) ...to here
| | (20) calling ‘update_recordsandxfrsize’ from ‘add32’
| 6650 | nodename->length);
| | ~~~~~~~~~~~~~~~~~
|
+--> ‘update_recordsandxfrsize’: event 21
|
| 6093 | update_recordsandxfrsize(bool add, rbtdb_version_t *rbtversion,
| | ^~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (21) entry to ‘update_recordsandxfrsize’
|
‘update_recordsandxfrsize’: event 22
|
|../../lib/isc/include/isc/util.h:322:26:
| 322 | #define RUNTIME_CHECK(e) assert(e)
| | ^~~~~~
| | |
| | (22) following ‘true’ branch...
../../lib/isc/include/isc/util.h:162:17: note: in expansion of macro ‘RUNTIME_CHECK’
| 162 | RUNTIME_CHECK(isc_rwlock_lock((lp), (t)) == ISC_R_SUCCESS); \
| | ^~~~~~~~~~~~~
rbtdb.c:6098:9: note: in expansion of macro ‘RWLOCK’
| 6098 | RWLOCK(&rbtversion->rwlock, isc_rwlocktype_write);
| | ^~~~~~
|
‘update_recordsandxfrsize’: event 23
|
|../../lib/isc/include/isc/util.h:164:71:
| 164 | (lp), (t), __FILE__, __LINE__)); \
| | ^
| | |
| | (23) ...to here
rbtdb.c:6098:9: note: in expansion of macro ‘RWLOCK’
| 6098 | RWLOCK(&rbtversion->rwlock, isc_rwlocktype_write);
| | ^~~~~~
|
‘update_recordsandxfrsize’: events 24-26
|
| 6099 | if (add) {
| | ^
| | |
| | (24) following ‘true’ branch (when ‘add != 0’)...
| 6100 | rbtversion->records += dns_rdataslab_count(hdr, hdrsize);
| | ~~~~~~~~~~ ~~
| | | |
| | | (26) dereference of NULL ‘rbtversion’
| | (25) ...to here
|
In file included from ../../lib/isc/include/isc/util.h:14,
from rbtdb.c:40:
rbtdb.c: In function ‘add32’:
rbtdb.c:6321:42: error: dereference of NULL ‘rbtversion’ [CWE-476] [-Werror=analyzer-null-dereference]
6321 | INSIST(rbtversion->serial >= header->serial);
| ~~~~~~~~~~^~~~~~~~
rbtdb.c:6321:25: note: in expansion of macro ‘INSIST’
6321 | INSIST(rbtversion->serial >= header->serial);
| ^~~~~~
‘add32’: events 1-8
|
| 6151 | if (rbtversion != NULL && !loading) {
| | ^
| | |
| | (1) following ‘false’ branch...
|......
| 6164 | newheader_nx = NONEXISTENT(newheader) ? true : false;
| | ~~~~~~~~~~~~
| | |
| | (2) ...to here
|......
| 6168 | if (rbtversion == NULL && !newheader_nx) {
| | ~
| | |
| | (3) following ‘true’ branch...
| 6169 | rdtype = RBTDB_RDATATYPE_BASE(newheader->type);
| | ~~~~~~
| | |
| | (4) ...to here
|......
| 6172 | if (NEGATIVE(newheader)) {
| | ~
| | |
| | (5) following ‘true’ branch...
|......
| 6176 | if (covers == dns_rdatatype_any) {
| | ~~ ~
| | | |
| | | (7) following ‘false’ branch (when ‘covers != 255’)...
| | (6) ...to here
|......
| 6198 | for (topheader = rbtnode->data; topheader != NULL;
| | ~~~
| | |
| | (8) ...to here
|
‘add32’: events 9-10
|
| 6198 | for (topheader = rbtnode->data; topheader != NULL;
| | ^
| | |
| | (9) following ‘true’ branch (when ‘topheader’ is non-NULL)...
| 6199 | topheader = topheader->next) {
| 6200 | if (topheader->type == sigtype) {
| | ~~
| | |
| | (10) ...to here
|
‘add32’: events 11-20
|
| 6275 | while (header != NULL && IGNORE(header)) {
| | ^
| | |
| | (11) following ‘false’ branch...
|......
| 6278 | if (header != NULL) {
| | ~~ ~
| | | |
| | | (13) following ‘true’ branch (when ‘header’ is non-NULL)...
| | (12) ...to here
| 6279 | header_nx = NONEXISTENT(header) ? true : false;
| | ~~~~~~~~~
| | |
| | (14) ...to here
|......
| 6284 | if (header_nx && newheader_nx) {
| | ~
| | |
| | (15) following ‘false’ branch...
|......
| 6296 | if (rbtversion == NULL && trust < header->trust &&
| | ~~ ~ ~~~~~~~~~~~~~
| | | | |
| | | | (18) ...to here
| | | (17) following ‘true’ branch (when ‘rbtversion’ is NULL)...
| | (16) ...to here
|......
| 6319 | if (merge) {
| | ~
| | |
| | (19) following ‘true’ branch (when ‘merge != 0’)...
| 6320 | unsigned int flags = 0;
| | ~~~~~~~~
| | |
| | (20) ...to here
|
‘add32’: event 21
|
| 6321 | INSIST(rbtversion->serial >= header->serial);
| | ~~~~~~~~~~^~~~~~~~
| | |
| | (21) dereference of NULL ‘rbtversion’
rbtdb.c:6321:25: note: in expansion of macro ‘INSIST’
| 6321 | INSIST(rbtversion->serial >= header->serial);
| | ^~~~~~
|
```June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)https://gitlab.isc.org/isc-projects/bind9/-/issues/2703gcc-10+ -fanalyzer reports dereference of NULL ‘text’ in server.c:147212021-07-14T19:15:38ZOndřej Surýgcc-10+ -fanalyzer reports dereference of NULL ‘text’ in server.c:14721```
server.c:14721:35: error: dereference of NULL ‘text’ [CWE-476] [-Werror=analyzer-null-dereference]
14721 | if (isc_buffer_usedlength(*text) > 0) {
../../lib/isc/include/isc/buffer.h:160:41: note: in definition of macro ‘isc_b...```
server.c:14721:35: error: dereference of NULL ‘text’ [CWE-476] [-Werror=analyzer-null-dereference]
14721 | if (isc_buffer_usedlength(*text) > 0) {
../../lib/isc/include/isc/buffer.h:160:41: note: in definition of macro ‘isc_buffer_usedlength’
160 | #define isc_buffer_usedlength(b) ((b)->used) /* d-a */
| ^
‘named_server_showzone’: event 1
|
|server.c:14633:1:
|14633 | named_server_showzone(named_server_t *server, isc_lex_t *lex,
| | ^~~~~~~~~~~~~~~~~~~~~
| | |
| | (1) entry to ‘named_server_showzone’
|
‘named_server_showzone’: event 2
|
|14649 | CHECK(zone_from_args(server, lex, NULL, &zone, zonename, text, true));
| | ^
| | |
| | (2) calling ‘zone_from_args’ from ‘named_server_showzone’
server.c:191:27: note: in definition of macro ‘CHECK’
| 191 | result = (op); \
| | ^~
|
+--> ‘zone_from_args’: event 3
|
|10671 | zone_from_args(named_server_t *server, isc_lex_t *lex, const char *zonetxt,
| | ^~~~~~~~~~~~~~
| | |
| | (3) entry to ‘zone_from_args’
|
‘zone_from_args’: event 4
|
|../../lib/isc/include/isc/util.h:287:20:
| 287 | #define REQUIRE(e) assert(e)
| | ^~~~~~
| | |
| | (4) following ‘true’ branch...
server.c:10686:9: note: in expansion of macro ‘REQUIRE’
|10686 | REQUIRE(zonep != NULL && *zonep == NULL);
| | ^~~~~~~
|
‘zone_from_args’: events 5-8
|
|10688 | if (skip) {
| | ^~ ~
| | | |
| | | (6) following ‘true’ branch (when ‘skip != 0’)...
| | (5) ...to here
|10689 | /* Skip the command name. */
|10690 | ptr = next_token(lex, text);
| | ~~~ ~~~~~~~~~~~~~~~~~~~~~
| | | |
| | | (8) calling ‘next_token’ from ‘zone_from_args’
| | (7) ...to here
|
+--> ‘next_token’: events 9-11
|
|10619 | next_token(isc_lex_t *lex, isc_buffer_t **text) {
| | ^~~~~~~~~~
| | |
| | (9) entry to ‘next_token’
|......
|10639 | (void)putnull(text);
| | ~~~~~~~~~~~~~
| | |
| | (11) ...to here
|......
|10643 | if (text != NULL) {
| | ~
| | |
| | (10) following ‘false’ branch (when ‘text’ is NULL)...
|
<------+
|
‘zone_from_args’: events 12-13
|
|10690 | ptr = next_token(lex, text);
| | ^~~~~~~~~~~~~~~~~~~~~
| | |
| | (12) returning to ‘zone_from_args’ from ‘next_token’
|10691 | if (ptr == NULL) {
| | ~
| | |
| | (13) following ‘true’ branch (when ‘ptr’ is NULL)...
|
‘zone_from_args’: event 14
|
|cc1:
| (14): ...to here
|
<------+
|
‘named_server_showzone’: event 15
|
|14649 | CHECK(zone_from_args(server, lex, NULL, &zone, zonename, text, true));
| | ^
| | |
| | (15) returning to ‘named_server_showzone’ from ‘zone_from_args’
server.c:191:27: note: in definition of macro ‘CHECK’
| 191 | result = (op); \
| | ^~
|
‘named_server_showzone’: event 16
|
| 192 | if (result != ISC_R_SUCCESS) \
| | ^
| | |
| | (16) following ‘true’ branch (when ‘result != 0’)...
server.c:14649:9: note: in expansion of macro ‘CHECK’
|14649 | CHECK(zone_from_args(server, lex, NULL, &zone, zonename, text, true));
| | ^~~~~
|
‘named_server_showzone’: event 17
|
| 193 | goto cleanup; \
| | ^~~~
| | |
| | (17) ...to here
server.c:14649:9: note: in expansion of macro ‘CHECK’
|14649 | CHECK(zone_from_args(server, lex, NULL, &zone, zonename, text, true));
| | ^~~~~
|
‘named_server_showzone’: events 18-19
|
|14717 | if (nzconfig != NULL) {
| | ^
| | |
| | (18) following ‘false’ branch...
|......
|14721 | if (isc_buffer_usedlength(*text) > 0) {
| | ~~
| | |
| | (19) ...to here
|
‘named_server_showzone’: event 20
|
|14721 | if (isc_buffer_usedlength(*text) > 0) {
../../lib/isc/include/isc/buffer.h:160:41: note: in definition of macro ‘isc_buffer_usedlength’
| 160 | #define isc_buffer_usedlength(b) ((b)->used) /* d-a */
| | ^
|
```August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)https://gitlab.isc.org/isc-projects/bind9/-/issues/2704Bind9 version 9.17.12 not starting without different DNS server2021-05-26T22:26:34ZDo HeBind9 version 9.17.12 not starting without different DNS serverI tried version **9.17.12** because of the new TLS features.
My _resolv.conf_ only contains the local resolver _127.0.0.1_ and _::1_.
The problem is that the new Bind9 doesn't start without having an alternative resolver in resolv.conf....I tried version **9.17.12** because of the new TLS features.
My _resolv.conf_ only contains the local resolver _127.0.0.1_ and _::1_.
The problem is that the new Bind9 doesn't start without having an alternative resolver in resolv.conf. It looks like something in the Bind9 startup process relies on DNS before itself is serving queries.
The last message in the logfile is:
`named[14264]: managed-keys-zone: Failed to create fetch for DNSKEY update`
After that the Bind9 process is running but doesn't answer queries.
Using the same build with the same config, but with an alternative resolver in _resolv.conf_ starts fine and serves DNS afterwards.
Starting with disabled DNSSEC makes the error message go away, but still spawns an unresponsive DNS resolver.
Thanks for any help.
Dominik
[named.conf](/uploads/100f7b902e9d09630c996a919c014367/named.conf)
[log.txt](/uploads/cdc57d006323edca79cd6817faab78e7/log.txt)June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)https://gitlab.isc.org/isc-projects/bind9/-/issues/2705Bind9 version 9.17.12 TLS capability problem2023-11-21T02:20:30ZDo HeBind9 version 9.17.12 TLS capability problemI tried version **9.17.12** because of the new TLS features.
Assume the following TLS settings in _named.conf_
```
tls mytls {
cert-file "/etc/ssl/example.crt";
key-file "/etc/ssl/example.key";
};
```
Both files are owned by roo...I tried version **9.17.12** because of the new TLS features.
Assume the following TLS settings in _named.conf_
```
tls mytls {
cert-file "/etc/ssl/example.crt";
key-file "/etc/ssl/example.key";
};
```
Both files are owned by root:root and chmod 0600.
```
-rw------- 1 root root 5938 May 14 02:19 example.crt
-rw------- 1 root root 3243 May 14 02:19 example.key
```
Bind9 is started with a `-u bind` parameter.
If compiled with `--disable-linux-caps`:
- named will start
- _rdnc reload_ will fail
If compiled without `--disable-linux-caps`:
- named will not start
In both cases the same error is raised:
```
May 17 21:33:22 s1 named[3596]: Error initializing TLS context: error:0200100D:system library:fopen:Permission denied
May 17 21:33:22 s1 named[3596]: loading configuration: TLS error
```
I know this is due to the privilege drop of the daemon. However both scenarios are uncommon if compared to other relevant Linux software. Especially for the second case with enabled capability support. The privilege drop seems to happen before the certificates are loaded.
However I still want to report this because it's unintuitive in my eyes. My expectation would be:
- Named starts in both scenarios
- _rdnc reload_ works but doesn't trigger a TLS stack reload without the necessary privileges
Thanks for any help.
DominikNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2706worker->cond_prio needs to be initialised2021-05-24T13:56:55ZMark Andrewsworker->cond_prio needs to be initialised```
netmgr/netmgr.c:882: fatal error: 18-May-2021 16:29:07.661 netmgr/netmgr.c:882: fatal error:
netmgr/netmgr.c:882: fatal error: netmgr/netmgr.c:882: fatal error: netmgr/netmgr.c:882: fatal error: netmgr/netmgr.c:882: fatal error: netm...```
netmgr/netmgr.c:882: fatal error: 18-May-2021 16:29:07.661 netmgr/netmgr.c:882: fatal error:
netmgr/netmgr.c:882: fatal error: netmgr/netmgr.c:882: fatal error: netmgr/netmgr.c:882: fatal error: netmgr/netmgr.c:882: fatal error: netmgr/netmgr.c:882: fatal error: RUNTIME_CHECK(((pthread_cond_wait(((cond)), ((&worker->lock))) == 0) ? 0 : 34) == 0) failedRUNTIME_CHECK(((pthread_cond_wait(((cond)), ((&worker->lock))) == 0) ? 0 : 34) == 0) failedRUNTIME_CHECK(((pthread_cond_wait(((cond)), ((&worker->lock))) == 0) ? 0 : 34) == 0) failedRUNTIME_CHECK(((pthread_cond_wait(((cond)), ((&worker->lock))) == 0) ? 0 : 34) == 0) failedRUNTIME_CHECK(((pthread_cond_wait(((cond)), ((&worker->lock))) == 0) ? 0 : 34) == 0) failedRUNTIME_CHECK(((pthread_cond_wait(((cond)), ((&worker->lock))) == 0) ? 0 : 34) == 0) failed18-May-2021 16:29:07.662 max open files (10240) is smaller than max sockets (21000)
18-May-2021 16:29:07.662 RUNTIME_CHECK(((pthread_cond_wait(((cond)), ((&worker->lock))) == 0) ? 0 : 34) == 0) failed
```June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)https://gitlab.isc.org/isc-projects/bind9/-/issues/2707RUNTIME_CHECK(((__libc_cond_wait(((cond)), ((&worker->lock))) == 0) ? 0 : 34)...2021-05-18T09:13:53ZMichal NowakRUNTIME_CHECK(((__libc_cond_wait(((cond)), ((&worker->lock))) == 0) ? 0 : 34) == 0) fail on NetBSD`main` and `v9_16` fail on NetBSD 9.1/9.2 on some unit tests and many system tests (e.g. auth) with:
```
netmgr/netmgr.c:882: fatal error: RUNTIME_CHECK(((__libc_cond_wait(((cond)), ((&worker->lock))) == 0) ? 0 : 34) == 0) failed
```
Th...`main` and `v9_16` fail on NetBSD 9.1/9.2 on some unit tests and many system tests (e.g. auth) with:
```
netmgr/netmgr.c:882: fatal error: RUNTIME_CHECK(((__libc_cond_wait(((cond)), ((&worker->lock))) == 0) ? 0 : 34) == 0) failed
```
The culprit has to be a recent change because `v9_17_12` works fine.
[query_test.log](/uploads/d9922a38acb20185c4569be757631f5f/query_test.log)
[notify_test.log](/uploads/2b5dc113e2cede4bcf7ca96e4eab42ec/notify_test.log)
[listenlist_test.log](/uploads/e29e79c222450adc26f46eed0e2dc5f8/listenlist_test.log)
[task_test.log](/uploads/9ff466b45de6bb843763baa59f5826bb/task_test.log)June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)https://gitlab.isc.org/isc-projects/bind9/-/issues/2708named doesn't compile with GCC 10.2021-05-28T10:33:58ZMark Andrewsnamed doesn't compile with GCC 10.```
CC libisc_la-lib.lo
lib.c:39:1: error: constructor priorities are not supported
39 | isc__initialize(void) ISC_CONSTRUCTOR(101);
| ^~~~~~~~~~~~~~~
lib.c:41:1: error: destructor priorities are not supported
41 | is...```
CC libisc_la-lib.lo
lib.c:39:1: error: constructor priorities are not supported
39 | isc__initialize(void) ISC_CONSTRUCTOR(101);
| ^~~~~~~~~~~~~~~
lib.c:41:1: error: destructor priorities are not supported
41 | isc__shutdown(void) ISC_DESTRUCTOR(101);
| ^~~~~~~~~~~~~
```June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)https://gitlab.isc.org/isc-projects/bind9/-/issues/2709"make install" unnecessarily creates certain directories2021-05-20T12:22:22ZMichał Kępień"make install" unnecessarily creates certain directoriesCreating `etc/` is not necessary since 2009, when we [started][2]
shipping `bind.keys`. That being said, IMHO it was unnecessary even
before, but oh well.
Creating `var/` is not necessary since 2008, which is when
`named_os_openfile()`...Creating `etc/` is not necessary since 2009, when we [started][2]
shipping `bind.keys`. That being said, IMHO it was unnecessary even
before, but oh well.
Creating `var/` is not necessary since 2008, which is when
`named_os_openfile()` [started][1] calling `mkdir()`.
The bottom line is that neither of these directories should be created
by `make install` these days. I would fix it in ~"v9.16" and leave
~"v9.11" alone, this is nothing critical.
(Found while [working][3] on #2629/!4945.)
[1]: f6f1672b4e460571c418e43ae3bd0fae97e4c149
[2]: 3a30493983df83a3184dd1ecd39cf31ccdac3bad
[3]: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4945#note_214242June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2712BIND 9.16.15 as resolver: sudden increase in ServFail query results2022-07-27T08:42:19ZHåvard EidnesBIND 9.16.15 as resolver: sudden increase in ServFail query resultsAfter upgrading BIND to 9.16.15, we have now observed this problem twice. Suddenly, named starts returning a large portion of ServFail query results. Simultaneously, it appears that named stops responding to `rndc` commands.
![query-s...After upgrading BIND to 9.16.15, we have now observed this problem twice. Suddenly, named starts returning a large portion of ServFail query results. Simultaneously, it appears that named stops responding to `rndc` commands.
![query-status](/uploads/e733994ba3ec97f322dcff102546c60a/query-status.png)
This shows the query results tallied in 10s intervals, categorized of whether they return ServFailed status or something else ("normal" results).
We have a `dnscap` running on this host which covers this latter event, but nothing immediately obvious leaps out when looking at the resulting packet traces, although it is a bit like searching for the proverbial needle in a haystack. There also does not seem to be any interesting messages logged which can be correlated with this event.
So ... not too much concrete to go on here, but I have two questions:
1. Have you received any similar error / incident reports?
2. What, if anything, can I look for to collect more or better information to trace the actual root cause of this issue?
I run my BIND instances on NetBSD/amd64, currently 9.0 or slightly later.
Since this somewhat smells like a possibly security-related issue, I'll restrict its availability.
For now I have downgraded BIND on the offending instance to 9.16.12 (the previous version we ran), there are a few other things I need to do before re-trying with 9.16.15.https://gitlab.isc.org/isc-projects/bind9/-/issues/2713Intermittent crashes in the "tkey" system test caused by broken dns_name_t st...2021-05-22T05:17:59ZMichał KępieńIntermittent crashes in the "tkey" system test caused by broken dns_name_t structuresThe following crash occurred on OpenBSD in the daily pipeline run for
`main` today:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/1737486
```
D:tkey:--------------------------------------------------------------------------------
D:...The following crash occurred on OpenBSD in the daily pipeline run for
`main` today:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/1737486
```
D:tkey:--------------------------------------------------------------------------------
D:tkey:Core was generated by `named'.
D:tkey:Program terminated with signal SIGABRT, Aborted.
D:tkey:#0 thrkill () at /tmp/-:3
D:tkey:[Current thread is 1 (process 151515)]
D:tkey:#0 thrkill () at /tmp/-:3
D:tkey:#1 0x00000b2a71112e0e in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
D:tkey:#2 0x00000b27e595d563 in assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>) at main.c:249
D:tkey:#3 0x00000b2a8312f3a0 in isc_assertion_failed (file=0x0, line=6, type=isc_assertiontype_require, cond=0xb2a7109410a <thrkill+10> "r\001\303d\211\004% ") at assertions.c:52
D:tkey:#4 0x00000b2a9f5a2a14 in dns_name_getlabelsequence (source=<optimized out>, first=<optimized out>, n=<optimized out>, target=<optimized out>) at name.c:922
D:tkey:#5 0x00000b2a9f546950 in dns_compress_add (cctx=0xb2a3d5c6f98, name=<optimized out>, prefix=<optimized out>, offset=279) at compress.c:433
D:tkey:#6 0x00000b2a9f5a47c9 in dns_name_towire2 (name=0xb2a3d5c6a90, cctx=0xb2a3d5c6f98, target=0xb2a3d5c7f30, comp_offsetp=<optimized out>) at name.c:2048
D:tkey:#7 0x00000b2a9f60cb82 in towiresorted (rdataset=0xb2aaa240a00, owner_name=<optimized out>, cctx=<optimized out>, target=0xb2a3d5c7f30, order=0xa, order_arg=0xb2a00000117, partial=<optimized out>, options=1, countp=0xb2a3d5c6f4c, state=<optimized out>) at rdataset.c:456
D:tkey:#8 0x00000b2a9f60c4b4 in dns_rdataset_towiresorted (rdataset=0x0, owner_name=0x6, cctx=0x0, target=0xb2a7109410a <thrkill+10>, order=0xb29e76ab640, order_arg=0x0, options=1, countp=0xb2a3d5c6f4c) at rdataset.c:554
D:tkey:#9 0x00000b2a9f58dfae in dns_message_rendersection (msg=<optimized out>, sectionid=<optimized out>, options=<optimized out>) at message.c:2079
D:tkey:#10 0x00000b2a8d4b881d in ns_client_send (client=0xb2a5d77e2c8) at client.c:532
D:tkey:#11 0x00000b2a8d4c7639 in query_send (client=0xb2a5d77e2c8) at query.c:576
D:tkey:#12 0x00000b2a8d4c8054 in ns_query_start (client=0xb2a5d77e2c8, handle=<optimized out>) at query.c:12014
D:tkey:#13 0x00000b2a8d4bb163 in ns__client_request (handle=0xb2a5d77e060, eresult=<optimized out>, region=<optimized out>, arg=<optimized out>) at client.c:2176
D:tkey:#14 0x00000b2a83109b47 in isc__nm_async_readcb (worker=<optimized out>, ev0=<optimized out>) at netmgr/netmgr.c:2701
D:tkey:#15 0x00000b2a83109a20 in isc__nm_readcb (sock=0xb2a5d7985f0, uvreq=0xb2ad0c0f000, eresult=0) at netmgr/netmgr.c:2676
D:tkey:#16 0x00000b2a8310fbc8 in isc__nm_tcpdns_processbuffer (sock=0xb2a5d7985f0) at netmgr/tcpdns.c:817
D:tkey:#17 0x00000b2a83108d12 in processbuffer (sock=0xb2a5d7985f0) at netmgr/netmgr.c:2252
D:tkey:#18 isc__nm_process_sock_buffer (sock=0xb2a5d7985f0) at netmgr/netmgr.c:2277
D:tkey:#19 0x00000b2a8310fd76 in isc__nm_tcpdns_read_cb (stream=<optimized out>, nread=304, buf=0xb2a3d5c9218) at netmgr/tcpdns.c:880
D:tkey:#20 0x00000b29f22923af in uv.stream_io () from /usr/local/lib/libuv.so.3.0
D:tkey:#21 0x00000b29f2298a19 in uv.io_poll () from /usr/local/lib/libuv.so.3.0
D:tkey:#22 0x00000b29f22870b8 in uv_run () from /usr/local/lib/libuv.so.3.0
D:tkey:#23 0x00000b2a83100e8b in nm_thread (worker0=0xb2aa115b0c0) at netmgr/netmgr.c:713
D:tkey:#24 0x00000b2a83153e23 in isc__trampoline_run (arg=0xb2aa1160d60) at trampoline.c:184
D:tkey:#25 0x00000b2a24a34f51 in _rthread_start (v=<optimized out>) at /usr/src/lib/librthread/rthread.c:96
D:tkey:#26 0x00000b2a710b18ea in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:84
D:tkey:--------------------------------------------------------------------------------
```
One other similar crash happened on Ubuntu Xenial in a pipeline run for
!5072, which is a not-yet-merged `v9_16` backport of !5071 (which is
already merged to `main`):
https://gitlab.isc.org/isc-projects/bind9/-/jobs/1736455
```
D:tkey:--------------------------------------------------------------------------------
D:tkey:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/lt-named -D tkey-ns1 -X named.lock -'.
D:tkey:Program terminated with signal SIGABRT, Aborted.
D:tkey:#0 0x00007f7eeeb99438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
D:tkey:[Current thread is 1 (Thread 0x7f7ee5ad9700 (LWP 12588))]
D:tkey:#0 0x00007f7eeeb99438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
D:tkey:#1 0x00007f7eeeb9b03a in __GI_abort () at abort.c:89
D:tkey:#2 0x000000000042d655 in assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>) at ./main.c:266
D:tkey:#3 0x00007f7ef05ce3aa in isc_assertion_failed (file=file@entry=0x7f7ef105df2f "name.c", line=line@entry=1721, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7f7ef10513dd "count <= 63") at assertions.c:46
D:tkey:#4 0x00007f7ef0f3e82d in set_offsets (name=name@entry=0x7f7ee5ad2eb0, offsets=offsets@entry=0x7f7ee5ad2d60 "", set_name=set_name@entry=0x7f7ee5ad2eb0) at name.c:1721
D:tkey:#5 0x00007f7ef0f4089e in dns_name_fromregion (name=name@entry=0x7f7ee5ad2eb0, r=r@entry=0x7f7ee5ad2e50) at name.c:1033
D:tkey:#6 0x00007f7ef0eefa77 in dns_compress_add (cctx=cctx@entry=0x7f7ee5ad3d90, name=name@entry=0x7f7ee5ad3450, prefix=<optimized out>, offset=279) at compress.c:424
D:tkey:#7 0x00007f7ef0f40461 in dns_name_towire2 (name=name@entry=0x7f7ee5ad3450, cctx=cctx@entry=0x7f7ee5ad3d90, target=target@entry=0x7f7ee5ad3cd0, comp_offsetp=comp_offsetp@entry=0x7f7ee5ad31d6) at name.c:2048
D:tkey:#8 0x00007f7ef0f42198 in dns_name_towire2 (name=name@entry=0x7f7ee5ad3450, cctx=cctx@entry=0x7f7ee5ad3d90, target=target@entry=0x7f7ee5ad3cd0, comp_offsetp=comp_offsetp@entry=0x7f7ee5ad31d6) at name.c:1952
D:tkey:#9 0x00007f7ef0fa6875 in towiresorted (rdataset=rdataset@entry=0x7f7edd05cad8, owner_name=owner_name@entry=0x7f7edd057430, cctx=<optimized out>, target=<optimized out>, order=<optimized out>, order_arg=order_arg@entry=0x7f7edd04a1f0, partial=false, options=1, countp=0x7f7ee5ad3c64, state=0x0) at rdataset.c:456
D:tkey:#10 0x00007f7ef0fa7464 in dns_rdataset_towiresorted (rdataset=rdataset@entry=0x7f7edd05cad8, owner_name=owner_name@entry=0x7f7edd057430, cctx=<optimized out>, target=<optimized out>, order=<optimized out>, order_arg=order_arg@entry=0x7f7edd04a1f0, options=1, countp=0x7f7ee5ad3c64) at rdataset.c:554
D:tkey:#11 0x00007f7ef0f2da3c in dns_message_rendersection (msg=0x7f7edd04a020, sectionid=sectionid@entry=1, options=options@entry=6) at message.c:2078
D:tkey:#12 0x00007f7ef12ca7ed in ns_client_send (client=client@entry=0x7f7ec8005588) at client.c:531
D:tkey:#13 0x00007f7ef12d6a7c in query_send (client=client@entry=0x7f7ec8005588) at query.c:568
D:tkey:#14 0x00007f7ef12e4de7 in ns_query_start (client=client@entry=0x7f7ec8005588, handle=handle@entry=0x7f7ec8005420) at query.c:11722
D:tkey:#15 0x00007f7ef12cdb02 in ns__client_request (handle=<optimized out>, eresult=<optimized out>, region=<optimized out>, arg=<optimized out>) at client.c:2163
D:tkey:#16 0x00007f7ef05ead94 in isc__nm_async_readcb (worker=worker@entry=0x0, ev0=ev0@entry=0x7f7ee5ad5980) at netmgr.c:2546
D:tkey:#17 0x00007f7ef05eaf26 in isc__nm_readcb (sock=sock@entry=0x7f7ec8000990, uvreq=uvreq@entry=0x7f7ed4015630, eresult=eresult@entry=0) at netmgr.c:2521
D:tkey:#18 0x00007f7ef05f4c96 in isc__nm_tcpdns_processbuffer (sock=sock@entry=0x7f7ec8000990) at tcpdns.c:813
D:tkey:#19 0x00007f7ef05e82fd in processbuffer (sock=0x7f7ec8000990) at netmgr.c:2150
D:tkey:#20 isc__nm_process_sock_buffer (sock=sock@entry=0x7f7ec8000990) at netmgr.c:2173
D:tkey:#21 0x00007f7ef05f4e22 in isc__nm_tcpdns_read_cb (stream=<optimized out>, nread=304, buf=0x7f7ee5ad5ab0) at tcpdns.c:876
D:tkey:#22 0x00007f7eef7a6aff in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:tkey:#23 0x00007f7eef7a724c in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:tkey:#24 0x00007f7eef7ac055 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:tkey:#25 0x00007f7eef79defc in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:tkey:#26 0x00007f7ef05eba8d in nm_thread (worker0=0x24f1860) at netmgr.c:710
D:tkey:#27 0x00007f7ef0604dfb in isc__trampoline_run (arg=0x291ca80) at trampoline.c:191
D:tkey:#28 0x00007f7eef57e6ba in start_thread (arg=0x7f7ee5ad9700) at pthread_create.c:333
D:tkey:#29 0x00007f7eeec6b4dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
D:tkey:--------------------------------------------------------------------------------
```
This strongly suggests that some issue with !5071 has been overlooked
due to the intermittent nature of the problem.June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)https://gitlab.isc.org/isc-projects/bind9/-/issues/2714Release Checklist for BIND 9.11.33, BIND 9.11.33-S1, BIND 9.16.17, BIND 9.16....2021-06-22T20:39:37ZMichał KępieńRelease Checklist for BIND 9.11.33, BIND 9.11.33-S1, BIND 9.16.17, BIND 9.16.17-S1, 9.17.14## Release Schedule
**Code Freeze:** Wednesday, June 2nd, 2021
**Tagging Deadline:** Monday, June 7th, 2021
**Public Release:** Wednesday, June 16th, 2021
## Documentation Review Links
**Closed issues assigned to the milestone witho...## Release Schedule
**Code Freeze:** Wednesday, June 2nd, 2021
**Tagging Deadline:** Monday, June 7th, 2021
**Public Release:** Wednesday, June 16th, 2021
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.17.14](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=June%202021%20(9.11.33%2C%209.11.33-S1%2C%209.16.17%2C%209.16.17-S1%2C%209.17.14)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.17)
- [9.16.17](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=June%202021%20(9.11.33%2C%209.11.33-S1%2C%209.16.17%2C%209.16.17-S1%2C%209.17.14)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.16)
- [9.11.33](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=June%202021%20(9.11.33%2C%209.11.33-S1%2C%209.16.17%2C%209.16.17-S1%2C%209.17.14)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.11)
**Merge requests merged into the milestone without a release note:**
- [9.17.14](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=June%202021%20(9.11.33%2C%209.11.33-S1%2C%209.16.17%2C%209.16.17-S1%2C%209.17.14)¬[label_name][]=Release%20Notes&target_branch=main)
- [9.16.17](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=June%202021%20(9.11.33%2C%209.11.33-S1%2C%209.16.17%2C%209.16.17-S1%2C%209.17.14)¬[label_name][]=Release%20Notes&target_branch=v9_16)
- [9.11.33](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=June%202021%20(9.11.33%2C%209.11.33-S1%2C%209.16.17%2C%209.16.17-S1%2C%209.17.14)¬[label_name][]=Release%20Notes&target_branch=v9_11)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.17.14](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=June%202021%20(9.11.33%2C%209.11.33-S1%2C%209.16.17%2C%209.16.17-S1%2C%209.17.14)&label_name[]=No%20CHANGES&target_branch=main)
- [9.16.17](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=June%202021%20(9.11.33%2C%209.11.33-S1%2C%209.16.17%2C%209.16.17-S1%2C%209.17.14)&label_name[]=No%20CHANGES&target_branch=v9_16)
- [9.11.33](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=June%202021%20(9.11.33%2C%209.11.33-S1%2C%209.16.17%2C%209.16.17-S1%2C%209.17.14)&label_name[]=No%20CHANGES&target_branch=v9_11)
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Inform Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform.
- [x] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
- [x] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [x] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only).
- [x] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported.
### Before the Tagging Deadline
- [x] ***(QA)*** Look for outstanding documentation issues (e.g. `CHANGES` mistakes) and address them if any are found.
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
- [x] ***(QA)*** Update API files for libraries with new version information.
- [x] ***(QA)*** Change software version and library versions in `configure.ac` (new major release only).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
- [x] ***(QA)*** Update `CHANGES`.
- [x] ***(QA)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ***(QA)*** Update `README.md`.
- [x] ***(QA)*** Update `version`.
- [x] ***(QA)*** Build documentation on `docs.isc.org`.
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Tag the releases in the private repository (`git tag -s -m "BIND 9.x.y" v9_x_y`).
### Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Verify GitLab CI results for the tags created and prepare a QA report for the releases to be published.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again.
- [x] ***(Support)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages.
- [x] ***(QA)*** Notify Support that the releases have been prepared.
- [x] ***(Support)*** Send out ASNs (if applicable).
### On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *bind-announce*.
- [x] ***(Support)*** Write email to *bind-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription Edition (update the -S edition delivery tickets, even if those links were provided earlier via an ASN ticket).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages.
- [x] ***(QA)*** Build public packages (`*.deb`, RPMs).
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(QA)*** Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made.
- [x] ***(Marketing)*** Post short note to Twitter.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(QA)*** Ensure all new tags are annotated and signed.
- [x] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Merge the automatically prepared `prep 9.x.y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_x`).
- [x] ***(QA)*** For each maintained branch, update the `BIND_BASELINE_VERSION` variable for the `abi-check` job in `.gitlab-ci.yml` to the latest published BIND version tag for a given branch.
- [x] ***(QA)*** Prepare empty release notes for the next set of releases.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate[^2].
- [x] ***(QA)*** Update QA tools used in GitLab CI (e.g. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.
[^2]: As a rule of thumb, security vulnerabilities which have reproducers merged to the public repository are considered okay for full disclosure.June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Michał KępieńMichał Kępień2021-06-16https://gitlab.isc.org/isc-projects/bind9/-/issues/2715RFC 8914 - DNSSEC validation failures2023-07-11T10:01:41ZVicky Riskvicky@isc.orgRFC 8914 - DNSSEC validation failuresFrom an ISC support customer, another specific use case for extended errors:
"I think our main interest is distinguishing between the class of Server Failed errors that indicate a DNSSEC validation failure and the more transitory sorts ...From an ISC support customer, another specific use case for extended errors:
"I think our main interest is distinguishing between the class of Server Failed errors that indicate a DNSSEC validation failure and the more transitory sorts (network errors, no authoritative DNS servers available, etc.). We have situations in which we have a DNS server with DNSSEC validation enabled forwarding to another DNS server with validation enabled, and when the forwarder returns Server Failed, it's unclear whether to return that answer to the querier or retry resolution without the forwarder. Does that make sense?"Not plannedMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2716signing a zone fails if the same zone file is used in several views2021-05-21T23:41:34ZHugo Grostabussiatsigning a zone fails if the same zone file is used in several views### Summary
named will fails to sign a zone if that zone is present in multiple views and use the same source zone file.
In my example, those zones use the same dnssec-policy, but the issue also happens with distinct policies.
### BIN...### Summary
named will fails to sign a zone if that zone is present in multiple views and use the same source zone file.
In my example, those zones use the same dnssec-policy, but the issue also happens with distinct policies.
### BIND version used
```
BIND 9.16.15 (Stable Release) <id:4469e3e>
running on Linux x86_64 5.12.4-arch1-2 #1 SMP PREEMPT Sat, 15 May 2021 20:58:02 +0000
built by make with '--prefix=/usr' '--sysconfdir=/etc' '--sbindir=/usr/bin' '--localstatedir=/var' '--disable-static' '--enable-fixed-rrset' '--enable-full-report' '--enable-dnsrps' '--with-python=/usr/bin/python' '--with-maxminddb' '--with-openssl' '--with-libidn2' '--with-json-c' '--with-libxml2' '--with-lmdb' '--with-libtool' 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -DDIG_SIGCHASE -fcommon' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2'
compiled by GCC 10.2.0
compiled with OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
linked to OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
compiled with libuv version: 1.41.0
linked to libuv version: 1.41.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.6.0
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/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
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
1. Use the provided `/etc/named.conf` and `/var/named/example.org.zone` below for a new named config.
2. Start named
3. Error messages appear in the logs (see first log below)
4. Increment the serial in the zone file and run `rndc reload`
5. Another flurry of error messages appear in the logs (see second log below)
### What is the current *bug* behavior?
Signing the zone fails and confusing error messages about a malformed transaction with mismatched serials are logged.
### What is the expected *correct* behavior?
One of those behaviors:
1. Fail to load the configuration with a helpful error message indicating that you must use a different zone file in each view, even if the content is the same (e.g. copy the zone file or make a symlink)
2. Add a suffix to the generated signed zone files so that their names are distinct per view.
### Relevant configuration files
named.conf
```
options {
directory "/var/named";
pid-file "/run/named/named.pid";
auth-nxdomain yes;
datasize default;
listen-on-v6 { any; };
allow-recursion { none; };
allow-transfer { none; };
allow-update { none; };
recursion no;
notify no;
version none;
hostname none;
server-id none;
max-cache-size 5%;
key-directory "dnssec-keys";
};
acl "guest" {
192.168.99.0/24;
};
dnssec-policy custom {
keys {
csk lifetime unlimited algorithm ecdsa256;
};
};
view "internet" {
match-clients { any; };
zone "example.org" IN {
type master;
file "example.org.zone";
dnssec-policy custom;
};
};
view "guest" {
match-clients { guest; };
zone "example.org" IN {
type master;
file "example.org.zone";
dnssec-policy custom;
};
};
logging {
channel xfer-log {
file "/var/log/named.log";
print-category yes;
print-severity yes;
print-time yes;
severity info;
};
channel default-log {
syslog daemon;
severity warning;
print-category yes;
print-severity yes;
};
category default { default-log; };
category xfer-in { xfer-log; };
category xfer-out { xfer-log; };
category notify { xfer-log; };
};
```
example.org.zone
```
@ 1D IN SOA exemple.org. root.example.org. (
2021051911 ; serial (yyyymmdd##)
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum ttl
1D IN NS example.org.
example.org. 1D IN A 10.0.0.1
www.example.org. 1D IN A 10.0.0.1
```
### Relevant logs and/or screenshots
Errors on first start with all the keys, .signed files and .jnl files removed:
```
general: error: zone example.org/IN/guest (signed): receive_secure_serial: unchanged
general: error: zone example.org/IN/internet (signed): receive_secure_serial: unchanged
general: error: malformed transaction: example.org.zone.signed.jnl last serial 2021051912 != transaction first serial 2021051911
general: error: zone example.org/IN/internet (signed): zone_rekey:dns_journal_write_transaction -> unexpected error
```
Errors after incrementing the zone serial and reloading:
```
general: error: zone example.org/IN/internet (signed): could not get zone keys for secure dynamic update
general: error: malformed transaction: example.org.zone.signed.jnl last serial 2021051913 != transaction first serial 2021051911
general: error: zone example.org/IN/internet (signed): receive_secure_serial:dns_journal_write_transaction -> unexpected error
general: error: zone example.org/IN/internet (signed): receive_secure_serial: unexpected error
general: error: malformed transaction: example.org.zone.jnl last serial 2021052100 != transaction first serial 2021051911
general: error: zone example.org/IN/guest (unsigned): ixfr-from-differences: failed: Success
general: error: malformed transaction: example.org.zone.signed.jnl last serial 2021051913 != transaction first serial 2021051911
general: error: zone example.org/IN/internet (signed): zone_rekey:dns_journal_write_transaction -> unexpected error
general: error: zone example.org/IN/guest (signed): could not get zone keys for secure dynamic update
```
### Possible fixes
Copy the zone file or symlink it as many times there are views using it.https://gitlab.isc.org/isc-projects/bind9/-/issues/2717Fix sysconfdir path in man pages with hardcoded default paths2022-02-25T13:57:06ZAthos RibeiroFix sysconfdir path in man pages with hardcoded default pathsSome man pages have hardcoded values for the default configuration file paths.
This path is configurable through the `sysconfdir` variable, and the manpages
should perform the proper substitutions whenever the default value is changed.
...Some man pages have hardcoded values for the default configuration file paths.
This path is configurable through the `sysconfdir` variable, and the manpages
should perform the proper substitutions whenever the default value is changed.
This attached patch (**which applies against the `v9_16` branch**) uses the
already existing template system for building the docs toperform such
substitutions.
[0004-fix-sysconfdir-path-in-man-pages.patch](/uploads/f1029c9d28f49f6f0179d18914d20c16/0004-fix-sysconfdir-path-in-man-pages.patch)March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/2718Can't get rcode statics by zone from statistics-channel.2021-05-25T10:26:37ZManabu SonodaCan't get rcode statics by zone from statistics-channel.<!--
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
Can't get rcode statics by zone from statistics-channel.
(Summarize the bug encountered concisely.)
### BIND version used
BIND 9.11.31 (Extended Support Version) <id:ac3f4eb>
### Steps to reproduce
```
$ dig @localhost example.jp TXT
$ curl http://localhost:10053/json/v1 | jq '.views._default.zones '
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 611k 100 611k 0 0 2282k 0 --:--:-- --:--:-- --:--:-- 2274k
[
{
"name": "example.jp",
"class": "IN",
"type": "slave",
"rcodes": {
"QrySuccess": 1,
"QryAuthAns": 1,
"QryUDP": 1
},
"qtypes": {
"TXT": 1
}
},
```
### What is the current *bug* behavior?
- Key is "rcodes", but returned nsstats.
### What is the expected *correct* behavior?
- Rcode counter value is assigned to "rcodes".
```
{
"name": "example.jp",
"class": "IN",
"type": "slave",
"rcodes": {
"QUERY": 1,
"IQUERY": 0,
"STATUS": 0,
"RESERVED3": 0,
"NOTIFY": 0,
"UPDATE": 0,
"RESERVED6": 0,
"RESERVED7": 0,
"RESERVED8": 0,
"RESERVED9": 0,
"RESERVED10": 0,
"RESERVED11": 0,
"RESERVED12": 0,
"RESERVED13": 0,
"RESERVED14": 0,
"RESERVED15": 0
},
"qtypes": {
"TXT": 1
}
```
### Relevant configuration files
```
controls {
inet 127.0.0.1 port 953 allow {
127.0.0.1/32;
} keys {
"rndc-key";
};
};
options {
directory "/etc/named";
interface-interval 0;
listen-on {
"any";
};
listen-on-v6 {
"any";
};
querylog no;
check-names slave warn;
recursion no;
allow-query {
"any";
};
masterfile-format text;
multi-master yes;
notify explicit;
zone-statistics yes;
};
statistics-channels {
inet 127.0.0.1 port 10053 allow {
127.0.0.1/32;
};
};
key "rndc-key" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
zone "example.jp" {
type master;
file "example.jp";
};
```
### Relevant logs and/or screenshots
```
/ # dig @localhost example.jp A
; <<>> DiG 9.16.15 <<>> @localhost example.jp A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35022
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 3c4dff88f795ae6aa18c4f6f60ab43d66d51e96071fb1f12 (good)
;; QUESTION SECTION:
;example.jp. IN A
;; ANSWER SECTION:
example.jp. 3600 IN A 127.0.0.1
;; AUTHORITY SECTION:
example.jp. 3600 IN NS localhost.
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon May 24 06:12:38 UTC 2021
;; MSG SIZE rcvd: 106
/ # curl http://localhost:10053/json/v1/zones
{
"json-stats-version":"1.2",
"boot-time":"2021-05-24T06:09:57.895Z",
"config-time":"2021-05-24T06:12:21.187Z",
"current-time":"2021-05-24T06:12:42.304Z",
"version":"9.11.31",
"views":{
"_default":{
"zones":[
{
"name":"example.jp",
"class":"IN",
"serial":0,
"type":"master",
"rcodes":{
"QrySuccess":1,
"QryAuthAns":1,
"QryUDP":1
},
"qtypes":{
"A":1
}
}
]
},
"_bind":{
"zones":[
{
"name":"authors.bind",
"class":"CH",
"serial":0,
"type":"builtin"
},
{
"name":"hostname.bind",
"class":"CH",
"serial":0,
"type":"builtin"
},
{
"name":"version.bind",
"class":"CH",
"serial":0,
"type":"builtin"
},
{
"name":"id.server",
"class":"CH",
"serial":0,
"type":"builtin"
}
]
}
}
}
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)https://gitlab.isc.org/isc-projects/bind9/-/issues/2719ThreadSanitizer: data race between ns_client_endrequest->rdataset_disassociat...2022-03-01T09:56:24ZOndřej SurýThreadSanitizer: data race between ns_client_endrequest->rdataset_disassociate and rmzone->free_rbtdbFull report here (it doesn't happen in the CI, just locally):
```
==================
WARNING: ThreadSanitizer: data race (pid=1434821)
Write of size 8 at 0x7b98000603a8 by thread T1 (mutexes: write M599395980743702552):
#0 memset <...Full report here (it doesn't happen in the CI, just locally):
```
==================
WARNING: ThreadSanitizer: data race (pid=1434821)
Write of size 8 at 0x7b98000603a8 by thread T1 (mutexes: write M599395980743702552):
#0 memset <null> (named+0x445d29)
#1 mem_put /home/ondrej/Projects/bind9/lib/isc/mem.c:361:3 (libisc-9.17.13.so+0xd7a1c)
#2 isc__mem_free /home/ondrej/Projects/bind9/lib/isc/mem.c:1012:2 (libisc-9.17.13.so+0xd6f17)
#3 isc__mem_put /home/ondrej/Projects/bind9/lib/isc/mem.c:777:3 (libisc-9.17.13.so+0xd8ec8)
#4 free_rbtdb /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:1203:2 (libdns-9.17.13.so+0x1c9a83)
#5 maybe_free_rbtdb /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:1288:4 (libdns-9.17.13.so+0x1d9310)
#6 detach /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:1300:3 (libdns-9.17.13.so+0x1cab3c)
#7 dns_db_detach /home/ondrej/Projects/bind9/lib/dns/db.c:155:2 (libdns-9.17.13.so+0x83d9b)
#8 zone_detachdb /home/ondrej/Projects/bind9/lib/dns/zone.c:17150:2 (libdns-9.17.13.so+0x40117e)
#9 zone_unload /home/ondrej/Projects/bind9/lib/dns/zone.c:11928:2 (libdns-9.17.13.so+0x3deee2)
#10 dns_zone_unload /home/ondrej/Projects/bind9/lib/dns/zone.c:11863:2 (libdns-9.17.13.so+0x3deca2)
#11 rmzone /home/ondrej/Projects/bind9/bin/named/server.c:14368:3 (named+0x4fbd3b)
#12 task_run /home/ondrej/Projects/bind9/lib/isc/task.c:816:5 (libisc-9.17.13.so+0xffd06)
#13 isc_task_run /home/ondrej/Projects/bind9/lib/isc/task.c:896:10 (libisc-9.17.13.so+0xff4f5)
#14 isc__nm_async_task /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:863:11 (libisc-9.17.13.so+0x47a8e)
#15 process_netievent /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:942:3 (libisc-9.17.13.so+0x3c0dc)
#16 process_queue /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:1032:16 (libisc-9.17.13.so+0x4792a)
#17 process_all_queues /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:783:25 (libisc-9.17.13.so+0x4774f)
#18 async_cb /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:812:6 (libisc-9.17.13.so+0x35482)
#19 uv__async_io /home/ondrej/Projects/tsan/libuv/src/unix/async.c:163:5 (libuv.so.1+0x15389)
#20 uv__io_poll /home/ondrej/Projects/tsan/libuv/src/unix/linux-core.c:462:11 (libuv.so.1+0x2ebb6)
#21 uv_run /home/ondrej/Projects/tsan/libuv/src/unix/core.c:392:5 (libuv.so.1+0x159ac)
#22 nm_thread /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:718:11 (libisc-9.17.13.so+0x3555e)
#23 isc__trampoline_run /home/ondrej/Projects/bind9/lib/isc/trampoline.c:184:11 (libisc-9.17.13.so+0x108746)
Previous atomic read of size 8 at 0x7b98000603a8 by thread T2:
#0 __tsan_atomic64_load <null> (named+0x487e0e)
#1 isc_rwlock_unlock /home/ondrej/Projects/bind9/lib/isc/rwlock.c:584:8 (libisc-9.17.13.so+0xf1287)
#2 detachnode /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:5508:2 (libdns-9.17.13.so+0x1d1c0d)
#3 rdataset_disassociate /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:8862:2 (libdns-9.17.13.so+0x1e4354)
#4 dns_rdataset_disassociate /home/ondrej/Projects/bind9/lib/dns/rdataset.c:111:2 (libdns-9.17.13.so+0x2d86cc)
#5 msgresetnames /home/ondrej/Projects/bind9/lib/dns/message.c:467:5 (libdns-9.17.13.so+0x142f07)
#6 msgreset /home/ondrej/Projects/bind9/lib/dns/message.c:542:2 (libdns-9.17.13.so+0x13613a)
#7 dns_message_reset /home/ondrej/Projects/bind9/lib/dns/message.c:762:2 (libdns-9.17.13.so+0x13609f)
#8 ns_client_endrequest /home/ondrej/Projects/bind9/lib/ns/client.c:212:2 (libns-9.17.13.so+0x16362)
#9 ns__client_reset_cb /home/ondrej/Projects/bind9/lib/ns/client.c:1536:2 (libns-9.17.13.so+0x155cd)
#10 nmhandle_detach_cb /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:1848:3 (libisc-9.17.13.so+0x40b3f)
#11 isc__nmhandle_detach /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:1804:3 (libisc-9.17.13.so+0x39a4f)
#12 isc___nm_uvreq_put /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:2462:3 (libisc-9.17.13.so+0x41b04)
#13 isc__nm_async_sendcb /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:2748:2 (libisc-9.17.13.so+0x46837)
#14 isc__nm_sendcb /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:2722:3 (libisc-9.17.13.so+0x41721)
#15 udp_send_cb /home/ondrej/Projects/bind9/lib/isc/netmgr/udp.c:560:2 (libisc-9.17.13.so+0x75549)
#16 uv__udp_run_completed /home/ondrej/Projects/tsan/libuv/src/unix/udp.c (libuv.so.1+0x2b9f9)
#17 uv__udp_io /home/ondrej/Projects/tsan/libuv/src/unix/udp.c:184:5 (libuv.so.1+0x2c94c)
#18 uv__run_pending /home/ondrej/Projects/tsan/libuv/src/unix/core.c:825:5 (libuv.so.1+0x15b87)
#19 uv_run /home/ondrej/Projects/tsan/libuv/src/unix/core.c:384:19 (libuv.so.1+0x15977)
#20 nm_thread /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:718:11 (libisc-9.17.13.so+0x3555e)
#21 isc__trampoline_run /home/ondrej/Projects/bind9/lib/isc/trampoline.c:184:11 (libisc-9.17.13.so+0x108746)
Location is heap block of size 11464 at 0x7b9800060000 allocated by thread T1:
#0 malloc <null> (named+0x43a74b)
#1 default_memalloc /home/ondrej/Projects/bind9/lib/isc/mem.c:411:8 (libisc-9.17.13.so+0xddffe)
#2 mem_get /home/ondrej/Projects/bind9/lib/isc/mem.c:343:8 (libisc-9.17.13.so+0xd8331)
#3 mem_allocateunlocked /home/ondrej/Projects/bind9/lib/isc/mem.c:918:7 (libisc-9.17.13.so+0xd9810)
#4 isc__mem_allocate /home/ondrej/Projects/bind9/lib/isc/mem.c:935:7 (libisc-9.17.13.so+0xd8195)
#5 isc__mem_get /home/ondrej/Projects/bind9/lib/isc/mem.c:740:11 (libisc-9.17.13.so+0xd7f8f)
#6 dns_rbtdb_create /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:8631:22 (libdns-9.17.13.so+0x1c538e)
#7 dns_db_create /home/ondrej/Projects/bind9/lib/dns/db.c:118:13 (libdns-9.17.13.so+0x83693)
#8 axfr_makedb /home/ondrej/Projects/bind9/lib/dns/xfrin.c:292:11 (libdns-9.17.13.so+0x3c0105)
#9 axfr_init /home/ondrej/Projects/bind9/lib/dns/xfrin.c:280:2 (libdns-9.17.13.so+0x3bf8da)
#10 xfr_rr /home/ondrej/Projects/bind9/lib/dns/xfrin.c:597:4 (libdns-9.17.13.so+0x3beb45)
#11 xfrin_recv_done /home/ondrej/Projects/bind9/lib/dns/xfrin.c:1430:5 (libdns-9.17.13.so+0x3bd2fd)
#12 isc__nm_async_readcb /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:2706:2 (libisc-9.17.13.so+0x463f8)
#13 isc__nm_readcb /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:2681:3 (libisc-9.17.13.so+0x45eae)
#14 isc__nm_tcpdns_processbuffer /home/ondrej/Projects/bind9/lib/isc/netmgr/tcpdns.c:817:2 (libisc-9.17.13.so+0x574fd)
#15 processbuffer /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:2257:11 (libisc-9.17.13.so+0x4413f)
#16 isc__nm_process_sock_buffer /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:2282:25 (libisc-9.17.13.so+0x43fb5)
#17 isc__nm_tcpdns_read_cb /home/ondrej/Projects/bind9/lib/isc/netmgr/tcpdns.c:880:2 (libisc-9.17.13.so+0x57c28)
#18 uv__read /home/ondrej/Projects/tsan/libuv/src/unix/stream.c:1239:7 (libuv.so.1+0x280bc)
#19 uv__stream_io /home/ondrej/Projects/tsan/libuv/src/unix/stream.c:1306:5 (libuv.so.1+0x25cef)
#20 uv__io_poll /home/ondrej/Projects/tsan/libuv/src/unix/linux-core.c:462:11 (libuv.so.1+0x2ebb6)
#21 uv_run /home/ondrej/Projects/tsan/libuv/src/unix/core.c:392:5 (libuv.so.1+0x159ac)
#22 nm_thread /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:718:11 (libisc-9.17.13.so+0x3555e)
#23 isc__trampoline_run /home/ondrej/Projects/bind9/lib/isc/trampoline.c:184:11 (libisc-9.17.13.so+0x108746)
Mutex M599395980743702552 is already destroyed.
Thread T1 'isc-net-0000' (tid=1434862, running) created by main thread at:
#0 pthread_create <null> (named+0x43bf6b)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/pthreads/thread.c:79:8 (libisc-9.17.13.so+0x10b706)
#2 isc__netmgr_create /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:347:3 (libisc-9.17.13.so+0x3535e)
#3 isc_managers_create /home/ondrej/Projects/bind9/lib/isc/managers.c:39:2 (libisc-9.17.13.so+0xd433e)
#4 create_managers /home/ondrej/Projects/bind9/bin/named/main.c:941:11 (named+0x4e4c71)
#5 setup /home/ondrej/Projects/bind9/bin/named/main.c:1216:11 (named+0x4e26d5)
#6 main /home/ondrej/Projects/bind9/bin/named/main.c:1507:2 (named+0x4e0e2b)
Thread T2 'isc-net-0001' (tid=1434882, running) created by main thread at:
#0 pthread_create <null> (named+0x43bf6b)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/pthreads/thread.c:79:8 (libisc-9.17.13.so+0x10b706)
#2 isc__netmgr_create /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:347:3 (libisc-9.17.13.so+0x3535e)
#3 isc_managers_create /home/ondrej/Projects/bind9/lib/isc/managers.c:39:2 (libisc-9.17.13.so+0xd433e)
#4 create_managers /home/ondrej/Projects/bind9/bin/named/main.c:941:11 (named+0x4e4c71)
#5 setup /home/ondrej/Projects/bind9/bin/named/main.c:1216:11 (named+0x4e26d5)
#6 main /home/ondrej/Projects/bind9/bin/named/main.c:1507:2 (named+0x4e0e2b)
SUMMARY: ThreadSanitizer: data race (/home/ondrej/Projects/bind9/bin/named/.libs/named+0x445d29) in memset
==================
==================
WARNING: ThreadSanitizer: data race (pid=1434821)
Write of size 8 at 0x7b98000603b0 by thread T1 (mutexes: write M599395980743702552):
#0 memset <null> (named+0x445d29)
#1 mem_put /home/ondrej/Projects/bind9/lib/isc/mem.c:361:3 (libisc-9.17.13.so+0xd7a1c)
#2 isc__mem_free /home/ondrej/Projects/bind9/lib/isc/mem.c:1012:2 (libisc-9.17.13.so+0xd6f17)
#3 isc__mem_put /home/ondrej/Projects/bind9/lib/isc/mem.c:777:3 (libisc-9.17.13.so+0xd8ec8)
#4 free_rbtdb /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:1203:2 (libdns-9.17.13.so+0x1c9a83)
#5 maybe_free_rbtdb /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:1288:4 (libdns-9.17.13.so+0x1d9310)
#6 detach /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:1300:3 (libdns-9.17.13.so+0x1cab3c)
#7 dns_db_detach /home/ondrej/Projects/bind9/lib/dns/db.c:155:2 (libdns-9.17.13.so+0x83d9b)
#8 zone_detachdb /home/ondrej/Projects/bind9/lib/dns/zone.c:17150:2 (libdns-9.17.13.so+0x40117e)
#9 zone_unload /home/ondrej/Projects/bind9/lib/dns/zone.c:11928:2 (libdns-9.17.13.so+0x3deee2)
#10 dns_zone_unload /home/ondrej/Projects/bind9/lib/dns/zone.c:11863:2 (libdns-9.17.13.so+0x3deca2)
#11 rmzone /home/ondrej/Projects/bind9/bin/named/server.c:14368:3 (named+0x4fbd3b)
#12 task_run /home/ondrej/Projects/bind9/lib/isc/task.c:816:5 (libisc-9.17.13.so+0xffd06)
#13 isc_task_run /home/ondrej/Projects/bind9/lib/isc/task.c:896:10 (libisc-9.17.13.so+0xff4f5)
#14 isc__nm_async_task /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:863:11 (libisc-9.17.13.so+0x47a8e)
#15 process_netievent /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:942:3 (libisc-9.17.13.so+0x3c0dc)
#16 process_queue /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:1032:16 (libisc-9.17.13.so+0x4792a)
#17 process_all_queues /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:783:25 (libisc-9.17.13.so+0x4774f)
#18 async_cb /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:812:6 (libisc-9.17.13.so+0x35482)
#19 uv__async_io /home/ondrej/Projects/tsan/libuv/src/unix/async.c:163:5 (libuv.so.1+0x15389)
#20 uv__io_poll /home/ondrej/Projects/tsan/libuv/src/unix/linux-core.c:462:11 (libuv.so.1+0x2ebb6)
#21 uv_run /home/ondrej/Projects/tsan/libuv/src/unix/core.c:392:5 (libuv.so.1+0x159ac)
#22 nm_thread /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:718:11 (libisc-9.17.13.so+0x3555e)
#23 isc__trampoline_run /home/ondrej/Projects/bind9/lib/isc/trampoline.c:184:11 (libisc-9.17.13.so+0x108746)
Previous atomic read of size 8 at 0x7b98000603b0 by thread T2:
#0 __tsan_atomic64_load <null> (named+0x487e0e)
#1 isc_rwlock_unlock /home/ondrej/Projects/bind9/lib/isc/rwlock.c:583:7 (libisc-9.17.13.so+0xf1247)
#2 detachnode /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:5508:2 (libdns-9.17.13.so+0x1d1c0d)
#3 rdataset_disassociate /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:8862:2 (libdns-9.17.13.so+0x1e4354)
#4 dns_rdataset_disassociate /home/ondrej/Projects/bind9/lib/dns/rdataset.c:111:2 (libdns-9.17.13.so+0x2d86cc)
#5 msgresetnames /home/ondrej/Projects/bind9/lib/dns/message.c:467:5 (libdns-9.17.13.so+0x142f07)
#6 msgreset /home/ondrej/Projects/bind9/lib/dns/message.c:542:2 (libdns-9.17.13.so+0x13613a)
#7 dns_message_reset /home/ondrej/Projects/bind9/lib/dns/message.c:762:2 (libdns-9.17.13.so+0x13609f)
#8 ns_client_endrequest /home/ondrej/Projects/bind9/lib/ns/client.c:212:2 (libns-9.17.13.so+0x16362)
#9 ns__client_reset_cb /home/ondrej/Projects/bind9/lib/ns/client.c:1536:2 (libns-9.17.13.so+0x155cd)
#10 nmhandle_detach_cb /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:1848:3 (libisc-9.17.13.so+0x40b3f)
#11 isc__nmhandle_detach /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:1804:3 (libisc-9.17.13.so+0x39a4f)
#12 isc___nm_uvreq_put /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:2462:3 (libisc-9.17.13.so+0x41b04)
#13 isc__nm_async_sendcb /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:2748:2 (libisc-9.17.13.so+0x46837)
#14 isc__nm_sendcb /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:2722:3 (libisc-9.17.13.so+0x41721)
#15 udp_send_cb /home/ondrej/Projects/bind9/lib/isc/netmgr/udp.c:560:2 (libisc-9.17.13.so+0x75549)
#16 uv__udp_run_completed /home/ondrej/Projects/tsan/libuv/src/unix/udp.c (libuv.so.1+0x2b9f9)
#17 uv__udp_io /home/ondrej/Projects/tsan/libuv/src/unix/udp.c:184:5 (libuv.so.1+0x2c94c)
#18 uv__run_pending /home/ondrej/Projects/tsan/libuv/src/unix/core.c:825:5 (libuv.so.1+0x15b87)
#19 uv_run /home/ondrej/Projects/tsan/libuv/src/unix/core.c:384:19 (libuv.so.1+0x15977)
#20 nm_thread /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:718:11 (libisc-9.17.13.so+0x3555e)
#21 isc__trampoline_run /home/ondrej/Projects/bind9/lib/isc/trampoline.c:184:11 (libisc-9.17.13.so+0x108746)
Location is heap block of size 11464 at 0x7b9800060000 allocated by thread T1:
#0 malloc <null> (named+0x43a74b)
#1 default_memalloc /home/ondrej/Projects/bind9/lib/isc/mem.c:411:8 (libisc-9.17.13.so+0xddffe)
#2 mem_get /home/ondrej/Projects/bind9/lib/isc/mem.c:343:8 (libisc-9.17.13.so+0xd8331)
#3 mem_allocateunlocked /home/ondrej/Projects/bind9/lib/isc/mem.c:918:7 (libisc-9.17.13.so+0xd9810)
#4 isc__mem_allocate /home/ondrej/Projects/bind9/lib/isc/mem.c:935:7 (libisc-9.17.13.so+0xd8195)
#5 isc__mem_get /home/ondrej/Projects/bind9/lib/isc/mem.c:740:11 (libisc-9.17.13.so+0xd7f8f)
#6 dns_rbtdb_create /home/ondrej/Projects/bind9/lib/dns/rbtdb.c:8631:22 (libdns-9.17.13.so+0x1c538e)
#7 dns_db_create /home/ondrej/Projects/bind9/lib/dns/db.c:118:13 (libdns-9.17.13.so+0x83693)
#8 axfr_makedb /home/ondrej/Projects/bind9/lib/dns/xfrin.c:292:11 (libdns-9.17.13.so+0x3c0105)
#9 axfr_init /home/ondrej/Projects/bind9/lib/dns/xfrin.c:280:2 (libdns-9.17.13.so+0x3bf8da)
#10 xfr_rr /home/ondrej/Projects/bind9/lib/dns/xfrin.c:597:4 (libdns-9.17.13.so+0x3beb45)
#11 xfrin_recv_done /home/ondrej/Projects/bind9/lib/dns/xfrin.c:1430:5 (libdns-9.17.13.so+0x3bd2fd)
#12 isc__nm_async_readcb /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:2706:2 (libisc-9.17.13.so+0x463f8)
#13 isc__nm_readcb /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:2681:3 (libisc-9.17.13.so+0x45eae)
#14 isc__nm_tcpdns_processbuffer /home/ondrej/Projects/bind9/lib/isc/netmgr/tcpdns.c:817:2 (libisc-9.17.13.so+0x574fd)
#15 processbuffer /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:2257:11 (libisc-9.17.13.so+0x4413f)
#16 isc__nm_process_sock_buffer /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:2282:25 (libisc-9.17.13.so+0x43fb5)
#17 isc__nm_tcpdns_read_cb /home/ondrej/Projects/bind9/lib/isc/netmgr/tcpdns.c:880:2 (libisc-9.17.13.so+0x57c28)
#18 uv__read /home/ondrej/Projects/tsan/libuv/src/unix/stream.c:1239:7 (libuv.so.1+0x280bc)
#19 uv__stream_io /home/ondrej/Projects/tsan/libuv/src/unix/stream.c:1306:5 (libuv.so.1+0x25cef)
#20 uv__io_poll /home/ondrej/Projects/tsan/libuv/src/unix/linux-core.c:462:11 (libuv.so.1+0x2ebb6)
#21 uv_run /home/ondrej/Projects/tsan/libuv/src/unix/core.c:392:5 (libuv.so.1+0x159ac)
#22 nm_thread /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:718:11 (libisc-9.17.13.so+0x3555e)
#23 isc__trampoline_run /home/ondrej/Projects/bind9/lib/isc/trampoline.c:184:11 (libisc-9.17.13.so+0x108746)
Mutex M599395980743702552 is already destroyed.
Thread T1 'isc-net-0000' (tid=1434862, running) created by main thread at:
#0 pthread_create <null> (named+0x43bf6b)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/pthreads/thread.c:79:8 (libisc-9.17.13.so+0x10b706)
#2 isc__netmgr_create /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:347:3 (libisc-9.17.13.so+0x3535e)
#3 isc_managers_create /home/ondrej/Projects/bind9/lib/isc/managers.c:39:2 (libisc-9.17.13.so+0xd433e)
#4 create_managers /home/ondrej/Projects/bind9/bin/named/main.c:941:11 (named+0x4e4c71)
#5 setup /home/ondrej/Projects/bind9/bin/named/main.c:1216:11 (named+0x4e26d5)
#6 main /home/ondrej/Projects/bind9/bin/named/main.c:1507:2 (named+0x4e0e2b)
Thread T2 'isc-net-0001' (tid=1434882, running) created by main thread at:
#0 pthread_create <null> (named+0x43bf6b)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/pthreads/thread.c:79:8 (libisc-9.17.13.so+0x10b706)
#2 isc__netmgr_create /home/ondrej/Projects/bind9/lib/isc/netmgr/netmgr.c:347:3 (libisc-9.17.13.so+0x3535e)
#3 isc_managers_create /home/ondrej/Projects/bind9/lib/isc/managers.c:39:2 (libisc-9.17.13.so+0xd433e)
#4 create_managers /home/ondrej/Projects/bind9/bin/named/main.c:941:11 (named+0x4e4c71)
#5 setup /home/ondrej/Projects/bind9/bin/named/main.c:1216:11 (named+0x4e26d5)
#6 main /home/ondrej/Projects/bind9/bin/named/main.c:1507:2 (named+0x4e0e2b)
SUMMARY: ThreadSanitizer: data race (/home/ondrej/Projects/bind9/bin/named/.libs/named+0x445d29) in memset
==================
ThreadSanitizer: reported 2 warningsNot plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2720ThreadSanitizer: data race lib/isc/unix/time.c:110 in isc_time_isepoch2021-06-09T13:57:29ZMichal NowakThreadSanitizer: data race lib/isc/unix/time.c:110 in isc_time_isepochJob [1742391](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1742391) on `v9_16` failed in the `dnssec` system test with the following TSAN error:
```
WARNING: ThreadSanitizer: data race
Read of size 4 at 0x000000000001 by thread T...Job [1742391](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1742391) on `v9_16` failed in the `dnssec` system test with the following TSAN error:
```
WARNING: ThreadSanitizer: data race
Read of size 4 at 0x000000000001 by thread T1 (mutexes: read M1, write M2):
#0 isc_time_isepoch lib/isc/unix/time.c:110
#1 zone_settimer lib/dns/zone.c:14649
#2 dns_zone_maintenance lib/dns/zone.c:6281
#3 dns_zonemgr_forcemaint lib/dns/zone.c:18190
#4 view_loaded server.c:9654
#5 call_loaddone lib/dns/zt.c:301
#6 doneloading lib/dns/zt.c:575
#7 zone_asyncload lib/dns/zone.c:2259
#8 task_run lib/isc/task.c:845
#9 isc_task_run lib/isc/task.c:938
#10 isc__nm_async_task lib/isc/netmgr/netmgr.c:855
#11 process_netievent lib/isc/netmgr/netmgr.c:934
#12 process_queue lib/isc/netmgr/netmgr.c:1003
#13 process_all_queues lib/isc/netmgr/netmgr.c:775
#14 async_cb lib/isc/netmgr/netmgr.c:804
#15 <null> <null>
#16 isc__trampoline_run lib/isc/trampoline.c:191
#17 <null> <null>
Previous write of size 4 at 0x000000000001 by thread T2:
#0 isc_time_set lib/isc/unix/time.c:93
#1 set_key_expiry_warning lib/dns/zone.c:6430
#2 del_sigs lib/dns/zone.c:6711
#3 zone_resigninc lib/dns/zone.c:7113
#4 zone_maintenance lib/dns/zone.c:11111
#5 zone_timer lib/dns/zone.c:14588
#6 task_run lib/isc/task.c:845
#7 isc_task_run lib/isc/task.c:938
#8 isc__nm_async_task lib/isc/netmgr/netmgr.c:855
#9 process_netievent lib/isc/netmgr/netmgr.c:934
#10 process_queue lib/isc/netmgr/netmgr.c:1003
#11 process_all_queues lib/isc/netmgr/netmgr.c:775
#12 async_cb lib/isc/netmgr/netmgr.c:804
#13 <null> <null>
#14 isc__trampoline_run lib/isc/trampoline.c:191
#15 <null> <null>
Location is heap block of size 2801 at 0x000000000023 allocated by thread T3:
#0 malloc <null>
#1 default_memalloc lib/isc/mem.c:717
#2 mem_get lib/isc/mem.c:626
#3 mem_allocateunlocked lib/isc/mem.c:1292
#4 isc___mem_allocate lib/isc/mem.c:1312
#5 isc__mem_allocate lib/isc/mem.c:2563
#6 isc___mem_get lib/isc/mem.c:1061
#7 isc__mem_get lib/isc/mem.c:2542
#8 dns_zone_create lib/dns/zone.c:1047
#9 dns_zonemgr_createzone lib/dns/zone.c:18063
#10 configure_zone server.c:6451
#11 configure_view server.c:4024
#12 load_configuration server.c:9096
#13 run_server server.c:9815
#14 task_run lib/isc/task.c:845
#15 isc_task_run lib/isc/task.c:938
#16 isc__nm_async_task lib/isc/netmgr/netmgr.c:855
#17 process_netievent lib/isc/netmgr/netmgr.c:934
#18 process_queue lib/isc/netmgr/netmgr.c:1003
#19 process_all_queues lib/isc/netmgr/netmgr.c:775
#20 async_cb lib/isc/netmgr/netmgr.c:804
#21 <null> <null>
#22 isc__trampoline_run lib/isc/trampoline.c:191
#23 <null> <null>
Mutex M1 is already destroyed.
Mutex M2 is already destroyed.
Thread T3 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:79
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:350
#3 isc_managers_create lib/isc/managers.c:33
#4 create_managers main.c:920
#5 setup main.c:1245
#6 main main.c:1548
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:79
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:350
#3 isc_managers_create lib/isc/managers.c:33
#4 create_managers main.c:920
#5 setup main.c:1245
#6 main main.c:1548
Thread T3 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:79
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:350
#3 isc_managers_create lib/isc/managers.c:33
#4 create_managers main.c:920
#5 setup main.c:1245
#6 main main.c:1548
SUMMARY: ThreadSanitizer: data race lib/isc/unix/time.c:110 in isc_time_isepoch
```
Similar TSAN error in the same CI job: [d84c7cc0b14ccdcf28a2c70083942efdc1f99addab62b39f3ab8f81f1e507975.tsan](/uploads/49ef557a68a7180b898ac7216f50681a/d84c7cc0b14ccdcf28a2c70083942efdc1f99addab62b39f3ab8f81f1e507975.tsan)July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2721interfacemgr shutdown race2021-05-28T10:27:35ZMark Andrewsinterfacemgr shutdown raceJob [#1748465](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1748465) failed for 80ca95a95c72012d2fbaaed102844f6921d9e192:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1 (mutexes: write M1):...Job [#1748465](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1748465) failed for 80ca95a95c72012d2fbaaed102844f6921d9e192:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1 (mutexes: write M1):
#0 memset <null>
#1 memset /usr/include/x86_64-linux-gnu/bits/string_fortified.h:71:10
#2 mem_put lib/isc/mem.c:361:3
#3 isc__mem_free lib/isc/mem.c:1012:2
#4 isc__mem_put lib/isc/mem.c:777:3
#5 ns_interface_destroy lib/ns/interfacemgr.c:713:2
#6 ns_interface_detach lib/ns/interfacemgr.c:730:3
#7 purge_old_interfaces lib/ns/interfacemgr.c:770:4
#8 ns_interfacemgr_shutdown lib/ns/interfacemgr.c:401:2
#9 shutdown_server bin/named/server.c:10086:2
#10 task_run lib/isc/task.c:816:5
#11 isc_task_run lib/isc/task.c:896:10
#12 isc__nm_async_task lib/isc/netmgr/netmgr.c:863:11
#13 process_netievent lib/isc/netmgr/netmgr.c:942:3
#14 process_queue lib/isc/netmgr/netmgr.c:1032:16
#15 process_all_queues lib/isc/netmgr/netmgr.c:783:25
#16 async_cb lib/isc/netmgr/netmgr.c:812:6
#17 <null> <null>
#18 isc__trampoline_run lib/isc/trampoline.c:184:11
Previous read of size 8 at 0x000000000001 by thread T2:
#0 memmove <null>
#1 isc___nmhandle_get lib/isc/netmgr/netmgr.c
#2 isc__nm_get_read_req lib/isc/netmgr/netmgr.c:2130:18
#3 isc__nm_tcpdns_processbuffer lib/isc/netmgr/tcpdns.c:787:8
#4 processbuffer lib/isc/netmgr/netmgr.c:2257:11
#5 isc__nm_process_sock_buffer lib/isc/netmgr/netmgr.c:2282:25
#6 isc__nm_resume_processing lib/isc/netmgr/netmgr.c:2338:2
#7 nmhandle_detach_cb lib/isc/netmgr/netmgr.c:1864:4
#8 isc__nmhandle_detach lib/isc/netmgr/netmgr.c:1804:3
#9 isc___nm_uvreq_put lib/isc/netmgr/netmgr.c:2462:3
#10 isc__nm_async_sendcb lib/isc/netmgr/netmgr.c:2748:2
#11 process_netievent lib/isc/netmgr/netmgr.c:994:3
#12 process_queue lib/isc/netmgr/netmgr.c:1032:16
#13 process_all_queues lib/isc/netmgr/netmgr.c:783:25
#14 async_cb lib/isc/netmgr/netmgr.c:812:6
#15 <null> <null>
#16 isc__trampoline_run lib/isc/trampoline.c:184:11
Location is heap block of size 1392 at 0x000000000032 allocated by thread T1:
#0 malloc <null>
#1 default_memalloc lib/isc/mem.c:411:8
#2 mem_get lib/isc/mem.c:343:8
#3 mem_allocateunlocked lib/isc/mem.c:918:7
#4 isc__mem_allocate lib/isc/mem.c:935:7
#5 isc__mem_get lib/isc/mem.c:740:11
#6 ns_interface_create lib/ns/interfacemgr.c:412:8
#7 ns_interface_setup lib/ns/interfacemgr.c:599:11
#8 do_scan lib/ns/interfacemgr.c:1199:14
#9 ns_interfacemgr_scan0 lib/ns/interfacemgr.c:1258:11
#10 ns_interfacemgr_scan lib/ns/interfacemgr.c:1306:11
#11 load_configuration bin/named/server.c:9110:11
#12 run_server bin/named/server.c:10054:2
#13 task_run lib/isc/task.c:816:5
#14 isc_task_run lib/isc/task.c:896:10
#15 isc__nm_async_task lib/isc/netmgr/netmgr.c:863:11
#16 process_netievent lib/isc/netmgr/netmgr.c:942:3
#17 process_queue lib/isc/netmgr/netmgr.c:1032:16
#18 process_all_queues lib/isc/netmgr/netmgr.c:783:25
#19 async_cb lib/isc/netmgr/netmgr.c:812:6
#20 <null> <null>
#21 isc__trampoline_run lib/isc/trampoline.c:184:11
Mutex M1 is already destroyed.
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:79:8
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:347:3
#3 isc_managers_create lib/isc/managers.c:39:2
#4 create_managers bin/named/main.c:941:11
#5 setup bin/named/main.c:1216:11
#6 main bin/named/main.c:1507:2
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:79:8
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:347:3
#3 isc_managers_create lib/isc/managers.c:39:2
#4 create_managers bin/named/main.c:941:11
#5 setup bin/named/main.c:1216:11
#6 main bin/named/main.c:1507:2
SUMMARY: ThreadSanitizer: data race in memset
```June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2722bad sizeof declaration in main2021-05-26T08:10:47ZMark Andrewsbad sizeof declaration in main```
** CID 331858: Incorrect expression (SIZEOF_MISMATCH)
/lib/ns/interfacemgr.c: 274 in ns_interfacemgr_create()
________________________________________________________________________________________________________
*** CID 331858...```
** CID 331858: Incorrect expression (SIZEOF_MISMATCH)
/lib/ns/interfacemgr.c: 274 in ns_interfacemgr_create()
________________________________________________________________________________________________________
*** CID 331858: Incorrect expression (SIZEOF_MISMATCH)
/lib/ns/interfacemgr.c: 274 in ns_interfacemgr_create()
268 #else /* ifdef USE_ROUTE_SOCKET */
269 isc_refcount_init(&mgr->references, 1);
270 #endif /* ifdef USE_ROUTE_SOCKET */
271 mgr->magic = IFMGR_MAGIC;
272 *mgrp = mgr;
273
CID 331858: Incorrect expression (SIZEOF_MISMATCH)
Passing argument "mgr->ncpus * 184UL /* sizeof (*mgr->clientmgrs[0]) */" to function "isc__mem_get" and then casting the return value to "ns_clientmgr_t **" is suspicious.
274 mgr->clientmgrs = isc_mem_get(mgr->mctx,
275 mgr->ncpus * sizeof(*mgr->clientmgrs[0]));
276 for (size_t i = 0; i < (size_t)mgr->ncpus; i++) {
277 result = ns_clientmgr_create(mgr->sctx, mgr->taskmgr,
278 mgr->timermgr, mgr->aclenv, (int)i,
279 &mgr->clientmgrs[i]);
________________________________________________________________________________________________________
```June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)https://gitlab.isc.org/isc-projects/bind9/-/issues/2723TLS key logging2021-12-22T20:08:49ZPetr Špačekpspacek@isc.orgTLS key logging### Description
Use-case: DoT/DoH debugging
Debugging encrypted transports is very hard because we do not see in the traffic, so plain PCAPs are useless.
### Request
Introduce a new logging channel for TLS keys, which would produce st...### Description
Use-case: DoT/DoH debugging
Debugging encrypted transports is very hard because we do not see in the traffic, so plain PCAPs are useless.
### Request
Introduce a new logging channel for TLS keys, which would produce stream of TLS pre-master secrets which can be used with Wireshark to decrypt TLS traffic. (Volume of the logged data can be significant so it's important to have some size limits on the file size - that's why I'm proposing to reuse logging machinery we have already.)
Open question is if it should somehow take into account `SSLKEYLOGFILE` environment variable as it is customary in [GnuTLS](https://gnutls.org/manual/html_node/Debugging-and-auditing.html) and [NSS](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format). The reason is that environment variable will be easier to use when debugging something in an automated test systems (as opposed to modifying named.conf). Maybe `SSLKEYLOGFILE` environment variable could, if present, just generate in-memory logging config snippet?
### Links / references
- https://wiki.wireshark.org/TLS#Using_the_.28Pre.29-Master-Secret
- https://www.openssl.org/docs/man1.1.0/man3/SSL_SESSION_print_keylog.htmlJanuary 2022 (9.16.25, 9.16.25-S1, 9.17.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/2724statschannel system test sometimes hangs2021-06-02T22:39:47ZMichal Nowakstatschannel system test sometimes hangsThe `statschannel` sometimes hungs and the system test CI job is terminated by CI's 1 hour timeout, see a job on [`main`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1749344/raw) (Debian Buster)
```
S:statschannel:2021-05-26T04:40:0...The `statschannel` sometimes hungs and the system test CI job is terminated by CI's 1 hour timeout, see a job on [`main`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1749344/raw) (Debian Buster)
```
S:statschannel:2021-05-26T04:40:00+0000
T:statschannel:1:A
A:statschannel:System test statschannel
I:statschannel:PORTS:24535,24536,24537,24538,24539,24540,24541,24542,24543,24544,24545,24546,24547
I:statschannel:starting servers
I:statschannel:checking consistency between named.stats and xml/json (1)
I:statschannel:checking malloced memory statistics xml/json (2)
I:statschannel:checking consistency between regular and compressed output (3)
I:statschannel:checking if compressed output is really compressed (4)
I:statschannel:fetching zone stats data after zone maintenance at startup (5)
I:statschannel:... using xml
I:statschannel:... using json
I:statschannel:fetching zone stats data after dynamic update (6)
I:statschannel:... using xml
I:statschannel:... using json
I:statschannel:fetch zone stats data after updating DNSKEY RRset (7)
I:statschannel:... using xml
I:statschannel:... using json
I:statschannel:exit status: 0
I:statschannel:stopping servers
I:statschannel:starting servers
D:statschannel:============================= test session starts ==============================
D:statschannel:platform linux -- Python 3.7.3, pytest-3.10.1, py-1.7.0, pluggy-0.8.0 -- /usr/bin/python3
D:statschannel:rootdir: /builds/isc-projects/bind9/bin/tests/system/statschannel, inifile:
D:statschannel:collecting ... collected 4 items
D:statschannel:
D:statschannel:tests-xml.py::test_zone_timers_primary_xml PASSED [ 25%]
D:statschannel:tests-xml.py::test_zone_timers_secondary_xml PASSED [ 50%]
D:statschannel:tests-xml.py::test_zone_with_many_keys_xml PASSED [ 75%]
D:statschannel:tests-xml.py::test_traffic_xml PASSED [100%]
D:statschannel:
D:statschannel:=========================== 4 passed in 0.08 seconds ===========================
I:statschannel:stopping servers
I:statschannel:starting servers
D:statschannel:============================= test session starts ==============================
D:statschannel:platform linux -- Python 3.7.3, pytest-3.10.1, py-1.7.0, pluggy-0.8.0 -- /usr/bin/python3
D:statschannel:rootdir: /builds/isc-projects/bind9/bin/tests/system/statschannel, inifile:
D:statschannel:collecting ... collected 4 items
D:statschannel:
D:statschannel:tests-json.py::test_zone_timers_primary_json PASSED [ 25%]
D:statschannel:tests-json.py::test_zone_timers_secondary_json PASSED [ 50%]
```
and [`v9_16`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1749328/raw) (openSUSE Tumbleweed):
```
S:statschannel:2021-05-26T04:37:15+0000
T:statschannel:1:A
A:statschannel:System test statschannel
I:statschannel:PORTRANGE:12700 - 12799
I:statschannel:starting servers
I:statschannel:checking consistency between named.stats and xml/json (1)
I:statschannel:checking malloced memory statistics xml/json (2)
I:statschannel:checking consistency between regular and compressed output (3)
I:statschannel:checking if compressed output is really compressed (4)
I:statschannel:fetching zone stats data after zone maintenance at startup (5)
I:statschannel:... using xml
I:statschannel:... using json
I:statschannel:fetching zone stats data after dynamic update (6)
I:statschannel:... using xml
I:statschannel:... using json
I:statschannel:fetch zone stats data after updating DNSKEY RRset (7)
I:statschannel:... using xml
I:statschannel:... using json
I:statschannel:exit status: 0
I:statschannel:stopping servers
I:statschannel:starting servers
D:statschannel:============================= test session starts ==============================
D:statschannel:platform linux -- Python 3.8.10, pytest-6.2.4, py-1.10.0, pluggy-0.13.1 -- /usr/bin/python3.8
D:statschannel:rootdir: /builds/isc-projects/bind9/bin/tests/system/statschannel
D:statschannel:collecting ... collected 4 items
D:statschannel:
D:statschannel:tests-xml.py::test_zone_timers_primary_xml PASSED [ 25%]
D:statschannel:tests-xml.py::test_zone_timers_secondary_xml PASSED [ 50%]
```
I started noticing this hang this or the week before.
Looking at the system test itself, there were no significant changes for some time.
Unfortunately, with timeout termination there are no job artifacts.June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)https://gitlab.isc.org/isc-projects/bind9/-/issues/2726inline signed zone journal goes out of sync if zone is modified when restarti...2021-05-27T22:30:22ZMichel Lespinasseinline signed zone journal goes out of sync if zone is modified when restarting bind9### Summary
When restarting bind9, it seems to be easy for inline signed zones to go out of sync with their journal. Note, the issue does not happen when reloading bind9.
### BIND version used
Debian buster-backports package version 1...### Summary
When restarting bind9, it seems to be easy for inline signed zones to go out of sync with their journal. Note, the issue does not happen when reloading bind9.
### BIND version used
Debian buster-backports package version 1:9.16.15-1~bpo10+1
### Steps to reproduce
- configure some inline signed zone. Mine are master zones with a dnssec-policy applied.
- start bind (using /etc/init.d/named start)
- edit the zone file
- restart bind (using /etc/init.d/named restart)
- the modified zone fails to load:
~~~
zone test.lespinasse.org/IN/public (unsigned): journal rollforward failed: journal out of sync with zone
zone test.lespinasse.org/IN/public (unsigned): not loaded due to errors.
~~~
Note, everything works fine if one reloads bind (using etc/init.d/named reload, or just rndc reload). Also, the server restats without issue if one edits the zone file, reloads bind to sync up the journal, and then issues the restart.
### What is the current *bug* behavior?
any edited zone fails to load when the server is restarted, without having been reloaded first.
### What is the expected *correct* behavior?
reload and restart should both pick up the current zone file.
### Relevant configuration files
### Relevant logs and/or screenshots
I think I covered the basics; I can provide more details on request.https://gitlab.isc.org/isc-projects/bind9/-/issues/2727dig package for Windows2023-11-02T16:24:19ZVicky Riskvicky@isc.orgdig package for WindowsWe plan to end support for Windows with 9.18. It seems like there are a number of users who need dig on Windows, so if we can build a dig package for Windows and host that on our website for download, that would be very useful.We plan to end support for Windows with 9.18. It seems like there are a number of users who need dig on Windows, so if we can build a dig package for Windows and host that on our website for download, that would be very useful.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2728BIND-9.16 and managed-keys-zone2022-06-24T20:22:48ZStanislav LevinBIND-9.16 and managed-keys-zone<!--
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
Wrong cache for `managed-keys` database.
### BIND version used
```console
[root@master1 /]# named -v
BIND 9.16.15-RH (Stable Release) <id:4469e3e>
```
### Steps to reproduce
This is the imitation of first run.
```console
[root@master1 /]# systemctl stop named
# remove current managed-keys
[root@master1 /]# rm -f /var/named/dynamic/managed-keys.bind*
# set forwarders with not existed or not available(offline), in my example I set it to '8.8.8.123' and forward policy 'only'
forward only;
forwarders {8.8.8.123;};
dnssec-validation auto(or yes);
[root@master1 /]# systemctl start named
[root@master1 /]# dig +dnssec mirrors.fedoraproject.org
; <<>> DiG 9.16.15-RH <<>> +dnssec mirrors.fedoraproject.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 23320
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 9297a095e3be13020100000060ae6af11adeea19e019f898 (good)
;; QUESTION SECTION:
;mirrors.fedoraproject.org. IN A
;; Query time: 3000 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed May 26 15:36:17 UTC 2021
;; MSG SIZE rcvd: 82
[root@master1 /]# cat /var/named/data/dnssec.log
26-May-2021 15:36:13.254 warning: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out
[root@master1 /]# cat /var/named/dynamic/managed-keys.bind
$ORIGIN .
$TTL 0 ; 0 seconds
@ IN SOA . . (
2 ; serial
0 ; refresh (0 seconds)
0 ; retry (0 seconds)
0 ; expire (0 seconds)
0 ; minimum (0 seconds)
)
KEYDATA 20210526163613 19700101000000 19700101000000 0 0 0 (
) ; ZSK; alg = 0; key id = 0
; next refresh: Wed, 26 May 2021 16:36:13 GMT
; no trust
# make the forwarder online
forwarders {8.8.8.8;};
[root@master1 /]# systemctl restart named
[root@master1 /]# dig +dnssec mirrors.fedoraproject.org
; <<>> DiG 9.16.15-RH <<>> +dnssec mirrors.fedoraproject.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21419
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 20598bf16da011a90100000060ae6b9240e3281a7a1f4680 (good)
;; QUESTION SECTION:
;mirrors.fedoraproject.org. IN A
;; Query time: 171 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed May 26 15:38:58 UTC 2021
;; MSG SIZE rcvd: 82
[root@master1 /]# cat /var/named/dynamic/managed-keys.bind
$ORIGIN .
$TTL 0 ; 0 seconds
@ IN SOA . . (
2 ; serial
0 ; refresh (0 seconds)
0 ; retry (0 seconds)
0 ; expire (0 seconds)
0 ; minimum (0 seconds)
)
KEYDATA 20210526163613 19700101000000 19700101000000 0 0 0 (
) ; ZSK; alg = 0; key id = 0
; next refresh: Wed, 26 May 2021 16:36:13 GMT
; no trust
[root@master1 /]# cat /var/named/data/dnssec.log
26-May-2021 15:36:13.254 warning: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out
26-May-2021 15:38:54.052 info: managed-keys-zone: DNSKEY set for zone '.' could not be verified with current keys
26-May-2021 15:38:58.312 info: validating org/DS: no valid signature found
26-May-2021 15:38:58.312 info: validating org/DNSKEY: bad cache hit (org/DS)
[root@master1 /]# cat /var/named/data/query_errors.log
26-May-2021 15:36:17.818 info: client @0x7f8154000cc8 ::1#48423 (mirrors.fedoraproject.org): query failed (timed out) for mirrors.fedoraproject.org/IN/A at ../../../lib/ns/query.c:7360
26-May-2021 15:36:17.818 info: client @0x7f81440104c8 127.0.0.1#50230 (mirrors.fedoraproject.org): query failed (timed out) for mirrors.fedoraproject.org/IN/A at ../../../lib/ns/query.c:7360
26-May-2021 15:38:58.313 info: client @0x7fd9d00104c8 127.0.0.1#59004 (mirrors.fedoraproject.org): query failed (broken trust chain) for mirrors.fedoraproject.org/IN/A at ../../../lib/ns/query.c:7360
```
### What is the current *bug* behavior?
In this case BIND answers SERVFAIL to all queries unless I stop it and manually remove managed-keys.bind and its journal.
In my opinion `managed-keys` zone should automatically be reconfigured since it's empty.July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)Brian ConryBrian Conryhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2729[FreeBSD] could not listen on UDP socket: permission denied ; creating IPv4 i...2021-05-27T03:38:35Zyuri@FreeBSD[FreeBSD] could not listen on UDP socket: permission denied ; creating IPv4 interface sk0 failed; interface ignoredI am getting these messages in ```/var/log/messages```:
```
$ grep named /var/log/messages
May 25 18:43:06 yv named[1416]: could not listen on UDP socket: permission denied
May 25 18:43:06 yv named[1416]: creating IPv4 interface sk0 fail...I am getting these messages in ```/var/log/messages```:
```
$ grep named /var/log/messages
May 25 18:43:06 yv named[1416]: could not listen on UDP socket: permission denied
May 25 18:43:06 yv named[1416]: creating IPv4 interface sk0 failed; interface ignored
May 25 19:43:06 yv named[1416]: could not listen on UDP socket: permission denied
May 25 19:43:06 yv named[1416]: creating IPv4 interface sk0 failed; interface ignored
May 25 20:43:06 yv named[1416]: could not listen on UDP socket: permission denied
May 25 20:43:06 yv named[1416]: creating IPv4 interface sk0 failed; interface ignored
May 25 21:43:06 yv named[1416]: could not listen on UDP socket: permission denied
May 25 21:43:06 yv named[1416]: creating IPv4 interface sk0 failed; interface ignored
May 25 22:43:06 yv named[1416]: could not listen on UDP socket: permission denied
May 25 22:43:06 yv named[1416]: creating IPv4 interface sk0 failed; interface ignored
May 25 23:43:06 yv named[1416]: could not listen on UDP socket: permission denied
May 25 23:43:06 yv named[1416]: creating IPv4 interface sk0 failed; interface ignored
May 26 00:17:03 yv named[1416]: could not listen on UDP socket: permission denied
May 26 00:17:03 yv named[1416]: creating IPv4 interface sk0 failed; interface ignored
May 26 00:17:03 yv named[1416]: could not listen on UDP socket: permission denied
May 26 00:17:03 yv named[1416]: creating IPv4 interface sk0 failed; interface ignored
```
```sockstat``` shows that ```named``` listens on the DNS socket:
```
$ sudo sockstat -l | grep named
bind named 1416 21 tcp6 *:53 *:*
bind named 1416 22 tcp4 127.0.0.1:953 *:*
bind named 1416 23 tcp6 ::1:953 *:*
bind named 1416 512 udp6 *:53 *:*
bind named 1416 513 udp6 *:53 *:*
bind named 1416 514 udp6 *:53 *:*
bind named 1416 515 udp6 *:53 *:*
bind named 1416 516 udp6 *:53 *:*
bind named 1416 517 udp6 *:53 *:*
bind named 1416 518 udp6 *:53 *:*
```
bind911-9.11.31 (installed from the port)
FreeBSD 13https://gitlab.isc.org/isc-projects/bind9/-/issues/2730[ISC-support #18552] Logging category for notify/xfer related messages2024-03-27T13:17:04ZChuck Stearns[ISC-support #18552] Logging category for notify/xfer related messages### Description
Logging category for notify/xfer related messages
### Request
The notify category does not include some messages that end up in the general category. There are also some messages that might be better placed in xfer-in....### Description
Logging category for notify/xfer related messages
### Request
The notify category does not include some messages that end up in the general category. There are also some messages that might be better placed in xfer-in. For instance, "notify from" and "refused notify from non-master". The intent is to have all messages useful for troubleshooting an aspect of operation in one log. For example, if troubleshooting zone transfer issues, the relevant messages would be in the transfer.log. This segregation also facilitates some noise reduction when using dynamic severity.
### Links / referencesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2731possible crash after answering DNS64 query with stale data2021-05-31T09:02:56ZEvan Huntpossible crash after answering DNS64 query with stale dataWhen a stale answer is sent to a client, the server continues processing the recursive query in hopes of getting a real answer. If an answer does arrive afterward, and DNS64 is enabled, an assertion failure can occur because `client->que...When a stale answer is sent to a client, the server continues processing the recursive query in hopes of getting a real answer. If an answer does arrive afterward, and DNS64 is enabled, an assertion failure can occur because `client->query.dns64_aaaa` was already set by the stale answer.June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)https://gitlab.isc.org/isc-projects/bind9/-/issues/2732Zone dumping is blocking the networking IO2021-06-07T12:43:40ZOndřej SurýZone dumping is blocking the networking IOJune 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2733"stale-answer-client-timeout" > 0 can cause crashes when prefetch is enabled2021-06-03T12:55:33ZMichał Kępień"stale-answer-client-timeout" > 0 can cause crashes when prefetch is enabled`named` can crash in the following scenario:
1. Assume that `stale-answer-client-timeout` is set to a positive value
and that in the course of resolving a `cname.example/A` query, the
following records were cached:
```
...`named` can crash in the following scenario:
1. Assume that `stale-answer-client-timeout` is set to a positive value
and that in the course of resolving a `cname.example/A` query, the
following records were cached:
```
cname.example. CNAME a.example. ; TTL=10
a.example. A 192.0.2.1 ; TTL=12
```
2. 10 seconds pass, causing the relevant cache contents to become:
```
cname.example. CNAME a.example. ; expired
a.example. A 192.0.2.1 ; TTL=2
```
3. The resolver is queried for `cname.example/A` again.
4. `cname.example/CNAME` is expired, so recursion starts. As a part of
this process, the `DNS_FETCHOPT_TRYSTALE_ONTIMEOUT` flag is [set][1]
in `client->query.fetchoptions`.
5. The authoritative response for `cname.example/CNAME` arrives before
`a.example/A` expires from the cache.
6. Query processing is restarted for `a.example/A` (the CNAME target).
7. `a.example/A` is found in the cache with a positive TTL which falls
below the default prefetch trigger (2 seconds).
8. A prefetch for `a.example/A` is started with
`DNS_FETCHOPT_TRYSTALE_ONTIMEOUT` still being set. This causes the
"try stale" timer to be started for the prefetch query.
9. No response to the prefetch query arrives before the "try stale"
timeout fires.
10. `prefetch_done()` is called and is passed an event of type
`DNS_EVENT_TRYSTALE`.
11. The `REQUIRE(event->ev_type == DNS_EVENT_FETCHDONE);` [assertion][2]
fails, causing `named` to crash.
See: https://support.isc.org/Ticket/Display.html?id=18536
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/e7f5c9582a8b3c441f57c33785ad8113b59428c0/lib/ns/query.c#L6429-6434
[2]: https://gitlab.isc.org/isc-projects/bind9/-/blob/e7f5c9582a8b3c441f57c33785ad8113b59428c0/lib/ns/query.c#L2491June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)https://gitlab.isc.org/isc-projects/bind9/-/issues/2734dns64 processing of stale AAAA doesn't use a non-stale A2023-11-02T16:26:07ZEvan Huntdns64 processing of stale AAAA doesn't use a non-stale AIn [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5102#note_216731) in !5102, @michal pointed out an edge case in stale-data/dns64 processing that may be a bug:
- we're searching for AAAA, but the auth server is...In [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5102#note_216731) in !5102, @michal pointed out an edge case in stale-data/dns64 processing that may be a bug:
- we're searching for AAAA, but the auth server is slow
- we reach the stale answer timeout, but we don't have a stale AAAA in the cache
- but we have a _current_ A record in the cache
- ...but dns64 can't use it to synthesize a reply, because when we're processing a stale timeout we only look for _stale_ data.
This can be observed by applying these changes to the test code that was introduced in that MR:
```
diff --git a/bin/tests/system/serve-stale/ans2/ans.pl b/bin/tests/system/serve-stale/ans2/ans.pl
index a046417e09c..5e11f22cf6a 100644
--- a/bin/tests/system/serve-stale/ans2/ans.pl
+++ b/bin/tests/system/serve-stale/ans2/ans.pl
@@ -119,7 +119,7 @@ sub reply_handler {
$rcode = "NOERROR";
} elsif ($qname eq "a-only.example") {
if ($qtype eq "A") {
- my $rr = new Net::DNS::RR("a-only.example 2 IN A $localaddr");
+ my $rr = new Net::DNS::RR("a-only.example 5 IN A $localaddr");
push @ans, $rr;
} else {
my $rr = new Net::DNS::RR($negSOA);
diff --git a/bin/tests/system/serve-stale/tests.sh b/bin/tests/system/serve-stale/tests.sh
index b287f8c1f07..7ac0288d329 100755
--- a/bin/tests/system/serve-stale/tests.sh
+++ b/bin/tests/system/serve-stale/tests.sh
@@ -2216,7 +2216,7 @@ $DIG -p ${PORT} @10.53.0.2 txt disable > /dev/null
# wait two seconds for the previous answer to become stale
sleep 2
# resend the query and wait in the background; we should get a stale answer
-$DIG -p ${PORT} @10.53.0.3 a-only.example AAAA > dig.out.2.test$n &
+$DIG -p ${PORT} +tries=1 @10.53.0.3 a-only.example AAAA > dig.out.2.test$n &
# re-enable queries after a pause, so the server gets a real answer too
sleep 2
$DIG -p ${PORT} @10.53.0.2 txt enable > /dev/null
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2735BIND 9.16, must stop named, delete .jnl files for signed zones to be updated2021-08-22T08:15:10ZHakan GustafssonBIND 9.16, must stop named, delete .jnl files for signed zones to be updated<!--
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
For a signed zone to be updated I have to stop named, delete all the "." files, update the serial number and then start named again. If I do a normal update, just update the serial number and then run "rndc reload", I got this error message "29-May-2021 13:54:52.008 general: error: zone ******.se/IN (signed): receive_secure_serial: unchanged", and the zone don't update. I have had this issue in previous versions also, now I run 9.16.16.
### BIND version used
```
BIND 9.16.16 (Stable Release) <id:0c314d8>
running on Linux x86_64 4.18.0-305.el8.x86_64 #1 SMP Thu Apr 29 08:54:30 EDT 2021
built by make with '--prefix=/service/dns/bind-9.16.16' '--sysconfdir=/data/dns/named' '--localstatedir=/var' '--with-openssl=/service/dns/openssl' 'LDFLAGS=-ldl'
compiled by GCC 8.4.1 20200928 (Red Hat 8.4.1-1)
compiled with OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
linked to OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
compiled with libuv version: 1.23.1
linked to libuv version: 1.23.1
compiled with libxml2 version: 2.9.7
linked to libxml2 version: 20907
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
default paths:
named configuration: /data/dns/named/named.conf
rndc configuration: /data/dns/named/rndc.conf
DNSSEC root key: /data/dns/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
Update the serial number for signed zone och then do a "rndc reload"
### What is the current *bug* behavior?
The zone doesn't update
### What is the expected *correct* behavior?
The zone should be updated after I have changed the serial number
### Relevant configuration files
I use a manually policy for signed zones, "dnssec-policy modified;"
```
dnssec-policy "modified" {
keys {
csk lifetime unlimited algorithm rsasha256 2048;
};
};
```
### Relevant logs and/or screenshots
"29-May-2021 13:54:52.008 general: error: zone ******.se/IN (signed): receive_secure_serial: unchanged"
### Possible fixes
The workaround is to stop named, delete all "." files (.jbk, .jnl, .signed, .signed.jnl), update the serial number, start named again.August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2736when I manually roll back the time, The slave server cannot synchronize data ...2021-06-02T03:32:55Zjin ggwhen I manually roll back the time, The slave server cannot synchronize data from the master server.The test case is as follows:
1. The bind version is **v9_11**:
2. named.conf in master server(192.168.1.10)(Some unnecessary information is omitted.):
```
options {
listen-on port 53 { 192.168.1.10; };
listen-on-v6 port...The test case is as follows:
1. The bind version is **v9_11**:
2. named.conf in master server(192.168.1.10)(Some unnecessary information is omitted.):
```
options {
listen-on port 53 { 192.168.1.10; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
allow-query { any; };
allow-transfer { localhost; 192.168.1.11; };
notify yes;
also-notify { 192.168.1.11; };
recursion yes;
};
zone "test.com" IN {
type master;
file "test.com.zone";
};
```
3. named.conf in slave server(192.168.1.11)(Some unnecessary information is omitted.):
```
options {
listen-on port 53 { 192.168.1.11; };
listen-on-v6 port 53 { ::1; };
allow-query { any; };
notify yes;
also-notify { 192.168.1.10; };
recursion yes;
};
zone "test.com" IN {
type slave;
file "slaves/test.com.zone";
masters { 9.99.88.99; };
};
```
4. test.com.zone:
```
$TTL 1D
@ IN SOA ns1 rname.invalid. (
2019062905 ; serial
5M ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
NS ns1
ns1 IN A 9.99.88.77
www IN A 9.99.100.100
NS ns2
ns2 IN A 9.82.177.0
```
5. modify serial to 2019062906, add bbs1 in master(192.168.1.10) and restart master:
```
$TTL 1D
@ IN SOA ns1 rname.invalid. (
2019062906 ; serial
5M ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
NS ns1
ns1 IN A 9.99.88.77
www IN A 9.99.100.100
NS ns2
ns2 IN A 9.82.177.0
bbs IN A 1.1.1.10
bbs1 IN A 1.1.1.11
```
6. dig -t a bbs1.test.com @192.168.1.11 (slave)
```
;; ANSWER SECTION:
bbs1.test.com. 86400 IN A 1.1.1.11
```
7. manually roll back the slave time
```
date -s "-1 year"
```
8. modify serial to 2019062907, add bbs2 in master(192.168.1.10) and restart master:
```
$TTL 1D
@ IN SOA ns1 rname.invalid. (
2019062907 ; serial
5M ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
NS ns1
ns1 IN A 9.99.88.77
www IN A 9.99.100.100
NS ns2
ns2 IN A 9.82.177.0
bbs IN A 1.1.1.10
bbs1 IN A 1.1.1.11
bbs2 IN A 1.1.1.12
```
9. test the synchronization between the master and slave:
```
dit -t a bbs2.test.com @192.168.1.11
```
10. Modifications in master cannot be synchronized.
I think the reason for this error is that the isc_time_now function uses CLOCK_REALTIME(or gettimeofday fuction) instead of CLOCK_MONOTONIC as the clock source.
this error can be fixed when I used CLOCK_MONOTONIC as the clock source and solved some conversion problems between isc_time_now and isc_stdtime_now.
# Possible fixes
The patch is as follow(**the modification based on v9_11**):
```
From 310e717804a226a75f40786e31f04aa7b3d77d71 Mon Sep 17 00:00:00 2001
From: jiangh <853048484@qq.com>
Date: Sat, 29 May 2021 20:45:55 +0800
Subject: [PATCH] Fix errors when time jumps
---
bin/named/client.c | 2 +-
bin/named/query.c | 4 +-
lib/dns/rbtdb.c | 4 +-
lib/dns/zone.c | 7 ++--
lib/isc/task.c | 2 +-
lib/isc/unix/time.c | 93 +++++++++------------------------------------
6 files changed, 28 insertions(+), 84 deletions(-)
diff --git a/bin/named/client.c b/bin/named/client.c
index 15fcfcd3c3..860a01309c 100644
--- a/bin/named/client.c
+++ b/bin/named/client.c
@@ -2558,7 +2558,7 @@ client_request(isc_task_t *task, isc_event_t *event) {
isc_task_getcurrenttimex(task, &client->requesttime);
client->tnow = client->requesttime;
- client->now = isc_time_seconds(&client->tnow);
+ isc_stdtime_get(&client->now);
if (result != ISC_R_SUCCESS) {
if (TCP_CLIENT(client)) {
diff --git a/bin/named/query.c b/bin/named/query.c
index f1098056b8..bca0ccd570 100644
--- a/bin/named/query.c
+++ b/bin/named/query.c
@@ -9123,11 +9123,11 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
uint32_t secs;
dns_zone_getexpiretime(zone, &expiretime);
secs = isc_time_seconds(&expiretime);
- if (secs >= client->now &&
+ if (secs >= isc_time_seconds(&client->tnow) &&
result == ISC_R_SUCCESS) {
client->attributes |=
NS_CLIENTATTR_HAVEEXPIRE;
- client->expire = secs - client->now;
+ client->expire = secs - isc_time_seconds(&client->tnow);
}
}
if (dns_zone_gettype(mayberaw) == dns_zone_master) {
diff --git a/lib/dns/rbtdb.c b/lib/dns/rbtdb.c
index 3ee18766cd..779b4247fb 100644
--- a/lib/dns/rbtdb.c
+++ b/lib/dns/rbtdb.c
@@ -6858,8 +6858,10 @@ addrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
}
if (rbtversion == NULL) {
- if (now == 0)
+ if (now == 0) {
isc_stdtime_get(&now);
+ }
+
} else
now = 0;
diff --git a/lib/dns/zone.c b/lib/dns/zone.c
index 4f7c2a773a..97589e4d8d 100644
--- a/lib/dns/zone.c
+++ b/lib/dns/zone.c
@@ -10198,6 +10198,7 @@ static void
zone_maintenance(dns_zone_t *zone) {
const char me[] = "zone_maintenance";
isc_time_t now;
+ isc_stdtime_t tnow;
isc_result_t result;
bool dumping, load_pending, viewok, start_refresh;
bool need_notify;
@@ -10231,6 +10232,7 @@ zone_maintenance(dns_zone_t *zone) {
}
TIME_NOW(&now);
+ isc_stdtime_get(&tnow);
/*
* Expire check.
@@ -10384,8 +10386,7 @@ zone_maintenance(dns_zone_t *zone) {
*/
if (!isc_time_isepoch(&zone->keywarntime) &&
isc_time_compare(&now, &zone->keywarntime) >= 0)
- set_key_expiry_warning(zone, zone->key_expiry,
- isc_time_seconds(&now));
+ set_key_expiry_warning(zone, zone->key_expiry, tnow);
break;
default:
@@ -18733,7 +18734,7 @@ zone_rekey(dns_zone_t *zone) {
CHECK(dns_db_getoriginnode(db, &node));
TIME_NOW(&timenow);
- now = isc_time_seconds(&timenow);
+ isc_stdtime_get(&now);
dns_zone_log(zone, ISC_LOG_INFO, "reconfiguring zone keys");
diff --git a/lib/isc/task.c b/lib/isc/task.c
index 048639350b..5f1f421d60 100644
--- a/lib/isc/task.c
+++ b/lib/isc/task.c
@@ -1138,7 +1138,7 @@ dispatch(isc__taskmgr_t *manager) {
XTRACE(isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL,
ISC_MSG_RUNNING, "running"));
TIME_NOW(&task->tnow);
- task->now = isc_time_seconds(&task->tnow);
+ isc_stdtime_get(&task->now);
do {
if (!EMPTY(task->events)) {
event = HEAD(task->events);
diff --git a/lib/isc/unix/time.c b/lib/isc/unix/time.c
index bcca41bd04..ae74ba8a98 100644
--- a/lib/isc/unix/time.c
+++ b/lib/isc/unix/time.c
@@ -38,16 +38,7 @@
#define NS_PER_MS 1000000 /*%< Nanoseconds per millisecond. */
#define US_PER_S 1000000 /*%< Microseconds per second. */
-/*
- * All of the INSIST()s checks of nanoseconds < NS_PER_S are for
- * consistency checking of the type. In lieu of magic numbers, it
- * is the best we've got. The check is only performed on functions which
- * need an initialized type.
- */
-
-#ifndef ISC_FIX_TV_USEC
-#define ISC_FIX_TV_USEC 1
-#endif
+#define CLOCKSOURCE CLOCK_MONOTONIC
/*%
*** Intervals
@@ -56,32 +47,6 @@
static const isc_interval_t zero_interval = { 0, 0 };
const isc_interval_t * const isc_interval_zero = &zero_interval;
-#if ISC_FIX_TV_USEC
-static inline void
-fix_tv_usec(struct timeval *tv) {
- bool fixed = false;
-
- if (tv->tv_usec < 0) {
- fixed = true;
- do {
- tv->tv_sec -= 1;
- tv->tv_usec += US_PER_S;
- } while (tv->tv_usec < 0);
- } else if (tv->tv_usec >= US_PER_S) {
- fixed = true;
- do {
- tv->tv_sec += 1;
- tv->tv_usec -= US_PER_S;
- } while (tv->tv_usec >=US_PER_S);
- }
- /*
- * Call syslog directly as was are called from the logging functions.
- */
- if (fixed)
- (void)syslog(LOG_ERR, "gettimeofday returned bad tv_usec: corrected");
-}
-#endif
-
void
isc_interval_set(isc_interval_t *i,
unsigned int seconds, unsigned int nanoseconds)
@@ -143,76 +108,52 @@ isc_time_isepoch(const isc_time_t *t) {
isc_result_t
isc_time_now(isc_time_t *t) {
- struct timeval tv;
+ struct timespec ts;
char strbuf[ISC_STRERRORSIZE];
REQUIRE(t != NULL);
- if (gettimeofday(&tv, NULL) == -1) {
+ if (clock_gettime(CLOCKSOURCE, &ts) == -1) {
isc__strerror(errno, strbuf, sizeof(strbuf));
UNEXPECTED_ERROR(__FILE__, __LINE__, "%s", strbuf);
return (ISC_R_UNEXPECTED);
}
- /*
- * Does POSIX guarantee the signedness of tv_sec and tv_usec? If not,
- * then this test will generate warnings for platforms on which it is
- * unsigned. In any event, the chances of any of these problems
- * happening are pretty much zero, but since the libisc library ensures
- * certain things to be true ...
- */
-#if ISC_FIX_TV_USEC
- fix_tv_usec(&tv);
- if (tv.tv_sec < 0)
- return (ISC_R_UNEXPECTED);
-#else
- if (tv.tv_sec < 0 || tv.tv_usec < 0 || tv.tv_usec >= US_PER_S)
+ if (ts.tv_sec < 0 || ts.tv_nsec < 0 || ts.tv_nsec >= NS_PER_S) {
return (ISC_R_UNEXPECTED);
-#endif
+ }
/*
* Ensure the tv_sec value fits in t->seconds.
*/
- if (sizeof(tv.tv_sec) > sizeof(t->seconds) &&
- ((tv.tv_sec | (unsigned int)-1) ^ (unsigned int)-1) != 0U)
+ if (sizeof(ts.tv_sec) > sizeof(t->seconds) &&
+ ((ts.tv_sec | (unsigned int)-1) ^ (unsigned int)-1) != 0U)
return (ISC_R_RANGE);
- t->seconds = tv.tv_sec;
- t->nanoseconds = tv.tv_usec * NS_PER_US;
+ t->seconds = ts.tv_sec;
+ t->nanoseconds = ts.tv_nsec;
return (ISC_R_SUCCESS);
}
isc_result_t
isc_time_nowplusinterval(isc_time_t *t, const isc_interval_t *i) {
- struct timeval tv;
+ struct timespec ts;
char strbuf[ISC_STRERRORSIZE];
REQUIRE(t != NULL);
REQUIRE(i != NULL);
INSIST(i->nanoseconds < NS_PER_S);
- if (gettimeofday(&tv, NULL) == -1) {
+ if (clock_gettime(CLOCKSOURCE, &ts) == -1) {
isc__strerror(errno, strbuf, sizeof(strbuf));
UNEXPECTED_ERROR(__FILE__, __LINE__, "%s", strbuf);
return (ISC_R_UNEXPECTED);
}
- /*
- * Does POSIX guarantee the signedness of tv_sec and tv_usec? If not,
- * then this test will generate warnings for platforms on which it is
- * unsigned. In any event, the chances of any of these problems
- * happening are pretty much zero, but since the libisc library ensures
- * certain things to be true ...
- */
-#if ISC_FIX_TV_USEC
- fix_tv_usec(&tv);
- if (tv.tv_sec < 0)
- return (ISC_R_UNEXPECTED);
-#else
- if (tv.tv_sec < 0 || tv.tv_usec < 0 || tv.tv_usec >= US_PER_S)
+ if (ts.tv_sec < 0 || ts.tv_nsec < 0 || ts.tv_nsec >= NS_PER_S) {
return (ISC_R_UNEXPECTED);
-#endif
+ }
/*
* Ensure the resulting seconds value fits in the size of an
@@ -220,12 +161,12 @@ isc_time_nowplusinterval(isc_time_t *t, const isc_interval_t *i) {
* note that even if both values == INT_MAX, then when added
* and getting another 1 added below the result is UINT_MAX.)
*/
- if ((tv.tv_sec > INT_MAX || i->seconds > INT_MAX) &&
- ((long long)tv.tv_sec + i->seconds > UINT_MAX))
+ if ((ts.tv_sec > INT_MAX || i->seconds > INT_MAX) &&
+ ((long long)ts.tv_sec + i->seconds > UINT_MAX))
return (ISC_R_RANGE);
- t->seconds = tv.tv_sec + i->seconds;
- t->nanoseconds = tv.tv_usec * NS_PER_US + i->nanoseconds;
+ t->seconds = ts.tv_sec + i->seconds;
+ t->nanoseconds = ts.tv_nsec + i->nanoseconds;
if (t->nanoseconds >= NS_PER_S) {
t->seconds++;
t->nanoseconds -= NS_PER_S;
--
2.28.0.windows.1
```https://gitlab.isc.org/isc-projects/bind9/-/issues/2738LeakSanitizer: detected memory leaks in in ns_listenelt_create()2022-12-14T18:30:51ZOndřej SurýLeakSanitizer: detected memory leaks in in ns_listenelt_create()```
=================================================================
==21575==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 352 byte(s) in 1 object(s) allocated from:
#0 0x4ac0cd in malloc (/builds/isc-projects/bind9/b...```
=================================================================
==21575==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 352 byte(s) in 1 object(s) allocated from:
#0 0x4ac0cd in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x4ac0cd)
#1 0x7f513ede8558 in CRYPTO_zalloc (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x18e558)
Indirect leak of 10040 byte(s) in 68 object(s) allocated from:
#0 0x4ac0cd in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x4ac0cd)
#1 0x7f513ede8558 in CRYPTO_zalloc (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x18e558)
Indirect leak of 526 byte(s) in 1 object(s) allocated from:
#0 0x4ac0cd in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x4ac0cd)
#1 0x7f513ed0c260 (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1+0xb2260)
Indirect leak of 512 byte(s) in 1 object(s) allocated from:
#0 0x4ac0cd in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x4ac0cd)
#1 0x7f513ecfd16a in ASN1_item_sign_ctx (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1+0xa316a)
Indirect leak of 312 byte(s) in 3 object(s) allocated from:
#0 0x4ac0cd in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x4ac0cd)
#1 0x7f513ed2b3c6 in BN_MONT_CTX_new (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1+0xd13c6)
Indirect leak of 208 byte(s) in 2 object(s) allocated from:
#0 0x4ac0cd in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x4ac0cd)
#1 0x7f513ed3ac9b in BUF_MEM_grow (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1+0xe0c9b)
Indirect leak of 146 byte(s) in 2 object(s) allocated from:
#0 0x4ac0cd in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x4ac0cd)
#1 0x7f513ee682bb (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x20e2bb)
Indirect leak of 130 byte(s) in 9 object(s) allocated from:
#0 0x4ac0cd in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x4ac0cd)
#1 0x7f513ed02989 in ASN1_STRING_set (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1+0xa8989)
Indirect leak of 128 byte(s) in 2 object(s) allocated from:
#0 0x4ac0cd in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x4ac0cd)
#1 0x7f513ede8558 in CRYPTO_zalloc (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x18e558)
#2 0x7f513f2d2463 in ns_listenelt_create /builds/isc-projects/bind9/lib/ns/listenlist.c:42:12
#3 0x56bada in ns_listenelt_fromconfig /builds/isc-projects/bind9/bin/named/server.c:10959:11
#4 0x555f57 in ns_listenlist_fromconfig /builds/isc-projects/bind9/bin/named/server.c:10841:12
#5 0x549b8b in load_configuration /builds/isc-projects/bind9/bin/named/server.c:8842:10
#6 0x510458 in run_server /builds/isc-projects/bind9/bin/named/server.c:9820:2
#7 0x7f5140d1070c in dispatch /builds/isc-projects/bind9/lib/isc/task.c:1152:7
#8 0x7f5140d03c84 in run /builds/isc-projects/bind9/lib/isc/task.c:1344:2
#9 0x7f513e9e2fa2 in start_thread /build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486:8
Indirect leak of 72 byte(s) in 2 object(s) allocated from:
#0 0x4ac0cd in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x4ac0cd)
#1 0x7f513ede8558 in CRYPTO_zalloc (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x18e558)
#2 0x84cf469241f605ff (<unknown module>)
Indirect leak of 48 byte(s) in 3 object(s) allocated from:
#0 0x4ac0cd in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x4ac0cd)
#1 0x7f513ed0d0b2 (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1+0xb30b2)
SUMMARY: AddressSanitizer: 12474 byte(s) leaked in 94 allocation(s).
```
[named-4.run](/uploads/3a348b8af74ff925c16b3d4e3373289e/named-4.run)Not plannedArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2739ThreadSanitizer: data race lib/isc/task.c:435 in task_send (unprotected acces...2021-06-15T02:53:51ZOndřej SurýThreadSanitizer: data race lib/isc/task.c:435 in task_send (unprotected access to `task->threadid`)(This should be ultimately resolved by making the tasks to be assigned to a single worker for their entire lifetime.)
```
==================
WARNING: ThreadSanitizer: data race (pid=32684)
Write of size 4 at 0x7b3800034688 by thread T...(This should be ultimately resolved by making the tasks to be assigned to a single worker for their entire lifetime.)
```
==================
WARNING: ThreadSanitizer: data race (pid=32684)
Write of size 4 at 0x7b3800034688 by thread T1 (mutexes: write M134399044339482320, write M230660, write M362957240824530600, write M239952160606078560):
#0 task_send /builds/isc-projects/bind9/lib/isc/task.c:435 (libisc-9.16.16.so+0x66587)
#1 isc_task_sendtoanddetach /builds/isc-projects/bind9/lib/isc/task.c:515 (libisc-9.16.16.so+0x66587)
#2 isc_task_sendanddetach /builds/isc-projects/bind9/lib/isc/task.c:456 (libisc-9.16.16.so+0x669bd)
#3 dns_resolver_cancelfetch /builds/isc-projects/bind9/lib/dns/resolver.c:11159 (libdns-9.16.16.so+0x19a861)
#4 ns_query_cancel /builds/isc-projects/bind9/lib/ns/query.c:653 (libns-9.16.16.so+0x30ad8)
#5 ns_client_killoldestquery /builds/isc-projects/bind9/lib/ns/client.c:175 (libns-9.16.16.so+0xea95)
#6 ns_query_recurse /builds/isc-projects/bind9/lib/ns/query.c:6302 (libns-9.16.16.so+0x327d2)
#7 query_delegation_recurse /builds/isc-projects/bind9/lib/ns/query.c:8643 (libns-9.16.16.so+0x4093c)
#8 query_delegation /builds/isc-projects/bind9/lib/ns/query.c:8589 (libns-9.16.16.so+0x4093c)
#9 query_gotanswer /builds/isc-projects/bind9/lib/ns/query.c:7322 (libns-9.16.16.so+0x3c4f9)
#10 query_lookup /builds/isc-projects/bind9/lib/ns/query.c:5919 (libns-9.16.16.so+0x3dbb7)
#11 ns__query_start /builds/isc-projects/bind9/lib/ns/query.c:5561 (libns-9.16.16.so+0x3ebc9)
#12 query_setup /builds/isc-projects/bind9/lib/ns/query.c:5274 (libns-9.16.16.so+0x477a2)
#13 ns_query_start /builds/isc-projects/bind9/lib/ns/query.c:11870 (libns-9.16.16.so+0x48073)
#14 ns__client_request /builds/isc-projects/bind9/lib/ns/client.c:2165 (libns-9.16.16.so+0x15bd8)
#15 isc__nm_async_readcb /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:2575 (libisc-9.16.16.so+0x4883e)
#16 isc__nm_readcb /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:2550 (libisc-9.16.16.so+0x489e7)
#17 udp_recv_cb /builds/isc-projects/bind9/lib/isc/netmgr/udp.c:426 (libisc-9.16.16.so+0x4fd79)
#18 <null> <null> (libuv.so.1+0x1d6d4)
#19 isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:191 (libisc-9.16.16.so+0x6bdc5)
#20 <null> <null> (libtsan.so.0+0x29b3d)
Previous read of size 4 at 0x7b3800034688 by thread T3:
#0 task_ready /builds/isc-projects/bind9/lib/isc/task.c:347 (libisc-9.16.16.so+0x6a1dc)
#1 isc_task_unpause /builds/isc-projects/bind9/lib/isc/task.c:1230 (libisc-9.16.16.so+0x6a1dc)
#2 ns__client_request /builds/isc-projects/bind9/lib/ns/client.c:2191 (libns-9.16.16.so+0x15bed)
#3 isc__nm_async_readcb /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:2575 (libisc-9.16.16.so+0x4883e)
#4 isc__nm_readcb /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:2550 (libisc-9.16.16.so+0x489e7)
#5 udp_recv_cb /builds/isc-projects/bind9/lib/isc/netmgr/udp.c:426 (libisc-9.16.16.so+0x4fd79)
#6 <null> <null> (libuv.so.1+0x1d6d4)
#7 isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:191 (libisc-9.16.16.so+0x6bdc5)
#8 <null> <null> (libtsan.so.0+0x29b3d)
Location is heap block of size 209 at 0x7b3800034640 allocated by thread T1:
#0 malloc <null> (libtsan.so.0+0x2b1a3)
#1 default_memalloc /builds/isc-projects/bind9/lib/isc/mem.c:717 (libisc-9.16.16.so+0x3796e)
#2 mem_get /builds/isc-projects/bind9/lib/isc/mem.c:626 (libisc-9.16.16.so+0x384b6)
#3 mem_allocateunlocked /builds/isc-projects/bind9/lib/isc/mem.c:1292 (libisc-9.16.16.so+0x384b6)
#4 isc___mem_allocate /builds/isc-projects/bind9/lib/isc/mem.c:1312 (libisc-9.16.16.so+0x384b6)
#5 isc__mem_allocate /builds/isc-projects/bind9/lib/isc/mem.c:2563 (libisc-9.16.16.so+0x3e6e0)
#6 isc___mem_get /builds/isc-projects/bind9/lib/isc/mem.c:1061 (libisc-9.16.16.so+0x3ec16)
#7 isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:2542 (libisc-9.16.16.so+0x3d7de)
#8 isc_task_create_bound /builds/isc-projects/bind9/lib/isc/task.c:216 (libisc-9.16.16.so+0x67f93)
#9 ns_clientmgr_create /builds/isc-projects/bind9/lib/ns/client.c:2475 (libns-9.16.16.so+0x110b2)
#10 ns_interface_create /builds/isc-projects/bind9/lib/ns/interfacemgr.c:430 (libns-9.16.16.so+0x19fe5)
#11 ns_interface_setup /builds/isc-projects/bind9/lib/ns/interfacemgr.c:513 (libns-9.16.16.so+0x19fe5)
#12 do_scan /builds/isc-projects/bind9/lib/ns/interfacemgr.c:1088 (libns-9.16.16.so+0x1b4e4)
#13 ns_interfacemgr_scan0 /builds/isc-projects/bind9/lib/ns/interfacemgr.c:1147 (libns-9.16.16.so+0x1bad9)
#14 ns_interfacemgr_scan /builds/isc-projects/bind9/lib/ns/interfacemgr.c:1195 (libns-9.16.16.so+0x1bc30)
#15 load_configuration server.c:8871 (named+0x55513)
#16 run_server server.c:9815 (named+0x5b132)
#17 task_run /builds/isc-projects/bind9/lib/isc/task.c:852 (libisc-9.16.16.so+0x68ae9)
#18 isc_task_run /builds/isc-projects/bind9/lib/isc/task.c:945 (libisc-9.16.16.so+0x68ae9)
#19 isc__nm_async_task /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:880 (libisc-9.16.16.so+0x40ba0)
#20 process_netievent /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:959 (libisc-9.16.16.so+0x48f04)
#21 process_queue /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:1028 (libisc-9.16.16.so+0x496de)
#22 process_all_queues /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:799 (libisc-9.16.16.so+0x49fae)
#23 async_cb /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:828 (libisc-9.16.16.so+0x49fae)
#24 <null> <null> (libuv.so.1+0x10667)
#25 isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:191 (libisc-9.16.16.so+0x6bdc5)
#26 <null> <null> (libtsan.so.0+0x29b3d)
Mutex M134399044339482320 is already destroyed.
Mutex M230660 (0x7b7c001b8488) created at:
#0 pthread_mutex_init <null> (libtsan.so.0+0x2c5ad)
#1 isc__mutex_init /builds/isc-projects/bind9/lib/isc/pthreads/mutex.c:288 (libisc-9.16.16.so+0x888f7)
#2 ns_query_init /builds/isc-projects/bind9/lib/ns/query.c:798 (libns-9.16.16.so+0x32012)
#3 ns__client_setup /builds/isc-projects/bind9/lib/ns/client.c:2291 (libns-9.16.16.so+0x10cbf)
#4 ns__client_request /builds/isc-projects/bind9/lib/ns/client.c:1658 (libns-9.16.16.so+0x134c4)
#5 isc__nm_async_readcb /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:2575 (libisc-9.16.16.so+0x4883e)
#6 isc__nm_readcb /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:2550 (libisc-9.16.16.so+0x489e7)
#7 udp_recv_cb /builds/isc-projects/bind9/lib/isc/netmgr/udp.c:426 (libisc-9.16.16.so+0x4fd79)
#8 <null> <null> (libuv.so.1+0x1d6d4)
#9 isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:191 (libisc-9.16.16.so+0x6bdc5)
#10 <null> <null> (libtsan.so.0+0x29b3d)
Mutex M362957240824530600 is already destroyed.
Mutex M239952160606078560 is already destroyed.
Thread T1 'isc-net-0000' (tid=32699, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x2be1b)
#1 isc_thread_create /builds/isc-projects/bind9/lib/isc/pthreads/thread.c:79 (libisc-9.16.16.so+0x889a0)
#2 isc__netmgr_create /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:374 (libisc-9.16.16.so+0x41619)
#3 isc_managers_create /builds/isc-projects/bind9/lib/isc/managers.c:33 (libisc-9.16.16.so+0x359cb)
#4 create_managers main.c:920 (named+0x2886e)
#5 setup main.c:1245 (named+0x2886e)
#6 main main.c:1548 (named+0x2886e)
Thread T3 'isc-net-0002' (tid=32701, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x2be1b)
#1 isc_thread_create /builds/isc-projects/bind9/lib/isc/pthreads/thread.c:79 (libisc-9.16.16.so+0x889a0)
#2 isc__netmgr_create /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:374 (libisc-9.16.16.so+0x41619)
#3 isc_managers_create /builds/isc-projects/bind9/lib/isc/managers.c:33 (libisc-9.16.16.so+0x359cb)
#4 create_managers main.c:920 (named+0x2886e)
#5 setup main.c:1245 (named+0x2886e)
#6 main main.c:1548 (named+0x2886e)
SUMMARY: ThreadSanitizer: data race /builds/isc-projects/bind9/lib/isc/task.c:435 in task_send
```July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2740Not able to parse zone file with ZONEMD other than sha3842021-06-01T02:57:23ZLibor PeltanNot able to parse zone file with ZONEMD other than sha384Neither `named`, nor `dnssec-verify` is not able to load zone file with a ZONEMD record other than sha384.
When I try to load `named` with sha512-ZONEMD in zone file, it fails with
```
31-May-2021 20:09:42.137 dns_rdata_fromtext: /home/...Neither `named`, nor `dnssec-verify` is not able to load zone file with a ZONEMD record other than sha384.
When I try to load `named` with sha512-ZONEMD in zone file, it fails with
```
31-May-2021 20:09:42.137 dns_rdata_fromtext: /home/peltan/conf/1/example.com.zone:67: near '2e0cc4827e7a3204': extra input text
```
Similar error occurs with `dnssec-verify`.
Bind9 version is 9.16.6:
```
BIND 9.16.6-Ubuntu (Stable Release) <id:25846cf>
running on Linux x86_64 5.8.0-53-generic #60-Ubuntu SMP Thu May 6 07:46:32 UTC 2021
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-option-checking' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--disable-isc-spnego' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-aPvtn0/bind9-9.16.6=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 10.2.0
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
compiled with libuv version: 1.38.0
linked to libuv version: 1.38.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```https://gitlab.isc.org/isc-projects/bind9/-/issues/2741TCP connections left in CLOSE_WAIT2022-11-29T08:24:07ZBrian ConryTCP connections left in CLOSE_WAIT### Summary
From https://lists.isc.org/pipermail/bind-users/2021-May/104682.html and https://lists.isc.org/pipermail/bind-users/2021-June/104698.html .
After updating public authoritative servers from 9.16.6/9.16.8 to 9.16.15/9.16.16 t...### Summary
From https://lists.isc.org/pipermail/bind-users/2021-May/104682.html and https://lists.isc.org/pipermail/bind-users/2021-June/104698.html .
After updating public authoritative servers from 9.16.6/9.16.8 to 9.16.15/9.16.16 there is an issue with TCP connections building up in CLOSE_WAIT status until named is restarted.
These appear to be client resolver queries for large TXT records where the client is not EDNS capable.
Requires `keep-response-order { any; }` (not default) to be configured to disable TCP-pipelining.https://gitlab.isc.org/isc-projects/bind9/-/issues/2742rndc serve-stale status output can be slightly confusing2021-10-27T13:15:11ZCathy Almondrndc serve-stale status output can be slightly confusingThe confusion is over what components of the serve-stale feature are active (or not) based on the output.
I don't think we document anywhere in the ARM how to interpret what is output.
Here are examples of what is currently output by r...The confusion is over what components of the serve-stale feature are active (or not) based on the output.
I don't think we document anywhere in the ARM how to interpret what is output.
Here are examples of what is currently output by rndc status from BIND 9.11.32-S1, and what should be understood from each:
1. Default (nothing explicitly configured)
```
$ rndc serve-stale status
my-default: off (stale-answer-ttl=1 max-stale-ttl=43200)
_bind: off (stale-answer-ttl=1 max-stale-ttl=43200)
```
Both views have `stale-cache-enable yes;` (by default) - otherwise we would not see values for stale-answer-ttl and max-stale-ttl. Those values are the default and have not been explicitly configured. `stale-answer-enable no;` is also the default.
The `off` means that stale-answer-enable is `no` and stale answers have not been enabled using rndc.
Commentary: This is confusing when you see it for the first time, because 'off' is ambiguous and could easily be misinterpreted as meaning that both stale cache and serving of stale answers are disabled (they're not)
2. Explicitly setting `stale-cache-enable no;`
```
$ rndc serve-stale status
my-default: off (not-cached)
_bind: off (not-cached)
```
This is easier to understand because we don't display any other options actually say 'not-cached' (although this wasn't always the case in earlier versions of BIND, which used to say just `off`.
Nothing is available for serving stale. You cannot enable stale answers using rndc, and even if you added 'stale-answer-enable yes;` to named.conf, this is ignored.
3. `stale-cache-enable yes;` (default or explicitly configured) plus `stale-answer-enable yes;`
```
$ rndc serve-stale status
my-default: on (stale-answer-ttl=1 max-stale-ttl=43200)
_bind: on (stale-answer-ttl=1 max-stale-ttl=43200)
```
This is the full monty - we have stale cache enabled AND we have have stale answers enabled (notice `on` instead of `off` as compared with example 1.
====
So what is the problem? The issue is that someone using a default configuration will issue `rndc serve-stale status`, see the output per example 1 and be confused as to whether they have serve-stale or not. Without the special knowledge that serve-stale has two components (retention of stale RRsets and serving of retained stale RRsets in specific circumstances), the existing status output can be confusing.
My suggestion for making it clearer would be something like this:
1. Default (nothing explicitly configured = `stale-cache-enable yes;` and `stale-answer-enable no;`
```
$ rndc serve-stale status
my-default: stale cache enabled; stale answers disabled (stale-answer-ttl=1 max-stale-ttl=43200)
_bind: stale cache enabled; stale answers disabled (stale-answer-ttl=1 max-stale-ttl=43200)
```
2. Explicitly setting `stale-cache-enable no;` (the setting of `stale-answer-enable` is irrelevant, it is overridden)
```
$ rndc serve-stale status
my-default: stale cache disabled; (stale answers unavailable)
_bind: stale cache disabled; (stale answers unavailable)
```
3. `stale-cache-enable yes;` (default or explicitly configured) plus `stale-answer-enable yes;`
```
$ rndc serve-stale status
my-default: stale cache enabled; stale answers enabled (stale-answer-ttl=1 max-stale-ttl=43200)
_bind: stale cache enabled; stale answers enabled (stale-answer-ttl=1 max-stale-ttl=43200)0)
```November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2744warning: checkhints: unable to get root NS rrset from cache: not found2024-03-27T00:34:35ZCathy Almondwarning: checkhints: unable to get root NS rrset from cache: not foundPeriodically we see reports of resolvers that are failing to respond to clients successfully, perhaps with a build-up of recursive clients, inbound UDP packet drops, late and missing query responses and so on. Rebooting the server entir...Periodically we see reports of resolvers that are failing to respond to clients successfully, perhaps with a build-up of recursive clients, inbound UDP packet drops, late and missing query responses and so on. Rebooting the server entirely usually fixes the problem - for a time. Flushing cache may also buy some relief, but generally this does not last as long as if the server is rebooted entirely.
Plus one symptom in the logs - repeated spates of messages like this:
```
31-May-2021 16:08:38.110 general: warning: checkhints: unable to get root NS rrset from cache: not found
31-May-2021 16:08:41.110 general: warning: checkhints: unable to get root NS rrset from cache: not found
31-May-2021 16:08:42.151 general: warning: checkhints: unable to get root NS rrset from cache: not found
```
This error message occurs when the root nameservers have just been primed, but when checkhints goes to look at them, they're no longer available in cache (have been expired, possible also removed), all in a very short period of time.
Reports of this have been seen intermittently for many years and from many versions of BIND 9. Typically (in the older reports) this was a rare occurrence seen on a resolver that had been running for a long time; months, possibly years. Therefore after rebooting, the error and the problem was never seen again (or at least not within the shelf-life of the admin who reported it to us originally).
We suspect that what is happening is that the cache structure and content have become unmaintainable over a long period of content being added, expired and removed, and that there it's become impossible to add new RRsets to cache without using expiring existing content because of max-cache-size. The cache tree structure itself also occupies memory, and we've seen a few instances where a long-lived cache has become 'straggly' but also sparsely populated.
What we haven't been able to catch (yet), is the exact path taken that causes this error to be logged, although we have been hoping that improved stats, along with a `catch it earlier` assertion (the server anyway needs to be restarted when it has reached this state) might help. See #2082 .
We have also seen that in one or two instances of this warning being logged, in addition there was a problem reaching some of the root nameserver addresses listed in the root hints and used for priming. Either the root hints were out of date and an older IP address was unreachable, or there were local routing issues (typically IPv6-related) reaching some root server addresses. **This shouldn't be a problem**, per the way that root hints priming is designed, _but 'fixing' the root hints appears to have made the problem go away in some instances, as has fixing the routing and unreachability of some root hint addresses._
----
For anyone experiencing this problem for the first time, the likelihood is that one or more things have changed in your operating environment, and that these are causing cache content to be more substantial than before, or potentially distributed differently. For example:
- Installing a version of BIND that has `stale-cache-enable yes` by default
- An increase in client queries overall
- Client query patterns changing - perhaps causing a higher rate than usual of cached negative responses
- An increase in dual-stack clients querying for AAAA records
- An increase in client querying for HTTPS records
- A new client application that uses DNS-based probing
- Clients using a tunnelling-over-DNS service
- Using a client filtering service that operates by means of resolving the original client query first by appending another private zone name to it and checking the response status before allowing the original query to pass - thus adding the filtering RRsets to cache as well as the actual client query responses.
Currently, clues may be found in the BIND statistics and also in a dump of cache.
Firstly, these counters (available either from the output from `rndc stats` or using the xml or json statistics interface), can be a good indicator that there is too much cache cleaning taking place due to memory pressure, versus RRset TTL expiration:
DeleteLRU - "cache records deleted due to memory exhaustion"
DeleteTTL - "cache records deleted due to TTL expiration"
These are counters, therefore although seeing DeleteLRU far exceeding DeleteTTL in a single snapshot of the stats is a good indicator that all is not well with cache, ideally you want to monitor the trend over time.
Also these :
HeapMemInUse - "cache heap memory in use"
TreeMemInUse - "cache tree memory in use"
HeapMemMax - "cache heap highest memory in use"
TreeMemMax - "cache tree highest memory in use"
All of the above are gauges - they tell you 'this is where we are now', so a snapshot can be useful, as well as monitoring pattern over time. The 'Max' is a high water mark.
Aside: don't be tempted to look at either of these - they are not useful operationally and aren't counting what you might think they are from their names:
HeapMemTotal - "cache heap memory total"
TreeMemTotal - "cache tree memory total"
And finally, there are counters available of what's in cache currrently by RType. These are prefixed with `!` for counters of NXRRSET (pseudo RR indicating that a name that was queried existed but the type didn't), `#` for stale content, and `~` for content that has expired and is waiting on housekeeping/deletion.
If there is any kind of unexpected skew, it might be worth dumping cache to see what's in there.
And then decide - is it just that max-cache-size is now insufficient, or is that something else needs to be done to reduce cache content.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2745HISTORY.md file needs removing2021-06-24T09:45:50ZPeter DaviesHISTORY.md file needs removingIn the bind 9.16 branch the HISTORY.md file does not appear to have any reference to bind 9.16
Though it does in main.
[RT #18566 ](https://support.isc.org/Ticket/Display.html?id=18566)
See comments below why we should remove the file.In the bind 9.16 branch the HISTORY.md file does not appear to have any reference to bind 9.16
Though it does in main.
[RT #18566 ](https://support.isc.org/Ticket/Display.html?id=18566)
See comments below why we should remove the file.July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2746unable to convert libuv error code in udp_send_cb to isc_result: -40: message...2021-06-07T12:43:54ZLaurent Gouhierunable to convert libuv error code in udp_send_cb to isc_result: -40: message too long<!--
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
When I request a record that should generate UDP Fragements I am gettings theses logs in named.log :
May 26 11:57:14 solid named[9534]: ./bind-9.16/lib/isc/netmgr/udp.c:548: unexpected error:
May 26 11:57:14 solid named[9534]: unable to convert libuv error code in udp_send_cb to isc_result: -40: message too long
### BIND version used
BIND 9.16.16 (Stable Release) <id:0c314d8>
running on FreeBSD amd64 13.0-STABLE FreeBSD 13.0-STABLE #155 stable/13-n245693-6cd1cb27a97-dirty: Thu May 20 01:40:10 UTC 2021 root@fb13-x64-sds80:/usr/obj/usr/src/amd64.amd64/sys/SOLIDSERVER
built by make with '--enable-threads' '--with-make-clean=no' '--with-gssapi=/usr/local' '--with-geoip' '--with-libjson=yes' '--with-libxml2=yes' '--prefix=/' '--enable-filter-aaaa'
compiled by CLANG FreeBSD Clang 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe)
compiled with OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
linked to OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
compiled with libuv version: 1.41.0
linked to libuv version: 1.41.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
### Steps to reproduce
- Set in named.conf :
edns-udp-size 4096;
max-udp-size 4096;
- Request a record that generate a response with a size greater than 3675
### Possible fixes
It seems that is related to : https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4668/diffs?commit_id=66eefac78c92b64b6689a1655cc677a2b1d13496
In the commit we can see the new define "setsockopt_off"
`#define setsockopt_off(socket, level, name) \`
` setsockopt(socket, level, name, &(int){ 1 }, sizeof(int))`
But instead of sending a value 0 to disable the option, a 1 is send.
So it is doing the same thing as the define "setsockopt_on"
editing the netmgr.c by
`#define setsockopt_off(socket, level, name) \`
` setsockopt(socket, level, name, &(int){ 0 }, sizeof(int))`
Work as it should
Best regardsJune 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)https://gitlab.isc.org/isc-projects/bind9/-/issues/2747Remove outdated Debian packages from Cloudsmith private repo2021-06-08T06:34:26ZVicky Riskvicky@isc.orgRemove outdated Debian packages from Cloudsmith private repoWe publish packages patched for CVEs in Cloudsmith for use by ISC support customers.
The [published KB](https://kb.isc.org/docs/isc-packages-for-bind-9) on this promises only CentOS/RHEL images - and that is all we are updating. However ...We publish packages patched for CVEs in Cloudsmith for use by ISC support customers.
The [published KB](https://kb.isc.org/docs/isc-packages-for-bind-9) on this promises only CentOS/RHEL images - and that is all we are updating. However we do have Debian images up there that are a year old. We should remove those because some people might download them not realizing they are out of date and, since they are not in the open source unrestricted repo, we are potentially paying to store them there.https://gitlab.isc.org/isc-projects/bind9/-/issues/2748Could more detail be added to the query log to show the query protocol used (...2022-03-22T09:49:26ZRichard NealCould more detail be added to the query log to show the query protocol used (eg Do53, DoT, DoH)?### Description
It would be useful if BIND could log the query protocol used by the client - e.g. Do53, DoT, DoH. This would allow system administrators to understand the proportion of different types of queries and to help determine an...### Description
It would be useful if BIND could log the query protocol used by the client - e.g. Do53, DoT, DoH. This would allow system administrators to understand the proportion of different types of queries and to help determine any additional resource overhead (e.g. the computational resource overhead of encryption for DoT or DoH)
### Request
The logging statement grammar should be enhanced to allow the system administrator to (optionally?) include the protocol type for the query. If the system administrator chooses to enable protocol logging then it may be preferable to use a simple integer value for the chosen field, eg:
1 = Do53, 2 = DoT, 3 = DoH (non-TLS, eg behind HTTPS load balancer), 4 = DoH (TLS)
This would allow for future protocols at a later date
### Links / references
I have looked in the BIND 9.17 ARM and can see no reference to BIND being able to log the query protocol used by the client, but I am happy to be corrected if this feature already exists.
Thanks,
Richard.BIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2749Missing ATOMIC_VAR_INIT for atomic static variables2022-09-27T03:49:26ZMark AndrewsMissing ATOMIC_VAR_INIT for atomic static variablesNot plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2750Provide more insight into why the timer_test is failing.2021-06-03T07:37:28ZMark AndrewsProvide more insight into why the timer_test is failing.On FreeBSD the timer_test is failing like this which doesn't actually report which tests failed.
```
1..5
not ok 1 - ticker
# 0x22 != 0
# timer_test.c:144: error: Failure!
not ok 2 - once_life
# 0x22 != 0
# timer_test.c:144: error: Fail...On FreeBSD the timer_test is failing like this which doesn't actually report which tests failed.
```
1..5
not ok 1 - ticker
# 0x22 != 0
# timer_test.c:144: error: Failure!
not ok 2 - once_life
# 0x22 != 0
# timer_test.c:144: error: Failure!
not ok 3 - once_idle
# 0x22 != 0
# timer_test.c:144: error: Failure!
not ok 4 - reset
# 0x22 != 0
# timer_test.c:144: error: Failure!
not ok 5 - purge
# 0x22 != 0
# timer_test.c:572: error: Failure!
```June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2751serve-stale tests false negative2021-06-07T13:22:37ZMark Andrewsserve-stale tests false negativeJob [#1772976](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1772976) failed for d4f7963dd310914d013cba5b7fd1bd6dec92668e:
```
8455I:serve-stale:sending queries for tests 144-145...
8456I:serve-stale:enable responses from authoritati...Job [#1772976](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1772976) failed for d4f7963dd310914d013cba5b7fd1bd6dec92668e:
```
8455I:serve-stale:sending queries for tests 144-145...
8456I:serve-stale:enable responses from authoritative server (143)
8457I:serve-stale:check not in cache longttl.example times out (stale-answer-client-timeout 1.8) (144)
8458I:serve-stale:check not in cache longttl.example comes from authoritative (stale-answer-client-timeout 1.8) (145)
8459I:serve-stale:failed
```
Both digs completed within a second of each other but only one of the
two passed despite the contents matching the expected values which leads
me to conclude that `dig.out.test145` was still being written when the
`grep`s where made.
```
% ls -lT dig.out.test14[45]
-rw-r--r--@ 1 marka staff 184 3 Jun 14:42:51 2021 dig.out.test144
-rw-r--r--@ 1 marka staff 664 3 Jun 14:42:52 2021 dig.out.test145
%
```
```
% grep "status: NOERROR" dig.out.test145
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46667
% grep "ANSWER: 1," dig.out.test145
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
```
```
n=$((n+1))
echo_i "check not in cache longttl.example times out (stale-answer-client-timeout 1.8) ($n)"
ret=0
wait_for_log 3 "longttl.example client timeout, stale answer unavailable" ns3/named.run || ret=1
waitfile() {
[ -s "$1" ] || return 1
}
retry_quiet 3 waitfile dig.out.test$n || ret=1
grep "connection timed out" dig.out.test$n > /dev/null || ret=1
if [ $ret != 0 ]; then echo_i "failed"; fi
status=$((status+ret))
n=$((n+1))
echo_i "check not in cache longttl.example comes from authoritative (stale-answer-client-timeout 1.8) ($n)"
ret=0
retry_quiet 7 waitfile dig.out.test$n || ret=1
grep "status: NOERROR" dig.out.test$n > /dev/null || ret=1
grep "ANSWER: 1," dig.out.test$n > /dev/null || ret=1
if [ $ret != 0 ]; then echo_i "failed"; fi
status=$((status+ret))
```June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2752Embed nosync or libeatmydata to CI2021-10-18T12:22:10ZMichal NowakEmbed nosync or libeatmydata to CIWe should embed `nosync` or `libeatmydata` to the CI and see if we can lower the I/O load on GitLab Runners and make the system test more stable.
Given that it's not clear how to measure system test stability and given the added complex...We should embed `nosync` or `libeatmydata` to the CI and see if we can lower the I/O load on GitLab Runners and make the system test more stable.
Given that it's not clear how to measure system test stability and given the added complexity to the CI, we might want to integrate the change in the CI firsts and then decide if the complexity is worth the gains or remove it otherwise.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2753timer_test subtests are not independent2021-07-12T03:58:03ZMark Andrewstimer_test subtests are not independentJob [#1773630](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1773630) failed for 6d84bff56595a2d06014f344f4b76bc4f316168a:
Only the first subtest failed below (timer_test.c:234 subthread_assert_true) but 2..5 reported failures.
```
...Job [#1773630](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1773630) failed for 6d84bff56595a2d06014f344f4b76bc4f316168a:
Only the first subtest failed below (timer_test.c:234 subthread_assert_true) but 2..5 reported failures.
```
1..5
# timer_test.c:234 subthread_assert_true
not ok 1 - ticker
# 0x22 != 0
# timer_test.c:144: error: Failure!
not ok 2 - once_life
# 0x22 != 0
# timer_test.c:144: error: Failure!
not ok 3 - once_idle
# 0x22 != 0
# timer_test.c:144: error: Failure!
not ok 4 - reset
# 0x22 != 0
# timer_test.c:144: error: Failure!
not ok 5 - purge
# 0x22 != 0
# timer_test.c:585: error: Failure!
```August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2754Bind not returning RPZ entries when edns0 z-field set to 0x80002021-06-03T21:48:32ZPatrick KavajinBind not returning RPZ entries when edns0 z-field set to 0x8000<!--
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
We noticed that dns queries which get forwarded by coredns to our bind do not get the answers we expect.
Queries against domains where we override the A record using a rpz get the regular A record as an answer instead of the overridden one.
By diffing direct queries against the bind using dig and queries forwarded over coredns we saw that coredns sets the edns0 z-field to 0x8000 instead of 0x0000 like dig. If i understand it correctly, 0x8000 means something like "allow dnssec security rr".
Read through some of the RFCs but I'm still not sure if this is a bug or expected behaviour to bypass the rpz in this case.
So, sorry for wasting your time if this is indeed wanted.
### BIND version used
1:9.11.5.P4+dfsg-5.1+deb10u5
### Steps to reproduce
1. Set up a bind with a db.rpz overriding the A record for a public domain name.
2. Query against it with edns0 z-field set to 0x0000 -> you get the A record from the rpz
3. Query against it with edns0 z-field set to 0x8000 -> you get the public A record
See the following db.rpz as an example:
```
$TTL 60
@ IN SOA localhost. root.localhost. (
1234567890 ; serial
1h ; refresh
30m ; retry
1w ; expiry
30m) ; minimum
IN NS localhost.
*.int.prod.nect.com A 192.168.13.37
```
I used the following two calls to craft the dns packets and watched the responses with wireshark, prolly there's also an option for dig to test it:
```
# z field set to 0x0000
echo -n -e "\x5b\x30\x01\x20\x00\x01\x00\x00\x00\x00\x00\x01\x10\x77\x61\x73\x64\x65\x6d\x66\x69\x63\x6b\x69\x73\x74\x64\x61\x73\x03\x69\x6e\x74\x04\x70\x72\x6f\x64\x04\x6e\x65\x63\x74\x03\x63\x6f\x6d\x00\x00\x01\x00\x01\x00\x00\x29\x10\x00\x00\x00\x00\x00\x00\x0c\x00\x0a\x00\x08\x00\xa9\xf9\xeb\x26\xc0\x68\x8b" | nc -u 127.0.0.1 53
# z field set to 0x8000
echo -n -e "\x5b\x30\x01\x20\x00\x01\x00\x00\x00\x00\x00\x01\x10\x77\x61\x73\x64\x65\x6d\x66\x69\x63\x6b\x69\x73\x74\x64\x61\x73\x03\x69\x6e\x74\x04\x70\x72\x6f\x64\x04\x6e\x65\x63\x74\x03\x63\x6f\x6d\x00\x00\x01\x00\x01\x00\x00\x29\x10\x00\x00\x00\x80\x00\x00\x0c\x00\x0a\x00\x08\x00\xa9\xf9\xeb\x26\xc0\x68\x8b" | nc -u 127.0.0.1 53
```
Expected behaviour is to get the entry from the rpz, no matter what flag the client set.https://gitlab.isc.org/isc-projects/bind9/-/issues/2755Bad TKEY samples in genzone.sh comment2021-07-08T08:02:48ZFrancis DupontBad TKEY samples in genzone.sh commentIn bin/tests/system/genzone.sh there are two TKEY RR samples using a number for the algorithm field when RFC 2930 specifies this field as a DNS name. As the TKEY RR is a meta RR which should never appear in a real zone file these samples...In bin/tests/system/genzone.sh there are two TKEY RR samples using a number for the algorithm field when RFC 2930 specifies this field as a DNS name. As the TKEY RR is a meta RR which should never appear in a real zone file these samples are in a comment which starts at line 422 making this ticket less than minor...July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)https://gitlab.isc.org/isc-projects/bind9/-/issues/2756RNDC fails when using keys with different algorithms within a control channel.2021-08-19T05:23:41ZEverett FultonRNDC fails when using keys with different algorithms within a control channel.Ref: https://support.isc.org/Ticket/Display.html?id=18569
A customer who is planning to change 'rndc' key algorithm from md5 to sha256, reports that in a list of keys configured in a single 'inet' block, the first-listed key work prope...Ref: https://support.isc.org/Ticket/Display.html?id=18569
A customer who is planning to change 'rndc' key algorithm from md5 to sha256, reports that in a list of keys configured in a single 'inet' block, the first-listed key work properly, subsequent keys using the same algorithm will also work, while later keys with different algorithms will fail.
### BIND version used
9.16.15, also confirmed on 9.11.31
### Steps to reproduce
Keys with differing algorithms, e.g.: md5 and sha256, and BIND configuration containing the keys in a control channel:
```
acl "rndc-users" {
192.168.12.100/32;
192.168.12.82/32;
};
key "key1" {
algorithm "hmac-sha256";
secret "????????????????????????????????????????????";
};
key "key2" {
algorithm "hmac-md5";
secret "????????????????????????";
};
.
.
.
controls {
inet 192.168.12.95 allow {
"rndc-users";
} keys {
"key1";
"key2";
};
};
```
Same key material in rndc.conf on remote hosts referenced by the 'rndc-users' ACL.
### What is the current *bug* behavior?
First key in the list will work properly, as well as any other keys using the same algorithm. A key in the list of a different algorithm will fail, and also any subsequent keys based on the algorithm of the first key.
rndc fails with the error:
```
rndc: connection to remote host closed
This may indicate that
* the remote server is using an older version of the command protocol,
* this host is not authorized to connect,
* the clocks are not synchronized,
* the key signing algorithm is incorrect, or
* the key is invalid.
```
A workaround is to set up another control channel on a different port, so each channel only has keys of the same algorithm.
### What is the expected *correct* behavior?
Customer expected both old and new keys to be functional.
Specific keys and config are in Support ticket linked above, but this problem is reproducible with any similar situation.August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)https://gitlab.isc.org/isc-projects/bind9/-/issues/2757"shutdown" system test fails intermittently with AttributeError2021-06-09T08:00:06ZMichał Kępień"shutdown" system test fails intermittently with AttributeErrorA quick investigation leads me to believe that this failure mode is
caused by a threading issue in dnspython < 1.16.0:
```
D:shutdown:
D:shutdown:name = 'dns.rdtypes.IN.A'
D:shutdown:
D:shutdown:def import_module(name):
D:shutdown:mod =...A quick investigation leads me to believe that this failure mode is
caused by a threading issue in dnspython < 1.16.0:
```
D:shutdown:
D:shutdown:name = 'dns.rdtypes.IN.A'
D:shutdown:
D:shutdown:def import_module(name):
D:shutdown:mod = __import__(name)
D:shutdown:components = name.split('.')
D:shutdown:for comp in components[1:]:
D:shutdown:> mod = getattr(mod, comp)
D:shutdown:E AttributeError: module 'dns.rdtypes' has no attribute 'IN'
D:shutdown:
D:shutdown:/usr/lib/python3/dist-packages/dns/rdata.py:356: AttributeError
```
<details>
<summary>https://gitlab.isc.org/isc-private/bind9/-/jobs/1779765</summary>
```
D:shutdown:=================================== FAILURES ===================================
D:shutdown:_____________________________ test_named_shutdown ______________________________
D:shutdown:
D:shutdown:named_port = 24730, control_port = 24742
D:shutdown:
D:shutdown:@pytest.mark.dnspython
D:shutdown:def test_named_shutdown(named_port, control_port):
D:shutdown:# pylint: disable-msg=too-many-locals
D:shutdown:cfg_dir = os.path.join(os.getcwd(), "resolver")
D:shutdown:assert os.path.isdir(cfg_dir)
D:shutdown:
D:shutdown:cfg_file = os.path.join(cfg_dir, "named.conf")
D:shutdown:assert os.path.isfile(cfg_file)
D:shutdown:
D:shutdown:named = os.getenv("NAMED")
D:shutdown:assert named is not None
D:shutdown:
D:shutdown:rndc = os.getenv("RNDC")
D:shutdown:assert rndc is not None
D:shutdown:
D:shutdown:# rndc configuration resides in ../common/rndc.conf
D:shutdown:rndc_cfg = os.path.join("..", "common", "rndc.conf")
D:shutdown:assert os.path.isfile(rndc_cfg)
D:shutdown:
D:shutdown:# rndc command with default arguments.
D:shutdown:rndc_cmd = [rndc, "-c", rndc_cfg, "-p", str(control_port),
D:shutdown:"-s", "10.53.0.3"]
D:shutdown:
D:shutdown:# We create a resolver instance that will be used to send queries.
D:shutdown:resolver = dns.resolver.Resolver()
D:shutdown:resolver.nameservers = ['10.53.0.3']
D:shutdown:resolver.port = named_port
D:shutdown:
D:shutdown:# We test named shutting down using two methods:
D:shutdown:# Method 1: using rndc ctop
D:shutdown:# Method 2: killing with SIGTERM
D:shutdown:# In both methods named should exit gracefully.
D:shutdown:for kill_method in ("rndc", "sigterm"):
D:shutdown:named_cmdline = [named, "-c", cfg_file, "-f"]
D:shutdown:with subprocess.Popen(named_cmdline, cwd=cfg_dir) as named_proc:
D:shutdown:# Ensure named is running
D:shutdown:assert named_proc.poll() is None
D:shutdown:# wait for named to finish loading
D:shutdown:for _ in range(10):
D:shutdown:try:
D:shutdown:resolver.query('version.bind', 'TXT', 'CH')
D:shutdown:break
D:shutdown:except (dns.resolver.NoNameservers, dns.exception.Timeout):
D:shutdown:time.sleep(1)
D:shutdown:
D:shutdown:do_work(named_proc, resolver, rndc_cmd,
D:shutdown:> kill_method, n_workers=12, n_queries=16)
D:shutdown:
D:shutdown:tests-shutdown.py:174:
D:shutdown:_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
D:shutdown:tests-shutdown.py:109: in do_work
D:shutdown:result = future.result()
D:shutdown:/usr/lib/python3.5/concurrent/futures/_base.py:398: in result
D:shutdown:return self.__get_result()
D:shutdown:/usr/lib/python3.5/concurrent/futures/_base.py:357: in __get_result
D:shutdown:raise self._exception
D:shutdown:/usr/lib/python3.5/concurrent/futures/thread.py:55: in run
D:shutdown:result = self.fn(*self.args, **self.kwargs)
D:shutdown:/usr/lib/python3/dist-packages/dns/resolver.py:962: in query
D:shutdown:source_port=source_port)
D:shutdown:/usr/lib/python3/dist-packages/dns/query.py:257: in udp
D:shutdown:one_rr_per_rrset=one_rr_per_rrset)
D:shutdown:/usr/lib/python3/dist-packages/dns/message.py:807: in from_wire
D:shutdown:reader.read()
D:shutdown:/usr/lib/python3/dist-packages/dns/message.py:746: in read
D:shutdown:self._get_section(self.message.answer, ancount)
D:shutdown:/usr/lib/python3/dist-packages/dns/message.py:720: in _get_section
D:shutdown:self.message.origin)
D:shutdown:/usr/lib/python3/dist-packages/dns/rdata.py:457: in from_wire
D:shutdown:cls = get_rdata_class(rdclass, rdtype)
D:shutdown:/usr/lib/python3/dist-packages/dns/rdata.py:368: in get_rdata_class
D:shutdown:rdclass_text, rdtype_text]))
D:shutdown:_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
D:shutdown:
D:shutdown:name = 'dns.rdtypes.IN.A'
D:shutdown:
D:shutdown:def import_module(name):
D:shutdown:mod = __import__(name)
D:shutdown:components = name.split('.')
D:shutdown:for comp in components[1:]:
D:shutdown:> mod = getattr(mod, comp)
D:shutdown:E AttributeError: module 'dns.rdtypes' has no attribute 'IN'
D:shutdown:
D:shutdown:/usr/lib/python3/dist-packages/dns/rdata.py:356: AttributeError
```
</details>
I believe this problem is caused by the `import_module()` closure not
locking the threading lock in dnspython < 1.16.0:
- dnspython 1.15.0
```python
def get_rdata_class(rdclass, rdtype):
def import_module(name):
mod = __import__(name)
components = name.split('.')
for comp in components[1:]:
mod = getattr(mod, comp)
return mod
```
- dnspython 1.16.0
```python
_import_lock = _threading.Lock()
def get_rdata_class(rdclass, rdtype):
def import_module(name):
with _import_lock:
mod = __import__(name)
components = name.split('.')
for comp in components[1:]:
mod = getattr(mod, comp)
return mod
```
The failure above was triggered on Debian 9 "stretch", which has
dnspython 1.15.0.
I am opening this issue merely as a data point - nothing needs to be
fixed on our side here.June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2758nsupdate does not use all name servers from resolv.conf2021-07-23T07:44:53ZMichael Osipovnsupdate does not use all name servers from resolv.conf<!--
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
`nsupdate(1)` does not traverse all nameservers from `resolv.conf` to resolve `SOA` record.
### BIND version used
nsupdate 9.16.16 on FreeBSD 12.2-RELEASE
### Steps to reproduce
Run:
```
# /usr/local/bin/nsupdate -DD -g /usr/local/etc/register-hostnames.nsupdate
# cat /usr/local/bin/nsupdate -DD -g /usr/local/etc/register-hostnames.nsupdate
zone ad001.siemens.net
update add HOST.ad001.siemens.net 3600 A 146.254.X.Y
send
```
### What is the current *bug* behavior?
`nsupdate` says:
```
response to SOA query was unsuccessful
```
Well, `host` says:
```
# host -t SOA ad001.siemens.net
ad001.SIEMENS.net has SOA record DC.ad001.siemens.net. ...\.siemens.com. 119802228 10800 3600 604800 3600
```
My `resolv.conf` is the following:
```
# cat /etc/resolv.conf
domain ad001.siemens.net
search ad001.siemens.net bln.siemens.de bln3.siemens.de
nameserver NS-A
nameserver NS-B
nameserver BIGSEC
options timeout:1 attempts:2
```
`NS-A` runs bind9 on FreeBSD 12-STABLE, `NS-B` runs bin9 on RHEL7, `BIGSEC` is out of my control and company wide.
### What is the expected *correct* behavior?
Update record in Active Directory with GSS-TSIG.
### Relevant logs and/or screenshots
I ran tcpdump while `nsupdate` was working. My expectation is that `nsupdate` will try all nameservers to resolve the SOA record, but it stops at first one:
```
# tcpdump -v -i vnet0 udp
tcpdump: listening on vnet0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:00:59.088426 IP (tos 0x0, ttl 64, id 30865, offset 0, flags [none], proto UDP (17), length 63)
HOST.ad001.siemens.net.59520 > NS-A.domain: 42421+ SOA? ad001.siemens.net. (35)
13:00:59.088849 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 63)
NS-A.domain > HOST.ad001.siemens.net.59520: 42421 Refused- 0/0/0 (35)
13:00:59.088928 IP (tos 0x0, ttl 64, id 15837, offset 0, flags [none], proto UDP (17), length 71)
HOST.ad001.siemens.net.17552 > NS-A.domain: 5051+ PTR? NS-A-IP.in-addr.arpa. (43)
13:00:59.089185 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 114)
NS-A.domain > HOST.ad001.siemens.net.17552: 5051*- 1/0/0 NS-A-IP.in-addr.arpa. PTR NS-A. (86)
```
For some reason I need to investigate the named on FreeBSD does not respond with the SOA records.
Now the same with the `host` command:
```
# tcpdump -v -i vnet0 udp
tcpdump: listening on vnet0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:03:18.496214 IP (tos 0x0, ttl 64, id 30867, offset 0, flags [none], proto UDP (17), length 63)
HOST.ad001.siemens.net.43313 > NS-A.domain: 46818+ SOA? ad001.siemens.net. (35)
13:03:18.496690 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 63)
NS-A.domain > HOST.ad001.siemens.net.43313: 46818 Refused- 0/0/0 (35)
13:03:18.496714 IP (tos 0x0, ttl 64, id 32357, offset 0, flags [none], proto UDP (17), length 71)
HOST.ad001.siemens.net.26366 > NS-A.domain: 20427+ PTR? NS-A-IP.in-addr.arpa. (43)
13:03:18.497085 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 114)
NS-A.domain > HOST.ad001.siemens.net.26366: 20427*- 1/0/0 NS-A-IP.in-addr.arpa. PTR NS-A. (86)
13:03:18.497420 IP (tos 0x0, ttl 64, id 30868, offset 0, flags [none], proto UDP (17), length 63)
HOST.ad001.siemens.net.31902 > NS-B.domain: 46818+ SOA? ad001.siemens.net. (35)
13:03:18.497485 IP (tos 0x0, ttl 64, id 32358, offset 0, flags [none], proto UDP (17), length 70)
HOST.ad001.siemens.net.45374 > NS-A.domain: 24116+ PTR? NS-B-IP.in-addr.arpa. (42)
13:03:18.497806 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 110)
NS-A.domain > HOST.ad001.siemens.net.45374: 24116*- 1/0/0 NS-B-IP.in-addr.arpa. PTR NS-B. (82)
13:03:18.499570 IP (tos 0x0, ttl 63, id 55996, offset 0, flags [none], proto UDP (17), length 533)
NS-B.domain > HOST.ad001.siemens.net.31902: 46818 1/13/11 ad001.SIEMENS.net. SOA DC.ad001.siemens.net. ...\.siemens.com. 119802228 10800 3600 604800 3600 (505)
```
In this case all nameservers are tried while `nsupdate` stops at the first one.July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)https://gitlab.isc.org/isc-projects/bind9/-/issues/2759Broken handling of DS/NSEC records in signed, wildcard+CNAME-sourced delegations2021-07-16T05:27:02ZMichał KępieńBroken handling of DS/NSEC records in signed, wildcard+CNAME-sourced delegationsWhen answering a query requires wildcard expansion, the AUTHORITY
section of the response needs to include NSEC(3) record(s) proving that
the QNAME does not exist.
When a response to a query is an insecure delegation, the AUTHORITY
sect...When answering a query requires wildcard expansion, the AUTHORITY
section of the response needs to include NSEC(3) record(s) proving that
the QNAME does not exist.
When a response to a query is an insecure delegation, the AUTHORITY
section needs to include an NSEC(3) proof that no DS record exists at
the parent side of the zone cut.
These two conditions combined trip up the NSEC part of the logic
contained in query_addds(), which expects the NS RRset to be owned by
the first name found in the AUTHORITY section of a delegation response.
This may not always be true, for example if wildcard expansion causes an
NSEC record proving QNAME nonexistence to be added to the AUTHORITY
section before the delegation is added to the response. In such a case,
named incorrectly omits the NSEC record proving nonexistence of QNAME
from the AUTHORITY section.
The same block of code is affected by another flaw: if the same NSEC
record proves nonexistence of both the QNAME and the DS record at the
parent side of the zone cut, this NSEC record will be added to the
AUTHORITY section twice.
This issue was [originally reported][1] by @libchap.
[1]: https://chat.dns-oarc.net/community/pl/8eezk1brqpy8je7fj3rtdco98eJuly 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2760db unit test failure2021-06-09T22:34:26ZMark Andrewsdb unit test failureJob [#1783201](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1783201) failed for 3d66e97a28333d455d2fbd145e67e98ef999ecd1:
```
[ RUN ] dns_dbfind_staleok_test
11 is not within the range 1-10
```
```
Thread 1 (LWP 12310):
#0 0x...Job [#1783201](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1783201) failed for 3d66e97a28333d455d2fbd145e67e98ef999ecd1:
```
[ RUN ] dns_dbfind_staleok_test
11 is not within the range 1-10
```
```
Thread 1 (LWP 12310):
#0 0x00007fb44671d2a2 in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007fb4467068a4 in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x00007fb446ba6255 in exit_test.constprop () from /lib64/libcmocka.so.0
No symbol table info available.
#3 0x00007fb446ba6301 in _fail () from /lib64/libcmocka.so.0
No symbol table info available.
#4 0x0000000000403422 in dns_dbfind_staleok_test (state=<optimized out>) at db_test.c:264
rdata = {data = 0x7fffd7863ca4 "\n", length = 4, rdclass = 1, type = 1, flags = 0, link = {prev = 0x0, next = 0x0}}
db = 0x8b2530
node = 0x0
example_fixed = {name = {magic = 1145983854, ndata = 0x7fffd7864090 "\aexample", length = 9, labels = 2, attributes = 1, offsets = 0x7fffd7863fd0 "", buffer = 0x7fffd7864050, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, list = {head = 0x0, tail = 0x0}}, offsets = "\000\b\000\000\000\000\000\000\004O\266F\264\177", '\000' <repeats 13 times>, "\024\000\000\000\000 \323qF\264\177\000\000\000\000\000@\000\000\000\000\002\000\000\000\000\000\000\000\016\000\000\000\000\000\000\200", '\000' <repeats 48 times>, "p@\206\327\377\177\000\000\060%\213\000\000\000\000", buffer = {magic = 1114990113, base = 0x7fffd7864090, length = 255, used = 9, current = 0, active = 0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, mctx = 0x0, autore = false}, data = "\aexample\000\000\000@\000\000\000\000\260%\213\000\000\000\000\000\240]\213\000\000\000\000\000pA\206\327\377\177\000\000\270l\270F\264\177\000\000\346\001\000\000\000\000\000\000M\261\265F\264\177\000\000\300A\206\327\377\177\000\000\032t\265F\001\000\000\000", '\377' <repeats 16 times>, "\001\000\000\000\000\000\000\000\000fo\275\215\f\024\262@A\206\327\377\177\000\000\b\375\377\377\377\377\377\377\002\000\000\000\000\000\000\000\000\000\000\020\264\177\000\000\320B\206\327\377\177\000\000 q\272F\264\177", '\000' <repeats 13 times>, "@\000\000\000\000\002\000\000\000\000\000\000\000\016\000\000\000\000\000\000\200", '\000' <repeats 48 times>...}
found_fixed = {name = {magic = 1145983854, ndata = 0x7fffd7863e80 "\aexample", length = 9, labels = 2, attributes = 1, offsets = 0x7fffd7863dc0 "", buffer = 0x7fffd7863e40, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, list = {head = 0x0, tail = 0x0}}, offsets = "\000\b", '\000' <repeats 14 times>, "\332\071\233F\264\177\000\000`T\000\000\000\000\000\000\060%\213\000\000\000\000\000@\006\213\000\000\000\000\000\020\020\211\000\000\000\000\000\240>\206\327\377\177\000\000", '\377' <repeats 16 times>, "\000\000\000\000\000\000\000\000\240\037\000\000\377\377", '\000' <repeats 19 times>, "\003\000\000\000\000\000\000\001\000\000\000\264\177\000", buffer = {magic = 1114990113, base = 0x7fffd7863e80, length = 255, used = 9, current = 0, active = 0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, mctx = 0x0, autore = false}, data = "\aexample\000\000\000\000\000\000\000\000\004\000\000\000w\000\000\000\022", '\000' <repeats 23 times>, "test.test\000rbt\000dn\000\000\000\000\000\000\000\000\000\001\377\377\377\000\377\377", '\000' <repeats 16 times>, '@' <repeats 16 times>, 'Z' <repeats 16 times>, ' ' <repeats 16 times>, "\377\377\377\377\000\377\377\377\377\000\377\377\377\000\377\377", '\000' <repeats 20 times>, "\377\000\377\377\377\000\377\377\377\000\377\377\240b\272F\264\177\000\000\000\000\000"...}
example = 0x7fffd7863f80
found = 0x7fffd7863d70
rdatalist = {rdclass = 1, type = 1, covers = 0, ttl = 2, rdata = {head = 0x7fffd7863c70, tail = 0x7fffd7863c70}, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, upper = "\352", '\353' <repeats 31 times>}
rdataset = {magic = 1145983826, methods = 0x0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, rdclass = 0, type = 0, ttl = 0, trust = 0, covers = 0, attributes = 0, count = 4294967295, resign = 0, private1 = 0x0, private2 = 0x0, private3 = 0x0, privateuint4 = 0, private5 = 0x0, private6 = 0x0, private7 = 0x0}
count = 11
pass = 1
mctx = 0x8b5da0
result = 23
data = "\n\000\000\001"
#5 0x00007fb446ba8cb1 in cmocka_run_one_test_or_fixture () from /lib64/libcmocka.so.0
No symbol table info available.
#6 0x00007fb446ba938b in _cmocka_run_group_tests () from /lib64/libcmocka.so.0
No symbol table info available.
#7 0x0000000000403886 in main () at db_test.c:409
tests = {{name = 0x40507c "getoriginnode_test", test_func = 0x403641 <getoriginnode_test>, setup_func = 0x0, teardown_func = 0x0, initial_state = 0x0}, {name = 0x40508f "getsetservestalettl_test", test_func = 0x4034c3 <getsetservestalettl_test>, setup_func = 0x0, teardown_func = 0x0, initial_state = 0x0}, {name = 0x4050a8 "dns_dbfind_staleok_test", test_func = 0x402e2c <dns_dbfind_staleok_test>, setup_func = 0x0, teardown_func = 0x0, initial_state = 0x0}, {name = 0x4050c0 "class_test", test_func = 0x402d53 <class_test>, setup_func = 0x402d1a <_setup>, teardown_func = 0x402d0a <_teardown>, initial_state = 0x0}, {name = 0x4050cb "dbtype_test", test_func = 0x402b02 <dbtype_test>, setup_func = 0x402d1a <_setup>, teardown_func = 0x402d0a <_teardown>, initial_state = 0x0}, {name = 0x4050d7 "version_test", test_func = 0x402736 <version_test>, setup_func = 0x402d1a <_setup>, teardown_func = 0x402d0a <_teardown>, initial_state = 0x0}}
D:db_test:backtrace from ./core.12310 end
FAIL db_test (exit status: 134)
```July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)