BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2022-02-10T15:06:08Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3135dnstap-read: add sorting option2022-02-10T15:06:08Zmartinvonwittichdnstap-read: add sorting option### Description
`dnstap-read` currently prints the DNS packets in the order in which they were stored in the file.
Unfortunately, the packets aren't necessarily stored in chronological order (probably due to the fact that dnstap loggin...### Description
`dnstap-read` currently prints the DNS packets in the order in which they were stored in the file.
Unfortunately, the packets aren't necessarily stored in chronological order (probably due to the fact that dnstap logging is understandably a low-priority task for BIND).
For example:
```
09-Feb-2022 02:33:36.294 CQ 127.0.0.1:41718 -> 127.0.0.1:0 UDP 33b example.com/IN/MX
09-Feb-2022 02:33:36.334 RR 192.168.1.2:55163 <- 192.168.1.1:53 UDP 71b example.com/IN/MX
09-Feb-2022 02:33:36.294 RQ 192.168.1.2:55163 -> 192.168.1.1:53 UDP 33b example.com/IN/MX
09-Feb-2022 02:33:36.334 CR 127.0.0.1:41718 <- 127.0.0.1:0 UDP 102b example.com/IN/MX
09-Feb-2022 02:33:38.453 CQ 127.0.0.1:57293 -> 127.0.0.1:0 UDP 33b example.com/IN/MX
09-Feb-2022 02:33:38.453 CR 127.0.0.1:57293 <- 127.0.0.1:0 UDP 102b example.com/IN/MX
```
Obviously the resolver query (RQ) comes before the resolver response (RR), and while the timestamps reflect this, the ordering does not. This can make reading the logs rather confusing, especially when piping `dnstap-read -p` or `dnstap-read -y` through a pager - when I'm looking at the RQ, then I expect to be able to search for the RR e.g. with `/55163`, but as `/` searches forward, I won't find it.
### Request
Add the ability to sort the packets chronologically, with a switch.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3133Some TCP error conditions are handled incorrectly2022-02-25T14:29:32ZMichał KępieńSome TCP error conditions are handled incorrectlyIn `lib/dns/dispatch.c:tcp_recv()`, the `default` case in the second
`switch` statement is overly broad and causes some result codes provided
by netmgr to be incorrectly overridden with `ISC_R_SHUTTINGDOWN`. This
enables e.g. `shutting ...In `lib/dns/dispatch.c:tcp_recv()`, the `default` case in the second
`switch` statement is overly broad and causes some result codes provided
by netmgr to be incorrectly overridden with `ISC_R_SHUTTINGDOWN`. This
enables e.g. `shutting down resolving ...` messages to be logged in the
middle of normal resolver operation (which is confusing as such messages
are only supposed to be logged when the netmgr is being shut down
entirely) and causes some error conditions to be mishandled by resolver
code (`resquery_response()`).
As an example, consider what happens if `tcp_recv()` gets invoked with
the `ISC_R_EOF` result code:
1. The first `switch` statement calls `tcp_recv_shutdown()` to prepare
the dispatch for cleanup.
2. The `result` variable remains untouched.
3. The second `switch` statement matches `ISC_R_EOF` to the `default`
case.
4. `tcp_recv_cancelall()` gets called, which causes the higher-level
dispatch callback (`resquery_response()`) to be invoked with the
`ISC_R_SHUTTINGDOWN` result code.
5. Instead of returning early (which should happen for `ISC_R_EOF`),
`resquery_response()` continues to process the `ISC_R_SHUTTINGDOWN`
result code, eventually reaching `rctx_dispfail()` and marking the
server as bad.
At least two other error conditions (`ISC_R_CANCELED` and
`ISC_R_CONNECTIONRESET`) can be similarly overridden with
`ISC_R_SHUTTINGDOWN`.
AIUI, the original netmgr error code should be propagated to the
resolver code so that it can be handled accordingly. Perhaps something
like this could work?
```diff
diff --git a/lib/dns/dispatch.c b/lib/dns/dispatch.c
index c13d91d0642..81e2f0658d7 100644
--- a/lib/dns/dispatch.c
+++ b/lib/dns/dispatch.c
@@ -713,13 +713,14 @@ tcp_recv_done(dns_dispentry_t *resp, isc_result_t eresult,
}
static void
-tcp_recv_cancelall(dns_displist_t *resps, isc_region_t *region) {
+tcp_recv_cancelall(dns_displist_t *resps, isc_region_t *region,
+ isc_result_t result) {
dns_dispentry_t *resp = NULL, *next = NULL;
for (resp = ISC_LIST_HEAD(*resps); resp != NULL; resp = next) {
next = ISC_LIST_NEXT(resp, rlink);
ISC_LIST_UNLINK(*resps, resp, rlink);
- resp->response(ISC_R_SHUTTINGDOWN, region, resp->arg);
+ resp->response(result, region, resp->arg);
dispentry_detach(&resp);
}
}
@@ -831,7 +832,7 @@ tcp_recv(isc_nmhandle_t *handle, isc_result_t result, isc_region_t *region,
break;
default:
/* We're being shut down; cancel all outstanding resps. */
- tcp_recv_cancelall(&resps, region);
+ tcp_recv_cancelall(&resps, region, result);
}
dns_dispatch_detach(&disp);
```March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3132netmgr is missing TCP send timeout2022-02-25T14:17:13ZOndřej Surýnetmgr is missing TCP send timeoutWhen the `uv_write()` fills up the TCP send buffers (around 208k) on Linux because the other side is not reading, the TCP connection will be kept open indefinitely.
We need to add a "idle" timer around the `uv_write()`, so we can bail o...When the `uv_write()` fills up the TCP send buffers (around 208k) on Linux because the other side is not reading, the TCP connection will be kept open indefinitely.
We need to add a "idle" timer around the `uv_write()`, so we can bail out early.
This also affects #1897 - the XFR timeout works fine, but the connection gets stuck as we have no way of terminating the pending `uv_write()`s on the stuck transfer.
FTR This is not CVE/ASN worthy because there's even a simpler way to keep the TCP connection open indefinitely - just keep sending and reading the DNS queries/responses, but keeping this confidential for the time being.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3131test case timeout when the number of CPUs is 1282022-02-21T11:59:29Zjin ggtest case timeout when the number of CPUs is 128test case timeout when the number of CPUs is 128 :
![image](/uploads/c53b15deba7467dd5e2d82cf56c92288/image.png)
I see some test cases will create manager wokers with the same number of CPUs on machine. This is the root cause of the tes...test case timeout when the number of CPUs is 128 :
![image](/uploads/c53b15deba7467dd5e2d82cf56c92288/image.png)
I see some test cases will create manager wokers with the same number of CPUs on machine. This is the root cause of the test case timeout. The more workers threads, the worse the performance seems.
![image](/uploads/00c9a46063873de9cfd1f78d3ca782a3/image.png)
At the same time, I see that named's main program also uses the number of CPUs on the macine to create manager worker threads, So I wonder if this affects named's performance when the number of CPUs is high?
![image](/uploads/1d7157ba9cafb358f80ea2fd3005fa25/image.png)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3130build for Android failed2022-02-25T13:53:20Zfpliubuild for Android failed![30](/uploads/f938bff0f327cf2f669a192af25fb740/30.PNG)
https://downloads.isc.org/isc/bind9/9.18.0/bind-9.18.0.tar.xz
relevant code at [lib/isc/thread.c#L100-102](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/lib/isc/thread.c#L...![30](/uploads/f938bff0f327cf2f669a192af25fb740/30.PNG)
https://downloads.isc.org/isc/bind9/9.18.0/bind-9.18.0.tar.xz
relevant code at [lib/isc/thread.c#L100-102](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/lib/isc/thread.c#L100-102) should look like:
```c
#if (defined(__NetBSD__) || defined(__ANDROID__))
```March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/3129[CVE-2022-0667] assertion failure on delayed DS lookup2022-11-10T14:07:26ZPetr Špačekpspacek@isc.org[CVE-2022-0667] assertion failure on delayed DS lookup<!--
THIS ISSUE TEMPLATE IS INTENDED ONLY FOR INTERNAL USE.
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 - the...<!--
THIS ISSUE TEMPLATE IS INTENDED ONLY FOR INTERNAL USE.
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).
-->
### CVE-specific actions
- [x] Assign a CVE identifier
- [x] Determine CVSS score 7.0
- AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:F/RL:O/RC:C
- [x] Determine the range of BIND versions affected (including the Subscription Edition)
- 9.18.0
- [x] Determine whether workarounds for the problem exists
- No workaround exits
- [x] Create a draft of the security advisory and put the information above in there
- https://portal.document360.io/956e37e2-5ec0-4942-8b27-35533899f099/document/v1/view/153f2922-2ac3-47ac-b8f4-a5f44be40e79
- [x] Prepare a detailed description of the problem which should include the following by default:
- instructions for reproducing the problem (a system test is good enough)
- explanation of code flow which triggers the problem (a system test is *not* good enough)
- [x] Prepare a private merge request containing the following items in separate commits:
- a test for the issue (may be moved to a separate merge request for deferred merging)
- a fix for the issue
- documentation updates (`CHANGES`, release notes, anything else applicable)
- [x] Ensure the merge request from the previous step is reviewed by SWENG staff and has no outstanding discussions
- [x] Ensure the documentation changes introduced by the merge request addressing the problem are reviewed by Support and Marketing staff
- [x] Prepare backports of the merge request addressing the problem for all affected (and still maintained) BIND branches (backporting might affect the issue's scope and/or description)
- [x] Prepare a standalone patch for the last stable release of each affected (and still maintained) BIND branch
### Release-specific actions
- [x] [Create/update the private issue containing links to fixes & reproducers for all CVEs fixed in a given release cycle](isc-private/bind9#49)
- [x] [Reserve a block of `CHANGES` placeholders once the complete set of vulnerabilities fixed in a given release cycle is determined](!5925)
- [x] Ensure the merge requests containing CVE fixes are merged into `security-*` branches in CVE identifier order
### Post-disclosure actions
- [x] Merge a regression test reproducing the bug into all affected (and still maintained) BIND branches
### Summary
BIND crashes when under heavy cache-miss load, while configured to forward queries to some other recursor.
### BIND version used
~"Affects v9.18" : v9.18.0
Other versions are under investigation.
### Steps to reproduce
Well, that's a problem. It happens only under load, when forwarding, and only when _some_ timeouts happen.
### What is the current *bug* behavior?
Crash on assert:
```
assertion_failed (file=0x7fea3376b05b "resolver.c", line=7117, type=isc_assertiontype_insist, cond=0x7fea3376b3a6 "__v > 0")
```
<details>
GDB
```
(gdb) bt
#0 0x00007fea3288ad22 in raise () from /usr/lib/libc.so.6
#1 0x00007fea32874862 in abort () from /usr/lib/libc.so.6
#2 0x000055fad8cb1821 in assertion_failed (file=0x7fea3376b05b "resolver.c", line=7117, type=isc_assertiontype_insist, cond=0x7fea3376b3a6 "__v > 0") at main.c:238
#3 0x00007fea337f88da in isc_assertion_failed (file=0x7fea3376b05b "resolver.c", line=7117, type=isc_assertiontype_insist, cond=0x7fea3376b3a6 "__v > 0") at assertions.c:49
#4 0x00007fea3368552f in fctx__detach (fctxp=0x7fea2c8f4a38, file=0x7fea3376b05b "resolver.c", line=7275, func=0x7fea3376f3f0 <__func__.5> "resume_dslookup") at resolver.c:7117
#5 0x00007fea33685c78 in resume_dslookup (task=0x7fea285a85c0, event=0x0) at resolver.c:7275
#6 0x00007fea33826e35 in task_run (task=0x7fea285a85c0) at task.c:820
#7 0x00007fea3382705d in isc_task_run (task=0x7fea285a85c0) at task.c:900
#8 0x00007fea337d7b30 in isc__nm_async_task (worker=0x7fea302a9770, ev0=0x7fea28055200) at netmgr/netmgr.c:837
#9 0x00007fea337d7dc4 in process_netievent (worker=0x7fea302a9770, ievent=0x7fea28055200) at netmgr/netmgr.c:916
#10 0x00007fea337d88f9 in process_queue (worker=0x7fea302a9770, type=NETIEVENT_TASK) at netmgr/netmgr.c:1010
#11 0x00007fea337d797c in process_all_queues (worker=0x7fea302a9770) at netmgr/netmgr.c:756
#12 0x00007fea337d7a00 in async_cb (handle=0x7fea302a9ad0) at netmgr/netmgr.c:785
#13 0x00007fea32c2f92d in ?? () from /usr/lib/libuv.so.1
#14 0x00007fea32c4bd0e in ?? () from /usr/lib/libuv.so.1
#15 0x00007fea32c35438 in uv_run () from /usr/lib/libuv.so.1
#16 0x00007fea337d75ab in nm_thread (worker0=0x7fea302a9770) at netmgr/netmgr.c:691
#17 0x00007fea33830a60 in isc__trampoline_run (arg=0x7fea30277ca0) at trampoline.c:187
#18 0x00007fea32a23259 in start_thread () from /usr/lib/libpthread.so.0
#19 0x00007fea3294c5e3 in clone () from /usr/lib/libc.so.6
```
```
(gdb) frame
#4 0x00007fea3368552f in fctx__detach (fctxp=0x7fea2c8f4a38, file=0x7fea3376b05b "resolver.c", line=7275, func=0x7fea3376f3f0 <__func__.5> "resume_dslookup") at resolver.c:7117
(gdb) p /x fctx->references
$2 = 0xffffffffffffffff
```
</details>
### What is the expected *correct* behavior?
Well, no crash :trollface:
### Relevant configuration files
* [named.conf](/uploads/d62d91f99f983549d27a198272642033/named.conf)
* 127.0.0.112 does recursion
I have a suspicion that all tracebacks had function `resume_dslookup` in them. Is this function special in some way?
### Relevant logs and/or screenshots
Original logs were lost, sorry. Generally the log had lots and lots of timeouts and also some "shut down hung fetch" messages.
Here is content of `fctx`:
<details>
```
(gdb) p *fctx
$5 = {magic = 1176576289, res = 0x0, fname = {name = {magic = 1145983854,
ndata = 0x7fea21692120 "\001\061\001\060\001\060\001\060\001\061\001\060\001\071\001\061\001\060\001\060\001\066\001\062\003ip6\004arpa", length = 34, labels = 15, attributes = 1, offsets = 0x7fea21692060 "",
buffer = 0x7fea216920e0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, list = {head = 0x0,
tail = 0x0}},
offsets = "\000\002\004\006\b\n\f\016\020\022\024\026\030\034!", '\000' <repeats 112 times>, buffer = {
magic = 1114990113, base = 0x7fea21692120, length = 255, used = 34, current = 0, active = 0, link = {
prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, mctx = 0x0, autore = false},
data = "\001\061\001\060\001\060\001\060\001\061\001\060\001\071\001\061\001\060\001\060\001\066\001\062\003ip6\004arpa", '\000' <repeats 221 times>}, name = 0x7fea21692010, type = 43, options = 0, bucketnum = 133,
dbucketnum = 4294967295, info = 0x0, mctx = 0x0, now = 1644339489, task = 0x7fea285a85c0,
references = 18446744073709551615, state = fetchstate_done, want_shutdown = true, cloned = false,
spilled = false, control_event = {ev_size = 104, ev_attributes = 0, ev_tag = 0x0, ev_type = 262144,
ev_action = 0x7fea3367d90f <fctx_doshutdown>, ev_arg = 0x7fea21692000, ev_sender = 0x0, ev_destroy = 0x0,
ev_destroy_arg = 0x0, ev_link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, ev_ratelink = {
prev = 0xffffffffffffffff, next = 0xffffffffffffffff}}, link = {prev = 0xffffffffffffffff,
next = 0xffffffffffffffff}, events = {head = 0x0, tail = 0x0}, dfname = {name = {magic = 1145983854,
ndata = 0x7fea21692400 "", length = 1, labels = 1, attributes = 1, offsets = 0x7fea21692340 "",
buffer = 0x7fea216923c0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, list = {head = 0x0,
tail = 0x0}}, offsets = '\000' <repeats 127 times>, buffer = {magic = 1114990113, base = 0x7fea21692400,
length = 255, used = 1, current = 0, active = 0, link = {prev = 0xffffffffffffffff,
next = 0xffffffffffffffff}, mctx = 0x0, autore = false}, data = '\000' <repeats 254 times>},
domain = 0x7fea216922f0, nameservers = {magic = 1145983826, methods = 0x0, link = {prev = 0xffffffffffffffff,
next = 0xffffffffffffffff}, rdclass = 0, type = 0, ttl = 0, trust = 0, covers = 0, attributes = 0,
count = 4294967295, resign = 0, private1 = 0x0, private2 = 0x0, private3 = 0x0, privateuint4 = 0,
private5 = 0x0, private6 = 0x0, private7 = 0x0}, attributes = 392, timer = 0x0, expires = {
seconds = 1644339499, nanoseconds = 261051224}, expires_try_stale = {seconds = 0, nanoseconds = 0},
next_timeout = {seconds = 1644339496, nanoseconds = 897675111}, final = {seconds = 1644339501,
nanoseconds = 261051224}, interval = {seconds = 1, nanoseconds = 200000000}, qmessage = 0x0, queries = {
head = 0x0, tail = 0x0}, finds = {head = 0x0, tail = 0x0}, find = 0x0, altfinds = {head = 0x0, tail = 0x0},
altfind = 0x0, forwaddrs = {head = 0x0, tail = 0x0}, altaddrs = {head = 0x0, tail = 0x0}, forwarders = {
head = 0x0, tail = 0x0}, fwdpolicy = dns_fwdpolicy_only, bad = {head = 0x0, tail = 0x0}, edns = {head = 0x0,
tail = 0x0}, bad_edns = {head = 0x0, tail = 0x0}, validator = 0x0, validators = {head = 0x0, tail = 0x0},
cache = 0x0, adb = 0x0, ns_ttl_ok = false, ns_ttl = 0, qc = 0x0, minimized = false, qmin_labels = 1,
qmin_warning = ISC_R_SUCCESS, ip6arpaskip = false, forwarding = true, qminfname = {name = {magic = 1145983854,
ndata = 0x7fea216927b8 "\001\061\001\060\001\060\001\060\001\061\001\060\001\071\001\061\001\060\001\060\001\066\001\062\003ip6\004arpa", length = 34, labels = 15, attributes = 1, offsets = 0x7fea216926f8 "",
buffer = 0x7fea21692778, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, list = {head = 0x0,
tail = 0x0}},
offsets = "\000\002\004\006\b\n\f\016\020\022\024\026\030\034!", '\000' <repeats 112 times>, buffer = {
magic = 1114990113, base = 0x7fea216927b8, length = 255, used = 34, current = 0, active = 0, link = {
prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, mctx = 0x0, autore = false},
data = "\001\061\001\060\001\060\001\060\001\061\001\060\001\071\001\061\001\060\001\060\001\066\001\062\003ip6\004arpa", '\000' <repeats 221 times>}, qminname = 0x7fea216926a8, qmintype = 43, qminfetch = 0x0, qminrrset = {
magic = 1145983826, methods = 0x0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff},
rdclass = 0, type = 0, ttl = 0, trust = 0, covers = 0, attributes = 0, count = 4294967295, resign = 0,
private1 = 0x0, private2 = 0x0, private3 = 0x0, privateuint4 = 0, private5 = 0x0, private6 = 0x0,
private7 = 0x0}, qmindcfname = {name = {magic = 1145983854, ndata = 0x7fea21692a50 "", length = 1,
labels = 1, attributes = 1, offsets = 0x7fea21692990 "", buffer = 0x7fea21692a10, link = {
prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, list = {head = 0x0, tail = 0x0}},
offsets = '\000' <repeats 127 times>, buffer = {magic = 1114990113, base = 0x7fea21692a50, length = 255,
used = 1, current = 0, active = 0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff},
mctx = 0x0, autore = false}, data = '\000' <repeats 254 times>}, qmindcname = 0x7fea21692940, pending = 0,
restarts = 1, timeouts = 0, nsfname = {name = {magic = 1145983854,
ndata = 0x7fea21692122 "\001\060\001\060\001\060\001\061\001\060\001\071\001\061\001\060\001\060\001\066\001\062\003ip6\004arpa", length = 32, labels = 14, attributes = 1, offsets = 0x7fea21692bb8 "",
buffer = 0x7fea21692c38, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, list = {head = 0x0,
tail = 0x0}}, offsets = "\000\002\004\006\b\n\f\016\020\022\024\026\032\037", '\000' <repeats 113 times>,
buffer = {magic = 1114990113, base = 0x7fea21692c78, length = 255, used = 0, current = 0, active = 0, link = {
prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, mctx = 0x0, autore = false},
data = '\000' <repeats 254 times>}, nsname = 0x7fea21692b68, nsfetch = 0x0, nsrrset = {magic = 1145983826,
methods = 0x0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, rdclass = 0, type = 0, ttl = 0,
trust = 0, covers = 0, attributes = 0, count = 4294967295, resign = 0, private1 = 0x0, private2 = 0x0,
private3 = 0x0, privateuint4 = 0, private5 = 0x0, private6 = 0x0, private7 = 0x0}, nqueries = 0,
rand_buf = 0, rand_bits = 0, result = ISC_R_CANCELED, vresult = ISC_R_SUCCESS, exitline = 7176, start = {
seconds = 1644339489, nanoseconds = 261051224}, duration = 12003253, logged = false, querysent = 5,
referrals = 0, lamecount = 0, quotacount = 0, neterr = 1, badresp = 1, adberr = 0, findfail = 0, valfail = 0,
timeout = false, addrinfo = 0x7fea02c8ba20, depth = 0, clientstr = "<unknown>", '\000' <repeats 53 times>}
```
</details>
And here are logs from other runs which crashed on the same line:
- [bind-run3.json.log](/uploads/5338f3dd528889677bc2201432c5799c/bind-run3.json.log)
- [bind-run5.json.log](/uploads/7aaa687521f4da04322c93cf7f248e73/bind-run5.json.log)March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Arаm SаrgsyаnArаm Sаrgsyаnhttps://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/3127No unique exit code for NXDOMAIN, "No answer" by ISC DNS CLI tools2022-02-07T09:12:23ZEgbertNo unique exit code for NXDOMAIN, "No answer" by ISC DNS CLI toolsWas kinda surprised that the following tools:
* nslookup
* dig
* delv
has no unique exit code for:
* NXDOMAIN,
* "No answer",
* signature failed, and
* DNSSEC failed.
Is this a deliberate design to not assist SHELL programming?Was kinda surprised that the following tools:
* nslookup
* dig
* delv
has no unique exit code for:
* NXDOMAIN,
* "No answer",
* signature failed, and
* DNSSEC failed.
Is this a deliberate design to not assist SHELL programming?https://gitlab.isc.org/isc-projects/bind9/-/issues/3126"resolver" test fails on openSUSE Tumbleweed2022-04-01T13:07:45ZJosef Möllers"resolver" test fails on openSUSE Tumbleweed<!--
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
When running "make test", the "resolver" test fails.
All other tests pass.
### BIND version used
```
BIND 9.18.0 (Stable Release) <id:8db45af>
running on Linux x86_64 5.16.2-1-default #1 SMP PREEMPT Mon Jan 24 18:27:48 UTC 2022 (0d710a8)
built by make with default
compiled by GCC 11.2.1 20220103 [revision d4a1d3c4b377f1d4acb34fe1b55b5088a3f293f6]
compiled with OpenSSL version: OpenSSL 1.1.1m 14 Dec 2021
linked to OpenSSL version: OpenSSL 1.1.1m 14 Dec 2021
compiled with libuv version: 1.42.0
linked to libuv version: 1.42.0
compiled with libnghttp2 version: 1.46.0
linked to libnghttp2 version: 1.46.0
compiled with libxml2 version: 2.9.12
linked to libxml2 version: 20912
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.6.0
threads support is enabled
default paths:
named configuration: /usr/local/etc/named.conf
rndc configuration: /usr/local/etc/rndc.conf
DNSSEC root key: /usr/local/etc/bind.keys
nsupdate session key: /usr/local/var/run/named/session.key
named PID file: /usr/local/var/run/named/named.pid
named lock file: /usr/local/var/run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
This was found in the context of testing the new bind release prior to releasing it as an openSUSE package.
On an openSUSE Tumbleweed installation:
As "root":
D=/usr/src/packages/BUILD; rm -rf $D/bind-9.18.0; chgrp users $D; chmod 775 $D
D=/usr/src/packages/BUILDROOT; rm -rf $D/bind-9.18.0[resolver.log](/uploads/b3042f0d71258410d0b64c613b1f6251/resolver.log)[resolver.log](/uploads/6756d586c879e135ecddb246e41cf190/resolver.log); chgrp users $D; chmod 775 $D
As an unprivileged user:
ln -s /usr/src/packages ~/rpmbuild
Then, as the unprivileged user:
cd /usr/src/packages/BUILD; rm -rf bind-9.18.0
tar xvJf /usr/src/packages/SOURCES/bind-9.18.0.tar.xz
cd bind-9.18.0/
./configure
make -j
make test
### What is the current *bug* behavior?
FAIL: resolver
### What is the expected *correct* behavior?
PASS: resolver
### Relevant configuration files
This is the unmodified source code.
### Relevant logs and/or screenshots
```
Configuration summary:
-------------------------------------------------------------------------------
Optional features enabled:
Memory allocator: jemalloc
GeoIP2 access control (--enable-geoip)
GSS-API (--with-gssapi)
DNSSEC validation active by default (--enable-auto-validation)
-------------------------------------------------------------------------------
Features disabled or unavailable on this platform:
Small-system tuning (--with-tuning)
Allow 'dnstap' packet logging (--enable-dnstap)
DNS Response Policy Service interface (--enable-dnsrps)
Allow 'fixed' rrset-order (--enable-fixed-rrset)
Very verbose query trace logging (--enable-querytrace)
Single-query trace logging (--enable-singletrace)
LMDB database to store configuration for 'addzone' zones (--with-lmdb)
IDN support (--with-libidn2)
-------------------------------------------------------------------------------
Configured paths:
prefix: /usr/local
sysconfdir: ${prefix}/etc
localstatedir: ${prefix}/var
-------------------------------------------------------------------------------
Compiler: gcc
gcc (SUSE Linux) 11.2.1 20220103 [revision d4a1d3c4b377f1d4acb34fe1b55b5088a3f293f6]
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
CFLAGS: -Wall -Wextra -Wwrite-strings -Wpointer-arith -Wno-missing-field-initializers -Wformat -Wshadow -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=format-security -Werror=parentheses -Werror=implicit -Werror=strict-prototypes -fno-strict-aliasing -fno-delete-null-pointer-checks -fdiagnostics-show-option -g -O2 -pthread
CPPFLAGS: -D_FORTIFY_SOURCE=2
LDFLAGS:
```
### Possible fixes
I thought this might be similar to issue #3069 so I tried
* adding "--enable-querytrace" to the configure flags
which hung the "resolver" test completely
* extending the timeout value from 15 to 30 (this is a single-core VM with only 1GB of main memory)
But nothing helped.https://gitlab.isc.org/isc-projects/bind9/-/issues/3125When accepting connection the hard quota is never logged2022-02-25T13:38:00ZOndřej SurýWhen accepting connection the hard quota is never loggedWhen the hard quota is reached (`ISC_R_QUOTA`) the condition is never logged, but the connection is silently not accepted.When the hard quota is reached (`ISC_R_QUOTA`) the condition is never logged, but the connection is silently not accepted.February 2022 (9.16.26, 9.16.26-S1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3124[question] named -f -g -d9 -c named.conf -u bind2022-11-25T17:10:08ZAllayna Wilson[question] named -f -g -d9 -c named.conf -u bindshould be doing something isn't doing anything
```
openat(AT_FDCWD, "/dev/null", O_RDWR) = 3
openat(AT_FDCWD, "/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC) = 4
read(4, "0-7\n", 8192) = 4
close(4) ...should be doing something isn't doing anything
```
openat(AT_FDCWD, "/dev/null", O_RDWR) = 3
openat(AT_FDCWD, "/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC) = 4
read(4, "0-7\n", 8192) = 4
close(4) = 0
prctl(PR_SET_KEEPCAPS, 1) = 0
getuid() = 0
capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, NULL) = 0
capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, NULL) = 0
capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=1<<CAP_SETGID|1<<CAP_SETUID|1<<CAP_NET_BIND_SERVICE|1<<CAP_SYS_CHROOT|1<<CAP_SYS_RESOURCE, permitted=1<<CAP_SETGID|1<<CAP_SETUID|1<<CAP_NET_BIND_SERVICE|1<<CAP_SYS_CHROOT|1<<CAP_SYS_RESOURCE, inheritable=0}) = 0
getuid() = 0
capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=1<<CAP_NET_BIND_SERVICE|1<<CAP_SYS_RESOURCE, permitted=1<<CAP_NET_BIND_SERVICE|1<<CAP_SYS_RESOURCE, inheritable=0}) = 0
brk(0x562a0d58e000) = 0x562a0d58e000
mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb356e9e000
pipe([4, 5]) = 0
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fb356edfb50) = 8503
close(5) = 0
read(4, "", 1) = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8503, si_uid=0, si_status=1, si_utime=1, si_stime=0} ---
exit_group(1) = ?
+++ exited with 1 +++
root@ovj:/etc/bind# named --version
```
nicehttps://gitlab.isc.org/isc-projects/bind9/-/issues/3123v9.16 test failure in Perflab: uv_udp_init_ex() errors out2022-02-02T08:12:15ZPetr Špačekpspacek@isc.orgv9.16 test failure in Perflab: uv_udp_init_ex() errors outVersion
=======
~"Affects v9.16" : Since isc-projects/bind9!5717 was merged.
Symptom
=======
Perflab test config LTT/v9_16/recursive/NXD-medium/dnsgen started failing.
`named` errors out before the test even starts with message:
```
ud...Version
=======
~"Affects v9.16" : Since isc-projects/bind9!5717 was merged.
Symptom
=======
Perflab test config LTT/v9_16/recursive/NXD-medium/dnsgen started failing.
`named` errors out before the test even starts with message:
```
udp.c:226: fatal error: RUNTIME_CHECK(r == 0) failed
```
Example of an affected run:
https://perflab.isc.org/#/run/test/61f911b58d88f33170df08b6/
Additional info
===============
Surprisingly, other test configurations do not seem to be affected, not even on v9_16 branch.
In any case, this is very suspicious and needs investigation ASAP before we tag %"February 2022 (9.16.26, 9.16.26-S1)". It stopped working during this monthly cycle so if it is a bug then it is a regression.February 2022 (9.16.26, 9.16.26-S1)https://gitlab.isc.org/isc-projects/bind9/-/issues/3122DoT stops working after "rndc reconfigure" when running named as non-root2024-01-11T14:13:01ZsthaugDoT stops working after "rndc reconfigure" when running named as non-root<!--
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
DoT stops working after "rndc reconfigure" when running named as non-root
### BIND version used
```
BIND 9.18.0 (Stable Release) <id:8db45af>
running on FreeBSD amd64 12.3-STABLE FreeBSD 12.3-STABLE r371270 DNS_VIMAGE
built by make with '--disable-linux-caps' '--localstatedir=/var' '--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--with-libxml2' '--with-openssl=/usr' '--enable-dnsrps' '--with-readline=libedit' '--enable-dnstap' '--disable-fixed-rrset' '--disable-geoip' '--without-maxminddb' '--without-gssapi' '--with-libidn2=/usr/local' '--with-json-c' '--disable-largefile' '--with-lmdb=/usr/local' '--disable-querytrace' '--enable-tcp-fastopen' '--prefix=/usr/local' '--mandir=/usr/local/man' '--disable-silent-rules' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd12.2' 'build_alias=amd64-portbld-freebsd12.2' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -L/usr/local/lib -ljson-c -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf' 'READLINE_CFLAGS=-L/usr/local/lib'
compiled by CLANG FreeBSD Clang 10.0.1 (git@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2)
compiled with OpenSSL version: OpenSSL 1.1.1m-freebsd 14 Dec 2021
linked to OpenSSL version: OpenSSL 1.1.1m-freebsd 14 Dec 2021
compiled with libuv version: 1.41.0
linked to libuv version: 1.41.0
compiled with libnghttp2 version: 1.44.0
linked to libnghttp2 version: 1.44.0
compiled with libxml2 version: 2.9.12
linked to libxml2 version: 20912
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
compiled with protobuf-c version: 1.4.0
linked to protobuf-c version: 1.4.0
threads support is enabled
default paths:
named configuration: /usr/local/etc/namedb/named.conf
rndc configuration: /usr/local/etc/namedb/rndc.conf
DNSSEC root key: /usr/local/etc/namedb/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
```
Also tried 9.17.18 (Installed from FreeBSD package) and 9.17.22 (compiled from source).
### Steps to reproduce
Start named with the following command line:
/usr/local/sbin/named -t /var/named -u bind -c /usr/local/etc/namedb/named.conf
and with the following named.conf file:
```
options {
directory "/usr/local/etc/namedb/working";
pid-file "/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
listen-on { 193.75.110.2; 127.0.0.1; };
listen-on port 853 tls dotas2116 { 193.75.110.2; 127.0.0.1; };
interface-interval 0;
recursion yes;
max-cache-size 1500M;
minimal-any yes;
minimal-responses yes;
querylog yes;
allow-query { 194.19.2.0/24; 193.75.110.0/24; 127.0.0.1; };
};
tls dotas2116 {
cert-file "/usr/local/etc/namedb/fullchain.pem";
key-file "/usr/local/etc/namedb/privkey.pem";
protocols { TLSv1.2; TLSv1.3; };
};
```
### What is the current *bug* behavior?
After doing "rndc reconfigure" named no longer listens to TCP port 853. This is visible in the log:
```
Jan 31 16:29:08 nslum named[42849]: no longer listening on 127.0.0.1#853
Jan 31 16:29:08 nslum named[42849]: listening on IPv4 interface lo0, 127.0.0.1#853
Jan 31 16:29:08 nslum named[42849]: creating TLS socket: permission denied
Jan 31 16:29:08 nslum named[42849]: creating IPv4 interface lo0 failed; interface ignored
Jan 31 16:29:08 nslum named[42849]: no longer listening on 193.75.110.2#853
Jan 31 16:29:08 nslum named[42849]: listening on IPv4 interface ixl1.15, 193.75.110.2#853
Jan 31 16:29:08 nslum named[42849]: creating TLS socket: permission denied
Jan 31 16:29:08 nslum named[42849]: creating IPv4 interface ixl1.15 failed; interface ignored
```
Using "dig +tls" to test results in:
;; Connection to 193.75.110.2#853(193.75.110.2) for vg.no failed: connection refused.
and using the FreeBSD "sockstat" command shows named is not listening to TCP port 853.
### What is the expected *correct* behavior?
The expected behavior is that "dig +tls" works, and resolves names normally. This works right after startup - and using the "sockstat command I can see that named is listening to TCP port 853:
```
Jan 31 16:27:10 nslum named[42849]: listening on IPv4 interface lo0, 127.0.0.1#853
Jan 31 16:27:10 nslum named[42849]: listening on IPv4 interface ixl1.15, 193.75.110.2#853
```
### Relevant configuration files
See named.conf above.
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3121rndc reload ignores changes to "querylog"2022-03-01T09:47:04ZPeter Daviesrndc reload ignores changes to "querylog"rndc reload ignores changes to "querylog":
The "querylog" statement in "options" appears not to get updated after BIND received an "rndc reload" command.
The "rndc querylog" does however change the logging of queries.
Configurat...rndc reload ignores changes to "querylog":
The "querylog" statement in "options" appears not to get updated after BIND received an "rndc reload" command.
The "rndc querylog" does however change the logging of queries.
Configurations that define the "queries" logging category have "query logging" enabled and are not affected
There may be cause to update the ARM to describe this behaviour.
1) Start BIND with no "querylog" statement in "options":
rndc status
query logging is OFF (queries are not logged)
2) Change "querylog yes;" in "options":
rndc reload
rndc status
query logging is OFF (queries are not logged) *
3) Start BIND with "querylog no;" in "options":
rndc reload
rndc status
query logging is OFF (queries are not logged)
4) Change "querylog yes;" defined in "options":
rndc reload
rndc status
query logging is NO (queries are not logged) *
5) Start BIND with "querylog yes;" defined in "options:"
rndc reload
rndc status
query logging is ON (queries are logged to syslog)
6) Change "querylog no;" in "options":
rndc reload
rndc status
query logging is ON (queries are logged to syslog) *
[RT #20067](https://support.isc.org/Ticket/Display.html?id=20067)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3120Recent editions (9.16.25, 9.17.22 onwards) of ARM have many empty grammar de...2022-02-25T13:37:09ZNiall O'ReillyRecent editions (9.16.25, 9.17.22 onwards) of ARM have many empty grammar descriptionsMany empty grammar description sections are present in the ARM. Editions since 9.17.22 appear to be affected. An example is at https://downloads.isc.org/isc/bind9/9.18.0/doc/arm/html/reference.html#acl-statement-grammar.
The most recen...Many empty grammar description sections are present in the ARM. Editions since 9.17.22 appear to be affected. An example is at https://downloads.isc.org/isc/bind9/9.18.0/doc/arm/html/reference.html#acl-statement-grammar.
The most recent edition which I have found where the corresponding section is not empty is at https://downloads.isc.org/isc/bind9/9.17.21/doc/arm/html/reference.html#acl-statement-grammar.
Some (apparently a minority) of the grammar description sections are present as expected, for example https://downloads.isc.org/isc/bind9/9.18.0/doc/arm/html/reference.html#view-statement-grammar.
Inspection of HTML source seems to confirm that the affected sections are indeed missing content, rather than that the content is hidden by some accident of styling.
It seems likely that there is a bug in the system used to generate the ARM.February 2022 (9.16.26, 9.16.26-S1)https://gitlab.isc.org/isc-projects/bind9/-/issues/3119Too much privilege required for a simple syntax checking via named-checkconf2022-01-31T14:41:08ZEgbertToo much privilege required for a simple syntax checking via named-checkconf### Summary
Was using the `named-checkconf` with '-p -x' options to do a simple syntax checking of the `named.conf` configuration file with the `-t <chroot_dir>` option ... as a non-root user.
All is well until a fix to actually use `c...### Summary
Was using the `named-checkconf` with '-p -x' options to do a simple syntax checking of the `named.conf` configuration file with the `-t <chroot_dir>` option ... as a non-root user.
All is well until a fix to actually use `chroot()` function call got introduced.
Now, all my unit tests broke because root UID 0 (and/or `CAP_SYS_CHROOT` capability) is required to properly execute `chroot()`. It's rather uncomfortable to do unit testing at elevated privilege.
How about when just the `-p` option is supplied, that we NOT call `chroot()` function?
### BIND version used
9.16.22-Debian
### Steps to reproduce
```
mkdir -p test/etc/bind
vim test/etc/bind/named.conf
```
Create an empty option clause in `test/etc/bind/named.conf` using `options {};`
Execute:
$ named-checkconf -p -x -t test /etc/bind/named.conf
isc_dir_chroot: permission denied
### What is the current *bug* behavior?
Function `chroot()` is being evoked during basic syntax checking.
### What is the expected *correct* behavior?
To perform syntax checking using a change relative directory. And not having to be requiring a `CAP_SYS_CHROOT` capabilitiy at user-level.
### Relevant configuration files
test/etc/bind/named.conf
```
options {};
```
### Relevant logs and/or screenshots
commit e502b133d630bda0ee64c1e2ce6729d96750d8ab
Author: Mark Andrews <marka@isc.org>
Date: Mon Feb 16 02:01:16 2009 +0000
### Possible fixes
In bin/check/named-checkconf.c
In the argument switch-case `t` option, relocate that body of code to just outside the while/switch-case, replace body of code a simple `chroot = 1;`
and
At the end of the arg parameter while/switch-case, relocate the following to something like:
```
if (chroot) {
if (print) {
/* insert CWD/change-PWD code snippet here */
} else {
result = isc_dir_chroot(isc_commandline_argument);
if (result != ISC_R_SUCCESS) {
fprintf(stderr, "isc_dir_chroot: %s\n",
isc_result_totext(result));
exit(1);
}
}
}
```https://gitlab.isc.org/isc-projects/bind9/-/issues/3118Bind 9.18 Error initializing TLS context: error:02001002:system library:fopen...2022-01-28T15:39:27ZPatrick DolinicBind 9.18 Error initializing TLS context: error:02001002:system library:fopen:No such file or directory<!--
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
I'm trying to get DoH working, works with Epheremal keys, but not with TLS Private/Public_Keys
### BIND version used
BIND 9.18.0-2-Debian (Stable Release) <id:>
### Steps to reproduce
Install Debian 11 SID, create a zone with a master, attempt to use the configuration from https://www.isc.org/blogs/bind-doh-update-2021/ on the "tls local-ts"-part
### What is the current *bug* behavior?
Jan 28 14:18:09 debian named[2920]: Error initializing TLS context: error:02001002:system library:fopen:No such file or directory
Jan 28 14:18:09 debian named[2920]: loading configuration: TLS error
Jan 28 14:18:09 debian named[2920]: exiting (due to fatal error)
systemctl restart named | but has the previous error-message
### What is the expected *correct* behavior?
systemctl restart named && systemctl status named | is green
### Relevant configuration files
I've recreated 3 different public and private keys and the problem persistshttps://gitlab.isc.org/isc-projects/bind9/-/issues/31179.18.0 nslookup debugging output2022-04-26T13:23:59ZJohn E. Krokes9.18.0 nslookup debugging output
### Summary
nslookup in interactive mode produces debugging output by default
### BIND version used
BIND 9.18.0 (Stable Release) <id:8db45af>
running on Linux x86_64 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18)
built by make ...
### Summary
nslookup in interactive mode produces debugging output by default
### BIND version used
BIND 9.18.0 (Stable Release) <id:8db45af>
running on Linux x86_64 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18)
built by make with '--sysconfdir=/etc' '--localstatedir=/var' '--disable-linux-caps' '--disable-doh'
compiled by GCC 10.2.1 20210110
compiled with OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
linked to OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
compiled with libuv version: 1.40.0
linked to libuv version: 1.40.0
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
### Steps to reproduce
run nslookup
attempt to look up literally anything
### What is the current *bug* behavior?
debugging output is produced alongside expected output
### What is the expected *correct* behavior?
normal output
### Possible fixes
in bin/dig/nslookup.c
Line 624 is "debugging = true;".
I suggest that this should be either "debugging = false;" or the line should be deleted.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/3116bind fails to build with jemalloc if jemalloc is using different prefix2022-07-12T13:50:19ZArkadiusz Miśkiewiczbind fails to build with jemalloc if jemalloc is using different prefix
### Summary
bind build with jemalloc fails (if jemalloc is using non default prefix)
### BIND version used
9.18.0
### Steps to reproduce
build jemalloc with --with-jemalloc-prefix=je_ and install it
build bind --with-jemalloc=yes
...
### Summary
bind build with jemalloc fails (if jemalloc is using non default prefix)
### BIND version used
9.18.0
### Steps to reproduce
build jemalloc with --with-jemalloc-prefix=je_ and install it
build bind --with-jemalloc=yes
### What is the current *bug* behavior?
Build fails with:
````
/bin/sh ../../libtool --tag=CC --mode=compile x86_64-pld-linux-gcc -DHAVE_CONFIG_H -I. -I../.. -D_FORTIFY_SOURCE=2 -include ../../config.h -I./include -I../../include -I../../lib/isc/include -I../../lib/isc/include -I/usr/include/json-c -I/usr/include/libxml2 -Wall -Wextra -Wwrite-strings -Wpointer-arith -Wno-missing-field-initializers -Wformat -Wshadow -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=format-security -Werror=parentheses -Werror=implicit -Werror=strict-prototypes -fno-strict-aliasing -fno-delete-null-pointer-checks -fdiagnostics-show-option -D_GNU_SOURCE=1 -O2 -fwrapv -pipe -Wformat -Werror=format-security -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4 -Werror=trampolines -fPIC -march=x86-64 -mtune=generic -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -pthread -MT libisc_la-mem.lo -MD -MP -MF .deps/libisc_la-mem.Tpo -c -o libisc_la-mem.lo `test -f 'mem.c' || echo './'`mem.c
libtool: compile: x86_64-pld-linux-gcc -DHAVE_CONFIG_H -I. -I../.. -D_FORTIFY_SOURCE=2 -include ../../config.h -I./include -I../../include -I../../lib/isc/include -I../../lib/isc/include -I/usr/include/json-c -I/usr/include/libxml2 -Wall -Wextra -Wwrite-strings -Wpointer-arith -Wno-missing-field-initializers -Wformat -Wshadow -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=format-security -Werror=parentheses -Werror=implicit -Werror=strict-prototypes -fno-strict-aliasing -fno-delete-null-pointer-checks -fdiagnostics-show-option -D_GNU_SOURCE=1 -O2 -fwrapv -pipe -Wformat -Werror=format-security -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong --param=ssp-buffer-size=4 -Werror=trampolines -fPIC -march=x86-64 -mtune=generic -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -pthread -MT libisc_la-mem.lo -MD -MP -MF .deps/libisc_la-mem.Tpo -c mem.c -fPIC -DPIC -o .libs/libisc_la-mem.o
mem.c: In function ‘mem_get’:
mem.c:345:15: error: implicit declaration of function ‘mallocx’; did you mean ‘malloc’? [-Werror=implicit-function-declaration]
345 | ret = mallocx(size, flags);
| ^~~~~~~
| malloc
mem.c:345:13: warning: assignment to ‘char *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
345 | ret = mallocx(size, flags);
| ^
mem.c: In function ‘mem_put’:
mem.c:366:9: error: implicit declaration of function ‘sdallocx’; did you mean ‘je_sdallocx’? [-Werror=implicit-function-declaration]
366 | sdallocx(mem, size, flags);
| ^~~~~~~~
| je_sdallocx
mem.c: In function ‘mem_realloc’:
mem.c:376:19: error: implicit declaration of function ‘rallocx’; did you mean ‘valloc’? [-Werror=implicit-function-declaration]
376 | new_ptr = rallocx(old_ptr, new_size, flags);
| ^~~~~~~
| valloc
mem.c:376:17: warning: assignment to ‘void *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
376 | new_ptr = rallocx(old_ptr, new_size, flags);
| ^
mem.c: In function ‘mem_create’:
mem.c:462:13: warning: assignment to ‘isc_mem_t *’ {aka ‘struct isc_mem *’} from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
462 | ctx = mallocx(sizeof(*ctx), MALLOCX_ALIGN(ISC_OS_CACHELINE_SIZE));
| ^
mem.c: In function ‘isc__mem_allocate’:
mem.c:897:16: error: implicit declaration of function ‘sallocx’; did you mean ‘valloc’? [-Werror=implicit-function-declaration]
897 | size = sallocx(ptr, 0);
| ^~~~~~~
| valloc
cc1: some warnings being treated as errors
make[4]: *** [Makefile:1391: libisc_la-mem.lo] Error 1
make[4]: Leaving directory '/home/users/arekm/rpm/BUILD/bind-9.18.0/lib/isc'
````
### What is the expected *correct* behavior?
build without failure
### Possible fixes
````
--- bind-9.18.0/lib/isc/mem.c~ 2022-01-24 09:28:57.000000000 +0100
+++ bind-9.18.0/lib/isc/mem.c 2022-01-27 15:01:27.389870903 +0100
@@ -48,6 +48,7 @@
#if defined(HAVE_MALLOC_NP_H)
#include <malloc_np.h>
#elif defined(HAVE_JEMALLOC)
+#define JEMALLOC_MANGLE 1
#include <jemalloc/jemalloc.h>
#if JEMALLOC_VERSION_MAJOR < 4
````
as explained in jemalloc/jemalloc.h itself:
```
/*
* By default application code must explicitly refer to mangled symbol names,
* so that it is possible to use jemalloc in conjunction with another allocator
* in the same application. Define JEMALLOC_MANGLE in order to cause automatic
* name mangling that matches the API prefixing that happened as a result of
* --with-mangling and/or --with-jemalloc-prefix configuration settings.
*/
```https://gitlab.isc.org/isc-projects/bind9/-/issues/3115Bind ignores cz.cc and cu.cc domains from RPZ blocking zone2022-02-25T13:16:42ZJan GardianBind ignores cz.cc and cu.cc domains from RPZ blocking zone<!--
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
When we added domains like test.cz.cc or test.cu.cc in RPZ zone, bind will not lookup those 2 TLDs in RPZ and always send request to upstream.
### BIND version used
Tested on Ubuntu20
BIND 9.16.1-Ubuntu (Stable Release) <id:d497c32>
Tested on Centos8
BIND 9.11.26-RedHat-9.11.26-6.el8 (Extended Support Version) <id:3ff8620>
### Steps to reproduce
1. Install bind and dns-utils
2. Configure named.conf
3. Configure test.zone
4. Validate with named-checkconf -z
5. Start named service
6. Test dig command for working block: `dig test.co.cc @127.0.0.1`
7. Test dig command for not working block: `dig test.cz.cc @127.0.0.1`
### What is the current *bug* behavior?
DNS queries against domain test.cu.cc and test.cz.cc are going always to upstream DNS for resolving and times out.
Even if those domains are configured in test.zone RPZ file. They are either ignored from RPZ checking or there is some hidden rule to always send those to upstream.
Another cc domains like test.co.cc and test.cc.cc return 127.0.0.1 correctly as defined in RPZ file.
### What is the expected *correct* behavior?
Domains test.cu.cc and test.cz.cc should be blocked with RPZ as it is for every other domain defined in RPZ.
### Relevant configuration files
named.conf:
```
options {
directory "/var/cache/bind";
recursion yes;
querylog yes;
allow-transfer {
none;
};
forwarders {
8.8.8.8;
};
dnssec-validation auto;
listen-on { 127.0.0.1; };
// enable response policy zone.
response-policy {
zone "rpz-block.com";
};
};
zone "rpz-block.com" {
type master;
file "/etc/named/test.zone";
};
```
RPZ block zone file /etc/named/test.zone:
```
$TTL 10
@ IN SOA localhost. root.localhost. (
2022012701 ;Serial
180 ;Refresh
180 ;Retry
604800 ;Expire
10 ;Minimum TTL
)
@ IN NS localhost.
test.co.cc 180 IN A 127.0.0.1
test.cc.cc 180 IN A 127.0.0.1
test.cu.cc 180 IN A 127.0.0.1
test.cz.cc 180 IN A 127.0.0.1
```
### Relevant logs and/or screenshots
Expected behavior from "dig test.co.cc":
```
dig test.co.cc @127.0.0.1
; <<>> DiG 9.11.26-RedHat-9.11.26-6.el8 <<>> test.co.cc @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2548
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 53d1528c6349377174a40a8261f2761a8758415c9e57bcf5 (good)
;; QUESTION SECTION:
;test.co.cc. IN A
;; ANSWER SECTION:
test.co.cc. 5 IN A 127.0.0.1
;; AUTHORITY SECTION:
rpz-block.com. 10 IN NS localhost.
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 27 10:38:18 UTC 2022
;; MSG SIZE rcvd: 119
```
named debug log:
```
27-Jan-2022 10:38:18.960 client @0x7f234c00c040 127.0.0.1#54687 (test.co.cc): query: test.co.cc IN A +E(0)K (127.0.0.1)
27-Jan-2022 10:38:18.960 client @0x7f234c00c040 127.0.0.1#54687 (test.co.cc): rpz QNAME Local-Data rewrite test.co.cc via test.co.cc.rpz-block.com
```
Debug logs from "dig test.cz.cc":
```
dig test.cz.cc @127.0.0.1
; <<>> DiG 9.11.26-RedHat-9.11.26-6.el8 <<>> test.cz.cc @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47907
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 21c9b32a3c911d3dbec3359461f276754b1b560848f9b487 (good)
;; QUESTION SECTION:
;test.cz.cc. IN A
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 27 10:39:49 UTC 2022
;; MSG SIZE rcvd: 67
```
named debug log:
```
7-Jan-2022 10:39:39.312 client @0x7f234c00c040 127.0.0.1#39671 (test.cz.cc): query: test.cz.cc IN A +E(0)K (127.0.0.1)
27-Jan-2022 10:39:39.312 fetch: test.cz.cc/A
27-Jan-2022 10:39:40.512 timed out resolving 'test.cz.cc/A/IN': 8.8.8.8#53
27-Jan-2022 10:39:40.512 address not available resolving 'test.cz.cc/A/IN': 240e:ff:9000:1100::1a7#53
27-Jan-2022 10:39:40.512 address not available resolving 'test.cz.cc/A/IN': 240e:ff:9000:1100::1a6#53
27-Jan-2022 10:39:44.312 client @0x7f2368220c50 127.0.0.1#39671 (test.cz.cc): query: test.cz.cc IN A +E(0)K (127.0.0.1)
27-Jan-2022 10:39:44.312 fetch: test.cz.cc/A
27-Jan-2022 10:39:49.312 client @0x7f234c00c040 127.0.0.1#39671 (test.cz.cc): query failed (SERVFAIL) for test.cz.cc/IN/A at ../../../bin/named/query.c:9441
27-Jan-2022 10:39:49.312 client @0x7f234c01cf50 127.0.0.1#39671 (test.cz.cc): query: test.cz.cc IN A +E(0)K (127.0.0.1)
27-Jan-2022 10:39:49.312 client @0x7f234c01cf50 127.0.0.1#39671 (test.cz.cc): servfail cache hit test.cz.cc/A (CD=0)
27-Jan-2022 10:39:49.312 client @0x7f234c01cf50 127.0.0.1#39671 (test.cz.cc): query failed (SERVFAIL) for test.cz.cc/IN/A at ../../../bin/named/query.c:7190
```
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)February 2022 (9.16.26, 9.16.26-S1)