BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2022-04-04T12:20:31Zhttps://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/3185Follow-up from "fix zone documentation in named.conf man page"2022-03-15T13:16:48ZMatthijs Mekkingmatthijs@isc.orgFollow-up from "fix zone documentation in named.conf man page"We actually said yesterday in the team meeting that we should add a note about the `zone` statement can also be added to the `view` statement in the output of `rst-options.pl`.We actually said yesterday in the team meeting that we should add a note about the `zone` statement can also be added to the `view` statement in the output of `rst-options.pl`.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3184query context management issues in dighost.c2022-04-26T13:25:07ZOndřej Surýquery context management issues in dighost.cFor the reference, the _cancel_lookup() function iterates through
the lookup's queries list and detaches them. In the ideal scenario,
that should be the last reference and the query will be destroyed
after that, but it is also possible t...For the reference, the _cancel_lookup() function iterates through
the lookup's queries list and detaches them. In the ideal scenario,
that should be the last reference and the query will be destroyed
after that, but it is also possible that we are still expecting a
callback, which also holds a reference (for example, _cancel_lookup()
could have been called from recv_done(), when send_done() was still
not executed).
The start_udp() and start_tcp() functions are currently designed in
slightly different ways: start_udp() creates a new query attachment
`connectquery`, to be called in the callback function, while
start_tcp() does not, which is a bug, but is hidden by the fact
that when the query is being erroneously destroyed prematurely (before
_cancel_lookup() is called) in the result of that, it also gets
de-listed from the lookup's queries' list, so _cancel_lookup() doesn't
even try to detach it.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/3180Replace netievent lock-free queue with simple locked queue2022-05-25T14:03:28ZEvan HuntReplace netievent lock-free queue with simple locked queueThe current implementation of isc_queue uses Michael-Scott lock-free queue that in turn uses hazard pointers. It was discovered that the way we use the isc_queue, such complicated mechanism isn't really needed, because most of the time, ...The current implementation of isc_queue uses Michael-Scott lock-free queue that in turn uses hazard pointers. It was discovered that the way we use the isc_queue, such complicated mechanism isn't really needed, because most of the time, we either execute the work directly when on nmthread (in case of UDP) or schedule the work from the matching nmthreads.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/3163Add remote TLS certificate verification support, implement Strict and Mutual ...2022-05-16T10:24:55ZArtem BoldarievAdd remote TLS certificate verification support, implement Strict and Mutual TLS authentication[RFC 9103, Section 9.3,](https://www.rfc-editor.org/rfc/rfc9103.html#name-tls) discusses three TLS-based authentication mechanisms:
- Opportunistic TLS;
- Strict TLS;
- Mutual TLS.
Currently, the released version of BIND and its comple...[RFC 9103, Section 9.3,](https://www.rfc-editor.org/rfc/rfc9103.html#name-tls) discusses three TLS-based authentication mechanisms:
- Opportunistic TLS;
- Strict TLS;
- Mutual TLS.
Currently, the released version of BIND and its complementary tools have support for the first one.
In order to implement support for Strict and Mutual TLS, the functionality to verify the remote TLS certificates needs to be added first.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3145"dig +nssearch" does not exit until interrupted in BIND 9.18+2022-04-26T13:29:46ZMichał Kępień"dig +nssearch" does not exit until interrupted in BIND 9.18+On my laptop, I am consistently observing the following behavior:
```
$ dig +nssearch isc.org.
SOA ns-int.isc.org. hostmaster.isc.org. 2022020916 7200 3600 24796800 3600 from server 51.75.79.143 in 19 ms.
SOA ns-int.isc.org. hostmaster....On my laptop, I am consistently observing the following behavior:
```
$ dig +nssearch isc.org.
SOA ns-int.isc.org. hostmaster.isc.org. 2022020916 7200 3600 24796800 3600 from server 51.75.79.143 in 19 ms.
SOA ns-int.isc.org. hostmaster.isc.org. 2022020916 7200 3600 24796800 3600 from server 199.6.1.52 in 23 ms.
SOA ns-int.isc.org. hostmaster.isc.org. 2022020916 7200 3600 24796800 3600 from server 2001:500:60:d::52 in 23 ms.
SOA ns-int.isc.org. hostmaster.isc.org. 2022020916 7200 3600 24796800 3600 from server 2001:4f8:1:f::73 in 156 ms.
SOA ns-int.isc.org. hostmaster.isc.org. 2022020916 7200 3600 24796800 3600 from server 149.20.1.73 in 166 ms.
SOA ns-int.isc.org. hostmaster.isc.org. 2022020916 7200 3600 24796800 3600 from server 2001:41d0:701:1100::2c92 in 166 ms.
SOA ns-int.isc.org. hostmaster.isc.org. 2022020916 7200 3600 24796800 3600 from server 199.254.63.254 in 169 ms.
SOA ns-int.isc.org. hostmaster.isc.org. 2022020916 7200 3600 24796800 3600 from server 2001:500:2c::254 in 246 ms.
<...hangs...>
^C$
```
AFAICT, this issue is not specific to my local environment, to the
address family used, etc.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/3142Add checkconf check for dnssec-policy keys algorithm2022-05-06T13:19:41ZMatthijs Mekkingmatthijs@isc.orgAdd checkconf check for dnssec-policy keys algorithmSo that this will not be accepted
```
keys {
ksk lifetime unlimited algorithm 8 2048 ;
zsk lifetime 30d algorithm 13;
};
```So that this will not be accepted
```
keys {
ksk lifetime unlimited algorithm 8 2048 ;
zsk lifetime 30d algorithm 13;
};
```April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/3128"dig" from BIND 9.18.0 does not recover from a isc_nm_udpconnect() failure2022-04-26T13:28:40ZThomas Amgarten"dig" from BIND 9.18.0 does not recover from a isc_nm_udpconnect() failure<!--
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
Using the dig-utility from BIND-9.18.0 (self-compiled), I see a curious behavior when using the "+trace"-option. The dig-tool does in most cases just queries the local resolver for the root-servers and does not follow the delegations:
```
$ /usr/local/bind-9.18.0/bin/dig @127.0.0.1 +trace www.isc.org
; <<>> DiG 9.18.0 <<>> @127.0.0.1 +trace www.isc.org
; (1 server found)
;; global options: +cmd
. 514551 IN NS m.root-servers.net.
. 514551 IN NS c.root-servers.net.
. 514551 IN NS a.root-servers.net.
. 514551 IN NS i.root-servers.net.
. 514551 IN NS l.root-servers.net.
. 514551 IN NS k.root-servers.net.
. 514551 IN NS e.root-servers.net.
. 514551 IN NS d.root-servers.net.
. 514551 IN NS h.root-servers.net.
. 514551 IN NS f.root-servers.net.
. 514551 IN NS g.root-servers.net.
. 514551 IN NS b.root-servers.net.
. 514551 IN NS j.root-servers.net.
. 514551 IN RRSIG NS 8 0 518400 20220221050000 20220208040000 9799 . fa3vdWBzC56rEdTkuEVhCX2iALLBoYn2H29psjgHC5wPv0ws6wqrC8yG jKJgWRS3xS92NJy8RsrTiv/K+tRoC0AxgQ1kcFJ6UKyfuSuYEkXEOpnk cqQhEHxDVBN7eBQ6mdIuJ/rTzoBJ8PCIW75aHv+OH/3Qt/tf74nZnH0s rptFsc7/d/O56FIu2bzBojBxdi5FUA8fzffKP9eQfyN8wMAyLXfwUtDw LkyAQZMGeTTLA1qWOV0DK8sTBS+YJwOz1PPcQFyDbU9PG6hbXjvBXINg 1v1+17/3knkhICiL8FN4ylEHj8YVMrFNtzhlIipXwy/V/SEhKsHgyJHv BNAhWw==
;; Received 1137 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms
```
In few tries/situations, dig (9.18.0) begins iterating through the dns-hierarchy, but in the most cases, dig stops after querying the local resolver or after iterating one or two steps. I've rarely seen, that dig-9.18.0 finished through the end (the final authoritative server).
```
$ /usr/local/bind-9.18.0/bin/dig @127.0.0.1 +trace www.isc.org
; <<>> DiG 9.18.0 <<>> @127.0.0.1 +trace www.isc.org
; (1 server found)
;; global options: +cmd
. 514510 IN NS l.root-servers.net.
. 514510 IN NS h.root-servers.net.
. 514510 IN NS f.root-servers.net.
. 514510 IN NS c.root-servers.net.
. 514510 IN NS e.root-servers.net.
. 514510 IN NS b.root-servers.net.
. 514510 IN NS k.root-servers.net.
. 514510 IN NS d.root-servers.net.
. 514510 IN NS g.root-servers.net.
. 514510 IN NS a.root-servers.net.
. 514510 IN NS i.root-servers.net.
. 514510 IN NS j.root-servers.net.
. 514510 IN NS m.root-servers.net.
. 514510 IN RRSIG NS 8 0 518400 20220221050000 20220208040000 9799 . fa3vdWBzC56rEdTkuEVhCX2iALLBoYn2H29psjgHC5wPv0ws6wqrC8yG jKJgWRS3xS92NJy8RsrTiv/K+tRoC0AxgQ1kcFJ6UKyfuSuYEkXEOpnk cqQhEHxDVBN7eBQ6mdIuJ/rTzoBJ8PCIW75aHv+OH/3Qt/tf74nZnH0s rptFsc7/d/O56FIu2bzBojBxdi5FUA8fzffKP9eQfyN8wMAyLXfwUtDw LkyAQZMGeTTLA1qWOV0DK8sTBS+YJwOz1PPcQFyDbU9PG6hbXjvBXINg 1v1+17/3knkhICiL8FN4ylEHj8YVMrFNtzhlIipXwy/V/SEhKsHgyJHv BNAhWw==
;; Received 1137 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
org. 172800 IN NS a0.org.afilias-nst.info.
org. 172800 IN NS a2.org.afilias-nst.info.
org. 172800 IN NS b0.org.afilias-nst.org.
org. 172800 IN NS b2.org.afilias-nst.org.
org. 172800 IN NS c0.org.afilias-nst.info.
org. 172800 IN NS d0.org.afilias-nst.org.
org. 86400 IN DS 26974 8 2 4FEDE294C53F438A158C41D39489CD78A86BEB0D8A0AEAFF14745C0D 16E1DE32
org. 86400 IN RRSIG DS 8 1 86400 20220221050000 20220208040000 9799 . S8iG14jGn8yS3WsOFOmuRT1omQto8Lwx5mpzTe81Wr3qny2i5NcIbmIj aionGUWQwgxax6lMApHaWHDsq8l2bkodRdRrFZGcQnA2spaQVDUbGJT4 nQxHUL7L7IRw5Vflm8p1EO7EZLV7aKW69dsIDEeuYPp31J3cemjCzD3X e3bHYQKwtrvDz2TVVTaGzMZsgdH0WV+xuJRqV8p1YshbxDE8T+hvXsyF GeL0Sun6ioXfq5lWNfH/hI5hmmMoxoPPppgmNZ5l2Kl5PxzXGYaK832R Kp9Nx8yVRYbAfFhxwC6J2HMPDka+o6lYOCTBhyqkJ+33rk5NH+IGml9k 6mepog==
;; Received 777 bytes from 192.203.230.10#53(e.root-servers.net) in 2 ms
```
It doesn't matter which address/record I try to resolve (www.google.com, www.microsoft.com, www.switch.ch...).
Using a dig older than 9.18.0 (from version 9.11.26 in that case) on the same server and using initially the same server (@127.0.0.1), then this version **always** iterates to the final authoritative server:
```
$ /usr/bin/dig @127.0.0.1 +trace www.isc.org
; <<>> DiG 9.11.26-RedHat-9.11.26-4.el8_4 <<>> @127.0.0.1 +trace www.isc.org
; (1 server found)
;; global options: +cmd
. 514368 IN NS g.root-servers.net.
. 514368 IN NS h.root-servers.net.
. 514368 IN NS l.root-servers.net.
. 514368 IN NS b.root-servers.net.
. 514368 IN NS e.root-servers.net.
. 514368 IN NS d.root-servers.net.
. 514368 IN NS k.root-servers.net.
. 514368 IN NS f.root-servers.net.
. 514368 IN NS m.root-servers.net.
. 514368 IN NS c.root-servers.net.
. 514368 IN NS a.root-servers.net.
. 514368 IN NS j.root-servers.net.
. 514368 IN NS i.root-servers.net.
. 514368 IN RRSIG NS 8 0 518400 20220221050000 20220208040000 9799 . fa3vdWBzC56rEdTkuEVhCX2iALLBoYn2H29psjgHC5wPv0ws6wqrC8yG jKJgWRS3xS92NJy8RsrTiv/K+tRoC0AxgQ1kcFJ6UKyfuSuYEkXEOpnk cqQhEHxDVBN7eBQ6mdIuJ/rTzoBJ8PCIW75aHv+OH/3Qt/tf74nZnH0s rptFsc7/d/O56FIu2bzBojBxdi5FUA8fzffKP9eQfyN8wMAyLXfwUtDw LkyAQZMGeTTLA1qWOV0DK8sTBS+YJwOz1PPcQFyDbU9PG6hbXjvBXINg 1v1+17/3knkhICiL8FN4ylEHj8YVMrFNtzhlIipXwy/V/SEhKsHgyJHv BNAhWw==
;; Received 1137 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
org. 172800 IN NS b2.org.afilias-nst.org.
org. 172800 IN NS a2.org.afilias-nst.info.
org. 172800 IN NS a0.org.afilias-nst.info.
org. 172800 IN NS b0.org.afilias-nst.org.
org. 172800 IN NS d0.org.afilias-nst.org.
org. 172800 IN NS c0.org.afilias-nst.info.
org. 86400 IN DS 26974 8 2 4FEDE294C53F438A158C41D39489CD78A86BEB0D8A0AEAFF14745C0D 16E1DE32
org. 86400 IN RRSIG DS 8 1 86400 20220221050000 20220208040000 9799 . S8iG14jGn8yS3WsOFOmuRT1omQto8Lwx5mpzTe81Wr3qny2i5NcIbmIj aionGUWQwgxax6lMApHaWHDsq8l2bkodRdRrFZGcQnA2spaQVDUbGJT4 nQxHUL7L7IRw5Vflm8p1EO7EZLV7aKW69dsIDEeuYPp31J3cemjCzD3X e3bHYQKwtrvDz2TVVTaGzMZsgdH0WV+xuJRqV8p1YshbxDE8T+hvXsyF GeL0Sun6ioXfq5lWNfH/hI5hmmMoxoPPppgmNZ5l2Kl5PxzXGYaK832R Kp9Nx8yVRYbAfFhxwC6J2HMPDka+o6lYOCTBhyqkJ+33rk5NH+IGml9k 6mepog==
;; Received 811 bytes from 192.36.148.17#53(i.root-servers.net) in 11 ms
isc.org. 86400 IN NS ns2.isc.org.
isc.org. 86400 IN NS ns.isc.afilias-nst.info.
isc.org. 86400 IN NS ns1.isc.org.
isc.org. 86400 IN NS ns3.isc.org.
isc.org. 86400 IN DS 7250 13 2 A30B3F78B6DDE9A4A9A2AD0C805518B4F49EC62E7D3F4531D33DE697 CDA01CB2
isc.org. 86400 IN RRSIG DS 8 2 86400 20220222152200 20220201142200 7986 org. cFxS3wGUhe85mBa6JNo7T0Z1KdpKoi9KeWEJtp8EKGfQp0PGBGWWrWwf oz+hH34L8ttXY5n+54VBo2C8O3cp/g95totmdQezCyoZYDCvRqaGEplp yjJCWY/KaRJ4KcHlkZ6LIt1JOs+eoH4njTfV9l8XYBpVIqYaNFSwMKbf lwE=
;; Received 446 bytes from 199.249.120.1#53(b2.org.afilias-nst.org) in 20 ms
www.isc.org. 300 IN CNAME dualstack.osff2.map.fastly.net.
www.isc.org. 300 IN RRSIG CNAME 13 3 300 20220309140450 20220207132719 27566 isc.org. QRsTnA1etMEBeA/txjOtLVIQXHSo22uuBQNUsIQXkN6j8njRVZ1iEYsV JVgG1f0R2QwNRomK23G9EcvGPaBCcw==
;; Received 215 bytes from 199.6.1.52#53(ns2.isc.org) in 13 ms
```
### BIND version used
9.18.0
### Steps to reproduce
Using the latest dig:
```
/usr/local/bind-9.18.0/bin/dig @127.0.0.1 +trace www.isc.org
```
### What is the current *bug* behavior?
The utility does not iterates to the final authoritative server and queries this server for the requested resource record.
### What is the expected *correct* behavior?
An answer for the requested RR from the final authoritative server like it works with dig 9.11.26 (for example).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/3105Assertion failure on shutdown in req_senddone()2022-03-08T08:50:44ZMichal NowakAssertion failure on shutdown in req_senddone()This seems to be the same issue as isc-projects/bind9#2951 but it has the fix isc-projects/bind9!5715 in and the problem still occurs in the CI.
Job [#2240130](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2240130) failed for 710f62b...This seems to be the same issue as isc-projects/bind9#2951 but it has the fix isc-projects/bind9!5715 in and the problem still occurs in the CI.
Job [#2240130](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2240130) failed for 710f62bf39a925c9a580192ec5ce8dee1ea66a06:
```
D:inline:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D inline-ns2 -X named.lock -m'.
D:inline:Program terminated with signal SIGABRT, Aborted.
D:inline:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:inline:[Current thread is 1 (Thread 0x7f9c82efb700 (LWP 28048))]
D:inline:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:inline:#1 0x00007f9c885cc537 in __GI_abort () at abort.c:79
D:inline:#2 0x0000000000420cbc in assertion_failed (file=0x7f9c89033a11 "request.c", line=<optimized out>, type=<optimized out>, cond=<optimized out>) at main.c:238
D:inline:#3 0x00007f9c890b726a in isc_assertion_failed (file=0x2 <error: Cannot access memory at address 0x2>, line=-2098243744, line@entry=1030, type=type@entry=isc_assertiontype_require, cond=0x7f9c885e2ce1 <__GI_raise+321> "H\213\204$\b\001") at assertions.c:49
D:inline:#4 0x00007f9c88f82172 in req_senddone (eresult=<optimized out>, region=<optimized out>, arg=<optimized out>) at request.c:1030
D:inline:#5 0x00007f9c88eb8cb5 in send_done (handle=0x7f9c75389780, result=ISC_R_CANCELED, cbarg=0x0) at dispatch.c:1864
D:inline:#6 0x00007f9c890a7cbf in isc__nm_async_sendcb (worker=<optimized out>, ev0=ev0@entry=0x7f9c7538a080) at netmgr/netmgr.c:2838
D:inline:#7 0x00007f9c890a4362 in process_netievent (worker=worker@entry=0x7f9c85c49c80, ievent=ievent@entry=0x7f9c7538a080) at netmgr/netmgr.c:972
D:inline:#8 0x00007f9c8909fa81 in process_queue (worker=0x7f9c85c49c80, type=NETIEVENT_NORMAL) at netmgr/netmgr.c:1010
D:inline:#9 process_all_queues (worker=0x7f9c85c49c80) at netmgr/netmgr.c:756
D:inline:#10 async_cb (handle=0x7f9c85c49fe0) at netmgr/netmgr.c:785
D:inline:#11 0x00007f9c889bce83 in uv__async_io (loop=0x7f9c85c49c90, w=0x7f9c85c49e58, events=1) at /usr/src/libuv-v1.43.0/src/unix/async.c:163
D:inline:#12 0x00007f9c889d8b87 in uv__io_poll (loop=0x7f9c85c49c90, timeout=0) at /usr/src/libuv-v1.43.0/src/unix/epoll.c:374
D:inline:#13 0x00007f9c889bd86c in uv_run (loop=0x7f9c85c49c90, mode=UV_RUN_DEFAULT) at /usr/src/libuv-v1.43.0/src/unix/core.c:389
D:inline:#14 0x00007f9c8909fbf1 in nm_thread (worker0=0x7f9c85c49c80) at netmgr/netmgr.c:691
D:inline:#15 0x00007f9c890dede5 in isc__trampoline_run (arg=0x2372760) at trampoline.c:187
D:inline:#16 0x00007f9c88774ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
D:inline:#17 0x00007f9c886a4def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
[core.28030-backtrace.txt](/uploads/454199c1540460b792772cad022aea8f/core.28030-backtrace.txt)April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/3028dig crashes when interrupted while waiting for TCP response2022-04-26T13:33:28ZPetr Špačekpspacek@isc.orgdig crashes when interrupted while waiting for TCP response<!--
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
dig crashes when interrupted while waiting for TCP response
### BIND version used
* ~"v9.17": c52a38352378d94129ccd590281c63fbe58dcb00
* ~"v9.11" and ~"v9.16" not affected
### Steps to reproduce
SIGINT dig while it's waiting for TCP response. :boom:
1. Run python3 [tcphang.py](/uploads/a03cf98515d2ea2794cbe0b9b7a298ae/tcphang.py)
2. Run `dig -d 99 +tcp @127.0.0.1 .`
3. SIGINT dig before it timeouts
(`timeout --signal=SIGINT 1 dig -d 99 +tcp @127.0.0.1 .` to do that in one go)
### What is the current *bug* behavior?
```
dighost.c:1683: INSIST(query->readhandle == ((void *)0)) failed, back trace
```
```
(gdb) bt
#0 0x00007ffff6b15d22 in raise () from /usr/lib/libc.so.6
#1 0x00007ffff6aff862 in abort () from /usr/lib/libc.so.6
#2 0x00007ffff7a514b5 in isc_assertion_failed (file=0x55555557605c "dighost.c", line=1683,
type=isc_assertiontype_insist, cond=0x5555555770b8 "query->readhandle == ((void *)0)") at assertions.c:48
#3 0x0000555555567cf0 in _query_detach (queryp=0x7fffffffe5d8, file=0x55555557605c "dighost.c", line=4216)
at dighost.c:1683
#4 0x0000555555571c3b in cancel_all () at dighost.c:4216
#5 0x0000555555562bc9 in dig_shutdown () at dig.c:2946
#6 0x0000555555562c2f in main (argc=4, argv=0x7fffffffe748) at dig.c:2957
```
### What is the expected *correct* behavior?
Obviously, it should not crash.
### Relevant configuration files
None, I believe.
### Relevant logs and/or screenshots
<details>
```
$ timeout --signal=SIGINT 1 /tmp/main/bin/dig -d 99 +tcp @127.0.0.1 .
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() = 0x7fd7117c0000->references = 1
digrc (open)
main parsing -d
main parsing 99
clone_lookup()
make_empty_lookup()
make_empty_lookup() = 0x7fd7117c1800->references = 1
clone_server_list()
looking up 99
main parsing +tcp
main parsing @127.0.0.1
make_server(127.0.0.1)
main parsing .
clone_lookup()
make_empty_lookup()
make_empty_lookup() = 0x7fd7117c3000->references = 1
clone_server_list()
looking up .
dig_startup()
lock_lookup dighost.c:4186
success
start_lookup()
setup_lookup(0x7fd7117c1800)
resetting lookup counter.
using root origin
recursive query
AD query
add_question()
starting to render the message
add_opt()
done rendering
create query 0x7fd710835000 linked to lookup 0x7fd7117c1800
dighost.c:2083:lookup_attach(0x7fd7117c1800) = 2
dighost.c:2587:new_query(0x7fd710835000) = 1
do_lookup()
start_tcp(0x7fd710835000)
dighost.c:2693:query_attach(0x7fd710835000) = 2
query->servname = 127.0.0.1
unlock_lookup dighost.c:4188
tcp_connected()
tcp_connected(0x7fd710813300, success, 0x7fd710835000)
lock_lookup dighost.c:3231
success
dighost.c:3232:lookup_attach(0x7fd7117c1800) = 3
launch_next_query()
dighost.c:3127:lookup_attach(0x7fd7117c1800) = 4
recvcount=1
have local timeout of 10000
dighost.c:3148:query_attach(0x7fd710835000) = 3
sending a request in launch_next_query
dighost.c:3179:query_attach(0x7fd710835000) = 4
sendcount=1
dighost.c:3202:lookup_detach(0x7fd7117c1800) = 3
dighost.c:1676:query_detach(0x7fd710835000) = 3
dighost.c:3303:query_detach(0x7fd710835000) = 2
dighost.c:3304:lookup_detach(0x7fd7117c1800) = 2
unlock_lookup dighost.c:3305
send_done(0x7fd710813300, success, 0x7fd710835000)
sendcount=0
lock_lookup dighost.c:2615
success
dighost.c:2629:lookup_attach(0x7fd7117c1800) = 3
dighost.c:2648:query_detach(0x7fd710835000) = 1
dighost.c:2649:lookup_detach(0x7fd7117c1800) = 2
check_if_done()
list full
pending lookup 0x7fd7117c3000
unlock_lookup dighost.c:2652
destroy_lookup
cancel_all()
lock_lookup dighost.c:4202
success
canceling pending query 0x7fd710835000, belonging to 0x7fd7117c1800
dighost.c:4216:query_detach(0x7fd710835000) = 0
dighost.c:1683: INSIST(query->readhandle == ((void *)0)) failed, back trace
/tmp/main/lib/libisc-9.17.20.so(+0x4059d)[0x7fd7152cd59d]
recv_done(0x7fd710813300, end of file, 0x7fd711579d90, 0x7fd710835000)
lock_lookup dighost.c:3579
/tmp/main/lib/libisc-9.17.20.so(isc_assertion_failed+0x31)[0x7fd7152cd4b0]
/tmp/main/bin/dig(+0x13cf0)[0x55d41bb0fcf0]
/tmp/main/bin/dig(+0x1dc3b)[0x55d41bb19c3b]
/tmp/main/bin/dig(+0xebc9)[0x55d41bb0abc9]
/tmp/main/bin/dig(+0xec2f)[0x55d41bb0ac2f]
/usr/lib/libc.so.6(__libc_start_main+0xd5)[0x7fd71437cb25]
/tmp/main/bin/dig(+0x5e9e)[0x55d41bb01e9e]
timeout: the monitored command dumped core
```
</details>
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)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/3020netmgr/netmgr.c:1737: (...) failed2022-04-26T13:28:04ZNelson A. de Oliveiranetmgr/netmgr.c:1737: (...) failedHi!
I am seeing this for some internal DNS queries:
```
$ host www.unesp.br 200.145.86.1
Using domain server:
Name: 200.145.86.1
Address: 200.145.86.1#53
Aliases:
www.unesp.br has address 200.145.6.98
netmgr/netmgr.c:1737: REQUIRE(((...Hi!
I am seeing this for some internal DNS queries:
```
$ host www.unesp.br 200.145.86.1
Using domain server:
Name: 200.145.86.1
Address: 200.145.86.1#53
Aliases:
www.unesp.br has address 200.145.6.98
netmgr/netmgr.c:1737: REQUIRE((((handle) != ((void *)0) && ((const isc__magic_t *)(handle))->magic == ((('N') << 24 | ('M') << 16 | ('H') << 8 | ('D')))) && __extension__ ({ __auto_type __atomic_load_ptr = (&(handle)->references); __typeof__ ((void)0, *__atomic_load_ptr) __atomic_load_tmp; __atomic_load (__atomic_load_ptr, &__atomic_load_tmp, (5)); __atomic_load_tmp; }) > 0)) failed, back trace
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(+0x3552f)[0x7fae10e0f52f]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(isc_assertion_failed+0xa)[0x7fae10e0f48a]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(isc__nmhandle_attach+0x63)[0x7fae10df9aa3]
host(+0xe3aa)[0x55c5f12963aa]
host(+0xf2c7)[0x55c5f12972c7]
host(+0x1177b)[0x55c5f129977b]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(isc__nm_async_readcb+0xad)[0x7fae10dfce6d]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(isc__nm_readcb+0x97)[0x7fae10dfcf97]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(+0x30cd0)[0x7fae10e0acd0]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(isc__nm_udp_read_cb+0x46)[0x7fae10e0c4c6]
/usr/lib/x86_64-linux-gnu/libuv.so.1(+0x1ee8d)[0x7fae10956e8d]
/usr/lib/x86_64-linux-gnu/libuv.so.1(+0x22c75)[0x7fae1095ac75]
/usr/lib/x86_64-linux-gnu/libuv.so.1(uv_run+0x114)[0x7fae10947854]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(+0x247da)[0x7fae10dfe7da]
/usr/lib/x86_64-linux-gnu/libisc-9.17.20-2-Debian.so(isc__trampoline_run+0x16)[0x7fae10e36bd6]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8eae)[0x7fae10b36eae]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7fae10a66a5f]
zsh: IOT instruction (core dumped) host www.unesp.br 200.145.86.1
```
I hope that some of these files are helpful :-)
[core dump](/uploads/325a587af3cbf8c8862b554c57597f93/core-isc-net-0000.55659.neon.1637667477)
[gdb's "thread apply all bt full"](/uploads/56e9ac73d79041b0ed8606e102813b88/gdb.txt)
[tcpdump output](/uploads/60932dfe55240b848a0ef2902bae3289/tcpdump.txt)
This is also https://bugs.debian.org/1000447
If you need anything else, just let me know, please.
Thank you!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/2826CLI tools usage in documentation is out of sync2022-04-04T13:45:17ZPetr Špačekpspacek@isc.orgCLI tools usage in documentation is out of sync### Summary
CLI tools usage in documentation is out of sync. See examples below.
### BIND version used
current main, commit 9a7d2000e6075e0a84d2e9f4a85f7d273e949de0
### Steps to reproduce
Compare named-compilezone with content of bi...### Summary
CLI tools usage in documentation is out of sync. See examples below.
### BIND version used
current main, commit 9a7d2000e6075e0a84d2e9f4a85f7d273e949de0
### Steps to reproduce
Compare named-compilezone with content of bin/check/named-checkzone.rst.
### What is the current *bug* behavior?
1. named-compilezone
Tool prints:
```
named-compilezone [-djqvD] [-c class] [-f inputformat] [-F outputformat] [-J filename] [-s (full|relative)] [-t directory] [-w directory] [-k (ignore|warn|fail)] [-m (ignore|warn|fail)] [-n (ignore|warn|fail)] [-r (ignore|warn|fail)] [-i (full|full-sibling|local|local-sibling|none)] [-M (ignore|warn|fail)] [-S (ignore|warn|fail)] [-W (ignore|warn)] -o filename zonename [ (filename|-) ]
```
Man page says:
```
named-compilezone [-d] [-j] [-q] [-v] [-c class] [-C mode] [-f format] [-F format] [-J filename] [-i mode] [-k mode] [-m mode] [-n mode] [-l ttl] [-L serial] [-r mode] [-s style] [-t directory] [-T mode] [-w directory] [-D] [-W mode] {-o filename} {zonename} {filename}
```
E.g. `-C` is not printed by the tool, and it errors out when specified:
```
named-compilezone: invalid argument -C
```
2. Another example is `tsig-keygen`:
Tool prints:
```
tsig-keygen [-a alg] [keyname]
```
Man page says:
```
tsig-keygen [-a algorithm] [-h] [-r randomfile] [name]
```
### What is the expected *correct* behavior?
Well, manpages should be correct :troll:
### Possible fixes
I think we could have mechanism to automatically check if usage in man page and in *.rst matches. I imagine it would run all tools in mode which prints usage, grep usage line, and compare it with (somehow tagged) usage line in *.rst
Obvious problems:
- Tools would have to have common way to print usage with options.
- Normalizing formatting from RST to plain text.April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)Petr Špačekpspacek@isc.orgPetr Špačekpspacek@isc.org