BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-01-02T15:27:20Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4504named generates core and ends with signal SIGFPE, Arithmetic exception.2024-01-02T15:27:20Zsagar sagarnamed 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/4235Flamethrower instance #3 stops querying BIND in RPZ mode2024-01-22T16:24:31ZMichal NowakFlamethrower instance #3 stops querying BIND in RPZ modeJob [#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 plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4135Data race lib/dns/zone.c:4127:26 in set_refreshkeytimer2023-12-08T07:49:51ZMichal NowakData race lib/dns/zone.c:4127:26 in set_refreshkeytimerJob [#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 FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3648Memory leak in authoritative-only servers2023-10-30T14:48:40ZGreg ChoulesMemory leak in authoritative-only serversA 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/3123v9.16 test failure in Perflab: uv_udp_init_ex() errors out2022-02-02T08:12:15ZPetr Špačekpspacek@isc.orgv9.16 test failure in Perflab: uv_udp_init_ex() errors outVersion
=======
~"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/3104Add latest DNS RFCs to doc/arm/general.rst2022-01-19T18:10:17ZSuzanne GoldlustAdd latest DNS RFCs to doc/arm/general.rstSome 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/3086Remove workaround for server mishandling NOTIFY with SOA record in ANSWER sec...2022-01-21T07:21:06ZOndřej SurýRemove workaround for server mishandling NOTIFY with SOA record in ANSWER sectionIn 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ýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2993Replace instances of ARRAYSIZE with ARRAY_SIZE2021-11-02T15:03:50ZMark AndrewsReplace instances of ARRAYSIZE with ARRAY_SIZEARRAY_SIZE is defined in isc/util.h if not already defined by the host systemARRAY_SIZE is defined in isc/util.h if not already defined by the host systemNovember 2021 (9.16.23, 9.16.23-S1, 9.17.20)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2956Change default for nsec3param to iterations 0 salt-length 02022-06-14T07:08:43ZMatthijs Mekkingmatthijs@isc.orgChange default for nsec3param to iterations 0 salt-length 0Following the guidance given in https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec3-guidance/
```
In short, for all zones, the recommended NSEC3 parameters are as
shown below:
; SHA-1, no extra iterations, empty salt:
;...Following the guidance given in https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec3-guidance/
```
In short, for all zones, the recommended NSEC3 parameters are as
shown below:
; SHA-1, no extra iterations, empty salt:
;
bcp.example. IN NSEC3PARAM 1 0 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/2952Remove manual branch prediction using __builtin_expect()2021-10-27T11:44:50ZOndřej SurýRemove manual branch prediction using __builtin_expect()A recent [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5476#note_241185) on a MR has sparkled interesting question: Are the software developers better at guessing which branch is more likely to happen and does i...A recent [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5476#note_241185) on a MR has sparkled interesting question: Are the software developers better at guessing which branch is more likely to happen and does it help with performance? The GCC documentation on [`__builtin_expect()`](https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fexpect) says:
> In general, you should prefer to use actual profile feedback for this (`-fprofile-arcs`), as programmers are notoriously bad at predicting how their programs actually perform. However, there are applications in which this data is hard to collect.
Turns out that the documentation was right, we are notoriously bad at predicting how our program actually perform.
In the authoritative scenarios in the perflab, the (lo-hi from the last 15) results are:
| Scenario | `main` | no-expect. |
| --- | --- | --- |
| 1k zones. | 991,710 - 1,001,476 | 985,835 - 992,007 |
| 1M delegations | 918,952 - 943,186 | 953,149 - 969,046 |
| 1M RRs | 946,390 - 973,202 | 966,150 - 993,660 |
| 1M zones | 963,561 - 991,627 | 984,624 - 998,857 |
| root zone | 427,566 - 469,889 | 460,026 - 473,576 |
In the recursive scenarios, the branch with disabled `__builtin_expect()` surpases the `main` branch:
![_allruns-latency-since_30-until_60](/uploads/dcbc799e6a7e2dd2e0f2b495e7deae2a/_allruns-latency-since_30-until_60.png)
![_allruns-latency-since_30-until_60](/uploads/52914286ee3aa75db15694c06c2d7c24/_allruns-latency-since_30-until_60.png)November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2941Implement alternative to all-at-once rehashing for real-time hash tables2022-03-15T20:59:39ZOndřej SurýImplement alternative to all-at-once rehashing for real-time hash tablesThe all-at-once rehashing becomes very costly when the hash tables grow large. The rehashing operation on a busy resolver with a large cache could disrupt resolving even for a couple of seconds. Implement incremental rehashing (as the ...The all-at-once rehashing becomes very costly when the hash tables grow large. The rehashing operation on a busy resolver with a large cache could disrupt resolving even for a couple of seconds. Implement incremental rehashing (as the linear rehashing seems too complex for our purpose) for hot-path hash tables (RBT mostly).November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2929Replace more "master" and "slave" keywords2021-10-27T11:25:17ZPeter DaviesReplace more "master" and "slave" keywordsThe following error message from the ```rndc freeze``` command:
```rndc: 'freeze' failed: not master```
It may be preferable to use the term ```primary```.
There are other instances in code and in the rndc man page.The following error message from the ```rndc freeze``` command:
```rndc: 'freeze' failed: not master```
It may be preferable to use the term ```primary```.
There are other instances in code and in the rndc man page.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/2927lame servers with IPv6 unreachable make dispatch@netmgr stuck on shutdown2022-01-26T11:33:41ZOndřej Surýlame servers with IPv6 unreachable make dispatch@netmgr stuck on shutdownSo, I narrowed it down to a single query:
```
dig -p 5300 IN A mail.lab.comcor.ru. @10.10.10.20
```
which goes like this:
```
04-Oct-2021 09:25:59.507 resolver priming query complete
04-Oct-2021 09:26:16.119 network unreachable resolvi...So, I narrowed it down to a single query:
```
dig -p 5300 IN A mail.lab.comcor.ru. @10.10.10.20
```
which goes like this:
```
04-Oct-2021 09:25:59.507 resolver priming query complete
04-Oct-2021 09:26:16.119 network unreachable resolving '_.ru/A/IN': 2001:500:2f::f#53
04-Oct-2021 09:26:16.119 network unreachable resolving '_.ru/A/IN': 2001:500:12::d0d#53
04-Oct-2021 09:26:16.135 network unreachable resolving '_.comcor.ru/A/IN': 2001:678:15:0:193:232:142:17#53
04-Oct-2021 09:26:16.135 network unreachable resolving '_.comcor.ru/A/IN': 2001:678:18:0:194:190:124:17#53
04-Oct-2021 09:26:16.135 network unreachable resolving '_.comcor.ru/A/IN': 2001:678:17:0:193:232:128:6#53
04-Oct-2021 09:26:16.135 network unreachable resolving '_.comcor.ru/A/IN': 2001:678:16:0:194:85:252:62#53
04-Oct-2021 09:26:16.135 network unreachable resolving '_.comcor.ru/A/IN': 2001:678:14:0:193:232:156:17#53
04-Oct-2021 09:26:16.143 network unreachable resolving '_.lab.comcor.ru/A/IN': 2a02:290:0:2::5#53
04-Oct-2021 09:26:16.143 network unreachable resolving '_.lab.comcor.ru/A/IN': 2a02:290:0:1::4#53
04-Oct-2021 09:26:16.203 network unreachable resolving 'ns.lab.comcor.ru/AAAA/IN': 2001:678:17:0:193:232:128:6#53
04-Oct-2021 09:26:16.207 network unreachable resolving 'ns.lab.comcor.ru/AAAA/IN': 2001:678:18:0:194:190:124:17#53
04-Oct-2021 09:26:16.207 network unreachable resolving 'ns.lab.comcor.ru/AAAA/IN': 2001:678:16:0:194:85:252:62#53
04-Oct-2021 09:26:16.251 lame server resolving 'mail.lab.comcor.ru' (in 'lab.COMCOR.ru'?): 212.45.0.3#53
04-Oct-2021 09:26:16.335 network unreachable resolving 'ns.lab.comcor.ru/AAAA/IN': 2a02:290:0:2::5#53
04-Oct-2021 09:26:16.443 lame server resolving 'ns.lab.comcor.ru' (in 'lab.COMCOR.ru'?): 212.45.0.3#53
```
You also need to have broken IPv6 :-), it doesn't happen when I run `named -4`.
#### Edited ####
This is caused by the new dispatch code:
1. Start `named -p 5300 -g -c /dev/null`
2. Start `dnsperf -s 127.0.0.1 -p 5300 -D -d queryfile-example-10million-201202`
3. Press Ctrl-C
4. `named` doesn't stop:
```
$ eu-stack -p $(pidof named)
PID 275694 - process
TID 275694:
#0 0x00007f4b7bac9c61 clock_nanosleep@@GLIBC_2.17
#1 0x00007f4b7bacf443 __nanosleep
#2 0x00007f4b7bafa125 usleep
#3 0x00007f4b7c476f19 isc__taskmgr_destroy
#4 0x00007f4b7c45b994 isc_managers_destroy
#5 0x0000564d877b86cf destroy_managers
#6 0x0000564d877b86da cleanup
#7 0x0000564d877ba041 main
#8 0x00007f4b7ba2ad0a __libc_start_main
#9 0x0000564d877ae9ca _start
TID 275708:
#0 0x00007f4b7bb02116 epoll_wait
#1 0x00007f4b7be18b3f uv__io_poll
#2 0x00007f4b7be07714 uv_run
#3 0x00007f4b7c43c33e nm_thread
#4 0x00007f4b7c47ce50 isc__trampoline_run
#5 0x00007f4b7bbd1ea7 start_thread
#6 0x00007f4b7bb01def __clone
TID 275709:
#0 0x00007f4b7bbd8ad8 pthread_cond_timedwait@@GLIBC_2.3.2
#1 0x00007f4b7c44f081 isc_condition_waituntil
#2 0x00007f4b7c479dab run
#3 0x00007f4b7c47ce50 isc__trampoline_run
#4 0x00007f4b7bbd1ea7 start_thread
#5 0x00007f4b7bb01def __clone
TID 275710:
#0 0x00007f4b7bb02116 epoll_wait
#1 0x00007f4b7c46f6f2 netthread
#2 0x00007f4b7c47ce50 isc__trampoline_run
#3 0x00007f4b7bbd1ea7 start_thread
#4 0x00007f4b7bb01def __clone
```
+1 we are obviously missing a system test for this kind of scenario.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2916duplicate catalog-zones is fatal2021-10-27T13:24:11ZMark Andrewsduplicate catalog-zones is fatal```
options {
port 5300;
catalog-zones { zone example.com; zone example.com; };
};
zone example.com {
type primary;
file "example.com";
};
``````
options {
port 5300;
catalog-zones { zone example.com; zone example.com; };
};
zone example.com {
type primary;
file "example.com";
};
```November 2021 (9.16.23, 9.16.23-S1, 9.17.20)https://gitlab.isc.org/isc-projects/bind9/-/issues/2905autoconf check for struct stat pulls in fcntl.h not stat.h2021-10-27T11:32:33ZStuart Hendersonautoconf check for struct stat pulls in fcntl.h not stat.hhttps://gitlab.isc.org/isc-projects/bind9/-/blob/main/configure.ac#L1079 includes sys/fcntl.h when checking struct stat members to determine if nanoseconds are available. At least on OpenBSD and raspbian this is in stat.h which is not pu...https://gitlab.isc.org/isc-projects/bind9/-/blob/main/configure.ac#L1079 includes sys/fcntl.h when checking struct stat members to determine if nanoseconds are available. At least on OpenBSD and raspbian this is in stat.h which is not pulled in by fcntl.h so the test always fails.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)https://gitlab.isc.org/isc-projects/bind9/-/issues/2843EC_KEY has been deprecated on OpenSSL 3.0.02022-01-19T11:20:50ZMark AndrewsEC_KEY has been deprecated on OpenSSL 3.0.0Need to workout what the replacement code needs to be as builds fail on strict systems.Need to workout what the replacement code needs to be as builds fail on strict systems.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2792memory trace (-m trace) overhaul2022-12-12T08:58:02ZBrian Conrymemory trace (-m trace) overhaulIn BIND there are as many as three different layers of memory management, including libc. Proper memory account and tracing will need to be able to track any allocation through all of those layers, including how the size and returned ad...In BIND there are as many as three different layers of memory management, including libc. Proper memory account and tracing will need to be able to track any allocation through all of those layers, including how the size and returned address may change through those transitions.
Original issue statement
> When `isc__mem_allocate` calls `ADD_TRACE` it uses a combination of pointer address `si` and size `si[-1].size` that is inconsistent.
>
> Specifically, the size reported (`si[-1].size`) has been modified from what was requested by `ALIGNMENT_SIZE` at least once (and `ISC_UNLIKELY` a second time) while the pointer reported (`si`) is offset from the actual base of the allocation by the same amount.
>
> This will lead to confusing `-m trace` entries such as:
> ```
> add 0x7f8f6240f018 size 104 file task.c line 1400 mctx 0x55a572544320
> ...
> add 0x7f8f6240f078 size 104 file hash.c line 159 mctx 0x55a572544320
> ```
>
> A sharp-eyed reader may notice that there are only 96 bytes between the two reported addresses even though the size reported is 104 bytes.
>
> This is only a "cosmetic error" in the `-m trace` output, so it's automatically low priority.
>
> I discovered this in 9.11 and have verified it still exists in both 9.16 and 9.17.
Edit: the merge of jemalloc support in 9.17.17 has changed things, requiring an update to all of these diagrams - consider them to be obsolete unless the comment containing them explicitly mentions being updated for 9.17.17https://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/1631kasp system test failed (bad number of keys)2022-04-28T19:13:15ZMichał Kępieńkasp system test failed (bad number of keys)https://gitlab.isc.org/isc-projects/bind9/-/jobs/700050
```
I:kasp:check number of keys with algorithm 5 for zone legacy-keys.kasp in dir ns3 (56)
I:kasp:error: bad number (2) of key files for zone legacy-keys.kasp (expected 3)
I:kasp:f...https://gitlab.isc.org/isc-projects/bind9/-/jobs/700050
```
I:kasp:check number of keys with algorithm 5 for zone legacy-keys.kasp in dir ns3 (56)
I:kasp:error: bad number (2) of key files for zone legacy-keys.kasp (expected 3)
I:kasp:failed
I:kasp:check key 24906
I:kasp:check key 38941
I:kasp:error: No KEY2 found for zone legacy-keys.kasp
I:kasp:failed
I:kasp:check DNSKEY rrset is signed correctly for zone legacy-keys.kasp (57)
I:kasp:check SOA rrset is signed correctly for zone legacy-keys.kasp (58)
I:kasp:error: SOA RRset not signed with key no
I:kasp:failed
I:kasp:check CDS and CDNSKEY rrset are signed correctly for zone legacy-keys.kasp (59)
I:kasp:check A a.legacy-keys.kasp rrset is signed correctly for zone legacy-keys.kasp (60)
I:kasp:error: A RRset not signed with key no
I:kasp:failed
```BIND 9.17 Backburnerhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1610dig: Incorrect encoding to punycode2022-04-26T13:22:14ZGhost Userdig: Incorrect encoding to punycode### Summary
Incorrect/invalid output when trying to encode the domain: ☺.unicode.
It appears the punycode encoder generates a domain label that includes a space. Several punycode generators do this, including dnspython and Python's ...### Summary
Incorrect/invalid output when trying to encode the domain: ☺.unicode.
It appears the punycode encoder generates a domain label that includes a space. Several punycode generators do this, including dnspython and Python's IDNA encoding built-in.
This came up while performing testing ahead of migrating towards a new system of handling DNS records which uses Python, however, we've subsequently identified that it affects dig as well.
### BIND version used
9.11.5-P4-5.1-Debian (From Debian Buster)
### Steps to reproduce
```
$ dig ☺.unicode
```
### What is the current *bug* behavior?
```
dig: 'xn--\032o-oia59s.unicode.' is not a legal IDNA2008 name (string contains a disallowed character), use +noidnout
```
### What is the expected *correct* behavior?
I'd expect dig to look up the A record for the correctly encoded domain.
I'm not sure what the correctly encoded domain is, although my suspicion is that it should be xn--xba3f15e.unicode.
### Relevant configuration files
Not sure that any config files are actually relevant - if there are, please let me know.December 2021 (9.16.24, 9.16.24-S1, 9.17.21)