BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2022-04-28T05:11:43Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3229Remove task exclusive mode from ns_interfacemgr2022-04-28T05:11:43ZOndřej SurýRemove task exclusive mode from ns_interfacemgrThe ns_interfacemgr uses the exclusive mode as a global lock for modifying the dns_aclenv.The ns_interfacemgr uses the exclusive mode as a global lock for modifying the dns_aclenv.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3227Remove extrahandle size from netmgr2022-05-05T02:07:15ZOndřej SurýRemove extrahandle size from netmgrPreviously, it was possible to assign a bit of memory space in the nmhandle to store the client data. This was complicated and prevents further refactoring of isc_nmhandle_t caching (future work).
Instead of caching the data in the nmha...Previously, it was possible to assign a bit of memory space in the nmhandle to store the client data. This was complicated and prevents further refactoring of isc_nmhandle_t caching (future work).
Instead of caching the data in the nmhandle, allocate the hot-path ns_client_t objects from per-thread clientmgr memory context and just assign it to the isc_nmhandle_t via isc_nmhandle_set().April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3226Create per-thread task and memory context for zonemgr2022-04-07T16:12:27ZOndřej SurýCreate per-thread task and memory context for zonemgrCreate per-thread task and memory context for zonemgr
Previously, the zonemgr created 1 task per 100 zones and 1 memory
context per 1000 zones (with minimum 10 tasks and 2 memory contexts) to
reduce the contention between threads.
Inst...Create per-thread task and memory context for zonemgr
Previously, the zonemgr created 1 task per 100 zones and 1 memory
context per 1000 zones (with minimum 10 tasks and 2 memory contexts) to
reduce the contention between threads.
Instead of reducing the contention by having many resources, create a
per-nm_thread memory context, loadtask and zonetask and spread the zones
between just per-thread resources.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3221[1/5] Catalog zones lightweight cleanup2022-05-16T11:26:46ZArаm Sаrgsyаn[1/5] Catalog zones lightweight cleanupDo some lightweight code cleanup and fixes in preparation of adding some new feature from the latest DNS catalog zones draft.Do some lightweight code cleanup and fixes in preparation of adding some new feature from the latest DNS catalog zones draft.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3213Remove exclusive task mode from dns_adb2022-07-01T01:03:38ZOndřej SurýRemove exclusive task mode from dns_adbdns_adb uses exclusive task mode to rehash the internal hashing tables. The exclusive mode stops all processing which causes temporarily brownouts because all the threads needs to be synchronized, stopped, then the exclusive tasks are r...dns_adb uses exclusive task mode to rehash the internal hashing tables. The exclusive mode stops all processing which causes temporarily brownouts because all the threads needs to be synchronized, stopped, then the exclusive tasks are run and the normal operation is resumed.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3212Implement incremental rehashing for isc_ht hashtables2023-01-25T20:21:25ZOndřej SurýImplement incremental rehashing for isc_ht hashtablesSee #2941 for the background. The isc_ht hashtables are constant sized making them unsuitable for generic use. Implementing incremental rehashing will allow us to use the isc_ht tables more flexibly.See #2941 for the background. The isc_ht hashtables are constant sized making them unsuitable for generic use. Implementing incremental rehashing will allow us to use the isc_ht tables more flexibly.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3210invalid prefix log message should quote the prefix2022-04-04T12:58:59ZTony Finchinvalid prefix log message should quote the prefixAs reported in https://lists.isc.org/pipermail/bind-users/2022-March/105833.html
The problem log message was:
```
Mar 11 18:14:27 tilapia named[9206]: /etc/bind/named.conf.options:40: invalid prefix, bits [64..71] must be zero
```
It ...As reported in https://lists.isc.org/pipermail/bind-users/2022-March/105833.html
The problem log message was:
```
Mar 11 18:14:27 tilapia named[9206]: /etc/bind/named.conf.options:40: invalid prefix, bits [64..71] must be zero
```
It fails to quote the invalid prefix, so that the reader can easily see which of multiple prefixes is erroneous.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Tony FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3209NOTAUTH errors should log the zone from the query not the nearest match2022-03-30T12:25:17ZTony FinchNOTAUTH errors should log the zone from the query not the nearest matchAs reported in https://lists.isc.org/pipermail/bind-users/2022-March/105832.html
When an UPDATE request arrives with a ZONE section that names a subdomain of a configured zone, `named` returns NOTAUTH, and logs the name of the closest e...As reported in https://lists.isc.org/pipermail/bind-users/2022-March/105832.html
When an UPDATE request arrives with a ZONE section that names a subdomain of a configured zone, `named` returns NOTAUTH, and logs the name of the closest enclosing zone instead of the zone in the request. This makes the log message rather mysterious because the server _is_ in fact authoritative for the zone quoted in the log. This discrepancy can make it difficult to identify what is the cause of NOTAUTH errors.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Tony FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3208Should this error logline be info instead?2022-04-07T13:08:03ZNiek WillemsShould this error logline be info instead?### Summary
After upgrade from 9.16.16 to 9.16.27 we are seeing a new kind of error in the logs when doing a xfer-out.
The transfer finishes at the same micro-second and we have no evidence that shows the transfer went wrong.
We suspect...### Summary
After upgrade from 9.16.16 to 9.16.27 we are seeing a new kind of error in the logs when doing a xfer-out.
The transfer finishes at the same micro-second and we have no evidence that shows the transfer went wrong.
We suspect this error message maybe should have been an info message instead.
### BIND version used
We are running 9.16.27 (because of an advisory still under NDA)
### Steps to reproduce
What we did:
Download source as directed in the advisory.
Build from source and package as rpm.
install and run 9.16.27 over 9.16.16.
observe the logging of outgoing transfers.
### What is the current *bug* behavior?
```
14-Mar-2022 13:31:04.924 xfer-out: info: client @0x7f5cc4024eb0 <ip address>#37444/key <key name> (politie): transfer of 'politie/IN': IXFR started: TSIG <key name> (serial 2022031426 -> 2022031427)
14-Mar-2022 13:31:04.925 xfer-out: error: client @0x7f5cc4024eb0 <ip address>#37444/key <key name> (politie): transfer of 'politie/IN': starting maxtime timer 7200000 ms
14-Mar-2022 13:31:04.925 xfer-out: info: client @0x7f5cc4024eb0 <ip address>#37444/key <key name> (politie): transfer of 'politie/IN': IXFR ended: 1 messages, 6 records, 624 bytes, 0.001 secs (624000 bytes/sec) (serial 2022031427)
```
Possibly:
```
... xfer-out: info: client @0x7f5cc4024eb0 ... starting maxtime timer 7200000 ms
```April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3205Assertion failure in dig with "+tcp" option and multiple servers when there i...2022-04-26T13:29:22ZArаm SаrgsyаnAssertion failure in dig with "+tcp" option and multiple servers when there is a connection errorAssertion failure in dig with "+tcp" option and multiple servers when there is a connection error
The following command, assuming `dig` can not connect to `10.53.0.99`, will produce an assertion failure in current `main` and `v9_18`:
`...Assertion failure in dig with "+tcp" option and multiple servers when there is a connection error
The following command, assuming `dig` can not connect to `10.53.0.99`, will produce an assertion failure in current `main` and `v9_18`:
`dig +tcp @10.53.0.99 @10.53.0.98 a.example`
```
;; Connection to 10.53.0.99#53(10.53.0.99) for a.example failed: connection refused.
;; Connection to 10.53.0.99#53(10.53.0.99) for a.example failed: connection refused.
;; Connection to 10.53.0.99#53(10.53.0.99) for a.example failed: connection refused.
dighost.c:2705: REQUIRE((((query)) != ((void *)0) && ((const isc__magic_t *)((query)))->magic == ((('D') << 24 | ('i') << 16 | ('g') << 8 | ('q'))))) failed, back trace
lib/isc/.libs/libisc-9.17.22.so(+0x367df)[0x7f7862fd87df]
lib/isc/.libs/libisc-9.17.22.so(isc_assertion_failed+0xa)[0x7f7862fd873a]
bin/dig/.libs/lt-dig(+0x135b2)[0x561295c345b2]
bin/dig/.libs/lt-dig(+0x140fd)[0x561295c350fd]
lib/isc/.libs/libisc-9.17.22.so(isc__nm_async_connectcb+0xa5)[0x7f7862fc4fe5]
lib/isc/.libs/libisc-9.17.22.so(isc__nm_connectcb+0xa4)[0x7f7862fc5134]
lib/isc/.libs/libisc-9.17.22.so(isc__nm_failed_connect_cb+0xb8)[0x7f7862fc7778]
lib/isc/.libs/libisc-9.17.22.so(+0x29c63)[0x7f7862fcbc63]
/usr/lib/libuv.so.1(+0x20069)[0x7f7862b17069]
/usr/lib/libuv.so.1(+0x24d0e)[0x7f7862b1bd0e]
/usr/lib/libuv.so.1(uv_run+0x678)[0x7f7862b05438]
lib/isc/.libs/libisc-9.17.22.so(+0x24f0a)[0x7f7862fc6f0a]
lib/isc/.libs/libisc-9.17.22.so(isc__trampoline_run+0x16)[0x7f78630018f6]
/usr/lib/libc.so.6(+0x8d5c2)[0x7f78621965c2]
/usr/lib/libc.so.6(clone+0x44)[0x7f786221b584]
Aborted (core dumped)
```
The reason is that in `dighost.c:tcp_connected()`, after the first server fails to connect `+tries` times (3 by default), `dig` [cancels](https://gitlab.isc.org/isc-projects/bind9/-/blob/e9f4d00bf0fa5984d09d1f6268fb8e51957ab900/bin/dig/dighost.c#L3295) the whole lookup before [starting](https://gitlab.isc.org/isc-projects/bind9/-/blob/e9f4d00bf0fa5984d09d1f6268fb8e51957ab900/bin/dig/dighost.c#L3300) a query with the next server in the lookup.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3203bind9 build sometimes fails when an older bind9 is installed2022-04-04T12:20:31ZDaniel Lukebind9 build sometimes fails when an older bind9 is installed### Summary
bind9's build finds installed (older) versions of bind9 which sometimes causes build failures (ie 9.18.0 fails when 9.16.26 is installed)
### BIND version used
9.18.0
### Steps to reproduce
Build + install bind9 9.16.26 ...### Summary
bind9's build finds installed (older) versions of bind9 which sometimes causes build failures (ie 9.18.0 fails when 9.16.26 is installed)
### BIND version used
9.18.0
### Steps to reproduce
Build + install bind9 9.16.26 into some place the build searches. Try to build bind 9.18.0
### What is the current *bug* behavior?
link fails w/ undefined symbols error
### What is the expected *correct* behavior?
build succeeds
### Relevant configuration files
### Relevant logs and/or screenshots
```
:info:build CC cfg_test-cfg_test.o
:info:build CCLD cfg_test
:info:build Undefined symbols for architecture x86_64:
:info:build "_isc_mem_create", referenced from:
:info:build _main in cfg_test-cfg_test.o
:info:build "_isc_mem_destroy", referenced from:
:info:build _main in cfg_test-cfg_test.o
:info:build ld: symbol(s) not found for architecture x86_64
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
### Possible fixes
I'll attach a patch that fixes the issue (used by MacPorts)April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/3201Avoid using C99 variable length arrays2022-04-04T12:44:11ZTony FinchAvoid using C99 variable length arraysFrom an attacker's point of view, a VLA declaration is essentially a
primitive for performing arbitrary arithmetic on the stack pointer. If
the attacker can control the size of a VLA they have a very powerful
tool for causing memory corr...From an attacker's point of view, a VLA declaration is essentially a
primitive for performing arbitrary arithmetic on the stack pointer. If
the attacker can control the size of a VLA they have a very powerful
tool for causing memory corruption.
To mitigate this kind of attack, and the more general class of stack
clash vulnerabilities, C compilers insert extra code when allocating a
VLA to probe the growing stack one page at a time. If these probes hit
the stack guard page, the program will crash.
From the point of view of a C programmer, there are a few things to
consider about VLAs:
* If it is important to handle allocation failures in a controlled
manner, don't use VLAs. You can use VLAs if it is OK for
unreasonable inputs to cause an uncontrolled crash.
* If the VLA is known to be smaller than some known fixed size,
use a fixed size array and a run-time check to ensure it is large
enough. This will be more efficient than the compiler's stack
probes that need to cope with arbitrary-size VLAs.
* If the VLA might be large, allocate it on the heap. The heap
allocator can allocate multiple pages in one shot, whereas the
stack clash probes work one page at a time.
Most of the existing uses of VLAs in BIND are in test code, but there
is one instance in `named`, in the GSS-TSIG verification code. In
this case the size of the VLA comes from the size of the signature in
the request; but it is safe because the code has previously checked
that the signature has a reasonable size. However, the safety checks
are in the generic TSIG implementation, and the risky VLA usage is in
the GSS-specific code, and they are separated by the DST indirection
layer, so it wasn't immediately obvious to me that the risky VLA was
in fact safe. And in fact this risky VLA is completely unnecessary,
because the GSS signature can be verified in place without being
copied to the stack.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Tony FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3200Single write timer could keep the TCP connection lingering2022-04-05T17:27:45ZOndřej SurýSingle write timer could keep the TCP connection lingeringThe single per-socket write timer would get restarted for every new write (call to `isc_nm_send()`. This turned out to be insufficient because the other side could keep resetting the timer by sending more DNS messages, but never reading...The single per-socket write timer would get restarted for every new write (call to `isc_nm_send()`. This turned out to be insufficient because the other side could keep resetting the timer by sending more DNS messages, but never reading back the responses.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3199a few developer documentation nits2022-04-04T12:15:20ZTony Fincha few developer documentation nitsA few little things I spotted when re-reading `doc/dev` and `doc/design`:
* a few files that contain duplicated text
* a file describing a feature that did not survive the 9.9 dev cycle
* GitLab not RT
* I don't think we support oper...A few little things I spotted when re-reading `doc/dev` and `doc/design`:
* a few files that contain duplicated text
* a file describing a feature that did not survive the 9.9 dev cycle
* GitLab not RT
* I don't think we support operating systems released in the 1990s any more!
* typos and formattingApril 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Tony FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3195A function cleanup bug in dns_request_createraw()2022-04-04T11:59:12ZArаm SаrgsyаnA function cleanup bug in dns_request_createraw()In lib/dns/request.c:dns_request_createraw(), when get_dispatch() returns an error result, the code [jumps](https://gitlab.isc.org/isc-projects/bind9/-/blob/e229d46a87b7e717b2981f6f93ab34cba2ab4d87/lib/dns/request.c#L561) to the `cleanup...In lib/dns/request.c:dns_request_createraw(), when get_dispatch() returns an error result, the code [jumps](https://gitlab.isc.org/isc-projects/bind9/-/blob/e229d46a87b7e717b2981f6f93ab34cba2ab4d87/lib/dns/request.c#L561) to the `cleanup` label, which will leave a previous attachment to the `request` pointer unattached.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3194CID 350472: (USE_AFTER_FREE) in /lib/dns/request.c: 805 in dns_request_create...2022-04-04T15:16:05ZOndřej SurýCID 350472: (USE_AFTER_FREE) in /lib/dns/request.c: 805 in dns_request_createvia()```
/lib/dns/request.c: 805 in dns_request_createvia()
799 /* connect failed, detach here */
800 req_detach(&(dns_request_t *){ request });
801
802 cleanup:
803 isc_task_detach(&(isc_task_t *){ task });
804 /...```
/lib/dns/request.c: 805 in dns_request_createvia()
799 /* connect failed, detach here */
800 req_detach(&(dns_request_t *){ request });
801
802 cleanup:
803 isc_task_detach(&(isc_task_t *){ task });
804 /* final detach to shut down request */
CID 350472: (USE_AFTER_FREE)
Calling "req_detach" frees pointer "request" which has already been freed.
805 req_detach(&request);
806 req_log(ISC_LOG_DEBUG(3), "dns_request_createvia: failed %s",
807 isc_result_totext(result));
808 return (result);
809 }
810
```
```
/lib/dns/request.c: 805 in dns_request_createvia()
799 /* connect failed, detach here */
800 req_detach(&(dns_request_t *){ request });
801
802 cleanup:
803 isc_task_detach(&(isc_task_t *){ task });
804 /* final detach to shut down request */
CID 350472: (USE_AFTER_FREE)
Calling "req_detach" frees pointer "request" which has already been freed.
805 req_detach(&request);
806 req_log(ISC_LOG_DEBUG(3), "dns_request_createvia: failed %s",
807 isc_result_totext(result));
808 return (result);
809 }
810
```April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/3193CID 350473: Null pointer dereferences (FORWARD_NULL) in bin/dig/dighost.c: 29...2022-04-26T13:25:39ZOndřej SurýCID 350473: Null pointer dereferences (FORWARD_NULL) in bin/dig/dighost.c: 2904 in udp_ready()```
/bin/dig/dighost.c: 2904 in udp_ready()
2898
2899 if (eresult == ISC_R_CANCELED || query->canceled) {
2900 dig_lookup_t *l = query->lookup;
2901
2902 debug("in cancel handler");
2903 query_detach(&que...```
/bin/dig/dighost.c: 2904 in udp_ready()
2898
2899 if (eresult == ISC_R_CANCELED || query->canceled) {
2900 dig_lookup_t *l = query->lookup;
2901
2902 debug("in cancel handler");
2903 query_detach(&query);
CID 350473: Null pointer dereferences (FORWARD_NULL)
Dereferencing null pointer "query".
2904 if (!query->canceled) {
2905 cancel_lookup(l);
2906 }
2907 lookup_detach(&l);
2908 return;
2909 } else if (eresult != ISC_R_SUCCESS) {
```April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3191Issue 45178 in oss-fuzz: bind9:dns_master_load_fuzzer: Integer-overflow in ge...2022-04-04T13:24:21ZMark AndrewsIssue 45178 in oss-fuzz: bind9:dns_master_load_fuzzer: Integer-overflow in generateNew issue 45178 by ClusterFuzz-External: bind9:dns_master_load_fuzzer: Integer-overflow in generate
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45178
Detailed Report: https://oss-fuzz.com/testcase?key=6397143751983104
Project...New issue 45178 by ClusterFuzz-External: bind9:dns_master_load_fuzzer: Integer-overflow in generate
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45178
Detailed Report: https://oss-fuzz.com/testcase?key=6397143751983104
Project: bind9
Fuzzing Engine: libFuzzer
Fuzz Target: dns_master_load_fuzzer
Job Type: libfuzzer_ubsan_bind9
Platform Id: linux
Crash Type: Integer-overflow
Crash Address:
Crash State:
generate
load_text
dns_master_loadbuffer
Sanitizer: undefined (UBSAN)
Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_ubsan_bind9&range=202202240600:202202250603
Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6397143751983104
master.c:849:31: runtime error: signed integer overflow: 19 + 2147483645 cannot be represented in type 'int'April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3190Potential improvements to post-zone-load response policy processing for 9.16 ...2023-05-01T07:44:39ZCathy AlmondPotential improvements to post-zone-load response policy processing for 9.16 and beyondPer [Support ticket #20228](https://support.isc.org/Ticket/Display.html?id=20228)
The zone in this example is exceptionally big and takes 20-24s to complete the entire post-load processing of the response policy afet the zone itself is ...Per [Support ticket #20228](https://support.isc.org/Ticket/Display.html?id=20228)
The zone in this example is exceptionally big and takes 20-24s to complete the entire post-load processing of the response policy afet the zone itself is loaded or updated via IXFR
Demonstrably, the policy updating **is** iterating, but it is doing so on threads that might otherwise be handling queries, so it is the luck of the inbound query->thread allocation whether or not something gets temporarily delayed while the current iteration completes and returns to the back of the "to do" queue.
Noted from the [stack traces](https://support.isc.org/Ticket/Attachment/761299/492768/), that there is evidence of:
a) It's trying to tweak the quantum for how long it runs (should it even be trying to do this - is this going to be effective or not on 9.16 anyway, and will it further slow things down by going through this additional processing?)
b) There are hash tables involved - we see this sort of thing on the tops of stacks - are the hash tables big enough for managing a really mammoth response policy (do we scale them accordingly)?
```
#0 0x00007f2394f847a5 in malloc () from /usr/lib64/libc.so.6
#1 0x00007f2396a5a2c7 in default_memalloc () from /usr/lib64/libisc-9.16.26-S1.so
#2 0x00007f2396a59f21 in mem_get () from /usr/lib64/libisc-9.16.26-S1.so
#3 0x00007f2396a5b917 in isc___mem_get () from /usr/lib64/libisc-9.16.26-S1.so
#4 0x00007f2396a5f25d in isc__mem_get () from /usr/lib64/libisc-9.16.26-S1.so
#5 0x00007f2396a4b390 in isc_ht_add () from /usr/lib64/libisc-9.16.26-S1
```
and:
```
#0 0x00007f2396a7ec9e in isc_siphash24 () from /usr/lib64/libisc-9.16.26-S1.so
#1 0x00007f2396a4ac8f in isc_hash64 () from /usr/lib64/libisc-9.16.26-S1.so
#2 0x00007f2396a4b2f9 in isc_ht_add () from /usr/lib64/libisc-9.16.26-S1.so
```
c) Why is this a problem on 9.16 but wasn't on 9.11? Likely bad luck - some queries get allocated to a thread that happens to be handling an RPZ policy update, and have to wait for it to finish its current iteration before they can be processed?April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/3189Version numbers are printed inconsistently2022-04-26T13:26:16ZTony FinchVersion numbers are printed inconsistentlyMost of the BIND utilities report their version number to `stderr`. A few print to `stdout` instead: `named`, `named-checkconf`, `named-checkzone`. The utilities that print to `stderr` then `exit(0)`, so they disagree with themselves abo...Most of the BIND utilities report their version number to `stderr`. A few print to `stdout` instead: `named`, `named-checkconf`, `named-checkzone`. The utilities that print to `stderr` then `exit(0)`, so they disagree with themselves about whether reporting the version number is an error or not. Since the user asked for the version number it seems more logical to make it a non-error, i.e. print to `stdout` and `exit(0)`.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Tony FinchTony Finch