BIND issues
https://gitlab.isc.org/isc-projects/bind9/-/issues
2020-07-16T07:23:52Z
https://gitlab.isc.org/isc-projects/bind9/-/issues/1235
system tests fail with new /etc/bind.keys installed
2020-07-16T07:23:52Z
Mark Andrews
system tests fail with new /etc/bind.keys installed
```
20-Sep-2019 08:44:42.396 loading configuration from '/Users/marka/git/bind9/bin/tests/system/qmin2/ns1/named.conf'
20-Sep-2019 08:44:42.399 reading built-in trust anchors from file '/etc/bind.keys'
20-Sep-2019 08:44:42.399 /etc/bind....
```
20-Sep-2019 08:44:42.396 loading configuration from '/Users/marka/git/bind9/bin/tests/system/qmin2/ns1/named.conf'
20-Sep-2019 08:44:42.399 reading built-in trust anchors from file '/etc/bind.keys'
20-Sep-2019 08:44:42.399 /etc/bind.keys:29: unknown option 'dnssec-keys'
20-Sep-2019 08:44:42.400 load_configuration: failure
20-Sep-2019 08:44:42.400 loading configuration: failure
20-Sep-2019 08:44:42.400 exiting (due to fatal error)
```
One can work around this temporarily by reverting /etc/bind.keys back to being managed keys but the correct fix
is to port to named to a private bind.keys instance.
August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)
https://gitlab.isc.org/isc-projects/bind9/-/issues/1232
expose zone timers (reload, refresh, expire) via stats channel
2020-06-08T12:58:10Z
Brian Conry
expose zone timers (reload, refresh, expire) via stats channel
### Description
A customer has requested:
> It would be very helpful for us to have the various zone timers
> exposed through the statistics channel. The information is currently
> available through `rndc zonestatus`, but it would be ...
### Description
A customer has requested:
> It would be very helpful for us to have the various zone timers
> exposed through the statistics channel. The information is currently
> available through `rndc zonestatus`, but it would be far easier for us
> to monitor the servers if this were accessible through the stats
> channel.
>
> Our use case would be to monitor for zones approaching expiration.
> We'd like to use the stats channel to pull the full list of zones with
> the timers in one operation, and then parse the data.
### Links / references
https://support.isc.org/Ticket/Display.html?id=15166
June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)
https://gitlab.isc.org/isc-projects/bind9/-/issues/1144
Encrypted DNS - RFC 8484, DNS over HTTPS, DOH (also DoT comments)
2021-02-03T14:01:33Z
Vicky Risk
vicky@isc.org
Encrypted DNS - RFC 8484, DNS over HTTPS, DOH (also DoT comments)
February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)
Artem Boldariev
Artem Boldariev
https://gitlab.isc.org/isc-projects/bind9/-/issues/1132
HTTPS and SVCB records
2024-03-14T12:58:04Z
Mark Andrews
HTTPS and SVCB records
Subject to change. Defined in draft-ietf-dnsop-svcb-https (now published as RFC 9460). Experimental type codes of HTTPS/65482 and SVBC/65481
Subject to change. Defined in draft-ietf-dnsop-svcb-https (now published as RFC 9460). Experimental type codes of HTTPS/65482 and SVBC/65481
September 2021 (9.16.21, 9.16.21-S1, 9.17.18)
Mark Andrews
Mark Andrews
https://gitlab.isc.org/isc-projects/bind9/-/issues/1126
Implement check if the DS record has been published
2021-07-08T08:59:38Z
Matthijs Mekking
matthijs@isc.org
Implement check if the DS record has been published
Implement a way to configure one or more name servers to query to ensure the DS for a given key is published. This is needed to perform automatic key rollover (for keys with the KSK role).
Will need a `check-ds-interval` too, to configu...
Implement a way to configure one or more name servers to query to ensure the DS for a given key is published. This is needed to perform automatic key rollover (for keys with the KSK role).
Will need a `check-ds-interval` too, to configure how often such a check needs to be performed.
July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)
Matthijs Mekking
matthijs@isc.org
Matthijs Mekking
matthijs@isc.org
https://gitlab.isc.org/isc-projects/bind9/-/issues/1100
Test inline-signing with $INCLUDE
2021-04-26T13:50:20Z
Matthijs Mekking
matthijs@isc.org
Test inline-signing with $INCLUDE
Dan found an issue that the `isc.org` zone did not work anymore. Specifically the zone has `inline-signing` marked and uses `$INCLUDE` statements.
`$INCLUDE` statements are relative to the working directory, not the zone file.
1. Add...
Dan found an issue that the `isc.org` zone did not work anymore. Specifically the zone has `inline-signing` marked and uses `$INCLUDE` statements.
`$INCLUDE` statements are relative to the working directory, not the zone file.
1. Add a test for this, or add a comment to this issue where case this is tested.
2. Document how `$INCLUDE` works (for example the ARM could at least mention from where relative paths are searched).
3. Logging for missing `$INCLUDE`s also needs some love
May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)
Matthijs Mekking
matthijs@isc.org
Matthijs Mekking
matthijs@isc.org
https://gitlab.isc.org/isc-projects/bind9/-/issues/1041
crash in 9.14.2, possibly on shutdown, cannot reproduce
2020-10-02T08:37:23Z
Carl Byington
crash in 9.14.2, possibly on shutdown, cannot reproduce
Updating from 9.14.1 to 9.14.2, scripts here do a few shutdown/restarts of bind. I cannot reproduce this.
```
(gdb) bt
#0 0x0000003a210324f5 in raise () from /lib64/libc.so.6
#1 0x0000003a21033cd5 in abort () from /lib64/libc.so.6
#2 ...
Updating from 9.14.1 to 9.14.2, scripts here do a few shutdown/restarts of bind. I cannot reproduce this.
```
(gdb) bt
#0 0x0000003a210324f5 in raise () from /lib64/libc.so.6
#1 0x0000003a21033cd5 in abort () from /lib64/libc.so.6
#2 0x000000000041e483 in assertion_failed (file=<value optimized out>, line=<value optimized out>, type=<value optimized out>,
cond=<value optimized out>) at ./main.c:253
#3 0x00007f8acaa1b23a in isc_assertion_failed (file=<value optimized out>, line=<value optimized out>, type=<value optimized out>,
cond=<value optimized out>) at assertions.c:50
#4 0x00007f8acaa2da9b in isc_mempool_destroy (mpctxp=0x7f8abc6c4e20) at mem.c:1647
#5 0x00007f8abc3adb59 in plugin_destroy (instp=0x7f8ac40c3e30) at filter-aaaa.c:456
#6 0x00007f8acb6df4b2 in unload_plugin (pluginp=<value optimized out>) at hooks.c:238
#7 0x00007f8acb6df5ca in ns_plugins_free (mctx=0x211d210, listp=<value optimized out>) at hooks.c:553
#8 0x00007f8acb406465 in destroy (view=0x7f8ac01872e0) at view.c:559
#9 0x00007f8acb42086e in zone_free (zone=0x7f8ac0b66d70) at zone.c:1135
#10 0x00007f8acb429d90 in zone_shutdown (task=<value optimized out>, event=<value optimized out>) at zone.c:13311
#11 0x00007f8acaa3b8b7 in dispatch (queuep=<value optimized out>) at task.c:1130
#12 run (queuep=<value optimized out>) at task.c:1297
#13 0x0000003a21407aa1 in start_thread () from /lib64/libpthread.so.0
#14 0x0000003a210e8c4d in clone () from /lib64/libc.so.6
```
October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)
Michał Kępień
Michał Kępień
https://gitlab.isc.org/isc-projects/bind9/-/issues/853
dnssec-dsfromkey doesn't omit revoked KSK
2021-12-21T05:23:52Z
Evan Hunt
dnssec-dsfromkey doesn't omit revoked KSK
I noticed in passing that if you run dnssec-dsfromkey on an arbitrary DNSKEY RRset, it'll convert all keys with a SEP bit into DS records, including the revoked keys, which is probably not wanted. (`dig dnskey nuthaven.org | dnssec-dsfro...
I noticed in passing that if you run dnssec-dsfromkey on an arbitrary DNSKEY RRset, it'll convert all keys with a SEP bit into DS records, including the revoked keys, which is probably not wanted. (`dig dnskey nuthaven.org | dnssec-dsfromkey -f - nuthaven.org` to demonstrate.)
Maybe we want to include revoked keys if using the -A option (which means all keys, not omitting ZSKs), but I think not by default.
December 2021 (9.16.24, 9.16.24-S1, 9.17.21)
https://gitlab.isc.org/isc-projects/bind9/-/issues/606
Improve ARM DNSSEC Documentation - add DNSSEC GUIDE to appendix
2021-01-11T07:32:20Z
Vicky Risk
vicky@isc.org
Improve ARM DNSSEC Documentation - add DNSSEC GUIDE to appendix
Anand B did a presentation on his assessment of signing systems for the RIPE 77 mtg n Amsterdam, and he reported that the DNSSEC section of the BIND ARM is out of date, and in particular, it does not mention the DNSSEC-keymgr utility. (t...
Anand B did a presentation on his assessment of signing systems for the RIPE 77 mtg n Amsterdam, and he reported that the DNSSEC section of the BIND ARM is out of date, and in particular, it does not mention the DNSSEC-keymgr utility. (that utility is covered in a manpage though).
We should review and spiff up the DNSSEC section.
Anand also commented that the documentation on DNSSEC on the ISC web site was out of date - that is probably the DNSSEC Guide, that we outsourced and haven't been updating. We should discuss whether it would be better to remove it or just mark it as 'somewhat out of date'.
ref: https://ripe77.ripe.net/archives/video/2290/
January 2021 (9.11.27, 9.11.27-S1, 9.16.11, 9.16.11-S1, 9.17.9)
Michał Kępień
Michał Kępień
https://gitlab.isc.org/isc-projects/bind9/-/issues/389
cache dump lists stale TTLs - intentional?
2021-04-26T13:50:22Z
Evan Hunt
cache dump lists stale TTLs - intentional?
While backporting serve-stale to the 9.11 subscription branch I noticed that `rndc dumpdb -cache` has changed its output; records in the cache dump now show their total time to live, not just the time until they become stale.
The dump f...
While backporting serve-stale to the 9.11 subscription branch I noticed that `rndc dumpdb -cache` has changed its output; records in the cache dump now show their total time to live, not just the time until they become stale.
The dump file does include a line that indicates what the stale TTL is set to. You can subtract that from the reported TTL and find out what the record's original TTL was in the auth server reply. So this may be fine, but it wasn't the behavior I was expecting and I wonder if it needs more condsideration.
May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)
Matthijs Mekking
matthijs@isc.org
Matthijs Mekking
matthijs@isc.org
https://gitlab.isc.org/isc-projects/bind9/-/issues/357
Mentions of BIND 8 in the ARM
2021-10-27T11:31:24Z
Ray Bellis
Mentions of BIND 8 in the ARM
There are numerous mentions of BIND 8 behaviour in the ARM. These should be removed where applicable.
There are numerous mentions of BIND 8 behaviour in the ARM. These should be removed where applicable.
November 2021 (9.16.23, 9.16.23-S1, 9.17.20)
Ray Bellis
Ray Bellis
https://gitlab.isc.org/isc-projects/bind9/-/issues/331
Further refactoring of functions in lib/dns/zoneverify.c
2021-08-31T13:33:10Z
Michał Kępień
Further refactoring of functions in lib/dns/zoneverify.c
Certain review comments in !291 were related to code which was not introduced by that MR, but rather just moved around. The following comments should thus be addressed:
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-pr...
Certain review comments in !291 were related to code which was not introduced by that MR, but rather just moved around. The following comments should thus be addressed:
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/291#note_12167): (+1 comment)
> This block is little bit confusing (triggering warning condition on ISC_R_SUCCESS), is there a reason why not to move the whole block before the `break` where it really logically belongs?
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/291#note_12176): (+1 comment)
> Also this sort of calls for a helper static functions similar to `innsec3params()`.
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/291#note_12178): (+1 comment)
> Perhaps use `= { 0 };` and remove memset?
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/291#note_12180): (+1 comment)
> Use `sizeof(set_algorithms)` instead of arbitrary number.
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/291#note_12181): (+1 comment)
> `= { 0 };`
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/291#note_12182): (+3 comments)
> `goto done;` as in previous functions instead of cut© code?
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/291#note_12184): (+1 comment)
> This seems awfully similar to just calling `!chain_equal()`.
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/291#note_12185): (+1 comment)
> This is so fragile.
- [x] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/291#note_12186): (+1 comment)
> Perhaps `255` should be a constant with a descriptive name?
September 2021 (9.16.21, 9.16.21-S1, 9.17.18)
https://gitlab.isc.org/isc-projects/bind9/-/issues/69
fetchlimit system test fails intermittently
2021-09-03T06:59:55Z
Michał Kępień
fetchlimit system test fails intermittently
One failure has been observed so far:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/940
```
S:fetchlimit:Wed Feb 14 15:04:15 UTC 2018
T:fetchlimit:1:A
A:System test fetchlimit
I: checking recursing clients are dropped at the per-s...
One failure has been observed so far:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/940
```
S:fetchlimit:Wed Feb 14 15:04:15 UTC 2018
T:fetchlimit:1:A
A:System test fetchlimit
I: checking recursing clients are dropped at the per-server limit
I: clients: 20
I: clients: 40
I: clients: 60
I: clients: 80
I: clients: 100
I: clients: 120
I: clients: 140
I: clients: 160
I: clients: 180
I: clients: 180
I: clients: 180
I: clients: 165
I: clients: 152
I: clients: 141
I: clients: 131
I: clients: 131
I: clients: 122
I: clients: 114
I: clients: 114
I: clients: 107
I: dumping ADB data
I: atr 1.00 quota 107
I: checking servfail statistics
I: checking lame server recovery
I: clients: 63
I: clients: 24
I: clients: 3
I: clients: 4
I: clients: 6
I: dumping ADB data
I: atr 0.51 quota 95
I: clients: 3
I: clients: 1
I: clients: 1
I: clients: 0
I: clients: 9
I: clients: 0
I: clients: 0
I: clients: 0
I: clients: 0
I: clients: 6
I: dumping ADB data
I: atr 0.06 quota 101
I: checking lame server clients are dropped at the per-domain limit
I: clients: 40
I: clients: 40
I: clients: 40
I: clients: 40
I: clients: 40
I: 5 successful valid queries, 0 SERVFAIL
I: checking drop statistics
I: checking lame server clients are dropped at the soft limit
I: clients: 361
I: 1 successful valid queries, 0 SERVFAIL
I: failed
I:exit status: 1
R:FAIL
E:fetchlimit:Wed Feb 14 15:05:10 UTC 2018
```
Test artifacts are not available as they were not yet collected when the failure happened.
September 2021 (9.16.21, 9.16.21-S1, 9.17.18)
https://gitlab.isc.org/isc-projects/bind9/-/issues/4504
named generates core and ends with signal SIGFPE, Arithmetic exception.
2024-01-02T15:27:20Z
sagar sagar
named generates core and ends with signal SIGFPE, Arithmetic exception.
<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please make sure that you make the new issue
confident...
<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please make sure that you make the new issue
confidential by clicking the checkbox at the bottom!
-->
### Summary
For max-cache-size value, 1823420M named is crashing with arithmetic exception and generating the core.
### BIND version affected
Version info
````
BIND 9.16.23-RH (Extended Support Version) <id:fde3b1f>
running on Linux x86_64 5.15.0-105.125.6.2.1.el9uek.x86_64 #2 SMP Thu Sep 14 21:51:15 PDT 2023
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' '--with-dlopen=yes' '--with-gssapi=yes' '--with-lmdb=yes' '--without-libjson' '--with-json-c' '--enable-dnstap' '--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 -march=x86-64-v2 -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 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 ' 'LT_SYS_LIBRARY_PATH=/usr/lib64:' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 11.4.1 20230605 (Red Hat 11.4.1-2.1.0.1)
compiled with OpenSSL version: OpenSSL 3.0.7 1 Nov 2022
linked to OpenSSL version: OpenSSL 3.0.7 1 Nov 2022
compiled with libuv version: 1.42.0
linked to libuv version: 1.42.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
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.5.2
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
````
### Relevant configuration files
Add max-cache-size value 1823420M option in named.conf to replicate the issue, why this particular value will be explained further in the report.
In our ssystem total memory is cat ./proc/meminfo | grep -i MemTotal
MemTotal: 2124386752 kB
we haven't configured the max cache size option in our configuration file so it takes the max-cache size to 90% of its total memory as seen in the log
````none:89: 'max-cache-size 90%' - setting to 1867136MB (out of 2074596MB)````
### Relevant logs
As soon as it start running it generates
````
Program terminated with signal SIGFPE, Arithmetic exception.
#0 0x00007f29bc9f5a8d in more_frags (new_size=0, ctx=0x7f29b032e6c0) at ../../../lib/isc/mem.c:457
457 frags = (int)(total_size / new_size);
[Current thread is 1 (Thread 0x7f29bb9e5640 (LWP 346082))]
(gdb) bt
#0 0x00007f29bc9f5a8d in more_frags (new_size=0, ctx=0x7f29b032e6c0) at ../../../lib/isc/mem.c:457
#1 mem_getunlocked (ctx=ctx@entry=0x7f29b032e6c0, size=size@entry=4294967296) at ../../../lib/isc/mem.c:522
#2 0x00007f29bca003ce in isc___mem_get (ctx0=0x7f29b032e6c0, size=4294967296, file=0x7f29bcc8e980 "../../../lib/dns/rbt.c", line=2387) at ../../../lib/isc/mem.c:1066
#3 0x00007f29bcb6c465 in rehash (newbits=<optimized out>, rbt=0x7f29b682d010) at ../../../lib/dns/rbt.c:2387
#4 maybe_rehash (rbt=0x7f29b682d010, newcount=<optimized out>) at ../../../lib/dns/rbt.c:2409
#5 0x00007f29bcb6d9d0 in dns_rbt_adjusthashsize (size=<optimized out>, rbt=<optimized out>) at ../../../lib/dns/rbt.c:1098
#6 dns_rbt_adjusthashsize (rbt=<optimized out>, size=<optimized out>) at ../../../lib/dns/rbt.c:1084
#7 0x00007f29bcb84dd9 in adjusthashsize (db=0x7f29b6829010, size=1911994449920) at ../../../lib/dns/rbtdb.c:8129
#8 0x000055742d5bd66b in configure_view (view=<optimized out>, viewlist=<optimized out>, config=0x7f29b6d60ee8, vconfig=0x0, cachelist=<optimized out>, kasplist=<optimized out>, bindkeys=0x0,
mctx=0x55742e088c40, actx=0x7f29bbb2f538, need_hints=true) at ../../../bin/named/server.c:4625
#9 0x000055742d5cba8b in load_configuration (filename=<optimized out>, server=server@entry=0x7f29b6d32010, first_time=first_time@entry=true) at ../../../bin/named/server.c:8997
#10 0x000055742d5cdc1e in run_server (task=<optimized out>, event=<optimized out>) at ../../../bin/named/server.c:9709
#11 0x00007f29bca221bd in task_run (task=0x7f29b6d3d010) at ../../../lib/isc/task.c:857
#12 isc_task_run (task=0x7f29b6d3d010) at ../../../lib/isc/task.c:950
#13 0x00007f29bca0d2a9 in isc__nm_async_task (worker=0x55742e09bfb0, ev0=0x7f29b6d478a8) at netmgr/../../../../lib/isc/netmgr/netmgr.c:873
#14 process_netievent (worker=worker@entry=0x55742e09bfb0, ievent=0x7f29b6d478a8) at netmgr/../../../../lib/isc/netmgr/netmgr.c:958
#15 0x00007f29bca0d425 in process_queue (worker=worker@entry=0x55742e09bfb0, type=type@entry=NETIEVENT_TASK) at netmgr/../../../../lib/isc/netmgr/netmgr.c:1027
#16 0x00007f29bca0dc17 in process_all_queues (worker=0x55742e09bfb0) at netmgr/../../../../lib/isc/netmgr/netmgr.c:798
#17 async_cb (handle=0x55742e09c310) at netmgr/../../../../lib/isc/netmgr/netmgr.c:827
#18 0x00007f29bc7a6b3d in uv__async_io (loop=0x55742e09bfc0, w=<optimized out>, events=<optimized out>) at src/unix/async.c:163
#19 0x00007f29bc7c285e in uv__io_poll (loop=0x55742e09bfc0, timeout=<optimized out>) at src/unix/epoll.c:374
#20 0x00007f29bc7ac5a8 in uv__io_poll (timeout=<optimized out>, loop=0x55742e09bfc0) at src/unix/udp.c:122
#21 uv_run (loop=loop@entry=0x55742e09bfc0, mode=mode@entry=UV_RUN_DEFAULT) at src/unix/core.c:389
#22 0x00007f29bca0d4b7 in nm_thread (worker0=0x55742e09bfb0) at netmgr/../../../../lib/isc/netmgr/netmgr.c:733
#23 0x00007f29bca1ff9a in isc__trampoline_run (arg=0x55742e09fe90) at ../../../lib/isc/trampoline.c:196
#24 0x00007f29bc200812 in start_thread (arg=<optimized out>) at pthread_create.c:443
#25 0x00007f29bc1a0450 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb)
````
I did some analysis the quantize function in mem_getunlocked is returning value zero for size =4294967296
I did testing around this and it seems like it can return zero for these cases and ours is one of them
````
for(size_t i=1;i<4294967399;i++)
{
size_t result = quantize(i);
if(result==0)
printf("%lu=%lu\n",i,result);
}
4294967289=0
4294967290=0
4294967291=0
4294967292=0
4294967293=0
4294967294=0
4294967295=0
4294967296=0
````
https://gitlab.isc.org/isc-projects/bind9/-/issues/4235
Flamethrower instance #3 stops querying BIND in RPZ mode
2024-01-22T16:24:31Z
Michal Nowak
Flamethrower instance #3 stops querying BIND in RPZ mode
Job [#3554059](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3554059) failed for 2086be9bcafb6985e4bdd79421fe9fb44ff5c9b5.
The `stress:rpz:fedora:38:amd64` "stress" test often fails on BIND 9.16 (and -S) because the Flamethrower no. ...
Job [#3554059](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3554059) failed for 2086be9bcafb6985e4bdd79421fe9fb44ff5c9b5.
The `stress:rpz:fedora:38:amd64` "stress" test often fails on BIND 9.16 (and -S) because the Flamethrower no. 3 stops sending queries over TCP. The other TCP Flamethrower (no. 4) and two UDP Flamethrowers keep working as they should. The issue is limited to BIND 9.16 and the amd64 RPZ job. The Fedora 38 image has Flamethrower 0.11.0 from Fedora repos.
This issue is close to isc-projects/bind9#2395, but not quite. I wonder if the https://gitlab.isc.org/isc-projects/bind9/-/issues/2395#note_187991 fix or bumping to Flamethrower `master` would work.
The first occurrence of this issue seems to be https://gitlab.isc.org/isc-projects/bind9/-/jobs/3435489 from 2 June 2023, between 9.16.41 and 9.16.42 releases. I could not reproduce the problem when manually triggering the job in the CI.
```
2023-07-30:13:27:29 INFO: Server 'ns4' (rpz) received 5,386,242 TCP queries
2023-07-30:13:27:29 INFO: About 10,800,000 TCP queries were expected
2023-07-30:13:27:29 INFO: Minimum number of TCP queries required to pass is 9,720,000
2023-07-30:13:27:29 ERROR: BIND did not process enough TCP queries
```
IPv4 TCP Flamethrower: [generator.log](/uploads/86f30e615716be3e60bbb0472eb82c60/generator.log)
```
45.4845s: send: 1760, avg send: 1406, recv: 1772, avg recv: 1386, min/avg/max resp: 120.112/462.365/2886.94ms, in flight: 587, timeouts: 11
46.4852s: send: 100, avg send: 1378, recv: 633, avg recv: 1369, min/avg/max resp: 52.8356/730.897/1950.99ms, in flight: 50, timeouts: 6
47.4848s: send: 0, avg send: 1378, recv: 7, avg recv: 1340, min/avg/max resp: 1175.22/2074.78/2833.18ms, in flight: 33, timeouts: 6
48.4851s: send: 0, avg send: 1378, recv: 2, avg recv: 1312, min/avg/max resp: 2511.72/2554.51/2597.29ms, in flight: 12, timeouts: 10
49.486s: send: 0, avg send: 1378, recv: 0, avg recv: 1312, min/avg/max resp: 0/-nan/0ms, in flight: 12, timeouts: 0
...
3599.61s: send: 0, avg send: 1378, recv: 0, avg recv: 1312, min/avg/max resp: 0/-nan/0ms, in flight: 12, timeouts: 0
3600.61s: send: 0, avg send: 1378, recv: 0, avg recv: 1312, min/avg/max resp: 0/-nan/0ms, in flight: 12, timeouts: 0
3600.87s: send: 0, avg send: 1378, recv: 0, avg recv: 1312, min/avg/max resp: 0/-nan/0ms, in flight: 12, timeouts: 0
...
runtime : 3600.87 s
total sent : 65289
total rcvd : 64877
```
About 5 million TCP queries should have been sent.
Not planned
https://gitlab.isc.org/isc-projects/bind9/-/issues/4135
Data race lib/dns/zone.c:4127:26 in set_refreshkeytimer
2023-12-08T07:49:51Z
Michal Nowak
Data race lib/dns/zone.c:4127:26 in set_refreshkeytimer
Job [#3451385](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3451385) failed for 81c5f12e2f8d2379e8be07b68102fc9ff9a5de8c.
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1 (mutexes: write M2, ...
Job [#3451385](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3451385) failed for 81c5f12e2f8d2379e8be07b68102fc9ff9a5de8c.
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1 (mutexes: write M2, read M2):
#0 set_refreshkeytimer lib/dns/zone.c:4127:26 (BuildId: fcbd6258d04361cb62bc32ccf87eff93722e9925)
#1 sync_keyzone lib/dns/zone.c:4683:5 (BuildId: fcbd6258d04361cb62bc32ccf87eff93722e9925)
#2 dns_zone_synckeyzone lib/dns/zone.c:4767:11
#3 view_loaded bin/named/./server.c:9692:14 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#4 call_loaddone lib/dns/zt.c:308:3 (BuildId: fcbd6258d04361cb62bc32ccf87eff93722e9925)
#5 doneloading lib/dns/zt.c:597:3
#6 zone_asyncload lib/dns/zone.c:2404:3 (BuildId: fcbd6258d04361cb62bc32ccf87eff93722e9925)
#7 task_run lib/isc/task.c:859:5 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#8 isc_task_run lib/isc/task.c:953:10
#9 process_netievent lib/isc/netmgr/netmgr.c (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#10 process_queue lib/isc/netmgr/netmgr.c:1009:8 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#11 process_all_queues lib/isc/netmgr/netmgr.c:790:25 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#12 async_cb lib/isc/netmgr/netmgr.c:819:6
#13 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163:5 (BuildId: 120c450d14885aa5308bc95c4ea77de2c2b1cc36)
#14 isc__trampoline_run lib/isc/trampoline.c:213:11 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
Previous read of size 4 at 0x000000000001 by thread T2:
#0 isc_time_compare lib/isc/unix/time.c:211:24 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#1 zone_maintenance lib/dns/zone.c:11440:7 (BuildId: fcbd6258d04361cb62bc32ccf87eff93722e9925)
#2 zone_timer lib/dns/zone.c:15072:2 (BuildId: fcbd6258d04361cb62bc32ccf87eff93722e9925)
#3 task_run lib/isc/task.c:859:5 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#4 isc_task_run lib/isc/task.c:953:10
#5 process_netievent lib/isc/netmgr/netmgr.c (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#6 process_queue lib/isc/netmgr/netmgr.c:1009:8 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#7 process_all_queues lib/isc/netmgr/netmgr.c:790:25 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#8 async_cb lib/isc/netmgr/netmgr.c:819:6
#9 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163:5 (BuildId: 120c450d14885aa5308bc95c4ea77de2c2b1cc36)
#10 isc__trampoline_run lib/isc/trampoline.c:213:11 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
Location is heap block of size 3289 at 0x000000000016 allocated by thread T1:
#0 malloc <null> (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#1 default_memalloc lib/isc/mem.c:716:8 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#2 mem_get lib/isc/mem.c:625:8 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#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:2406:10 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#6 isc___mem_get lib/isc/mem.c:1060:11 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#7 isc__mem_get lib/isc/mem.c:2385:10 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#8 dns_zone_create lib/dns/zone.c:1137:9 (BuildId: fcbd6258d04361cb62bc32ccf87eff93722e9925)
#9 dns_zonemgr_createzone lib/dns/zone.c:18828:11 (BuildId: fcbd6258d04361cb62bc32ccf87eff93722e9925)
#10 add_keydata_zone bin/named/./server.c:6789:2 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#11 configure_view_dnsseckeys bin/named/./server.c:1218:2 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#12 configure_view bin/named/./server.c:5515:2 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#13 load_configuration bin/named/./server.c:9136:3 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#14 loadconfig bin/named/./server.c:10322:11 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#15 named_server_reconfigcommand bin/named/./server.c:10724:2 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#16 named_control_docommand bin/named/control.c:252:12 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#17 control_recvmessage bin/named/controlconf.c:477:13 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#18 task_run lib/isc/task.c:859:5 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#19 isc_task_run lib/isc/task.c:953:10
#20 process_netievent lib/isc/netmgr/netmgr.c (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#21 process_queue lib/isc/netmgr/netmgr.c:1009:8 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#22 process_all_queues lib/isc/netmgr/netmgr.c:790:25 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#23 async_cb lib/isc/netmgr/netmgr.c:819:6
#24 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163:5 (BuildId: 120c450d14885aa5308bc95c4ea77de2c2b1cc36)
#25 isc__trampoline_run lib/isc/trampoline.c:213:11 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
Mutex M2 (0x000000000033) created at:
#0 pthread_mutex_init <null> (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#1 isc__mutex_init lib/isc/pthreads/mutex.c:290:8 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#2 dns_zone_create lib/dns/zone.c:1142:2 (BuildId: fcbd6258d04361cb62bc32ccf87eff93722e9925)
#3 dns_zonemgr_createzone lib/dns/zone.c:18828:11 (BuildId: fcbd6258d04361cb62bc32ccf87eff93722e9925)
#4 add_keydata_zone bin/named/./server.c:6789:2 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#5 configure_view_dnsseckeys bin/named/./server.c:1218:2 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#6 configure_view bin/named/./server.c:5515:2 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#7 load_configuration bin/named/./server.c:9136:3 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#8 loadconfig bin/named/./server.c:10322:11 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#9 named_server_reconfigcommand bin/named/./server.c:10724:2 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#10 named_control_docommand bin/named/control.c:252:12 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#11 control_recvmessage bin/named/controlconf.c:477:13 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#12 task_run lib/isc/task.c:859:5 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#13 isc_task_run lib/isc/task.c:953:10
#14 process_netievent lib/isc/netmgr/netmgr.c (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#15 process_queue lib/isc/netmgr/netmgr.c:1009:8 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#16 process_all_queues lib/isc/netmgr/netmgr.c:790:25 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#17 async_cb lib/isc/netmgr/netmgr.c:819:6
#18 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163:5 (BuildId: 120c450d14885aa5308bc95c4ea77de2c2b1cc36)
#19 isc__trampoline_run lib/isc/trampoline.c:213:11 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
Mutex M2 (0x000000000037) created at:
#0 pthread_rwlock_init <null> (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#1 isc_rwlock_init lib/isc/rwlock.c:41:2 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#2 dns_rbtdb_create lib/dns/rbtdb.c:8656:2 (BuildId: fcbd6258d04361cb62bc32ccf87eff93722e9925)
#3 dns_db_create lib/dns/db.c:120:13 (BuildId: fcbd6258d04361cb62bc32ccf87eff93722e9925)
#4 zone_load lib/dns/zone.c:2307:11 (BuildId: fcbd6258d04361cb62bc32ccf87eff93722e9925)
#5 dns_zone_load lib/dns/zone.c:2380:10 (BuildId: fcbd6258d04361cb62bc32ccf87eff93722e9925)
#6 load_zones bin/named/./server.c:9754:13 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#7 named_server_reconfigcommand bin/named/./server.c:10726:11 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#8 named_control_docommand bin/named/control.c:252:12 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#9 control_recvmessage bin/named/controlconf.c:477:13 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#10 task_run lib/isc/task.c:859:5 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#11 isc_task_run lib/isc/task.c:953:10
#12 process_netievent lib/isc/netmgr/netmgr.c (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#13 process_queue lib/isc/netmgr/netmgr.c:1009:8 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#14 process_all_queues lib/isc/netmgr/netmgr.c:790:25 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#15 async_cb lib/isc/netmgr/netmgr.c:819:6
#16 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163:5 (BuildId: 120c450d14885aa5308bc95c4ea77de2c2b1cc36)
#17 isc__trampoline_run lib/isc/trampoline.c:213:11 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
Thread T1 (running) created by main thread at:
#0 pthread_create <null> (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#1 isc_thread_create lib/isc/pthreads/thread.c:81:8 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:355:3 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#3 isc_managers_create lib/isc/managers.c:28:2 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#4 create_managers bin/named/./main.c:1065:11 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#5 setup bin/named/./main.c:1397:11
#6 main bin/named/./main.c:1711:2
Thread T2 (running) created by main thread at:
#0 pthread_create <null> (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#1 isc_thread_create lib/isc/pthreads/thread.c:81:8 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:355:3 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#3 isc_managers_create lib/isc/managers.c:28:2 (BuildId: 6899e3b78cd26e2e0be1758888e5b949c65bdb33)
#4 create_managers bin/named/./main.c:1065:11 (BuildId: dbafb0d25d480c1049a7bd687a3c53a6f4aeace4)
#5 setup bin/named/./main.c:1397:11
#6 main bin/named/./main.c:1711:2
SUMMARY: ThreadSanitizer: data race lib/dns/zone.c:4127:26 in set_refreshkeytimer
```
July 2023 (9.18.17, 9.18.17-S1, 9.19.15)
Tony Finch
Tony Finch
https://gitlab.isc.org/isc-projects/bind9/-/issues/3648
Memory leak in authoritative-only servers
2023-10-30T14:48:40Z
Greg Choules
Memory leak in authoritative-only servers
A customer has reported that some very busy primary/secondary servers have increasing memory usage and decreasing performance over a period of several days, ultimately resulting in the servers crashing and needing to be restarted. The ve...
A customer has reported that some very busy primary/secondary servers have increasing memory usage and decreasing performance over a period of several days, ultimately resulting in the servers crashing and needing to be restarted. The version in use is 9.16.30.
https://gitlab.isc.org/isc-projects/bind9/-/issues/3123
v9.16 test failure in Perflab: uv_udp_init_ex() errors out
2022-02-02T08:12:15Z
Petr Špaček
pspacek@isc.org
v9.16 test failure in Perflab: uv_udp_init_ex() errors out
Version
=======
~"Affects v9.16" : Since isc-projects/bind9!5717 was merged.
Symptom
=======
Perflab test config LTT/v9_16/recursive/NXD-medium/dnsgen started failing.
`named` errors out before the test even starts with message:
```
ud...
Version
=======
~"Affects v9.16" : Since isc-projects/bind9!5717 was merged.
Symptom
=======
Perflab test config LTT/v9_16/recursive/NXD-medium/dnsgen started failing.
`named` errors out before the test even starts with message:
```
udp.c:226: fatal error: RUNTIME_CHECK(r == 0) failed
```
Example of an affected run:
https://perflab.isc.org/#/run/test/61f911b58d88f33170df08b6/
Additional info
===============
Surprisingly, other test configurations do not seem to be affected, not even on v9_16 branch.
In any case, this is very suspicious and needs investigation ASAP before we tag %"February 2022 (9.16.26, 9.16.26-S1)". It stopped working during this monthly cycle so if it is a bug then it is a regression.
February 2022 (9.16.26, 9.16.26-S1)
https://gitlab.isc.org/isc-projects/bind9/-/issues/3104
Add latest DNS RFCs to doc/arm/general.rst
2022-01-19T18:10:17Z
Suzanne Goldlust
Add latest DNS RFCs to doc/arm/general.rst
Some new RFCs have been published (and listed on https://www.isc.org/rfcs/), but they haven't been added to the ARM list yet.
Some new RFCs have been published (and listed on https://www.isc.org/rfcs/), but they haven't been added to the ARM list yet.
https://gitlab.isc.org/isc-projects/bind9/-/issues/3086
Remove workaround for server mishandling NOTIFY with SOA record in ANSWER sec...
2022-01-21T07:21:06Z
Ondřej Surý
Remove workaround for server mishandling NOTIFY with SOA record in ANSWER section
In d39e56173d65178cdb2eb1cf31f9293c507cb139, a workaround was added to retry sending `NOTIFY` without `SOA` record when the peer would return `FORMERR`. This is no longer needed.
In d39e56173d65178cdb2eb1cf31f9293c507cb139, a workaround was added to retry sending `NOTIFY` without `SOA` record when the peer would return `FORMERR`. This is no longer needed.
January 2022 (9.18.0)
Ondřej Surý
Ondřej Surý