BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-11-03T14:35:18Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2998CID 340918: Uninitialized variables (UNINIT)2021-11-03T14:35:18ZMichal NowakCID 340918: Uninitialized variables (UNINIT)It seems to point to 78066157145b6a75f58ff843ac32ffabe62b2143:
```
790 static isc_result_t
791. opensslrsa_tofile(const dst_key_t *key, const char *directory) {
792 isc_result_t ret;
1. var_decl: Declaring variable p...It seems to point to 78066157145b6a75f58ff843ac32ffabe62b2143:
```
790 static isc_result_t
791. opensslrsa_tofile(const dst_key_t *key, const char *directory) {
792 isc_result_t ret;
1. var_decl: Declaring variable priv without initializer.
793 dst_private_t priv;
794 unsigned char *bufs[8] = { NULL };
795 unsigned short i = 0;
796 EVP_PKEY *pkey;
797. #if OPENSSL_VERSION_NUMBER < 0x30000000L
798 RSA *rsa = NULL;
799 const BIGNUM *n = NULL, *e = NULL, *d = NULL;
800 const BIGNUM *p = NULL, *q = NULL;
801 const BIGNUM *dmp1 = NULL, *dmq1 = NULL, *iqmp = NULL;
802 #else
803 BIGNUM *n = NULL, *e = NULL, *d = NULL;
804 BIGNUM *p = NULL, *q = NULL;
805 BIGNUM *dmp1 = NULL, *dmq1 = NULL, *iqmp = NULL;
806. #endif /* OPENSSL_VERSION_NUMBER < 0x30000000L */
807
2. Condition key->keydata.pkey == NULL, taking true branch.
808 if (key->keydata.pkey == NULL) {
3. Jumping to label err.
809 DST_RET(DST_R_NULLKEY);
810 }
```
```
*** CID 340918: Uninitialized variables (UNINIT)
/lib/dns/opensslrsa_link.c: 937 in opensslrsa_tofile()
931 priv.nelements = i;
932 ret = dst__privstruct_writefile(key, &priv, directory);
933
934 err:
935 for (i = 0; i < ARRAY_SIZE(bufs); i++) {
936 if (bufs[i] != NULL) {
>>> CID 340918: Uninitialized variables (UNINIT)
>>> Using uninitialized value "priv.elements[i].length" when calling "isc__mem_put".
937 isc_mem_put(key->mctx, bufs[i],
938 priv.elements[i].length);
939 }
940 }
941 #if OPENSSL_VERSION_NUMBER < 0x30000000L
942 RSA_free(rsa);
```November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2993Replace instances of ARRAYSIZE with ARRAY_SIZE2021-11-02T15:03:50ZMark AndrewsReplace instances of ARRAYSIZE with ARRAY_SIZEARRAY_SIZE is defined in isc/util.h if not already defined by the host systemARRAY_SIZE is defined in isc/util.h if not already defined by the host systemNovember 2021 (9.16.23, 9.16.23-S1, 9.17.20)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2991Address reports by Coverity in updated OpenSSL code !53852021-11-02T14:49:08ZMark AndrewsAddress reports by Coverity in updated OpenSSL code !5385```
** CID 340808: Control flow issues (DEADCODE)
/lib/dns/openssldh_link.c: 1209 in openssldh_parse()
________________________________________________________________________________________________________
*** CID 340808: Control ...```
** CID 340808: Control flow issues (DEADCODE)
/lib/dns/openssldh_link.c: 1209 in openssldh_parse()
________________________________________________________________________________________________________
*** CID 340808: Control flow issues (DEADCODE)
/lib/dns/openssldh_link.c: 1209 in openssldh_parse()
1203 key->key_size = (unsigned int)key_size;
1204 ret = ISC_R_SUCCESS;
1205
1206 err:
1207 #if OPENSSL_VERSION_NUMBER < 0x30000000L
1208 if (dh != NULL) {
CID 340808: Control flow issues (DEADCODE)
Execution cannot reach this statement: "DH_free(dh);".
1209 DH_free(dh);
1210 }
1211 #else
1212 if (pkey != NULL) {
1213 EVP_PKEY_free(pkey);
1214 }
```
```
** CID 340807: (OVERRUN)
/lib/dns/opensslrsa_link.c: 931 in opensslrsa_tofile()
/lib/dns/opensslrsa_link.c: 930 in opensslrsa_tofile()
/lib/dns/opensslrsa_link.c: 931 in opensslrsa_tofile()
________________________________________________________________________________________________________
*** CID 340807: (OVERRUN)
/lib/dns/opensslrsa_link.c: 931 in opensslrsa_tofile()
925 priv.nelements = i;
926 ret = dst__privstruct_writefile(key, &priv, directory);
927
928 err:
929 while (i--) {
930 if (bufs[i] != NULL) {
CID 340807: (OVERRUN)
Overrunning array "bufs" of 8 8-byte elements at element index 9 (byte offset 79) using index "i" (which evaluates to 9).
931 isc_mem_put(key->mctx, bufs[i],
932 priv.elements[i].length);
933 }
934 }
935 #if OPENSSL_VERSION_NUMBER < 0x30000000L
936 RSA_free(rsa);
/lib/dns/opensslrsa_link.c: 930 in opensslrsa_tofile()
924
925 priv.nelements = i;
926 ret = dst__privstruct_writefile(key, &priv, directory);
927
928 err:
929 while (i--) {
CID 340807: (OVERRUN)
Overrunning array "bufs" of 8 8-byte elements at element index 9 (byte offset 79) using index "i" (which evaluates to 9).
930 if (bufs[i] != NULL) {
931 isc_mem_put(key->mctx, bufs[i],
932 priv.elements[i].length);
933 }
934 }
935 #if OPENSSL_VERSION_NUMBER < 0x30000000L
/lib/dns/opensslrsa_link.c: 931 in opensslrsa_tofile()
925 priv.nelements = i;
926 ret = dst__privstruct_writefile(key, &priv, directory);
927
928 err:
929 while (i--) {
930 if (bufs[i] != NULL) {
CID 340807: (OVERRUN)
Overrunning array "bufs" of 8 8-byte elements at element index 9 (byte offset 79) using index "i" (which evaluates to 9).
931 isc_mem_put(key->mctx, bufs[i],
932 priv.elements[i].length);
933 }
934 }
935 #if OPENSSL_VERSION_NUMBER < 0x30000000L
936 RSA_free(rsa);
```November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2985Release Checklist for BIND 9.16.23, 9.16.23-S1, 9.17.202022-03-01T08:22:19ZMichał KępieńRelease Checklist for BIND 9.16.23, 9.16.23-S1, 9.17.20## Release Schedule
**Code Freeze:** Wednesday, November 3rd, 2021
**Tagging Deadline:** Monday, November 8th, 2021
**Public Release:** Wednesday, November 17th, 2021
## Documentation Review Links
**Closed issues assigned to the mil...## Release Schedule
**Code Freeze:** Wednesday, November 3rd, 2021
**Tagging Deadline:** Monday, November 8th, 2021
**Public Release:** Wednesday, November 17th, 2021
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.17.20](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&state=closed&milestone_title=November%202021%20(9.16.23%2C%209.16.23-S1%2C%209.17.20)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.17)
- [9.16.23](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&state=closed&milestone_title=November%202021%20(9.16.23%2C%209.16.23-S1%2C%209.17.20)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.16)
**Merge requests merged into the milestone without a release note:**
- [9.17.20](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&state=merged&milestone_title=November%202021%20(9.16.23%2C%209.16.23-S1%2C%209.17.20)¬[label_name][]=Release%20Notes&target_branch=main)
- [9.16.23](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&state=merged&milestone_title=November%202021%20(9.16.23%2C%209.16.23-S1%2C%209.17.20)¬[label_name][]=Release%20Notes&target_branch=v9_16)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.17.20](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&state=merged&milestone_title=November%202021%20(9.16.23%2C%209.16.23-S1%2C%209.17.20)&label_name[]=No%20CHANGES&target_branch=main)
- [9.16.23](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&state=merged&milestone_title=November%202021%20(9.16.23%2C%209.16.23-S1%2C%209.17.20)&label_name[]=No%20CHANGES&target_branch=v9_16)
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Inform Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform.
- [x] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
- [x] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [x] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only).
- [x] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is in effect.
### Before the Tagging Deadline
- [x] ***(QA)*** Look for outstanding documentation issues (e.g. `CHANGES` mistakes) and address them if any are found.
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
- [x] ***(QA)*** Update API files for libraries with new version information.
- [x] ***(QA)*** Change software version and library versions in `configure.ac` (new major release only).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
- [x] ***(QA)*** Update `CHANGES`.
- [x] ***(QA)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ***(QA)*** Update `README.md`.
- [x] ***(QA)*** Update `version`.
- [x] ***(QA)*** Build documentation on `docs.isc.org`.
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Tag the releases in the private repository (`git tag -s -m "BIND 9.x.y" v9_x_y`).
### Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Verify GitLab CI results for the tags created and prepare a QA report for the releases to be published.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is over.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again.
- [x] ***(Support)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages.
- [x] ***(QA)*** Notify Support that the releases have been prepared.
- [x] ***(Support)*** Send out ASNs (if applicable).
### On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *bind-announce*.
- [x] ***(Support)*** Write email to *bind-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription Edition (update the -S edition delivery tickets, even if those links were provided earlier via an ASN ticket).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages.
- [x] ***(QA)*** Build public RPMs.
- [x] ***(SwEng)*** Build Debian/Ubuntu packages.
- [x] ***(SwEng)*** Update Docker images.
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(QA)*** Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made.
- [x] ***(Marketing)*** Post short note to Twitter.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(QA)*** Ensure all new tags are annotated and signed.
- [x] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Merge the automatically prepared `prep 9.x.y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_x`).
- [x] ***(QA)*** For each maintained branch, update the `BIND_BASELINE_VERSION` variable for the `abi-check` job in `.gitlab-ci.yml` to the latest published BIND version tag for a given branch.
- [x] ***(QA)*** Prepare empty release notes for the next set of releases.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate[^2].
- [x] ***(QA)*** Update QA tools used in GitLab CI (e.g. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.
[^2]: As a rule of thumb, security vulnerabilities which have reproducers merged to the public repository are considered okay for full disclosure.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)2021-11-17https://gitlab.isc.org/isc-projects/bind9/-/issues/2976Restore 'xsltproc' discovery for statistics system test 9.162021-11-02T14:58:34ZMark AndrewsRestore 'xsltproc' discovery for statistics system test 9.16xsltproc is used by the statistics system test and its discovery was removed in the transition to sphinx for documents.
```
I:statistics:checking bind9.xsl vs xml (16)
I:statistics:skipping test as libxml2 and/or curl and/or xsltproc wa...xsltproc is used by the statistics system test and its discovery was removed in the transition to sphinx for documents.
```
I:statistics:checking bind9.xsl vs xml (16)
I:statistics:skipping test as libxml2 and/or curl and/or xsltproc was not found
I:statistics:checking bind9.xml socket statistics (17)
I:statistics:skipping test as libxml2 and/or curl and/or xsltproc was not found
I:statistics:checking priming queries are counted (18)
I:statistics:Check that 'zone-statistics full;' is processed by 'rndc reconfig' (19)
I:statistics:exit status: 0
I:statistics:stopping servers
```November 2021 (9.16.23, 9.16.23-S1, 9.17.20)https://gitlab.isc.org/isc-projects/bind9/-/issues/2973buffer overwrite in stats channel2021-12-03T11:07:09ZEvan Huntbuffer overwrite in stats channel`httpd_request()` is the read callback handler for the stats channel that reads incoming HTTP requests. It calls `process_request()`, which immediately calls `memmove` to append newly read data to the end of any previously read data in `...`httpd_request()` is the read callback handler for the stats channel that reads incoming HTTP requests. It calls `process_request()`, which immediately calls `memmove` to append newly read data to the end of any previously read data in `httpd->recvbuf`. There's no length checking and `recvbuf` is only 1024 bytes. So if there are two successive reads of, say, 700 and 500 bytes, due to a browser sending an HTTP request with a ton of headers, it's possible to write past the end of the buffer.
I believe this was introduced in 9.17.4 when the statschannel was ported to use the netmgr in commit 69c1ee1ce9f80. It wouldn't have happened before because the caller supplies the buffer for `isc_socket_recv()`.
(I'm setting this to confidential just in case I'm wrong about that.)November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2972Bug in RSA keys comparing function2021-10-28T13:51:53ZArаm SаrgsyаnBug in RSA keys comparing functionWhen comparing different parameters of two RSA keys in `opensslrsa_compare()`, there is a typo in the code which causes the "p" prime factors to not being compared.When comparing different parameters of two RSA keys in `opensslrsa_compare()`, there is a typo in the code which causes the "p" prime factors to not being compared.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2970bind9.xsl is not properly transmitted over stats channel2021-11-02T15:04:51ZMark Andrewsbind9.xsl is not properly transmitted over stats channelLooking at the stats channel in a web browser errors are reported.Looking at the stats channel in a web browser errors are reported.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Mark AndrewsMark Andrewshttps://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/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/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/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/2947unexpected deletion of configured catalog zone2021-10-27T13:05:17ZMark Andrewsunexpected deletion of configured catalog zoneJob [#2034208](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2034208) failed for 8a962622f211d50a9da66aa4759685f1598b87eb:
dom1.example is deleted despite it being added.
```
11-Oct-2021 23:27:45.427 catz: dns_catz_add_zone catalog1...Job [#2034208](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2034208) failed for 8a962622f211d50a9da66aa4759685f1598b87eb:
dom1.example is deleted despite it being added.
```
11-Oct-2021 23:27:45.427 catz: dns_catz_add_zone catalog1.example
11-Oct-2021 23:27:45.427 catz: dns_catz_add_zone catalog2.example
11-Oct-2021 23:27:45.427 catz: dns_catz_add_zone catalog3.example
11-Oct-2021 23:27:45.427 /builds/isc-projects/bind9/bin/tests/system/catz/ns2/named.conf:39: catz: zone-directory 'nonexistent' not found; zone files will not be saved
11-Oct-2021 23:27:45.639 catz: updating catalog zone 'catalog1.example' with serial 1
11-Oct-2021 23:27:45.639 catz: update_from_db: iteration finished
11-Oct-2021 23:27:45.655 catz: update_from_db: new zone merged
11-Oct-2021 23:27:45.743 catz: updating catalog zone 'catalog3.example' with serial 1
11-Oct-2021 23:27:45.743 catz: update_from_db: iteration finished
11-Oct-2021 23:27:45.759 catz: update_from_db: new zone merged
11-Oct-2021 23:27:50.835 catz: updating catalog zone 'catalog1.example' with serial 2
11-Oct-2021 23:27:50.835 catz: update_from_db: iteration finished
11-Oct-2021 23:27:50.843 catz: iterating over 'dom1.example' from catalog 'catalog1.example'
11-Oct-2021 23:27:50.843 catz: adding zone 'dom1.example' from catalog 'catalog1.example' - success
11-Oct-2021 23:27:50.855 catz: update_from_db: new zone merged
11-Oct-2021 23:27:50.855 catz: new zone version came too soon, deferring update
11-Oct-2021 23:27:55.859 catz: updating catalog zone 'catalog1.example' with serial 2
11-Oct-2021 23:27:55.859 catz: update_from_db: iteration finished
11-Oct-2021 23:27:55.867 catz: iterating over 'dom1.example' from catalog 'catalog1.example'
11-Oct-2021 23:27:55.867 catz: deleting zone 'dom1.example' from catalog 'catalog1.example' - success
11-Oct-2021 23:27:55.879 catz: update_from_db: new zone merged
11-Oct-2021 23:27:55.879 catz: catz_delzone_taskaction: zone 'dom1.example' deleted
11-Oct-2021 23:28:00.747 catz: updating catalog zone 'catalog2.example' with serial 1
11-Oct-2021 23:28:00.747 catz: update_from_db: iteration finished
11-Oct-2021 23:28:00.767 catz: update_from_db: new zone merged
11-Oct-2021 23:28:02.863 catz: update already queued
11-Oct-2021 23:28:02.863 catz: updating catalog zone 'catalog1.example' with serial 3
11-Oct-2021 23:28:02.863 catz: update_from_db: iteration finished
11-Oct-2021 23:28:02.867 catz: deleting zone 'dom1.example' from catalog 'catalog1.example' - success
11-Oct-2021 23:28:02.879 catz: update_from_db: new zone merged
11-Oct-2021 23:28:02.879 catz: catz_delzone_taskaction: zone 'dom1.example' not found
11-Oct-2021 23:28:03.351 catz: new zone version came too soon, deferring update
11-Oct-2021 23:28:06.355 catz: updating catalog zone 'catalog2.example' with serial 2
11-Oct-2021 23:28:06.355 catz: update_from_db: iteration finished
11-Oct-2021 23:28:06.359 catz: iterating over 'dom4.example' from catalog 'catalog2.example'
11-Oct-2021 23:28:06.359 catz: adding zone 'dom4.example' from catalog 'catalog2.example' - success
11-Oct-2021 23:28:06.367 catz: update_from_db: new zone merged
11-Oct-2021 23:28:07.867 catz: new zone version came too soon, deferring update
11-Oct-2021 23:28:07.867 catz: update already queued
11-Oct-2021 23:28:08.871 catz: updating catalog zone 'catalog1.example' with serial 4
11-Oct-2021 23:28:08.871 catz: unknown record in catalog zone - trash2.foo.catalog1.example IN A(failure) - ignoring
11-Oct-2021 23:28:08.871 catz: unknown record in catalog zone - trash.catalog1.example IN A(failure) - ignoring
11-Oct-2021 23:28:08.871 catz: unknown record in catalog zone - version.catalog1.example IN A(failure) - ignoring
11-Oct-2021 23:28:08.871 catz: unknown record in catalog zone - blahblah.636722929740e507aaf27c502812fc395d30fb17.zones.catalog1.example IN TXT(failure) - ignoring
11-Oct-2021 23:28:08.871 catz: unknown record in catalog zone - foobarbaz.b901f492f3ebf6c1e5b597e51766f02f0479eb03.zones.catalog1.example IN APL(failure) - ignoring
11-Oct-2021 23:28:08.871 catz: unknown record in catalog zone - e721433b6160b450260d4f54b3ec8bab30cb3b83.zones.catalog1.example IN NS(failure) - ignoring
11-Oct-2021 23:28:08.871 catz: unknown record in catalog zone - trash3.zones.catalog1.example IN NS(failure) - ignoring
11-Oct-2021 23:28:08.871 catz: update_from_db: iteration finished
```
Closer look at the zone disappearing while the TXT queries for the new records are being made.
```
11-Oct-2021 23:27:54.819 query client=0x7b7c00070178 thread=0x7feb7696e700(dom1.example/TXT): ns__query_start
11-Oct-2021 23:27:54.819 client @0x7b7c00070178 10.53.0.1#39041 (dom1.example): query 'dom1.example/TXT/IN' approved
11-Oct-2021 23:27:54.819 query client=0x7b7c00070178 thread=0x7feb7696e700(dom1.example/TXT): query_lookup
11-Oct-2021 23:27:54.819 query client=0x7b7c00070178 thread=0x7feb7696e700(dom1.example/TXT): query_gotanswer
11-Oct-2021 23:27:54.819 client @0x7b7c00070178 10.53.0.1#39041 (dom1.example): rrl=(nil), HAVECOOKIE=0, result=DNS_R_NXRRSET, fname=0x7b5400030480(1), is_zone=1, RECURSIONOK=0, query.rpz_st=(nil)(0), RRL_CHECKED=0
11-Oct-2021 23:27:54.819 query client=0x7b7c00070178 thread=0x7feb7696e700(dom1.example/TXT): query_checkrpz
11-Oct-2021 23:27:54.819 query client=0x7b7c00070178 thread=0x7feb7696e700(dom1.example/TXT): rpz_rewrite
11-Oct-2021 23:27:54.819 query client=0x7b7c00070178 thread=0x7feb7696e700(dom1.example/TXT): query_nodata
11-Oct-2021 23:27:54.819 query client=0x7b7c00070178 thread=0x7feb7696e700(dom1.example/TXT): query_sign_nodata
11-Oct-2021 23:27:54.819 query client=0x7b7c00070178 thread=0x7feb7696e700(dom1.example/TXT): query_addsoa
11-Oct-2021 23:27:54.819 query client=0x7b7c00070178 thread=0x7feb7696e700(dom1.example/TXT): query_addrrset
11-Oct-2021 23:27:54.819 query client=0x7b7c00070178 thread=0x7feb7696e700(dom1.example/TXT): query_setorder
11-Oct-2021 23:27:54.819 query client=0x7b7c00070178 thread=0x7feb7696e700(dom1.example/TXT): query_additional
11-Oct-2021 23:27:54.819 query client=0x7b7c00070178 thread=0x7feb7696e700(dom1.example/TXT): query_additional: done
11-Oct-2021 23:27:54.819 query client=0x7b7c00070178 thread=0x7feb7696e700(dom1.example/TXT): query_addrrset: done
11-Oct-2021 23:27:54.819 query client=0x7b7c00070178 thread=0x7feb7696e700(dom1.example/TXT): ns_query_done
11-Oct-2021 23:27:54.819 client @0x7b7c00070178 10.53.0.1#39041 (dom1.example): reset client
11-Oct-2021 23:27:54.819 query client=0x7b7c00070178 thread=0x7feb7696e700(dom1.example/TXT): query_reset
11-Oct-2021 23:27:55.435 client @0x7b7c0002f578 10.53.0.1#36757: received notify for zone 'dom1.example'
11-Oct-2021 23:27:55.435 zone dom1.example/IN: notify from 10.53.0.1#36757: serial 2
11-Oct-2021 23:27:55.435 queue_soa_query: zone dom1.example/IN: enter
11-Oct-2021 23:27:55.435 soa_query: zone dom1.example/IN: enter
11-Oct-2021 23:27:55.439 refresh_callback: zone dom1.example/IN: enter
11-Oct-2021 23:27:55.439 refresh_callback: zone dom1.example/IN: serial: new 2, old 1
11-Oct-2021 23:27:55.439 queue_xfrin: zone dom1.example/IN: enter
11-Oct-2021 23:27:55.439 zone dom1.example/IN: Transfer started.
11-Oct-2021 23:27:55.439 zone dom1.example/IN: requesting IXFR from 10.53.0.1#6200
11-Oct-2021 23:27:55.439 transfer of 'dom1.example/IN' from 10.53.0.1#6200: connected using 10.53.0.2#44285
11-Oct-2021 23:27:55.439 transfer of 'dom1.example/IN' from 10.53.0.1#6200: requesting IXFR for serial 1
11-Oct-2021 23:27:55.439 transfer of 'dom1.example/IN' from 10.53.0.1#6200: sent request data
11-Oct-2021 23:27:55.443 transfer of 'dom1.example/IN' from 10.53.0.1#6200: received 191 bytes
;dom1.example. IN IXFR
dom1.example. 3600 IN SOA . . 2 3600 3600 3600 3600
dom1.example. 3600 IN SOA . . 1 3600 3600 3600 3600
dom1.example. 3600 IN SOA . . 2 3600 3600 3600 3600
dom1.example. 0 IN TXT "added" "record"
dom1.example. 3600 IN SOA . . 2 3600 3600 3600 3600
11-Oct-2021 23:27:55.443 transfer of 'dom1.example/IN' from 10.53.0.1#6200: got incremental response
11-Oct-2021 23:27:55.443 journal file zonedir/__catz___default_catalog1.example_dom1.example.db.jnl does not exist, creating it
11-Oct-2021 23:27:55.443 del dom1.example. 3600 IN SOA . . 1 3600 3600 3600 3600
11-Oct-2021 23:27:55.447 add dom1.example. 3600 IN SOA . . 2 3600 3600 3600 3600
11-Oct-2021 23:27:55.447 add dom1.example. 0 IN TXT "added" "record"
11-Oct-2021 23:27:55.447 dns_zone_verifydb: zone dom1.example/IN: enter
11-Oct-2021 23:27:55.447 zone_needdump: zone dom1.example/IN: enter
11-Oct-2021 23:27:55.447 zone_settimer: zone dom1.example/IN: enter
11-Oct-2021 23:27:55.447 zone dom1.example/IN: zone transfer finished: success
11-Oct-2021 23:27:55.447 zone dom1.example/IN: transferred serial 2
11-Oct-2021 23:27:55.447 zone_needdump: zone dom1.example/IN: enter
11-Oct-2021 23:27:55.447 zone_settimer: zone dom1.example/IN: enter
11-Oct-2021 23:27:55.447 zone_settimer: zone dom1.example/IN: enter
11-Oct-2021 23:27:55.447 transfer of 'dom1.example/IN' from 10.53.0.1#6200: Transfer status: success
11-Oct-2021 23:27:55.447 transfer of 'dom1.example/IN' from 10.53.0.1#6200: Transfer completed: 1 messages, 5 records, 191 bytes, 0.007 secs (27285 bytes/sec) (serial 2)
11-Oct-2021 23:27:55.447 transfer of 'dom1.example/IN' from 10.53.0.1#6200: freeing transfer context
11-Oct-2021 23:27:55.859 catz: updating catalog zone 'catalog1.example' with serial 2
11-Oct-2021 23:27:55.859 catz: update_from_db: iteration finished
11-Oct-2021 23:27:55.867 catz: iterating over 'dom1.example' from catalog 'catalog1.example'
11-Oct-2021 23:27:55.867 catz: deleting zone 'dom1.example' from catalog 'catalog1.example' - success
11-Oct-2021 23:27:55.879 catz: update_from_db: new zone merged
11-Oct-2021 23:27:55.879 calling free_rbtdb(dom1.example)
11-Oct-2021 23:27:55.879 done free_rbtdb(dom1.example)
11-Oct-2021 23:27:55.879 catz: catz_delzone_taskaction: zone 'dom1.example' deleted
11-Oct-2021 23:27:55.883 zone_shutdown: zone dom1.example/IN: shutting down
11-Oct-2021 23:27:56.027 query client=0x7b7c0001f978 thread=0x7feb78537700(dom1.example/TXT): qctx_init
11-Oct-2021 23:27:56.027 query client=0x7b7c0001f978 thread=0x7feb78537700(dom1.example/TXT): client attr:0x22300, query attr:0x700, restarts:0, origqname:dom1.example, timer:0, authdb:0, referral:0
11-Oct-2021 23:27:56.027 query client=0x7b7c0001f978 thread=0x7feb78537700(dom1.example/TXT): ns__query_start
11-Oct-2021 23:27:56.027 query client=0x7b7c0001f978 thread=0x7feb78537700(dom1.example/TXT): ns_query_done
11-Oct-2021 23:27:56.027 client @0x7b7c0001f978 10.53.0.1#34865 (dom1.example): query failed (REFUSED) for dom1.example/IN/TXT at query.c:5484
```
```
S:catz:2021-10-11T23:27:42+0000
T:catz:1:A
A:catz:System test catz
I:catz:PORTRANGE:6200 - 6299
I:catz:starting servers
I:catz:Testing adding/removing of domain in catalog zone
I:catz:checking that dom1.example. is not served by primary (1)
I:catz:Adding a domain dom1.example. to primary via RNDC (2)
I:catz:checking that dom1.example. is now served by primary (3)
I:catz:Adding domain dom1.example. to catalog1 zone (4)
I:catz:waiting for secondary to sync up (5)
I:catz:checking that dom1.example. is served by secondary (6)
I:catz:checking that zone-directory is populated (7)
I:catz:update dom1.example. (8)
I:catz:wait for secondary to be updated (9)
I:catz:failed
I:catz:check that journal was created for cleanup test (10)
I:catz:failed
```
- [x] Need to check v9.17November 2021 (9.16.23, 9.16.23-S1, 9.17.20)https://gitlab.isc.org/isc-projects/bind9/-/issues/2946Investigate resolver hangs in Perflab2021-11-03T13:52:54ZMichał KępieńInvestigate resolver hangs in PerflabAfter #2401/!4601 got merged, recursive tests in Perflab started
triggering what looks like hangs in the new resolver code:
- https://perflab.isc.org/#/config/run/5bf195dd83ba91a870b2976f/
- https://perflab.isc.org/#/config/run/5cd6...After #2401/!4601 got merged, recursive tests in Perflab started
triggering what looks like hangs in the new resolver code:
- 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/
This was already [pointed out][1] on Mattermost. What seems to be
happening is that during the recursive tests in Perflab, the tested
resolver only responds to queries for a few (dozen) seconds and then
stops responding indefinitely. Such failure modes were *not* observed
in AWS-based resolver benchmarks.
We should definitely get to the bottom of what is happening here.
[1]: https://mattermost.isc.org/isc/pl/oxnmi51mstyt7fs5pbdmhybpdyNovember 2021 (9.16.23, 9.16.23-S1, 9.17.20)https://gitlab.isc.org/isc-projects/bind9/-/issues/2944doth system test fails with 256 file descriptors2021-10-20T20:45:19ZMark Andrewsdoth system test fails with 256 file descriptors```
I:doth:checking server quotas for both encrypted and unencrypted HTTP (136)
Traceback (most recent call last):
File "/Users/marka/git/bind9/bin/tests/system/doth/stress_http_quota.py", line 242, in <module>
sys.exit(main())
F...```
I:doth:checking server quotas for both encrypted and unencrypted HTTP (136)
Traceback (most recent call last):
File "/Users/marka/git/bind9/bin/tests/system/doth/stress_http_quota.py", line 242, in <module>
sys.exit(main())
File "/Users/marka/git/bind9/bin/tests/system/doth/stress_http_quota.py", line 234, in main
run_test(http_secure=True)
File "/Users/marka/git/bind9/bin/tests/system/doth/stress_http_quota.py", line 205, in run_test
subdig.run()
File "/Users/marka/git/bind9/bin/tests/system/doth/stress_http_quota.py", line 132, in run
self.sub_process = subprocess.Popen(self.get_command(), shell=True,
File "/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/subprocess.py", line 951, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File "/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/subprocess.py", line 1720, in _execute_child
errpipe_read, errpipe_write = os.pipe()
OSError: [Errno 24] Too many open files
I:doth:failed
I:doth:exit status: 1
I:doth:stopping servers
R:doth:FAIL
E:doth:2021-10-08T12:36:09+1100
FAIL doth (exit status: 1)
```November 2021 (9.16.23, 9.16.23-S1, 9.17.20)https://gitlab.isc.org/isc-projects/bind9/-/issues/2942Replace the CHANGES file with a more practical alternative2021-11-05T08:27:39ZMichał KępieńReplace the CHANGES file with a more practical alternativeI am creating this issue so that we can discuss whether we can come up
with a usable alternative for maintaining the `CHANGES` file in the BIND
9 source repository.
This would really be a topic for an All Hands meeting, but it was raise...I am creating this issue so that we can discuss whether we can come up
with a usable alternative for maintaining the `CHANGES` file in the BIND
9 source repository.
This would really be a topic for an All Hands meeting, but it was raised
often enough recently that it arguably should not wait until the next
All Hands actually happens. Releasing BIND 9.18.0 sounds like a nice
milestone at which we could change things.
Let's start with the pros:
- `CHANGES` is a quick way for people not necessarily proficient with
Git (support folks, users, etc.) to get a quick summary of what
changed in a given BIND 9 release.[^1]
- `CHANGES` is trivial to search for keywords.
- Each `CHANGES` entry is a unique[^2] identifier of a given set of
changes *across various BIND 9 branches*.
Then, there are the cons:
- These days, `CHANGES` entries are pretty much duplicates of commit
log messages (which have become more verbose in the past months).
However, they cannot be as long or as exhaustive as the latter,
which necessitates edits/rewrites, which in certain cases causes a
significant amount of time to be spent on making them legible and/or
correct and/or precise (enough), both when merge requests are
discussed and when monthly releases are prepared. As `CHANGES` has
a more limited target audience than release notes, it does not
necessarily feel like time well spent.
- There are no strict rules governing what gets into `CHANGES`, in
what form, and under what circumstances. We try to adhere to a rule
of thumb which says that "anything that might be of interest to
users and/or important to developers should be listed", but that
turns out to be a very fuzzy line in practice.
- Since the `CHANGES` file is under version control, all entries need
to be cleaned up and prepared *before* any BIND 9 release is
prepared. If a `CHANGES` tweak/fix/addition turns out to be
necessary after a release is prepared, a respin is in order just to
fix a text file.
- `CHANGES` is generally a superset of release notes, which are
supposed to list all important user-facing changes. However, the
form and/or detail level of a given `CHANGES` entry often differs
from its release notes counterpart. This means more duplicate work
for every release.
Replacing `CHANGES` with some other solution acceptable by other ISC
teams would allow SWENG to save time on discussing repeated/derivative
texts, allowing us to spend that time on preparing accurate, verbose
commit messages which are not limited to a few lines in size. It would
also help avoid burning engineering time on silly stuff like retesting
an entire release because of tweaks which do not affect the code itself
or preparing & backporting missing `CHANGES` entries which were
forgotten about (or consciously omitted) for random MRs.
[^1]: There is a a catch, though: adding a `CHANGES` entry for any given
set of changes is not mandatory and therefore arbitrary in
practice. Sometimes we list trivial stuff, sometimes we gloss
over modifications which turn out to have critical consequences
down the line, sometimes we spend time on arguing whether
something needs to be listed or not.
[^2]: Sometimes we assign different texts to the same entry. Example:
entry 5712 in `main` vs. `v9_16`.November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2941Implement alternative to all-at-once rehashing for real-time hash tables2022-03-15T20:59:39ZOndřej SurýImplement alternative to all-at-once rehashing for real-time hash tablesThe all-at-once rehashing becomes very costly when the hash tables grow large. The rehashing operation on a busy resolver with a large cache could disrupt resolving even for a couple of seconds. Implement incremental rehashing (as the ...The all-at-once rehashing becomes very costly when the hash tables grow large. The rehashing operation on a busy resolver with a large cache could disrupt resolving even for a couple of seconds. Implement incremental rehashing (as the linear rehashing seems too complex for our purpose) for hot-path hash tables (RBT mostly).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/2940Double free on shutdown after binding a TLS socket fails2021-10-13T15:09:20ZMichał KępieńDouble free on shutdown after binding a TLS socket failsWith no root privileges and the following `named.conf`:
```
options {
listen-on tls ephemeral { 127.0.0.1; };
};
```
I can see this message logged during startup:
```
07-Oct-2021 08:08:46.020 creating TLS socket: permission denied
``...With no root privileges and the following `named.conf`:
```
options {
listen-on tls ephemeral { 127.0.0.1; };
};
```
I can see this message logged during startup:
```
07-Oct-2021 08:08:46.020 creating TLS socket: permission denied
```
and then this one during shutdown:
```
corrupted size vs. prev_size while consolidating
Aborted (core dumped)
```
(The message logged by libc may vary across hosts.)
The bug lies [here][1]:
```c
501 static isc_result_t
502 ns_interface_listentls(ns_interface_t *ifp, isc_tlsctx_t *sslctx) {
503 isc_result_t result;
504
505 result = isc_nm_listentlsdns(
506 ifp->mgr->nm, &ifp->addr, ns__client_request, ifp,
507 ns__client_tcpconn, ifp, sizeof(ns_client_t), ifp->mgr->backlog,
508 &ifp->mgr->sctx->tcpquota, sslctx, &ifp->tcplistensocket);
509
510 if (result != ISC_R_SUCCESS) {
511 isc_log_write(IFMGR_COMMON_LOGARGS, ISC_LOG_ERROR,
512 "creating TLS socket: %s",
513 isc_result_totext(result));
514 >>> isc_tlsctx_free(&sslctx);
515 return (result);
516 }
```
The `isc_tlsctx_free()` call on line 514 cleans up the `isc_tlsctx_t`
passed to `ns_interface_listentls()`, but look how the latter is called:
```c
627 if (elt->sslctx != NULL) {
628 result = ns_interface_listentls(ifp, elt->sslctx);
629 if (result != ISC_R_SUCCESS) {
630 goto cleanup_interface;
631 }
632 *ifpret = ifp;
633 return (result);
634 }
```
Specifically, note that `elt->sslctx` is passed by value, so even if
`ns_interface_listentls()` releases the SSL context, `elt->sslctx`
remains non-NULL. This makes `ns_listenelt_destroy()` [call][2]
`isc_tlsctx_free()` again for an already destroyed SSL context.
This bug has been around for at least the past 8 months, so there is no
rush to fix it in October.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/3b9d9f5afb8e9786757843a041b2c0b3392a4ec9/lib/ns/interfacemgr.c#L514
[2]: https://gitlab.isc.org/isc-projects/bind9/-/blob/3b9d9f5afb8e9786757843a041b2c0b3392a4ec9/lib/ns/listenlist.c#L127November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2935CID 339035 (#1 of 1): Explicit null dereferenced (FORWARD_NULL)2021-10-14T14:17:09ZMark AndrewsCID 339035 (#1 of 1): Explicit null dereferenced (FORWARD_NULL)signeedsfree doesn't correctly track whether sig.signature needs to be freed.
lib/dns/dnssec.c:
```
1054failure:
11. Condition dynbuf != NULL, taking false branch.
1055 if (dynbuf != NULL) {
1056 isc_buffer_f...signeedsfree doesn't correctly track whether sig.signature needs to be freed.
lib/dns/dnssec.c:
```
1054failure:
11. Condition dynbuf != NULL, taking false branch.
1055 if (dynbuf != NULL) {
1056 isc_buffer_free(&dynbuf);
1057 }
12. Condition signeedsfree, taking true branch.
1058 if (signeedsfree) {
CID 339035 (#1 of 1): Explicit null dereferenced (FORWARD_NULL)
13. var_deref_model: Passing null pointer sig.signature to isc__mem_put, which dereferences it. [show details]
1059 isc_mem_put(mctx, sig.signature, sig.siglen);
1060 }
1061 if (ctx != NULL) {
1062 dst_context_destroy(&ctx);
1063 }
```November 2021 (9.16.23, 9.16.23-S1, 9.17.20)Mark AndrewsMark Andrews