BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2022-03-21T14:37:51Zhttps://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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/3027Move setting of @SO@ to copy_setports2022-03-01T09:43:31ZMark AndrewsMove setting of @SO@ to copy_setportsSetting @SO@ in conf files is currently done by configure. copy_setports should be capable of doing this.Setting @SO@ in conf files is currently done by configure. copy_setports should be capable of doing this.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3015QNAME minimization test fails as non-minimized request is served from cache2022-03-01T09:38:59ZWil KnollQNAME minimization test fails as non-minimized request is served from cache### Summary
When using default configuration for BIND the QNAME minimization test hosted at internet.nl would fail randomly after four or more iterations. It appears that the fourth request in a row is served the proper minimized reques...### Summary
When using default configuration for BIND the QNAME minimization test hosted at internet.nl would fail randomly after four or more iterations. It appears that the fourth request in a row is served the proper minimized request cached previously, but triggers a fetch at the same time which is not minimized. The response to that request is then served to the following fifth request and beyond.
```
17-Nov-2021 06:17:13.568 client @0x7fef808ae838 127.0.0.1#35491 (qnamemintest.internet.nl): query: qnamemintest.internet.nl IN TXT + (127.0.0.1)
17-Nov-2021 06:17:13.568 client @0x7fef808ae838 127.0.0.1#35491 (qnamemintest.internet.nl): query (cache) 'qnamemintest.internet.nl/TXT/IN' approved
17-Nov-2021 06:17:13.568 fetch: a.b.qnamemin-test.internet.nl/TXT
17-Nov-2021 06:17:13.568 log_ns_ttl: fctx 0x7fef80044e60: fctx_create: a.b.qnamemin-test.internet.nl (in 'internet.nl'?): 1 3587
17-Nov-2021 06:17:13.568 QNAME minimization - not minimized, qmintype 16 qminname a.b.qnamemin-test.internet.nl
```
### BIND version used
BIND 9.16.22-Ubuntu (Extended Support Version) <id:59bfaba>
### Steps to reproduce
We ran the following bash commands and this behaviour would occur sometimes after four of five iterations, other times after a dozen or more. We echo'ed the `date` command into the log as well to line up events.
```
for i in {1..30};
do date +"%T.%6N";
echo "Test Number " $i;
echo "========== Before test" $i >> /var/log/named/default.log;
kdig +nodnssec +short @127.0.0.1 qnamemintest.internet.nl TXT;
date +"%T.%6N";
echo "======== done test" $i >> /var/log/named/default.log;
echo "Test Number " $i "done, sleeping.";
sleep 3;
done
```
### What is the current *bug* behavior?
Here the test fails on the fifth iteration
```
06:16:57.072993
Test Number 1
;; WARNING: response timeout for 127.0.0.1@53(UDP)
a.b.qnamemin-test.internet.nl.
"HOORAY - QNAME minimisation is enabled on your resolver :)!"
06:17:04.540956
Test Number 1 done, sleeping.
06:17:07.545660
Test Number 2
a.b.qnamemin-test.internet.nl.
"HOORAY - QNAME minimisation is enabled on your resolver :)!"
06:17:07.551628
Test Number 2 done, sleeping.
06:17:10.556281
Test Number 3
a.b.qnamemin-test.internet.nl.
"HOORAY - QNAME minimisation is enabled on your resolver :)!"
06:17:10.562749
Test Number 3 done, sleeping.
06:17:13.567638
Test Number 4
a.b.qnamemin-test.internet.nl.
"HOORAY - QNAME minimisation is enabled on your resolver :)!"
06:17:13.574423
Test Number 4 done, sleeping.
06:17:16.578864
Test Number 5
a.b.qnamemin-test.internet.nl.
"NO - QNAME minimisation is NOT enabled on your resolver :("
06:17:16.584539
Test Number 5 done, sleeping.
06:17:19.588370
Test Number 6
a.b.qnamemin-test.internet.nl.
"NO - QNAME minimisation is NOT enabled on your resolver :("
06:17:19.594741
Test Number 6 done, sleeping.
```
Part of the internet.nl test is to serve a different TXT record based on the delegation path for their records. If you do not follow QNAME minimization to spec, you will miss a delegation and be served a different record than if you had walked the whole way down from the top. In this case, we are served the failure message.
In the debug below, we see that the fourth test is served from cache while a new fetch of the TXT is started and not minimized. That response arrives after the fourth request has been served and before the fifth. The fifth is then sent the non-minimized response.
```
========== Before test 4
17-Nov-2021 06:17:13.568 clientmgr @0x7fef8ee53190 attach: 4
17-Nov-2021 06:17:13.568 client @0x7fef808ae838 (no-peer): allocate new client
17-Nov-2021 06:17:13.568 client @0x7fef808ae838 127.0.0.1#35491: UDP request
17-Nov-2021 06:17:13.568 client @0x7fef808ae838 127.0.0.1#35491: using view '_default'
17-Nov-2021 06:17:13.568 client @0x7fef808ae838 127.0.0.1#35491: request is not signed
17-Nov-2021 06:17:13.568 client @0x7fef808ae838 127.0.0.1#35491: recursion available
17-Nov-2021 06:17:13.568 client @0x7fef808ae838 127.0.0.1#35491 (qnamemintest.internet.nl): query: qnamemintest.internet.nl IN TXT + (127.0.0.1)
17-Nov-2021 06:17:13.568 client @0x7fef808ae838 127.0.0.1#35491 (qnamemintest.internet.nl): query (cache) 'qnamemintest.internet.nl/TXT/IN' approved
17-Nov-2021 06:17:13.568 fetch: a.b.qnamemin-test.internet.nl/TXT
17-Nov-2021 06:17:13.568 log_ns_ttl: fctx 0x7fef80044e60: fctx_create: a.b.qnamemin-test.internet.nl (in 'internet.nl'?): 1 3587
17-Nov-2021 06:17:13.568 QNAME minimization - not minimized, qmintype 16 qminname a.b.qnamemin-test.internet.nl
17-Nov-2021 06:17:13.568 expiring v4 for name 0x7fef8432c600
17-Nov-2021 06:17:13.568 expire_v4 set to MIN(2147483647,1637129843) import_rdataset
17-Nov-2021 06:17:13.568 dns_adb_createfind: found A for name ns1.sidnlabs.nl (0x7fef8432c600) in db
17-Nov-2021 06:17:13.568 fctx 0x7fef80044e60(a.b.qnamemin-test.internet.nl/TXT): createfind for 127.0.0.1#35491/54667 - success
17-Nov-2021 06:17:13.568 expiring v4 for name 0x7fef8432c4d0
17-Nov-2021 06:17:13.568 expire_v4 set to MIN(2147483647,1637129843) import_rdataset
17-Nov-2021 06:17:13.568 dns_adb_createfind: found A for name ns3.sidn.nl (0x7fef8432c4d0) in db
17-Nov-2021 06:17:13.568 fctx 0x7fef80044e60(a.b.qnamemin-test.internet.nl/TXT): createfind for 127.0.0.1#35491/54667 - success
17-Nov-2021 06:17:13.568 socket 0x7fef8419c178: socket_recv: event 0x7fef8419f160 -> task 0x7fef84914550
17-Nov-2021 06:17:13.568 sending packet to 94.198.159.8#53
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15820
;; flags:; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 6e57d9bce860fbf50100000061949e5c594abc51bbb6293a
;; QUESTION SECTION:
;a.b.qnamemin-test.internet.nl. IN TXT
======== done test 4
17-Nov-2021 06:17:13.844 socket 0x7fef8419c178: socket_recv: event 0x7fef8419f010 -> task 0x7fef84914550
17-Nov-2021 06:17:13.844 received packet from 94.198.159.8#53
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15820
;; flags: qr; QUESTION: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 6e57d9bce860fbf50100000061949e69a15a47ca6fecf4ce
;; QUESTION SECTION:
;a.b.qnamemin-test.internet.nl. IN TXT
;; AUTHORITY SECTION:
;qnamemin-test.internet.nl. 10 IN NS ns.qnamemin-test.internet.nl.
;37EVSMIUKP9K7OAANU0THSBL3AFJAJJI.internet.nl. 300 IN NSEC3 1 0 0 - (
; 3UK0OFP95GPMB6AJ2O611UGNO7EJ4O6U
; NS )
;37EVSMIUKP9K7OAANU0THSBL3AFJAJJI.internet.nl. 300 IN RRSIG NSEC3 13 3 300 (
; 20211212072148 20211112065813 16313 internet.nl.
; E/vfuxroRZjeupIxjp+s3aQpKPb0
; fYR3UjTMs3yoHhF66kz/wvPyuwvY
; 9vlHJ1UmifUBfmyAtZj560mQ0loV
; MQ== )
;; ADDITIONAL SECTION:
;ns.qnamemin-test.internet.nl. 10 IN A 185.49.140.61
;ns.qnamemin-test.internet.nl. 10 IN AAAA 2a04:b900::8:0:0:61
17-Nov-2021 06:17:13.844 log_ns_ttl: fctx 0x7fef80044e60: rctx_answer_none: a.b.qnamemin-test.internet.nl (in 'internet.nl'?): 1 3587
17-Nov-2021 06:17:13.844 QNAME minimization - not minimized, qmintype 16 qminname a.b.qnamemin-test.internet.nl
17-Nov-2021 06:17:13.844 log_ns_ttl: fctx 0x7fef80044e60: DELEGATION: a.b.qnamemin-test.internet.nl (in 'qnamemin-test.internet.nl'?): 0 3587
17-Nov-2021 06:17:13.844 dns_adb_destroyfind on find 0x7fef84329d10
17-Nov-2021 06:17:13.844 dns_adb_destroyfind on find 0x7fef84327e10
17-Nov-2021 06:17:13.844 expiring v4 for name 0x7fef8432c3a0
17-Nov-2021 06:17:13.844 expire_v4 set to MIN(2147483647,1637129843) import_rdataset
17-Nov-2021 06:17:13.844 dns_adb_createfind: found A for name ns.qnamemin-test.internet.nl (0x7fef8432c3a0) in db
17-Nov-2021 06:17:13.844 fctx 0x7fef80044e60(a.b.qnamemin-test.internet.nl/TXT): createfind for 127.0.0.1#35491/54667 - success
17-Nov-2021 06:17:13.844 socket 0x7fef8419c010: socket_recv: event 0x7fef841a0550 -> task 0x7fef849186d0
17-Nov-2021 06:17:13.844 sending packet to 185.49.140.61#53
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7077
;; flags:; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: e77abc1b4903389a
;; QUESTION SECTION:
;a.b.qnamemin-test.internet.nl. IN TXT
17-Nov-2021 06:17:14.236 socket 0x7fef8419c010: socket_recv: event 0x7fef841a0400 -> task 0x7fef849186d0
17-Nov-2021 06:17:14.236 received packet from 185.49.140.61#53
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7077
;; flags: qr aa; QUESTION: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;a.b.qnamemin-test.internet.nl. IN TXT
;; ANSWER SECTION:
;a.b.qnamemin-test.internet.nl. 10 IN TXT "NO - QNAME minimisation is NOT enabled on your resolver :("
;; AUTHORITY SECTION:
;a.b.qnamemin-test.internet.nl. 10 IN NS ns.a.b.qnamemin-test.internet.nl.
;; ADDITIONAL SECTION:
;ns.a.b.qnamemin-test.internet.nl. 10 IN A 185.49.140.61
;ns.a.b.qnamemin-test.internet.nl. 10 IN AAAA 2a04:b900::8:0:0:61
17-Nov-2021 06:17:14.236 log_ns_ttl: fctx 0x7fef80044e60: rctx_answer: a.b.qnamemin-test.internet.nl (in 'qnamemin-test.internet.nl'?): 1 10
17-Nov-2021 06:17:14.236 validating a.b.qnamemin-test.internet.nl/TXT: starting
17-Nov-2021 06:17:14.236 validating a.b.qnamemin-test.internet.nl/TXT: attempting insecurity proof
17-Nov-2021 06:17:14.236 validating a.b.qnamemin-test.internet.nl/TXT: checking existence of DS at 'nl'
17-Nov-2021 06:17:14.236 validating a.b.qnamemin-test.internet.nl/TXT: checking existence of DS at 'internet.nl'
17-Nov-2021 06:17:14.236 validating a.b.qnamemin-test.internet.nl/TXT: checking existence of DS at 'qnamemin-test.internet.nl'
17-Nov-2021 06:17:14.236 validating a.b.qnamemin-test.internet.nl/TXT: marking as answer (proveunsecure (4))
17-Nov-2021 06:17:14.236 validator @0x7fef80047440: dns_validator_destroy
17-Nov-2021 06:17:14.236 delete_node(): 0x7fef8482b940 ns.a.b.qnamemin-test.internet.nl (bucket 13)
17-Nov-2021 06:17:14.236 client @0x7fef808ae838 127.0.0.1#35491 (qnamemintest.internet.nl): reset client
17-Nov-2021 06:17:14.236 dns_adb_destroyfind on find 0x7fef84327e10
========== Before test 5
17-Nov-2021 06:17:16.580 client @0x7fef78053e18 127.0.0.1#45992: UDP request
17-Nov-2021 06:17:16.580 client @0x7fef78053e18 127.0.0.1#45992: using view '_default'
17-Nov-2021 06:17:16.580 client @0x7fef78053e18 127.0.0.1#45992: request is not signed
17-Nov-2021 06:17:16.580 client @0x7fef78053e18 127.0.0.1#45992: recursion available
17-Nov-2021 06:17:16.580 client @0x7fef78053e18 127.0.0.1#45992 (qnamemintest.internet.nl): query: qnamemintest.internet.nl IN TXT + (127.0.0.1)
17-Nov-2021 06:17:16.580 client @0x7fef78053e18 127.0.0.1#45992 (qnamemintest.internet.nl): query (cache) 'qnamemintest.internet.nl/TXT/IN' approved
17-Nov-2021 06:17:16.580 client @0x7fef78053e18 127.0.0.1#45992 (qnamemintest.internet.nl): reset client
======== done test 5
```
### What is the expected *correct* behavior?
We believe that served from cache or not, all requests should be minimized and this test should pass every time.
### Relevant logs and/or screenshots
We have `qname-minimization strict;` set in `named.conf.options`.
Beyond that and some logging changes, we are using the default configuration.
### Possible fixes
Wish I was that skilled to help out. I have previously opened https://gitlab.isc.org/isc-projects/bind9/-/issues/2665 which was similar, so some of the work there might be relevant.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3011rndc addzone accepts secondary zone without primaries2023-11-02T16:26:08ZJP Mensrndc addzone accepts secondary zone without primaries`rndc addzone` accepts addition of secondary zone to a running server without me specifying primaries, even though such a configuration is not permitted in `named.conf`. Is this an error or does it cater for a use-case I'm not familiar w...`rndc addzone` accepts addition of secondary zone to a running server without me specifying primaries, even though such a configuration is not permitted in `named.conf`. Is this an error or does it cater for a use-case I'm not familiar with?
`BIND 9.17.19 (Development Release) <id:e8d1dd3>`
#### named.conf
```
key "rndc-key" {
algorithm hmac-sha256;
secret "4tFLJTPa4EXIY0bkrIzJOj1WNp1KSvYI4HJE+n2vrbo=";
};
options {
directory "/tmp/named";
allow-query { any; };
listen-on { 127.0.0.2; };
listen-on-v6 { none; };
allow-new-zones yes;
recursion no;
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
```
#### named -g
```
# named -g
11-Nov-2021 09:41:36.716 starting BIND 9.17.19 (Development Release) <id:e8d1dd3>
11-Nov-2021 09:41:36.716 running on Darwin x86_64 19.6.0 Darwin Kernel Version 19.6.0: Thu Sep 16 20:58:47 PDT 2021; root:xnu-6153.141.40.1~1/RELEASE_X86_64
11-Nov-2021 09:41:36.716 built with '--prefix=/usr/local/bind9git' '--with-libxml2' '--with-json-c' '--with-openssl=/usr/local/Cellar/openssl@1.1/1.1.1l_1/' 'LDFLAGS=-L/usr/local/Cellar/openssl@1.1/1.1.1l_1//lib/' 'CPPFLAGS=-I/usr/local/Cellar/openssl@1.1/1.1.1l_1//include/' 'PYTHON=/usr/local/bin/python3.9'
11-Nov-2021 09:41:36.716 running as: named -g -c /usr/local/etc/named-addzones.conf
11-Nov-2021 09:41:36.716 compiled by CLANG Apple LLVM 12.0.0 (clang-1200.0.32.29)
11-Nov-2021 09:41:36.716 compiled with OpenSSL version: OpenSSL 1.1.1l 24 Aug 2021
11-Nov-2021 09:41:36.716 linked to OpenSSL version: OpenSSL 1.1.1l 24 Aug 2021
11-Nov-2021 09:41:36.716 compiled with libxml2 version: 2.9.4
11-Nov-2021 09:41:36.716 linked to libxml2 version: 20904
11-Nov-2021 09:41:36.716 compiled with json-c version: 0.15
11-Nov-2021 09:41:36.716 linked to json-c version: 0.15
11-Nov-2021 09:41:36.716 compiled with zlib version: 1.2.11
11-Nov-2021 09:41:36.716 linked to zlib version: 1.2.11
...
11-Nov-2021 09:41:44.997 received control channel command 'addzone example.com { type secondary; file "example.com"; };'
11-Nov-2021 09:41:44.997 zone example.com/IN: cannot refresh: no primaries
11-Nov-2021 09:41:44.998 added zone example.com in view _default via addzone
```
#### rndc addzone
```console
$ rndc -k rndc.key addzone example.com '{ type secondary; file "example.com"; };'
```
#### nzf file
```console
# named-nzd2nzf /tmp/named/_default.nzd
zone "example.com" { type secondary; file "example.com"; };
```
If I try to load a `named.conf` with a statically configured secondary without primaries
```
zone "example.net" IN {
type secondary;
file "example.net";
};
```
I get an error:
```
named-addzones.conf:22: zone 'example.net': missing 'primaries' entry
```Not planned