BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-02-29T15:48:40Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4615Improve dnssec-keygen warnings when unnecessary parameters are ignored2024-02-29T15:48:40ZCathy AlmondImprove dnssec-keygen warnings when unnecessary parameters are ignored### Summary
The specific instance that inspires this bug report is that these commands
> dnssec-keygen -b 2048 -a ECDSAP256SHA256 -f KSK example.com
> dnssec-keygen -b 2048 -a ECDSAP256SHA256 example.com
.. don't generate a warning th...### Summary
The specific instance that inspires this bug report is that these commands
> dnssec-keygen -b 2048 -a ECDSAP256SHA256 -f KSK example.com
> dnssec-keygen -b 2048 -a ECDSAP256SHA256 example.com
.. don't generate a warning that the -b 2048 is ignored because key algorithm ECDSAP256SHA256 has a predefined length
There may be other scenarios worth checking at the same time?
### BIND version affected
Noted against 9.16.28 (a long time ago), but the situation I don't think has changed.
### Steps to reproduce
See above - just do it?
### What is the current *bug* behavior?
No warning. dnssec-keygen goes its own sweet way and uses its built-in default length for this key
### What is the expected *correct* behavior?
It would have been really helpful to have known that the keys didn't have the requested length - this caused a bunch of other problems during migration to dnssec-policy using these keys!
What actually happened is that after restarting named and switching to dnssec-policy with these parameters:
> ksk lifetime unlimited algorithm ECDSAP256SHA256 2048;
> zsk lifetime unlimited algorithm ECDSAP256SHA256 2048;
named didn't recognise the existing keys as matching the policy and generated new ones for the zone, retiring the old keys - which is just what you don't want when migrating your existing zone's configuration and not intending to abruptly re-sign it with new keys (aargh!)
In fact, named-checkconf does fuss about the 2048:
> /etc/namedb/named.conf:54: dnssec-policy: key algorithm ECDSAP256SHA256 has predefined length; ignoring length value 2048
> /etc/namedb/named.conf:55: dnssec-policy: key algorithm ECDSAP256SHA256 has predefined length; ignoring length value 2048
So perhaps this is another small bug too - if the length is irrelevant and ignored - why did it not just recognise the existing keys?
It was perfectly happy with the same keys and with:
> ksk lifetime unlimited algorithm ECDSAP256SHA256;
> zsk lifetime unlimited algorithm ECDSAP256SHA256;May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4614Fix memory consumption in qp (Follow-up from "create QPDB zone database")2024-03-29T09:26:31ZMatthijs Mekkingmatthijs@isc.orgFix memory consumption in qp (Follow-up from "create QPDB zone database")The following discussion from !8543 should be addressed:
- [x] @pspacek started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8543#note_438118): (+1 comment)
> I gave it a quick look and sanity check - ...The following discussion from !8543 should be addressed:
- [x] @pspacek started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8543#note_438118): (+1 comment)
> I gave it a quick look and sanity check - loaded `net.` TLD into this version (configured as secondary - [named.conf](/uploads/d55553c50824d4c519123d18d743225f/named.conf)).
>
> Here's a quick summary:
>
> | metric | main | qpdb-heavy | 4411-qpdb-lite |
> |---------------------------------------------|---------|------------|----------------|
> | zone load time | 4:20 | 1:30 | 1:38 |
> | memory RSS | 6.2 GiB | 12.8 GiB | 12.8 GiB |
> | repeated bla.net. A query [QPS] | 155 k | 160 k | 152 k |
> | repeated bla.net. A query [CPU utilization] | 400 % | 300 % | 320 % |
> | random delegations [QPS] | 150 k | 150 k | 148 k |
> | random delegations [CPU utilization] | 470 % | 370 % | 410 % |
>
> TL;DR smaller CPU usage while doubling amount of memory.
>
> Statistics channel output after just loading the zone (no queries yet):
> - [main.json](/uploads/b0e43a7f25acb60fad379fee27577f06/main.json)
> - [heavy.json](/uploads/42baadb5c3dba87142ef36552c71d725/heavy.json)
> - [lite.json](/uploads/7bc0516d2565aba18692cc9bf0bd50b1/lite.json)April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4613Release Checklist for BIND 9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.222024-03-27T21:12:56ZPetr Špačekpspacek@isc.orgRelease Checklist for BIND 9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22## Release Schedule
**Code Freeze:** Wednesday, 6 March 2024
**Tagging Deadline:** Monday, 11 March 2024
**Public Release:** Wednesday, 20 March 2024
## Warning
This release uses non-standard process. It is based on February releas...## Release Schedule
**Code Freeze:** Wednesday, 6 March 2024
**Tagging Deadline:** Monday, 11 March 2024
**Public Release:** Wednesday, 20 March 2024
## Warning
This release uses non-standard process. It is based on February releases (9.16.48, 9.18.24, 9.19.21) and adds cherry-picked MRs on top.
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.16.49](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.16)
- [9.16.49-S1](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.16-S)
- [9.18.25](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.18)
- [9.18.25-S1](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.18-S)
- [9.19.22](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&sort=created_asc&state=closed&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.19)
**Merge requests merged into the milestone without a release note:**
- [9.16.49](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.16)
- [9.16.49-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.16-sub)
- [9.18.25](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.18)
- [9.18.25-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=bind-9.18-sub)
- [9.19.22](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29¬%5Blabel_name%5D%5B%5D=Release+Notes&target_branch=main)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.16.49](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.16)
- [9.16.49-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.16-sub)
- [9.18.25](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.18)
- [9.18.25-S1](https://gitlab.isc.org/isc-private/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29&label_name%5B%5D=No+CHANGES&target_branch=bind-9.18-sub)
- [9.19.22](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&sort=merged_at&state=merged&milestone_title=March+2024+%289.16.49%2C+9.16.49-S1%2C+9.18.25%2C+9.18.25-S1%2C+9.19.22%29&label_name%5B%5D=No+CHANGES&target_branch=main)
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Rebase -S editions on top of current open-source versions: `git checkout bind-9.18-sub && git rebase origin/bind-9.18`
- [x] ***(QA)*** [Inform](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/inform_supp_marketing.py) Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform. Check [public](https://gitlab.isc.org/isc-projects/bind9/-/pipelines?scope=all&source=schedule) and [private](https://gitlab.isc.org/isc-private/bind9/-/pipelines?scope=all&source=schedule) scheduled pipelines.
- [x] ***(QA)*** Check charts from `shotgun:*` jobs in the scheduled pipelines to verify there is no unexplained performance drop for any protocol.
- [x] ***(QA)*** Check [Perflab](https://perflab.isc.org/) 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](https://gitlab.isc.org/isc-private/bind9/-/merge_requests/)[^1] (Subscription Edition only).
- [x] ***(QA)*** [Ensure](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/check_backports.py) all merge requests marked for backporting have been indeed backported.
- [x] ***(QA)*** ~~[Announce](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/inform_code_freeze.py) (on Mattermost) that the code freeze is in effect.~~
### Before the Tagging Deadline
- [x] ***(QA)*** Inspect the current output of the `cross-version-config-tests` job to verify that no unexpected backward-incompatible change was introduced in the current release cycle.
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well. [Example](https://gitlab.isc.org/isc-private/bind9/-/merge_requests/510)
- [x] ***(QA)*** Add a release marker to `CHANGES`. Examples: [9.18](https://gitlab.isc.org/isc-projects/bind9/-/commit/f14d8ad78c0506fd4247187f2177f8eceeb6b3b9), [9.16](https://gitlab.isc.org/isc-projects/bind9/-/commit/1bcdf21874f99a00da389d723e0ad07dfd70f9f1)
- [x] ***(QA)*** Add a release marker to `CHANGES.SE` (Subscription Edition only). [Example](https://gitlab.isc.org/isc-private/bind9/-/commit/0f03d5737bcbdaa1bf713c6db1887b14938c3421)
- [x] ***(QA)*** Update BIND 9 version in `configure.ac` ([9.18+](https://gitlab.isc.org/isc-projects/bind9/-/commit/3c85ab7f4c35e6d8acef1393606002a0a8730100)) or `version` ([9.16](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7692/diffs?commit_id=1bcdf21874f99a00da389d723e0ad07dfd70f9f1)).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org` (9.16).
- [x] ***(QA)*** ~~Update GitLab settings for all maintained branches to disallow merging to them: [public](https://gitlab.isc.org/isc-projects/bind9/-/settings/repository), [private](https://gitlab.isc.org/isc-private/bind9/-/settings/repository)~~
- [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 the HTML version 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](https://gitlab.isc.org/isc-private/bind9/-/pipelines?scope=tags) created and sign off on the releases to be published.
- [x] ***(QA)*** ~~Update GitLab settings for all maintained branches to allow merging to them again: [public](https://gitlab.isc.org/isc-projects/bind9/-/settings/repository), [private](https://gitlab.isc.org/isc-private/bind9/-/settings/repository)~~
- [x] ***(QA)*** Prepare (using [`version_bump.py`](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/version_bump.py)) and merge MRs resetting the release notes and updating the version string for [each](!8856) [maintained](!8857) [branch](!8858).
- [x] ***(QA)*** Rebase the Subscription Edition branches (including recent release prep commits) on top of the open source branches with updated version strings.
- [x] ***(QA)*** [Announce (on Mattermost) that the code freeze is over.](https://mattermost.isc.org/isc/pl/8chqbcam7igq5nu8ryxtrjfq4r)
- [x] ***(QA)*** [Request signatures for the tarballs, providing their location and checksums. Ask signers on Mattermost.](https://mattermost.isc.org/isc/pl/ku6mfsqaktrq3ryz4iuth8183c)
- [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: Run `publish_bind.sh` on repo.isc.org to pre-publish.
- [x] ***(QA)*** ~~Prepare the `patches/` subdirectory for each security release (if applicable).~~
- [x] ***(QA)*** 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 (in [cloudsmith branch in private repo](https://gitlab.isc.org/isc-private/rpms/bind/-/tree/cloudsmith)). [Example](https://gitlab.isc.org/isc-private/rpms/bind/-/commit/e2512f4cfaf991827a635e374e7e93b27a5f38ba)
- [x] ***(Marketing)*** ~~Prepare and send out ASN emails (as outlined in the CVE checklist; if applicable).~~
### On the Day of Public Release
- [x] ***(QA)*** ~~Wait for clearance from Security Officer to proceed with the public release (if applicable).~~
- [x] ***(QA)*** Place tarballs in public location on FTP site.
- [x] ***(QA)*** Inform Marketing of the release, providing FTP links for the published tarballs.
- [x] ***(QA)*** [Use the Printing Press project to prepare a release announcement email.](isc-private/printing-press!103)
- [x] ***(Marketing)*** Publish links to downloads on ISC website. [Example](https://gitlab.isc.org/website/theme-staging-site/-/commit/1ac7b30b73cb03228df4cd5651fa4e774ac35625)
- [x] ***(Marketing)*** Update the BIND -S information document in SF with download links to the new versions. (If this is a security release, this will have already been done as part of the ASN process.)
- [x] ***(Marketing)*** Update the Current Software Versions document in the SF portal if any stable versions were released.
- [x] ***(Marketing)*** Send the release announcement email to the *bind-announce* mailing list (and to *bind-users* if a major release - [example](https://lists.isc.org/pipermail/bind-users/2022-January/105624.html)).
- [x] ***(Marketing)*** Announce release on social media sites.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Support)*** Add the new releases to the [vulnerability matrix in the Knowledge Base](https://kb.isc.org/docs/aa-00913).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages in [private repo](https://gitlab.isc.org/isc-private/rpms/bind/-/tree/cloudsmith). [Example](https://gitlab.isc.org/isc-private/rpms/bind/-/commit/2007d566db81dd9dfd79e571e2f600a3bc284da4)
- [x] ***(QA)*** Build [public RPMs](https://gitlab.isc.org/isc-packages/rpms/bind). [Example commit](https://gitlab.isc.org/isc-packages/rpms/bind/-/commit/3b5e851ea7c4e3570371a4878b5461f02a44f8cc) which triggers [Copr builds](https://copr.fedorainfracloud.org/coprs/isc/) automatically
- [x] ***(SwEng)*** Build Debian/Ubuntu packages.
- [x] ***(SwEng)*** Update Docker files [here](https://gitlab.isc.org/isc-projects/bind9-docker/-/branches) and make sure push is synchronized to [GitHub](https://github.com/isc-projects/bind9-docker). [Docker Hub](https://hub.docker.com/r/internetsystemsconsortium/bind9) should pick it up automatically. [Example](https://gitlab.isc.org/isc-projects/bind9-docker/-/commit/cada7e10e9af951595c98bfffc4bd42512faac05)
- [x] ***(QA)*** Ensure all new tags are annotated and signed. `git show --show-signature v9.19.12`
- [x] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Using [`merge_tag.py`](https://gitlab.isc.org/isc-private/bind-qa/-/blob/master/bind9/releng/merge_tag.py), merge published release tags back into the their relevant development/maintenance branches.
- [x] ***(QA)*** ~~Ensure `allow_failure: true` is removed from the `cross-version-config-tests` job if it was set during the current release cycle.~~
- [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](https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=milestone_due_desc&state=opened&confidential=yes) 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`.](isc-projects/images!305)
- [x] ***(QA)*** [Run a pipeline to rebuild all images used in GitLab CI.](https://gitlab.isc.org/isc-projects/images/-/pipelines/168133)
- [x] ***(QA)*** [Update `metadata.json` with the upcoming release information.](isc-private/bind-qa!96)
[^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.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4612resolver crashes on 10-0-0-38.abcdefghijklmnopqrstuvwxyz012345.plex.direct DS...2024-03-06T00:16:14ZPetr Špačekpspacek@isc.orgresolver crashes on 10-0-0-38.abcdefghijklmnopqrstuvwxyz012345.plex.direct DS query### Summary
Processing query `10-0-0-38.abcdefghijklmnopqrstuvwxyz012345.plex.direct DS` causes the resolver to crash.
### BIND version affected
* ~"Affects v9.19": 88c56e25a1e6c0c994f38a5db4c6b6f677ec633a
It seems it does NOT affect ...### Summary
Processing query `10-0-0-38.abcdefghijklmnopqrstuvwxyz012345.plex.direct DS` causes the resolver to crash.
### BIND version affected
* ~"Affects v9.19": 88c56e25a1e6c0c994f38a5db4c6b6f677ec633a
It seems it does NOT affect stable branches.
### Steps to reproduce
1. `named -g -c /dev/null`
2. `dig @127.0.0.1 10-0-0-38.abcdefghijklmnopqrstuvwxyz012345.plex.direct DS`
3. :boom:
### What is the current *bug* behavior?
```
28-Feb-2024 14:35:04.363 chase DS servers resolving '10-0-0-38.abcdefghijklmnopqrstuvwxyz012345.plex.direct/DS/IN': 18.202.136.15#53
28-Feb-2024 14:35:04.466 resolver.c:10427: REQUIRE(!dns_rdataset_isassociated(rdataset)) failed
```
### What is the expected *correct* behavior?
No crash.
### Relevant logs
- [Debug -d 99 log](/uploads/7aeca53fc41d38c9c9cbfa8dac8b3475/log)March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4611Stub zones return unexpected NS records2024-03-06T00:14:18ZPeter DaviesStub zones return unexpected NS records### Summary
BIND server B with a static-stub zone configured with a server address of BIND
server A, a secondary for that zone, may return unexpected NS records.
### BIND version affected
```
I tested with BIND 9.19.21, but I belie...### Summary
BIND server B with a static-stub zone configured with a server address of BIND
server A, a secondary for that zone, may return unexpected NS records.
### BIND version affected
```
I tested with BIND 9.19.21, but I believe this behaviour probably goes back to BIND 9.11.x
named -V
BIND 9.19.21 (Development Release) <id:c030a67>
running on Linux x86_64 6.2.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 16:51:53 UTC 2023
built by make with '--enable-fixed-rrset' '--enable-dnstap' '--enable-querytrace=yes' '--with-openssl' '--with-libxml2' '--with-json-c' '--enable-full-report' 'PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/'
compiled by GCC 12.3.1 20230508 (Red Hat 12.3.1-1)
compiled with OpenSSL version: OpenSSL 3.0.9 30 May 2023
linked to OpenSSL version: OpenSSL 3.0.9 30 May 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.46.0
compiled with liburcu version: 0.15.0-pre
compiled with jemalloc version: 5.2.1
compiled with libnghttp2 version: 1.51.0
linked to libnghttp2 version: 1.51.0
compiled with libxml2 version: 2.10.3
linked to libxml2 version: 21004
compiled with json-c version: 0.15
linked to json-c version: 0.17
compiled with zlib version: 1.2.12
linked to zlib version: 1.2.12
compiled with protobuf-c version: 1.4.1
linked to protobuf-c version: 1.4.1
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): no
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /usr/local/etc/named.conf
rndc configuration: /usr/local/etc/rndc.conf
nsupdate session key: /usr/local/var/run/named/session.key
named PID file: /usr/local/var/run/named/named.pid
```
### Steps to reproduce
1) set up servers A and B with the configurations below.
2) Query Server B repeatedly for an RR from the static-stub zone:
```
While true do dig hgw.ddi.com @127.0.0.1
; <<>> DiG 9.19.21 <<>> hgw.ddi.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27748
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 23cb1ccef98f3bf00100000065df1c8b908417789e893016 (good)
;; QUESTION SECTION:
;hgw.ddi.com. IN A
;; ANSWER SECTION:
hgw.ddi.com. 300 IN A 10.0.0.1
;; AUTHORITY SECTION:
ddi.com. 260 IN NS bialistock.ddi.com.
ddi.com. 260 IN NS haparanda.ddi.com.
;; ADDITIONAL SECTION:
haparanda.ddi.com. 300 IN A 10.0.0.237
bialistock.ddi.com. 300 IN A 10.0.0.49
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Feb 28 11:44:11 UTC 2024
;; MSG SIZE rcvd: 165
```
### What is the current *bug* behavior?
When the NS records in the authority section expire, Server B add the server-names
from its static-stub configuration as NS records plus a NS record in the name of
the domain itself
```
...
; <<>> DiG 9.19.21 <<>> hgw.ddi.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50265
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 88424ea83ed9b09d0100000065df1d8b76b871a0c1e4d1e7 (good)
;; QUESTION SECTION:
;hgw.ddi.com. IN A
;; ANSWER SECTION:
hgw.ddi.com. 44 IN A 10.0.0.1
;; AUTHORITY SECTION:
ddi.com. 4 IN NS bialistock.ddi.com.
ddi.com. 4 IN NS haparanda.ddi.com.
;; ADDITIONAL SECTION:
haparanda.ddi.com. 44 IN A 10.0.0.237
bialistock.ddi.com. 44 IN A 10.0.0.49
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Feb 28 11:48:27 UTC 2024
;; MSG SIZE rcvd: 165
; <<>> DiG 9.19.21 <<>> hgw.ddi.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39703
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 329a1ed8e54b28d30100000065df1d90545987c64fe602f2 (good)
;; QUESTION SECTION:
;hgw.ddi.com. IN A
;; ANSWER SECTION:
hgw.ddi.com. 39 IN A 10.0.0.1
;; AUTHORITY SECTION:
ddi.com. 86400 IN NS StaticStubZoneNS-1.org.
ddi.com. 86400 IN NS ddi.com.
ddi.com. 86400 IN NS StaticStubZoneNS-2.org.
```
### What is the expected *correct* behavior?
I expect to see the NS records from the domain or none at all.
### Relevant configuration files
Server A config:
```
options {
directory "/home/named";
pid-file "named.pid";
listen-on-v6 { none; };
dnssec-validation auto;
recursion yes;
allow-recursion { any; };
};
zone "ddi.com" IN {
type secondary;
primaries { 10.0.0.4;};
file "s/db.ddi.com";
allow-transfer {any;};
notify false;
};
```
Server B config:
```
options {
directory "/home/named";
pid-file "named.pid";
listen-on-v6 { none; };
dnssec-validation no;
minimal-responses no;
recursion yes;
max-cache-size 90%;
allow-recursion { any; };
};
zone "ddi.com" IN {
type static-stub;
server-addresses {
10.0.0.182;
};
server-names {
"StaticStubZoneNS-1.org";
"StaticStubZoneNS-2.org";
};
};
```
Zone file:
```
ddi.com. 86400 IN SOA haparanda.ddi.com. support.ddi.com. 2024021733 1800 900 604800 86400
ddi.com. 260 IN NS haparanda.ddi.com.
ddi.com. 260 IN NS bialistock.ddi.com.
alice-laptop.ddi.com. 600 IN A 10.0.0.149
bag-local-lyset.ddi.com. 300 IN A 10.0.0.15
bialistock.ddi.com. 300 IN A 10.0.0.49
haparanda.ddi.com. 300 IN A 10.0.0.237
hgw.ddi.com. 300 IN A 10.0.0.1
...
```
### Relevant logs
Server B has no IPV6 connectivity the following was logged at startup:
```
Feb 28 11:44:11 bialistock named[235198]: network unreachable resolving 'StaticStubZoneNS-1.org/AAAA/IN': 2001:500:c::1#53
Feb 28 11:44:11 bialistock named[235198]: network unreachable resolving 'StaticStubZoneNS-2.org/A/IN': 2001:500:c::1#53
```
[SF00001680](https://isc.lightning.force.com/lightning/r/Case/500S60000054BVSIA2/view)https://gitlab.isc.org/isc-projects/bind9/-/issues/4609ADB memory growth in 9.192024-02-28T06:53:58ZOndřej SurýADB memory growth in 9.19During the 25h test, it was discovered that ADB and main memory contextx grows suspiciously:
![bindstats.memory.contexts.ADB._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1-9.19](/uploads/5e5f039e83e4a892554001b6c7348e92/bindstats....During the 25h test, it was discovered that ADB and main memory contextx grows suspiciously:
![bindstats.memory.contexts.ADB._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1-9.19](/uploads/5e5f039e83e4a892554001b6c7348e92/bindstats.memory.contexts.ADB._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1-9.19.png)
![bindstats.memory.contexts.main._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1-main-9.19](/uploads/bad7883a65948bfd2946b84fe6505cdf/bindstats.memory.contexts.main._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1-main-9.19.png)
The growth is much slower in 9.18:
![bindstats.memory.contexts.ADB._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1](/uploads/4cc202485a129130ecd978cf23ad452a/bindstats.memory.contexts.ADB._sum_inuse-http_3A_2F_2F127.0.0.1_3A8888_2Fjson_2Fv1.png)May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4608Ensure static stub NS records are not returned2024-03-29T10:17:32ZMark AndrewsEnsure static stub NS records are not returnedstatic-stub synthesises NS record which shouldn't be returned to clients. Normally the NS records from the actual zone will be returned but not always.
- Setup a static-stub for "com" and disable minimal responses.
- query for foo.com ...static-stub synthesises NS record which shouldn't be returned to clients. Normally the NS records from the actual zone will be returned but not always.
- Setup a static-stub for "com" and disable minimal responses.
- query for foo.com NS (TTL is 600)
- wait 120 seconds
- query for foo.com A (TTL is 600)
- wait 500 seconds
- query for foo.com A
```
; <<>> DiG 9.19.20-dev <<>> foo.com -p 5555
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18858
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: dddb220761d487fa0100000065dec10ee6a221e99d9baa11 (good)
;; QUESTION SECTION:
;foo.com. IN A
;; ANSWER SECTION:
foo.com. 100 IN A 34.206.39.153
;; AUTHORITY SECTION:
com. 86400 IN NS com.
;; Query time: 2 msec
;; SERVER: ::1#5555(::1) (UDP)
;; WHEN: Wed Feb 28 16:13:50 AEDT 2024
;; MSG SIZE rcvd: 94
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4607chain system test: mem.c:1311: INSIST(unreachable) failed2024-03-18T08:53:51ZMichal Nowakchain system test: mem.c:1311: INSIST(unreachable) failedJob [#4071483](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4071483) failed for f42a441b05408f4e816ea44a4780667a00c5fb86.
ns1 of the `chain` system test ended up in a bad place.
```
context: 0x7b3000001b00 (zonemgr-mctxpoo): 2 refe...Job [#4071483](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4071483) failed for f42a441b05408f4e816ea44a4780667a00c5fb86.
ns1 of the `chain` system test ended up in a bad place.
```
context: 0x7b3000001b00 (zonemgr-mctxpoo): 2 references
Dump of all outstanding memory allocations:
ptr 0x7b5000020200 size 496 file rbtdb.c line 3866
ptr 0x7b6000001000 size 1016 file rbt-zonedb.c line 2091
mem.c:1311: INSIST(unreachable) failed
```
```
2024-02-27 17:50:11 INFO:chain D:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D chain_tmp_qm1vyy5o-ns1 -m r'.
2024-02-27 17:50:11 INFO:chain D:Program terminated with signal SIGABRT, Aborted.
2024-02-27 17:50:11 INFO:chain D:#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
2024-02-27 17:50:11 INFO:chain D:Downloading source file /usr/src/debug/glibc-2.38-16.fc39.x86_64/nptl/pthread_kill.c...
2024-02-27 17:50:11 INFO:chain D:44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;
2024-02-27 17:50:11 INFO:chain D:[Current thread is 1 (Thread 0x7f96faa8a380 (LWP 77097))]
2024-02-27 17:50:11 INFO:chain D:#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
2024-02-27 17:50:11 INFO:chain D:#1 0x00007f96fb0ed8a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
2024-02-27 17:50:11 INFO:chain D:#2 0x00007f96fb09b8ee in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
2024-02-27 17:50:11 INFO:chain D:#3 0x00007f96fb0838ff in __GI_abort () at abort.c:79
2024-02-27 17:50:11 INFO:chain D:#4 0x00007f96fc0bee3c in __interceptor_abort (fake=-89613312) at ../../../../libsanitizer/tsan/tsan_interceptors_posix.cpp:1875
2024-02-27 17:50:11 INFO:chain D:#5 0x0000000000427e49 in assertion_failed (file=<optimized out>, line=1311, type=<optimized out>, cond=0x7f96fc065ac3 "unreachable") at main.c:234
2024-02-27 17:50:11 INFO:chain D:#6 0x00007f96fc00b194 in isc_assertion_failed (file=file@entry=0x7f96fc0624cb "mem.c", line=line@entry=1311, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7f96fc065ac3 "unreachable") at assertions.c:48
2024-02-27 17:50:11 INFO:chain D:#7 0x00007f96fc02f45f in isc__mem_checkdestroyed () at mem.c:1311
2024-02-27 17:50:11 INFO:chain D:#8 0x00007f96fc02f54c in mem_shutdown () at mem.c:442
2024-02-27 17:50:11 INFO:chain D:#9 0x00007f96fc0da084 in __interceptor_pthread_once (o=o@entry=0x7f96fc07dec8 <shut_once>, f=f@entry=0x7f96fc02f533 <mem_shutdown>) at ../../../../libsanitizer/tsan/tsan_interceptors_posix.cpp:1551
2024-02-27 17:50:11 INFO:chain D:#10 0x00007f96fc02ce7e in isc__mem_shutdown () at mem.c:455
2024-02-27 17:50:11 INFO:chain D:#11 0x00007f96fc023088 in isc__shutdown () at lib.c:67
2024-02-27 17:50:11 INFO:chain D:#12 0x00007f96fd0ec0f2 in _dl_call_fini (closure_map=closure_map@entry=0x7f96fd0e98d0) at dl-call_fini.c:43
2024-02-27 17:50:11 INFO:chain D:#13 0x00007f96fd0f006e in _dl_fini () at dl-fini.c:114
2024-02-27 17:50:11 INFO:chain D:#14 0x00007f96fb09dfd6 in __run_exit_handlers (status=0, listp=<optimized out>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:111
2024-02-27 17:50:11 INFO:chain D:#15 0x00007f96fb09e11e in __GI_exit (status=<optimized out>) at exit.c:141
2024-02-27 17:50:11 INFO:chain D:#16 0x00007f96fb085151 in __libc_start_call_main (main=main@entry=0x429913 <main>, argc=argc@entry=12, argv=argv@entry=0x7ffe1fcbda88) at ../sysdeps/nptl/libc_start_call_main.h:74
2024-02-27 17:50:11 INFO:chain D:#17 0x00007f96fb08520b in __libc_start_main_impl (main=0x429913 <main>, argc=12, argv=0x7ffe1fcbda88, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe1fcbda78) at ../csu/libc-start.c:360
2024-02-27 17:50:11 INFO:chain D:#18 0x0000000000418d35 in _start ()
```
[core.77097-backtrace.txt](/uploads/dfe2e0c9ee3a48df96c87773f2674a12/core.77097-backtrace.txt)
[core.77097.gz](/uploads/6a868166ed706bec348e2930ddc5fa5c/core.77097.gz)
[named.run](/uploads/ef60bc0ac117defd99c6f3c831f99368/named.run)May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4606"dry-run" mode to help with dnssec-policy migration2024-02-28T10:46:36ZCarsten Strotmann"dry-run" mode to help with dnssec-policy migration### Description
For some users of BIND 9, esp. people are part time DNS admins only, migrating from manual DNSSEC key management with "auto-dnssec maintain;" towards "dnssec-policy" is difficult.
While the documentation provided by ISC...### Description
For some users of BIND 9, esp. people are part time DNS admins only, migrating from manual DNSSEC key management with "auto-dnssec maintain;" towards "dnssec-policy" is difficult.
While the documentation provided by ISC is good, there is currently no way to "verify" the new "dnssec-policy" configuration before enabling it. Experience has shown (in DNS training classes, but also in real world deployments) that there are many things that can go wrong:
- differences in the DNSSEC key configuration (old vs. new)
- file system permissions on the old key material
- file system location of the old key material
- issues with the time-events stored in the old key material
Going online with a slightly wrong configuration can cause an immediate key rollover, which might break the zone. Recovering from this situation is possible, but requires good knowledge of BIND 9 DNSSEC workings
### Request
Provide a "dnssec-policy dry-run" mode, where BIND 9 will log the next steps in the automatic DNSSEC management to the log files (e.g. category "DNSSEC"), but will not execute any changes to the DNSSEC signed zone or the key material. This will enable the user to test drive the new "dnssec-policy" to see if it will act as expected.
Admins can create a configuration with "dry-run" mode enabled, check the logfiles, and if the actions in the log-file match the expectations, the "dry-run" mode can be removed and the new configuration will become active.
### Links / referencesMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4605re-enable enginepkcs11 system test2024-03-29T09:38:56ZTom Krizekre-enable enginepkcs11 system testThe `enginepkcs11` test was accidentally disabled by a wrong `prereq.sh` condition in https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5924/diffs?commit_id=2e9fd6d0c11d0648589da5779baeefb5b98e855e#8b557d8387b0ad5e06dad7a7c2c6f6...The `enginepkcs11` test was accidentally disabled by a wrong `prereq.sh` condition in https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5924/diffs?commit_id=2e9fd6d0c11d0648589da5779baeefb5b98e855e#8b557d8387b0ad5e06dad7a7c2c6f6521febff5e_16_16.
Once [enabled](https://gitlab.isc.org/isc-projects/bind9/-/commit/f3d402d1aa2e359caa741ce2b4742795a4a37224), the test has a couple of [failures](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4068956) that need to be addressed:
```
2024-02-26 17:25:39 INFO:enginepkcs11.test_enginepkcs11 I:Test SOA is signed for ecdsap256sha256.same-policy.views in view1 (65)
2024-02-26 17:25:42 INFO:enginepkcs11.test_enginepkcs11 I:failed (SOA RRset not signed)
2024-02-26 17:25:42 INFO:enginepkcs11.test_enginepkcs11 I:Test DNSKEY is signed for ecdsap256sha256.same-policy.views in view1 (66)
2024-02-26 17:25:45 INFO:enginepkcs11.test_enginepkcs11 I:failed (DNSKEY RRset not signed)
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4604Fix initial tests in masterfile system test2024-03-08T11:12:54ZMark AndrewsFix initial tests in masterfile system testAll three of the initial tests should have a known good output to test against.
The BIND 8 tests should be testing against ttl1.
There should be independent failure reporting for the first three tests.All three of the initial tests should have a known good output to test against.
The BIND 8 tests should be testing against ttl1.
There should be independent failure reporting for the first three tests.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4603Comments to CVE-2023-56802024-02-26T16:05:08ZPeter DaviesComments to CVE-2023-5680Comments to CVE-2023-5680:
Description: When reviewing the fix for CVE-2023-5680 due to the crash we
reported separately, we've noticed many other suspicious points in its implemen
-tation. Though these are based on code inspect...Comments to CVE-2023-5680:
Description: When reviewing the fix for CVE-2023-5680 due to the crash we
reported separately, we've noticed many other suspicious points in its implemen
-tation. Though these are based on code inspection and we haven't checked whether
the issue is real or it can cause any practical problem like a crash, we're
deeply concerned about the overall quality of this implementation, and would
like to suggest ISC revisiting it, perhaps fundamentally.
The issues we've noticed are as follows (there may be more):
- it looks like a longer prefix match in ->old_ecs_root will not be found if
a shorter prefix match is found in ->ecs_root. When using two address prefix
trees, we ought to search both and use the longest prefix match, with ->ecs_root
in preference if both have equal prefix lengths.
- On a related note, it seems possible that copying (moving) data in old_ecs_root
to ecs_root can result in separate rdatasetheaders at the top level for the same record type.
- unlikely to be a big deal in practice, but this code in clean_iptree_nodedata()
probably doesn't do what it appears to intend; it results in cleaning up to 12
- as a meta issue, we're afraid the introduction of old_ecs_root and incremental
cleaning needs a lot more tests, especially low level unit tests, given its comp
-lexity. For example, if the last point is indeed an oversight, it could have
been caught by a unit test easily.
See also #4587https://gitlab.isc.org/isc-projects/bind9/-/issues/4601wrong filename looked when reading key files2024-02-23T20:10:41ZMichael Tokarevwrong filename looked when reading key files### Summary
When bind9 tools read a zone file with DNSKEY records, for which no .key file is provided but .private exists, a misleading error message is generated. For example:
```
$ dnssec-signzone 168.192.in-addr.arpa
dnssec-signzone...### Summary
When bind9 tools read a zone file with DNSKEY records, for which no .key file is provided but .private exists, a misleading error message is generated. For example:
```
$ dnssec-signzone 168.192.in-addr.arpa
dnssec-signzone: warning: dns_dnssec_keylistfromrdataset: error reading ./K168.192.in-addr.arpa.+007+13293.private: file not found
$ ls -l ./K168.192.in-addr.arpa.+007+13293.*
-rw------- 1 root root 1707 Oct 28 2011 ./K168.192.in-addr.arpa.+007+13293.private
```
So, it reports an existing file as "not found", while actually (according to strace) it looked for a .key file (which indeed does not exist, since it is inlined in the zone itself).
The end result is that this key is not processed at all, despite the tool has all the information, - the .key file contents is in the zone already (that's where dnssec-signzone found the `+007+13293` part, so it does have the DNSKEY record and don't actually need the .key file), and the .private file which it reported as missing (while not even trying to open it), is actually exists.
### BIND version affected
```
BIND 9.18.24-1-Debian (Extended Support Version) <id:>
running on Linux x86_64 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01)
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/reproducible-path/bind9-9.18.24=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 12.2.0
compiled with OpenSSL version: OpenSSL 3.0.11 19 Sep 2023
linked to OpenSSL version: OpenSSL 3.0.11 19 Sep 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.52.0
linked to libnghttp2 version: 1.52.0
compiled with libxml2 version: 2.9.14
linked to libxml2 version: 20914
compiled with json-c version: 0.16
linked to json-c version: 0.16
compiled with zlib version: 1.2.13
linked to zlib version: 1.2.13
linked to maxminddb version: 1.7.1
compiled with protobuf-c version: 1.4.1
linked to protobuf-c version: 1.4.1
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4600autosign system test hung in cross-version-config-tests CI job2024-03-08T11:25:56ZMichal Nowakautosign system test hung in cross-version-config-tests CI jobJob [#4058605](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4058605) failed for e5a98f14bf3203cf803fcc6bd9f3ff03a2b4a8f7 (CI artifacts were saved).
The `autosign` system test hung for 5 minutes on shutdown in [the `cross-version-con...Job [#4058605](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4058605) failed for e5a98f14bf3203cf803fcc6bd9f3ff03a2b4a8f7 (CI artifacts were saved).
The `autosign` system test hung for 5 minutes on shutdown in [the `cross-version-config-tests` CI job](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4058605). I see this for the second time in two days, and I think this is something new and will persist.
This CI job is unique compared to other system test CI jobs: it just starts and stops BIND servers to check that `named.conf` breakages introduced since the previous point release are not present. We had a problem in this scenario before: https://gitlab.isc.org/isc-projects/bind9/-/issues/4213.
```
23-Feb-2024 00:10:42.106 adjust_quantum: old=100, new=137
23-Feb-2024 00:10:42.106 calling free_rbtdb(.)
23-Feb-2024 00:10:42.106 done free_rbtdb(.)
23-Feb-2024 00:10:42.106 done free_rbtdb(oldsigs.example)
23-Feb-2024 00:10:42.106 done free_rbtdb(jitter.nsec3.example)
```
```
2024-02-23 00:18:18 INFO:autosign D:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D autosign_tmp_7ktl_4p5-ns3 -'.
2024-02-23 00:18:18 INFO:autosign D:Program terminated with signal SIGABRT, Aborted.
2024-02-23 00:18:18 INFO:autosign D:#0 0x00007f5df3ae9b9e in __GI_epoll_pwait (epfd=4, events=0x7ffe9b1a8be0, maxevents=1024, timeout=-1, set=0x0) at ../sysdeps/unix/sysv/linux/epoll_pwait.c:40
2024-02-23 00:18:18 INFO:autosign D:Download failed: Invalid argument. Continuing without source file ./misc/../sysdeps/unix/sysv/linux/epoll_pwait.c.
2024-02-23 00:18:18 INFO:autosign D:[Current thread is 1 (Thread 0x7f5df1217500 (LWP 52959))]
2024-02-23 00:18:18 INFO:autosign D:#0 0x00007f5df3ae9b9e in __GI_epoll_pwait (epfd=4, events=0x7ffe9b1a8be0, maxevents=1024, timeout=-1, set=0x0) at ../sysdeps/unix/sysv/linux/epoll_pwait.c:40
2024-02-23 00:18:18 INFO:autosign D:#1 0x00007f5df3ece522 in uv__io_poll (loop=0x7f5df0e53020, timeout=-1) at /usr/src/libuv-v1.47.0/src/unix/linux.c:1430
2024-02-23 00:18:18 INFO:autosign D:#2 0x00007f5df3eb3e20 in uv_run (loop=0x7f5df0e53020, mode=UV_RUN_DEFAULT) at /usr/src/libuv-v1.47.0/src/unix/core.c:447
2024-02-23 00:18:18 INFO:autosign D:#3 0x00007f5df46b0324 in loop_thread (arg=arg@entry=0x7f5df0e53000) at loop.c:284
2024-02-23 00:18:18 INFO:autosign D:#4 0x00007f5df46c1af1 in thread_body (wrap=0x7f5df0ee7420) at thread.c:85
2024-02-23 00:18:18 INFO:autosign D:#5 0x00007f5df46c1b6a in isc_thread_main (func=func@entry=0x7f5df46b0299 <loop_thread>, arg=0x7f5df0e53000) at thread.c:116
2024-02-23 00:18:18 INFO:autosign D:#6 0x00007f5df46b12c4 in isc_loopmgr_run (loopmgr=0x7f5df0e20a80) at loop.c:456
2024-02-23 00:18:18 INFO:autosign D:#7 0x000055ad3d813480 in main (argc=<optimized out>, argv=<optimized out>) at main.c:1574
```
[core.52959-backtrace.txt](/uploads/3594340469e8638ccfe6192044d7174a/core.52959-backtrace.txt)
[named.run](/uploads/9ff12f3ada8161d465dd0498f6dd7722/named.run)March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4599dns zone failed to reload after upgrade to latest ISC Bind (Ubuntu package)2024-02-26T15:38:01ZDavid Calafrancescodns zone failed to reload after upgrade to latest ISC Bind (Ubuntu package)<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please make sure that you make the new issue
confident...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please make sure that you make the new issue
confidential by clicking the checkbox at the bottom!
-->
### Summary
<!-- Concisely summarize the bug encountered. -->
### BIND version affected
<!--
Make sure you are testing with the **latest** supported version of BIND
for a given branch. Many bugs have been fixed over time!
See https://kb.isc.org/docs/supported-platforms for the current list.
The latest source is available from https://www.isc.org/download/#BIND
Paste the output of `named -V` here.
-->
named -V
```
BIND 9.16.48-Ubuntu (Extended Support Version) <id:0dab57e>
running on Linux x86_64 5.4.0-172-generic #190-Ubuntu SMP Fri Feb 2 23:24:22 UTC 2024
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--disable-isc-spnego' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-jSiMEl/bind9-9.16.48=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 9.4.0
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
compiled with libuv version: 1.34.2
linked to libuv version: 1.34.2
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
**Upgraded yesterday from this version: **
named -V
```
BIND 9.16.1-Ubuntu (Stable Release) <id:d497c32>
running on Linux x86_64 5.4.0-162-generic #179-Ubuntu SMP Mon Aug 14 08:51:31 UTC 2023
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--disable-isc-spnego' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-uTvsKR/bind9-9.16.1=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 9.4.0
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
<!--
This is extremely important! Be precise and use itemized lists, please.
Even if a default configuration is affected, please include the full configuration
files _you were testing with_.
Example:
1. Use _attached_ configuration file
2. Start BIND server with command: `named -g -c named.conf ...`
3. Simulate legitimate clients using command `dnsperf -S1 -d legit-queries ...`
4. Simulate attack traffic using command `dnsperf -S1 -d attack-queries ...`
-->
1. Zone file that was loading previous to upgrade now fails when the following lines are present in zone:
```
$ORIGIN _domainkey.gvtc.communication.gvtc.net.
hs1-2082415 CNAME gvtc-communication-gvtc-net.hs17a.dkim.hubspotemail.net.
hs2-2082415 CNAME gvtc-communication-gvtc-net.hs17b.dkim.hubspotemail.net.
$ORIGIN gvtc.communication.gvtc.net.
TXT "v=spf1 include:2082415.spf07.hubspotemail.net -all"
$ORIGIN gvtc.net.
```
The above fails to load zone with these errors:
```
Feb 23 01:15:31 ns0-0 named[1003]: /etc/bind/masters/db.gvtc.net:167: record with inherited owner (hs2-2082415._domainkey.gvtc.communication.gvtc.net) immediately after $ORIGIN (gvtc.communication.gvtc.net)
Feb 23 01:15:31 ns0-0 named[1003]: dns_master_load: /etc/bind/masters/db.gvtc.net:167: hs2-2082415._domainkey.gvtc.communication.gvtc.net: CNAME and other data
Feb 23 01:15:31 ns0-0 named[1003]: zone gvtc.net/IN: loading from master file /etc/bind/masters/db.gvtc.net failed: CNAME and other data
Feb 23 01:15:31 ns0-0 named[1003]: zone gvtc.net/IN: not loaded due to errors.
Feb 23 01:15:54 ns0-0 named[1003]: received control channel command 'reload gvtc.net'
Feb 23 01:15:54 ns0-0 named[1003]: /etc/bind/masters/db.gvtc.net:168: record with inherited owner (hs2-2082415._domainkey.gvtc.communication.gvtc.net) immediately after $ORIGIN (gvtc.communication.gvtc.net)
Feb 23 01:15:54 ns0-0 named[1003]: dns_master_load: /etc/bind/masters/db.gvtc.net:168: hs2-2082415._domainkey.gvtc.communication.gvtc.net: CNAME and other data
Feb 23 01:15:54 ns0-0 named[1003]: zone gvtc.net/IN: loading from master file /etc/bind/masters/db.gvtc.net failed: CNAME and other data
Feb 23 01:15:54 ns0-0 named[1003]: zone gvtc.net/IN: not loaded due to errors.
```
Zone was last edited on Feb 13th, 2024 and loaded without issue on prior version of ISC BIND9
Edited the zone to show this construct:
```
$ORIGIN _domainkey.gvtc.communication.gvtc.net.
hs1-2082415 CNAME gvtc-communication-gvtc-net.hs17a.dkim.hubspotemail.net.
hs2-2082415 CNAME gvtc-communication-gvtc-net.hs17b.dkim.hubspotemail.net.
; $ORIGIN gvtc.communication.gvtc.net.
; TXT "v=spf1 include:2082415.spf07.hubspotemail.net -all"
$ORIGIN gvtc.net.
$ORIGIN communication.gvtc.net.
gvtc TXT "v=spf1 include:2082415.spf07.hubspotemail.net -all"
$ORIGIN gvtc.net.
```
Now zone file loads cleanly again.
If we remove comments on two lines and comment the replacement lines, the zone fails. Flip it back to this formation, zone loads.
Only thing different as far as we can tell was updating Bind9 via Ubuntu.
### What is the current *bug* behavior?
<!-- What actually happens. -->
### What is the expected *correct* behavior?
<!-- What you should see instead. -->
### Relevant configuration files
<!-- Paste any relevant configuration files here - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential issue, it is advisable to
obscure key secrets; this can be done automatically by using
`named-checkconf -px`. -->
### Relevant logs
<!-- Paste any relevant logs here - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise. -->https://gitlab.isc.org/isc-projects/bind9/-/issues/4598statschannel test may fail due to a missing response2024-02-22T09:53:52ZTom Krizekstatschannel test may fail due to a missing response`statschannel` system tests [`test_traffic_xml`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4054038) ([9.18 job](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4002144)) or [`test_traffic_json`](https://gitlab.isc.org/isc-project...`statschannel` system tests [`test_traffic_xml`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4054038) ([9.18 job](https://gitlab.isc.org/isc-projects/bind9/-/jobs/4002144)) or [`test_traffic_json`](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3999177) may fail with:
```
_______________________________ test_traffic_xml _______________________________
[gw2] linux -- Python 3.12.1 /usr/bin/python3
/builds/isc-projects/bind9/bin/tests/system/statschannel/tests_xml.py:134: in test_traffic_xml
generic.test_traffic(fetch_traffic_xml, statsip="10.53.0.2", statsport=statsport)
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:211: in test_traffic
check_traffic(data, exp)
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:185: in check_traffic
assert ordered_data == ordered_expected
E AssertionError: assert [('dns-tcp-re...v6', []), ...] == [('dns-tcp-re...v6', []), ...]
E At index 6 diff: ('dns-udp-responses-sizes-sent-ipv4', [('96-111', 1)]) != ('dns-udp-responses-sizes-sent-ipv4', [('816-831', 1), ('96-111', 1)])
E Full diff:
E [
E ('dns-tcp-requests-sizes-received-ipv4', [('16-31', 1)]),
E ('dns-tcp-requests-sizes-received-ipv6', []),
E ('dns-tcp-responses-sizes-sent-ipv4', [('64-79', 1)]),
E ('dns-tcp-responses-sizes-sent-ipv6', []),
E ('dns-udp-requests-sizes-received-ipv4', [('32-47', 2)]),
E ('dns-udp-requests-sizes-received-ipv6', []),
E - ('dns-udp-responses-sizes-sent-ipv4', [('816-831', 1), ('96-111', 1)]),
E ? ----------------
E + ('dns-udp-responses-sizes-sent-ipv4', [('96-111', 1)]),
E ('dns-udp-responses-sizes-sent-ipv6', []),
E ]
```
```
______________________________ test_traffic_json _______________________________
[gw3] linux -- Python 3.11.2 /usr/bin/python3
/builds/isc-projects/bind9/bin/tests/system/statschannel/tests_json.py:104: in test_traffic_json
generic.test_traffic(fetch_traffic_json, statsip="10.53.0.2", statsport=statsport)
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:229: in test_traffic
check_traffic(data, exp)
/builds/isc-projects/bind9/bin/tests/system/statschannel/generic.py:185: in check_traffic
assert ordered_data == ordered_expected
E AssertionError: assert [('dns-tcp-re...v6', []), ...] == [('dns-tcp-re...v6', []), ...]
E At index 2 diff: ('dns-tcp-responses-sizes-sent-ipv4', [('64-79', 1), ('96-111', 1)]) != ('dns-tcp-responses-sizes-sent-ipv4', [('64-79', 1), ('816-831', 1), ('96-111', 1)])
E Full diff:
E [
E ('dns-tcp-requests-sizes-received-ipv4',
E [('16-31',
E 1),
E ('32-47',
E 2)]),
E ('dns-tcp-requests-sizes-received-ipv6',
E []),
E ('dns-tcp-responses-sizes-sent-ipv4',
E [('64-79',
E - 1),
E - ('816-831',
E 1),
E ('96-111',
E 1)]),
E ('dns-tcp-responses-sizes-sent-ipv6',
E []),
E ('dns-udp-requests-sizes-received-ipv4',
E [('32-47',
E 2)]),
E ('dns-udp-requests-sizes-received-ipv6',
E []),
E ('dns-udp-responses-sizes-sent-ipv4',
E [('816-831',
E 1),
E ('96-111',
E 1)]),
E ('dns-udp-responses-sizes-sent-ipv6',
E []),
E ]
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4597Potential race condition in TTL heap introduced by February 2024 BIND release...2024-03-07T22:29:41ZCathy AlmondPotential race condition in TTL heap introduced by February 2024 BIND release patchesReported to us by an OEM customer who integrates BIND into their own appliance and redistributes:
> In rbtdb.c, there's a call path expirenodeall()->expire_headerlist()->set_ttl()->isc_heap_increased() or isc_heap_decreased(), where a s...Reported to us by an OEM customer who integrates BIND into their own appliance and redistributes:
> In rbtdb.c, there's a call path expirenodeall()->expire_headerlist()->set_ttl()->isc_heap_increased() or isc_heap_decreased(), where a shared TTL heap (per node lock bucket) is modified. Previously, this path is protected by the node write lock, but it's now unprotected, so there can be a race on the heap with, e.g, another thread adding a cache entry to the cache (thus to the TTL heap). expirenodeall() is called via dns_db_expirenodeall(), which is indirectly used for "rndc dumpdb" or "dumpdb flushname/flushtree". So it may be possible, though I've not tried it myself, that invoking these rndc commands results in a crash on a busy recursive server.
>
> It's basically the same for other cases: expirenode() and delete_callback(), although in the latter case the protected data is different. Also, we've found that there's probably no code path to these functions in practice, so it's not a big deal.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4596Regression in cache cleaning2024-03-08T11:20:36ZOndřej SurýRegression in cache cleaningThere's an regression introduced in the fix to #4383 that causes the cache memory to clean too slow, so busy resolvers can run out of configured cache memory by not cleaning expired (TTL-expired) records to be not cleaned from the memory...There's an regression introduced in the fix to #4383 that causes the cache memory to clean too slow, so busy resolvers can run out of configured cache memory by not cleaning expired (TTL-expired) records to be not cleaned from the memory fast enough.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4595Regression in change for CVE-2023-5680 that can cause named to crash2024-03-08T11:03:30ZCathy AlmondRegression in change for CVE-2023-5680 that can cause named to crashReported to us by an OEM customer who integrates BIND into their own appliance and redistributes:
> NOTE: you might find this as a security issue.
>
> We believe we've identified the likely cause of the crash. It's a regression due to ...Reported to us by an OEM customer who integrates BIND into their own appliance and redistributes:
> NOTE: you might find this as a security issue.
>
> We believe we've identified the likely cause of the crash. It's a regression due to the change for CVE-2023-5680. I've added a patch to a unit test for BIND 9.18.24-S1 that can reproduce the crash. I confirmed the crash happened for 9.18.24-S1 and 9.16.48-S1. One straightforward fix is the other patch I've attached to this ticket.
>
> I believe an engineer familiar with the code base can understand how it happens by reading the patch (it has a lot of comments explaining it), so I won't repeat it here. But I'd note one thing: the introduction of the "old IP tree" breaks one critical assumption: when a node's last reference is released, the cleanup makes sure that there is no rdatasetheader that would still have to be cleaned up (such as an expired cache entry). With this, and the fact that whenerver an rdatasetheader makes a node dirty either a node (read or rw) lock is acquired or a node's reference is increased from 0, it was previously guaranteed that overmem purge never frees other entries that the purge code may reference later. Now that the basic assumption is broken, we now have this crash, and there might be other such cases.
>
> I've not tried to reproduce a crash using a `named` executable, but the unit test indicates it's probably possible to trigger the crash by an external attacker, albeit with some high barriers such as being listed as an "ecs-zone" in the named's configuration. You may want to deal with this case as such.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4594Reinstate '-T delay' support2024-02-21T22:55:09ZMark AndrewsReinstate '-T delay' supportThe following discussion from !8751 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8751#note_439018): (+3 comments)
> I wouldn't remove this. It needs to be rei...The following discussion from !8751 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8751#note_439018): (+3 comments)
> I wouldn't remove this. It needs to be reinstated at some point.
>
> bin/tests/system/pipelined/ns3/named.args:-m record,size,mctx -c named.conf -d 99 -D pipelined-ns3 -X named.lock -g -T delay=200