BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-12-06T18:22:03Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4433Supplied Buffer Too Large in wire_test.c2023-12-06T18:22:03ZEric SesterhennSupplied Buffer Too Large in wire_test.cThe code in wire_test.c does provide an 64*1024 buffer to dns_message_renderbegin(). This might trigger an error in a corner case, where the code is expecting to receive buffers that are not larger than 65536 bytes.
~~~
if (result != IS...The code in wire_test.c does provide an 64*1024 buffer to dns_message_renderbegin(). This might trigger an error in a corner case, where the code is expecting to receive buffers that are not larger than 65536 bytes.
~~~
if (result != ISC_R_SUCCESS) {
INSIST(st.used < 65536);
dns_compress_rollback(
msg->cctx, (uint16_t)st.used);
*(msg->buffer) = st; /* rollback */
msg->buffer->length += msg->reserved;
msg->counts[sectionid] += total;
maybe_clear_ad(msg, sectionid);
return (result);
}
~~~December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4328ThreadSanitizer: data race in dns_tsigkeyring_dump2023-12-06T18:18:29ZOndřej SurýThreadSanitizer: data race in dns_tsigkeyring_dump```
==================
WARNING: ThreadSanitizer: data race (pid=1731304)
Write of size 8 at 0x7b1800000b90 by thread T16:
#0 isc_hashmap_iter_create /home/ondrej/Projects/bind9/lib/isc/hashmap.c:608:20 (libisc-9.19.18-dev.so+0x55c1...```
==================
WARNING: ThreadSanitizer: data race (pid=1731304)
Write of size 8 at 0x7b1800000b90 by thread T16:
#0 isc_hashmap_iter_create /home/ondrej/Projects/bind9/lib/isc/hashmap.c:608:20 (libisc-9.19.18-dev.so+0x55c12) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
#1 dns_tsigkeyring_dump /home/ondrej/Projects/bind9/lib/dns/tsig.c:473:2 (libdns-9.19.18-dev.so+0x2ed639) (BuildId: 0c875e4d1ebe40ad865f17a9c21753da586ae188)
#2 destroy /home/ondrej/Projects/bind9/lib/dns/view.c:239:13 (libdns-9.19.18-dev.so+0x3140c6) (BuildId: 0c875e4d1ebe40ad865f17a9c21753da586ae188)
#3 dns_view_weakdetach /home/ondrej/Projects/bind9/lib/dns/view.c:586:3 (libdns-9.19.18-dev.so+0x313b0c) (BuildId: 0c875e4d1ebe40ad865f17a9c21753da586ae188)
#4 zone_shutdown /home/ondrej/Projects/bind9/lib/dns/zone.c:14515:3 (libdns-9.19.18-dev.so+0x3642dd) (BuildId: 0c875e4d1ebe40ad865f17a9c21753da586ae188)
#5 isc__async_cb /home/ondrej/Projects/bind9/lib/isc/async.c:111:3 (libisc-9.19.18-dev.so+0x46682) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
#6 uv__async_io /home/ondrej/Projects/tsan/libuv/src/unix/async.c:176:5 (libuv.so.1+0x19fb5) (BuildId: 473d7a8bf34342bf61b8e7193e565ce2b7962210)
#7 uv__io_poll /home/ondrej/Projects/tsan/libuv/src/unix/linux.c:1476:11 (libuv.so.1+0x4d289) (BuildId: 473d7a8bf34342bf61b8e7193e565ce2b7962210)
#8 uv_run /home/ondrej/Projects/tsan/libuv/src/unix/core.c:447:5 (libuv.so.1+0x1adee) (BuildId: 473d7a8bf34342bf61b8e7193e565ce2b7962210)
#9 loop_thread /home/ondrej/Projects/bind9/lib/isc/loop.c:282:6 (libisc-9.19.18-dev.so+0x79c40) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
#10 thread_body /home/ondrej/Projects/bind9/lib/isc/thread.c:85:8 (libisc-9.19.18-dev.so+0x9e423) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
#11 thread_run /home/ondrej/Projects/bind9/lib/isc/thread.c:100:14 (libisc-9.19.18-dev.so+0x9e70f) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
Previous write of size 8 at 0x7b1800000b90 by thread T29:
#0 isc_hashmap_iter_create /home/ondrej/Projects/bind9/lib/isc/hashmap.c:608:20 (libisc-9.19.18-dev.so+0x55c12) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
#1 dns_tsigkeyring_dump /home/ondrej/Projects/bind9/lib/dns/tsig.c:473:2 (libdns-9.19.18-dev.so+0x2ed639) (BuildId: 0c875e4d1ebe40ad865f17a9c21753da586ae188)
#2 destroy /home/ondrej/Projects/bind9/lib/dns/view.c:239:13 (libdns-9.19.18-dev.so+0x3140c6) (BuildId: 0c875e4d1ebe40ad865f17a9c21753da586ae188)
#3 dns_view_weakdetach /home/ondrej/Projects/bind9/lib/dns/view.c:586:3 (libdns-9.19.18-dev.so+0x313b0c) (BuildId: 0c875e4d1ebe40ad865f17a9c21753da586ae188)
#4 zone_shutdown /home/ondrej/Projects/bind9/lib/dns/zone.c:14515:3 (libdns-9.19.18-dev.so+0x3642dd) (BuildId: 0c875e4d1ebe40ad865f17a9c21753da586ae188)
#5 isc__async_cb /home/ondrej/Projects/bind9/lib/isc/async.c:111:3 (libisc-9.19.18-dev.so+0x46682) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
#6 uv__async_io /home/ondrej/Projects/tsan/libuv/src/unix/async.c:176:5 (libuv.so.1+0x19fb5) (BuildId: 473d7a8bf34342bf61b8e7193e565ce2b7962210)
#7 uv__io_poll /home/ondrej/Projects/tsan/libuv/src/unix/linux.c:1476:11 (libuv.so.1+0x4d289) (BuildId: 473d7a8bf34342bf61b8e7193e565ce2b7962210)
#8 uv_run /home/ondrej/Projects/tsan/libuv/src/unix/core.c:447:5 (libuv.so.1+0x1adee) (BuildId: 473d7a8bf34342bf61b8e7193e565ce2b7962210)
#9 loop_thread /home/ondrej/Projects/bind9/lib/isc/loop.c:282:6 (libisc-9.19.18-dev.so+0x79c40) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
#10 thread_body /home/ondrej/Projects/bind9/lib/isc/thread.c:85:8 (libisc-9.19.18-dev.so+0x9e423) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
#11 thread_run /home/ondrej/Projects/bind9/lib/isc/thread.c:100:14 (libisc-9.19.18-dev.so+0x9e70f) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
Location is heap block of size 88 at 0x7b1800000b40 allocated by main thread:
#0 malloc <null> (lt-named+0x738dc) (BuildId: a34b7ed3d2c9f1e42cab4821d53fbde3e4c5b946)
#1 mallocx /home/ondrej/Projects/bind9/lib/isc/./jemalloc_shim.h:67:14 (libisc-9.19.18-dev.so+0x8591e) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
#2 mem_get /home/ondrej/Projects/bind9/lib/isc/mem.c:305:8 (libisc-9.19.18-dev.so+0x7f23e) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
#3 isc__mem_get /home/ondrej/Projects/bind9/lib/isc/mem.c:744:8 (libisc-9.19.18-dev.so+0x7f0c6) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
#4 isc_hashmap_create /home/ondrej/Projects/bind9/lib/isc/hashmap.c:210:27 (libisc-9.19.18-dev.so+0x53a20) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
#5 dns_tsigkeyring_create /home/ondrej/Projects/bind9/lib/dns/tsig.c:1589:2 (libdns-9.19.18-dev.so+0x2f49c7) (BuildId: 0c875e4d1ebe40ad865f17a9c21753da586ae188)
#6 dns_view_create /home/ondrej/Projects/bind9/lib/dns/view.c:144:2 (libdns-9.19.18-dev.so+0x3121e6) (BuildId: 0c875e4d1ebe40ad865f17a9c21753da586ae188)
#7 create_view /home/ondrej/Projects/bind9/bin/named/server.c:6425:11 (lt-named+0x141562) (BuildId: a34b7ed3d2c9f1e42cab4821d53fbde3e4c5b946)
#8 load_configuration /home/ondrej/Projects/bind9/bin/named/server.c:9111:12 (lt-named+0x13a831) (BuildId: a34b7ed3d2c9f1e42cab4821d53fbde3e4c5b946)
#9 run_server /home/ondrej/Projects/bind9/bin/named/server.c:9952:2 (lt-named+0x11f465) (BuildId: a34b7ed3d2c9f1e42cab4821d53fbde3e4c5b946)
#10 isc__async_cb /home/ondrej/Projects/bind9/lib/isc/async.c:111:3 (libisc-9.19.18-dev.so+0x46682) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
#11 uv__async_io /home/ondrej/Projects/tsan/libuv/src/unix/async.c:176:5 (libuv.so.1+0x19fb5) (BuildId: 473d7a8bf34342bf61b8e7193e565ce2b7962210)
#12 uv__io_poll /home/ondrej/Projects/tsan/libuv/src/unix/linux.c:1476:11 (libuv.so.1+0x4d289) (BuildId: 473d7a8bf34342bf61b8e7193e565ce2b7962210)
#13 uv_run /home/ondrej/Projects/tsan/libuv/src/unix/core.c:447:5 (libuv.so.1+0x1adee) (BuildId: 473d7a8bf34342bf61b8e7193e565ce2b7962210)
#14 loop_thread /home/ondrej/Projects/bind9/lib/isc/loop.c:282:6 (libisc-9.19.18-dev.so+0x79c40) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
#15 thread_body /home/ondrej/Projects/bind9/lib/isc/thread.c:85:8 (libisc-9.19.18-dev.so+0x9e423) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
#16 isc_thread_main /home/ondrej/Projects/bind9/lib/isc/thread.c:116:2 (libisc-9.19.18-dev.so+0x9e313) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
#17 isc_loopmgr_run /home/ondrej/Projects/bind9/lib/isc/loop.c:454:2 (libisc-9.19.18-dev.so+0x79963) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
#18 main /home/ondrej/Projects/bind9/bin/named/main.c:1580:2 (lt-named+0x115cb2) (BuildId: a34b7ed3d2c9f1e42cab4821d53fbde3e4c5b946)
Thread T16 'isc-loop-0016' (tid=1733466, running) created by main thread at:
#0 pthread_create <null> (lt-named+0x754bb) (BuildId: a34b7ed3d2c9f1e42cab4821d53fbde3e4c5b946)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/thread.c:139:8 (libisc-9.19.18-dev.so+0x9e667) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
#2 isc_loopmgr_run /home/ondrej/Projects/bind9/lib/isc/loop.c:448:3 (libisc-9.19.18-dev.so+0x798e4) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
#3 main /home/ondrej/Projects/bind9/bin/named/main.c:1580:2 (lt-named+0x115cb2) (BuildId: a34b7ed3d2c9f1e42cab4821d53fbde3e4c5b946)
Thread T29 'isc-loop-0029' (tid=1733524, running) created by main thread at:
#0 pthread_create <null> (lt-named+0x754bb) (BuildId: a34b7ed3d2c9f1e42cab4821d53fbde3e4c5b946)
#1 isc_thread_create /home/ondrej/Projects/bind9/lib/isc/thread.c:139:8 (libisc-9.19.18-dev.so+0x9e667) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
#2 isc_loopmgr_run /home/ondrej/Projects/bind9/lib/isc/loop.c:448:3 (libisc-9.19.18-dev.so+0x798e4) (BuildId: 39be444545292c4d1a56c1084e4150ff076e95d7)
#3 main /home/ondrej/Projects/bind9/bin/named/main.c:1580:2 (lt-named+0x115cb2) (BuildId: a34b7ed3d2c9f1e42cab4821d53fbde3e4c5b946)
SUMMARY: ThreadSanitizer: data race /home/ondrej/Projects/bind9/lib/isc/hashmap.c:608:20 in isc_hashmap_iter_create
==================
ThreadSanitizer: reported 1 warnings
```December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4421Remove support for AES-based DNS cookies and AES implementation2023-12-06T18:12:06ZEric SesterhennRemove support for AES-based DNS cookies and AES implementationThe legacy support for AES-based DNS cookies should go, which will resolve following:
> The functions `isc_aes256_crypt()` and `isc_aes192_crypt()` in `lib/isc/aes.c` have no callers besides test code and should be removed.
as we are g...The legacy support for AES-based DNS cookies should go, which will resolve following:
> The functions `isc_aes256_crypt()` and `isc_aes192_crypt()` in `lib/isc/aes.c` have no callers besides test code and should be removed.
as we are going to remove the AES implementation in libisc completely.December 2023 (9.18.21, 9.18.21-S1, 9.19.19)https://gitlab.isc.org/isc-projects/bind9/-/issues/4464BIND can crash with assertion in the situation when a `tls` entry is used mul...2023-12-06T17:24:11ZArtem BoldarievBIND can crash with assertion in the situation when a `tls` entry is used multiple times to establish an outgoing connectionBIND can crash with assertion in the situation when a `tls` entry is used multiple times to establish an outgoing connection to other servers via TLS.
```
04-Dec-2023 13:38:33.746 tls.c:1187: REQUIRE(pstore != ((void *)0) && *pstore != ...BIND can crash with assertion in the situation when a `tls` entry is used multiple times to establish an outgoing connection to other servers via TLS.
```
04-Dec-2023 13:38:33.746 tls.c:1187: REQUIRE(pstore != ((void *)0) && *pstore != ((void *)0)) failed
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.19.19-dev.so(isc_backtrace_log+0x49) [0x7ffff7f4e6d7]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/bin/named/.libs/named() [0x42c0c6]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.19.19-dev.so(isc_assertion_failed+0x31) [0x7ffff7f4e052]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.19.19-dev.so(isc_tls_cert_store_free+0x42) [0x7ffff7f87ebd]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/dns/.libs/libdns-9.19.19-dev.so(dns_transport_get_tlsctx+0x6f1) [0x7ffff7de49f4]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/dns/.libs/libdns-9.19.19-dev.so(+0x696e6) [0x7ffff7c696e6]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/dns/.libs/libdns-9.19.19-dev.so(dns_dispatch_connect+0xb6) [0x7ffff7c69d32]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/dns/.libs/libdns-9.19.19-dev.so(+0x20acf2) [0x7ffff7e0acf2]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/dns/.libs/libdns-9.19.19-dev.so(dns_xfrin_create+0x2c0) [0x7ffff7e09469]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/dns/.libs/libdns-9.19.19-dev.so(+0x255a9b) [0x7ffff7e55a9b]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.19.19-dev.so(isc__async_cb+0x186) [0x7ffff7f4e500]
04-Dec-2023 13:38:33.746 /nix/store/lsp8kyfkyi35shk51alffb4vsll7030q-libuv-1.46.0/lib/libuv.so.1(+0x10543) [0x7ffff7730543]
04-Dec-2023 13:38:33.746 /nix/store/lsp8kyfkyi35shk51alffb4vsll7030q-libuv-1.46.0/lib/libuv.so.1(+0x238e5) [0x7ffff77438e5]
04-Dec-2023 13:38:33.746 /nix/store/lsp8kyfkyi35shk51alffb4vsll7030q-libuv-1.46.0/lib/libuv.so.1(uv_run+0xb0) [0x7ffff77311c0]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.19.19-dev.so(+0x571e0) [0x7ffff7f6c1e0]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.19.19-dev.so(+0x6e669) [0x7ffff7f83669]
04-Dec-2023 13:38:33.746 /home/artem/projects/isc/open/bind9/lib/isc/.libs/libisc-9.19.19-dev.so(+0x6e6ad) [0x7ffff7f836ad]
04-Dec-2023 13:38:33.746 /nix/store/qn3ggz5sf3hkjs2c797xf7nan3amdxmp-glibc-2.38-27/lib/libc.so.6(+0x8b084) [0x7ffff6e62084]
04-Dec-2023 13:38:33.746 /nix/store/qn3ggz5sf3hkjs2c797xf7nan3amdxmp-glibc-2.38-27/lib/libc.so.6(+0x10d60c) [0x7ffff6ee460c]
04-Dec-2023 13:38:33.746 exiting (due to assertion failure)
```
In particular, the problem reveals itself when multiple threads are trying to initialise a transport-specific TLS context and associated data from the context of multiple threads, like in the following situation:
```
tls tls-v1.3 {
protocols { TLSv1.3; };
prefer-server-ciphers yes;
};
zone "example-1" {
type secondary;
primaries port 22168 { 10.53.0.1 tls tls-v1.3; };
file "example-1.db";
allow-transfer { any; };
};
zone "example-2" {
type secondary;
primaries port 22169 { 10.53.0.1 tls tls-v1.3; };
file "example-2.db";
allow-transfer { any; };
};
zone "example-3" {
type secondary;
primaries port 22170 { 10.53.0.1 tls tls-v1.3; };
file "example-3.db";
allow-transfer { any; };
};
```
The error handling code is not correct for this case, as in some cases, freeing a TLS certificate store is not required. In this particular case it can be `NULL`.
The problem _does not_ reveal itself on each run.December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4476CID 469729: Control flow issue in lib/isccfg/kaspconf.c2023-12-06T12:51:25ZMichal NowakCID 469729: Control flow issue in lib/isccfg/kaspconf.cCoverity Scan claims a control flow issue in `lib/isccfg/kaspconf.c` after !8515.
```
*** CID 469729: Control flow issues (UNREACHABLE)
/lib/isccfg/kaspconf.c: 300 in cfg_nsec3param_fromconfig()
294 if (iter != DEFAULT_NSEC3PARAM...Coverity Scan claims a control flow issue in `lib/isccfg/kaspconf.c` after !8515.
```
*** CID 469729: Control flow issues (UNREACHABLE)
/lib/isccfg/kaspconf.c: 300 in cfg_nsec3param_fromconfig()
294 if (iter != DEFAULT_NSEC3PARAM_ITER) {
295 cfg_obj_log(obj, logctx, ISC_LOG_ERROR,
296 "dnssec-policy: nsec3 iterations value %u "
297 "not allowed, must be zero",
298 iter);
299 return (DNS_R_NSEC3ITERRANGE);
>>> CID 469729: Control flow issues (UNREACHABLE)
>>> This code cannot be reached: "return ret;".
300 return (ret);
301 }
302
303 /* Opt-out? */
304 obj = cfg_tuple_get(config, "optout");
305 if (cfg_obj_isboolean(obj)) {
```December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3983dns_zone_t->loadtime is zero after initial AXFR of a secondary zone2023-12-06T09:37:50ZTom Krizekdns_zone_t->loadtime is zero after initial AXFR of a secondary zone### Summary
When a server is configured as a secondary for a zone and no backing zone file exists yet, the initial AXFR of the zone from the primary doesn't set the `loadtime` for the zone on the secondary. Once the secondary is restart...### Summary
When a server is configured as a secondary for a zone and no backing zone file exists yet, the initial AXFR of the zone from the primary doesn't set the `loadtime` for the zone on the secondary. Once the secondary is restarted, and the zone can be loaded from the backing file, `loadtime` is set correctly.
### Steps to reproduce
The `statschannel` test already has a check for this behavior, but it was [disabled](7522583b5756924e697f10633d7d5d476176c594) to avoid a persistent failure. Uncomment the `assert` statements in `check_loadtime()` and run `pytest -k test_zone_timers_secondary_json`.
### What is the current *bug* behavior?
If secondary is queried for the zones through the stats channel, `loadtime` is set to `1970-01-01T00:00:00Z`:
```
...
"zones":[
{
"name":"example",
"class":"IN",
"serial":1,
"type":"secondary",
"loaded":"1970-01-01T00:00:00Z",
"expires":"2023-04-21T12:24:32Z",
"refresh":"2023-03-31T12:29:25Z"
}
]
...
```
### What is the expected *correct* behavior?
`loaded` should be the time when the initial AXFR completes.
### Relevant configuration files
- [ns1 (primary)](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/bin/tests/system/statschannel/ns1/named.conf.in)
- [ns3 (secondary)](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/bin/tests/system/statschannel/ns3/named.conf.in)December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/4474Unexpected hash table miss in ixfr system test2023-12-06T05:44:44ZMark AndrewsUnexpected hash table miss in ixfr system testhttps://gitlab.isc.org/isc-private/bind9/-/jobs/3848787
```
2023-12-06 02:05:43 INFO:ixfr I:ixfr_tmp_aodmwieh:testing initial AXFR (1)
2023-12-06 02:05:44 INFO:ixfr I:ixfr_tmp_aodmwieh:ns1 server reload successful
2023-12-06 02:...https://gitlab.isc.org/isc-private/bind9/-/jobs/3848787
```
2023-12-06 02:05:43 INFO:ixfr I:ixfr_tmp_aodmwieh:testing initial AXFR (1)
2023-12-06 02:05:44 INFO:ixfr I:ixfr_tmp_aodmwieh:ns1 server reload successful
2023-12-06 02:05:44 INFO:ixfr I:ixfr_tmp_aodmwieh:testing successful IXFR (2)
2023-12-06 02:05:45 INFO:ixfr I:ixfr_tmp_aodmwieh:ns1 zone refresh queued
2023-12-06 02:05:47 INFO:ixfr I:ixfr_tmp_aodmwieh:failed
2023-12-06 02:05:47 INFO:ixfr I:ixfr_tmp_aodmwieh:testing AXFR fallback after IXFR failure (not exact error) (3)
2023-12-06 02:05:48 INFO:ixfr I:ixfr_tmp_aodmwieh:ns1 zone refresh queued
2023-12-06 02:05:51 INFO:ixfr I:ixfr_tmp_aodmwieh:failed
2023-12-06 02:05:51 INFO:ixfr I:ixfr_tmp_aodmwieh:testing AXFR fallback after IXFR failure (bad SOA owner) (4)
2023-12-06 02:05:51 INFO:ixfr I:ixfr_tmp_aodmwieh:ns1 zone refresh queued
2023-12-06 02:06:00 INFO:ixfr I:ixfr_tmp_aodmwieh:timed out waiting for version 4 of zone nil. to be transferred
2023-12-06 02:06:00 INFO:ixfr I:ixfr_tmp_aodmwieh:ns1 zone refresh queued
2023-12-06 02:06:00 INFO:ixfr I:ixfr_tmp_aodmwieh:failed
2023-12-06 02:06:00 INFO:ixfr I:ixfr_tmp_aodmwieh:testing ixfr-from-differences option (5)
2023-12-06 02:06:01 INFO:ixfr I:ixfr_tmp_aodmwieh:ns3 server reload successful
2023-12-06 02:06:02 INFO:ixfr I:ixfr_tmp_aodmwieh:failed
2023-12-06 02:06:02 INFO:ixfr I:ixfr_tmp_aodmwieh:testing 'request-ixfr no' option inheritance from view (6)
2023-12-06 02:06:04 INFO:ixfr I:ixfr_tmp_aodmwieh:ns3 server reload successful
2023-12-06 02:06:05 INFO:ixfr I:ixfr_tmp_aodmwieh:testing 'request-ixfr yes' option inheritance from view (7)
2023-12-06 02:06:06 INFO:ixfr I:ixfr_tmp_aodmwieh:ns3 server reload successful
2023-12-06 02:06:07 INFO:ixfr I:ixfr_tmp_aodmwieh:testing DiG's handling of a multi message AXFR style IXFR response (8)
2023-12-06 02:06:07 INFO:ixfr I:ixfr_tmp_aodmwieh:test 'dig +notcp ixfr=<value>' vs 'dig ixfr=<value> +notcp' vs 'dig ixfr=<value>' (9)
2023-12-06 02:06:07 INFO:ixfr I:ixfr_tmp_aodmwieh:check estimated IXFR size (10)
2023-12-06 02:06:12 INFO:ixfr I:ixfr_tmp_aodmwieh:test 'provide-ixfr no;' (serial < current) (11)
2023-12-06 02:06:12 INFO:ixfr I:ixfr_tmp_aodmwieh:test 'provide-ixfr no;' (serial = current) (12)
2023-12-06 02:06:12 INFO:ixfr I:ixfr_tmp_aodmwieh:test 'provide-ixfr no;' (serial > current) (13)
2023-12-06 02:06:12 INFO:ixfr I:ixfr_tmp_aodmwieh:checking whether dig calculates IXFR statistics correctly (14)
2023-12-06 02:06:12 INFO:ixfr I:ixfr_tmp_aodmwieh:checking whether named calculates incoming IXFR statistics correctly (15)
2023-12-06 02:06:12 INFO:ixfr I:ixfr_tmp_aodmwieh:checking whether named calculates outgoing IXFR statistics correctly (16)
2023-12-06 02:06:12 INFO:ixfr I:ixfr_tmp_aodmwieh:testing fallback to AXFR when max-ixfr-ratio is exceeded (17)
2023-12-06 02:06:13 INFO:ixfr I:ixfr_tmp_aodmwieh:ns3 server reload successful
2023-12-06 02:06:17 INFO:ixfr I:ixfr_tmp_aodmwieh:exit status: 4
```
```
06-Dec-2023 02:05:45.901 queue_xfrin: zone nil/IN: enter
06-Dec-2023 02:05:45.901 zone nil/IN: Transfer started.
06-Dec-2023 02:05:45.901 req_destroy: request 0x7f232dcf5000
06-Dec-2023 02:05:45.901 zone nil/IN: requesting IXFR from 10.53.0.2#22502
06-Dec-2023 02:05:45.901 dispatchmgr 0x7f23359988c0: dns_dispatch_createtcp: created TCP dispatch 0x7f232dcfa540 for 10.53.0.1#0
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP response 0x7f232dc2a280: connecting from 10.53.0.1#0 to 10.53.0.2#22502, timeout 30000
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: connected from 10.53.0.1#0 to 10.53.0.2#22502: success
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP response 0x7f232dc2a280: start reading
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP reading without response from 0x7f232dcfa8c0
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP response 0x7f232dc2a280: connect callback: success
06-Dec-2023 02:05:45.901 0x7f232dd01000: transfer of 'nil/IN' from 10.53.0.2#22502: connected using 10.53.0.2#22502
06-Dec-2023 02:05:45.901 0x7f232dd01000: transfer of 'nil/IN' from 10.53.0.2#22502: requesting IXFR for serial 1
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP response 0x7f232dc2a280: sending
06-Dec-2023 02:05:45.901 0x7f232dd01000: transfer of 'nil/IN' from 10.53.0.2#22502: sending IXFR request, QID 0
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP response 0x7f232dc2a280: sent: success
06-Dec-2023 02:05:45.901 0x7f232dd01000: transfer of 'nil/IN' from 10.53.0.2#22502: sent request data
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP read:success:requests 1
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP read success, length == 332, addr = 0x7f2335180982
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: got valid DNS message header, /QR 1, id 15280
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: search for response in hashtable: not found
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: shutting down due to TCP receive error: 10.53.0.2#22502: unexpected error
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP response 0x7f232dc2a280: read callback: unexpected error
06-Dec-2023 02:05:45.901 0x7f232dd01000: transfer of 'nil/IN' from 10.53.0.2#22502: failed while receiving responses: unexpected error
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP response 0x7f232dc2a280: canceling response: operation canceled, connected/not reading (canceled/not reading), requests 1
06-Dec-2023 02:05:45.901 zone nil/IN: zone transfer finished: unexpected error
06-Dec-2023 02:05:45.901 0x7f232dd01000: transfer of 'nil/IN' from 10.53.0.2#22502: Transfer status: unexpected error
06-Dec-2023 02:05:45.901 0x7f232dd01000: transfer of 'nil/IN' from 10.53.0.2#22502: Transfer completed: 0 messages, 0 records, 0 bytes, 0.001 secs (0 bytes/sec) (serial 0)
06-Dec-2023 02:05:45.901 0x7f232dd01000: transfer of 'nil/IN' from 10.53.0.2#22502: freeing transfer context
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP response 0x7f232dc2a280: canceling response: operation canceled, canceled/not reading (canceled/not reading), requests 1
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: TCP response 0x7f232dc2a280: destroying
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: destroying dispatch 0x7f232dcfa540
06-Dec-2023 02:05:45.901 dispatch 0x7f232dcfa540: detaching TCP handle 0x7f232dcfa8c0 from 0x7f232dcfa568
06-Dec-2023 02:05:45.901 zone__settimer: zone nil/IN: enter
```January 2024 (9.16.46, 9.16.46-S1, 9.18.22, 9.18.22-S1, 9.19.20) (❗RECALLED❗)https://gitlab.isc.org/isc-projects/bind9/-/issues/4341Investigate the memory spike when the cache is cold2023-12-05T15:58:56ZOndřej SurýInvestigate the memory spike when the cache is coldOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4366XFR (dispatch) doesn't shutdown TCP connection on timeout2023-12-05T15:50:25ZOndřej SurýXFR (dispatch) doesn't shutdown TCP connection on timeoutAfter switching the XFR to use `dns_dispatch`, the TCP connection doesn't get cancelled properly when `dns_dispatch_done()` is called and it waits for the TCP connection to timeout on the server side.After switching the XFR to use `dns_dispatch`, the TCP connection doesn't get cancelled properly when `dns_dispatch_done()` is called and it waits for the TCP connection to timeout on the server side.https://gitlab.isc.org/isc-projects/bind9/-/issues/4452log more information from pytest assertions in system tests2023-12-05T15:29:43ZTom Krizeklog more information from pytest assertions in system testsSome python system tests contain `assert` expression like
```
assert loaded == expected
```
which provide no useful information in case the check [fails](https://gitlab.isc.org/isc-private/bind9/-/jobs/3820431), e.g.:
```
____________...Some python system tests contain `assert` expression like
```
assert loaded == expected
```
which provide no useful information in case the check [fails](https://gitlab.isc.org/isc-private/bind9/-/jobs/3820431), e.g.:
```
_______________________ test_zone_timers_secondary_json ________________________
[gw1] linux -- Python 3.11.6 /usr/bin/python3
/builds/isc-private/bind9/bin/tests/system/statschannel/tests_json.py:86: in test_zone_timers_secondary_json
generic.test_zone_timers_secondary(
/builds/isc-private/bind9/bin/tests/system/statschannel/generic.py:94: in test_zone_timers_secondary
check_zone_timers(loaded, expires, refresh, mtime)
/builds/isc-private/bind9/bin/tests/system/statschannel/generic.py:49: in check_zone_timers
check_loaded(loaded, loaded_exp, now)
/builds/isc-private/bind9/bin/tests/system/statschannel/generic.py:38: in check_loaded
assert loaded == expected
E AssertionError
```
An informative assert message with the relevant values/data should be added to the assert statements:
```
assert loaded == expected, f"loaded={loaded}, expected={expected}"
```December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2445NSEC3 iterations considered harmful2023-12-05T14:58:58ZMatthijs Mekkingmatthijs@isc.orgNSEC3 iterations considered harmful### Summary
BIND doesn't limit, allowing 16-bit unsigned integer number of iterations. Seeing a lot of traffic for a zone with a high iteration number can effectively DDoS the resolver.
CVSS Score: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/...### Summary
BIND doesn't limit, allowing 16-bit unsigned integer number of iterations. Seeing a lot of traffic for a zone with a high iteration number can effectively DDoS the resolver.
CVSS Score: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L - 5.3
### BIND version used
Affected versions: 9.11, 9.16
### Steps to reproduce
1. Set up an authoritative server with a DNSSEC signed zone with high iteration count:
`dnssec-signzone -3 - -H 65535 example.`, then configure `named` and start
2. Set up a validating resolver.
3. Run a NXDOMAIN style attack
### What is the current *bug* behavior?
Resolver has very low QPS.
### What is the expected *correct* behavior?
Resolver doesn't starve.
### Relevant configuration files
To do.
### Relevant logs and/or screenshots
N/A
### Possible fixes
From the resolver perspective, this situation is actually protocol compliant.
RFC 5155 says:
```
A zone owner MUST NOT use a value higher than shown in the table
below for iterations for the given key size. A resolver MAY treat a
response with a higher value as insecure, after the validator has
verified that the signature over the NSEC3 RR is correct.
+----------+------------+
| Key Size | Iterations |
+----------+------------+
| 1024 | 150 |
| 2048 | 500 |
| 4096 | 2,500 |
+----------+------------+
```
But it also acknowledges this is susceptible to attacks:
```
12.1.4. Using High Iteration Values
Since validators should treat responses containing NSEC3 RRs with
high iteration values as insecure, presence of just one signed NSEC3
RR with a high iteration value in a zone provides attackers with a
possible downgrade attack.
[...]
Using a high number of iterations also introduces an additional
denial-of-service opportunity against servers, since servers must
calculate several hashes per negative or wildcard response.
```
Proposed fixes:
When loading a zone (primary server):
- We could error if we try to load a zone with NSEC3 records with too high iteration count.
- Or we could treat it as garbage in/garbage out.
When transferring a zone (secondary server):
- Nothing much we can do about it.
When validating a response from this zone (resolver):
- Treat such NSEC3 records as insecure after validating (as suggested in the RFC).October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4384Assertion failure at ENSURE(isc_mempool_getallocated(*namepoolp) == 0) in mes...2023-12-05T12:50:50ZMichal NowakAssertion failure at ENSURE(isc_mempool_getallocated(*namepoolp) == 0) in message.c:4791See #4462 for reproducer.
Job [#3740189](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3740189) failed for cddd9dcb5329165633767fd1e319fbb0700487d2; worked fine 2 MRs prior (at 2728b810). Looks like a shutdown issue.
```
Core was ge...See #4462 for reproducer.
Job [#3740189](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3740189) failed for cddd9dcb5329165633767fd1e319fbb0700487d2; worked fine 2 MRs prior (at 2728b810). Looks like a shutdown issue.
```
Core was generated by `/builds/isc-projects/bind9/.local/usr/local/sbin/named -f -c ./named.conf'.
Program terminated with signal SIGABRT, Aborted.
#0 __pthread_kill_implementation (threadid=281472872136768, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
Downloading source file /usr/src/debug/glibc-2.37-10.fc38.aarch64/nptl/pthread_kill.c...
44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;
[Current thread is 1 (Thread 0xffff828ec040 (LWP 24241))]
#0 __pthread_kill_implementation (threadid=281472872136768, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x0000ffff8171d958 [PAC] in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2 0x0000ffff816d4980 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x0000ffff816c0284 [PAC] in __GI_abort () at abort.c:79
#4 0x000000000042efa8 [PAC] in assertion_failed (file=<optimized out>, line=4791, type=isc_assertiontype_ensure, cond=0xffff827a2368 "isc_mempool_getallocated(*namepoolp) == 0") at main.c:234
#5 0x0000ffff828658a4 in isc_assertion_failed (file=file@entry=0xffff827a0998 "message.c", line=line@entry=4791, type=type@entry=isc_assertiontype_ensure, cond=cond@entry=0xffff827a2368 "isc_mempool_getallocated(*namepoolp) == 0") at assertions.c:48
#6 0x0000ffff82678060 in dns_message_destroypools (namepoolp=0xffff80bf8e20, rdspoolp=0xffff80bf8e40) at message.c:4791
#7 0x0000ffff827031ec in dns_resolver__destroy (res=res@entry=0xffff80b21400) at resolver.c:9891
#8 0x0000ffff8270b0e4 in dns_resolver_unref (ptr=0xffff80b21400) at resolver.c:10172
#9 0x0000ffff8270b178 in dns_resolver_detach (ptrp=ptrp@entry=0xffff80070050) at resolver.c:10172
#10 0x0000ffff826185dc in destroy (adb=adb@entry=0xffff80070000) at adb.c:1833
#11 0x0000ffff8261acd4 in dns_adb_unref (ptr=0xffff80070000) at adb.c:1841
#12 0x0000ffff8261ae6c in dns_adb_detach (ptrp=ptrp@entry=0xffffec576580) at adb.c:1841
#13 0x0000ffff8273bf74 in dns_view_detach (viewp=viewp@entry=0xffff8090ae08) at view.c:516
#14 0x0000ffff82738050 in destroy_validator (val=val@entry=0xffff8090ae00) at validator.c:3122
#15 0x0000ffff82738148 in dns_validator_unref (ptr=0xffff8090ae00) at validator.c:3226
#16 0x0000ffff82736020 in dns_validator_detach (ptrp=ptrp@entry=0xffffec576688) at validator.c:3226
#17 0x0000ffff82737ee4 in validator_done_cb (arg=<optimized out>) at validator.c:211
#18 0x0000ffff82865c1c in isc__async_cb (handle=<optimized out>) at async.c:111
#19 0x0000ffff81dda0c0 in uv__async_io (loop=0xffff80482820, w=0xffff804829f0, events=1) at /usr/src/libuv-v1.46.0/src/unix/async.c:176
#20 0x0000ffff81df6d0c in uv__io_poll (loop=0xffff80482820, timeout=11996) at /usr/src/libuv-v1.46.0/src/unix/linux.c:1476
#21 0x0000ffff81ddb084 in uv_run (loop=0xffff80482820, mode=UV_RUN_DEFAULT) at /usr/src/libuv-v1.46.0/src/unix/core.c:447
#22 0x0000ffff8287977c in loop_thread (arg=arg@entry=0xffff80482800) at loop.c:282
#23 0x0000ffff82889204 in thread_body (wrap=0x29878850) at thread.c:85
#24 0x0000ffff8288928c in isc_thread_main (func=func@entry=0xffff82879710 <loop_thread>, arg=<optimized out>) at thread.c:116
#25 0x0000ffff8287a4e0 in isc_loopmgr_run (loopmgr=0xffff808c06c0) at loop.c:454
#26 0x00000000004318a8 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1580
```
[core.24241-backtrace.txt](/uploads/8c4ac88405f3d8fb408f3ce70c590971/core.24241-backtrace.txt)
[named.conf](/uploads/28375b11fdea2ade28463c2c3c437c01/named.conf)
Similar issue: isc-projects/bind9#2188December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4457dig crashes after SIGINT if there are multiple queries2023-12-04T21:59:30ZPetr Špačekpspacek@isc.orgdig crashes after SIGINT if there are multiple queries### Summary
Dig with multiple queries crashes when interrupted.
### BIND version used
* ~"Affects v9.19" : de2009e3c2a
### Steps to reproduce
```
$ dig 2000.delay.getdnsapi.net 3000.delay.getdnsapi.net
```
+ SIGINT before the first qu...### Summary
Dig with multiple queries crashes when interrupted.
### BIND version used
* ~"Affects v9.19" : de2009e3c2a
### Steps to reproduce
```
$ dig 2000.delay.getdnsapi.net 3000.delay.getdnsapi.net
```
+ SIGINT before the first query finishes.
### What is the current *bug* behavior?
:boom:
```
signal.c:78: REQUIRE(((signal) != ((void *)0) && ((const isc__magic_t *)(signal))->magic == ((('S') << 24 | ('I') << 16 | ('G') << 8 | (' '))))) failed, back trace
```
### What is the expected *correct* behavior?
No crash.
### Relevant configuration files
None needed.
### Relevant logs and/or screenshots
Full debug log:
<details>
```
$ dig -d 2000.delay.getdnsapi.net 3000.delay.getdnsapi.net
setup_libs()
setup_system()
create_search_list()
ndots is 1.
timeout is 0.
retries is 3.
get_server_list()
make_server(127.0.0.111)
dig_query_setup
parse_args()
making new lookup
make_empty_lookup()
make_empty_lookup() = 0x7f6faa9aa000->references = 1
digrc (open)
main parsing +timeout=5
main parsing +retry=0
main parsing -d
main parsing 2000.delay.getdnsapi.net
clone_lookup()
make_empty_lookup()
make_empty_lookup() = 0x7f6faa9ab800->references = 1
clone_server_list()
looking up 2000.delay.getdnsapi.net
main parsing 3000.delay.getdnsapi.net
clone_lookup()
make_empty_lookup()
make_empty_lookup() = 0x7f6faa9ad000->references = 1
clone_server_list()
looking up 3000.delay.getdnsapi.net
dig_startup()
start_lookup()
setup_lookup(0x7f6faa9ab800)
resetting lookup counter.
cloning server list
clone_server_list()
make_server(127.0.0.111)
idn_textname: 2000.delay.getdnsapi.net
using root origin
recursive query
AD query
add_question()
starting to render the message
add_opt()
done rendering
create query 0x7f6fab09f540 linked to lookup 0x7f6faa9ab800
dighost.c:2141:lookup_attach(0x7f6faa9ab800) = 2
dighost.c:2652:new_query(0x7f6fab09f540) = 1
do_lookup()
start_udp(0x7f6fab09f540)
dighost.c:3255:query_attach(0x7f6fab09f540) = 2
working on lookup 0x7f6faa9ab800, query 0x7f6fab09f540
dighost.c:3300:query_attach(0x7f6fab09f540) = 3
udp_ready()
udp_ready(0x7f6fab09f700, success, 0x7f6fab09f540)
dighost.c:3147:lookup_attach(0x7f6faa9ab800) = 3
dighost.c:3216:query_attach(0x7f6fab09f540) = 4
recving with lookup=0x7f6faa9ab800, query=0x7f6fab09f540, handle=0x7f6fab09f700
recvcount=1
have local timeout of 5000
dighost.c:3094:query_attach(0x7f6fab09f540) = 5
sending a request
sendcount=1
dighost.c:1729:query_detach(0x7f6fab09f540) = 4
dighost.c:3236:query_detach(0x7f6fab09f540) = 3
dighost.c:3237:lookup_detach(0x7f6faa9ab800) = 2
send_done(0x7f6fab09f700, success, 0x7f6fab09f540)
sendcount=0
dighost.c:2729:lookup_attach(0x7f6faa9ab800) = 3
dighost.c:2746:query_detach(0x7f6fab09f540) = 2
dighost.c:2747:lookup_detach(0x7f6faa9ab800) = 2
check_if_done()
list full
pending lookup 0x7f6faa9ad000
^Crecv_done(0x7f6fab09f700, shutting down, 0x7ffe1fb53710, 0x7f6fab09f540)
recvcount=0
dighost.c:3905:lookup_attach(0x7f6faa9ab800) = 3
recv_done: cancel
dighost.c:3913:_cancel_lookup()
canceling pending query 0x7f6fab09f540, belonging to 0x7f6faa9ab800
dighost.c:2775:query_detach(0x7f6fab09f540) = 1
check_if_done()
list full
pending lookup 0x7f6faa9ad000
dighost.c:3915:query_detach(0x7f6fab09f540) = 0
dighost.c:3915:destroy_query(0x7f6fab09f540) = 0
dighost.c:1687:lookup_detach(0x7f6faa9ab800) = 2
dighost.c:3916:lookup_detach(0x7f6faa9ab800) = 1
clear_current_lookup()
lookup cleared
dighost.c:1820:lookup_detach(0x7f6faa9ab800) = 0
destroy_lookup
freeing server 0x7f6fab072a00 belonging to 0x7f6faa9ab800
start_lookup()
setup_lookup(0x7f6faa9ad000)
resetting lookup counter.
cloning server list
clone_server_list()
make_server(127.0.0.111)
idn_textname: 3000.delay.getdnsapi.net
using root origin
recursive query
AD query
add_question()
starting to render the message
add_opt()
done rendering
create query 0x7f6fab09f540 linked to lookup 0x7f6faa9ad000
dighost.c:2141:lookup_attach(0x7f6faa9ad000) = 2
dighost.c:2652:new_query(0x7f6fab09f540) = 1
do_lookup()
start_udp(0x7f6fab09f540)
dighost.c:3255:query_attach(0x7f6fab09f540) = 2
working on lookup 0x7f6faa9ad000, query 0x7f6fab09f540
signal.c:78: REQUIRE(((signal) != ((void *)0) && ((const isc__magic_t *)(signal))->magic == ((('S') << 24 | ('I') << 16 | ('G') << 8 | (' '))))) failed, back trace
/usr/lib/libisc-9.19.19-dev.so(+0x33891)[0x7f6faef42891]
/usr/lib/libisc-9.19.19-dev.so(isc_assertion_failed+0x31)[0x7f6faef427a2]
/usr/lib/libisc-9.19.19-dev.so(isc_signal_stop+0x44)[0x7f6faef71f5b]
/usr/lib/libisc-9.19.19-dev.so(isc_loopmgr_blocking+0x55)[0x7f6faef61f96]
dig(get_address+0x38)[0x55ddd5ed030b]
dig(+0x1b006)[0x55ddd5ecc006]
dig(do_lookup+0xc8)[0x55ddd5ed067b]
dig(start_lookup+0x285)[0x55ddd5ec6e71]
dig(+0x15485)[0x55ddd5ec6485]
dig(+0x15fcc)[0x55ddd5ec6fcc]
dig(+0x1d23b)[0x55ddd5ece23b]
/usr/lib/libisc-9.19.19-dev.so(+0x1e71d)[0x7f6faef2d71d]
/usr/lib/libisc-9.19.19-dev.so(isc__nm_readcb+0x121)[0x7f6faef2d863]
/usr/lib/libisc-9.19.19-dev.so(isc__nm_udp_failed_read_cb+0x12b)[0x7f6faef420b0]
/usr/lib/libisc-9.19.19-dev.so(isc__nm_failed_read_cb+0x89)[0x7f6faef2ac2c]
/usr/lib/libisc-9.19.19-dev.so(isc__nm_udp_shutdown+0x127)[0x7f6faef42723]
/usr/lib/libisc-9.19.19-dev.so(isc__nmsocket_shutdown+0x6e)[0x7f6faef2dd24]
/usr/lib/libisc-9.19.19-dev.so(+0x1edb4)[0x7f6faef2ddb4]
/usr/lib/libuv.so.1(uv_walk+0x9b)[0x7f6fae9a474b]
/usr/lib/libisc-9.19.19-dev.so(+0x1818b)[0x7f6faef2718b]
/usr/lib/libisc-9.19.19-dev.so(isc__async_cb+0x18d)[0x7f6faef42c6b]
/usr/lib/libuv.so.1(+0x9a1b)[0x7f6fae99fa1b]
/usr/lib/libuv.so.1(+0x26d48)[0x7f6fae9bcd48]
/usr/lib/libuv.so.1(uv_run+0x1bf)[0x7f6fae9a4fbf]
/usr/lib/libisc-9.19.19-dev.so(+0x51370)[0x7f6faef60370]
/usr/lib/libisc-9.19.19-dev.so(+0x66f07)[0x7f6faef75f07]
/usr/lib/libisc-9.19.19-dev.so(isc_thread_main+0x62)[0x7f6faef75fc6]
/usr/lib/libisc-9.19.19-dev.so(isc_loopmgr_run+0x187)[0x7f6faef613fb]
dig(dig_startup+0x48)[0x55ddd5ec0624]
dig(main+0x40)[0x55ddd5ec068a]
/usr/lib/libc.so.6(+0x27cd0)[0x7f6fae9f1cd0]
/usr/lib/libc.so.6(__libc_start_main+0x8a)[0x7f6fae9f1d8a]
dig(_start+0x25)[0x55ddd5eb7045]
Aborted (core dumped)
```
</details>December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4417Stale hyperlinks in the ARM2023-12-04T10:02:12ZMatthijs Mekkingmatthijs@isc.orgStale hyperlinks in the ARMFrom bind-users:
https://bind9.readthedocs.io/en/v9.18.19/dnssec-guide.html
there's a link to
https://stats.research.icann.org/dns/tld_report/
which is no longer valid. New data seems to be here:
https://ithi.research.icann.or...From bind-users:
https://bind9.readthedocs.io/en/v9.18.19/dnssec-guide.html
there's a link to
https://stats.research.icann.org/dns/tld_report/
which is no longer valid. New data seems to be here:
https://ithi.research.icann.org/
ITHI == idenitifier technologies health indicators
how many TLDs support DNSSEC ?
https://ithi.research.icann.org/graph-m7.htmlDecember 2023 (9.18.21, 9.18.21-S1, 9.19.19)Petr Špačekpspacek@isc.orgPetr Špačekpspacek@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/26Switch to IDNA2008 non-transitional processing (and use libidn2 for that)2023-12-01T10:23:29ZOndřej SurýSwitch to IDNA2008 non-transitional processing (and use libidn2 for that)Copied here from https://bugs.isc.org/Ticket/Display.html?id=36101
The most current (and maintained) implementation of IDNA is libidn2 and that what we should be using. Moreover the DNS world just needs to bite the bullet and switch to...Copied here from https://bugs.isc.org/Ticket/Display.html?id=36101
The most current (and maintained) implementation of IDNA is libidn2 and that what we should be using. Moreover the DNS world just needs to bite the bullet and switch to IDNA2008 non-transitional processing and finally be done with that.
Firefox, curl and wget have already switched to IDNA2008 non-transitional, and it's not like dig/host/nslookup IDNA processing would have any security implications like with the web browser software.BIND-9.13.0Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4456license question: do bind9 based configs require Mozilla License?2023-11-27T20:54:47ZPJ Fanninglicense question: do bind9 based configs require Mozilla License?I'm a developer on the Apache Pekko project, an open source fork of Akka.
One of our mentors has queried if we have a licensing issue for the files in this directory.
https://github.com/apache/incubator-pekko/tree/main/actor-tests/src/t...I'm a developer on the Apache Pekko project, an open source fork of Akka.
One of our mentors has queried if we have a licensing issue for the files in this directory.
https://github.com/apache/incubator-pekko/tree/main/actor-tests/src/test/bind/etc
The configs there are Bind9 configs used in our tests.
Does the Mozilla Public License have to be applied to our config files?
https://gitlab.isc.org/isc-projects/bind9/-/blob/main/LICENSE
The Mozilla Public License is regarded by the ASF as having copyleft implications.
Any advice on the licensing implications of having config files based on this repo would be appreciated.https://gitlab.isc.org/isc-projects/bind9/-/issues/4340"max-cache-size" is a no-op since BIND 9.19.162023-11-27T13:22:48ZMichał Kępień"max-cache-size" is a no-op since BIND 9.19.16Commit 4db150437e14b28c5b50ae466af9ce502fd73185 (part of !7873)
inadvertently turned the `max-cache-size` option into a no-op by
removing the `isc_mem_setwater()` call from `dns_cache_setcachesize()`.
This was not caught in testing as t...Commit 4db150437e14b28c5b50ae466af9ce502fd73185 (part of !7873)
inadvertently turned the `max-cache-size` option into a no-op by
removing the `isc_mem_setwater()` call from `dns_cache_setcachesize()`.
This was not caught in testing as the current memory use limitation
logic employed in `named` is not stable enough for low `max-cache-size`
values (which is documented) and most tests use the implicit default of
`max-cache-size 90%;`.
Shout-out to @esesterhenn for [spotting this][1], thank you! :medal:
[1]: https://mattermost.isc.org/x41-dsec/pl/e9ja89c8at8wxpyqkjcpoukoycNovember 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1295Implement PROXY protocol2023-11-27T12:46:04ZOndřej SurýImplement PROXY protocolThe PowerDNS folks are now considering dropping the XPF in favour of the [PROXY protocol](http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) which is pretty much reasonable.The PowerDNS folks are now considering dropping the XPF in favour of the [PROXY protocol](http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) which is pretty much reasonable.BIND 9.19.xArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2209TSAN error bin/named/controlconf.c related.2023-11-23T08:14:30ZMark AndrewsTSAN error bin/named/controlconf.c related.Job [#1213042](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1213042) failed for ced5041de73f16dbadf1acacbf8c20659efcb6a6:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 isc_nmhandle...Job [#1213042](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1213042) failed for ced5041de73f16dbadf1acacbf8c20659efcb6a6:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1:
#0 isc_nmhandle_detach lib/isc/netmgr/netmgr.c:1258:15
#1 control_command bin/named/controlconf.c:388:3
#2 dispatch lib/isc/task.c:1152:7
#3 run lib/isc/task.c:1344:2
Previous read of size 8 at 0x000000000001 by thread T2:
#0 isc_nm_pauseread lib/isc/netmgr/netmgr.c:1449:33
#1 recv_data lib/isccc/ccmsg.c:109:2
#2 isc__nm_tcp_shutdown lib/isc/netmgr/tcp.c:1157:4
#3 shutdown_walk_cb lib/isc/netmgr/netmgr.c:1515:3
#4 uv_walk <null>
#5 process_queue lib/isc/netmgr/netmgr.c:659:4
#6 process_normal_queue lib/isc/netmgr/netmgr.c:582:10
#7 process_queues lib/isc/netmgr/netmgr.c:590:8
#8 async_cb lib/isc/netmgr/netmgr.c:548:2
#9 <null> <null>
Location is heap block of size 569 at 0x000000000016 allocated by thread T2:
#0 malloc <null>
#1 default_memalloc lib/isc/mem.c:713:8
#2 mem_get lib/isc/mem.c:622:8
#3 isc___mem_get lib/isc/mem.c:1044:9
#4 isc__mem_get lib/isc/mem.c:2432:10
#5 alloc_handle lib/isc/netmgr/netmgr.c:1076:3
#6 isc__nmhandle_get lib/isc/netmgr/netmgr.c:1100:12
#7 isc__nm_async_tcpchildaccept lib/isc/netmgr/tcp.c:486:11
#8 process_queue lib/isc/netmgr/netmgr.c:624:4
#9 process_normal_queue lib/isc/netmgr/netmgr.c:582:10
#10 process_queues lib/isc/netmgr/netmgr.c:590:8
#11 async_cb lib/isc/netmgr/netmgr.c:548:2
#12 <null> <null>
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_taskmgr_create lib/isc/task.c:1434:3
#3 create_managers bin/named/main.c:915:11
#4 setup bin/named/main.c:1223:11
#5 main bin/named/main.c:1523:2
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:73:8
#2 isc_nm_start lib/isc/netmgr/netmgr.c:232:3
#3 create_managers bin/named/main.c:909:15
#4 setup bin/named/main.c:1223:11
#5 main bin/named/main.c:1523:2
SUMMARY: ThreadSanitizer: data race lib/isc/netmgr/netmgr.c:1258:15 in isc_nmhandle_detach
```November 2020 (9.11.25, 9.11.25-S1, 9.16.9, 9.16.9-S1, 9.17.7)https://gitlab.isc.org/isc-projects/bind9/-/issues/3637BIND 9.18 retries same authoritative nameserver before trying another one2023-11-22T09:02:06ZDavid ZychBIND 9.18 retries same authoritative nameserver before trying another one<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
Given an authoritative zone with multiple nameservers, some of which may currently be unavailable, how should a BIND recursive resolver react when its first query attempt times out?
Empirically, BIND 9.16 will try a _different_ authoritative nameserver next, but BIND 9.18 will try the _same_ one 3 times in a row before moving on to a different one. The BIND 9.18 behavior is significantly less robust.
### BIND version used
```
[root@dmrz-test-rdns ~]# named -V
BIND 9.18.8 (Stable Release) <id:35f5d35>
running on Linux x86_64 3.10.0-1160.el7.x86_64 #1 SMP Mon Oct 19 16:18:59 UTC 2020
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/opt/isc/isc-bind/root/usr' '--exec-prefix=/opt/isc/isc-bind/root/usr' '--bindir=/opt/isc/isc-bind/root/usr/bin' '--sbindir=/opt/isc/isc-bind/root/usr/sbin' '--sysconfdir=/etc/opt/isc/isc-bind' '--datadir=/opt/isc/isc-bind/root/usr/share' '--includedir=/opt/isc/isc-bind/root/usr/include' '--libdir=/opt/isc/isc-bind/root/usr/lib64' '--libexecdir=/opt/isc/isc-bind/root/usr/libexec' '--localstatedir=/var/opt/isc/isc-bind' '--sharedstatedir=/var/opt/isc/isc-bind/lib' '--mandir=/opt/isc/isc-bind/root/usr/share/man' '--infodir=/opt/isc/isc-bind/root/usr/share/info' '--disable-static' '--enable-dnstap' '--with-pic' '--with-gssapi' '--with-json-c' '--with-libxml2' '--without-lmdb' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro -L/opt/isc/isc-bind/root/usr/lib64' 'CPPFLAGS= -I/opt/isc/isc-bind/root/usr/include' 'LT_SYS_LIBRARY_PATH=/usr/lib64' 'PKG_CONFIG_PATH=:/opt/isc/isc-bind/root/usr/lib64/pkgconfig:/opt/isc/isc-bind/root/usr/share/pkgconfig' 'SPHINX_BUILD=/builddir/build/BUILD/bind-9.18.8/sphinx/bin/sphinx-build'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44)
compiled with OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.33.0
linked to libnghttp2 version: 1.33.0
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with json-c version: 0.11
linked to json-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
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
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/opt/isc/isc-bind/named.conf
rndc configuration: /etc/opt/isc/isc-bind/rndc.conf
DNSSEC root key: /etc/opt/isc/isc-bind/bind.keys
nsupdate session key: /var/opt/isc/isc-bind/run/named/session.key
named PID file: /var/opt/isc/isc-bind/run/named/named.pid
named lock file: /var/opt/isc/isc-bind/run/named/named.lock
```
### Steps to reproduce
1. Configure an authoritative server with the following authoritative zone, listing one working nameserver IP (itself) plus two others which are "down".
```
example.com. 30 IN SOA ns1.example.com. dns-admin.illinois.edu. 1 3600 900 1209600 30
example.com. 30 IN NS ns1.example.com.
example.com. 30 IN NS ns2.example.com.
example.com. 30 IN NS ns3.example.com.
foo.example.com. 30 IN TXT "test"
ns1.example.com. 30 IN A 18.191.96.154
ns2.example.com. 30 IN A 192.168.0.20
ns3.example.com. 30 IN A 192.168.0.30
```
2. Configure a CentOS 7 instance "dmrz-test-rdns" running isc-bind-bind 9.18.8-1.1.el7 from https://copr.fedorainfracloud.org/coprs/isc/bind/ with a stub zone for example.com:
```
options {
directory "/var/opt/isc/isc-bind/named/data";
allow-query { localhost; 10.0.0.0/8; };
recursion yes;
dnssec-validation no;
# enable querylogging at startup
querylog yes;
};
logging {
channel default_debug {
file "named.run";
print-time yes;
severity dynamic;
};
# local file for query logs
channel queries_file {
file "queries.log" versions 5 size 200m;
severity info;
print-time yes; print-category yes; print-severity yes;
};
category queries { queries_file; };
};
zone "example.com" IN {
file "example.com";
type stub;
masters { 18.191.96.154; };
};
```
3. As root on dmrz-test-rdns, start a packet capture:
```
[root@dmrz-test-rdns data]# tcpdump -i eth0 -Uw /var/tmp/${HOSTNAME}.pcap
```
4. From another workstation in the allow-query ACL, send a test query:
```
$ dig @10.225.64.30 foo.example.com txt
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.10 <<>> @10.225.64.30 foo.example.com txt
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33425
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;foo.example.com. IN TXT
;; ANSWER SECTION:
foo.example.com. 30 IN TXT "test"
;; Query time: 3784 msec
;; SERVER: 10.225.64.30#53(10.225.64.30)
;; WHEN: Tue Nov 01 20:08:08 UTC 2022
;; MSG SIZE rcvd: 61
```
Note the very long query time (over 3 seconds). If you don't see a long query time at first, wait at least 30s (for cache to expire) and try again.
5. Observe named complaining about a timeout:
```
[root@dmrz-test-rdns data]# tail /var/opt/isc/isc-bind/named/data/named.run
01-Nov-2022 20:04:54.508 all zones loaded
01-Nov-2022 20:04:54.508 running
01-Nov-2022 20:08:08.556 timed out resolving 'foo.example.com/TXT/IN': 192.168.0.20#53
01-Nov-2022 20:08:51.441 timed out resolving 'foo.example.com/TXT/IN': 192.168.0.30#53
```
6. Download the packet capture file and examine it in Wireshark, filtering by `dns` protocol.
Observe that after receiving a query from client (10.224.255.16) at 20:08:04, we try 3 times in a row to query the unresponsive 192.168.0.20 before moving on to the working nameserver 18.191.96.154.
On another occasion, we try 192.168.0.30 3 times in a row.
At 20:09:32 we happen to try the working nameserver first and are able to respond to our client quickly.
```
No. Time Source Destination Protocol Length Info
3 2022-11-01 20:08:04.776005 10.224.255.16 10.225.64.30 DNS 86 Standard query 0x8291 TXT foo.example.com OPT
4 2022-11-01 20:08:04.776851 10.225.64.30 192.168.0.20 DNS 98 Standard query 0x90f6 TXT foo.example.com OPT
5 2022-11-01 20:08:05.576960 10.225.64.30 192.168.0.20 DNS 98 Standard query 0x7acc TXT foo.example.com OPT
7 2022-11-01 20:08:06.378009 10.225.64.30 192.168.0.20 DNS 98 Standard query 0x05fe TXT foo.example.com OPT
14 2022-11-01 20:08:08.557405 10.225.64.30 18.191.96.154 DNS 98 Standard query 0x7979 TXT foo.example.com OPT
15 2022-11-01 20:08:08.558188 18.191.96.154 10.225.64.30 DNS 233 Standard query response 0x7979 TXT foo.example.com TXT NS ns3.example.com NS ns2.example.com NS ns1.example.com A 18.191.96.154 A 192.168.0.20 A 192.168.0.30 OPT
16 2022-11-01 20:08:08.558432 10.225.64.30 10.224.255.16 DNS 103 Standard query response 0x8291 TXT foo.example.com TXT OPT
31 2022-11-01 20:08:47.747803 10.224.255.16 10.225.64.30 DNS 86 Standard query 0xbf02 TXT foo.example.com OPT
32 2022-11-01 20:08:47.748163 10.225.64.30 192.168.0.30 DNS 98 Standard query 0x474b TXT foo.example.com OPT
33 2022-11-01 20:08:48.549188 10.225.64.30 192.168.0.30 DNS 98 Standard query 0x2130 TXT foo.example.com OPT
34 2022-11-01 20:08:49.350213 10.225.64.30 192.168.0.30 DNS 98 Standard query 0x7d5f TXT foo.example.com OPT
37 2022-11-01 20:08:51.441890 10.225.64.30 18.191.96.154 DNS 114 Standard query 0x1ef3 TXT foo.example.com OPT
38 2022-11-01 20:08:51.442705 18.191.96.154 10.225.64.30 DNS 233 Standard query response 0x1ef3 TXT foo.example.com TXT NS ns2.example.com NS ns1.example.com NS ns3.example.com A 18.191.96.154 A 192.168.0.20 A 192.168.0.30 OPT
39 2022-11-01 20:08:51.442872 10.225.64.30 10.224.255.16 DNS 103 Standard query response 0xbf02 TXT foo.example.com TXT OPT
55 2022-11-01 20:09:32.834068 10.224.255.16 10.225.64.30 DNS 86 Standard query 0x0297 TXT foo.example.com OPT
56 2022-11-01 20:09:32.834680 10.225.64.30 18.191.96.154 DNS 114 Standard query 0x958a TXT foo.example.com OPT
57 2022-11-01 20:09:32.835082 18.191.96.154 10.225.64.30 DNS 233 Standard query response 0x958a TXT foo.example.com TXT NS ns2.example.com NS ns3.example.com NS ns1.example.com A 18.191.96.154 A 192.168.0.20 A 192.168.0.30 OPT
58 2022-11-01 20:09:32.835211 10.225.64.30 10.224.255.16 DNS 103 Standard query response 0x0297 TXT foo.example.com TXT OPT
```
7. Now retry the experiment with a different recursive resolver "dmrz-test-rdns-916" (10.225.64.119) running isc-bind-bind 9.16.34-1.1.el7 from https://copr.fedorainfracloud.org/coprs/isc/bind-esv/
BIND 9.16 handles the situation much more gracefully; at 20:42:51 we fail to get a response from 192.168.0.30, but instead of retrying the same server we try another one, which happens to be the working one, so we are able to respond successfully to the client in under 1 second.
```
No. Time Source Destination Protocol Length Info
12 2022-11-01 20:42:51.913893 10.224.255.16 10.225.64.119 DNS 86 Standard query 0x29ac TXT foo.example.com OPT
13 2022-11-01 20:42:51.915009 10.225.64.119 192.168.0.30 DNS 98 Standard query 0x19c1 TXT foo.example.com OPT
14 2022-11-01 20:42:52.713887 10.225.64.119 18.191.96.154 DNS 98 Standard query 0x2280 TXT foo.example.com OPT
15 2022-11-01 20:42:52.714303 18.191.96.154 10.225.64.119 DNS 131 Standard query response 0x2280 TXT foo.example.com TXT OPT
16 2022-11-01 20:42:52.714709 10.225.64.119 10.224.255.16 DNS 103 Standard query response 0x29ac TXT foo.example.com TXT OPT
53 2022-11-01 20:44:15.623212 10.224.255.16 10.225.64.119 DNS 86 Standard query 0xcf02 TXT foo.example.com OPT
54 2022-11-01 20:44:15.623584 10.225.64.119 18.191.96.154 DNS 114 Standard query 0xc333 TXT foo.example.com OPT
55 2022-11-01 20:44:15.624183 18.191.96.154 10.225.64.119 DNS 233 Standard query response 0xc333 TXT foo.example.com TXT NS ns1.example.com NS ns3.example.com NS ns2.example.com A 18.191.96.154 A 192.168.0.20 A 192.168.0.30 OPT
56 2022-11-01 20:44:15.624371 10.225.64.119 10.224.255.16 DNS 103 Standard query response 0xcf02 TXT foo.example.com TXT OPT
68 2022-11-01 20:44:54.321211 10.224.255.16 10.225.64.119 DNS 86 Standard query 0x6f5f TXT foo.example.com OPT
69 2022-11-01 20:44:54.321578 10.225.64.119 192.168.0.20 DNS 98 Standard query 0x1fa5 TXT foo.example.com OPT
70 2022-11-01 20:44:55.120996 10.225.64.119 18.191.96.154 DNS 114 Standard query 0xddae TXT foo.example.com OPT
71 2022-11-01 20:44:55.121400 18.191.96.154 10.225.64.119 DNS 233 Standard query response 0xddae TXT foo.example.com TXT NS ns3.example.com NS ns1.example.com NS ns2.example.com A 18.191.96.154 A 192.168.0.20 A 192.168.0.30 OPT
72 2022-11-01 20:44:55.121577 10.225.64.119 10.224.255.16 DNS 103 Standard query response 0x6f5f TXT foo.example.com TXT OPT
```
In this case, we also do not see any "timed out" log messages in named.run
### What is the current *bug* behavior?
As shown above, BIND 9.18 consistently tries multiple times in a row to reach the same unresponsive authoritative nameserver IP, and is therefore unable to answer the client in a timely fashion even though the zone has another authoritative nameserver which is working just fine.
### What is the expected *correct* behavior?
Be like BIND 9.16 and retry against a different authoritative nameserver IP when the first one doesn't respond.
aside: this may be related to #3629January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)Ondřej SurýOndřej Surý