BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-07-28T13:57:35Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3834Release Checklist for BIND 9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.102023-07-28T13:57:35ZTom KrizekRelease Checklist for BIND 9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10## Release Schedule
**Code Freeze:** Wednesday, 1 February 2023
**Tagging Deadline:** Monday, 6 February 2023
**Public Release:** Wednesday, 15 February 2023
## Documentation Review Links
**Closed issues assigned to the milestone ...## Release Schedule
**Code Freeze:** Wednesday, 1 February 2023
**Tagging Deadline:** Monday, 6 February 2023
**Public Release:** Wednesday, 15 February 2023
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.19.10](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=February+2023+%289.16.38%2C+9.16.38-S1%2C+9.18.12%2C+9.18.12-S1%2C+9.19.10%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.19)
- [9.18.12-S1](https://gitlab.isc.org/isc-private/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=February+2023+%289.16.38%2C+9.16.38-S1%2C+9.18.12%2C+9.18.12-S1%2C+9.19.10%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.18-S)
- [9.18.12](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=February+2023+%289.16.38%2C+9.16.38-S1%2C+9.18.12%2C+9.18.12-S1%2C+9.19.10%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.18)
- [9.16.38-S1](https://gitlab.isc.org/isc-private/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=February+2023+%289.16.38%2C+9.16.38-S1%2C+9.18.12%2C+9.18.12-S1%2C+9.19.10%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.16-S)
- [9.16.38](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=February+2023+%289.16.38%2C+9.16.38-S1%2C+9.18.12%2C+9.18.12-S1%2C+9.19.10%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.16)
**Merge requests merged into the milestone without a release note:**
- [9.19.10](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=February+2023+%289.16.38%2C+9.16.38-S1%2C+9.18.12%2C+9.18.12-S1%2C+9.19.10%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=main)
- [9.18.12-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=February+2023+%289.16.38%2C+9.16.38-S1%2C+9.18.12%2C+9.18.12-S1%2C+9.19.10%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=v9_18_sub)
- [9.18.12](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=February+2023+%289.16.38%2C+9.16.38-S1%2C+9.18.12%2C+9.18.12-S1%2C+9.19.10%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=v9_18)
- [9.16.38-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=February+2023+%289.16.38%2C+9.16.38-S1%2C+9.18.12%2C+9.18.12-S1%2C+9.19.10%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=v9_16_sub)
- [9.16.38](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=February+2023+%289.16.38%2C+9.16.38-S1%2C+9.18.12%2C+9.18.12-S1%2C+9.19.10%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=v9_16)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.19.10](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=February+2023+%289.16.38%2C+9.16.38-S1%2C+9.18.12%2C+9.18.12-S1%2C+9.19.10%29&label_name%5B%5D=No+CHANGES&target_branch=main)
- [9.18.12-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=February+2023+%289.16.38%2C+9.16.38-S1%2C+9.18.12%2C+9.18.12-S1%2C+9.19.10%29&label_name%5B%5D=No+CHANGES&target_branch=v9_18_sub)
- [9.18.12](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=February+2023+%289.16.38%2C+9.16.38-S1%2C+9.18.12%2C+9.18.12-S1%2C+9.19.10%29&label_name%5B%5D=No+CHANGES&target_branch=v9_18)
- [9.16.38-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=February+2023+%289.16.38%2C+9.16.38-S1%2C+9.18.12%2C+9.18.12-S1%2C+9.19.10%29&label_name%5B%5D=No+CHANGES&target_branch=v9_16_sub)
- [9.16.38](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=February+2023+%289.16.38%2C+9.16.38-S1%2C+9.18.12%2C+9.18.12-S1%2C+9.19.10%29&label_name%5B%5D=No+CHANGES&target_branch=v9_16)
## Release checklist
### Before the Code Freeze
- [x] ***(QA)*** [Inform Support and Marketing of impending release (and give estimated release dates).](https://mattermost.isc.org/isc/pl/3cyqjh8wrffxxdyxeh35s8kgoy)
- [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.](https://gitlab.isc.org/isc-projects/bind9/-/issues/3834#note_348371)
- [x] ***(QA)*** [Check whether all issues assigned to the release milestone are resolved.](https://gitlab.isc.org/isc-projects/bind9/-/milestones/98)[^1]
- [x] ***(QA)*** [Ensure that there are no outstanding merge requests in the private repository (Subscription Edition only).](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&state=opened&milestone_title=February%202023%20(9.16.38%2C%209.16.38-S1%2C%209.18.12%2C%209.18.12-S1%2C%209.19.10))[^1]
- [x] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported.
- [x] ***(QA)*** Update GitLab settings for all maintained branches to disallow merging to them.
- [x] ***(QA)*** [Announce (on Mattermost) that the code freeze is in effect.](https://mattermost.isc.org/isc/pl/a4z5p1ssft8ybmhrz8o7ynzway)
### Before the Tagging Deadline
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
- [x] ***(QA)*** Add a release marker to `CHANGES`.
- [x] ***(QA)*** Add a release marker to `CHANGES.SE` (Subscription Edition only).
- [x] ***(QA)*** Update BIND 9 version in `configure.ac` (9.18+) or `version` (9.16).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org` (9.16).
- [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)*** Check that the formatting is correct for HTML and PDF versions of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** [Verify GitLab CI results for the tags created and sign off on the releases to be published.](https://gitlab.isc.org/isc-projects/bind9/-/issues/3834#note_349669)
- [x] ***(QA)*** Update GitLab settings for all maintained branches to allow merging to them again.
- [x] ***(QA)*** Prepare and merge MRs resetting the release notes and updating the version string for [each](isc-projects/bind9!7495) [maintained](isc-projects/bind9!7496) [branch](isc-projects/bind9!7497).
- [x] ***(QA)*** [Announce (on Mattermost) that the code freeze is over.](https://mattermost.isc.org/isc/pl/nn8ugoq7ipbdtfahaxbjet7obe)
- [x] ***(QA)*** [Request signatures for the tarballs, providing their location and checksums.](https://mattermost.isc.org/isc/pl/dedshneke3gc5demc88ws9kxmy)
- [x] ***(Signers)*** Ensure that the contents of tarballs and tags are identical.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** [Verify tarball signatures and check tarball checksums again.](https://mattermost.isc.org/isc/pl/n7dkmt3cs7ryikk1ri4aagdjjc)
- [x] ***(Support)*** [Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.](https://mattermost.isc.org/isc/pl/yewdfdkbutf8dgf5oxcgwehqca)
- [x] ***(QA)*** [Build and test ASN and/or Subscription Edition packages.](https://gitlab.isc.org/isc-private/rpms/bind/-/pipelines/128027)
- [x] ***(QA)*** Prepare the `patches/` subdirectory for each security release (if applicable).
- [x] ***(QA)*** [Notify Support that the releases have been prepared.](https://gitlab.isc.org/isc-projects/bind9/-/issues/3834#note_350156)
- [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.](The usual Support tasks have been completed for the Feb. BIND releases.)
- [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.](https://gitlab.isc.org/isc-private/rpms/bind/-/pipelines/129046)
- [x] ***(QA)*** Build public RPMs.
- [x] ***(SwEng)*** Build Debian/Ubuntu packages.
- [x] ***(SwEng)*** Update Docker images.
- [x] ***(QA)*** Inform Marketing of the release.
- [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 published release tags (non-linearly) back into the their relevant development/maintenance branches.
- [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. Black, PyLint, Sphinx) by modifying the relevant `Dockerfile`.
- [x] ***(QA)*** Run a pipeline to rebuild all [images](https://gitlab.isc.org/isc-projects/images) used in GitLab CI.
[^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.February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)Michal NowakMichal Nowak2023-02-15https://gitlab.isc.org/isc-projects/bind9/-/issues/3830nsupdate failed to handle primary server address lookup gracefully2023-01-31T13:41:36ZMark Andrewsnsupdate failed to handle primary server address lookup gracefullynsupdate just exited when the address lookup of the primary server from the SOA record failed. Instead handle this like other errors when sending UPDATEs. This is useful for interactive mode and also allows memory to be properly freed.nsupdate just exited when the address lookup of the primary server from the SOA record failed. Instead handle this like other errors when sending UPDATEs. This is useful for interactive mode and also allows memory to be properly freed.February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3829'named -V' leaks memory when shutting down2023-01-30T23:06:14ZMark Andrews'named -V' leaks memory when shutting downThere is a missing `dst_lib_destroy` call in `printversion`.There is a missing `dst_lib_destroy` call in `printversion`.February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)https://gitlab.isc.org/isc-projects/bind9/-/issues/3828fuzz/dns_message_checksig.c fails to call dst_lib_destroy2023-02-01T14:13:32ZMark Andrewsfuzz/dns_message_checksig.c fails to call dst_lib_destroydns_message_checksig.c fails to call dst_lib_destroy leading
to a memory leak.
f3f56c0ba8f23243cbfc5a81ab08e171aa7e85d9 fixes this but needs
to be applied as a seperate MR.dns_message_checksig.c fails to call dst_lib_destroy leading
to a memory leak.
f3f56c0ba8f23243cbfc5a81ab08e171aa7e85d9 fixes this but needs
to be applied as a seperate MR.February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3827DNSRPS builds are broken2023-02-28T08:14:45ZMark AndrewsDNSRPS builds are brokenFrom victor dukhovni
The FreeBSD port attempts to build BIND 9.18 after `configure ... --enable-dnsrps ...`. With this enabled, neither BIND 9.18.10 nor 9.18.11 build:
```
dnsrps.c:945:2: error: incompatible function pointer types initi...From victor dukhovni
The FreeBSD port attempts to build BIND 9.18 after `configure ... --enable-dnsrps ...`. With this enabled, neither BIND 9.18.10 nor 9.18.11 build:
```
dnsrps.c:945:2: error: incompatible function pointer types initializing 'isc_result_t (*)(dns_db_t *, dns_dbnode_t *, dns_dbversion_t *, unsigned int, isc_stdtime_t, dns_rdatasetiter_t **)' (aka 'enum isc_result (*)(struct dns_db *, void *, void *, unsigned int, unsigned int, struct dns_rdatasetiter **)') with an expression of type 'isc_result_t (dns_db_t *, dns_dbnode_t *, dns_dbversion_t *, isc_stdtime_t, dns_rdatasetiter_t **)' (aka 'enum isc_result (struct dns_db *, void *, void *, unsigned int, struct dns_rdatasetiter **)') [-Werror,-Wincompatible-function-pointer-types]
rpsdb_allrdatasets,
^~~~~~~~~~~~~~~~~~
1 error generated.
```February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3824Teach danger about amend!2023-02-03T14:47:35ZMark AndrewsTeach danger about amend!`git commit --fixup=amend:<hash>` produces an `amend!` line which is not detected by danger.`git commit --fixup=amend:<hash>` produces an `amend!` line which is not detected by danger.February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)https://gitlab.isc.org/isc-projects/bind9/-/issues/3822'rndc dnssec -checkds published' should force move DS state into rumoured2023-02-01T14:09:06ZMatthijs Mekkingmatthijs@isc.org'rndc dnssec -checkds published' should force move DS state into rumouredSimilarly, `rndc dnssec -checkds withdrawn` should force move DS state into "unretentive".
For example, the `DS` state is in hidden because it is not yet safe to publish the DS, but if the user tells the DS is already in the parent, we ...Similarly, `rndc dnssec -checkds withdrawn` should force move DS state into "unretentive".
For example, the `DS` state is in hidden because it is not yet safe to publish the DS, but if the user tells the DS is already in the parent, we should accept that this is the case and update the state accordingly.February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3808Refactor isc_nm_xfr_allowed() to return isc_result_t instead of bool2023-01-31T17:36:31ZArаm SаrgsyаnRefactor isc_nm_xfr_allowed() to return isc_result_t instead of boolThis is a followup issue from the !7360 MR review, see the following discussion: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7360#note_344309.This is a followup issue from the !7360 MR review, see the following discussion: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7360#note_344309.February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3807TSAN error in TLS code2023-01-18T09:14:35ZMark AndrewsTSAN error in TLS codeJob [#3077671](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3077671) failed for d90db6dcaa12d33f6dafcd99841e789a3ed7a7d7:
```
WARNING: ThreadSanitizer: data race
Read of size 8 at 0x000000000001 by thread T1:
#0 memcmp <null> ...Job [#3077671](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3077671) failed for d90db6dcaa12d33f6dafcd99841e789a3ed7a7d7:
```
WARNING: ThreadSanitizer: data race
Read of size 8 at 0x000000000001 by thread T1:
#0 memcmp <null> (BuildId: b0d06e7836759374a227933a22694f15d308d7f4)
#1 ASN1_STRING_cmp <null> (BuildId: 6bc8b0545e8b77a3c250fa8462431979d25036fe)
#2 tls_do_bio lib/isc/netmgr/tlsstream.c:524:10 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#3 tls_readcb lib/isc/netmgr/tlsstream.c:775:2 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#4 isc__nm_async_readcb lib/isc/netmgr/netmgr.c:2082:2 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#5 isc__nm_readcb lib/isc/netmgr/netmgr.c:2055:3 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#6 isc__nm_tcp_read_cb lib/isc/netmgr/tcp.c:830:2 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#7 uv__read /usr/src/libuv-v1.44.1/src/unix/stream.c:1247:7 (BuildId: 120c450d14885aa5308bc95c4ea77de2c2b1cc36)
#8 isc__trampoline_run lib/isc/trampoline.c:198:11 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
Previous write of size 8 at 0x000000000001 by thread T2 (mutexes: write M1):
#0 memcpy <null> (BuildId: b0d06e7836759374a227933a22694f15d308d7f4)
#1 ASN1_STRING_set <null> (BuildId: 6bc8b0545e8b77a3c250fa8462431979d25036fe)
#2 tls_do_bio lib/isc/netmgr/tlsstream.c:524:10 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#3 tls_readcb lib/isc/netmgr/tlsstream.c:775:2 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#4 isc__nm_async_readcb lib/isc/netmgr/netmgr.c:2082:2 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#5 isc__nm_readcb lib/isc/netmgr/netmgr.c:2055:3 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#6 isc__nm_tcp_read_cb lib/isc/netmgr/tcp.c:830:2 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#7 uv__read /usr/src/libuv-v1.44.1/src/unix/stream.c:1247:7 (BuildId: 120c450d14885aa5308bc95c4ea77de2c2b1cc36)
#8 isc__trampoline_run lib/isc/trampoline.c:198:11 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
Location is heap block of size 21 at 0x000000000001 allocated by thread T2:
#0 malloc <null> (BuildId: b0d06e7836759374a227933a22694f15d308d7f4)
#1 mallocx lib/isc/./jemalloc_shim.h:57:14 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#2 mem_get lib/isc/mem.c:343:8
#3 isc__mem_allocate lib/isc/mem.c:908:8
#4 isc__mem_reallocate lib/isc/mem.c:960:13 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#5 isc__tls_realloc_ex lib/isc/tls.c:103:10 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#6 ASN1_STRING_set <null> (BuildId: 6bc8b0545e8b77a3c250fa8462431979d25036fe)
#7 tls_do_bio lib/isc/netmgr/tlsstream.c:524:10 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#8 tls_readcb lib/isc/netmgr/tlsstream.c:775:2 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#9 isc__nm_async_readcb lib/isc/netmgr/netmgr.c:2082:2 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#10 isc__nm_readcb lib/isc/netmgr/netmgr.c:2055:3 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#11 isc__nm_tcp_read_cb lib/isc/netmgr/tcp.c:830:2 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#12 uv__read /usr/src/libuv-v1.44.1/src/unix/stream.c:1247:7 (BuildId: 120c450d14885aa5308bc95c4ea77de2c2b1cc36)
#13 isc__trampoline_run lib/isc/trampoline.c:198:11 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
Mutex M1 (0x000000000018) created at:
#0 pthread_rwlock_init <null> (BuildId: b0d06e7836759374a227933a22694f15d308d7f4)
#1 CRYPTO_THREAD_lock_new <null> (BuildId: 6bc8b0545e8b77a3c250fa8462431979d25036fe)
#2 listenelt_create lib/ns/listenlist.c:84:15 (BuildId: 89b9089e5e649140f035c9711f7a38d1961da4cb)
#3 ns_listenelt_create lib/ns/listenlist.c:206:9 (BuildId: 89b9089e5e649140f035c9711f7a38d1961da4cb)
#4 listenelt_fromconfig bin/named/server.c:11265:3 (BuildId: b0d06e7836759374a227933a22694f15d308d7f4)
#5 listenlist_fromconfig bin/named/server.c:11006:12
#6 load_configuration bin/named/server.c:8884:13 (BuildId: b0d06e7836759374a227933a22694f15d308d7f4)
#7 run_server bin/named/server.c:9974:2 (BuildId: b0d06e7836759374a227933a22694f15d308d7f4)
#8 task_run lib/isc/task.c:470:4 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#9 task__run lib/isc/task.c:287:24
#10 isc__job_cb lib/isc/job.c:75:2 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#11 uv__run_idle /usr/src/libuv-v1.44.1/src/unix/loop-watcher.c:68:1 (BuildId: 120c450d14885aa5308bc95c4ea77de2c2b1cc36)
#12 isc_loopmgr_run lib/isc/loop.c:481:2 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#13 main bin/named/main.c:1513:2 (BuildId: b0d06e7836759374a227933a22694f15d308d7f4)
Thread T1 'isc-loop-0001' (running) created by main thread at:
#0 pthread_create <null> (BuildId: b0d06e7836759374a227933a22694f15d308d7f4)
#1 isc_thread_create lib/isc/thread.c:70:8 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#2 isc_loopmgr_run lib/isc/loop.c:475:3 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#3 main bin/named/main.c:1513:2 (BuildId: b0d06e7836759374a227933a22694f15d308d7f4)
Thread T2 'isc-loop-0010' (running) created by main thread at:
#0 pthread_create <null> (BuildId: b0d06e7836759374a227933a22694f15d308d7f4)
#1 isc_thread_create lib/isc/thread.c:70:8 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#2 isc_loopmgr_run lib/isc/loop.c:475:3 (BuildId: 4e2f84938bb8c350982ab15619317a22e19aef5e)
#3 main bin/named/main.c:1513:2 (BuildId: b0d06e7836759374a227933a22694f15d308d7f4)
SUMMARY: ThreadSanitizer: data race (BuildId: b0d06e7836759374a227933a22694f15d308d7f4) in __interceptor_memcmp
```February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)https://gitlab.isc.org/isc-projects/bind9/-/issues/3806adb->hmctx does not have a name associated with it2023-02-03T14:47:33ZMichał Kępieńadb->hmctx does not have a name associated with itThis is a minor issue introduced by !7228 and its backport (!7248). See
#3739 for context.
The new memory context added in those MRs, `adb->hmctx`, does not have a
name associated with it.
## Before (e.g. BIND 9.18.10)
```sh
$ curl -...This is a minor issue introduced by !7228 and its backport (!7248). See
#3739 for context.
The new memory context added in those MRs, `adb->hmctx`, does not have a
name associated with it.
## Before (e.g. BIND 9.18.10)
```sh
$ curl -s http://localhost:8080/json | jq ".memory.contexts[].name"
"main"
"zonemgr-pool"
"zonemgr-pool"
"clientmgr"
"clientmgr"
"clientmgr"
"clientmgr"
"cache"
"cache_heap"
"ADB"
"cache"
"cache_heap"
"ADB"
```
## After (e.g. BIND 9.18.11)
```sh
$ curl -s http://localhost:8080/json | jq ".memory.contexts[].name"
"main"
"zonemgr-pool"
"zonemgr-pool"
"clientmgr"
"clientmgr"
"clientmgr"
"clientmgr"
"cache"
"cache_heap"
"ADB"
null
"cache"
"cache_heap"
"ADB"
null
```
Could we please add an `isc_mem_setname()` call for this new memory
context that would describe its purpose?February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3804[tests] False-negative results of test `statschannel`2023-01-17T13:49:58ZStanislav Levin[tests] False-negative results of test `statschannel`System tests `statschannel` are conditional and depend on build
options, e.g. they may require `libxml2` or `libjson-c`. Those
conditions are checked with the help of `feature-test` tool which
exits with `0` code in case of enabled featu...System tests `statschannel` are conditional and depend on build
options, e.g. they may require `libxml2` or `libjson-c`. Those
conditions are checked with the help of `feature-test` tool which
exits with `0` code in case of enabled feature and `1` otherwise.
Pytest markers `have_libxml2` and `have_json_c` have wrong skip
condition, i.e. a test will be skipped if the build has feature.
Thereby,
- upstream unintentionally skip these tests
- xml/json test false-negatively fail against builds without
corresponging feature
Example of the fix:
```diff
--- a/bin/tests/system/pytest_custom_markers.py
+++ b/bin/tests/system/pytest_custom_markers.py
@@ -34,9 +34,9 @@ def feature_test(feature):
have_libxml2 = pytest.mark.skipif(
- feature_test("--have-libxml2"), reason="libxml2 support disabled in the build"
+ not feature_test("--have-libxml2"), reason="libxml2 support disabled in the build"
)
have_json_c = pytest.mark.skipif(
- feature_test("--have-json-c"), reason="json-c support disabled in the build"
+ not feature_test("--have-json-c"), reason="json-c support disabled in the build"
)
```February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3801dns_view is detached from deleted zone too late2023-10-30T15:00:55ZOndřej Surýdns_view is detached from deleted zone too lateWhen zone is removed from the configuration, it keeps a reference to `.view` (and possibly `.prev_view`) until the zone is deleted. The removal can take a long time, and if there's a constant stream of `rndc reconfig` adding and removin...When zone is removed from the configuration, it keeps a reference to `.view` (and possibly `.prev_view`) until the zone is deleted. The removal can take a long time, and if there's a constant stream of `rndc reconfig` adding and removing zones, the otherwise dead views can be kept in memory for really long time leading to a memory bloat.
This symptom might also be encountered on a server with a Catalog Zone with a high rate of change.February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3800MacOS address in use not handled gracefully2023-02-01T13:43:03ZMark AndrewsMacOS address in use not handled gracefullyI happened to have an `asn.pl` active on one interface and that triggered an assertion due to mismatching result values.
```
(lldb) print sock->children[0].result
(isc_result_t) $11 = ISC_R_ADDRINUSE
(lldb) print sock->children[1].resul...I happened to have an `asn.pl` active on one interface and that triggered an assertion due to mismatching result values.
```
(lldb) print sock->children[0].result
(isc_result_t) $11 = ISC_R_ADDRINUSE
(lldb) print sock->children[1].result
(isc_result_t) $12 = ISC_R_SUCCESS
(lldb) print sock->children[2].result
(isc_result_t) $13 = ISC_R_SUCCESS
(lldb) print sock->children[3].result
(isc_result_t) $14 = ISC_R_SUCCESS
(lldb) print sock->children[4].result
(isc_result_t) $15 = ISC_R_SUCCESS
```
```
* thread #1, stop reason = signal SIGSTOP
frame #0: 0x00000001814b8e28 libsystem_kernel.dylib`__pthread_kill + 8
frame #1: 0x00000001814eb43c libsystem_pthread.dylib`pthread_kill + 292
frame #2: 0x0000000181433454 libsystem_c.dylib`abort + 124
frame #3: 0x0000000102f6a478 named`assertion_failed(file="netmgr/udp.c", line=181, type=isc_assertiontype_insist, cond="result == sock->children[i].result") at main.c:236:3
frame #4: 0x000000010351a14c libisc-9.19.10-dev.dylib`isc_assertion_failed(file="netmgr/udp.c", line=181, type=isc_assertiontype_insist, cond="result == sock->children[i].result") at assertions.c:49:2
* frame #5: 0x0000000103517050 libisc-9.19.10-dev.dylib`isc_nm_listenudp(mgr=0x0000000106a781e0, workers=8, iface=0x00000001088eedd8, cb=(libns-9.19.10-dev.dylib`ns__client_request at client.c:1689), cbarg=0x00000001088eed80, sockp=0x00000001088eee98) at udp.c:181:3
frame #6: 0x00000001033185a4 libns-9.19.10-dev.dylib`ns_interface_listenudp(ifp=0x00000001088eed80) at interfacemgr.c:494:11
frame #7: 0x000000010331763c libns-9.19.10-dev.dylib`interface_setup(mgr=0x0000000106a121a0, addr=0x000000016cea2670, name="lo0", ifpret=0x000000016cea2638, elt=0x00000001067f0bf0, addr_in_use=0x000000016cea25ff) at interfacemgr.c:696:11
frame #8: 0x0000000103315ed0 libns-9.19.10-dev.dylib`do_scan(mgr=0x0000000106a121a0, verbose=true, config=true) at interfacemgr.c:1266:13
frame #9: 0x00000001033157b0 libns-9.19.10-dev.dylib`ns_interfacemgr_scan(mgr=0x0000000106a121a0, verbose=true, config=true) at interfacemgr.c:1326:11
frame #10: 0x0000000102f80860 named`load_configuration(filename="/dev/null", server=0x0000000106b3c8c0, first_time=true) at server.c:8947:12
frame #11: 0x0000000102f7ed18 named`run_server(task=0x0000000106ac6640, event=0x0000000000000000) at server.c:9974:2
frame #12: 0x000000010354ffb4 libisc-9.19.10-dev.dylib`task_run(task=0x0000000106ac6640) at task.c:470:4
frame #13: 0x000000010354fb98 libisc-9.19.10-dev.dylib`task__run(arg=0x0000000106ac6640) at task.c:287:24
frame #14: 0x000000010352aa70 libisc-9.19.10-dev.dylib`isc__job_cb(idle=0x0000000106ac6a08) at job.c:75:2
frame #15: 0x00000001041dafe4 libuv.1.dylib`uv__run_idle + 152
frame #16: 0x00000001041d5cd0 libuv.1.dylib`uv_run + 204
frame #17: 0x0000000103535bb8 libisc-9.19.10-dev.dylib`loop_run(loop=0x0000000106c3c000) at loop.c:270:6
frame #18: 0x00000001035342bc libisc-9.19.10-dev.dylib`loop_thread(arg=0x0000000106c3c000) at loop.c:297:2
frame #19: 0x0000000103534174 libisc-9.19.10-dev.dylib`isc_loopmgr_run(loopmgr=0x00000001067ef750) at loop.c:481:2
frame #20: 0x0000000102f6a17c named`main(argc=6, argv=0x000000016cea36c0) at main.c:1513:2
frame #21: 0x0000000181509430 libdyld.dylib`start + 4
```
The assertion doesn't make sense on the Mac as `mgr->load_balance_sockets` is `false` and `fd` is the result of `dup` rather than using `socket` and `bind` resulting in different `result` values being stored.February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)https://gitlab.isc.org/isc-projects/bind9/-/issues/3799TSAN race between dns_rbtnode_t bitfields2023-02-01T13:40:09ZMichał KępieńTSAN race between dns_rbtnode_t bitfieldsA certain TSAN issue has been repeatedly reported for different branches
by TSAN-enabled respdiff tests:
- `v9_18_sub`: https://gitlab.isc.org/isc-private/bind9/-/jobs/3069484
- `v9_16`: https://gitlab.isc.org/isc-private/bind9/-/jo...A certain TSAN issue has been repeatedly reported for different branches
by TSAN-enabled respdiff tests:
- `v9_18_sub`: https://gitlab.isc.org/isc-private/bind9/-/jobs/3069484
- `v9_16`: https://gitlab.isc.org/isc-private/bind9/-/jobs/3067159
- `v9_16_sub`: https://gitlab.isc.org/isc-private/bind9/-/jobs/3067260
```
WARNING: ThreadSanitizer: data race
Read of size 1 at 0x000000000001 by thread T1 (mutexes: read M1):
#0 decrement_reference lib/dns/rbtdb.c:2090
#1 detachnode lib/dns/rbtdb.c:5552
#2 rdataset_disassociate lib/dns/rbtdb.c:8874
#3 dns_rdataset_disassociate lib/dns/rdataset.c:113
#4 fctx_destroy lib/dns/resolver.c:4718
#5 fctx_doshutdown lib/dns/resolver.c:4945
#6 task_run lib/isc/task.c:853
#7 isc_task_run lib/isc/task.c:947
#8 isc__nm_async_task lib/isc/netmgr/netmgr.c:861
#9 process_netievent lib/isc/netmgr/netmgr.c:933
#10 process_queue lib/isc/netmgr/netmgr.c:999
#11 process_all_queues lib/isc/netmgr/netmgr.c:780
#12 async_cb lib/isc/netmgr/netmgr.c:809
#13 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163
#14 isc__trampoline_run lib/isc/trampoline.c:213
Previous write of size 1 at 0x000000000001 by thread T2 (mutexes: write M2, write M3):
#0 add_wildcard_magic lib/dns/rbtdb.c:2808
#1 findnodeintree lib/dns/rbtdb.c:2885
#2 findnode lib/dns/rbtdb.c:2923
#3 dns_db_findnode lib/dns/db.c:441
#4 validated lib/dns/resolver.c:6155
#5 task_run lib/isc/task.c:853
#6 isc_task_run lib/isc/task.c:947
#7 isc__nm_async_task lib/isc/netmgr/netmgr.c:861
#8 process_netievent lib/isc/netmgr/netmgr.c:933
#9 process_queue lib/isc/netmgr/netmgr.c:999
#10 process_all_queues lib/isc/netmgr/netmgr.c:780
#11 async_cb lib/isc/netmgr/netmgr.c:809
#12 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163
#13 isc__trampoline_run lib/isc/trampoline.c:213
Location is heap block of size 115 at 0x000000000022 allocated by thread T3:
#0 malloc ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:651
#1 default_memalloc lib/isc/mem.c:715
#2 mem_get lib/isc/mem.c:624
#3 isc___mem_get lib/isc/mem.c:1066
#4 isc__mem_get lib/isc/mem.c:2384
#5 create_node lib/dns/rbt.c:2279
#6 dns_rbt_addnode lib/dns/rbt.c:1471
#7 findnodeintree lib/dns/rbtdb.c:2877
#8 findnode lib/dns/rbtdb.c:2923
#9 dns_db_findnode lib/dns/db.c:441
#10 cache_name lib/dns/resolver.c:6457
#11 cache_message lib/dns/resolver.c:6870
#12 resquery_response lib/dns/resolver.c:8274
#13 task_run lib/isc/task.c:853
#14 isc_task_run lib/isc/task.c:947
#15 isc__nm_async_task lib/isc/netmgr/netmgr.c:861
#16 process_netievent lib/isc/netmgr/netmgr.c:933
#17 process_queue lib/isc/netmgr/netmgr.c:999
#18 process_all_queues lib/isc/netmgr/netmgr.c:780
#19 async_cb lib/isc/netmgr/netmgr.c:809
#20 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163
#21 isc__trampoline_run lib/isc/trampoline.c:213
Mutex M1 is already destroyed.
Mutex M2 is already destroyed.
Mutex M3 is already destroyed.
Thread T1 (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:962
#1 isc_thread_create lib/isc/pthreads/thread.c:81
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:345
#3 isc_managers_create lib/isc/managers.c:28
#4 create_managers main.c:1064
#5 setup main.c:1389
#6 main main.c:1703
Thread T2 (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:962
#1 isc_thread_create lib/isc/pthreads/thread.c:81
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:345
#3 isc_managers_create lib/isc/managers.c:28
#4 create_managers main.c:1064
#5 setup main.c:1389
#6 main main.c:1703
Thread T3 (running) created by main thread at:
#0 pthread_create ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:962
#1 isc_thread_create lib/isc/pthreads/thread.c:81
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:345
#3 isc_managers_create lib/isc/managers.c:28
#4 create_managers main.c:1064
#5 setup main.c:1389
#6 main main.c:1703
SUMMARY: ThreadSanitizer: data race lib/dns/rbtdb.c:2090 in decrement_reference
```
Looking at line numbers, this looks like a race between (line numbers
taken from `v9_16_37`):
```c
2089 /* Handle easy and typical case first. */
2090 >>> if (!node->dirty && KEEP_NODE(node, rbtdb, locked)) {
2091 if (isc_refcount_decrement(&node->references) == 1) {
2092 refs = isc_refcount_decrement(&nodelock->references);
2093 INSIST(refs > 0);
2094 return (true);
2095 } else {
2096 return (false);
2097 }
2098 }
```
and:
```c
2787 static isc_result_t
2788 add_wildcard_magic(dns_rbtdb_t *rbtdb, const dns_name_t *name) {
2789 isc_result_t result;
2790 dns_name_t foundname;
2791 dns_offsets_t offsets;
2792 unsigned int n;
2793 dns_rbtnode_t *node = NULL;
2794
2795 dns_name_init(&foundname, offsets);
2796 n = dns_name_countlabels(name);
2797 INSIST(n >= 2);
2798 n--;
2799 dns_name_getlabelsequence(name, 1, n, &foundname);
2800 result = dns_rbt_addnode(rbtdb->tree, &foundname, &node);
2801 if (result != ISC_R_SUCCESS && result != ISC_R_EXISTS) {
2802 return (result);
2803 }
2804 if (result == ISC_R_SUCCESS) {
2805 node->nsec = DNS_RBT_NSEC_NORMAL;
2806 }
2807 node->find_callback = 1;
2808 >>> node->wild = 1;
2809 return (ISC_R_SUCCESS);
2810 }
```
`dirty` and `wild` are bitfields:
```c
struct dns_rbtnode {
...
void *data;
uint8_t : 0; /* start of bitfields c/o node lock */
uint8_t dirty : 1;
uint8_t wild : 1;
uint8_t : 0; /* end of bitfields c/o node lock */
uint16_t locknum; /* note that this is not in the bitfield */
isc_refcount_t references;
/*@}*/
};
```
I cannot recall this issue being reported for the current `main`, but
perhaps it gets triggered there as well, just with a lower frequency.February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3796Building BIND on newer versions of DragonFly BSD (at least 6.4) fails (w/ and...2023-02-03T14:24:47ZArtem BoldarievBuilding BIND on newer versions of DragonFly BSD (at least 6.4) fails (w/ and w/o Jemalloc)While doing some investigations for #3774, it was found that building BIND 9 is not possible on that platform as our memory management code fails to build on this platform when configuring with both `--with-jemalloc=yes` and `--with-jema...While doing some investigations for #3774, it was found that building BIND 9 is not possible on that platform as our memory management code fails to build on this platform when configuring with both `--with-jemalloc=yes` and `--with-jemalloc=no`. I think that it would be fair to make it work at least in the case when jemalloc-specific APIs are not available (like in the case of OpenBSD). BIND builds fine at least for DragonFly 6.2, according to @mnowak report in #3774. Obviously, that happens due to the changes to OS-specific headers.
## When Jemalloc is detected or when building with `--with-jemalloc=yes`
By default, `./configure` tries to detect presence of `<malloc_np.h>` and assumes that when it is available, Jemalloc specific API is availalbe (`mallocx()`, `sdallocx()`, `rallocx()`, etc). The header usually corresponds to `<jemalloc/jemalloc.h>` in upstream versions of Jemalloc. In this case `HAVE_MALLOC_NP_H` is defined in `config.h`.
That used to be the case for DragonFly BSD, but is not tanymore. On this platform `./configure` script works fine, but building BIND will fail as follows:
```
mem.c: In function 'mem_get':
mem.c:343:8: error: implicit declaration of function 'mallocx'; did you mean 'malloc'? [-Werror=implicit-function-declaration]
ret = mallocx(size, flags);
^~~~~~~
malloc
mem.c:343:6: warning: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
ret = mallocx(size, flags);
^
mem.c: In function 'mem_put':
mem.c:365:2: error: implicit declaration of function 'sdallocx'; did you mean 'reallocf'? [-Werror=implicit-function-declaration]
sdallocx(mem, size, flags);
^~~~~~~~
reallocf
mem.c: In function 'mem_realloc':
mem.c:375:12: error: implicit declaration of function 'rallocx'; did you mean 'reallocf'? [-Werror=implicit-function-declaration]
new_ptr = rallocx(old_ptr, new_size, flags);
^~~~~~~
reallocf
mem.c:375:10: warning: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
new_ptr = rallocx(old_ptr, new_size, flags);
^
In file included from ./include/isc/hash.h:22,
from mem.c:26:
mem.c: In function 'mem_initialize':
mem.c:441:32: error: 'MALLOCX_ZERO' undeclared (first use in this function)
RUNTIME_CHECK(ISC_MEM_ZERO == MALLOCX_ZERO);
...
```
Keep in mind that `HAVE_MALLOC_NP_H` is defined in the case above, as the header is present. The case is that it does not provide the required API.
## When building without Jemalloc (`--with-jemalloc=yes`)
In such a case, `jemalloc_shim.h` is broken (the file is intended to provide a simple implementation of Jemalloc specific APIs using the available OS-specific capabilities). It fails as follows:
```
jemalloc_shim.h:44:10: fatal error: malloc.h: No such file or directory
#include <malloc.h>
^~~~~~~~~~
```
As memory allocator on DragonFly BSD does have `malloc_usable_size()`, we end up building with `HAVE_MALLOC_USABLE_SIZE` defined (which is not a surprise, as it is still a custom version of Jemalloc). In such a case, we attempt to include non-standard `<malloc.h>` ... which is not available on DragonFly BSD anymore. As far as I understand the matter, on newer versions of DragonFly BSD we should use `<sys/malloc.h>`. Doing so fixes the build. We can solve this by introducing `HAVE_SYS_MALLOC_H`, I guess.
To lessen maintenance pressure, I would suggest to assume that Jemalloc is not available on Dragon Fly BSD and use the generic code (the one used on OpenBSD)February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3795performance degradation on NSEC3 zones when queried with DO=12023-02-01T13:31:57ZPetr Špačekpspacek@isc.orgperformance degradation on NSEC3 zones when queried with DO=1### Summary
Authoritative zone signed using RSASHA256 + NSEC3 with 15 iterations and no opt-out suffers from large performance degradation when queried with DO=1.
### BIND version used
* ~"Affects v9.19": v9_19_9
* ~"Affects v9.18": v...### Summary
Authoritative zone signed using RSASHA256 + NSEC3 with 15 iterations and no opt-out suffers from large performance degradation when queried with DO=1.
### BIND version used
* ~"Affects v9.19": v9_19_9
* ~"Affects v9.18": v9_18_11
* ~"Affects v9.16": v9_16_36
### Steps to reproduce
1. Start with an empty zone: [empty.db](/uploads/78f9e83a3ba44691462255a842ec70c6/empty.db)
2. Generate new keys, I used alg 8 KSK 2048 b, ZSK 1024 b: [Knet.+008+42541.private](/uploads/6ae5ccf49604074e33dcab6b60491ae4/Knet.+008+42541.private) [Knet.+008+42541.key](/uploads/5f3e28bd750148db6aa88636ec14cbbe/Knet.+008+42541.key) [Knet.+008+62311.private](/uploads/5c5ba007421f0fd65246feb30f621bfb/Knet.+008+62311.private) [Knet.+008+62311.key](/uploads/8bf39172d04789154af9aed67bb83449/Knet.+008+62311.key)
3. Resign the original zone using new keys and 15 NSEC3 iterations with non-empty salt
```
dnssec-signzone -S -o net -u -H 15 -3 0123456789ABCDEF empty.db
```
[empty.db.signed](/uploads/1066d5cebdc4eed9999551c1a3d6b411/empty.db.signed)
4. Load into auth:
```
options {
check-names primary ignore;
check-names secondary ignore;
recursion no;
allow-query {
"any";
};
check-dup-records warn;
check-integrity no;
check-mx ignore;
check-mx-cname ignore;
check-sibling no;
check-spf ignore;
check-srv-cname ignore;
check-wildcard no;
notify no;
};
zone "net." {
type primary;
file "/usr/etc/empty.db.signed";
masterfile-format text;
};
```
5. Query with DO=0 and DO=1.
Query list can contain a single line:
`aaa.net. A`
Repeating the query suffices to reproduce the problem.
Command:
```
dnsperf -d qlist -s 10.10.126.46 -p 53 -S1 -T8 -O suppress=timeout -c 64 -q 1000 -l 10 -D
```
6. Compare max QPS - use `dnsperf` without and with `-D` to set the bit
### What is the current *bug* behavior?
On a 16 thread machine, 8 cores, AWS type c5n.4xlarge, the performance degradation from DO=0 to DO=1 is roughly 10x.
### What is the expected *correct* behavior?
Well, smaller performance drop :-)
### CPU profiling
Beware: Done on a `net.` zone which exhibits ~ 3-4x degradation. Profile is from v9_18_8.
#### DO=0
![flame.do0.try1.svg](/uploads/b8423164a1416387b5b04cc291b39d4e/flame.do0.try1.svg)
#### DO=1
![flame.do1.try1.svg](/uploads/369400e1f2e02c9ee94590066416ac28/flame.do1.try1.svg)
#### diff between DO=0 and DO=1 run
![diff-do0-vs-do1.svg](/uploads/4c29e97de144a0bb7dd71185a179bbbc/diff-do0-vs-do1.svg)February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)https://gitlab.isc.org/isc-projects/bind9/-/issues/3793dnssec-signzone doesn't parallelise signing2023-02-01T13:47:44ZOndřej Surýdnssec-signzone doesn't parallelise signing@fabled discovered that there's an error how `assignwork()` is called when `sign()` returns data to the writer - all the work is done by the main thread and all other workers are idle.@fabled discovered that there's an error how `assignwork()` is called when `sign()` returns data to the writer - all the work is done by the main thread and all other workers are idle.February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3789fully remove DSCP2023-02-01T12:59:10ZEvan Huntfully remove DSCPThis is a continuation of #3773, which marked DSCP as obsolete and removed the vestigial implementation code in 9.19 and 9.18, and marked it deprecated in 9.16. For 9.19 we will now remove the remaining DSCP parsing code and make configu...This is a continuation of #3773, which marked DSCP as obsolete and removed the vestigial implementation code in 9.19 and 9.18, and marked it deprecated in 9.16. For 9.19 we will now remove the remaining DSCP parsing code and make configuration of DSCP values an error.February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3783parental DS requests need RD=12023-01-19T15:56:50ZMark Andrewsparental DS requests need RD=1Parental DS requests need to set RD=1 and check if they get AA=1 or RA=1. If the request is to an authoritative server it should return AA=1. If it is to a recursive server it should return RA=1.Parental DS requests need to set RD=1 and check if they get AA=1 or RA=1. If the request is to an authoritative server it should return AA=1. If it is to a recursive server it should return RA=1.February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3781Deprecate source port configuration2023-12-07T13:15:14ZEvan HuntDeprecate source port configurationDeprecate the definition of the source ports and rely on the operating system to provide reasonable ephemeral port range for outgoing UDP and TCP connections.
Specifying outgoing ports is a bad practice, it's already discouraged, it's ...Deprecate the definition of the source ports and rely on the operating system to provide reasonable ephemeral port range for outgoing UDP and TCP connections.
Specifying outgoing ports is a bad practice, it's already discouraged, it's prone to errors (it's not only specifying single port, but specifying not enough ports removes a layer of protection) and is already full of caveats like:
```
.. note:: The address specified in the :any:`query-source` option is used for both
UDP and TCP queries, but the port applies only to UDP queries. TCP
queries always use a random unprivileged port.
.. warning:: Specifying a single port is discouraged, as it removes a layer of
protection against spoofing errors.
.. warning:: The configured :term:`port` must not be the same as the listening port.
```
The deprecation will include:
* specifying **port** in the following statements:
- `query-source`
- `query-source-v6`
- `transfer-source`
- `transfer-source-v6`
- `notify-source`
- `notify-source-v6`
- `parental-source`
- `parental-source-v6`
-
* the following statements as a whole:
- `use-v4-udp-ports`
- `use-v6-udp-ports`
- `avoid-v4-udp-ports`
- `avoid-v6-udp-ports`
See #3843 for the corresponding option removal issue.February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)