BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-10-21T08:10:52Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2967Consider adding back resolver timers2021-10-21T08:10:52ZMatthijs Mekkingmatthijs@isc.orgConsider adding back resolver timers#2927 unveiled a cycle that would result in a hang, that previously was a timeout. Consider adding back timers, either with `isc_timers` or with the new network manager timers.#2927 unveiled a cycle that would result in a hang, that previously was a timeout. Consider adding back timers, either with `isc_timers` or with the new network manager timers.https://gitlab.isc.org/isc-projects/bind9/-/issues/2966logfileconfig system test is timing sensitive2021-10-27T13:11:20ZMark Andrewslogfileconfig system test is timing sensitiveDepending upon when the directories contents are sampled there can be 2 (log rollover in progress) or 3 old versions present for the timestamp subtest.Depending upon when the directories contents are sampled there can be 2 (log rollover in progress) or 3 old versions present for the timestamp subtest.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)https://gitlab.isc.org/isc-projects/bind9/-/issues/2965RPZ and /0 prefixes2021-11-09T17:33:50ZMark AndrewsRPZ and /0 prefixesOn quick examination of lib/dns/rpz.c it looks just removing the check for zero length prefixes is not enough to have them work.On quick examination of lib/dns/rpz.c it looks just removing the check for zero length prefixes is not enough to have them work.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2964Templates in the configuration2024-01-15T07:00:03ZOndřej SurýTemplates in the configurationThe zone should contain reusable chunks (something like yaml: `<< *foo`).The zone should contain reusable chunks (something like yaml: `<< *foo`).Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2963Assertion failure in dns_dispatch_gettcp2021-10-27T12:58:15ZOndřej SurýAssertion failure in dns_dispatch_gettcphttps://gitlab.isc.org/isc-projects/bind9/-/jobs/2057945
```
D:checkds:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D checkds-ns9 -X named.lock -'.
D:checkds:Program terminated with signal SIGABRT, Aborted.
D...https://gitlab.isc.org/isc-projects/bind9/-/jobs/2057945
```
D:checkds:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D checkds-ns9 -X named.lock -'.
D:checkds:Program terminated with signal SIGABRT, Aborted.
D:checkds:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:checkds:[Current thread is 1 (Thread 0x7f33c7431700 (LWP 13506))]
D:checkds:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:checkds:#1 0x00007f33cfaa3535 in __GI_abort () at abort.c:79
D:checkds:#2 0x00000000004665f3 in abort ()
D:checkds:#3 0x00000000004e2252 in assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>) at main.c:236
D:checkds:#4 0x00007f33d09eb11e in isc_assertion_failed (file=0x2 <error: Cannot access memory at address 0x2>, line=-952190400, line@entry=1147, type=isc_assertiontype_require, type@entry=isc_assertiontype_insist, cond=0x7f33cfab87bb <__GI_raise+267> "H\213\214$\b\001") at assertions.c:47
D:checkds:#5 0x00007f33d0747a3f in dns_dispatch_gettcp (mgr=<optimized out>, destaddr=destaddr@entry=0x7b3c00027ad0, localaddr=localaddr@entry=0x7f33c73ed440, connected=connected@entry=0x7f33c73ed3c7, dispp=dispp@entry=0x7b440001e690) at dispatch.c:1147
D:checkds:#6 0x00007f33d086da6b in tcp_dispatch (newtcp=<optimized out>, requestmgr=0x7b4c00011640, srcaddr=0x7f33c73ed440, destaddr=0x7b3c00027ad0, dscp=<optimized out>, connected=0x7f33c73ed3c7, dispatchp=0x7b440001e690) at request.c:401
D:checkds:#7 get_dispatch (tcp=<optimized out>, newtcp=<optimized out>, requestmgr=requestmgr@entry=0x7b4c00011640, srcaddr=srcaddr@entry=0x7f33c73ed440, destaddr=destaddr@entry=0x7b3c00027ad0, dscp=dscp@entry=-1, connected=0x7f33c73ed3c7, dispatchp=0x7b440001e690) at request.c:456
D:checkds:#8 0x00007f33d086f13d in dns_request_createvia (requestmgr=requestmgr@entry=0x7b4c00011640, message=message@entry=0x7b5000070800, srcaddr=srcaddr@entry=0x7f33c73ed440, destaddr=destaddr@entry=0x7b3c00027ad0, dscp=1, dscp@entry=-1, options=<optimized out>, options@entry=1, key=0x0, timeout=45, udptimeout=<optimized out>, udpretries=0, task=0x7b3000000900, action=0x7f33d09200f0 <checkds_done>, arg=0x7b3c00027ab0, requestp=0x7b3c00027ac8) at request.c:717
D:checkds:#9 0x00007f33d091ffc7 in checkds_send_toaddr (task=<optimized out>, event=<optimized out>) at zone.c:21280
D:checkds:#10 0x00007f33d0a1bb37 in task_run (task=<optimized out>) at task.c:827
D:checkds:#11 isc_task_run (task=<optimized out>) at task.c:907
D:checkds:#12 0x00007f33d09d5968 in isc__nm_async_task (worker=<optimized out>, ev0=ev0@entry=0x7b4800019080) at netmgr/netmgr.c:834
D:checkds:#13 0x00007f33d09cebe0 in process_netievent (worker=worker@entry=0x7ba000009c20, ievent=ievent@entry=0x7b4800019080) at netmgr/netmgr.c:908
D:checkds:#14 0x00007f33d09c8e39 in process_queue (worker=0x7ba000009c20, type=NETIEVENT_TASK) at netmgr/netmgr.c:1007
D:checkds:#15 process_all_queues (worker=0x7ba000009c20) at netmgr/netmgr.c:753
D:checkds:#16 async_cb (handle=0x7ba000009f80) at netmgr/netmgr.c:782
D:checkds:#17 0x00007f33d023b6d8 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:checkds:#18 0x00007f33d024a530 in uv.io_poll () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:checkds:#19 0x00007f33d023bff5 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:checkds:#20 0x00007f33d09c9056 in nm_thread (worker0=0x7ba000009c20) at netmgr/netmgr.c:688
D:checkds:#21 0x00007f33d0a2496a in isc__trampoline_run (arg=0x7b08000189a0) at trampoline.c:185
D:checkds:#22 0x0000000000460c8d in __tsan_thread_start_func ()
D:checkds:#23 0x00007f33cfde8fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
D:checkds:#24 0x00007f33cfb7a4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```November 2021 (9.16.23, 9.16.23-S1, 9.17.20)https://gitlab.isc.org/isc-projects/bind9/-/issues/2962Assertion failed in `dns_resolver_logfetch()`2022-07-15T11:44:10ZOndřej SurýAssertion failed in `dns_resolver_logfetch()`https://gitlab.isc.org/isc-projects/bind9/-/jobs/2057408
```
D:resolver:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D resolver-ns5 -X named.lock'.
8759D:resolver:Program terminated with signal SIGABRT, Abort...https://gitlab.isc.org/isc-projects/bind9/-/jobs/2057408
```
D:resolver:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D resolver-ns5 -X named.lock'.
8759D:resolver:Program terminated with signal SIGABRT, Aborted.
8760D:resolver:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
8761D:resolver:[Current thread is 1 (Thread 0x7f4643d7f700 (LWP 5704))]
8762D:resolver:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
8763D:resolver:#1 0x00007f4646f67535 in __GI_abort () at abort.c:79
8764D:resolver:#2 0x0000560317906076 in assertion_failed (file=0x7f4647dab44b "resolver.c", line=10543, type=isc_assertiontype_require, cond=0x7f4647dac878 "((fctx) != ((void *)0) && ((const isc__magic_t *)(fctx))->magic == ((('F') << 24 | ('!') << 16 | ('!') << 8 | ('!'))))") at main.c:236
8765D:resolver:#3 0x00007f4647f39a9d in isc_assertion_failed (file=0x7f4647dab44b "resolver.c", line=10543, type=isc_assertiontype_require, cond=0x7f4647dac878 "((fctx) != ((void *)0) && ((const isc__magic_t *)(fctx))->magic == ((('F') << 24 | ('!') << 16 | ('!') << 8 | ('!'))))") at assertions.c:47
8766D:resolver:#4 0x00007f4647cacff2 in dns_resolver_logfetch (fetch=0x7f460b4068e0, lctx=0x7f464440b800, category=0x7f4647a54230 <ns_categories+80>, module=0x7f4647a54290 <ns_modules+16>, level=4, duplicateok=false) at resolver.c:10543
8767D:resolver:#5 0x00007f4647a142ef in fetch_callback (task=0x7f4639ad70c0, event=0x7f460b88b300) at query.c:6242
8768D:resolver:#6 0x00007f4647f71680 in task_run (task=0x7f4639ad70c0) at task.c:827
8769D:resolver:#7 0x00007f4647f71941 in isc_task_run (task=0x7f4639ad70c0) at task.c:907
8770D:resolver:#8 0x00007f4647f13006 in isc__nm_async_task (worker=0x7f4644448240, ev0=0x7f4638397b80) at netmgr/netmgr.c:834
8771D:resolver:#9 0x00007f4647f1338a in process_netievent (worker=0x7f4644448240, ievent=0x7f4638397b80) at netmgr/netmgr.c:913
8772D:resolver:#10 0x00007f4647f14465 in process_queue (worker=0x7f4644448240, type=NETIEVENT_TASK) at netmgr/netmgr.c:1007
8773D:resolver:#11 0x00007f4647f12dab in process_all_queues (worker=0x7f4644448240) at netmgr/netmgr.c:753
8774D:resolver:#12 0x00007f4647f12e58 in async_cb (handle=0x7f46444485a0) at netmgr/netmgr.c:782
8775D:resolver:#13 0x00007f46475606d8 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
8776D:resolver:#14 0x00007f464756f530 in uv.io_poll () from /usr/lib/x86_64-linux-gnu/libuv.so.1
8777D:resolver:#15 0x00007f4647560ff5 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
8778D:resolver:#16 0x00007f4647f128da in nm_thread (worker0=0x7f4644448240) at netmgr/netmgr.c:688
8779D:resolver:#17 0x00007f4647f7bfe2 in isc__trampoline_run (arg=0x560318659d50) at trampoline.c:185
8780D:resolver:#18 0x00007f464710dfa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
8781D:resolver:#19 0x00007f464703e4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```August 2022 (9.16.32, 9.16.32-S1, 9.18.6, 9.19.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/2961CID 340477: Control flow issues (DEADCODE)2022-07-01T01:03:36ZMichal NowakCID 340477: Control flow issues (DEADCODE)It seems that 18cc459e05a9271e430b3384fb6fdaed92f6b25f made some of the code a dead code:
```
*** CID 340477: Control flow issues (DEADCODE)
/lib/dns/adb.c: 982 in import_rdataset()
976 }
977 nh = NULL;
978 result = d...It seems that 18cc459e05a9271e430b3384fb6fdaed92f6b25f made some of the code a dead code:
```
*** CID 340477: Control flow issues (DEADCODE)
/lib/dns/adb.c: 982 in import_rdataset()
976 }
977 nh = NULL;
978 result = dns_rdataset_next(rdataset);
979 }
980
981 if (nh != NULL) {
>>> CID 340477: Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "free_adbnamehook(adb, &nh);".
982 free_adbnamehook(adb, &nh);
983 }
984
985 if (addr_bucket != DNS_ADB_INVALIDBUCKET) {
986 UNLOCK(&adb->entrylocks[addr_bucket]);
987 }
```
Here's [Coverity Scan tracker](https://scan8.coverity.com/reports.htm#v38342/p12579/fileInstanceId=48005809&defectInstanceId=11803256&mergedDefectId=340477) for reference:Not plannedEvan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2960When a user requests a recordset, can bind9 perform a health check on whether...2021-10-20T05:20:15Zweijun linWhen a user requests a recordset, can bind9 perform a health check on whether the registered record set is reachable?### Description
I registered two record sets, such as
aaa.a 1.2.3.4 2.2.2.2 A
1.2.3.4 is actually a fake and unreachable.
2.2.2.2 is actually a normal address.
When I request the analysis of this recordset 'aaa.a' from bind9, can bi...### Description
I registered two record sets, such as
aaa.a 1.2.3.4 2.2.2.2 A
1.2.3.4 is actually a fake and unreachable.
2.2.2.2 is actually a normal address.
When I request the analysis of this recordset 'aaa.a' from bind9, can bind9 tell me which IP is normal?
### Request
(Describe the solution you'd like to see.)
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2959Remove support for signed 32-bit time_t2023-11-02T17:02:20ZOndřej SurýRemove support for signed 32-bit time_tNow there are couple of requirements:
* All user space must be compiled with a 64-bit time_t, which are supported in the musl-1.2 and glibc-2.32 releases, along with installed kernel headers from linux-5.6 or higher.
See for details: h...Now there are couple of requirements:
* All user space must be compiled with a 64-bit time_t, which are supported in the musl-1.2 and glibc-2.32 releases, along with installed kernel headers from linux-5.6 or higher.
See for details: https://lkml.org/lkml/2020/1/29/355?anz=webNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2958HZ45197 AF intermittently getting hanged2021-10-19T07:29:13Zapoorva maheshwariHZ45197 AF intermittently getting hangedHi Team,
Currently we are using Bind version 9.16.10,
My Query
I recently found that there is an issue with the 9.16.10 version. "Issue#2389 BIND 9.16.10: critical: xfrout.c:1643: INSIST(xfr->sends == 0) failed".
Can anyone please help...Hi Team,
Currently we are using Bind version 9.16.10,
My Query
I recently found that there is an issue with the 9.16.10 version. "Issue#2389 BIND 9.16.10: critical: xfrout.c:1643: INSIST(xfr->sends == 0) failed".
Can anyone please help me to understand the scenario when this issue will appear?
Note: We will upgrade soon but we ask for some quick work around, as customer has some outage due to this. This will help me to skip scenarios which may lead to the above issue.
Thanks in advance.https://gitlab.isc.org/isc-projects/bind9/-/issues/2957Comparison of integer expressions of different signedness in dispatch.c on il...2021-10-19T07:48:06ZMichal NowakComparison of integer expressions of different signedness in dispatch.c on illumosCompilation on OpenIndiana (illumos `c5ef4e1ed4`) produces the following warning:
```
In file included from ../../lib/isc/include/isc/list.h:14,
from ../../lib/isc/include/isc/types.h:30,
from ../../lib/...Compilation on OpenIndiana (illumos `c5ef4e1ed4`) produces the following warning:
```
In file included from ../../lib/isc/include/isc/list.h:14,
from ../../lib/isc/include/isc/types.h:30,
from ../../lib/isc/include/isc/mem.h:22,
from dispatch.c:21:
dispatch.c: In function 'dispatch_getnext':
dispatch.c:1432:18: warning: comparison of integer expressions of different signedness: 'int32_t' {aka 'int'} and 'unsigned int' [-Wsign-compare]
1432 | REQUIRE(timeout <= UINT16_MAX);
| ^~
../../lib/isc/include/isc/assertions.h:44:11: note: in definition of macro 'ISC_REQUIRE'
44 | ((void)((cond) || \
| ^~~~
dispatch.c:1432:2: note: in expansion of macro 'REQUIRE'
1432 | REQUIRE(timeout <= UINT16_MAX);
| ^~~~~~~
```
It seems to be related to the net manager dispatch branch, namely 8551ad026fe1232f23b2c2778e5d21ca0d785c19.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2956Change default for nsec3param to iterations 0 salt-length 02022-06-14T07:08:43ZMatthijs Mekkingmatthijs@isc.orgChange default for nsec3param to iterations 0 salt-length 0Following the guidance given in https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec3-guidance/
```
In short, for all zones, the recommended NSEC3 parameters are as
shown below:
; SHA-1, no extra iterations, empty salt:
;...Following the guidance given in https://datatracker.ietf.org/doc/draft-ietf-dnsop-nsec3-guidance/
```
In short, for all zones, the recommended NSEC3 parameters are as
shown below:
; SHA-1, no extra iterations, empty salt:
;
bcp.example. IN NSEC3PARAM 1 0 0 -
```November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2955Bad html generated for 9.11 doc on web site2022-03-01T09:46:14ZMark AndrewsBad html generated for 9.11 doc on web siteSee https://bind.isc.org/doc/arm/9.11/man.named.conf.html for example. White space is incorrect.See https://bind.isc.org/doc/arm/9.11/man.named.conf.html for example. White space is incorrect.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2954BIND 9 Dev PPA2021-11-18T22:48:19ZtriaticBIND 9 Dev PPAThe BIND 9 Dev PPA is missing packages for Ubuntu 21.10 (impish) which has now released.The BIND 9 Dev PPA is missing packages for Ubuntu 21.10 (impish) which has now released.https://gitlab.isc.org/isc-projects/bind9/-/issues/2953Resolver issues with refactored dispatch code2023-11-02T17:02:19ZMichał KępieńResolver issues with refactored dispatch codeThis issue attempts to describe various issues with resolver behavior
found after merging !4601 (#2401). Most of these issues are
intermittent, so it is important to keep track of them somewhere in
order to not forget that they exist. ...This issue attempts to describe various issues with resolver behavior
found after merging !4601 (#2401). Most of these issues are
intermittent, so it is important to keep track of them somewhere in
order to not forget that they exist. We should get to the bottom of all
of these issues before we release BIND 9.18.0.
1. [x] **Recursive Perflab tests cause the resolver to stop responding.**
This issue might be the simplest to start with because the behavior
observed seems to be consistent rather than intermittent. Namely,
all Perflab jobs which test a resolver seem to crank out a response
rate of some 70-120 kQPS at the beginning of the test and then...
the resolver stops responding indefinitely. While Perflab was not
designed with recursive tests in mind and therefore we can treat its
recursive results with a grain of salt, it certainly should not be
reporting zeros all over the place.
- https://perflab.isc.org/#/config/run/5bf195dd83ba91a870b2976f/
- https://perflab.isc.org/#/config/run/5cd6a166643076f6c1f6c26f/
- https://perflab.isc.org/#/config/run/5db74b6264458967f762143a/
- https://perflab.isc.org/#/config/run/5db74b7264458967f762143b/
- https://perflab.isc.org/#/config/run/5db74c2764458967f7621440/
- https://perflab.isc.org/#/config/run/5db74c3464458967f7621441/
(Resolved by !5500.)
2. [x] **`respdiff` tests are *sometimes* slow.**
Ever since we merged the dispatch branch, the `respdiff` tests
started failing *intermittently* for `main` (and only `main`)
because of timeouts.
- [job 2016337][1]: pass, ~2m30s per each 10,000 queries
- [job 2016622][2]: pass, ~2m45s per each 10,000 queries
- [job 2017990][3]: pass, ~2m30s per each 10,000 queries
- [job 2020093][4]: fail, 7+ minutes per each 10,000 queries
- [job 2023057][5]: fail, 16+ minutes per each 10,000 queries
- [job 2023490][6]: pass, ~2m40s per each 10,000 queries
I do not think varying CI runner stress can be blamed for this, not
for discrepancies this large. It also never happened before merging
!4601, AFAIK.
3. [x] **A lot of "stress" test graph indicate growing memory use.** #3002
While testing October BIND 9 releases, one of the 1-hour "stress"
tests ran in recursive mode for BIND 9.17.19 yielded a graph which
indicates that memory use growth over time might be an issue.
https://wiki.isc.org/bin/viewfile/QA/BindQaResults_9_11_36?filename=bind-9.17.19-linux-amd64-recursive-1h.png;rev=1
However, that phenomenon was not observable for other OS/arch
combinations this specific code revision was tested with.
It was also not observable on the *same* OS/arch combination for a
very similar code revision (the code differences should not have any
effect on memory use patterns):
https://wiki.isc.org/bin/viewfile/QA/BindQaResults_9_11_36?filename=bind-9.17.19-linux-amd64-recursive-1h.png;rev=2
Pre-release tests run for BIND 9.17.20 confirmed that memory leaks
are a common thing when `named` is used as a recursive resolver.
More details are available in #3002.
The "stress" tests are run on isolated VMs and despite being pretty
synthetic (fixed traffic pattern, everything happens on one machine,
etc.), they have a history of being very stable, so typical issues
like test host load varying over time etc. are not a factor here.
4. [x] **Lame servers with IPv6 unreachable cause hang on shutdown.** #2927
5. [x] **resolver test fails intermittently** #3013
See https://gitlab.isc.org/isc-projects/bind9/-/jobs/2054296
```
I:resolver:query count error: 6 NS records: expected queries 10, actual 11
I:resolver:failed
```
6. [x] **Assertion failed in `dns_resolver_logfetch()`** #2962
7. [x] **Assertion failed in `dns_dispatch_gettcp()`** #2963
8. [x] **Assertion failed in `dns_resolver_destroyfetch()`** #2969
9. [x] **ThreadSanitizer issues with adb** #2978 #2979
10. [x] **fctx_cancelquery() attempts to process a query which has already been freed** #3018
11. [x] **premature TCP connection closure leaks fetch contexts (hang on shutdown)** #3026
12. [ ] **validator loops can cause shutdown hang** #3033
13. [ ] **ADB finds for a broken zone may cause fetch contexts to hang** #3037
14. [ ] **ASAN error in fctx_cancelquery()** #3102
I decided to open a single issue for all of the above problems because I
sense they are somehow related and I hope that fixing the root cause of
one of them will eliminate the other ones as well.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2016337
[2]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2016622
[3]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2017990
[4]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2020093
[5]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2023057
[6]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2023490Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2952Remove manual branch prediction using __builtin_expect()2021-10-27T11:44:50ZOndřej SurýRemove manual branch prediction using __builtin_expect()A recent [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5476#note_241185) on a MR has sparkled interesting question: Are the software developers better at guessing which branch is more likely to happen and does i...A recent [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5476#note_241185) on a MR has sparkled interesting question: Are the software developers better at guessing which branch is more likely to happen and does it help with performance? The GCC documentation on [`__builtin_expect()`](https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fexpect) says:
> In general, you should prefer to use actual profile feedback for this (`-fprofile-arcs`), as programmers are notoriously bad at predicting how their programs actually perform. However, there are applications in which this data is hard to collect.
Turns out that the documentation was right, we are notoriously bad at predicting how our program actually perform.
In the authoritative scenarios in the perflab, the (lo-hi from the last 15) results are:
| Scenario | `main` | no-expect. |
| --- | --- | --- |
| 1k zones. | 991,710 - 1,001,476 | 985,835 - 992,007 |
| 1M delegations | 918,952 - 943,186 | 953,149 - 969,046 |
| 1M RRs | 946,390 - 973,202 | 966,150 - 993,660 |
| 1M zones | 963,561 - 991,627 | 984,624 - 998,857 |
| root zone | 427,566 - 469,889 | 460,026 - 473,576 |
In the recursive scenarios, the branch with disabled `__builtin_expect()` surpases the `main` branch:
![_allruns-latency-since_30-until_60](/uploads/dcbc799e6a7e2dd2e0f2b495e7deae2a/_allruns-latency-since_30-until_60.png)
![_allruns-latency-since_30-until_60](/uploads/52914286ee3aa75db15694c06c2d7c24/_allruns-latency-since_30-until_60.png)November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2951assertion failure in req_senddone2022-01-21T07:32:54ZMark Andrewsassertion failure in req_senddoneJob [#2037401](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2037401) failed for c177c33c2773d7efa4b5af5460fd354450529d05:
```
D:checkds:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D checkds-ns9 -X named.l...Job [#2037401](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2037401) failed for c177c33c2773d7efa4b5af5460fd354450529d05:
```
D:checkds:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D checkds-ns9 -X named.lock -'.
D:checkds:Program terminated with signal SIGABRT, Aborted.
D:checkds:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:checkds:[Current thread is 1 (Thread 0x7f81a97fa700 (LWP 1941))]
D:checkds:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:checkds:#1 0x00007f81b069e535 in __GI_abort () at abort.c:79
D:checkds:#2 0x0000000000420cac in assertion_failed (file=0x7f81b12ee461 "request.c", line=<optimized out>, type=<optimized out>, cond=<optimized out>) at main.c:237
D:checkds:#3 0x00007f81b1372b7a in isc_assertion_failed (file=0x2 <error: Cannot access memory at address 0x2>, line=-1451276416, line@entry=1029, type=type@entry=isc_assertiontype_require, cond=0x7f81b06b37bb <__GI_raise+267> "H\213\214$\b\001") at assertions.c:47
D:checkds:#4 0x00007f81b123b4e2 in req_senddone (eresult=<optimized out>, region=<optimized out>, arg=<optimized out>) at request.c:1029
D:checkds:#5 0x00007f81b11727f6 in send_done (handle=0x7f819db70d80, result=ISC_R_CANCELED, cbarg=<optimized out>) at dispatch.c:1770
D:checkds:#6 0x00007f81b1363b7f in isc__nm_async_sendcb (worker=<optimized out>, ev0=ev0@entry=0x7f81a5843580) at netmgr/netmgr.c:2788
D:checkds:#7 0x00007f81b13603c6 in process_netievent (worker=worker@entry=0x7f81adc4a030, ievent=ievent@entry=0x7f81a5843580) at netmgr/netmgr.c:960
D:checkds:#8 0x00007f81b135baf1 in process_queue (worker=0x7f81adc4a030, type=NETIEVENT_NORMAL) at netmgr/netmgr.c:998
D:checkds:#9 process_all_queues (worker=0x7f81adc4a030) at netmgr/netmgr.c:746
D:checkds:#10 async_cb (handle=0x7f81adc4a390) at netmgr/netmgr.c:775
D:checkds:#11 0x00007f81b0c976d8 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:checkds:#12 0x00007f81b0ca6530 in uv.io_poll () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:checkds:#13 0x00007f81b0c97ff5 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:checkds:#14 0x00007f81b135bc39 in nm_thread (worker0=0x7f81adc4a030) at netmgr/netmgr.c:681
D:checkds:#15 0x00007f81b13a1aea in isc__trampoline_run (arg=0x1948b00) at trampoline.c:185
D:checkds:#16 0x00007f81b0844fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
D:checkds:#17 0x00007f81b07754cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
```
Thread 1 (Thread 0x7f81a97fa700 (LWP 1941)):
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
set = {__val = {16387, 0, 0, 0, 3905522674892552757, 140195000463360, 140195000513668, 140195000691568, 140195006326720, 140194998247424, 0, 140194998247424, 140194871224000, 140194942605624, 140194942605616, 5}}
pid = <optimized out>
tid = <optimized out>
ret = <optimized out>
#1 0x00007f81b069e535 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x7f81b0c5e900, sa_sigaction = 0x7f81b0c5e900}, sa_mask = {__val = {140194987098112, 140194987177249, 140194988119184, 140195000149089, 140194871199616, 31, 1483, 140194175012544, 13, 140194993269024, 17674366533170704384, 206158430256, 4575977, 140195000149089, 14, 206158430248}}, sa_flags = -1451275824, sa_restorer = 0xe}
sigs = {__val = {32, 0 <repeats 15 times>}}
#2 0x0000000000420cac in assertion_failed (file=0x7f81b12ee461 "request.c", line=<optimized out>, type=<optimized out>, cond=<optimized out>) at main.c:237
tracebuf = {0x420cc4 <assertion_failed+148>, 0x7f81b1372b7a <isc_assertion_failed+10>, 0x7f81b123b4e2 <req_senddone+450>, 0x7f81b11727f6 <send_done+54>, 0x7f81b1363b7f <isc__nm_async_sendcb+143>, 0x7f81b13603c6 <process_netievent+1222>, 0x7f81b135baf1 <async_cb+145>, 0x7f81b0c976d8, 0x7f81b0ca6530 <uv.io_poll+800>, 0x7f81b0c97ff5 <uv_run+277>, 0x7f81b135bc39 <nm_thread+121>, 0x7f81b13a1aea <isc__trampoline_run+74>, 0x7f81b0844fa3 <start_thread+243>, 0x7f81b07754cf <clone+63>, 0x7f81b07754cf <clone+63>, 0x0, 0x0, 0x405, 0x7f81b12ee461, 0x7f81a576f990, 0x7f81b0679668, 0x7f819c2b4e00, 0x7f81adc4a030, 0x7f81b18e2b00 <_dl_fixup+208>, 0x5, 0xffff00001f80, 0x7f816e473000, 0xa0, 0x7f819ca05748, 0x7f81a97f4e10, 0x0, 0x7f81a97f9080, 0x7f819ca05708, 0x7f81b043efaf, 0x7f81ade5f740, 0x7f81adea5040, 0x7f81adedc6c0, 0x7f81adedc6c0, 0x7f81adedc6c0, 0x7f81adedd340, 0x7f81adedd340, 0x7f81adedd440, 0xdededededededede, 0xdededededededede, 0xff00ffff00ff00, 0xff00ff00ff00ff, 0xff000000, 0x0, 0x3036346536313866, 0x756873203a303034, 0x0, 0x10, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7325732500732520, 0x7325732573257325, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x4200000042, 0x4200000042, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7f81adc09000, 0x7f816e460400, 0x7f81b138437b <isc__mem_put+171>, 0x0, 0x7f816e460400, 0x7f819da00000, 0x7f816e460410, 0x0, 0x1, 0x7f816e460560, 0x7f816e460410, 0x2, 0x800000000000000e, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x7f81a97f4e70, 0x7f81b1171054 <tcp_recv+1828>, 0x7f81a56e2000, 0x700350a1f640002, 0x0 <repeats 15 times>, 0x10, 0xffffffffffffffff, 0xffffffffffffffff, 0x700350a1f640002, 0x0, 0x0, 0x0, 0x0, 0xf547f6b817b13000, 0x0, 0x7f81adc09000, 0x7f81a97f4e10, 0x7f81b13ac7a8, 0x7b0, 0x7f81adc09008}
nframes = <optimized out>
#3 0x00007f81b1372b7a in isc_assertion_failed (file=0x2 <error: Cannot access memory at address 0x2>, line=-1451276416, line@entry=1029, type=type@entry=isc_assertiontype_require, cond=0x7f81b06b37bb <__GI_raise+267> "H\213\214$\b\001") at assertions.c:47
No locals.
#4 0x00007f81b123b4e2 in req_senddone (eresult=<optimized out>, region=<optimized out>, arg=<optimized out>) at request.c:1029
request = <optimized out>
#5 0x00007f81b11727f6 in send_done (handle=0x7f819db70d80, result=ISC_R_CANCELED, cbarg=<optimized out>) at dispatch.c:1770
resp = 0x0
#6 0x00007f81b1363b7f in isc__nm_async_sendcb (worker=<optimized out>, ev0=ev0@entry=0x7f81a5843580) at netmgr/netmgr.c:2788
ievent = <optimized out>
sock = 0x7f816e473000
uvreq = 0x0
eresult = ISC_R_CANCELED
#7 0x00007f81b13603c6 in process_netievent (worker=worker@entry=0x7f81adc4a030, ievent=ievent@entry=0x7f81a5843580) at netmgr/netmgr.c:960
No locals.
#8 0x00007f81b135baf1 in process_queue (worker=0x7f81adc4a030, type=NETIEVENT_NORMAL) at netmgr/netmgr.c:998
waiting = 4
ievent = 0x7f81a5843580
stop = <optimized out>
#9 process_all_queues (worker=0x7f81adc4a030) at netmgr/netmgr.c:746
result = <optimized out>
type = 3
reschedule = true
type = <optimized out>
result = <optimized out>
#10 async_cb (handle=0x7f81adc4a390) at netmgr/netmgr.c:775
worker = 0x7f81adc4a030
#11 0x00007f81b0c976d8 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#12 0x00007f81b0ca6530 in uv.io_poll () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#13 0x00007f81b0c97ff5 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#14 0x00007f81b135bc39 in nm_thread (worker0=0x7f81adc4a030) at netmgr/netmgr.c:681
r = <optimized out>
worker = 0x7f81adc4a030
mgr = 0x7f81adc45000
#15 0x00007f81b13a1aea in isc__trampoline_run (arg=0x1948b00) at trampoline.c:185
trampoline = 0x1948b00
result = <optimized out>
#16 0x00007f81b0844fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
ret = <optimized out>
pd = <optimized out>
now = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140194871224064, -130959809494454272, 140721831580654, 140721831580655, 140194871224064, 26512128, 84985927855435776, 84967749757497344}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#17 0x00007f81b07754cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.
```January 2022 (9.18.0)https://gitlab.isc.org/isc-projects/bind9/-/issues/2950[CVE-2021-25220] DNS Cache Poisoning Vulnerability2022-11-10T08:15:18ZOndřej Surý[CVE-2021-25220] DNS Cache Poisoning Vulnerability### CVE-specific actions
- [x] Assign a CVE identifier: CVE-2021-25220
- [x] Determine CVSS score: [6.8](https://mattermost.isc.org/isc/pl/esax9emkd7fxdxqxm99zaz9azw): CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:H/A:N/E:U/RL:U/RC:C
- ...### CVE-specific actions
- [x] Assign a CVE identifier: CVE-2021-25220
- [x] Determine CVSS score: [6.8](https://mattermost.isc.org/isc/pl/esax9emkd7fxdxqxm99zaz9azw): CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:H/A:N/E:U/RL:U/RC:C
- [x] Determine the range of BIND [versions affected](https://gitlab.isc.org/isc-projects/bind9/-/issues/2950#note_243838) (including the Subscription Edition)
- [x] Determine whether [workarounds](https://gitlab.isc.org/isc-projects/bind9/-/issues/2950#note_243853) for the problem exists: No
- [x] Create a draft of the security advisory and put the information above in there (+ add [credits](https://gitlab.isc.org/isc-projects/bind9/-/issues/2950#note_244651))
- [x] Prepare a detailed description of the problem which should include the following by default:
- instructions for [reproducing the problem](https://gitlab.isc.org/isc-projects/bind9/-/issues/2950#note_243791) (a system test is good enough)
- explanation of [code flow](https://gitlab.isc.org/isc-projects/bind9/-/issues/2950#note_244624) which triggers the problem (a system test is *not* good enough)
- [x] Prepare a private merge request containing the following items in separate commits:
- a test for the issue (may be moved to a separate merge request for deferred merging)
- a fix for the issue
- documentation updates (`CHANGES`, release notes, anything else applicable)
- [x] Ensure the merge request from the previous step is reviewed by SWENG staff and has no outstanding discussions
- [x] Ensure the documentation changes introduced by the merge request addressing the problem are reviewed by Support and Marketing staff
- [x] Prepare backports of the merge request addressing the problem for all affected (and still maintained [+ this time also v9.11](https://gitlab.isc.org/isc-projects/bind9/-/issues/2950#note_243881)) BIND branches (backporting might affect the issue's scope and/or description)
- [x] Prepare a standalone patch for the last stable release of each affected (and still maintained) BIND branch
### Release-specific actions
- [x] [Create/update the private issue containing links to fixes & reproducers for all CVEs fixed in a given release cycle](isc-private/bind9#49)
- [x] [Reserve a block of `CHANGES` placeholders once the complete set of vulnerabilities fixed in a given release cycle is determined](!5925)
- [x] Ensure the merge requests containing CVE fixes are merged into `security-*` branches in CVE identifier order
### Post-disclosure actions
- [x] Merge a regression test reproducing the bug into all affected (and still maintained) BIND branches
# Report: DNS Cache Poisoning Vulnerability
By Xiang Li from Network and Information Security Laboratory, Tsinghua University
On Oct 10, 2021
## Overview
We found a vulnerability in the bailiwick checking procedure of your resolver, which allows specific attackers to inject NS records of any domain (even TLDs) into the cache and conduct a DNS cache poisoning attack. The effects of an exploit would be widespread and highly impactful, as this injection could hijack any subdomain under the poisoned domain, including TLDs, e.g., com and net .
## Vulnerability Details
When the resolver is configured with a conditional forwarding zone and a forwarder, it will query all domains under the zone targeting the forwarder. For example, we give a brief config file in the following, where queries of any domain under `attacker.com` will be sent directly to `x.x.x.x` for resolution. While for the other domains, they are processed by the resolver itself through recursive queries, such as `com` and `victim.com`.
```
options {
recursion yes;
dnssec-validation yes; // this is not sufficient to enable DNSSEC validation - keys are missing!
};
zone "attacker.com" {
type forward;
forwarders { x.x.x.x port 53; };
};
```
If an attacker query A records of `x.attacker.com`, and the resolver receives a response with an AA flag in the following. The bogus `NS` records of com will be cached. As a result, queries of any domain under `com` in the future will be sent directly to the fake name server `ns.attacker.com`, thus hijacked by attackers.
| Field | Value |
|------------|---------------------------|
| Question | x.attacker.com A |
| Answer | x.attacker.com A 1.2.3.4 |
| Authority | com NS ns.attacker.com |
## Root Cause Analysis
Through source code review, we locate the root cause of the vulnerability.
Specifically, `Query.zone` is the key to bailiwick checking logic. Any resource records whose name is not under or same as `Query.zone` during responses processing will be removed.
However, when forwarding, `Query.zone` is initialized with the "closest" name of NS records following the recursive resolution process.
As for the forwarding zone, there are no directly corresponding `NS` records. Therefore, for example, when querying `attacker.com`, `Query.zone` is com or the root `.`.
Consequently, the fake domain is under `com` and `.`, which is considered to be in-bailiwick.
## Proof-of-Concept
We give two exploiting methods and show our real attack videos in the [link](https://cloud.tsinghua.edu.cn/d/faddf16c281e41a7b216/) with password: `bind_attack_pre_21`.
For ethical considerations, we build the whole DNS testing environment, including the attacker machine, the conditional DNS server, the upstream resolver, and our authoritative server. And we use `attacker.attack` as an example domain to attack NS records of `com`.
1. If the forwarder `x.x.x.x` is held by an attacker, he can return the bogus response directly from the authoritative server. We show our attack steps below, and the video is named `bind_attack_fd.mp4` in the folder.
1. From 00:00, we show the latest BIND version.
2. From 00:05, we start BIND.
3. From 00:10, we query `github.com` and obtain correct `com` `NS` records through recursive queries.
4. From 00:20, we query the forwarded domain `attacker.attack` and receive fake com `NS` records.
5. From 00:28, bingo, fake `com` `NS` records are cached successfully.
2. If the forwarder `x.x.x.x` is not held by an attacker, he should inject the bogus response directly from the off-path. And we leverage the SAD DNS attack to poison the resolver successfully. We show our attack steps below, and the video is named `bind_attack_fu.mp4` in the folder.
1. From 00:00, we show the latest BIND version and Linux version.
2. From 00:06, we start BIND.
3. From 00:11, we query `github.com` and obtain correct `com` `NS` records through recursive queries.
4. From 00:21, we query the forwarded domain `[random_prefix].attacker.attack` and start [SAD DNS](https://www.saddns.net/) attacks.
5. From 33:10, bingo, after 1,642 attempts costing 1,970s, fake `com` `NS` records are cached successfully.
## Threat Surface
We test the latest version 9.16.21, until Oct. 10, 2021, which is vulnerable.
## Mitigation
Consider setting Query.zone with the forwarding zone, such as attacker.com .
## Attachments
* [Report_-_DNS_Cache_Poisoning_Vulnerability_of_BIND.pdf](/uploads/f7e07b5bf026bec7f875dea6fd4f9b42/Report_-_DNS_Cache_Poisoning_Vulnerability_of_BIND.pdf)March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2949statistics-channel displays zone type 'master' i/o 'primary' in Zones for View2021-10-12T09:57:37ZJP Mensstatistics-channel displays zone type 'master' i/o 'primary' in Zones for ViewBIND's `statistics-channels` Web page at URI `/xml/v3/zones` displays zone type "master" instead of "primary" and "slave" i/o "secondary".
![rabbit-8451](/uploads/ea9ab9190da1009f87e818f5629a30f4/rabbit-8451.png)
```
statistics-channel...BIND's `statistics-channels` Web page at URI `/xml/v3/zones` displays zone type "master" instead of "primary" and "slave" i/o "secondary".
![rabbit-8451](/uploads/ea9ab9190da1009f87e818f5629a30f4/rabbit-8451.png)
```
statistics-channels {
inet * port 80 allow { any; };
};
zone "zone100.dnslab.org" {
type primary;
file "zone100.dnslab.org";
};
zone "zone101.dnslab.org" {
type secondary;
file "zone101.dnslab.org";
primaries { 2604:a880:cad:d0::d6d:f001; };
};
```
The `/json` URI uses the same data, so suffers from the same issue:
```json
"zones":[
{
"name":"zone100.dnslab.org",
"class":"IN",
"serial":1019,
"type":"master",
"loaded":"2021-10-11T20:48:12Z",
```
```
BIND 9.16.21 (Extended Support Version) <id:a8aa450>
installed from ISC copr repository.
```https://gitlab.isc.org/isc-projects/bind9/-/issues/2948DNSSEC signing statistics do not account for cross-algorithm key ID collisions2023-11-02T17:02:19ZMichał KępieńDNSSEC signing statistics do not account for cross-algorithm key ID collisionsIn https://gitlab.isc.org/isc-private/bind9/-/jobs/2033550, two signing
keys for different signing algorithms have the same key ID:
```
>>> 11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/RSASHA256/51742 (policy manykeys)
11-Oct-...In https://gitlab.isc.org/isc-private/bind9/-/jobs/2033550, two signing
keys for different signing algorithms have the same key ID:
```
>>> 11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/RSASHA256/51742 (policy manykeys)
11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/ECDSAP384SHA384/951 (policy manykeys)
11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/RSASHA256/37386 (policy manykeys)
>>> 11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/ECDSAP256SHA256/51742 (policy manykeys)
11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/ECDSAP256SHA256/23421 (policy manykeys)
11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/ECDSAP384SHA384/8256 (policy manykeys)
```
While this situation is not considered a key ID collision (because
different algorithms are involved), it messes up the XML/JSON statistics
because these are not keyed by the `<algorithm, ID>` tuple but rather
just by the key ID. In the `statschannel` system test, the
`zones-{json,xml}.pl` helper scripts only process *unique* key IDs,
leaving duplicate entries out of their output files. In this specific
example, this led to:
```diff
$ diff -u zones.expect.8 zones.out.x8
--- zones.expect.8 2021-10-11 23:30:21.000000000 +0200
+++ zones.out.x8 2021-10-11 23:30:23.000000000 +0200
@@ -1,12 +1,10 @@
dnssec-refresh operations 23421: 1
dnssec-refresh operations 37386: 10
dnssec-refresh operations 51742: 1
-dnssec-refresh operations 51742: 10
dnssec-refresh operations 8256: 1
dnssec-refresh operations 951: 10
dnssec-sign operations 23421: 1
dnssec-sign operations 37386: 10
dnssec-sign operations 51742: 1
-dnssec-sign operations 51742: 10
dnssec-sign operations 8256: 1
dnssec-sign operations 951: 10
```Not planned