ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-03-22T10:57:42Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3928Data race lib/dns/rbtdb.c:1474 in node_createdata2023-03-22T10:57:42ZMichal NowakData race lib/dns/rbtdb.c:1474 in node_createdataJob [#3213901](https://gitlab.isc.org/isc-private/bind9/-/jobs/3213901) failed for isc-private/bind9@0f03d5737bcbdaa1bf713c6db1887b14938c3421 (`v9_18_sub`) in `respdiff-long:tsan` CI job.
```
WARNING: ThreadSanitizer: data race
Read ...Job [#3213901](https://gitlab.isc.org/isc-private/bind9/-/jobs/3213901) failed for isc-private/bind9@0f03d5737bcbdaa1bf713c6db1887b14938c3421 (`v9_18_sub`) in `respdiff-long:tsan` CI job.
```
WARNING: ThreadSanitizer: data race
Read of size 8 at 0x000000000001 by thread T1 (mutexes: write M1, write M2):
#0 node_createdata lib/dns/rbtdb.c:1474
#1 rbt_addnode_withdata lib/dns/rbtdb.c:1678
#2 findnodeintree lib/dns/rbtdb.c:3014
#3 findnode lib/dns/rbtdb.c:3060
#4 dns_db_findnode lib/dns/db.c:428
#5 cache_name lib/dns/resolver.c:6559
#6 cache_message lib/dns/resolver.c:7028
#7 resquery_response lib/dns/resolver.c:8495
#8 udp_recv lib/dns/dispatch.c:638
#9 isc__nm_async_readcb netmgr/netmgr.c:2890
#10 isc__nm_readcb netmgr/netmgr.c:2863
#11 udp_recv_cb netmgr/udp.c:650
#12 isc__nm_udp_read_cb netmgr/udp.c:1057
#13 uv__udp_recvmsg /usr/src/libuv-v1.44.1/src/unix/udp.c:303
#14 isc__trampoline_run lib/isc/trampoline.c:189
Previous write of size 8 at 0x000000000001 by thread T2 (mutexes: write M3, write M4):
#0 node_createdata lib/dns/rbtdb.c:1479
#1 ecs_nonecs_nodedata_set lib/dns/rbtdb.c:1489
#2 add32 lib/dns/rbtdb.c:7662
#3 addrdatasetext lib/dns/rbtdb.c:8118
#4 dns_db_addrdatasetext lib/dns/db.c:822
#5 cache_name lib/dns/resolver.c:6766
#6 cache_message lib/dns/resolver.c:7028
#7 resquery_response lib/dns/resolver.c:8495
#8 udp_recv lib/dns/dispatch.c:638
#9 isc__nm_async_readcb netmgr/netmgr.c:2890
#10 isc__nm_readcb netmgr/netmgr.c:2863
#11 udp_recv_cb netmgr/udp.c:650
#12 isc__nm_udp_read_cb netmgr/udp.c:1057
#13 uv__udp_recvmsg /usr/src/libuv-v1.44.1/src/unix/udp.c:303
#14 isc__trampoline_run lib/isc/trampoline.c:189
Location is heap block of size 110 at 0x000000000023 allocated by thread T2:
#0 malloc ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:651
#1 mallocx lib/isc/jemalloc_shim.h:35
#2 mem_get lib/isc/mem.c:343
#3 isc__mem_get lib/isc/mem.c:761
#4 create_node lib/dns/rbt.c:1557
#5 dns_rbt_addnode lib/dns/rbt.c:629
#6 rbt_addnode_withdata lib/dns/rbtdb.c:1673
#7 findnodeintree lib/dns/rbtdb.c:3014
#8 findnode lib/dns/rbtdb.c:3060
#9 dns_db_findnode lib/dns/db.c:428
#10 cache_name lib/dns/resolver.c:6559
#11 cache_message lib/dns/resolver.c:7028
#12 resquery_response lib/dns/resolver.c:8495
#13 udp_recv lib/dns/dispatch.c:638
#14 isc__nm_async_readcb netmgr/netmgr.c:2890
#15 isc__nm_readcb netmgr/netmgr.c:2863
#16 udp_recv_cb netmgr/udp.c:650
#17 isc__nm_udp_read_cb netmgr/udp.c:1057
#18 uv__udp_recvmsg /usr/src/libuv-v1.44.1/src/unix/udp.c:303
#19 isc__trampoline_run lib/isc/trampoline.c:189
Mutex M1 (0x000000000030) created at:
#0 pthread_mutex_init ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1220
#1 isc__mutex_init lib/isc/mutex.c:49
#2 dns_resolver_create lib/dns/resolver.c:10943
#3 dns_view_createresolver lib/dns/view.c:876
#4 configure_view bin/named/server.c:4947
#5 load_configuration bin/named/server.c:9570
#6 run_server bin/named/server.c:10307
#7 task_run lib/isc/task.c:815
#8 isc_task_run lib/isc/task.c:896
#9 isc__nm_async_task netmgr/netmgr.c:848
#10 process_netievent netmgr/netmgr.c:920
#11 process_queue netmgr/netmgr.c:1013
#12 process_all_queues netmgr/netmgr.c:767
#13 async_cb netmgr/netmgr.c:796
#14 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163
#15 isc__trampoline_run lib/isc/trampoline.c:189
Mutex M2 (0x000000000046) created at:
#0 pthread_rwlock_init ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1313
#1 isc_rwlock_init lib/isc/rwlock.c:40
#2 dns_rbtdb_create lib/dns/rbtdb.c:9428
#3 dns_db_create lib/dns/db.c:120
#4 cache_create_db lib/dns/cache.c:172
#5 dns_cache_create lib/dns/cache.c:254
#6 configure_view bin/named/server.c:4890
#7 load_configuration bin/named/server.c:9570
#8 run_server bin/named/server.c:10307
#9 task_run lib/isc/task.c:815
#10 isc_task_run lib/isc/task.c:896
#11 isc__nm_async_task netmgr/netmgr.c:848
#12 process_netievent netmgr/netmgr.c:920
#13 process_queue netmgr/netmgr.c:1013
#14 process_all_queues netmgr/netmgr.c:767
#15 async_cb netmgr/netmgr.c:796
#16 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163
#17 isc__trampoline_run lib/isc/trampoline.c:189
Mutex M3 (0x000000000054) created at:
#0 pthread_mutex_init ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1220
#1 isc__mutex_init lib/isc/mutex.c:49
#2 dns_resolver_create lib/dns/resolver.c:10943
#3 dns_view_createresolver lib/dns/view.c:876
#4 configure_view bin/named/server.c:4947
#5 load_configuration bin/named/server.c:9570
#6 run_server bin/named/server.c:10307
#7 task_run lib/isc/task.c:815
#8 isc_task_run lib/isc/task.c:896
#9 isc__nm_async_task netmgr/netmgr.c:848
#10 process_netievent netmgr/netmgr.c:920
#11 process_queue netmgr/netmgr.c:1013
#12 process_all_queues netmgr/netmgr.c:767
#13 async_cb netmgr/netmgr.c:796
#14 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163
#15 isc__trampoline_run lib/isc/trampoline.c:189
Mutex M4 (0x000000000055) created at:
#0 pthread_rwlock_init ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1313
#1 isc_rwlock_init lib/isc/rwlock.c:40
#2 dns_rbtdb_create lib/dns/rbtdb.c:9491
#3 dns_db_create lib/dns/db.c:120
#4 cache_create_db lib/dns/cache.c:172
#5 dns_cache_create lib/dns/cache.c:254
#6 configure_view bin/named/server.c:4890
#7 load_configuration bin/named/server.c:9570
#8 run_server bin/named/server.c:10307
#9 task_run lib/isc/task.c:815
#10 isc_task_run lib/isc/task.c:896
#11 isc__nm_async_task netmgr/netmgr.c:848
#12 process_netievent netmgr/netmgr.c:920
#13 process_queue netmgr/netmgr.c:1013
#14 process_all_queues netmgr/netmgr.c:767
#15 async_cb netmgr/netmgr.c:796
#16 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163
#17 isc__trampoline_run lib/isc/trampoline.c:189
Thread T1 (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:962
#1 isc_thread_create lib/isc/thread.c:73
#2 isc__netmgr_create netmgr/netmgr.c:311
#3 isc_managers_create lib/isc/managers.c:31
#4 create_managers bin/named/main.c:1033
#5 setup bin/named/main.c:1304
#6 main bin/named/main.c:1576
Thread T2 (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:962
#1 isc_thread_create lib/isc/thread.c:73
#2 isc__netmgr_create netmgr/netmgr.c:311
#3 isc_managers_create lib/isc/managers.c:31
#4 create_managers bin/named/main.c:1033
#5 setup bin/named/main.c:1304
#6 main bin/named/main.c:1576
SUMMARY: ThreadSanitizer: data race lib/dns/rbtdb.c:1474 in node_createdata
```April 2023 (9.16.40, 9.16.40-S1, 9.18.14, 9.18.14-S1, 9.19.12)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3927nslookup command blocking2023-03-07T06:37:36Zwu jianyongnslookup command blocking<!--
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!
-->
### Summary
We found that the nslookup command occasionally blocks after bind-utils 9.16 is installed on Euler-based 22.03 images
### BIND version used
bind-utils 9.16
### Steps to reproduce
Install bind-utils 9.16 on Euler 22.03 base image using binaries, and run nslookup xxx(domain name). Repeat several times to find the blocking problem
### What is the current *bug* behavior?
(What actually happens.)
### What is the expected *correct* behavior?
(What you should see instead.)
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)https://gitlab.isc.org/isc-projects/bind9/-/issues/3926dns_qp fuzz test is failing to build under Clusterfuzz2023-04-11T17:33:46ZMark Andrewsdns_qp fuzz test is failing to build under Clusterfuzz```
Step #3 - "compile-afl-address-x86_64": depbase=`echo dns_qp.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
Step #3 - "compile-afl-address-x86_64": /src/aflplusplus/afl-clang-fast -DHAVE_CONFIG_H -I. -I.. -U_FORTIFY_SOURCE -D_FORTIFY_SOURC...```
Step #3 - "compile-afl-address-x86_64": depbase=`echo dns_qp.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
Step #3 - "compile-afl-address-x86_64": /src/aflplusplus/afl-clang-fast -DHAVE_CONFIG_H -I. -I.. -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -DISC_MEM_DEFAULTFILL=1 -DISC_MEM_TRACKLINES=1 -DISC_LIST_CHECKINIT=1 -DISC_STATS_CHECKUNDERFLOW=1 -DDNS_RBTDB_STRONG_RWLOCK_CHECK=1 -include ../config.h -I./include -I../include -I../lib/isc/include -I../lib/isc/include -I../lib/dns/include -I../lib/dns/include -DFUZZDIR=\"/src/bind9/fuzz\" -Wall -Wextra -Wwrite-strings -Wpointer-arith -Wno-missing-field-initializers -Wformat -Wshadow -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=format-security -Werror=parentheses -Werror=implicit -Werror=strict-prototypes -Werror=vla -fno-strict-aliasing -fno-delete-null-pointer-checks -fdiagnostics-show-option -Werror -Wno-vla -O1 -fno-omit-frame-pointer -gline-tables-only -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -fsanitize=address -fsanitize-address-use-after-scope -pthread -MT dns_qp.o -MD -MP -MF $depbase.Tpo -c -o dns_qp.o dns_qp.c &&\
Step #3 - "compile-afl-address-x86_64": mv -f $depbase.Tpo $depbase.Po
Step #3 - "compile-afl-address-x86_64": �[1mdns_qp.c:29:10: �[0m�[0;1;31mfatal error: �[0m�[1m'qp_p.h' file not found�[0m
```
Looking at fuzz/Makefile.am `dns_qp` and `dns_qpkey_name` are bracketed by `if HAVE_CMOCKA`/`if HAVE_CMOCKA` which sets up the include paths to find `qp_p.h`. On a quick examination I can't see a reason for the condition.April 2023 (9.16.40, 9.16.40-S1, 9.18.14, 9.18.14-S1, 9.19.12)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3925system test `serve-stale` doesn't get refreshed answer when expected2023-03-16T11:04:11ZTom Krizeksystem test `serve-stale` doesn't get refreshed answer when expectedJob [#3214712](https://gitlab.isc.org/isc-private/bind9/-/jobs/3214712) failed with:
```
I:serve-stale:check stale data.example TXT was refreshed (stale-answer-client-timeout 0 stale-refresh-time 4) (183)
I:serve-stale:failed
```
The t...Job [#3214712](https://gitlab.isc.org/isc-private/bind9/-/jobs/3214712) failed with:
```
I:serve-stale:check stale data.example TXT was refreshed (stale-answer-client-timeout 0 stale-refresh-time 4) (183)
I:serve-stale:failed
```
The test was expecting a fresh answer, but it got a stale one instead:
```
; <<>> DiG 9.18.13-S1 <<>> +time +tries -p 14092 @10.53.0.3 data.example TXT
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62349
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 8c969d3b5a853b08010000006405d40e4781607af7f2ae49 (good)
; EDE: 3 (Stale Answer): (stale data prioritized over lookup)
;; QUESTION SECTION:
;data.example. IN TXT
;; ANSWER SECTION:
data.example. 3 IN TXT "A text record with a 2 second ttl"
;; Query time: 23 msec
;; SERVER: 10.53.0.3#14092(10.53.0.3) (UDP)
;; WHEN: Mon Mar 06 11:52:46 UTC 2023
;; MSG SIZE rcvd: 155
```
Saw this in ~"v9.18", but the exact same test is present in other branches, so I assume they're affected as well.April 2023 (9.16.40, 9.16.40-S1, 9.18.14, 9.18.14-S1, 9.19.12)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3924missing messages in `dnstap` system test after query failure2023-03-13T12:01:09ZTom Krizekmissing messages in `dnstap` system test after query failureIn job [#3215476](https://gitlab.isc.org/isc-private/bind9/-/jobs/3215476), the tests expects two UDP messages in the dnstap output - `CLIENT_QUERY` and `CLIENT_RESPONSE` after querying for `a.example`. The [`dnstap.out`](https://gitlab....In job [#3215476](https://gitlab.isc.org/isc-private/bind9/-/jobs/3215476), the tests expects two UDP messages in the dnstap output - `CLIENT_QUERY` and `CLIENT_RESPONSE` after querying for `a.example`. The [`dnstap.out`](https://gitlab.isc.org/isc-private/bind9/-/jobs/3215476/artifacts/file/bin/tests/system/dnstap/dnstap.out) doesn't contain any messages.
```
I:dnstap:checking reopened unix socket message counts
I:dnstap:checking UDP message counts
I:dnstap:ns4 0 expected 2
I:dnstap:failed
I:dnstap:checking TCP message counts
I:dnstap:checking AUTH_QUERY message counts
I:dnstap:checking AUTH_RESPONSE message counts
I:dnstap:checking CLIENT_QUERY message counts
I:dnstap:ns4 0 expected 1
I:dnstap:failed
I:dnstap:checking CLIENT_RESPONSE message counts
I:dnstap:ns4 0 expected 1
I:dnstap:failed
```
Inspecting the [`ns4/named.run`](https://gitlab.isc.org/isc-private/bind9/-/jobs/3215476/artifacts/file/bin/tests/system/dnstap/ns4/named.run), it looks like reopening the dnstap socket happened as expected. Afterwards, a query for a.example was received. For some reason, the query failed to resolve. It looks like before the server had a chance to respond to the query, it was shut down. The [`dig.out`](https://gitlab.isc.org/isc-private/bind9/-/jobs/3215476/artifacts/file/bin/tests/system/dnstap/dnstap.out) is also empty.
```
06-Mar-2023 14:48:09.490 received control channel command 'dnstap -reopen'
06-Mar-2023 14:48:09.490 reopening dnstap destination 'dnstap.out'
06-Mar-2023 14:48:09.550 client @0x7f1bed89ff68 10.53.0.1#59720: UDP request
06-Mar-2023 14:48:09.550 query client=0x7f1bed89ff68 thread=0x7f1c197ff700(a.example/A): client attr:0x2302, query attr:0x703, restarts:0, origqname:a.example, timer:0, authdb:0, referral:0
06-Mar-2023 14:48:09.550 query client=0x7f1bed89ff68 thread=0x7f1c197ff700(a.example/A): query_gotanswer: unexpected error: failure
06-Mar-2023 14:48:09.554 client @0x7f1bed89ff68 10.53.0.1#59720 (a.example): query failed (failure) for a.example/IN/A at query.c:7779
06-Mar-2023 14:48:16.306 shutting down
06-Mar-2023 14:48:16.310 client @0x7f1bed89ff68 10.53.0.1#59720: freeing client
06-Mar-2023 14:48:16.310 query client=0x7f1bed89ff68 thread=0x7f1c20fff700(<unknown-query>): query_reset
06-Mar-2023 14:48:16.322 closing dnstap
```April 2023 (9.16.40, 9.16.40-S1, 9.18.14, 9.18.14-S1, 9.19.12)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3923timing issue with incoming XoT check in `doth` system test2023-03-09T10:42:44ZTom Krizektiming issue with incoming XoT check in `doth` system testIn job [#3214134](https://gitlab.isc.org/isc-private/bind9/-/jobs/3214134):
```
I:doth:testing incoming XoT functionality (from the first secondary, StrictTLS via specified IPv6) (5)
I:doth:failed
```
The check failed because the file ...In job [#3214134](https://gitlab.isc.org/isc-private/bind9/-/jobs/3214134):
```
I:doth:testing incoming XoT functionality (from the first secondary, StrictTLS via specified IPv6) (5)
I:doth:failed
```
The check failed because the file `ns2/example6.db` didn't exist at the time when it's checked (which happens right after client dig AXFR succeeds). The file is present in the artifacts. From the log, it seems that the file was written shortly after the client AXFR has completed.
```
06-Mar-2023 09:32:09.973 zone example6/IN: Transfer started.
06-Mar-2023 09:32:10.301 zone example6/IN: zone transfer finished: success
06-Mar-2023 09:32:10.301 zone_dump: zone example6/IN: enter
06-Mar-2023 09:32:11.789 client @0x7fe9ab435d68 10.53.0.10#44113 (example6): AXFR request
06-Mar-2023 09:32:11.801 client @0x7fe9ab435d68 10.53.0.10#44113 (example6): transfer of 'example6/IN': AXFR ended: 5 messages, 2676 records, 55815 bytes, 0.011 secs (5074090 bytes/sec) (serial 1397051952)
06-Mar-2023 09:32:12.409 zone_gotwritehandle: zone example6/IN: enter
06-Mar-2023 09:32:12.421 dump_done: zone example6/IN: enter
06-Mar-2023 09:32:12.421 zone_journal_compact: zone example6/IN: target journal size 53044
```
Possible fix: Add retry to the file check.April 2023 (9.16.40, 9.16.40-S1, 9.18.14, 9.18.14-S1, 9.19.12)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3922Release date in generated man pages is not replaced correctly2023-03-08T16:56:13ZTom KrizekRelease date in generated man pages is not replaced correctlyWhen the tarball is generated, the manpage templates incorrectly contain `@RELEASEDATE@` instead of `@RELEASE_DATE@`. During the build, this string is not replaced with the actual release date, since the variable name is different.
This...When the tarball is generated, the manpage templates incorrectly contain `@RELEASEDATE@` instead of `@RELEASE_DATE@`. During the build, this string is not replaced with the actual release date, since the variable name is different.
This was introduced by the recently merged https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7518/diffs?commit_id=18b7ba3ea3e49cf9bf62379b3c00663d5b2a8830.March 2023 (9.16.39, 9.16.39-S1, 9.18.13, 9.18.13-S1, 9.19.11)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3921CPU get abnormally high and thread get stucked2023-03-06T05:38:38ZMario MaCPU get abnormally high and thread get stuckedsometimes my DNS server CPU rise to 800% , which is normally 100% , here is the rndc status and pstack output
rndc status
version: BIND 9.16.4 (Stable Release) <id:0849b42> (i don't know)
running on bjht17876: Linux x86_64 3.10.0-...sometimes my DNS server CPU rise to 800% , which is normally 100% , here is the rndc status and pstack output
rndc status
version: BIND 9.16.4 (Stable Release) <id:0849b42> (i don't know)
running on bjht17876: Linux x86_64 3.10.0-957.el7.x86_64 #1 SMP Thu Nov 8 23:39:32 UTC 2018
boot time: Wed, 01 Mar 2023 14:02:22 GMT
last configured: Mon, 06 Mar 2023 03:45:20 GMT
configuration file: /etc/opt/isc/isc-bind/named.conf
CPUs found: 64
worker threads: 64
UDP listeners per interface: 64
number of zones: 109 (97 automatic)
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 6/102300/102400
tcp clients: 0/150
TCP high-water: 14
server is up and running
[pstacklog](/uploads/cdcc13600dd0fb85118155eab9f6f0fb/pstacklog)
seems there are some locks , but I can not find them, named.run log and rndc recursing seems all ok :
cat named.recursing
;
; Recursing Queries
;
; client 10.37.42.69#15676: id 29223 'msgrecv.f5.ynhtbank.com/AAAA/IN' for msgrecv.ynhtbank.com requesttime 1678073230
; client 10.35.22.18#29524: id 51632 'ns2.dnslog.cn/AAAA/IN' requesttime 1678073234
; client 10.35.64.3#51697: id 4066 'olearning-sgp-replay.myoppo.com.cdn.gl102.com/AAAA/IN' for olearning-sgp-replay.myoppo.com requesttime 1678073237
; client 10.35.22.18#51079: id 8557 '52m7hp.dnslog.cn/AAAA/IN' requesttime 1678073242
; client 10.34.172.48#39630: id 24172 '143.219.241.192.in-addr.arpa/PTR/IN' requesttime 1678073244
; client 10.35.96.6#48324: id 11819 'apiserver-test-sg01-baymax-op-lc-e4eda5fda71edd38.elb.ap-southeast-1.amazonaws.com/A/IN' for apiserver-test-sg01.baymax.oppo.local requesttime 1678073244
;
; Active fetch domains [view: _default]
;
msgrecv.f5.ynhtbank.com.: 1 active (0 spilled, 1 allowed)
elb.ap-southeast-1.amazonaws.com.: 1 active (0 spilled, 1 allowed)
cdn.gl102.com.: 1 active (0 spilled, 1 allowed)
219.241.192.in-addr.arpa.: 1 active (0 spilled, 1 allowed)
dnslog.cn.: 4 active (0 spilled, 7 allowed)
;
; Active fetch domains [view: _bind]
;
; Dump complete
06-Mar-2023 12:04:08.491 network unreachable resolving 'web.congrong-inc.com/AAAA/IN': 2001:502:7094::30#53
06-Mar-2023 12:04:08.491 network unreachable resolving 'web.congrong-inc.com/AAAA/IN': 2001:502:8cc::30#53
06-Mar-2023 12:04:08.720 network unreachable resolving 'xhn-wap.hinews.cn.iname.damddos.com/A/IN': 240e:980:0:1600::118:254#53
06-Mar-2023 12:04:08.720 network unreachable resolving 'xhn-wap.hinews.cn.iname.damddos.com/A/IN': 240e:980:0:1600::116:253#53
06-Mar-2023 12:04:08.822 timed out resolving 'ht-44-29-188.internal.zeku.com/A/IN': 10.123.35.100#53
06-Mar-2023 12:04:09.936 network unreachable resolving 'downloads.sourceforge.net/A/IN': 2600:180a:4001::1#53
06-Mar-2023 12:04:10.075 timed out resolving 'ht-44-29-188.internal.zeku.com/A/IN': 10.123.35.101#53
06-Mar-2023 12:04:10.879 network unreachable resolving 'bj02-train-prod002-node-10-38-32-169/A/IN': 2001:dc3::35#53
06-Mar-2023 12:04:11.043 network unreachable resolving 'h5.yuyouma.com/A/IN': 2402:4e00:1020:1264:0:9136:29bc:87f9#53
06-Mar-2023 12:04:11.043 network unreachable resolving 'h5.yuyouma.com/A/IN': 2402:4e00:1430:1102:0:9136:2b30:e554#53
06-Mar-2023 12:04:11.644 network unreachable resolving 'version.gitlab.com/A/IN': 2a06:98c1:50::ac40:239d#53
06-Mar-2023 12:04:11.792 DNS format error from 8.143.241.249#53 resolving m-gsdk.snssdk.com.queniurc.com/AAAA for 10.37.42.81#54716: Name w.cdngslb.com (SOA) not subdomain of zone queniurc.com -- invalid response
06-Mar-2023 12:04:11.792 FORMERR resolving 'm-gsdk.snssdk.com.queniurc.com/AAAA/IN': 8.143.241.249#53
06-Mar-2023 12:04:11.809 network unreachable resolving '188.80.222.60.adsl-pool.sx.cn/AAAA/IN': 2803:f800:50::6ca2:c14b#53
06-Mar-2023 12:04:11.809 network unreachable resolving '188.80.222.60.adsl-pool.sx.cn/AAAA/IN': 2a06:98c1:50::ac40:20f7#53
06-Mar-2023 12:04:12.441 network unreachable resolving 'jyys.easepictures.art/A/IN': 2001:67c:13cc::1:49#53
06-Mar-2023 12:04:12.574 timed out resolving 'ht-44-24-119.internal.zeku.com/AAAA/IN': 10.123.35.100#53
06-Mar-2023 12:04:13.019 network unreachable resolving 'packagecloud.io/A/IN': 2600:9000:5301:3800::1#53
06-Mar-2023 12:04:13.232 network unreachable resolving 'cdl-lb-1356093980.us-east-1.elb.amazonaws.com/AAAA/IN': 2600:9000:5303:a600::1#53
06-Mar-2023 12:04:13.340 network unreachable resolving 'gt-push.gltxy.xyz/AAAA/IN': 2600:1480:b800::40#53https://gitlab.isc.org/isc-projects/stork/-/issues/1000Use proper logo font on login page2023-05-31T13:01:50ZSlawek FigielUse proper logo font on login pageThe logo on the Stork login page and the [Stork page](https://stork.isc.org/) look different. We should unify it.
Login page:
![image](/uploads/1e2bfb196c2fee35ef4f9ca0fe5e7480/image.png)
Web page:
![image](/uploads/bac635b5dc441c46e...The logo on the Stork login page and the [Stork page](https://stork.isc.org/) look different. We should unify it.
Login page:
![image](/uploads/1e2bfb196c2fee35ef4f9ca0fe5e7480/image.png)
Web page:
![image](/uploads/bac635b5dc441c46e4e7c08ee1ac2dcf/image.png)1.11https://gitlab.isc.org/isc-projects/bind9/-/issues/3917Named should log UV version when starting up2023-04-19T21:26:25ZMark AndrewsNamed should log UV version when starting upWe already report UV version via rndc. This should have been added at the same time.We already report UV version via rndc. This should have been added at the same time.March 2023 (9.16.39, 9.16.39-S1, 9.18.13, 9.18.13-S1, 9.19.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/3916legacy system test fails with "ns1 sent 10 queries to ns7, expected less than...2023-04-06T12:12:15ZMichal Nowaklegacy system test fails with "ns1 sent 10 queries to ns7, expected less than 10"The `legacy` system test [fails](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3207142) on FreeBSD 12.4 on `main`.
The test fails intermittently in about 1 in 5 cases.
```
I:legacy:checking recursive lookup to edns 512 + no tcp serv...The `legacy` system test [fails](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3207142) on FreeBSD 12.4 on `main`.
The test fails intermittently in about 1 in 5 cases.
```
I:legacy:checking recursive lookup to edns 512 + no tcp server does not cause query loops (19)
I:legacy:ns1 sent 10 queries to ns7, expected less than 10
I:legacy:failed
```
The test has been added in !2500.
legacy-n1: [named.run](/uploads/425074a5f6f78131362aa5f7cd97ec2a/named.run)
legacy-ns7: [named.run](/uploads/69a948100ab11c5e528b9c96e0abca10/named.run)April 2023 (9.16.40, 9.16.40-S1, 9.18.14, 9.18.14-S1, 9.19.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/3915dig network issue detection in system tests2023-04-11T20:23:00ZTom Krizekdig network issue detection in system testsWhen investigating a system test failure, an issue is often caused by a network error / time out in dig due to the CI system load / instability. For example, in [#3207126](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3207126) the `se...When investigating a system test failure, an issue is often caused by a network error / time out in dig due to the CI system load / instability. For example, in [#3207126](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3207126) the `serve-stale` test failed due to a query that timed out:
```
$ cat serve-stale/dig.out.test31
;; communications error to 10.53.0.1#13253: timed out
; <<>> DiG 9.19.11-dev <<>> +time +tries -p 13253 @10.53.0.1 data.example TXT
; (1 server found)
;; global options: +cmd
;; no servers could be reached
```
To speed up the investigation of such failures, it'd be useful to grep for common failure patterns in case the test fails, e.g.:
```
$ grep 'timed out' */dig.out*
serve-stale/dig.out.test147:;; communications error to 10.53.0.3#13253: timed out
serve-stale/dig.out.test149:;; communications error to 10.53.0.3#13253: timed out
serve-stale/dig.out.test31:;; communications error to 10.53.0.1#13253: timed out
serve-stale/dig.out.test98:;; communications error to 10.53.0.3#13253: timed out
```
If the information above would be displayed in the job's log, investigation would be quicker. Of course, the context of the test still has to be taken into account, since some tests actually do expect a timeout. Nevertheless, I believe it could be helpful.April 2023 (9.16.40, 9.16.40-S1, 9.18.14, 9.18.14-S1, 9.19.12)https://gitlab.isc.org/isc-projects/stork/-/issues/999Display user-context in lease details2023-08-29T19:08:00ZPeter DaviesDisplay user-context in lease detailsStork uses the leaseX-get commands to retrieve lease information from Kea.
"user-context" is returned but not displayed in Stork. "user-context" may contain interesting information such as RAI (option 82) data.
It would be hel...Stork uses the leaseX-get commands to retrieve lease information from Kea.
"user-context" is returned but not displayed in Stork. "user-context" may contain interesting information such as RAI (option 82) data.
It would be helpful if this data was also displayed.
[RT #21662](https://support.isc.org/Ticket/Display.html?id=21862)1.11Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2780Free lease queue allocator2023-07-17T13:58:22ZMarcin SiodelskiFree lease queue allocatorThe Free lease queue allocator populates leases at the startup or reconfiguration in the server's memory. It installs callbacks in LeaseMgr using #2764. When a DHCP request comes in, it picks the next free lease for a subnet and offers i...The Free lease queue allocator populates leases at the startup or reconfiguration in the server's memory. It installs callbacks in LeaseMgr using #2764. When a DHCP request comes in, it picks the next free lease for a subnet and offers it to the client. When the client requests the lease and the lease is allocated, the callbacks are invoked causing the lease removal from the populated list. Similarly, when the lease is deleted or reclaimed, the lease is put back into the queue.
This ticket doesn't necessarily contain optimizations to inherit populated leases across reconfigurations. It means that the leases will be populated every time, the server is reconfigured. But, that's fine for the first step. We will address it in another ticket.
Also see: https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/free-lease-queues-designkea2.3.7Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2779automatically retry interfaces that previously failed2023-04-06T13:47:30ZThomas Eppersonautomatically retry interfaces that previously failedI am trying to use kea-dhcp4 to listed on two different ethernet connections. One or both of them might not be connected on startup. I am using networkmanager to configure the ethernet ports. I have the ignore-carrier option set in netwo...I am trying to use kea-dhcp4 to listed on two different ethernet connections. One or both of them might not be connected on startup. I am using networkmanager to configure the ethernet ports. I have the ignore-carrier option set in networkmanager so that both ethernet ports are configured with ip addresses as desired.
I would like to have kea-dchp4 respond on both ports. Current behavior is that kea only responds to ports that are connected on startup. Connecting a port after startup does not result in kea listening on that ethernet port.
In the log, I see the following:
2022-12-20 19:08:38.634 WARN [kea-dhcp4.dhcpsrv/487.281473514119200] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface end1 is not runninghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3911crash on reconfig with duplicated zone name in zone catalog vs. named.conf2023-03-01T15:59:23ZPetr Špačekpspacek@isc.orgcrash on reconfig with duplicated zone name in zone catalog vs. named.conf### Summary
Run-time addition of zone into named.conf causes crash if the same zone is present in a catalog zone.
### BIND version used
* ~"Affects v9.16": v9_16_34
* ~"Affects v9.18": 2f808b76e5208a39cc17d183e053254547597ea1
* ~"Affe...### Summary
Run-time addition of zone into named.conf causes crash if the same zone is present in a catalog zone.
### BIND version used
* ~"Affects v9.16": v9_16_34
* ~"Affects v9.18": 2f808b76e5208a39cc17d183e053254547597ea1
* ~"Affects v9.19": f6f525132b073df731609ce5fc3ae0b0639f897b
### Steps to reproduce
1. Define zone in a catalog, e.g. [catalog.db](/uploads/697e9d4366c1975f7eab6ca0752995b6/catalog.db) [empty.db](/uploads/16f5396fecf9b13ebd3646a612d5151b/empty.db)
2. Start primary with this config: [primary.conf](/uploads/470b3a11065f2d989ec562c4c7ea6b6a/primary.conf)
3. Configure secondary with catalog: [named.conf](/uploads/f98ebb6226861ab9f891a49b948010b6/named.conf)
4. Start secondary
5. On the secondary, uncomment duplicate zone definition as non-catalog secondary zone (I did not try other types)
6. On the secondary, run `rndc reconfig`
### What is the current *bug* behavior?
:boom:
```
zt.c:166: REQUIRE((__builtin_expect(!!((zt) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(zt))->magic == ((('Z') << 24 | ('T') << 16 | ('b') << 8 | ('l')))), 1))) failed, back trace
```
```
(gdb) bt
#0 0x00007f808410b8ec in ?? () from /usr/lib/libc.so.6
#1 0x00007f80840bcea8 in raise () from /usr/lib/libc.so.6
#2 0x00007f80840a653d in abort () from /usr/lib/libc.so.6
#3 0x0000556161c1bc0a in assertion_failed[cold] ()
#4 0x0000556161e2c7da in isc_assertion_failed ()
#5 0x0000556161df047a in dns_zt_find ()
#6 0x0000556161ca48bf in dns_catz_zones_merge ()
#7 0x0000556161ca8783 in dns_catz_update_from_db ()
#8 0x0000556161ca8938 in dns_catz_update_taskaction ()
#9 0x0000556161e5cc81 in isc_task_run ()
#10 0x0000556161e4666e in process_netievent ()
#11 0x0000556161e46898 in process_queue ()
#12 0x0000556161e47233 in async_cb ()
#13 0x00007f8084278363 in uv__async_io (loop=0x5561622a1400,
w=<optimized out>, events=<optimized out>) at src/unix/async.c:163
#14 0x00007f808428ac23 in uv__io_poll (loop=loop@entry=0x5561622a1400,
timeout=-1) at src/unix/epoll.c:374
#15 0x00007f8084278d47 in uv_run (loop=0x5561622a1400, mode=UV_RUN_DEFAULT)
at src/unix/core.c:406
#16 0x0000556161e46b39 in nm_thread ()
#17 0x0000556161e5efd5 in isc.trampoline_run ()
```
### What is the expected *correct* behavior?
Good question. I'm not sure which zone definition should win, but at least it should not crash.March 2023 (9.16.39, 9.16.39-S1, 9.18.13, 9.18.13-S1, 9.19.11)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3910CID 442819 442818 442817: Various Coverity Scan issues in qp-trie tests2023-04-11T20:34:58ZMichal NowakCID 442819 442818 442817: Various Coverity Scan issues in qp-trie testsCoverity Scan claims the following issues in qp-trie tests on `main`.
```
*** CID 442819: Insecure data handling (TAINTED_SCALAR)
/tests/libtest/isc.c: 84 in setup_loopmgr()
78 } else {
79 /* We always need at least two loo...Coverity Scan claims the following issues in qp-trie tests on `main`.
```
*** CID 442819: Insecure data handling (TAINTED_SCALAR)
/tests/libtest/isc.c: 84 in setup_loopmgr()
78 } else {
79 /* We always need at least two loops for some of the tests */
80 workers = isc_os_ncpus() + 1;
81 }
82 INSIST(workers != 0);
83
>>> CID 442819: Insecure data handling (TAINTED_SCALAR)
>>> Passing tainted expression "workers" to "isc_loopmgr_create", which uses it as an offset.
84 isc_loopmgr_create(mctx, workers, &loopmgr);
85 mainloop = isc_loop_main(loopmgr);
86
87 return (0);
88 }
89
```
```
*** CID 442818: Error handling issues (CHECKED_RETURN)
/tests/bench/load-names.c: 130 in new_rbt()
124 * rbt
125 */
126
127 static void *
128 new_rbt(isc_mem_t *mem) {
129 dns_rbt_t *rbt = NULL;
>>> CID 442818: Error handling issues (CHECKED_RETURN)
>>> Calling "dns_rbt_create" without checking return value (as is done elsewhere 15 out of 16 times).
130 dns_rbt_create(mem, NULL, NULL, &rbt);
131 return (rbt);
132 }
133
134 static isc_result_t
135 add_rbt(void *rbt, size_t count) {
```
```
*** CID 442817: Memory - illegal accesses (OVERRUN)
/tests/libtest/qp.c: 82 in qp_test_keytoname()
76 /* Scan the key looking for label boundaries */
77 for (offset = 0; offset < 512; offset++) {
78 INSIST(key[offset] >= SHIFT_NOBYTE &&
79 key[offset] < SHIFT_OFFSET);
80 INSIST(loc < 128);
81 if (key[offset] == SHIFT_NOBYTE) {
>>> CID 442817: Memory - illegal accesses (OVERRUN)
>>> Overrunning array of 512 bytes at byte offset 512 by dereferencing pointer "key + (offset + 1UL)".
82 if (key[offset + 1] == SHIFT_NOBYTE) {
83 locs[loc] = offset + 1;
84 break;
85 }
86 locs[loc++] = offset + 1;
87 } else if (offset == 0) {
```April 2023 (9.16.40, 9.16.40-S1, 9.18.14, 9.18.14-S1, 9.19.12)Tony FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3909CID 442816: Concurrent data access violations in lib/dns/zone.c2023-03-01T09:50:05ZMichal NowakCID 442816: Concurrent data access violations in lib/dns/zone.cCoverity Scan infers a missing lock in `lib/dns/zone.c` on `v9_18` from how we used it before.
The culprit seems to be !7620.
```
*** CID 442816: Concurrent data access violations (MISSING_LOCK)
/lib/dns/zone.c: 17886 in zone_loaddon...Coverity Scan infers a missing lock in `lib/dns/zone.c` on `v9_18` from how we used it before.
The culprit seems to be !7620.
```
*** CID 442816: Concurrent data access violations (MISSING_LOCK)
/lib/dns/zone.c: 17886 in zone_loaddone()
17880 DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_THAW);
17881 if (inline_secure(zone)) {
17882 UNLOCK_ZONE(zone->raw);
17883 } else if (secure != NULL) {
17884 UNLOCK_ZONE(secure);
17885 }
>>> CID 442816: Concurrent data access violations (MISSING_LOCK)
>>> Accessing "zone->locked" without holding lock "dns_zone.lock". Elsewhere, "dns_zone.locked" is accessed with "dns_zone.lock" held 354 out of 371 times.
17886 UNLOCK_ZONE(zone);
17887
17888 (void)dns_db_endload(load->db, &load->callbacks);
17889
17890 LOCK_ZONE(zone);
17891 zone_idetach(&load->callbacks.zone);
```March 2023 (9.16.39, 9.16.39-S1, 9.18.13, 9.18.13-S1, 9.19.11)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3907ThreadSanitizer: data race lib/dns/rbtdb.c:1365 in newversion2023-03-02T20:17:04ZArаm SаrgsyаnThreadSanitizer: data race lib/dns/rbtdb.c:1365 in newversionTSAN report during the `mkeys` system test on commit 1d79b314 (based on `9_16`): https://gitlab.isc.org/isc-projects/bind9/-/jobs/3201599
```
==================
WARNING: ThreadSanitizer: data race (pid=23059)
Read of size 1 at 0x7b540...TSAN report during the `mkeys` system test on commit 1d79b314 (based on `9_16`): https://gitlab.isc.org/isc-projects/bind9/-/jobs/3201599
```
==================
WARNING: ThreadSanitizer: data race (pid=23059)
Read of size 1 at 0x7b54000214e4 by thread T10 (mutexes: write M1109428466744296080):
#0 newversion /builds/isc-projects/bind9/lib/dns/rbtdb.c:1365 (libdns-9.16.39-dev.so+0x103c4a)
#1 dns_db_newversion /builds/isc-projects/bind9/lib/dns/db.c:381 (libdns-9.16.39-dev.so+0x60449)
#2 zone_rekey /builds/isc-projects/bind9/lib/dns/zone.c:21430 (libdns-9.16.39-dev.so+0x22d043)
#3 zone_maintenance /builds/isc-projects/bind9/lib/dns/zone.c:11447 (libdns-9.16.39-dev.so+0x230c97)
#4 zone_timer /builds/isc-projects/bind9/lib/dns/zone.c:15066 (libdns-9.16.39-dev.so+0x230c97)
#5 task_run /builds/isc-projects/bind9/lib/isc/task.c:859 (libisc-9.16.39-dev.so+0x641c5)
#6 isc_task_run /builds/isc-projects/bind9/lib/isc/task.c:953 (libisc-9.16.39-dev.so+0x641c5)
#7 isc__nm_async_task /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:871 (libisc-9.16.39-dev.so+0x3c472)
#8 process_netievent /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:943 (libisc-9.16.39-dev.so+0x446f6)
#9 process_queue /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:1009 (libisc-9.16.39-dev.so+0x45000)
#10 process_all_queues /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:790 (libisc-9.16.39-dev.so+0x45ba3)
#11 async_cb /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:819 (libisc-9.16.39-dev.so+0x45ba3)
#12 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163 (libuv.so.1+0x1118e)
#13 isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:213 (libisc-9.16.39-dev.so+0x6717a)
Previous write of size 1 at 0x7b54000214e4 by thread T8 (mutexes: read M1109709941721006800):
#0 setnsec3parameters /builds/isc-projects/bind9/lib/dns/rbtdb.c:2398 (libdns-9.16.39-dev.so+0x104961)
#1 iszonesecure /builds/isc-projects/bind9/lib/dns/rbtdb.c:2369 (libdns-9.16.39-dev.so+0x104961)
#2 endload /builds/isc-projects/bind9/lib/dns/rbtdb.c:7790 (libdns-9.16.39-dev.so+0x104f76)
#3 dns_db_endload /builds/isc-projects/bind9/lib/dns/db.c:297 (libdns-9.16.39-dev.so+0x60088)
#4 zone_loaddone /builds/isc-projects/bind9/lib/dns/zone.c:17843 (libdns-9.16.39-dev.so+0x23fcbb)
#5 load_quantum /builds/isc-projects/bind9/lib/dns/master.c:3238 (libdns-9.16.39-dev.so+0xa6635)
#6 task_run /builds/isc-projects/bind9/lib/isc/task.c:859 (libisc-9.16.39-dev.so+0x641c5)
#7 isc_task_run /builds/isc-projects/bind9/lib/isc/task.c:953 (libisc-9.16.39-dev.so+0x641c5)
#8 isc__nm_async_task /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:871 (libisc-9.16.39-dev.so+0x3c472)
#9 process_netievent /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:943 (libisc-9.16.39-dev.so+0x446f6)
#10 process_queue /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:1009 (libisc-9.16.39-dev.so+0x45000)
#11 process_all_queues /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:790 (libisc-9.16.39-dev.so+0x45ba3)
#12 async_cb /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:819 (libisc-9.16.39-dev.so+0x45ba3)
#13 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163 (libuv.so.1+0x1118e)
#14 isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:213 (libisc-9.16.39-dev.so+0x6717a)
Location is heap block of size 537 at 0x7b5400021480 allocated by thread T8:
#0 malloc <null> (libtsan.so.2+0x3f618)
#1 default_memalloc /builds/isc-projects/bind9/lib/isc/mem.c:715 (libisc-9.16.39-dev.so+0x37004)
#2 mem_get /builds/isc-projects/bind9/lib/isc/mem.c:624 (libisc-9.16.39-dev.so+0x35c6c)
#3 mem_allocateunlocked /builds/isc-projects/bind9/lib/isc/mem.c:1289 (libisc-9.16.39-dev.so+0x37c3f)
#4 isc___mem_allocate /builds/isc-projects/bind9/lib/isc/mem.c:1309 (libisc-9.16.39-dev.so+0x37c3f)
#5 isc__mem_allocate /builds/isc-projects/bind9/lib/isc/mem.c:2405 (libisc-9.16.39-dev.so+0x3b4cd)
#6 isc___mem_get /builds/isc-projects/bind9/lib/isc/mem.c:1059 (libisc-9.16.39-dev.so+0x3b84d)
#7 isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:2384 (libisc-9.16.39-dev.so+0x3ab4b)
#8 allocate_version /builds/isc-projects/bind9/lib/dns/rbtdb.c:1326 (libdns-9.16.39-dev.so+0xfb085)
#9 dns_rbtdb_create /builds/isc-projects/bind9/lib/dns/rbtdb.c:8834 (libdns-9.16.39-dev.so+0x117760)
#10 dns_db_create /builds/isc-projects/bind9/lib/dns/db.c:120 (libdns-9.16.39-dev.so+0x5f86b)
#11 zone_load /builds/isc-projects/bind9/lib/dns/zone.c:2307 (libdns-9.16.39-dev.so+0x23ef95)
#12 zone_asyncload /builds/isc-projects/bind9/lib/dns/zone.c:2396 (libdns-9.16.39-dev.so+0x23f646)
#13 task_run /builds/isc-projects/bind9/lib/isc/task.c:859 (libisc-9.16.39-dev.so+0x641c5)
#14 isc_task_run /builds/isc-projects/bind9/lib/isc/task.c:953 (libisc-9.16.39-dev.so+0x641c5)
#15 isc__nm_async_task /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:871 (libisc-9.16.39-dev.so+0x3c472)
#16 process_netievent /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:943 (libisc-9.16.39-dev.so+0x446f6)
#17 process_queue /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:1009 (libisc-9.16.39-dev.so+0x45000)
#18 process_all_queues /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:790 (libisc-9.16.39-dev.so+0x45ba3)
#19 async_cb /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:819 (libisc-9.16.39-dev.so+0x45ba3)
#20 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163 (libuv.so.1+0x1118e)
#21 isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:213 (libisc-9.16.39-dev.so+0x6717a)
Mutex M1109428466744296080 is already destroyed.
Mutex M1109709941721006800 is already destroyed.
Thread T10 'isc-net-0009' (tid=23105, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.2+0x5f0e6)
#1 isc_thread_create /builds/isc-projects/bind9/lib/isc/pthreads/thread.c:81 (libisc-9.16.39-dev.so+0x81d01)
#2 isc__netmgr_create /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:355 (libisc-9.16.39-dev.so+0x3ce55)
#3 isc_managers_create /builds/isc-projects/bind9/lib/isc/managers.c:28 (libisc-9.16.39-dev.so+0x34669)
#4 create_managers main.c:1065 (named+0x427ca4)
#5 setup main.c:1390 (named+0x427ca4)
#6 main main.c:1704 (named+0x427ca4)
Thread T8 'isc-net-0007' (tid=23090, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.2+0x5f0e6)
#1 isc_thread_create /builds/isc-projects/bind9/lib/isc/pthreads/thread.c:81 (libisc-9.16.39-dev.so+0x81d01)
#2 isc__netmgr_create /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:355 (libisc-9.16.39-dev.so+0x3ce55)
#3 isc_managers_create /builds/isc-projects/bind9/lib/isc/managers.c:28 (libisc-9.16.39-dev.so+0x34669)
#4 create_managers main.c:1065 (named+0x427ca4)
#5 setup main.c:1390 (named+0x427ca4)
#6 main main.c:1704 (named+0x427ca4)
SUMMARY: ThreadSanitizer: data race /builds/isc-projects/bind9/lib/dns/rbtdb.c:1365 in newversion
==================
```March 2023 (9.16.39, 9.16.39-S1, 9.18.13, 9.18.13-S1, 9.19.11)https://gitlab.isc.org/isc-projects/bind9/-/issues/3905Remove TKEY Diffie-Hellman authentication2023-05-30T08:11:18ZOndřej SurýRemove TKEY Diffie-Hellman authenticationAlthough [draft-eastlake-dnsop-rfc2930bis-tkey](https://datatracker.ietf.org/doc/draft-eastlake-dnsop-rfc2930bis-tkey/) hasn't been finished, I would suggest that we go with the recommendation in the draft:
```
4.2 Diffie-Hellman Exchan...Although [draft-eastlake-dnsop-rfc2930bis-tkey](https://datatracker.ietf.org/doc/draft-eastlake-dnsop-rfc2930bis-tkey/) hasn't been finished, I would suggest that we go with the recommendation in the draft:
```
4.2 Diffie-Hellman Exchanged Keying (Deprecated)
The use of this mode (#2) is NOT RECOMMENDED for the following two
reasons but the specification is still included in Appendix A in case
an implementation is needed for compatibility with old TKEY
implementations. See Section 4.6 on ECDH Exchanged Keying.
The mixing function used does not meet current cryptographic
standards because it uses MD5 [RFC6151].
RSA keys must be excessively long to achieve levels of security
required by current standards.
```June 2023 (9.16.42, 9.16.42-S1, 9.18.16, 9.18.16-S1, 9.19.14)Ondřej SurýOndřej Surý