BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-11-06T11:08:42Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1733Additional parameter to minimal-responses2023-11-06T11:08:42ZPeter DaviesAdditional parameter to minimal-responses### Description
Description:
In order to minimise the data returned from a forwarder to a forwardee when the forwarder has "minimal-responses" enabled; including delegations, negative responses etc.
This is because, in a typical setup, t...### Description
Description:
In order to minimise the data returned from a forwarder to a forwardee when the forwarder has "minimal-responses" enabled; including delegations, negative responses etc.
This is because, in a typical setup, the forwardee will be configured to "forward only" and so has no use for additional or authority data.
Suggestions on how this might be enabled are:
1) If the query received by the forwarder has RD=1 (from the forwardee), additional/authority data is NOT returned, even for delegations and negative responses.
Note: The danger with this is there might be a use case where the forwardee needs some or all of this data, even if RD=1
or
2) An additional parameter for "minimal-responses", something like "always", which if configured on the forwarder would cause it to never return additional/authority data to the forwardee under any circumstances.
Note: I think this would involve changing its parameter type from boolean to integer(?) in order to introduce a third option.
see RT [#16200](https://support.isc.org/Ticket/Display.html?id=16200)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/987Update Catalog Zones2023-11-03T09:09:10ZVicky Riskvicky@isc.orgUpdate Catalog ZonesUpdate Catalog zones to align with the latest (04?) draft. (As discussed at All-Hands 2019)
At the same time, implement the filter controls in Gitlab issue #751Update Catalog zones to align with the latest (04?) draft. (As discussed at All-Hands 2019)
At the same time, implement the filter controls in Gitlab issue #751BIND 9.19.xArаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/858Use configured paths in documentation2023-11-03T07:42:59ZOndřej SurýUse configured paths in documentationCurrently, the documentation contains stuff like this:
> This creates a file <filename>rndc.key</filename>
> in <filename>/usr/local/etc</filename> (or whatever
> <varname>sysconfdir</varname>
> was specified as when <acronym>BIND</acro...Currently, the documentation contains stuff like this:
> This creates a file <filename>rndc.key</filename>
> in <filename>/usr/local/etc</filename> (or whatever
> <varname>sysconfdir</varname>
> was specified as when <acronym>BIND</acronym> was
> built)
while it should really use the paths configure via autoconf.January 2022 (9.18.0)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3805Memory context reference leak intermittently triggered by the "stress" system...2023-11-03T07:35:41ZMichał KępieńMemory context reference leak intermittently triggered by the "stress" system testThe `stress` system test (**not** the performance test that is only run
in scheduled pipelines!) fails intermittently due to the reference count
for one of the memory contexts not being brought down to zero upon
shutdown.
Example: https...The `stress` system test (**not** the performance test that is only run
in scheduled pipelines!) fails intermittently due to the reference count
for one of the memory contexts not being brought down to zero upon
shutdown.
Example: https://gitlab.isc.org/isc-projects/bind9/-/jobs/3074540
`bin/tests/system/stress/ns3/named.run`:
```
...
17-Jan-2023 01:18:03.406 calling free_rbtdb(zone000004.example)
17-Jan-2023 01:18:03.406 done free_rbtdb(zone000001.example)
17-Jan-2023 01:18:03.410 adjust_quantum: old=200, new=275
17-Jan-2023 01:18:03.410 adjust_quantum: old=400, new=550
17-Jan-2023 01:18:03.410 done free_rbtdb(zone000000.example)
17-Jan-2023 01:18:03.410 done free_rbtdb(zone000004.example)
17-Jan-2023 01:18:03.422 Unregistering DLZ_dlopen driver
17-Jan-2023 01:18:03.422 Unregistering SDLZ driver.
17-Jan-2023 01:18:03.422 Unregistering DLZ driver.
17-Jan-2023 01:18:03.422 exiting
Dump of all outstanding memory allocations:
None.
mem.c:675: REQUIRE(isc_refcount_current(&ctx->references) == 0) failed
```
Backtrace:
```
(lldb) bt
* thread #1, name = 'named', stop reason = signal SIGABRT
* frame #0: 0x00007f4e4f2c7ce1 libc.so.6`__GI_raise(sig=<unavailable>) at raise.c:51:1
frame #1: 0x00007f4e4f2b1537 libc.so.6`__GI_abort at abort.c:79:7
frame #2: 0x0000560aa520ee31 named`assertion_failed(file=<unavailable>, line=<unavailable>, type=<unavailable>, cond=<unavailable>) at main.c:236:3
frame #3: 0x00007f4e5161983a libisc-9.18.12-dev.so`isc_assertion_failed(file=<unavailable>, line=675, type=isc_assertiontype_require, cond=<unavailable>) at assertions.c:48:2
frame #4: 0x00007f4e5168ae2d libisc-9.18.12-dev.so`isc__mem_destroy(ctxp=0x0000560aa5d3c200, file=<unavailable>, line=1614) at mem.c:675:2
frame #5: 0x0000560aa520df76 named`main(argc=<unavailable>, argv=0x00007ffc6f3a9ec8) at main.c:1614:2
frame #6: 0x00007f4e4f2b2d0a libc.so.6`__libc_start_main(main=(named`main at main.c:1480), argc=16, argv=0x00007ffc6f3a9ec8, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007ffc6f3a9eb8) at libc-start.c:308:16
frame #7: 0x0000560aa511ba5a named`_start + 42
```
The context in question is the `main` one. It has one outstanding
reference.
I can only confirm this with 100% certainty for ~"v9.18" right now, but
we should definitely keep our minds open wrt other branches being
affected ;-)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3102ASAN error in fctx_cancelquery()2023-11-03T07:32:07ZMichał KępieńASAN error in fctx_cancelquery()Apparently #3018/!5584 was not the only scenario to fix.
https://gitlab.isc.org/isc-projects/bind9/-/jobs/2233451
<details>
<summary>Click to expand/collapse backtrace</summary>
<pre>D:forward:Core was generated by `/builds/isc-project...Apparently #3018/!5584 was not the only scenario to fix.
https://gitlab.isc.org/isc-projects/bind9/-/jobs/2233451
<details>
<summary>Click to expand/collapse backtrace</summary>
<pre>D:forward:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D forward-ns3 -X named.lock -'.
D:forward:Program terminated with signal SIGABRT, Aborted.
D:forward:#0 0x00007f82ca52984c in __pthread_kill_implementation () from /lib64/libc.so.6
D:forward:[Current thread is 1 (Thread 0x7f82c26e8640 (LWP 6446))]
D:forward:#0 0x00007f82ca52984c in __pthread_kill_implementation () from /lib64/libc.so.6
D:forward:#1 0x00007f82ca4dc6a6 in raise () from /lib64/libc.so.6
D:forward:#2 0x00007f82ca4c67d3 in abort () from /lib64/libc.so.6
D:forward:#3 0x00007f82ce2a05df in __sanitizer::Abort() () from /lib64/libasan.so.6
D:forward:#4 0x00007f82ce2ab94c in __sanitizer::Die() () from /lib64/libasan.so.6
D:forward:#5 0x00007f82ce28cd9c in __asan::ScopedInErrorReport::~ScopedInErrorReport() () from /lib64/libasan.so.6
D:forward:#6 0x00007f82ce28c666 in __asan::ReportGenericError(unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool) () from /lib64/libasan.so.6
D:forward:#7 0x00007f82ce28d22c in __asan_report_load4 () from /lib64/libasan.so.6
D:forward:#8 0x00007f82cc974fa5 in fctx_cancelquery (queryp=queryp@entry=0x7f82c26e1fb0, finish=0x7f82c26e29a8, no_response=no_response@entry=false, age_untried=age_untried@entry=false) at resolver.c:1297
D:forward:#9 0x00007f82cc99e8df in rctx_done (rctx=rctx@entry=0x7f82c26e2930, result=result@entry=ISC_R_SUCCESS) at resolver.c:9658
D:forward:#10 0x00007f82cc9af918 in resquery_response (eresult=eresult@entry=ISC_R_SUCCESS, region=region@entry=0x7f82c26e4570, arg=<optimized out>) at resolver.c:7805
D:forward:#11 0x00007f82cc5b49a5 in udp_recv (handle=<optimized out>, eresult=ISC_R_SUCCESS, region=<optimized out>, arg=<optimized out>) at dispatch.c:593
D:forward:#12 0x00007f82cd8f6f00 in isc__nm_async_readcb (worker=worker@entry=0x0, ev0=ev0@entry=0x7f82c26e4610) at netmgr/netmgr.c:2798
D:forward:#13 0x00007f82cd8f755f in isc__nm_readcb (sock=sock@entry=0x61d0000a3280, uvreq=uvreq@entry=0x61d0000a4680, eresult=eresult@entry=ISC_R_SUCCESS) at netmgr/netmgr.c:2771
D:forward:#14 0x00007f82cd934490 in udp_recv_cb (handle=handle@entry=0x61d0000a3830, nrecv=nrecv@entry=339, buf=buf@entry=0x7f82c26e4860, addr=addr@entry=0x7f82c26e48b0, flags=flags@entry=0) at netmgr/udp.c:641
D:forward:#15 0x00007f82cd93854f in isc__nm_udp_read_cb (handle=0x61d0000a3830, nrecv=339, buf=0x7f82c26e4860, addr=0x7f82c26e48b0, flags=0) at netmgr/udp.c:1047
D:forward:#16 0x00007f82cb21acc4 in uv__udp_recvmsg (handle=0x61d0000a3830) at /usr/src/libuv-v1.43.0/src/unix/udp.c:302
D:forward:#17 0x00007f82cb21a5e8 in uv__udp_io (loop=0x6280000021e0, w=0x61d0000a38b0, revents=1) at /usr/src/libuv-v1.43.0/src/unix/udp.c:178
D:forward:#18 0x00007f82cb22162b in uv__io_poll (loop=0x6280000021e0, timeout=800) at /usr/src/libuv-v1.43.0/src/unix/epoll.c:374
D:forward:#19 0x00007f82cb205c01 in uv_run (loop=0x6280000021e0, mode=UV_RUN_DEFAULT) at /usr/src/libuv-v1.43.0/src/unix/core.c:389
D:forward:#20 0x00007f82cd8fad6d in nm_thread (worker0=0x6280000021d0) at netmgr/netmgr.c:691
D:forward:#21 0x00007f82cd9f87f6 in isc__trampoline_run (arg=0x60300002c6b0) at trampoline.c:187
D:forward:#22 0x00007f82ca527a87 in start_thread () from /lib64/libc.so.6
D:forward:#23 0x00007f82ca5ab8d4 in clone () from /lib64/libc.so.6
D:forward:--------------------------------------------------------------------------------</pre>
</details>
Unfortunately, the job ran over the weekend and the artifacts were no
longer available when I tried to examine them today, so I am unable to
paste the full ASAN report. However, judging from line numbers, the
problem lies here:
```c
1286 REQUIRE(queryp != NULL);
1287
1288 query = *queryp;
1289 fctx = query->fctx;
1290
1291 if (RESQUERY_CANCELED(query)) {
1292 return;
1293 }
1294
1295 FCTXTRACE("cancelquery");
1296
1297 >>> query->attributes |= RESQUERY_ATTR_CANCELED;
```
Looking at the test output, I sense this is happening on shutdown.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1083Possible race in configure_catz_zone2023-11-03T07:20:57ZWitold KrecickiPossible race in configure_catz_zoneAppeared once, when running system tests with libfaketime:
```
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f3401379535 in __GI_abort () at abort.c:79
#2 0x000055f98610e292 in library_fatal_error ...Appeared once, when running system tests with libfaketime:
```
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f3401379535 in __GI_abort () at abort.c:79
#2 0x000055f98610e292 in library_fatal_error (file=0x55f986446038 "./server.c", line=2959, format=0x55f9864bcd8f "RUNTIME_CHECK(%s) failed", args=0x7f33fe634820) at ./main.c:293
#3 0x000055f9863fe605 in isc_error_fatal (file=0x55f986446038 "./server.c", line=2959, format=0x55f9864bcd8f "RUNTIME_CHECK(%s) failed") at error.c:65
#4 0x000055f9863fe645 in isc_error_runtimecheck (file=0x55f986446038 "./server.c", line=2959, expression=0x55f986446d90 "tresult == 0") at error.c:72
#5 0x000055f9861178e5 in configure_catz_zone (view=0x7f33b40900d0, config=0x7f33ebd7f890, element=0x7f33f25e4318) at ./server.c:2959
#6 0x000055f986117cfd in configure_catz (view=0x7f33b40900d0, config=0x7f33ebd7f890, catz_obj=0x7f33b4035cb8) at ./server.c:3056
#7 0x000055f98611a179 in configure_view (view=0x7f33b40900d0, viewlist=0x7f33fe635ab0, config=0x7f33ebd7f890, vconfig=0x0, cachelist=0x7f33fe635ad0, bindkeys=0x0, mctx=0x55f98780d160, actx=0x7f33f25ebff0, need_hints=true) at ./server.c:3888
#8 0x000055f986129c4e in load_configuration (filename=0x55f986534d00 <absolute_conffile> "/home/wpk/dev/isc/bind9/master/bin/tests/system/catz/ns2/named.conf", server=0x7f33fee46020, first_time=false) at ./server.c:8810
#9 0x000055f98612e586 in loadconfig (server=0x7f33fee46020) at ./server.c:10029
#10 0x000055f98612f3fa in named_server_reconfigcommand (server=0x7f33fee46020) at ./server.c:10397
#11 0x000055f986106d5c in named_control_docommand (message=0x7f33b4025150, readonly=false, text=0x7f33fe635ce8) at control.c:241
--Type <RET> for more, q to quit, c to continue without paging--
#12 0x000055f98610878c in control_recvmessage (task=0x7f33fee53020, event=0x7f33f25ef610) at controlconf.c:462
#13 0x000055f986424805 in dispatch (manager=0x7f33fee3d020, threadid=1) at task.c:1128
#14 0x000055f986424e70 in run (queuep=0x55f98781a6b0) at task.c:1295
#15 0x00007f3401548182 in start_thread (arg=<optimized out>) at pthread_create.c:486
#16 0x00007f3401471b1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
tresult is ISC_R_NOTFOUNDNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1022named may crash upon shutdown when catalog zones are used (mutex destruction)2023-11-03T07:17:57ZMichał Kępieńnamed may crash upon shutdown when catalog zones are used (mutex destruction)See https://gitlab.isc.org/isc-projects/bind9/-/jobs/230738. Mutex destruction fails, causing a `RUNTIME_CHECK()` assertion failure. There is another thread ("Thread 9" below) in the core which is also "in the middle of" failing an ass...See https://gitlab.isc.org/isc-projects/bind9/-/jobs/230738. Mutex destruction fails, causing a `RUNTIME_CHECK()` assertion failure. There is another thread ("Thread 9" below) in the core which is also "in the middle of" failing an assertion failure related to reference counting for a view structure. Looks like the catalog zone shutdown code handles certain event scheduling scenarios less than ideally - this crash might or might not be related to #994.
```
(gdb) thread apply all bt
Thread 11 (Thread 0x7f0c9c6d8700 (LWP 28074)):
#0 0x00007f0ca253c243 in epoll_wait () from /lib64/libc.so.6
#1 0x00007f0ca3e4ee4c in watcher (uap=0x7f0ca5116020) at socket.c:4299
#2 0x00007f0ca2fdbaa1 in start_thread () from /lib64/libpthread.so.0
#3 0x00007f0ca253bc4d in clone () from /lib64/libc.so.6
Thread 10 (Thread 0x7f0c9ced9700 (LWP 28073)):
#0 0x00007f0ca2fdfa5e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f0ca3e5158e in isc_condition_waituntil (c=0x7f0ca5114088, m=0x7f0ca5114038, t=0x7f0ca511407c) at condition.c:59
#2 0x00007f0ca3e3ab5c in run (uap=0x7f0ca5114020) at timer.c:806
#3 0x00007f0ca2fdbaa1 in start_thread () from /lib64/libpthread.so.0
#4 0x00007f0ca253bc4d in clone () from /lib64/libc.so.6
Thread 9 (Thread 0x7f0ca06e0700 (LWP 28066)):
#0 0x00007f0c99b4d8eb in ?? () from /lib64/libgcc_s.so.1
#1 0x00007f0ca25799d6 in dl_iterate_phdr () from /lib64/libc.so.6
#2 0x00007f0c99b4e207 in _Unwind_Find_FDE () from /lib64/libgcc_s.so.1
#3 0x00007f0c99b4b603 in ?? () from /lib64/libgcc_s.so.1
#4 0x00007f0c99b4c119 in _Unwind_Backtrace () from /lib64/libgcc_s.so.1
#5 0x00007f0ca2551c46 in backtrace () from /lib64/libc.so.6
#6 0x00007f0ca3e0bb1a in isc_backtrace_gettrace (addrs=0x7f0ca06de3d0, maxaddrs=<value optimized out>, nframes=0x7f0ca06de7ec) at backtrace.c:75
#7 0x00000000004321df in assertion_failed (file=0x7f0ca4af370c "view.c", line=583, type=isc_assertiontype_require, cond=0x7f0ca4ac4cdd "prev > 0") at ./main.c:190
#8 0x00007f0ca3e0b93a in isc_assertion_failed (file=<value optimized out>, line=<value optimized out>, type=<value optimized out>, cond=<value optimized out>) at assertions.c:51
#9 0x00007f0ca4a62eb3 in dns_view_attach (source=<value optimized out>, targetp=<value optimized out>) at view.c:583
#10 0x00000000004569b1 in catz_create_chg_task (entry=0x7f0ca5114e80, origin=0x7f0ca50a9020, view=0x7f0c7c04ab90, taskmgr=0x7f0ca5112020, udata=0x6cb370, type=262200) at ./server.c:2412
#11 0x00007f0ca4948526 in dns_catz_zones_merge (target=0x7f0ca50a9020, newzone=<value optimized out>) at catz.c:515
#12 0x00007f0ca494a05b in dns_catz_update_from_db (db=<value optimized out>, catzs=0x7f0ca50a8fa0) at catz.c:1940
#13 0x00007f0ca494a1f8 in dns_catz_update_taskaction (task=<value optimized out>, event=0x7f0ca50a9168) at catz.c:1694
#14 0x00007f0ca3e35cdc in dispatch (uap=0x7f0ca5112020) at task.c:1143
#15 run (uap=0x7f0ca5112020) at task.c:1315
#16 0x00007f0ca2fdbaa1 in start_thread () from /lib64/libpthread.so.0
#17 0x00007f0ca253bc4d in clone () from /lib64/libc.so.6
Thread 8 (Thread 0x7f0c9eedd700 (LWP 28069)):
#0 0x00007f0ca2fdf68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f0ca3e35ac6 in dispatch (uap=0x7f0ca5112020) at task.c:1089
#2 run (uap=0x7f0ca5112020) at task.c:1315
#3 0x00007f0ca2fdbaa1 in start_thread () from /lib64/libpthread.so.0
#4 0x00007f0ca253bc4d in clone () from /lib64/libc.so.6
Thread 7 (Thread 0x7f0c9e6dc700 (LWP 28070)):
#0 0x00007f0ca2fe2334 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x00007f0ca2fdd60e in _L_lock_995 () from /lib64/libpthread.so.0
#2 0x00007f0ca2fdd576 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x00007f0ca4952d22 in destroy_disp (task=<value optimized out>, event=0x7f0ca50a06b0) at dispatch.c:527
#4 0x00007f0ca3e35cdc in dispatch (uap=0x7f0ca5112020) at task.c:1143
#5 run (uap=0x7f0ca5112020) at task.c:1315
#6 0x00007f0ca2fdbaa1 in start_thread () from /lib64/libpthread.so.0
#7 0x00007f0ca253bc4d in clone () from /lib64/libc.so.6
Thread 6 (Thread 0x7f0c9dedb700 (LWP 28071)):
#0 0x00007f0ca2fe2334 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x00007f0ca2fdd60e in _L_lock_995 () from /lib64/libpthread.so.0
#2 0x00007f0ca2fdd576 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x00007f0ca3e1ad40 in isc_log_doit (lctx=0x1656820, category=0x6c30d0, module=0x6c3170, level=3, write_once=false, msgcat=0x0, msgset=0, msg=0, format=0x49f320 "client @%p %s%s%s%s%s%s%s%s: %s", args=0x7f0c9ded9280) at log.c:1440
#4 0x00007f0ca3e1be3c in isc_log_write (lctx=<value optimized out>, category=<value optimized out>, module=<value optimized out>, level=<value optimized out>, format=<value optimized out>) at log.c:833
#5 0x000000000041ef5e in ns_client_logv (client=0x7f0c7c994d00, category=0x6c30d0, module=0x6c3170, level=3, fmt=<value optimized out>, ap=<value optimized out>) at client.c:4049
#6 0x000000000041f105 in ns_client_log (client=0x7f0c7c994d00, category=0x6c30d0, module=0x6c3170, level=3, fmt=0x4b1d22 "%s") at client.c:4065
#7 0x00000000004237e9 in client_shutdown (task=<value optimized out>, event=0x7f0c7c600df8) at client.c:826
#8 0x00007f0ca3e35cdc in dispatch (uap=0x7f0ca5112020) at task.c:1143
#9 run (uap=0x7f0ca5112020) at task.c:1315
#10 0x00007f0ca2fdbaa1 in start_thread () from /lib64/libpthread.so.0
#11 0x00007f0ca253bc4d in clone () from /lib64/libc.so.6
Thread 5 (Thread 0x7f0c9d6da700 (LWP 28072)):
#0 0x00007f0ca2fdf68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f0ca3e35ac6 in dispatch (uap=0x7f0ca5112020) at task.c:1089
#2 run (uap=0x7f0ca5112020) at task.c:1315
#3 0x00007f0ca2fdbaa1 in start_thread () from /lib64/libpthread.so.0
#4 0x00007f0ca253bc4d in clone () from /lib64/libc.so.6
Thread 4 (Thread 0x7f0c9f6de700 (LWP 28068)):
#0 0x00007f0ca2fe2334 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x00007f0ca2fdd60e in _L_lock_995 () from /lib64/libpthread.so.0
#2 0x00007f0ca2fdd576 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x00007f0ca4952d22 in destroy_disp (task=<value optimized out>, event=0x7f0ca50a04d0) at dispatch.c:527
#4 0x00007f0ca3e35cdc in dispatch (uap=0x7f0ca5112020) at task.c:1143
#5 run (uap=0x7f0ca5112020) at task.c:1315
#6 0x00007f0ca2fdbaa1 in start_thread () from /lib64/libpthread.so.0
#7 0x00007f0ca253bc4d in clone () from /lib64/libc.so.6
Thread 3 (Thread 0x7f0c9fedf700 (LWP 28067)):
#0 0x00007f0ca253861a in mmap64 () from /lib64/libc.so.6
#1 0x00007f0ca24b91cc in _IO_file_doallocate_internal () from /lib64/libc.so.6
#2 0x00007f0ca24c668c in _IO_doallocbuf_internal () from /lib64/libc.so.6
#3 0x00007f0ca24c4fbc in _IO_new_file_seekoff () from /lib64/libc.so.6
#4 0x00007f0ca24c3d42 in _IO_new_file_attach () from /lib64/libc.so.6
#5 0x00007f0ca24b9685 in fdopen@@GLIBC_2.2.5 () from /lib64/libc.so.6
#6 0x00007f0ca3e411a5 in isc_file_openuniquemode (templet=0x7f0c9feddd20 "tmp-ARUQf2zBLO", mode=384, fp=0x7f0c9feded28) at file.c:360
#7 0x00007f0ca4a679bd in destroy (view=0x7f0c7d0afa80) at view.c:376
#8 0x00007f0ca4a68e48 in adb_shutdown (task=<value optimized out>, event=0x0) at view.c:757
#9 0x00007f0ca3e35cdc in dispatch (uap=0x7f0ca5112020) at task.c:1143
#10 run (uap=0x7f0ca5112020) at task.c:1315
#11 0x00007f0ca2fdbaa1 in start_thread () from /lib64/libpthread.so.0
#12 0x00007f0ca253bc4d in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7f0ca514e7c0 (LWP 28051)):
#0 0x00007f0ca2fdc2fd in pthread_join () from /lib64/libpthread.so.0
#1 0x00007f0ca3e37b24 in isc__taskmgr_destroy (managerp=0x6caa10) at task.c:1585
#2 0x00007f0ca3e37dad in isc_taskmgr_destroy (managerp=0x6caa10) at task.c:2102
#3 0x0000000000433ead in destroy_managers (argc=<value optimized out>, argv=<value optimized out>) at ./main.c:872
#4 cleanup (argc=<value optimized out>, argv=<value optimized out>) at ./main.c:1275
#5 main (argc=<value optimized out>, argv=<value optimized out>) at ./main.c:1508
Thread 1 (Thread 0x7f0ca0ee1700 (LWP 28065)):
#0 0x00007f0ca24854f5 in raise () from /lib64/libc.so.6
#1 0x00007f0ca2486cd5 in abort () from /lib64/libc.so.6
#2 0x000000000043212b in library_fatal_error (file=0x7f0ca4acb84c "catz.c", line=<value optimized out>, format=0x7f0ca3e53020 "RUNTIME_CHECK(%s) %s", args=0x7f0ca0ee0bf0) at ./main.c:275
#3 0x00007f0ca3e0fa54 in isc_error_fatal (file=<value optimized out>, line=<value optimized out>, format=<value optimized out>) at error.c:68
#4 0x00007f0ca3e0fab4 in isc_error_runtimecheck (file=0x7f0ca4acb84c "catz.c", line=866, expression=0x7f0ca4acb0e8 "((pthread_mutex_destroy(((&catzs->lock))) == 0) ? 0 : 34) == 0") at error.c:75
#5 0x00007f0ca4947e12 in dns_catz_catzs_detach (catzsp=<value optimized out>) at catz.c:866
#6 0x00007f0ca4a82ae5 in zone_free (zone=0x7f0c944f0260) at zone.c:1223
#7 0x00007f0ca4a8b180 in zone_shutdown (task=<value optimized out>, event=<value optimized out>) at zone.c:13024
#8 0x00007f0ca3e35cdc in dispatch (uap=0x7f0ca5112020) at task.c:1143
#9 run (uap=0x7f0ca5112020) at task.c:1315
#10 0x00007f0ca2fdbaa1 in start_thread () from /lib64/libpthread.so.0
#11 0x00007f0ca253bc4d in clone () from /lib64/libc.so.6
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/994named may crash upon shutdown when catalog zones are used (deallocated events)2023-11-03T07:17:30ZMichał Kępieńnamed may crash upon shutdown when catalog zones are used (deallocated events)See https://gitlab.isc.org/isc-projects/bind9/-/jobs/217460. Apparently the task for the `updatetimer` timer belonging to the `catalog4.example` zone holds events which were already deallocated by the time `isc_task_purgerange()` is cal...See https://gitlab.isc.org/isc-projects/bind9/-/jobs/217460. Apparently the task for the `updatetimer` timer belonging to the `catalog4.example` zone holds events which were already deallocated by the time `isc_task_purgerange()` is called and thus `dequeue_events()` segfaults.
```
(gdb) bt full
#0 dequeue_events (task=0x7efed4e40cc8, sender=0x7efed4ec7c00, first=65536, last=131071, tag=0x0, events=<value optimized out>, purging=true) at task.c:623
event = 0xdededededededede
next_event = <value optimized out>
count = <value optimized out>
#1 0x00007efed3bb6730 in isc_task_purgerange (task0=<value optimized out>, sender=<value optimized out>, first=<value optimized out>, last=<value optimized out>, tag=<value optimized out>) at task.c:657
task = <value optimized out>
count = <value optimized out>
events = {head = 0x0, tail = 0x0}
event = <value optimized out>
next_event = <value optimized out>
#2 0x00007efed3bbc071 in destroy (timerp=0x7efed4e47500) at timer.c:218
manager = 0x7efed4eac020
#3 isc_timer_detach (timerp=0x7efed4e47500) at timer.c:511
timer = 0x7efed4ec7c00
free_timer = <value optimized out>
#4 0x00007efed46b9981 in dns_catz_zone_detach (zonep=<value optimized out>) at catz.c:813
mctx = 0x19282d0
zone = 0x7efed4e473c0
#5 0x00007efed46b9bf2 in dns_catz_catzs_detach (catzsp=<value optimized out>) at catz.c:860
zone = 0x0
iter = 0x7efed4eb9098
result = 0
catzs = 0x7efed4eb57a0
#6 0x00007efed47dd30c in zone_free (zone=0x7efec4145820) at zone.c:1207
mctx = 0x0
signing = <value optimized out>
nsec3chain = <value optimized out>
setnsec3param_event = <value optimized out>
include = 0x0
#7 0x00007efed47e6410 in zone_shutdown (task=<value optimized out>, event=<value optimized out>) at zone.c:13309
zone = 0x7efec4145820
free_needed = true
linked = <value optimized out>
raw = 0x0
secure = 0x0
#8 0x00007efed3bb8956 in dispatch (queuep=<value optimized out>) at task.c:1128
dispatch_count = 1
done = false
finished = false
requeue = false
event = 0x7efec41460f0
task = <value optimized out>
#9 run (queuep=<value optimized out>) at task.c:1295
tq = <value optimized out>
manager = 0x7efed4eab020
threadid = <value optimized out>
#10 0x00007efed257baa1 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#11 0x00007efed22c8c4d in clone () from /lib64/libc.so.6
No symbol table info available.
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3853ASAN detected use after free in zero system test2023-11-03T07:09:15ZEvan HuntASAN detected use after free in zero system testSpotted in https://gitlab.isc.org/isc-projects/bind9/-/jobs/3133245. I don't recall seeing this one before.
```
==14131==ERROR: AddressSanitizer: heap-use-after-free on address 0x6160026d6298 at pc 0x7feea3e4944f bp 0x7fee99eda670 sp 0x...Spotted in https://gitlab.isc.org/isc-projects/bind9/-/jobs/3133245. I don't recall seeing this one before.
```
==14131==ERROR: AddressSanitizer: heap-use-after-free on address 0x6160026d6298 at pc 0x7feea3e4944f bp 0x7fee99eda670 sp 0x7fee99eda668
READ of size 8 at 0x6160026d6298 thread T4
06-Feb-2023 23:17:32.490 fetch: zzzhip2.example/HIP
06-Feb-2023 23:17:32.490 fetch: zzzhip2.example/HIP
06-Feb-2023 23:17:32.490 fetch: zzzhip2.example/HIP
06-Feb-2023 23:17:32.490 fetch: zzzhip2.example/HIP
#0 0x7feea3e4944e in fcount_decr /builds/isc-projects/bind9/lib/dns/resolver.c:1700:7
#1 0x7feea3e28f2a in fctx_destroy /builds/isc-projects/bind9/lib/dns/resolver.c:4496:2
#2 0x7feea3e24a8e in fetchctx_unref /builds/isc-projects/bind9/lib/dns/resolver.c:7189:1
#3 0x7feea3e29ff5 in fetchctx_detach /builds/isc-projects/bind9/lib/dns/resolver.c:7189:1
#4 0x7feea3e3ec1f in dns_resolver_destroyfetch /builds/isc-projects/bind9/lib/dns/resolver.c:10847:2
#5 0x7feea31e87c4 in fetch_callback /builds/isc-projects/bind9/lib/ns/query.c:6384:2
#6 0x7feea48d5a04 in task_run /builds/isc-projects/bind9/lib/isc/task.c:469:4
#7 0x7feea48d5a04 in task__run /builds/isc-projects/bind9/lib/isc/task.c:287:24
#8 0x7feea4830bc3 in isc__job_cb /builds/isc-projects/bind9/lib/isc/job.c:75:2
#9 0x7feea2afc01a in uv__run_idle /usr/src/libuv-v1.44.1/src/unix/loop-watcher.c:68:1
#10 0x7feea2af2868 in uv_run /usr/src/libuv-v1.44.1/src/unix/core.c:384:5
#11 0x7feea4863e77 in loop_run /builds/isc-projects/bind9/lib/isc/loop.c:270:6
#12 0x7feea4863e77 in loop_thread /builds/isc-projects/bind9/lib/isc/loop.c:297:2
#13 0x7feea48f185d in isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:202:11
#14 0x7feea27f4ea6 in start_thread nptl/pthread_create.c:477:8
#15 0x7feea259aa2e in __clone misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:95
0x6160026d6298 is located 536 bytes inside of 568-byte region [0x6160026d6080,0x6160026d62b8)
freed by thread T7 here:
#0 0x5566c56ba3c2 in free (/builds/isc-projects/bind9/bin/named/.libs/named+0x1653c2) (BuildId: a62ae17ac70828fe0069dfa7ee77d75f3ac0238d)
#1 0x7feea4871299 in sdallocx /builds/isc-projects/bind9/lib/isc/./jemalloc_shim.h:80:2
#2 0x7feea4871299 in mem_put /builds/isc-projects/bind9/lib/isc/mem.c:328:2
#3 0x7feea487375f in isc__mem_put /builds/isc-projects/bind9/lib/isc/mem.c:686:2
#4 0x7feea3e49163 in fcount_decr /builds/isc-projects/bind9/lib/dns/resolver.c:1711:3
#5 0x7feea3e28f2a in fctx_destroy /builds/isc-projects/bind9/lib/dns/resolver.c:4496:2
#6 0x7feea3e24a8e in fetchctx_unref /builds/isc-projects/bind9/lib/dns/resolver.c:7189:1
#7 0x7feea3e29ff5 in fetchctx_detach /builds/isc-projects/bind9/lib/dns/resolver.c:7189:1
#8 0x7feea3e3ec1f in dns_resolver_destroyfetch /builds/isc-projects/bind9/lib/dns/resolver.c:10847:2
#9 0x7feea31e87c4 in fetch_callback /builds/isc-projects/bind9/lib/ns/query.c:6384:2
#10 0x7feea48d5a04 in task_run /builds/isc-projects/bind9/lib/isc/task.c:469:4
#11 0x7feea48d5a04 in task__run /builds/isc-projects/bind9/lib/isc/task.c:287:24
#12 0x7feea4830bc3 in isc__job_cb /builds/isc-projects/bind9/lib/isc/job.c:75:2
#13 0x7feea2afc01a in uv__run_idle /usr/src/libuv-v1.44.1/src/unix/loop-watcher.c:68:1
#14 0x7feea2af2868 in uv_run /usr/src/libuv-v1.44.1/src/unix/core.c:384:5
#15 0x7feea4863e77 in loop_run /builds/isc-projects/bind9/lib/isc/loop.c:270:6
#16 0x7feea4863e77 in loop_thread /builds/isc-projects/bind9/lib/isc/loop.c:297:2
#17 0x7feea48f185d in isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:202:11
#18 0x7feea27f4ea6 in start_thread nptl/pthread_create.c:477:8
previously allocated by thread T4 here:
#0 0x5566c56ba66e in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x16566e) (BuildId: a62ae17ac70828fe0069dfa7ee77d75f3ac0238d)
#1 0x7feea4871fb4 in mallocx /builds/isc-projects/bind9/lib/isc/./jemalloc_shim.h:65:14
#2 0x7feea4871fb4 in mem_get /builds/isc-projects/bind9/lib/isc/mem.c:306:8
#3 0x7feea4871cce in isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:669:8
#4 0x7feea3e5bd9f in fcount_incr /builds/isc-projects/bind9/lib/dns/resolver.c:1653:13
#5 0x7feea3e34d95 in fctx_create /builds/isc-projects/bind9/lib/dns/resolver.c:4827:11
#6 0x7feea3e2d4a3 in get_attached_fctx /builds/isc-projects/bind9/lib/dns/resolver.c:10543:12
#7 0x7feea3e2d4a3 in dns_resolver_createfetch /builds/isc-projects/bind9/lib/dns/resolver.c:10645:12
#8 0x7feea31e5f81 in ns_query_recurse /builds/isc-projects/bind9/lib/ns/query.c:6541:11
#9 0x7feea326f1ab in query_delegation_recurse /builds/isc-projects/bind9/lib/ns/query.c:8971:12
#10 0x7feea32123a4 in query_delegation /builds/isc-projects/bind9/lib/ns/query.c:8917:11
#11 0x7feea320429e in query_gotanswer /builds/isc-projects/bind9/lib/ns/query.c:7698:11
#12 0x7feea31e364e in query_lookup /builds/isc-projects/bind9/lib/ns/query.c:6144:11
#13 0x7feea31d39cb in ns__query_start /builds/isc-projects/bind9/lib/ns/query.c:5830:11
#14 0x7feea31fe213 in query_setup /builds/isc-projects/bind9/lib/ns/query.c:5544:11
#15 0x7feea31fc9e5 in ns_query_start /builds/isc-projects/bind9/lib/ns/query.c:12127:8
#16 0x7feea3197e1b in ns__client_request /builds/isc-projects/bind9/lib/ns/client.c:2239:3
#17 0x7feea47901e3 in isc__nm_async_readcb /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:2082:2
#18 0x7feea47895be in isc__nm_readcb /builds/isc-projects/bind9/lib/isc/netmgr/netmgr.c:2055:3
#19 0x7feea47e10e3 in isc__nm_udp_read_cb /builds/isc-projects/bind9/lib/isc/netmgr/udp.c:617:2
#20 0x7feea2b07194 in uv__udp_recvmmsg /usr/src/libuv-v1.44.1/src/unix/udp.c:231:7
#21 0x7feea2b0735d in uv__udp_recvmsg /usr/src/libuv-v1.44.1/src/unix/udp.c:273:15
#22 0x7feea2b06e0a in uv__udp_io /usr/src/libuv-v1.44.1/src/unix/udp.c:178:5
#23 0x7feea2b0dbc2 in uv__io_poll /usr/src/libuv-v1.44.1/src/unix/epoll.c:374:11
#24 0x7feea2af28ad in uv_run /usr/src/libuv-v1.44.1/src/unix/core.c:391:5
#25 0x7feea4863e77 in loop_run /builds/isc-projects/bind9/lib/isc/loop.c:270:6
#26 0x7feea4863e77 in loop_thread /builds/isc-projects/bind9/lib/isc/loop.c:297:2
#27 0x7feea48f185d in isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:202:11
#28 0x7feea27f4ea6 in start_thread nptl/pthread_create.c:477:8
Thread T4 created by T0 here:
#0 0x5566c56a351c in __interceptor_pthread_create (/builds/isc-projects/bind9/bin/named/.libs/named+0x14e51c) (BuildId: a62ae17ac70828fe0069dfa7ee77d75f3ac0238d)
#1 0x7feea48d70ce in isc_thread_create /builds/isc-projects/bind9/lib/isc/thread.c:70:8
#2 0x7feea4862acb in isc_loopmgr_run /builds/isc-projects/bind9/lib/isc/loop.c:475:3
#3 0x5566c57295eb in main /builds/isc-projects/bind9/bin/named/main.c:1513:2
#4 0x7feea24c1d09 in __libc_start_main csu/../csu/libc-start.c:308:16
Thread T7 created by T0 here:
#0 0x5566c56a351c in __interceptor_pthread_create (/builds/isc-projects/bind9/bin/named/.libs/named+0x14e51c) (BuildId: a62ae17ac70828fe0069dfa7ee77d75f3ac0238d)
#1 0x7feea48d70ce in isc_thread_create /builds/isc-projects/bind9/lib/isc/thread.c:70:8
#2 0x7feea4862acb in isc_loopmgr_run /builds/isc-projects/bind9/lib/isc/loop.c:475:3
#3 0x5566c57295eb in main /builds/isc-projects/bind9/bin/named/main.c:1513:2
#4 0x7feea24c1d09 in __libc_start_main csu/../csu/libc-start.c:308:16
SUMMARY: AddressSanitizer: heap-use-after-free /builds/isc-projects/bind9/lib/dns/resolver.c:1700:7 in fcount_decr
Shadow bytes around the buggy address:
0x0c2c804d2c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2c804d2c10: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2c804d2c20: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2c804d2c30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2c804d2c40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c2c804d2c50: fd fd fd[fd]fd fd fd fa fa fa fa fa fa fa fa fa
0x0c2c804d2c60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c2c804d2c70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2c804d2c80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2c804d2c90: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c2c804d2ca0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==14131==ABORTING
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1903Authoritative server leaks 260 KB every 1-2 hours2023-11-03T06:59:46ZMichal NowakAuthoritative server leaks 260 KB every 1-2 hoursI run [stress test](https://gitlab.isc.org/isc-private/bind-qa/-/tree/master/bind9/stress) against BIND 9.16.3 authoritative server on Alpine Linux 3.12 (uses MUSL libc) for 18 hours and I noticed that in many cases `named`'s VSZ usage b...I run [stress test](https://gitlab.isc.org/isc-private/bind-qa/-/tree/master/bind9/stress) against BIND 9.16.3 authoritative server on Alpine Linux 3.12 (uses MUSL libc) for 18 hours and I noticed that in many cases `named`'s VSZ usage bumps 260 bytes every 1-2 hours. I haven't spotted this on Linux distributions with glibc. There are a few discrepancies from the "260 byte rule", but it seems too regular to be a coincidence. Although the mem usage bump is really tiny, there might be a leak of structure.
![named-memory-use-graph-alpine-3.12](/uploads/de49507ad28ed28fababf1b713f29b6d/named-memory-use-graph-alpine-3.12.png)
Here are `VSZ`/`RSS` data every 30 seconds: [alpine-vm.txt](/uploads/9942d3ad62e9c8ec145a2e9fb9bc815b/alpine-vm.txt)
Here's a sample of few last lines funneled via `uniq`:
```
...
422496
422756
423016
423276
423536
423796
424056
424316
424576
424836
425096
425356
425616
425876
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4412Question about response to ANY query2023-11-02T21:14:26ZAmauvpQuestion about response to ANY queryHello, I'm a student in the Master in Cybersecurity organized by the Free University of Brussels. As part of my Master's thesis, I have to implement a DNS amplification scenario within a Cyber Range. Before doing so, I need to measure th...Hello, I'm a student in the Master in Cybersecurity organized by the Free University of Brussels. As part of my Master's thesis, I have to implement a DNS amplification scenario within a Cyber Range. Before doing so, I need to measure the amplification rate for each DNS request. However, I know that BIND is designed to respond to ANY requests via TCP for security reasons. So my question is: how can I make my BIND9 server respond to ANY queries via UDP and not TCP for the purposes of my thesis?
Thank you in advance for your reply.https://gitlab.isc.org/isc-projects/bind9/-/issues/852Bind returning malformed packet error when sshfp record has fingerprint value...2023-11-02T17:11:59ZGhost UserBind returning malformed packet error when sshfp record has fingerprint value less than 4 characters<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
Bind returning malformed packet error when sshfp record has fingerprint value less than 4 characters
### BIND version used
BIND 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.3
### Steps to reproduce
zone has sshfp records has follows
test1.ramesh-sshfp.com. 86400 IN SSHFP 1 1 aa
test2.ramesh-sshfp.com. 86400 IN SSHFP 1 1 00
### What is the current *bug* behavior?
Returning malformed error and no answer
```
[qa][root@regression-bind-useast1a01-01 zones]# dig @localhost test2.ramesh-sshfp.com. sshfp
;; Warning: Message parser reports malformed message packet.
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.3 <<>> @localhost test2.ramesh-sshfp.com. sshfp
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49768
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; WARNING: Messages has 55 extra bytes at end
;; QUESTION SECTION:
;test2.ramesh-sshfp.com. IN SSHFP
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 31 13:29:18 2019
;; MSG SIZE rcvd: 107
[qa][root@regression-bind-useast1a01-01 zones]# dig @localhost test1.ramesh-sshfp.com. sshfp
;; Warning: Message parser reports malformed message packet.
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.3 <<>> @localhost test1.ramesh-sshfp.com. sshfp
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23302
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; WARNING: Messages has 55 extra bytes at end
;; QUESTION SECTION:
;test1.ramesh-sshfp.com. IN SSHFP
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 31 13:29:23 2019
;; MSG SIZE rcvd: 107
```
### What is the expected *correct* behavior?
If the value is correct we should return answer. if the value is wrong, bind should validate and should not start
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)https://gitlab.isc.org/isc-projects/bind9/-/issues/1984"./configure --with-gperftools-profiler" can fail oddly with "error: libcap i...2023-11-02T16:57:55ZMichal Nowak"./configure --with-gperftools-profiler" can fail oddly with "error: libcap is required"On Fedora 32 when `gperftools-devel` and `gperftools-libs` packages are missing, `./configure --with-gperftools-profiler` fails oddly with `error: libcap is required`:
```
checking whether to use gperftools profiler... yes
...
checking f...On Fedora 32 when `gperftools-devel` and `gperftools-libs` packages are missing, `./configure --with-gperftools-profiler` fails oddly with `error: libcap is required`:
```
checking whether to use gperftools profiler... yes
...
checking for library containing cap_set_proc... no
configure: error: libcap is required for Linux capabilities support. Either install libcap or use --disable-linux-caps.
```
`config.log`:
```
| #ifdef __cplusplus
| extern "C"
| #endif
| char cap_set_proc ();
| int
| main ()
| {
| return cap_set_proc ();
| ;
| return 0;
| }
configure:18826: result: no
configure:18833: error: libcap is required for Linux capabilities support. Either install libcap or use --disable-linux-caps.
```September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)https://gitlab.isc.org/isc-projects/bind9/-/issues/1600Core dump in resolver.c when shutting down.2023-11-02T16:51:27ZMark AndrewsCore dump in resolver.c when shutting down.Job [#637123](https://gitlab.isc.org/isc-projects/bind9/-/jobs/637123) failed for 4e2ac5f6c79d91cc0c58d4c3c097e47b79d1f647:
```
05-Feb-2020 08:49:12.254 resolver.c:9813: INSIST(((res->dbuckets[i].list).head == ((void *)0))) failed, back...Job [#637123](https://gitlab.isc.org/isc-projects/bind9/-/jobs/637123) failed for 4e2ac5f6c79d91cc0c58d4c3c097e47b79d1f647:
```
05-Feb-2020 08:49:12.254 resolver.c:9813: INSIST(((res->dbuckets[i].list).head == ((void *)0))) failed, back trace
05-Feb-2020 08:49:12.254 #0 0x5620b7b6cc74 in ??
05-Feb-2020 08:49:12.254 #1 0x7f7c47de1857 in ??
05-Feb-2020 08:49:12.254 #2 0x7f7c48318728 in ??
05-Feb-2020 08:49:12.254 #3 0x7f7c48352808 in ??
05-Feb-2020 08:49:12.254 #4 0x7f7c4835345d in ??
05-Feb-2020 08:49:12.254 #5 0x7f7c4835355c in ??
05-Feb-2020 08:49:12.254 #6 0x7f7c47e06159 in ??
05-Feb-2020 08:49:12.254 #7 0x7f7c47699fa3 in ??
05-Feb-2020 08:49:12.254 #8 0x7f7c475ac4cf in ??
05-Feb-2020 08:49:12.254 exiting (due to assertion failure)
```
Artifacts saved. core dump present (rpzrecurs/ns3/core.7909).Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2727dig package for Windows2023-11-02T16:24:19ZVicky Riskvicky@isc.orgdig package for WindowsWe plan to end support for Windows with 9.18. It seems like there are a number of users who need dig on Windows, so if we can build a dig package for Windows and host that on our website for download, that would be very useful.We plan to end support for Windows with 9.18. It seems like there are a number of users who need dig on Windows, so if we can build a dig package for Windows and host that on our website for download, that would be very useful.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4401make check may throw KeyError while processing pytest's junitxml output2023-11-02T09:03:21ZTom Krizekmake check may throw KeyError while processing pytest's junitxml output`make check` may end up with the following python error:
```
Traceback (most recent call last):
File "/usr/home/ondrej/Projects/bind9/bin/tests/system/./convert-junit-to-trs.py", line 70, in <module>
main()
File "/usr/home/ondre...`make check` may end up with the following python error:
```
Traceback (most recent call last):
File "/usr/home/ondrej/Projects/bind9/bin/tests/system/./convert-junit-to-trs.py", line 70, in <module>
main()
File "/usr/home/ondrej/Projects/bind9/bin/tests/system/./convert-junit-to-trs.py", line 66, in main
sys.exit(junit_to_trs(junit_xml))
File "/usr/home/ondrej/Projects/bind9/bin/tests/system/./convert-junit-to-trs.py", line 37, in junit_to_trs
if node.attrib["type"] == "pytest.xfail":
KeyError: 'type'
```
Related #4262, #3810November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3287A jemalloc quirk may trigger an out-of-memory condition in named over time2023-11-01T14:23:00ZMichał KępieńA jemalloc quirk may trigger an out-of-memory condition in named over timeSince version 5.0.0, decay-based purging is the only available dirty
page cleanup mechanism in jemalloc. It relies on so-called tickers,
which are simple data structures used for ensuring that certain actions
are taken "once every N tim...Since version 5.0.0, decay-based purging is the only available dirty
page cleanup mechanism in jemalloc. It relies on so-called tickers,
which are simple data structures used for ensuring that certain actions
are taken "once every N times". Ticker data (state) is stored in a
thread-specific data structure called tsd in jemalloc parlance. Ticks
are triggered when extents are allocated and deallocated. Once every
1000 ticks, jemalloc attempts to release some of the dirty pages hanging
around (if any). This allows memory use to be kept in check over time.
This dirty page cleanup mechanism has a quirk. If the first
allocator-related action for a given thread is a `free()`, a
minimally-initialized tsd is set up which does not include ticker data.
When that thread subsequently calls `*alloc()`, the tsd transitions to
its nominal state, but due to a certain flag being set during minimal
tsd initialization, ticker data remains unallocated. This prevents
decay-based dirty page purging from working, effectively enabling memory
exhaustion over time. This problem has been [reported][1] upstream and
was subsequently confirmed by jemalloc developers.
The quirk described above has been [addressed][2] (by moving ticker
state to a different structure) in jemalloc's development branch, but
not in any numbered jemalloc version released to date (the latest one
being 5.2.1 as of this writing).
This problem affects:
- BIND 9.18+ builds with jemalloc explicitly linked in,
- BIND 9.16 builds on FreeBSD, where jemalloc is the default system
allocator.
[1]: https://github.com/jemalloc/jemalloc/issues/2251
[2]: https://github.com/jemalloc/jemalloc/commit/c259323ab3082324100c708109dbfff660d0f4b8May 2022 (9.16.29, 9.16.29-S1, 9.18.3, 9.19.1)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1609Use native rwlock implementation2023-11-01T13:36:50ZOndřej SurýUse native rwlock implementationAs discovered by @wpk and perflab, the pthread_rwlock API gives BIND 9 better performance on modern systems than our native adaptive rwlock implementation.
We should drop the native rwlock implementation in favor of native rwlock implem...As discovered by @wpk and perflab, the pthread_rwlock API gives BIND 9 better performance on modern systems than our native adaptive rwlock implementation.
We should drop the native rwlock implementation in favor of native rwlock implementation both on POSIX and Windows platforms.March 2023 (9.16.39, 9.16.39-S1, 9.18.13, 9.18.13-S1, 9.19.11)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4264Improve locking in dns_nta2023-11-01T11:34:06ZEvan HuntImprove locking in dns_ntaAfter converting the NTA to use a QP-trie instead of an RBT, the locking can be cleaned up. (See [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7811#note_395512) in !7811.)
-After converting the NTA to use a QP-trie instead of an RBT, the locking can be cleaned up. (See [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7811#note_395512) in !7811.)
-BIND 9.19.xEvan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/4208deprecate 'dig +trace'2023-11-01T11:33:15ZEvan Huntdeprecate 'dig +trace'`delv +ns` (introduced in #3842) is a better choice now.
I figure we should issue a deprecation warning for `dig +trace` for now and then remove it in 9.22. Or, maybe just go ahead and remove it now?`delv +ns` (introduced in #3842) is a better choice now.
I figure we should issue a deprecation warning for `dig +trace` for now and then remove it in 9.22. Or, maybe just go ahead and remove it now?Not planned