BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2022-03-01T09:57:36Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2424CID 316506: Insecure data handling (TAINTED_SCALAR)2022-03-01T09:57:36ZMichal NowakCID 316506: Insecure data handling (TAINTED_SCALAR)```
*** CID 316506: Insecure data handling (TAINTED_SCALAR)
/lib/dns/journal.c: 1855 in read_one_rr()
1849 */
1850 if (isc_buffer_remaininglength(&j->it.source) != rdlen) {
1851 FAIL(DNS_R_FORMERR);
1852 }
1853 ...```
*** CID 316506: Insecure data handling (TAINTED_SCALAR)
/lib/dns/journal.c: 1855 in read_one_rr()
1849 */
1850 if (isc_buffer_remaininglength(&j->it.source) != rdlen) {
1851 FAIL(DNS_R_FORMERR);
1852 }
1853 isc_buffer_setactive(&j->it.source, rdlen);
1854 dns_rdata_reset(&j->it.rdata);
>>> CID 316506: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted expression "j->it.source.active" to "dns_rdata_fromwire", which uses it as a loop boundary.
1855 CHECK(dns_rdata_fromwire(&j->it.rdata, rdclass, rdtype, &j->it.source,
1856 &j->it.dctx, 0, &j->it.target));
1857 j->it.ttl = ttl;
1858
1859 j->it.xpos += sizeof(journal_rawrrhdr_t) + rrhdr.size;
1860 if (rdtype == dns_rdatatype_soa) {
```Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2423CID 316507: Insecure data handling (TAINTED_SCALAR)2021-03-02T13:57:07ZMichal NowakCID 316507: Insecure data handling (TAINTED_SCALAR)```
*** CID 316507: Insecure data handling (TAINTED_SCALAR)
/lib/dns/rdata/generic/nsec3param_51.c: 241 in tostruct_nsec3param()
235 region.length = rdata->length;
236 nsec3param->hash = uint8_consume_fromregion(&region);
237...```
*** CID 316507: Insecure data handling (TAINTED_SCALAR)
/lib/dns/rdata/generic/nsec3param_51.c: 241 in tostruct_nsec3param()
235 region.length = rdata->length;
236 nsec3param->hash = uint8_consume_fromregion(®ion);
237 nsec3param->flags = uint8_consume_fromregion(®ion);
238 nsec3param->iterations = uint16_consume_fromregion(®ion);
239
240 nsec3param->salt_length = uint8_consume_fromregion(®ion);
>>> CID 316507: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted expression "nsec3param->salt_length" to "mem_maybedup", which uses it as an offset.
241 nsec3param->salt = mem_maybedup(mctx, region.base,
242 nsec3param->salt_length);
243 if (nsec3param->salt == NULL) {
244 return (ISC_R_NOMEMORY);
245 }
246 isc_region_consume(®ion, nsec3param->salt_length);
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2422CID 316508: Insecure data handling (TAINTED_SCALAR)2022-03-01T09:57:39ZMichal NowakCID 316508: Insecure data handling (TAINTED_SCALAR)```
*** CID 316508: Insecure data handling (TAINTED_SCALAR)
/lib/dns/journal.c: 1714 in dns_journal_iter_init()
1708
1709 result = journal_next(j, &pos);
1710 if (result == ISC_R_NOMORE) {
1711 result = ISC_R...```
*** CID 316508: Insecure data handling (TAINTED_SCALAR)
/lib/dns/journal.c: 1714 in dns_journal_iter_init()
1708
1709 result = journal_next(j, &pos);
1710 if (result == ISC_R_NOMORE) {
1711 result = ISC_R_SUCCESS;
1712 }
1713 CHECK(result);
>>> CID 316508: Insecure data handling (TAINTED_SCALAR)
>>> Using tainted variable "pos.serial" as a loop boundary.
1714 } while (pos.serial != end_serial);
1715
1716 /*
1717 * For each RR, subtract the length of the RR header,
1718 * as this would not be present in IXFR messages.
1719 * (We don't need to worry about the transaction header
```Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2421CID 316509: Untrusted value as argument (TAINTED_SCALAR)2021-03-02T13:57:03ZMichal NowakCID 316509: Untrusted value as argument (TAINTED_SCALAR)```
*** CID 316509: (TAINTED_SCALAR)
/lib/dns/rdata/generic/nsec3_50.c: 312 in tostruct_nsec3()
306 if (nsec3->salt == NULL) {
307 return (ISC_R_NOMEMORY);
308 }
309 isc_region_consume(&region, nsec3->salt_length)...```
*** CID 316509: (TAINTED_SCALAR)
/lib/dns/rdata/generic/nsec3_50.c: 312 in tostruct_nsec3()
306 if (nsec3->salt == NULL) {
307 return (ISC_R_NOMEMORY);
308 }
309 isc_region_consume(®ion, nsec3->salt_length);
310
311 nsec3->next_length = uint8_consume_fromregion(®ion);
>>> CID 316509: (TAINTED_SCALAR)
>>> Passing tainted expression "nsec3->next_length" to "mem_maybedup", which uses it as an offset.
312 nsec3->next = mem_maybedup(mctx, region.base, nsec3->next_length);
313 if (nsec3->next == NULL) {
314 goto cleanup;
315 }
316 isc_region_consume(®ion, nsec3->next_length);
317
/lib/dns/rdata/generic/nsec3_50.c: 305 in tostruct_nsec3()
299 region.length = rdata->length;
300 nsec3->hash = uint8_consume_fromregion(®ion);
301 nsec3->flags = uint8_consume_fromregion(®ion);
302 nsec3->iterations = uint16_consume_fromregion(®ion);
303
304 nsec3->salt_length = uint8_consume_fromregion(®ion);
>>> CID 316509: (TAINTED_SCALAR)
>>> Passing tainted expression "nsec3->salt_length" to "mem_maybedup", which uses it as an offset.
305 nsec3->salt = mem_maybedup(mctx, region.base, nsec3->salt_length);
306 if (nsec3->salt == NULL) {
307 return (ISC_R_NOMEMORY);
308 }
309 isc_region_consume(®ion, nsec3->salt_length);
310
```March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2420CID 316510: Memory - corruptions (USE_AFTER_FREE)2021-01-28T21:42:48ZMichal NowakCID 316510: Memory - corruptions (USE_AFTER_FREE)```
*** CID 316510: Memory - corruptions (USE_AFTER_FREE)
/bin/named/statschannel.c: 2353 in generatexml()
2347
2348 cleanup:
2349 isc_log_write(named_g_lctx, NAMED_LOGCATEGORY_GENERAL,
2350 NAMED_LOGMODULE_SE...```
*** CID 316510: Memory - corruptions (USE_AFTER_FREE)
/bin/named/statschannel.c: 2353 in generatexml()
2347
2348 cleanup:
2349 isc_log_write(named_g_lctx, NAMED_LOGCATEGORY_GENERAL,
2350 NAMED_LOGMODULE_SERVER, ISC_LOG_ERROR,
2351 "failed generating XML response");
2352 if (writer != NULL) {
>>> CID 316510: Memory - corruptions (USE_AFTER_FREE)
>>> Calling "xmlFreeTextWriter" frees pointer "writer" which has already been freed.
2353 xmlFreeTextWriter(writer);
2354 }
2355 if (doc != NULL) {
2356 xmlFreeDoc(doc);
2357 }
2358 return (ISC_R_FAILURE);
```February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2419CID 316511: Insecure data handling (TAINTED_SCALAR)2022-03-01T09:57:42ZMichal NowakCID 316511: Insecure data handling (TAINTED_SCALAR)```
*** CID 316511: Insecure data handling (TAINTED_SCALAR)
/lib/dns/rdata/generic/hip_55.c: 496 in casecompare_hip()
490 key_len = uint16_fromregion(&r1);
491 isc_region_consume(&r1, 2); /* key length */
492 isc_region_...```
*** CID 316511: Insecure data handling (TAINTED_SCALAR)
/lib/dns/rdata/generic/hip_55.c: 496 in casecompare_hip()
490 key_len = uint16_fromregion(&r1);
491 isc_region_consume(&r1, 2); /* key length */
492 isc_region_consume(&r2, 4);
493
494 INSIST(r1.length >= (unsigned)(hit_len + key_len));
495 INSIST(r2.length >= (unsigned)(hit_len + key_len));
>>> CID 316511: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted expression "hit_len + key_len" to "memcmp", which uses it as an offset.
496 order = memcmp(r1.base, r2.base, hit_len + key_len);
497 if (order != 0) {
498 return (order);
499 }
500 isc_region_consume(&r1, hit_len + key_len);
501 isc_region_consume(&r2, hit_len + key_len);
```Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2418CID 316512: Untrusted loop bound (TAINTED_SCALAR)2022-03-01T09:57:44ZMichal NowakCID 316512: Untrusted loop bound (TAINTED_SCALAR)```
*** CID 316512: (TAINTED_SCALAR)
/lib/dns/rdata/generic/sig_24.c: 199 in totext_sig()
193
194 /*
195 * Time signed.
196 */
197 when = uint32_fromregion(&sr);
198 isc_region_consume(&sr, 4);
>>> ...```
*** CID 316512: (TAINTED_SCALAR)
/lib/dns/rdata/generic/sig_24.c: 199 in totext_sig()
193
194 /*
195 * Time signed.
196 */
197 when = uint32_fromregion(&sr);
198 isc_region_consume(&sr, 4);
>>> CID 316512: (TAINTED_SCALAR)
>>> Passing tainted expression "when" to "dns_time32_totext", which uses it as a loop boundary.
199 RETERR(dns_time32_totext(when, target));
200 RETERR(str_totext(" ", target));
201
202 /*
203 * Footprint.
204 */
/lib/dns/rdata/generic/sig_24.c: 187 in totext_sig()
181
182 /*
183 * Sig exp.
184 */
185 exp = uint32_fromregion(&sr);
186 isc_region_consume(&sr, 4);
>>> CID 316512: (TAINTED_SCALAR)
>>> Passing tainted expression "exp" to "dns_time32_totext", which uses it as a loop boundary.
187 RETERR(dns_time32_totext(exp, target));
188
189 if ((tctx->flags & DNS_STYLEFLAG_MULTILINE) != 0) {
190 RETERR(str_totext(" (", target));
191 }
192 RETERR(str_totext(tctx->linebreak, target));
```Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2417CID 316513: Insecure data handling (TAINTED_SCALAR)2022-03-01T09:57:47ZMichal NowakCID 316513: Insecure data handling (TAINTED_SCALAR)```
*** CID 316513: Insecure data handling (TAINTED_SCALAR)
/lib/dns/master.c: 2618 in load_raw()
2612 * the target available region be the same if
2613 * decompression is disabled (see dctx above) and we
2614 *...```
*** CID 316513: Insecure data handling (TAINTED_SCALAR)
/lib/dns/master.c: 2618 in load_raw()
2612 * the target available region be the same if
2613 * decompression is disabled (see dctx above) and we
2614 * are not downcasing names (options == 0).
2615 */
2616 isc_buffer_init(&buf, isc_buffer_current(&target),
2617 (unsigned int)rdlen);
>>> CID 316513: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted expression "target.active" to "dns_rdata_fromwire", which uses it as a loop boundary.
2618 result = dns_rdata_fromwire(
2619 &rdata[i], rdatalist.rdclass, rdatalist.type,
2620 &target, &dctx, 0, &buf);
2621 if (result != ISC_R_SUCCESS) {
2622 goto cleanup;
2623 }
```Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2416tlsdns_test gets stuck on FreeBSDs intermittently2021-03-29T13:23:28ZOndřej Surýtlsdns_test gets stuck on FreeBSDs intermittentlyThe `tlsdns_test` gets stuck on the FreeBSD 11 and 12 intermittently. It's not related to the OpenSSL version and it happens only occasionally. When it happens all the threads are waiting in either yield or kevent. We might be missing...The `tlsdns_test` gets stuck on the FreeBSD 11 and 12 intermittently. It's not related to the OpenSSL version and it happens only occasionally. When it happens all the threads are waiting in either yield or kevent. We might be missing some `tls_cycle()` invocation on some rare edge condition that happens only on FreeBSD.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2415Update Coverity Scan CI job to 2020.092021-01-25T11:38:06ZMichal NowakUpdate Coverity Scan CI job to 2020.09Coverity Scan was [updated](https://community.synopsys.com/s/question/0D52H00005NeWJf/announcement-upcoming-coverity-scan-upgrade-to-coverity-202009-release) to [2020.09](https://scan.coverity.com/download). The `coverity` CI job assumes...Coverity Scan was [updated](https://community.synopsys.com/s/question/0D52H00005NeWJf/announcement-upcoming-coverity-scan-upgrade-to-coverity-202009-release) to [2020.09](https://scan.coverity.com/download). The `coverity` CI job assumes 2019.03 at few places.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2411Gracefully shutdown the TLS connections in TLSDNS using SSL_shutdown2021-09-02T12:42:57ZOndřej SurýGracefully shutdown the TLS connections in TLSDNS using SSL_shutdownThe SSL_shutdown needs bit back and forth on the networking channel, so right now we are doing ungraceful shutdown by tearing down the underlying TCP connection. This should be fixed to behave like a good netizen.The SSL_shutdown needs bit back and forth on the networking channel, so right now we are doing ungraceful shutdown by tearing down the underlying TCP connection. This should be fixed to behave like a good netizen.Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2410Follow-up from "Draft: refactor TLSDNS module to work with libuv/ssl directly"2021-09-02T09:10:46ZOndřej SurýFollow-up from "Draft: refactor TLSDNS module to work with libuv/ssl directly"The following discussion from !4584 should be addressed:
- [ ] @each started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4584#note_187796): (+1 comment)
> The "dot" system test is currently only using...The following discussion from !4584 should be addressed:
- [ ] @each started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4584#note_187796): (+1 comment)
> The "dot" system test is currently only using "tls ephemeral". I'm thinking we really should add a test with a non-ephemeral cert and key, but I'm not sure how best to do that. Can we generate some with extremely long lifetimes and put them in the source tree?September 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/2408kasp: Purge deleted keys2021-03-03T11:53:26ZMatthijs Mekkingmatthijs@isc.orgkasp: Purge deleted keysAdd a configuration option for `dnssec-policy` to purge deleted keys.
`purge-keys duration` will purge deleted keys after the given duration. Set to `0` to never purge deleted keys. Default 90 days.Add a configuration option for `dnssec-policy` to purge deleted keys.
`purge-keys duration` will purge deleted keys after the given duration. Set to `0` to never purge deleted keys. Default 90 days.March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2406kasp: look at Inactive/Delete when initializing state files2021-02-03T13:58:41ZMatthijs Mekkingmatthijs@isc.orgkasp: look at Inactive/Delete when initializing state filesThe internal BIND keymgr tries to initialize legacy keys (keys without a state file). If no state file is present it is going to assume the keys in use are actively being used for signing (so setting everything to `rumoured` or `omnipres...The internal BIND keymgr tries to initialize legacy keys (keys without a state file). If no state file is present it is going to assume the keys in use are actively being used for signing (so setting everything to `rumoured` or `omnipresent`, depending on the time).
Initializing the state files currently does not look at the `Inactive` and `Delete` time. So I agree that we can add logic such that when the `Inactive` time has passed set the key goal to `hidden` and `ds/krrsig/zrrsig` to `unretentive`, and when the `Delete` time has passed set the everything to `hidden`.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2405[ISC-support #17264] ADB overmem condition and cleaning - very difficult to d...2024-03-01T10:04:57ZBrian Conry[ISC-support #17264] ADB overmem condition and cleaning - very difficult to detect and causes erratic behaviorThe ADB's mctx size is set to 1/8 of the max-cache-size, if set. This is the only means to control the ADB memory limit. There is also a hard-coded maximum ADB size applied to ADBs for views that share a cache.
When it goes overmem, t...The ADB's mctx size is set to 1/8 of the max-cache-size, if set. This is the only means to control the ADB memory limit. There is also a hard-coded maximum ADB size applied to ADBs for views that share a cache.
When it goes overmem, the ADB starts removing names and entries. The strategy for removing entries doesn't seem to be tied strongly to utility.
This can lead to erratic behavior as BIND is constantly forgetting information about server SRTTs, EDNS capabilities, and other useful data.
In some cases, if not all of the entries for servers associated with a zone are affected by the overmem purge, this can cause the resolver to fixate on a small subset of the servers authoritative for the zone - and not necessarily the subset with the best SRTT.
There is no logging at any level related to ADB overmem activities, nor are there any stats directly related to ADB memory usage.
There are stats for counts of names and entries, along with the number of buckets for each type, but there's no reliable way to map those to memory usage.
The stats channel does contain detail for the ADB memory contexts, but there's no reliable way to map those memory contexts to a particular view.
It seems likely that most of the time the symptoms of an overmem ADB will be minor and nearly impossible to directly measure - small delays and increases in CPU usage associated with the repeated creation and destruction of ADB entries and/or fixation on suboptimal upstream servers - but will definitely degrade the quality of service that the resolver is providing.
This behavior was noticed by a customer when their monitoring zone happened to, by chance, be negatively affected.
Most of the symptoms described here are theoretical, based on my understanding of the code and various customer-described, but unreproducable and otherwise unexplained, behaviors.
This issue is a feature request covering:
* specific testing by ISC to better understand the impact and range of behaviors with the ADB is overmem #2441
* additional logging related to ADB overmem activities #2435
* additional stats/metrics relating to ADB overmem #2436
* improvements to ADB overmem behavior (ideally based on some utility metric) #2437
* ability to directly control ADB size independent of cache size #2438
* revisit the hard-coded shared-cache maximum ADB size (e.g. remove in favor of configuration) #2439
* system tests related to any/all items aboveNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2404Bind 9.16.8 reuses old keys2021-03-15T13:16:47ZMarc Dequènes (Duck)Bind 9.16.8 reuses old keys
### Summary
I switched from 9.11.5.P4 to 9.16.8 and from dnssec-keymgr to dnssec-policy. dnssec-keymgr did not remove old keys and Bind now just revived them all without caring for the old state.
### BIND version used
```
BIND 9.16.8...
### Summary
I switched from 9.11.5.P4 to 9.16.8 and from dnssec-keymgr to dnssec-policy. dnssec-keymgr did not remove old keys and Bind now just revived them all without caring for the old state.
### BIND version used
```
BIND 9.16.8-Debian (Stable Release) <id:539f9f0>
running on Linux x86_64 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28)
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--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' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-Pv1hAF/bind9-9.16.8=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 8.3.0
compiled with OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019
linked to OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019
compiled with libuv version: 1.24.1
linked to libuv version: 1.24.1
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with json-c version: 0.12.1
linked to json-c version: 0.12.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.3.2
compiled with protobuf-c version: 1.3.1
linked to protobuf-c version: 1.3.1
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
```
### Steps to reproduce
Switch from dnssec-keymgr based management to dnssec-policy. You also need to have old keys around. dnssec-keymgr lacked cleanup management so they stayed around.
### What is the current *bug* behavior?
Here is an example zone: https://dnsviz.net/d/_kage.duckcorp.org/dnssec/
You can have a look at the previous state. As you can see that's a bit of a mess. I also wonder if Bind is gonna inactive old keys again by itself or if I have to do that myself.
### What is the expected *correct* behavior?
IMHO it would help to have a proper upgrade path from dnssec-keymgr to dnssec-policy. That means reading the .key files (created by dnssec-keymgr) and at least the Inactive field in order to ignore keys that are not relevant.
### Relevant configuration files
The configuration with dnssec-keymgr:
```
zone "hq.duckcorp.org" IN {
type master;
allow-transfer { key duckcorp-internal; };
also-notify { duckland_ns2; };
file "/var/cache/bind/masters/hq.duckcorp.org.zone";
inline-signing yes;
auto-dnssec maintain;
}
```
with /etc/bind/dnssec-policy.conf:
```
policy default {
algorithm RSASHA512;
keyttl 3600;
key-size ksk 4096;
key-size zsk 2048;
roll-period ksk 1y;
roll-period zsk 3mo;
pre-publish ksk 1mo;
pre-publish zsk 1mo;
post-publish ksk 1mo;
post-publish zsk 1mo;
standby ksk 0;
standby zsk 0;
coverage 1y;
};
```
And now:
```
zone "hq.duckcorp.org" IN {
type master;
allow-transfer { key duckcorp-internal; };
also-notify { duckland_ns2; };
file "/var/cache/bind/masters/hq.duckcorp.org.zone";
dnssec-policy "generated";
}
dnssec-policy "generated" {
keys {
ksk key-directory lifetime P1Y algorithm rsasha512 4096;
zsk key-directory lifetime 30d algorithm rsasha512 2048;
};
max-zone-ttl PT1H;
};
```
Example of key header for one of the obsolete keys K_kage.hq.duckcorp.org.+010+57716.key:
```
; This is a zone-signing key, keyid 57716, for _kage.hq.duckcorp.org.
; Created: 20190927153144 (Sat Sep 28 00:31:44 2019)
; Publish: 20200224153144 (Tue Feb 25 00:31:44 2020)
; Activate: 20200325153144 (Thu Mar 26 00:31:44 2020)
; Inactive: 20200623153144 (Wed Jun 24 00:31:44 2020)
; Delete: 20200723153144 (Fri Jul 24 00:31:44 2020)
```
And the corresponding `rndc dnssec -status` for it:
```
key: 57716 (RSASHA512), ZSK
published: yes - since Tue Feb 25 00:31:44 2020
zone signing: yes - since Thu Mar 26 00:31:44 2020
Rollover is due since Wed Jun 24 00:31:44 2020
- dnskey: omnipresent
- zone rrsig: omnipresent
```
Interestingly some are in other states like:
```
key: 36878 (RSASHA512), ZSK
published: no - scheduled Fri Feb 19 00:31:44 2021
zone signing: no - scheduled Sun Mar 21 00:31:44 2021
Key will retire on Sat Jun 19 00:31:44 2021
- dnskey: hidden
- zone rrsig: hidden
```
or
```
key: 49415 (RSASHA512), ZSK
published: no
zone signing: no
Key has been removed from the zone
- goal: hidden
- dnskey: hidden
- zone rrsig: unretentive
```
Regards.
\\_o<March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2403dig has a fit with option -multi (typo on +multi)2022-04-26T13:16:36ZJP Mensdig has a fit with option -multi (typo on +multi)### Summary
`dig` crashes when erroneously given option `-multi`
During a training, a student (Rob) erroneously specified `-multi` instead of `+multi` when using `dig` on an internal training domain. This was using `bind-utils-9.11.20-...### Summary
`dig` crashes when erroneously given option `-multi`
During a training, a student (Rob) erroneously specified `-multi` instead of `+multi` when using `dig` on an internal training domain. This was using `bind-utils-9.11.20-5.el8.x86_64` on CentOS 8.
I am able to reproduce this on a similar machine with an ISC COPR release.
### BIND version used
```
BIND 9.16.11 (Stable Release) <id:9ff601b>
running on Linux x86_64 4.18.0-240.1.1.el8_3.x86_64 #1 SMP Thu Nov 19 17:20:08 UTC 2020
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/opt/isc/isc-bind/root/usr' '--exec-prefix=/opt/isc/isc-bind/root/usr' '--bindir=/opt/isc/isc-bind/root/usr/bin' '--sbindir=/opt/isc/isc-bind/root/usr/sbin' '--sysconfdir=/etc/opt/isc/scls/isc-bind' '--datadir=/opt/isc/isc-bind/root/usr/share' '--includedir=/opt/isc/isc-bind/root/usr/include' '--libdir=/opt/isc/isc-bind/root/usr/lib64' '--libexecdir=/opt/isc/isc-bind/root/usr/libexec' '--localstatedir=/var/opt/isc/scls/isc-bind' '--sharedstatedir=/var/opt/isc/scls/isc-bind/lib' '--mandir=/opt/isc/isc-bind/root/usr/share/man' '--infodir=/opt/isc/isc-bind/root/usr/share/info' '--disable-static' '--enable-dnstap' '--with-pic' '--with-gssapi' '--with-json-c' '--with-libtool' '--with-libxml2' '--without-lmdb' '--with-python' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -L/opt/isc/isc-bind/root/usr/lib64' 'LT_SYS_LIBRARY_PATH=/usr/lib64' 'PKG_CONFIG_PATH=:/opt/isc/isc-bind/root/usr/lib64/pkgconfig:/opt/isc/isc-bind/root/usr/share/pkgconfig' 'SPHINX_BUILD=/builddir/build/BUILD/bind-9.16.11/sphinx/bin/sphinx-build'
compiled by GCC 8.3.1 20191121 (Red Hat 8.3.1-5)
compiled with OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
linked to OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
compiled with libuv version: 1.40.0
linked to libuv version: 1.40.0
compiled with libxml2 version: 2.9.7
linked to libxml2 version: 20907
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
default paths:
named configuration: /etc/opt/isc/scls/isc-bind/named.conf
rndc configuration: /etc/opt/isc/scls/isc-bind/rndc.conf
DNSSEC root key: /etc/opt/isc/scls/isc-bind/bind.keys
nsupdate session key: /var/opt/isc/scls/isc-bind/run/named/session.key
named PID file: /var/opt/isc/scls/isc-bind/run/named/named.pid
named lock file: /var/opt/isc/scls/isc-bind/run/named/named.lock
```
### Steps to reproduce
```
/opt/isc/isc-bind/root/bin/dig isc.org -multi
```
### What is the current *bug* behavior?
```console
$ /opt/isc/isc-bind/root/bin/dig isc.org -multi
add 0x55a9501c2160 size 8528 file log.c line 257 mctx 0x55a9501b53e0
add 0x7fd9d72c6010 size 72 file log.c line 306 mctx 0x55a9501b53e0
add 0x7fd9d72c7010 size 80 file log.c line 665 mctx 0x55a9501b53e0
add 0x7fd9d72c8018 size 23 file log.c line 667 mctx 0x55a9501b53e0
add 0x7fd9d72c7060 size 80 file log.c line 665 mctx 0x55a9501b53e0
add 0x7fd9d72c8030 size 23 file log.c line 667 mctx 0x55a9501b53e0
add 0x7fd9d72c70b0 size 80 file log.c line 665 mctx 0x55a9501b53e0
add 0x7fd9d72c8048 size 22 file log.c line 667 mctx 0x55a9501b53e0
add 0x7fd9d72c7100 size 80 file log.c line 665 mctx 0x55a9501b53e0
add 0x7fd9d72c9008 size 13 file log.c line 667 mctx 0x55a9501b53e0
add 0x7fd9d72c9010 size 32 file log.c line 996 mctx 0x55a9501b53e0
add 0x7fd9d72ca010 size 336 file log.c line 996 mctx 0x55a9501b53e0
del 0x7fd9d72c9010 size 32 file log.c line 1004 mctx 0x55a9501b53e0
add 0x7fd9d72c9010 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9030 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9050 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9070 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9090 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9090 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c90b0 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c90d0 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c90f0 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9110 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9130 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9150 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9170 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9190 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c91b0 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c91d0 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c91f0 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9210 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9230 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9250 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9270 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72c9290 size 32 file log.c line 952 mctx 0x55a9501b53e0
add 0x7fd9d72cb010 size 288 file task.c line 1386 mctx 0x55a9501b53e0
add 0x7fd9d72cc010 size 144 file task.c line 1410 mctx 0x55a9501b53e0
add 0x7fd9d72cd010 size 216 file task.c line 286 mctx 0x55a9501b53e0
add 0x7fd9d72ce010 size 160 file timer.c line 697 mctx 0x55a9501b53e0
add 0x7fd9d72cf010 size 56 file heap.c line 87 mctx 0x55a9501b53e0
add 0x7fd9d72d0010 size 168 file socket.c line 3806 mctx 0x55a9501b53e0
add 0x7fd9d72c7150 size 80 file socket.c line 3827 mctx 0x55a9501b53e0
add 0x7fd9d729c010 size 168000 file socket.c line 3578 mctx 0x55a9501b53e0
add 0x55a9501c7ce0 size 84000 file socket.c line 3584 mctx 0x55a9501b53e0
add 0x55a9501dc550 size 40960 file socket.c line 3589 mctx 0x55a9501b53e0
add 0x55a9501e65a0 size 84000 file socket.c line 3631 mctx 0x55a9501b53e0
add 0x55a9501fae10 size 24576 file socket.c line 3638 mctx 0x55a9501b53e0
add 0x7fd9d72cefb0 size 96 file mem.c line 1607 mctx 0x55a9501b53e0
add 0x55a95021a170 size 2464 file resconf.c line 522 mctx 0x55a9501b53e0
add 0x7fd9d72d1010 size 152 file resconf.c line 239 mctx 0x55a9501b53e0
add 0x7fd9d72d10a8 size 152 file resconf.c line 239 mctx 0x55a9501b53e0
add 0x55a950220418 size 2072 file dighost.c line 487 mctx 0x55a9501b53e0
add 0x55a950220418 size 2072 file dighost.c line 487 mctx 0x55a9501b53e0
add 0x55a950220c38 size 2072 file dighost.c line 487 mctx 0x55a9501b53e0
del 0x7fd9d72d1010 size 152 file resconf.c line 652 mctx 0x55a9501b53e0
del 0x7fd9d72d10a8 size 152 file resconf.c line 652 mctx 0x55a9501b53e0
del 0x55a95021a170 size 2464 file resconf.c line 665 mctx 0x55a9501b53e0
add 0x55a950221458 size 5176 file dighost.c line 618 mctx 0x55a9501b53e0
add 0x55a950222898 size 5176 file dighost.c line 618 mctx 0x55a9501b53e0
Invalid option: -lti
Usage: dig [@global-server] [domain] [q-type] [q-class] {q-opt}
{global-d-opt} host [@local-server] {local-d-opt}
[ host [@local-server] {local-d-opt} [...]]
Use "dig -h" (or "dig -h | more") for complete list of options
```
### What is the expected *correct* behavior?
```
Invalid option: -lti
Usage: dig [@global-server] [domain] [q-type] [q-class] {q-opt}
{global-d-opt} host [@local-server] {local-d-opt}
[ host [@local-server] {local-d-opt} [...]]
Use "dig -h" (or "dig -h | more") for complete list of options
```
### Relevant configuration files
### Relevant logs and/or screenshots
### Possible fixesFebruary 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)https://gitlab.isc.org/isc-projects/bind9/-/issues/2402BIND 9.16.11 build fails with static OpenSSL library2021-02-16T23:38:49ZGreg RabilBIND 9.16.11 build fails with static OpenSSL libraryBuilding BIND 9.16.11 with a static version of OpenSSL fails. This worked previously with BIND 9.16.10. The problem appears to be due to the ordering of SSL libraries in several of the Makefiles. For example, this line in the 'lib/sam...Building BIND 9.16.11 with a static version of OpenSSL fails. This worked previously with BIND 9.16.10. The problem appears to be due to the ordering of SSL libraries in several of the Makefiles. For example, this line in the 'lib/samples/Makefile':
OPENSSL_LIBS = -L/opt/work6/tmp/openssl/lib -lcrypto -lssl
In BIND 9.16.10, this line read:
OPENSSL_LIBS = -L/opt/incontrol/dns/openssl/lib -lcrypto
The addition of '-lssl' must be before '-lcrypto'. However, setting OPENSSL_LIBS environment variable prior to running configure does not solve the problem because OPENSSL_LIBS does not appear to be honored for this setting.
Please find the attached config and build logs.
[bind-9.16.11-with-static-openssl-build.log](/uploads/8e027756bf75e7799fc516ef0bd88c55/bind-9.16.11-with-static-openssl-build.log)
[bind-9.16.11-with-static-openssl-config.log](/uploads/89aa076f9bf0e728820f1c6bc2d99ae4/bind-9.16.11-with-static-openssl-config.log)March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/2398Memory demands of BIND are MUCH higher on systems with many CPU cores2022-01-20T10:21:44ZPetr MenšíkMemory demands of BIND are MUCH higher on systems with many CPU cores<!--
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
Compared to BIND 9.11, latest builds of 9.16 and 9.17 have quite huge memory demands if CPU count is unusually high.
### BIND version used
```
BIND 9.17.8 (Development Release) <id:6455657>
running on Linux aarch64 5.10.8-200.fc33.aarch64 #1 SMP Sun Jan 17 19:21:29 UTC 2021
built by make with '--enable-developer'
compiled by GCC 10.2.1 20201125 (Red Hat 10.2.1-9)
compiled with OpenSSL version: OpenSSL 1.1.1i FIPS 8 Dec 2020
linked to OpenSSL version: OpenSSL 1.1.1i FIPS 8 Dec 2020
compiled with libuv version: 1.40.0
linked to libuv version: 1.40.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.14
linked to json-c version: 0.14
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.3
threads support is enabled
default paths:
named configuration: /usr/local/etc/named.conf
rndc configuration: /usr/local/etc/rndc.conf
DNSSEC root key: /usr/local/etc/bind.keys
nsupdate session key: /usr/local/var/run/named/session.key
named PID file: /usr/local/var/run/named/named.pid
named lock file: /usr/local/var/run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
- have an unusual high count of cores detected
- do not limit used cores by -n parameter
```
# lscpu
Architecture: aarch64
CPU op-mode(s): 64-bit
Byte Order: Little Endian
CPU(s): 256
On-line CPU(s) list: 0-255
Thread(s) per core: 4
Core(s) per socket: 32
Socket(s): 2
NUMA node(s): 2
Vendor ID: Cavium
Model: 1
Model name: ThunderX2 99xx
Stepping: 0x1
Frequency boost: disabled
CPU max MHz: 2200.0000
CPU min MHz: 1000.0000
BogoMIPS: 400.00
L1d cache: 2 MiB
L1i cache: 2 MiB
L2 cache: 16 MiB
L3 cache: 64 MiB
NUMA node0 CPU(s): 0-127
NUMA node1 CPU(s): 128-255
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Branch predictor hardening
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics cpuid asimdrdm
```
### What is the current *bug* behavior?
```
# ps u -C lt-named
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
named 368968 26.0 27.5 42908208 18101652 pts/0 Sl 05:35 1:06 /root/bind9/bin/named/.libs/lt-named -u named -c /etc/named.conf -g
```
### What is the expected *correct* behavior?
(What you should see instead.)
- BIND 9.11 has tiny memory demands compared to recent versions.
```
# bind 9.11.26 package of Fedora
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
named 288640 0.3 0.2 3679852 188712 ? Ssl 04:07 0:00 /usr/sbin/named -u named -c /etc/named.conf
# devel build BIND 9.17.8
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
named 289095 27.3 27.5 42581812 18102972 pts/0 Sl+ 04:14 0:16 /root/bind9/bin/named/.libs/lt-named -g -u named -c /etc/name
# devel build BIND 9.16.10
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
named 307237 77.5 28.3 42578444 18634528 pts/0 Sl+ 04:29 1:36 ./named -u named -c /etc/named.conf -g
# devel build BIND 9.11.26 (Extended Support Version) <id:0ea4f682f3>
named 327832 6.2 0.2 2760764 146140 pts/0 Sl+ 04:59 0:00 ./named -u named -c /etc/named.conf -g
```
Check [original comment](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4582#note_187873)
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
```
21-Jan-2021 05:34:39.847 starting BIND 9.17.8 (Development Release) <id:6455657>
21-Jan-2021 05:34:39.847 running on Linux aarch64 5.10.8-200.fc33.aarch64 #1 SMP Sun Jan 17 19:21:29 UTC 2021
21-Jan-2021 05:34:39.847 built with '--enable-developer'
21-Jan-2021 05:34:39.847 running as: lt-named -u named -c /dev/null -g
21-Jan-2021 05:34:39.847 compiled by GCC 10.2.1 20201125 (Red Hat 10.2.1-9)
21-Jan-2021 05:34:39.847 compiled with OpenSSL version: OpenSSL 1.1.1i FIPS 8 Dec 2020
21-Jan-2021 05:34:39.847 linked to OpenSSL version: OpenSSL 1.1.1i FIPS 8 Dec 2020
21-Jan-2021 05:34:39.847 compiled with libxml2 version: 2.9.10
21-Jan-2021 05:34:39.847 linked to libxml2 version: 20910
21-Jan-2021 05:34:39.847 compiled with json-c version: 0.14
21-Jan-2021 05:34:39.847 linked to json-c version: 0.14
21-Jan-2021 05:34:39.847 compiled with zlib version: 1.2.11
21-Jan-2021 05:34:39.847 linked to zlib version: 1.2.11
21-Jan-2021 05:34:39.847 ----------------------------------------------------
21-Jan-2021 05:34:39.847 BIND 9 is maintained by Internet Systems Consortium,
21-Jan-2021 05:34:39.847 Inc. (ISC), a non-profit 501(c)(3) public-benefit
21-Jan-2021 05:34:39.847 corporation. Support and training for BIND 9 are
21-Jan-2021 05:34:39.847 available at https://www.isc.org/support
21-Jan-2021 05:34:39.847 ----------------------------------------------------
21-Jan-2021 05:34:39.847 adjusted limit on open files from 4096 to 1048576
21-Jan-2021 05:34:39.847 found 256 CPUs, using 256 worker threads
21-Jan-2021 05:34:39.847 using 256 UDP listeners per interface
21-Jan-2021 05:34:49.947 using up to 21000 sockets
21-Jan-2021 05:34:49.947 config.c: option 'trust-anchor-telemetry' is experimental and subject to change in the future
21-Jan-2021 05:34:49.947 loading configuration from '/dev/null'
21-Jan-2021 05:34:49.947 unable to open '/usr/local/etc/bind.keys'; using built-in keys instead
21-Jan-2021 05:34:50.027 looking for GeoIP2 databases in '/usr/share/GeoIP'
21-Jan-2021 05:34:50.027 opened GeoIP2 database '/usr/share/GeoIP/GeoLite2-Country.mmdb'
21-Jan-2021 05:34:50.027 opened GeoIP2 database '/usr/share/GeoIP/GeoLite2-City.mmdb'
21-Jan-2021 05:34:50.037 using default UDP/IPv4 port range: [32768, 60999]
21-Jan-2021 05:34:50.037 using default UDP/IPv6 port range: [32768, 60999]
```
### Possible fixes
Lazy initialization of some worker threads queues. Detected during unit tests slowdown, when checking MR !4582.January 2022 (9.16.25, 9.16.25-S1, 9.17.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/2396BIND 9.16 unit tests failing reliably on x86_64 NUMA machines2021-10-07T09:42:24ZPetr MenšíkBIND 9.16 unit tests failing reliably on x86_64 NUMA machines<!--
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
Some libisc unit tests are reliably failing on 9.16.10 build
### BIND version used
(Paste the output of `named -V`.)
```
BIND 9.16.10-RedHat-9.16.10-2.fc34 (Stable Release) <id:fac8def>
running on Linux x86_64 5.11.0-0.rc2.20210108gitf5e6c330254a.119.fc34.x86_64 #1 SMP Fri Jan 8 16:28:08 UTC 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/python3' '--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' '--disable-isc-spnego' '--with-lmdb=yes' '--without-libjson' '--with-json-c' '--enable-dnstap' '--with-cmocka' '--enable-fixed-rrset' '--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CC=gcc' 'CFLAGS= -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld ' 'LT_SYS_LIBRARY_PATH=/usr/lib64:' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 11.0.0 20210113 (Red Hat 11.0.0-0)
compiled with OpenSSL version: OpenSSL 1.1.1i FIPS 8 Dec 2020
linked to OpenSSL version: OpenSSL 1.1.1i FIPS 8 Dec 2020
compiled with libuv version: 1.40.0
linked to libuv version: 1.40.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.14
linked to json-c version: 0.14
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.3
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
default paths:
named configuration: /etc/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
Run unit tests on numa machine with 40+ processors.
### What is the current *bug* behavior?
Few lib/isc tests end with signal 6.
```
gdb .libs/lt-buffer_test
(gdb) run
(gdb) bt
#0 0x00007ffff7da0272 in raise () from /lib64/libc.so.6
#1 0x00007ffff7d898a4 in abort () from /lib64/libc.so.6
#2 0x00007ffff7f5f1a5 in isc_assertion_failed (file=file@entry=0x7ffff7fa60ea "../../../lib/isc/hp.c", line=line@entry=88,
type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7ffff7fa60ce "tid_v < isc__hp_max_threads")
at ../../../lib/isc/assertions.c:47
#3 0x00007ffff7f6363d in tid () at ../../../lib/isc/hp.c:85
#4 tid () at ../../../lib/isc/hp.c:85
#5 isc_hp_protect (hp=0x55555db5adb8, ihp=<optimized out>, atom=0x555558f9ef80) at ../../../lib/isc/hp.c:167
#6 0x00007ffff7f8036c in isc_queue_dequeue (queue=<optimized out>) at ../../../lib/isc/queue.c:181
#7 isc_queue_dequeue (queue=queue@entry=0x555558f9ef80) at ../../../lib/isc/queue.c:173
#8 0x00007ffff7f84e90 in process_queue (worker=worker@entry=0x5555555744c0, queue=0x555558f9ef80)
at netmgr/../../../../lib/isc/netmgr/netmgr.c:606
#9 0x00007ffff7f8567b in process_priority_queue (worker=0x5555555744c0) at netmgr/../../../../lib/isc/netmgr/netmgr.c:585
#10 process_queues (worker=0x5555555744c0) at netmgr/../../../../lib/isc/netmgr/netmgr.c:595
#11 async_cb (handle=<optimized out>) at netmgr/../../../../lib/isc/netmgr/netmgr.c:556
#12 0x00007ffff7a3bffd in uv__async_io (loop=0x5555555744d0, w=<optimized out>, events=<optimized out>) at src/unix/async.c:163
#13 0x00007ffff7a54ac3 in uv__io_poll (loop=0x5555555744d0, timeout=<optimized out>) at src/unix/linux-core.c:462
#14 0x00007ffff7a44794 in uv_run (loop=loop@entry=0x5555555744d0, mode=mode@entry=UV_RUN_DEFAULT) at src/unix/core.c:385
#15 0x00007ffff7f852f9 in nm_thread (worker0=0x5555555744c0) at netmgr/../../../../lib/isc/netmgr/netmgr.c:496
#16 0x00007ffff786a269 in start_thread () from /lib64/libpthread.so.0
#17 0x00007ffff7e64143 in clone () from /lib64/libc.so.6
(gdb) frame 2
#2 0x00007ffff7f5f1a5 in isc_assertion_failed (file=file@entry=0x7ffff7fa60ea "../../../lib/isc/hp.c", line=line@entry=88,
type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7ffff7fa60ce "tid_v < isc__hp_max_threads")
at ../../../lib/isc/assertions.c:47
47 abort();
(gdb) p tid_v
$1 = 145
(gdb) p isc__hp_max_threads
$2 = 128
```
### What is the expected *correct* behavior?
It should pass, just like on older
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
### Relevant logs and/or screenshots
Fails oten on BIND build on Fedora infrastructure.
https://kojipkgs.fedoraproject.org//work/tasks/3832/59983832/build.log
https://koji.fedoraproject.org/koji/taskinfo?taskID=59983579
```
22/28 passed (6 failed)
===> Broken tests
buffer_test:main -> broken: Received signal 6 [3.586s]
mem_test:main -> broken: Received signal 6 [6.796s]
pool_test:main -> broken: Received signal 6 [3.524s]
socket_test:main -> broken: Received signal 6 [3.409s]
task_test:main -> broken: Received signal 6 [15.954s]
taskpool_test:main -> broken: Received signal 6 [3.504s]
===> Summary
Results read from /root/.kyua/store/results.root_bind_bind-9.16.10_build_lib_isc_tests.20210119-125008-906997.db
Test cases: 28 total, 0 skipped, 0 expected failures, 6 broken, 0 failed
Total time: 62.697s
R:FAIL:status:1
E:unit:Tue Jan 19 07:51:12 AM EST 2021
```
```
# tail -30 /proc/cpuinfo
power management:
processor : 55
vendor_id : GenuineIntel
cpu family : 6
model : 63
model name : Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz
stepping : 2
microcode : 0x2d
cpu MHz : 2400.000
cache size : 35840 KB
physical id : 1
siblings : 28
core id : 14
cpu cores : 14
apicid : 61
initial apicid : 61
fpu : yes
fpu_exception : yes
cpuid level : 15
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti intel_ppin tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc dtherm ida arat pln pts
vmx flags : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid ple shadow_vmcs
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
bogomips : 5187.78
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Ondřej SurýOndřej Surý