BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-11-02T17:02:20Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3030Feature request: allow named-checkconf to accept "-" as a filename argument a...2023-11-02T17:02:20Zlibchap1Feature request: allow named-checkconf to accept "-" as a filename argument and read from stdinIt would be nice if `named-checkconf` (and possibly other utilities as well) accepted `-` as a source filename with the meaning of stdin.
It's possible to use `/dev/stdin`, but it does not work e.g. from within Python (calling by `subpr...It would be nice if `named-checkconf` (and possibly other utilities as well) accepted `-` as a source filename with the meaning of stdin.
It's possible to use `/dev/stdin`, but it does not work e.g. from within Python (calling by `subprocess.Popen(stdin=PIPE, ...)`.
It's also possible to use `/dev/fd/0`, but it seems not to be very nice.
Related issues: #1014 #1279
Thank you!Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3031Add support for caching parent and child NSEC and RRSIG at the same name2022-06-01T14:34:00ZMark AndrewsAdd support for caching parent and child NSEC and RRSIG at the same nameThis should improve synth-from-dnssec hit rates as we currently only keep the latest one we learn.
rbtdb will also need to become more selective about the covering NSEC returned. If we have a parental NSEC it is not valid for names tha...This should improve synth-from-dnssec hit rates as we currently only keep the latest one we learn.
rbtdb will also need to become more selective about the covering NSEC returned. If we have a parental NSEC it is not valid for names that are subdomains of the NSEC owner.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3034UDP dispatch can reuse <srcip, srcport, dstip, dstport>2022-03-01T09:47:10ZOndřej SurýUDP dispatch can reuse <srcip, srcport, dstip, dstport>This could possibly lead to the wrong callback receiving the response and dropping it on the floor because of non-matching QID.This could possibly lead to the wrong callback receiving the response and dropping it on the floor because of non-matching QID.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3036clang-format-13 leads to weird layout formatting of function parameters2021-12-01T08:52:54ZMatthijs Mekkingmatthijs@isc.orgclang-format-13 leads to weird layout formatting of function parametersThe following discussion from !5602 should be addressed:
- [ ] @matthijs started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5602#note_251399): (+1 comment)
> Off topic, but is this really the preferr...The following discussion from !5602 should be addressed:
- [ ] @matthijs started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5602#note_251399): (+1 comment)
> Off topic, but is this really the preferred format? Maybe we want to adjust the `clang-format`? @ondrejhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3038refactor peer.c to reduce copy-and-paste needed for new options.2021-12-02T02:05:21ZMark Andrewsrefactor peer.c to reduce copy-and-paste needed for new options.This should reduce copy-paste-replace errors.This should reduce copy-paste-replace errors.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3039update forward logging2024-03-27T13:21:26ZPeter Daviesupdate forward loggingupdate forward logging:
In installations where dynamic updates are forwarded from a secondary server to a stealth master server.
It could be helpful to be able to configure the forwarding server to log the originating source of the u...update forward logging:
In installations where dynamic updates are forwarded from a secondary server to a stealth master server.
It could be helpful to be able to configure the forwarding server to log the originating source of the update and the RRs being updated or enough sufficient to identify the client requesting the update.
[RT #19907](https://support.isc.org/Ticket/Display.html?id=19907 )Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3044'recursing clients' counter in stats is still underflowing on BIND 9.16.23-S12021-12-07T11:47:20ZCathy Almond'recursing clients' counter in stats is still underflowing on BIND 9.16.23-S1As reported in [Support ticket #19917](https://support.isc.org/Ticket/Display.html?id=19917)
For example:
```
4294445023 recursing clients
```
We seem to have addressed some causes of this anomaly in earlier versions of BIND ...As reported in [Support ticket #19917](https://support.isc.org/Ticket/Display.html?id=19917)
For example:
```
4294445023 recursing clients
```
We seem to have addressed some causes of this anomaly in earlier versions of BIND (#1078, #1719), but it is definitely still a problem.
There was one hypothesis that this might be related to DNS64 - however, no sign of DNS64 in this named.conf.
I would like to suggest that it might be due to one (or all) of:
- prefetch (it'd be easy to turn this off to confirm?)
- RPZ (yes, they have all of `nsip-wait-recurse no` and `qname-wait-recurse no` but whether or not additional recursion takes place is determined also by the actual policies in the policy zones themselves)
- Something awry with TCP socket handling?
- Something whacky with the interaction with serve-stale? (Although this is a default config., so `stale-cache-enable yes;`, `stale-answer-enable no;`.
No fetch-limits in this configuration, but if it was purely fetch-limits related, I think we'd have found and fixed it by now.https://gitlab.isc.org/isc-projects/bind9/-/issues/3046TCP client not being identified in log message2023-11-02T17:02:21ZMark AndrewsTCP client not being identified in log messageI was trying to match expected log messages in a system test (!5616) and switching from UDP to TCP to force a SERVFAIL rather than timeout response resulted in `<unknown>` for the client being logged instead of IP address and port.
`06-...I was trying to match expected log messages in a system test (!5616) and switching from UDP to TCP to force a SERVFAIL rather than timeout response resulted in `<unknown>` for the client being logged instead of IP address and port.
`06-Dec-2021 16:26:06.430 DNS format error from 10.53.0.8#5300 resolving tcpalso.no-questions/A for <unknown>: empty question section, accepting it anyway as TC=1`
The string I was expecting to match against was
`resolving tcpalso.no-questions/A for 10.53.0.5#[0-9]*: empty question section, accepting it anyway as TC=1`
I haven't checked 9.16 yet.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3050Post load checking of missing delegations2023-11-02T16:26:08ZMark AndrewsPost load checking of missing delegationsIs it worth while to perform a post load DS lookup for each primary / slave zone against the other loaded zone looking for a NXDOMAIN response which would indicate a missing delegation? This would catch cases like bhutan.gov.bt where b...Is it worth while to perform a post load DS lookup for each primary / slave zone against the other loaded zone looking for a NXDOMAIN response which would indicate a missing delegation? This would catch cases like bhutan.gov.bt where both it and the parent zone are served by the same servers but there isn't a delegation for bhutan.gov.bt in the gov.bt zone.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3058SUMMARY: ThreadSanitizer: data race in read2023-11-02T17:02:21ZOndřej SurýSUMMARY: ThreadSanitizer: data race in readThis almost seems like we are passing some buffer to isc_task that libuv is still using.
```
==================
WARNING: ThreadSanitizer: data race (pid=22062)
Write of size 8 at 0x7fdcbeac0000 by thread T9:
#0 read <null> (libtsa...This almost seems like we are passing some buffer to isc_task that libuv is still using.
```
==================
WARNING: ThreadSanitizer: data race (pid=22062)
Write of size 8 at 0x7fdcbeac0000 by thread T9:
#0 read <null> (libtsan.so.0+0x4ace2)
#1 uv__read /usr/src/libuv-v1.42.0/src/unix/stream.c:1164 (libuv.so.1+0x227e1)
#2 isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:185 (libisc-9.17.20.so+0x7b0e1)
Previous read of size 8 at 0x7fdcbeac0000 by thread T8:
#0 memmove <null> (libtsan.so.0+0x5da6e)
#1 memmove /usr/include/bits/string_fortified.h:36 (libisc-9.17.20.so+0x453d9)
#2 isc_buffer_copyregion /builds/isc-projects/bind9/lib/isc/buffer.c:530 (libisc-9.17.20.so+0x453d9)
#3 dns_zone_forwardupdate /builds/isc-projects/bind9/lib/dns/zone.c:18408 (libdns-9.17.20.so+0x22081d)
#4 forward_action /builds/isc-projects/bind9/lib/ns/update.c:3748 (libns-9.17.20.so+0x516d6)
#5 task_run /builds/isc-projects/bind9/lib/isc/task.c:827 (libisc-9.17.20.so+0x7237a)
#6 isc_task_run /builds/isc-projects/bind9/lib/isc/task.c:907 (libisc-9.17.20.so+0x7237a)
#7 isc__nm_async_task netmgr/netmgr.c:835 (libisc-9.17.20.so+0x1e9ab)
#8 process_netievent netmgr/netmgr.c:914 (libisc-9.17.20.so+0x27efb)
#9 process_queue netmgr/netmgr.c:1008 (libisc-9.17.20.so+0x28a2a)
#10 process_all_queues netmgr/netmgr.c:754 (libisc-9.17.20.so+0x29353)
#11 async_cb netmgr/netmgr.c:783 (libisc-9.17.20.so+0x29353)
#12 uv__async_io /usr/src/libuv-v1.42.0/src/unix/async.c:163 (libuv.so.1+0x110ef)
#13 isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:185 (libisc-9.17.20.so+0x7b0e1)
Location is heap block of size 1310720 at 0x7fdcbeac0000 allocated by main thread:
#0 malloc <null> (libtsan.so.0+0x32919)
#1 mallocx /builds/isc-projects/bind9/lib/isc/jemalloc_shim.h:33 (libisc-9.17.20.so+0x5b02a)
#2 mem_get /builds/isc-projects/bind9/lib/isc/mem.c:343 (libisc-9.17.20.so+0x5b02a)
#3 isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:758 (libisc-9.17.20.so+0x5b02a)
#4 isc__netmgr_create netmgr/netmgr.c:319 (libisc-9.17.20.so+0x1f2a4)
#5 isc_managers_create /builds/isc-projects/bind9/lib/isc/managers.c:39 (libisc-9.17.20.so+0x59ef2)
#6 create_managers /builds/isc-projects/bind9/bin/named/main.c:920 (named+0x424a19)
#7 setup /builds/isc-projects/bind9/bin/named/main.c:1184 (named+0x424a19)
#8 main /builds/isc-projects/bind9/bin/named/main.c:1452 (named+0x424a19)
Thread T9 'isc-net-0008' (tid=22096, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x5bf45)
#1 isc_thread_create /builds/isc-projects/bind9/lib/isc/thread.c:79 (libisc-9.17.20.so+0x7466d)
#2 isc__netmgr_create netmgr/netmgr.c:328 (libisc-9.17.20.so+0x1f34b)
#3 isc_managers_create /builds/isc-projects/bind9/lib/isc/managers.c:39 (libisc-9.17.20.so+0x59ef2)
#4 create_managers /builds/isc-projects/bind9/bin/named/main.c:920 (named+0x424a19)
#5 setup /builds/isc-projects/bind9/bin/named/main.c:1184 (named+0x424a19)
#6 main /builds/isc-projects/bind9/bin/named/main.c:1452 (named+0x424a19)
Thread T8 'isc-net-0007' (tid=22094, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.0+0x5bf45)
#1 isc_thread_create /builds/isc-projects/bind9/lib/isc/thread.c:79 (libisc-9.17.20.so+0x7466d)
#2 isc__netmgr_create netmgr/netmgr.c:328 (libisc-9.17.20.so+0x1f34b)
#3 isc_managers_create /builds/isc-projects/bind9/lib/isc/managers.c:39 (libisc-9.17.20.so+0x59ef2)
#4 create_managers /builds/isc-projects/bind9/bin/named/main.c:920 (named+0x424a19)
#5 setup /builds/isc-projects/bind9/bin/named/main.c:1184 (named+0x424a19)
#6 main /builds/isc-projects/bind9/bin/named/main.c:1452 (named+0x424a19)
SUMMARY: ThreadSanitizer: data race (/lib64/libtsan.so.0+0x4ace2) in read
==================
ThreadSanitizer: reported 1 warnings
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3059Follow-up from "Draft: Resolve #3055 by examining RTM_NEWADDR, RTM_DELADDR me...2021-12-20T11:58:16ZEvan HuntFollow-up from "Draft: Resolve #3055 by examining RTM_NEWADDR, RTM_DELADDR messages contents"The following discussion from !5638 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5638#note_254568): (+3 comments)
> We could also just take the RTM_NEWADDR and...The following discussion from !5638 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5638#note_254568): (+3 comments)
> We could also just take the RTM_NEWADDR and RTM_DELADDR content and add/delete the interfaces individually rather than scanning at all. Leave scanning for startup / reconfiguration. Queue up events while scanning then process any queued events at the end.
Also, see #3064.https://gitlab.isc.org/isc-projects/bind9/-/issues/3063dnssec-verify detect and support multiple cores2023-11-02T17:02:21ZDaniel Stirnimanndnssec-verify detect and support multiple cores### Description
We use `dnssec-verify` (from BIND 9.16) to validate large DNSSEC-signed zones. I noticed that on a multi core processor (eg 16 cores) always only one cpu is used. I guess, validation time could be speed up a lot if all a...### Description
We use `dnssec-verify` (from BIND 9.16) to validate large DNSSEC-signed zones. I noticed that on a multi core processor (eg 16 cores) always only one cpu is used. I guess, validation time could be speed up a lot if all available cores would be used.
### Request
Make `dnssec-verify` use all available cores automatically for operations for which this is possible eg. signature verification.
`dnssec-signzone` already automatically detects and uses all available cores and even has an argument switch to specify an specific number (`man dnssec-signzone`). I think something like this would be very useful:
```
-n ncpus
This option specifies the number of threads to use. By default, one thread is started for each detected CPU.
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3081When is BIND ready?2024-03-27T13:27:23ZGreg ChoulesWhen is BIND ready?Related to Support ticket [19717](https://support.isc.org/Ticket/Display.html?id=19717)
The purpose of this issue is to make BIND more verbose and precise about reporting various stages of readiness when starting up, leading to a definit...Related to Support ticket [19717](https://support.isc.org/Ticket/Display.html?id=19717)
The purpose of this issue is to make BIND more verbose and precise about reporting various stages of readiness when starting up, leading to a definitive "I'm ready now" log message.
The question an operator will want an answer to is, when can I send queries to this server again?
Different features will all have their own completeness check. For example: RPZ, local zones, remote zones, mirror zones, CATZ. The request is for new log messages to allow operators to track progress of each of these features and a new (or redefined) final log message when all tasks are complete.
What is a task? When is it complete and when is BIND ready to do that thing?
Us and the customer have, in parallel, come up with similar thinking on what needs to be done. The principle is, at startup time create a one-time todo list from the zone configuration statements. As each list item is completed, generate a signal and remove it from the list. When all items are completed generate a final completion signal and set the state of an indicator that can be queried by RNDC, so that users can test the current complete/not complete state periodically.
Taking some different types of zones as examples, we would expect behaviour like this:
Primary zones:
- Read zone data from local storage. Once this has been read into memory the zone is 'ready', a signal is generated and no further readiness checks need to be made: this task is complete.
Secondary zones:
- If a zone has been configured with a file, read zone data from local storage. Once this has been read into memory the zone is 'ready', a signal is generated and no further readiness checks need to be made: this task is complete. NOTE: checking whether the zone is up to date (SOA queries and possible subsequent zone transfer) is specifically excluded from this task.
- If a zone has **not** been configured with a file, make SOA queries and attempt zone transfers as necessary in order to load the zone. If zone transfer succeeds and zone data is loaded into memory the zone is 'ready', a signal is generated and no further readiness checks need to be made: this task is complete. If zone transfer fails there needs to be a limit - number of tries without success - to how long this task remains on the todo list. In this case generate a 'not ready' signal and remove the task from the list.
Catalog zones:
- These can be treated similarly to Primary or Secondary zones for the catalog itself. Once the catalog is loaded generate a ready signal and remove it from the todo list.
- However, during processing of each catalog a further list of (member) zones will be generated, each of which need to be added to the todo list and treated as a Secondary zone with no previous local data storage - i.e. needing to be transferred from a primary server.
Response Policy Zones:
- These can be treated similarly to Primary or Secondary zones for the zone data itself, but with the (possible?) additional step of needing to build the policy once it has been loaded. An RPZ should be considered ready only when the policy is active and responses would be re-written.
Mirror zones:
- These are similar to secondary zones.
Anything else?https://gitlab.isc.org/isc-projects/bind9/-/issues/3085checkds test is unstable on OpenBSD2022-01-10T14:50:34ZMichal Nowakcheckds test is unstable on OpenBSDJob [#2213656](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2213656) failed for 5d677c1b3642a33a1c855fc44b2fb65b7a36f512 on OpenBSD:
`wait_for_log()` fails to find `zone multiple-dspublished.checkds/IN (signed): checkds: DS response...Job [#2213656](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2213656) failed for 5d677c1b3642a33a1c855fc44b2fb65b7a36f512 on OpenBSD:
`wait_for_log()` fails to find `zone multiple-dspublished.checkds/IN (signed): checkds: DS response from 10.53.0.4` line in `ns9/named.run` which supposedly appears in the log at `07-Jan-2022 09:21:12.195` but it was able to find `zone multiple-dspublished.checkds/IN (signed): checkds: DS response from 10.53.0.2`, which in the log appears at `07-Jan-2022 09:21:11.688` - just 507 ms before. But this should not happen because `wait_for_log()` is polling 10 seconds for the line.
```
...
D:checkds:# DS correctly published in all parents.
D:checkds:zone_check(server, "multiple-dspublished.checkds.")
D:checkds:wait_for_log("ns9/named.run",
D:checkds:"zone multiple-dspublished.checkds/IN (signed): checkds: "
D:checkds:"DS response from 10.53.0.2")
D:checkds:> wait_for_log("ns9/named.run",
D:checkds:"zone multiple-dspublished.checkds/IN (signed): checkds: "
D:checkds:"DS response from 10.53.0.4")
D:checkds:
D:checkds:tests-checkds.py:269:
D:checkds:_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
D:checkds:
D:checkds:filename = 'ns9/named.run'
D:checkds:log = 'zone multiple-dspublished.checkds/IN (signed): checkds: DS response from 10.53.0.4'
D:checkds:
D:checkds:def wait_for_log(filename, log):
D:checkds:found = False
D:checkds:
D:checkds:for _ in range(10):
D:checkds:print("read log file {}".format(filename))
D:checkds:
D:checkds:try:
D:checkds:with open(filename, 'r', encoding='utf-8') as file:
D:checkds:s = mmap.mmap(file.fileno(), 0, access=mmap.ACCESS_READ)
D:checkds:if s.find(bytes(log, "ascii")) != -1:
D:checkds:found = True
D:checkds:except FileNotFoundError:
D:checkds:print("file not found {}".format(filename))
D:checkds:
D:checkds:if found:
D:checkds:break
D:checkds:
D:checkds:print("sleep")
D:checkds:time.sleep(1)
D:checkds:
D:checkds:> assert found
D:checkds:E assert False
D:checkds:
D:checkds:tests-checkds.py:219: AssertionError
D:checkds:----------------------------- Captured stdout call -----------------------------
D:checkds:read log file ns9/named.run
D:checkds:read state file ns9/Kdspublished.checkds.+013+46589.state
D:checkds:read log file ns9/named.run
D:checkds:read state file ns9/Kreference.checkds.+013+33843.state
D:checkds:read log file ns9/named.run
D:checkds:read state file ns9/Kmissing-dspublished.checkds.+013+18135.state
D:checkds:read log file ns9/named.run
D:checkds:read state file ns9/Kbad-dspublished.checkds.+013+20215.state
D:checkds:read log file ns9/named.run
D:checkds:read log file ns9/named.run
D:checkds:sleep
D:checkds:read log file ns9/named.run
D:checkds:sleep
D:checkds:read log file ns9/named.run
D:checkds:sleep
D:checkds:read log file ns9/named.run
D:checkds:sleep
D:checkds:read log file ns9/named.run
D:checkds:sleep
D:checkds:read log file ns9/named.run
D:checkds:sleep
D:checkds:read log file ns9/named.run
D:checkds:sleep
D:checkds:read log file ns9/named.run
D:checkds:sleep
D:checkds:read log file ns9/named.run
D:checkds:sleep
D:checkds:read log file ns9/named.run
D:checkds:sleep
D:checkds:===================== 1 failed, 1 passed in 11.14 seconds ======================
```
`named.run`: [named.run](/uploads/ced46b015192dfd435fd28988c35d7d5/named.run)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3089dispatch_test unit test fails on Dragonfly BSD2023-11-02T17:02:22ZMichal Nowakdispatch_test unit test fails on Dragonfly BSD`dispatch_test` unit test fails on Dragonfly BSD 6.2.1.
```
Core was generated by `dispatch_test'.
Program terminated with signal 6, Aborted.
#0 0x00000008019a879c in lwp_kill () from /lib/libc.so.8
#0 0x00000008019a879c in lwp_kill (...`dispatch_test` unit test fails on Dragonfly BSD 6.2.1.
```
Core was generated by `dispatch_test'.
Program terminated with signal 6, Aborted.
#0 0x00000008019a879c in lwp_kill () from /lib/libc.so.8
#0 0x00000008019a879c in lwp_kill () from /lib/libc.so.8
#1 0x000000080173c7f2 in _thr_send_sig () from /usr/lib/libpthread.so.0
#2 0x0000000801733ee5 in raise () from /usr/lib/libpthread.so.0
#3 0x0000000801a42dff in abort () from /lib/libc.so.8
#4 0x000000080069030f in isc_assertion_failed (file=file@entry=0x8006c3822 "netmgr/netmgr.c", line=line@entry=2565, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x8006c8780 "(((handle) != ((void *)0) && ((const isc__magic_t *)(handle))->magic == ((('N') << 24 | ('M') << 16 | ('H') << 8 | ('D')))) && __extension__ ({ __auto_type __atomic_load_ptr = (&(handle)->references);"...) at assertions.c:48
#5 0x000000080067d1df in isc_nm_send (handle=handle@entry=0x0, region=region@entry=0x7fffffdfc720, cb=cb@entry=0x800c3ac4b <send_done>, cbarg=cbarg@entry=0x8023e3a20) at netmgr/netmgr.c:2567
#6 0x0000000800c3d506 in dns_dispatch_send (resp=0x8023e3a20, r=r@entry=0x7fffffdfc720, dscp=dscp@entry=-1) at dispatch.c:1913
#7 0x0000000000403082 in connected (eresult=<optimized out>, region=<optimized out>, cbarg=0x7fffffdfc720) at dispatch_test.c:406
#8 0x0000000800c3b0fd in tcp_connected (handle=<optimized out>, eresult=ISC_R_UNEXPECTED, arg=<optimized out>) at dispatch.c:1747
#9 0x000000080067f739 in isc__nm_async_connectcb (worker=worker@entry=0x802558020, ev0=ev0@entry=0x802346ce0) at netmgr/netmgr.c:2763
#10 0x00000008006803ee in process_netievent (worker=worker@entry=0x802558020, ievent=0x802346ce0) at netmgr/netmgr.c:968
#11 0x00000008006806c7 in process_queue (worker=worker@entry=0x802558020, type=type@entry=NETIEVENT_NORMAL) at netmgr/netmgr.c:1008
#12 0x0000000800680da8 in process_all_queues (worker=0x802558020) at netmgr/netmgr.c:754
#13 async_cb (handle=0x8025582f8) at netmgr/netmgr.c:783
#14 0x000000080048c871 in ?? () from /usr/local/lib/libuv.so.1
#15 0x000000080049cd6a in ?? () from /usr/local/lib/libuv.so.1
#16 0x000000080048cfb6 in uv_run () from /usr/local/lib/libuv.so.1
#17 0x00000008006807bc in nm_thread (worker0=0x802558020) at netmgr/netmgr.c:689
#18 0x00000008006b8b03 in isc__trampoline_run (arg=0x802498440) at trampoline.c:185
#19 0x0000000801735a11 in ?? () from /usr/lib/libpthread.so.0
#20 0x0000000000000000 in ?? ()
```
<details><summary>backtrace</summary>
```
[newman@ ~/bind9]$ ./libtool --mode=execute /usr/bin/gdb.base -batch -command=bin/tests/system/run.gdb -core=lib/dns/tests/dispatch_test.core -- lib/dns/tests/.libs/dispatch_test
[New process 7]
[New process 1]
[New process 2]
[New process 3]
[New process 4]
[New process 5]
[New process 6]
[New process 8]
[New process 9]
[New process 10]
Core was generated by `dispatch_test'.
Program terminated with signal 6, Aborted.
#0 0x00000008019a879c in lwp_kill () from /lib/libc.so.8
Thread 10 (process 10):
#0 0x00000008019a8c7c in kevent () from /lib/libc.so.8
No symbol table info available.
#1 0x000000080049cba3 in ?? () from /usr/local/lib/libuv.so.1
No symbol table info available.
#2 0x000000080048cfb6 in uv_run () from /usr/local/lib/libuv.so.1
No symbol table info available.
#3 0x00000008006807bc in nm_thread (worker0=0x802558b90) at netmgr/netmgr.c:689
r = <optimized out>
worker = 0x802558b90
mgr = 0x8023b0ea0
#4 0x00000008006b8b03 in isc__trampoline_run (arg=0x8024968c0) at trampoline.c:185
trampoline = 0x8024968c0
result = <optimized out>
#5 0x0000000801735a11 in ?? () from /usr/lib/libpthread.so.0
No symbol table info available.
#6 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 9 (process 9):
#0 0x00000008019a8c7c in kevent () from /lib/libc.so.8
No symbol table info available.
#1 0x000000080049cba3 in ?? () from /usr/local/lib/libuv.so.1
No symbol table info available.
#2 0x000000080048cfb6 in uv_run () from /usr/local/lib/libuv.so.1
No symbol table info available.
#3 0x00000008006807bc in nm_thread (worker0=0x8025587c0) at netmgr/netmgr.c:689
r = <optimized out>
worker = 0x8025587c0
mgr = 0x8023b0ea0
#4 0x00000008006b8b03 in isc__trampoline_run (arg=0x802496a00) at trampoline.c:185
trampoline = 0x802496a00
result = <optimized out>
#5 0x0000000801735a11 in ?? () from /usr/lib/libpthread.so.0
No symbol table info available.
#6 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 8 (process 8):
#0 0x00000008019a8c7c in kevent () from /lib/libc.so.8
No symbol table info available.
#1 0x000000080049cba3 in ?? () from /usr/local/lib/libuv.so.1
No symbol table info available.
#2 0x000000080048cfb6 in uv_run () from /usr/local/lib/libuv.so.1
No symbol table info available.
#3 0x00000008006807bc in nm_thread (worker0=0x8025583f0) at netmgr/netmgr.c:689
r = <optimized out>
worker = 0x8025583f0
mgr = 0x8023b0ea0
#4 0x00000008006b8b03 in isc__trampoline_run (arg=0x802498b00) at trampoline.c:185
trampoline = 0x802498b00
result = <optimized out>
#5 0x0000000801735a11 in ?? () from /usr/lib/libpthread.so.0
No symbol table info available.
#6 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 7 (process 6):
#0 0x00000008017388bc in _umtx_sleep_err () from /usr/lib/libpthread.so.0
No symbol table info available.
#1 0x00000008017387fa in _thr_umtx_wait () from /usr/lib/libpthread.so.0
No symbol table info available.
#2 0x0000000801736531 in ?? () from /usr/lib/libpthread.so.0
No symbol table info available.
#3 0x0000000801736990 in pthread_cond_wait () from /usr/lib/libpthread.so.0
No symbol table info available.
#4 0x00000008006b4c88 in run (uap=0x8024a10a0) at timer.c:621
manager = 0x8024a10a0
now = {seconds = 1641839066, nanoseconds = 218490898}
result = <optimized out>
#5 0x00000008006b8b03 in isc__trampoline_run (arg=0x802497fa0) at trampoline.c:185
trampoline = 0x802497fa0
result = <optimized out>
#6 0x0000000801735a11 in ?? () from /usr/lib/libpthread.so.0
No symbol table info available.
#7 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 6 (process 5):
#0 0x00000008019a8c7c in kevent () from /lib/libc.so.8
No symbol table info available.
#1 0x000000080049cba3 in ?? () from /usr/local/lib/libuv.so.1
No symbol table info available.
#2 0x000000080048cfb6 in uv_run () from /usr/local/lib/libuv.so.1
No symbol table info available.
#3 0x00000008006807bc in nm_thread (worker0=0x80255fb90) at netmgr/netmgr.c:689
r = <optimized out>
worker = 0x80255fb90
mgr = 0x8023b12c0
#4 0x00000008006b8b03 in isc__trampoline_run (arg=0x8024979a0) at trampoline.c:185
trampoline = 0x8024979a0
result = <optimized out>
#5 0x0000000801735a11 in ?? () from /usr/lib/libpthread.so.0
No symbol table info available.
#6 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 5 (process 4):
#0 0x00000008019a8c7c in kevent () from /lib/libc.so.8
No symbol table info available.
#1 0x000000080049cba3 in ?? () from /usr/local/lib/libuv.so.1
No symbol table info available.
#2 0x000000080048cfb6 in uv_run () from /usr/local/lib/libuv.so.1
No symbol table info available.
#3 0x00000008006807bc in nm_thread (worker0=0x80255f7c0) at netmgr/netmgr.c:689
r = <optimized out>
worker = 0x80255f7c0
mgr = 0x8023b12c0
#4 0x00000008006b8b03 in isc__trampoline_run (arg=0x802496500) at trampoline.c:185
trampoline = 0x802496500
result = <optimized out>
#5 0x0000000801735a11 in ?? () from /usr/lib/libpthread.so.0
No symbol table info available.
#6 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 4 (process 3):
#0 0x00000008019a8c7c in kevent () from /lib/libc.so.8
No symbol table info available.
#1 0x000000080049cba3 in ?? () from /usr/local/lib/libuv.so.1
No symbol table info available.
#2 0x000000080048cfb6 in uv_run () from /usr/local/lib/libuv.so.1
No symbol table info available.
#3 0x00000008006807bc in nm_thread (worker0=0x80255f3f0) at netmgr/netmgr.c:689
r = <optimized out>
worker = 0x80255f3f0
mgr = 0x8023b12c0
#4 0x00000008006b8b03 in isc__trampoline_run (arg=0x802497de0) at trampoline.c:185
trampoline = 0x802497de0
result = <optimized out>
#5 0x0000000801735a11 in ?? () from /usr/lib/libpthread.so.0
No symbol table info available.
#6 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 3 (process 2):
#0 0x00000008019a8c7c in kevent () from /lib/libc.so.8
No symbol table info available.
#1 0x000000080049cba3 in ?? () from /usr/local/lib/libuv.so.1
No symbol table info available.
#2 0x000000080048cfb6 in uv_run () from /usr/local/lib/libuv.so.1
No symbol table info available.
#3 0x00000008006807bc in nm_thread (worker0=0x80255f020) at netmgr/netmgr.c:689
r = <optimized out>
worker = 0x80255f020
mgr = 0x8023b12c0
#4 0x00000008006b8b03 in isc__trampoline_run (arg=0x8024985c0) at trampoline.c:185
trampoline = 0x8024985c0
result = <optimized out>
#5 0x0000000801735a11 in ?? () from /usr/lib/libpthread.so.0
No symbol table info available.
#6 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 2 (process 1):
#0 0x00000008017388bc in _umtx_sleep_err () from /usr/lib/libpthread.so.0
No symbol table info available.
#1 0x000000080173886e in _thr_umtx_wait_intr () from /usr/lib/libpthread.so.0
No symbol table info available.
#2 0x0000000801739f5a in sem_wait () from /usr/lib/libpthread.so.0
No symbol table info available.
#3 0x000000080049943d in uv_sem_wait () from /usr/local/lib/libuv.so.1
No symbol table info available.
#4 0x0000000000403950 in dispatch_timeout_tcp_response (state=<optimized out>) at dispatch_test.c:532
result = <optimized out>
region = {base = 0x7fffffdfc708 "V\001", length = 12}
rbuf = '\000' <repeats 11 times>
message = "V\001\000\000\000\000\000\000\000\000\000"
id = 22017
sock = 0x80253e220
#5 0x0000000800606ae7 in ?? () from /usr/local/lib/libcmocka.so.0
No symbol table info available.
#6 0x00000008006073e8 in _cmocka_run_group_tests () from /usr/local/lib/libcmocka.so.0
No symbol table info available.
#7 0x00000000004041a2 in main () at dispatch_test.c:736
tests = {{name = 0x405256 "dispatch_timeout_tcp_connect", test_func = 0x403f87 <dispatch_timeout_tcp_connect>, setup_func = 0x403dde <_setup>, teardown_func = 0x403cd3 <_teardown>, initial_state = 0x0}, {name = 0x405273 "dispatch_timeout_tcp_response", test_func = 0x4037dc <dispatch_timeout_tcp_response>, setup_func = 0x403dde <_setup>, teardown_func = 0x403cd3 <_teardown>, initial_state = 0x0}, {name = 0x405291 "dispatch_tcp_response", test_func = 0x403a47 <dispatch_tcp_response>, setup_func = 0x403dde <_setup>, teardown_func = 0x403cd3 <_teardown>, initial_state = 0x0}, {name = 0x4052a7 "dispatch_timeout_udp_response", test_func = 0x4034a7 <dispatch_timeout_udp_response>, setup_func = 0x403dde <_setup>, teardown_func = 0x403cd3 <_teardown>, initial_state = 0x0}, {name = 0x4052c5 "dispatchset_create", test_func = 0x403445 <dispatchset_create>, setup_func = 0x403dde <_setup>, teardown_func = 0x403cd3 <_teardown>, initial_state = 0x0}, {name = 0x4052d8 "dispatchset_get", test_func = 0x403202 <dispatchset_get>, setup_func = 0x403dde <_setup>, teardown_func = 0x403cd3 <_teardown>, initial_state = 0x0}, {name = 0x4052e8 "dispatch_getnext", test_func = 0x402d57 <dispatch_getnext>, setup_func = 0x403dde <_setup>, teardown_func = 0x403cd3 <_teardown>, initial_state = 0x0}}
Thread 1 (process 7):
#0 0x00000008019a879c in lwp_kill () from /lib/libc.so.8
No symbol table info available.
#1 0x000000080173c7f2 in _thr_send_sig () from /usr/lib/libpthread.so.0
No symbol table info available.
#2 0x0000000801733ee5 in raise () from /usr/lib/libpthread.so.0
No symbol table info available.
#3 0x0000000801a42dff in abort () from /lib/libc.so.8
No symbol table info available.
#4 0x000000080069030f in isc_assertion_failed (file=file@entry=0x8006c3822 "netmgr/netmgr.c", line=line@entry=2565, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x8006c8780 "(((handle) != ((void *)0) && ((const isc__magic_t *)(handle))->magic == ((('N') << 24 | ('M') << 16 | ('H') << 8 | ('D')))) && __extension__ ({ __auto_type __atomic_load_ptr = (&(handle)->references);"...) at assertions.c:48
No locals.
#5 0x000000080067d1df in isc_nm_send (handle=handle@entry=0x0, region=region@entry=0x7fffffdfc720, cb=cb@entry=0x800c3ac4b <send_done>, cbarg=cbarg@entry=0x8023e3a20) at netmgr/netmgr.c:2567
No locals.
#6 0x0000000800c3d506 in dns_dispatch_send (resp=0x8023e3a20, r=r@entry=0x7fffffdfc720, dscp=dscp@entry=-1) at dispatch.c:1913
handle = 0x0
#7 0x0000000000403082 in connected (eresult=<optimized out>, region=<optimized out>, cbarg=0x7fffffdfc720) at dispatch_test.c:406
r = 0x7fffffdfc720
__func__ = "connected"
#8 0x0000000800c3b0fd in tcp_connected (handle=<optimized out>, eresult=ISC_R_UNEXPECTED, arg=<optimized out>) at dispatch.c:1747
disp = 0x802543b00
resp = 0x8023e3a20
next = 0x0
resps = {head = 0x0, tail = 0x0}
#9 0x000000080067f739 in isc__nm_async_connectcb (worker=worker@entry=0x802558020, ev0=ev0@entry=0x802346ce0) at netmgr/netmgr.c:2763
ievent = 0x802346ce0
sock = 0x80253d920
uvreq = 0x80247f020
eresult = ISC_R_UNEXPECTED
#10 0x00000008006803ee in process_netievent (worker=worker@entry=0x802558020, ievent=0x802346ce0) at netmgr/netmgr.c:968
No locals.
#11 0x00000008006806c7 in process_queue (worker=worker@entry=0x802558020, type=type@entry=NETIEVENT_NORMAL) at netmgr/netmgr.c:1008
stop = <optimized out>
waiting = 0
ievent = <optimized out>
#12 0x0000000800680da8 in process_all_queues (worker=0x802558020) at netmgr/netmgr.c:754
result = <optimized out>
type = 3
reschedule = false
#13 async_cb (handle=0x8025582f8) at netmgr/netmgr.c:783
worker = 0x802558020
#14 0x000000080048c871 in ?? () from /usr/local/lib/libuv.so.1
No symbol table info available.
#15 0x000000080049cd6a in ?? () from /usr/local/lib/libuv.so.1
No symbol table info available.
#16 0x000000080048cfb6 in uv_run () from /usr/local/lib/libuv.so.1
No symbol table info available.
#17 0x00000008006807bc in nm_thread (worker0=0x802558020) at netmgr/netmgr.c:689
r = <optimized out>
worker = 0x802558020
mgr = 0x8023b0ea0
#18 0x00000008006b8b03 in isc__trampoline_run (arg=0x802498440) at trampoline.c:185
trampoline = 0x802498440
result = <optimized out>
#19 0x0000000801735a11 in ?? () from /usr/lib/libpthread.so.0
No symbol table info available.
#20 0x0000000000000000 in ?? ()
No symbol table info available.
```
</details>
<details><summary>dispatch_test.log</summary>
```
[==========] Running 7 test(s).
[ RUN ] dispatch_timeout_tcp_connect
netmgr/tcpdns.c:151: unable to convert libuv error code in tcpdns_connect_direct to isc_result: -45: operation not supported on socket
timeout_connected(..., unexpected error, ...)
[ ERROR ] --- 0x22 != 0x2
[ LINE ] --- dispatch_test.c:487: error: Failure!
[ FAILED ] dispatch_timeout_tcp_connect
[ RUN ] dispatch_timeout_tcp_response
netmgr/tcpdns.c:151: unable to convert libuv error code in tcpdns_connect_direct to isc_result: -45: operation not supported on socket
connected(..., unexpected error, ...)
netmgr/netmgr.c:2565: 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__ (*__atomic_load_ptr) __atomic_load_tmp; __atomic_load (__atomic_load_ptr, &__atomic_load_tmp, (5)); __atomic_load_tmp; }) > 0)) failed, back trace
0x80069038f <isc_assertion_typetotext+0x6a> at /home/newman/bind9/lib/isc/.libs/libisc-9.17.21.so
0x80069030a <isc_assertion_failed+0xa> at /home/newman/bind9/lib/isc/.libs/libisc-9.17.21.so
0x80067d1df <isc_nm_send+0x52> at /home/newman/bind9/lib/isc/.libs/libisc-9.17.21.so
0x800c3d506 <dns_dispatch_send+0x5a> at /home/newman/bind9/lib/dns/.libs/libdns-9.17.21.so
0x403082 <connected+0x43> at /home/newman/bind9/lib/dns/tests/.libs/dispatch_test
0x800c3b0fd <dns_dispatch_detach+0xa4c> at /home/newman/bind9/lib/dns/.libs/libdns-9.17.21.so
0x80067f739 <isc__nm_async_connectcb+0xa5> at /home/newman/bind9/lib/isc/.libs/libisc-9.17.21.so
0x8006803ee <isc__nm_async_sendcb+0x79f> at /home/newman/bind9/lib/isc/.libs/libisc-9.17.21.so
0x8006806c7 <isc__nm_async_sendcb+0xa78> at /home/newman/bind9/lib/isc/.libs/libisc-9.17.21.so
0x800680da8 <isc_nm_resume+0x26d> at /home/newman/bind9/lib/isc/.libs/libisc-9.17.21.so
0x80048c871 <uv_version_string+0x1b1> at /usr/local/lib/libuv.so.1
0x80049cd6a <uv_cpu_info+0xb4a> at /usr/local/lib/libuv.so.1
0x80048cfb6 <uv_run+0xf6> at /usr/local/lib/libuv.so.1
0x8006807bc <isc__nm_async_sendcb+0xb6d> at /home/newman/bind9/lib/isc/.libs/libisc-9.17.21.so
0x8006b8b03 <isc__trampoline_run+0x16> at /home/newman/bind9/lib/isc/.libs/libisc-9.17.21.so
0x801735a11 <pthread_detach+0x287> at /usr/lib/libpthread.so.0
FAIL dispatch_test (exit status: 134)
```
</details>Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3094doth: RNDC reconfiguration too slow on OpenIndiana2022-01-14T11:18:06ZMichal Nowakdoth: RNDC reconfiguration too slow on OpenIndianaEven with 2e5f9a0df5e0a8a15c1cdf69f2aae55fd7a0aca3 RNDC reconfiguration in `doth` system test takes 30-60 second and `dig` invocations fail with "connection refused" on OpenIndiana (but not on Solaris 11.4). Affects `doth` tests "checkin...Even with 2e5f9a0df5e0a8a15c1cdf69f2aae55fd7a0aca3 RNDC reconfiguration in `doth` system test takes 30-60 second and `dig` invocations fail with "connection refused" on OpenIndiana (but not on Solaris 11.4). Affects `doth` tests "checking DoT query after a reconfiguration" and "checking DoH query (POST) after a reconfiguration".
Keep `named`s from `doth` system test running and issue `../../../bin/rndc/rndc -c common/rndc.conf -p 5312 -s 10.53.0.4 reconfig` command:
```
...
11-Jan-2022 16:43:49.938 calling free_rbtdb(.)
11-Jan-2022 16:43:49.938 done free_rbtdb(.)
```
Only after 30 seconds (sometimes close to 60 seconds) `named` is ready:
```
11-Jan-2022 16:44:19.082 listening on IPv4 interface lo0, 10.53.0.4#5301
11-Jan-2022 16:44:19.083 listening on IPv4 interface lo0, 10.53.0.4#5303
```
Otherwise, `../../../bin/dig/dig +tls +noadd +nosea +nostat +noquest +nocmd -p 5301 @10.53.0.4 example SOA` fails with:
```
;; Connection to 10.53.0.4#5301(10.53.0.4) for example failed: connection refused.
;; Connection to 10.53.0.4#5301(10.53.0.4) for example failed: connection refused.
;; Connection to 10.53.0.4#5301(10.53.0.4) for example failed: connection refused.
```
CPU utilization of `named` looks sub 1% during the reconfiguration.Not plannedArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/30979.16 responds with Additional section even though "minimal-responses" is set ...2022-03-21T14:37:51ZGreg Choules9.16 responds with Additional section even though "minimal-responses" is set to yesAs reported in [20030](https://support.isc.org/Ticket/Display.html?id=20030)
An authoritative server (secondary, but it happens on a primary as well) is configured with "minimal-responses yes;". Queries to it - either recursive or non-r...As reported in [20030](https://support.isc.org/Ticket/Display.html?id=20030)
An authoritative server (secondary, but it happens on a primary as well) is configured with "minimal-responses yes;". Queries to it - either recursive or non-recursive - for a name it owns receive a response containing the answer + an Additional section. For comparison, 9.11 provides only the answer section.
This issue is, firstly, a question: why does 9.16 do this and do subsequent versions behave the same way?
Secondly, if this behaviour is unintended can it be fixed?
**Config**
```
options {
minimal-responses yes;
zone "junk" {
type primary;
file "db.junk";
};
```
**zone data**
```
@ SOA test test 2022011301 10800 3600 604800 1800
@ NS a.nsset.junk.
@ NS b.nsset.junk.
a.nsset A 1.2.3.4
b.nsset A 1.2.3.5
```
**dig output**
```
; <<>> DiG 9.16.19 <<>> @127.0.0.1 junk ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44384
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: a42ac059d64983360100000061e06294be1d9cc3a16e3adc (good)
;; QUESTION SECTION:
;junk. IN NS
;; ANSWER SECTION:
junk. 1800 IN NS b.nsset.junk.
junk. 1800 IN NS a.nsset.junk.
;; ADDITIONAL SECTION:
a.nsset.junk. 1800 IN A 1.2.3.4
b.nsset.junk. 1800 IN A 1.2.3.5
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 13 17:34:12 GMT 2022
;; MSG SIZE rcvd: 135
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3098Intermittent mkeys test failure2022-01-14T13:53:30ZOndřej SurýIntermittent mkeys test failurehttps://gitlab.isc.org/isc-projects/bind9/-/jobs/2231254
```
I:mkeys:reset the root server with no keys, check for minimal update (23)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:ns2 refreshing managed keys for '_default'
...https://gitlab.isc.org/isc-projects/bind9/-/jobs/2231254
```
I:mkeys:reset the root server with no keys, check for minimal update (23)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:failed
I:mkeys:reset the root server with no signatures, check for minimal update (24)
```
I am guessing this is timing related again.Not plannedhttps://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/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 planned