BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-02-28T06:53:58Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4609ADB memory growth in 9.192024-02-28T06:53:58ZOndřej SurýADB memory growth in 9.19During the 25h test, it was discovered that ADB and main memory contextx grows suspiciously:
![bindstats.memory.contexts.ADB._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1-9.19](/uploads/5e5f039e83e4a892554001b6c7348e92/bindstats....During the 25h test, it was discovered that ADB and main memory contextx grows suspiciously:
![bindstats.memory.contexts.ADB._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1-9.19](/uploads/5e5f039e83e4a892554001b6c7348e92/bindstats.memory.contexts.ADB._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1-9.19.png)
![bindstats.memory.contexts.main._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1-main-9.19](/uploads/bad7883a65948bfd2946b84fe6505cdf/bindstats.memory.contexts.main._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1-main-9.19.png)
The growth is much slower in 9.18:
![bindstats.memory.contexts.ADB._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1](/uploads/4cc202485a129130ecd978cf23ad452a/bindstats.memory.contexts.ADB._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1.png)May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4607chain system test: mem.c:1311: INSIST(unreachable) failed2024-03-18T08:53:51ZMichal Nowakchain system test: mem.c:1311: INSIST(unreachable) failedJob [#4071483](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4071483) failed for f42a441b05408f4e816ea44a4780667a00c5fb86.
ns1 of the `chain` system test ended up in a bad place.
```
context: 0x7b3000001b00 (zonemgr-mctxpoo): 2 refe...Job [#4071483](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4071483) failed for f42a441b05408f4e816ea44a4780667a00c5fb86.
ns1 of the `chain` system test ended up in a bad place.
```
context: 0x7b3000001b00 (zonemgr-mctxpoo): 2 references
Dump of all outstanding memory allocations:
ptr 0x7b5000020200 size 496 file rbtdb.c line 3866
ptr 0x7b6000001000 size 1016 file rbt-zonedb.c line 2091
mem.c:1311: INSIST(unreachable) failed
```
```
2024-02-27 17:50:11 INFO:chain D:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D chain_tmp_qm1vyy5o-ns1 -m r'.
2024-02-27 17:50:11 INFO:chain D:Program terminated with signal SIGABRT, Aborted.
2024-02-27 17:50:11 INFO:chain D:#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
2024-02-27 17:50:11 INFO:chain D:Downloading source file /usr/src/debug/glibc-2.38-16.fc39.x86_64/nptl/pthread_kill.c...
2024-02-27 17:50:11 INFO:chain D:44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;
2024-02-27 17:50:11 INFO:chain D:[Current thread is 1 (Thread 0x7f96faa8a380 (LWP 77097))]
2024-02-27 17:50:11 INFO:chain D:#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
2024-02-27 17:50:11 INFO:chain D:#1 0x00007f96fb0ed8a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
2024-02-27 17:50:11 INFO:chain D:#2 0x00007f96fb09b8ee in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
2024-02-27 17:50:11 INFO:chain D:#3 0x00007f96fb0838ff in __GI_abort () at abort.c:79
2024-02-27 17:50:11 INFO:chain D:#4 0x00007f96fc0bee3c in __interceptor_abort (fake=-89613312) at ../../../../libsanitizer/tsan/tsan_interceptors_posix.cpp:1875
2024-02-27 17:50:11 INFO:chain D:#5 0x0000000000427e49 in assertion_failed (file=<optimized out>, line=1311, type=<optimized out>, cond=0x7f96fc065ac3 "unreachable") at main.c:234
2024-02-27 17:50:11 INFO:chain D:#6 0x00007f96fc00b194 in isc_assertion_failed (file=file@entry=0x7f96fc0624cb "mem.c", line=line@entry=1311, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7f96fc065ac3 "unreachable") at assertions.c:48
2024-02-27 17:50:11 INFO:chain D:#7 0x00007f96fc02f45f in isc__mem_checkdestroyed () at mem.c:1311
2024-02-27 17:50:11 INFO:chain D:#8 0x00007f96fc02f54c in mem_shutdown () at mem.c:442
2024-02-27 17:50:11 INFO:chain D:#9 0x00007f96fc0da084 in __interceptor_pthread_once (o=o@entry=0x7f96fc07dec8 <shut_once>, f=f@entry=0x7f96fc02f533 <mem_shutdown>) at ../../../../libsanitizer/tsan/tsan_interceptors_posix.cpp:1551
2024-02-27 17:50:11 INFO:chain D:#10 0x00007f96fc02ce7e in isc__mem_shutdown () at mem.c:455
2024-02-27 17:50:11 INFO:chain D:#11 0x00007f96fc023088 in isc__shutdown () at lib.c:67
2024-02-27 17:50:11 INFO:chain D:#12 0x00007f96fd0ec0f2 in _dl_call_fini (closure_map=closure_map@entry=0x7f96fd0e98d0) at dl-call_fini.c:43
2024-02-27 17:50:11 INFO:chain D:#13 0x00007f96fd0f006e in _dl_fini () at dl-fini.c:114
2024-02-27 17:50:11 INFO:chain D:#14 0x00007f96fb09dfd6 in __run_exit_handlers (status=0, listp=<optimized out>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:111
2024-02-27 17:50:11 INFO:chain D:#15 0x00007f96fb09e11e in __GI_exit (status=<optimized out>) at exit.c:141
2024-02-27 17:50:11 INFO:chain D:#16 0x00007f96fb085151 in __libc_start_call_main (main=main@entry=0x429913 <main>, argc=argc@entry=12, argv=argv@entry=0x7ffe1fcbda88) at ../sysdeps/nptl/libc_start_call_main.h:74
2024-02-27 17:50:11 INFO:chain D:#17 0x00007f96fb08520b in __libc_start_main_impl (main=0x429913 <main>, argc=12, argv=0x7ffe1fcbda88, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe1fcbda78) at ../csu/libc-start.c:360
2024-02-27 17:50:11 INFO:chain D:#18 0x0000000000418d35 in _start ()
```
[core.77097-backtrace.txt](/uploads/dfe2e0c9ee3a48df96c87773f2674a12/core.77097-backtrace.txt)
[core.77097.gz](/uploads/6a868166ed706bec348e2930ddc5fa5c/core.77097.gz)
[named.run](/uploads/ef60bc0ac117defd99c6f3c831f99368/named.run)May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4593Deprecate sortlist2024-03-06T18:18:23ZMichal NowakDeprecate sortlistThe following discussion from !8684 should be addressed:
- [ ] @pspacek started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8684#note_433409): (+1 comment)
> Can we also deprecate the feature? It's su...The following discussion from !8684 should be addressed:
- [ ] @pspacek started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8684#note_433409): (+1 comment)
> Can we also deprecate the feature? It's such an obscure thing ...
- @ondrej commented:
> That would be 9.21+May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4581CID 486476: Memory - corruptions (OVERRUN) in lib/dns/resconf.c2024-02-24T07:55:23ZMichal NowakCID 486476: Memory - corruptions (OVERRUN) in lib/dns/resconf.cAfter 371defc35753d04fa8b769b8c859630c3a76e9ed, Coverity Scan claims memory corruption in `lib/dns/resconf.c`:
```cpp
/lib/dns/resconf.c: 246 in add_server()
240
241 /* XXX: special case: treat all-0 IPv4 address as loopback *...After 371defc35753d04fa8b769b8c859630c3a76e9ed, Coverity Scan claims memory corruption in `lib/dns/resconf.c`:
```cpp
/lib/dns/resconf.c: 246 in add_server()
240
241 /* XXX: special case: treat all-0 IPv4 address as loopback */
242 v4 = &((struct sockaddr_in *)res->ai_addr)->sin_addr;
243 if (memcmp(v4, zeroaddress, 4) == 0) {
244 memmove(v4, loopaddress, 4);
245 }
>>> CID 486476: Memory - corruptions (OVERRUN)
>>> Overrunning struct type sockaddr_in of 16 bytes by passing it to a function which accesses it at byte offset 27 using argument "res->ai_addrlen" (which evaluates to 28). [Note: The source code implementation of the function has been overridden by a builtin model.]
246 memmove(&address->type.sin, res->ai_addr, res->ai_addrlen);
247 } else if (res->ai_family == AF_INET6) {
248 memmove(&address->type.sin6, res->ai_addr, res->ai_addrlen);
249 } else {
250 isc_mem_put(mctx, address, sizeof(*address));
251 UNEXPECTED_ERROR("ai_family (%d) not INET nor INET6",
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4543Re-enable unreachable checks in dnssec system test2024-02-24T07:55:26ZTom KrizekRe-enable unreachable checks in dnssec system testIn https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8085, a premature [exit statement](https://gitlab.isc.org/isc-projects/bind9/-/blob/b54bdf8d78666d8dcc6d4e1ad74c4af0a130e1a8/bin/tests/system/dnssec/tests.sh#L3711) has been a...In https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8085, a premature [exit statement](https://gitlab.isc.org/isc-projects/bind9/-/blob/b54bdf8d78666d8dcc6d4e1ad74c4af0a130e1a8/bin/tests/system/dnssec/tests.sh#L3711) has been accidentally added to the `dnssec` test, making the remaining checks unreachable.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4502Missing reference?2024-02-24T07:53:00ZMark AndrewsMissing reference?Job [#3894124](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3894124) failed for c56a0ce25353ac1d4a8226d72373e3d7fb4c4c10:
```
2023-12-21 02:40:08 INFO:catz I:catz_tmp_8975m3uv:ns4 crashed on shutdown
2023-12-21 02:40:08 ERROR:cat...Job [#3894124](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3894124) failed for c56a0ce25353ac1d4a8226d72373e3d7fb4c4c10:
```
2023-12-21 02:40:08 INFO:catz I:catz_tmp_8975m3uv:ns4 crashed on shutdown
2023-12-21 02:40:08 ERROR:catz Failed to stop servers
2023-12-21 02:40:08 INFO:catz I:catz_tmp_8975m3uv:Core dump(s) found: /builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv/ns4/core.56121
2023-12-21 02:40:08 INFO:catz D:catz_tmp_8975m3uv:backtrace from /builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv/ns4/core.56121:
2023-12-21 02:40:08 INFO:catz D:catz_tmp_8975m3uv:--------------------------------------------------------------------------------
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/lt-named -D catz_tmp_8975m3uv-ns4 -m'.
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:Program terminated with signal SIGABRT, Aborted.
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#0 0x00007ff5cd7dfb8f in raise () from /lib64/libc.so.6
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:[Current thread is 1 (Thread 0x7ff5b1dff700 (LWP 56142))]
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#0 0x00007ff5cd7dfb8f in raise () from /lib64/libc.so.6
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#1 0x00007ff5cd7b2ea5 in abort () from /lib64/libc.so.6
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#2 0x0000000000422b8a in assertion_failed (file=0x7ff5d17eda82 "view.c", line=427, type=isc_assertiontype_insist, cond=0x7ff5d17c47c0 "__v > 0 && __v < (4294967295U)") at main.c:234
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#3 0x00007ff5d1c35f9d in isc_assertion_failed (file=file@entry=0x7ff5d17eda82 "view.c", line=line@entry=427, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7ff5d17c47c0 "__v > 0 && __v < (4294967295U)") at assertions.c:48
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#4 0x00007ff5d176d241 in dns_view_attach (source=source@entry=0x7ff5ca3c0c00, targetp=targetp@entry=0x7ff5afa051f8) at view.c:429
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#5 0x000000000042b579 in catz_run (entry=0x7ff5b803f0c0, origin=origin@entry=0x7ff5ca20c540, view=0x7ff5ca3c0c00, udata=0x680608 <ns_catz_cbdata>, type=type@entry=CATZ_DELZONE) at server.c:2957
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#6 0x000000000042b5d2 in catz_delzone (entry=<optimized out>, origin=origin@entry=0x7ff5ca20c540, view=<optimized out>, udata=<optimized out>) at server.c:2973
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#7 0x00007ff5d1644645 in dns__catz_zones_merge (catz=0x7ff5ca20c540, newcatz=0x7ff5afa17000) at catz.c:696
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#8 0x00007ff5d1647be0 in dns__catz_update_cb (data=<optimized out>) at catz.c:2481
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#9 0x00007ff5d1c6316a in isc__work_cb (req=<optimized out>) at work.c:30
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#10 0x00007ff5cf6244ee in worker () from /lib64/libuv.so.1
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#11 0x00007ff5ce4f71da in start_thread () from /lib64/libpthread.so.0
2023-12-21 02:40:09 INFO:catz D:/builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv:#12 0x00007ff5cd7cae73 in clone () from /lib64/libc.so.6
2023-12-21 02:40:09 INFO:catz D:catz_tmp_8975m3uv:--------------------------------------------------------------------------------
2023-12-21 02:40:09 INFO:catz D:catz_tmp_8975m3uv:full backtrace from /builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv/ns4/core.56121 saved in /builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv/ns4/core.56121-backtrace.txt
2023-12-21 02:40:10 INFO:catz D:catz_tmp_8975m3uv:core dump /builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv/ns4/core.56121 archived as /builds/isc-projects/bind9/bin/tests/system/catz_tmp_8975m3uv/ns4/core.56121.gz
2023-12-21 02:40:11 INFO:catz I:catz_tmp_8975m3uv:1 assertion failure(s) found
2023-12-21 02:40:11 ERROR:catz Found core dumps or sanitizer reports
2023-12-21 02:40:11 INFO:catz test artifacts in: catz_sh_catz
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4469Follow-up from "Resolve "Crash on shutdown when DNSSEC validation is running:...2024-02-24T07:53:03ZMark AndrewsFollow-up from "Resolve "Crash on shutdown when DNSSEC validation is running: ENSURE(isc_mempool_getallocated(*namepoolp) == 0) failed""The following discussion from !8526 should be addressed:
- [ ] @pspacek started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8526#note_420948): (+1 comment)
> Now the hard question: Was this caused by ...The following discussion from !8526 should be addressed:
- [ ] @pspacek started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8526#note_420948): (+1 comment)
> Now the hard question: Was this caused by some recent change in the mempool usage? @ondrej?
>
> If so, can we have, say, a Cocinelle check for the correct order of operations? Chasing down these shutdown issues one by one is nightmare and consumes QA time, so if we can have an automated check I'm all for it.
>
> If an automated check is not feasible please could you manually check places affected by (presumed) recent changes to see if there are other place with similar bugs?
>
> Thank you!May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4434dispatch unit test is unstable2024-03-28T14:42:25ZMichal Nowakdispatch unit test is unstableEven after #4392, we keep seeing failures of the `dispatch` unit test.
`dispatch_getnext`:
- https://gitlab.isc.org/isc-projects/bind9/-/issues/4392#note_415175
- https://gitlab.isc.org/isc-projects/bind9/-/issues/4392#note_416028
`dis...Even after #4392, we keep seeing failures of the `dispatch` unit test.
`dispatch_getnext`:
- https://gitlab.isc.org/isc-projects/bind9/-/issues/4392#note_415175
- https://gitlab.isc.org/isc-projects/bind9/-/issues/4392#note_416028
`dispatch_newtcp`: Job [#3799293](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3799293) failed for 25cfec4d2b7b2d33c041a8543ab7f21191e6241c.
```
[==========] Running 10 test(s).
[ RUN ] dispatch_gettcp
[ OK ] dispatch_gettcp
[ RUN ] dispatch_newtcp
[ OK ] dispatch_newtcp
[ RUN ] dispatch_timeout_udp_response
[ OK ] dispatch_timeout_udp_response
[ RUN ] dispatchset_create
[ OK ] dispatchset_create
[ RUN ] dispatchset_get
[ OK ] dispatchset_get
[ RUN ] dispatch_timeout_tcp_response
[ OK ] dispatch_timeout_tcp_response
[ RUN ] dispatch_timeout_tcp_connect
[ OK ] dispatch_timeout_tcp_connect
[ RUN ] dispatch_tcp_response
[ OK ] dispatch_tcp_response
[ RUN ] dispatch_tls_response
[ OK ] dispatch_tls_response
[ RUN ] dispatch_getnext
0x2 != 0
[ LINE ] --- dispatch_test.c:419: error: Failure!I:dispatch_test:Core dump found: ./core.23758
D:dispatch_test:backtrace from ./core.23758 start
warning: Can't open file anon_inode:[io_uring] which was expanded to anon_inode:[io_uring] during file-backed mapping note processing
warning: Can't open file anon_inode:[io_uring] which was expanded to anon_inode:[io_uring] during file-backed mapping note processing
warning: Can't open file anon_inode:[io_uring] which was expanded to anon_inode:[io_uring] during file-backed mapping note processing
warning: Can't open file anon_inode:[io_uring] which was expanded to anon_inode:[io_uring] during file-backed mapping note processing
[New LWP 23758]
[New LWP 23799]
[New LWP 23798]
[New LWP 24634]
Downloading separate debug info for /lib/x86_64-linux-gnu/libcmocka.so.0...
Downloading separate debug info for /lib/x86_64-linux-gnu/libuv.so.1...
Downloading separate debug info for /lib/x86_64-linux-gnu/libssl.so.3...
Downloading separate debug info for /lib/x86_64-linux-gnu/libcrypto.so.3...
Downloading separate debug info for /lib/x86_64-linux-gnu/libz.so.1...
Downloading separate debug info for /lib/x86_64-linux-gnu/libjson-c.so.5...
Downloading separate debug info for /lib/x86_64-linux-gnu/libnghttp2.so.14...
Downloading separate debug info for /lib/x86_64-linux-gnu/libxml2.so.2...
Downloading separate debug info for /lib/x86_64-linux-gnu/liburcu.so.8...
Downloading separate debug info for /root/.cache/debuginfod_client/be4446e17e11dc07dd007465b7e3008bc69f905a/debuginfo...
Downloading separate debug info for /lib/x86_64-linux-gnu/liburcu-common.so.8...
Downloading separate debug info for /lib/x86_64-linux-gnu/libgssapi_krb5.so.2...
Downloading separate debug info for /lib/x86_64-linux-gnu/libkrb5.so.3...
Downloading separate debug info for /lib/x86_64-linux-gnu/libmaxminddb.so.0...
Downloading separate debug info for /lib/x86_64-linux-gnu/libfstrm.so.0...
Downloading separate debug info for /lib/x86_64-linux-gnu/libprotobuf-c.so.1...
Downloading separate debug info for /lib/x86_64-linux-gnu/liblmdb.so.0...
Downloading separate debug info for /lib/x86_64-linux-gnu/liburcu-cds.so.8...
Downloading separate debug info for /lib/x86_64-linux-gnu/libicuuc.so.72...
Downloading separate debug info for /root/.cache/debuginfod_client/0bc79e91cbc31da5a4c73b10bff30734ec138da0/debuginfo...
Downloading separate debug info for /lib/x86_64-linux-gnu/liblzma.so.5...
Downloading separate debug info for /lib/x86_64-linux-gnu/libk5crypto.so.3...
Downloading separate debug info for /lib/x86_64-linux-gnu/libcom_err.so.2...
Downloading separate debug info for /lib/x86_64-linux-gnu/libkrb5support.so.0...
Downloading separate debug info for /lib/x86_64-linux-gnu/libkeyutils.so.1...
Downloading separate debug info for /lib/x86_64-linux-gnu/libicudata.so.72...
Downloading separate debug info for /lib/x86_64-linux-gnu/libstdc++.so.6...
Downloading separate debug info for /lib/x86_64-linux-gnu/libgcc_s.so.1...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/builds/isc-projects/bind9/tests/dns/.libs/dispatch_test'.
Program terminated with signal SIGABRT, Aborted.
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
Download failed: Invalid argument. Continuing without source file ./nptl/./nptl/pthread_kill.c.
44 ./nptl/pthread_kill.c: Inappropriate ioctl for device.
[Current thread is 1 (Thread 0x7f91a32d6b80 (LWP 23758))]
Thread 4 (LWP 24634):
#0 0x0000000000000000 in ?? ()
No symbol table info available.
Backtrace stopped: Cannot access memory at address 0x0
Thread 3 (Thread 0x7f91a304d680 (LWP 23798)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1 0x00007f91a55bcbf4 in futex (val3=0, uaddr2=0x0, timeout=0x0, val=-1, op=0, uaddr=0x557352879600) at ../include/urcu/futex.h:81
No locals.
#2 futex_async (timeout=0x0, uaddr2=0x0, val3=0, val=-1, op=0, uaddr=0x557352879600) at ../include/urcu/futex.h:113
ret = <optimized out>
ret = <optimized out>
#3 futex_wait (futex=futex@entry=0x557352879600) at ./src/workqueue.c:135
__func__ = "futex_wait"
#4 0x00007f91a55bd035 in workqueue_thread (arg=0x5573528795c0) at ./src/workqueue.c:246
cbs_tmp_n = <optimized out>
splice_ret = <optimized out>
cbs_tmp_head = {node = {next = 0x55735285fa40}, lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}}
cbs_tmp_tail = {p = 0x557352898e50}
cbs = <optimized out>
cbcount = <optimized out>
workqueue = 0x5573528795c0
rt = 0
__func__ = "workqueue_thread"
__PRETTY_FUNCTION__ = "workqueue_thread"
#5 0x00007f91a5ea63ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444
ret = <optimized out>
pd = <optimized out>
out = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140263530586416, -6319514938243892525, -808, 0, 140723762111680, 140263473598464, 6300488242360924883, 6300493485668219603}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#6 0x00007f91a5f26a4c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
No locals.
Thread 2 (Thread 0x7f91a284c680 (LWP 23799)):
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1 0x00007f91a626d3ad in futex (val3=0, uaddr2=0x0, timeout=0x0, val=-1, op=0, uaddr=0x557352852020) at ../include/urcu/futex.h:81
No locals.
#2 futex_noasync (timeout=0x0, uaddr2=0x0, val3=0, val=-1, op=0, uaddr=0x557352852020) at ../include/urcu/futex.h:90
ret = <optimized out>
ret = <optimized out>
#3 call_rcu_wait (crdp=0x557352851fe0) at ./src/urcu-call-rcu-impl.h:248
__func__ = "call_rcu_wait"
#4 call_rcu_thread (arg=0x557352851fe0) at ./src/urcu-call-rcu-impl.h:400
cbs_tmp_n = <optimized out>
splice_ret = <optimized out>
cbs_tmp_head = {node = {next = 0x55735287d778}, lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}}
cbs_tmp_tail = {p = 0x557352876df0}
cbs = <optimized out>
cbcount = <optimized out>
crdp = 0x557352851fe0
rt = 0
__func__ = "call_rcu_thread"
__PRETTY_FUNCTION__ = "call_rcu_thread"
#5 0x00007f91a5ea63ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444
ret = <optimized out>
pd = <optimized out>
out = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140263530586416, -6319514938243892525, -808, 115, 140723762111824, 140263465205760, 6300491538211453651, 6300493485668219603}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#6 0x00007f91a5f26a4c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
No locals.
Thread 1 (Thread 0x7f91a32d6b80 (LWP 23758)):
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
tid = <optimized out>
ret = 0
pd = <optimized out>
old_mask = {__val = {24576}}
ret = <optimized out>
#1 0x00007f91a5ea815f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
No locals.
#2 0x00007f91a5e5a472 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
ret = <optimized out>
#3 0x00007f91a5e444b2 in __GI_abort () at ./stdlib/abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, sa_mask = {__val = {93953797214704, 140263484650848, 4294934528, 7, 140263531945088, 7, 0, 12880216814053340279, 9278577283777313019, 6439199540737383679, 93953794348112, 140263536447415, 140263530288466, 8, 140263530288466, 0}}, sa_flags = 1373274116, sa_restorer = 0x1a3}
#4 0x00007f91a63b7f45 in exit_test (quit_application=1) at ./src/cmocka.c:404
env = 0x7ffccdda8a0a "1"
abort_test = <optimized out>
#5 0x00007f91a63b7fda in _fail (file=file@entry=0x557351da8004 "dispatch_test.c", line=line@entry=419) at ./src/cmocka.c:2196
output = <optimized out>
#6 0x00007f91a63ba0bf in _assert_int_equal (a=<optimized out>, b=b@entry=0, file=file@entry=0x557351da8004 "dispatch_test.c", line=line@entry=419) at ./src/cmocka.c:1800
No locals.
#7 0x0000557351da695a in response_getnext (result=<optimized out>, region=<optimized out>, arg=0x55735283e170) at dispatch_test.c:419
test = 0x55735283e170
#8 0x00007f91a60596e5 in udp_recv (handle=0x557352899450, eresult=ISC_R_TIMEDOUT, region=0x7ffccdda6bb0, arg=<optimized out>) at dispatch.c:618
resp = 0x557352898340
disp = <optimized out>
id = 0
dres = <optimized out>
source = {magic = 1384304336, base = 0x6e8, length = 1494, used = 0, current = 3453643520, active = 32764, extra = 1384304336, dynamic = 115, link = {prev = 0x7f91a64127d8 <add_trace_entry+296>, next = 0x8}, mctx = 0x1a800000000}
flags = 3453643280
peer = {type = {sa = {sa_family = 27408, sa_data = "\332\315\374\177\000\000\212GA\246\221\177\000"}, sin = {sin_family = 27408, sin_port = 52698, sin_addr = {s_addr = 32764}, sin_zero = "\212GA\246\221\177\000"}, sin6 = {sin6_family = 27408, sin6_port = 52698, sin6_flowinfo = 32764, sin6_addr = {__in6_u = {__u6_addr8 = "\212GA\246\221\177\000\000 k\332\315\374\177\000", __u6_addr16 = {18314, 42561, 32657, 0, 27424, 52698, 32764, 0}, __u6_addr32 = {2789296010, 32657, 3453643552, 32764}}}, sin6_scope_id = 1384603504}, ss = {ss_family = 27408, __ss_padding = "\332\315\374\177\000\000\212GA\246\221\177\000\000 k\332\315\374\177\000\000p_\207RsU\000\000p_\207RsU\000\000\240\255\264RsU\000\000\000\000\000\000\000\000\000\000`\232\203RsU\000\000`k\332\315\374\177\000\000\324EA\246\221\177\000\000@k\332\315\374\177\000\000{\240C\246\221\177\000\000\000\000\000\000\000\000\000\000\326\005", '\000' <repeats 13 times>, __ss_align = 93953794203504}}, length = 1384603504, link = {prev = 0x7f91a643a07b, next = 0x0}}
netaddr = {family = 2789449851, type = {in = {s_addr = 32657}, in6 = {__in6_u = {__u6_addr8 = "\221\177\000\000\240\255\264RsU\000\000w\264\2517", __u6_addr16 = {32657, 0, 44448, 21172, 21875, 0, 46199, 14249}, __u6_addr32 = {32657, 1387572640, 21875, 933868663}}}, un = "\221\177\000\000\240\255\264RsU\000\000w\264\2517\363\270\277\262%\310%\001\304\370\241\215\221\237\355\250li\301\345\000\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000\320k\332\315\374\177\000\0008e\207RsU\000\000\001", '\000' <repeats 15 times>, "`\232\203RsU\000\000\240\255\264RsU\000\000\320\316\202RsU\000"}, zone = 64}
match = 32764
timeout = <optimized out>
respond = <optimized out>
now = {seconds = 1533, nanoseconds = 0}
done = <optimized out>
#9 0x00007f91a63e8f28 in isc___nm_readcb (arg=<optimized out>) at netmgr/netmgr.c:1764
uvreq = 0x557352b4ada0
region = {base = 0x0, length = 0}
#10 isc__nm_readcb (sock=sock@entry=0x557352875f70, uvreq=<optimized out>, eresult=eresult@entry=ISC_R_TIMEDOUT, async=async@entry=false) at netmgr/netmgr.c:1779
No locals.
#11 0x00007f91a63e9009 in isc__nmsocket_readtimeout_cb (timer=0x5573528763b0) at netmgr/netmgr.c:1113
req = <optimized out>
sock = 0x557352875f70
#12 0x00007f91a638def6 in uv__run_timers (loop=loop@entry=0x55735287c5b0) at ./src/timer.c:178
heap_node = 0x557352876418
handle = 0x5573528763b0
#13 0x00007f91a639243a in uv_run (loop=loop@entry=0x55735287c5b0, mode=mode@entry=UV_RUN_DEFAULT) at ./src/unix/core.c:465
timeout = <optimized out>
r = <optimized out>
can_sleep = <optimized out>
#14 0x00007f91a640f554 in loop_thread (arg=arg@entry=0x55735287c590) at loop.c:282
loop = 0x55735287c590
r = <optimized out>
__func__ = "loop_thread"
ret = <optimized out>
#15 0x00007f91a641f893 in thread_body (wrap=0x55735283e170) at thread.c:85
func = 0x7f91a640f4d0 <loop_thread>
arg = 0x55735287c590
ret = 0x0
jemalloc_enforce_init = 0x557352b52d00
#16 isc_thread_main (func=func@entry=0x7f91a640f4d0 <loop_thread>, arg=0x55735287c590) at thread.c:116
No locals.
#17 0x00007f91a64106ac in isc_loopmgr_run (loopmgr=0x55735287d4c0) at loop.c:454
__func__ = "isc_loopmgr_run"
#18 0x0000557351da5766 in run_test_dispatch_getnext (state=<optimized out>) at dispatch_test.c:741
setup_loop = 0x0
teardown_loop = 0x0
#19 0x00007f91a63ba8f8 in cmocka_run_one_test_or_fixture (function_name=0x557351da813c "dispatch_getnext", test_func=0x557351da5740 <run_test_dispatch_getnext>, setup_func=setup_func@entry=0x0, teardown_func=teardown_func@entry=0x0, state=<optimized out>, state@entry=0x55735282ac80, heap_check_point=heap_check_point@entry=0x0) at ./src/cmocka.c:2801
check_point = 0x7f91a32d68d0
handle_exceptions = <optimized out>
current_state = 0x0
rc = 0
#20 0x00007f91a63bafdb in cmocka_run_one_tests (test_state=0x55735282ac70) at ./src/cmocka.c:2909
start = {tv_sec = 1700007173, tv_nsec = 801457005}
finish = {tv_sec = 0, tv_nsec = 0}
rc = 0
start = <optimized out>
finish = <optimized out>
rc = <optimized out>
#21 _cmocka_run_group_tests (group_name=group_name@entry=0x557351da806e "tests", tests=tests@entry=0x557351da9be0 <tests>, num_tests=num_tests@entry=10, group_setup=group_setup@entry=0x0, group_teardown=group_teardown@entry=0x0) at ./src/cmocka.c:3040
cmtest = 0x55735282ac70
test_number = 10
cm_tests = 0x55735282aac0
group_check_point = <optimized out>
group_state = 0x0
total_tests = <optimized out>
total_failed = <optimized out>
total_passed = 9
total_executed = 9
total_errors = 0
total_skipped = 0
total_runtime = 20.010910813999995
i = 9
rc = <optimized out>
#22 0x0000557351da5493 in main () at dispatch_test.c:855
r = <optimized out>
D:dispatch_test:backtrace from ./core.23758 end
FAIL dispatch_test (exit status: 134)
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4427Various improvements to hashing and hash table management2024-02-24T08:19:32ZMichał KępieńVarious improvements to hashing and hash table managementThis is a meta issue to keep track of various improvements to hashing
and hash table management that were implemented since ~"v9.18".
Sparked by a [Mattermost discussion][1].
---
- [x] #4306/!8288 Implement incremental hashing
---
...This is a meta issue to keep track of various improvements to hashing
and hash table management that were implemented since ~"v9.18".
Sparked by a [Mattermost discussion][1].
---
- [x] #4306/!8288 Implement incremental hashing
---
[1]: https://mattermost.isc.org/isc/pl/rsyemrkwhtfcbxhtyxddhkn58yMay 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4400CID 467118: Control flow issue in lib/dns/message.c2024-02-24T07:55:29ZMichal NowakCID 467118: Control flow issue in lib/dns/message.cCoverity Scan claims control flow issue in `lib/dns/message.c` (suspect: !8400).
```
*** CID 467118: Control flow issues (DEADCODE)
/lib/dns/message.c: 1076 in getquestions()
1070 return (DNS_R_RECOVERABLE);
1071 }
1072 ...Coverity Scan claims control flow issue in `lib/dns/message.c` (suspect: !8400).
```
*** CID 467118: Control flow issues (DEADCODE)
/lib/dns/message.c: 1076 in getquestions()
1070 return (DNS_R_RECOVERABLE);
1071 }
1072 return (ISC_R_SUCCESS);
1073
1074 cleanup:
1075 if (rdataset != NULL) {
>>> CID 467118: Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "dns_message_puttemprdataset...".
1076 dns_message_puttemprdataset(msg, &rdataset);
1077 }
1078 if (free_name) {
1079 dns_message_puttempname(msg, &name);
1080 }
1081
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4333catz: assertion failure in dns_view_attach() during shutdown2024-02-24T07:55:32ZArаm Sаrgsyаncatz: assertion failure in dns_view_attach() during shutdownSee https://gitlab.isc.org/isc-projects/bind9/-/jobs/3673976
This has happened on a branch based on `main`, so for now only ~"Affects v9.19" is set, but the other branches are probably affected too. The labels will updated when there is...See https://gitlab.isc.org/isc-projects/bind9/-/jobs/3673976
This has happened on a branch based on `main`, so for now only ~"Affects v9.19" is set, but the other branches are probably affected too. The labels will updated when there is more information.
```
[New LWP 55771]
[New LWP 55766]
[New LWP 55752]
[New LWP 55767]
[New LWP 55772]
[New LWP 55770]
[New LWP 55773]
[New LWP 55769]
[New LWP 55768]
[New LWP 55774]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/lt-named -D catz_tmp_b13wq61e-ns4 -X'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f0c573e0b8f in raise () from /lib64/libc.so.6
[Current thread is 1 (Thread 0x7f0c3c87e700 (LWP 55771))]
Thread 10 (Thread 0x7f0c3b07b700 (LWP 55774)):
#0 0x00007f0c573cb9bd in syscall () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007f0c57b68c76 in synchronize_rcu_memb () from /lib64/liburcu.so.6
No symbol table info available.
#2 0x00007f0c57b6975d in call_rcu_thread () from /lib64/liburcu.so.6
No symbol table info available.
#3 0x00007f0c580f81da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00007f0c573cbe73 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 9 (Thread 0x7f0c5247d700 (LWP 55768)):
#0 0x00007f0c580ff60e in pthread_barrier_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007f0c5b8416f9 in resume_loop (loop=0x7f0c53e93180) at loop.c:114
loopmgr = <optimized out>
loopmgr = <optimized out>
#2 pauseresume_cb (handle=<optimized out>) at loop.c:114
loop = 0x7f0c53e93180
#3 0x00007f0c5922a2f1 in uv.async_io.part () from /lib64/libuv.so.1
No symbol table info available.
#4 0x00007f0c5923bd15 in uv.io_poll () from /lib64/libuv.so.1
No symbol table info available.
#5 0x00007f0c5922aa74 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#6 0x00007f0c5b841792 in loop_thread (arg=arg@entry=0x7f0c53e93180) at loop.c:282
loop = 0x7f0c53e93180
r = <optimized out>
__func__ = "loop_thread"
ret = <optimized out>
#7 0x00007f0c5b850469 in thread_body (wrap=wrap@entry=0xf19630) at thread.c:85
func = 0x7f0c5b841707 <loop_thread>
arg = 0x7f0c53e93180
ret = 0x0
jemalloc_enforce_init = 0x7f0c48000b60
#8 0x00007f0c5b850492 in thread_run (wrap=0xf19630) at thread.c:100
ret = <optimized out>
#9 0x00007f0c580f81da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#10 0x00007f0c573cbe73 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 8 (Thread 0x7f0c51c7c700 (LWP 55769)):
#0 0x00007f0c573cb9bd in syscall () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007f0c5795e96d in futex_wait.part () from /lib64/liburcu-cds.so.6
No symbol table info available.
#2 0x00007f0c5795ee10 in workqueue_thread () from /lib64/liburcu-cds.so.6
No symbol table info available.
#3 0x00007f0c580f81da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00007f0c573cbe73 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 7 (Thread 0x7f0c3b87c700 (LWP 55773)):
#0 0x00007f0c5810187d in __lll_lock_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007f0c580fab29 in pthread_mutex_lock () from /lib64/libpthread.so.0
No symbol table info available.
#2 0x00007f0c57b681c9 in mutex_lock () from /lib64/liburcu.so.6
No symbol table info available.
#3 0x00007f0c57b69498 in rcu_register_thread_memb () from /lib64/liburcu.so.6
No symbol table info available.
#4 0x00007f0c5b856969 in isc__work_cb (req=<optimized out>) at work.c:28
work = 0x7f0c406203c0
#5 0x00007f0c592254ee in worker () from /lib64/libuv.so.1
No symbol table info available.
#6 0x00007f0c580f81da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#7 0x00007f0c573cbe73 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 6 (Thread 0x7f0c3d07f700 (LWP 55770)):
#0 0x00007f0c580fe4ac in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007f0c5923821d in uv_cond_wait () from /lib64/libuv.so.1
No symbol table info available.
#2 0x00007f0c5922558d in worker () from /lib64/libuv.so.1
No symbol table info available.
#3 0x00007f0c580f81da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00007f0c573cbe73 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 5 (Thread 0x7f0c3c07d700 (LWP 55772)):
#0 0x00007f0c580fe4ac in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007f0c5923821d in uv_cond_wait () from /lib64/libuv.so.1
No symbol table info available.
#2 0x00007f0c5922558d in worker () from /lib64/libuv.so.1
No symbol table info available.
#3 0x00007f0c580f81da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00007f0c573cbe73 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 4 (Thread 0x7f0c52c7e700 (LWP 55767)):
#0 0x00007f0c580ff60e in pthread_barrier_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007f0c5b8416f9 in resume_loop (loop=0x7f0c53e92900) at loop.c:114
loopmgr = <optimized out>
loopmgr = <optimized out>
#2 pauseresume_cb (handle=<optimized out>) at loop.c:114
loop = 0x7f0c53e92900
#3 0x00007f0c5922a2f1 in uv.async_io.part () from /lib64/libuv.so.1
No symbol table info available.
#4 0x00007f0c5923bd15 in uv.io_poll () from /lib64/libuv.so.1
No symbol table info available.
#5 0x00007f0c5922aa74 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#6 0x00007f0c5b841792 in loop_thread (arg=arg@entry=0x7f0c53e92900) at loop.c:282
loop = 0x7f0c53e92900
r = <optimized out>
__func__ = "loop_thread"
ret = <optimized out>
#7 0x00007f0c5b850469 in thread_body (wrap=wrap@entry=0xf19660) at thread.c:85
func = 0x7f0c5b841707 <loop_thread>
arg = 0x7f0c53e92900
ret = 0x0
jemalloc_enforce_init = 0x7f0c44000b60
#8 0x00007f0c5b850492 in thread_run (wrap=0xf19660) at thread.c:100
ret = <optimized out>
#9 0x00007f0c580f81da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#10 0x00007f0c573cbe73 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 3 (Thread 0x7f0c5bd5e480 (LWP 55752)):
#0 0x00007f0c5810187d in __lll_lock_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007f0c580fab29 in pthread_mutex_lock () from /lib64/libpthread.so.0
No symbol table info available.
#2 0x00007f0c57b681c9 in mutex_lock () from /lib64/liburcu.so.6
No symbol table info available.
#3 0x00007f0c57b68c44 in synchronize_rcu_memb () from /lib64/liburcu.so.6
No symbol table info available.
#4 0x00007f0c5b36f3ca in dns_view_detach (viewp=viewp@entry=0x7ffddd6d9348) at view.c:519
mkzone = 0x0
rdzone = 0x0
resolver = 0x0
adb = 0x7f0c40625600
zonetable = 0x7f0c5395d0a0
requestmgr = 0x7f0c4061b1e0
dispatchmgr = 0x7f0c53e7a9a0
view = 0x7f0c538cfc00
__func__ = "dns_view_detach"
#5 0x00000000004457e1 in shutdown_server (arg=0x7f0c53e881c0) at server.c:10025
server = 0x7f0c53e881c0
view = 0x0
view_next = 0x7f0c538cf600
kasp = 0x0
kasp_next = <optimized out>
flush = false
nsc = 0x0
#6 0x00007f0c5b82e23a in isc__async_cb (handle=<optimized out>) at async.c:111
job = 0x7f0c53e673c0
loop = 0x7f0c53e91800
jobs = {head = {node = {next = 0x7f0c53e63cd0}}, tail = {p = 0x7f0c53e673d0}}
ret = <optimized out>
node = 0x7f0c53e673d0
next = 0x0
#7 0x00007f0c5922a2f1 in uv.async_io.part () from /lib64/libuv.so.1
No symbol table info available.
#8 0x00007f0c5923bd15 in uv.io_poll () from /lib64/libuv.so.1
No symbol table info available.
#9 0x00007f0c5922aa74 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#10 0x00007f0c5b841792 in loop_thread (arg=arg@entry=0x7f0c53e91800) at loop.c:282
loop = 0x7f0c53e91800
r = <optimized out>
__func__ = "loop_thread"
ret = <optimized out>
#11 0x00007f0c5b850469 in thread_body (wrap=0xf1a3e0) at thread.c:85
func = 0x7f0c5b841707 <loop_thread>
arg = 0x7f0c53e91800
ret = 0x0
jemalloc_enforce_init = 0xf1a410
#12 0x00007f0c5b8504e3 in isc_thread_main (func=func@entry=0x7f0c5b841707 <loop_thread>, arg=0x7f0c53e91800) at thread.c:116
No locals.
#13 0x00007f0c5b84271a in isc_loopmgr_run (loopmgr=0x7f0c53e11540) at loop.c:454
__func__ = "isc_loopmgr_run"
#14 0x0000000000425995 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1580
result = <optimized out>
Thread 2 (Thread 0x7f0c5347f700 (LWP 55766)):
#0 0x00007f0c580ff60e in pthread_barrier_wait () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007f0c5b8416f9 in resume_loop (loop=0x7f0c53e92080) at loop.c:114
loopmgr = <optimized out>
loopmgr = <optimized out>
#2 pauseresume_cb (handle=<optimized out>) at loop.c:114
loop = 0x7f0c53e92080
#3 0x00007f0c5922a2f1 in uv.async_io.part () from /lib64/libuv.so.1
No symbol table info available.
#4 0x00007f0c5923bd15 in uv.io_poll () from /lib64/libuv.so.1
No symbol table info available.
#5 0x00007f0c5922aa74 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#6 0x00007f0c5b841792 in loop_thread (arg=arg@entry=0x7f0c53e92080) at loop.c:282
loop = 0x7f0c53e92080
r = <optimized out>
__func__ = "loop_thread"
ret = <optimized out>
#7 0x00007f0c5b850469 in thread_body (wrap=wrap@entry=0xf19710) at thread.c:85
func = 0x7f0c5b841707 <loop_thread>
arg = 0x7f0c53e92080
ret = 0x0
jemalloc_enforce_init = 0x7f0c4c000b60
#8 0x00007f0c5b850492 in thread_run (wrap=0xf19710) at thread.c:100
ret = <optimized out>
#9 0x00007f0c580f81da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#10 0x00007f0c573cbe73 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 1 (Thread 0x7f0c3c87e700 (LWP 55771)):
#0 0x00007f0c573e0b8f in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007f0c573b3ea5 in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x0000000000422efd in assertion_failed (file=0x7f0c5b3eb932 "view.c", line=429, type=isc_assertiontype_insist, cond=0x7f0c5b3c1f70 "__v > 0 && __v < (4294967295U)") at main.c:234
No locals.
#3 0x00007f0c5b82df3b in isc_assertion_failed (file=file@entry=0x7f0c5b3eb932 "view.c", line=line@entry=429, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7f0c5b3c1f70 "__v > 0 && __v < (4294967295U)") at assertions.c:48
No locals.
#4 0x00007f0c5b36c3f1 in dns_view_attach (source=source@entry=0x7f0c538cfc00, targetp=targetp@entry=0x7f0c3a20e4c8) at view.c:431
__v = <optimized out>
#5 0x000000000042ba15 in catz_run (entry=0x7f0c39e25000, origin=origin@entry=0x7f0c53e88540, view=0x7f0c538cfc00, udata=0x680670 <ns_catz_cbdata>, type=type@entry=CATZ_DELZONE) at server.c:2956
cz = 0x7f0c3a20e4b0
action = 0x42baf4 <catz_delzone_cb>
#6 0x000000000042ba6e in catz_delzone (entry=<optimized out>, origin=origin@entry=0x7f0c53e88540, view=<optimized out>, udata=<optimized out>) at server.c:2972
No locals.
#7 0x00007f0c5b244c2b in dns__catz_zones_merge (catz=0x7f0c53e88540, newcatz=0x7f0c3a211000) at catz.c:696
entry = 0x7f0c39e25000
result = ISC_R_SUCCESS
iter1 = 0x0
iter2 = 0x7f0c3a21e060
iteradd = 0x7f0c3a21e040
itermod = 0x7f0c3a21e020
toadd = 0x7f0c53e6aa30
tomod = 0x7f0c53e6a9e0
delcur = <optimized out>
czname = "catalog-tls.example\000\f\177\000\000\240\340tW\f\177\000\000\000\000\000\000\000\000\000\000\212\067HW\f\177\000\000@\000\000\000\000\000\000\000\000\006\"s\223>Z\177 \260\207<\f\177\000\000\034\024\205[\f\177\000\000\067\000\000\000\037\000\000\000\016\000\000\000\026\000\000\000\b\000\000\000{\000\000\000\001\000\000\000\000\000\000\000P\262\207<\f\177\000\000\365\016\204[\f\177\000\000{e\206[\f\177\000\000\000&uW\f\177\000\000\240\343tW\f\177\000\000Pl\205[\f\177\000\000{e\206[\f\177\000\000\000\000\000\000\000\000\000\000P\262\207<\f\177\000\000\300\b\204[\f\177\000\000H\361\350S\f\177\000\000"...
zname = "tls1.example\000\177\000\000\377", '\000' <repeats 23 times>, '\377' <repeats 16 times>, '\000' <repeats 24 times>, "`\330tW\f\177\000\000\000\006\"s\223>Z\177\000&uW\f\177\000\000\207(\255\373\000\000\000\000\360\200\346S\f\177\000\000\060\264\207<\f\177\000\000!fuB\000\000\000\000\240\253\207<\f\177\000\000\377", '\000' <repeats 23 times>, '\377' <repeats 16 times>, "\000\006\"s\223>Z\177\340\253\207<\f\177\000\000\000"...
addzone = 0x42ba81 <catz_addzone>
modzone = 0x42ba70 <catz_modzone>
delzone = 0x42ba5f <catz_delzone>
__func__ = "dns__catz_zones_merge"
#8 0x00007f0c5b248106 in dns__catz_update_cb (data=<optimized out>) at catz.c:2467
catz = <optimized out>
updb = <optimized out>
catzs = <optimized out>
oldcatz = 0x7f0c53e88540
newcatz = 0x7f0c3a211000
result = ISC_R_SHUTTINGDOWN
r = <optimized out>
node = 0x0
vers_node = 0x0
updbit = 0x0
fixname = {name = {magic = 1145983854, ndata = 0x0, length = 0, labels = 0, attributes = {absolute = false, readonly = false, dynamic = false, dynoffsets = false, nocompress = false, cache = false, answer = false, ncache = false, chaining = false, chase = false, wildcard = false, prerequisite = false, update = false, hasupdaterec = false}, offsets = 0x7f0c3c87bf40 "", buffer = 0x7f0c3c87bfc0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, list = {head = 0x0, tail = 0x0}}, offsets = "\000\b\024\034", '\000' <repeats 123 times>, buffer = {magic = 1114990113, base = 0x7f0c3c87c000, length = 255, used = 0, current = 0, active = 0, extra = 0, dynamic = false, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, mctx = 0x0}, data = "\aversion\vcatalog-tls\aexample", '\000' <repeats 36 times>, "!fuB\000\000\000\000@y\":\f\177\000\000\000\000\002\000\016", '\000' <repeats 19 times>, '\377' <repeats 16 times>, "\000\000\000\000\000\000\000\000!fuB", '\000' <repeats 20 times>, ")\253\017X\f\177\000\000\000\000\000\000\000\000\000\000\n\000\000\000\000\000\000\000\200\322\326W\f\177\000\000\000\000\000\000\000\000\000\000\066\303\017X\f\177\000\000\000"...}
name = 0x7f0c3c87bef0
rdsiter = 0x0
rdataset = {magic = 1145983826, methods = 0x0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, rdclass = 0, type = 0, ttl = 0, trust = 0, covers = 0, attributes = 0, count = 4294967295, resign = 0, {keytable = {node = 0x0, iter = 0x0}, ncache = {raw = 0x0, iter_pos = 0x0, iter_count = 0}, slab = {db = 0x0, node = 0x0, raw = 0x0, iter_pos = 0x0, iter_count = 0, noqname = 0x0, closest = 0x0}, rdlist = {list = 0x0, iter = 0x0, noqname = 0x0, closest = 0x0, node = 0x0}, rps = {db = 0x0, iter_pos = 0x0, iter_count = 0}}}
bname = "catalog-tls.example", '\000' <repeats 413 times>...
cname = "\000\274\207<\f\177\000\000\001\000\000\000\001\000\000\000@y\":\f\177", '\000' <repeats 19 times>, "\204$:\f\177\000\000\000\340$:\f\177", '\000' <repeats 11 times>, "~`@\f\177", '\000' <repeats 18 times>, "\340\300\207<\f\177\000\000\200\250\340S\f\177\000\000\000\000\000\000\000\000\000\000 \200d@\f\177\000\000\020", '\000' <repeats 311 times>...
is_vers_processed = <optimized out>
is_active = true
vers = 2
catz_vers = <optimized out>
__func__ = "dns__catz_update_cb"
#9 0x00007f0c5b856976 in isc__work_cb (req=<optimized out>) at work.c:30
work = 0x7f0c53e6dbe0
#10 0x00007f0c592254ee in worker () from /lib64/libuv.so.1
No symbol table info available.
#11 0x00007f0c580f81da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#12 0x00007f0c573cbe73 in clone () from /lib64/libc.so.6
No symbol table info available.
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3792incoming AXFR sometimes does not close TCP connection2024-02-24T07:53:11ZPetr Špačekpspacek@isc.orgincoming AXFR sometimes does not close TCP connection### Summary
I've noticed in PCAPs that sometimes BIND does not close TCP connection after successful incoming AXFR. This might cause source port depletion on a busy server.
### BIND version used
* ~"Affects v9.19": 9.19.9 56d7e01
* No...### Summary
I've noticed in PCAPs that sometimes BIND does not close TCP connection after successful incoming AXFR. This might cause source port depletion on a busy server.
### BIND version used
* ~"Affects v9.19": 9.19.9 56d7e01
* Not reproducible on ~"v9.18" (9.18.11 equivalent, b04ab06) - albeit closing the connection can take more than one second, it happens from the secondary side as expected
* ~"Affects v9.16": (9.16.37, b4a65aaea19762a3712932aa2270e8a833fbde22) - reproducible
Don't ask me how is that possible ...
### Steps to reproduce
1. Configure primary with 100k zones + catalog - can be BIND or Knot DNS (recommended to take BIND out of equation on one side)
2. Configure BIND as secondary for the catalog
3. Start secondary with clean state
### What is the current *bug* behavior?
PCAPs show that sometimes the primary closes hanging connection after primary-side timeout.
### What is the expected *correct* behavior?
Connections are closed as soon as possible.
### Relevant configuration files
#### Primary
* [named.conf](/uploads/863bf85788384d2e4893ea94cc606c89/named.conf)
* [catalog.db](/uploads/c515216922d648acf6065f7a50b36233/catalog.db)
* [empty.db](/uploads/5686c122ffb6fd4eb035bc1b88931e0f/empty.db)
Knot DNS version: [knotd.conf](/uploads/e59561f0b1f2047d348a51303d5a2119/knotd.conf)
#### Secondary
* [named.conf](/uploads/984a16e8322400cc6465b14ca45710ef/named.conf)
### Relevant logs and/or screenshots
* Primary: [primary.log.zst](/uploads/e50efe9e008cd762b3a671245e207b7d/primary.log.zst)
* Secondary: [secondary-for-knotd-conf3000.log.zst](/uploads/e8732553815f19ebf3b483629afd6279/secondary-for-knotd-conf3000.log.zst)
* search for `z19823.test` and look at timestamps
* PCAP: [bindconf3000.pcap.zst](/uploads/86b89c9ddc6d4e1c6066cfd1a997c25b/bindconf3000.pcap.zst)
* search for `tcp.stream eq 37322` in Wireshark to get `z19823.test` transfer
Suspicious conversation from the PCAP, times relative to the previous packet:
|No. | Time | Source | Source Port | Destination | Reply code | Info|
|--- | --- | --- | --- | --- | --- | ---|
|484345 | 0 | 192.0.2.2 | 40571 | 192.0.2.1 | | 40571 → 53 [SYN] Seq=0 Win=64660 Len=0 MSS=1220 SACK_PERM TSval=3661096036 TSecr=0 WS=128|
|484346 | 0,000027 | 192.0.2.1 | 53 | 192.0.2.2 | | 53 → 40571 [SYN, ACK] Seq=0 Ack=1 Win=65232 Len=0 MSS=1220 SACK_PERM TSval=1123290483 TSecr=3661096036 WS=128|
|484347 | 0,000008 | 192.0.2.2 | 40571 | 192.0.2.1 | | 40571 → 53 [ACK] Seq=1 Ack=1 Win=64768 Len=0 TSval=3661096036 TSecr=1123290483|
|511718 | 1,98078 | 192.0.2.2 | 40571 | 192.0.2.1 | | Standard query 0x47aa AXFR z19823.test|
|511719 | 0,000019 | 192.0.2.1 | 53 | 192.0.2.2 | | 53 → 40571 [ACK] Seq=1 Ack=32 Win=65280 Len=0 TSval=1123292464 TSecr=3661098017|
|511724 | 0,000107 | 192.0.2.1 | 53 | 192.0.2.2 | No error | Standard query response 0x47aa AXFR z19823.test SOA <Root> NS invalid SOA <Root>|
|511726 | 0,000009 | 192.0.2.2 | 40571 | 192.0.2.1 | | 40571 → 53 [ACK] Seq=32 Ack=121 Win=64768 Len=0 TSval=3661098017 TSecr=1123292464|
|601979 | 9,49634 | 192.0.2.1 | 53 | 192.0.2.2 | | 53 → 40571 [FIN, ACK] Seq=121 Ack=32 Win=65280 Len=0 TSval=1123301960 TSecr=3661098017|
|602469 | 0,040942 | 192.0.2.2 | 40571 | 192.0.2.1 | | 40571 → 53 [ACK] Seq=32 Ack=122 Win=64768 Len=0 TSval=3661107554 TSecr=1123301960|
|621475 | 1,959518 | 192.0.2.2 | 40571 | 192.0.2.1 | | 40571 → 53 [FIN, ACK] Seq=32 Ack=122 Win=64768 Len=0 TSval=3661109514 TSecr=1123301960|
|621476 | 0,000019 | 192.0.2.1 | 53 | 192.0.2.2 | | 53 → 40571 [ACK] Seq=122 Ack=33 Win=65280 Len=0 TSval=1123303961 TSecr=3661109514|
### Possible fixesMay 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4615Improve dnssec-keygen warnings when unnecessary parameters are ignored2024-02-29T15:48:40ZCathy AlmondImprove dnssec-keygen warnings when unnecessary parameters are ignored### Summary
The specific instance that inspires this bug report is that these commands
> dnssec-keygen -b 2048 -a ECDSAP256SHA256 -f KSK example.com
> dnssec-keygen -b 2048 -a ECDSAP256SHA256 example.com
.. don't generate a warning th...### Summary
The specific instance that inspires this bug report is that these commands
> dnssec-keygen -b 2048 -a ECDSAP256SHA256 -f KSK example.com
> dnssec-keygen -b 2048 -a ECDSAP256SHA256 example.com
.. don't generate a warning that the -b 2048 is ignored because key algorithm ECDSAP256SHA256 has a predefined length
There may be other scenarios worth checking at the same time?
### BIND version affected
Noted against 9.16.28 (a long time ago), but the situation I don't think has changed.
### Steps to reproduce
See above - just do it?
### What is the current *bug* behavior?
No warning. dnssec-keygen goes its own sweet way and uses its built-in default length for this key
### What is the expected *correct* behavior?
It would have been really helpful to have known that the keys didn't have the requested length - this caused a bunch of other problems during migration to dnssec-policy using these keys!
What actually happened is that after restarting named and switching to dnssec-policy with these parameters:
> ksk lifetime unlimited algorithm ECDSAP256SHA256 2048;
> zsk lifetime unlimited algorithm ECDSAP256SHA256 2048;
named didn't recognise the existing keys as matching the policy and generated new ones for the zone, retiring the old keys - which is just what you don't want when migrating your existing zone's configuration and not intending to abruptly re-sign it with new keys (aargh!)
In fact, named-checkconf does fuss about the 2048:
> /etc/namedb/named.conf:54: dnssec-policy: key algorithm ECDSAP256SHA256 has predefined length; ignoring length value 2048
> /etc/namedb/named.conf:55: dnssec-policy: key algorithm ECDSAP256SHA256 has predefined length; ignoring length value 2048
So perhaps this is another small bug too - if the length is irrelevant and ignored - why did it not just recognise the existing keys?
It was perfectly happy with the same keys and with:
> ksk lifetime unlimited algorithm ECDSAP256SHA256;
> zsk lifetime unlimited algorithm ECDSAP256SHA256;May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4579Restore the ability to select individual unit tests and turn on debugging2024-02-24T07:53:44ZMark AndrewsRestore the ability to select individual unit tests and turn on debugging63fe9312ff8f removed the ability to select individual tests from the command line and turn on debugging. This is useful when you want to check only parts of a unit test when developing. This restores / adds this ability.63fe9312ff8f removed the ability to select individual tests from the command line and turn on debugging. This is useful when you want to check only parts of a unit test when developing. This restores / adds this ability.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4352inline-signing breaks nsdiff2024-02-24T07:55:39ZBjörn Perssoninline-signing breaks nsdiff### Summary
When both inline-signing and update-policy are in use, I can't detect race conditions with the method described in RFC 2136 section 5.7, which nsdiff uses.
In a zone that uses dnssec-policy and relies on the default value o...### Summary
When both inline-signing and update-policy are in use, I can't detect race conditions with the method described in RFC 2136 section 5.7, which nsdiff uses.
In a zone that uses dnssec-policy and relies on the default value of inline-signing, the method in RFC 2136 section 5.7 will stop working on upgrade to BIND 9.20, as inline-signing will then be switched on by default, if I understand correctly.
### BIND version used
```
$ named -V
BIND 9.18.19-1~deb12u1-Debian (Extended Support Version) <id:>
running on Linux x86_64 5.10.0-25-amd64 #1 SMP Debian 5.10.191-1 (2023-08-16)
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/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' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--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 -ffile-prefix-map=/build/reproducible-path/bind9-9.18.19=. -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 12.2.0
compiled with OpenSSL version: OpenSSL 3.0.10 1 Aug 2023
linked to OpenSSL version: OpenSSL 3.0.9 30 May 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.52.0
linked to libnghttp2 version: 1.52.0
compiled with libxml2 version: 2.9.14
linked to libxml2 version: 20914
compiled with json-c version: 0.16
linked to json-c version: 0.16
compiled with zlib version: 1.2.13
linked to zlib version: 1.2.13
linked to maxminddb version: 1.7.1
compiled with protobuf-c version: 1.4.1
linked to protobuf-c version: 1.4.1
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): yes
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
Here I start from a working state with serial number 2023091800. The prerequisite matches the reply to the SOA query, and the update is answered with NOERROR. This is correct as far as I understand:
```
$ (echo 'prereq yxrrset xn--rombobjrn-67a.se. IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091800 14400 3600 3024000 86400' ; echo send) | nsupdate -k internal -d
Creating key...
Creating key...
namefromtext
keycreate
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23595
;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; ANSWER SECTION:
xn--rombobjrn-67a.se. 86400 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091800 14400 3600 3024000 86400
Found zone name: xn--rombobjrn-67a.se
The primary is: ns1.xn--rombobjrn-67a.se
Sending update to 192.168.72.1#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 44980
;; flags:; ZONE: 1, PREREQ: 1, UPDATE: 0, ADDITIONAL: 1
;; PREREQUISITE SECTION:
xn--rombobjrn-67a.se. 0 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091800 14400 3600 3024000 86400
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695171088 300 64 [...] 44980 NOERROR 0
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 44980
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695171088 300 64 [...] 44980 NOERROR 0
```
Later, the server has automatically increased the serial number to 2023091802. I use the new serial number in the prerequisite, so it looks identical to the new SOA value, but this time the update is rejected with NXRRSET:
```
$ (echo 'prereq yxrrset xn--rombobjrn-67a.se. IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091802 14400 3600 3024000 86400' ; echo send) | nsupdate -k internal -d
Creating key...
Creating key...
namefromtext
keycreate
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65052
;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; ANSWER SECTION:
xn--rombobjrn-67a.se. 86400 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091802 14400 3600 3024000 86400
Found zone name: xn--rombobjrn-67a.se
The primary is: ns1.xn--rombobjrn-67a.se
Sending update to 192.168.72.1#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 52912
;; flags:; ZONE: 1, PREREQ: 1, UPDATE: 0, ADDITIONAL: 1
;; PREREQUISITE SECTION:
xn--rombobjrn-67a.se. 0 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091802 14400 3600 3024000 86400
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695259647 300 64 [...] 52912 NOERROR 0
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NXRRSET, id: 52912
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695259647 300 64 [...] 52912 NOERROR 0
```
Now I change the prerequisite back to 2023091800. The SOA hasn't changed again. The serial number is still 2023091802. This update should be rejected as the prerequisite contains an outdated serial number, but is in fact answered with NOERROR:
```
$ (echo 'prereq yxrrset xn--rombobjrn-67a.se. IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091800 14400 3600 3024000 86400' ; echo send) | nsupdate -k internal -d
Creating key...
Creating key...
namefromtext
keycreate
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6226
;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; ANSWER SECTION:
xn--rombobjrn-67a.se. 86400 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091802 14400 3600 3024000 86400
Found zone name: xn--rombobjrn-67a.se
The primary is: ns1.xn--rombobjrn-67a.se
Sending update to 192.168.72.1#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 49961
;; flags:; ZONE: 1, PREREQ: 1, UPDATE: 0, ADDITIONAL: 1
;; PREREQUISITE SECTION:
xn--rombobjrn-67a.se. 0 IN SOA ns1.xn--rombobjrn-67a.se. hostmaster.xn--rombobjrn-67a.se. 2023091800 14400 3600 3024000 86400
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695263626 300 64 [...] 49961 NOERROR 0
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 49961
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;xn--rombobjrn-67a.se. IN SOA
;; TSIG PSEUDOSECTION:
internal.beorn.tag.xn--rombobjrn-67a.se. 0 ANY TSIG hmac-sha512. 1695263626 300 64 [...] 49961 NOERROR 0
```
### What is the current *bug* behavior?
It seems that a serial number specified in a prerequisite of an update is compared to the unsigned version of the zone, but the serial number retrieved with a SOA or AXFR query is from the signed version. As far as I know a client can't look up the unsigned serial number, and thus can't specify it in the prerequisite. Thus the update fails when the two serial numbers differ.
### What is the expected *correct* behavior?
It seems to me that a prerequisite that specifies a SOA record should be checked against the same record that a client gets in response to a SOA or AXFR query. I don't know what other usecases that might break though.
### Relevant excerpts from the configuration file
```
dnssec-policy "some_name" {
keys {
ksk lifetime unlimited algorithm rsasha256 2048;
zsk lifetime unlimited algorithm rsasha256 2048;
};
dnskey-ttl P1D;
purge-keys 0;
};
view "internal" {
allow-transfer { key internal.beorn.tag.xn--rombobjrn-67a.se.; };
zone "xn--rombobjrn-67a.se" {
type master;
file "/var/lib/bind/db.xn--rombobjrn-67a.se.internal";
dnssec-policy some_name;
parental-agents { ::1; };
inline-signing yes;
update-policy {
grant internal.beorn.tag.xn--rombobjrn-67a.se. zonesub ANY;
};
};
};May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4606"dry-run" mode to help with dnssec-policy migration2024-02-28T10:46:36ZCarsten Strotmann"dry-run" mode to help with dnssec-policy migration### Description
For some users of BIND 9, esp. people are part time DNS admins only, migrating from manual DNSSEC key management with "auto-dnssec maintain;" towards "dnssec-policy" is difficult.
While the documentation provided by ISC...### Description
For some users of BIND 9, esp. people are part time DNS admins only, migrating from manual DNSSEC key management with "auto-dnssec maintain;" towards "dnssec-policy" is difficult.
While the documentation provided by ISC is good, there is currently no way to "verify" the new "dnssec-policy" configuration before enabling it. Experience has shown (in DNS training classes, but also in real world deployments) that there are many things that can go wrong:
- differences in the DNSSEC key configuration (old vs. new)
- file system permissions on the old key material
- file system location of the old key material
- issues with the time-events stored in the old key material
Going online with a slightly wrong configuration can cause an immediate key rollover, which might break the zone. Recovering from this situation is possible, but requires good knowledge of BIND 9 DNSSEC workings
### Request
Provide a "dnssec-policy dry-run" mode, where BIND 9 will log the next steps in the automatic DNSSEC management to the log files (e.g. category "DNSSEC"), but will not execute any changes to the DNSSEC signed zone or the key material. This will enable the user to test drive the new "dnssec-policy" to see if it will act as expected.
Admins can create a configuration with "dry-run" mode enabled, check the logfiles, and if the actions in the log-file match the expectations, the "dry-run" mode can be removed and the new configuration will become active.
### Links / referencesMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4598statschannel test may fail due to a missing response2024-02-22T09:53:52ZTom Krizekstatschannel test may fail due to a missing response`statschannel` system tests [`test_traffic_xml`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4054038) ([9.18 job](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4002144)) or [`test_traffic_json`](https://gitlab.isc.org/isc-project...`statschannel` system tests [`test_traffic_xml`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4054038) ([9.18 job](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4002144)) or [`test_traffic_json`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3999177) may fail with:
```
_______________________________ test_traffic_xml _______________________________
[gw2] linux -- Python 3.12.1 /usr/bin/python3
/builds/isc-projects/bind9/bin/tests/system/statschannel/tests_xml.py:134: in test_traffic_xml
generic.test_traffic(fetch_traffic_xml, statsip="10.53.0.2", statsport=statsport)
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:211: in test_traffic
check_traffic(data, exp)
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:185: in check_traffic
assert ordered_data == ordered_expected
E AssertionError: assert [('dns-tcp-re...v6', []), ...] == [('dns-tcp-re...v6', []), ...]
E At index 6 diff: ('dns-udp-responses-sizes-sent-ipv4', [('96-111', 1)]) != ('dns-udp-responses-sizes-sent-ipv4', [('816-831', 1), ('96-111', 1)])
E Full diff:
E [
E ('dns-tcp-requests-sizes-received-ipv4', [('16-31', 1)]),
E ('dns-tcp-requests-sizes-received-ipv6', []),
E ('dns-tcp-responses-sizes-sent-ipv4', [('64-79', 1)]),
E ('dns-tcp-responses-sizes-sent-ipv6', []),
E ('dns-udp-requests-sizes-received-ipv4', [('32-47', 2)]),
E ('dns-udp-requests-sizes-received-ipv6', []),
E - ('dns-udp-responses-sizes-sent-ipv4', [('816-831', 1), ('96-111', 1)]),
E ? ----------------
E + ('dns-udp-responses-sizes-sent-ipv4', [('96-111', 1)]),
E ('dns-udp-responses-sizes-sent-ipv6', []),
E ]
```
```
______________________________ test_traffic_json _______________________________
[gw3] linux -- Python 3.11.2 /usr/bin/python3
/builds/isc-projects/bind9/bin/tests/system/statschannel/tests_json.py:104: in test_traffic_json
generic.test_traffic(fetch_traffic_json, statsip="10.53.0.2", statsport=statsport)
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:229: in test_traffic
check_traffic(data, exp)
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:185: in check_traffic
assert ordered_data == ordered_expected
E AssertionError: assert [('dns-tcp-re...v6', []), ...] == [('dns-tcp-re...v6', []), ...]
E At index 2 diff: ('dns-tcp-responses-sizes-sent-ipv4', [('64-79', 1), ('96-111', 1)]) != ('dns-tcp-responses-sizes-sent-ipv4', [('64-79', 1), ('816-831', 1), ('96-111', 1)])
E Full diff:
E [
E ('dns-tcp-requests-sizes-received-ipv4',
E [('16-31',
E 1),
E ('32-47',
E 2)]),
E ('dns-tcp-requests-sizes-received-ipv6',
E []),
E ('dns-tcp-responses-sizes-sent-ipv4',
E [('64-79',
E - 1),
E - ('816-831',
E 1),
E ('96-111',
E 1)]),
E ('dns-tcp-responses-sizes-sent-ipv6',
E []),
E ('dns-udp-requests-sizes-received-ipv4',
E [('32-47',
E 2)]),
E ('dns-udp-requests-sizes-received-ipv6',
E []),
E ('dns-udp-responses-sizes-sent-ipv4',
E [('816-831',
E 1),
E ('96-111',
E 1)]),
E ('dns-udp-responses-sizes-sent-ipv6',
E []),
E ]
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4550Resolve license aggregation for "reuse lint"2024-02-07T16:19:55ZMichal NowakResolve license aggregation for "reuse lint"`reuse lint` in the [`reuse`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3976938) CI job has a lot of deprecation warnings about license aggregation in our repo:
```
/opt/venv/lib/python3.11/site-packages/reuse/project.py:286: Pen...`reuse lint` in the [`reuse`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3976938) CI job has a lot of deprecation warnings about license aggregation in our repo:
```
/opt/venv/lib/python3.11/site-packages/reuse/project.py:286: PendingDeprecationWarning: Copyright and licensing
information for 'COPYRIGHT' has been found in both 'COPYRIGHT' and in the DEP5 file located at '.reuse/dep5'.
The information for these two sources has been aggregated. In the future this behaviour will change, and you will
need to explicitly enable aggregation. See <https://github.com/fsfe/reuse-tool/issues/779>. You need do nothing
yet. Run with `--suppress-deprecation` to hide this warning.
...
```Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4485Update httppicoparser2023-12-13T16:43:09ZOndřej SurýUpdate httppicoparserThis sounds like something we should eventually sync: https://github.com/h2o/picohttpparser/pull/78This sounds like something we should eventually sync: https://github.com/h2o/picohttpparser/pull/78BIND 9.19.xOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4458dnssec auto fails across multiple views + unable to add/remove DS records fro...2023-12-04T05:39:28ZTom Shawdnssec auto fails across multiple views + unable to add/remove DS records from second view + invalid DS records### Summary
- When using multiple views, the affected views fail to manage dnssec properly
- When using dnssec to auto sign zones, across multiple views, all but one of the views will fail to add DS records through nsupdate.
- The view ...### Summary
- When using multiple views, the affected views fail to manage dnssec properly
- When using dnssec to auto sign zones, across multiple views, all but one of the views will fail to add DS records through nsupdate.
- The view fails to manage and purge old key/state/private files and these start to build up over time
- Unable to get DS records, publish CDS log entries stop appearing for the view
### BIND version used
BIND 9.18.20-1+ubuntu22.04.1+deb.sury.org+1-Ubuntu
### Steps to reproduce
Create a config which has two views, with the same domain in each view. One of the views must only be available to an internal ip range (internal), the other must be available from all (external). Enable dnssec on both domains in both views using separate policies.
### What is the current *bug* behavior?
- keys in the internal view will not be managed correctly and will build up over time
- nsupdate will appear to add/delete the DS records correctly but these are not added or deleted in bind.
### What is the expected *correct* behavior?
- keys in both views should be managed correctly
- nsupdate should be able to manipulate the DS records in the internal view
### Relevant configuration files
I will share my configs privately if possible
Use this yearly internal policy for TDL level domains
```
dnssec-policy "yearly-internal" {
keys {
ksk lifetime P365D algorithm ECDSAP384SHA384;
zsk lifetime P1D algorithm ECDSAP384SHA384;
};
//
dnskey-ttl PT5M;
publish-safety PT3M;
retire-safety PT5M;
purge-keys PT10M;
// Signature timings
signatures-refresh PT5M;
signatures-validity PT10M;
signatures-validity-dnskey PT10M;
//
max-zone-ttl PT5M;
parent-ds-ttl PT3M;
parent-propagation-delay PT3M;
nsec3param iterations 10 optout no salt-length 16;
};
Use this aggressive standard internal policy for sub domains
dnssec-policy "standard" {
keys {
ksk lifetime PT40M algorithm ECDSAP384SHA384;
zsk lifetime PT20M algorithm ECDSAP384SHA384;
};
//
dnskey-ttl 60;
publish-safety PT2M;
retire-safety PT2M;
purge-keys PT10M;
// Signature timings
signatures-refresh PT5M;
signatures-validity PT10M;
signatures-validity-dnskey PT10M;
//
max-zone-ttl 300;
parent-ds-ttl 60;
parent-propagation-delay 60;
nsec3param iterations 10 optout no salt-length 16;
};
options {
check-names master ignore;
check-names slave ignore;
check-names response ignore;
masterfile-format text;
listen-on-v6 { none; };
listen-on port 53 { 127.0.0.1; 165.227.238.11; 10.0.254.1; 10.0.254.2; };
directory "/var/cache/bind";
auth-nxdomain no; # conform to RFC1035
querylog yes;
pid-file "/var/run/named/named.pid";
include "/etc/bind/named.options.transfer.conf";
# if running a natted server, set the public ip address here
# this will not work in a multihomed box (specifically linode fails)
# notify the NS servers - only on master
notify yes;
# some dnssec stuff
include "/etc/bind/named.options.dnssec.conf";
max-cache-size 10485760;
};
```
Zone file
```
#ns1.node.flipkick.media
zone "entitywind.dev" {
key-directory "/var/cache/bind/keys/internals-master";
file "internals.master.dev.entitywind.db";
update-policy {
grant 127.0.0.1 subdomain entitywind.dev;
grant internal subdomain entitywind.dev;
grant internal zonesub any;
grant internal-externaldns subdomain entitywind.dev;
grant internal-externaldns zonesub any;
grant internal-rndc-key subdomain entitywind.dev;
grant internal-rndc-key zonesub any;
};
include "/etc/bind/named.zone.internals-master.conf";
include "/etc/bind/named.zone.dnssec.policy.yearly-internal.conf";
parental-agents { "externals"; };
};
#ns1.node.flipkick.media
zone "node.entitywind.dev" {
key-directory "/var/cache/bind/keys/internals-master";
file "internals.master.dev.entitywind.db";
update-policy {
grant 127.0.0.1 subdomain entitywind.dev;
grant internal subdomain entitywind.dev;
grant internal zonesub any;
grant internal-externaldns subdomain entitywind.dev;
grant internal-externaldns zonesub any;
grant internal-rndc-key subdomain entitywind.dev;
grant internal-rndc-key zonesub any;
};
include "/etc/bind/named.zone.internals-master.conf";
include "/etc/bind/named.zone.dnssec.policy.yearly-internal.conf";
parental-agents { "externals"; };
};
```
### Relevant logs and/or screenshots
```
28-Nov-2023 12:58:02.305 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/25339 (KSK) is now inactive
28-Nov-2023 12:58:02.309 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/53449 (KSK) is now inactive
28-Nov-2023 12:58:02.309 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/43625 (KSK) is now inactive
28-Nov-2023 12:58:02.309 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/26195 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/33520 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/26171 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/37281 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/7041 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/63692 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/9156 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/29571 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/44364 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/44662 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/40817 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/22890 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/64449 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/39830 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/30931 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/57355 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/23733 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/25059 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/20634 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/2754 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/19617 (KSK) is now inactive
28-Nov-2023 12:58:02.313 dnssec: info: DNSKEY prod.node.flipkick.media/ECDSAP384SHA384/61960 (KSK) is now inactive
```
### Possible fixes
Run two bind servers and attach to differing ips