BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-07-07T09:25:45Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4112"serve-stale:check prefetch processing of a stale CNAME target" fails on Free...2023-07-07T09:25:45ZMichal Nowak"serve-stale:check prefetch processing of a stale CNAME target" fails on FreeBSD 13Job [#3435305](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3435305) failed for ff3d25a47f9f969669b2e4f5cde10c50f9cdd171 (~"v9.18").
On FreeBSD 13.2, the `check prefetch processing of a stale CNAME target` check [failed](https://git...Job [#3435305](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3435305) failed for ff3d25a47f9f969669b2e4f5cde10c50f9cdd171 (~"v9.18").
On FreeBSD 13.2, the `check prefetch processing of a stale CNAME target` check [failed](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3435305) [twice](https://gitlab.isc.org/isc-private/bind9/-/jobs/3431983) in the recent days:
```
2023-06-02 01:09:52 INFO:serve-stale I:serve-stale_tmp_q8yamlle:check prefetch processing of a stale CNAME target (214)
2023-06-02 01:09:55 INFO:serve-stale I:serve-stale_tmp_q8yamlle:failed
```
This was expected:
```
target.example. 2 IN A 10.53.0.2
```
But this was the answer:
```
target.example. 30 IN A 10.53.0.2
```
We got a stale answer after client timeout (`; EDE: 3 (Stale Answer): (client timeout)`), query time was 1840 msec. Locally, I get 2 msec and a non-stale answer.
I was unable to reproduce the problem locally.https://gitlab.isc.org/isc-projects/bind9/-/issues/4104ZoneQuota stats counter is not counting everything2024-02-24T07:55:05ZOndřej SurýZoneQuota stats counter is not counting everythingThe `ZoneQuota` should log all the hits to `fcount_incr()` returning `ISC_R_QUOTA`, but it does only in a single place. The counting should be moved to `fctx_incr()`.The `ZoneQuota` should log all the hits to `fcount_incr()` returning `ISC_R_QUOTA`, but it does only in a single place. The counting should be moved to `fctx_incr()`.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4092timer.c:223:timerevent_destroy(): fatal error: RUNTIME_CHECK(isc_mutex_unlock...2023-05-25T07:38:17ZMichal Nowaktimer.c:223:timerevent_destroy(): fatal error: RUNTIME_CHECK(isc_mutex_unlock((&timer->lock)) == ISC_R_SUCCESS) failedJob [#3411550](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3411550) failed for 66254cf56d7072833db6d8744e6bcef2109b72e2.
BIND 9.18 `task` unit test failed on `unit:gcc:oraclelinux8:amd64`.
```
[==========] Running 11 test(s).
[ RU...Job [#3411550](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3411550) failed for 66254cf56d7072833db6d8744e6bcef2109b72e2.
BIND 9.18 `task` unit test failed on `unit:gcc:oraclelinux8:amd64`.
```
[==========] Running 11 test(s).
[ RUN ] manytasks
[ OK ] manytasks
[ RUN ] all_events
[ OK ] all_events
[ RUN ] basic
timer.c:223:timerevent_destroy(): fatal error: RUNTIME_CHECK(isc_mutex_unlock((&timer->lock)) == ISC_R_SUCCESS) failed
../../tests/unit-test-driver.sh: line 36: 8595 Aborted (core dumped) "${TEST_PROGRAM}"
I:task_test:Core dump found: ./core.8595
D:task_test:backtrace from ./core.8595 start
[New LWP 8636]
[New LWP 8595]
[New LWP 8637]
[New LWP 8638]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/builds/isc-projects/bind9/tests/isc/.libs/lt-task_test'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f8c5b302aff in raise () from /lib64/libc.so.6
[Current thread is 1 (Thread 0x7f8c3bfff700 (LWP 8636))]
Thread 4 (Thread 0x7f8c412fa700 (LWP 8638)):
#0 0x00007f8c5b68846c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x00007f8c5c4af725 in run (uap=0x7f8c591e1000) at timer.c:632
manager = 0x7f8c591e1000
now = {seconds = 1684976709, nanoseconds = 609640403}
result = <optimized out>
__func__ = "run"
#2 0x00007f8c5c4b4b20 in isc__trampoline_run (arg=0x1973730) at trampoline.c:189
trampoline = 0x1973730
result = <optimized out>
#3 0x00007f8c5b6821da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00007f8c5b2ede73 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 3 (Thread 0x7f8c40af9700 (LWP 8637)):
#0 0x00007f8c5b3e4017 in epoll_wait () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007f8c5c2460f9 in uv.io_poll () from /lib64/libuv.so.1
No symbol table info available.
#2 0x00007f8c5c234a74 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#3 0x00007f8c5c47aa6c in nm_thread (worker0=0x7f8c591f75b8) at netmgr/netmgr.c:698
r = <optimized out>
worker = 0x7f8c591f75b8
mgr = 0x7f8c59036000
__func__ = "nm_thread"
#4 0x00007f8c5c4b4b20 in isc__trampoline_run (arg=0x1974330) at trampoline.c:189
trampoline = 0x1974330
result = <optimized out>
#5 0x00007f8c5b6821da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#6 0x00007f8c5b2ede73 in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 2 (Thread 0x7f8c5ce04140 (LWP 8595)):
#0 0x00007f8c5b3ae9a8 in nanosleep () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007f8c5b3dbf48 in usleep () from /lib64/libc.so.6
No symbol table info available.
#2 0x00007f8c5c4ac692 in isc__taskmgr_destroy (managerp=managerp@entry=0x607348 <taskmgr>) at task.c:1041
No locals.
#3 0x00007f8c5c49b4b0 in isc_managers_destroy (netmgrp=netmgrp@entry=0x607338 <netmgr>, taskmgrp=taskmgrp@entry=0x607348 <taskmgr>, timermgrp=timermgrp@entry=0x607340 <timermgr>) at managers.c:99
No locals.
#4 0x00000000004052ee in teardown_managers (state=<optimized out>) at isc.c:84
No locals.
#5 0x0000000000404f64 in _teardown (state=<optimized out>) at task_test.c:91
No locals.
#6 0x00007f8c5be1702e in cmocka_run_one_test_or_fixture () from /lib64/libcmocka.so.0
No symbol table info available.
#7 0x00007f8c5be179e0 in _cmocka_run_group_tests () from /lib64/libcmocka.so.0
No symbol table info available.
#8 0x000000000040516b in main () at task_test.c:1408
r = <optimized out>
Thread 1 (Thread 0x7f8c3bfff700 (LWP 8636)):
#0 0x00007f8c5b302aff in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007f8c5b2d5ea5 in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x00007f8c5c48f5c2 in isc_error_fatal (file=file@entry=0x7f8c5c4c45a6 "timer.c", line=line@entry=223, func=func@entry=0x7f8c5c4d07a0 <__func__.7544> "timerevent_destroy", format=format@entry=0x7f8c5c4c0814 "RUNTIME_CHECK(%s) failed") at error.c:72
args = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7f8c3bff9d00, reg_save_area = 0x7f8c3bff9c40}}
#3 0x00007f8c5c4af15f in timerevent_destroy (event0=0x7f8c51800b00) at timer.c:225
timer = 0x7f8c591e10a0
event = 0x7f8c51800b00
__func__ = "timerevent_destroy"
#4 0x00007f8c5c48f7e9 in isc_event_free (eventp=eventp@entry=0x7f8c3bff9d48) at event.c:93
event = <optimized out>
#5 0x0000000000403449 in basic_tick (task=<optimized out>, event=<optimized out>) at task_test.c:444
No locals.
#6 0x00007f8c5c4abf17 in task_run (task=0x7f8c591e73c0) at task.c:815
dispatch_count = 0
finished = false
quantum = <optimized out>
event = 0x7f8c51800b00
result = ISC_R_SUCCESS
dispatch_count = <optimized out>
finished = <optimized out>
event = <optimized out>
result = <optimized out>
quantum = <optimized out>
__func__ = "task_run"
__atomic_load_ptr = <optimized out>
__atomic_load_tmp = <optimized out>
__atomic_load_ptr = <optimized out>
__atomic_load_tmp = <optimized out>
__atomic_load_ptr = <optimized out>
__atomic_load_tmp = <optimized out>
__atomic_load_ptr = <optimized out>
__atomic_load_tmp = <optimized out>
__v = <optimized out>
#7 isc_task_run (task=0x7f8c591e73c0) at task.c:896
No locals.
#8 0x00007f8c5c472579 in isc__nm_async_task (worker=worker@entry=0x7f8c591f7000, ev0=ev0@entry=0x7f8c51805f80) at netmgr/netmgr.c:848
ievent = 0x7f8c51805f80
result = <optimized out>
#9 0x00007f8c5c479d78 in process_netievent (worker=worker@entry=0x7f8c591f7000, ievent=ievent@entry=0x7f8c51805f80) at netmgr/netmgr.c:920
No locals.
#10 0x00007f8c5c47a78e in process_queue (worker=worker@entry=0x7f8c591f7000, type=type@entry=NETIEVENT_TASK) at netmgr/netmgr.c:1013
next = 0x0
ievent = 0x7f8c51805f80
list = {head = 0x0, tail = 0x0}
__func__ = "process_queue"
#11 0x00007f8c5c47b23b in process_all_queues (worker=0x7f8c591f7000) at netmgr/netmgr.c:767
result = <optimized out>
type = 2
reschedule = false
reschedule = <optimized out>
type = <optimized out>
result = <optimized out>
#12 async_cb (handle=0x7f8c591f7360) at netmgr/netmgr.c:796
worker = 0x7f8c591f7000
#13 0x00007f8c5c2342f1 in uv.async_io.part () from /lib64/libuv.so.1
No symbol table info available.
#14 0x00007f8c5c245d15 in uv.io_poll () from /lib64/libuv.so.1
No symbol table info available.
#15 0x00007f8c5c234a74 in uv_run () from /lib64/libuv.so.1
No symbol table info available.
#16 0x00007f8c5c47aa6c in nm_thread (worker0=0x7f8c591f7000) at netmgr/netmgr.c:698
r = <optimized out>
worker = 0x7f8c591f7000
mgr = 0x7f8c59036000
__func__ = "nm_thread"
#17 0x00007f8c5c4b4b20 in isc__trampoline_run (arg=0x1976840) at trampoline.c:189
trampoline = 0x1976840
result = <optimized out>
#18 0x00007f8c5b6821da in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#19 0x00007f8c5b2ede73 in clone () from /lib64/libc.so.6
No symbol table info available.
D:task_test:backtrace from ./core.8595 end
FAIL task_test (exit status: 134)
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4014Implement tests for maximum global and idle time for incoming XFR2023-05-04T14:23:14ZOndřej SurýImplement tests for maximum global and idle time for incoming XFRSpin-off from !7810 to not forget to write pytests for maximum global and idle time for incoming XFR.Spin-off from !7810 to not forget to write pytests for maximum global and idle time for incoming XFR.Not plannedTom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4013Add more tests for #4001 and #40022023-07-03T15:47:55ZOndřej SurýAdd more tests for #4001 and #4002This is a follow up from !7805 to add more tests for the source-port configuration.
To quote @pspacek:
> Well, this is pretty large change and needs tests. If nothing else I would like to see what happens if:
>
> * attempt to open TCP...This is a follow up from !7805 to add more tests for the source-port configuration.
To quote @pspacek:
> Well, this is pretty large change and needs tests. If nothing else I would like to see what happens if:
>
> * attempt to open TCP connection ends up in packet black-hole
> * connection is established and the remote side does not respond (established connection hangs)
> * the remote side responds with some something which does not parse as DNS
> * the remote side sends mismatching NOTIFY answer (say different zone name)Not plannedTom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4007mkeys: exceeded time limit waiting for 'dump_done' in ns5/named.run2023-04-06T12:42:02ZMichal Nowakmkeys: exceeded time limit waiting for 'dump_done' in ns5/named.runJob [#3300214](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3300214) failed for 8f73f5d0886d9e0f57f593fbf3bae862d13f9853:
```
I:mkeys:check 'rndc managed-keys' and islands of trust now that root is reachable (39)
I:mkeys:exceeded ti...Job [#3300214](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3300214) failed for 8f73f5d0886d9e0f57f593fbf3bae862d13f9853:
```
I:mkeys:check 'rndc managed-keys' and islands of trust now that root is reachable (39)
I:mkeys:exceeded time limit waiting for 'dump_done' in ns5/named.run
```
I've seen the 20-second limit exceeded several times.
Bumping it to 60 might be a good thing.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3987Change DNSKEY TTL of inline-signed zone2024-02-24T07:55:08ZGerald VogtChange DNSKEY TTL of inline-signed zone### Description
I have a few zones using inline-signing which I have set up originally with 2d TTL. Due to this the existing DNSKEY RRs also have 2d TTL. Now I have been trying to reduce the TTL to 1d but it seems there is no supported ...### Description
I have a few zones using inline-signing which I have set up originally with 2d TTL. Due to this the existing DNSKEY RRs also have 2d TTL. Now I have been trying to reduce the TTL to 1d but it seems there is no supported way or tool to do so.
I have set dnskey-ttl to 1d and replace keys, still all DNSKEY RRs have 2d TTL. Setting it on the key with dnssec-settime doesn't help either and man pages specifically mention:
```
This option sets the default TTL to use for this key when it is converted into a DNSKEY RR.
This is the TTL used when the key is imported into a zone, unless there was already a DNSKEY
RRset in place, in which case the existing TTL takes precedence.
```
Running AlmaLinux 9 bind-9.16.23-5.el9_1.x86_64.
### Request
Add some way to change the TTL of DNSKEY RRs in inline-signed zones.
### Links / references
I have found a thread from 2016 about the same problem: https://www.mail-archive.com/bind-users@lists.isc.org/msg23186.htmlMay 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3913timing issue in statschannel system test2023-03-03T08:07:02ZTom Krizektiming issue in statschannel system testIn job [#3207137](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3207137) the `statschannel` failed on check `fetch zone 'dnssec' stats data after updating DNSKEY RRset (7)`.
The test expects 1 zsk sign operation and 1 ksk sign operat...In job [#3207137](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3207137) the `statschannel` failed on check `fetch zone 'dnssec' stats data after updating DNSKEY RRset (7)`.
The test expects 1 zsk sign operation and 1 ksk sign operation. These happen:
```
02-Mar-2023 09:10:06.228 add re-sign dnssec. 300 IN RRSIG DNSKEY 13 1 300 20230401091005 20230302081006 7913 dnssec. MT/JQRYMGsWYBwyRkdnj+tB7h2oSbpVfZ9n+DMr1oyDdXtRSoxGwydIO a2GRjUgP5kQ/N5JWUQMK2LkvThFvsA==
02-Mar-2023 09:10:06.228 add re-sign dnssec. 300 IN RRSIG SOA 13 1 300 20230401091006 20230302081006 35685 dnssec. unerVqERet0Xr8KV19/D174G3moa5NVkDoXIbvpc3cPQuzCd/z+eYC2h zuLlEZawAFe2NTI3jw+TDkIgKfpnCw==
```
Then the test waits for `next key event`:
```
02-Mar-2023 09:10:06.228 zone dnssec/IN: next key event: 02-Mar-2023 10:10:06.220
```
However, 100 milliseconds later, before the test retrieves the zone statistics from the statschannel, additional signing operations take place:
```
02-Mar-2023 09:10:06.328 zone_maintenance: zone dnssec/IN: enter
02-Mar-2023 09:10:06.328 zone_resigninc: zone dnssec/IN: enter
02-Mar-2023 09:10:06.328 zone_journal: zone dnssec/IN: enter
02-Mar-2023 09:10:06.328 writing to journal
02-Mar-2023 09:10:06.328 del dnssec. 300 IN SOA mname1. . 4 20 20 1814400 3600
02-Mar-2023 09:10:06.328 del re-sign dnssec. 300 IN RRSIG NS 13 1 300 20230309211006 20230302080959 35685 dnssec. kaS58YnGbS/p3V8088p+yREiSINte5ETOr/3QvFU9XsHyuxDqRLkux6i XqY5/PSkQFm094MO/wNLdbTp8LaB2g==
02-Mar-2023 09:10:06.328 del re-sign a.dnssec. 300 IN RRSIG NSEC 13 2 300 20230309211006 20230302080959 35685 dnssec. 12MDX1o0qgh0T3SoM0aKsu6AjJYcueqHpOT//xD0l/EjFJgBOVu3VJpA 0OO3R/VdQzFeBq1tgY88dpLnTwvKUw==
02-Mar-2023 09:10:06.328 del re-sign a.dnssec. 300 IN RRSIG MX 13 2 300 20230309211006 20230302080959 35685 dnssec. vGNl05h/fsvnnHvU1RX3yUuCRS5Egqd9Mr5HxZ8J3uZAleQNVxUa+gG9 f9ZJ+q6+Zp8Kz8AFHqCxN1vMq0+5zw==
02-Mar-2023 09:10:06.332 del re-sign mail.dnssec. 300 IN RRSIG A 13 2 300 20230309211006 20230302080959 35685 dnssec. RRafXWoDHpbErUBXOVzI3rbREe8ezmj8QEHpHampjKVNJrfzFWbP1cku meg3TPsTCQdy/1v6v4cvfB03SusQoQ==
02-Mar-2023 09:10:06.332 del re-sign a.dnssec. 300 IN RRSIG A 13 2 300 20230309211006 20230302080959 35685 dnssec. ofun5lwcYTsK0OawryLIViK/sdJHPSHT7RxoQR5ErmkAPpjZvTIoE4EO ua95xdHE1X5h/hnJCBYPpl5kHS+Lfg==
02-Mar-2023 09:10:06.332 del re-sign mail.dnssec. 300 IN RRSIG NSEC 13 2 300 20230309211006 20230302080959 35685 dnssec. GspggAHIxa6RQMbauI4On2esTEWifodSorcCjxqlwtZ71XOF7LdtWTbw HLf5o1xYP76o2RRN3CAZRPmAOs1Lkw==
02-Mar-2023 09:10:06.332 del re-sign ns2.dnssec. 300 IN RRSIG NSEC 13 2 300 20230309211006 20230302080959 35685 dnssec. FJXd9+ncwyBxhrMpmAO3xs1sEGlP3g0EhmOk9IHa4/Ljgv6qIJYIL7hW dz2JbfYjI3oI+QqbCEM/5mIM9AO5Jw==
02-Mar-2023 09:10:06.332 del re-sign ns2.dnssec. 300 IN RRSIG A 13 2 300 20230309211006 20230302080959 35685 dnssec. gzliUistEykm6hpMGY8ForYJewFzaUB4rPOJxHROOupf8jaX+GhbelWU tfcnLKmjypuWEIdyFkGugFpzE/slCA==
02-Mar-2023 09:10:06.332 del re-sign dnssec. 300 IN RRSIG SOA 13 1 300 20230401091006 20230302081006 35685 dnssec. unerVqERet0Xr8KV19/D174G3moa5NVkDoXIbvpc3cPQuzCd/z+eYC2h zuLlEZawAFe2NTI3jw+TDkIgKfpnCw==
02-Mar-2023 09:10:06.332 add dnssec. 300 IN SOA mname1. . 5 20 20 1814400 3600
02-Mar-2023 09:10:06.332 add re-sign dnssec. 300 IN RRSIG NS 13 1 300 20230401084359 20230302081006 35685 dnssec. C+vYMDHLb6wperZxXwTAAK3vM9XJ+7/WAGddPyQcdI+fp6hRXL6UM4hz C5qj8+hnKY0E2bHq1jYLoQaw62M/mw==
02-Mar-2023 09:10:06.332 add re-sign a.dnssec. 300 IN RRSIG NSEC 13 2 300 20230401084359 20230302081006 35685 dnssec. h1X7d4NBfaVyRJnkzcsiyjAZPXufVBgKPw08wxAm8Zx1W8N5Tg0WS2/m Xx6MyytvPoCSFFvFOQLkCXurucZUww==
02-Mar-2023 09:10:06.332 add re-sign a.dnssec. 300 IN RRSIG MX 13 2 300 20230401084359 20230302081006 35685 dnssec. J5uy5bjeXLdt73gV8nv4/dbj+cjOIcyFHuh6Qp/sdqFE/sswo8izCdRU 3/iYmjwLS9EeNs6dEb2xx0l9heRmDg==
02-Mar-2023 09:10:06.332 add re-sign mail.dnssec. 300 IN RRSIG A 13 2 300 20230401084359 20230302081006 35685 dnssec. wCLJPDVyC8ja84GHqaA/OnUrOocpAKNOZiTQJdHJkwkkd0BbVxLazYiP fE2rKG54VIFvGxC/EcXavXcqiFeQEg==
02-Mar-2023 09:10:06.332 add re-sign a.dnssec. 300 IN RRSIG A 13 2 300 20230401084359 20230302081006 35685 dnssec. /BXz8YtxNfEo3tJYFGRHVjMQQDAtzZ8ne2nJOm6CQm3d803qzs5JaHLy /4hmNB5oTEz1l9kXw3LQnB94iuH/yA==
02-Mar-2023 09:10:06.332 add re-sign mail.dnssec. 300 IN RRSIG NSEC 13 2 300 20230401084359 20230302081006 35685 dnssec. QWpfnMgaVTitdgvpdIBTimLxJY+YUPcCvcQcVlnVta8FkmhSxgRhLkRs NGM9H1J5o+4K9uFwso3bSmLTADq1YA==
02-Mar-2023 09:10:06.332 add re-sign ns2.dnssec. 300 IN RRSIG NSEC 13 2 300 20230401084359 20230302081006 35685 dnssec. o/RJ6s2Jcccttnk2PxugOcjnyQ9kX9BfxEu5nKLZglAcaFAl7pnPjhNm 9455gOUH62iNPlxHS3KXrac8HuruIQ==
02-Mar-2023 09:10:06.332 add re-sign ns2.dnssec. 300 IN RRSIG A 13 2 300 20230401084359 20230302081006 35685 dnssec. E59RXGdRykOWp+Oad6UJ6DjIJDJT0vtX326pRcoW54obolq/sc2ZjCha GZk634z/MvcNFHWaQnF2rmtOj0SuGg==
02-Mar-2023 09:10:06.332 add re-sign dnssec. 300 IN RRSIG SOA 13 1 300 20230401091006 20230302081006 35685 dnssec. aSQQxKw8rg8Pbn6bacb22o993cEwzPXchCB9wQM4nLjMWq5VgW5JIQeG Tkz2VIWj9dPCQVRv4xKInZmBjHSwfg==
```
This results in the test detecting extra 9 signature operations which it doesn't expect and thus fails.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3906ThreadSanitizer: data race lib/dns/request.c:1020 in req_senddone (v9_18)2023-03-01T16:11:39ZArаm SаrgsyаnThreadSanitizer: data race lib/dns/request.c:1020 in req_senddone (v9_18)TSAN report during the `xferquota` system test on commit 6b7d2df6 (based on `9_18`): https://gitlab.isc.org/isc-projects/bind9/-/jobs/3201521
```
==================
WARNING: ThreadSanitizer: data race (pid=24022)
Read of size 4 at 0x7...TSAN report during the `xferquota` system test on commit 6b7d2df6 (based on `9_18`): https://gitlab.isc.org/isc-projects/bind9/-/jobs/3201521
```
==================
WARNING: ThreadSanitizer: data race (pid=24022)
Read of size 4 at 0x7b44000615a0 by thread T6:
#0 req_senddone /builds/isc-projects/bind9/lib/dns/request.c:1020 (libdns-9.18.13-dev.so+0x1814d3)
#1 send_done /builds/isc-projects/bind9/lib/dns/dispatch.c:2061 (libdns-9.18.13-dev.so+0x68967)
#2 isc__nm_async_sendcb netmgr/netmgr.c:2930 (libisc-9.18.13-dev.so+0x2967b)
#3 isc__nm_sendcb netmgr/netmgr.c:2906 (libisc-9.18.13-dev.so+0x298ec)
#4 udp_send_cb netmgr/udp.c:806 (libisc-9.18.13-dev.so+0x3f9ec)
#5 uv__udp_run_completed /usr/src/libuv-v1.44.1/src/unix/udp.c:155 (libuv.so.1+0x264f2)
#6 isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:189 (libisc-9.18.13-dev.so+0x80114)
Previous write of size 4 at 0x7b44000615a0 by thread T2 (mutexes: write M55023186806375632, write M56149086713218488):
#0 request_cancel /builds/isc-projects/bind9/lib/dns/request.c:889 (libdns-9.18.13-dev.so+0x181130)
#1 dns_request_cancel /builds/isc-projects/bind9/lib/dns/request.c:905 (libdns-9.18.13-dev.so+0x18191b)
#2 dns_requestmgr_shutdown /builds/isc-projects/bind9/lib/dns/request.c:230 (libdns-9.18.13-dev.so+0x181a9b)
#3 view_flushanddetach /builds/isc-projects/bind9/lib/dns/view.c:656 (libdns-9.18.13-dev.so+0x1ed89e)
#4 dns_view_detach /builds/isc-projects/bind9/lib/dns/view.c:716 (libdns-9.18.13-dev.so+0x1ed96f)
#5 ns_client_endrequest /builds/isc-projects/bind9/lib/ns/client.c:246 (libns-9.18.13-dev.so+0x13ceb)
#6 ns__client_reset_cb /builds/isc-projects/bind9/lib/ns/client.c:1621 (libns-9.18.13-dev.so+0x13ceb)
#7 nmhandle_detach_cb netmgr/netmgr.c:1851 (libisc-9.18.13-dev.so+0x279e5)
#8 isc__nm_async_detach netmgr/netmgr.c:2960 (libisc-9.18.13-dev.so+0x2ba57)
#9 process_netievent netmgr/netmgr.c:981 (libisc-9.18.13-dev.so+0x2ba57)
#10 process_queue netmgr/netmgr.c:1013 (libisc-9.18.13-dev.so+0x2bdce)
#11 process_all_queues netmgr/netmgr.c:767 (libisc-9.18.13-dev.so+0x2cb44)
#12 async_cb netmgr/netmgr.c:796 (libisc-9.18.13-dev.so+0x2cb44)
#13 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163 (libuv.so.1+0x1118e)
#14 isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:189 (libisc-9.18.13-dev.so+0x80114)
Location is heap block of size 280 at 0x7b4400061580 allocated by thread T6:
#0 malloc <null> (libtsan.so.2+0x3f618)
#1 mallocx /builds/isc-projects/bind9/lib/isc/jemalloc_shim.h:35 (libisc-9.18.13-dev.so+0x5d262)
#2 mem_get /builds/isc-projects/bind9/lib/isc/mem.c:343 (libisc-9.18.13-dev.so+0x5d262)
#3 isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:761 (libisc-9.18.13-dev.so+0x5dfea)
#4 new_request /builds/isc-projects/bind9/lib/dns/request.c:362 (libdns-9.18.13-dev.so+0x17e093)
#5 dns_request_create /builds/isc-projects/bind9/lib/dns/request.c:665 (libdns-9.18.13-dev.so+0x180749)
#6 notify_send_toaddr /builds/isc-projects/bind9/lib/dns/zone.c:12693 (libdns-9.18.13-dev.so+0x211206)
#7 task_run /builds/isc-projects/bind9/lib/isc/task.c:815 (libisc-9.18.13-dev.so+0x745c5)
#8 isc_task_run /builds/isc-projects/bind9/lib/isc/task.c:896 (libisc-9.18.13-dev.so+0x745c5)
#9 isc__nm_async_task netmgr/netmgr.c:848 (libisc-9.18.13-dev.so+0x1fdeb)
#10 process_netievent netmgr/netmgr.c:920 (libisc-9.18.13-dev.so+0x2b0fd)
#11 process_queue netmgr/netmgr.c:1013 (libisc-9.18.13-dev.so+0x2bdce)
#12 process_all_queues netmgr/netmgr.c:767 (libisc-9.18.13-dev.so+0x2cb44)
#13 async_cb netmgr/netmgr.c:796 (libisc-9.18.13-dev.so+0x2cb44)
#14 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163 (libuv.so.1+0x1118e)
#15 isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:189 (libisc-9.18.13-dev.so+0x80114)
Mutex M55023186806375632 is already destroyed.
Mutex M56149086713218488 is already destroyed.
Thread T6 'isc-net-0005' (tid=24096, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.2+0x5f0e6)
#1 isc_thread_create /builds/isc-projects/bind9/lib/isc/thread.c:73 (libisc-9.18.13-dev.so+0x76b3a)
#2 isc__netmgr_create netmgr/netmgr.c:311 (libisc-9.18.13-dev.so+0x20890)
#3 isc_managers_create /builds/isc-projects/bind9/lib/isc/managers.c:31 (libisc-9.18.13-dev.so+0x5c8f3)
#4 create_managers /builds/isc-projects/bind9/bin/named/main.c:1029 (named+0x427f86)
#5 setup /builds/isc-projects/bind9/bin/named/main.c:1293 (named+0x427f86)
#6 main /builds/isc-projects/bind9/bin/named/main.c:1562 (named+0x427f86)
Thread T2 'isc-net-0001' (tid=24073, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.2+0x5f0e6)
#1 isc_thread_create /builds/isc-projects/bind9/lib/isc/thread.c:73 (libisc-9.18.13-dev.so+0x76b3a)
#2 isc__netmgr_create netmgr/netmgr.c:311 (libisc-9.18.13-dev.so+0x20890)
#3 isc_managers_create /builds/isc-projects/bind9/lib/isc/managers.c:31 (libisc-9.18.13-dev.so+0x5c8f3)
#4 create_managers /builds/isc-projects/bind9/bin/named/main.c:1029 (named+0x427f86)
#5 setup /builds/isc-projects/bind9/bin/named/main.c:1293 (named+0x427f86)
#6 main /builds/isc-projects/bind9/bin/named/main.c:1562 (named+0x427f86)
SUMMARY: ThreadSanitizer: data race /builds/isc-projects/bind9/lib/dns/request.c:1020 in req_senddone
==================
ThreadSanitizer: reported 1 warnings
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3885"Loop detected resolving..." and different query-behavior after flushing a ca...2023-11-02T16:30:30ZThomas Amgarten"Loop detected resolving..." and different query-behavior after flushing a cache entry between BIND-9.19.10 and BIND-9.18.12### Summary
Regarding https://www.mail-archive.com/bind-users@lists.isc.org/msg33119.html, I fill this GL issue.
BIND-9.19.10 behaves differently to BIND-9.18.12 regarding AAAA-Lookups, when an entry (for example A record for "ns2.comt...### Summary
Regarding https://www.mail-archive.com/bind-users@lists.isc.org/msg33119.html, I fill this GL issue.
BIND-9.19.10 behaves differently to BIND-9.18.12 regarding AAAA-Lookups, when an entry (for example A record for "ns2.comtronic.ch") was cached and then succesfully flushed with ``rndc flushname ns2.comtronic.ch``.
BIND-9.19.10 then always...
- does A and AAAA lookups for the requested query (``dig @resolver ns2.comtronic.ch``)
- shows an INFO ``21-Feb-2023 09:23:15.463 resolver: info: loop detected resolving 'ns2.comtronic.ch/A'``
... where BIND-9.18.12 only sporadic shows the loop detected info and doesn't do AAAA lookups.
### BIND version used
#### 9.19.10
```
$ named -V
BIND 9.19.10 (Development Release) <id:789be8e>
running on Linux x86_64 4.18.0-305.10.2.el8_4.x86_64 #1 SMP Tue Jul 20 20:34:55 UTC 2021
built by make with '--prefix=/usr/local/bind-9.19.10' '--sysconfdir=/opt/chroot/bind/etc/named/' '--mandir=/usr/local/share/man' '--localstatedir=/opt/chroot/bind/var' '--enable-largefile' '--enable-full-report' '--without-gssapi' '--with-json-c' '--enable-singletrace' '--enable-dnstap' '--with-libxml2' 'PKG_CONFIG_PATH=/usr/local/fstrm/lib/pkgconfig/:/usr/local/h2o/lib64/pkgconfig'
compiled by GCC 8.4.1 20200928 (Red Hat 8.4.1-1)
compiled with OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
linked to OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
compiled with libuv version: 1.41.1
linked to libuv version: 1.41.1
compiled with libnghttp2 version: 1.33.0
linked to libnghttp2 version: 1.33.0
compiled with libxml2 version: 2.9.7
linked to libxml2 version: 20907
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
compiled with protobuf-c version: 1.3.0
linked to protobuf-c version: 1.3.0
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): no
default paths:
named configuration: /opt/chroot/bind/etc/named/named.conf
rndc configuration: /opt/chroot/bind/etc/named/rndc.conf
DNSSEC root key: /opt/chroot/bind/etc/named/bind.keys
nsupdate session key: /opt/chroot/bind/var/run/named/session.key
named PID file: /opt/chroot/bind/var/run/named/named.pid
named lock file: /opt/chroot/bind/var/run/named/named.lock
```
#### 9.18.12
```
$ named -V
BIND 9.18.12 (Extended Support Version) <id:99783f9>
running on Linux x86_64 4.18.0-305.10.2.el8_4.x86_64 #1 SMP Tue Jul 20 20:34:55 UTC 2021
built by make with '--prefix=/usr/local/bind-9.18.12' '--sysconfdir=/opt/chroot/bind/etc/named/' '--mandir=/usr/local/share/man' '--localstatedir=/opt/chroot/bind/var' '--enable-largefile' '--enable-full-report' '--without-gssapi' '--with-json-c' '--enable-singletrace' '--enable-dnstap' '--with-libxml2' 'PKG_CONFIG_PATH=/usr/local/fstrm/lib/pkgconfig/:/usr/local/h2o/lib64/pkgconfig'
compiled by GCC 8.4.1 20200928 (Red Hat 8.4.1-1)
compiled with OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
linked to OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
compiled with libuv version: 1.41.1
linked to libuv version: 1.41.1
compiled with libnghttp2 version: 1.33.0
linked to libnghttp2 version: 1.33.0
compiled with libxml2 version: 2.9.7
linked to libxml2 version: 20907
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
compiled with protobuf-c version: 1.3.0
linked to protobuf-c version: 1.3.0
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): no
default paths:
named configuration: /opt/chroot/bind/etc/named/named.conf
rndc configuration: /opt/chroot/bind/etc/named/rndc.conf
DNSSEC root key: /opt/chroot/bind/etc/named/bind.keys
nsupdate session key: /opt/chroot/bind/var/run/named/session.key
named PID file: /opt/chroot/bind/var/run/named/named.pid
named lock file: /opt/chroot/bind/var/run/named/named.lock
```
### Steps to reproduce
```
# Start named on the resolver
$ systemctl start named
```
```
# Query the record, which causes the behavior
$ dig @resolver ns2.comtronic.ch
; <<>> DiG 9.19.10 <<>> @resolver ns2.comtronic.ch
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22395
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 6a9803403ae47edc0100000063f4e59976baec2fb3207c4a (good)
;; QUESTION SECTION:
;ns2.comtronic.ch. IN A
;; ANSWER SECTION:
ns2.comtronic.ch. 60 IN A 195.200.242.162
;; Query time: 12 msec
;; SERVER: 10.100.102.21#53(resolver) (UDP)
;; WHEN: Tue Feb 21 16:39:05 CET 2023
;; MSG SIZE rcvd: 89
```
```
# Run "rndc flushname ns2.comtronic.ch"
$ rndc flushname ns2.comtronic.ch
```
```
# Query the resolver with the same query again
$ dig @resolver ns2.comtronic.ch
; <<>> DiG 9.19.10 <<>> @resolver ns2.comtronic.ch
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43078
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 70097c934a18c03c0100000063f4e6a0cc14b1551adc474c (good)
;; QUESTION SECTION:
;ns2.comtronic.ch. IN A
;; ANSWER SECTION:
ns2.comtronic.ch. 60 IN A 195.200.242.162
;; Query time: 8 msec
;; SERVER: 10.100.102.21#53(resolver) (UDP)
;; WHEN: Tue Feb 21 16:43:28 CET 2023
;; MSG SIZE rcvd: 89
```
```
# On the resolver check the named.log for "loop detected"
21-Feb-2023 16:43:28.238 resolver: info: loop detected resolving 'ns2.comtronic.ch/A'
```
```
# On the resolver sniff dns traffic, which always shows A and AAAA lookups
16:43:28.239336 IP 10.100.2.62.43415 > 10.100.102.21.53: 43078+ [1au] A? ns2.comtronic.ch. (57)
16:43:28.240559 IP6 2001:db8::affe.44411 > 2603:1020:a01:2::34.53: 11540 [1au] A? ns2.comtronic.ch. (45)
16:43:28.240885 IP6 2001:db8::affe.33227 > 2001:67c:1010:2::53.53: 46123% [1au] AAAA? ns2.comtronic.ch. (45)
16:43:28.240984 IP6 2001:db8::affe.29014 > 2001:67c:1010:2::53.53: 50359% [1au] A? ns2.comtronic.ch. (45)
16:43:28.243680 IP6 2603:1020:a01:2::34.53 > 2001:db8::affe.44411: 11540*- 1/0/1 A 195.200.242.162 (61)
16:43:28.243951 IP 10.100.102.21.53 > 10.100.2.62.43415: 43078 1/0/1 A 195.200.242.162 (89)
16:43:28.246959 IP6 2001:67c:1010:2::53.53 > 2001:db8::affe.33227: 46123- 0/10/10 (695)
16:43:28.247176 IP6 2001:67c:1010:2::53.53 > 2001:db8::affe.29014: 50359- 0/10/10 (695)
16:43:28.247420 IP6 2001:db8::affe.36611 > 2a02:1368:1:47::53.53: 1441% [1au] AAAA? ns2.comtronic.ch. (45)
16:43:28.247515 IP6 2001:db8::affe.6551 > 2a02:1368:1:47::53.53: 45763% [1au] A? ns2.comtronic.ch. (45)
16:43:28.248042 IP6 2a02:1368:1:47::53.53 > 2001:db8::affe.36611: 1441*- 0/1/1 (96)
16:43:28.248080 IP6 2a02:1368:1:47::53.53 > 2001:db8::affe.6551: 45763*- 1/0/1 A 195.200.242.162 (61)
```
### What is the current *bug* behavior?
Regarding https://www.mail-archive.com/bind-users@lists.isc.org/msg33119.html it's not clear,
- what "loop detected resolving 'ns2.comtronic.ch/A' means here?
- why "loop detected resolving 'ns2.comtronic.ch/A'" always is reproducable in BIND-9.19.10 and sporadic in BIND-9.18.12?
- why BIND-9.19.10 behaves differently to BIND-9.18.12 regarding AAAA lookups after flushing the name "ns2.comtronic.ch"?
A ``tcpdump`` from BIND-9.18.12 shows the following traffic (excerpt from my mailing-list- question):
```
# Query from the client
09:36:34.242064 IP 10.100.2.62.59765 > 10.100.102.21.53: 58600+ [1au] A? ns2.comtronic.ch. (57)
# Query from the resolver to the authoritative
09:36:34.242787 IP6 2001:db8::affe.4717 > 2a02:1368:1:48::53.53: 26321 [1au] A? ns2.comtronic.ch. (45)
# Query from the resolver to the TLD server
09:36:34.242880 IP6 2001:db8::affe.25272 > 2001:620:0:ff::56.53: 50695% [1au] A? ns2.comtronic.ch. (45)
# Response back from the authoritative server
09:36:34.243673 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.4717: 26321*- 1/0/1 A 195.200.242.162 (61)
# Response back to the client
09:36:34.243841 IP 10.100.102.21.53 > 10.100.2.62.59765: 58600 1/0/1 A 195.200.242.162 (89)
# Delegation answer from the TLD server
09:36:34.244556 IP6 2001:620:0:ff::56.53 > 2001:db8::affe.25272: 50695- 0/10/10 (695)
# A 2nd query to the same authoritative
09:36:34.244750 IP6 2001:db8::affe.18083 > 2a02:1368:1:48::53.53: 21395% [1au] A? ns2.comtronic.ch. (45)
# 2nd response back from the authoritative server
09:36:34.245246 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.18083: 21395*- 1/0/1 A 195.200.242.162 (61)
```
### What is the expected *correct* behavior?
I'm not sure, which behavior is the correct one, 9.19.10 or 9.18.12.
### Relevant configuration files
--
### Relevant logs and/or screenshots
--
### Possible fixes
--Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3878Missing and undocumented statistics from the HTTP stats channel in the ARM2023-11-02T16:30:30ZPieter LexisMissing and undocumented statistics from the HTTP stats channel in the ARMHi folks,
I'm implementing a new monitoring solution and adding a bunch of stats from the HTTP-based stats channel to said monitoring solution. I'm basing the descriptions on what I can find in the ARM section 8.5 (I'm using the one fro...Hi folks,
I'm implementing a new monitoring solution and adding a bunch of stats from the HTTP-based stats channel to said monitoring solution. I'm basing the descriptions on what I can find in the ARM section 8.5 (I'm using the one from 9.18 and 9.19), but some stats are missing there. Some of them are self-evident based on the name, but some are not. I've compiled a list here, the naming is based on the JSON from the webserver:
* nsstats.TCPConnHighWater
* nsstats.SynthNXDOMAIN
* nsstats.CookieNew
* nsstats.CookieIn
* in view.NAME.resolver.stats
* BucketSize
* ClientCookieOut
* ServerCookieOut
* CookieIn
* CookieClientOk
* BadCookieRcode
* NextItem
* Priming
* traffic
The following stats are mostly unclear:
* view.NAME.resolver.cachestats - none of these statistics are described
* view.NAME.resolver.adb - none of these statistics are described
* opcodes.CODE - Are these the counts of received opcodes from clients?
* rcodes.CODE - Are these the counts of rcodes sent to clients?
* qtypes.CODE - Are these the counts of qtypes that were queried by clients?
* view.NAME.resolver.qtypes - what do these numbers mean?
* view.NAME.resolver.cache - Are the current cache entries for these types?
Cheers,
PieterNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3813Duplicate key IDs across algorithms are not handled correctly.2023-09-11T16:19:33ZMark AndrewsDuplicate key IDs across algorithms are not handled correctly.Job [#3089156](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3089156) failed for e706fb81ca2f46f893bc96216544b73a16022884:
```
I:nsec3:check number of keys for zone nsec3-to-rsasha1.kasp in dir ns3 (103)
I:nsec3:check key id 08113
I:...Job [#3089156](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3089156) failed for e706fb81ca2f46f893bc96216544b73a16022884:
```
I:nsec3:check number of keys for zone nsec3-to-rsasha1.kasp in dir ns3 (103)
I:nsec3:check key id 08113
I:nsec3:check key id 08113
I:nsec3:KEY1 ID 8113
I:nsec3:KEY2 ID 8113
I:nsec3:error: bad DNSKEY RRset for zone nsec3-to-rsasha1.kasp
I:nsec3:failed
```
```
% ls ns3/*nsec3-to-rsasha1.kasp*
ns3/Knsec3-to-rsasha1.kasp.+005+08113.key ns3/Knsec3-to-rsasha1.kasp.+013+08113.private ns3/nsec3-to-rsasha1.kasp.db.signed
ns3/Knsec3-to-rsasha1.kasp.+005+08113.private ns3/Knsec3-to-rsasha1.kasp.+013+08113.state ns3/nsec3-to-rsasha1.kasp.db.signed.jnl
ns3/Knsec3-to-rsasha1.kasp.+005+08113.state ns3/nsec3-to-rsasha1.kasp.db
ns3/Knsec3-to-rsasha1.kasp.+013+08113.key ns3/nsec3-to-rsasha1.kasp.db.jbk
%
```
```
% more *103
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50279
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: b4e1d78c34d15ba70100000063c9e02dac6c36fa7c841c69 (good)
;; QUESTION SECTION:
;nsec3-to-rsasha1.kasp. IN DNSKEY
;; ANSWER SECTION:
nsec3-to-rsasha1.kasp. 3600 IN DNSKEY 257 3 5 AwEAAawagVzMn34eS6HLSz9abmIkj9l1migiobJkbGX2CoDqh+xaQ5mI UIPmS6AUMqKEsPL5hH0YWkD4qRKLe9HtC8e73mqpZBYmd5KhEsvPPSaB Za17TRTlTSpfJpE3XTL5LCUIxDBpgfz/NNLNChIMTLM4hKLnVoWhvz13 3Q9Xvma+wpb7l1OZVEf0kDxapvJo2Hug941E7OxNuGI8h0QmE5XA9Pxj c+BpIbx01U5iwKK47q0Zh57El7E86wxgzw+hBdE0sK/tJPFFA0WwvPl8 zY/MzyNunDiOUG9PdmB2hWszDAVzlUXheHv4/Glf/bK8JTYBeuA8zxe7 i8OlSwvST60=
nsec3-to-rsasha1.kasp. 3600 IN RRSIG DNSKEY 5 2 3600 20230203002817 20230119232817 8113 nsec3-to-rsasha1.kasp. DhIH5wi/8VCZ3WEr+R4B1NGvOD7U1UKUZQPQCg+xWAxmldsNAMhCdvTu eJpg4WryFyrmlZcbfzHEMv29tqpUMn+azZORdjX9VI0unBzElwfIAdn1 6Dapbq8n4CuBm3CsDM5plxVj/EUnJET/PKacyimC8CfuwqRlxDoxesuF ohY2Xt01NUqHp9ETrOJkPdd+hiL45j1YcrPYPWCpCFrpHVhMbnOpXajq UqQw5WgH0P2O/vPEwaqSVjgUtdQqguv/ebQAZ4C7N7zxQa9gv+Y7YEJa OJl0IMmmJt4FMuqAytvdSsZjz1QslYWXCkiAEVIxmsd2x7kDB44s6ml/ yApNxw==
%
```Not plannedMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3812You can't just destroy created managers2023-02-28T14:24:43ZMark AndrewsYou can't just destroy created managersThe following sequence fails which makes error handling difficult.
```
isc_managers_create(&mctx, isc_os_ncpus(), &loopmgr, &netmgr, &taskmgr);
isc_managers_destroy(&mctx, &loopmgr, &netmgr, &taskmgr);
```The following sequence fails which makes error handling difficult.
```
isc_managers_create(&mctx, isc_os_ncpus(), &loopmgr, &netmgr, &taskmgr);
isc_managers_destroy(&mctx, &loopmgr, &netmgr, &taskmgr);
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3811Lock contention in the RBTDB2023-11-02T17:03:41ZOndřej SurýLock contention in the RBTDB@pspacek discovered a lock contention of the RBTDB nodelocks in the `rdataset_getownercase()` and `decrement_reference()` functions.@pspacek discovered a lock contention of the RBTDB nodelocks in the `rdataset_getownercase()` and `decrement_reference()` functions.Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3810Replace system test runner with pytest2024-02-29T15:26:01ZTom KrizekReplace system test runner with pytestThe legacy solution for running systems test has evolved over the course of years and is currently a mix of shell & perl scripts intermingled with the build system, while some of the system tests utilize pytest. Implementing a more consi...The legacy solution for running systems test has evolved over the course of years and is currently a mix of shell & perl scripts intermingled with the build system, while some of the system tests utilize pytest. Implementing a more consistent solution using just pytest as a runner could bring following benefits:
- better test run isolation (i.e. artifacts from previous run don't interfere with current test run)
- more precise control over test selection (running just a single test case)
- getting rid of perl+shell glue scripts
- a simpler and more standard way to run and parallelize test runs
- solid foundation for future extensions (e.g. wrapping test execution inside a network/pid namespace)
For a transitory period of time, the legacy test framework should be supported, since it'd be difficult to replace everything at once. The pytest runner should be available in 9.18+, it'd be prudent to keep the legacy runner support until 9.16 reaches EOL. By that time, we should have enough insight to determine whether pytest proves to be a suitable replacement and throw away the legacy runner from supported branches at that point.
Migration plan for moving to pytest runner and dropping the legacy runner support:
- Phase I - pytest runner development, legacy runner supported
- [x] initial implementation of the pytest runner (#3978, !6809)
- [x] support out-of-tree tests (#4246)
- [x] resolve support on CI systems with old pytest (OpenBSD, CentOS 7) (!8193)
- [x] implement any missing (and desired) features from legacy runner (#4252)
- [x] configure `make check` to invoke pytest (#4262)
- Phase II - deprecating legacy runner - 9.19-only
- [ ] remove legacy runner control script(s) - legacy.run.sh, get_ports.sh ...
- [ ] remove no longer needed scripts from system tests (e.g. clean.sh)
- [ ] remove conf.sh(.common) and declare variables in pytest only
- [ ] remove the Makefile entanglement
- [ ] declare python and pytest-xdist as required dependencies for tests + document
- [ ] address any `FUTURE` comments in the pytest runner code
- Phase III - cleanup after legacy runner
- [ ] rewrite start.pl/stop.pl to python (related https://gitlab.isc.org/isc-projects/bind9/-/issues/3198)
- [ ] rewrite remaining setup/teardown perl&shell scripts to python
- [ ] rewrite setup.sh/prereq.sh system tests scripts to pytest fixtures
- [ ] ensure system test documentation is up to dateBIND 9.19.xTom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3809zones deleted during asyncload are never freed2023-01-18T16:02:17ZOndřej Surýzones deleted during asyncload are never freedZones that are deleted during the asyncload go into spiral:
```
dns_zone_create:::0:0x7f4c0b3c4e00->irefs = 0
zone_iattach:asyncload:zt.c:370:0x7f4c0b3c4e00->irefs = 2
dns_zone__idetach:zone_asyncload:zone.c:2423:0x7f4c0b3c4e00->irefs =...Zones that are deleted during the asyncload go into spiral:
```
dns_zone_create:::0:0x7f4c0b3c4e00->irefs = 0
zone_iattach:asyncload:zt.c:370:0x7f4c0b3c4e00->irefs = 2
dns_zone__idetach:zone_asyncload:zone.c:2423:0x7f4c0b3c4e00->irefs = 1
[...13k...]
zone_iattach:asyncload:zt.c:370:0x7f4c0b3c4e00->irefs = 2
dns_zone__idetach:zone_asyncload:zone.c:2423:0x7f4c0b3c4e00->irefs = 1
[...continues...]
```https://gitlab.isc.org/isc-projects/bind9/-/issues/3794Dispatch code intermittently reports "response doesn't match" during the "rec...2023-02-23T10:23:56ZMichał KępieńDispatch code intermittently reports "response doesn't match" during the "reclimit" system testhttps://gitlab.isc.org/isc-private/bind9/-/jobs/3068391
```
S:reclimit:2023-01-13T13:29:59+0000
T:reclimit:1:A
A:reclimit:System test reclimit
I:reclimit:PORTS:12586,12587,12588,12589,12590,12591,12592,12593,12594,12595,12596,12597,1259...https://gitlab.isc.org/isc-private/bind9/-/jobs/3068391
```
S:reclimit:2023-01-13T13:29:59+0000
T:reclimit:1:A
A:reclimit:System test reclimit
I:reclimit:PORTS:12586,12587,12588,12589,12590,12591,12592,12593,12594,12595,12596,12597,12598
I:reclimit:starting servers
I:reclimit:set max-recursion-depth=12
I:reclimit:attempt excessive-depth lookup (1)
I:reclimit:attempt permissible lookup (2)
I:reclimit:set max-recursion-depth=5
I:reclimit:attempt excessive-depth lookup (3)
I:reclimit:attempt permissible lookup (4)
I:reclimit:set max-recursion-depth=100, max-recursion-queries=50
I:reclimit:attempt excessive-queries lookup (5)
I:reclimit:attempt permissible lookup (6)
I:reclimit:failed
I:reclimit:set max-recursion-depth=100, max-recursion-queries=40
I:reclimit:attempt excessive-queries lookup (7)
I:reclimit:attempt permissible lookup (8)
I:reclimit:attempting NS explosion (9)
I:reclimit:exit status: 1
I:reclimit:stopping servers
R:reclimit:FAIL
E:reclimit:2023-01-13T13:30:05+0000
```
The reason for the test failure is that one of the "intermediate"
queries sent by `ns3` to `ans4` (`ns1.1.example.org/A`) got a response
that the dispatch code did not like, necessitating a requery, which in
turn caused the `max-recursion-queries` limit to be exceeded for the
`indirect6.example.org/A` query, causing the test to fail.
The interesting part is *why* the dispatch code did not like the
response that the `ans4` "server" sent. Here are the relevant log
excerpts:
```
13-Jan-2023 13:30:02.298 sending packet to 10.53.0.4#12586
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57016
;; flags:; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;ns1.1.example.org. IN A
13-Jan-2023 13:30:02.298 dispatch 0x7f55202f6400: UDP response 0x7f5508de0800: sending
13-Jan-2023 13:30:02.298 dispatch 0x7f55202b8600: UDP response 0x7f5508ce4a00: connected: success
13-Jan-2023 13:30:02.298 dispatch 0x7f55202b8600: UDP response 0x7f5508ce4a00: attaching handle 0x7f5508a05980 to 0x7f5508ce4a18
13-Jan-2023 13:30:02.298 dispatch 0x7f55202b8600: UDP response 0x7f5508ce4a00: reading
13-Jan-2023 13:30:02.298 dispatch 0x7f55202b8600: UDP response 0x7f5508ce4a00: connect callback: success
13-Jan-2023 13:30:02.298 sending packet to 10.53.0.4#12586
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56518
;; flags:; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;ns1.1.example.org. IN AAAA
13-Jan-2023 13:30:02.298 dispatch 0x7f55202b8600: UDP response 0x7f5508ce4a00: sending
13-Jan-2023 13:30:02.298 dispatch 0x7f55202f6400: UDP response 0x7f5508de0800: sent: success
13-Jan-2023 13:30:02.298 dispatch 0x7f55202b8600: UDP response 0x7f5508ce4a00: sent: success
13-Jan-2023 13:30:02.298 dispatch 0x7f55202b8600: UDP response 0x7f5508ce4a00: read callback:success, requests 1
13-Jan-2023 13:30:02.298 dispatch 0x7f55202b8600: UDP response 0x7f5508ce4a00: got valid DNS message header, /QR 1, id 57016
13-Jan-2023 13:30:02.298 dispatch 0x7f55202b8600: UDP response 0x7f5508ce4a00: response doesn't match
13-Jan-2023 13:30:02.298 dispatch 0x7f55202b8600: UDP response 0x7f5508ce4a00: continue reading
```
The relevant piece of code is:
```c
594 /*
595 * The QID and the address must match the expected ones.
596 */
597 if (resp->id != id || !isc_sockaddr_equal(&peer, &resp->peer)) {
598 dispentry_log(resp, LVL(90), "response doesn't match");
599 inc_stats(disp->mgr, dns_resstatscounter_mismatch);
600 goto next;
601 }
```
Given the `got valid DNS message header` log message with the expected
ID, it seems that `isc_sockaddr_equal(&peer, &resp->peer)` must have
returned `false`. I do not know why that happened because I do not have
a PCAP file containing the traffic exchanged between the servers in
question.
This only happens intermittently, so for now I am merely opening this
issue to record it and make others aware of it. My gut feeling is that
there is no way to figure out what happened here without a PCAP file or
improved dispatch debugging, but I would love to be proved wrong :-)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3775update-policy documentation confuses2023-01-09T11:29:01ZTimothe Littupdate-policy documentation confusesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3763rndc documentation misses a feature; rndc-confgen still uses md52023-01-05T21:28:34ZTimothe Littrndc documentation misses a feature; rndc-confgen still uses md5The code is (mostly) willing, but the documentation is weak :-(
I finally noticed that the rndc [documentation](https://bind9.readthedocs.io/en/v9_18_10/manpages.html#rndc-conf-rndc-configuration-file) describes rndc.conf as
> "has a si...The code is (mostly) willing, but the documentation is weak :-(
I finally noticed that the rndc [documentation](https://bind9.readthedocs.io/en/v9_18_10/manpages.html#rndc-conf-rndc-configuration-file) describes rndc.conf as
> "has a similar structure and syntax to `named.conf`".
This is true, but omits a valuable feature:
`include` works in `rndc.conf`.
It turns out that this is useful if you ever need (or want) to rotate keys, since a (suitably protected) .key file can be `include`d in `rndc.conf` and likewise `include`d in `named.conf`.
In any case, this structure avoids duplication of the secret key; makes updating the key simpler, and allows `rndc.conf` to have read permissions - thus making the `options` clause visible, which may be desirable. It also means that if you use unique keys for more than one `named` instance, you can simply move the key file to your management stations, but retain the default-server without editing each station's `rndc.conf`.
For example:
```sh
named.conf
# Define the rndc control key
include "rndc.key";
cat >/etc/named/rndc.conf
include "rndc.key";
options {
default-server: 2001:0db8::53;
default-port: 953;
};
# Now, updating and initial key creation becomes simply:
touch /etc/named/rndc.key
chmod 600 /etc/named/rndc.key
tsig-keygen -a sha256 rndc-key >/etc/named/rndc.key
rndc reconfig
```
No more copying the `key` clause into both files, or including in `named.conf` but copying into `rndc.conf`.
For extra credit - `rndc-confgen` should probably produce this structure, since it's better than the current suggestions.
`rndc-confgen` should definitely be updated to default to SHA256 rather than MD5, since MD5 is deprecated and the documentation says (under the `key` statment) that SHA256 is now the default...
Happy New Year.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3699Hang on shutdown in the "tcp" system test2023-08-07T09:16:17ZMichał KępieńHang on shutdown in the "tcp" system testThe `tcp` system test fails fairly often as it puts quite a bit of
strain on the test host, so this [job][1] might not *have* to be a hang,
but the backtrace seems to be a match:
```
D:tcp:#0 0x00007f1ce8f765be in pthread_barrier_wait ...The `tcp` system test fails fairly often as it puts quite a bit of
strain on the test host, so this [job][1] might not *have* to be a hang,
but the backtrace seems to be a match:
```
D:tcp:#0 0x00007f1ce8f765be in pthread_barrier_wait () from /lib64/libpthread.so.0
D:tcp:[Current thread is 1 (Thread 0x7f1cecac22c0 (LWP 22507))]
D:tcp:#0 0x00007f1ce8f765be in pthread_barrier_wait () from /lib64/libpthread.so.0
D:tcp:#1 0x00007f1cea0aca7d in uv_barrier_wait () from /lib64/libuv.so.1
D:tcp:#2 0x00007f1cec14c414 in isc__nm_async_tcpdnsstop (worker=worker@entry=0x7f1ce5276000, ev0=ev0@entry=0x7f1ce4b7d800) at netmgr/tcpdns.c:670
D:tcp:#3 0x00007f1cec146a92 in process_netievent (arg=0x7f1ce4b7d800) at netmgr/netmgr.c:463
D:tcp:#4 0x00007f1cec146db3 in isc__nm_process_ievent (worker=<optimized out>, event=<optimized out>) at netmgr/netmgr.c:567
D:tcp:#5 0x00007f1cec14b585 in stop_tcpdns_child (sock=sock@entry=0x7f1ce53eac00, tid=tid@entry=0) at netmgr/tcpdns.c:605
D:tcp:#6 0x00007f1cec14bed4 in isc__nm_tcpdns_stoplistening (sock=0x7f1ce53eac00) at netmgr/tcpdns.c:632
D:tcp:#7 0x00007f1cec143356 in isc_nm_stoplistening (sock=<optimized out>) at netmgr/netmgr.c:2091
D:tcp:#8 0x00007f1cebae0559 in ns_interface_shutdown (ifp=ifp@entry=0x7f1ce528a500) at interfacemgr.c:742
D:tcp:#9 0x00007f1cebae08d9 in purge_old_interfaces (mgr=mgr@entry=0x7f1ce53d3460) at interfacemgr.c:828
D:tcp:#10 0x00007f1cebae0b8b in ns_interfacemgr_shutdown (mgr=0x7f1ce53d3460) at interfacemgr.c:447
D:tcp:#11 0x000000000044288a in shutdown_server (task=<optimized out>, event=<optimized out>) at server.c:10124
D:tcp:#12 0x00007f1cec178944 in task_run (task=<optimized out>, task@entry=0x7f1ce5225e80) at task.c:470
D:tcp:#13 0x00007f1cec178a85 in task__run (arg=0x7f1ce5225e80) at task.c:287
D:tcp:#14 0x00007f1cec160bf4 in isc__job_cb (idle=0x7f1ce52236c8) at job.c:75
D:tcp:#15 0x00007f1cea0a6a49 in uv.run_idle () from /lib64/libuv.so.1
D:tcp:#16 0x00007f1cea09fbf8 in uv_run () from /lib64/libuv.so.1
D:tcp:#17 0x00007f1cec166d31 in loop_run (loop=0x7f1ce52a1e40) at loop.c:270
D:tcp:#18 loop_thread (arg=0x7f1ce52a1e40) at loop.c:297
D:tcp:#19 0x00007f1cec167dd3 in isc_loopmgr_run (loopmgr=0x7f1ce5223540) at loop.c:477
D:tcp:#20 0x00000000004238e0 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1545
```
I do not recall seeing this particular backtrace before, so I assumed it
makes sense to at least retain job artifacts and have this problem
catalogued as a GitLab issue.
Perhaps a total red herring, but `isc__nm_async_tcpdnsstop()` is also
present in the backtrace for one of the threads in a failed unit test
job reported [elsewhere][2], which also happened on Oracle Linux 8.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2935216
[2]: https://gitlab.isc.org/isc-projects/bind9/-/issues/3642Not planned